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_flush okay? Trying to flush pinned inodes doesn't seem that much of a good idea. From owner-xfs@oss.sgi.com Thu Sep 13 07:50:34 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Sep 2007 07:50: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=-3.3 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 l8DEoW4p011058 for ; Thu, 13 Sep 2007 07:50:33 -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 l8DEoW5H022698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Sep 2007 10:50:32 -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 l8DEoWG8008742; Thu, 13 Sep 2007 10:50:32 -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 l8DEoVng019903; Thu, 13 Sep 2007 10:50:31 -0400 Message-ID: <46E94E37.4030505@sandeen.net> Date: Thu, 13 Sep 2007 09:50:31 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: Christoph Hellwig CC: Mark Goodwin , xfs@oss.sgi.com Subject: Re: state of the cvs tree References: <20070912121938.GA16870@lst.de> <46E870AB.30906@sgi.com> <20070913104000.GB3351@lst.de> In-Reply-To: <20070913104000.GB3351@lst.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 12876 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: > 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. Yes ;-) I've got that patch in Fedora now, but it'd be great to have it come via upstream. -Eric From owner-xfs@oss.sgi.com Thu Sep 13 07:49:34 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Sep 2007 07:49: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=-1.4 required=5.0 tests=AWL,BAYES_20, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,URI_NOVOWEL 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 l8DEnT4p010652 for ; Thu, 13 Sep 2007 07:49:34 -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 l8DEnIdn021682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Sep 2007 10:49:18 -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 l8DEnIGG007680; Thu, 13 Sep 2007 10:49:18 -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 l8DEnGVM019095; Thu, 13 Sep 2007 10:49:17 -0400 Message-ID: <46E94DEC.3090404@sandeen.net> Date: Thu, 13 Sep 2007 09:49:16 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: Kumaraswamy.Namburu@barclayscapital.com CC: xfs@oss.sgi.com Subject: Re: Configuring XFS on Redhat Linux References: <53F49A183F99D94D9C84E062566A97E3037C6E1E@SGPPCMEU302VEUA.INTRANET.BARCAPINT.COM> In-Reply-To: <53F49A183F99D94D9C84E062566A97E3037C6E1E@SGPPCMEU302VEUA.INTRANET.BARCAPINT.COM> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 12875 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 Kumaraswamy.Namburu@barclayscapital.com wrote: > 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. unless you really need cvs, how about http via kernel.org? or the git tree? http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs-2.6.git If you want xfs for your 2.6.9-22.ELsmp kernel, you might just grab the xfs kernel module packages & xfs userspace from the Centos distribution. Or, since it looks like you're using scientific linux and not actually RHEL, maybe just ask them. -Eric From owner-xfs@oss.sgi.com Thu Sep 13 12:40:04 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Sep 2007 12:40:07 -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.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8DJdw4p003042 for ; Thu, 13 Sep 2007 12:40:03 -0700 Received: by wa-out-1112.google.com with SMTP id k22so773944waf for ; Thu, 13 Sep 2007 12:39:57 -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=4dnP2T3j83qxPe9YlPNuqGNftDDgGIcVKtQ0021a9io=; b=mVG5VXQ4ZeuYs5RjnfaLOdk+OCzoMxy3XbfRUlHfoz/gvWB00dpPzJT4QnqSFH3DfVLrBBTHl3FN/XguHOjZ0MjMeGL9vLQhHh/hcfK+IyAfWBncYjzqXIMN88opghanjXfNs4kZJIas4/9hNVyxh/I2Fqtxrz55SkeppMnVlGY= 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=Y4Ve9c5ClkBrVDQFDH9O0gE5UTzokActyGpcmpEfuibAOQ7H8UCUHB8ph9DqFRxWxU/ue5blaxbHQ0QANUMGG0na5hK6/HCByMXBkevW2aplGlCHPTRMSibvfaubhLVJKF1BBxnOjmv0iW2zrp0IRkSt4LbsO7kMGtN0CH7W8EA= Received: by 10.114.123.1 with SMTP id v1mr315505wac.1189712397038; Thu, 13 Sep 2007 12:39:57 -0700 (PDT) Received: by 10.114.123.20 with HTTP; Thu, 13 Sep 2007 12:39:56 -0700 (PDT) Message-ID: Date: Fri, 14 Sep 2007 01:09:56 +0530 From: "Bhagi rathi" To: "Josef Sipek" Subject: Re: compression Cc: "Jordan Mendler" , xfs@oss.sgi.com In-Reply-To: <20070912174216.GA5521@filer.fsl.cs.sunysb.edu> MIME-Version: 1.0 References: <654e62180709111643k4700c2bdibec2a16eb5446e76@mail.gmail.com> <20070912174216.GA5521@filer.fsl.cs.sunysb.edu> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 2313 X-archive-position: 12877 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 Using open source rsync seems to be smart enough to identify files which haven't been modified and use hard-link instead of copying the file. I am not sure that rsync used here is smart enough to identify the same file which haven't been modified. If hard-linking is already done, I believe that there is lot of duplication of data in the same file. It looks that open source rsync doesn't eliminate duplication of data that was already existing in older backup. It copies it again. Compressing the data for the same file across various backup snapshots can be very powerful and my guess is that it can definitely free more that 30% of your space. Note that this is not file-system wide compression, it is compression of the same file existing in various back-ups. Restore gets affected, but should be easy to tweak given that it can free lot of space. -Cheers, Saradhi. On 9/12/07, Josef Sipek wrote: > > 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 > > > [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Thu Sep 13 12:49:43 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Sep 2007 12:49: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.4 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.183]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8DJnc4p004667 for ; Thu, 13 Sep 2007 12:49:42 -0700 Received: by wa-out-1112.google.com with SMTP id k22so776795waf for ; Thu, 13 Sep 2007 12:49:40 -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=adpwz9bkWLnft4O8TTMR00IQbTNJ6uunPtdJnvw7Vwg=; b=nTX0bqUvFcmzm33Kwf7f1kEmGcCHXpfoRfPDZaDEL56oKwM6gjeWLeDYLLBmUJW2GEDB5b8IUQ9MNxNBtE0gpzSIOxr0nqg4Znjq7iffT2AiB4LVYYAHkQqV8lg2XcD+tMWXEqlrMVOVS960UcGDUU1OIbmNfAYJpiE9Cab2cLU= 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=FsLKCM3BKqMTCduWkF2F3fCkrYW6Dnep+H9R+U+w/czV40jWQ++gwTYEAc2cQGDfd38Yc+fZnVPnF5oBP6BWzalZnPPRCRJuKemRG/MjmlVKYmWZ1DJUScvnWny6KpEEnfOAhggMaYC3pEimBkjNa+qDDtRDS6AA8vDulq931Ls= Received: by 10.115.90.1 with SMTP id s1mr798544wal.1189711400927; Thu, 13 Sep 2007 12:23:20 -0700 (PDT) Received: by 10.114.123.20 with HTTP; Thu, 13 Sep 2007 12:23:20 -0700 (PDT) Message-ID: Date: Fri, 14 Sep 2007 00:53:20 +0530 From: "Bhagi rathi" To: "donaldd@sgi.com" Subject: Re: TAKE 970240 - kill BMAPI_DEVICE Cc: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com In-Reply-To: <20070913043416.CCFAC2F9EBDB@linuxbuild.melbourne.sgi.com> MIME-Version: 1.0 References: <20070913043416.CCFAC2F9EBDB@linuxbuild.melbourne.sgi.com> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 2340 X-archive-position: 12878 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 Can one of you let me know the process of submitting changes? Problem: Real time flag set on a regular file can race with directio which can lead to incorrect real time device for iomap in xfs_vm_direct_IO. This can happen only on the first I/O to the file as we don't set real time flag if any of the extents or delayed blocks present. Fix: xfs_setattr() { ... if (!(mask & XFS_AT_SIZE)) { if (need_io_lock && vap->va_xflags & XFS_XFLAG_REALTIME) lock_flags |= XFS_IOLOCK_EXCL; ..... } ... } -Thanks, Saradhi. On 9/13/07, donaldd@sgi.com wrote: > > 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 > > 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 > > 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 > > 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 > > > > [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Thu Sep 13 13:30:56 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Sep 2007 13:31:03 -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_05 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 l8DKUt4p011302 for ; Thu, 13 Sep 2007 13:30:56 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1IVvKx-0003te-5O; Thu, 13 Sep 2007 21:30:55 +0100 Date: Thu, 13 Sep 2007 21:30:55 +0100 From: Christoph Hellwig To: Bhagi rathi Cc: "donaldd@sgi.com" , xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: Re: TAKE 970240 - kill BMAPI_DEVICE Message-ID: <20070913203055.GA14895@infradead.org> References: <20070913043416.CCFAC2F9EBDB@linuxbuild.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 12879 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 Fri, Sep 14, 2007 at 12:53:20AM +0530, Bhagi rathi wrote: > Can one of you let me know the process of submitting changes? Just send a unified diff (using diff -u) to the list. > > Problem: Real time flag set on a regular file can race with directio which > can lead to > incorrect real time device for iomap in xfs_vm_direct_IO. This > can happen > only on the first I/O to the file as we don't set real time > flag if any of > the extents or delayed blocks present. > > Fix: > > xfs_setattr() { > ... > if (!(mask & XFS_AT_SIZE)) { > if (need_io_lock && vap->va_xflags & XFS_XFLAG_REALTIME) > lock_flags |= XFS_IOLOCK_EXCL; > ..... > } I have a patch queued up aswell, although it's after a reorganization of the code to not clutter xfs_setattr even more. If you want to send out the fix now please go ahead. From owner-xfs@oss.sgi.com Thu Sep 13 16:48:47 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Sep 2007 16:48: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.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 l8DNmi4p015396 for ; Thu, 13 Sep 2007 16:48:45 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA29438; Fri, 14 Sep 2007 09:48:35 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l8DNmWdD18456923; Fri, 14 Sep 2007 09:48:33 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l8DNmT5O18449973; Fri, 14 Sep 2007 09:48:29 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 14 Sep 2007 09:48:29 +1000 From: David Chinner To: Christoph Hellwig Cc: Mark Goodwin , xfs@oss.sgi.com Subject: Re: state of the cvs tree Message-ID: <20070913234829.GW734179@sgi.com> 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.4.2.1i X-archive-position: 12880 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 12:40:00PM +0200, Christoph Hellwig 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. > > 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" Ah, that's still sitting in my tree from a past life. It fell through the cracks, I think. It should go in to .24 > 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" *nod*. yeah, that's pretty trivial so should go as well. > 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. Yeah, that's been floating about for a bit and has been tested in FC8 so seems like a no-brainer for .24. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Sep 13 17:06:05 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Sep 2007 17:06: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=-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 l8E0624p018008 for ; Thu, 13 Sep 2007 17:06:03 -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 KAA29804; Fri, 14 Sep 2007 10:06:00 +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 l8E05xdD18337573; Fri, 14 Sep 2007 10:05:59 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l8E05uKQ17184835; Fri, 14 Sep 2007 10:05:56 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 14 Sep 2007 10:05:56 +1000 From: David Chinner To: Christoph Hellwig Cc: Lachlan McIlroy , 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: <20070914000556.GX734179@sgi.com> References: <200709130330.l8D3UGu9004196@redback.melbourne.sgi.com> <20070913112046.GA25515@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070913112046.GA25515@infradead.org> User-Agent: Mutt/1.4.2.1i X-archive-position: 12881 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 12:20:46PM +0100, Christoph Hellwig wrote: > 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/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). true - obvious to lachlan and myself, maybe not others. :/ > But hopefully I'll push changes to the core code soon > to move the filemap_datawrite/wait into fs domain completely. What timeframe are we looking at there? > 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. Sounds like another cleanup patch for Eric ;) > Why is removing the ipincount check in xfs_inode_flush okay? Trying > to flush pinned inodes doesn't seem that much of a good idea. The code is .... convoluted. In the case where we are doing an async flush, we check the pin count once we've got the locks so the pin count check is not really needed here. In the case of a sync flush, we'd return EAGAIN, which would then call use again with the FLUSH_LOG flag and so we'd do a log force to unpin the inode. If we then race with something to else, the inode could end up pinned again before we go to flush the inode and hence we'd end up not flushing the inode because the pin count was set again. Anyway, if we are doing a sync flush, it's a blocking operation and we want to push the log, which is exactly what will happen in xfs_iflush() when it calls xfs_iunpin_wait() if the inode is pinned. hence the check for xfs_ipincount() in the higher level is pretty much redundant as the correct log force will occur just by allowing the inode flush to continue. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Sep 13 19:54:47 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Sep 2007 19:54: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.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 l8E2sj4p017616 for ; Thu, 13 Sep 2007 19:54:47 -0700 Received: from liberator.sandeen.net (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 5DCF718003EF4; Thu, 13 Sep 2007 21:54:47 -0500 (CDT) Message-ID: <46E9F7F3.6090405@sandeen.net> Date: Thu, 13 Sep 2007 21:54:43 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: David Chinner CC: Christoph Hellwig , Mark Goodwin , xfs@oss.sgi.com Subject: Re: state of the cvs tree References: <20070912121938.GA16870@lst.de> <46E870AB.30906@sgi.com> <20070913104000.GB3351@lst.de> <20070913234829.GW734179@sgi.com> In-Reply-To: <20070913234829.GW734179@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 12882 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 David Chinner wrote: >> 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. > > Yeah, that's been floating about for a bit and has been tested in > FC8 so seems like a no-brainer for .24. you're assuming anyone besides me tested xfs in F8TestX... *grin* (F8Test2 was released today... hint hint...) -Eric From owner-xfs@oss.sgi.com Thu Sep 13 20:36:04 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Sep 2007 20:36: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=-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 l8E3a14p028454 for ; Thu, 13 Sep 2007 20:36: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 NAA04551; Fri, 14 Sep 2007 13:35:56 +1000 Message-ID: <46EA020A.2060106@sgi.com> Date: Fri, 14 Sep 2007 13:37:46 +1000 From: Vlad Apostolov User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH] xfs_dmapi: add MODULE_ tags References: <20070828202102.GB17289@lst.de> In-Reply-To: <20070828202102.GB17289@lst.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 12883 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 Sorry for the late reply Christoph. It is looking good. I will push the patch in the XFS development tree. Regards, Vlad Christoph Hellwig wrote: > Without these I get a warning about an unspecified license everytime > I try to load xfs_dmapi. > > > Signed-off-by: Christoph Hellwig > > Index: linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/dmapi/xfs_dm.c 2007-08-25 00:05:33.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c 2007-08-25 00:05:53.000000000 +0200 > @@ -3372,5 +3372,9 @@ xfs_dm_exit(void) > dmapi_unregister(&xfs_fs_type); > } > > +MODULE_AUTHOR("Silicon Graphics, Inc."); > +MODULE_DESCRIPTION("SGI XFS dmapi subsystem"); > +MODULE_LICENSE("GPL"); > + > module_init(xfs_dm_init); > module_exit(xfs_dm_exit); > > From owner-xfs@oss.sgi.com Thu Sep 13 21:50:50 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Sep 2007 21:50: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.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 l8E4ol4p013811 for ; Thu, 13 Sep 2007 21:50:49 -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 OAA06170; Fri, 14 Sep 2007 14:50:45 +1000 Message-ID: <46EA1392.3040505@sgi.com> Date: Fri, 14 Sep 2007 14:52:34 +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 970514: [PATCH] xfs_dmapi: add MODULE_ tags Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 12884 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 Signed-off-by: Christoph Hellwig Date: Fri Sep 14 14:48:04 AEST 2007 Workarea: soarer.melbourne.sgi.com:/home/vapo/isms/linux-xfs Inspected by: vapo 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:29687a fs/xfs/dmapi/xfs_dm.c - 1.54 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/xfs_dm.c.diff?r1=text&tr1=1.54&r2=text&tr2=1.53&f=h - pv 970514, author hch@lst.de, rv vapo - xfs_dmapi: add MODULE_ tags From owner-xfs@oss.sgi.com Fri Sep 14 01:33:23 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Sep 2007 01:33:26 -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=BAYES_05,SPF_HELO_PASS autolearn=ham version=3.2.0-pre1-r499012 Received: from sargon.lncsa.com (sargon.lncsa.com [212.99.8.251]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8E8XL4p026589 for ; Fri, 14 Sep 2007 01:33:22 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by sargon.lncsa.com (Postfix) with ESMTP id 4FFC53131B0E for ; Fri, 14 Sep 2007 10:09:47 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lncsa.com Received: from sargon.lncsa.com ([127.0.0.1]) by localhost (sargon.lncsa.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JVIJaqNc0NG for ; Fri, 14 Sep 2007 10:09:47 +0200 (CEST) Received: from zenon.apartia.fr (zenon.apartia.fr [10.0.3.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "zenon.apartia.fr", Issuer "ca.apartia.fr" (verified OK)) by sargon.lncsa.com (Postfix) with ESMTP id 26B903131B0D for ; Fri, 14 Sep 2007 10:09:47 +0200 (CEST) Received: from trajan.apartia.fr (trajan.apartia.fr [10.0.3.121]) by zenon.apartia.fr (Postfix) with ESMTP id 3EECFF09FE51F for ; Fri, 14 Sep 2007 10:09:23 +0200 (CEST) Received: by trajan.apartia.fr (Postfix, from userid 1000) id CFA8525105E6; Fri, 14 Sep 2007 10:09:26 +0200 (CEST) Date: Fri, 14 Sep 2007 10:09:26 +0200 From: Louis-David Mitterrand To: linux-xfs@oss.sgi.com Subject: can't remove dir Message-ID: <20070914080926.GA30150@apartia.fr> Mail-Followup-To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-11) X-archive-position: 12885 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vindex+lists-xfs@apartia.org Precedence: bulk X-list: xfs Hello, While cleaning up /lost+found a directory resisted removal: sylla:/lost+found# rm 1879629858 -rf rm: cannot remove directory `1879629858': Directory not empty The directory _is_ empty and "-rf" should remove it anyway, so this looks like a fs error. This is on debian unstable with 2.6.23-rc6. From owner-xfs@oss.sgi.com Fri Sep 14 01:38:25 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Sep 2007 01:38: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=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 l8E8cL4p027680 for ; Fri, 14 Sep 2007 01:38:25 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id BF33F1C00022D; Fri, 14 Sep 2007 04:38:22 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id BAA774019F6F; Fri, 14 Sep 2007 04:38:22 -0400 (EDT) Date: Fri, 14 Sep 2007 04:38:22 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Louis-David Mitterrand cc: linux-xfs@oss.sgi.com Subject: Re: [UNSURE] can't remove dir In-Reply-To: <20070914080926.GA30150@apartia.fr> Message-ID: References: <20070914080926.GA30150@apartia.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 12886 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, 14 Sep 2007, Louis-David Mitterrand wrote: > Hello, > > While cleaning up /lost+found a directory resisted removal: > > sylla:/lost+found# rm 1879629858 -rf > rm: cannot remove directory `1879629858': Directory not empty > > The directory _is_ empty and "-rf" should remove it anyway, so this > looks like a fs error. > > This is on debian unstable with 2.6.23-rc6. > > what does "ls -al 1879629858" say? From owner-xfs@oss.sgi.com Fri Sep 14 01:41:22 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Sep 2007 01:41: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.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.2.0-pre1-r499012 Received: from sargon.lncsa.com (sargon.lncsa.com [212.99.8.251]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8E8fL4p028459 for ; Fri, 14 Sep 2007 01:41:22 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by sargon.lncsa.com (Postfix) with ESMTP id 64A9F300E022 for ; Fri, 14 Sep 2007 10:41:23 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lncsa.com Received: from sargon.lncsa.com ([127.0.0.1]) by localhost (sargon.lncsa.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5aV6pzcuTg2q for ; Fri, 14 Sep 2007 10:41:23 +0200 (CEST) Received: from zenon.apartia.fr (zenon.apartia.fr [10.0.3.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "zenon.apartia.fr", Issuer "ca.apartia.fr" (verified OK)) by sargon.lncsa.com (Postfix) with ESMTP id 3CDB1300E343 for ; Fri, 14 Sep 2007 10:41:23 +0200 (CEST) Received: from trajan.apartia.fr (trajan.apartia.fr [10.0.3.121]) by zenon.apartia.fr (Postfix) with ESMTP id 7C6A4F09FE51F for ; Fri, 14 Sep 2007 10:41:22 +0200 (CEST) Received: by trajan.apartia.fr (Postfix, from userid 1000) id CD79125105E6; Fri, 14 Sep 2007 10:41:25 +0200 (CEST) Date: Fri, 14 Sep 2007 10:41:25 +0200 From: Louis-David Mitterrand To: linux-xfs@oss.sgi.com Subject: Re: [UNSURE] can't remove dir Message-ID: <20070914084125.GA31074@apartia.fr> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20070914080926.GA30150@apartia.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-11) X-archive-position: 12887 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vindex+lists-xfs@apartia.org Precedence: bulk X-list: xfs On Fri, Sep 14, 2007 at 04:38:22AM -0400, Justin Piszcz wrote: > > On Fri, 14 Sep 2007, Louis-David Mitterrand wrote: >> >> While cleaning up /lost+found a directory resisted removal: >> >> sylla:/lost+found# rm 1879629858 -rf >> rm: cannot remove directory `1879629858': Directory not empty >> >> The directory _is_ empty and "-rf" should remove it anyway, so this >> looks like a fs error. >> >> This is on debian unstable with 2.6.23-rc6. > > what does "ls -al 1879629858" say? > I knew someone would ask, and this is slightly insulting ;-) sylla:/lost+found# ls -al 1879629858 total 24 drwxr-xr-x 2 root root 8192 2007-09-14 09:25 ./ drwxr-xr-x 3 root root 299008 2007-09-14 10:05 ../ From owner-xfs@oss.sgi.com Fri Sep 14 01:45:31 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Sep 2007 01:45: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.2 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 l8E8jT4p029431 for ; Fri, 14 Sep 2007 01:45:30 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 8D7E11C000265; Fri, 14 Sep 2007 04:45:31 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 88B014019F6F; Fri, 14 Sep 2007 04:45:31 -0400 (EDT) Date: Fri, 14 Sep 2007 04:45:31 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Louis-David Mitterrand cc: linux-xfs@oss.sgi.com Subject: Re: [UNSURE] can't remove dir In-Reply-To: <20070914084125.GA31074@apartia.fr> Message-ID: References: <20070914080926.GA30150@apartia.fr> <20070914084125.GA31074@apartia.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 12888 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, 14 Sep 2007, Louis-David Mitterrand wrote: > On Fri, Sep 14, 2007 at 04:38:22AM -0400, Justin Piszcz wrote: >> >> On Fri, 14 Sep 2007, Louis-David Mitterrand wrote: >>> >>> While cleaning up /lost+found a directory resisted removal: >>> >>> sylla:/lost+found# rm 1879629858 -rf >>> rm: cannot remove directory `1879629858': Directory not empty >>> >>> The directory _is_ empty and "-rf" should remove it anyway, so this >>> looks like a fs error. >>> >>> This is on debian unstable with 2.6.23-rc6. >> >> what does "ls -al 1879629858" say? >> > > I knew someone would ask, and this is slightly insulting ;-) > > sylla:/lost+found# ls -al 1879629858 > total 24 > drwxr-xr-x 2 root root 8192 2007-09-14 09:25 ./ > drwxr-xr-x 3 root root 299008 2007-09-14 10:05 ../ > > What happens if you reboot to (e.g., knoppix) and run: xfs_check /dev/that_partition? and/or: xfs_repair -n /dev/that_partition? -n No modify mode. Specifies that xfs_repair should not modify the filesystem but should only scan the filesystem and indicate what repairs would have been made. This would be useful to figure out what went wrong. Justin. From owner-xfs@oss.sgi.com Fri Sep 14 02:10:36 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Sep 2007 02:10: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=-1.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_45 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 l8E9AX4p001752 for ; Fri, 14 Sep 2007 02:10:35 -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 TAA12556 for ; Fri, 14 Sep 2007 19:10:34 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l8E9AXdD18678008 for ; Fri, 14 Sep 2007 19:10:34 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l8E9AWAp18677735 for linux-xfs@oss.sgi.com; Fri, 14 Sep 2007 19:10:32 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 14 Sep 2007 19:10:32 +1000 From: David Chinner To: linux-xfs@oss.sgi.com Subject: Re: [UNSURE] can't remove dir Message-ID: <20070914091032.GE734179@sgi.com> References: <20070914080926.GA30150@apartia.fr> <20070914084125.GA31074@apartia.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070914084125.GA31074@apartia.fr> User-Agent: Mutt/1.4.2.1i X-archive-position: 12889 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 14, 2007 at 10:41:25AM +0200, Louis-David Mitterrand wrote: > On Fri, Sep 14, 2007 at 04:38:22AM -0400, Justin Piszcz wrote: > > > > On Fri, 14 Sep 2007, Louis-David Mitterrand wrote: > >> > >> While cleaning up /lost+found a directory resisted removal: > >> > >> sylla:/lost+found# rm 1879629858 -rf > >> rm: cannot remove directory `1879629858': Directory not empty > >> > >> The directory _is_ empty and "-rf" should remove it anyway, so this > >> looks like a fs error. > >> > >> This is on debian unstable with 2.6.23-rc6. > > > > what does "ls -al 1879629858" say? > > > > I knew someone would ask, and this is slightly insulting ;-) Well, feel insulted if you want, but it was *exactly* the right question to ask. :/ Looking at the link count of the directory that can't be removed: > sylla:/lost+found# ls -al 1879629858 > total 24 > drwxr-xr-x 2 root root 8192 2007-09-14 09:25 ./ Which is correct for an empty directory. So this code in xfs_rmdir: ASSERT(cdp->i_d.di_nlink >= 2); if (cdp->i_d.di_nlink != 2) { error = XFS_ERROR(ENOTEMPTY); goto error_return; } is not where the error is coming from. But, the size indicates that the dirctory is not in shortform state. An empty directory should look like: # mkdir empty # ls -la empty total 0 drwxrwxr-x 2 root root 6 Sep 14 18:58 ./ ^^ drwxrwxr-x 4 root root 28 Sep 14 18:58 ../ # So that means the error came from: if (!xfs_dir_isempty(cdp)) { error = XFS_ERROR(ENOTEMPTY); goto error_return; } xfs_dir_isempty( xfs_inode_t *dp) { xfs_dir2_sf_t *sfp; ASSERT((dp->i_d.di_mode & S_IFMT) == S_IFDIR); if (dp->i_d.di_size == 0) /* might happen during shutdown. */ return 1; >>>>>>> if (dp->i_d.di_size > XFS_IFORK_DSIZE(dp)) >>>>>>> return 0; sfp = (xfs_dir2_sf_t *)dp->i_df.if_u1.if_data; return !sfp->hdr.count; } So, this wasn't a stupid question at all. It indicates that the source of the problem is a directory that did not get converted back to short form as the entries were removed and greatly narrows down teh possible causes of the problem. Can you tell us the output of 'xfs_info '? Also, get the inode number of the bad directory (ls -i) and then run: # xfs_db -r -c "inode " -c "p" So we can see what the state of the inode is? BTW, what problem led you to running xfs_repair in the first place (i.e. what led to lost+found getting populated)? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Fri Sep 14 02:50:03 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Sep 2007 02:50:07 -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,J_CHICKENPOX_43, J_CHICKENPOX_44,J_CHICKENPOX_45,J_CHICKENPOX_46,J_CHICKENPOX_47, J_CHICKENPOX_48,SPF_HELO_PASS autolearn=no version=3.2.0-pre1-r499012 Received: from sargon.lncsa.com (sargon.lncsa.com [212.99.8.251]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8E9o14p009786 for ; Fri, 14 Sep 2007 02:50:03 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by sargon.lncsa.com (Postfix) with ESMTP id 904F4302557A for ; Fri, 14 Sep 2007 11:27:31 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lncsa.com Received: from sargon.lncsa.com ([127.0.0.1]) by localhost (sargon.lncsa.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQjtE9b0gnb7 for ; Fri, 14 Sep 2007 11:27:31 +0200 (CEST) Received: from zenon.apartia.fr (zenon.apartia.fr [10.0.3.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "zenon.apartia.fr", Issuer "ca.apartia.fr" (verified OK)) by sargon.lncsa.com (Postfix) with ESMTP id 6F3B13025570 for ; Fri, 14 Sep 2007 11:27:31 +0200 (CEST) Received: from trajan.apartia.fr (trajan.apartia.fr [10.0.3.121]) by zenon.apartia.fr (Postfix) with ESMTP id 6D943F0A253A2 for ; Fri, 14 Sep 2007 11:27:18 +0200 (CEST) Received: by trajan.apartia.fr (Postfix, from userid 1000) id 0545E25105E6; Fri, 14 Sep 2007 11:27:21 +0200 (CEST) Date: Fri, 14 Sep 2007 11:27:21 +0200 From: Louis-David Mitterrand To: linux-xfs@oss.sgi.com Subject: Re: can't remove dir Message-ID: <20070914092712.GA31997@apartia.fr> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20070914080926.GA30150@apartia.fr> <20070914084125.GA31074@apartia.fr> <20070914091032.GE734179@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070914091032.GE734179@sgi.com> User-Agent: Mutt/1.5.16 (2007-06-11) X-archive-position: 12890 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vindex+lists-xfs@apartia.org Precedence: bulk X-list: xfs On Fri, Sep 14, 2007 at 07:10:32PM +1000, David Chinner wrote: > > Can you tell us the output of 'xfs_info '? sylla:~# xfs_info / meta-data=/dev/root isize=256 agcount=41, agsize=15252656 blks = sectsz=4096 attr=1 data = bsize=4096 blocks=610178720, imaxpct=25 = sunit=16 swidth=80 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=2 = sectsz=4096 sunit=1 blks, lazy-count=0 realtime =none extsz=327680 blocks=0, rtextents=0 > Also, get the inode number of the bad directory (ls -i) and then > run: > > # xfs_db -r -c "inode " -c "p" sylla:/lost+found# xfs_db -r -c "inode 1879629858" -c "p" /dev/md1 core.magic = 0x494e core.mode = 040755 core.version = 1 core.format = 2 (extents) core.nlinkv1 = 2 core.uid = 0 core.gid = 0 core.flushiter = 9 core.atime.sec = Tue Aug 1 20:49:16 2006 core.atime.nsec = 000000000 core.mtime.sec = Fri Sep 14 09:25:29 2007 core.mtime.nsec = 589593557 core.ctime.sec = Fri Sep 14 09:25:29 2007 core.ctime.nsec = 589593557 core.size = 8192 core.nblocks = 3 core.extsize = 0 core.nextents = 2 core.naextents = 0 core.forkoff = 0 core.aformat = 2 (extents) core.dmevmask = 0 core.dmstate = 0 core.newrtbm = 0 core.prealloc = 0 core.realtime = 0 core.immutable = 0 core.append = 0 core.sync = 0 core.noatime = 0 core.nodump = 0 core.rtinherit = 0 core.projinherit = 0 core.nosymlinks = 0 core.extsz = 0 core.extszinherit = 0 core.nodefrag = 0 core.gen = 0 next_unlinked = null u.bmx[0-1] = [startoff,startblock,blockcount,extentflag] 0:[0,117476868,2,0] 1:[8388608,125865476,1,0] > So we can see what the state of the inode is? > > BTW, what problem led you to running xfs_repair in the first > place (i.e. what led to lost+found getting populated)? The infamous 2.6.17.1 corruption. Thanks, From owner-xfs@oss.sgi.com Fri Sep 14 06:05:23 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Sep 2007 06:05:26 -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 rubicon.netdirect.ca (nic.NetDirect.CA [216.16.235.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8ED5L4p016133 for ; Fri, 14 Sep 2007 06:05:23 -0700 X-Envelope-To: X-Originating-Ip: 72.143.66.27 Received: from [192.168.1.100] (CPE0018396a01fc-CM001225dbafb6.cpe.net.cable.rogers.com [72.143.66.27]) (authenticated bits=0) by rubicon.netdirect.ca (8.13.1/8.13.1) with ESMTP id l8ECsr61011936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 14 Sep 2007 08:55:04 -0400 Date: Fri, 14 Sep 2007 08:53:20 -0400 (EDT) From: "Robert P. J. Day" X-X-Sender: rpjday@localhost.localdomain To: xfs@oss.sgi.com Subject: [PATCH] XFS: Delete duplicate macro definitions. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Net-Direct-Inc-MailScanner-Information: Please contact the ISP for more information X-Net-Direct-Inc-MailScanner: Found to be clean X-Net-Direct-Inc-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-16.723, required 5, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -15.00, INIT_RECVD_OUR_AUTH -20.00, RCVD_IN_SORBS_DUL 20.00, TW_BM 0.08, UPPERCASE_25_50 0.00) X-Net-Direct-Inc-MailScanner-From: rpjday@mindspring.com X-archive-position: 12891 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: rpjday@mindspring.com Precedence: bulk X-list: xfs Signed-off-by: Robert P. J. Day --- something that popped out of a script i have that scans for redundant macro definitions. apply or not as you see fit. not compile-tested as it was just done visually. diff --git a/fs/xfs/xfs_bmap_btree.h b/fs/xfs/xfs_bmap_btree.h index a77b1b7..0173575 100644 --- a/fs/xfs/xfs_bmap_btree.h +++ b/fs/xfs/xfs_bmap_btree.h @@ -47,28 +47,25 @@ typedef struct xfs_bmdr_block { * l1:0-20 are blockcount. */ +#define BMBT_TOTAL_BITLEN 128 /* 128 bits, 16 bytes */ +#define BMBT_EXNTFLAG_BITLEN 1 +#define BMBT_STARTOFF_BITLEN 54 +#define BMBT_STARTBLOCK_BITLEN 52 + #ifndef XFS_NATIVE_HOST -#define BMBT_TOTAL_BITLEN 128 /* 128 bits, 16 bytes */ #define BMBT_EXNTFLAG_BITOFF 0 -#define BMBT_EXNTFLAG_BITLEN 1 #define BMBT_STARTOFF_BITOFF (BMBT_EXNTFLAG_BITOFF + BMBT_EXNTFLAG_BITLEN) -#define BMBT_STARTOFF_BITLEN 54 #define BMBT_STARTBLOCK_BITOFF (BMBT_STARTOFF_BITOFF + BMBT_STARTOFF_BITLEN) -#define BMBT_STARTBLOCK_BITLEN 52 #define BMBT_BLOCKCOUNT_BITOFF \ (BMBT_STARTBLOCK_BITOFF + BMBT_STARTBLOCK_BITLEN) #define BMBT_BLOCKCOUNT_BITLEN (BMBT_TOTAL_BITLEN - BMBT_BLOCKCOUNT_BITOFF) #else -#define BMBT_TOTAL_BITLEN 128 /* 128 bits, 16 bytes */ #define BMBT_EXNTFLAG_BITOFF 63 -#define BMBT_EXNTFLAG_BITLEN 1 #define BMBT_STARTOFF_BITOFF (BMBT_EXNTFLAG_BITOFF - BMBT_STARTOFF_BITLEN) -#define BMBT_STARTOFF_BITLEN 54 #define BMBT_STARTBLOCK_BITOFF 85 /* 128 - 43 (other 9 is in first word) */ -#define BMBT_STARTBLOCK_BITLEN 52 #define BMBT_BLOCKCOUNT_BITOFF 64 /* Start of second 64 bit container */ #define BMBT_BLOCKCOUNT_BITLEN 21 -- ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca ======================================================================== From owner-xfs@oss.sgi.com Fri Sep 14 07:14:25 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Sep 2007 07:14: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.3 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 l8EEEO4p031669 for ; Fri, 14 Sep 2007 07:14: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 1AE2D18003EF4 for ; Fri, 14 Sep 2007 09:14:26 -0500 (CDT) Message-ID: <46EA9741.6060303@sandeen.net> Date: Fri, 14 Sep 2007 09:14:25 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: can't remove dir References: <20070914080926.GA30150@apartia.fr> In-Reply-To: <20070914080926.GA30150@apartia.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 12892 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 Louis-David Mitterrand wrote: > Hello, > > While cleaning up /lost+found a directory resisted removal: > > sylla:/lost+found# rm 1879629858 -rf > rm: cannot remove directory `1879629858': Directory not empty > > The directory _is_ empty and "-rf" should remove it anyway, so this > looks like a fs error. > > This is on debian unstable with 2.6.23-rc6. > > Any errors in the system logs? I'd try most recent xfs_repair next. If that doesn't fix it, make an xfs_metadump for Barry to look at. :) Make a backup first if you're paranoid. -Eric From owner-xfs@oss.sgi.com Fri Sep 14 07:18:22 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Sep 2007 07:18: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.3 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 l8EEIL4p000514 for ; Fri, 14 Sep 2007 07:18: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 2479918003EF4 for ; Fri, 14 Sep 2007 09:18:24 -0500 (CDT) Message-ID: <46EA982F.5090109@sandeen.net> Date: Fri, 14 Sep 2007 09:18:23 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: can't remove dir References: <20070914080926.GA30150@apartia.fr> <46EA9741.6060303@sandeen.net> In-Reply-To: <46EA9741.6060303@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 12893 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: > Louis-David Mitterrand wrote: >> Hello, >> >> While cleaning up /lost+found a directory resisted removal: >> >> sylla:/lost+found# rm 1879629858 -rf >> rm: cannot remove directory `1879629858': Directory not empty >> >> The directory _is_ empty and "-rf" should remove it anyway, so this >> looks like a fs error. >> >> This is on debian unstable with 2.6.23-rc6. >> >> > > Any errors in the system logs? I'd try most recent xfs_repair next. If > that doesn't fix it, make an xfs_metadump for Barry to look at. :) > Make a backup first if you're paranoid. Some day I'll learn to read all of a thread before replying... ignore me. Looks like dgc has things well under control. :) -Eric From owner-xfs@oss.sgi.com Fri Sep 14 07:27:15 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Sep 2007 07:27: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.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 l8EERD4p002702 for ; Fri, 14 Sep 2007 07:27:15 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1IWBpJ-0006De-IZ; Fri, 14 Sep 2007 15:07:21 +0100 Date: Fri, 14 Sep 2007 15:07:21 +0100 From: Christoph Hellwig To: "Robert P. J. Day" Cc: xfs@oss.sgi.com Subject: Re: [PATCH] XFS: Delete duplicate macro definitions. Message-ID: <20070914140721.GA23878@infradead.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 12894 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 Fri, Sep 14, 2007 at 08:53:20AM -0400, Robert P. J. Day wrote: > > Signed-off-by: Robert P. J. Day > > --- > > something that popped out of a script i have that scans for > redundant macro definitions. apply or not as you see fit. not > compile-tested as it was just done visually. Yes, this is correct. But I've already done this and a little more in this area - these changes are in XFS CVS already and will go into 2.6.24. From owner-xfs@oss.sgi.com Fri Sep 14 07:46:05 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Sep 2007 07:46: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=-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 l8EEk34p006850 for ; Fri, 14 Sep 2007 07:46:04 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1IWCQm-0006kb-TE; Fri, 14 Sep 2007 15:46:04 +0100 Date: Fri, 14 Sep 2007 15:46:04 +0100 From: Christoph Hellwig To: David Chinner Cc: Christoph Hellwig , Lachlan McIlroy , 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: <20070914144604.GA25941@infradead.org> References: <200709130330.l8D3UGu9004196@redback.melbourne.sgi.com> <20070913112046.GA25515@infradead.org> <20070914000556.GX734179@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070914000556.GX734179@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: 12895 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 Fri, Sep 14, 2007 at 10:05:56AM +1000, David Chinner wrote: > > But hopefully I'll push changes to the core code soon > > to move the filemap_datawrite/wait into fs domain completely. > > What timeframe are we looking at there? I'll aim for 2.6.25, but there is some mess to sort out with the fsync prototype first. From owner-xfs@oss.sgi.com Fri Sep 14 09:28:11 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Sep 2007 09:28: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,J_CHICKENPOX_35, J_CHICKENPOX_66 autolearn=no 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 l8EGS94p028634 for ; Fri, 14 Sep 2007 09:28:10 -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 l8EGS9A5007415 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 14 Sep 2007 18:28:09 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8EGS8bN007413 for xfs@oss.sgi.com; Fri, 14 Sep 2007 18:28:08 +0200 Date: Fri, 14 Sep 2007 18:28:08 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: [PATCH 2/2] kill xfs_iocore_t Message-ID: <20070914162808.GF7110@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: 12901 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 xfs_iocore_t is a structure embedded in xfs_inode. Except for one field it just duplicates fields already in xfs_inode, and there is nothing this abstraction buys us on XFS/Linux. This patch removes it and shrinks source and binary size of xfs aswell as shrinking the size of xfs_inode by 60/44 bytes in debug/non-debug builds. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/Makefile-linux-2.6 =================================================================== --- linux-2.6-xfs.orig/fs/xfs/Makefile-linux-2.6 2007-09-12 13:12:59.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/Makefile-linux-2.6 2007-09-12 14:05:49.000000000 +0200 @@ -60,7 +60,6 @@ xfs-y += xfs_alloc.o \ xfs_iget.o \ xfs_inode.o \ xfs_inode_item.o \ - xfs_iocore.o \ xfs_iomap.o \ xfs_itable.o \ xfs_dfrag.o \ Index: linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/dmapi/xfs_dm.c 2007-09-12 14:05:07.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c 2007-09-12 14:05:49.000000000 +0200 @@ -187,7 +187,7 @@ xfs_dm_send_data_event( ip = xfs_vtoi(vp); do { - dmstate = ip->i_iocore.io_dmstate; + dmstate = ip->i_d.di_dmstate; if (locktype) xfs_rwunlock(ip, *locktype); @@ -201,7 +201,7 @@ xfs_dm_send_data_event( if (locktype) xfs_rwlock(ip, *locktype); - } while (!error && (ip->i_iocore.io_dmstate != dmstate)); + } while (!error && (ip->i_d.di_dmstate != dmstate)); return error; } @@ -1017,7 +1017,6 @@ xfs_dm_f_set_eventlist( xfs_trans_ijoin(tp, ip, XFS_ILOCK_EXCL); ip->i_d.di_dmevmask = (eventset & max_mask) | (ip->i_d.di_dmevmask & ~max_mask); - ip->i_iocore.io_dmevmask = ip->i_d.di_dmevmask; xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); VN_HOLD(vp); @@ -2597,7 +2596,7 @@ xfs_dm_punch_hole( error = -error; /* Let threads in send_data_event know we punched the file. */ - ip->i_iocore.io_dmstate++; + ip->i_d.di_dmstate++; xfs_iunlock(ip, XFS_IOLOCK_EXCL); xfs_iflags_set(ip, XFS_IMODIFIED); @@ -2925,7 +2924,7 @@ xfs_dm_set_region( * bit, then that's always okay. Otherwise, it's busy. */ dm_eventset_t m1; - m1 = ip->i_iocore.io_dmevmask & ((1 << DM_EVENT_WRITE) | (1 << DM_EVENT_TRUNCATE)); + m1 = ip->i_d.di_dmevmask & ((1 << DM_EVENT_WRITE) | (1 << DM_EVENT_TRUNCATE)); if (m1 != new_mask) { return -EBUSY; } @@ -2942,7 +2941,6 @@ xfs_dm_set_region( xfs_trans_ijoin(tp, ip, XFS_ILOCK_EXCL); ip->i_d.di_dmevmask = (ip->i_d.di_dmevmask & ~mr_mask) | new_mask; - ip->i_iocore.io_dmevmask = ip->i_d.di_dmevmask; xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); VN_HOLD(vp); @@ -3221,7 +3219,7 @@ xfs_dm_send_mmap_event( offset = 0; /* beginning of file, for now */ length = 0; /* whole file, for now */ - filesize = ip->i_iocore.io_new_size; + filesize = ip->i_new_size; if (filesize < ip->i_size) { filesize = ip->i_size; } 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-12 14:05:43.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_aops.c 2007-09-12 14:05:49.000000000 +0200 @@ -163,7 +163,7 @@ xfs_destroy_ioend( /* * Update on-disk file size now that data has been written to disk. * The current in-memory file size is i_size. If a write is beyond - * eof io_new_size will be the intended file size until i_size is + * eof i_new_size will be the intended file size until i_size is * updated. If this write does not extend all the way to the valid * file size then restrict this update to the end of the write. */ @@ -185,7 +185,7 @@ xfs_setfilesize( xfs_ilock(ip, XFS_ILOCK_EXCL); - isize = MAX(ip->i_size, ip->i_iocore.io_new_size); + isize = MAX(ip->i_size, ip->i_new_size); isize = MIN(isize, bsize); if (ip->i_d.di_size < isize) { Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ksyms.c 2007-09-12 14:05:43.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c 2007-09-12 14:05:49.000000000 +0200 @@ -247,7 +247,6 @@ EXPORT_SYMBOL(xfs_ilock_map_shared); EXPORT_SYMBOL(xfs_ilock_nowait); EXPORT_SYMBOL(xfs_inode_lock_init); EXPORT_SYMBOL(xfs_internal_inum); -EXPORT_SYMBOL(xfs_iocore_inode_init); EXPORT_SYMBOL(xfs_iput); EXPORT_SYMBOL(xfs_iput_new); EXPORT_SYMBOL(xfs_iread); Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_lrw.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_lrw.c 2007-09-12 14:05:43.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_lrw.c 2007-09-12 14:06:32.000000000 +0200 @@ -58,14 +58,12 @@ void xfs_rw_enter_trace( int tag, - xfs_iocore_t *io, + xfs_inode_t *ip, void *data, size_t segs, loff_t offset, int ioflags) { - xfs_inode_t *ip = XFS_IO_INODE(io); - if (ip->i_rwtrace == NULL) return; ktrace_enter(ip->i_rwtrace, @@ -78,8 +76,8 @@ xfs_rw_enter_trace( (void *)((unsigned long)((offset >> 32) & 0xffffffff)), (void *)((unsigned long)(offset & 0xffffffff)), (void *)((unsigned long)ioflags), - (void *)((unsigned long)((io->io_new_size >> 32) & 0xffffffff)), - (void *)((unsigned long)(io->io_new_size & 0xffffffff)), + (void *)((unsigned long)((ip->i_new_size >> 32) & 0xffffffff)), + (void *)((unsigned long)(ip->i_new_size & 0xffffffff)), (void *)((unsigned long)current_pid()), (void *)NULL, (void *)NULL, @@ -89,13 +87,12 @@ xfs_rw_enter_trace( void xfs_inval_cached_trace( - xfs_iocore_t *io, + xfs_inode_t *ip, xfs_off_t offset, xfs_off_t len, xfs_off_t first, xfs_off_t last) { - xfs_inode_t *ip = XFS_IO_INODE(io); if (ip->i_rwtrace == NULL) return; @@ -267,7 +264,7 @@ xfs_read( } } - xfs_rw_enter_trace(XFS_READ_ENTER, &ip->i_iocore, + xfs_rw_enter_trace(XFS_READ_ENTER, ip, (void *)iovp, segs, *offset, ioflags); iocb->ki_pos = *offset; @@ -312,7 +309,7 @@ xfs_splice_read( return -error; } } - xfs_rw_enter_trace(XFS_SPLICE_READ_ENTER, &ip->i_iocore, + xfs_rw_enter_trace(XFS_SPLICE_READ_ENTER, ip, pipe, count, *ppos, ioflags); ret = generic_file_splice_read(infilp, ppos, pipe, count, flags); if (ret > 0) @@ -334,7 +331,6 @@ xfs_splice_write( { bhv_vnode_t *vp = XFS_ITOV(ip); xfs_mount_t *mp = ip->i_mount; - xfs_iocore_t *io = &ip->i_iocore; ssize_t ret; struct inode *inode = outfilp->f_mapping->host; xfs_fsize_t isize, new_size; @@ -361,10 +357,10 @@ xfs_splice_write( xfs_ilock(ip, XFS_ILOCK_EXCL); if (new_size > ip->i_size) - io->io_new_size = new_size; + ip->i_new_size = new_size; xfs_iunlock(ip, XFS_ILOCK_EXCL); - xfs_rw_enter_trace(XFS_SPLICE_WRITE_ENTER, &ip->i_iocore, + xfs_rw_enter_trace(XFS_SPLICE_WRITE_ENTER, ip, pipe, count, *ppos, ioflags); ret = generic_file_splice_write(pipe, outfilp, ppos, count, flags); if (ret > 0) @@ -381,9 +377,9 @@ xfs_splice_write( xfs_iunlock(ip, XFS_ILOCK_EXCL); } - if (io->io_new_size) { + if (ip->i_new_size) { xfs_ilock(ip, XFS_ILOCK_EXCL); - io->io_new_size = 0; + ip->i_new_size = 0; if (ip->i_d.di_size > ip->i_size) ip->i_d.di_size = ip->i_size; xfs_iunlock(ip, XFS_ILOCK_EXCL); @@ -469,26 +465,24 @@ xfs_zero_last_block( int /* error (positive) */ xfs_zero_eof( - bhv_vnode_t *vp, - xfs_iocore_t *io, + xfs_inode_t *ip, xfs_off_t offset, /* starting I/O offset */ xfs_fsize_t isize) /* current inode size */ { - struct inode *inode = vn_to_inode(vp); - xfs_inode_t *ip = XFS_I(inode); + struct inode *inode = XFS_ITOV(ip); xfs_fileoff_t start_zero_fsb; xfs_fileoff_t end_zero_fsb; xfs_fileoff_t zero_count_fsb; xfs_fileoff_t last_fsb; xfs_fileoff_t zero_off; xfs_fsize_t zero_len; - xfs_mount_t *mp = io->io_mount; + xfs_mount_t *mp = ip->i_mount; int nimaps; int error = 0; xfs_bmbt_irec_t imap; - ASSERT(ismrlocked(io->io_lock, MR_UPDATE)); - ASSERT(ismrlocked(io->io_iolock, MR_UPDATE)); + ASSERT(ismrlocked(&ip->i_lock, MR_UPDATE)); + ASSERT(ismrlocked(&ip->i_iolock, MR_UPDATE)); ASSERT(offset > isize); /* @@ -497,8 +491,8 @@ xfs_zero_eof( */ error = xfs_zero_last_block(inode, ip, offset, isize); if (error) { - ASSERT(ismrlocked(io->io_lock, MR_UPDATE)); - ASSERT(ismrlocked(io->io_iolock, MR_UPDATE)); + ASSERT(ismrlocked(&ip->i_lock, MR_UPDATE)); + ASSERT(ismrlocked(&ip->i_iolock, MR_UPDATE)); return error; } @@ -529,8 +523,8 @@ xfs_zero_eof( error = xfs_bmapi(NULL, ip, start_zero_fsb, zero_count_fsb, 0, NULL, 0, &imap, &nimaps, NULL, NULL); if (error) { - ASSERT(ismrlocked(io->io_lock, MR_UPDATE)); - ASSERT(ismrlocked(io->io_iolock, MR_UPDATE)); + ASSERT(ismrlocked(&ip->i_lock, MR_UPDATE)); + ASSERT(ismrlocked(&ip->i_iolock, MR_UPDATE)); return error; } ASSERT(nimaps > 0); @@ -598,7 +592,6 @@ xfs_write( xfs_mount_t *mp; ssize_t ret = 0, error = 0; xfs_fsize_t isize, new_size; - xfs_iocore_t *io; int iolock; int eventsent = 0; bhv_vrwlock_t locktype; @@ -618,8 +611,7 @@ xfs_write( if (count == 0) return 0; - io = &xip->i_iocore; - mp = io->io_mount; + mp = xip->i_mount; xfs_wait_for_freeze(mp, SB_FREEZE_WRITE); @@ -699,7 +691,7 @@ start: new_size = pos + count; if (new_size > xip->i_size) - io->io_new_size = new_size; + xip->i_new_size = new_size; if (likely(!(ioflags & IO_INVIS))) { file_update_time(file); @@ -717,7 +709,7 @@ start: */ if (pos > xip->i_size) { - error = xfs_zero_eof(vp, io, pos, xip->i_size); + error = xfs_zero_eof(xip, pos, xip->i_size); if (error) { xfs_iunlock(xip, XFS_ILOCK_EXCL); goto out_unlock_internal; @@ -751,7 +743,7 @@ retry: if ((ioflags & IO_ISDIRECT)) { if (VN_CACHED(vp)) { WARN_ON(need_i_mutex == 0); - xfs_inval_cached_trace(io, pos, -1, + xfs_inval_cached_trace(xip, pos, -1, ctooff(offtoct(pos)), -1); error = xfs_flushinval_pages(xip, ctooff(offtoct(pos)), @@ -770,7 +762,7 @@ retry: need_i_mutex = 0; } - xfs_rw_enter_trace(XFS_DIOWR_ENTER, io, (void *)iovp, segs, + xfs_rw_enter_trace(XFS_DIOWR_ENTER, xip, (void *)iovp, segs, *offset, ioflags); ret = generic_file_direct_write(iocb, iovp, &segs, pos, offset, count, ocount); @@ -790,7 +782,7 @@ retry: goto relock; } } else { - xfs_rw_enter_trace(XFS_WRITE_ENTER, io, (void *)iovp, segs, + xfs_rw_enter_trace(XFS_WRITE_ENTER, xip, (void *)iovp, segs, *offset, ioflags); ret = generic_file_buffered_write(iocb, iovp, segs, pos, offset, count, ret); @@ -854,9 +846,9 @@ retry: } out_unlock_internal: - if (io->io_new_size) { + if (xip->i_new_size) { xfs_ilock(xip, XFS_ILOCK_EXCL); - io->io_new_size = 0; + xip->i_new_size = 0; /* * If this was a direct or synchronous I/O that failed (such * as ENOSPC) then part of the I/O may have been written to Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_lrw.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_lrw.h 2007-09-12 13:56:20.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_lrw.h 2007-09-12 14:05:49.000000000 +0200 @@ -19,7 +19,6 @@ #define __XFS_LRW_H__ struct xfs_mount; -struct xfs_iocore; struct xfs_inode; struct xfs_bmbt_irec; struct xfs_buf; @@ -59,20 +58,19 @@ struct xfs_iomap; #define XFS_IOMAP_UNWRITTEN 27 #define XFS_SPLICE_READ_ENTER 28 #define XFS_SPLICE_WRITE_ENTER 29 -extern void xfs_rw_enter_trace(int, struct xfs_iocore *, +extern void xfs_rw_enter_trace(int, struct xfs_inode *, void *, size_t, loff_t, int); -extern void xfs_inval_cached_trace(struct xfs_iocore *, +extern void xfs_inval_cached_trace(struct xfs_inode *, xfs_off_t, xfs_off_t, xfs_off_t, xfs_off_t); #else -#define xfs_rw_enter_trace(tag, io, data, size, offset, ioflags) -#define xfs_inval_cached_trace(io, offset, len, first, last) +#define xfs_rw_enter_trace(tag, ip, data, size, offset, ioflags) +#define xfs_inval_cached_trace(ip, offset, len, first, last) #endif extern int xfsbdstrat(struct xfs_mount *, struct xfs_buf *); extern int xfs_bdstrat_cb(struct xfs_buf *); extern int xfs_dev_is_read_only(struct xfs_mount *, char *); -extern int xfs_zero_eof(struct inode *, struct xfs_iocore *, xfs_off_t, - xfs_fsize_t); +extern int xfs_zero_eof(struct xfs_inode *, xfs_off_t, xfs_fsize_t); #endif /* __XFS_LRW_H__ */ Index: linux-2.6-xfs/fs/xfs/xfs_dfrag.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_dfrag.c 2007-09-12 14:05:43.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_dfrag.c 2007-09-12 14:05:49.000000000 +0200 @@ -199,7 +199,7 @@ xfs_swap_extents( } if (VN_CACHED(tvp) != 0) { - xfs_inval_cached_trace(&tip->i_iocore, 0, -1, 0, -1); + xfs_inval_cached_trace(tip, 0, -1, 0, -1); error = xfs_flushinval_pages(tip, 0, -1, FI_REMAPF_LOCKED); if (error) Index: linux-2.6-xfs/fs/xfs/xfs_iget.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_iget.c 2007-09-12 13:56:15.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_iget.c 2007-09-12 14:05:49.000000000 +0200 @@ -200,12 +200,9 @@ again: XFS_STATS_INC(xs_ig_found); finish_inode: - if (ip->i_d.di_mode == 0) { - if (!(flags & XFS_IGET_CREATE)) { - xfs_put_perag(mp, pag); - return ENOENT; - } - xfs_iocore_inode_reinit(ip); + if (ip->i_d.di_mode == 0 && !(flags & XFS_IGET_CREATE)) { + xfs_put_perag(mp, pag); + return ENOENT; } if (lock_flags != 0) @@ -237,7 +234,6 @@ finish_inode: _xfs_itrace_exit(ip, "xfs_iget.alloc", (inst_t *)__return_address); xfs_inode_lock_init(ip, vp); - xfs_iocore_inode_init(ip); if (lock_flags) xfs_ilock(ip, lock_flags); @@ -333,9 +329,6 @@ finish_inode: ASSERT(ip->i_df.if_ext_max == XFS_IFORK_DSIZE(ip) / sizeof(xfs_bmbt_rec_t)); - ASSERT(((ip->i_d.di_flags & XFS_DIFLAG_REALTIME) != 0) == - ((ip->i_iocore.io_flags & XFS_IOCORE_RT) != 0)); - xfs_iflags_set(ip, XFS_IMODIFIED); *ipp = ip; Index: linux-2.6-xfs/fs/xfs/xfs_inode.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_inode.c 2007-09-12 14:05:43.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_inode.c 2007-09-12 14:05:49.000000000 +0200 @@ -1220,10 +1220,8 @@ xfs_ialloc( ip->i_d.di_extsize = pip->i_d.di_extsize; } } else if ((mode & S_IFMT) == S_IFREG) { - if (pip->i_d.di_flags & XFS_DIFLAG_RTINHERIT) { + if (pip->i_d.di_flags & XFS_DIFLAG_RTINHERIT) di_flags |= XFS_DIFLAG_REALTIME; - ip->i_iocore.io_flags |= XFS_IOCORE_RT; - } if (pip->i_d.di_flags & XFS_DIFLAG_EXTSZINHERIT) { di_flags |= XFS_DIFLAG_EXTSIZE; ip->i_d.di_extsize = pip->i_d.di_extsize; @@ -1842,8 +1840,6 @@ xfs_igrow_start( xfs_fsize_t new_size, cred_t *credp) { - int error; - ASSERT(ismrlocked(&(ip->i_lock), MR_UPDATE) != 0); ASSERT(ismrlocked(&(ip->i_iolock), MR_UPDATE) != 0); ASSERT(new_size > ip->i_size); @@ -1853,9 +1849,7 @@ xfs_igrow_start( * xfs_write_file() beyond the end of the file * and any blocks between the old and new file sizes. */ - error = xfs_zero_eof(XFS_ITOV(ip), &ip->i_iocore, new_size, - ip->i_size); - return error; + return xfs_zero_eof(ip, new_size, ip->i_size); } /* Index: linux-2.6-xfs/fs/xfs/xfs_inode.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_inode.h 2007-09-12 13:56:16.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_inode.h 2007-09-12 14:05:49.000000000 +0200 @@ -132,45 +132,6 @@ typedef struct dm_attrs_s { __uint16_t da_pad; /* DMIG extra padding */ } dm_attrs_t; -typedef struct xfs_iocore { - void *io_obj; /* pointer to container - * inode or dcxvn structure */ - struct xfs_mount *io_mount; /* fs mount struct ptr */ -#ifdef DEBUG - mrlock_t *io_lock; /* inode IO lock */ - mrlock_t *io_iolock; /* inode IO lock */ -#endif - - /* I/O state */ - xfs_fsize_t io_new_size; /* sz when write completes */ - - /* Miscellaneous state. */ - unsigned int io_flags; /* IO related flags */ - - /* DMAPI state */ - dm_attrs_t io_dmattrs; - -} xfs_iocore_t; - -#define io_dmevmask io_dmattrs.da_dmevmask -#define io_dmstate io_dmattrs.da_dmstate - -#define XFS_IO_INODE(io) ((xfs_inode_t *) ((io)->io_obj)) -#define XFS_IO_DCXVN(io) ((dcxvn_t *) ((io)->io_obj)) - -/* - * Flags in the flags field - */ - -#define XFS_IOCORE_RT 0x1 - -/* - * xfs_iocore prototypes - */ - -extern void xfs_iocore_inode_init(struct xfs_inode *); -extern void xfs_iocore_inode_reinit(struct xfs_inode *); - /* * This is the xfs inode cluster structure. This structure is used by * xfs_iflush to find inodes that share a cluster and can be flushed to disk at @@ -283,9 +244,6 @@ typedef struct xfs_inode { struct xfs_inode **i_refcache; /* ptr to entry in ref cache */ struct xfs_inode *i_release; /* inode to unref */ #endif - /* I/O state */ - xfs_iocore_t i_iocore; /* I/O core */ - /* Miscellaneous state. */ unsigned short i_flags; /* see defined flags below */ unsigned char i_update_core; /* timestamps/size is dirty */ @@ -298,6 +256,7 @@ typedef struct xfs_inode { struct hlist_node i_cnode; /* cluster link node */ xfs_fsize_t i_size; /* in-memory size */ + xfs_fsize_t i_new_size; /* size when write completes */ atomic_t i_iocount; /* outstanding I/O count */ /* Trace buffers per inode. */ #ifdef XFS_INODE_TRACE Index: linux-2.6-xfs/fs/xfs/xfs_iocore.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_iocore.c 2007-09-12 14:05:43.000000000 +0200 +++ /dev/null 1970-01-01 00:00:00.000000000 +0000 @@ -1,79 +0,0 @@ -/* - * Copyright (c) 2000-2003,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 - */ -#include "xfs.h" -#include "xfs_fs.h" -#include "xfs_types.h" -#include "xfs_bit.h" -#include "xfs_log.h" -#include "xfs_inum.h" -#include "xfs_trans.h" -#include "xfs_sb.h" -#include "xfs_ag.h" -#include "xfs_dir2.h" -#include "xfs_dfrag.h" -#include "xfs_dmapi.h" -#include "xfs_mount.h" -#include "xfs_bmap_btree.h" -#include "xfs_alloc_btree.h" -#include "xfs_ialloc_btree.h" -#include "xfs_dir2_sf.h" -#include "xfs_attr_sf.h" -#include "xfs_dinode.h" -#include "xfs_inode.h" -#include "xfs_inode_item.h" -#include "xfs_itable.h" -#include "xfs_btree.h" -#include "xfs_alloc.h" -#include "xfs_ialloc.h" -#include "xfs_bmap.h" -#include "xfs_error.h" -#include "xfs_rw.h" -#include "xfs_quota.h" -#include "xfs_trans_space.h" -#include "xfs_iomap.h" - -void -xfs_iocore_inode_reinit( - xfs_inode_t *ip) -{ - xfs_iocore_t *io = &ip->i_iocore; - - io->io_flags = 0; - if (ip->i_d.di_flags & XFS_DIFLAG_REALTIME) - io->io_flags |= XFS_IOCORE_RT; - io->io_dmevmask = ip->i_d.di_dmevmask; - io->io_dmstate = ip->i_d.di_dmstate; -} - -void -xfs_iocore_inode_init( - xfs_inode_t *ip) -{ - xfs_iocore_t *io = &ip->i_iocore; - xfs_mount_t *mp = ip->i_mount; - - io->io_mount = mp; -#ifdef DEBUG - io->io_lock = &ip->i_lock; - io->io_iolock = &ip->i_iolock; -#endif - - io->io_obj = (void *)ip; - - xfs_iocore_inode_reinit(ip); -} Index: linux-2.6-xfs/fs/xfs/xfs_iomap.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_iomap.c 2007-09-12 14:05:43.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_iomap.c 2007-09-12 14:05:49.000000000 +0200 @@ -57,8 +57,6 @@ xfs_iomap_enter_trace( xfs_off_t offset, ssize_t count) { - xfs_iocore_t *io = &ip->i_iocore; - if (!ip->i_rwtrace) return; @@ -70,8 +68,8 @@ xfs_iomap_enter_trace( (void *)((unsigned long)((offset >> 32) & 0xffffffff)), (void *)((unsigned long)(offset & 0xffffffff)), (void *)((unsigned long)count), - (void *)((unsigned long)((io->io_new_size >> 32) & 0xffffffff)), - (void *)((unsigned long)(io->io_new_size & 0xffffffff)), + (void *)((unsigned long)((ip->i_new_size >> 32) & 0xffffffff)), + (void *)((unsigned long)(ip->i_new_size & 0xffffffff)), (void *)((unsigned long)current_pid()), (void *)NULL, (void *)NULL, @@ -186,8 +184,6 @@ xfs_iomap( int iomap_flags = 0; ASSERT((ip->i_d.di_mode & S_IFMT) == S_IFREG); - ASSERT(((ip->i_d.di_flags & XFS_DIFLAG_REALTIME) != 0) == - ((ip->i_iocore.io_flags & XFS_IOCORE_RT) != 0)); if (XFS_FORCED_SHUTDOWN(mp)) return XFS_ERROR(EIO); @@ -402,7 +398,6 @@ xfs_iomap_write_direct( int found) { xfs_mount_t *mp = ip->i_mount; - xfs_iocore_t *io = &ip->i_iocore; xfs_fileoff_t offset_fsb; xfs_fileoff_t last_fsb; xfs_filblks_t count_fsb, resaligned; @@ -432,8 +427,8 @@ xfs_iomap_write_direct( extsz = xfs_get_extsz_hint(ip); isize = ip->i_size; - if (io->io_new_size > isize) - isize = io->io_new_size; + if (ip->i_new_size > isize) + isize = ip->i_new_size; offset_fsb = XFS_B_TO_FSBT(mp, offset); last_fsb = XFS_B_TO_FSB(mp, ((xfs_ufsize_t)(offset + count))); @@ -528,7 +523,8 @@ xfs_iomap_write_direct( goto error_out; } - if (unlikely(!imap.br_startblock && !(io->io_flags & XFS_IOCORE_RT))) { + if (unlikely(!imap.br_startblock && + !(ip->i_d.di_flags & XFS_DIFLAG_REALTIME))) { error = xfs_cmn_err_fsblock_zero(ip, &imap); goto error_out; } @@ -616,7 +612,6 @@ xfs_iomap_write_delay( int *nmaps) { xfs_mount_t *mp = ip->i_mount; - xfs_iocore_t *io = &ip->i_iocore; xfs_fileoff_t offset_fsb; xfs_fileoff_t last_fsb; xfs_off_t aligned_offset; @@ -644,8 +639,8 @@ xfs_iomap_write_delay( retry: isize = ip->i_size; - if (io->io_new_size > isize) - isize = io->io_new_size; + if (ip->i_new_size > isize) + isize = ip->i_new_size; error = xfs_iomap_eof_want_preallocate(mp, ip, isize, offset, count, ioflag, imap, XFS_WRITE_IMAPS, &prealloc); @@ -691,7 +686,8 @@ retry: goto retry; } - if (unlikely(!imap[0].br_startblock && !(io->io_flags & XFS_IOCORE_RT))) + if (unlikely(!imap[0].br_startblock && + !(ip->i_d.di_flags & XFS_DIFLAG_REALTIME))) return xfs_cmn_err_fsblock_zero(ip, &imap[0]); *ret_imap = imap[0]; @@ -716,7 +712,6 @@ xfs_iomap_write_allocate( int *retmap) { xfs_mount_t *mp = ip->i_mount; - xfs_iocore_t *io = &ip->i_iocore; xfs_fileoff_t offset_fsb, last_block; xfs_fileoff_t end_fsb, map_start_fsb; xfs_fsblock_t first_block; @@ -814,7 +809,7 @@ xfs_iomap_write_allocate( */ for (i = 0; i < nimaps; i++) { if (unlikely(!imap[i].br_startblock && - !(io->io_flags & XFS_IOCORE_RT))) + !(ip->i_d.di_flags & XFS_DIFLAG_REALTIME))) return xfs_cmn_err_fsblock_zero(ip, &imap[i]); if ((offset_fsb >= imap[i].br_startoff) && (offset_fsb < (imap[i].br_startoff + @@ -850,7 +845,6 @@ xfs_iomap_write_unwritten( size_t count) { xfs_mount_t *mp = ip->i_mount; - xfs_iocore_t *io = &ip->i_iocore; xfs_fileoff_t offset_fsb; xfs_filblks_t count_fsb; xfs_filblks_t numblks_fsb; @@ -913,7 +907,7 @@ xfs_iomap_write_unwritten( return XFS_ERROR(error); if (unlikely(!imap.br_startblock && - !(io->io_flags & XFS_IOCORE_RT))) + !(ip->i_d.di_flags & XFS_DIFLAG_REALTIME))) return xfs_cmn_err_fsblock_zero(ip, &imap); if ((numblks_fsb = imap.br_blockcount) == 0) { Index: linux-2.6-xfs/fs/xfs/xfs_mount.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_mount.h 2007-09-12 14:05:43.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_mount.h 2007-09-12 14:05:49.000000000 +0200 @@ -56,7 +56,6 @@ struct cred; struct log; struct xfs_mount_args; struct xfs_inode; -struct xfs_iocore; struct xfs_bmbt_irec; struct xfs_bmap_free; struct xfs_extdelta; Index: linux-2.6-xfs/fs/xfs/xfs_rw.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_rw.h 2007-09-06 13:24:47.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_rw.h 2007-09-12 14:05:49.000000000 +0200 @@ -36,14 +36,6 @@ xfs_fsb_to_db(struct xfs_inode *ip, xfs_ (xfs_daddr_t)XFS_FSB_TO_BB((ip)->i_mount, (fsb)) : \ XFS_FSB_TO_DADDR((ip)->i_mount, (fsb))); } -#define XFS_FSB_TO_DB_IO(io,fsb) xfs_fsb_to_db_io(io,fsb) -static inline xfs_daddr_t -xfs_fsb_to_db_io(struct xfs_iocore *io, xfs_fsblock_t fsb) -{ - return (((io)->io_flags & XFS_IOCORE_RT) ? \ - XFS_FSB_TO_BB((io)->io_mount, (fsb)) : \ - XFS_FSB_TO_DADDR((io)->io_mount, (fsb))); -} /* * Flags for xfs_free_eofblocks Index: linux-2.6-xfs/fs/xfs/xfs_vnodeops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.c 2007-09-12 14:05:43.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.c 2007-09-12 14:05:49.000000000 +0200 @@ -804,12 +804,8 @@ xfs_setattr( if (vap->va_xflags & XFS_XFLAG_EXTSZINHERIT) di_flags |= XFS_DIFLAG_EXTSZINHERIT; } else if ((ip->i_d.di_mode & S_IFMT) == S_IFREG) { - if (vap->va_xflags & XFS_XFLAG_REALTIME) { + if (vap->va_xflags & XFS_XFLAG_REALTIME) di_flags |= XFS_DIFLAG_REALTIME; - ip->i_iocore.io_flags |= XFS_IOCORE_RT; - } else { - ip->i_iocore.io_flags &= ~XFS_IOCORE_RT; - } if (vap->va_xflags & XFS_XFLAG_EXTSIZE) di_flags |= XFS_DIFLAG_EXTSIZE; } @@ -3640,8 +3636,8 @@ xfs_set_dmattrs( xfs_ilock(ip, XFS_ILOCK_EXCL); xfs_trans_ijoin(tp, ip, XFS_ILOCK_EXCL); - ip->i_iocore.io_dmevmask = ip->i_d.di_dmevmask = evmask; - ip->i_iocore.io_dmstate = ip->i_d.di_dmstate = state; + ip->i_d.di_dmevmask = evmask; + ip->i_d.di_dmstate = state; xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); IHOLD(ip); @@ -4179,7 +4175,7 @@ xfs_free_file_space( ioffset = offset & ~(rounding - 1); if (VN_CACHED(vp) != 0) { - xfs_inval_cached_trace(&ip->i_iocore, ioffset, -1, + xfs_inval_cached_trace(ip, ioffset, -1, ctooff(offtoct(ioffset)), -1); error = xfs_flushinval_pages(ip, ctooff(offtoct(ioffset)), Index: linux-2.6-xfs/fs/xfs/xfsidbg.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfsidbg.c 2007-09-12 13:56:18.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfsidbg.c 2007-09-12 14:05:49.000000000 +0200 @@ -164,7 +164,6 @@ static void xfsidbg_xlog_tic(xlog_ticket static void xfsidbg_xlogitem(xfs_log_item_t *); static void xfsidbg_xmount(xfs_mount_t *); static void xfsidbg_xnode(xfs_inode_t *ip); -static void xfsidbg_xcore(xfs_iocore_t *io); static void xfsidbg_xperag(xfs_mount_t *); static void xfsidbg_xqm_diskdq(xfs_disk_dquot_t *); static void xfsidbg_xqm_dqattached_inos(xfs_mount_t *); @@ -1472,25 +1471,6 @@ static int kdbm_xfs_xnode( return 0; } -static int kdbm_xfs_xcore( - int argc, - const char **argv) -{ - unsigned long addr; - int nextarg = 1; - long offset = 0; - int diag; - - if (argc != 1) - return KDB_ARGCOUNT; - diag = kdbgetaddrarg(argc, argv, &nextarg, &addr, &offset, NULL); - if (diag) - return diag; - - xfsidbg_xcore((xfs_iocore_t *) addr); - return 0; -} - static int kdbm_xfs_xperag( int argc, const char **argv) @@ -2552,8 +2532,6 @@ static struct xif xfsidbg_funcs[] = { "Dump XFS mount structure"}, { "xnode", kdbm_xfs_xnode, "", "Dump XFS inode"}, - { "xiocore", kdbm_xfs_xcore, "", - "Dump XFS iocore"}, { "xperag", kdbm_xfs_xperag, "", "Dump XFS per-allocation group data"}, { "xqinfo", kdbm_xfs_xqm_qinfo, "", @@ -6588,7 +6566,7 @@ xfsidbg_xnode(xfs_inode_t *ip) xfs_ipincount(ip)); kdb_printf("udquotp 0x%p gdquotp 0x%p\n", ip->i_udquot, ip->i_gdquot); - kdb_printf("new_size %Ld\n", ip->i_iocore.io_new_size); + kdb_printf("new_size %Ld\n", ip->i_new_size); printflags((int)ip->i_flags, tab_flags, "flags"); kdb_printf("\n"); kdb_printf("update_core %d update size %d\n", @@ -6628,14 +6606,6 @@ xfsidbg_xnode(xfs_inode_t *ip) xfs_prdinode_incore(&ip->i_d); } -static void -xfsidbg_xcore(xfs_iocore_t *io) -{ - kdb_printf("io_obj 0x%p io_flags 0x%x io_mount 0x%p\n", - io->io_obj, io->io_flags, io->io_mount); - kdb_printf("new_size %Lx\n", io->io_new_size); -} - /* * Print xfs per-ag data structures for filesystem. */ From owner-xfs@oss.sgi.com Fri Sep 14 09:27:47 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Sep 2007 09:27: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.7 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 l8EGRk4p028450 for ; Fri, 14 Sep 2007 09:27:47 -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 l8EGRlA5007349 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 14 Sep 2007 18:27:47 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8EGRlMG007347 for xfs@oss.sgi.com; Fri, 14 Sep 2007 18:27:47 +0200 Date: Fri, 14 Sep 2007 18:27:47 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: [PATCH 1/4] simplify validata_fields Message-ID: <20070914162746.GB7110@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: 12897 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 Stop using xfs_getattr and a onstack bhv_vattr_t just to get three fields from the underlying inode and opencode copying from the inode fields instead. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_iops.c 2007-09-06 10:13:41.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c 2007-09-06 10:18:06.000000000 +0200 @@ -179,18 +179,19 @@ xfs_ichgtime_fast( */ STATIC void xfs_validate_fields( - struct inode *ip, - bhv_vattr_t *vattr) + struct inode *inode) { - vattr->va_mask = XFS_AT_NLINK|XFS_AT_SIZE|XFS_AT_NBLOCKS; - if (!xfs_getattr(XFS_I(ip), vattr, ATTR_LAZY)) { - ip->i_nlink = vattr->va_nlink; - ip->i_blocks = vattr->va_nblocks; - - /* we're under i_sem so i_size can't change under us */ - if (i_size_read(ip) != vattr->va_size) - i_size_write(ip, vattr->va_size); - } + struct xfs_inode *ip = XFS_I(inode); + loff_t size; + + inode->i_nlink = ip->i_d.di_nlink; + inode->i_blocks = + XFS_FSB_TO_BB(ip->i_mount, ip->i_d.di_nblocks + + ip->i_delayed_blks); + /* we're under i_sem so i_size can't change under us */ + size = XFS_ISIZE(ip); + if (i_size_read(inode) != size) + i_size_write(inode, size); } /* @@ -340,9 +341,9 @@ xfs_vn_mknod( if (S_ISCHR(mode) || S_ISBLK(mode)) ip->i_rdev = rdev; else if (S_ISDIR(mode)) - xfs_validate_fields(ip, &vattr); + xfs_validate_fields(ip); d_instantiate(dentry, ip); - xfs_validate_fields(dir, &vattr); + xfs_validate_fields(dir); } return -error; } @@ -397,7 +398,6 @@ xfs_vn_link( { struct inode *ip; /* inode of guy being linked to */ bhv_vnode_t *vp; /* vp of name being linked */ - bhv_vattr_t vattr; int error; ip = old_dentry->d_inode; /* inode being linked to */ @@ -409,7 +409,7 @@ xfs_vn_link( VN_RELE(vp); } else { xfs_iflags_set(XFS_I(dir), XFS_IMODIFIED); - xfs_validate_fields(ip, &vattr); + xfs_validate_fields(ip); d_instantiate(dentry, ip); } return -error; @@ -421,15 +421,14 @@ xfs_vn_unlink( struct dentry *dentry) { struct inode *inode; - bhv_vattr_t vattr; int error; inode = dentry->d_inode; error = xfs_remove(XFS_I(dir), dentry); if (likely(!error)) { - xfs_validate_fields(dir, &vattr); /* size needs update */ - xfs_validate_fields(inode, &vattr); + xfs_validate_fields(dir); /* size needs update */ + xfs_validate_fields(inode); } return -error; } @@ -458,8 +457,8 @@ xfs_vn_symlink( if (likely(!error)) { ip = vn_to_inode(cvp); d_instantiate(dentry, ip); - xfs_validate_fields(dir, &va); - xfs_validate_fields(ip, &va); + xfs_validate_fields(dir); + xfs_validate_fields(ip); } else { xfs_cleanup_inode(dir, cvp, dentry, 0); } @@ -473,13 +472,12 @@ xfs_vn_rmdir( struct dentry *dentry) { struct inode *inode = dentry->d_inode; - bhv_vattr_t vattr; int error; error = xfs_rmdir(XFS_I(dir), dentry); if (likely(!error)) { - xfs_validate_fields(inode, &vattr); - xfs_validate_fields(dir, &vattr); + xfs_validate_fields(inode); + xfs_validate_fields(dir); } return -error; } @@ -493,7 +491,6 @@ xfs_vn_rename( { struct inode *new_inode = ndentry->d_inode; bhv_vnode_t *tvp; /* target directory */ - bhv_vattr_t vattr; int error; tvp = vn_from_inode(ndir); @@ -501,10 +498,10 @@ xfs_vn_rename( error = xfs_rename(XFS_I(odir), odentry, tvp, ndentry); if (likely(!error)) { if (new_inode) - xfs_validate_fields(new_inode, &vattr); - xfs_validate_fields(odir, &vattr); + xfs_validate_fields(new_inode); + xfs_validate_fields(odir); if (ndir != odir) - xfs_validate_fields(ndir, &vattr); + xfs_validate_fields(ndir); } return -error; } From owner-xfs@oss.sgi.com Fri Sep 14 09:27:40 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Sep 2007 09:27:44 -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 l8EGRc4p028430 for ; Fri, 14 Sep 2007 09:27:39 -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 l8EGRcA5007302 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 14 Sep 2007 18:27:38 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8EGRcAo007300 for xfs@oss.sgi.com; Fri, 14 Sep 2007 18:27:38 +0200 Date: Fri, 14 Sep 2007 18:27:38 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: [PATCH 4/4] avoid xfs_getattr in XFS_IOC_FSGETXATTR ioctl Message-ID: <20070914162738.GA7110@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: 12896 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 No need to call into xfs_getattr and put a big bhv_vattr_t on the stack just to get a little information from the XFS inode. Add a helper called xfs_ioc_fsgetxattr instead that deals with retriving the information in a clean way. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ioctl.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ioctl.c 2007-08-19 16:33:06.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ioctl.c 2007-08-19 16:51:16.000000000 +0200 @@ -709,6 +709,12 @@ xfs_ioc_xattr( void __user *arg); STATIC int +xfs_ioc_fsgetxattr( + xfs_inode_t *ip, + int attr, + void __user *arg); + +STATIC int xfs_ioc_getbmap( struct xfs_inode *ip, int flags, @@ -783,11 +789,13 @@ xfs_ioctl( case XFS_IOC_GETVERSION: return put_user(inode->i_generation, (int __user *)arg); + case XFS_IOC_FSGETXATTR: + return xfs_ioc_fsgetxattr(ip, 0, arg); + case XFS_IOC_FSGETXATTRA: + return xfs_ioc_fsgetxattr(ip, 1, arg); case XFS_IOC_GETXFLAGS: case XFS_IOC_SETXFLAGS: - case XFS_IOC_FSGETXATTR: case XFS_IOC_FSSETXATTR: - case XFS_IOC_FSGETXATTRA: return xfs_ioc_xattr(vp, ip, filp, cmd, arg); case XFS_IOC_FSSETDM: { @@ -1162,6 +1170,42 @@ xfs_di2lxflags( } STATIC int +xfs_ioc_fsgetxattr( + xfs_inode_t *ip, + int attr, + void __user *arg) +{ + struct fsxattr fa; + + xfs_ilock(ip, XFS_ILOCK_SHARED); + fa.fsx_xflags = xfs_ip2xflags(ip); + fa.fsx_extsize = ip->i_d.di_extsize << ip->i_mount->m_sb.sb_blocklog; + fa.fsx_projid = ip->i_d.di_projid; + + if (attr) { + if (ip->i_afp) { + if (ip->i_afp->if_flags & XFS_IFEXTENTS) + fa.fsx_nextents = ip->i_afp->if_bytes / + sizeof(xfs_bmbt_rec_t); + else + fa.fsx_nextents = ip->i_d.di_anextents; + } else + fa.fsx_nextents = 0; + } else { + if (ip->i_df.if_flags & XFS_IFEXTENTS) + fa.fsx_nextents = ip->i_df.if_bytes / + sizeof(xfs_bmbt_rec_t); + else + fa.fsx_nextents = ip->i_d.di_nextents; + } + xfs_iunlock(ip, XFS_ILOCK_SHARED); + + if (copy_to_user(arg, &fa, sizeof(fa))) + return -EFAULT; + return 0; +} + +STATIC int xfs_ioc_xattr( bhv_vnode_t *vp, xfs_inode_t *ip, @@ -1180,27 +1224,6 @@ xfs_ioc_xattr( return -ENOMEM; switch (cmd) { - case XFS_IOC_FSGETXATTR: { - vattr->va_mask = XFS_AT_XFLAGS | XFS_AT_EXTSIZE | \ - XFS_AT_NEXTENTS | XFS_AT_PROJID; - error = xfs_getattr(ip, vattr, 0); - if (unlikely(error)) { - error = -error; - break; - } - - fa.fsx_xflags = vattr->va_xflags; - fa.fsx_extsize = vattr->va_extsize; - fa.fsx_nextents = vattr->va_nextents; - fa.fsx_projid = vattr->va_projid; - - if (copy_to_user(arg, &fa, sizeof(fa))) { - error = -EFAULT; - break; - } - break; - } - case XFS_IOC_FSSETXATTR: { if (copy_from_user(&fa, arg, sizeof(fa))) { error = -EFAULT; @@ -1223,27 +1246,6 @@ xfs_ioc_xattr( break; } - case XFS_IOC_FSGETXATTRA: { - vattr->va_mask = XFS_AT_XFLAGS | XFS_AT_EXTSIZE | \ - XFS_AT_ANEXTENTS | XFS_AT_PROJID; - error = xfs_getattr(ip, vattr, 0); - if (unlikely(error)) { - error = -error; - break; - } - - fa.fsx_xflags = vattr->va_xflags; - fa.fsx_extsize = vattr->va_extsize; - fa.fsx_nextents = vattr->va_anextents; - fa.fsx_projid = vattr->va_projid; - - if (copy_to_user(arg, &fa, sizeof(fa))) { - error = -EFAULT; - break; - } - break; - } - case XFS_IOC_GETXFLAGS: { flags = xfs_di2lxflags(ip->i_d.di_flags); if (copy_to_user(arg, &flags, sizeof(flags))) From owner-xfs@oss.sgi.com Fri Sep 14 09:28:00 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Sep 2007 09:28:03 -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 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 l8EGRu4p028505 for ; Fri, 14 Sep 2007 09:27:59 -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 l8EGRvA5007381 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 14 Sep 2007 18:27:57 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8EGRvG2007379 for xfs@oss.sgi.com; Fri, 14 Sep 2007 18:27:57 +0200 Date: Fri, 14 Sep 2007 18:27:57 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: [PATCH 3/4] simplify xfs_vn_getattr Message-ID: <20070914162757.GD7110@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: 12899 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 Just fill in struct kstat directly from the xfs_inode instead of doing a detour through a bhv_vattr_t and xfs_getattr. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_iops.c 2007-09-06 10:42:40.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c 2007-09-06 10:44:33.000000000 +0200 @@ -564,33 +564,61 @@ xfs_vn_permission( STATIC int xfs_vn_getattr( - struct vfsmount *mnt, - struct dentry *dentry, - struct kstat *stat) + struct vfsmount *mnt, + struct dentry *dentry, + struct kstat *stat) { - struct inode *inode = dentry->d_inode; - bhv_vattr_t vattr = { .va_mask = XFS_AT_STAT }; - int error; - - error = xfs_getattr(XFS_I(inode), &vattr, ATTR_LAZY); - if (likely(!error)) { - stat->size = i_size_read(inode); - stat->dev = inode->i_sb->s_dev; - stat->rdev = (vattr.va_rdev == 0) ? 0 : - MKDEV(sysv_major(vattr.va_rdev) & 0x1ff, - sysv_minor(vattr.va_rdev)); - stat->mode = vattr.va_mode; - stat->nlink = vattr.va_nlink; - stat->uid = vattr.va_uid; - stat->gid = vattr.va_gid; - stat->ino = vattr.va_nodeid; - stat->atime = vattr.va_atime; - stat->mtime = vattr.va_mtime; - stat->ctime = vattr.va_ctime; - stat->blocks = vattr.va_nblocks; - stat->blksize = vattr.va_blocksize; + struct inode *inode = dentry->d_inode; + struct xfs_inode *ip = XFS_I(inode); + struct xfs_mount *mp = ip->i_mount; + + xfs_itrace_entry(ip); + + if (XFS_FORCED_SHUTDOWN(mp)) + return XFS_ERROR(EIO); + + stat->size = XFS_ISIZE(ip); + stat->dev = inode->i_sb->s_dev; + stat->mode = ip->i_d.di_mode; + stat->nlink = ip->i_d.di_nlink; + stat->uid = ip->i_d.di_uid; + stat->gid = ip->i_d.di_gid; + stat->ino = ip->i_ino; +#if XFS_BIG_INUMS + stat->ino += mp->m_inoadd; +#endif + stat->atime = inode->i_atime; + stat->mtime.tv_sec = ip->i_d.di_mtime.t_sec; + stat->mtime.tv_nsec = ip->i_d.di_mtime.t_nsec; + stat->ctime.tv_sec = ip->i_d.di_ctime.t_sec; + stat->ctime.tv_nsec = ip->i_d.di_ctime.t_nsec; + stat->blocks = + XFS_FSB_TO_BB(mp, ip->i_d.di_nblocks + ip->i_delayed_blks); + + + switch (inode->i_mode & S_IFMT) { + case S_IFBLK: + case S_IFCHR: + stat->blksize = BLKDEV_IOSIZE; + stat->rdev = MKDEV(sysv_major(ip->i_df.if_u2.if_rdev) & 0x1ff, + sysv_minor(ip->i_df.if_u2.if_rdev)); + break; + default: + if (ip->i_d.di_flags & XFS_DIFLAG_REALTIME) { + /* + * If the file blocks are being allocated from a + * realtime volume, then return the inode's realtime + * extent size or the realtime volume's extent size. + */ + stat->blksize = + xfs_get_extsz_hint(ip) << mp->m_sb.sb_blocklog; + } else + stat->blksize = xfs_preferred_iosize(mp); + stat->rdev = 0; + break; } - return -error; + + return 0; } STATIC int From owner-xfs@oss.sgi.com Fri Sep 14 09:28:05 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Sep 2007 09:28: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,J_CHICKENPOX_52, J_CHICKENPOX_65 autolearn=no 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 l8EGS34p028553 for ; Fri, 14 Sep 2007 09:28:04 -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 l8EGS2A5007400 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 14 Sep 2007 18:28:02 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8EGS2BR007398 for xfs@oss.sgi.com; Fri, 14 Sep 2007 18:28:02 +0200 Date: Fri, 14 Sep 2007 18:28:02 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: [PATCH 1/2] kill unnessecary ioops indirection Message-ID: <20070914162802.GE7110@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: 12900 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 Currently there is an indirection called ioops in the XFS data I/O path. Various functions are called by functions pointers, but there is no coherence in what this is for, and of course for XFS itself it's entirely unused. This patch removes it instead and significantly reduces source and binary size of XFS while making maintaince easier. For users that use xfs_iomap.c for their own filesystem I suggest to just copy all of it - the only part that's sharable due to the ioops (xfs_iomap and xfs_imap_to_bmap) will go away mid-term anyway. For the other hooks I don't have a suggestion as their use is not clear to me. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_lrw.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_lrw.c 2007-09-12 14:17:09.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_lrw.c 2007-09-14 14:30:16.000000000 +0200 @@ -400,20 +400,20 @@ xfs_splice_write( */ STATIC int /* error (positive) */ xfs_zero_last_block( - struct inode *ip, - xfs_iocore_t *io, + struct inode *inode, + xfs_inode_t *ip, xfs_fsize_t offset, xfs_fsize_t isize) { xfs_fileoff_t last_fsb; - xfs_mount_t *mp = io->io_mount; + xfs_mount_t *mp = ip->i_mount; int nimaps; int zero_offset; int zero_len; int error = 0; xfs_bmbt_irec_t imap; - ASSERT(ismrlocked(io->io_lock, MR_UPDATE) != 0); + ASSERT(ismrlocked(&ip->i_lock, MR_UPDATE) != 0); zero_offset = XFS_B_FSB_OFFSET(mp, isize); if (zero_offset == 0) { @@ -426,7 +426,7 @@ xfs_zero_last_block( last_fsb = XFS_B_TO_FSBT(mp, isize); nimaps = 1; - error = XFS_BMAPI(mp, NULL, io, last_fsb, 1, 0, NULL, 0, &imap, + error = xfs_bmapi(NULL, ip, last_fsb, 1, 0, NULL, 0, &imap, &nimaps, NULL, NULL); if (error) { return error; @@ -444,14 +444,14 @@ xfs_zero_last_block( * out sync. We need to drop the ilock while we do this so we * don't deadlock when the buffer cache calls back to us. */ - XFS_IUNLOCK(mp, io, XFS_ILOCK_EXCL| XFS_EXTSIZE_RD); + xfs_iunlock(ip, XFS_ILOCK_EXCL| XFS_EXTSIZE_RD); zero_len = mp->m_sb.sb_blocksize - zero_offset; if (isize + zero_len > offset) zero_len = offset - isize; - error = xfs_iozero(ip, isize, zero_len); + error = xfs_iozero(inode, isize, zero_len); - XFS_ILOCK(mp, io, XFS_ILOCK_EXCL|XFS_EXTSIZE_RD); + xfs_ilock(ip, XFS_ILOCK_EXCL|XFS_EXTSIZE_RD); ASSERT(error >= 0); return error; } @@ -474,7 +474,8 @@ xfs_zero_eof( xfs_off_t offset, /* starting I/O offset */ xfs_fsize_t isize) /* current inode size */ { - struct inode *ip = vn_to_inode(vp); + struct inode *inode = vn_to_inode(vp); + xfs_inode_t *ip = XFS_I(inode); xfs_fileoff_t start_zero_fsb; xfs_fileoff_t end_zero_fsb; xfs_fileoff_t zero_count_fsb; @@ -494,7 +495,7 @@ xfs_zero_eof( * First handle zeroing the block on which isize resides. * We only zero a part of that block so it is handled specially. */ - error = xfs_zero_last_block(ip, io, offset, isize); + error = xfs_zero_last_block(inode, ip, offset, isize); if (error) { ASSERT(ismrlocked(io->io_lock, MR_UPDATE)); ASSERT(ismrlocked(io->io_iolock, MR_UPDATE)); @@ -525,7 +526,7 @@ xfs_zero_eof( while (start_zero_fsb <= end_zero_fsb) { nimaps = 1; zero_count_fsb = end_zero_fsb - start_zero_fsb + 1; - error = XFS_BMAPI(mp, NULL, io, start_zero_fsb, zero_count_fsb, + error = xfs_bmapi(NULL, ip, start_zero_fsb, zero_count_fsb, 0, NULL, 0, &imap, &nimaps, NULL, NULL); if (error) { ASSERT(ismrlocked(io->io_lock, MR_UPDATE)); @@ -553,7 +554,7 @@ xfs_zero_eof( * Drop the inode lock while we're doing the I/O. * We'll still have the iolock to protect us. */ - XFS_IUNLOCK(mp, io, XFS_ILOCK_EXCL|XFS_EXTSIZE_RD); + xfs_iunlock(ip, XFS_ILOCK_EXCL|XFS_EXTSIZE_RD); zero_off = XFS_FSB_TO_B(mp, start_zero_fsb); zero_len = XFS_FSB_TO_B(mp, imap.br_blockcount); @@ -561,7 +562,7 @@ xfs_zero_eof( if ((zero_off + zero_len) > offset) zero_len = offset - zero_off; - error = xfs_iozero(ip, zero_off, zero_len); + error = xfs_iozero(inode, zero_off, zero_len); if (error) { goto out_lock; } @@ -569,14 +570,13 @@ xfs_zero_eof( start_zero_fsb = imap.br_startoff + imap.br_blockcount; ASSERT(start_zero_fsb <= (end_zero_fsb + 1)); - XFS_ILOCK(mp, io, XFS_ILOCK_EXCL|XFS_EXTSIZE_RD); + xfs_ilock(ip, XFS_ILOCK_EXCL|XFS_EXTSIZE_RD); } return 0; out_lock: - - XFS_ILOCK(mp, io, XFS_ILOCK_EXCL|XFS_EXTSIZE_RD); + xfs_ilock(ip, XFS_ILOCK_EXCL|XFS_EXTSIZE_RD); ASSERT(error >= 0); return error; } @@ -762,7 +762,7 @@ retry: if (need_i_mutex) { /* demote the lock now the cached pages are gone */ - XFS_ILOCK_DEMOTE(mp, io, XFS_IOLOCK_EXCL); + xfs_ilock_demote(xip, XFS_IOLOCK_EXCL); mutex_unlock(&inode->i_mutex); iolock = XFS_IOLOCK_SHARED; @@ -905,25 +905,6 @@ xfs_bdstrat_cb(struct xfs_buf *bp) } } - -int -xfs_bmap( - xfs_inode_t *ip, - xfs_off_t offset, - ssize_t count, - int flags, - xfs_iomap_t *iomapp, - int *niomaps) -{ - xfs_iocore_t *io = &ip->i_iocore; - - ASSERT((ip->i_d.di_mode & S_IFMT) == S_IFREG); - ASSERT(((ip->i_d.di_flags & XFS_DIFLAG_REALTIME) != 0) == - ((ip->i_iocore.io_flags & XFS_IOCORE_RT) != 0)); - - return xfs_iomap(io, offset, count, flags, iomapp, niomaps); -} - /* * Wrapper around bdstrat so that we can stop data * from going to disk in case we are shutting down the filesystem. Index: linux-2.6-xfs/fs/xfs/xfs_iomap.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_iomap.c 2007-09-13 12:33:56.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_iomap.c 2007-09-14 14:30:16.000000000 +0200 @@ -53,11 +53,11 @@ void xfs_iomap_enter_trace( int tag, - xfs_iocore_t *io, + xfs_inode_t *ip, xfs_off_t offset, ssize_t count) { - xfs_inode_t *ip = XFS_IO_INODE(io); + xfs_iocore_t *io = &ip->i_iocore; if (!ip->i_rwtrace) return; @@ -84,15 +84,13 @@ xfs_iomap_enter_trace( void xfs_iomap_map_trace( int tag, - xfs_iocore_t *io, + xfs_inode_t *ip, xfs_off_t offset, ssize_t count, xfs_iomap_t *iomapp, xfs_bmbt_irec_t *imapp, int flags) { - xfs_inode_t *ip = XFS_IO_INODE(io); - if (!ip->i_rwtrace) return; @@ -126,7 +124,7 @@ xfs_iomap_map_trace( STATIC int xfs_imap_to_bmap( - xfs_iocore_t *io, + xfs_inode_t *ip, xfs_off_t offset, xfs_bmbt_irec_t *imap, xfs_iomap_t *iomapp, @@ -134,11 +132,10 @@ xfs_imap_to_bmap( int iomaps, /* Number of iomap entries */ int flags) { - xfs_mount_t *mp; + xfs_mount_t *mp = ip->i_mount; int pbm; xfs_fsblock_t start_block; - mp = io->io_mount; for (pbm = 0; imaps && pbm < iomaps; imaps--, iomapp++, imap++, pbm++) { iomapp->iomap_offset = XFS_FSB_TO_B(mp, imap->br_startoff); @@ -146,7 +143,7 @@ xfs_imap_to_bmap( iomapp->iomap_bsize = XFS_FSB_TO_B(mp, imap->br_blockcount); iomapp->iomap_flags = flags; - if (io->io_flags & XFS_IOCORE_RT) { + if (ip->i_d.di_flags & XFS_DIFLAG_REALTIME) { iomapp->iomap_flags |= IOMAP_REALTIME; iomapp->iomap_target = mp->m_rtdev_targp; } else { @@ -160,7 +157,7 @@ xfs_imap_to_bmap( iomapp->iomap_bn = IOMAP_DADDR_NULL; iomapp->iomap_flags |= IOMAP_DELAY; } else { - iomapp->iomap_bn = XFS_FSB_TO_DB_IO(io, start_block); + iomapp->iomap_bn = XFS_FSB_TO_DB(ip, start_block); if (ISUNWRITTEN(imap)) iomapp->iomap_flags |= IOMAP_UNWRITTEN; } @@ -172,14 +169,14 @@ xfs_imap_to_bmap( int xfs_iomap( - xfs_iocore_t *io, + xfs_inode_t *ip, xfs_off_t offset, ssize_t count, int flags, xfs_iomap_t *iomapp, int *niomaps) { - xfs_mount_t *mp = io->io_mount; + xfs_mount_t *mp = ip->i_mount; xfs_fileoff_t offset_fsb, end_fsb; int error = 0; int lockmode = 0; @@ -188,32 +185,37 @@ xfs_iomap( int bmapi_flags = 0; int iomap_flags = 0; + ASSERT((ip->i_d.di_mode & S_IFMT) == S_IFREG); + ASSERT(((ip->i_d.di_flags & XFS_DIFLAG_REALTIME) != 0) == + ((ip->i_iocore.io_flags & XFS_IOCORE_RT) != 0)); + if (XFS_FORCED_SHUTDOWN(mp)) return XFS_ERROR(EIO); 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); + xfs_iomap_enter_trace(XFS_IOMAP_READ_ENTER, ip, offset, count); + lockmode = xfs_ilock_map_shared(ip); bmapi_flags = XFS_BMAPI_ENTIRE; break; case BMAPI_WRITE: - xfs_iomap_enter_trace(XFS_IOMAP_WRITE_ENTER, io, offset, count); + xfs_iomap_enter_trace(XFS_IOMAP_WRITE_ENTER, ip, offset, count); lockmode = XFS_ILOCK_EXCL|XFS_EXTSIZE_WR; if (flags & BMAPI_IGNSTATE) bmapi_flags |= XFS_BMAPI_IGSTATE|XFS_BMAPI_ENTIRE; - XFS_ILOCK(mp, io, lockmode); + xfs_ilock(ip, lockmode); break; case BMAPI_ALLOCATE: - xfs_iomap_enter_trace(XFS_IOMAP_ALLOC_ENTER, io, offset, count); + xfs_iomap_enter_trace(XFS_IOMAP_ALLOC_ENTER, ip, offset, count); lockmode = XFS_ILOCK_SHARED|XFS_EXTSIZE_RD; bmapi_flags = XFS_BMAPI_ENTIRE; + /* Attempt non-blocking lock */ if (flags & BMAPI_TRYLOCK) { - if (!XFS_ILOCK_NOWAIT(mp, io, lockmode)) + if (!xfs_ilock_nowait(ip, lockmode)) return XFS_ERROR(EAGAIN); } else { - XFS_ILOCK(mp, io, lockmode); + xfs_ilock(ip, lockmode); } break; default: @@ -226,7 +228,7 @@ xfs_iomap( end_fsb = XFS_B_TO_FSB(mp, (xfs_ufsize_t)offset + count); offset_fsb = XFS_B_TO_FSBT(mp, offset); - error = XFS_BMAPI(mp, NULL, io, offset_fsb, + error = xfs_bmapi(NULL, ip, offset_fsb, (xfs_filblks_t)(end_fsb - offset_fsb), bmapi_flags, NULL, 0, &imap, &nimaps, NULL, NULL); @@ -240,42 +242,42 @@ xfs_iomap( if (nimaps && (imap.br_startblock != HOLESTARTBLOCK) && (imap.br_startblock != DELAYSTARTBLOCK)) { - xfs_iomap_map_trace(XFS_IOMAP_WRITE_MAP, io, + xfs_iomap_map_trace(XFS_IOMAP_WRITE_MAP, ip, offset, count, iomapp, &imap, flags); break; } if (flags & (BMAPI_DIRECT|BMAPI_MMAP)) { - error = XFS_IOMAP_WRITE_DIRECT(mp, io, offset, - count, flags, &imap, &nimaps, nimaps); + error = xfs_iomap_write_direct(ip, offset, count, flags, + &imap, &nimaps, nimaps); } else { - error = XFS_IOMAP_WRITE_DELAY(mp, io, offset, count, - flags, &imap, &nimaps); + error = xfs_iomap_write_delay(ip, offset, count, flags, + &imap, &nimaps); } if (!error) { - xfs_iomap_map_trace(XFS_IOMAP_ALLOC_MAP, io, + xfs_iomap_map_trace(XFS_IOMAP_ALLOC_MAP, ip, offset, count, iomapp, &imap, flags); } iomap_flags = IOMAP_NEW; break; case BMAPI_ALLOCATE: /* If we found an extent, return it */ - XFS_IUNLOCK(mp, io, lockmode); + xfs_iunlock(ip, lockmode); lockmode = 0; if (nimaps && !ISNULLSTARTBLOCK(imap.br_startblock)) { - xfs_iomap_map_trace(XFS_IOMAP_WRITE_MAP, io, + xfs_iomap_map_trace(XFS_IOMAP_WRITE_MAP, ip, offset, count, iomapp, &imap, flags); break; } - error = XFS_IOMAP_WRITE_ALLOCATE(mp, io, offset, count, + error = xfs_iomap_write_allocate(ip, offset, count, &imap, &nimaps); break; } if (nimaps) { - *niomaps = xfs_imap_to_bmap(io, offset, &imap, + *niomaps = xfs_imap_to_bmap(ip, offset, &imap, iomapp, nimaps, *niomaps, iomap_flags); } else if (niomaps) { *niomaps = 0; @@ -283,14 +285,15 @@ xfs_iomap( out: if (lockmode) - XFS_IUNLOCK(mp, io, lockmode); + xfs_iunlock(ip, lockmode); return XFS_ERROR(error); } + STATIC int xfs_iomap_eof_align_last_fsb( xfs_mount_t *mp, - xfs_iocore_t *io, + xfs_inode_t *ip, xfs_fsize_t isize, xfs_extlen_t extsize, xfs_fileoff_t *last_fsb) @@ -299,7 +302,7 @@ xfs_iomap_eof_align_last_fsb( xfs_extlen_t align; int eof, error; - if (io->io_flags & XFS_IOCORE_RT) + if (ip->i_d.di_flags & XFS_DIFLAG_REALTIME) ; /* * If mounted with the "-o swalloc" option, roundup the allocation @@ -330,7 +333,7 @@ xfs_iomap_eof_align_last_fsb( } if (new_last_fsb) { - error = XFS_BMAP_EOF(mp, io, new_last_fsb, XFS_DATA_FORK, &eof); + error = xfs_bmap_eof(ip, new_last_fsb, XFS_DATA_FORK, &eof); if (error) return error; if (eof) @@ -435,7 +438,7 @@ xfs_iomap_write_direct( offset_fsb = XFS_B_TO_FSBT(mp, offset); last_fsb = XFS_B_TO_FSB(mp, ((xfs_ufsize_t)(offset + count))); if ((offset + count) > isize) { - error = xfs_iomap_eof_align_last_fsb(mp, io, isize, extsz, + error = xfs_iomap_eof_align_last_fsb(mp, ip, isize, extsz, &last_fsb); if (error) goto error_out; @@ -502,7 +505,7 @@ xfs_iomap_write_direct( */ XFS_BMAP_INIT(&free_list, &firstfsb); nimaps = 1; - error = XFS_BMAPI(mp, tp, io, offset_fsb, count_fsb, bmapi_flag, + error = xfs_bmapi(tp, ip, offset_fsb, count_fsb, bmapi_flag, &firstfsb, 0, &imap, &nimaps, &free_list, NULL); if (error) goto error0; @@ -560,7 +563,7 @@ error_out: STATIC int xfs_iomap_eof_want_preallocate( xfs_mount_t *mp, - xfs_iocore_t *io, + xfs_inode_t *ip, xfs_fsize_t isize, xfs_off_t offset, size_t count, @@ -587,7 +590,7 @@ xfs_iomap_eof_want_preallocate( while (count_fsb > 0) { imaps = nimaps; firstblock = NULLFSBLOCK; - error = XFS_BMAPI(mp, NULL, io, start_fsb, count_fsb, 0, + error = xfs_bmapi(NULL, ip, start_fsb, count_fsb, 0, &firstblock, 0, imap, &imaps, NULL, NULL); if (error) return error; @@ -644,7 +647,7 @@ retry: if (io->io_new_size > isize) isize = io->io_new_size; - error = xfs_iomap_eof_want_preallocate(mp, io, isize, offset, count, + error = xfs_iomap_eof_want_preallocate(mp, ip, isize, offset, count, ioflag, imap, XFS_WRITE_IMAPS, &prealloc); if (error) return error; @@ -658,7 +661,7 @@ retry: } if (prealloc || extsz) { - error = xfs_iomap_eof_align_last_fsb(mp, io, isize, extsz, + error = xfs_iomap_eof_align_last_fsb(mp, ip, isize, extsz, &last_fsb); if (error) return error; @@ -666,7 +669,7 @@ retry: nimaps = XFS_WRITE_IMAPS; firstblock = NULLFSBLOCK; - error = XFS_BMAPI(mp, NULL, io, offset_fsb, + error = xfs_bmapi(NULL, ip, offset_fsb, (xfs_filblks_t)(last_fsb - offset_fsb), XFS_BMAPI_DELAY | XFS_BMAPI_WRITE | XFS_BMAPI_ENTIRE, &firstblock, 1, imap, @@ -680,7 +683,7 @@ retry: */ if (nimaps == 0) { xfs_iomap_enter_trace(XFS_IOMAP_WRITE_NOSPACE, - io, offset, count); + ip, offset, count); if (xfs_flush_space(ip, &fsynced, &ioflag)) return XFS_ERROR(ENOSPC); @@ -788,7 +791,7 @@ xfs_iomap_write_allocate( } /* Go get the actual blocks */ - error = XFS_BMAPI(mp, tp, io, map_start_fsb, count_fsb, + error = xfs_bmapi(tp, ip, map_start_fsb, count_fsb, XFS_BMAPI_WRITE, &first_block, 1, imap, &nimaps, &free_list, NULL); if (error) @@ -860,8 +863,7 @@ xfs_iomap_write_unwritten( int committed; int error; - xfs_iomap_enter_trace(XFS_IOMAP_UNWRITTEN, - &ip->i_iocore, offset, count); + xfs_iomap_enter_trace(XFS_IOMAP_UNWRITTEN, ip, offset, count); offset_fsb = XFS_B_TO_FSBT(mp, offset); count_fsb = XFS_B_TO_FSB(mp, (xfs_ufsize_t)offset + count); @@ -895,7 +897,7 @@ xfs_iomap_write_unwritten( */ XFS_BMAP_INIT(&free_list, &firstfsb); nimaps = 1; - error = XFS_BMAPI(mp, tp, io, offset_fsb, count_fsb, + error = xfs_bmapi(tp, ip, offset_fsb, count_fsb, XFS_BMAPI_WRITE|XFS_BMAPI_CONVERT, &firstfsb, 1, &imap, &nimaps, &free_list, NULL); if (error) Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ksyms.c 2007-09-12 14:17:09.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c 2007-09-14 14:30:16.000000000 +0200 @@ -248,8 +248,6 @@ EXPORT_SYMBOL(xfs_ilock_nowait); EXPORT_SYMBOL(xfs_inode_lock_init); EXPORT_SYMBOL(xfs_internal_inum); EXPORT_SYMBOL(xfs_iocore_inode_init); -EXPORT_SYMBOL(xfs_iocore_xfs); -EXPORT_SYMBOL(xfs_iomap); EXPORT_SYMBOL(xfs_iput); EXPORT_SYMBOL(xfs_iput_new); EXPORT_SYMBOL(xfs_iread); Index: linux-2.6-xfs/fs/xfs/xfs_dfrag.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_dfrag.c 2007-09-12 14:17:09.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_dfrag.c 2007-09-14 14:30:16.000000000 +0200 @@ -111,7 +111,7 @@ xfs_swapext( goto error0; } - error = XFS_SWAP_EXTENTS(mp, &ip->i_iocore, &tip->i_iocore, sxp); + error = xfs_swap_extents(ip, ip, sxp); error0: if (fp != NULL) Index: linux-2.6-xfs/fs/xfs/xfs_inode.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_inode.c 2007-09-12 14:17:09.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_inode.c 2007-09-14 14:30:16.000000000 +0200 @@ -1709,7 +1709,7 @@ xfs_itruncate_finish( * runs. */ XFS_BMAP_INIT(&free_list, &first_block); - error = XFS_BUNMAPI(mp, ntp, &ip->i_iocore, + error = xfs_bunmapi(ntp, ip, first_unmap_block, unmap_len, XFS_BMAPI_AFLAG(fork) | (sync ? 0 : XFS_BMAPI_ASYNC), Index: linux-2.6-xfs/fs/xfs/xfs_iocore.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_iocore.c 2007-09-12 14:17:09.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_iocore.c 2007-09-14 14:30:16.000000000 +0200 @@ -47,46 +47,6 @@ #include "xfs_trans_space.h" #include "xfs_iomap.h" - -STATIC xfs_fsize_t -xfs_size_fn( - xfs_inode_t *ip) -{ - return XFS_ISIZE(ip); -} - -STATIC int -xfs_ioinit( - struct xfs_mount *mp, - struct xfs_mount_args *mntargs, - int flags) -{ - return xfs_mountfs(mp, flags); -} - -xfs_ioops_t xfs_iocore_xfs = { - .xfs_ioinit = (xfs_ioinit_t) xfs_ioinit, - .xfs_bmapi_func = (xfs_bmapi_t) xfs_bmapi, - .xfs_bunmapi_func = (xfs_bunmapi_t) xfs_bunmapi, - .xfs_bmap_eof_func = (xfs_bmap_eof_t) xfs_bmap_eof, - .xfs_iomap_write_direct = - (xfs_iomap_write_direct_t) xfs_iomap_write_direct, - .xfs_iomap_write_delay = - (xfs_iomap_write_delay_t) xfs_iomap_write_delay, - .xfs_iomap_write_allocate = - (xfs_iomap_write_allocate_t) xfs_iomap_write_allocate, - .xfs_iomap_write_unwritten = - (xfs_iomap_write_unwritten_t) xfs_iomap_write_unwritten, - .xfs_ilock = (xfs_lock_t) xfs_ilock, - .xfs_lck_map_shared = (xfs_lck_map_shared_t) xfs_ilock_map_shared, - .xfs_ilock_demote = (xfs_lock_demote_t) xfs_ilock_demote, - .xfs_ilock_nowait = (xfs_lock_nowait_t) xfs_ilock_nowait, - .xfs_unlock = (xfs_unlk_t) xfs_iunlock, - .xfs_size_func = (xfs_size_t) xfs_size_fn, - .xfs_iodone = (xfs_iodone_t) fs_noerr, - .xfs_swap_extents_func = (xfs_swap_extents_t) xfs_swap_extents, -}; - void xfs_iocore_inode_reinit( xfs_inode_t *ip) Index: linux-2.6-xfs/fs/xfs/xfs_mount.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_mount.c 2007-09-13 12:33:53.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_mount.c 2007-09-14 14:30:16.000000000 +0200 @@ -1307,7 +1307,6 @@ xfs_unmountfs(xfs_mount_t *mp, struct cr #if defined(DEBUG) || defined(INDUCE_IO_ERROR) xfs_errortag_clearall(mp, 0); #endif - XFS_IODONE(mp); xfs_mount_free(mp); return 0; } Index: linux-2.6-xfs/fs/xfs/xfs_mount.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_mount.h 2007-09-12 14:17:09.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_mount.h 2007-09-14 14:30:16.000000000 +0200 @@ -196,105 +196,6 @@ typedef struct xfs_qmops { #define XFS_QM_QUOTACTL(mp, cmd, id, addr) \ (*(mp)->m_qm_ops->xfs_quotactl)(mp, cmd, id, addr) - -/* - * Prototypes and functions for I/O core modularization. - */ - -typedef int (*xfs_ioinit_t)(struct xfs_mount *, - struct xfs_mount_args *, int); -typedef int (*xfs_bmapi_t)(struct xfs_trans *, void *, - xfs_fileoff_t, xfs_filblks_t, int, - xfs_fsblock_t *, xfs_extlen_t, - struct xfs_bmbt_irec *, int *, - struct xfs_bmap_free *, struct xfs_extdelta *); -typedef int (*xfs_bunmapi_t)(struct xfs_trans *, - void *, xfs_fileoff_t, - xfs_filblks_t, int, xfs_extnum_t, - xfs_fsblock_t *, struct xfs_bmap_free *, - struct xfs_extdelta *, int *); -typedef int (*xfs_bmap_eof_t)(void *, xfs_fileoff_t, int, int *); -typedef int (*xfs_iomap_write_direct_t)( - void *, xfs_off_t, size_t, int, - struct xfs_bmbt_irec *, int *, int); -typedef int (*xfs_iomap_write_delay_t)( - void *, xfs_off_t, size_t, int, - struct xfs_bmbt_irec *, int *); -typedef int (*xfs_iomap_write_allocate_t)( - void *, xfs_off_t, size_t, - struct xfs_bmbt_irec *, int *); -typedef int (*xfs_iomap_write_unwritten_t)( - void *, xfs_off_t, size_t); -typedef uint (*xfs_lck_map_shared_t)(void *); -typedef void (*xfs_lock_t)(void *, uint); -typedef void (*xfs_lock_demote_t)(void *, uint); -typedef int (*xfs_lock_nowait_t)(void *, uint); -typedef void (*xfs_unlk_t)(void *, unsigned int); -typedef xfs_fsize_t (*xfs_size_t)(void *); -typedef xfs_fsize_t (*xfs_iodone_t)(struct xfs_mount *); -typedef int (*xfs_swap_extents_t)(void *, void *, - struct xfs_swapext*); - -typedef struct xfs_ioops { - xfs_ioinit_t xfs_ioinit; - xfs_bmapi_t xfs_bmapi_func; - xfs_bunmapi_t xfs_bunmapi_func; - xfs_bmap_eof_t xfs_bmap_eof_func; - xfs_iomap_write_direct_t xfs_iomap_write_direct; - xfs_iomap_write_delay_t xfs_iomap_write_delay; - xfs_iomap_write_allocate_t xfs_iomap_write_allocate; - xfs_iomap_write_unwritten_t xfs_iomap_write_unwritten; - xfs_lock_t xfs_ilock; - xfs_lck_map_shared_t xfs_lck_map_shared; - xfs_lock_demote_t xfs_ilock_demote; - xfs_lock_nowait_t xfs_ilock_nowait; - xfs_unlk_t xfs_unlock; - xfs_size_t xfs_size_func; - xfs_iodone_t xfs_iodone; - xfs_swap_extents_t xfs_swap_extents_func; -} xfs_ioops_t; - -#define XFS_IOINIT(mp, args, flags) \ - (*(mp)->m_io_ops.xfs_ioinit)(mp, args, flags) -#define XFS_BMAPI(mp, trans,io,bno,len,f,first,tot,mval,nmap,flist,delta) \ - (*(mp)->m_io_ops.xfs_bmapi_func) \ - (trans,(io)->io_obj,bno,len,f,first,tot,mval,nmap,flist,delta) -#define XFS_BUNMAPI(mp, trans,io,bno,len,f,nexts,first,flist,delta,done) \ - (*(mp)->m_io_ops.xfs_bunmapi_func) \ - (trans,(io)->io_obj,bno,len,f,nexts,first,flist,delta,done) -#define XFS_BMAP_EOF(mp, io, endoff, whichfork, eof) \ - (*(mp)->m_io_ops.xfs_bmap_eof_func) \ - ((io)->io_obj, endoff, whichfork, eof) -#define XFS_IOMAP_WRITE_DIRECT(mp, io, offset, count, flags, mval, nmap, found)\ - (*(mp)->m_io_ops.xfs_iomap_write_direct) \ - ((io)->io_obj, offset, count, flags, mval, nmap, found) -#define XFS_IOMAP_WRITE_DELAY(mp, io, offset, count, flags, mval, nmap) \ - (*(mp)->m_io_ops.xfs_iomap_write_delay) \ - ((io)->io_obj, offset, count, flags, mval, nmap) -#define XFS_IOMAP_WRITE_ALLOCATE(mp, io, offset, count, mval, nmap) \ - (*(mp)->m_io_ops.xfs_iomap_write_allocate) \ - ((io)->io_obj, offset, count, mval, nmap) -#define XFS_IOMAP_WRITE_UNWRITTEN(mp, io, offset, count) \ - (*(mp)->m_io_ops.xfs_iomap_write_unwritten) \ - ((io)->io_obj, offset, count) -#define XFS_LCK_MAP_SHARED(mp, io) \ - (*(mp)->m_io_ops.xfs_lck_map_shared)((io)->io_obj) -#define XFS_ILOCK(mp, io, mode) \ - (*(mp)->m_io_ops.xfs_ilock)((io)->io_obj, mode) -#define XFS_ILOCK_NOWAIT(mp, io, mode) \ - (*(mp)->m_io_ops.xfs_ilock_nowait)((io)->io_obj, mode) -#define XFS_IUNLOCK(mp, io, mode) \ - (*(mp)->m_io_ops.xfs_unlock)((io)->io_obj, mode) -#define XFS_ILOCK_DEMOTE(mp, io, mode) \ - (*(mp)->m_io_ops.xfs_ilock_demote)((io)->io_obj, mode) -#define XFS_SIZE(mp, io) \ - (*(mp)->m_io_ops.xfs_size_func)((io)->io_obj) -#define XFS_IODONE(mp) \ - (*(mp)->m_io_ops.xfs_iodone)(mp) -#define XFS_SWAP_EXTENTS(mp, io, tio, sxp) \ - (*(mp)->m_io_ops.xfs_swap_extents_func) \ - ((io)->io_obj, (tio)->io_obj, sxp) - #ifdef HAVE_PERCPU_SB /* @@ -423,7 +324,6 @@ typedef struct xfs_mount { * hash table */ struct xfs_dmops *m_dm_ops; /* vector of DMI ops */ struct xfs_qmops *m_qm_ops; /* vector of XQM ops */ - struct xfs_ioops m_io_ops; /* vector of I/O ops */ atomic_t m_active_trans; /* number trans frozen */ #ifdef HAVE_PERCPU_SB xfs_icsb_cnts_t *m_sb_cnts; /* per-cpu superblock counters */ @@ -646,7 +546,6 @@ extern int xfs_qmops_get(struct xfs_moun extern void xfs_qmops_put(struct xfs_mount *); extern struct xfs_dmops xfs_dmcore_xfs; -extern struct xfs_ioops xfs_iocore_xfs; extern int xfs_init(void); extern void xfs_cleanup(void); Index: linux-2.6-xfs/fs/xfs/xfs_vfsops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vfsops.c 2007-09-12 14:17:09.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_vfsops.c 2007-09-14 14:30:16.000000000 +0200 @@ -449,8 +449,6 @@ xfs_mount( if (error) return error; - mp->m_io_ops = xfs_iocore_xfs; - if (args->flags & XFSMNT_QUIET) flags |= XFS_MFSI_QUIET; @@ -544,7 +542,7 @@ xfs_mount( if ((error = xfs_filestream_mount(mp))) goto error2; - error = XFS_IOINIT(mp, args, flags); + error = xfs_mountfs(mp, flags); if (error) goto error2; Index: linux-2.6-xfs/fs/xfs/xfs_vnodeops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.c 2007-09-13 11:59:59.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.c 2007-09-14 14:30:16.000000000 +0200 @@ -1187,7 +1187,7 @@ xfs_free_eofblocks( nimaps = 1; xfs_ilock(ip, XFS_ILOCK_SHARED); - error = XFS_BMAPI(mp, NULL, &ip->i_iocore, end_fsb, map_len, 0, + error = xfs_bmapi(NULL, ip, end_fsb, map_len, 0, NULL, 0, &imap, &nimaps, NULL, NULL); xfs_iunlock(ip, XFS_ILOCK_SHARED); @@ -3983,7 +3983,7 @@ retry: * Issue the xfs_bmapi() call to allocate the blocks */ XFS_BMAP_INIT(&free_list, &firstfsb); - error = XFS_BMAPI(mp, tp, &ip->i_iocore, startoffset_fsb, + error = xfs_bmapi(tp, ip, startoffset_fsb, allocatesize_fsb, bmapi_flag, &firstfsb, 0, imapp, &nimaps, &free_list, NULL); @@ -4065,7 +4065,7 @@ xfs_zero_remaining_bytes( for (offset = startoff; offset <= endoff; offset = lastoffset + 1) { offset_fsb = XFS_B_TO_FSBT(mp, offset); nimap = 1; - error = XFS_BMAPI(mp, NULL, &ip->i_iocore, offset_fsb, 1, 0, + error = xfs_bmapi(NULL, ip, offset_fsb, 1, 0, NULL, 0, &imap, &nimap, NULL, NULL); if (error || nimap < 1) break; @@ -4200,7 +4200,7 @@ xfs_free_file_space( */ if (rt && !XFS_SB_VERSION_HASEXTFLGBIT(&mp->m_sb)) { nimap = 1; - error = XFS_BMAPI(mp, NULL, &ip->i_iocore, startoffset_fsb, + error = xfs_bmapi(NULL, ip, startoffset_fsb, 1, 0, NULL, 0, &imap, &nimap, NULL, NULL); if (error) goto out_unlock_iolock; @@ -4215,7 +4215,7 @@ xfs_free_file_space( startoffset_fsb += mp->m_sb.sb_rextsize - mod; } nimap = 1; - error = XFS_BMAPI(mp, NULL, &ip->i_iocore, endoffset_fsb - 1, + error = xfs_bmapi(NULL, ip, endoffset_fsb - 1, 1, 0, NULL, 0, &imap, &nimap, NULL, NULL); if (error) goto out_unlock_iolock; @@ -4291,7 +4291,7 @@ xfs_free_file_space( * issue the bunmapi() call to free the blocks */ XFS_BMAP_INIT(&free_list, &firstfsb); - error = XFS_BUNMAPI(mp, tp, &ip->i_iocore, startoffset_fsb, + error = xfs_bunmapi(tp, ip, startoffset_fsb, endoffset_fsb - startoffset_fsb, 0, 2, &firstfsb, &free_list, NULL, &done); if (error) { 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-13 11:59:59.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_aops.c 2007-09-14 14:30:16.000000000 +0200 @@ -317,7 +317,7 @@ xfs_map_blocks( xfs_inode_t *ip = XFS_I(inode); int error, nmaps = 1; - error = xfs_bmap(ip, offset, count, + error = xfs_iomap(ip, offset, count, flags, mapp, &nmaps); if (!error && (flags & (BMAPI_WRITE|BMAPI_ALLOCATE))) xfs_iflags_set(ip, XFS_IMODIFIED); @@ -1342,7 +1342,7 @@ __xfs_get_blocks( offset = (xfs_off_t)iblock << inode->i_blkbits; ASSERT(bh_result->b_size >= (1 << inode->i_blkbits)); size = bh_result->b_size; - error = xfs_bmap(XFS_I(inode), offset, size, + error = xfs_iomap(XFS_I(inode), offset, size, create ? flags : BMAPI_READ, &iomap, &niomap); if (error) return -error; Index: linux-2.6-xfs/fs/xfs/xfs_iomap.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_iomap.h 2007-09-13 12:33:56.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_iomap.h 2007-09-14 14:30:16.000000000 +0200 @@ -71,11 +71,10 @@ typedef struct xfs_iomap { iomap_flags_t iomap_flags; } xfs_iomap_t; -struct xfs_iocore; struct xfs_inode; struct xfs_bmbt_irec; -extern int xfs_iomap(struct xfs_iocore *, xfs_off_t, ssize_t, int, +extern int xfs_iomap(struct xfs_inode *, xfs_off_t, ssize_t, int, struct xfs_iomap *, int *); extern int xfs_iomap_write_direct(struct xfs_inode *, xfs_off_t, size_t, int, struct xfs_bmbt_irec *, int *, int); From owner-xfs@oss.sgi.com Fri Sep 14 09:27:54 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Sep 2007 09:27: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.7 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 l8EGRp4p028477 for ; Fri, 14 Sep 2007 09:27:53 -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 l8EGRqA5007365 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 14 Sep 2007 18:27:52 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8EGRqba007363 for xfs@oss.sgi.com; Fri, 14 Sep 2007 18:27:52 +0200 Date: Fri, 14 Sep 2007 18:27:52 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: [PATCH 2/4] simplify vn_revalidate Message-ID: <20070914162752.GC7110@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: 12898 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 No need to allocate a bhv_vattr_t on stack and call xfs_getattr to update a few fields in the Linux inode from the XFS inode, just do it directly. And yes, this function is in dire need of a better name and prototype, I'll do in a separate patch, though. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ioctl.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ioctl.c 2007-09-06 10:18:02.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ioctl.c 2007-09-06 10:26:33.000000000 +0200 @@ -1217,7 +1217,7 @@ xfs_ioc_xattr( error = xfs_setattr(ip, vattr, attr_flags, NULL); if (likely(!error)) - __vn_revalidate(vp, vattr); /* update flags */ + vn_revalidate(vp); /* update flags */ error = -error; break; } @@ -1273,7 +1273,7 @@ xfs_ioc_xattr( error = xfs_setattr(ip, vattr, attr_flags, NULL); if (likely(!error)) - __vn_revalidate(vp, vattr); /* update flags */ + vn_revalidate(vp); /* update flags */ error = -error; break; } Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_iops.c 2007-09-06 10:25:54.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c 2007-09-06 10:26:33.000000000 +0200 @@ -645,7 +645,7 @@ xfs_vn_setattr( error = xfs_setattr(XFS_I(inode), &vattr, flags, NULL); if (likely(!error)) - __vn_revalidate(vn_from_inode(inode), &vattr); + vn_revalidate(vn_from_inode(inode)); return -error; } Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ksyms.c 2007-09-06 10:18:00.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c 2007-09-06 10:26:33.000000000 +0200 @@ -183,7 +183,6 @@ EXPORT_SYMBOL(uuid_table_remove); EXPORT_SYMBOL(vn_hold); EXPORT_SYMBOL(vn_initialize); EXPORT_SYMBOL(vn_revalidate); -EXPORT_SYMBOL(vn_revalidate_core); #if defined(CONFIG_XFS_POSIX_ACL) EXPORT_SYMBOL(xfs_acl_vtoacl); Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_vnode.c 2007-09-06 10:18:00.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.c 2007-09-06 10:38:40.000000000 +0200 @@ -97,69 +97,57 @@ vn_initialize( } /* - * Revalidate the Linux inode from the vattr. + * Revalidate the Linux inode from the XFS inode. * Note: i_size _not_ updated; we must hold the inode * semaphore when doing that - callers responsibility. */ -void -vn_revalidate_core( - bhv_vnode_t *vp, - bhv_vattr_t *vap) -{ - struct inode *inode = vn_to_inode(vp); - - inode->i_mode = vap->va_mode; - inode->i_nlink = vap->va_nlink; - inode->i_uid = vap->va_uid; - inode->i_gid = vap->va_gid; - inode->i_blocks = vap->va_nblocks; - inode->i_mtime = vap->va_mtime; - inode->i_ctime = vap->va_ctime; - if (vap->va_xflags & XFS_XFLAG_IMMUTABLE) +int +vn_revalidate( + bhv_vnode_t *vp) +{ + struct inode *inode = vn_to_inode(vp); + struct xfs_inode *ip = XFS_I(inode); + struct xfs_mount *mp = ip->i_mount; + unsigned long xflags; + + xfs_itrace_entry(ip); + + if (XFS_FORCED_SHUTDOWN(mp)) + return -EIO; + + xfs_ilock(ip, XFS_ILOCK_SHARED); + inode->i_mode = ip->i_d.di_mode; + inode->i_nlink = ip->i_d.di_nlink; + inode->i_uid = ip->i_d.di_uid; + inode->i_gid = ip->i_d.di_gid; + inode->i_blocks = + XFS_FSB_TO_BB(mp, ip->i_d.di_nblocks + ip->i_delayed_blks); + inode->i_mtime.tv_sec = ip->i_d.di_mtime.t_sec; + inode->i_mtime.tv_nsec = ip->i_d.di_mtime.t_nsec; + inode->i_ctime.tv_sec = ip->i_d.di_ctime.t_sec; + inode->i_ctime.tv_nsec = ip->i_d.di_ctime.t_nsec; + + xflags = xfs_ip2xflags(ip); + if (xflags & XFS_XFLAG_IMMUTABLE) inode->i_flags |= S_IMMUTABLE; else inode->i_flags &= ~S_IMMUTABLE; - if (vap->va_xflags & XFS_XFLAG_APPEND) + if (xflags & XFS_XFLAG_APPEND) inode->i_flags |= S_APPEND; else inode->i_flags &= ~S_APPEND; - if (vap->va_xflags & XFS_XFLAG_SYNC) + if (xflags & XFS_XFLAG_SYNC) inode->i_flags |= S_SYNC; else inode->i_flags &= ~S_SYNC; - if (vap->va_xflags & XFS_XFLAG_NOATIME) + if (xflags & XFS_XFLAG_NOATIME) inode->i_flags |= S_NOATIME; else inode->i_flags &= ~S_NOATIME; -} - -/* - * Revalidate the Linux inode from the vnode. - */ -int -__vn_revalidate( - bhv_vnode_t *vp, - bhv_vattr_t *vattr) -{ - int error; - - xfs_itrace_entry(xfs_vtoi(vp)); - vattr->va_mask = XFS_AT_STAT | XFS_AT_XFLAGS; - error = xfs_getattr(xfs_vtoi(vp), vattr, 0); - if (likely(!error)) { - vn_revalidate_core(vp, vattr); - xfs_iflags_clear(xfs_vtoi(vp), XFS_IMODIFIED); - } - return -error; -} - -int -vn_revalidate( - bhv_vnode_t *vp) -{ - bhv_vattr_t vattr; + xfs_iunlock(ip, XFS_ILOCK_SHARED); - return __vn_revalidate(vp, &vattr); + xfs_iflags_clear(ip, XFS_IMODIFIED); + return 0; } /* Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_vnode.h 2007-09-06 10:18:50.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.h 2007-09-06 10:26:33.000000000 +0200 @@ -189,8 +189,6 @@ typedef struct bhv_vattr { extern void vn_init(void); extern bhv_vnode_t *vn_initialize(struct inode *); extern int vn_revalidate(bhv_vnode_t *); -extern int __vn_revalidate(bhv_vnode_t *, bhv_vattr_t *); -extern void vn_revalidate_core(bhv_vnode_t *, bhv_vattr_t *); /* * Yeah, these don't take vnode anymore at all, all this should be From owner-xfs@oss.sgi.com Fri Sep 14 09:30:43 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Sep 2007 09:30: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.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_24, J_CHICKENPOX_64 autolearn=no 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 l8EGUf4p030185 for ; Fri, 14 Sep 2007 09:30:42 -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 l8EGUgA5007488 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 14 Sep 2007 18:30:42 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8EGUgpV007486 for xfs@oss.sgi.com; Fri, 14 Sep 2007 18:30:42 +0200 Date: Fri, 14 Sep 2007 18:30:42 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: [PATCH 5/4] simplify xfs_create/mknod/symlink prototype Message-ID: <20070914163041.GG7110@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: 12902 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 (sorry, go the patch numbering one off) Simplify the prototype for xfs_create/xfs_mkdir/xfs_symlink by not passing down a bhv_vattr_t that just hogs stack space. Instead pass down the mode in a mode_t and in case of xfs_crate the rdev as a scalar type aswell. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_iops.c 2007-09-14 14:34:55.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c 2007-09-14 14:40:49.000000000 +0200 @@ -272,7 +272,6 @@ xfs_vn_mknod( dev_t rdev) { struct inode *ip; - bhv_vattr_t vattr = { 0 }; bhv_vnode_t *vp = NULL, *dvp = vn_from_inode(dir); xfs_acl_t *default_acl = NULL; attrexists_t test_default_acl = _ACL_DEFAULT_EXISTS; @@ -298,19 +297,14 @@ xfs_vn_mknod( if (IS_POSIXACL(dir) && !default_acl && xfs_has_fs_struct(current)) mode &= ~current->fs->umask; - vattr.va_mask = XFS_AT_TYPE|XFS_AT_MODE; - vattr.va_mode = mode; - switch (mode & S_IFMT) { case S_IFCHR: case S_IFBLK: case S_IFIFO: case S_IFSOCK: - vattr.va_rdev = sysv_encode_dev(rdev); - vattr.va_mask |= XFS_AT_RDEV; - /*FALLTHROUGH*/ + rdev = sysv_encode_dev(rdev); case S_IFREG: - error = xfs_create(XFS_I(dir), dentry, &vattr, &vp, NULL); + error = xfs_create(XFS_I(dir), dentry, mode, rdev, &vp, NULL); break; case S_IFDIR: - error = xfs_mkdir(XFS_I(dir), dentry, &vattr, &vp, NULL); + error = xfs_mkdir(XFS_I(dir), dentry, mode, &vp, NULL); break; default: error = EINVAL; @@ -325,7 +319,7 @@ xfs_vn_mknod( if (unlikely(default_acl)) { if (!error) { - error = _ACL_INHERIT(vp, &vattr, default_acl); + error = _ACL_INHERIT(vp, mode, default_acl); if (!error) xfs_iflags_set(XFS_I(vp), XFS_IMODIFIED); else @@ -440,18 +434,17 @@ xfs_vn_symlink( const char *symname) { struct inode *ip; - bhv_vattr_t va = { 0 }; bhv_vnode_t *cvp; /* used to lookup symlink to put in dentry */ int error; + mode_t mode; cvp = NULL; - va.va_mode = S_IFLNK | + mode = S_IFLNK | (irix_symlink_mode ? 0777 & ~current->fs->umask : S_IRWXUGO); - va.va_mask = XFS_AT_TYPE|XFS_AT_MODE; - error = xfs_symlink(XFS_I(dir), dentry, &va, - (char *)symname, &cvp, NULL); + error = xfs_symlink(XFS_I(dir), dentry, (char *)symname, mode, + &cvp, NULL); if (likely(!error && cvp)) { error = xfs_init_security(cvp, dir); if (likely(!error)) { Index: linux-2.6-xfs/fs/xfs/xfs_vnodeops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.c 2007-09-14 14:31:34.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.c 2007-09-14 14:38:23.000000000 +0200 @@ -1819,7 +1819,8 @@ int xfs_create( xfs_inode_t *dp, bhv_vname_t *dentry, - bhv_vattr_t *vap, + mode_t mode, + xfs_dev_t rdev, bhv_vnode_t **vpp, cred_t *credp) { @@ -1829,7 +1830,6 @@ xfs_create( xfs_inode_t *ip; bhv_vnode_t *vp = NULL; xfs_trans_t *tp; - xfs_dev_t rdev; int error; xfs_bmap_free_t free_list; xfs_fsblock_t first_block; @@ -1840,20 +1840,18 @@ xfs_create( xfs_prid_t prid; struct xfs_dquot *udqp, *gdqp; uint resblks; - int dm_di_mode; int namelen; ASSERT(!*vpp); xfs_itrace_entry(dp); - dm_di_mode = vap->va_mode; namelen = VNAMELEN(dentry); if (DM_EVENT_ENABLED(dp, DM_EVENT_CREATE)) { error = XFS_SEND_NAMESP(mp, DM_EVENT_CREATE, dir_vp, DM_RIGHT_NULL, NULL, DM_RIGHT_NULL, name, NULL, - dm_di_mode, 0, 0); + mode, 0, 0); if (error) return error; @@ -1868,8 +1866,6 @@ xfs_create( udqp = gdqp = NULL; if (dp->i_d.di_flags & XFS_DIFLAG_PROJINHERIT) prid = dp->i_d.di_projid; - else if (vap->va_mask & XFS_AT_PROJID) - prid = (xfs_prid_t)vap->va_projid; else prid = (xfs_prid_t)dfltprid; @@ -1921,8 +1917,7 @@ xfs_create( if (resblks == 0 && (error = xfs_dir_canenter(tp, dp, name, namelen))) goto error_return; - rdev = (vap->va_mask & XFS_AT_RDEV) ? vap->va_rdev : 0; - error = xfs_dir_ialloc(&tp, dp, vap->va_mode, 1, + error = xfs_dir_ialloc(&tp, dp, mode, 1, rdev, credp, prid, resblks > 0, &ip, &committed); if (error) { @@ -2013,7 +2008,7 @@ std_return: dir_vp, DM_RIGHT_NULL, *vpp ? vp:NULL, DM_RIGHT_NULL, name, NULL, - dm_di_mode, error, 0); + mode, error, 0); } return error; @@ -2702,7 +2697,7 @@ int xfs_mkdir( xfs_inode_t *dp, bhv_vname_t *dentry, - bhv_vattr_t *vap, + mode_t mode, bhv_vnode_t **vpp, cred_t *credp) { @@ -2724,19 +2719,17 @@ xfs_mkdir( xfs_prid_t prid; struct xfs_dquot *udqp, *gdqp; uint resblks; - int dm_di_mode; if (XFS_FORCED_SHUTDOWN(mp)) return XFS_ERROR(EIO); tp = NULL; - dm_di_mode = vap->va_mode; if (DM_EVENT_ENABLED(dp, DM_EVENT_CREATE)) { error = XFS_SEND_NAMESP(mp, DM_EVENT_CREATE, dir_vp, DM_RIGHT_NULL, NULL, DM_RIGHT_NULL, dir_name, NULL, - dm_di_mode, 0, 0); + mode, 0, 0); if (error) return error; dm_event_sent = 1; @@ -2750,8 +2743,6 @@ xfs_mkdir( udqp = gdqp = NULL; if (dp->i_d.di_flags & XFS_DIFLAG_PROJINHERIT) prid = dp->i_d.di_projid; - else if (vap->va_mask & XFS_AT_PROJID) - prid = (xfs_prid_t)vap->va_projid; else prid = (xfs_prid_t)dfltprid; @@ -2804,7 +2795,7 @@ xfs_mkdir( /* * create the directory inode. */ - error = xfs_dir_ialloc(&tp, dp, vap->va_mode, 2, + error = xfs_dir_ialloc(&tp, dp, mode, 2, 0, credp, prid, resblks > 0, &cdp, NULL); if (error) { @@ -2898,7 +2889,7 @@ std_return: created ? XFS_ITOV(cdp):NULL, DM_RIGHT_NULL, dir_name, NULL, - dm_di_mode, error, 0); + mode, error, 0); } return error; @@ -3155,8 +3146,8 @@ int xfs_symlink( xfs_inode_t *dp, bhv_vname_t *dentry, - bhv_vattr_t *vap, char *target_path, + mode_t mode, bhv_vnode_t **vpp, cred_t *credp) { @@ -3243,8 +3234,6 @@ xfs_symlink( udqp = gdqp = NULL; if (dp->i_d.di_flags & XFS_DIFLAG_PROJINHERIT) prid = dp->i_d.di_projid; - else if (vap->va_mask & XFS_AT_PROJID) - prid = (xfs_prid_t)vap->va_projid; else prid = (xfs_prid_t)dfltprid; @@ -3313,7 +3302,7 @@ xfs_symlink( /* * Allocate an inode for the symlink. */ - error = xfs_dir_ialloc(&tp, dp, S_IFLNK | (vap->va_mode&~S_IFMT), + error = xfs_dir_ialloc(&tp, dp, S_IFLNK | (mode & ~S_IFMT), 1, 0, credp, prid, resblks > 0, &ip, NULL); if (error) { if (error == ENOSPC) Index: linux-2.6-xfs/fs/xfs/xfs_vnodeops.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.h 2007-09-14 14:31:34.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.h 2007-09-14 14:34:49.000000000 +0200 @@ -26,19 +26,19 @@ int xfs_release(struct xfs_inode *ip); int xfs_inactive(struct xfs_inode *ip); int xfs_lookup(struct xfs_inode *dp, bhv_vname_t *dentry, bhv_vnode_t **vpp); -int xfs_create(struct xfs_inode *dp, bhv_vname_t *dentry, - struct bhv_vattr *vap, bhv_vnode_t **vpp, struct cred *credp); +int xfs_create(struct xfs_inode *dp, bhv_vname_t *dentry, mode_t mode, + xfs_dev_t rdev, bhv_vnode_t **vpp, struct cred *credp); int xfs_remove(struct xfs_inode *dp, bhv_vname_t *dentry); int xfs_link(struct xfs_inode *tdp, bhv_vnode_t *src_vp, bhv_vname_t *dentry); int xfs_mkdir(struct xfs_inode *dp, bhv_vname_t *dentry, - struct bhv_vattr *vap, bhv_vnode_t **vpp, struct cred *credp); + mode_t mode, bhv_vnode_t **vpp, struct cred *credp); int xfs_rmdir(struct xfs_inode *dp, bhv_vname_t *dentry); int xfs_readdir(struct xfs_inode *dp, void *dirent, size_t bufsize, xfs_off_t *offset, filldir_t filldir); int xfs_symlink(struct xfs_inode *dp, bhv_vname_t *dentry, - struct bhv_vattr *vap, char *target_path, - bhv_vnode_t **vpp, struct cred *credp); + char *target_path, mode_t mode, bhv_vnode_t **vpp, + struct cred *credp); int xfs_fid2(struct xfs_inode *ip, struct xfs_fid *xfid); int xfs_rwlock(struct xfs_inode *ip, bhv_vrwlock_t locktype); void xfs_rwunlock(struct xfs_inode *ip, bhv_vrwlock_t locktype); Index: linux-2.6-xfs/fs/xfs/xfs_acl.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_acl.c 2007-09-14 14:39:46.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_acl.c 2007-09-14 14:40:00.000000000 +0200 @@ -705,7 +705,7 @@ xfs_acl_vtoacl( int xfs_acl_inherit( bhv_vnode_t *vp, - bhv_vattr_t *vap, + mode_t mode, xfs_acl_t *pdaclp) { xfs_acl_t *cacl; @@ -733,7 +733,7 @@ xfs_acl_inherit( return ENOMEM; memcpy(cacl, pdaclp, sizeof(xfs_acl_t)); - xfs_acl_filter_mode(vap->va_mode, cacl); + xfs_acl_filter_mode(mode, cacl); xfs_acl_setmode(vp, cacl, &basicperms); /* Index: linux-2.6-xfs/fs/xfs/xfs_acl.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_acl.h 2007-09-14 14:40:09.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_acl.h 2007-09-14 14:40:31.000000000 +0200 @@ -57,7 +57,7 @@ extern struct kmem_zone *xfs_acl_zone; (zone) = kmem_zone_init(sizeof(xfs_acl_t), (name)) #define xfs_acl_zone_destroy(zone) kmem_zone_destroy(zone) -extern int xfs_acl_inherit(bhv_vnode_t *, struct bhv_vattr *, xfs_acl_t *); +extern int xfs_acl_inherit(bhv_vnode_t *, mode_t mode, xfs_acl_t *); extern int xfs_acl_iaccess(struct xfs_inode *, mode_t, cred_t *); extern int xfs_acl_vtoacl(bhv_vnode_t *, xfs_acl_t *, xfs_acl_t *); extern int xfs_acl_vhasacl_access(bhv_vnode_t *); @@ -70,7 +70,7 @@ extern int xfs_acl_vremove(bhv_vnode_t * #define _ACL_TYPE_DEFAULT 2 #define _ACL_PERM_INVALID(perm) ((perm) & ~(ACL_READ|ACL_WRITE|ACL_EXECUTE)) -#define _ACL_INHERIT(c,v,d) (xfs_acl_inherit(c,v,d)) +#define _ACL_INHERIT(c,m,d) (xfs_acl_inherit(c,m,d)) #define _ACL_GET_ACCESS(pv,pa) (xfs_acl_vtoacl(pv,pa,NULL) == 0) #define _ACL_GET_DEFAULT(pv,pd) (xfs_acl_vtoacl(pv,NULL,pd) == 0) #define _ACL_ACCESS_EXISTS xfs_acl_vhasacl_access @@ -90,7 +90,7 @@ extern int xfs_acl_vremove(bhv_vnode_t * #define xfs_acl_vhasacl_default(v) (0) #define _ACL_ALLOC(a) (1) /* successfully allocate nothing */ #define _ACL_FREE(a) ((void)0) -#define _ACL_INHERIT(c,v,d) (0) +#define _ACL_INHERIT(c,m,d) (0) #define _ACL_GET_ACCESS(pv,pa) (0) #define _ACL_GET_DEFAULT(pv,pd) (0) #define _ACL_ACCESS_EXISTS (NULL) From owner-xfs@oss.sgi.com Fri Sep 14 09:36:06 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Sep 2007 09:36:11 -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,RCVD_IN_PSBL, VIRUS_WARNING179 autolearn=no version=3.2.0-pre1-r499012 Received: from mx.sidi.istruzione.it (mx4.sidi.istruzione.it [193.206.15.65]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8EGa54p031541 for ; Fri, 14 Sep 2007 09:36:06 -0700 Received: from localhost (unknown [127.0.0.1]) by mx4.sidi.istruzione.it (Mail Service) with ESMTP id 7BE705051B for ; Fri, 14 Sep 2007 16:24:45 +0200 (CEST) Content-Type: multipart/report; report-type=delivery-status; boundary="----------=_1189779885-12984-0" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Subject: VIRUS (Worm.SomeFool.AA-2): IN UNA E-MAIL DA LEI INVIATA In-Reply-To: <20070914142442.4B0D55057B@mx4.sidi.istruzione.it> Message-ID: From: "Content-filter at mx4.sidi.istruzione.it" To: Date: Fri, 14 Sep 2007 16:24:45 +0200 (CEST) X-archive-position: 12903 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: postmaster@mx4.sidi.istruzione.it Precedence: bulk X-list: xfs This is a multi-part message in MIME format... ------------=_1189779885-12984-0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit VIRUS ALERT Il sistema di scansione ha rilevato un problema in una email presumibilmente inviata da Lei -> (), per il seguente destinatario: -> tate01000x@istruzione.it La consegna del messaggio non e' potuta avvenire Di seguito i riferimenti della e-Mail inviata: ------------------------- BEGIN HEADERS ----------------------------- Return-Path: Received: from istruzione.it (unknown [85.45.242.114]) by mx4.sidi.istruzione.it (Mail Service) with ESMTP id 4B0D55057B for ; Fri, 14 Sep 2007 16:24:41 +0200 (CEST) From: linux-xfs@oss.sgi.com To: tate01000x@istruzione.it Subject: Information Date: Fri, 14 Sep 2007 16:24:32 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0013_0000280D.00005858" X-Priority: 1 X-MSMail-Priority: High Message-Id: <20070914142442.4B0D55057B@mx4.sidi.istruzione.it> -------------------------- END HEADERS ------------------------------ ------------=_1189779885-12984-0 Content-Type: message/delivery-status; name="dsn_status" Content-Disposition: inline; filename="dsn_status" Content-Transfer-Encoding: 7bit Content-Description: Delivery error report Reporting-MTA: dns; mx4.sidi.istruzione.it Received-From-MTA: smtp; mx.sidi.istruzione.it ([127.0.0.1]) Arrival-Date: Fri, 14 Sep 2007 16:24:45 +0200 (CEST) Original-Recipient: rfc822;tate01000x@istruzione.it Final-Recipient: rfc822;tate01000x@istruzione.it Action: failed Status: 5.7.1 Diagnostic-Code: smtp; 550-5.7.1 Rejected, id=12984-10-12 - VIRUS: 550 5.7.1 Worm.SomeFool.AA-2 Last-Attempt-Date: Fri, 14 Sep 2007 16:24:45 +0200 (CEST) ------------=_1189779885-12984-0 Content-Type: text/rfc822-headers; name="header" Content-Disposition: inline; filename="header" Content-Transfer-Encoding: 7bit Content-Description: Message headers Return-Path: Received: from istruzione.it (unknown [85.45.242.114]) by mx4.sidi.istruzione.it (Mail Service) with ESMTP id 4B0D55057B for ; Fri, 14 Sep 2007 16:24:41 +0200 (CEST) From: linux-xfs@oss.sgi.com To: tate01000x@istruzione.it Subject: Information Date: Fri, 14 Sep 2007 16:24:32 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0013_0000280D.00005858" X-Priority: 1 X-MSMail-Priority: High Message-Id: <20070914142442.4B0D55057B@mx4.sidi.istruzione.it> ------------=_1189779885-12984-0-- From owner-xfs@oss.sgi.com Fri Sep 14 11:31:05 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Sep 2007 11:31: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=-3.4 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 l8EIV24p023833 for ; Fri, 14 Sep 2007 11:31:05 -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 l8EIV2KW006879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Sep 2007 14:31:02 -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 l8EIV1TL005514; Fri, 14 Sep 2007 14:31:01 -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 l8EIV13W019940; Fri, 14 Sep 2007 14:31:01 -0400 Message-ID: <46EAD364.7060305@sandeen.net> Date: Fri, 14 Sep 2007 13:31:00 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH 5/4] simplify xfs_create/mknod/symlink prototype References: <20070914163041.GG7110@lst.de> In-Reply-To: <20070914163041.GG7110@lst.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 12904 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: > (sorry, go the patch numbering one off) > > Simplify the prototype for xfs_create/xfs_mkdir/xfs_symlink by not > passing down a bhv_vattr_t that just hogs stack space. Instead pass > down the mode in a mode_t and in case of xfs_crate the rdev as a scalar > type aswell. With this whole patch series, I see these stack reductions on my x86 box, nice! --- before 2007-09-14 06:41:25.000000000 -0500 +++ after 2007-09-14 06:42:25.000000000 -0500 -vn_revalidate [xfs]: 100 +vn_revalidate [xfs]: 4 -xfs_bmbt_delrec [xfs]: 212 +xfs_bmbt_delrec [xfs]: 204 -xfs_free_file_space [xfs]: 196 +xfs_free_file_space [xfs]: 188 +xfs_ioc_fsgetxattr [xfs]: 28 -xfs_ioctl [xfs]: 64 +xfs_ioctl [xfs]: 68 -xfs_symlink [xfs]: 240 +xfs_symlink [xfs]: 256 -xfs_validate_fields [xfs]: 4 +xfs_validate_fields [xfs]: 8 -xfs_vn_getattr [xfs]: 104 +xfs_vn_getattr [xfs]: 12 -xfs_vn_link [xfs]: 108 +xfs_vn_link [xfs]: 8 -xfs_vn_mknod [xfs]: 128 +xfs_vn_mknod [xfs]: 32 -xfs_vn_rename [xfs]: 108 -xfs_vn_rmdir [xfs]: 104 +xfs_vn_rename [xfs]: 8 -xfs_vn_symlink [xfs]: 120 +xfs_vn_symlink [xfs]: 20 -xfs_vn_unlink [xfs]: 104 From owner-xfs@oss.sgi.com Fri Sep 14 11:34:28 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Sep 2007 11: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=-3.5 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 l8EIYQ4p024626 for ; Fri, 14 Sep 2007 11:34:27 -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 l8EIYRL1008509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Sep 2007 14:34:27 -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 l8EIYRiS006865; Fri, 14 Sep 2007 14:34:27 -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 l8EIYQ5F020327; Fri, 14 Sep 2007 14:34:27 -0400 Message-ID: <46EAD432.1030704@sandeen.net> Date: Fri, 14 Sep 2007 13:34:26 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: Eric Sandeen CC: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: [PATCH 5/4] simplify xfs_create/mknod/symlink prototype References: <20070914163041.GG7110@lst.de> <46EAD364.7060305@sandeen.net> In-Reply-To: <46EAD364.7060305@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 12905 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: > Christoph Hellwig wrote: >> (sorry, go the patch numbering one off) >> >> Simplify the prototype for xfs_create/xfs_mkdir/xfs_symlink by not >> passing down a bhv_vattr_t that just hogs stack space. Instead pass >> down the mode in a mode_t and in case of xfs_crate the rdev as a scalar >> type aswell. > > With this whole patch series, I see these stack reductions on my x86 > box, nice! > > -xfs_symlink [xfs]: 240 > +xfs_symlink [xfs]: 256 Although, that one is a little unfortunate ;) -eric From owner-xfs@oss.sgi.com Fri Sep 14 13:24:11 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Sep 2007 13:24: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.9 required=5.0 tests=AWL,BAYES_50,SPF_HELO_PASS, WHOIS_MYPRIVREG autolearn=no version=3.2.0-pre1-r499012 Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8EKO94p015841 for ; Fri, 14 Sep 2007 13:24:11 -0700 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1IWHRM-0005t8-Kk for linux-xfs@oss.sgi.com; Fri, 14 Sep 2007 13:07:00 -0700 Message-ID: <12682767.post@talk.nabble.com> Date: Fri, 14 Sep 2007 13:07:00 -0700 (PDT) From: Hxsrmeng To: linux-xfs@oss.sgi.com Subject: Newbie question about xfs_db with the response message "unexpected XFS SB magic number 0x2e524d46" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: hxsrmeng@gmail.com X-archive-position: 12906 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hxsrmeng@gmail.com Precedence: bulk X-list: xfs OpenSUSE10.2. and 2.6.22-rc7-default XFS 1) I'd like to run "xfs_db -f -c "sb 0" -c "p" ./myfile | egrep 'agcount|inopblog|agblklog'" to see the three values. I mounted my xfs_disk. Then I run : xfs_db -f -c "sb 0" -c "p" ./loop | egrep 'agcount|inopblog|agblklog' It said: xfs_db: unexpected XFS SB magic number 0x2e524d46 Floating point exception I don't know what the problem is. But if I umount my xfs_disk, Then I run xfs_db {my_xfs_device} xfs_db>sb xfs_db>p It's OK.But I can not see things about ./myfile now, since my xfs_disk is umounted. 2) I have to umount my xfs_disk before I use xfs_db, correct? 3) If I want to read the inode content of a file, say, myfile, I should "ls -li myfile" to get the inode number of myfile Then "xfs_db> inode " to read the content of inode Is what I said correct? Thanks in advance. -- View this message in context: http://www.nabble.com/Newbie-question-about-xfs_db-with-the-response-message-%22unexpected-XFS-SB-magic-number-0x2e524d46%22-tf4444973.html#a12682767 Sent from the linux-xfs mailing list archive at Nabble.com. From owner-xfs@oss.sgi.com Fri Sep 14 13:42:28 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Sep 2007 13:42: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=-3.6 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 l8EKgQ4p019152 for ; Fri, 14 Sep 2007 13:42:28 -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 l8EKgQ4X009564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Sep 2007 16:42:26 -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 l8EKgQLR005048; Fri, 14 Sep 2007 16:42:26 -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 l8EKgOiW018393; Fri, 14 Sep 2007 16:42:26 -0400 Message-ID: <46EAF230.4030407@sandeen.net> Date: Fri, 14 Sep 2007 15:42:24 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: Hxsrmeng CC: linux-xfs@oss.sgi.com Subject: Re: Newbie question about xfs_db with the response message "unexpected XFS SB magic number 0x2e524d46" References: <12682767.post@talk.nabble.com> In-Reply-To: <12682767.post@talk.nabble.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 12907 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 Hxsrmeng wrote: > OpenSUSE10.2. and 2.6.22-rc7-default XFS > 1) > I'd like to run "xfs_db -f -c "sb 0" -c "p" ./myfile | egrep > 'agcount|inopblog|agblklog'" to see the three values. if "myfile" is a file on your xfs filesystem, then that's not right. xfs_db needs to be pointed at a block device (or filesystem image file) containing an xfs filesystem. You can look at it while it's mounted, though (IIRC) the information may not be perfectly in sync with the fs's data. agcount, inopblog, etc are parameters of an xfs filesystem, not a file on that filesystem. What are you trying to learn (about your file or filesystem?) -Eric From owner-xfs@oss.sgi.com Fri Sep 14 13:58:47 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Sep 2007 13:58: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=0.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, WHOIS_MYPRIVREG autolearn=no version=3.2.0-pre1-r499012 Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8EKwk4p022671 for ; Fri, 14 Sep 2007 13:58:46 -0700 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1IWIFT-0007C4-Sd for linux-xfs@oss.sgi.com; Fri, 14 Sep 2007 13:58:47 -0700 Message-ID: <12683711.post@talk.nabble.com> Date: Fri, 14 Sep 2007 13:58:47 -0700 (PDT) From: Hxsrmeng To: linux-xfs@oss.sgi.com Subject: Re: Newbie question about xfs_db with the response message "unexpected XFS SB magic number 0x2e524d46" In-Reply-To: <46EAF230.4030407@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: hxsrmeng@gmail.com References: <12682767.post@talk.nabble.com> <46EAF230.4030407@sandeen.net> X-archive-position: 12908 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hxsrmeng@gmail.com Precedence: bulk X-list: xfs Thanks. But what should I do to " look at it while it's mounted,though (IIRC)"? Only thing I know is that I have to umount xfs_disk to use xfs_db. But at this time, I can not see files in my xfs_disk. Actually, I'd like to know where exactly myfile is located in xfs_disk. Eric Sandeen-3 wrote: > > Hxsrmeng wrote: >> OpenSUSE10.2. and 2.6.22-rc7-default XFS >> 1) >> I'd like to run "xfs_db -f -c "sb 0" -c "p" ./myfile | egrep >> 'agcount|inopblog|agblklog'" to see the three values. > > if "myfile" is a file on your xfs filesystem, then that's not right. > xfs_db needs to be pointed at a block device (or filesystem image file) > containing an xfs filesystem. You can look at it while it's mounted, > though (IIRC) the information may not be perfectly in sync with the fs's > data. > > agcount, inopblog, etc are parameters of an xfs filesystem, not a file > on that filesystem. > > What are you trying to learn (about your file or filesystem?) > > -Eric > > > > -- View this message in context: http://www.nabble.com/Newbie-question-about-xfs_db-with-the-response-message-%22unexpected-XFS-SB-magic-number-0x2e524d46%22-tf4444973.html#a12683711 Sent from the linux-xfs mailing list archive at Nabble.com. From owner-xfs@oss.sgi.com Fri Sep 14 14:21:06 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Sep 2007 14:21: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=-3.7 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 l8ELL24p027543 for ; Fri, 14 Sep 2007 14:21:06 -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 l8ELL2rF032386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Sep 2007 17:21:02 -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 l8ELL2wK023683; Fri, 14 Sep 2007 17:21:02 -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 l8ELL1OG027375; Fri, 14 Sep 2007 17:21:02 -0400 Message-ID: <46EAFB3D.9080109@sandeen.net> Date: Fri, 14 Sep 2007 16:21:01 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: Hxsrmeng CC: linux-xfs@oss.sgi.com Subject: Re: Newbie question about xfs_db with the response message "unexpected XFS SB magic number 0x2e524d46" References: <12682767.post@talk.nabble.com> <46EAF230.4030407@sandeen.net> <12683711.post@talk.nabble.com> In-Reply-To: <12683711.post@talk.nabble.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 12909 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 Hxsrmeng wrote: > Thanks. > But what should I do to " look at it while it's mounted,though (IIRC)"? > Only thing I know is that I have to umount xfs_disk to use xfs_db. But at > this time, I can not see files in my xfs_disk. > > Actually, I'd like to know where exactly myfile is located in xfs_disk. xfs_bmap -v myfile -Eric From owner-xfs@oss.sgi.com Fri Sep 14 15:05:21 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Sep 2007 15:05: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_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 l8EM5J4p003701 for ; Fri, 14 Sep 2007 15:05: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 l8EM5KA5019649 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 15 Sep 2007 00:05:20 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8EM5KLP019647; Sat, 15 Sep 2007 00:05:20 +0200 Date: Sat, 15 Sep 2007 00:05:20 +0200 From: Christoph Hellwig To: Eric Sandeen Cc: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: [PATCH 5/4] simplify xfs_create/mknod/symlink prototype Message-ID: <20070914220520.GA19567@lst.de> References: <20070914163041.GG7110@lst.de> <46EAD364.7060305@sandeen.net> <46EAD432.1030704@sandeen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46EAD432.1030704@sandeen.net> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 12910 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 14, 2007 at 01:34:26PM -0500, Eric Sandeen wrote: > > -xfs_symlink [xfs]: 240 > > +xfs_symlink [xfs]: 256 > > Although, that one is a little unfortunate ;) and rather odd. 16 bytes more stack for passing in a 32bit scalar instead of a 32/64bit pointer, huh? Then again we could just kill that parameter because symlinks always get the same mode.. From owner-xfs@oss.sgi.com Fri Sep 14 20:27:17 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Sep 2007 20:27: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.3 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 l8F3RG4p006152 for ; Fri, 14 Sep 2007 20:27:17 -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 7AC5118003EF4; Fri, 14 Sep 2007 22:27:19 -0500 (CDT) Message-ID: <46EB5115.3050808@sandeen.net> Date: Fri, 14 Sep 2007 22:27:17 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH 5/4] simplify xfs_create/mknod/symlink prototype References: <20070914163041.GG7110@lst.de> <46EAD364.7060305@sandeen.net> <46EAD432.1030704@sandeen.net> <20070914220520.GA19567@lst.de> In-Reply-To: <20070914220520.GA19567@lst.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 12911 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 Fri, Sep 14, 2007 at 01:34:26PM -0500, Eric Sandeen wrote: >>> -xfs_symlink [xfs]: 240 >>> +xfs_symlink [xfs]: 256 >> Although, that one is a little unfortunate ;) > > and rather odd. 16 bytes more stack for passing in a 32bit scalar > instead of a 32/64bit pointer, huh? Then again we could just kill > that parameter because symlinks always get the same mode.. it's a short on x86... *shrug* I dunno, ask Jakub ;-) -Eric From owner-xfs@oss.sgi.com Sat Sep 15 03:23:12 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 15 Sep 2007 03:23: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.4 required=5.0 tests=AWL,BAYES_40 autolearn=ham version=3.2.0-pre1-r499012 Received: from stlx01.stz-softwaretechnik.com (stz-softwaretechnik.de [217.160.223.211]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8FAN94p028358 for ; Sat, 15 Sep 2007 03:23:11 -0700 Received: from rg by stlx01.stz-softwaretechnik.com with local (Exim 3.36 #1 (Debian)) id 1IWUWf-00048J-00; Sat, 15 Sep 2007 12:05:21 +0200 Date: Sat, 15 Sep 2007 12:05:11 +0200 From: Ralf Gross To: Jordan Mendler Cc: xfs@oss.sgi.com Subject: Re: compression Message-ID: <20070915100511.GA8183@p15145560.pureserver.info> 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.9i X-archive-position: 12912 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Ralf-Lists@ralfgross.de Precedence: bulk X-list: xfs Jordan Mendler schrieb: > > 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. A very nice tool for backups is backuppc which stores all backed up files in a pool and uses hardlinks to map these files to the real backup. There is only one copy of each file in the pool regardless of on how may clients this file exist (De-duplication). You can use backuppc with tar/rsync/smb and with compression. Ralf From owner-xfs@oss.sgi.com Sat Sep 15 11:58:05 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 15 Sep 2007 11:58: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=3.7 required=5.0 tests=AWL,BAYES_05,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.189]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8FIw24p001275 for ; Sat, 15 Sep 2007 11:58:05 -0700 Received: by rv-out-0910.google.com with SMTP id k20so835730rvb for ; Sat, 15 Sep 2007 11:58:04 -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=LcJ48MXGdp28wsh1MockONxgNBaPjOLNCpOLK9voKgc=; b=M7b69o1xIUX8lO4JiovlpfgfpmEaMStnyplumfg0CGAROCFvTY6RBRqfeNHm6gN5BMsAC2Ri6DbmAE248QrLbJoAvigMUFroAO6HLCMJCz7sQkOW3L/kEzwHktT38yXSwekIkWEXCsZ9FmkTV5Ybj6MsJhFLwl9n8ZEBLodN0xg= 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=P8ZkV1nFUBqBRb3VUrPTaPDahXueN6szG4sIKkWTcII3PHif7n8zA23U0hTsyqh9QWzkVLN07aJc7uAEpjVwYXWmYMnGv0WA4Mo3+4E3pdVVBSfmCWCV9xfbN04/DkEN8/acF/MAUiEL6/CoCE9wfFxYpEr16XkJfk+TxpDWE1I= Received: by 10.140.191.14 with SMTP id o14mr449113rvf.1189882684715; Sat, 15 Sep 2007 11:58:04 -0700 (PDT) Received: by 10.141.159.19 with HTTP; Sat, 15 Sep 2007 11:58:04 -0700 (PDT) Message-ID: <654e62180709151158v454d33b8k864d5bcb8a37f003@mail.gmail.com> Date: Sat, 15 Sep 2007 11:58:04 -0700 From: "Jordan Mendler" To: "Ralf Gross" Subject: Re: compression Cc: xfs@oss.sgi.com In-Reply-To: <20070915100511.GA8183@p15145560.pureserver.info> MIME-Version: 1.0 References: <654e62180709111643k4700c2bdibec2a16eb5446e76@mail.gmail.com> <20070915100511.GA8183@p15145560.pureserver.info> X-Google-Sender-Auth: 00bfbd0e24b619e4 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 1179 X-archive-position: 12913 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 Cool. I will give that a shot. Right now I am just using rsync and rdiff-backup scripts, but it would be nice to have a frontend in addition to command line. Thanks so much, Jordan On 9/15/07, Ralf Gross wrote: > > Jordan Mendler schrieb: > > > > 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. > > A very nice tool for backups is backuppc which stores all backed up > files in a pool and uses hardlinks to map these files to the real > backup. There is only one copy of each file in the pool regardless of > on how may clients this file exist (De-duplication). You can use > backuppc with tar/rsync/smb and with compression. > > Ralf > [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Sun Sep 16 19:40:54 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Sep 2007 19:40: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.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_64, J_CHICKENPOX_65,J_CHICKENPOX_66 autolearn=no 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 l8H2epuw026307 for ; Sun, 16 Sep 2007 19:40:53 -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 l8GC5NA5031752 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 16 Sep 2007 14:05:23 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8GC5NfG031750 for xfs@oss.sgi.com; Sun, 16 Sep 2007 14:05:23 +0200 Date: Sun, 16 Sep 2007 14:05:23 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: [PATCH] kill xfs_dm_fsops.c Message-ID: <20070916120523.GB31602@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: 12915 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 No point having a separate file for these few methods, especially if we want to merge the crufty ops vector into the dmapiops one day. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/dmapi/xfs_dm.c 2007-09-15 10:35:50.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c 2007-09-15 10:37:46.000000000 +0200 @@ -46,6 +46,7 @@ #include "xfs_attr.h" #include "xfs_attr_leaf.h" #include "xfs_inode_item.h" +#include "xfs_vfsops.h" #include "xfs_vnodeops.h" #include #include @@ -3071,9 +3072,10 @@ xfs_dm_obj_ref_hold( static fsys_function_vector_t xfs_fsys_vector[DM_FSYS_MAX]; -int -xfs_dm_get_fsys_vector( - caddr_t addr) +STATIC int +xfs_dm_get_dmapiops( + struct super_block *sb, + void *addr) { static int initialized = 0; dm_fcntl_vector_t *vecrq; @@ -3357,6 +3359,81 @@ xfs_dmops_t xfs_dmcore_xfs = { }; EXPORT_SYMBOL(xfs_dmcore_xfs); +STATIC const struct file_operations * +xfs_dm_get_invis_ops( + struct inode *ip) +{ + return &xfs_invis_file_operations; +} + +STATIC int +xfs_dm_fh_to_inode( + struct super_block *sb, + struct inode **ip, + dm_fid_t *dmfid) +{ + bhv_vnode_t *vp = NULL; + xfs_mount_t *mp = XFS_M(sb); + int error; + struct xfs_fid xfid; + + /* Returns negative errors to DMAPI */ + + *ip = NULL; + memcpy(&xfid, dmfid, sizeof(*dmfid)); + if (xfid.fid_len) { /* file object handle */ + error = xfs_vget(mp, &vp, &xfid); + } + else { /* filesystem handle */ + error = xfs_root(mp, &vp); + } + if (vp && (error == 0)) + *ip = vn_to_inode(vp); + return -error; /* Return negative error to DMAPI */ +} + +STATIC int +xfs_dm_inode_to_fh( + struct inode *inode, + dm_fid_t *dmfid, + dm_fsid_t *dmfsid) +{ + xfs_inode_t *ip = XFS_I(inode); + int error; + struct xfs_fid xfid; + + /* Returns negative errors to DMAPI */ + + if (ip->i_mount->m_fixedfsid == NULL) + return -EINVAL; + error = xfs_fid2(ip, &xfid); + if (error) + return -error; /* Return negative error to DMAPI */ + + memcpy(dmfid, &xfid, sizeof(*dmfid)); + memcpy(dmfsid, ip->i_mount->m_fixedfsid, sizeof(*dmfsid)); + return 0; +} + +STATIC void +xfs_dm_get_fsid( + struct super_block *sb, + dm_fsid_t *fsid) +{ + memcpy(fsid, XFS_M(sb)->m_fixedfsid, sizeof(*fsid)); +} + +/* + * Filesystem operations accessed by the DMAPI core. + */ +static struct filesystem_dmapi_operations xfs_dmapiops = { + .get_fsys_vector = xfs_dm_get_dmapiops, + .fh_to_inode = xfs_dm_fh_to_inode, + .get_invis_ops = xfs_dm_get_invis_ops, + .inode_to_fh = xfs_dm_inode_to_fh, + .get_fsid = xfs_dm_get_fsid, +}; + static int __init xfs_dm_init(void) { Index: linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/dmapi/xfs_dm.h 2007-09-15 10:35:50.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.h 2007-09-15 10:36:07.000000000 +0200 @@ -18,9 +18,6 @@ #ifndef __XFS_DM_H__ #define __XFS_DM_H__ -extern int xfs_dm_get_fsys_vector(caddr_t); - extern struct file_system_type xfs_fs_type; -extern struct filesystem_dmapi_operations xfs_dmapiops; #endif /* __XFS_DM_H__ */ Index: linux-2.6-xfs/fs/xfs/dmapi/Makefile-linux-2.6 =================================================================== --- linux-2.6-xfs.orig/fs/xfs/dmapi/Makefile-linux-2.6 2007-09-15 10:35:50.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/dmapi/Makefile-linux-2.6 2007-09-15 10:36:07.000000000 +0200 @@ -25,5 +25,4 @@ endif obj-$(CONFIG_XFS_DMAPI) += xfs_dmapi.o -xfs_dmapi-y += xfs_dm_fsops.o \ - xfs_dm.o +xfs_dmapi-y += xfs_dm.o Index: linux-2.6-xfs/fs/xfs/dmapi/xfs_dm_fsops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/dmapi/xfs_dm_fsops.c 2007-09-15 10:36:19.000000000 +0200 +++ /dev/null 1970-01-01 00:00:00.000000000 +0000 @@ -1,135 +0,0 @@ -/* - * Copyright (c) 2000-2006 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 "xfs.h" -#include "xfs_fs.h" -#include "xfs_types.h" -#include "xfs_bit.h" -#include "xfs_log.h" -#include "xfs_inum.h" -#include "xfs_clnt.h" -#include "xfs_trans.h" -#include "xfs_sb.h" -#include "xfs_ag.h" -#include "xfs_dir2.h" -#include "xfs_alloc.h" -#include "xfs_dmapi.h" -#include "xfs_mount.h" -#include "xfs_bmap_btree.h" -#include "xfs_alloc_btree.h" -#include "xfs_ialloc_btree.h" -#include "xfs_dir2_sf.h" -#include "xfs_attr_sf.h" -#include "xfs_dinode.h" -#include "xfs_inode.h" -#include "xfs_btree.h" -#include "xfs_ialloc.h" -#include "xfs_itable.h" -#include "xfs_bmap.h" -#include "xfs_rw.h" -#include "xfs_acl.h" -#include "xfs_attr.h" -#include "xfs_inode_item.h" -#include "xfs_vnodeops.h" -#include "xfs_vfsops.h" -#include -#include -#include "xfs_dm.h" - - -STATIC const struct file_operations * -xfs_dm_get_invis_ops( - struct inode *ip) -{ - return &xfs_invis_file_operations; -} - -STATIC int -xfs_dm_fh_to_inode( - struct super_block *sb, - struct inode **ip, - dm_fid_t *dmfid) -{ - bhv_vnode_t *vp = NULL; - xfs_mount_t *mp = XFS_M(sb); - int error; - struct xfs_fid xfid; - - /* Returns negative errors to DMAPI */ - - *ip = NULL; - memcpy(&xfid, dmfid, sizeof(*dmfid)); - if (xfid.fid_len) { /* file object handle */ - error = xfs_vget(mp, &vp, &xfid); - } - else { /* filesystem handle */ - error = xfs_root(mp, &vp); - } - if (vp && (error == 0)) - *ip = vn_to_inode(vp); - return -error; /* Return negative error to DMAPI */ -} - -STATIC int -xfs_dm_inode_to_fh( - struct inode *inode, - dm_fid_t *dmfid, - dm_fsid_t *dmfsid) -{ - xfs_inode_t *ip = XFS_I(inode); - int error; - struct xfs_fid xfid; - - /* Returns negative errors to DMAPI */ - - if (ip->i_mount->m_fixedfsid == NULL) - return -EINVAL; - error = xfs_fid2(ip, &xfid); - if (error) - return -error; /* Return negative error to DMAPI */ - - memcpy(dmfid, &xfid, sizeof(*dmfid)); - memcpy(dmfsid, ip->i_mount->m_fixedfsid, sizeof(*dmfsid)); - return 0; -} - -STATIC int -xfs_dm_get_dmapiops( - struct super_block *sb, - void *addr) -{ - return -xfs_dm_get_fsys_vector(addr); -} - -STATIC void -xfs_dm_get_fsid( - struct super_block *sb, - dm_fsid_t *fsid) -{ - memcpy(fsid, XFS_M(sb)->m_fixedfsid, sizeof(*fsid)); -} - -/* - * Filesystem operations accessed by the DMAPI core. - */ -struct filesystem_dmapi_operations xfs_dmapiops = { - .get_fsys_vector = xfs_dm_get_dmapiops, - .fh_to_inode = xfs_dm_fh_to_inode, - .get_invis_ops = xfs_dm_get_invis_ops, - .inode_to_fh = xfs_dm_inode_to_fh, - .get_fsid = xfs_dm_get_fsid, -}; From owner-xfs@oss.sgi.com Sun Sep 16 19:40:55 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Sep 2007 19:40: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.7 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 l8H2epv0026307 for ; Sun, 16 Sep 2007 19:40:54 -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 l8GC4YA5031717 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 16 Sep 2007 14:04:34 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8GC4XOj031713 for xfs@oss.sgi.com; Sun, 16 Sep 2007 14:04:33 +0200 Date: Sun, 16 Sep 2007 14:04:33 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: [PATCH] fix valid but harmless sparse warning in xfs_log_recovery.c Message-ID: <20070916120433.GA31602@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: 12914 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 The new xlog_recover_do_reg_buffer checks call be16_to_cpu on di_gen which is a 32bit value so sparse rightly complains. Fortunately the warning is harmless because we don't care for the value, but only whether it's non-NULL. Due to that fact we can simply kill the endian swaps on this and the previous di_mode check entirely. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/xfs_log_recover.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_log_recover.c 2007-09-16 12:57:25.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_log_recover.c 2007-09-16 12:57:38.000000000 +0200 @@ -1920,9 +1920,9 @@ xlog_recover_do_reg_buffer( stale_buf = 1; break; } - if (be16_to_cpu(dip->di_core.di_mode)) + if (dip->di_core.di_mode) mode_count++; - if (be16_to_cpu(dip->di_core.di_gen)) + if (dip->di_core.di_gen) gen_count++; } From owner-xfs@oss.sgi.com Sun Sep 16 19:47:25 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Sep 2007 19:47:28 -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,J_CHICKENPOX_45 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 l8H2lLuw027715 for ; Sun, 16 Sep 2007 19:47:24 -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 IAA09364 for ; Mon, 17 Sep 2007 08:32:59 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l8GMWwdD22573961 for ; Mon, 17 Sep 2007 08:32:59 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l8GMWvKR22618307 for linux-xfs@oss.sgi.com; Mon, 17 Sep 2007 08:32:57 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 17 Sep 2007 08:32:57 +1000 From: David Chinner To: linux-xfs@oss.sgi.com Subject: Re: can't remove dir Message-ID: <20070916223257.GI734179@sgi.com> References: <20070914080926.GA30150@apartia.fr> <20070914084125.GA31074@apartia.fr> <20070914091032.GE734179@sgi.com> <20070914092712.GA31997@apartia.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070914092712.GA31997@apartia.fr> User-Agent: Mutt/1.4.2.1i X-archive-position: 12916 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 14, 2007 at 11:27:21AM +0200, Louis-David Mitterrand wrote: > On Fri, Sep 14, 2007 at 07:10:32PM +1000, David Chinner wrote: > > BTW, what problem led you to running xfs_repair in the first > > place (i.e. what led to lost+found getting populated)? > > The infamous 2.6.17.1 corruption. Well, that explains it ;) http://oss.sgi.com/projects/xfs/faq.html#dir2 "To add insult to injury, xfs_repair(8) is currently not correcting these directories on detection of this corrupt state either. This xfs_repair issue is actively being worked on, and a fixed version will be available shortly. Update: a fixed xfs_repair is now available; version 2.8.10 or later of the xfsprogs package contains the fixed version." What version of xfs_repair are you using? (xfs_repair -V) Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sun Sep 16 19:49:57 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Sep 2007 19:50: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,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 l8H2nsuw028355 for ; Sun, 16 Sep 2007 19:49:57 -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 8667A18003EF4 for ; Sun, 16 Sep 2007 20:47:22 -0500 (CDT) Message-ID: <46EDDCA7.5030601@sandeen.net> Date: Sun, 16 Sep 2007 20:47:19 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: xfs-oss Subject: [PATCH] fix 32-bit compat ioctls for GETXFLAGS, SETXFLAGS, GETVERSION Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 12917 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 XFS_IOC_GETVERSION, XFS_IOC_GETXFLAGS and XFS_IOC_SETXFLAGS all take a "long" which changes size between 32 and 64 bit platforms. So, the ioctl cmds that come in from a 32-bit app aren't as expected, for example on GETXFLAGS, unknown cmd fd(3) cmd(80046601){t:'f';sz:4} due to the size mismatch. So, use instead the 32-bit version of the commands for compat ioctls, and other than that it doesn't take any more manipulation. Also, for both native and compat versions, just define them to the values as defined in fs.h Signed-off-by: Eric Sandeen Index: linux-2.6.22/fs/xfs/linux-2.6/xfs_ioctl32.c =================================================================== --- linux-2.6.22.orig/fs/xfs/linux-2.6/xfs_ioctl32.c +++ linux-2.6.22/fs/xfs/linux-2.6/xfs_ioctl32.c @@ -376,9 +376,6 @@ xfs_compat_ioctl( switch (cmd) { case XFS_IOC_DIOINFO: case XFS_IOC_FSGEOMETRY: - case XFS_IOC_GETVERSION: - case XFS_IOC_GETXFLAGS: - case XFS_IOC_SETXFLAGS: case XFS_IOC_FSGETXATTR: case XFS_IOC_FSSETXATTR: case XFS_IOC_FSGETXATTRA: @@ -404,6 +401,11 @@ xfs_compat_ioctl( case XFS_IOC_ERROR_CLEARALL: break; + case XFS_IOC32_GETXFLAGS: + case XFS_IOC32_SETXFLAGS: + case XFS_IOC32_GETVERSION: + cmd = _NATIVE_IOC(cmd, long); + break; #ifdef BROKEN_X86_ALIGNMENT /* xfs_flock_t has wrong u32 vs u64 alignment */ case XFS_IOC_ALLOCSP_32: Index: linux-2.6.22/fs/xfs/xfs_fs.h =================================================================== --- linux-2.6.22.orig/fs/xfs/xfs_fs.h +++ linux-2.6.22/fs/xfs/xfs_fs.h @@ -436,9 +436,13 @@ typedef struct xfs_handle { /* * ioctl commands that are used by Linux filesystems */ -#define XFS_IOC_GETXFLAGS _IOR('f', 1, long) -#define XFS_IOC_SETXFLAGS _IOW('f', 2, long) -#define XFS_IOC_GETVERSION _IOR('v', 1, long) +#define XFS_IOC_GETXFLAGS FS_IOC_GETFLAGS +#define XFS_IOC_SETXFLAGS FS_IOC_SETFLAGS +#define XFS_IOC_GETVERSION FS_IOC_GETVERSION +/* 32-bit compat counterparts */ +#define XFS_IOC32_GETXFLAGS FS_IOC32_GETFLAGS +#define XFS_IOC32_SETXFLAGS FS_IOC32_SETFLAGS +#define XFS_IOC32_GETVERSION FS_IOC32_GETVERSION /* * ioctl commands that replace IRIX fcntl()'s From owner-xfs@oss.sgi.com Sun Sep 16 19:58:31 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Sep 2007 19:58: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=-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 l8H2wQuw030178 for ; Sun, 16 Sep 2007 19:58:28 -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 l8H1NhKc005467; Mon, 17 Sep 2007 11:23:45 +1000 Received: (from lachlan@localhost) by redback.melbourne.sgi.com (8.13.8/8.13.8/Submit) id l8H1NgXX005466; Mon, 17 Sep 2007 11:23:42 +1000 Date: Mon, 17 Sep 2007 11:23:42 +1000 From: Lachlan McIlroy Message-Id: <200709170123.l8H1NgXX005466@redback.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 970335 - more vnode/inode tracing fixes X-archive-position: 12918 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 more vnode/inode tracing fixes Date: Mon Sep 17 11:20:10 AEST 2007 Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-xfs Inspected by: tes,sandeen@sandeen.net The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29697a fs/xfs/xfs_iget.c - 1.234 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iget.c.diff?r1=text&tr1=1.234&r2=text&tr2=1.233&f=h - more vnode/inode tracing fixes fs/xfs/linux-2.6/xfs_vnode.h - 1.141 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vnode.h.diff?r1=text&tr1=1.141&r2=text&tr2=1.140&f=h - more vnode/inode tracing fixes From owner-xfs@oss.sgi.com Sun Sep 16 23:31:20 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Sep 2007 23: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=-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 l8H6VHuw011558 for ; Sun, 16 Sep 2007 23:31:19 -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 QAA20082; Mon, 17 Sep 2007 16:31:13 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 5251358C4C09; Mon, 17 Sep 2007 16:31:13 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: PARTIAL TAKE 968563 - Kill unused IOMAP_EOF flag Message-Id: <20070917063113.5251358C4C09@chook.melbourne.sgi.com> Date: Mon, 17 Sep 2007 16:31:13 +1000 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 12919 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 Kill unused IOMAP_EOF flag Signed-off-by: Christoph Hellwig Date: Mon Sep 17 16:30:34 AEST 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/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:29705a fs/xfs/xfs_iomap.h - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iomap.h.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h - kill unused IOMAP_EOF flag fs/xfs/xfs_iomap.c - 1.57 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iomap.c.diff?r1=text&tr1=1.57&r2=text&tr2=1.56&f=h - kill unused IOMAP_EOF flag From owner-xfs@oss.sgi.com Mon Sep 17 07:15:08 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 17 Sep 2007 07:15: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=-0.9 required=5.0 tests=AWL,BAYES_50, RCVD_IN_DNSWL_MED,URI_NOVOWEL autolearn=ham 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 l8HEF5uw027006 for ; Mon, 17 Sep 2007 07:15:08 -0700 Received: from oplss0036.barcap.com (localhost [127.0.0.1]) by oplss0036.barcap.com (8.13.7/8.11.4) with ESMTP id l8HDurVP008156 for ; Mon, 17 Sep 2007 14:56:53 +0100 (BST) Received: from ldnpsmeg315.INTRANET.BARCAPINT.COM (ldnpsmeg315.nat.barcapint.com [172.23.3.10]) by oplss0036.barcap.com (8.13.7/8.11.4) with ESMTP id l8HDuraC008153; Mon, 17 Sep 2007 14:56:53 +0100 (BST) Received: from sgppsmeh001.INTRANET.BARCAPINT.COM (Not Verified[10.197.1.2]) by ldnpsmeg315.INTRANET.BARCAPINT.COM with Barclays Capital Filter ESMTP id ; Mon, 17 Sep 2007 15:15:05 +0100 Received: from SGPPCMEU302VEUA.INTRANET.BARCAPINT.COM ([10.197.1.44]) by sgppsmeh001.INTRANET.BARCAPINT.COM with Microsoft SMTPSVC(5.0.2195.6713); Mon, 17 Sep 2007 22:15:04 +0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: Configuring XFS on Redhat Linux Date: Mon, 17 Sep 2007 22:15:04 +0800 Message-ID: <53F49A183F99D94D9C84E062566A97E3037C6E4C@SGPPCMEU302VEUA.INTRANET.BARCAPINT.COM> In-reply-to: <46E94DEC.3090404@sandeen.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Configuring XFS on Redhat Linux Thread-Index: Acf2FXenjeQDrC5DS7mF81IZF0ud4QDHxpSg From: To: Cc: X-OriginalArrivalTime: 17 Sep 2007 14:15:04.0706 (UTC) FILETIME=[24AA1E20:01C7F935] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id l8HEF8uw027010 X-archive-position: 12922 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 Sandeen, Thank you very much for your mail. I am new to Linux Kernel Compilation. Could you please advise me the steps involved in enabling xfs filesystem on Linux version 2.6.9-22.Elsmp. I have googled and tried few methods, but I have failed to enable XFS, Infact my machine is not booting up after xfs module installation. Please help me. Kind Regards, kumaraswamy Namburu >Development Tools Team >http://devtoolswiki >* developmenttools >* General Team Hotline : 87731250 >* Direct : +65 68284827 >* Mobile : +65 91137662 Barclays Capital, Singapore. -----Original Message----- From: Eric Sandeen [mailto:sandeen@sandeen.net] Sent: 13 September 2007 22:49 To: Namburu, Kumaraswamy: IT (SGP) Cc: xfs@oss.sgi.com Subject: Re: Configuring XFS on Redhat Linux Kumaraswamy.Namburu@barclayscapital.com wrote: > 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. unless you really need cvs, how about http via kernel.org? or the git tree? http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs-2.6.git If you want xfs for your 2.6.9-22.ELsmp kernel, you might just grab the xfs kernel module packages & xfs userspace from the Centos distribution. Or, since it looks like you're using scientific linux and not actually RHEL, maybe just ask them. -Eric ------------------------------------------------------------------------ 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 Mon Sep 17 08:03:05 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 17 Sep 2007 08:03: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=-3.8 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 l8HF32uw002135 for ; Mon, 17 Sep 2007 08:03:05 -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 l8HF2qIA005310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Sep 2007 11:02:52 -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 l8HF2psn006423; Mon, 17 Sep 2007 11:02:51 -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 l8HF2obI029743; Mon, 17 Sep 2007 11:02:51 -0400 Message-ID: <46EE971A.2080302@sandeen.net> Date: Mon, 17 Sep 2007 10:02:50 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: Kumaraswamy.Namburu@barclayscapital.com CC: xfs@oss.sgi.com Subject: Re: Configuring XFS on Redhat Linux References: <53F49A183F99D94D9C84E062566A97E3037C6E4C@SGPPCMEU302VEUA.INTRANET.BARCAPINT.COM> In-Reply-To: <53F49A183F99D94D9C84E062566A97E3037C6E4C@SGPPCMEU302VEUA.INTRANET.BARCAPINT.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 12923 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 Kumaraswamy.Namburu@barclayscapital.com wrote: > > Hello Sandeen, > > Thank you very much for your mail. I am new to Linux Kernel > Compilation. Could you please advise me the steps involved in enabling > xfs filesystem on Linux version 2.6.9-22.Elsmp. I have googled and > tried few methods, but I have failed to enable XFS, Infact my machine is > not booting up after xfs module installation. Please help me. If you require xfs support for an enterprise-class Linux distribution and you are not comfortable compiling your own kernel code, I would suggest using something which already includes xfs support, such as SuSE's SLES10. Or, if you need xfs on RHEL, talk to Red Hat about that need. Otherwise I think I'd just be giving you enough rope to hang yourself. :) -Eric From owner-xfs@oss.sgi.com Mon Sep 17 10:36:04 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 17 Sep 2007 10:36:07 -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_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 l8HHa3uw029764 for ; Mon, 17 Sep 2007 10:36:04 -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 l8HHa41O013089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Sep 2007 13:36:04 -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 l8HHa3Nj015177; Mon, 17 Sep 2007 13:36:03 -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 l8HHa311000529; Mon, 17 Sep 2007 13:36:03 -0400 Message-ID: <46EEBB02.9050507@sandeen.net> Date: Mon, 17 Sep 2007 12:36:02 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: Eric Sandeen CC: xfs-oss Subject: [PATCH V2] fix 32-bit compat ioctls for GETXFLAGS, SETXFLAGS, GETVERSION References: <46EDDCA7.5030601@sandeen.net> In-Reply-To: <46EDDCA7.5030601@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 12925 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 (With rh bug info and attribution for the bug-finder) --------- In Red Hat bugzilla #291981, Sami Farin notes that 32-bit-compat lsattr/chattr does not work on xfs. After investigation, I found: XFS_IOC_GETVERSION, XFS_IOC_GETXFLAGS and XFS_IOC_SETXFLAGS all take a "long" which changes size between 32 and 64 bit platforms. So, the ioctl cmds that come in from a 32-bit app aren't as expected, for example on GETXFLAGS, unknown cmd fd(3) cmd(80046601){t:'f';sz:4} due to the size mismatch. So, use instead the 32-bit version of the commands for compat ioctls, and other than that it doesn't take any more manipulation. Also, for both native and compat versions, just define them to the values as defined in fs.h Signed-off-by: Eric Sandeen Index: linux-2.6.22/fs/xfs/linux-2.6/xfs_ioctl32.c =================================================================== --- linux-2.6.22.orig/fs/xfs/linux-2.6/xfs_ioctl32.c +++ linux-2.6.22/fs/xfs/linux-2.6/xfs_ioctl32.c @@ -376,9 +376,6 @@ xfs_compat_ioctl( switch (cmd) { case XFS_IOC_DIOINFO: case XFS_IOC_FSGEOMETRY: - case XFS_IOC_GETVERSION: - case XFS_IOC_GETXFLAGS: - case XFS_IOC_SETXFLAGS: case XFS_IOC_FSGETXATTR: case XFS_IOC_FSSETXATTR: case XFS_IOC_FSGETXATTRA: @@ -404,6 +401,11 @@ xfs_compat_ioctl( case XFS_IOC_ERROR_CLEARALL: break; + case XFS_IOC32_GETXFLAGS: + case XFS_IOC32_SETXFLAGS: + case XFS_IOC32_GETVERSION: + cmd = _NATIVE_IOC(cmd, long); + break; #ifdef BROKEN_X86_ALIGNMENT /* xfs_flock_t has wrong u32 vs u64 alignment */ case XFS_IOC_ALLOCSP_32: Index: linux-2.6.22/fs/xfs/xfs_fs.h =================================================================== --- linux-2.6.22.orig/fs/xfs/xfs_fs.h +++ linux-2.6.22/fs/xfs/xfs_fs.h @@ -436,9 +436,13 @@ typedef struct xfs_handle { /* * ioctl commands that are used by Linux filesystems */ -#define XFS_IOC_GETXFLAGS _IOR('f', 1, long) -#define XFS_IOC_SETXFLAGS _IOW('f', 2, long) -#define XFS_IOC_GETVERSION _IOR('v', 1, long) +#define XFS_IOC_GETXFLAGS FS_IOC_GETFLAGS +#define XFS_IOC_SETXFLAGS FS_IOC_SETFLAGS +#define XFS_IOC_GETVERSION FS_IOC_GETVERSION +/* 32-bit compat counterparts */ +#define XFS_IOC32_GETXFLAGS FS_IOC32_GETFLAGS +#define XFS_IOC32_SETXFLAGS FS_IOC32_SETFLAGS +#define XFS_IOC32_GETVERSION FS_IOC32_GETVERSION /* * ioctl commands that replace IRIX fcntl()'s From owner-xfs@oss.sgi.com Mon Sep 17 11:26:55 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 17 Sep 2007 11:27:00 -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 l8HIQsuw005220 for ; Mon, 17 Sep 2007 11:26:55 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1IXL1g-00070c-2c; Mon, 17 Sep 2007 19:08:52 +0100 Date: Mon, 17 Sep 2007 19:08:52 +0100 From: Christoph Hellwig To: Eric Sandeen Cc: xfs-oss Subject: Re: [PATCH V2] fix 32-bit compat ioctls for GETXFLAGS, SETXFLAGS, GETVERSION Message-ID: <20070917180851.GA26874@infradead.org> References: <46EDDCA7.5030601@sandeen.net> <46EEBB02.9050507@sandeen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46EEBB02.9050507@sandeen.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: 12926 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 17, 2007 at 12:36:02PM -0500, Eric Sandeen wrote: > Also, for both native and compat versions, just define them to > the values as defined in fs.h Should we just kill the XFS_ variants? Otherwise the patch looks good. From owner-xfs@oss.sgi.com Mon Sep 17 11:33:00 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 17 Sep 2007 11: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=-4.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 l8HIWwuw006299 for ; Mon, 17 Sep 2007 11:33:00 -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 l8HIWtSU012876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Sep 2007 14:32:55 -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 l8HIWtPt012513; Mon, 17 Sep 2007 14:32:55 -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 l8HIWsQN013746; Mon, 17 Sep 2007 14:32:55 -0400 Message-ID: <46EEC855.7010101@sandeen.net> Date: Mon, 17 Sep 2007 13:32:53 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs-oss Subject: Re: [PATCH V2] fix 32-bit compat ioctls for GETXFLAGS, SETXFLAGS, GETVERSION References: <46EDDCA7.5030601@sandeen.net> <46EEBB02.9050507@sandeen.net> <20070917180851.GA26874@infradead.org> In-Reply-To: <20070917180851.GA26874@infradead.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 12927 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 Mon, Sep 17, 2007 at 12:36:02PM -0500, Eric Sandeen wrote: >> Also, for both native and compat versions, just define them to >> the values as defined in fs.h > > Should we just kill the XFS_ variants? > > Otherwise the patch looks good. > perhaps. It looks like ext3 tried to move GETVERSION, too, though generic kernel variant still uses the "old" one. -Eric From owner-xfs@oss.sgi.com Mon Sep 17 19:24:29 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 17 Sep 2007 19:24: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.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 l8I2OLuw017322 for ; Mon, 17 Sep 2007 19:24:27 -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 MAA23200; Tue, 18 Sep 2007 12:24:18 +1000 Date: Tue, 18 Sep 2007 12:27:57 +1000 To: "Mark Goodall" , xfs@oss.sgi.com Subject: Re: Bug Report From: "Barry Naujok" Organization: SGI 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 l8I2OTuw017337 X-archive-position: 12932 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? > > - 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 Latest xfsprogs 2.9.4 doesn't segfault anymore in Phase 6. The "corrupt dinode..." error is a symptom of running xfs_repair in -n mode where Phase 3 would have fixed the offending inode up: -n mode: bad attribute format 0 in inode 25809974, would reset value bad anextents 16 for inode 25809974, would reset to 0 repair mode: bad attribute format 0 in inode 25809974, resetting value correcting anextents for inode 25809974, was 16 - counted 0 Regards, Barry. From owner-xfs@oss.sgi.com Mon Sep 17 19:48:03 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 17 Sep 2007 19:48:07 -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 ns1.hosting101.biz (NS1.hosting101.biz [72.232.98.98]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8I2m1uw021253 for ; Mon, 17 Sep 2007 19:48:03 -0700 Received: from [127.0.0.1] (helo=gualaceo.com) by ns1.hosting101.biz with esmtpa (Exim 4.68) (envelope-from ) id 1IXRI8-0006RH-Ln; Mon, 17 Sep 2007 20:50:16 -0400 Received: from 41.219.220.102 ([41.219.220.102]) (SquirrelMail authenticated user ss@gualaceo.com) by gualaceo.com with HTTP; Mon, 17 Sep 2007 20:50:16 -0400 (EDT) Message-ID: <4132.41.219.220.102.1190076616.squirrel@gualaceo.com> Date: Mon, 17 Sep 2007 20:50:16 -0400 (EDT) Subject: Job Opportunity From: "House of Bliss Art Gallery." Reply-To: Brian96walter@yahoo.com User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns1.hosting101.biz X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - houseofbliss.com X-Source: X-Source-Args: X-Source-Dir: To: undisclosed-recipients:; X-archive-position: 12933 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Do_Not_Reply@houseofbliss.com Precedence: bulk X-list: xfs HOUSE OF BLISS ART GALLERY 2753 Jay dr, Longview, Texas 75604 United State of America. http://www.houseofbliss.com Private email: Brian96walter@yahoo.com This is the House of Bliss Industry. We want to know if you would like to work for the house of bliss gallery and get paid without affecting your present job? Actually we need a representative who can be working for our company. We make lots of supplies to some of our clients in the UK for which we do come to the UK to receive payment and have it cashed after we supply them goods. Its always too expensive and stressful for us to come to the UK and receive such payment twice in a month so we therefore decided to contact you. We are willing to pay you 10% for every payment received by you from our clients who makes payment through you. Just in case you are concerned about how we got to your contact, it was through the UK Chamber of Commerce for trust worthy individuals, we were directed on how to make an online search. Kindly get back to us as soon as possible if you are interested in this job offer with your: First Name:................ .......................... Middle Name:.......................................... Last Name:............................................ Address Line 1....................................... Address Line 2........................................ City.................................................. State................................................. Zip................................................... Home Phone............................................ Cell Phone............................................ Gender................................................ Marital Status........................................ Age................................................... Nation of Origin...................................... Current job........................................... PLS SEND REPLY ASAP TO: Brian96walter@yahoo.com ATTESTATION According to how you have been briefed earlier by a qualified representative of this establishment. You are required and mandated to receive payment on behalf of the above mentioned firm. You are to deduct 10% of all funds processed on a particular order and forward the balance payment via Western Union Money Transfer to any of "HOUSE OF BLISS ART GALLERY" Group which you will be given. From owner-xfs@oss.sgi.com Mon Sep 17 20:02:28 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 17 Sep 2007 20:02: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.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43, J_CHICKENPOX_44,J_CHICKENPOX_45,J_CHICKENPOX_46,J_CHICKENPOX_47, J_CHICKENPOX_48 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 l8I32Muw023089 for ; Mon, 17 Sep 2007 20:02:27 -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 MAA23703; Tue, 18 Sep 2007 12:39:20 +1000 Date: Tue, 18 Sep 2007 12:43:05 +1000 To: "Louis-David Mitterrand" , linux-xfs@oss.sgi.com Subject: Re: can't remove dir From: "Barry Naujok" Organization: SGI Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: <20070914080926.GA30150@apartia.fr> <20070914084125.GA31074@apartia.fr> <20070914091032.GE734179@sgi.com> <20070914092712.GA31997@apartia.fr> Message-ID: In-Reply-To: <20070914092712.GA31997@apartia.fr> User-Agent: Opera Mail/9.10 (Win32) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by oss.sgi.com id l8I32Tuw023096 X-archive-position: 12934 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, 14 Sep 2007 19:27:21 +1000, Louis-David Mitterrand wrote: > On Fri, Sep 14, 2007 at 07:10:32PM +1000, David Chinner wrote: >> >> Also, get the inode number of the bad directory (ls -i) and then >> run: >> >> # xfs_db -r -c "inode " -c "p" > > sylla:/lost+found# xfs_db -r -c "inode 1879629858" -c "p" /dev/md1 > core.magic = 0x494e > core.mode = 040755 > core.version = 1 > core.format = 2 (extents) > core.nlinkv1 = 2 > core.uid = 0 > core.gid = 0 > core.flushiter = 9 > core.atime.sec = Tue Aug 1 20:49:16 2006 > core.atime.nsec = 000000000 > core.mtime.sec = Fri Sep 14 09:25:29 2007 > core.mtime.nsec = 589593557 > core.ctime.sec = Fri Sep 14 09:25:29 2007 > core.ctime.nsec = 589593557 > core.size = 8192 > core.nblocks = 3 > core.extsize = 0 > core.nextents = 2 > core.naextents = 0 > core.forkoff = 0 > core.aformat = 2 (extents) > core.dmevmask = 0 > core.dmstate = 0 > core.newrtbm = 0 > core.prealloc = 0 > core.realtime = 0 > core.immutable = 0 > core.append = 0 > core.sync = 0 > core.noatime = 0 > core.nodump = 0 > core.rtinherit = 0 > core.projinherit = 0 > core.nosymlinks = 0 > core.extsz = 0 > core.extszinherit = 0 > core.nodefrag = 0 > core.gen = 0 > next_unlinked = null > u.bmx[0-1] = [startoff,startblock,blockcount,extentflag] > 0:[0,117476868,2,0] 1:[8388608,125865476,1,0] > If you still have the bad directory, can you run these as well? # xfs_db -r -c "inode 1879629858" -c "dblock 0" -c "p" /dev/md1 # xfs_db -r -c "inode 1879629858" -c "dblock 1" -c "p" /dev/md1 # xfs_db -r -c "inode 1879629858" -c "dblock 8388608" -c "p" /dev/md1 Thanks, Barry. From owner-xfs@oss.sgi.com Wed Sep 19 08:33:43 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Sep 2007 08:34:07 -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 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 l8JFXbv0030965 for ; Wed, 19 Sep 2007 08:33:42 -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 l8JB3JA5003772 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 19 Sep 2007 13:03:19 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8JB3Ird003770; Wed, 19 Sep 2007 13:03:18 +0200 Date: Wed, 19 Sep 2007 13:03:18 +0200 From: Christoph Hellwig To: Lachlan McIlroy Cc: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: [PATCH 1/2] kill unnessecary ioops indirection Message-ID: <20070919110318.GA3703@lst.de> References: <20070914162802.GE7110@lst.de> <46EF661C.4030500@sgi.com> <20070918192327.GA24369@lst.de> <46F07E79.8090605@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46F07E79.8090605@sgi.com> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 12943 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 Wed, Sep 19, 2007 at 11:42:17AM +1000, Lachlan McIlroy wrote: > >vn_to_inode()/vn_from_inode() are no-ops nowdays, btw. > Yeah I know - that's why I'd like to get rid of them. They make the > code ugly and give the impression we need to work with two different > objects. There's lots of places where we declare an extra pointer on > the stack when we don't need to. Anyway that's fodder for another > patch, this patch looks good now. Yes, eventually we should get rid of them. I have a patch for the functions prototypes in xfs_vnodeops.h somewhere, and fixing the dmapi interface to avoid vnodes is also high on my todo list. From owner-xfs@oss.sgi.com Wed Sep 19 08:33:42 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Sep 2007 08:34: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.8 required=5.0 tests=AWL,BAYES_00 autolearn=unavailable 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 l8JFXbuw030965 for ; Wed, 19 Sep 2007 08:33:41 -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 l8JB4dA5003826 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 19 Sep 2007 13:04:39 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8JB4dDZ003824; Wed, 19 Sep 2007 13:04:39 +0200 Date: Wed, 19 Sep 2007 13:04:38 +0200 From: Christoph Hellwig To: Lachlan McIlroy Cc: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: [PATCH 3/4] simplify xfs_vn_getattr Message-ID: <20070919110438.GB3703@lst.de> References: <20070914162757.GD7110@lst.de> <46F08F98.9070102@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46F08F98.9070102@sgi.com> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 12944 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 Wed, Sep 19, 2007 at 12:55:20PM +1000, Lachlan McIlroy wrote: > Why do we copy the atime from the inode and not the xfs_inode? > > I think I see what's the deal here - the atime in the inode is > the authoritative atime. It gets updated from various places and > we synchronise it to the xfs inode before flushing the xfs inode > to disk. This means we shouldn't be using the atime in the > xfs_inode because it will be stale - is this correct? Yes. atime is updated by the vfs without callouts to the filesystem in various places unfortunately. From owner-xfs@oss.sgi.com Wed Sep 19 08:47:49 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Sep 2007 08:47: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.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 l8JFlQv6001339 for ; Wed, 19 Sep 2007 08:47:47 -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 UAA03697; Tue, 18 Sep 2007 20:39:21 +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 l8IAdIdD26549909; Tue, 18 Sep 2007 20:39:19 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l8IAdGGC26466774; Tue, 18 Sep 2007 20:39:16 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 18 Sep 2007 20:39:16 +1000 From: David Chinner To: Christoph Hellwig , David Chinner , Justin Piszcz , linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: 2.6.20 (XFS? related) crash after uptime of > 180 days during apt-get dist-upgrade on Debian Testing Message-ID: <20070918103916.GV23367404@sgi.com> References: <20070918014537.GK23367404@sgi.com> <20070918092013.GA1352@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070918092013.GA1352@infradead.org> User-Agent: Mutt/1.4.2.1i X-archive-position: 12949 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 18, 2007 at 10:20:13AM +0100, Christoph Hellwig wrote: > On Tue, Sep 18, 2007 at 11:45:37AM +1000, David Chinner wrote: > > No idea - it looks like dkpg was trying to remove a directory on the > > same path the lookup was and both have gone splat in __d_lookup on > > the same dentry. Something happened in those 180 days that left a > > landmine that was tripped over here, I think. I can't see any way of > > tracking it down from this, but thanks for reporting it anyway, > > This looks a lot like the i_sem leak that Vlad debugged. Do you remember > where this was fixed? The i_sem leak was hitting us on sles9 - 2.6.5 base kernel - and it was fixed before the i_sem -> i_mutex conversion in mainline. Some time around 2.6.16, IIRC. Given this was a 2.6.20 kernel, there'd be an almighty kaboom if that bug still existed after the i_mutex conversion.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Sep 19 08:47:36 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Sep 2007 08:47: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.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 l8JFlQv0001339 for ; Wed, 19 Sep 2007 08:47:34 -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 MAA27329; Wed, 19 Sep 2007 12:17:06 +1000 Message-ID: <46F0876A.5090809@sgi.com> Date: Wed, 19 Sep 2007 12:20:26 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH 2/4] simplify vn_revalidate References: <20070914162752.GC7110@lst.de> In-Reply-To: <20070914162752.GC7110@lst.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 12946 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 Anyone know why we don't copy the atime across? Should we be marking the inode dirty at the end of vn_revalidate()? Christoph Hellwig wrote: > No need to allocate a bhv_vattr_t on stack and call xfs_getattr to > update a few fields in the Linux inode from the XFS inode, just > do it directly. > > And yes, this function is in dire need of a better name and prototype, > I'll do in a separate patch, though. Good to know, thanks. > > > Signed-off-by: Christoph Hellwig > > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ioctl.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ioctl.c 2007-09-06 10:18:02.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ioctl.c 2007-09-06 10:26:33.000000000 +0200 > @@ -1217,7 +1217,7 @@ xfs_ioc_xattr( > > error = xfs_setattr(ip, vattr, attr_flags, NULL); > if (likely(!error)) > - __vn_revalidate(vp, vattr); /* update flags */ > + vn_revalidate(vp); /* update flags */ > error = -error; > break; > } > @@ -1273,7 +1273,7 @@ xfs_ioc_xattr( > > error = xfs_setattr(ip, vattr, attr_flags, NULL); > if (likely(!error)) > - __vn_revalidate(vp, vattr); /* update flags */ > + vn_revalidate(vp); /* update flags */ > error = -error; > break; > } > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_iops.c 2007-09-06 10:25:54.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c 2007-09-06 10:26:33.000000000 +0200 > @@ -645,7 +645,7 @@ xfs_vn_setattr( > > error = xfs_setattr(XFS_I(inode), &vattr, flags, NULL); > if (likely(!error)) > - __vn_revalidate(vn_from_inode(inode), &vattr); > + vn_revalidate(vn_from_inode(inode)); > return -error; > } > > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ksyms.c 2007-09-06 10:18:00.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c 2007-09-06 10:26:33.000000000 +0200 > @@ -183,7 +183,6 @@ EXPORT_SYMBOL(uuid_table_remove); > EXPORT_SYMBOL(vn_hold); > EXPORT_SYMBOL(vn_initialize); > EXPORT_SYMBOL(vn_revalidate); > -EXPORT_SYMBOL(vn_revalidate_core); > > #if defined(CONFIG_XFS_POSIX_ACL) > EXPORT_SYMBOL(xfs_acl_vtoacl); > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_vnode.c 2007-09-06 10:18:00.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.c 2007-09-06 10:38:40.000000000 +0200 > @@ -97,69 +97,57 @@ vn_initialize( > } > > /* > - * Revalidate the Linux inode from the vattr. > + * Revalidate the Linux inode from the XFS inode. > * Note: i_size _not_ updated; we must hold the inode > * semaphore when doing that - callers responsibility. > */ > -void > -vn_revalidate_core( > - bhv_vnode_t *vp, > - bhv_vattr_t *vap) > -{ > - struct inode *inode = vn_to_inode(vp); > - > - inode->i_mode = vap->va_mode; > - inode->i_nlink = vap->va_nlink; > - inode->i_uid = vap->va_uid; > - inode->i_gid = vap->va_gid; > - inode->i_blocks = vap->va_nblocks; > - inode->i_mtime = vap->va_mtime; > - inode->i_ctime = vap->va_ctime; > - if (vap->va_xflags & XFS_XFLAG_IMMUTABLE) > +int > +vn_revalidate( > + bhv_vnode_t *vp) > +{ > + struct inode *inode = vn_to_inode(vp); > + struct xfs_inode *ip = XFS_I(inode); > + struct xfs_mount *mp = ip->i_mount; > + unsigned long xflags; > + > + xfs_itrace_entry(ip); > + > + if (XFS_FORCED_SHUTDOWN(mp)) > + return -EIO; > + > + xfs_ilock(ip, XFS_ILOCK_SHARED); > + inode->i_mode = ip->i_d.di_mode; > + inode->i_nlink = ip->i_d.di_nlink; > + inode->i_uid = ip->i_d.di_uid; > + inode->i_gid = ip->i_d.di_gid; > + inode->i_blocks = > + XFS_FSB_TO_BB(mp, ip->i_d.di_nblocks + ip->i_delayed_blks); > + inode->i_mtime.tv_sec = ip->i_d.di_mtime.t_sec; > + inode->i_mtime.tv_nsec = ip->i_d.di_mtime.t_nsec; > + inode->i_ctime.tv_sec = ip->i_d.di_ctime.t_sec; > + inode->i_ctime.tv_nsec = ip->i_d.di_ctime.t_nsec; > + > + xflags = xfs_ip2xflags(ip); > + if (xflags & XFS_XFLAG_IMMUTABLE) > inode->i_flags |= S_IMMUTABLE; > else > inode->i_flags &= ~S_IMMUTABLE; > - if (vap->va_xflags & XFS_XFLAG_APPEND) > + if (xflags & XFS_XFLAG_APPEND) > inode->i_flags |= S_APPEND; > else > inode->i_flags &= ~S_APPEND; > - if (vap->va_xflags & XFS_XFLAG_SYNC) > + if (xflags & XFS_XFLAG_SYNC) > inode->i_flags |= S_SYNC; > else > inode->i_flags &= ~S_SYNC; > - if (vap->va_xflags & XFS_XFLAG_NOATIME) > + if (xflags & XFS_XFLAG_NOATIME) > inode->i_flags |= S_NOATIME; > else > inode->i_flags &= ~S_NOATIME; > -} > - > -/* > - * Revalidate the Linux inode from the vnode. > - */ > -int > -__vn_revalidate( > - bhv_vnode_t *vp, > - bhv_vattr_t *vattr) > -{ > - int error; > - > - xfs_itrace_entry(xfs_vtoi(vp)); > - vattr->va_mask = XFS_AT_STAT | XFS_AT_XFLAGS; > - error = xfs_getattr(xfs_vtoi(vp), vattr, 0); > - if (likely(!error)) { > - vn_revalidate_core(vp, vattr); > - xfs_iflags_clear(xfs_vtoi(vp), XFS_IMODIFIED); > - } > - return -error; > -} > - > -int > -vn_revalidate( > - bhv_vnode_t *vp) > -{ > - bhv_vattr_t vattr; > + xfs_iunlock(ip, XFS_ILOCK_SHARED); > > - return __vn_revalidate(vp, &vattr); > + xfs_iflags_clear(ip, XFS_IMODIFIED); > + return 0; > } > > /* > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.h > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_vnode.h 2007-09-06 10:18:50.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.h 2007-09-06 10:26:33.000000000 +0200 > @@ -189,8 +189,6 @@ typedef struct bhv_vattr { > extern void vn_init(void); > extern bhv_vnode_t *vn_initialize(struct inode *); > extern int vn_revalidate(bhv_vnode_t *); > -extern int __vn_revalidate(bhv_vnode_t *, bhv_vattr_t *); > -extern void vn_revalidate_core(bhv_vnode_t *, bhv_vattr_t *); > > /* > * Yeah, these don't take vnode anymore at all, all this should be > > > From owner-xfs@oss.sgi.com Wed Sep 19 08:47:39 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Sep 2007 08:47: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=-2.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_52, J_CHICKENPOX_65 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 l8JFlQv2001339 for ; Wed, 19 Sep 2007 08:47:37 -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 LAA26440; Wed, 19 Sep 2007 11:38:57 +1000 Message-ID: <46F07E79.8090605@sgi.com> Date: Wed, 19 Sep 2007 11:42:17 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH 1/2] kill unnessecary ioops indirection References: <20070914162802.GE7110@lst.de> <46EF661C.4030500@sgi.com> <20070918192327.GA24369@lst.de> In-Reply-To: <20070918192327.GA24369@lst.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 12947 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 Christoph Hellwig wrote: >>> STATIC int /* error (positive) */ >>> xfs_zero_last_block( >>> - struct inode *ip, >>> - xfs_iocore_t *io, >>> + struct inode *inode, >>> + xfs_inode_t *ip, >> We don't really need to pass both the inode and xfs_inode >> since it's easy to get one from the other. It was a trivial >> exercise to get the iocore from the inode too so it's not a >> problem with this change but should be cleaned up. > > Yeah, and when doing this change a lot more similar cleanups to > get rid of xfs_inode and vnode fall out automatically. I've > incorporated those bits into the next version. Smashing, thanks. > >>> @@ -474,7 +474,8 @@ xfs_zero_eof( >>> xfs_off_t offset, /* starting I/O offset */ >>> xfs_fsize_t isize) /* current inode size */ >>> { >>> - struct inode *ip = vn_to_inode(vp); >>> + struct inode *inode = vn_to_inode(vp); >>> + xfs_inode_t *ip = XFS_I(inode); >> Can we change the prototype for xfs_zero_eof() to take an inode >> instead of the vp? They are the same object and vn_to_inode()/ >> vn_from_inode() are just a waste of cycles. Also kills another >> stack variable. > > I've changed to to an xfs_inode because that's what we want. > inode is only needed all the way up in xfs_iozero once. Oh that's even better, thanks. > > vn_to_inode()/vn_from_inode() are no-ops nowdays, btw. Yeah I know - that's why I'd like to get rid of them. They make the code ugly and give the impression we need to work with two different objects. There's lots of places where we declare an extra pointer on the stack when we don't need to. Anyway that's fodder for another patch, this patch looks good now. > >>> - error = XFS_SWAP_EXTENTS(mp, &ip->i_iocore, &tip->i_iocore, sxp); >>> + error = xfs_swap_extents(ip, ip, sxp); >> xfs_swap_extents(ip, tip, sxp); > > Oops, fixed. No idea why xfsqa didn't catch this. > > > And here's the updated patch: > > > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_lrw.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_lrw.c 2007-09-16 13:51:33.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_lrw.c 2007-09-18 16:44:27.000000000 +0200 > @@ -131,7 +131,7 @@ xfs_inval_cached_trace( > */ > STATIC int > xfs_iozero( > - struct inode *ip, /* inode */ > + struct xfs_inode *ip, /* inode */ > loff_t pos, /* offset in file */ > size_t count) /* size of data to zero */ > { > @@ -140,7 +140,7 @@ xfs_iozero( > struct address_space *mapping; > int status; > > - mapping = ip->i_mapping; > + mapping = ip->i_vnode->i_mapping; > do { > unsigned long index, offset; > > @@ -400,20 +400,19 @@ xfs_splice_write( > */ > STATIC int /* error (positive) */ > xfs_zero_last_block( > - struct inode *ip, > - xfs_iocore_t *io, > + xfs_inode_t *ip, > xfs_fsize_t offset, > xfs_fsize_t isize) > { > xfs_fileoff_t last_fsb; > - xfs_mount_t *mp = io->io_mount; > + xfs_mount_t *mp = ip->i_mount; > int nimaps; > int zero_offset; > int zero_len; > int error = 0; > xfs_bmbt_irec_t imap; > > - ASSERT(ismrlocked(io->io_lock, MR_UPDATE) != 0); > + ASSERT(ismrlocked(&ip->i_lock, MR_UPDATE) != 0); > > zero_offset = XFS_B_FSB_OFFSET(mp, isize); > if (zero_offset == 0) { > @@ -426,7 +425,7 @@ xfs_zero_last_block( > > last_fsb = XFS_B_TO_FSBT(mp, isize); > nimaps = 1; > - error = XFS_BMAPI(mp, NULL, io, last_fsb, 1, 0, NULL, 0, &imap, > + error = xfs_bmapi(NULL, ip, last_fsb, 1, 0, NULL, 0, &imap, > &nimaps, NULL, NULL); > if (error) { > return error; > @@ -444,14 +443,14 @@ xfs_zero_last_block( > * out sync. We need to drop the ilock while we do this so we > * don't deadlock when the buffer cache calls back to us. > */ > - XFS_IUNLOCK(mp, io, XFS_ILOCK_EXCL| XFS_EXTSIZE_RD); > + xfs_iunlock(ip, XFS_ILOCK_EXCL| XFS_EXTSIZE_RD); > > zero_len = mp->m_sb.sb_blocksize - zero_offset; > if (isize + zero_len > offset) > zero_len = offset - isize; > error = xfs_iozero(ip, isize, zero_len); > > - XFS_ILOCK(mp, io, XFS_ILOCK_EXCL|XFS_EXTSIZE_RD); > + xfs_ilock(ip, XFS_ILOCK_EXCL|XFS_EXTSIZE_RD); > ASSERT(error >= 0); > return error; > } > @@ -469,12 +468,11 @@ xfs_zero_last_block( > > int /* error (positive) */ > xfs_zero_eof( > - bhv_vnode_t *vp, > - xfs_iocore_t *io, > + xfs_inode_t *ip, > xfs_off_t offset, /* starting I/O offset */ > xfs_fsize_t isize) /* current inode size */ > { > - struct inode *ip = vn_to_inode(vp); > + xfs_iocore_t *io = &ip->i_iocore; > xfs_fileoff_t start_zero_fsb; > xfs_fileoff_t end_zero_fsb; > xfs_fileoff_t zero_count_fsb; > @@ -494,7 +492,7 @@ xfs_zero_eof( > * First handle zeroing the block on which isize resides. > * We only zero a part of that block so it is handled specially. > */ > - error = xfs_zero_last_block(ip, io, offset, isize); > + error = xfs_zero_last_block(ip, offset, isize); > if (error) { > ASSERT(ismrlocked(io->io_lock, MR_UPDATE)); > ASSERT(ismrlocked(io->io_iolock, MR_UPDATE)); > @@ -525,7 +523,7 @@ xfs_zero_eof( > while (start_zero_fsb <= end_zero_fsb) { > nimaps = 1; > zero_count_fsb = end_zero_fsb - start_zero_fsb + 1; > - error = XFS_BMAPI(mp, NULL, io, start_zero_fsb, zero_count_fsb, > + error = xfs_bmapi(NULL, ip, start_zero_fsb, zero_count_fsb, > 0, NULL, 0, &imap, &nimaps, NULL, NULL); > if (error) { > ASSERT(ismrlocked(io->io_lock, MR_UPDATE)); > @@ -553,7 +551,7 @@ xfs_zero_eof( > * Drop the inode lock while we're doing the I/O. > * We'll still have the iolock to protect us. > */ > - XFS_IUNLOCK(mp, io, XFS_ILOCK_EXCL|XFS_EXTSIZE_RD); > + xfs_iunlock(ip, XFS_ILOCK_EXCL|XFS_EXTSIZE_RD); > > zero_off = XFS_FSB_TO_B(mp, start_zero_fsb); > zero_len = XFS_FSB_TO_B(mp, imap.br_blockcount); > @@ -569,14 +567,13 @@ xfs_zero_eof( > start_zero_fsb = imap.br_startoff + imap.br_blockcount; > ASSERT(start_zero_fsb <= (end_zero_fsb + 1)); > > - XFS_ILOCK(mp, io, XFS_ILOCK_EXCL|XFS_EXTSIZE_RD); > + xfs_ilock(ip, XFS_ILOCK_EXCL|XFS_EXTSIZE_RD); > } > > return 0; > > out_lock: > - > - XFS_ILOCK(mp, io, XFS_ILOCK_EXCL|XFS_EXTSIZE_RD); > + xfs_ilock(ip, XFS_ILOCK_EXCL|XFS_EXTSIZE_RD); > ASSERT(error >= 0); > return error; > } > @@ -717,7 +714,7 @@ start: > */ > > if (pos > xip->i_size) { > - error = xfs_zero_eof(vp, io, pos, xip->i_size); > + error = xfs_zero_eof(xip, pos, xip->i_size); > if (error) { > xfs_iunlock(xip, XFS_ILOCK_EXCL); > goto out_unlock_internal; > @@ -762,7 +759,7 @@ retry: > > if (need_i_mutex) { > /* demote the lock now the cached pages are gone */ > - XFS_ILOCK_DEMOTE(mp, io, XFS_IOLOCK_EXCL); > + xfs_ilock_demote(xip, XFS_IOLOCK_EXCL); > mutex_unlock(&inode->i_mutex); > > iolock = XFS_IOLOCK_SHARED; > @@ -905,25 +902,6 @@ xfs_bdstrat_cb(struct xfs_buf *bp) > } > } > > - > -int > -xfs_bmap( > - xfs_inode_t *ip, > - xfs_off_t offset, > - ssize_t count, > - int flags, > - xfs_iomap_t *iomapp, > - int *niomaps) > -{ > - xfs_iocore_t *io = &ip->i_iocore; > - > - ASSERT((ip->i_d.di_mode & S_IFMT) == S_IFREG); > - ASSERT(((ip->i_d.di_flags & XFS_DIFLAG_REALTIME) != 0) == > - ((ip->i_iocore.io_flags & XFS_IOCORE_RT) != 0)); > - > - return xfs_iomap(io, offset, count, flags, iomapp, niomaps); > -} > - > /* > * Wrapper around bdstrat so that we can stop data > * from going to disk in case we are shutting down the filesystem. > Index: linux-2.6-xfs/fs/xfs/xfs_iomap.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_iomap.c 2007-09-18 16:34:31.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_iomap.c 2007-09-18 16:37:22.000000000 +0200 > @@ -53,11 +53,11 @@ > void > xfs_iomap_enter_trace( > int tag, > - xfs_iocore_t *io, > + xfs_inode_t *ip, > xfs_off_t offset, > ssize_t count) > { > - xfs_inode_t *ip = XFS_IO_INODE(io); > + xfs_iocore_t *io = &ip->i_iocore; > > if (!ip->i_rwtrace) > return; > @@ -84,15 +84,13 @@ xfs_iomap_enter_trace( > void > xfs_iomap_map_trace( > int tag, > - xfs_iocore_t *io, > + xfs_inode_t *ip, > xfs_off_t offset, > ssize_t count, > xfs_iomap_t *iomapp, > xfs_bmbt_irec_t *imapp, > int flags) > { > - xfs_inode_t *ip = XFS_IO_INODE(io); > - > if (!ip->i_rwtrace) > return; > > @@ -126,7 +124,7 @@ xfs_iomap_map_trace( > > STATIC int > xfs_imap_to_bmap( > - xfs_iocore_t *io, > + xfs_inode_t *ip, > xfs_off_t offset, > xfs_bmbt_irec_t *imap, > xfs_iomap_t *iomapp, > @@ -134,11 +132,10 @@ xfs_imap_to_bmap( > int iomaps, /* Number of iomap entries */ > int flags) > { > - xfs_mount_t *mp; > + xfs_mount_t *mp = ip->i_mount; > int pbm; > xfs_fsblock_t start_block; > > - mp = io->io_mount; > > for (pbm = 0; imaps && pbm < iomaps; imaps--, iomapp++, imap++, pbm++) { > iomapp->iomap_offset = XFS_FSB_TO_B(mp, imap->br_startoff); > @@ -146,7 +143,7 @@ xfs_imap_to_bmap( > iomapp->iomap_bsize = XFS_FSB_TO_B(mp, imap->br_blockcount); > iomapp->iomap_flags = flags; > > - if (io->io_flags & XFS_IOCORE_RT) { > + if (ip->i_d.di_flags & XFS_DIFLAG_REALTIME) { > iomapp->iomap_flags |= IOMAP_REALTIME; > iomapp->iomap_target = mp->m_rtdev_targp; > } else { > @@ -160,7 +157,7 @@ xfs_imap_to_bmap( > iomapp->iomap_bn = IOMAP_DADDR_NULL; > iomapp->iomap_flags |= IOMAP_DELAY; > } else { > - iomapp->iomap_bn = XFS_FSB_TO_DB_IO(io, start_block); > + iomapp->iomap_bn = XFS_FSB_TO_DB(ip, start_block); > if (ISUNWRITTEN(imap)) > iomapp->iomap_flags |= IOMAP_UNWRITTEN; > } > @@ -172,14 +169,14 @@ xfs_imap_to_bmap( > > int > xfs_iomap( > - xfs_iocore_t *io, > + xfs_inode_t *ip, > xfs_off_t offset, > ssize_t count, > int flags, > xfs_iomap_t *iomapp, > int *niomaps) > { > - xfs_mount_t *mp = io->io_mount; > + xfs_mount_t *mp = ip->i_mount; > xfs_fileoff_t offset_fsb, end_fsb; > int error = 0; > int lockmode = 0; > @@ -188,32 +185,37 @@ xfs_iomap( > int bmapi_flags = 0; > int iomap_flags = 0; > > + ASSERT((ip->i_d.di_mode & S_IFMT) == S_IFREG); > + ASSERT(((ip->i_d.di_flags & XFS_DIFLAG_REALTIME) != 0) == > + ((ip->i_iocore.io_flags & XFS_IOCORE_RT) != 0)); > + > if (XFS_FORCED_SHUTDOWN(mp)) > return XFS_ERROR(EIO); > > 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); > + xfs_iomap_enter_trace(XFS_IOMAP_READ_ENTER, ip, offset, count); > + lockmode = xfs_ilock_map_shared(ip); > bmapi_flags = XFS_BMAPI_ENTIRE; > break; > case BMAPI_WRITE: > - xfs_iomap_enter_trace(XFS_IOMAP_WRITE_ENTER, io, offset, count); > + xfs_iomap_enter_trace(XFS_IOMAP_WRITE_ENTER, ip, offset, count); > lockmode = XFS_ILOCK_EXCL|XFS_EXTSIZE_WR; > if (flags & BMAPI_IGNSTATE) > bmapi_flags |= XFS_BMAPI_IGSTATE|XFS_BMAPI_ENTIRE; > - XFS_ILOCK(mp, io, lockmode); > + xfs_ilock(ip, lockmode); > break; > case BMAPI_ALLOCATE: > - xfs_iomap_enter_trace(XFS_IOMAP_ALLOC_ENTER, io, offset, count); > + xfs_iomap_enter_trace(XFS_IOMAP_ALLOC_ENTER, ip, offset, count); > lockmode = XFS_ILOCK_SHARED|XFS_EXTSIZE_RD; > bmapi_flags = XFS_BMAPI_ENTIRE; > + > /* Attempt non-blocking lock */ > if (flags & BMAPI_TRYLOCK) { > - if (!XFS_ILOCK_NOWAIT(mp, io, lockmode)) > + if (!xfs_ilock_nowait(ip, lockmode)) > return XFS_ERROR(EAGAIN); > } else { > - XFS_ILOCK(mp, io, lockmode); > + xfs_ilock(ip, lockmode); > } > break; > default: > @@ -226,7 +228,7 @@ xfs_iomap( > end_fsb = XFS_B_TO_FSB(mp, (xfs_ufsize_t)offset + count); > offset_fsb = XFS_B_TO_FSBT(mp, offset); > > - error = XFS_BMAPI(mp, NULL, io, offset_fsb, > + error = xfs_bmapi(NULL, ip, offset_fsb, > (xfs_filblks_t)(end_fsb - offset_fsb), > bmapi_flags, NULL, 0, &imap, > &nimaps, NULL, NULL); > @@ -240,42 +242,42 @@ xfs_iomap( > if (nimaps && > (imap.br_startblock != HOLESTARTBLOCK) && > (imap.br_startblock != DELAYSTARTBLOCK)) { > - xfs_iomap_map_trace(XFS_IOMAP_WRITE_MAP, io, > + xfs_iomap_map_trace(XFS_IOMAP_WRITE_MAP, ip, > offset, count, iomapp, &imap, flags); > break; > } > > if (flags & (BMAPI_DIRECT|BMAPI_MMAP)) { > - error = XFS_IOMAP_WRITE_DIRECT(mp, io, offset, > - count, flags, &imap, &nimaps, nimaps); > + error = xfs_iomap_write_direct(ip, offset, count, flags, > + &imap, &nimaps, nimaps); > } else { > - error = XFS_IOMAP_WRITE_DELAY(mp, io, offset, count, > - flags, &imap, &nimaps); > + error = xfs_iomap_write_delay(ip, offset, count, flags, > + &imap, &nimaps); > } > if (!error) { > - xfs_iomap_map_trace(XFS_IOMAP_ALLOC_MAP, io, > + xfs_iomap_map_trace(XFS_IOMAP_ALLOC_MAP, ip, > offset, count, iomapp, &imap, flags); > } > iomap_flags = IOMAP_NEW; > break; > case BMAPI_ALLOCATE: > /* If we found an extent, return it */ > - XFS_IUNLOCK(mp, io, lockmode); > + xfs_iunlock(ip, lockmode); > lockmode = 0; > > if (nimaps && !ISNULLSTARTBLOCK(imap.br_startblock)) { > - xfs_iomap_map_trace(XFS_IOMAP_WRITE_MAP, io, > + xfs_iomap_map_trace(XFS_IOMAP_WRITE_MAP, ip, > offset, count, iomapp, &imap, flags); > break; > } > > - error = XFS_IOMAP_WRITE_ALLOCATE(mp, io, offset, count, > + error = xfs_iomap_write_allocate(ip, offset, count, > &imap, &nimaps); > break; > } > > if (nimaps) { > - *niomaps = xfs_imap_to_bmap(io, offset, &imap, > + *niomaps = xfs_imap_to_bmap(ip, offset, &imap, > iomapp, nimaps, *niomaps, iomap_flags); > } else if (niomaps) { > *niomaps = 0; > @@ -283,14 +285,15 @@ xfs_iomap( > > out: > if (lockmode) > - XFS_IUNLOCK(mp, io, lockmode); > + xfs_iunlock(ip, lockmode); > return XFS_ERROR(error); > } > > + > STATIC int > xfs_iomap_eof_align_last_fsb( > xfs_mount_t *mp, > - xfs_iocore_t *io, > + xfs_inode_t *ip, > xfs_fsize_t isize, > xfs_extlen_t extsize, > xfs_fileoff_t *last_fsb) > @@ -299,7 +302,7 @@ xfs_iomap_eof_align_last_fsb( > xfs_extlen_t align; > int eof, error; > > - if (io->io_flags & XFS_IOCORE_RT) > + if (ip->i_d.di_flags & XFS_DIFLAG_REALTIME) > ; > /* > * If mounted with the "-o swalloc" option, roundup the allocation > @@ -330,7 +333,7 @@ xfs_iomap_eof_align_last_fsb( > } > > if (new_last_fsb) { > - error = XFS_BMAP_EOF(mp, io, new_last_fsb, XFS_DATA_FORK, &eof); > + error = xfs_bmap_eof(ip, new_last_fsb, XFS_DATA_FORK, &eof); > if (error) > return error; > if (eof) > @@ -435,7 +438,7 @@ xfs_iomap_write_direct( > offset_fsb = XFS_B_TO_FSBT(mp, offset); > last_fsb = XFS_B_TO_FSB(mp, ((xfs_ufsize_t)(offset + count))); > if ((offset + count) > isize) { > - error = xfs_iomap_eof_align_last_fsb(mp, io, isize, extsz, > + error = xfs_iomap_eof_align_last_fsb(mp, ip, isize, extsz, > &last_fsb); > if (error) > goto error_out; > @@ -502,7 +505,7 @@ xfs_iomap_write_direct( > */ > XFS_BMAP_INIT(&free_list, &firstfsb); > nimaps = 1; > - error = XFS_BMAPI(mp, tp, io, offset_fsb, count_fsb, bmapi_flag, > + error = xfs_bmapi(tp, ip, offset_fsb, count_fsb, bmapi_flag, > &firstfsb, 0, &imap, &nimaps, &free_list, NULL); > if (error) > goto error0; > @@ -560,7 +563,7 @@ error_out: > STATIC int > xfs_iomap_eof_want_preallocate( > xfs_mount_t *mp, > - xfs_iocore_t *io, > + xfs_inode_t *ip, > xfs_fsize_t isize, > xfs_off_t offset, > size_t count, > @@ -587,7 +590,7 @@ xfs_iomap_eof_want_preallocate( > while (count_fsb > 0) { > imaps = nimaps; > firstblock = NULLFSBLOCK; > - error = XFS_BMAPI(mp, NULL, io, start_fsb, count_fsb, 0, > + error = xfs_bmapi(NULL, ip, start_fsb, count_fsb, 0, > &firstblock, 0, imap, &imaps, NULL, NULL); > if (error) > return error; > @@ -644,7 +647,7 @@ retry: > if (io->io_new_size > isize) > isize = io->io_new_size; > > - error = xfs_iomap_eof_want_preallocate(mp, io, isize, offset, count, > + error = xfs_iomap_eof_want_preallocate(mp, ip, isize, offset, count, > ioflag, imap, XFS_WRITE_IMAPS, &prealloc); > if (error) > return error; > @@ -658,7 +661,7 @@ retry: > } > > if (prealloc || extsz) { > - error = xfs_iomap_eof_align_last_fsb(mp, io, isize, extsz, > + error = xfs_iomap_eof_align_last_fsb(mp, ip, isize, extsz, > &last_fsb); > if (error) > return error; > @@ -666,7 +669,7 @@ retry: > > nimaps = XFS_WRITE_IMAPS; > firstblock = NULLFSBLOCK; > - error = XFS_BMAPI(mp, NULL, io, offset_fsb, > + error = xfs_bmapi(NULL, ip, offset_fsb, > (xfs_filblks_t)(last_fsb - offset_fsb), > XFS_BMAPI_DELAY | XFS_BMAPI_WRITE | > XFS_BMAPI_ENTIRE, &firstblock, 1, imap, > @@ -680,7 +683,7 @@ retry: > */ > if (nimaps == 0) { > xfs_iomap_enter_trace(XFS_IOMAP_WRITE_NOSPACE, > - io, offset, count); > + ip, offset, count); > if (xfs_flush_space(ip, &fsynced, &ioflag)) > return XFS_ERROR(ENOSPC); > > @@ -788,7 +791,7 @@ xfs_iomap_write_allocate( > } > > /* Go get the actual blocks */ > - error = XFS_BMAPI(mp, tp, io, map_start_fsb, count_fsb, > + error = xfs_bmapi(tp, ip, map_start_fsb, count_fsb, > XFS_BMAPI_WRITE, &first_block, 1, > imap, &nimaps, &free_list, NULL); > if (error) > @@ -860,8 +863,7 @@ xfs_iomap_write_unwritten( > int committed; > int error; > > - xfs_iomap_enter_trace(XFS_IOMAP_UNWRITTEN, > - &ip->i_iocore, offset, count); > + xfs_iomap_enter_trace(XFS_IOMAP_UNWRITTEN, ip, offset, count); > > offset_fsb = XFS_B_TO_FSBT(mp, offset); > count_fsb = XFS_B_TO_FSB(mp, (xfs_ufsize_t)offset + count); > @@ -895,7 +897,7 @@ xfs_iomap_write_unwritten( > */ > XFS_BMAP_INIT(&free_list, &firstfsb); > nimaps = 1; > - error = XFS_BMAPI(mp, tp, io, offset_fsb, count_fsb, > + error = xfs_bmapi(tp, ip, offset_fsb, count_fsb, > XFS_BMAPI_WRITE|XFS_BMAPI_CONVERT, &firstfsb, > 1, &imap, &nimaps, &free_list, NULL); > if (error) > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ksyms.c 2007-09-16 13:51:33.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c 2007-09-18 16:37:22.000000000 +0200 > @@ -248,8 +248,6 @@ EXPORT_SYMBOL(xfs_ilock_nowait); > EXPORT_SYMBOL(xfs_inode_lock_init); > EXPORT_SYMBOL(xfs_internal_inum); > EXPORT_SYMBOL(xfs_iocore_inode_init); > -EXPORT_SYMBOL(xfs_iocore_xfs); > -EXPORT_SYMBOL(xfs_iomap); > EXPORT_SYMBOL(xfs_iput); > EXPORT_SYMBOL(xfs_iput_new); > EXPORT_SYMBOL(xfs_iread); > Index: linux-2.6-xfs/fs/xfs/xfs_dfrag.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_dfrag.c 2007-09-16 13:51:33.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_dfrag.c 2007-09-18 16:37:38.000000000 +0200 > @@ -111,7 +111,7 @@ xfs_swapext( > goto error0; > } > > - error = XFS_SWAP_EXTENTS(mp, &ip->i_iocore, &tip->i_iocore, sxp); > + error = xfs_swap_extents(ip, tip, sxp); > > error0: > if (fp != NULL) > Index: linux-2.6-xfs/fs/xfs/xfs_inode.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_inode.c 2007-09-16 13:51:33.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_inode.c 2007-09-18 16:43:12.000000000 +0200 > @@ -1709,7 +1709,7 @@ xfs_itruncate_finish( > * runs. > */ > XFS_BMAP_INIT(&free_list, &first_block); > - error = XFS_BUNMAPI(mp, ntp, &ip->i_iocore, > + error = xfs_bunmapi(ntp, ip, > first_unmap_block, unmap_len, > XFS_BMAPI_AFLAG(fork) | > (sync ? 0 : XFS_BMAPI_ASYNC), > @@ -1842,8 +1842,6 @@ xfs_igrow_start( > xfs_fsize_t new_size, > cred_t *credp) > { > - int error; > - > ASSERT(ismrlocked(&(ip->i_lock), MR_UPDATE) != 0); > ASSERT(ismrlocked(&(ip->i_iolock), MR_UPDATE) != 0); > ASSERT(new_size > ip->i_size); > @@ -1853,9 +1851,7 @@ xfs_igrow_start( > * xfs_write_file() beyond the end of the file > * and any blocks between the old and new file sizes. > */ > - error = xfs_zero_eof(XFS_ITOV(ip), &ip->i_iocore, new_size, > - ip->i_size); > - return error; > + return xfs_zero_eof(ip, new_size, ip->i_size); > } > > /* > Index: linux-2.6-xfs/fs/xfs/xfs_iocore.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_iocore.c 2007-09-16 13:51:33.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_iocore.c 2007-09-18 16:37:22.000000000 +0200 > @@ -47,46 +47,6 @@ > #include "xfs_trans_space.h" > #include "xfs_iomap.h" > > - > -STATIC xfs_fsize_t > -xfs_size_fn( > - xfs_inode_t *ip) > -{ > - return XFS_ISIZE(ip); > -} > - > -STATIC int > -xfs_ioinit( > - struct xfs_mount *mp, > - struct xfs_mount_args *mntargs, > - int flags) > -{ > - return xfs_mountfs(mp, flags); > -} > - > -xfs_ioops_t xfs_iocore_xfs = { > - .xfs_ioinit = (xfs_ioinit_t) xfs_ioinit, > - .xfs_bmapi_func = (xfs_bmapi_t) xfs_bmapi, > - .xfs_bunmapi_func = (xfs_bunmapi_t) xfs_bunmapi, > - .xfs_bmap_eof_func = (xfs_bmap_eof_t) xfs_bmap_eof, > - .xfs_iomap_write_direct = > - (xfs_iomap_write_direct_t) xfs_iomap_write_direct, > - .xfs_iomap_write_delay = > - (xfs_iomap_write_delay_t) xfs_iomap_write_delay, > - .xfs_iomap_write_allocate = > - (xfs_iomap_write_allocate_t) xfs_iomap_write_allocate, > - .xfs_iomap_write_unwritten = > - (xfs_iomap_write_unwritten_t) xfs_iomap_write_unwritten, > - .xfs_ilock = (xfs_lock_t) xfs_ilock, > - .xfs_lck_map_shared = (xfs_lck_map_shared_t) xfs_ilock_map_shared, > - .xfs_ilock_demote = (xfs_lock_demote_t) xfs_ilock_demote, > - .xfs_ilock_nowait = (xfs_lock_nowait_t) xfs_ilock_nowait, > - .xfs_unlock = (xfs_unlk_t) xfs_iunlock, > - .xfs_size_func = (xfs_size_t) xfs_size_fn, > - .xfs_iodone = (xfs_iodone_t) fs_noerr, > - .xfs_swap_extents_func = (xfs_swap_extents_t) xfs_swap_extents, > -}; > - > void > xfs_iocore_inode_reinit( > xfs_inode_t *ip) > Index: linux-2.6-xfs/fs/xfs/xfs_mount.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_mount.c 2007-09-18 16:34:38.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_mount.c 2007-09-18 16:36:30.000000000 +0200 > @@ -1307,7 +1307,6 @@ xfs_unmountfs(xfs_mount_t *mp, struct cr > #if defined(DEBUG) || defined(INDUCE_IO_ERROR) > xfs_errortag_clearall(mp, 0); > #endif > - XFS_IODONE(mp); > xfs_mount_free(mp); > return 0; > } > Index: linux-2.6-xfs/fs/xfs/xfs_mount.h > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_mount.h 2007-09-16 13:51:33.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_mount.h 2007-09-18 16:37:22.000000000 +0200 > @@ -196,105 +196,6 @@ typedef struct xfs_qmops { > #define XFS_QM_QUOTACTL(mp, cmd, id, addr) \ > (*(mp)->m_qm_ops->xfs_quotactl)(mp, cmd, id, addr) > > - > -/* > - * Prototypes and functions for I/O core modularization. > - */ > - > -typedef int (*xfs_ioinit_t)(struct xfs_mount *, > - struct xfs_mount_args *, int); > -typedef int (*xfs_bmapi_t)(struct xfs_trans *, void *, > - xfs_fileoff_t, xfs_filblks_t, int, > - xfs_fsblock_t *, xfs_extlen_t, > - struct xfs_bmbt_irec *, int *, > - struct xfs_bmap_free *, struct xfs_extdelta *); > -typedef int (*xfs_bunmapi_t)(struct xfs_trans *, > - void *, xfs_fileoff_t, > - xfs_filblks_t, int, xfs_extnum_t, > - xfs_fsblock_t *, struct xfs_bmap_free *, > - struct xfs_extdelta *, int *); > -typedef int (*xfs_bmap_eof_t)(void *, xfs_fileoff_t, int, int *); > -typedef int (*xfs_iomap_write_direct_t)( > - void *, xfs_off_t, size_t, int, > - struct xfs_bmbt_irec *, int *, int); > -typedef int (*xfs_iomap_write_delay_t)( > - void *, xfs_off_t, size_t, int, > - struct xfs_bmbt_irec *, int *); > -typedef int (*xfs_iomap_write_allocate_t)( > - void *, xfs_off_t, size_t, > - struct xfs_bmbt_irec *, int *); > -typedef int (*xfs_iomap_write_unwritten_t)( > - void *, xfs_off_t, size_t); > -typedef uint (*xfs_lck_map_shared_t)(void *); > -typedef void (*xfs_lock_t)(void *, uint); > -typedef void (*xfs_lock_demote_t)(void *, uint); > -typedef int (*xfs_lock_nowait_t)(void *, uint); > -typedef void (*xfs_unlk_t)(void *, unsigned int); > -typedef xfs_fsize_t (*xfs_size_t)(void *); > -typedef xfs_fsize_t (*xfs_iodone_t)(struct xfs_mount *); > -typedef int (*xfs_swap_extents_t)(void *, void *, > - struct xfs_swapext*); > - > -typedef struct xfs_ioops { > - xfs_ioinit_t xfs_ioinit; > - xfs_bmapi_t xfs_bmapi_func; > - xfs_bunmapi_t xfs_bunmapi_func; > - xfs_bmap_eof_t xfs_bmap_eof_func; > - xfs_iomap_write_direct_t xfs_iomap_write_direct; > - xfs_iomap_write_delay_t xfs_iomap_write_delay; > - xfs_iomap_write_allocate_t xfs_iomap_write_allocate; > - xfs_iomap_write_unwritten_t xfs_iomap_write_unwritten; > - xfs_lock_t xfs_ilock; > - xfs_lck_map_shared_t xfs_lck_map_shared; > - xfs_lock_demote_t xfs_ilock_demote; > - xfs_lock_nowait_t xfs_ilock_nowait; > - xfs_unlk_t xfs_unlock; > - xfs_size_t xfs_size_func; > - xfs_iodone_t xfs_iodone; > - xfs_swap_extents_t xfs_swap_extents_func; > -} xfs_ioops_t; > - > -#define XFS_IOINIT(mp, args, flags) \ > - (*(mp)->m_io_ops.xfs_ioinit)(mp, args, flags) > -#define XFS_BMAPI(mp, trans,io,bno,len,f,first,tot,mval,nmap,flist,delta) \ > - (*(mp)->m_io_ops.xfs_bmapi_func) \ > - (trans,(io)->io_obj,bno,len,f,first,tot,mval,nmap,flist,delta) > -#define XFS_BUNMAPI(mp, trans,io,bno,len,f,nexts,first,flist,delta,done) \ > - (*(mp)->m_io_ops.xfs_bunmapi_func) \ > - (trans,(io)->io_obj,bno,len,f,nexts,first,flist,delta,done) > -#define XFS_BMAP_EOF(mp, io, endoff, whichfork, eof) \ > - (*(mp)->m_io_ops.xfs_bmap_eof_func) \ > - ((io)->io_obj, endoff, whichfork, eof) > -#define XFS_IOMAP_WRITE_DIRECT(mp, io, offset, count, flags, mval, nmap, found)\ > - (*(mp)->m_io_ops.xfs_iomap_write_direct) \ > - ((io)->io_obj, offset, count, flags, mval, nmap, found) > -#define XFS_IOMAP_WRITE_DELAY(mp, io, offset, count, flags, mval, nmap) \ > - (*(mp)->m_io_ops.xfs_iomap_write_delay) \ > - ((io)->io_obj, offset, count, flags, mval, nmap) > -#define XFS_IOMAP_WRITE_ALLOCATE(mp, io, offset, count, mval, nmap) \ > - (*(mp)->m_io_ops.xfs_iomap_write_allocate) \ > - ((io)->io_obj, offset, count, mval, nmap) > -#define XFS_IOMAP_WRITE_UNWRITTEN(mp, io, offset, count) \ > - (*(mp)->m_io_ops.xfs_iomap_write_unwritten) \ > - ((io)->io_obj, offset, count) > -#define XFS_LCK_MAP_SHARED(mp, io) \ > - (*(mp)->m_io_ops.xfs_lck_map_shared)((io)->io_obj) > -#define XFS_ILOCK(mp, io, mode) \ > - (*(mp)->m_io_ops.xfs_ilock)((io)->io_obj, mode) > -#define XFS_ILOCK_NOWAIT(mp, io, mode) \ > - (*(mp)->m_io_ops.xfs_ilock_nowait)((io)->io_obj, mode) > -#define XFS_IUNLOCK(mp, io, mode) \ > - (*(mp)->m_io_ops.xfs_unlock)((io)->io_obj, mode) > -#define XFS_ILOCK_DEMOTE(mp, io, mode) \ > - (*(mp)->m_io_ops.xfs_ilock_demote)((io)->io_obj, mode) > -#define XFS_SIZE(mp, io) \ > - (*(mp)->m_io_ops.xfs_size_func)((io)->io_obj) > -#define XFS_IODONE(mp) \ > - (*(mp)->m_io_ops.xfs_iodone)(mp) > -#define XFS_SWAP_EXTENTS(mp, io, tio, sxp) \ > - (*(mp)->m_io_ops.xfs_swap_extents_func) \ > - ((io)->io_obj, (tio)->io_obj, sxp) > - > #ifdef HAVE_PERCPU_SB > > /* > @@ -423,7 +324,6 @@ typedef struct xfs_mount { > * hash table */ > struct xfs_dmops *m_dm_ops; /* vector of DMI ops */ > struct xfs_qmops *m_qm_ops; /* vector of XQM ops */ > - struct xfs_ioops m_io_ops; /* vector of I/O ops */ > atomic_t m_active_trans; /* number trans frozen */ > #ifdef HAVE_PERCPU_SB > xfs_icsb_cnts_t *m_sb_cnts; /* per-cpu superblock counters */ > @@ -646,7 +546,6 @@ extern int xfs_qmops_get(struct xfs_moun > extern void xfs_qmops_put(struct xfs_mount *); > > extern struct xfs_dmops xfs_dmcore_xfs; > -extern struct xfs_ioops xfs_iocore_xfs; > > extern int xfs_init(void); > extern void xfs_cleanup(void); > Index: linux-2.6-xfs/fs/xfs/xfs_vfsops.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_vfsops.c 2007-09-16 13:51:33.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_vfsops.c 2007-09-18 16:36:30.000000000 +0200 > @@ -449,8 +449,6 @@ xfs_mount( > if (error) > return error; > > - mp->m_io_ops = xfs_iocore_xfs; > - > if (args->flags & XFSMNT_QUIET) > flags |= XFS_MFSI_QUIET; > > @@ -544,7 +542,7 @@ xfs_mount( > if ((error = xfs_filestream_mount(mp))) > goto error2; > > - error = XFS_IOINIT(mp, args, flags); > + error = xfs_mountfs(mp, flags); > if (error) > goto error2; > > Index: linux-2.6-xfs/fs/xfs/xfs_vnodeops.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.c 2007-09-16 13:51:33.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.c 2007-09-18 16:37:22.000000000 +0200 > @@ -1187,7 +1187,7 @@ xfs_free_eofblocks( > > nimaps = 1; > xfs_ilock(ip, XFS_ILOCK_SHARED); > - error = XFS_BMAPI(mp, NULL, &ip->i_iocore, end_fsb, map_len, 0, > + error = xfs_bmapi(NULL, ip, end_fsb, map_len, 0, > NULL, 0, &imap, &nimaps, NULL, NULL); > xfs_iunlock(ip, XFS_ILOCK_SHARED); > > @@ -3983,7 +3983,7 @@ retry: > * Issue the xfs_bmapi() call to allocate the blocks > */ > XFS_BMAP_INIT(&free_list, &firstfsb); > - error = XFS_BMAPI(mp, tp, &ip->i_iocore, startoffset_fsb, > + error = xfs_bmapi(tp, ip, startoffset_fsb, > allocatesize_fsb, bmapi_flag, > &firstfsb, 0, imapp, &nimaps, > &free_list, NULL); > @@ -4065,7 +4065,7 @@ xfs_zero_remaining_bytes( > for (offset = startoff; offset <= endoff; offset = lastoffset + 1) { > offset_fsb = XFS_B_TO_FSBT(mp, offset); > nimap = 1; > - error = XFS_BMAPI(mp, NULL, &ip->i_iocore, offset_fsb, 1, 0, > + error = xfs_bmapi(NULL, ip, offset_fsb, 1, 0, > NULL, 0, &imap, &nimap, NULL, NULL); > if (error || nimap < 1) > break; > @@ -4200,7 +4200,7 @@ xfs_free_file_space( > */ > if (rt && !XFS_SB_VERSION_HASEXTFLGBIT(&mp->m_sb)) { > nimap = 1; > - error = XFS_BMAPI(mp, NULL, &ip->i_iocore, startoffset_fsb, > + error = xfs_bmapi(NULL, ip, startoffset_fsb, > 1, 0, NULL, 0, &imap, &nimap, NULL, NULL); > if (error) > goto out_unlock_iolock; > @@ -4215,7 +4215,7 @@ xfs_free_file_space( > startoffset_fsb += mp->m_sb.sb_rextsize - mod; > } > nimap = 1; > - error = XFS_BMAPI(mp, NULL, &ip->i_iocore, endoffset_fsb - 1, > + error = xfs_bmapi(NULL, ip, endoffset_fsb - 1, > 1, 0, NULL, 0, &imap, &nimap, NULL, NULL); > if (error) > goto out_unlock_iolock; > @@ -4291,7 +4291,7 @@ xfs_free_file_space( > * issue the bunmapi() call to free the blocks > */ > XFS_BMAP_INIT(&free_list, &firstfsb); > - error = XFS_BUNMAPI(mp, tp, &ip->i_iocore, startoffset_fsb, > + error = xfs_bunmapi(tp, ip, startoffset_fsb, > endoffset_fsb - startoffset_fsb, > 0, 2, &firstfsb, &free_list, NULL, &done); > if (error) { > 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-16 13:51:33.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_aops.c 2007-09-18 16:37:22.000000000 +0200 > @@ -317,7 +317,7 @@ xfs_map_blocks( > xfs_inode_t *ip = XFS_I(inode); > int error, nmaps = 1; > > - error = xfs_bmap(ip, offset, count, > + error = xfs_iomap(ip, offset, count, > flags, mapp, &nmaps); > if (!error && (flags & (BMAPI_WRITE|BMAPI_ALLOCATE))) > xfs_iflags_set(ip, XFS_IMODIFIED); > @@ -1342,7 +1342,7 @@ __xfs_get_blocks( > offset = (xfs_off_t)iblock << inode->i_blkbits; > ASSERT(bh_result->b_size >= (1 << inode->i_blkbits)); > size = bh_result->b_size; > - error = xfs_bmap(XFS_I(inode), offset, size, > + error = xfs_iomap(XFS_I(inode), offset, size, > create ? flags : BMAPI_READ, &iomap, &niomap); > if (error) > return -error; > Index: linux-2.6-xfs/fs/xfs/xfs_iomap.h > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_iomap.h 2007-09-18 16:34:31.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_iomap.h 2007-09-18 16:36:30.000000000 +0200 > @@ -71,11 +71,10 @@ typedef struct xfs_iomap { > iomap_flags_t iomap_flags; > } xfs_iomap_t; > > -struct xfs_iocore; > struct xfs_inode; > struct xfs_bmbt_irec; > > -extern int xfs_iomap(struct xfs_iocore *, xfs_off_t, ssize_t, int, > +extern int xfs_iomap(struct xfs_inode *, xfs_off_t, ssize_t, int, > struct xfs_iomap *, int *); > extern int xfs_iomap_write_direct(struct xfs_inode *, xfs_off_t, size_t, > int, struct xfs_bmbt_irec *, int *, int); > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_lrw.h > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_lrw.h 2007-09-18 16:43:56.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_lrw.h 2007-09-18 16:44:06.000000000 +0200 > @@ -72,7 +72,6 @@ extern int xfsbdstrat(struct xfs_mount * > extern int xfs_bdstrat_cb(struct xfs_buf *); > extern int xfs_dev_is_read_only(struct xfs_mount *, char *); > > -extern int xfs_zero_eof(struct inode *, struct xfs_iocore *, xfs_off_t, > - xfs_fsize_t); > +extern int xfs_zero_eof(struct xfs_inode *, xfs_off_t, xfs_fsize_t); > > #endif /* __XFS_LRW_H__ */ > From owner-xfs@oss.sgi.com Wed Sep 19 08:47:45 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Sep 2007 08:47: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.4 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 l8JFlQv4001339 for ; Wed, 19 Sep 2007 08:47:41 -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 VAA04642; Tue, 18 Sep 2007 21:24:47 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1116) id 4315C58C4C09; Tue, 18 Sep 2007 21:24:47 +1000 (EST) Date: Tue, 18 Sep 2007 21:24:47 +1000 To: torvalds@linux-foundation.org Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com, akpm@linux-foundation.org Subject: [GIT PULL] XFS update for 2.6.23 User-Agent: nail 11.25 7/29/05 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20070918112447.4315C58C4C09@chook.melbourne.sgi.com> From: tes@sgi.com (Tim Shimmin) X-archive-position: 12948 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, A couple of fixes for potential fs corruption. And one fix to ensure that xfs_mru_cache is not doing anything unless the cache has active objects. Please pull from the for-linus branch: git pull git://oss.sgi.com:8090/xfs/xfs-2.6.git for-linus This will update the following files: fs/xfs/linux-2.6/xfs_aops.c | 1 + fs/xfs/linux-2.6/xfs_super.c | 4 ++- fs/xfs/xfs_buf_item.h | 5 +++ fs/xfs/xfs_filestream.c | 3 +- fs/xfs/xfs_log_recover.c | 51 ++++++++++++++++++++++++++++-- fs/xfs/xfs_mru_cache.c | 72 ++++++++++++++++------------------------- fs/xfs/xfs_mru_cache.h | 6 +-- fs/xfs/xfs_trans_buf.c | 1 + fs/xfs/xfs_vnodeops.c | 20 +++++++----- 9 files changed, 101 insertions(+), 62 deletions(-) through these commits: commit b394e43e995d08821588a22561c6a71a63b4ff27 Author: Lachlan McIlroy Date: Fri Sep 14 15:23:04 2007 +1000 [XFS] Avoid replaying inode buffer initialisation log items if on-disk version is newer. SGI-PV: 969656 SGI-Modid: xfs-linux-melb:xfs-kern:29676a Signed-off-by: Lachlan McIlroy Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 776a75fa5cfb8f3602d3ca9d221dc34497133f4b Author: Lachlan McIlroy Date: Fri Sep 14 15:22:50 2007 +1000 [XFS] Ensure file size updates have been completed before writing inode to disk. SGI-PV: 968767 SGI-Modid: xfs-linux-melb:xfs-kern:29675a Signed-off-by: Lachlan McIlroy Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 65de5567564e70edd01b6d4e95e548d7ba284872 Author: David Chinner Date: Thu Aug 16 15:21:11 2007 +1000 [XFS] On-demand reaping of the MRU cache Instead of running the mru cache reaper all the time based on a timeout, we should only run it when the cache has active objects. This allows CPUs to sleep when there is no activity rather than be woken repeatedly just to check if there is anything to do. SGI-PV: 968554 SGI-Modid: xfs-linux-melb:xfs-kern:29305a Signed-off-by: David Chinner Signed-off-by: Donald Douwsma Signed-off-by: Tim Shimmin --Tim From owner-xfs@oss.sgi.com Wed Sep 19 08:47:33 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Sep 2007 08:47: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=-2.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 l8JFlQuw001339 for ; Wed, 19 Sep 2007 08:47:30 -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 MAA28279; Wed, 19 Sep 2007 12:52:00 +1000 Message-ID: <46F08F98.9070102@sgi.com> Date: Wed, 19 Sep 2007 12:55:20 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH 3/4] simplify xfs_vn_getattr References: <20070914162757.GD7110@lst.de> In-Reply-To: <20070914162757.GD7110@lst.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 12945 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 one question below - patch looks fine. Christoph Hellwig wrote: > Just fill in struct kstat directly from the xfs_inode instead of doing > a detour through a bhv_vattr_t and xfs_getattr. > > > Signed-off-by: Christoph Hellwig > > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_iops.c 2007-09-06 10:42:40.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c 2007-09-06 10:44:33.000000000 +0200 > @@ -564,33 +564,61 @@ xfs_vn_permission( > > STATIC int > xfs_vn_getattr( > - struct vfsmount *mnt, > - struct dentry *dentry, > - struct kstat *stat) > + struct vfsmount *mnt, > + struct dentry *dentry, > + struct kstat *stat) > { > - struct inode *inode = dentry->d_inode; > - bhv_vattr_t vattr = { .va_mask = XFS_AT_STAT }; > - int error; > - > - error = xfs_getattr(XFS_I(inode), &vattr, ATTR_LAZY); > - if (likely(!error)) { > - stat->size = i_size_read(inode); > - stat->dev = inode->i_sb->s_dev; > - stat->rdev = (vattr.va_rdev == 0) ? 0 : > - MKDEV(sysv_major(vattr.va_rdev) & 0x1ff, > - sysv_minor(vattr.va_rdev)); > - stat->mode = vattr.va_mode; > - stat->nlink = vattr.va_nlink; > - stat->uid = vattr.va_uid; > - stat->gid = vattr.va_gid; > - stat->ino = vattr.va_nodeid; > - stat->atime = vattr.va_atime; > - stat->mtime = vattr.va_mtime; > - stat->ctime = vattr.va_ctime; > - stat->blocks = vattr.va_nblocks; > - stat->blksize = vattr.va_blocksize; > + struct inode *inode = dentry->d_inode; > + struct xfs_inode *ip = XFS_I(inode); > + struct xfs_mount *mp = ip->i_mount; > + > + xfs_itrace_entry(ip); > + > + if (XFS_FORCED_SHUTDOWN(mp)) > + return XFS_ERROR(EIO); > + > + stat->size = XFS_ISIZE(ip); > + stat->dev = inode->i_sb->s_dev; > + stat->mode = ip->i_d.di_mode; > + stat->nlink = ip->i_d.di_nlink; > + stat->uid = ip->i_d.di_uid; > + stat->gid = ip->i_d.di_gid; > + stat->ino = ip->i_ino; > +#if XFS_BIG_INUMS > + stat->ino += mp->m_inoadd; > +#endif > + stat->atime = inode->i_atime; > + stat->mtime.tv_sec = ip->i_d.di_mtime.t_sec; > + stat->mtime.tv_nsec = ip->i_d.di_mtime.t_nsec; > + stat->ctime.tv_sec = ip->i_d.di_ctime.t_sec; > + stat->ctime.tv_nsec = ip->i_d.di_ctime.t_nsec; Why do we copy the atime from the inode and not the xfs_inode? I think I see what's the deal here - the atime in the inode is the authoritative atime. It gets updated from various places and we synchronise it to the xfs inode before flushing the xfs inode to disk. This means we shouldn't be using the atime in the xfs_inode because it will be stale - is this correct? > + stat->blocks = > + XFS_FSB_TO_BB(mp, ip->i_d.di_nblocks + ip->i_delayed_blks); > + > + > + switch (inode->i_mode & S_IFMT) { > + case S_IFBLK: > + case S_IFCHR: > + stat->blksize = BLKDEV_IOSIZE; > + stat->rdev = MKDEV(sysv_major(ip->i_df.if_u2.if_rdev) & 0x1ff, > + sysv_minor(ip->i_df.if_u2.if_rdev)); > + break; > + default: > + if (ip->i_d.di_flags & XFS_DIFLAG_REALTIME) { > + /* > + * If the file blocks are being allocated from a > + * realtime volume, then return the inode's realtime > + * extent size or the realtime volume's extent size. > + */ > + stat->blksize = > + xfs_get_extsz_hint(ip) << mp->m_sb.sb_blocklog; > + } else > + stat->blksize = xfs_preferred_iosize(mp); > + stat->rdev = 0; > + break; > } > - return -error; > + > + return 0; > } > > STATIC int > > > From owner-xfs@oss.sgi.com Wed Sep 19 08:51:49 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Sep 2007 08:51: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.7 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_52, J_CHICKENPOX_65 autolearn=no 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 l8JFpiv0003681 for ; Wed, 19 Sep 2007 08:51: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 l8IJNTA5024421 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 18 Sep 2007 21:23:29 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8IJNSYD024414; Tue, 18 Sep 2007 21:23:28 +0200 Date: Tue, 18 Sep 2007 21:23:27 +0200 From: Christoph Hellwig To: Lachlan McIlroy Cc: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: [PATCH 1/2] kill unnessecary ioops indirection Message-ID: <20070918192327.GA24369@lst.de> References: <20070914162802.GE7110@lst.de> <46EF661C.4030500@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46EF661C.4030500@sgi.com> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 12951 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 > > STATIC int /* error (positive) */ > > xfs_zero_last_block( > >- struct inode *ip, > >- xfs_iocore_t *io, > >+ struct inode *inode, > >+ xfs_inode_t *ip, > We don't really need to pass both the inode and xfs_inode > since it's easy to get one from the other. It was a trivial > exercise to get the iocore from the inode too so it's not a > problem with this change but should be cleaned up. Yeah, and when doing this change a lot more similar cleanups to get rid of xfs_inode and vnode fall out automatically. I've incorporated those bits into the next version. > >@@ -474,7 +474,8 @@ xfs_zero_eof( > > xfs_off_t offset, /* starting I/O offset */ > > xfs_fsize_t isize) /* current inode size */ > > { > >- struct inode *ip = vn_to_inode(vp); > >+ struct inode *inode = vn_to_inode(vp); > >+ xfs_inode_t *ip = XFS_I(inode); > Can we change the prototype for xfs_zero_eof() to take an inode > instead of the vp? They are the same object and vn_to_inode()/ > vn_from_inode() are just a waste of cycles. Also kills another > stack variable. I've changed to to an xfs_inode because that's what we want. inode is only needed all the way up in xfs_iozero once. vn_to_inode()/vn_from_inode() are no-ops nowdays, btw. > >- error = XFS_SWAP_EXTENTS(mp, &ip->i_iocore, &tip->i_iocore, sxp); > >+ error = xfs_swap_extents(ip, ip, sxp); > > xfs_swap_extents(ip, tip, sxp); Oops, fixed. No idea why xfsqa didn't catch this. And here's the updated patch: Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_lrw.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_lrw.c 2007-09-16 13:51:33.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_lrw.c 2007-09-18 16:44:27.000000000 +0200 @@ -131,7 +131,7 @@ xfs_inval_cached_trace( */ STATIC int xfs_iozero( - struct inode *ip, /* inode */ + struct xfs_inode *ip, /* inode */ loff_t pos, /* offset in file */ size_t count) /* size of data to zero */ { @@ -140,7 +140,7 @@ xfs_iozero( struct address_space *mapping; int status; - mapping = ip->i_mapping; + mapping = ip->i_vnode->i_mapping; do { unsigned long index, offset; @@ -400,20 +400,19 @@ xfs_splice_write( */ STATIC int /* error (positive) */ xfs_zero_last_block( - struct inode *ip, - xfs_iocore_t *io, + xfs_inode_t *ip, xfs_fsize_t offset, xfs_fsize_t isize) { xfs_fileoff_t last_fsb; - xfs_mount_t *mp = io->io_mount; + xfs_mount_t *mp = ip->i_mount; int nimaps; int zero_offset; int zero_len; int error = 0; xfs_bmbt_irec_t imap; - ASSERT(ismrlocked(io->io_lock, MR_UPDATE) != 0); + ASSERT(ismrlocked(&ip->i_lock, MR_UPDATE) != 0); zero_offset = XFS_B_FSB_OFFSET(mp, isize); if (zero_offset == 0) { @@ -426,7 +425,7 @@ xfs_zero_last_block( last_fsb = XFS_B_TO_FSBT(mp, isize); nimaps = 1; - error = XFS_BMAPI(mp, NULL, io, last_fsb, 1, 0, NULL, 0, &imap, + error = xfs_bmapi(NULL, ip, last_fsb, 1, 0, NULL, 0, &imap, &nimaps, NULL, NULL); if (error) { return error; @@ -444,14 +443,14 @@ xfs_zero_last_block( * out sync. We need to drop the ilock while we do this so we * don't deadlock when the buffer cache calls back to us. */ - XFS_IUNLOCK(mp, io, XFS_ILOCK_EXCL| XFS_EXTSIZE_RD); + xfs_iunlock(ip, XFS_ILOCK_EXCL| XFS_EXTSIZE_RD); zero_len = mp->m_sb.sb_blocksize - zero_offset; if (isize + zero_len > offset) zero_len = offset - isize; error = xfs_iozero(ip, isize, zero_len); - XFS_ILOCK(mp, io, XFS_ILOCK_EXCL|XFS_EXTSIZE_RD); + xfs_ilock(ip, XFS_ILOCK_EXCL|XFS_EXTSIZE_RD); ASSERT(error >= 0); return error; } @@ -469,12 +468,11 @@ xfs_zero_last_block( int /* error (positive) */ xfs_zero_eof( - bhv_vnode_t *vp, - xfs_iocore_t *io, + xfs_inode_t *ip, xfs_off_t offset, /* starting I/O offset */ xfs_fsize_t isize) /* current inode size */ { - struct inode *ip = vn_to_inode(vp); + xfs_iocore_t *io = &ip->i_iocore; xfs_fileoff_t start_zero_fsb; xfs_fileoff_t end_zero_fsb; xfs_fileoff_t zero_count_fsb; @@ -494,7 +492,7 @@ xfs_zero_eof( * First handle zeroing the block on which isize resides. * We only zero a part of that block so it is handled specially. */ - error = xfs_zero_last_block(ip, io, offset, isize); + error = xfs_zero_last_block(ip, offset, isize); if (error) { ASSERT(ismrlocked(io->io_lock, MR_UPDATE)); ASSERT(ismrlocked(io->io_iolock, MR_UPDATE)); @@ -525,7 +523,7 @@ xfs_zero_eof( while (start_zero_fsb <= end_zero_fsb) { nimaps = 1; zero_count_fsb = end_zero_fsb - start_zero_fsb + 1; - error = XFS_BMAPI(mp, NULL, io, start_zero_fsb, zero_count_fsb, + error = xfs_bmapi(NULL, ip, start_zero_fsb, zero_count_fsb, 0, NULL, 0, &imap, &nimaps, NULL, NULL); if (error) { ASSERT(ismrlocked(io->io_lock, MR_UPDATE)); @@ -553,7 +551,7 @@ xfs_zero_eof( * Drop the inode lock while we're doing the I/O. * We'll still have the iolock to protect us. */ - XFS_IUNLOCK(mp, io, XFS_ILOCK_EXCL|XFS_EXTSIZE_RD); + xfs_iunlock(ip, XFS_ILOCK_EXCL|XFS_EXTSIZE_RD); zero_off = XFS_FSB_TO_B(mp, start_zero_fsb); zero_len = XFS_FSB_TO_B(mp, imap.br_blockcount); @@ -569,14 +567,13 @@ xfs_zero_eof( start_zero_fsb = imap.br_startoff + imap.br_blockcount; ASSERT(start_zero_fsb <= (end_zero_fsb + 1)); - XFS_ILOCK(mp, io, XFS_ILOCK_EXCL|XFS_EXTSIZE_RD); + xfs_ilock(ip, XFS_ILOCK_EXCL|XFS_EXTSIZE_RD); } return 0; out_lock: - - XFS_ILOCK(mp, io, XFS_ILOCK_EXCL|XFS_EXTSIZE_RD); + xfs_ilock(ip, XFS_ILOCK_EXCL|XFS_EXTSIZE_RD); ASSERT(error >= 0); return error; } @@ -717,7 +714,7 @@ start: */ if (pos > xip->i_size) { - error = xfs_zero_eof(vp, io, pos, xip->i_size); + error = xfs_zero_eof(xip, pos, xip->i_size); if (error) { xfs_iunlock(xip, XFS_ILOCK_EXCL); goto out_unlock_internal; @@ -762,7 +759,7 @@ retry: if (need_i_mutex) { /* demote the lock now the cached pages are gone */ - XFS_ILOCK_DEMOTE(mp, io, XFS_IOLOCK_EXCL); + xfs_ilock_demote(xip, XFS_IOLOCK_EXCL); mutex_unlock(&inode->i_mutex); iolock = XFS_IOLOCK_SHARED; @@ -905,25 +902,6 @@ xfs_bdstrat_cb(struct xfs_buf *bp) } } - -int -xfs_bmap( - xfs_inode_t *ip, - xfs_off_t offset, - ssize_t count, - int flags, - xfs_iomap_t *iomapp, - int *niomaps) -{ - xfs_iocore_t *io = &ip->i_iocore; - - ASSERT((ip->i_d.di_mode & S_IFMT) == S_IFREG); - ASSERT(((ip->i_d.di_flags & XFS_DIFLAG_REALTIME) != 0) == - ((ip->i_iocore.io_flags & XFS_IOCORE_RT) != 0)); - - return xfs_iomap(io, offset, count, flags, iomapp, niomaps); -} - /* * Wrapper around bdstrat so that we can stop data * from going to disk in case we are shutting down the filesystem. Index: linux-2.6-xfs/fs/xfs/xfs_iomap.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_iomap.c 2007-09-18 16:34:31.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_iomap.c 2007-09-18 16:37:22.000000000 +0200 @@ -53,11 +53,11 @@ void xfs_iomap_enter_trace( int tag, - xfs_iocore_t *io, + xfs_inode_t *ip, xfs_off_t offset, ssize_t count) { - xfs_inode_t *ip = XFS_IO_INODE(io); + xfs_iocore_t *io = &ip->i_iocore; if (!ip->i_rwtrace) return; @@ -84,15 +84,13 @@ xfs_iomap_enter_trace( void xfs_iomap_map_trace( int tag, - xfs_iocore_t *io, + xfs_inode_t *ip, xfs_off_t offset, ssize_t count, xfs_iomap_t *iomapp, xfs_bmbt_irec_t *imapp, int flags) { - xfs_inode_t *ip = XFS_IO_INODE(io); - if (!ip->i_rwtrace) return; @@ -126,7 +124,7 @@ xfs_iomap_map_trace( STATIC int xfs_imap_to_bmap( - xfs_iocore_t *io, + xfs_inode_t *ip, xfs_off_t offset, xfs_bmbt_irec_t *imap, xfs_iomap_t *iomapp, @@ -134,11 +132,10 @@ xfs_imap_to_bmap( int iomaps, /* Number of iomap entries */ int flags) { - xfs_mount_t *mp; + xfs_mount_t *mp = ip->i_mount; int pbm; xfs_fsblock_t start_block; - mp = io->io_mount; for (pbm = 0; imaps && pbm < iomaps; imaps--, iomapp++, imap++, pbm++) { iomapp->iomap_offset = XFS_FSB_TO_B(mp, imap->br_startoff); @@ -146,7 +143,7 @@ xfs_imap_to_bmap( iomapp->iomap_bsize = XFS_FSB_TO_B(mp, imap->br_blockcount); iomapp->iomap_flags = flags; - if (io->io_flags & XFS_IOCORE_RT) { + if (ip->i_d.di_flags & XFS_DIFLAG_REALTIME) { iomapp->iomap_flags |= IOMAP_REALTIME; iomapp->iomap_target = mp->m_rtdev_targp; } else { @@ -160,7 +157,7 @@ xfs_imap_to_bmap( iomapp->iomap_bn = IOMAP_DADDR_NULL; iomapp->iomap_flags |= IOMAP_DELAY; } else { - iomapp->iomap_bn = XFS_FSB_TO_DB_IO(io, start_block); + iomapp->iomap_bn = XFS_FSB_TO_DB(ip, start_block); if (ISUNWRITTEN(imap)) iomapp->iomap_flags |= IOMAP_UNWRITTEN; } @@ -172,14 +169,14 @@ xfs_imap_to_bmap( int xfs_iomap( - xfs_iocore_t *io, + xfs_inode_t *ip, xfs_off_t offset, ssize_t count, int flags, xfs_iomap_t *iomapp, int *niomaps) { - xfs_mount_t *mp = io->io_mount; + xfs_mount_t *mp = ip->i_mount; xfs_fileoff_t offset_fsb, end_fsb; int error = 0; int lockmode = 0; @@ -188,32 +185,37 @@ xfs_iomap( int bmapi_flags = 0; int iomap_flags = 0; + ASSERT((ip->i_d.di_mode & S_IFMT) == S_IFREG); + ASSERT(((ip->i_d.di_flags & XFS_DIFLAG_REALTIME) != 0) == + ((ip->i_iocore.io_flags & XFS_IOCORE_RT) != 0)); + if (XFS_FORCED_SHUTDOWN(mp)) return XFS_ERROR(EIO); 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); + xfs_iomap_enter_trace(XFS_IOMAP_READ_ENTER, ip, offset, count); + lockmode = xfs_ilock_map_shared(ip); bmapi_flags = XFS_BMAPI_ENTIRE; break; case BMAPI_WRITE: - xfs_iomap_enter_trace(XFS_IOMAP_WRITE_ENTER, io, offset, count); + xfs_iomap_enter_trace(XFS_IOMAP_WRITE_ENTER, ip, offset, count); lockmode = XFS_ILOCK_EXCL|XFS_EXTSIZE_WR; if (flags & BMAPI_IGNSTATE) bmapi_flags |= XFS_BMAPI_IGSTATE|XFS_BMAPI_ENTIRE; - XFS_ILOCK(mp, io, lockmode); + xfs_ilock(ip, lockmode); break; case BMAPI_ALLOCATE: - xfs_iomap_enter_trace(XFS_IOMAP_ALLOC_ENTER, io, offset, count); + xfs_iomap_enter_trace(XFS_IOMAP_ALLOC_ENTER, ip, offset, count); lockmode = XFS_ILOCK_SHARED|XFS_EXTSIZE_RD; bmapi_flags = XFS_BMAPI_ENTIRE; + /* Attempt non-blocking lock */ if (flags & BMAPI_TRYLOCK) { - if (!XFS_ILOCK_NOWAIT(mp, io, lockmode)) + if (!xfs_ilock_nowait(ip, lockmode)) return XFS_ERROR(EAGAIN); } else { - XFS_ILOCK(mp, io, lockmode); + xfs_ilock(ip, lockmode); } break; default: @@ -226,7 +228,7 @@ xfs_iomap( end_fsb = XFS_B_TO_FSB(mp, (xfs_ufsize_t)offset + count); offset_fsb = XFS_B_TO_FSBT(mp, offset); - error = XFS_BMAPI(mp, NULL, io, offset_fsb, + error = xfs_bmapi(NULL, ip, offset_fsb, (xfs_filblks_t)(end_fsb - offset_fsb), bmapi_flags, NULL, 0, &imap, &nimaps, NULL, NULL); @@ -240,42 +242,42 @@ xfs_iomap( if (nimaps && (imap.br_startblock != HOLESTARTBLOCK) && (imap.br_startblock != DELAYSTARTBLOCK)) { - xfs_iomap_map_trace(XFS_IOMAP_WRITE_MAP, io, + xfs_iomap_map_trace(XFS_IOMAP_WRITE_MAP, ip, offset, count, iomapp, &imap, flags); break; } if (flags & (BMAPI_DIRECT|BMAPI_MMAP)) { - error = XFS_IOMAP_WRITE_DIRECT(mp, io, offset, - count, flags, &imap, &nimaps, nimaps); + error = xfs_iomap_write_direct(ip, offset, count, flags, + &imap, &nimaps, nimaps); } else { - error = XFS_IOMAP_WRITE_DELAY(mp, io, offset, count, - flags, &imap, &nimaps); + error = xfs_iomap_write_delay(ip, offset, count, flags, + &imap, &nimaps); } if (!error) { - xfs_iomap_map_trace(XFS_IOMAP_ALLOC_MAP, io, + xfs_iomap_map_trace(XFS_IOMAP_ALLOC_MAP, ip, offset, count, iomapp, &imap, flags); } iomap_flags = IOMAP_NEW; break; case BMAPI_ALLOCATE: /* If we found an extent, return it */ - XFS_IUNLOCK(mp, io, lockmode); + xfs_iunlock(ip, lockmode); lockmode = 0; if (nimaps && !ISNULLSTARTBLOCK(imap.br_startblock)) { - xfs_iomap_map_trace(XFS_IOMAP_WRITE_MAP, io, + xfs_iomap_map_trace(XFS_IOMAP_WRITE_MAP, ip, offset, count, iomapp, &imap, flags); break; } - error = XFS_IOMAP_WRITE_ALLOCATE(mp, io, offset, count, + error = xfs_iomap_write_allocate(ip, offset, count, &imap, &nimaps); break; } if (nimaps) { - *niomaps = xfs_imap_to_bmap(io, offset, &imap, + *niomaps = xfs_imap_to_bmap(ip, offset, &imap, iomapp, nimaps, *niomaps, iomap_flags); } else if (niomaps) { *niomaps = 0; @@ -283,14 +285,15 @@ xfs_iomap( out: if (lockmode) - XFS_IUNLOCK(mp, io, lockmode); + xfs_iunlock(ip, lockmode); return XFS_ERROR(error); } + STATIC int xfs_iomap_eof_align_last_fsb( xfs_mount_t *mp, - xfs_iocore_t *io, + xfs_inode_t *ip, xfs_fsize_t isize, xfs_extlen_t extsize, xfs_fileoff_t *last_fsb) @@ -299,7 +302,7 @@ xfs_iomap_eof_align_last_fsb( xfs_extlen_t align; int eof, error; - if (io->io_flags & XFS_IOCORE_RT) + if (ip->i_d.di_flags & XFS_DIFLAG_REALTIME) ; /* * If mounted with the "-o swalloc" option, roundup the allocation @@ -330,7 +333,7 @@ xfs_iomap_eof_align_last_fsb( } if (new_last_fsb) { - error = XFS_BMAP_EOF(mp, io, new_last_fsb, XFS_DATA_FORK, &eof); + error = xfs_bmap_eof(ip, new_last_fsb, XFS_DATA_FORK, &eof); if (error) return error; if (eof) @@ -435,7 +438,7 @@ xfs_iomap_write_direct( offset_fsb = XFS_B_TO_FSBT(mp, offset); last_fsb = XFS_B_TO_FSB(mp, ((xfs_ufsize_t)(offset + count))); if ((offset + count) > isize) { - error = xfs_iomap_eof_align_last_fsb(mp, io, isize, extsz, + error = xfs_iomap_eof_align_last_fsb(mp, ip, isize, extsz, &last_fsb); if (error) goto error_out; @@ -502,7 +505,7 @@ xfs_iomap_write_direct( */ XFS_BMAP_INIT(&free_list, &firstfsb); nimaps = 1; - error = XFS_BMAPI(mp, tp, io, offset_fsb, count_fsb, bmapi_flag, + error = xfs_bmapi(tp, ip, offset_fsb, count_fsb, bmapi_flag, &firstfsb, 0, &imap, &nimaps, &free_list, NULL); if (error) goto error0; @@ -560,7 +563,7 @@ error_out: STATIC int xfs_iomap_eof_want_preallocate( xfs_mount_t *mp, - xfs_iocore_t *io, + xfs_inode_t *ip, xfs_fsize_t isize, xfs_off_t offset, size_t count, @@ -587,7 +590,7 @@ xfs_iomap_eof_want_preallocate( while (count_fsb > 0) { imaps = nimaps; firstblock = NULLFSBLOCK; - error = XFS_BMAPI(mp, NULL, io, start_fsb, count_fsb, 0, + error = xfs_bmapi(NULL, ip, start_fsb, count_fsb, 0, &firstblock, 0, imap, &imaps, NULL, NULL); if (error) return error; @@ -644,7 +647,7 @@ retry: if (io->io_new_size > isize) isize = io->io_new_size; - error = xfs_iomap_eof_want_preallocate(mp, io, isize, offset, count, + error = xfs_iomap_eof_want_preallocate(mp, ip, isize, offset, count, ioflag, imap, XFS_WRITE_IMAPS, &prealloc); if (error) return error; @@ -658,7 +661,7 @@ retry: } if (prealloc || extsz) { - error = xfs_iomap_eof_align_last_fsb(mp, io, isize, extsz, + error = xfs_iomap_eof_align_last_fsb(mp, ip, isize, extsz, &last_fsb); if (error) return error; @@ -666,7 +669,7 @@ retry: nimaps = XFS_WRITE_IMAPS; firstblock = NULLFSBLOCK; - error = XFS_BMAPI(mp, NULL, io, offset_fsb, + error = xfs_bmapi(NULL, ip, offset_fsb, (xfs_filblks_t)(last_fsb - offset_fsb), XFS_BMAPI_DELAY | XFS_BMAPI_WRITE | XFS_BMAPI_ENTIRE, &firstblock, 1, imap, @@ -680,7 +683,7 @@ retry: */ if (nimaps == 0) { xfs_iomap_enter_trace(XFS_IOMAP_WRITE_NOSPACE, - io, offset, count); + ip, offset, count); if (xfs_flush_space(ip, &fsynced, &ioflag)) return XFS_ERROR(ENOSPC); @@ -788,7 +791,7 @@ xfs_iomap_write_allocate( } /* Go get the actual blocks */ - error = XFS_BMAPI(mp, tp, io, map_start_fsb, count_fsb, + error = xfs_bmapi(tp, ip, map_start_fsb, count_fsb, XFS_BMAPI_WRITE, &first_block, 1, imap, &nimaps, &free_list, NULL); if (error) @@ -860,8 +863,7 @@ xfs_iomap_write_unwritten( int committed; int error; - xfs_iomap_enter_trace(XFS_IOMAP_UNWRITTEN, - &ip->i_iocore, offset, count); + xfs_iomap_enter_trace(XFS_IOMAP_UNWRITTEN, ip, offset, count); offset_fsb = XFS_B_TO_FSBT(mp, offset); count_fsb = XFS_B_TO_FSB(mp, (xfs_ufsize_t)offset + count); @@ -895,7 +897,7 @@ xfs_iomap_write_unwritten( */ XFS_BMAP_INIT(&free_list, &firstfsb); nimaps = 1; - error = XFS_BMAPI(mp, tp, io, offset_fsb, count_fsb, + error = xfs_bmapi(tp, ip, offset_fsb, count_fsb, XFS_BMAPI_WRITE|XFS_BMAPI_CONVERT, &firstfsb, 1, &imap, &nimaps, &free_list, NULL); if (error) Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ksyms.c 2007-09-16 13:51:33.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c 2007-09-18 16:37:22.000000000 +0200 @@ -248,8 +248,6 @@ EXPORT_SYMBOL(xfs_ilock_nowait); EXPORT_SYMBOL(xfs_inode_lock_init); EXPORT_SYMBOL(xfs_internal_inum); EXPORT_SYMBOL(xfs_iocore_inode_init); -EXPORT_SYMBOL(xfs_iocore_xfs); -EXPORT_SYMBOL(xfs_iomap); EXPORT_SYMBOL(xfs_iput); EXPORT_SYMBOL(xfs_iput_new); EXPORT_SYMBOL(xfs_iread); Index: linux-2.6-xfs/fs/xfs/xfs_dfrag.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_dfrag.c 2007-09-16 13:51:33.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_dfrag.c 2007-09-18 16:37:38.000000000 +0200 @@ -111,7 +111,7 @@ xfs_swapext( goto error0; } - error = XFS_SWAP_EXTENTS(mp, &ip->i_iocore, &tip->i_iocore, sxp); + error = xfs_swap_extents(ip, tip, sxp); error0: if (fp != NULL) Index: linux-2.6-xfs/fs/xfs/xfs_inode.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_inode.c 2007-09-16 13:51:33.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_inode.c 2007-09-18 16:43:12.000000000 +0200 @@ -1709,7 +1709,7 @@ xfs_itruncate_finish( * runs. */ XFS_BMAP_INIT(&free_list, &first_block); - error = XFS_BUNMAPI(mp, ntp, &ip->i_iocore, + error = xfs_bunmapi(ntp, ip, first_unmap_block, unmap_len, XFS_BMAPI_AFLAG(fork) | (sync ? 0 : XFS_BMAPI_ASYNC), @@ -1842,8 +1842,6 @@ xfs_igrow_start( xfs_fsize_t new_size, cred_t *credp) { - int error; - ASSERT(ismrlocked(&(ip->i_lock), MR_UPDATE) != 0); ASSERT(ismrlocked(&(ip->i_iolock), MR_UPDATE) != 0); ASSERT(new_size > ip->i_size); @@ -1853,9 +1851,7 @@ xfs_igrow_start( * xfs_write_file() beyond the end of the file * and any blocks between the old and new file sizes. */ - error = xfs_zero_eof(XFS_ITOV(ip), &ip->i_iocore, new_size, - ip->i_size); - return error; + return xfs_zero_eof(ip, new_size, ip->i_size); } /* Index: linux-2.6-xfs/fs/xfs/xfs_iocore.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_iocore.c 2007-09-16 13:51:33.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_iocore.c 2007-09-18 16:37:22.000000000 +0200 @@ -47,46 +47,6 @@ #include "xfs_trans_space.h" #include "xfs_iomap.h" - -STATIC xfs_fsize_t -xfs_size_fn( - xfs_inode_t *ip) -{ - return XFS_ISIZE(ip); -} - -STATIC int -xfs_ioinit( - struct xfs_mount *mp, - struct xfs_mount_args *mntargs, - int flags) -{ - return xfs_mountfs(mp, flags); -} - -xfs_ioops_t xfs_iocore_xfs = { - .xfs_ioinit = (xfs_ioinit_t) xfs_ioinit, - .xfs_bmapi_func = (xfs_bmapi_t) xfs_bmapi, - .xfs_bunmapi_func = (xfs_bunmapi_t) xfs_bunmapi, - .xfs_bmap_eof_func = (xfs_bmap_eof_t) xfs_bmap_eof, - .xfs_iomap_write_direct = - (xfs_iomap_write_direct_t) xfs_iomap_write_direct, - .xfs_iomap_write_delay = - (xfs_iomap_write_delay_t) xfs_iomap_write_delay, - .xfs_iomap_write_allocate = - (xfs_iomap_write_allocate_t) xfs_iomap_write_allocate, - .xfs_iomap_write_unwritten = - (xfs_iomap_write_unwritten_t) xfs_iomap_write_unwritten, - .xfs_ilock = (xfs_lock_t) xfs_ilock, - .xfs_lck_map_shared = (xfs_lck_map_shared_t) xfs_ilock_map_shared, - .xfs_ilock_demote = (xfs_lock_demote_t) xfs_ilock_demote, - .xfs_ilock_nowait = (xfs_lock_nowait_t) xfs_ilock_nowait, - .xfs_unlock = (xfs_unlk_t) xfs_iunlock, - .xfs_size_func = (xfs_size_t) xfs_size_fn, - .xfs_iodone = (xfs_iodone_t) fs_noerr, - .xfs_swap_extents_func = (xfs_swap_extents_t) xfs_swap_extents, -}; - void xfs_iocore_inode_reinit( xfs_inode_t *ip) Index: linux-2.6-xfs/fs/xfs/xfs_mount.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_mount.c 2007-09-18 16:34:38.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_mount.c 2007-09-18 16:36:30.000000000 +0200 @@ -1307,7 +1307,6 @@ xfs_unmountfs(xfs_mount_t *mp, struct cr #if defined(DEBUG) || defined(INDUCE_IO_ERROR) xfs_errortag_clearall(mp, 0); #endif - XFS_IODONE(mp); xfs_mount_free(mp); return 0; } Index: linux-2.6-xfs/fs/xfs/xfs_mount.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_mount.h 2007-09-16 13:51:33.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_mount.h 2007-09-18 16:37:22.000000000 +0200 @@ -196,105 +196,6 @@ typedef struct xfs_qmops { #define XFS_QM_QUOTACTL(mp, cmd, id, addr) \ (*(mp)->m_qm_ops->xfs_quotactl)(mp, cmd, id, addr) - -/* - * Prototypes and functions for I/O core modularization. - */ - -typedef int (*xfs_ioinit_t)(struct xfs_mount *, - struct xfs_mount_args *, int); -typedef int (*xfs_bmapi_t)(struct xfs_trans *, void *, - xfs_fileoff_t, xfs_filblks_t, int, - xfs_fsblock_t *, xfs_extlen_t, - struct xfs_bmbt_irec *, int *, - struct xfs_bmap_free *, struct xfs_extdelta *); -typedef int (*xfs_bunmapi_t)(struct xfs_trans *, - void *, xfs_fileoff_t, - xfs_filblks_t, int, xfs_extnum_t, - xfs_fsblock_t *, struct xfs_bmap_free *, - struct xfs_extdelta *, int *); -typedef int (*xfs_bmap_eof_t)(void *, xfs_fileoff_t, int, int *); -typedef int (*xfs_iomap_write_direct_t)( - void *, xfs_off_t, size_t, int, - struct xfs_bmbt_irec *, int *, int); -typedef int (*xfs_iomap_write_delay_t)( - void *, xfs_off_t, size_t, int, - struct xfs_bmbt_irec *, int *); -typedef int (*xfs_iomap_write_allocate_t)( - void *, xfs_off_t, size_t, - struct xfs_bmbt_irec *, int *); -typedef int (*xfs_iomap_write_unwritten_t)( - void *, xfs_off_t, size_t); -typedef uint (*xfs_lck_map_shared_t)(void *); -typedef void (*xfs_lock_t)(void *, uint); -typedef void (*xfs_lock_demote_t)(void *, uint); -typedef int (*xfs_lock_nowait_t)(void *, uint); -typedef void (*xfs_unlk_t)(void *, unsigned int); -typedef xfs_fsize_t (*xfs_size_t)(void *); -typedef xfs_fsize_t (*xfs_iodone_t)(struct xfs_mount *); -typedef int (*xfs_swap_extents_t)(void *, void *, - struct xfs_swapext*); - -typedef struct xfs_ioops { - xfs_ioinit_t xfs_ioinit; - xfs_bmapi_t xfs_bmapi_func; - xfs_bunmapi_t xfs_bunmapi_func; - xfs_bmap_eof_t xfs_bmap_eof_func; - xfs_iomap_write_direct_t xfs_iomap_write_direct; - xfs_iomap_write_delay_t xfs_iomap_write_delay; - xfs_iomap_write_allocate_t xfs_iomap_write_allocate; - xfs_iomap_write_unwritten_t xfs_iomap_write_unwritten; - xfs_lock_t xfs_ilock; - xfs_lck_map_shared_t xfs_lck_map_shared; - xfs_lock_demote_t xfs_ilock_demote; - xfs_lock_nowait_t xfs_ilock_nowait; - xfs_unlk_t xfs_unlock; - xfs_size_t xfs_size_func; - xfs_iodone_t xfs_iodone; - xfs_swap_extents_t xfs_swap_extents_func; -} xfs_ioops_t; - -#define XFS_IOINIT(mp, args, flags) \ - (*(mp)->m_io_ops.xfs_ioinit)(mp, args, flags) -#define XFS_BMAPI(mp, trans,io,bno,len,f,first,tot,mval,nmap,flist,delta) \ - (*(mp)->m_io_ops.xfs_bmapi_func) \ - (trans,(io)->io_obj,bno,len,f,first,tot,mval,nmap,flist,delta) -#define XFS_BUNMAPI(mp, trans,io,bno,len,f,nexts,first,flist,delta,done) \ - (*(mp)->m_io_ops.xfs_bunmapi_func) \ - (trans,(io)->io_obj,bno,len,f,nexts,first,flist,delta,done) -#define XFS_BMAP_EOF(mp, io, endoff, whichfork, eof) \ - (*(mp)->m_io_ops.xfs_bmap_eof_func) \ - ((io)->io_obj, endoff, whichfork, eof) -#define XFS_IOMAP_WRITE_DIRECT(mp, io, offset, count, flags, mval, nmap, found)\ - (*(mp)->m_io_ops.xfs_iomap_write_direct) \ - ((io)->io_obj, offset, count, flags, mval, nmap, found) -#define XFS_IOMAP_WRITE_DELAY(mp, io, offset, count, flags, mval, nmap) \ - (*(mp)->m_io_ops.xfs_iomap_write_delay) \ - ((io)->io_obj, offset, count, flags, mval, nmap) -#define XFS_IOMAP_WRITE_ALLOCATE(mp, io, offset, count, mval, nmap) \ - (*(mp)->m_io_ops.xfs_iomap_write_allocate) \ - ((io)->io_obj, offset, count, mval, nmap) -#define XFS_IOMAP_WRITE_UNWRITTEN(mp, io, offset, count) \ - (*(mp)->m_io_ops.xfs_iomap_write_unwritten) \ - ((io)->io_obj, offset, count) -#define XFS_LCK_MAP_SHARED(mp, io) \ - (*(mp)->m_io_ops.xfs_lck_map_shared)((io)->io_obj) -#define XFS_ILOCK(mp, io, mode) \ - (*(mp)->m_io_ops.xfs_ilock)((io)->io_obj, mode) -#define XFS_ILOCK_NOWAIT(mp, io, mode) \ - (*(mp)->m_io_ops.xfs_ilock_nowait)((io)->io_obj, mode) -#define XFS_IUNLOCK(mp, io, mode) \ - (*(mp)->m_io_ops.xfs_unlock)((io)->io_obj, mode) -#define XFS_ILOCK_DEMOTE(mp, io, mode) \ - (*(mp)->m_io_ops.xfs_ilock_demote)((io)->io_obj, mode) -#define XFS_SIZE(mp, io) \ - (*(mp)->m_io_ops.xfs_size_func)((io)->io_obj) -#define XFS_IODONE(mp) \ - (*(mp)->m_io_ops.xfs_iodone)(mp) -#define XFS_SWAP_EXTENTS(mp, io, tio, sxp) \ - (*(mp)->m_io_ops.xfs_swap_extents_func) \ - ((io)->io_obj, (tio)->io_obj, sxp) - #ifdef HAVE_PERCPU_SB /* @@ -423,7 +324,6 @@ typedef struct xfs_mount { * hash table */ struct xfs_dmops *m_dm_ops; /* vector of DMI ops */ struct xfs_qmops *m_qm_ops; /* vector of XQM ops */ - struct xfs_ioops m_io_ops; /* vector of I/O ops */ atomic_t m_active_trans; /* number trans frozen */ #ifdef HAVE_PERCPU_SB xfs_icsb_cnts_t *m_sb_cnts; /* per-cpu superblock counters */ @@ -646,7 +546,6 @@ extern int xfs_qmops_get(struct xfs_moun extern void xfs_qmops_put(struct xfs_mount *); extern struct xfs_dmops xfs_dmcore_xfs; -extern struct xfs_ioops xfs_iocore_xfs; extern int xfs_init(void); extern void xfs_cleanup(void); Index: linux-2.6-xfs/fs/xfs/xfs_vfsops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vfsops.c 2007-09-16 13:51:33.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_vfsops.c 2007-09-18 16:36:30.000000000 +0200 @@ -449,8 +449,6 @@ xfs_mount( if (error) return error; - mp->m_io_ops = xfs_iocore_xfs; - if (args->flags & XFSMNT_QUIET) flags |= XFS_MFSI_QUIET; @@ -544,7 +542,7 @@ xfs_mount( if ((error = xfs_filestream_mount(mp))) goto error2; - error = XFS_IOINIT(mp, args, flags); + error = xfs_mountfs(mp, flags); if (error) goto error2; Index: linux-2.6-xfs/fs/xfs/xfs_vnodeops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.c 2007-09-16 13:51:33.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.c 2007-09-18 16:37:22.000000000 +0200 @@ -1187,7 +1187,7 @@ xfs_free_eofblocks( nimaps = 1; xfs_ilock(ip, XFS_ILOCK_SHARED); - error = XFS_BMAPI(mp, NULL, &ip->i_iocore, end_fsb, map_len, 0, + error = xfs_bmapi(NULL, ip, end_fsb, map_len, 0, NULL, 0, &imap, &nimaps, NULL, NULL); xfs_iunlock(ip, XFS_ILOCK_SHARED); @@ -3983,7 +3983,7 @@ retry: * Issue the xfs_bmapi() call to allocate the blocks */ XFS_BMAP_INIT(&free_list, &firstfsb); - error = XFS_BMAPI(mp, tp, &ip->i_iocore, startoffset_fsb, + error = xfs_bmapi(tp, ip, startoffset_fsb, allocatesize_fsb, bmapi_flag, &firstfsb, 0, imapp, &nimaps, &free_list, NULL); @@ -4065,7 +4065,7 @@ xfs_zero_remaining_bytes( for (offset = startoff; offset <= endoff; offset = lastoffset + 1) { offset_fsb = XFS_B_TO_FSBT(mp, offset); nimap = 1; - error = XFS_BMAPI(mp, NULL, &ip->i_iocore, offset_fsb, 1, 0, + error = xfs_bmapi(NULL, ip, offset_fsb, 1, 0, NULL, 0, &imap, &nimap, NULL, NULL); if (error || nimap < 1) break; @@ -4200,7 +4200,7 @@ xfs_free_file_space( */ if (rt && !XFS_SB_VERSION_HASEXTFLGBIT(&mp->m_sb)) { nimap = 1; - error = XFS_BMAPI(mp, NULL, &ip->i_iocore, startoffset_fsb, + error = xfs_bmapi(NULL, ip, startoffset_fsb, 1, 0, NULL, 0, &imap, &nimap, NULL, NULL); if (error) goto out_unlock_iolock; @@ -4215,7 +4215,7 @@ xfs_free_file_space( startoffset_fsb += mp->m_sb.sb_rextsize - mod; } nimap = 1; - error = XFS_BMAPI(mp, NULL, &ip->i_iocore, endoffset_fsb - 1, + error = xfs_bmapi(NULL, ip, endoffset_fsb - 1, 1, 0, NULL, 0, &imap, &nimap, NULL, NULL); if (error) goto out_unlock_iolock; @@ -4291,7 +4291,7 @@ xfs_free_file_space( * issue the bunmapi() call to free the blocks */ XFS_BMAP_INIT(&free_list, &firstfsb); - error = XFS_BUNMAPI(mp, tp, &ip->i_iocore, startoffset_fsb, + error = xfs_bunmapi(tp, ip, startoffset_fsb, endoffset_fsb - startoffset_fsb, 0, 2, &firstfsb, &free_list, NULL, &done); if (error) { 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-16 13:51:33.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_aops.c 2007-09-18 16:37:22.000000000 +0200 @@ -317,7 +317,7 @@ xfs_map_blocks( xfs_inode_t *ip = XFS_I(inode); int error, nmaps = 1; - error = xfs_bmap(ip, offset, count, + error = xfs_iomap(ip, offset, count, flags, mapp, &nmaps); if (!error && (flags & (BMAPI_WRITE|BMAPI_ALLOCATE))) xfs_iflags_set(ip, XFS_IMODIFIED); @@ -1342,7 +1342,7 @@ __xfs_get_blocks( offset = (xfs_off_t)iblock << inode->i_blkbits; ASSERT(bh_result->b_size >= (1 << inode->i_blkbits)); size = bh_result->b_size; - error = xfs_bmap(XFS_I(inode), offset, size, + error = xfs_iomap(XFS_I(inode), offset, size, create ? flags : BMAPI_READ, &iomap, &niomap); if (error) return -error; Index: linux-2.6-xfs/fs/xfs/xfs_iomap.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_iomap.h 2007-09-18 16:34:31.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_iomap.h 2007-09-18 16:36:30.000000000 +0200 @@ -71,11 +71,10 @@ typedef struct xfs_iomap { iomap_flags_t iomap_flags; } xfs_iomap_t; -struct xfs_iocore; struct xfs_inode; struct xfs_bmbt_irec; -extern int xfs_iomap(struct xfs_iocore *, xfs_off_t, ssize_t, int, +extern int xfs_iomap(struct xfs_inode *, xfs_off_t, ssize_t, int, struct xfs_iomap *, int *); extern int xfs_iomap_write_direct(struct xfs_inode *, xfs_off_t, size_t, int, struct xfs_bmbt_irec *, int *, int); Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_lrw.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_lrw.h 2007-09-18 16:43:56.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_lrw.h 2007-09-18 16:44:06.000000000 +0200 @@ -72,7 +72,6 @@ extern int xfsbdstrat(struct xfs_mount * extern int xfs_bdstrat_cb(struct xfs_buf *); extern int xfs_dev_is_read_only(struct xfs_mount *, char *); -extern int xfs_zero_eof(struct inode *, struct xfs_iocore *, xfs_off_t, - xfs_fsize_t); +extern int xfs_zero_eof(struct xfs_inode *, xfs_off_t, xfs_fsize_t); #endif /* __XFS_LRW_H__ */ From owner-xfs@oss.sgi.com Wed Sep 19 08:51:50 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Sep 2007 08: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.8 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 l8JFpiv2003681 for ; Wed, 19 Sep 2007 08:51:49 -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 l8IEd5A5008638 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 18 Sep 2007 16:39:05 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8IEd5s3008636; Tue, 18 Sep 2007 16:39:05 +0200 Date: Tue, 18 Sep 2007 16:39:04 +0200 From: Christoph Hellwig To: Lachlan McIlroy Cc: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: [PATCH] fix valid but harmless sparse warning in xfs_log_recovery.c Message-ID: <20070918143904.GA8488@lst.de> References: <20070916120433.GA31602@lst.de> <46EF6A6A.3080702@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46EF6A6A.3080702@sgi.com> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 12952 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 Tue, Sep 18, 2007 at 04:04:26PM +1000, Lachlan McIlroy wrote: > Ah thanks for that, my goof. Can you and Tim make sure this goes to Linus? I saw Tim sent out your original fix, and I really don't want to regress on sparse warnings in mainline. From owner-xfs@oss.sgi.com Wed Sep 19 08:51:47 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Sep 2007 08:51: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.7 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_35, J_CHICKENPOX_66 autolearn=no 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 l8JFpiuw003681 for ; Wed, 19 Sep 2007 08:51:46 -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 l8IJRtA5024756 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 18 Sep 2007 21:27:55 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8IJRsgv024754; Tue, 18 Sep 2007 21:27:54 +0200 Date: Tue, 18 Sep 2007 21:27:53 +0200 From: Christoph Hellwig To: Lachlan McIlroy Cc: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: [PATCH 2/2] kill xfs_iocore_t Message-ID: <20070918192753.GA24632@lst.de> References: <20070914162808.GF7110@lst.de> <46EF4C88.3070504@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46EF4C88.3070504@sgi.com> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 12950 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 Tue, Sep 18, 2007 at 01:56:56PM +1000, Lachlan McIlroy wrote: > This all looks good to me. A lot cleaner, nice one. It needs a little update to still apply after the ioops removal has been reworked per your suggestions. Here's the new version: Index: linux-2.6-xfs/fs/xfs/Makefile-linux-2.6 =================================================================== --- linux-2.6-xfs.orig/fs/xfs/Makefile-linux-2.6 2007-09-18 16:37:22.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/Makefile-linux-2.6 2007-09-18 16:47:33.000000000 +0200 @@ -60,7 +60,6 @@ xfs-y += xfs_alloc.o \ xfs_iget.o \ xfs_inode.o \ xfs_inode_item.o \ - xfs_iocore.o \ xfs_iomap.o \ xfs_itable.o \ xfs_dfrag.o \ Index: linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/dmapi/xfs_dm.c 2007-09-18 16:37:22.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c 2007-09-18 16:47:33.000000000 +0200 @@ -188,7 +188,7 @@ xfs_dm_send_data_event( ip = xfs_vtoi(vp); do { - dmstate = ip->i_iocore.io_dmstate; + dmstate = ip->i_d.di_dmstate; if (locktype) xfs_rwunlock(ip, *locktype); @@ -202,7 +202,7 @@ xfs_dm_send_data_event( if (locktype) xfs_rwlock(ip, *locktype); - } while (!error && (ip->i_iocore.io_dmstate != dmstate)); + } while (!error && (ip->i_d.di_dmstate != dmstate)); return error; } @@ -1018,7 +1018,6 @@ xfs_dm_f_set_eventlist( xfs_trans_ijoin(tp, ip, XFS_ILOCK_EXCL); ip->i_d.di_dmevmask = (eventset & max_mask) | (ip->i_d.di_dmevmask & ~max_mask); - ip->i_iocore.io_dmevmask = ip->i_d.di_dmevmask; xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); VN_HOLD(vp); @@ -2598,7 +2597,7 @@ xfs_dm_punch_hole( error = -error; /* Let threads in send_data_event know we punched the file. */ - ip->i_iocore.io_dmstate++; + ip->i_d.di_dmstate++; xfs_iunlock(ip, XFS_IOLOCK_EXCL); xfs_iflags_set(ip, XFS_IMODIFIED); @@ -2926,7 +2925,7 @@ xfs_dm_set_region( * bit, then that's always okay. Otherwise, it's busy. */ dm_eventset_t m1; - m1 = ip->i_iocore.io_dmevmask & ((1 << DM_EVENT_WRITE) | (1 << DM_EVENT_TRUNCATE)); + m1 = ip->i_d.di_dmevmask & ((1 << DM_EVENT_WRITE) | (1 << DM_EVENT_TRUNCATE)); if (m1 != new_mask) { return -EBUSY; } @@ -2943,7 +2942,6 @@ xfs_dm_set_region( xfs_trans_ijoin(tp, ip, XFS_ILOCK_EXCL); ip->i_d.di_dmevmask = (ip->i_d.di_dmevmask & ~mr_mask) | new_mask; - ip->i_iocore.io_dmevmask = ip->i_d.di_dmevmask; xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); VN_HOLD(vp); @@ -3223,7 +3221,7 @@ xfs_dm_send_mmap_event( offset = 0; /* beginning of file, for now */ length = 0; /* whole file, for now */ - filesize = ip->i_iocore.io_new_size; + filesize = ip->i_new_size; if (filesize < ip->i_size) { filesize = ip->i_size; } 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-18 16:37:22.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_aops.c 2007-09-18 16:47:33.000000000 +0200 @@ -163,7 +163,7 @@ xfs_destroy_ioend( /* * Update on-disk file size now that data has been written to disk. * The current in-memory file size is i_size. If a write is beyond - * eof io_new_size will be the intended file size until i_size is + * eof i_new_size will be the intended file size until i_size is * updated. If this write does not extend all the way to the valid * file size then restrict this update to the end of the write. */ @@ -185,7 +185,7 @@ xfs_setfilesize( xfs_ilock(ip, XFS_ILOCK_EXCL); - isize = MAX(ip->i_size, ip->i_iocore.io_new_size); + isize = MAX(ip->i_size, ip->i_new_size); isize = MIN(isize, bsize); if (ip->i_d.di_size < isize) { Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ksyms.c 2007-09-18 16:37:22.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c 2007-09-18 16:47:33.000000000 +0200 @@ -247,7 +247,6 @@ EXPORT_SYMBOL(xfs_ilock_map_shared); EXPORT_SYMBOL(xfs_ilock_nowait); EXPORT_SYMBOL(xfs_inode_lock_init); EXPORT_SYMBOL(xfs_internal_inum); -EXPORT_SYMBOL(xfs_iocore_inode_init); EXPORT_SYMBOL(xfs_iput); EXPORT_SYMBOL(xfs_iput_new); EXPORT_SYMBOL(xfs_iread); Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_lrw.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_lrw.c 2007-09-18 16:44:27.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_lrw.c 2007-09-18 16:56:30.000000000 +0200 @@ -58,14 +58,12 @@ void xfs_rw_enter_trace( int tag, - xfs_iocore_t *io, + xfs_inode_t *ip, void *data, size_t segs, loff_t offset, int ioflags) { - xfs_inode_t *ip = XFS_IO_INODE(io); - if (ip->i_rwtrace == NULL) return; ktrace_enter(ip->i_rwtrace, @@ -78,8 +76,8 @@ xfs_rw_enter_trace( (void *)((unsigned long)((offset >> 32) & 0xffffffff)), (void *)((unsigned long)(offset & 0xffffffff)), (void *)((unsigned long)ioflags), - (void *)((unsigned long)((io->io_new_size >> 32) & 0xffffffff)), - (void *)((unsigned long)(io->io_new_size & 0xffffffff)), + (void *)((unsigned long)((ip->i_new_size >> 32) & 0xffffffff)), + (void *)((unsigned long)(ip->i_new_size & 0xffffffff)), (void *)((unsigned long)current_pid()), (void *)NULL, (void *)NULL, @@ -89,13 +87,12 @@ xfs_rw_enter_trace( void xfs_inval_cached_trace( - xfs_iocore_t *io, + xfs_inode_t *ip, xfs_off_t offset, xfs_off_t len, xfs_off_t first, xfs_off_t last) { - xfs_inode_t *ip = XFS_IO_INODE(io); if (ip->i_rwtrace == NULL) return; @@ -267,7 +264,7 @@ xfs_read( } } - xfs_rw_enter_trace(XFS_READ_ENTER, &ip->i_iocore, + xfs_rw_enter_trace(XFS_READ_ENTER, ip, (void *)iovp, segs, *offset, ioflags); iocb->ki_pos = *offset; @@ -312,7 +309,7 @@ xfs_splice_read( return -error; } } - xfs_rw_enter_trace(XFS_SPLICE_READ_ENTER, &ip->i_iocore, + xfs_rw_enter_trace(XFS_SPLICE_READ_ENTER, ip, pipe, count, *ppos, ioflags); ret = generic_file_splice_read(infilp, ppos, pipe, count, flags); if (ret > 0) @@ -334,7 +331,6 @@ xfs_splice_write( { bhv_vnode_t *vp = XFS_ITOV(ip); xfs_mount_t *mp = ip->i_mount; - xfs_iocore_t *io = &ip->i_iocore; ssize_t ret; struct inode *inode = outfilp->f_mapping->host; xfs_fsize_t isize, new_size; @@ -361,10 +357,10 @@ xfs_splice_write( xfs_ilock(ip, XFS_ILOCK_EXCL); if (new_size > ip->i_size) - io->io_new_size = new_size; + ip->i_new_size = new_size; xfs_iunlock(ip, XFS_ILOCK_EXCL); - xfs_rw_enter_trace(XFS_SPLICE_WRITE_ENTER, &ip->i_iocore, + xfs_rw_enter_trace(XFS_SPLICE_WRITE_ENTER, ip, pipe, count, *ppos, ioflags); ret = generic_file_splice_write(pipe, outfilp, ppos, count, flags); if (ret > 0) @@ -381,9 +377,9 @@ xfs_splice_write( xfs_iunlock(ip, XFS_ILOCK_EXCL); } - if (io->io_new_size) { + if (ip->i_new_size) { xfs_ilock(ip, XFS_ILOCK_EXCL); - io->io_new_size = 0; + ip->i_new_size = 0; if (ip->i_d.di_size > ip->i_size) ip->i_d.di_size = ip->i_size; xfs_iunlock(ip, XFS_ILOCK_EXCL); @@ -472,20 +468,19 @@ xfs_zero_eof( xfs_off_t offset, /* starting I/O offset */ xfs_fsize_t isize) /* current inode size */ { - xfs_iocore_t *io = &ip->i_iocore; + xfs_mount_t *mp = ip->i_mount; xfs_fileoff_t start_zero_fsb; xfs_fileoff_t end_zero_fsb; xfs_fileoff_t zero_count_fsb; xfs_fileoff_t last_fsb; xfs_fileoff_t zero_off; xfs_fsize_t zero_len; - xfs_mount_t *mp = io->io_mount; int nimaps; int error = 0; xfs_bmbt_irec_t imap; - ASSERT(ismrlocked(io->io_lock, MR_UPDATE)); - ASSERT(ismrlocked(io->io_iolock, MR_UPDATE)); + ASSERT(ismrlocked(&ip->i_lock, MR_UPDATE)); + ASSERT(ismrlocked(&ip->i_iolock, MR_UPDATE)); ASSERT(offset > isize); /* @@ -494,8 +489,8 @@ xfs_zero_eof( */ error = xfs_zero_last_block(ip, offset, isize); if (error) { - ASSERT(ismrlocked(io->io_lock, MR_UPDATE)); - ASSERT(ismrlocked(io->io_iolock, MR_UPDATE)); + ASSERT(ismrlocked(&ip->i_lock, MR_UPDATE)); + ASSERT(ismrlocked(&ip->i_iolock, MR_UPDATE)); return error; } @@ -526,8 +521,8 @@ xfs_zero_eof( error = xfs_bmapi(NULL, ip, start_zero_fsb, zero_count_fsb, 0, NULL, 0, &imap, &nimaps, NULL, NULL); if (error) { - ASSERT(ismrlocked(io->io_lock, MR_UPDATE)); - ASSERT(ismrlocked(io->io_iolock, MR_UPDATE)); + ASSERT(ismrlocked(&ip->i_lock, MR_UPDATE)); + ASSERT(ismrlocked(&ip->i_iolock, MR_UPDATE)); return error; } ASSERT(nimaps > 0); @@ -595,7 +590,6 @@ xfs_write( xfs_mount_t *mp; ssize_t ret = 0, error = 0; xfs_fsize_t isize, new_size; - xfs_iocore_t *io; int iolock; int eventsent = 0; bhv_vrwlock_t locktype; @@ -615,8 +609,7 @@ xfs_write( if (count == 0) return 0; - io = &xip->i_iocore; - mp = io->io_mount; + mp = xip->i_mount; xfs_wait_for_freeze(mp, SB_FREEZE_WRITE); @@ -696,7 +689,7 @@ start: new_size = pos + count; if (new_size > xip->i_size) - io->io_new_size = new_size; + xip->i_new_size = new_size; if (likely(!(ioflags & IO_INVIS))) { file_update_time(file); @@ -748,7 +741,7 @@ retry: if ((ioflags & IO_ISDIRECT)) { if (VN_CACHED(vp)) { WARN_ON(need_i_mutex == 0); - xfs_inval_cached_trace(io, pos, -1, + xfs_inval_cached_trace(xip, pos, -1, ctooff(offtoct(pos)), -1); error = xfs_flushinval_pages(xip, ctooff(offtoct(pos)), @@ -767,7 +760,7 @@ retry: need_i_mutex = 0; } - xfs_rw_enter_trace(XFS_DIOWR_ENTER, io, (void *)iovp, segs, + xfs_rw_enter_trace(XFS_DIOWR_ENTER, xip, (void *)iovp, segs, *offset, ioflags); ret = generic_file_direct_write(iocb, iovp, &segs, pos, offset, count, ocount); @@ -787,7 +780,7 @@ retry: goto relock; } } else { - xfs_rw_enter_trace(XFS_WRITE_ENTER, io, (void *)iovp, segs, + xfs_rw_enter_trace(XFS_WRITE_ENTER, xip, (void *)iovp, segs, *offset, ioflags); ret = generic_file_buffered_write(iocb, iovp, segs, pos, offset, count, ret); @@ -851,9 +844,9 @@ retry: } out_unlock_internal: - if (io->io_new_size) { + if (xip->i_new_size) { xfs_ilock(xip, XFS_ILOCK_EXCL); - io->io_new_size = 0; + xip->i_new_size = 0; /* * If this was a direct or synchronous I/O that failed (such * as ENOSPC) then part of the I/O may have been written to Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_lrw.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_lrw.h 2007-09-18 16:44:06.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_lrw.h 2007-09-18 16:54:45.000000000 +0200 @@ -19,7 +19,6 @@ #define __XFS_LRW_H__ struct xfs_mount; -struct xfs_iocore; struct xfs_inode; struct xfs_bmbt_irec; struct xfs_buf; @@ -59,13 +58,13 @@ struct xfs_iomap; #define XFS_IOMAP_UNWRITTEN 27 #define XFS_SPLICE_READ_ENTER 28 #define XFS_SPLICE_WRITE_ENTER 29 -extern void xfs_rw_enter_trace(int, struct xfs_iocore *, - void *, size_t, loff_t, int); -extern void xfs_inval_cached_trace(struct xfs_iocore *, - xfs_off_t, xfs_off_t, xfs_off_t, xfs_off_t); +extern void xfs_rw_enter_trace(int, struct xfs_inode *, + void *, size_t, loff_t, int); +extern void xfs_inval_cached_trace(struct xfs_inode *, + xfs_off_t, xfs_off_t, xfs_off_t, xfs_off_t); #else -#define xfs_rw_enter_trace(tag, io, data, size, offset, ioflags) -#define xfs_inval_cached_trace(io, offset, len, first, last) +#define xfs_rw_enter_trace(tag, ip, data, size, offset, ioflags) +#define xfs_inval_cached_trace(ip, offset, len, first, last) #endif extern int xfsbdstrat(struct xfs_mount *, struct xfs_buf *); Index: linux-2.6-xfs/fs/xfs/xfs_dfrag.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_dfrag.c 2007-09-18 16:37:38.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_dfrag.c 2007-09-18 16:47:33.000000000 +0200 @@ -199,7 +199,7 @@ xfs_swap_extents( } if (VN_CACHED(tvp) != 0) { - xfs_inval_cached_trace(&tip->i_iocore, 0, -1, 0, -1); + xfs_inval_cached_trace(tip, 0, -1, 0, -1); error = xfs_flushinval_pages(tip, 0, -1, FI_REMAPF_LOCKED); if (error) Index: linux-2.6-xfs/fs/xfs/xfs_iget.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_iget.c 2007-09-18 16:37:22.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_iget.c 2007-09-18 16:47:33.000000000 +0200 @@ -199,12 +199,9 @@ again: XFS_STATS_INC(xs_ig_found); finish_inode: - if (ip->i_d.di_mode == 0) { - if (!(flags & XFS_IGET_CREATE)) { - xfs_put_perag(mp, pag); - return ENOENT; - } - xfs_iocore_inode_reinit(ip); + if (ip->i_d.di_mode == 0 && !(flags & XFS_IGET_CREATE)) { + xfs_put_perag(mp, pag); + return ENOENT; } if (lock_flags != 0) @@ -235,7 +232,6 @@ finish_inode: xfs_itrace_exit_tag(ip, "xfs_iget.alloc"); xfs_inode_lock_init(ip, vp); - xfs_iocore_inode_init(ip); if (lock_flags) xfs_ilock(ip, lock_flags); @@ -331,9 +327,6 @@ finish_inode: ASSERT(ip->i_df.if_ext_max == XFS_IFORK_DSIZE(ip) / sizeof(xfs_bmbt_rec_t)); - ASSERT(((ip->i_d.di_flags & XFS_DIFLAG_REALTIME) != 0) == - ((ip->i_iocore.io_flags & XFS_IOCORE_RT) != 0)); - xfs_iflags_set(ip, XFS_IMODIFIED); *ipp = ip; Index: linux-2.6-xfs/fs/xfs/xfs_inode.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_inode.c 2007-09-18 16:43:12.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_inode.c 2007-09-18 16:47:33.000000000 +0200 @@ -1220,10 +1220,8 @@ xfs_ialloc( ip->i_d.di_extsize = pip->i_d.di_extsize; } } else if ((mode & S_IFMT) == S_IFREG) { - if (pip->i_d.di_flags & XFS_DIFLAG_RTINHERIT) { + if (pip->i_d.di_flags & XFS_DIFLAG_RTINHERIT) di_flags |= XFS_DIFLAG_REALTIME; - ip->i_iocore.io_flags |= XFS_IOCORE_RT; - } if (pip->i_d.di_flags & XFS_DIFLAG_EXTSZINHERIT) { di_flags |= XFS_DIFLAG_EXTSIZE; ip->i_d.di_extsize = pip->i_d.di_extsize; Index: linux-2.6-xfs/fs/xfs/xfs_inode.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_inode.h 2007-09-18 16:37:22.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_inode.h 2007-09-18 16:47:33.000000000 +0200 @@ -132,45 +132,6 @@ typedef struct dm_attrs_s { __uint16_t da_pad; /* DMIG extra padding */ } dm_attrs_t; -typedef struct xfs_iocore { - void *io_obj; /* pointer to container - * inode or dcxvn structure */ - struct xfs_mount *io_mount; /* fs mount struct ptr */ -#ifdef DEBUG - mrlock_t *io_lock; /* inode IO lock */ - mrlock_t *io_iolock; /* inode IO lock */ -#endif - - /* I/O state */ - xfs_fsize_t io_new_size; /* sz when write completes */ - - /* Miscellaneous state. */ - unsigned int io_flags; /* IO related flags */ - - /* DMAPI state */ - dm_attrs_t io_dmattrs; - -} xfs_iocore_t; - -#define io_dmevmask io_dmattrs.da_dmevmask -#define io_dmstate io_dmattrs.da_dmstate - -#define XFS_IO_INODE(io) ((xfs_inode_t *) ((io)->io_obj)) -#define XFS_IO_DCXVN(io) ((dcxvn_t *) ((io)->io_obj)) - -/* - * Flags in the flags field - */ - -#define XFS_IOCORE_RT 0x1 - -/* - * xfs_iocore prototypes - */ - -extern void xfs_iocore_inode_init(struct xfs_inode *); -extern void xfs_iocore_inode_reinit(struct xfs_inode *); - /* * This is the xfs inode cluster structure. This structure is used by * xfs_iflush to find inodes that share a cluster and can be flushed to disk at @@ -283,9 +244,6 @@ typedef struct xfs_inode { struct xfs_inode **i_refcache; /* ptr to entry in ref cache */ struct xfs_inode *i_release; /* inode to unref */ #endif - /* I/O state */ - xfs_iocore_t i_iocore; /* I/O core */ - /* Miscellaneous state. */ unsigned short i_flags; /* see defined flags below */ unsigned char i_update_core; /* timestamps/size is dirty */ @@ -298,6 +256,7 @@ typedef struct xfs_inode { struct hlist_node i_cnode; /* cluster link node */ xfs_fsize_t i_size; /* in-memory size */ + xfs_fsize_t i_new_size; /* size when write completes */ atomic_t i_iocount; /* outstanding I/O count */ /* Trace buffers per inode. */ #ifdef XFS_INODE_TRACE Index: linux-2.6-xfs/fs/xfs/xfs_iocore.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_iocore.c 2007-09-18 16:37:22.000000000 +0200 +++ /dev/null 1970-01-01 00:00:00.000000000 +0000 @@ -1,79 +0,0 @@ -/* - * Copyright (c) 2000-2003,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 - */ -#include "xfs.h" -#include "xfs_fs.h" -#include "xfs_types.h" -#include "xfs_bit.h" -#include "xfs_log.h" -#include "xfs_inum.h" -#include "xfs_trans.h" -#include "xfs_sb.h" -#include "xfs_ag.h" -#include "xfs_dir2.h" -#include "xfs_dfrag.h" -#include "xfs_dmapi.h" -#include "xfs_mount.h" -#include "xfs_bmap_btree.h" -#include "xfs_alloc_btree.h" -#include "xfs_ialloc_btree.h" -#include "xfs_dir2_sf.h" -#include "xfs_attr_sf.h" -#include "xfs_dinode.h" -#include "xfs_inode.h" -#include "xfs_inode_item.h" -#include "xfs_itable.h" -#include "xfs_btree.h" -#include "xfs_alloc.h" -#include "xfs_ialloc.h" -#include "xfs_bmap.h" -#include "xfs_error.h" -#include "xfs_rw.h" -#include "xfs_quota.h" -#include "xfs_trans_space.h" -#include "xfs_iomap.h" - -void -xfs_iocore_inode_reinit( - xfs_inode_t *ip) -{ - xfs_iocore_t *io = &ip->i_iocore; - - io->io_flags = 0; - if (ip->i_d.di_flags & XFS_DIFLAG_REALTIME) - io->io_flags |= XFS_IOCORE_RT; - io->io_dmevmask = ip->i_d.di_dmevmask; - io->io_dmstate = ip->i_d.di_dmstate; -} - -void -xfs_iocore_inode_init( - xfs_inode_t *ip) -{ - xfs_iocore_t *io = &ip->i_iocore; - xfs_mount_t *mp = ip->i_mount; - - io->io_mount = mp; -#ifdef DEBUG - io->io_lock = &ip->i_lock; - io->io_iolock = &ip->i_iolock; -#endif - - io->io_obj = (void *)ip; - - xfs_iocore_inode_reinit(ip); -} Index: linux-2.6-xfs/fs/xfs/xfs_iomap.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_iomap.c 2007-09-18 16:37:22.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_iomap.c 2007-09-18 16:47:33.000000000 +0200 @@ -57,8 +57,6 @@ xfs_iomap_enter_trace( xfs_off_t offset, ssize_t count) { - xfs_iocore_t *io = &ip->i_iocore; - if (!ip->i_rwtrace) return; @@ -70,8 +68,8 @@ xfs_iomap_enter_trace( (void *)((unsigned long)((offset >> 32) & 0xffffffff)), (void *)((unsigned long)(offset & 0xffffffff)), (void *)((unsigned long)count), - (void *)((unsigned long)((io->io_new_size >> 32) & 0xffffffff)), - (void *)((unsigned long)(io->io_new_size & 0xffffffff)), + (void *)((unsigned long)((ip->i_new_size >> 32) & 0xffffffff)), + (void *)((unsigned long)(ip->i_new_size & 0xffffffff)), (void *)((unsigned long)current_pid()), (void *)NULL, (void *)NULL, @@ -186,8 +184,6 @@ xfs_iomap( int iomap_flags = 0; ASSERT((ip->i_d.di_mode & S_IFMT) == S_IFREG); - ASSERT(((ip->i_d.di_flags & XFS_DIFLAG_REALTIME) != 0) == - ((ip->i_iocore.io_flags & XFS_IOCORE_RT) != 0)); if (XFS_FORCED_SHUTDOWN(mp)) return XFS_ERROR(EIO); @@ -402,7 +398,6 @@ xfs_iomap_write_direct( int found) { xfs_mount_t *mp = ip->i_mount; - xfs_iocore_t *io = &ip->i_iocore; xfs_fileoff_t offset_fsb; xfs_fileoff_t last_fsb; xfs_filblks_t count_fsb, resaligned; @@ -432,8 +427,8 @@ xfs_iomap_write_direct( extsz = xfs_get_extsz_hint(ip); isize = ip->i_size; - if (io->io_new_size > isize) - isize = io->io_new_size; + if (ip->i_new_size > isize) + isize = ip->i_new_size; offset_fsb = XFS_B_TO_FSBT(mp, offset); last_fsb = XFS_B_TO_FSB(mp, ((xfs_ufsize_t)(offset + count))); @@ -528,7 +523,8 @@ xfs_iomap_write_direct( goto error_out; } - if (unlikely(!imap.br_startblock && !(io->io_flags & XFS_IOCORE_RT))) { + if (unlikely(!imap.br_startblock && + !(ip->i_d.di_flags & XFS_DIFLAG_REALTIME))) { error = xfs_cmn_err_fsblock_zero(ip, &imap); goto error_out; } @@ -616,7 +612,6 @@ xfs_iomap_write_delay( int *nmaps) { xfs_mount_t *mp = ip->i_mount; - xfs_iocore_t *io = &ip->i_iocore; xfs_fileoff_t offset_fsb; xfs_fileoff_t last_fsb; xfs_off_t aligned_offset; @@ -644,8 +639,8 @@ xfs_iomap_write_delay( retry: isize = ip->i_size; - if (io->io_new_size > isize) - isize = io->io_new_size; + if (ip->i_new_size > isize) + isize = ip->i_new_size; error = xfs_iomap_eof_want_preallocate(mp, ip, isize, offset, count, ioflag, imap, XFS_WRITE_IMAPS, &prealloc); @@ -691,7 +686,8 @@ retry: goto retry; } - if (unlikely(!imap[0].br_startblock && !(io->io_flags & XFS_IOCORE_RT))) + if (unlikely(!imap[0].br_startblock && + !(ip->i_d.di_flags & XFS_DIFLAG_REALTIME))) return xfs_cmn_err_fsblock_zero(ip, &imap[0]); *ret_imap = imap[0]; @@ -716,7 +712,6 @@ xfs_iomap_write_allocate( int *retmap) { xfs_mount_t *mp = ip->i_mount; - xfs_iocore_t *io = &ip->i_iocore; xfs_fileoff_t offset_fsb, last_block; xfs_fileoff_t end_fsb, map_start_fsb; xfs_fsblock_t first_block; @@ -814,7 +809,7 @@ xfs_iomap_write_allocate( */ for (i = 0; i < nimaps; i++) { if (unlikely(!imap[i].br_startblock && - !(io->io_flags & XFS_IOCORE_RT))) + !(ip->i_d.di_flags & XFS_DIFLAG_REALTIME))) return xfs_cmn_err_fsblock_zero(ip, &imap[i]); if ((offset_fsb >= imap[i].br_startoff) && (offset_fsb < (imap[i].br_startoff + @@ -850,7 +845,6 @@ xfs_iomap_write_unwritten( size_t count) { xfs_mount_t *mp = ip->i_mount; - xfs_iocore_t *io = &ip->i_iocore; xfs_fileoff_t offset_fsb; xfs_filblks_t count_fsb; xfs_filblks_t numblks_fsb; @@ -913,7 +907,7 @@ xfs_iomap_write_unwritten( return XFS_ERROR(error); if (unlikely(!imap.br_startblock && - !(io->io_flags & XFS_IOCORE_RT))) + !(ip->i_d.di_flags & XFS_DIFLAG_REALTIME))) return xfs_cmn_err_fsblock_zero(ip, &imap); if ((numblks_fsb = imap.br_blockcount) == 0) { Index: linux-2.6-xfs/fs/xfs/xfs_mount.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_mount.h 2007-09-18 16:37:22.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_mount.h 2007-09-18 16:47:33.000000000 +0200 @@ -56,7 +56,6 @@ struct cred; struct log; struct xfs_mount_args; struct xfs_inode; -struct xfs_iocore; struct xfs_bmbt_irec; struct xfs_bmap_free; struct xfs_extdelta; Index: linux-2.6-xfs/fs/xfs/xfs_rw.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_rw.h 2007-09-18 16:37:22.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_rw.h 2007-09-18 16:47:33.000000000 +0200 @@ -36,14 +36,6 @@ xfs_fsb_to_db(struct xfs_inode *ip, xfs_ (xfs_daddr_t)XFS_FSB_TO_BB((ip)->i_mount, (fsb)) : \ XFS_FSB_TO_DADDR((ip)->i_mount, (fsb))); } -#define XFS_FSB_TO_DB_IO(io,fsb) xfs_fsb_to_db_io(io,fsb) -static inline xfs_daddr_t -xfs_fsb_to_db_io(struct xfs_iocore *io, xfs_fsblock_t fsb) -{ - return (((io)->io_flags & XFS_IOCORE_RT) ? \ - XFS_FSB_TO_BB((io)->io_mount, (fsb)) : \ - XFS_FSB_TO_DADDR((io)->io_mount, (fsb))); -} /* * Flags for xfs_free_eofblocks Index: linux-2.6-xfs/fs/xfs/xfs_vnodeops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.c 2007-09-18 16:37:22.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.c 2007-09-18 16:47:33.000000000 +0200 @@ -804,12 +804,8 @@ xfs_setattr( if (vap->va_xflags & XFS_XFLAG_EXTSZINHERIT) di_flags |= XFS_DIFLAG_EXTSZINHERIT; } else if ((ip->i_d.di_mode & S_IFMT) == S_IFREG) { - if (vap->va_xflags & XFS_XFLAG_REALTIME) { + if (vap->va_xflags & XFS_XFLAG_REALTIME) di_flags |= XFS_DIFLAG_REALTIME; - ip->i_iocore.io_flags |= XFS_IOCORE_RT; - } else { - ip->i_iocore.io_flags &= ~XFS_IOCORE_RT; - } if (vap->va_xflags & XFS_XFLAG_EXTSIZE) di_flags |= XFS_DIFLAG_EXTSIZE; } @@ -3644,8 +3640,8 @@ xfs_set_dmattrs( xfs_ilock(ip, XFS_ILOCK_EXCL); xfs_trans_ijoin(tp, ip, XFS_ILOCK_EXCL); - ip->i_iocore.io_dmevmask = ip->i_d.di_dmevmask = evmask; - ip->i_iocore.io_dmstate = ip->i_d.di_dmstate = state; + ip->i_d.di_dmevmask = evmask; + ip->i_d.di_dmstate = state; xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); IHOLD(ip); @@ -4183,7 +4179,7 @@ xfs_free_file_space( ioffset = offset & ~(rounding - 1); if (VN_CACHED(vp) != 0) { - xfs_inval_cached_trace(&ip->i_iocore, ioffset, -1, + xfs_inval_cached_trace(ip, ioffset, -1, ctooff(offtoct(ioffset)), -1); error = xfs_flushinval_pages(ip, ctooff(offtoct(ioffset)), Index: linux-2.6-xfs/fs/xfs/xfsidbg.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfsidbg.c 2007-09-18 16:37:22.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfsidbg.c 2007-09-18 16:47:33.000000000 +0200 @@ -164,7 +164,6 @@ static void xfsidbg_xlog_tic(xlog_ticket static void xfsidbg_xlogitem(xfs_log_item_t *); static void xfsidbg_xmount(xfs_mount_t *); static void xfsidbg_xnode(xfs_inode_t *ip); -static void xfsidbg_xcore(xfs_iocore_t *io); static void xfsidbg_xperag(xfs_mount_t *); static void xfsidbg_xqm_diskdq(xfs_disk_dquot_t *); static void xfsidbg_xqm_dqattached_inos(xfs_mount_t *); @@ -1472,25 +1471,6 @@ static int kdbm_xfs_xnode( return 0; } -static int kdbm_xfs_xcore( - int argc, - const char **argv) -{ - unsigned long addr; - int nextarg = 1; - long offset = 0; - int diag; - - if (argc != 1) - return KDB_ARGCOUNT; - diag = kdbgetaddrarg(argc, argv, &nextarg, &addr, &offset, NULL); - if (diag) - return diag; - - xfsidbg_xcore((xfs_iocore_t *) addr); - return 0; -} - static int kdbm_xfs_xperag( int argc, const char **argv) @@ -2552,8 +2532,6 @@ static struct xif xfsidbg_funcs[] = { "Dump XFS mount structure"}, { "xnode", kdbm_xfs_xnode, "", "Dump XFS inode"}, - { "xiocore", kdbm_xfs_xcore, "", - "Dump XFS iocore"}, { "xperag", kdbm_xfs_xperag, "", "Dump XFS per-allocation group data"}, { "xqinfo", kdbm_xfs_xqm_qinfo, "", @@ -6588,7 +6566,7 @@ xfsidbg_xnode(xfs_inode_t *ip) xfs_ipincount(ip)); kdb_printf("udquotp 0x%p gdquotp 0x%p\n", ip->i_udquot, ip->i_gdquot); - kdb_printf("new_size %Ld\n", ip->i_iocore.io_new_size); + kdb_printf("new_size %Ld\n", ip->i_new_size); printflags((int)ip->i_flags, tab_flags, "flags"); kdb_printf("\n"); kdb_printf("update_core %d update size %d\n", @@ -6628,14 +6606,6 @@ xfsidbg_xnode(xfs_inode_t *ip) xfs_prdinode_incore(&ip->i_d); } -static void -xfsidbg_xcore(xfs_iocore_t *io) -{ - kdb_printf("io_obj 0x%p io_flags 0x%x io_mount 0x%p\n", - io->io_obj, io->io_flags, io->io_mount); - kdb_printf("new_size %Lx\n", io->io_new_size); -} - /* * Print xfs per-ag data structures for filesystem. */ From owner-xfs@oss.sgi.com Wed Sep 19 08:53:47 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Sep 2007 08:53: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=0.1 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 l8JFrkuw004972 for ; Wed, 19 Sep 2007 08:53:47 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 53EC51C000265; Wed, 19 Sep 2007 04:47:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 516534069858; Wed, 19 Sep 2007 04:47:38 -0400 (EDT) Date: Wed, 19 Sep 2007 04:47:38 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: linux-kernel@vger.kernel.org cc: xfs@oss.sgi.com Subject: Re: 2.6.20 (XFS? related) crash after uptime of > 180 days during apt-get dist-upgrade on Debian Testing In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 12953 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, 17 Sep 2007, Justin Piszcz wrote: > Including the XFS mailing list in here too because it may be an XFS bug > looking at the call trace. > > System: Debian Testing > Kernel: 2.6.20 > Config: Attached > > I was running apt-get dist-upgrade as I always do to get the latest packages > upgraded and the kernel OOPS'd when it was upgrading 'tzdata' and the process > went into D-state and I had to reboot. > > The config file is from 2.6.20 but it had been moved to a 2.6.22 directory > for an upgrade, but all of the options have been left unchanged. > > Here is the *OOPS I captured via dmesg before I rebooted: > > Also, Not sure if this helps but when this happened, any file that was open() for read/write seem to have also been corrupted.. $ /usr/sbin/xfs_bmap -v myconfig.txt.orig myconfig.txt.orig: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..7]: 64601112..64601119 14 (52040..52047) 8 $ /usr/sbin/xfs_bmap -v myconfig.txt myconfig.txt: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..7]: 64625720..64625727 14 (76648..76655) 8 $ md5sum myconfig* db8c50ca2c86d2e757ecef1d6b3fcc69 myconfig.txt 09fb630623b3ae614511cef4c7a21063 myconfig.txt.orig $ file myconfig.txt myconfig.txt.orig myconfig.txt: ASCII text myconfig.txt.orig: data $ $ strings -a myconfig.txt.orig $ $ od -c myconfig.txt.orig 0000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0003500 \0 \0 \0 \0 \0 \0 0003506 Seems like it was NULL'd out? Justin. From owner-xfs@oss.sgi.com Wed Sep 19 08:58:28 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Sep 2007 08:58: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=-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 l8JFwNuw006297 for ; Wed, 19 Sep 2007 08:58:25 -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 l8I7uq77029871; Tue, 18 Sep 2007 17:56:55 +1000 Received: (from lachlan@localhost) by redback.melbourne.sgi.com (8.13.8/8.13.8/Submit) id l8I7uq6L029870; Tue, 18 Sep 2007 17:56:52 +1000 Date: Tue, 18 Sep 2007 17:56:52 +1000 From: Lachlan McIlroy Message-Id: <200709180756.l8I7uq6L029870@redback.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 970662 - simplify validata_fields X-archive-position: 12954 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 simplify validata_fields Stop using xfs_getattr and a onstack bhv_vattr_t just to get three fields from the underlying inode and opencode copying from the inode fields instead. Signed-off-by: Christoph Hellwig Date: Tue Sep 18 17:53:18 AEST 2007 Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-hch 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:29711a fs/xfs/linux-2.6/xfs_iops.c - 1.263 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_iops.c.diff?r1=text&tr1=1.263&r2=text&tr2=1.262&f=h - simplify validata_fields From owner-xfs@oss.sgi.com Wed Sep 19 09:12:05 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Sep 2007 09:12: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=-1.8 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 l8JGC3uw009019 for ; Wed, 19 Sep 2007 09:12: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 l8JGC4A5018188 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 19 Sep 2007 18:12:04 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8JGC3Cn018184 for xfs@oss.sgi.com; Wed, 19 Sep 2007 18:12:03 +0200 Date: Wed, 19 Sep 2007 18:12:03 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: [PATCH] kill XFS_INOBT_IS_FREE_DISK Message-ID: <20070919161202.GA18130@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: 12955 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 This macro is unused an all other acros in this family operate on native types, so we most likely won't grow a user either. Signed-off-by: Christoph Hellwig Index: linux-2.6.23-rc6/fs/xfs/xfs_ialloc_btree.h =================================================================== --- linux-2.6.23-rc6.orig/fs/xfs/xfs_ialloc_btree.h 2007-09-18 16:27:08.000000000 +0200 +++ linux-2.6.23-rc6/fs/xfs/xfs_ialloc_btree.h 2007-09-18 16:27:18.000000000 +0200 @@ -81,8 +81,6 @@ typedef struct xfs_btree_sblock xfs_inob #define XFS_INOBT_MASK(i) ((xfs_inofree_t)1 << (i)) #define XFS_INOBT_IS_FREE(rp,i) \ (((rp)->ir_free & XFS_INOBT_MASK(i)) != 0) -#define XFS_INOBT_IS_FREE_DISK(rp,i) \ - ((be64_to_cpu((rp)->ir_free) & XFS_INOBT_MASK(i)) != 0) #define XFS_INOBT_SET_FREE(rp,i) ((rp)->ir_free |= XFS_INOBT_MASK(i)) #define XFS_INOBT_CLR_FREE(rp,i) ((rp)->ir_free &= ~XFS_INOBT_MASK(i)) From owner-xfs@oss.sgi.com Wed Sep 19 09:28:16 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Sep 2007 09:28: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=-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 l8JGSCuw012194 for ; Wed, 19 Sep 2007 09:28:15 -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 l8J2RsLr003571; Wed, 19 Sep 2007 12:27:57 +1000 Received: (from lachlan@localhost) by redback.melbourne.sgi.com (8.13.8/8.13.8/Submit) id l8J2Rss2003570; Wed, 19 Sep 2007 12:27:54 +1000 Date: Wed, 19 Sep 2007 12:27:54 +1000 From: Lachlan McIlroy Message-Id: <200709190227.l8J2Rss2003570@redback.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 970705 - simplify vn_revalidate X-archive-position: 12956 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 simplify vn_revalidate No need to allocate a bhv_vattr_t on stack and call xfs_getattr to update a few fields in the Linux inode from the XFS inode, just do it directly. And yes, this function is in dire need of a better name and prototype, I'll do in a separate patch, though. Signed-off-by: Christoph Hellwig Date: Wed Sep 19 12:24:22 AEST 2007 Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-hch 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:29713a fs/xfs/linux-2.6/xfs_ioctl.c - 1.154 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ioctl.c.diff?r1=text&tr1=1.154&r2=text&tr2=1.153&f=h - simplify vn_revalidate fs/xfs/linux-2.6/xfs_vnode.c - 1.152 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vnode.c.diff?r1=text&tr1=1.152&r2=text&tr2=1.151&f=h - simplify vn_revalidate fs/xfs/linux-2.6/xfs_vnode.h - 1.142 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vnode.h.diff?r1=text&tr1=1.142&r2=text&tr2=1.141&f=h - simplify vn_revalidate fs/xfs/linux-2.6/xfs_iops.c - 1.264 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_iops.c.diff?r1=text&tr1=1.264&r2=text&tr2=1.263&f=h - simplify vn_revalidate fs/xfs/linux-2.6/xfs_ksyms.c - 1.72 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ksyms.c.diff?r1=text&tr1=1.72&r2=text&tr2=1.71&f=h - simplify vn_revalidate From owner-xfs@oss.sgi.com Wed Sep 19 10:27:26 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Sep 2007 10:27: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=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.2.0-pre1-r499012 Received: from astra.simleu.ro (astra.simleu.ro [80.97.18.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8JHRMuw023613 for ; Wed, 19 Sep 2007 10:27:25 -0700 Received: from teal.hq.k1024.org (k1024.vpn.cable.simleu.ro [10.1.2.8]) by astra.simleu.ro (Postfix) with ESMTP id DFD754D for ; Tue, 18 Sep 2007 21:33:23 +0300 (EEST) Received: by teal.hq.k1024.org (Postfix, from userid 4004) id 432B040A079; Tue, 18 Sep 2007 20:33:08 +0200 (CEST) Date: Tue, 18 Sep 2007 20:33:08 +0200 From: Iustin Pop To: linux-xfs@oss.sgi.com Subject: possible bug with non-default extent sizes Message-ID: <20070918183308.GB10782@teal.hq.k1024.org> Mail-Followup-To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.16 (2007-06-11) X-archive-position: 12957 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: xfs Hi, I've seen a strange behaviour related to sparse files with non-default extent sizes and I'm not sure if it's a bug or expected behaviour (certainly I was not expecting it). cd $TMPDIR /usr/sbin/xfs_io -c "extsize 16k" . python <; Wed, 19 Sep 2007 10:50:03 -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 l8JHo229012767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Sep 2007 13:50:03 -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 l8JHo2f6023451; Wed, 19 Sep 2007 13:50:02 -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 l8JHo1gY016693; Wed, 19 Sep 2007 13:50:01 -0400 Message-ID: <46F16149.8080503@sandeen.net> Date: Wed, 19 Sep 2007 12:50:01 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: Tim Shimmin CC: xfs@oss.sgi.com Subject: Re: [GIT PULL] XFS update for 2.6.23 References: <20070918112447.4315C58C4C09@chook.melbourne.sgi.com> In-Reply-To: <20070918112447.4315C58C4C09@chook.melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 12958 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 Tim Shimmin wrote: > Hi Linus, > > A couple of fixes for potential fs corruption. > And one fix to ensure that xfs_mru_cache is not > doing anything unless the cache has active objects. cc: trimmed... Seems like you should push the filestreams fix too? http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs-2.6.git;a=commitdiff;h=f4b26d9d73e38ff915720440b1c373fb239a4254 Thanks, -Eric p.s. just FWIW, here are the patches I'm currently carrying in F8: linux-2.6-xfs-avoid-replaying-inode-buffer-init.patch In for-linus linux-2.6-xfs-filesize-updates.patch In for-linus linux-2.6-xfs-filestreams-on-demand-MRU-reaping.patch In for-linus linux-2.6-xfs-fix-filestreams-free-func-cast.patch linux-2.6-xfs-optimize-away-dmapi-tests.patch linux-2.6-xfs-optimize-away-realtime-tests.patch linux-2.6-xfs-refactor-xfs_mountfs.patch linux-2.6-xfs-setfattr-32bit-compat.patch From owner-xfs@oss.sgi.com Wed Sep 19 10:58:56 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Sep 2007 10: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=0.1 required=5.0 tests=BAYES_50,J_CHICKENPOX_43 autolearn=no version=3.2.0-pre1-r499012 Received: from mail.edu.haifa.ac.il (mail.edu.haifa.ac.il [132.74.40.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8JHwruw032089 for ; Wed, 19 Sep 2007 10:58:55 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.edu.haifa.ac.il (Postfix) with ESMTP id 34B7114B1BD for ; Wed, 19 Sep 2007 10:49:29 +0200 (IST) X-Virus-Scanned: amavisd-new at edu.haifa.ac.il Received: from mail.edu.haifa.ac.il ([127.0.0.1]) by localhost (mail.edu.haifa.ac.il [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Czbk+eY6tdDt for ; Wed, 19 Sep 2007 10:49:29 +0200 (IST) Received: from kozanostra (leon.edu.haifa.ac.il [132.74.41.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.edu.haifa.ac.il (Postfix) with ESMTP id 0146ADE43 for ; Wed, 19 Sep 2007 10:49:29 +0200 (IST) From: "Leon Kolchinsky" To: Subject: Tips on xfs creation on MIPS R5000 machine running Linux? Date: Wed, 19 Sep 2007 10:48:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acf6mdps1LQ7z9oBSJupPr4e3J1ZRg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Message-Id: <20070919084929.0146ADE43@mail.edu.haifa.ac.il> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id l8JHwuuw032106 X-archive-position: 12959 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: leonk@construct.haifa.ac.il Precedence: bulk X-list: xfs Hello All, Finally I've got my hands on some nice R5000 Model O2 machine with IRIX 6.5 on it. # hinv CPU: MIPS R5000 Processor Chip Revision: 2.1 FPU: MIPS R5000 Floating Point Coprocessor Revision: 1.0 1 180 MHZ IP32 Processor Main memory size: 256 Mbytes Secondary unified instruction/data cache size: 512 Kbytes on Processor 0 Instruction cache size: 32 Kbytes Data cache size: 32 Kbytes FLASH PROM version 4.13 Integral SCSI controller 0: Version ADAPTEC 7880 Disk drive: unit 1 on SCSI controller 0 Disk drive: unit 2 on SCSI controller 0 CDROM: unit 4 on SCSI controller 0 Integral SCSI controller 1: Version ADAPTEC 7880 On-board serial ports: tty1 On-board serial ports: tty2 On-board EPP/ECP parallel port CRM graphics installed Integral Ethernet: ec0, version 1 Iris Audio Processor: version A3 revision 0 Video: MVP unit 0 version 1.4 AV: AV1 Card version 1, O2Cam type 1 version 0 connected. Vice: TRE I'm intending to install Gentoo on this machine and I need some advice. Following are the commands I've used to create and mount my partitions on some old x86 PC. a) Should I use the same values for all partitions on R5000 ? 1) Creating FS: mkfs.xfs -l internal,size=128m -d agcount=2 –d unwritten=0 /dev/hda1 2) Mount options: mount -o noatime,nodiratime,logbufs=8 Any suggestion for best performance configuration for XFS on this machine? b) If I'd like to replace the old 2GB disk to some new 80GB disk. Would PROM recognize it? Is there any special procedure? c) Anyone has any experience with Gentoo on MIPS as a desktop system (performance, device recognition (i.e. webcam) etc.)? Best Regards, Leon Kolchinsky From owner-xfs@oss.sgi.com Wed Sep 19 11:18:44 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Sep 2007 11: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=-4.2 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,UPPERCASE_50_75 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 l8JIIfuw003441 for ; Wed, 19 Sep 2007 11:18:43 -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 l8JIIFP5029724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Sep 2007 14:18:40 -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 l8JIFlTR003311; Wed, 19 Sep 2007 14:15:47 -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 l8JIFkfJ023157; Wed, 19 Sep 2007 14:15:46 -0400 Message-ID: <46F16752.1090702@sandeen.net> Date: Wed, 19 Sep 2007 13:15:46 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH] kill XFS_INOBT_IS_FREE_DISK References: <20070919161202.GA18130@lst.de> In-Reply-To: <20070919161202.GA18130@lst.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 12960 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: > This macro is unused an all other acros in this family operate on native > types, so we most likely won't grow a user either. Looks good to me... FWIW, here are the currently-unused macros in xfs cvs, if I'm massaging it right: _ACL_ACCESS_EXISTS _ACL_GET_ACCESS ATTR_DONTFOLLOW ATTR_TRUST BMBT_USE_64 CE_CONT current_clear_flags_nested FSYNC_INVAL FSYNC_NOWAIT HAVE_DM_EVENTTYPE_T HAVE_DM_RIGHT_T HAVE_SPLICE MODEMASK NDPP nested_spinlock nested_spinunlock SGI_ACL_DEFAULT_SIZE SV_KEYED SV_LIFO SV_PRIO sv_timedwait sv_timedwait_sig sv_wait_sig TRACE0 TRACE1 TRACE3 VN_ISBLK VN_ISCHR VN_ISLNK VREAD VSUID VSVTX VWRITE XB_GET_OWNER XFS_AT_ALL XFS_AT_SIZE_NOPERM XFS_AT_TIMES xfs_buf_ctob XFS_BUF_ISORDERED XFS_BUF_ISWRITE XFS_BUF_OFFSET XFS_BUF_SET_OFFSET XFS_BUF_SET_SIZE XFS_BUF_UNBUSY XFS_BUF_VSEMA XFS_DA_MAXHASH XFS_DFORK_ASIZE_HOST XFS_DFORK_DSIZE_HOST XFS_ERRLEVEL_OFF XFS_ERRTAG_DIOWRITE_IOERR XFS_ERRTAG_MAX XFS_ERRTAG_NOERROR XFS_ERRTAG_STRATCMPL_IOERR XFS_ERRTAG_STRATREAD_IOERR XFS_EXTENT_TOKEN_WR XFS_IO_DCXVN XFS_IOMAP_WRITE_UNWRITTEN XFS_IS_PQUOTA_RUNNING XFS_LID_PINNED XFS_MAX_LOG_BLOCKS XFS_MAX_LOG_BYTES xfs_probe_dmapi xfs_probe_ioops xfs_probe_quota XFS_QMOPT_DOLOG XFS_RANDOM_DIOWRITE_IOERR XFS_RANDOM_STRATCMPL_IOERR XFS_RANDOM_STRATREAD_IOERR XFS_SBF_NOFLAGS XFS_SB_VERSION2_REALFBITS XFS_SB_VERSION2_RESERVED1BIT XFS_SB_VERSION2_RESERVED4BIT XFS_SB_VERSION_ADDDALIGN XFS_SB_VERSION_ADDEXTFLGBIT XFS_SB_VERSION_ADDSHARED XFS_SB_VERSION_SUBEXTFLGBIT XFS_SB_VERSION_SUBSHARED XFS_SIZE_TOKEN_WR XFS_SX_VERSION xlog_exit XLOG_FMT_IRIX_BE XLOG_MIN_RECORD_BSHIFT XLOG_RHASH_BITS XLOG_SET XLOG_STATE_NOTUSED -Eric From owner-xfs@oss.sgi.com Wed Sep 19 11:31:20 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Sep 2007 11: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.2 required=5.0 tests=BAYES_50,DATE_IN_PAST_24_48, RCVD_IN_PSBL,VIRUS_WARNING179 autolearn=no version=3.2.0-pre1-r499012 Received: from mx.sidi.istruzione.it (mx8.sidi.istruzione.it [193.206.15.69]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8JIVGuw006120 for ; Wed, 19 Sep 2007 11:31:20 -0700 Received: from localhost (unknown [127.0.0.1]) by mx8.sidi.istruzione.it (Mail Service) with ESMTP id 5C898501ED for ; Tue, 18 Sep 2007 16:33:38 +0200 (CEST) Content-Type: multipart/report; report-type=delivery-status; boundary="----------=_1190126018-29406-0" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Subject: VIRUS (Worm.Mydoom.M): IN UNA E-MAIL DA LEI INVIATA In-Reply-To: <20070918143335.88153501E9@mx8.sidi.istruzione.it> Message-ID: From: "Content-filter at mx8.sidi.istruzione.it" To: Date: Tue, 18 Sep 2007 16:33:38 +0200 (CEST) X-archive-position: 12961 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: postmaster@mx8.sidi.istruzione.it Precedence: bulk X-list: xfs This is a multi-part message in MIME format... ------------=_1190126018-29406-0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit VIRUS ALERT Il sistema di scansione ha rilevato un problema in una email presumibilmente inviata da Lei -> (), per il seguente destinatario: -> direzione-abruzzo@istruzione.it La consegna del messaggio non e' potuta avvenire Di seguito i riferimenti della e-Mail inviata: ------------------------- BEGIN HEADERS ----------------------------- Return-Path: Received: from oss.sgi.com (unknown [85.45.242.114]) by mx8.sidi.istruzione.it (Mail Service) with ESMTP id 88153501E9 for ; Tue, 18 Sep 2007 16:33:35 +0200 (CEST) From: linux-xfs@oss.sgi.com To: direzione-abruzzo@istruzione.it Subject: Mail System Error - Returned Mail Date: Tue, 18 Sep 2007 16:33:24 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0014_37B15B68.0961D63E" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20070918143335.88153501E9@mx8.sidi.istruzione.it> -------------------------- END HEADERS ------------------------------ ------------=_1190126018-29406-0 Content-Type: message/delivery-status; name="dsn_status" Content-Disposition: inline; filename="dsn_status" Content-Transfer-Encoding: 7bit Content-Description: Delivery error report Reporting-MTA: dns; mx8.sidi.istruzione.it Received-From-MTA: smtp; mx.sidi.istruzione.it ([127.0.0.1]) Arrival-Date: Tue, 18 Sep 2007 16:33:38 +0200 (CEST) Original-Recipient: rfc822;direzione-abruzzo@istruzione.it Final-Recipient: rfc822;direzione-abruzzo@istruzione.it Action: failed Status: 5.7.1 Diagnostic-Code: smtp; 550-5.7.1 Rejected, id=29406-02-4 - VIRUS: 550 5.7.1 Worm.Mydoom.M Last-Attempt-Date: Tue, 18 Sep 2007 16:33:38 +0200 (CEST) ------------=_1190126018-29406-0 Content-Type: text/rfc822-headers; name="header" Content-Disposition: inline; filename="header" Content-Transfer-Encoding: 7bit Content-Description: Message headers Return-Path: Received: from oss.sgi.com (unknown [85.45.242.114]) by mx8.sidi.istruzione.it (Mail Service) with ESMTP id 88153501E9 for ; Tue, 18 Sep 2007 16:33:35 +0200 (CEST) From: linux-xfs@oss.sgi.com To: direzione-abruzzo@istruzione.it Subject: Mail System Error - Returned Mail Date: Tue, 18 Sep 2007 16:33:24 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0014_37B15B68.0961D63E" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20070918143335.88153501E9@mx8.sidi.istruzione.it> ------------=_1190126018-29406-0-- From owner-xfs@oss.sgi.com Wed Sep 19 11:54:32 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Sep 2007 11:54: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=3.1 required=5.0 tests=BAYES_50,HTML_MESSAGE, J_CHICKENPOX_43 autolearn=no version=3.2.0-pre1-r499012 Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.186]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8JIsUuw009824 for ; Wed, 19 Sep 2007 11:54:32 -0700 Received: by rv-out-0910.google.com with SMTP id k20so225946rvb for ; Wed, 19 Sep 2007 11:54:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=RHS4UY++E3rhECYd2xQmlY6hNUaYjTNHBRhOB9hCZQo=; b=fKNs7LlJD0TcAHvysN9+tltjqqkmwraG5DMPp8qpFxewl9lqIrysVWUTMB9emSMeddYZLbBV1ZAZHfw9A2oftKnNOjR2l6c0uxHTQfQsETo9hQlBSFKlSkU/gwLh44QC/JTeRtIXiGRJOvF/U7ZZtxzJbH5l91ROGQ9qeVWZ33o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=c/rS5C1yg4jbWsCJJFIFfm8J/5dglJ9WcYxDHDD9TA5WIf8xViPLEImuG+gcXhqtjX3nmaWTDzwtlwVp3oiiSq6aS8hnuF+gC6J9GVubxmtnuidqs3jQub35lfGKuw80Y6F542axXD44/TycwK3A4eI9EMpRy6nc3OFb6/v3/BY= Received: by 10.141.90.17 with SMTP id s17mr253755rvl.1190226575556; Wed, 19 Sep 2007 11:29:35 -0700 (PDT) Received: by 10.140.141.3 with HTTP; Wed, 19 Sep 2007 11:29:35 -0700 (PDT) Message-ID: <728b8e3b0709191129j27b7c319h2efd51ffc9cb64f3@mail.gmail.com> Date: Wed, 19 Sep 2007 20:29:35 +0200 From: "Jochen K." To: xfs@oss.sgi.com Subject: Cant find sunit and swidth on luks encrypted raid6 device MIME-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 4905 X-archive-position: 12962 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jochen.f.k@googlemail.com Precedence: bulk X-list: xfs Hi, I tried to create a xfs filesystem on a big encrypted mapped device but it isnt working at all. Also got latest kernel and kernel.org drivers for the raid controller. I hope you guys have any idea what might have happened here :) With ext3 its workin but i have no clue how to fix this problem. Kernel: 2.6.22.5-76.fc7 #1 SMP Thu Aug 30 13:47:21 EDT 2007 i686 i686 i386 GNU/Linux mdadm - v2.6.3 - 20th August 2007 cryptsetup 1.0.5 mkfs.xfs version 2.9.4 --added encryption-- /sbin/cryptsetup -c aes-cbc-essiv:sha256 -y -s 256 luksFormat /dev/md0 /sbin/cryptsetup luksOpen /dev/md0 raid6 [output without encryption] mkfs.xfs /dev/md0 meta-data=/dev/md0 isize=256 agcount=32, agsize=53412608 blks = sectsz=4096 attr=0 data = bsize=4096 blocks=1709202880, imaxpct=25 = sunit=32 swidth=448 blks, unwritten=1 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=32768, version=2 = sectsz=4096 sunit=1 blks, lazy-count=0 realtime =none extsz=1835008 blocks=0, rtextents=0 :Workin fine here! swidth/sunit = 14 used hdds which is useable space on the raid6 [output with encryption] mkfs.xfs -f /dev/mapper/raid6 meta-data=/dev/mapper/raid6 isize=256 agcount=32, agsize=53412581 blks = sectsz=512 attr=0 data = bsize=4096 blocks=1709202592, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks, lazy-count=0 realtime =none extsz=4096 blocks=0, rtextents=0 b7f57ad0: Badness in key lookup (length) bp=(bno 13673620728, len 131072 bytes) key=(bno 13673620728, len 4096 bytes) : not workin at all :/ [output with usin dev/md0 values] mkfs.xfs -s size=4096 -d sunit=32,swidth=448 -r extsize=1835008 /dev/mapper/raid6 meta-data=/dev/mapper/raid6 isize=256 agcount=32, agsize=53412584 blks = sectsz=4096 attr=0 data = bsize=4096 blocks=1709202592, imaxpct=25 = sunit=4 swidth=56 blks, unwritten=1 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=32768, version=2 = sectsz=4096 sunit=1 blks, lazy-count=0 realtime =none extsz=1835008 blocks=0, rtextents=0 b7f66ad0: Badness in key lookup (length) bp=(bno 13673620728, len 131072 bytes) key=(bno 13673620728, len 4096 bytes) :its still using wrong values here :/ [System Details] mdadm --detail /dev/md0 /dev/md0: Version : 00.90.03 Creation Time : Tue Sep 18 09:51:12 2007 Raid Level : raid6 Array Size : 6836811520 ( 6520.09 GiB 7000.89 GB) Used Dev Size : 488343680 (465.72 GiB 500.06 GB) Raid Devices : 16 Total Devices : 16 Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Wed Sep 19 19:53:29 2007 State : clean Active Devices : 16 Working Devices : 16 Failed Devices : 0 Spare Devices : 0 Chunk Size : 128K UUID : ae1231f4:1b4dc7a0:370b3052:b437b3a1 Events : 0.18 Number Major Minor RaidDevice State 0 8 17 0 active sync /dev/sdb1 1 8 33 1 active sync /dev/sdc1 2 8 49 2 active sync /dev/sdd1 3 8 65 3 active sync /dev/sde1 4 8 81 4 active sync /dev/sdf1 5 8 97 5 active sync /dev/sdg1 6 8 113 6 active sync /dev/sdh1 7 8 129 7 active sync /dev/sdi1 8 8 145 8 active sync /dev/sdj1 9 8 161 9 active sync /dev/sdk1 10 8 177 10 active sync /dev/sdl1 11 8 193 11 active sync /dev/sdm1 12 8 209 12 active sync /dev/sdn1 13 8 225 13 active sync /dev/sdo1 14 8 241 14 active sync /dev/sdp1 15 65 1 15 active sync /dev/sdq1 cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] md0 : active raid6 sdb1[0] sdq1[15] sdp1[14] sdo1[13] sdn1[12] sdm1[11] sdl1[10] sdk1[9] sdj1[8] sdi1[7] sdh1[6] sdg1[5] sdf1[4] sde1[3] sdd1[2] sdc1[1] 6836811520 blocks level 6, 128k chunk, algorithm 2 [16/16] [UUUUUUUUUUUUUUUU] ------------------------------------------------ Best regards, Jochen. [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Wed Sep 19 12:42:57 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Sep 2007 12:43:02 -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.3 required=5.0 tests=AWL,BAYES_20,J_CHICKENPOX_43, 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 l8JJgtuw029040 for ; Wed, 19 Sep 2007 12:42:57 -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 l8JJguhj014984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Sep 2007 15:42:56 -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 l8JJgtFh011062; Wed, 19 Sep 2007 15:42:55 -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 l8JJgtTx009367; Wed, 19 Sep 2007 15:42:55 -0400 Message-ID: <46F17BBE.7060304@sandeen.net> Date: Wed, 19 Sep 2007 14:42:54 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: "Jochen K." CC: xfs@oss.sgi.com Subject: Re: Cant find sunit and swidth on luks encrypted raid6 device References: <728b8e3b0709191129j27b7c319h2efd51ffc9cb64f3@mail.gmail.com> In-Reply-To: <728b8e3b0709191129j27b7c319h2efd51ffc9cb64f3@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 12963 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 Jochen K. wrote: > [output with encryption] > > mkfs.xfs -f /dev/mapper/raid6 > > meta-data=/dev/mapper/raid6 isize=256 agcount=32, agsize=53412581 > blks > = sectsz=512 attr=0 > data = bsize=4096 blocks=1709202592, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=1 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=32768, version=1 > = sectsz=512 sunit=0 blks, lazy-count=0 > realtime =none extsz=4096 blocks=0, rtextents=0 > b7f57ad0: Badness in key lookup (length) > bp=(bno 13673620728, len 131072 bytes) key=(bno 13673620728, len 4096 bytes) What generates the last two lines in the above message, and do you know what it indicates? For one thing, I notice your filesystem comes out as different sizes, 1709202880 without encryption, 1709202592 with encryption (i.e., smaller) (these are 4k block units) I assume the error message is trying to read or write 131072 bytes from the offset 13673620728 * 512, or: 7000893812736 -> 7000893943807 The filesystem claims to end at: 1709202592 * 4096 = 7000893816832 which appears to be in the middle of the above range. 131072 is the amount that mkfs.xfs tries to zero at the end of a block device. (you could confirm that it's this write by stracing mkfs, perhaps?) It looks like somebody has the size wrong... What does "blockdev --getsize64" and "blockdev --getsize" and/or /proc/partitions say about how big /dev/mapper/raid6 is? Can you use dd to write to the last 128k of the device, as reported by blockdev --getsize64? -Eric From owner-xfs@oss.sgi.com Wed Sep 19 13:05:54 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Sep 2007 13:05: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.9 required=5.0 tests=AWL,BAYES_50,HTML_MESSAGE, J_CHICKENPOX_43,J_CHICKENPOX_44 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 l8JK5quw002088 for ; Wed, 19 Sep 2007 13:05:54 -0700 Received: by wa-out-1112.google.com with SMTP id k22so384080waf for ; Wed, 19 Sep 2007 13:05:54 -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=L2Rd8mbGVL7brLE64osbpQYWT5I2q0arF0WpqYFxzQo=; b=VkMH0pKrISSrj/Q05y4SUYwLRHchX3CC+cEMmCHsEiAD9va8GOGe1KXmR+k39oa2Lwpt3YU57YRQ3cS8v0f4a6Cw1ZfhejlUu3J+pFvqc1nEWGqWW3J8alUHtfn5lGrJcGJemcFkV6CsLDR4A4YyR0N8aGX+Khjyekbwrfs0ZeI= 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=Cd8FlWeBw8ZFQE3o0pCGzGC3y3OQlkFXU3qk00RzrkqLnBG6V57hH1zCMntnQwjWXCN7DiPJNTre0GQLTn3v2eE3ibNZ1LHPwo6LnG5rQ7zpgm0vng0wUCwJhCDTSt2FVoh3kldz2RDawQHMjifbjx0leNzddyMiivqPYbm1fCU= Received: by 10.114.168.1 with SMTP id q1mr1117826wae.1190230832623; Wed, 19 Sep 2007 12:40:32 -0700 (PDT) Received: by 10.114.123.20 with HTTP; Wed, 19 Sep 2007 12:40:32 -0700 (PDT) Message-ID: Date: Thu, 20 Sep 2007 01:10:32 +0530 From: "Bhagi rathi" To: "Jochen K." Subject: Re: Cant find sunit and swidth on luks encrypted raid6 device Cc: xfs@oss.sgi.com In-Reply-To: <728b8e3b0709191129j27b7c319h2efd51ffc9cb64f3@mail.gmail.com> MIME-Version: 1.0 References: <728b8e3b0709191129j27b7c319h2efd51ffc9cb64f3@mail.gmail.com> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 5696 X-archive-position: 12964 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 Can we get strace output of mkfs.xfs -f /dev/mapper/raid6. It seems that we are trying to access beyond the end of the encrypted device. My guess is that we are reported with wrong size from DKIOCGETBLOCKCOUNT ioctl. The easiest way to get configured is tell the size of the device by yourself through mkfs.dvfs -d size= and all other parameters you want for sw, su, etc. This may work and give a try:) -Cheers, Bhagi. On 9/19/07, Jochen K. wrote: > > Hi, > > I tried to create a xfs filesystem on a big encrypted mapped device but it > isnt working at all. > Also got latest kernel and kernel.org drivers for the raid controller. > I hope you guys have any idea what might have happened here :) > With ext3 its workin but i have no clue how to fix this problem. > > > Kernel: 2.6.22.5-76.fc7 #1 SMP Thu Aug 30 13:47:21 EDT 2007 i686 i686 i386 > GNU/Linux > mdadm - v2.6.3 - 20th August 2007 > cryptsetup 1.0.5 > mkfs.xfs version 2.9.4 > > --added encryption-- > /sbin/cryptsetup -c aes-cbc-essiv:sha256 -y -s 256 luksFormat /dev/md0 > /sbin/cryptsetup luksOpen /dev/md0 raid6 > > [output without encryption] > > mkfs.xfs /dev/md0 > > meta-data=/dev/md0 isize=256 agcount=32, agsize=53412608 > blks > = sectsz=4096 attr=0 > data = bsize=4096 blocks=1709202880, > imaxpct=25 > = sunit=32 swidth=448 blks, unwritten=1 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=32768, version=2 > = sectsz=4096 sunit=1 blks, lazy-count=0 > realtime =none extsz=1835008 blocks=0, rtextents=0 > > :Workin fine here! swidth/sunit = 14 used hdds which is useable space on > the > raid6 > > [output with encryption] > > mkfs.xfs -f /dev/mapper/raid6 > > meta-data=/dev/mapper/raid6 isize=256 agcount=32, agsize=53412581 > blks > = sectsz=512 attr=0 > data = bsize=4096 blocks=1709202592, > imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=1 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=32768, version=1 > = sectsz=512 sunit=0 blks, lazy-count=0 > realtime =none extsz=4096 blocks=0, rtextents=0 > b7f57ad0: Badness in key lookup (length) > bp=(bno 13673620728, len 131072 bytes) key=(bno 13673620728, len 4096 > bytes) > > : not workin at all :/ > > [output with usin dev/md0 values] > > mkfs.xfs -s size=4096 -d sunit=32,swidth=448 -r extsize=1835008 > /dev/mapper/raid6 > > meta-data=/dev/mapper/raid6 isize=256 agcount=32, agsize=53412584 > blks > = sectsz=4096 attr=0 > data = bsize=4096 blocks=1709202592, > imaxpct=25 > = sunit=4 swidth=56 blks, unwritten=1 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=32768, version=2 > = sectsz=4096 sunit=1 blks, lazy-count=0 > realtime =none extsz=1835008 blocks=0, rtextents=0 > b7f66ad0: Badness in key lookup (length) > bp=(bno 13673620728, len 131072 bytes) key=(bno 13673620728, len 4096 > bytes) > > > :its still using wrong values here :/ > > [System Details] > > mdadm --detail /dev/md0 > /dev/md0: > Version : 00.90.03 > Creation Time : Tue Sep 18 09:51:12 2007 > Raid Level : raid6 > Array Size : 6836811520 ( 6520.09 GiB 7000.89 GB) > Used Dev Size : 488343680 (465.72 GiB 500.06 GB) > Raid Devices : 16 > Total Devices : 16 > Preferred Minor : 0 > Persistence : Superblock is persistent > > Update Time : Wed Sep 19 19:53:29 2007 > State : clean > Active Devices : 16 > Working Devices : 16 > Failed Devices : 0 > Spare Devices : 0 > > Chunk Size : 128K > > UUID : ae1231f4:1b4dc7a0:370b3052:b437b3a1 > Events : 0.18 > > Number Major Minor RaidDevice State > 0 8 17 0 active sync /dev/sdb1 > 1 8 33 1 active sync /dev/sdc1 > 2 8 49 2 active sync /dev/sdd1 > 3 8 65 3 active sync /dev/sde1 > 4 8 81 4 active sync /dev/sdf1 > 5 8 97 5 active sync /dev/sdg1 > 6 8 113 6 active sync /dev/sdh1 > 7 8 129 7 active sync /dev/sdi1 > 8 8 145 8 active sync /dev/sdj1 > 9 8 161 9 active sync /dev/sdk1 > 10 8 177 10 active sync /dev/sdl1 > 11 8 193 11 active sync /dev/sdm1 > 12 8 209 12 active sync /dev/sdn1 > 13 8 225 13 active sync /dev/sdo1 > 14 8 241 14 active sync /dev/sdp1 > 15 65 1 15 active sync /dev/sdq1 > > cat /proc/mdstat > Personalities : [raid6] [raid5] [raid4] > md0 : active raid6 sdb1[0] sdq1[15] sdp1[14] sdo1[13] sdn1[12] sdm1[11] > sdl1[10] sdk1[9] sdj1[8] sdi1[7] sdh1[6] sdg1[5] sdf1[4] sde1[3] sdd1[2] > sdc1[1] > 6836811520 blocks level 6, 128k chunk, algorithm 2 [16/16] > [UUUUUUUUUUUUUUUU] > > ------------------------------------------------ > > > Best regards, > Jochen. > > > [[HTML alternate version deleted]] > > > [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Wed Sep 19 13:22:46 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Sep 2007 13:22: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.8 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 l8JKMguw006205 for ; Wed, 19 Sep 2007 13:22:46 -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 l8JKMgA5032532 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 19 Sep 2007 22:22:42 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8JKMf0G032530; Wed, 19 Sep 2007 22:22:41 +0200 Date: Wed, 19 Sep 2007 22:22:40 +0200 From: Christoph Hellwig To: Eric Sandeen Cc: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: [PATCH] kill XFS_INOBT_IS_FREE_DISK Message-ID: <20070919202239.GA32475@lst.de> References: <20070919161202.GA18130@lst.de> <46F16752.1090702@sandeen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46F16752.1090702@sandeen.net> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 12965 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 Wed, Sep 19, 2007 at 01:15:46PM -0500, Eric Sandeen wrote: > Christoph Hellwig wrote: > > This macro is unused an all other acros in this family operate on native > > types, so we most likely won't grow a user either. > > Looks good to me... FWIW, here are the currently-unused macros in xfs > cvs, if I'm massaging it right: > > _ACL_ACCESS_EXISTS > _ACL_GET_ACCESS > SGI_ACL_DEFAULT_SIZE will go away with conversion to generic posix acl code. > ATTR_DONTFOLLOW > ATTR_TRUST might go away with conversion to generic xattr code. > BMBT_USE_64 I have a patch for this one. > CE_CONT > current_clear_flags_nested > FSYNC_INVAL > FSYNC_NOWAIT We should probably kill these. > HAVE_DM_EVENTTYPE_T > HAVE_DM_RIGHT_T no idea for these. > HAVE_SPLICE Backward compat? > MODEMASK > NDPP kill? > nested_spinlock > nested_spinunlock don't your patches kill these? > SV_KEYED > SV_LIFO > SV_PRIO > sv_timedwait > sv_timedwait_sig > sv_wait_sig should probably go. > TRACE0 > TRACE1 > TRACE3 kill? > VN_ISBLK > VN_ISCHR > VN_ISLNK > VREAD > VSUID > VSVTX > VWRITE I have a patch to kill all this gunk. > XFS_AT_ALL > XFS_AT_SIZE_NOPERM > XFS_AT_TIMES I have some patches patch to kill XFS_AT_* > XFS_DFORK_ASIZE_HOST > XFS_DFORK_DSIZE_HOST I have some patches to rework XFS_{C,D,I}FORK* > XB_GET_OWNER > xfs_buf_ctob > XFS_BUF_ISORDERED > XFS_BUF_ISWRITE > XFS_BUF_OFFSET > XFS_BUF_SET_OFFSET > XFS_BUF_SET_SIZE > XFS_BUF_UNBUSY > XFS_BUF_VSEMA not sure what to do with all the buf stuff. > XFS_IO_DCXVN > XFS_IOMAP_WRITE_UNWRITTEN should be gone with the patches I sent to the list. > xfs_probe_dmapi > xfs_probe_ioops > xfs_probe_quota these are gone in a patch that I sent to the list already. > XFS_SBF_NOFLAGS > XFS_SB_VERSION2_REALFBITS > XFS_SB_VERSION2_RESERVED1BIT > XFS_SB_VERSION2_RESERVED4BIT > XFS_SB_VERSION_ADDDALIGN > XFS_SB_VERSION_ADDEXTFLGBIT > XFS_SB_VERSION_ADDSHARED > XFS_SB_VERSION_SUBEXTFLGBIT > XFS_SB_VERSION_SUBSHARED I suspect there are kind expected to be unused. From owner-xfs@oss.sgi.com Wed Sep 19 13:29:55 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Sep 2007 13:29: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=-4.3 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 l8JKTquw007823 for ; Wed, 19 Sep 2007 13:29:54 -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 l8JKTTpW011866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Sep 2007 16:29:29 -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 l8JKTSdC000907; Wed, 19 Sep 2007 16:29: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 l8JKTRvD020194; Wed, 19 Sep 2007 16:29:28 -0400 Message-ID: <46F186A7.7050301@sandeen.net> Date: Wed, 19 Sep 2007 15:29:27 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH] kill XFS_INOBT_IS_FREE_DISK References: <20070919161202.GA18130@lst.de> <46F16752.1090702@sandeen.net> <20070919202239.GA32475@lst.de> In-Reply-To: <20070919202239.GA32475@lst.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 12966 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: > >> HAVE_SPLICE > > > Backward compat? ah, yeah, it's for 2.4: 0 xfs/linux-2.6/xfs_linux.h 104 #define HAVE_SPLICE 1 fs/xfs/xfs_vnodeops.c 4718 #ifdef HAVE_SPLICE can probably go soon eh. HAVE_PERCPU_SB can too (not sure why it's not in my list) There may be others that are just for 2.4. > >> nested_spinlock >> nested_spinunlock > > don't your patches kill these? yeah, I just checked pristine cvs. -Eric From owner-xfs@oss.sgi.com Wed Sep 19 13:43:58 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Sep 2007 13:44: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.1 required=5.0 tests=AWL,BAYES_00,UPPERCASE_50_75 autolearn=no 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 l8JKhuuw010171 for ; Wed, 19 Sep 2007 13:43:58 -0700 Received: from mail.aconex.com (castle.yarra.acx [192.168.3.3]) by postoffice.aconex.com (Postfix) with ESMTP id D641E127C5EE; Thu, 20 Sep 2007 06:43:58 +1000 (EST) Received: from 192.168.3.1 (proxying for 211.28.181.43) (SquirrelMail authenticated user nscott) by mail.aconex.com with HTTP; Thu, 20 Sep 2007 06:44:18 +1000 (EST) Message-ID: <54685.192.168.3.1.1190234658.squirrel@mail.aconex.com> In-Reply-To: <20070919202239.GA32475@lst.de> References: <20070919161202.GA18130@lst.de> <46F16752.1090702@sandeen.net> <20070919202239.GA32475@lst.de> Date: Thu, 20 Sep 2007 06:44:18 +1000 (EST) Subject: Re: [PATCH] kill XFS_INOBT_IS_FREE_DISK From: nscott@aconex.com To: "Christoph Hellwig" Cc: "Eric Sandeen" , "Christoph Hellwig" , xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.8-4.el4.centos MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-archive-position: 12967 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 Wed, Sep 19, 2007 at 01:15:46PM -0500, Eric Sandeen wrote: >> Christoph Hellwig wrote: >> ... >> XFS_SBF_NOFLAGS >> XFS_SB_VERSION2_REALFBITS >> XFS_SB_VERSION2_RESERVED1BIT >> XFS_SB_VERSION2_RESERVED4BIT >> XFS_SB_VERSION_ADDDALIGN >> XFS_SB_VERSION_ADDEXTFLGBIT >> XFS_SB_VERSION_ADDSHARED >> XFS_SB_VERSION_SUBEXTFLGBIT >> XFS_SB_VERSION_SUBSHARED > > I suspect there are kind expected to be unused. > They're used in userspace IIRC. (Well, some - probably not the RESERVED ones) cheers. -- Nathan From owner-xfs@oss.sgi.com Wed Sep 19 15:34:02 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Sep 2007 15:34: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=-4.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43, 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 l8JMXxuw027365 for ; Wed, 19 Sep 2007 15:34:02 -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 l8JMY1kd023732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Sep 2007 18:34:01 -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 l8JMY0Bv018066; Wed, 19 Sep 2007 18:34:00 -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 l8JMXxDg012538; Wed, 19 Sep 2007 18:34:00 -0400 Message-ID: <46F1A3D7.5090805@sandeen.net> Date: Wed, 19 Sep 2007 17:33:59 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: Eric Sandeen CC: "Jochen K." , xfs@oss.sgi.com Subject: Re: Cant find sunit and swidth on luks encrypted raid6 device References: <728b8e3b0709191129j27b7c319h2efd51ffc9cb64f3@mail.gmail.com> <46F17BBE.7060304@sandeen.net> In-Reply-To: <46F17BBE.7060304@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 12968 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: > What does "blockdev --getsize64" and "blockdev --getsize" and/or > /proc/partitions say about how big /dev/mapper/raid6 is? > > Can you use dd to write to the last 128k of the device, as reported by > blockdev --getsize64? Not a cryptsetup problem, FWIW: [root@inode obj]# /tmp/truncate fsfile 7000893943808 Truncating fsfile to 7000893943808 [root@inode obj]# ls -l fsfile -rw-r--r-- 1 root root 7000893943808 Sep 19 17:23 fsfile [root@inode obj]# mkfs.xfs -f fsfile meta-data=fsfile isize=256 agcount=32, agsize=53412581 blks = sectsz=512 attr=0 data = bsize=4096 blocks=1709202592, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks, lazy-count=0 realtime =none extsz=4096 blocks=0, rtextents=0 2b2d4c133680: Badness in key lookup (length) bp=(bno 13673620728, len 131072 bytes) key=(bno 13673620728, len 4096 bytes) If we take out the pwrite that does the end-of-device zeroing, we don't get the error... but that's been there since forever, so again, I'm a bit confused here. -Eric From owner-xfs@oss.sgi.com Wed Sep 19 15:39:27 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Sep 2007 15:39: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_05 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 l8JMdLuw028435 for ; Wed, 19 Sep 2007 15:39:26 -0700 Received: from mail.aconex.com (castle.yarra.acx [192.168.3.3]) by postoffice.aconex.com (Postfix) with ESMTP id DEA6E127C565; Thu, 20 Sep 2007 08:39:23 +1000 (EST) Received: from 192.168.3.1 (proxying for 211.28.181.43) (SquirrelMail authenticated user nscott) by mail.aconex.com with HTTP; Thu, 20 Sep 2007 08:39:43 +1000 (EST) Message-ID: <33249.192.168.3.1.1190241583.squirrel@mail.aconex.com> In-Reply-To: <46F1A3D7.5090805@sandeen.net> References: <728b8e3b0709191129j27b7c319h2efd51ffc9cb64f3@mail.gmail.com> <46F17BBE.7060304@sandeen.net> <46F1A3D7.5090805@sandeen.net> Date: Thu, 20 Sep 2007 08:39:43 +1000 (EST) Subject: Re: Cant find sunit and swidth on luks encrypted raid6 device From: nscott@aconex.com To: "Eric Sandeen" Cc: "Jochen K." , xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.8-4.el4.centos MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-archive-position: 12969 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 > Eric Sandeen wrote: > > 2b2d4c133680: Badness in key lookup (length) > bp=(bno 13673620728, len 131072 bytes) key=(bno 13673620728, len 4096 > bytes) > > If we take out the pwrite that does the end-of-device zeroing, we don't > get the error... but that's been there since forever, so again, I'm a > bit confused here. libxfs has been changing alot - most likely the problem lies in the buffer caching code there - Barry will probably recognise the error (when he gets online). cheers. -- Nathan From owner-xfs@oss.sgi.com Wed Sep 19 15:47:54 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Sep 2007 15:47: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=-4.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_31, 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 l8JMlZuw029928 for ; Wed, 19 Sep 2007 15:47: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 l8JMlX68004371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Sep 2007 18:47:33 -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 l8JMlX1F022944; Wed, 19 Sep 2007 18:47:33 -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 l8JMlWRq015355; Wed, 19 Sep 2007 18:47:33 -0400 Message-ID: <46F1A703.6040309@sandeen.net> Date: Wed, 19 Sep 2007 17:47:31 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: nscott@aconex.com CC: "Jochen K." , xfs@oss.sgi.com Subject: Re: Cant find sunit and swidth on luks encrypted raid6 device References: <728b8e3b0709191129j27b7c319h2efd51ffc9cb64f3@mail.gmail.com> <46F17BBE.7060304@sandeen.net> <46F1A3D7.5090805@sandeen.net> <33249.192.168.3.1.1190241583.squirrel@mail.aconex.com> In-Reply-To: <33249.192.168.3.1.1190241583.squirrel@mail.aconex.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 12970 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 nscott@aconex.com wrote: >> Eric Sandeen wrote: >> >> 2b2d4c133680: Badness in key lookup (length) >> bp=(bno 13673620728, len 131072 bytes) key=(bno 13673620728, len 4096 >> bytes) >> >> If we take out the pwrite that does the end-of-device zeroing, we don't >> get the error... but that's been there since forever, so again, I'm a >> bit confused here. > > libxfs has been changing alot - most likely the problem lies in the buffer > caching > code there - Barry will probably recognise the error (when he gets online). --- xfs-cmds/xfsprogs/libxfs/rdwr.c 2007/02/21 14:37:52 1.34 +++ xfs-cmds/xfsprogs/libxfs/rdwr.c 2007/07/16 15:55:26 1.35 @@ -24,6 +24,8 @@ #define BDSTRAT_SIZE (256 * 1024) #define min(x, y) ((x) < (y) ? (x) : (y)) +#define IO_BCOMPARE_CHECK + Yep.... :) -Eric > cheers. > > -- > Nathan > > From owner-xfs@oss.sgi.com Wed Sep 19 15:50:28 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Sep 2007 15:50: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.8 required=5.0 tests=AWL,BAYES_00,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 l8JMoPuw030645 for ; Wed, 19 Sep 2007 15:50:28 -0700 Received: by rv-out-0910.google.com with SMTP id k20so269981rvb for ; Wed, 19 Sep 2007 15:50:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=hx7NayGI+y87lCS8XgV+dsGV8NBzSdR7ymH4MTlrmLY=; b=qvOKHrSm3jrw+sC5hkttZB7w1Wu0HUrkJZzMaM5VCNPFsUizwDzCiPgOeAZqge2+h460/m+cJ668STiab+rqf7+1x0O7Zw7Ud2Qo8oX+V9hYZ+3AdtOE+hO9Q3pIp1quJxaqxWbKhqBdlDG+ck95iygSGYyGhGJOYOeB1OrBjI8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=m7FI+OiAL/AjrlKcSLNPK0y4gFyMMu6EqQi9v80qIIM1xbQVu0ijPHZ9+1Hjlpd8SFjyjVQdXQeuJZGiusJ9HvGkK0tj1bixz9yztzK75cJt2CHf9cKkBx62vAcNQ5y9M+0OnbhxWo4kSvzZHwa4glo2HBllMd+QHIpHjgz8fV0= Received: by 10.141.19.16 with SMTP id w16mr308757rvi.1190242228133; Wed, 19 Sep 2007 15:50:28 -0700 (PDT) Received: by 10.140.141.3 with HTTP; Wed, 19 Sep 2007 15:50:28 -0700 (PDT) Message-ID: <728b8e3b0709191550q3adad31bx53e759f66808d8b@mail.gmail.com> Date: Thu, 20 Sep 2007 00:50:28 +0200 From: "Jochen K." To: "Eric Sandeen" Subject: Re: Cant find sunit and swidth on luks encrypted raid6 device Cc: nscott@aconex.com, xfs@oss.sgi.com In-Reply-To: <46F1A703.6040309@sandeen.net> MIME-Version: 1.0 References: <728b8e3b0709191129j27b7c319h2efd51ffc9cb64f3@mail.gmail.com> <46F17BBE.7060304@sandeen.net> <46F1A3D7.5090805@sandeen.net> <33249.192.168.3.1.1190241583.squirrel@mail.aconex.com> <46F1A703.6040309@sandeen.net> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 1201 X-archive-position: 12971 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jochen.f.k@googlemail.com Precedence: bulk X-list: xfs Hi, Eric Here is the output you wanted. I also did some debuging with strace but its kinda big to paste it in here. I also tried with the size option using a smaller device size which was working but still using wrong optimized values for the raid6 device. I guess you found the bug up there so should I add that and recompile xfsprogs to try again ? mkfs.xfs -f -dsize=5t /dev/mapper/raid6 meta-data=/dev/mapper/raid6 isize=256 agcount=32, agsize=41943040 blks = sectsz=512 attr=0 data = bsize=4096 blocks=1342177280, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks, lazy-count=0 realtime =none extsz=4096 blocks=0, rtextents=0 Here is the output of blockdev and proc: blockdev --getsize64 /dev/mapper/raid6 7000893943808 cat /proc/partitions 9 0 6836811520 md0 7 0 2150400 loop0 253 2 2149372 dm-2 253 3 6836810492 dm-3 -Jochen [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Wed Sep 19 15:56:57 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Sep 2007 15:57:00 -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_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 l8JMutuw031963 for ; Wed, 19 Sep 2007 15:56:57 -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 l8JMutCU009318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Sep 2007 18:56:55 -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 l8JMutwA026614; Wed, 19 Sep 2007 18:56:55 -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 l8JMusBb017181; Wed, 19 Sep 2007 18:56:54 -0400 Message-ID: <46F1A936.8060706@sandeen.net> Date: Wed, 19 Sep 2007 17:56:54 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: "Jochen K." CC: nscott@aconex.com, xfs@oss.sgi.com Subject: Re: Cant find sunit and swidth on luks encrypted raid6 device References: <728b8e3b0709191129j27b7c319h2efd51ffc9cb64f3@mail.gmail.com> <46F17BBE.7060304@sandeen.net> <46F1A3D7.5090805@sandeen.net> <33249.192.168.3.1.1190241583.squirrel@mail.aconex.com> <46F1A703.6040309@sandeen.net> <728b8e3b0709191550q3adad31bx53e759f66808d8b@mail.gmail.com> In-Reply-To: <728b8e3b0709191550q3adad31bx53e759f66808d8b@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-archive-position: 12972 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 Jochen K. wrote: > Hi, Eric > > Here is the output you wanted. I also did some debuging with strace but > its kinda big to paste it in here. > I also tried with the size option using a smaller device size which was > working but still using wrong optimized values for the raid6 device. > I guess you found the bug up there so should I add that and recompile > xfsprogs to try again ? Let's let Barry chime in. I got off on a luks thing, saw "key lookup" and thought it was unique to luks. Didn't realize that message came from libxfs :) Oh well... Also FWIW, the issue w/ sunit/swidth is unrelated to the error message. It has more to do with xfs not knowing how to get that geometry out of the encrypted block device (and hmmm is it even relevant in that case? As long as it just encrypts each individual block, I suppose it still is relevant). -Eric From owner-xfs@oss.sgi.com Wed Sep 19 16:34:18 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Sep 2007 16:34: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.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 l8JNYBuw009138 for ; Wed, 19 Sep 2007 16:34: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 JAA02937 for ; Thu, 20 Sep 2007 09:34:13 +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 l8JNYCdD29802686 for ; Thu, 20 Sep 2007 09:34:13 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l8JNYBpm29705449 for linux-xfs@oss.sgi.com; Thu, 20 Sep 2007 09:34:11 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Thu, 20 Sep 2007 09:34:11 +1000 From: David Chinner To: linux-xfs@oss.sgi.com Subject: Re: possible bug with non-default extent sizes Message-ID: <20070919233411.GP995458@sgi.com> References: <20070918183308.GB10782@teal.hq.k1024.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070918183308.GB10782@teal.hq.k1024.org> User-Agent: Mutt/1.4.2.1i X-archive-position: 12973 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 18, 2007 at 08:33:08PM +0200, Iustin Pop wrote: > Hi, > > I've seen a strange behaviour related to sparse files with non-default > extent sizes and I'm not sure if it's a bug or expected behaviour > (certainly I was not expecting it). > > cd $TMPDIR > /usr/sbin/xfs_io -c "extsize 16k" . > python < f = open("test", "w+") > f.truncate(1024*64) > f.write("A") > f.close() > EOF FWIW: /usr/sbin/xfs_io -f \ -c "extsize 16k" \ -c "truncate 64k" \ -c "pwrite 0 4k" \ -c "bmap -vp" \ $TMPDIR/test Is my usual way of writing these quick sort of tests. > what I see if I look at the file now with od for example, is that the > first filesystem block contains "A" and then zeroes, but after the 4k > offset the file contains stale data from the disk. Yeah, there's a bug there that I've been trying to work out the best way to fix - basically the delalloc is supposed to convert the extent size to 4k of written data and 12k of unwritten data, but the unwritten flag is not getting set on the unwritten section. and so we are allocating 16k when we are only writing to 4k. > I haven't found any bug related to this, and I would not expect stale > data (since this is doable even by normal users, and maybe could leak > old data). > > Is this a known issue? Yes - it was discovered a few months back amongst a raft of other issues similar to this. This is the only one I know of that I haven't fixed yet - I've had a couple of attempts and they drowned in complexity. I'll have another look at it seeing as I have a better understanding of what is supposed to happen since I last tried to fix it.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Sep 19 17:50:50 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Sep 2007 17:50: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.2 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 l8K0oiuw018919 for ; Wed, 19 Sep 2007 17:50:48 -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 KAA04466; Thu, 20 Sep 2007 10:50:39 +1000 To: "Eric Sandeen" , "Jochen K." Subject: Re: Cant find sunit and swidth on luks encrypted raid6 device 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: <728b8e3b0709191129j27b7c319h2efd51ffc9cb64f3@mail.gmail.com> <46F17BBE.7060304@sandeen.net> Date: Thu, 20 Sep 2007 10:54:33 +1000 Message-ID: In-Reply-To: <46F17BBE.7060304@sandeen.net> User-Agent: Opera Mail/9.10 (Win32) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by oss.sgi.com id l8K0oouw018937 X-archive-position: 12974 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 Thu, 20 Sep 2007 05:42:54 +1000, Eric Sandeen wrote: > Jochen K. wrote: > >> [output with encryption] >> >> mkfs.xfs -f /dev/mapper/raid6 >> >> meta-data=/dev/mapper/raid6 isize=256 agcount=32, >> agsize=53412581 >> blks >> = sectsz=512 attr=0 >> data = bsize=4096 blocks=1709202592, >> imaxpct=25 >> = sunit=0 swidth=0 blks, unwritten=1 >> naming =version 2 bsize=4096 >> log =internal log bsize=4096 blocks=32768, version=1 >> = sectsz=512 sunit=0 blks, lazy-count=0 >> realtime =none extsz=4096 blocks=0, rtextents=0 >> b7f57ad0: Badness in key lookup (length) >> bp=(bno 13673620728, len 131072 bytes) key=(bno 13673620728, len 4096 >> bytes) > > What generates the last two lines in the above message, and do you know > what it indicates? One problem I discovered with libxfs and repair in the prefetch is the handling of I/O to a block offset, but with different I/O size. libxfs cannot handle this, so I enabled IO_BCOMPARE_CHECK to detect any I/Os that have the same offset but different length. This is a bad thing for libxfs and it can lose data coherency. I need to know what mkfs is doing at that offset. Probably the simplest way is to enable IO_DEBUG, rebuild and observe all the I/Os to libxfs. Since it's mkfs, there shouldn't be too many I/Os in total. If you want to be clever, use XFS_BUF_TRACING with gdb, that will pin-point the exact location :) Regards, Barry. From owner-xfs@oss.sgi.com Wed Sep 19 18:49:23 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Sep 2007 18: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.9 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_32, J_CHICKENPOX_42,J_CHICKENPOX_43,J_CHICKENPOX_44,J_CHICKENPOX_45, J_CHICKENPOX_46,J_CHICKENPOX_47,J_CHICKENPOX_48,J_CHICKENPOX_62, J_CHICKENPOX_63,J_CHICKENPOX_66,J_CHICKENPOX_74,SPF_HELO_PASS,WHOIS_MYPRIVREG autolearn=no version=3.2.0-pre1-r499012 Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8K1nMuw027860 for ; Wed, 19 Sep 2007 18:49:23 -0700 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1IYAt5-00075k-W6 for xfs@oss.sgi.com; Wed, 19 Sep 2007 18:31:28 -0700 Message-ID: <12789210.post@talk.nabble.com> Date: Wed, 19 Sep 2007 18:31:27 -0700 (PDT) From: Hxsrmeng To: xfs@oss.sgi.com Subject: Re: Review: Concurrent Multi-File Data Streams In-Reply-To: <20070511003606.GB85884050@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: hxsrmeng@gmail.com References: <20070511003606.GB85884050@sgi.com> X-archive-position: 12975 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hxsrmeng@gmail.com Precedence: bulk X-list: xfs Is this feature included in the linux-2.6-xfs kernel downloaded from cvs@oss.sgi.com? If it is included, in order to enable it, which control flag should be set? If I write many files concurrently, should each file be stored in contiguous blocks in the same AG? Thanks David Chinner wrote: > > > Concurrent Multi-File Data Streams > > In media spaces, video is often stored in a frame-per-file format. > When dealing with uncompressed realtime HD video streams in this format, > it is crucial that files do not get fragmented and that multiple files > a placed contiguously on disk. > > When multiple streams are being ingested and played out at the same > time, it is critical that the filesystem does not cross the streams > and interleave them together as this creates seek and readahead > cache miss latency and prevents both ingest and playout from meeting > frame rate targets. > > This patches creates a "stream of files" concept into the allocator > to place all the data from a single stream contiguously on disk so > that RAID array readahead can be used effectively. Each additional > stream gets placed in different allocation groups within the > filesystem, thereby ensuring that we don't cross any streams. When > an AG fills up, we select a new AG for the stream that is not in > use. > > The core of the functionality is the stream tracking - each inode > that we create in a directory needs to be associated with the > directories' stream. Hence every time we create a file, we look up > the directories' stream object and associate the new file with that > object. > > Once we have a stream object for a file, we use the AG that the > stream object point to for allocations. If we can't allocate in that > AG (e.g. it is full) we move the entire stream to another AG. Other > inodes in the same stream are moved to the new AG on their next > allocation (i.e. lazy update). > > Stream objects are kept in a cache and hold a reference on the > inode. Hence the inode cannot be reclaimed while there is an > outstanding stream reference. This means that on unlink we need to > remove the stream association and we also need to flush all the > associations on certain events that want to reclaim all unreferenced > inodes (e.g. filesystem freeze). > > The following patch survives XFSQA with timeouts set to minimum, > default, 500s and maximum. The patch has not had a great > deal of low memory testing, and the object cache may need a shrinker > interface to work in low memory conditions. > > Comments? > > Credits: The original filestream allocator on Irix was written by > Glen Overby, the Linux port and rewrite by Nathan Scott and Sam > Vaughan (none of whom work at SGI any more). I just picked the pieces > and beat it repeatedly with a big stick until it passed XFSQA. > > Cheers, > > Dave. > -- > Dave Chinner > Principal Engineer > SGI Australian Software Group > > > --- > fs/xfs/Makefile-linux-2.6 | 2 > fs/xfs/linux-2.6/xfs_globals.c | 1 > fs/xfs/linux-2.6/xfs_linux.h | 1 > fs/xfs/linux-2.6/xfs_sysctl.c | 11 > fs/xfs/linux-2.6/xfs_sysctl.h | 2 > fs/xfs/quota/xfs_qm.c | 3 > fs/xfs/xfs_ag.h | 1 > fs/xfs/xfs_bmap.c | 337 +++++++++++++++++ > fs/xfs/xfs_clnt.h | 2 > fs/xfs/xfs_dinode.h | 4 > fs/xfs/xfs_filestream.c | 777 > +++++++++++++++++++++++++++++++++++++++++ > fs/xfs/xfs_filestream.h | 59 +++ > fs/xfs/xfs_fs.h | 1 > fs/xfs/xfs_fsops.c | 2 > fs/xfs/xfs_inode.c | 17 > fs/xfs/xfs_mount.c | 11 > fs/xfs/xfs_mount.h | 4 > fs/xfs/xfs_mru_cache.c | 607 ++++++++++++++++++++++++++++++++ > fs/xfs/xfs_mru_cache.h | 225 +++++++++++ > fs/xfs/xfs_vfsops.c | 25 + > fs/xfs/xfs_vnodeops.c | 28 + > 21 files changed, 2114 insertions(+), 6 deletions(-) > > Index: 2.6.x-xfs-new/fs/xfs/Makefile-linux-2.6 > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/Makefile-linux-2.6 2007-05-10 > 17:22:43.486754830 +1000 > +++ 2.6.x-xfs-new/fs/xfs/Makefile-linux-2.6 2007-05-10 17:24:12.975025602 > +1000 > @@ -54,6 +54,7 @@ xfs-y += xfs_alloc.o \ > xfs_dir2_sf.o \ > xfs_error.o \ > xfs_extfree_item.o \ > + xfs_filestream.o \ > xfs_fsops.o \ > xfs_ialloc.o \ > xfs_ialloc_btree.o \ > @@ -67,6 +68,7 @@ xfs-y += xfs_alloc.o \ > xfs_log.o \ > xfs_log_recover.o \ > xfs_mount.o \ > + xfs_mru_cache.o \ > xfs_rename.o \ > xfs_trans.o \ > xfs_trans_ail.o \ > Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_globals.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_globals.c 2007-05-10 > 17:22:43.486754830 +1000 > +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_globals.c 2007-05-10 > 17:24:12.987024029 +1000 > @@ -49,6 +49,7 @@ xfs_param_t xfs_params = { > .inherit_nosym = { 0, 0, 1 }, > .rotorstep = { 1, 1, 255 }, > .inherit_nodfrg = { 0, 1, 1 }, > + .fstrm_timer = { 1, 50, 3600*100}, > }; > > /* > Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_linux.h > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_linux.h 2007-05-10 > 17:22:43.486754830 +1000 > +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_linux.h 2007-05-10 > 17:24:12.991023505 +1000 > @@ -132,6 +132,7 @@ > #define xfs_inherit_nosymlinks xfs_params.inherit_nosym.val > #define xfs_rotorstep xfs_params.rotorstep.val > #define xfs_inherit_nodefrag xfs_params.inherit_nodfrg.val > +#define xfs_fstrm_centisecs xfs_params.fstrm_timer.val > > #define current_cpu() (raw_smp_processor_id()) > #define current_pid() (current->pid) > Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_sysctl.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_sysctl.c 2007-05-10 > 17:22:43.486754830 +1000 > +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_sysctl.c 2007-05-10 > 17:24:12.991023505 +1000 > @@ -243,6 +243,17 @@ static ctl_table xfs_table[] = { > .extra1 = &xfs_params.inherit_nodfrg.min, > .extra2 = &xfs_params.inherit_nodfrg.max > }, > + { > + .ctl_name = XFS_FILESTREAM_TIMER, > + .procname = "filestream_centisecs", > + .data = &xfs_params.fstrm_timer.val, > + .maxlen = sizeof(int), > + .mode = 0644, > + .proc_handler = &proc_dointvec_minmax, > + .strategy = &sysctl_intvec, > + .extra1 = &xfs_params.fstrm_timer.min, > + .extra2 = &xfs_params.fstrm_timer.max, > + }, > /* please keep this the last entry */ > #ifdef CONFIG_PROC_FS > { > Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_sysctl.h > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_sysctl.h 2007-05-10 > 17:22:43.486754830 +1000 > +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_sysctl.h 2007-05-10 > 17:24:12.991023505 +1000 > @@ -50,6 +50,7 @@ typedef struct xfs_param { > xfs_sysctl_val_t inherit_nosym; /* Inherit the "nosymlinks" flag. */ > xfs_sysctl_val_t rotorstep; /* inode32 AG rotoring control knob */ > xfs_sysctl_val_t inherit_nodfrg;/* Inherit the "nodefrag" inode flag. */ > + xfs_sysctl_val_t fstrm_timer; /* Filestream dir-AG assoc'n timeout. */ > } xfs_param_t; > > /* > @@ -89,6 +90,7 @@ enum { > XFS_INHERIT_NOSYM = 19, > XFS_ROTORSTEP = 20, > XFS_INHERIT_NODFRG = 21, > + XFS_FILESTREAM_TIMER = 22, > }; > > extern xfs_param_t xfs_params; > Index: 2.6.x-xfs-new/fs/xfs/xfs_ag.h > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_ag.h 2007-05-10 17:22:43.494753782 +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_ag.h 2007-05-10 17:24:12.995022981 +1000 > @@ -196,6 +196,7 @@ typedef struct xfs_perag > lock_t pagb_lock; /* lock for pagb_list */ > #endif > xfs_perag_busy_t *pagb_list; /* unstable blocks */ > + atomic_t pagf_fstrms; /* # of filestreams active in this AG */ > > /* > * inode allocation search lookup optimisation. > Index: 2.6.x-xfs-new/fs/xfs/xfs_bmap.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_bmap.c 2007-05-10 17:22:43.494753782 > +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_bmap.c 2007-05-10 17:24:13.011020884 +1000 > @@ -52,6 +52,7 @@ > #include "xfs_quota.h" > #include "xfs_trans_space.h" > #include "xfs_buf_item.h" > +#include "xfs_filestream.h" > > > #ifdef DEBUG > @@ -171,6 +172,14 @@ xfs_bmap_alloc( > xfs_bmalloca_t *ap); /* bmap alloc argument struct */ > > /* > + * xfs_bmap_filestreams is the underlying allocator when filestreams are > + * enabled. > + */ > +STATIC int /* error */ > +xfs_bmap_filestreams( > + xfs_bmalloca_t *ap); /* bmap alloc argument struct */ > + > +/* > * Transform a btree format file with only one leaf node, where the > * extents list will fit in the inode, into an extents format file. > * Since the file extents are already in-core, all we have to do is > @@ -2968,10 +2977,338 @@ xfs_bmap_alloc( > { > if ((ap->ip->i_d.di_flags & XFS_DIFLAG_REALTIME) && ap->userdata) > return xfs_bmap_rtalloc(ap); > + if ((ap->ip->i_mount->m_flags & XFS_MOUNT_FILESTREAMS) || > + (ap->ip->i_d.di_flags & XFS_DIFLAG_FILESTREAM)) > + return xfs_bmap_filestreams(ap); > return xfs_bmap_btalloc(ap); > } > > /* > + * xfs_filestreams called by xfs_bmapi for multi-file data stream > filesystems. > + * > + * Allocate files in a directory all in the same AG. When an AG fills, > pick > + * a new AG. > + */ > +int /* error */ > +xfs_bmap_filestreams( > + xfs_bmalloca_t *ap) /* bmap alloc argument struct */ > +{ > + xfs_alloctype_t atype; /* type for allocation routines */ > + int error; /* error return value */ > + xfs_agnumber_t fb_agno; /* ag number of ap->firstblock */ > + xfs_mount_t *mp; /* mount point structure */ > + int nullfb; /* true if ap->firstblock isn't set */ > + int rt; /* true if inode is realtime */ > + xfs_extlen_t align; /* minimum allocation alignment */ > + xfs_agnumber_t ag; > + xfs_alloc_arg_t args; > + xfs_extlen_t blen; > + xfs_extlen_t delta; > + int isaligned; > + xfs_extlen_t longest; > + xfs_extlen_t need; > + xfs_extlen_t nextminlen = 0; > + int notinit; > + xfs_perag_t *pag; > + xfs_agnumber_t startag; > + int tryagain; > + > + /* > + * Set up variables. > + */ > + mp = ap->ip->i_mount; > + rt = (ap->ip->i_d.di_flags & XFS_DIFLAG_REALTIME) && ap->userdata; > + align = (ap->userdata && ap->ip->i_d.di_extsize && > + (ap->ip->i_d.di_flags & XFS_DIFLAG_EXTSIZE)) ? > + ap->ip->i_d.di_extsize : 0; > + if (align) { > + error = xfs_bmap_extsize_align(mp, ap->gotp, ap->prevp, > + align, rt, > + ap->eof, 0, ap->conv, > + &ap->off, &ap->alen); > + ASSERT(!error); > + ASSERT(ap->alen); > + } > + nullfb = ap->firstblock == NULLFSBLOCK; > + fb_agno = nullfb ? NULLAGNUMBER : XFS_FSB_TO_AGNO(mp, ap->firstblock); > + if (nullfb) { > + ag = xfs_filestream_get_ag(ap->ip); > + ag = (ag != NULLAGNUMBER) ? ag : 0; > + ap->rval = (ap->userdata) ? XFS_AGB_TO_FSB(mp, ag, 0) : > + XFS_INO_TO_FSB(mp, ap->ip->i_ino); > + } else { > + ap->rval = ap->firstblock; > + } > + > + xfs_bmap_adjacent(ap); > + > + /* > + * If allowed, use ap->rval; otherwise must use firstblock since > + * it's in the right allocation group. > + */ > + if (nullfb || XFS_FSB_TO_AGNO(mp, ap->rval) == fb_agno) > + ; > + else > + ap->rval = ap->firstblock; > + /* > + * Normal allocation, done through xfs_alloc_vextent. > + */ > + tryagain = isaligned = 0; > + args.tp = ap->tp; > + args.mp = mp; > + args.fsbno = ap->rval; > + args.maxlen = MIN(ap->alen, mp->m_sb.sb_agblocks); > + blen = 0; > + if (nullfb) { > + /* _vextent doesn't pick an AG */ > + args.type = XFS_ALLOCTYPE_NEAR_BNO; > + args.total = ap->total; > + /* > + * Find the longest available space. > + * We're going to try for the whole allocation at once. > + */ > + startag = ag = XFS_FSB_TO_AGNO(mp, args.fsbno); > + if (startag == NULLAGNUMBER) { > + startag = ag = 0; > + } > + notinit = 0; > + /* > + * Search for an allocation group with a single extent > + * large enough for the request. > + * > + * If one isn't found, then adjust the minimum allocation > + * size to the largest space found. > + */ > + down_read(&mp->m_peraglock); > + while (blen < ap->alen) { > + pag = &mp->m_perag[ag]; > + if (!pag->pagf_init && > + (error = xfs_alloc_pagf_init(mp, args.tp, > + ag, XFS_ALLOC_FLAG_TRYLOCK))) { > + up_read(&mp->m_peraglock); > + return error; > + } > + /* > + * See xfs_alloc_fix_freelist... > + */ > + if (pag->pagf_init) { > + need = XFS_MIN_FREELIST_PAG(pag, mp); > + delta = need > pag->pagf_flcount ? > + need - pag->pagf_flcount : 0; > + longest = (pag->pagf_longest > delta) ? > + (pag->pagf_longest - delta) : > + (pag->pagf_flcount > 0 || > + pag->pagf_longest > 0); > + if (blen < longest) > + blen = longest; > + } else { > + notinit = 1; > + } > + > + if (blen >= ap->alen) > + break; > + > + if (ap->userdata) { > + if (startag == NULLAGNUMBER) { > + /* > + * If startag is an invalid AG, > + * we've come here once before and > + * xfs_filestream_new_ag picked the best > + * currently available. > + * > + * Don't continue looping, since we > + * could loop forever. > + */ > + break; > + } > + > + if ((error = xfs_filestream_new_ag(ap, &ag))) { > + up_read(&mp->m_peraglock); > + return error; > + } > + > + startag = NULLAGNUMBER; > + > + /* Go around the loop once more to set 'blen'*/ > + } else { > + if (++ag == mp->m_sb.sb_agcount) > + ag = 0; > + > + if (ag == startag) > + break; > + } > + } > + up_read(&mp->m_peraglock); > + /* > + * Since the above loop did a BUF_TRYLOCK, it is > + * possible that there is space for this request. > + */ > + if (notinit || blen < ap->minlen) > + args.minlen = ap->minlen; > + /* > + * If the best seen length is less than the request > + * length, use the best as the minimum. > + */ > + else if (blen < ap->alen) > + args.minlen = blen; > + /* > + * Otherwise we've seen an extent as big as alen, > + * use that as the minimum. > + */ > + else > + args.minlen = ap->alen; > + ap->rval = args.fsbno = XFS_AGB_TO_FSB(mp, ag, 0); > + } else if (ap->low) { > + args.type = XFS_ALLOCTYPE_FIRST_AG; > + args.total = args.minlen = ap->minlen; > + } else { > + args.type = XFS_ALLOCTYPE_NEAR_BNO; > + args.total = ap->total; > + args.minlen = ap->minlen; > + } > + if (ap->userdata && ap->ip->i_d.di_extsize && > + (ap->ip->i_d.di_flags & XFS_DIFLAG_EXTSIZE)) { > + args.prod = ap->ip->i_d.di_extsize; > + if ((args.mod = (xfs_extlen_t)(do_mod(ap->off, args.prod)))) > + args.mod = (xfs_extlen_t)(args.prod - args.mod); > + } else if (mp->m_sb.sb_blocksize >= NBPP) { > + args.prod = 1; > + args.mod = 0; > + } else { > + args.prod = NBPP >> mp->m_sb.sb_blocklog; > + if ((args.mod = (xfs_extlen_t)(do_mod(ap->off, args.prod)))) > + args.mod = (xfs_extlen_t)(args.prod - args.mod); > + } > + /* > + * If we are not low on available data blocks, and the > + * underlying logical volume manager is a stripe, and > + * the file offset is zero then try to allocate data > + * blocks on stripe unit boundary. > + * NOTE: ap->aeof is only set if the allocation length > + * is >= the stripe unit and the allocation offset is > + * at the end of file. > + */ > + atype = args.type; > + if (!ap->low && ap->aeof) { > + if (!ap->off) { > + args.alignment = mp->m_dalign; > + atype = args.type; > + isaligned = 1; > + /* > + * Adjust for alignment > + */ > + if (blen > args.alignment && blen <= ap->alen) > + args.minlen = blen - args.alignment; > + args.minalignslop = 0; > + } else { > + /* > + * First try an exact bno allocation. > + * If it fails then do a near or start bno > + * allocation with alignment turned on. > + */ > + atype = args.type; > + tryagain = 1; > + args.type = XFS_ALLOCTYPE_THIS_BNO; > + args.alignment = 1; > + /* > + * Compute the minlen+alignment for the > + * next case. Set slop so that the value > + * of minlen+alignment+slop doesn't go up > + * between the calls. > + */ > + if (blen > mp->m_dalign && blen <= ap->alen) > + nextminlen = blen - mp->m_dalign; > + else > + nextminlen = args.minlen; > + if (nextminlen + mp->m_dalign > args.minlen + 1) > + args.minalignslop = > + nextminlen + mp->m_dalign - > + args.minlen - 1; > + else > + args.minalignslop = 0; > + } > + } else { > + args.alignment = 1; > + args.minalignslop = 0; > + } > + args.minleft = ap->minleft; > + args.wasdel = ap->wasdel; > + args.isfl = 0; > + args.userdata = ap->userdata; > + if ((error = xfs_alloc_vextent(&args))) > + return error; > + if (tryagain && args.fsbno == NULLFSBLOCK) { > + /* > + * Exact allocation failed. Now try with alignment > + * turned on. > + */ > + args.type = atype; > + args.fsbno = ap->rval; > + args.alignment = mp->m_dalign; > + args.minlen = nextminlen; > + args.minalignslop = 0; > + isaligned = 1; > + if ((error = xfs_alloc_vextent(&args))) > + return error; > + } > + if (isaligned && args.fsbno == NULLFSBLOCK) { > + /* > + * allocation failed, so turn off alignment and > + * try again. > + */ > + args.type = atype; > + args.fsbno = ap->rval; > + args.alignment = 0; > + if ((error = xfs_alloc_vextent(&args))) > + return error; > + } > + if (args.fsbno == NULLFSBLOCK && nullfb && > + args.minlen > ap->minlen) { > + args.minlen = ap->minlen; > + args.type = XFS_ALLOCTYPE_START_BNO; > + args.fsbno = ap->rval; > + if ((error = xfs_alloc_vextent(&args))) > + return error; > + } > + if (args.fsbno == NULLFSBLOCK && nullfb) { > + args.fsbno = 0; > + args.type = XFS_ALLOCTYPE_FIRST_AG; > + args.total = ap->minlen; > + args.minleft = 0; > + if ((error = xfs_alloc_vextent(&args))) > + return error; > + ap->low = 1; > + } > + if (args.fsbno != NULLFSBLOCK) { > + ap->firstblock = ap->rval = args.fsbno; > + ASSERT(nullfb || fb_agno == args.agno || > + (ap->low && fb_agno < args.agno)); > + ap->alen = args.len; > + ap->ip->i_d.di_nblocks += args.len; > + xfs_trans_log_inode(ap->tp, ap->ip, XFS_ILOG_CORE); > + if (ap->wasdel) > + ap->ip->i_delayed_blks -= args.len; > + /* > + * Adjust the disk quota also. This was reserved > + * earlier. > + */ > + if (XFS_IS_QUOTA_ON(mp) && > + ap->ip->i_ino != mp->m_sb.sb_uquotino && > + ap->ip->i_ino != mp->m_sb.sb_gquotino) { > + XFS_TRANS_MOD_DQUOT_BYINO(mp, ap->tp, ap->ip, > + ap->wasdel ? > + XFS_TRANS_DQ_DELBCOUNT : > + XFS_TRANS_DQ_BCOUNT, > + (long)args.len); > + } > + } else { > + ap->rval = NULLFSBLOCK; > + ap->alen = 0; > + } > + return 0; > +} > + > +/* > * Transform a btree format file with only one leaf node, where the > * extents list will fit in the inode, into an extents format file. > * Since the file extents are already in-core, all we have to do is > Index: 2.6.x-xfs-new/fs/xfs/xfs_clnt.h > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_clnt.h 2007-05-10 17:22:43.494753782 > +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_clnt.h 2007-05-10 17:24:13.011020884 +1000 > @@ -99,5 +99,7 @@ struct xfs_mount_args { > */ > #define XFSMNT2_COMPAT_IOSIZE 0x00000001 /* don't report large preferred > * I/O size in stat(2) */ > +#define XFSMNT2_FILESTREAMS 0x00000002 /* enable the filestreams > + * allocator */ > > #endif /* __XFS_CLNT_H__ */ > Index: 2.6.x-xfs-new/fs/xfs/xfs_dinode.h > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_dinode.h 2007-05-10 17:22:43.494753782 > +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_dinode.h 2007-05-10 17:24:13.015020360 +1000 > @@ -257,6 +257,7 @@ typedef enum xfs_dinode_fmt > #define XFS_DIFLAG_EXTSIZE_BIT 11 /* inode extent size allocator > hint */ > #define XFS_DIFLAG_EXTSZINHERIT_BIT 12 /* inherit inode extent size */ > #define XFS_DIFLAG_NODEFRAG_BIT 13 /* do not reorganize/defragment */ > +#define XFS_DIFLAG_FILESTREAM_BIT 14 /* use filestream allocator */ > #define XFS_DIFLAG_REALTIME (1 << XFS_DIFLAG_REALTIME_BIT) > #define XFS_DIFLAG_PREALLOC (1 << XFS_DIFLAG_PREALLOC_BIT) > #define XFS_DIFLAG_NEWRTBM (1 << XFS_DIFLAG_NEWRTBM_BIT) > @@ -271,12 +272,13 @@ typedef enum xfs_dinode_fmt > #define XFS_DIFLAG_EXTSIZE (1 << XFS_DIFLAG_EXTSIZE_BIT) > #define XFS_DIFLAG_EXTSZINHERIT (1 << XFS_DIFLAG_EXTSZINHERIT_BIT) > #define XFS_DIFLAG_NODEFRAG (1 << XFS_DIFLAG_NODEFRAG_BIT) > +#define XFS_DIFLAG_FILESTREAM (1 << XFS_DIFLAG_FILESTREAM_BIT) > > #define XFS_DIFLAG_ANY \ > (XFS_DIFLAG_REALTIME | XFS_DIFLAG_PREALLOC | XFS_DIFLAG_NEWRTBM | \ > XFS_DIFLAG_IMMUTABLE | XFS_DIFLAG_APPEND | XFS_DIFLAG_SYNC | \ > XFS_DIFLAG_NOATIME | XFS_DIFLAG_NODUMP | XFS_DIFLAG_RTINHERIT | \ > XFS_DIFLAG_PROJINHERIT | XFS_DIFLAG_NOSYMLINKS | XFS_DIFLAG_EXTSIZE | \ > - XFS_DIFLAG_EXTSZINHERIT | XFS_DIFLAG_NODEFRAG) > + XFS_DIFLAG_EXTSZINHERIT | XFS_DIFLAG_NODEFRAG | XFS_DIFLAG_FILESTREAM) > > #endif /* __XFS_DINODE_H__ */ > Index: 2.6.x-xfs-new/fs/xfs/xfs_filestream.c > =================================================================== > --- /dev/null 1970-01-01 00:00:00.000000000 +0000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_filestream.c 2007-05-10 17:24:13.019019836 > +1000 > @@ -0,0 +1,777 @@ > +/* > + * Copyright (c) 2000-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 > + */ > +#include "xfs.h" > +#include "xfs_bmap_btree.h" > +#include "xfs_inum.h" > +#include "xfs_dir2.h" > +#include "xfs_dir2_sf.h" > +#include "xfs_attr_sf.h" > +#include "xfs_dinode.h" > +#include "xfs_inode.h" > +#include "xfs_ag.h" > +#include "xfs_dmapi.h" > +#include "xfs_log.h" > +#include "xfs_trans.h" > +#include "xfs_sb.h" > +#include "xfs_mount.h" > +#include "xfs_bmap.h" > +#include "xfs_alloc.h" > +#include "xfs_utils.h" > +#include "xfs_mru_cache.h" > +#include "xfs_filestream.h" > + > +#ifdef DEBUG_FILESTREAMS > +#define dprint(fmt, args...) do { \ > + printk(KERN_DEBUG "%4d %s: " fmt "\n", \ > + current_pid(), __FUNCTION__, ##args); \ > +} while(0) > +#else > +#define dprint(args...) do {} while (0) > +#endif > + > +static kmem_zone_t *item_zone; > + > +/* > + * Per-mount point data structure to maintain its active filestreams. > Currently > + * only contains a single pointer, but set up and allocated as a > structure to > + * ease future expansion, if any. > + */ > +typedef struct fstrm_mnt_data > +{ > + struct xfs_mru_cache *fstrm_items; > +} fstrm_mnt_data_t; > + > +/* > + * Structure for associating a file or a directory with an allocation > group. > + * The parent directory pointer is only needed for files, but since there > will > + * generally be vastly more files than directories in the cache, using > the same > + * data structure simplifies the code with very little memory overhead. > + */ > +typedef struct fstrm_item > +{ > + xfs_agnumber_t ag; /* AG currently in use for the file/directory. */ > + xfs_inode_t *ip; /* inode self-pointer. */ > + xfs_inode_t *pip; /* Parent directory inode pointer. */ > +} fstrm_item_t; > + > +/* > + * Allocation group filestream associations are tracked with per-ag > atomic > + * counters. These counters allow _xfs_filestream_pick_ag() to tell > whether a > + * particular AG already has active filestreams associated with it. The > mount > + * point's m_peraglock is used to protect these counters from per-ag > array > + * re-allocation during a growfs operation. When > xfs_growfs_data_private() is > + * about to reallocate the array, it calls xfs_filestream_flush() with > the > + * m_peraglock held in write mode. > + * > + * Since xfs_mru_cache_flush() guarantees that all the free functions for > all > + * the cache elements have finished executing before it returns, it's > safe for > + * the free functions to use the atomic counters without m_peraglock > protection. > + * This allows the implementation of xfs_fstrm_free_func() to be agnostic > about > + * whether it was called with the m_peraglock held in read mode, write > mode or > + * not held at all. The race condition this addresses is the following: > + * > + * - The work queue scheduler fires and pulls a filestream directory > cache > + * element off the LRU end of the cache for deletion, then gets > pre-empted. > + * - A growfs operation grabs the m_peraglock in write mode, flushes all > the > + * remaining items from the cache and reallocates the mount point's > per-ag > + * array, resetting all the counters to zero. > + * - The work queue thread resumes and calls the free function for the > element > + * it started cleaning up earlier. In the process it decrements the > + * filestreams counter for an AG that now has no references. > + * > + * With a shrinkfs feature, the above scenario could panic the system. > + * > + * All other uses of the following macros should be protected by either > the > + * m_peraglock held in read mode, or the cache's internal locking exposed > by the > + * interval between a call to xfs_mru_cache_lookup() and a call to > + * xfs_mru_cache_done(). In addition, the m_peraglock must be held in > read mode > + * when new elements are added to the cache. > + * > + * Combined, these locking rules ensure that no associations will ever > exist in > + * the cache that reference per-ag array elements that have since been > + * reallocated. > + */ > +#define GET_AG_REF(mp, ag) atomic_read(&(mp)->m_perag[ag].pagf_fstrms) > +#define INC_AG_REF(mp, ag) > atomic_inc_return(&(mp)->m_perag[ag].pagf_fstrms) > +#define DEC_AG_REF(mp, ag) > atomic_dec_return(&(mp)->m_perag[ag].pagf_fstrms) > + > +#define XFS_PICK_USERDATA 1 > +#define XFS_PICK_LOWSPACE 2 > + > +/* > + * Scan the AGs starting at startag looking for an AG that isn't in use > and has > + * at least minlen blocks free. > + */ > +static int > +_xfs_filestream_pick_ag( > + xfs_mount_t *mp, > + xfs_agnumber_t startag, > + xfs_agnumber_t *agp, > + int flags, > + xfs_extlen_t minlen) > +{ > + int err, trylock, nscan; > + xfs_extlen_t delta, longest, need, free, minfree, maxfree = 0; > + xfs_agnumber_t ag, max_ag = NULLAGNUMBER; > + struct xfs_perag *pag; > + > + /* 2% of an AG's blocks must be free for it to be chosen. */ > + minfree = mp->m_sb.sb_agblocks / 50; > + > + ag = startag; > + *agp = NULLAGNUMBER; > + > + /* For the first pass, don't sleep trying to init the per-AG. */ > + trylock = XFS_ALLOC_FLAG_TRYLOCK; > + > + for (nscan = 0; 1; nscan++) { > + > + //dprint("scanning AG %d[%d]", ag, GET_AG_REF(mp, ag)); > + > + pag = mp->m_perag + ag; > + > + if (!pag->pagf_init && > + (err = xfs_alloc_pagf_init(mp, NULL, ag, trylock)) && > + !trylock) { > + dprint("xfs_alloc_pagf_init returned %d", err); > + return err; > + } > + > + /* Might fail sometimes during the 1st pass with trylock set. */ > + if (!pag->pagf_init) { > + dprint("!pagf_init"); > + goto next_ag; > + } > + > + /* Keep track of the AG with the most free blocks. */ > + if (pag->pagf_freeblks > maxfree) { > + maxfree = pag->pagf_freeblks; > + max_ag = ag; > + } > + > + /* > + * The AG reference count does two things: it enforces mutual > + * exclusion when examining the suitability of an AG in this > + * loop, and it guards against two filestreams being established > + * in the same AG as each other. > + */ > + if (INC_AG_REF(mp, ag) > 1) { > + DEC_AG_REF(mp, ag); > + goto next_ag; > + } > + > + need = XFS_MIN_FREELIST_PAG(pag, mp); > + delta = need > pag->pagf_flcount ? need - pag->pagf_flcount : 0; > + longest = (pag->pagf_longest > delta) ? > + (pag->pagf_longest - delta) : > + (pag->pagf_flcount > 0 || pag->pagf_longest > 0); > + > + if (((minlen && longest >= minlen) || > + (!minlen && pag->pagf_freeblks >= minfree)) && > + (!pag->pagf_metadata || !(flags & XFS_PICK_USERDATA) || > + (flags & XFS_PICK_LOWSPACE))) { > + > + /* Break out, retaining the reference on the AG. */ > + free = pag->pagf_freeblks; > + *agp = ag; > + break; > + } > + > + /* Drop the reference on this AG, it's not usable. */ > + DEC_AG_REF(mp, ag); > +next_ag: > + /* Move to the next AG, wrapping to AG 0 if necessary. */ > + if (++ag >= mp->m_sb.sb_agcount) > + ag = 0; > + > + /* If a full pass of the AGs hasn't been done yet, continue. */ > + if (ag != startag) > + continue; > + > + /* Allow sleeping in xfs_alloc_pagf_init() on the 2nd pass. */ > + if (trylock != 0) { > + trylock = 0; > + continue; > + } > + > + /* Finally, if lowspace wasn't set, set it for the 3rd pass. */ > + if (!(flags & XFS_PICK_LOWSPACE)) { > + flags |= XFS_PICK_LOWSPACE; > + continue; > + } > + > + /* > + * Take the AG with the most free space, regardless of whether > + * it's already in use by another filestream. > + */ > + if (max_ag != NULLAGNUMBER) { > + INC_AG_REF(mp, max_ag); > + dprint("using max_ag %d[1] with maxfree %d", max_ag, > + maxfree); > + > + free = maxfree; > + *agp = max_ag; > + break; > + } > + > + dprint("giving up, returning AG 0"); > + *agp = 0; > + return 0; > + } > + > + /* > + dprint("mp %p startag %d newag %d[%d] free %d minlen %d minfree %d " > + "scanned %d trylock %d flags 0x%x", mp, startag, *agp, > + GET_AG_REF(mp, *agp), free, minlen, minfree, nscan, trylock, > + flags); > + */ > + > + return 0; > +} > + > +/* > + * Set the allocation group number for a file or a directory, updating > inode > + * references and per-AG references as appropriate. Must be called with > the > + * m_peraglock held in read mode. > + */ > +static int > +_xfs_filestream_set_ag( > + xfs_inode_t *ip, > + xfs_inode_t *pip, > + xfs_agnumber_t ag) > +{ > + int err = 0; > + xfs_mount_t *mp; > + xfs_mru_cache_t *cache; > + fstrm_item_t *item; > + xfs_agnumber_t old_ag; > + xfs_inode_t *old_pip; > + > + /* > + * Either ip is a regular file and pip is a directory, or ip is a > + * directory and pip is NULL. > + */ > + ASSERT(ip && (((ip->i_d.di_mode & S_IFREG) && pip && > + (pip->i_d.di_mode & S_IFDIR)) || > + ((ip->i_d.di_mode & S_IFDIR) && !pip))); > + > + mp = ip->i_mount; > + cache = mp->m_filestream->fstrm_items; > + > + if ((item = (fstrm_item_t*)xfs_mru_cache_lookup(cache, ip->i_ino))) { > + ASSERT(item->ip == ip); > + old_ag = item->ag; > + item->ag = ag; > + old_pip = item->pip; > + item->pip = pip; > + xfs_mru_cache_done(cache); > + > + /* > + * If the AG has changed, drop the old ref and take a new one, > + * effectively transferring the reference from old to new AG. > + */ > + if (ag != old_ag) { > + DEC_AG_REF(mp, old_ag); > + INC_AG_REF(mp, ag); > + } > + > + /* > + * If ip is a file and its pip has changed, drop the old ref and > + * take a new one. > + */ > + if (pip && pip != old_pip) { > + IRELE(old_pip); > + IHOLD(pip); > + } > + > + if (ag != old_ag) > + dprint("found ip %p ino %lld, AG %d[%d] -> %d[%d]", ip, > + ip->i_ino, old_ag, GET_AG_REF(mp, old_ag), ag, > + GET_AG_REF(mp, ag)); > + else > + dprint("found ip %p ino %lld, AG %d[%d]", ip, ip->i_ino, > + ag, GET_AG_REF(mp, ag)); > + > + return 0; > + } > + > + if (!(item = (fstrm_item_t*)kmem_zone_zalloc(item_zone, KM_SLEEP))) > + return ENOMEM; > + > + item->ag = ag; > + item->ip = ip; > + item->pip = pip; > + > + if ((err = xfs_mru_cache_insert(cache, ip->i_ino, item))) { > + kmem_zone_free(item_zone, item); > + return err; > + } > + > + /* Take a reference on the AG. */ > + INC_AG_REF(mp, ag); > + > + /* > + * Take a reference on the inode itself regardless of whether it's a > + * regular file or a directory. > + */ > + IHOLD(ip); > + > + /* > + * In the case of a regular file, take a reference on the parent inode > + * as well to ensure it remains in-core. > + */ > + if (pip) > + IHOLD(pip); > + > + dprint("put ip %p ino %lld into AG %d[%d]", ip, ip->i_ino, ag, > + GET_AG_REF(mp, ag)); > + > + return 0; > +} > + > +/* xfs_fstrm_free_func(): callback for freeing cached stream items. */ > +void > +xfs_fstrm_free_func( > + xfs_ino_t ino, > + fstrm_item_t *item) > +{ > + xfs_inode_t *ip = item->ip; > + int ref; > + > + ASSERT(ip->i_ino == ino); > + > + /* Drop the reference taken on the AG when the item was added. */ > + ref = DEC_AG_REF(ip->i_mount, item->ag); > + > + ASSERT(ref >= 0); > + > + /* > + * _xfs_filestream_set_ag() always takes a reference on the inode > + * itself, whether it's a file or a directory. Release it here. > + */ > + IRELE(ip); > + > + /* > + * In the case of a regular file, _xfs_filestream_set_ag() also takes a > + * ref on the parent inode to keep it in-core. Release that too. > + */ > + if (item->pip) > + IRELE(item->pip); > + > + if (ip->i_d.di_mode & S_IFDIR) > + dprint("deleting dip %p ino %lld, AG %d[%d]", ip, ip->i_ino, > + item->ag, GET_AG_REF(ip->i_mount, item->ag)); > + else > + dprint("deleting file %p ino %lld, pip %p ino %lld, AG %d[%d]", > + ip, ip->i_ino, item->pip, > + item->pip ? item->pip->i_ino : 0, item->ag, > + GET_AG_REF(ip->i_mount, item->ag)); > + > + /* Finally, free the memory allocated for the item. */ > + kmem_zone_free(item_zone, item); > +} > + > +/* > + * xfs_filestream_init() is called at xfs initialisation time to set up > the > + * memory zone that will be used for filestream data structure > allocation. > + */ > +void > +xfs_filestream_init(void) > +{ > + item_zone = kmem_zone_init(sizeof(fstrm_item_t), "fstrm_item"); > + ASSERT(item_zone); > +} > + > +/* > + * xfs_filestream_uninit() is called at xfs termination time to destroy > the > + * memory zone that was used for filestream data structure allocation. > + */ > +void > +xfs_filestream_uninit(void) > +{ > + if (item_zone) { > + kmem_zone_destroy(item_zone); > + item_zone = NULL; > + } > +} > + > +/* > + * xfs_filestream_mount() is called when a file system is mounted with > the > + * filestream option. It is responsible for allocating the data > structures > + * needed to track the new file system's file streams. > + */ > +int > +xfs_filestream_mount( > + xfs_mount_t *mp) > +{ > + int err = 0; > + unsigned int lifetime, grp_count; > + fstrm_mnt_data_t *md; > + > + if (!(md = (fstrm_mnt_data_t*)kmem_zalloc(sizeof(*md), KM_SLEEP))) > + return ENOMEM; > + > + /* > + * The filestream timer tunable is currently fixed within the range of > + * one second to four minutes, with five seconds being the default. The > + * group count is somewhat arbitrary, but it'd be nice to adhere to the > + * timer tunable to within about 10 percent. This requires at least 10 > + * groups. > + */ > + lifetime = xfs_fstrm_centisecs * 10; > + grp_count = 10; > + > + if ((err = xfs_mru_cache_create(&md->fstrm_items, lifetime, grp_count, > + (xfs_mru_cache_free_func_t)xfs_fstrm_free_func))) { > + kmem_free(md, sizeof(*md)); > + return err; > + } > + > + mp->m_filestream = md; > + > + dprint("created fstrm_items %p for mount %p", md->fstrm_items, mp); > + > + return 0; > +} > + > +/* > + * xfs_filestream_unmount() is called when a file system that was mounted > with > + * the filestream option is unmounted. It drains the data structures > created > + * to track the file system's file streams and frees all the memory that > was > + * allocated. > + */ > +void > +xfs_filestream_unmount( > + xfs_mount_t *mp) > +{ > + xfs_mru_cache_destroy(mp->m_filestream->fstrm_items); > + kmem_free(mp->m_filestream, sizeof(*mp->m_filestream)); > +} > + > +/* > + * If the mount point's m_perag array is going to be reallocated, all > + * outstanding cache entries must be flushed to avoid accessing reference > count > + * addresses that have been freed. The call to xfs_filestream_flush() > must be > + * made inside the block that holds the m_peraglock in write mode to do > the > + * reallocation. > + */ > +void > +xfs_filestream_flush( > + xfs_mount_t *mp) > +{ > + /* point in time flush, so keep the reaper running */ > + xfs_mru_cache_flush(mp->m_filestream->fstrm_items, 1); > +} > + > +/* > + * Return the AG of the filestream the file or directory belongs to, or > + * NULLAGNUMBER otherwise. > + */ > +xfs_agnumber_t > +xfs_filestream_get_ag( > + xfs_inode_t *ip) > +{ > + xfs_mru_cache_t *cache; > + fstrm_item_t *item; > + xfs_agnumber_t ag; > + int ref; > + > + ASSERT(ip->i_d.di_mode & (S_IFREG | S_IFDIR)); > + if (!(ip->i_d.di_mode & (S_IFREG | S_IFDIR))) > + return NULLAGNUMBER; > + > + cache = ip->i_mount->m_filestream->fstrm_items; > + if (!(item = (fstrm_item_t*)xfs_mru_cache_lookup(cache, ip->i_ino))) { > + dprint("lookup on %s ip %p ino %lld failed, returning %d", > + ip->i_d.di_mode & S_IFREG ? "file" : "dir", ip, > + ip->i_ino, NULLAGNUMBER); > + return NULLAGNUMBER; > + } > + > + ASSERT(ip == item->ip); > + ag = item->ag; > + ref = GET_AG_REF(ip->i_mount, ag); > + xfs_mru_cache_done(cache); > + > + if (ip->i_d.di_mode & S_IFREG) > + dprint("lookup on file ip %p ino %lld dir %p dino %lld got AG " > + "%d[%d]", ip, ip->i_ino, item->pip, item->pip->i_ino, ag, > + ref); > + else > + dprint("lookup on dir ip %p ino %lld got AG %d[%d]", ip, > + ip->i_ino, ag, ref); > + > + return ag; > +} > + > +/* > + * xfs_filestream_associate() should only be called to associate a > regular file > + * with its parent directory. Calling it with a child directory isn't > + * appropriate because filestreams don't apply to entire directory > hierarchies. > + * Creating a file in a child directory of an existing filestream > directory > + * starts a new filestream with its own allocation group association. > + */ > +int > +xfs_filestream_associate( > + xfs_inode_t *pip, > + xfs_inode_t *ip) > +{ > + xfs_mount_t *mp; > + xfs_mru_cache_t *cache; > + fstrm_item_t *item; > + xfs_agnumber_t ag, rotorstep, startag; > + int err = 0; > + > + ASSERT(pip->i_d.di_mode & S_IFDIR); > + ASSERT(ip->i_d.di_mode & S_IFREG); > + if (!(pip->i_d.di_mode & S_IFDIR) || !(ip->i_d.di_mode & S_IFREG)) > + return EINVAL; > + > + mp = pip->i_mount; > + cache = mp->m_filestream->fstrm_items; > + down_read(&mp->m_peraglock); > + xfs_ilock(pip, XFS_IOLOCK_EXCL); > + > + /* If the parent directory is already in the cache, use its AG. */ > + if ((item = (fstrm_item_t*)xfs_mru_cache_lookup(cache, pip->i_ino))) { > + ASSERT(item->ip == pip); > + ag = item->ag; > + xfs_mru_cache_done(cache); > + > + dprint("got cached dir %p ino %lld with AG %d[%d]", pip, > + pip->i_ino, ag, GET_AG_REF(mp, ag)); > + > + if ((err = _xfs_filestream_set_ag(ip, pip, ag))) > + dprint("_xfs_filestream_set_ag(%p, %p, %d) -> err %d", > + ip, pip, ag, err); > + > + goto exit; > + } > + > + /* > + * Set the starting AG using the rotor for inode32, otherwise > + * use the directory inode's AG. > + */ > + if (mp->m_flags & XFS_MOUNT_32BITINODES) { > + rotorstep = xfs_rotorstep; > + startag = (mp->m_agfrotor / rotorstep) % mp->m_sb.sb_agcount; > + mp->m_agfrotor = (mp->m_agfrotor + 1) % > + (mp->m_sb.sb_agcount * rotorstep); > + } else > + startag = XFS_INO_TO_AGNO(mp, pip->i_ino); > + > + /* Pick a new AG for the parent inode starting at startag. */ > + if ((err = _xfs_filestream_pick_ag(mp, startag, &ag, 0, 0)) || > + ag == NULLAGNUMBER) > + goto exit_did_pick; > + > + /* Associate the parent inode with the AG. */ > + if ((err = _xfs_filestream_set_ag(pip, NULL, ag))) { > + dprint("_xfs_filestream_set_ag(%p (%lld), NULL, %d) -> err %d", > + pip, pip->i_ino, ag, err); > + goto exit_did_pick; > + } > + > + /* Associate the file inode with the AG. */ > + if ((err = _xfs_filestream_set_ag(ip, pip, ag))) { > + dprint("_xfs_filestream_set_ag(%p (%lld), %p (%lld), %d) -> " > + "err %d", ip, ip->i_ino, pip, pip->i_ino, ag, err); > + goto exit_did_pick; > + } > + > + dprint("pip %p ino %lld and ip %p ino %lld given ag %d[%d]", > + pip, pip->i_ino, ip, ip->i_ino, ag, GET_AG_REF(mp, ag)); > + > +exit_did_pick: > + /* > + * If _xfs_filestream_pick_ag() returned a valid AG, remove the > + * reference it took on it, since the file and directory will have taken > + * their own now if they were successfully cached. > + */ > + if (ag != NULLAGNUMBER) > + DEC_AG_REF(mp, ag); > + else > + dprint("_pick_ag() returned invalid AG %d, no stream set", ag); > + > +exit: > + xfs_iunlock(pip, XFS_IOLOCK_EXCL); > + up_read(&mp->m_peraglock); > + return err; > +} > + > +/* > + * Pick a new allocation group for the current file and its file stream. > This > + * function is called by xfs_bmap_filestreams() with the mount point's > per-ag > + * lock held. > + */ > +int > +xfs_filestream_new_ag( > + xfs_bmalloca_t *ap, > + xfs_agnumber_t *agp) > +{ > + int flags, err; > + xfs_inode_t *ip, *pip = NULL; > + xfs_mount_t *mp; > + xfs_mru_cache_t *cache; > + xfs_extlen_t minlen; > + fstrm_item_t *dir, *file; > + xfs_agnumber_t ag = NULLAGNUMBER; > + > + ip = ap->ip; > + mp = ip->i_mount; > + cache = mp->m_filestream->fstrm_items; > + minlen = ap->alen; > + *agp = NULLAGNUMBER; > + > + /* > + * Look for the file in the cache, removing it if it's found. Doing > + * this allows it to be held across the dir lookup that follows. > + */ > + if ((file = (fstrm_item_t*)xfs_mru_cache_remove(cache, ip->i_ino))) { > + ASSERT(ip == file->ip); > + > + /* Save the file's parent inode and old AG number for later. */ > + pip = file->pip; > + ag = file->ag; > + > + /* Look for the file's directory in the cache. */ > + dir = (fstrm_item_t*)xfs_mru_cache_lookup(cache, pip->i_ino); > + if (dir) { > + ASSERT(pip == dir->ip); > + > + /* > + * If the directory has already moved on to a new AG, > + * use that AG as the new AG for the file. Don't > + * forget to twiddle the AG refcounts to match the > + * movement. > + */ > + if (dir->ag != file->ag) { > + DEC_AG_REF(mp, file->ag); > + INC_AG_REF(mp, dir->ag); > + *agp = file->ag = dir->ag; > + } > + > + xfs_mru_cache_done(cache); > + } > + > + /* > + * Put the file back in the cache. If this fails, the free > + * function needs to be called to tidy up in the same way as if > + * the item had simply expired from the cache. > + */ > + if ((err = xfs_mru_cache_insert(cache, ip->i_ino, file))) { > + xfs_fstrm_free_func(ip->i_ino, file); > + return err; > + } > + > + /* > + * If the file's AG was moved to the directory's new AG, there's > + * nothing more to be done. > + */ > + if (*agp != NULLAGNUMBER) { > + dprint("dir %p ino %lld for file %p ino %lld has " > + "already moved %d[%d] -> %d[%d]", pip, > + pip->i_ino, ip, ip->i_ino, ag, > + GET_AG_REF(mp, ag), *agp, GET_AG_REF(mp, *agp)); > + return 0; > + } > + } > + > + /* > + * If the file's parent directory is known, take its iolock in exclusive > + * mode to prevent two sibling files from racing each other to migrate > + * themselves and their parent to different AGs. > + */ > + if (pip) > + xfs_ilock(pip, XFS_IOLOCK_EXCL); > + > + /* > + * A new AG needs to be found for the file. If the file's parent > + * directory is also known, it will be moved to the new AG as well to > + * ensure that files created inside it in future use the new AG. > + */ > + ag = (ag == NULLAGNUMBER) ? 0 : (ag + 1) % mp->m_sb.sb_agcount; > + flags = (ap->userdata ? XFS_PICK_USERDATA : 0) | > + (ap->low ? XFS_PICK_LOWSPACE : 0); > + > + if ((err = _xfs_filestream_pick_ag(mp, ag, agp, flags, minlen)) || > + *agp == NULLAGNUMBER) > + goto exit; > + > + /* > + * If the file wasn't found in the file cache, then its parent directory > + * inode isn't known. For this to have happened, the file must either > + * be pre-existing, or it was created long enough ago that its cache > + * entry has expired. This isn't the sort of usage that the filestreams > + * allocator is trying to optimise, so there's no point trying to track > + * its new AG somehow in the filestream data structures. > + */ > + if (!pip) { > + dprint("gave ag %d to orphan ip %p ino %lld", *agp, ip, > + ip->i_ino); > + goto exit; > + } > + > + /* Associate the parent inode with the AG. */ > + if ((err = _xfs_filestream_set_ag(pip, NULL, *agp))) { > + dprint("_xfs_filestream_set_ag(%p (%lld), NULL, %d) -> err %d", > + pip, pip->i_ino, *agp, err); > + goto exit; > + } > + > + /* Associate the file inode with the AG. */ > + if ((err = _xfs_filestream_set_ag(ip, pip, *agp))) { > + dprint("_xfs_filestream_set_ag(%p (%lld), %p (%lld), %d) -> " > + "err %d", ip, ip->i_ino, pip, pip->i_ino, *agp, err); > + goto exit; > + } > + > + dprint("pip %p ino %lld and ip %p ino %lld moved to new ag %d[%d]", > + pip, pip->i_ino, ip, ip->i_ino, *agp, GET_AG_REF(mp, *agp)); > + > +exit: > + /* > + * If _xfs_filestream_pick_ag() returned a valid AG, remove the > + * reference it took on it, since the file and directory will have taken > + * their own now if they were successfully cached. > + */ > + if (*agp != NULLAGNUMBER) > + DEC_AG_REF(mp, *agp); > + else { > + dprint("_pick_ag() returned invalid AG %d, using AG 0", *agp); > + *agp = 0; > + } > + > + if (pip) > + xfs_iunlock(pip, XFS_IOLOCK_EXCL); > + > + return err; > +} > + > +/* > + * Remove an association between an inode and a filestream object. > + * Typically this is done on last close of an unlinked file. > + */ > +void > +xfs_filestream_deassociate( > + xfs_inode_t *ip) > +{ > + xfs_mru_cache_t *cache = ip->i_mount->m_filestream->fstrm_items; > + > + xfs_mru_cache_delete(cache, ip->i_ino); > +} > Index: 2.6.x-xfs-new/fs/xfs/xfs_filestream.h > =================================================================== > --- /dev/null 1970-01-01 00:00:00.000000000 +0000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_filestream.h 2007-05-10 17:24:13.107008304 > +1000 > @@ -0,0 +1,59 @@ > +/* > + * 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_FILESTREAM_H__ > +#define __XFS_FILESTREAM_H__ > + > +#ifdef __KERNEL__ > + > +struct xfs_mount; > +struct xfs_inode; > +struct xfs_perag; > +struct xfs_bmalloca; > + > +void > +xfs_filestream_init(void); > + > +void > +xfs_filestream_uninit(void); > + > +int > +xfs_filestream_mount(struct xfs_mount *mp); > + > +void > +xfs_filestream_unmount(struct xfs_mount *mp); > + > +void > +xfs_filestream_flush(struct xfs_mount *mp); > + > +xfs_agnumber_t > +xfs_filestream_get_ag(struct xfs_inode *ip); > + > +int > +xfs_filestream_associate(struct xfs_inode *dip, > + struct xfs_inode *ip); > + > +void > +xfs_filestream_deassociate(struct xfs_inode *ip); > + > +int > +xfs_filestream_new_ag(struct xfs_bmalloca *ap, > + xfs_agnumber_t *agp); > + > +#endif /* __KERNEL__ */ > + > +#endif /* __XFS_FILESTREAM_H__ */ > Index: 2.6.x-xfs-new/fs/xfs/xfs_fs.h > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_fs.h 2007-05-10 17:22:43.506752209 +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_fs.h 2007-05-10 17:24:13.123006207 +1000 > @@ -66,6 +66,7 @@ struct fsxattr { > #define XFS_XFLAG_EXTSIZE 0x00000800 /* extent size allocator hint */ > #define XFS_XFLAG_EXTSZINHERIT 0x00001000 /* inherit inode extent size */ > #define XFS_XFLAG_NODEFRAG 0x00002000 /* do not defragment */ > +#define XFS_XFLAG_FILESTREAM 0x00004000 /* use filestream allocator */ > #define XFS_XFLAG_HASATTR 0x80000000 /* no DIFLAG for this */ > > /* > Index: 2.6.x-xfs-new/fs/xfs/xfs_fsops.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_fsops.c 2007-05-10 17:22:43.506752209 > +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_fsops.c 2007-05-10 17:24:13.131005159 +1000 > @@ -44,6 +44,7 @@ > #include "xfs_trans_space.h" > #include "xfs_rtalloc.h" > #include "xfs_rw.h" > +#include "xfs_filestream.h" > > /* > * File system operations > @@ -163,6 +164,7 @@ xfs_growfs_data_private( > new = nb - mp->m_sb.sb_dblocks; > oagcount = mp->m_sb.sb_agcount; > if (nagcount > oagcount) { > + xfs_filestream_flush(mp); > down_write(&mp->m_peraglock); > mp->m_perag = kmem_realloc(mp->m_perag, > sizeof(xfs_perag_t) * nagcount, > Index: 2.6.x-xfs-new/fs/xfs/xfs_inode.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_inode.c 2007-05-10 17:22:43.506752209 > +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_inode.c 2007-05-10 17:24:13.143003586 +1000 > @@ -48,6 +48,7 @@ > #include "xfs_dir2_trace.h" > #include "xfs_quota.h" > #include "xfs_acl.h" > +#include "xfs_filestream.h" > > > kmem_zone_t *xfs_ifork_zone; > @@ -817,6 +818,8 @@ _xfs_dic2xflags( > flags |= XFS_XFLAG_EXTSZINHERIT; > if (di_flags & XFS_DIFLAG_NODEFRAG) > flags |= XFS_XFLAG_NODEFRAG; > + if (di_flags & XFS_DIFLAG_FILESTREAM) > + flags |= XFS_XFLAG_FILESTREAM; > } > > return flags; > @@ -1099,7 +1102,7 @@ xfs_ialloc( > * Call the space management code to pick > * the on-disk inode to be allocated. > */ > - error = xfs_dialloc(tp, pip->i_ino, mode, okalloc, > + error = xfs_dialloc(tp, pip ? pip->i_ino : 0, mode, okalloc, > ialloc_context, call_again, &ino); > if (error != 0) { > return error; > @@ -1153,7 +1156,7 @@ xfs_ialloc( > if ( (prid != 0) && (ip->i_d.di_version == XFS_DINODE_VERSION_1)) > xfs_bump_ino_vers2(tp, ip); > > - if (XFS_INHERIT_GID(pip, vp->v_vfsp)) { > + if (pip && XFS_INHERIT_GID(pip, vp->v_vfsp)) { > ip->i_d.di_gid = pip->i_d.di_gid; > if ((pip->i_d.di_mode & S_ISGID) && (mode & S_IFMT) == S_IFDIR) { > ip->i_d.di_mode |= S_ISGID; > @@ -1195,8 +1198,14 @@ xfs_ialloc( > flags |= XFS_ILOG_DEV; > break; > case S_IFREG: > + if (unlikely(pip && > + ((ip->i_mount->m_flags & XFS_MOUNT_FILESTREAMS) || > + (pip->i_d.di_flags & XFS_DIFLAG_FILESTREAM)) && > + (error = xfs_filestream_associate(pip, ip)))) > + return error; > + /* fall through */ > case S_IFDIR: > - if (unlikely(pip->i_d.di_flags & XFS_DIFLAG_ANY)) { > + if (unlikely(pip && (pip->i_d.di_flags & XFS_DIFLAG_ANY))) { > uint di_flags = 0; > > if ((mode & S_IFMT) == S_IFDIR) { > @@ -1233,6 +1242,8 @@ xfs_ialloc( > if ((pip->i_d.di_flags & XFS_DIFLAG_NODEFRAG) && > xfs_inherit_nodefrag) > di_flags |= XFS_DIFLAG_NODEFRAG; > + if (pip->i_d.di_flags & XFS_DIFLAG_FILESTREAM) > + di_flags |= XFS_DIFLAG_FILESTREAM; > ip->i_d.di_flags |= di_flags; > } > /* FALLTHROUGH */ > Index: 2.6.x-xfs-new/fs/xfs/xfs_mount.h > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_mount.h 2007-05-10 17:22:43.506752209 > +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_mount.h 2007-05-10 17:24:13.147003062 +1000 > @@ -66,6 +66,7 @@ struct xfs_bmbt_irec; > struct xfs_bmap_free; > struct xfs_extdelta; > struct xfs_swapext; > +struct xfs_filestream; > > extern struct bhv_vfsops xfs_vfsops; > extern struct bhv_vnodeops xfs_vnodeops; > @@ -436,6 +437,7 @@ typedef struct xfs_mount { > struct notifier_block m_icsb_notifier; /* hotplug cpu notifier */ > struct mutex m_icsb_mutex; /* balancer sync lock */ > #endif > + struct fstrm_mnt_data *m_filestream; /* per-mount filestream data */ > } xfs_mount_t; > > /* > @@ -475,6 +477,8 @@ typedef struct xfs_mount { > * I/O size in stat() */ > #define XFS_MOUNT_NO_PERCPU_SB (1ULL << 23) /* don't use per-cpu > superblock > counters */ > +#define XFS_MOUNT_FILESTREAMS (1ULL << 24) /* enable the filestreams > + allocator */ > > > /* > Index: 2.6.x-xfs-new/fs/xfs/xfs_mru_cache.c > =================================================================== > --- /dev/null 1970-01-01 00:00:00.000000000 +0000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_mru_cache.c 2007-05-10 17:24:13.151002538 > +1000 > @@ -0,0 +1,607 @@ > +/* > + * Copyright (c) 2000-2002,2006 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 > + */ > +//#define DEBUG_MRU_CACHE 1 > +#include "xfs.h" > +#include "xfs_mru_cache.h" > + > +/* > + * An MRU Cache is a dynamic data structure that stores its elements in a > way > + * that allows efficient lookups, but also groups them into discrete time > + * intervals based on insertion time. This allows elements to be > efficiently > + * and automatically reaped after a fixed period of inactivity. > + */ > + > +#ifdef DEBUG_MRU_CACHE > +#define dprint(fmt, args...) do { > \ > + printk(KERN_DEBUG "%4d %s: " fmt "\n", > \ > + current_pid(), __FUNCTION__, ##args); > \ > +} while(0) > + > +#define DEBUG_DECL_CACHE_FIELDS > \ > + unsigned int *list_elems; > \ > + unsigned int reap_elems; > \ > + unsigned long allocs; > \ > + unsigned long frees; > + > +#define DEBUG_INIT_CACHE(mru) > \ > + ((mru)->list_elems = (unsigned int*) > \ > + kmem_zalloc((mru)->grp_count * > sizeof(*(mru)->list_elems), \ > + KM_SLEEP)) > + > +#define DEBUG_UNINIT_CACHE(mru) > \ > + kmem_free((mru)->list_elems, > \ > + (mru)->grp_count * sizeof(*(mru)->list_elems)) > + > +#define DEBUG_INC_ALLOCS(mru) (mru)->allocs++ > +#define DEBUG_INC_FREES(mru) (mru)->frees++ > + > +STATIC int > +_xfs_mru_cache_print(struct xfs_mru_cache *mru, char *buf); > + > +#define DEBUG_PRINT_STACK_VARS > \ > + char buf[256]; > \ > + char *bufp = buf; > + > +#define DEBUG_PRINT_BEFORE_REAP > \ > + bufp += _xfs_mru_cache_print(mru, bufp) > + > +#define DEBUG_PRINT_AFTER_REAP > \ > + bufp += sprintf(bufp, " -> "); > \ > + bufp += _xfs_mru_cache_print(mru, bufp); > \ > + dprint("[%p]: %s", mru, buf) > +#else /* !defined DEBUG_MRU_CACHE */ > +#define dprint(args...) do {} while (0) > +#define DEBUG_DECL_CACHE_FIELDS > +#define DEBUG_INIT_CACHE(mru) 1 > +#define DEBUG_UNINIT_CACHE(mru) do {} while (0) > +#define DEBUG_INC_ALLOCS(mru) do {} while (0) > +#define DEBUG_INC_FREES(mru) do {} while (0) > +#define DEBUG_PRINT_STACK_VARS > +#define DEBUG_PRINT_BEFORE_REAP do {} while (0) > +#define DEBUG_PRINT_AFTER_REAP do {} while (0) > +#endif /* DEBUG_MRU_CACHE */ > + > + > +/* > + * When a client data pointer is stored in the MRU Cache it needs to be > added to > + * both the data store and to one of the lists. It must also be possible > to > + * access each of these entries via the other, i.e. to: > + * > + * a) Walk a list, removing the corresponding data store entry for > each item. > + * b) Look up a data store entry, then access its list entry directly. > + * > + * To achieve both of these goals, each entry must contain both a list > entry and > + * a key, in addition to the user's data pointer. Note that it's not a > good > + * idea to have the client embed one of these structures at the top of > their own > + * data structure, because inserting the same item more than once would > most > + * likely result in a loop in one of the lists. That's a sure-fire > recipe for > + * an infinite loop in the code. > + */ > +typedef struct xfs_mru_cache_elem > +{ > + struct list_head list_node; > + unsigned long key; > + void *value; > +} xfs_mru_cache_elem_t; > + > +static kmem_zone_t *elem_zone; > +static struct workqueue_struct *reap_wq; > + > +/* > + * When inserting, destroying or reaping, it's first necessary to update > the > + * lists relative to a particular time. In the case of destroying, that > time > + * will be well in the future to ensure that all items are moved to the > reap > + * list. In all other cases though, the time will be the current time. > + * > + * This function enters a loop, moving the contents of the LRU list to > the reap > + * list again and again until either a) the lists are all empty, or b) > time zero > + * has been advanced sufficiently to be within the immediate element > lifetime. > + * > + * Case a) above is detected by counting how many groups are migrated and > + * stopping when they've all been moved. Case b) is detected by > monitoring the > + * time_zero field, which is updated as each group is migrated. > + * > + * The return value is the earliest time that more migration could be > needed, or > + * zero if there's no need to schedule more work because the lists are > empty. > + */ > +STATIC unsigned long > +_xfs_mru_cache_migrate( > + xfs_mru_cache_t *mru, > + unsigned long now) > +{ > + unsigned int grp; > + unsigned int migrated = 0; > + struct list_head *lru_list; > + > + /* Nothing to do if the data store is empty. */ > + if (!mru->time_zero) > + return 0; > + > + /* While time zero is older than the time spanned by all the lists. */ > + while (mru->time_zero <= now - mru->grp_count * mru->grp_time) { > + > + /* > + * If the LRU list isn't empty, migrate its elements to the tail > + * of the reap list. > + */ > + lru_list = mru->lists + mru->lru_grp; > + if (!list_empty(lru_list)) > + list_splice_init(lru_list, mru->reap_list.prev); > + > + /* > + * Advance the LRU group number, freeing the old LRU list to > + * become the new MRU list; advance time zero accordingly. > + */ > + mru->lru_grp = (mru->lru_grp + 1) % mru->grp_count; > + mru->time_zero += mru->grp_time; > + > + /* > + * If reaping is so far behind that all the elements on all the > + * lists have been migrated to the reap list, it's now empty. > + */ > + if (++migrated == mru->grp_count) { > + mru->lru_grp = 0; > + mru->time_zero = 0; > + return 0; > + } > + } > + > + /* Find the first non-empty list from the LRU end. */ > + for (grp = 0; grp < mru->grp_count; grp++) { > + > + /* Check the grp'th list from the LRU end. */ > + lru_list = mru->lists + ((mru->lru_grp + grp) % mru->grp_count); > + if (!list_empty(lru_list)) > + return mru->time_zero + > + (mru->grp_count + grp) * mru->grp_time; > + } > + > + /* All the lists must be empty. */ > + mru->lru_grp = 0; > + mru->time_zero = 0; > + return 0; > +} > + > +/* > + * When inserting or doing a lookup, an element needs to be inserted into > the > + * MRU list. The lists must be migrated first to ensure that they're > + * up-to-date, otherwise the new element could be given a shorter > lifetime in > + * the cache than it should. > + */ > +STATIC void > +_xfs_mru_cache_list_insert( > + xfs_mru_cache_t *mru, > + xfs_mru_cache_elem_t *elem) > +{ > + unsigned int grp = 0; > + unsigned long now = jiffies; > + > + /* > + * If the data store is empty, initialise time zero, leave grp set to > + * zero and start the work queue timer if necessary. Otherwise, set grp > + * to the number of group times that have elapsed since time zero. > + */ > + if (!_xfs_mru_cache_migrate(mru, now)) { > + mru->time_zero = now; > + if (!mru->next_reap) > + mru->next_reap = mru->grp_count * mru->grp_time; > + } else { > + grp = (now - mru->time_zero) / mru->grp_time; > + grp = (mru->lru_grp + grp) % mru->grp_count; > + } > + > + /* Insert the element at the tail of the corresponding list. */ > + list_add_tail(&elem->list_node, mru->lists + grp); > +} > + > +/* > + * When destroying or reaping, all the elements that were migrated to the > reap > + * list need to be deleted. For each element this involves removing it > from the > + * data store, removing it from the reap list, calling the client's free > + * function and deleting the element from the element zone. > + */ > +STATIC void > +_xfs_mru_cache_clear_reap_list( > + xfs_mru_cache_t *mru) > +{ > + xfs_mru_cache_elem_t *elem, *next; > + struct list_head tmp; > + > + INIT_LIST_HEAD(&tmp); > + list_for_each_entry_safe(elem, next, &mru->reap_list, list_node) { > + > + /* Remove the element from the data store. */ > + radix_tree_delete(&mru->store, elem->key); > + > + /* > + * remove to temp list so it can be freed without > + * needing to hold the lock > + */ > + list_move(&elem->list_node, &tmp); > + } > + mutex_spinunlock(&mru->lock, 0); > + > + list_for_each_entry_safe(elem, next, &tmp, list_node) { > + > + /* Remove the element from the reap list. */ > + list_del_init(&elem->list_node); > + > + /* Call the client's free function with the key and value pointer. */ > + mru->free_func(elem->key, elem->value); > + > + /* Free the element structure. */ > + kmem_zone_free(elem_zone, elem); > + DEBUG_INC_FREES(mru); > + } > + > + mutex_spinlock(&mru->lock); > +} > + > +/* > + * We fire the reap timer every group expiry interval so > + * we always have a reaper ready to run. This makes shutdown > + * and flushing of the reaper easy to do. Hence we need to > + * keep when the next reap must occur so we can determine > + * at each interval whether there is anything we need to do. > + */ > +STATIC void > +_xfs_mru_cache_reap( > + struct work_struct *work) > +{ > + xfs_mru_cache_t *mru = container_of(work, xfs_mru_cache_t, work.work); > + unsigned long now, next; > + DEBUG_PRINT_STACK_VARS; > + > + ASSERT(mru && mru->lists); > + if (!mru || !mru->lists) > + return; > + > + mutex_spinlock(&mru->lock); > + now = jiffies; > + if (mru->reap_all || > + (mru->next_reap && time_after(now, mru->next_reap))) { > + DEBUG_PRINT_BEFORE_REAP; > + if (mru->reap_all) > + now += mru->grp_count * mru->grp_time * 2; > + mru->next_reap = _xfs_mru_cache_migrate(mru, now); > + _xfs_mru_cache_clear_reap_list(mru); > + DEBUG_PRINT_AFTER_REAP; > + } > + > + /* > + * the process that triggered the reap_all is responsible > + * for restating the periodic reap if it is required. > + */ > + if (!mru->reap_all) > + queue_delayed_work(reap_wq, &mru->work, mru->grp_time); > + mru->reap_all = 0; > + mutex_spinunlock(&mru->lock, 0); > +} > + > +int > +xfs_mru_cache_init(void) > +{ > + if (!(elem_zone = kmem_zone_init(sizeof(xfs_mru_cache_elem_t), > + "xfs_mru_cache_elem"))) > + return ENOMEM; > + > + if (!(reap_wq = create_singlethread_workqueue("xfs_mru_cache"))) { > + kmem_zone_destroy(elem_zone); > + elem_zone = NULL; > + return ENOMEM; > + } > + > + return 0; > +} > + > +void > +xfs_mru_cache_uninit(void) > +{ > + if (reap_wq) { > + destroy_workqueue(reap_wq); > + reap_wq = NULL; > + } > + > + if (elem_zone) { > + kmem_zone_destroy(elem_zone); > + elem_zone = NULL; > + } > +} > + > +int > +xfs_mru_cache_create( > + xfs_mru_cache_t **mrup, > + unsigned int lifetime_ms, > + unsigned int grp_count, > + xfs_mru_cache_free_func_t free_func) > +{ > + xfs_mru_cache_t *mru = NULL; > + int err = 0, grp; > + unsigned int grp_time; > + > + if (mrup) > + *mrup = NULL; > + > + if (!mrup || !grp_count || !lifetime_ms || !free_func) > + return EINVAL; > + > + if (!(grp_time = msecs_to_jiffies(lifetime_ms) / grp_count)) > + return EINVAL; > + > + if (!(mru = kmem_zalloc(sizeof(*mru), KM_SLEEP))) > + return ENOMEM; > + > + /* An extra list is needed to avoid reaping up to a grp_time early. */ > + mru->grp_count = grp_count + 1; > + mru->lists = (struct list_head*) > + kmem_alloc(mru->grp_count * sizeof(*mru->lists), KM_SLEEP); > + > + if (!mru->lists || !DEBUG_INIT_CACHE(mru)) { > + err = ENOMEM; > + goto exit; > + } > + > + for (grp = 0; grp < mru->grp_count; grp++) > + INIT_LIST_HEAD(mru->lists + grp); > + > + /* > + * We use GFP_KERNEL radix tree preload and do inserts under a > + * spinlock so GFP_ATOMIC is appropriate for the radix tree itself. > + */ > + INIT_RADIX_TREE(&mru->store, GFP_ATOMIC); > + INIT_LIST_HEAD(&mru->reap_list); > + spinlock_init(&mru->lock, "xfs_mru_cache"); > + INIT_DELAYED_WORK(&mru->work, _xfs_mru_cache_reap); > + > + mru->grp_time = grp_time; > + mru->free_func = free_func; > + > + /* start up the reaper event */ > + mru->next_reap = 0; > + mru->reap_all = 0; > + queue_delayed_work(reap_wq, &mru->work, mru->grp_time); > + > + *mrup = mru; > + > +exit: > + if (err && mru && mru->lists) > + kmem_free(mru->lists, mru->grp_count * sizeof(*mru->lists)); > + if (err && mru) > + kmem_free(mru, sizeof(*mru)); > + > + return err; > +} > + > +/* > + * When flushing, we stop the periodic reaper from running first > + * so we don't race with it. If we are flushing on unmount, we > + * don't want to restart the reaper again, so the restart is conditional. > + * > + * Because reaping can drop the last refcount on inodes which can free > + * extents, we have to push the reaping off to the workqueue thread > + * because we could be called holding locks that extent freeing requires. > + */ > +void > +xfs_mru_cache_flush( > + xfs_mru_cache_t *mru, > + int restart) > +{ > + DEBUG_PRINT_STACK_VARS; > + > + if (!mru || !mru->lists) > + return; > + > + cancel_rearming_delayed_workqueue(reap_wq, &mru->work); > + > + mutex_spinlock(&mru->lock); > + mru->reap_all = 1; > + mutex_spinunlock(&mru->lock, 0); > + > + queue_work(reap_wq, &mru->work.work); > + flush_workqueue(reap_wq); > + > + mutex_spinlock(&mru->lock); > + WARN_ON_ONCE(mru->reap_all != 0); > + mru->reap_all = 0; > + if (restart) > + queue_delayed_work(reap_wq, &mru->work, mru->grp_time); > + mutex_spinunlock(&mru->lock, 0); > +} > + > +void > +xfs_mru_cache_destroy( > + xfs_mru_cache_t *mru) > +{ > + if (!mru || !mru->lists) > + return; > + > + /* we don't want the reaper to restart here */ > + xfs_mru_cache_flush(mru, 0); > + > + DEBUG_UNINIT_CACHE(mru); > + kmem_free(mru->lists, mru->grp_count * sizeof(*mru->lists)); > + kmem_free(mru, sizeof(*mru)); > +} > + > +int > +xfs_mru_cache_insert( > + xfs_mru_cache_t *mru, > + unsigned long key, > + void *value) > +{ > + xfs_mru_cache_elem_t *elem; > + > + ASSERT(mru && mru->lists); > + if (!mru || !mru->lists) > + return EINVAL; > + > + elem = (xfs_mru_cache_elem_t*)kmem_zone_zalloc(elem_zone, KM_SLEEP); > + if (!elem) > + return ENOMEM; > + > + if (radix_tree_preload(GFP_KERNEL)) { > + kmem_zone_free(elem_zone, elem); > + return ENOMEM; > + } > + > + INIT_LIST_HEAD(&elem->list_node); > + elem->key = key; > + elem->value = value; > + > + mutex_spinlock(&mru->lock); > + > + radix_tree_insert(&mru->store, key, elem); > + radix_tree_preload_end(); > + > + _xfs_mru_cache_list_insert(mru, elem); > + > + DEBUG_INC_ALLOCS(mru); > + > + mutex_spinunlock(&mru->lock, 0); > + > + return 0; > +} > + > +void* > +xfs_mru_cache_remove( > + xfs_mru_cache_t *mru, > + unsigned long key) > +{ > + xfs_mru_cache_elem_t *elem; > + void *value = NULL; > + > + ASSERT(mru && mru->lists); > + if (!mru || !mru->lists) > + return NULL; > + > + mutex_spinlock(&mru->lock); > + elem = (xfs_mru_cache_elem_t*)radix_tree_delete(&mru->store, key); > + if (elem) { > + value = elem->value; > + list_del(&elem->list_node); > + DEBUG_INC_FREES(mru); > + } > + > + mutex_spinunlock(&mru->lock, 0); > + > + if (elem) > + kmem_zone_free(elem_zone, elem); > + > + return value; > +} > + > +void > +xfs_mru_cache_delete( > + xfs_mru_cache_t *mru, > + unsigned long key) > +{ > + void *value; > + > + if ((value = xfs_mru_cache_remove(mru, key))) > + mru->free_func(key, value); > +} > + > +void* > +xfs_mru_cache_lookup( > + xfs_mru_cache_t *mru, > + unsigned long key) > +{ > + xfs_mru_cache_elem_t *elem; > + > + ASSERT(mru && mru->lists); > + if (!mru || !mru->lists) > + return NULL; > + > + mutex_spinlock(&mru->lock); > + elem = (xfs_mru_cache_elem_t*)radix_tree_lookup(&mru->store, key); > + if (elem) { > + list_del(&elem->list_node); > + _xfs_mru_cache_list_insert(mru, elem); > + } > + else > + mutex_spinunlock(&mru->lock, 0); > + > + return elem ? elem->value : NULL; > +} > + > +void* > +xfs_mru_cache_peek( > + xfs_mru_cache_t *mru, > + unsigned long key) > +{ > + xfs_mru_cache_elem_t *elem; > + > + ASSERT(mru && mru->lists); > + if (!mru || !mru->lists) > + return NULL; > + > + mutex_spinlock(&mru->lock); > + elem = (xfs_mru_cache_elem_t*)radix_tree_lookup(&mru->store, key); > + if (!elem) > + mutex_spinunlock(&mru->lock, 0); > + > + return elem ? elem->value : NULL; > +} > + > +void > +xfs_mru_cache_done( > + xfs_mru_cache_t *mru) > +{ > + mutex_spinunlock(&mru->lock, 0); > +} > + > +#ifdef DEBUG_MRU_CACHE > +STATIC int > +_xfs_mru_cache_print( > + xfs_mru_cache_t *mru, > + char *buf) > +{ > + unsigned int grp; > + struct list_head *node; > + char *bufp = buf; > + > + for (grp = 0; grp < mru->grp_count; grp++) { > + mru->list_elems[grp] = 0; > + list_for_each(node, mru->lists + grp) > + mru->list_elems[grp]++; > + } > + mru->reap_elems = 0; > + list_for_each(node, &mru->reap_list) > + mru->reap_elems++; > + > + bufp += sprintf(bufp, "(%d) ", mru->reap_elems); > + > + for (grp = 0; grp < mru->grp_count; grp++) > + { > + if (grp == mru->lru_grp) > + *bufp++ = '*'; > + > + bufp += sprintf(bufp, "%u", mru->list_elems[grp]); > + > + if (grp == mru->lru_grp) > + *bufp++ = '*'; > + > + if (grp < mru->grp_count - 1) > + *bufp++ = ' '; > + } > + > + bufp += sprintf(bufp, " [%lu/%lu]", mru->allocs, mru->frees); > + > + return bufp - buf; > +} > +#endif /* DEBUG_MRU_CACHE */ > Index: 2.6.x-xfs-new/fs/xfs/xfs_mru_cache.h > =================================================================== > --- /dev/null 1970-01-01 00:00:00.000000000 +0000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_mru_cache.h 2007-05-10 17:24:13.155002014 > +1000 > @@ -0,0 +1,225 @@ > +/* > + * Copyright (c) 2000-2002,2006 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_MRU_CACHE_H__ > +#define __XFS_MRU_CACHE_H__ > + > +/* > + * The MRU Cache data structure consists of a data store, an array of > lists and > + * a lock to protect its internal state. At initialisation time, the > client > + * supplies an element lifetime in milliseconds and a group count, as > well as a > + * function pointer to call when deleting elements. A data structure for > + * queueing up work in the form of timed callbacks is also included. > + * > + * The group count controls how many lists are created, and thereby how > finely > + * the elements are grouped in time. When reaping occurs, all the > elements in > + * all the lists whose time has expired are deleted. > + * > + * To give an example of how this works in practice, consider a client > that > + * initialises an MRU Cache with a lifetime of ten seconds and a group > count of > + * five. Five internal lists will be created, each representing a two > second > + * period in time. When the first element is added, time zero for the > data > + * structure is initialised to the current time. > + * > + * All the elements added in the first two seconds are appended to the > first > + * list. Elements added in the third second go into the second list, and > so on. > + * If an element is accessed at any point, it is removed from its list > and > + * inserted at the head of the current most-recently-used list. > + * > + * The reaper function will have nothing to do until at least twelve > seconds > + * have elapsed since the first element was added. The reason for this > is that > + * if it were called at t=11s, there could be elements in the first list > that > + * have only been inactive for nine seconds, so it still does nothing. > If it is > + * called anywhere between t=12 and t=14 seconds, it will delete all the > + * elements that remain in the first list. It's therefore possible for > elements > + * to remain in the data store even after they've been inactive for up to > + * (t + t/g) seconds, where t is the inactive element lifetime and g is > the > + * number of groups. > + * > + * The above example assumes that the reaper function gets called at > least once > + * every (t/g) seconds. If it is called less frequently, unused elements > will > + * accumulate in the reap list until the reaper function is eventually > called. > + * The current implementation uses work queue callbacks to carefully time > the > + * reaper function calls, so this should happen rarely, if at all. > + * > + * From a design perspective, the primary reason for the choice of a list > array > + * representing discrete time intervals is that it's only practical to > reap > + * expired elements in groups of some appreciable size. This > automatically > + * introduces a granularity to element lifetimes, so there's no point > storing an > + * individual timeout with each element that specifies a more precise > reap time. > + * The bonus is a saving of sizeof(long) bytes of memory per element > stored. > + * > + * The elements could have been stored in just one list, but an array of > + * counters or pointers would need to be maintained to allow them to be > divided > + * up into discrete time groups. More critically, the process of > touching or > + * removing an element would involve walking large portions of the entire > list, > + * which would have a detrimental effect on performance. The additional > memory > + * requirement for the array of list heads is minimal. > + * > + * When an element is touched or deleted, it needs to be removed from its > + * current list. Doubly linked lists are used to make the list > maintenance > + * portion of these operations O(1). Since reaper timing can be > imprecise, > + * inserts and lookups can occur when there are no free lists available. > When > + * this happens, all the elements on the LRU list need to be migrated to > the end > + * of the reap list. To keep the list maintenance portion of these > operations > + * O(1) also, list tails need to be accessible without walking the entire > list. > + * This is the reason why doubly linked list heads are used. > + */ > + > +/* Function pointer type for callback to free a client's data pointer. */ > +typedef void (*xfs_mru_cache_free_func_t)(void*, void*); > + > +typedef struct xfs_mru_cache > +{ > + struct radix_tree_root store; /* Core storage data structure. */ > + struct list_head *lists; /* Array of lists, one per grp. */ > + struct list_head reap_list; /* Elements overdue for reaping. */ > + spinlock_t lock; /* Lock to protect this struct. */ > + unsigned int grp_count; /* Number of discrete groups. */ > + unsigned int grp_time; /* Time period spanned by grps. */ > + unsigned int lru_grp; /* Group containing time zero. */ > + unsigned long time_zero; /* Time first element was added. */ > + unsigned long next_reap; /* Time that the reaper should > + next do something. */ > + unsigned int reap_all; /* if set, reap all lists */ > + xfs_mru_cache_free_func_t free_func; /* Function pointer for freeing. */ > + struct delayed_work work; /* Workqueue data for reaping. */ > +#ifdef DEBUG_MRU_CACHE > + unsigned int *list_elems; > + unsigned int reap_elems; > + unsigned long allocs; > + unsigned long frees; > +#endif > +} xfs_mru_cache_t; > + > +/* > + * xfs_mru_cache_init() prepares memory zones and any other globally > scoped > + * resources. > + */ > +int > +xfs_mru_cache_init(void); > + > +/* > + * xfs_mru_cache_uninit() tears down all the globally scoped resources > prepared > + * in xfs_mru_cache_init(). > + */ > +void > +xfs_mru_cache_uninit(void); > + > +/* > + * To initialise a struct xfs_mru_cache pointer, call > xfs_mru_cache_create() > + * with the address of the pointer, a lifetime value in milliseconds, a > group > + * count and a free function to use when deleting elements. This > function > + * returns 0 if the initialisation was successful. > + */ > +int > +xfs_mru_cache_create(struct xfs_mru_cache **mrup, > + unsigned int lifetime_ms, > + unsigned int grp_count, > + xfs_mru_cache_free_func_t free_func); > + > +/* > + * Call xfs_mru_cache_flush() to flush out all cached entries, calling > their > + * free functions as they're deleted. When this function returns, the > caller is > + * guaranteed that all the free functions for all the elements have > finished > + * executing. > + * > + * While we are flushing, we stop the periodic reaper event from > triggering. > + * Normally, we want to restart this periodic event, but if we are > shutting > + * down the cache we do not want it restarted. hence the restart > parameter > + * where 0 = do not restart reaper and 1 = restart reaper. > + */ > +void > +xfs_mru_cache_flush( > + xfs_mru_cache_t *mru, > + int restart); > + > +/* > + * Call xfs_mru_cache_destroy() with the MRU Cache pointer when the cache > is no > + * longer needed. > + */ > +void > +xfs_mru_cache_destroy(struct xfs_mru_cache *mru); > + > +/* > + * To insert an element, call xfs_mru_cache_insert() with the data store, > the > + * element's key and the client data pointer. This function returns 0 on > + * success or ENOMEM if memory for the data element couldn't be > allocated. > + */ > +int > +xfs_mru_cache_insert(struct xfs_mru_cache *mru, > + unsigned long key, > + void *value); > + > +/* > + * To remove an element without calling the free function, call > + * xfs_mru_cache_remove() with the data store and the element's key. On > success > + * the client data pointer for the removed element is returned, otherwise > this > + * function will return a NULL pointer. > + */ > +void* > +xfs_mru_cache_remove(struct xfs_mru_cache *mru, > + unsigned long key); > + > +/* > + * To remove and element and call the free function, call > xfs_mru_cache_delete() > + * with the data store and the element's key. > + */ > +void > +xfs_mru_cache_delete(struct xfs_mru_cache *mru, > + unsigned long key); > + > +/* > + * To look up an element using its key, call xfs_mru_cache_lookup() with > the > + * data store and the element's key. If found, the element will be moved > to the > + * head of the MRU list to indicate that it's been touched. > + * > + * The internal data structures are protected by a spinlock that is STILL > HELD > + * when this function returns. Call xfs_mru_cache_done() to release it. > Note > + * that it is not safe to call any function that might sleep in the > interim. > + * > + * The implementation could have used reference counting to avoid this > + * restriction, but since most clients simply want to get, set or test a > member > + * of the returned data structure, the extra per-element memory isn't > warranted. > + * > + * If the element isn't found, this function returns NULL and the > spinlock is > + * released. xfs_mru_cache_done() should NOT be called when this occurs. > + */ > +void* > +xfs_mru_cache_lookup(struct xfs_mru_cache *mru, > + unsigned long key); > + > +/* > + * To look up an element using its key, but leave its location in the > internal > + * lists alone, call xfs_mru_cache_peek(). If the element isn't found, > this > + * function returns NULL. > + * > + * See the comments above the declaration of the xfs_mru_cache_lookup() > function > + * for important locking information pertaining to this call. > + */ > +void* > +xfs_mru_cache_peek(struct xfs_mru_cache *mru, > + unsigned long key); > +/* > + * To release the internal data structure spinlock after having performed > an > + * xfs_mru_cache_lookup() or an xfs_mru_cache_peek(), call > xfs_mru_cache_done() > + * with the data store pointer. > + */ > +void > +xfs_mru_cache_done(struct xfs_mru_cache *mru); > + > +#endif /* __XFS_MRU_CACHE_H__ */ > Index: 2.6.x-xfs-new/fs/xfs/xfs_vfsops.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_vfsops.c 2007-05-10 17:22:43.506752209 > +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_vfsops.c 2007-05-10 17:24:13.163000966 +1000 > @@ -51,6 +51,8 @@ > #include "xfs_acl.h" > #include "xfs_attr.h" > #include "xfs_clnt.h" > +#include "xfs_mru_cache.h" > +#include "xfs_filestream.h" > #include "xfs_fsops.h" > > STATIC int xfs_sync(bhv_desc_t *, int, cred_t *); > @@ -81,6 +83,8 @@ xfs_init(void) > xfs_dabuf_zone = kmem_zone_init(sizeof(xfs_dabuf_t), "xfs_dabuf"); > xfs_ifork_zone = kmem_zone_init(sizeof(xfs_ifork_t), "xfs_ifork"); > xfs_acl_zone_init(xfs_acl_zone, "xfs_acl"); > + xfs_mru_cache_init(); > + xfs_filestream_init(); > > /* > * The size of the zone allocated buf log item is the maximum > @@ -164,6 +168,8 @@ xfs_cleanup(void) > xfs_cleanup_procfs(); > xfs_sysctl_unregister(); > xfs_refcache_destroy(); > + xfs_filestream_uninit(); > + xfs_mru_cache_uninit(); > xfs_acl_zone_destroy(xfs_acl_zone); > > #ifdef XFS_DIR2_TRACE > @@ -320,6 +326,9 @@ xfs_start_flags( > else > mp->m_flags &= ~XFS_MOUNT_BARRIER; > > + if (ap->flags2 & XFSMNT2_FILESTREAMS) > + mp->m_flags |= XFS_MOUNT_FILESTREAMS; > + > return 0; > } > > @@ -518,6 +527,9 @@ xfs_mount( > if (mp->m_flags & XFS_MOUNT_BARRIER) > xfs_mountfs_check_barriers(mp); > > + if ((error = xfs_filestream_mount(mp))) > + goto error2; > + > error = XFS_IOINIT(vfsp, args, flags); > if (error) > goto error2; > @@ -575,6 +587,13 @@ xfs_unmount( > */ > xfs_refcache_purge_mp(mp); > > + /* > + * Blow away any referenced inode in the filestreams cache. > + * This can and will cause log traffic as inodes go inactive > + * here. > + */ > + xfs_filestream_unmount(mp); > + > XFS_bflush(mp->m_ddev_targp); > error = xfs_unmount_flush(mp, 0); > if (error) > @@ -682,6 +701,7 @@ xfs_mntupdate( > mp->m_flags &= ~XFS_MOUNT_BARRIER; > } > } else if (!(vfsp->vfs_flag & VFS_RDONLY)) { /* rw -> ro */ > + xfs_filestream_flush(mp); > bhv_vfs_sync(vfsp, SYNC_FSDATA|SYNC_BDFLUSH|SYNC_ATTR, NULL); > xfs_quiesce_fs(mp); > xfs_log_sbcount(mp, 1); > @@ -909,6 +929,9 @@ xfs_sync( > { > xfs_mount_t *mp = XFS_BHVTOM(bdp); > > + if (flags & SYNC_IOWAIT) > + xfs_filestream_flush(mp); > + > return xfs_syncsub(mp, flags, NULL); > } > > @@ -1869,6 +1892,8 @@ xfs_parseargs( > } else if (!strcmp(this_char, "irixsgid")) { > cmn_err(CE_WARN, > "XFS: irixsgid is now a sysctl(2) variable, option is deprecated."); > + } else if (!strcmp(this_char, "filestreams")) { > + args->flags2 |= XFSMNT2_FILESTREAMS; > } else { > cmn_err(CE_WARN, > "XFS: unknown mount option [%s].", this_char); > Index: 2.6.x-xfs-new/fs/xfs/xfs_vnodeops.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_vnodeops.c 2007-05-10 17:22:43.506752209 > +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_vnodeops.c 2007-05-10 17:24:13.170999917 > +1000 > @@ -51,6 +51,7 @@ > #include "xfs_refcache.h" > #include "xfs_trans_space.h" > #include "xfs_log_priv.h" > +#include "xfs_filestream.h" > > STATIC int > xfs_open( > @@ -94,6 +95,19 @@ xfs_close( > return 0; > > /* > + * If we are using filestreams, and we have an unlinked > + * file that we are processing the last close on, then nothing > + * will be able to reopen and write to this file. Purge this > + * inode from the filestreams cache so that it doesn't delay > + * teardown of the inode. > + */ > + if ((ip->i_d.di_nlink == 0) && > + ((ip->i_mount->m_flags & XFS_MOUNT_FILESTREAMS) || > + (ip->i_d.di_flags & XFS_DIFLAG_FILESTREAM))) { > + xfs_filestream_deassociate(ip); > + } > + > + /* > * If we previously truncated this file and removed old data in > * the process, we want to initiate "early" writeout on the last > * close. This is an attempt to combat the notorious NULL files > @@ -820,6 +834,8 @@ xfs_setattr( > di_flags |= XFS_DIFLAG_PROJINHERIT; > if (vap->va_xflags & XFS_XFLAG_NODEFRAG) > di_flags |= XFS_DIFLAG_NODEFRAG; > + if (vap->va_xflags & XFS_XFLAG_FILESTREAM) > + di_flags |= XFS_DIFLAG_FILESTREAM; > if ((ip->i_d.di_mode & S_IFMT) == S_IFDIR) { > if (vap->va_xflags & XFS_XFLAG_RTINHERIT) > di_flags |= XFS_DIFLAG_RTINHERIT; > @@ -2564,6 +2580,18 @@ xfs_remove( > */ > xfs_refcache_purge_ip(ip); > > + /* > + * If we are using filestreams, kill the stream association. > + * If the file is still open it may get a new one but that > + * will get killed on last close in xfs_close() so we don't > + * have to worry about that. > + */ > + if (link_zero && > + ((ip->i_mount->m_flags & XFS_MOUNT_FILESTREAMS) || > + (ip->i_d.di_flags & XFS_DIFLAG_FILESTREAM))) { > + xfs_filestream_deassociate(ip); > + } > + > vn_trace_exit(XFS_ITOV(ip), __FUNCTION__, (inst_t *)__return_address); > > /* > Index: 2.6.x-xfs-new/fs/xfs/quota/xfs_qm.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/quota/xfs_qm.c 2007-05-10 17:22:43.506752209 > +1000 > +++ 2.6.x-xfs-new/fs/xfs/quota/xfs_qm.c 2007-05-10 17:24:13.186997821 > +1000 > @@ -65,7 +65,6 @@ kmem_zone_t *qm_dqtrxzone; > static struct shrinker *xfs_qm_shaker; > > static cred_t xfs_zerocr; > -static xfs_inode_t xfs_zeroino; > > STATIC void xfs_qm_list_init(xfs_dqlist_t *, char *, int); > STATIC void xfs_qm_list_destroy(xfs_dqlist_t *); > @@ -1415,7 +1414,7 @@ xfs_qm_qino_alloc( > return error; > } > > - if ((error = xfs_dir_ialloc(&tp, &xfs_zeroino, S_IFREG, 1, 0, > + if ((error = xfs_dir_ialloc(&tp, NULL, S_IFREG, 1, 0, > &xfs_zerocr, 0, 1, ip, &committed))) { > xfs_trans_cancel(tp, XFS_TRANS_RELEASE_LOG_RES | > XFS_TRANS_ABORT); > > > > -- View this message in context: http://www.nabble.com/Review%3A-Concurrent-Multi-File-Data-Streams-tf3724878.html#a12789210 Sent from the Xfs - General mailing list archive at Nabble.com. From owner-xfs@oss.sgi.com Wed Sep 19 19:32:36 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Sep 2007 19:32: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=-1.2 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 l8K2WVuw000462 for ; Wed, 19 Sep 2007 19:32:35 -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 MAA06955; Thu, 20 Sep 2007 12:32:18 +1000 Date: Thu, 20 Sep 2007 12:36:52 +1000 To: "Eric Sandeen" , "Jochen K." Subject: Re: Cant find sunit and swidth on luks encrypted raid6 device 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: <728b8e3b0709191129j27b7c319h2efd51ffc9cb64f3@mail.gmail.com> <46F17BBE.7060304@sandeen.net> Message-ID: In-Reply-To: <46F17BBE.7060304@sandeen.net> User-Agent: Opera Mail/9.10 (Win32) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by oss.sgi.com id l8K2Wauw000472 X-archive-position: 12976 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 Thu, 20 Sep 2007 05:42:54 +1000, Eric Sandeen wrote: > Jochen K. wrote: > >> [output with encryption] >> >> mkfs.xfs -f /dev/mapper/raid6 >> >> meta-data=/dev/mapper/raid6 isize=256 agcount=32, >> agsize=53412581 >> blks >> = sectsz=512 attr=0 >> data = bsize=4096 blocks=1709202592, >> imaxpct=25 >> = sunit=0 swidth=0 blks, unwritten=1 >> naming =version 2 bsize=4096 >> log =internal log bsize=4096 blocks=32768, version=1 >> = sectsz=512 sunit=0 blks, lazy-count=0 >> realtime =none extsz=4096 blocks=0, rtextents=0 >> b7f57ad0: Badness in key lookup (length) >> bp=(bno 13673620728, len 131072 bytes) key=(bno 13673620728, len 4096 >> bytes) > > What generates the last two lines in the above message, and do you know > what it indicates? The following patch should fix this problem: --- a/xfsprogs/mkfs/xfs_mkfs.c 2007-09-20 12:31:33.000000000 +1000 +++ b/xfsprogs/mkfs/xfs_mkfs.c 2007-09-20 12:28:46.698533734 +1000 @@ -2115,6 +2115,7 @@ BTOBB(WHACK_SIZE)); bzero(XFS_BUF_PTR(buf), WHACK_SIZE); libxfs_writebuf(buf, LIBXFS_EXIT_ON_FAILURE); + libxfs_purgebuf(buf); } /* From owner-xfs@oss.sgi.com Wed Sep 19 21:32:14 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Sep 2007 21:32: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=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8K4WCuw018453 for ; Wed, 19 Sep 2007 21:32:13 -0700 Received: by an-out-0708.google.com with SMTP id c38so79802ana for ; Wed, 19 Sep 2007 21:32:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:subject:from:reply-to:to:content-type:organization:date:message-id:mime-version:x-mailer:content-transfer-encoding; bh=GRWvebGiCOh1D5TRNL5RepYgdWKmVtlpnR3TSgO6Jx8=; b=sdf3jr98Ym3zBeqtbcWXo41GJ05lzgx407rU7DBWEOlAU6r3qBz+JYGod7L3bdrh2HEQ72R/uF3fg5Y3so4TFla7at0TcTEvL2tLX7amKnlWhAezMfNWpxvIqe98//UUWzKVKUgdFxp6SHkjdrmU8DsJbl6fNfV9saz5sXgkp/c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:subject:from:reply-to:to:content-type:organization:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=ZH38dpAsoh623A0hP+y0YCiI6xKKj32/iBRtYJAy4eVMMmoEPSLcDdS50Fvz4DnDMuCCxRu5Yto8XRhjLTQRTfiRcwgIQxOcHEyHQOkgjp1YQr/tOW4A8cU8BMXML69X3beRXxZIRouIutEBtlft6jdhNZJbHXP2c3gRM6u4SNA= Received: by 10.100.166.14 with SMTP id o14mr1607573ane.1190261133590; Wed, 19 Sep 2007 21:05:33 -0700 (PDT) Received: from ?192.168.0.7? ( [75.69.253.52]) by mx.google.com with ESMTPS id i40sm3151190wxd.2007.09.19.21.05.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 19 Sep 2007 21:05:31 -0700 (PDT) Subject: The problem in installing the linux-2.6-xfs kernel From: hxsrmeng Reply-To: hxsrmeng@gmail.com To: XFS Content-Type: text/plain Organization: TT Date: Thu, 20 Sep 2007 00:01:58 -0400 Message-Id: <1190260918.24375.4.camel@OpenSUSE-desktop.Home> Mime-Version: 1.0 X-Mailer: Evolution 2.8.2 Content-Transfer-Encoding: 7bit X-archive-position: 12977 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hxsrmeng@gmail.com Precedence: bulk X-list: xfs Hi, When I do: $/sbin/mkinitrd -k vmlinuz-2.6-xfs -i initrd-2.6-xfs I got: " Filesystem modules: WARNING: Couldn't open directory /var/tmp/mkinitramfs.C23294/mnt/lib/modules/2.6.23-rc4: No such file or directory FATAL: Could not open /var/tmp/mkinitramfs.C23294/mnt/lib/modules/2.6.23-rc4/modules.dep.temp for writing: No such file or directory " So, does this mean it failed? If I can still boot this kernel, are the file system features OK? Especially, I want to try XFS and "Concurrent Multi-File Data Streams". Thanks in advance! From owner-xfs@oss.sgi.com Wed Sep 19 21:48:02 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Sep 2007 21:48: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.3 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 l8K4m1uw020705 for ; Wed, 19 Sep 2007 21:48:02 -0700 Received: from liberator.sandeen.net (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 482A118003EFA; Wed, 19 Sep 2007 23:48:03 -0500 (CDT) Message-ID: <46F1FB7C.9080901@sandeen.net> Date: Wed, 19 Sep 2007 23:47:56 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: hxsrmeng@gmail.com CC: XFS Subject: Re: The problem in installing the linux-2.6-xfs kernel References: <1190260918.24375.4.camel@OpenSUSE-desktop.Home> In-Reply-To: <1190260918.24375.4.camel@OpenSUSE-desktop.Home> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 12978 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 hxsrmeng wrote: > Hi, > > When I do: > $/sbin/mkinitrd -k vmlinuz-2.6-xfs -i initrd-2.6-xfs mkinitrd varies from distribution to distribution. I don't know what the -k and -i options do in your case. But, this really isn't particularly on-topic for the xfs list... if you're having trouble installing a custom kernel, I'd suggest asking on a list more relevant to your distribution. -Eric > I got: > " > Filesystem modules: > WARNING: Couldn't open > directory /var/tmp/mkinitramfs.C23294/mnt/lib/modules/2.6.23-rc4: No > such file or directory > FATAL: Could not > open /var/tmp/mkinitramfs.C23294/mnt/lib/modules/2.6.23-rc4/modules.dep.temp for writing: No such file or directory > " > So, does this mean it failed? > > If I can still boot this kernel, are the file system features OK? > Especially, I want to try XFS and "Concurrent Multi-File Data Streams". > > Thanks in advance! > > From owner-xfs@oss.sgi.com Wed Sep 19 22:33:00 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Sep 2007 22:33: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.2 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.224]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8K5Wtuw026569 for ; Wed, 19 Sep 2007 22:33:00 -0700 Received: by wx-out-0506.google.com with SMTP id s9so383227wxc for ; Wed, 19 Sep 2007 22:32:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:subject:from:reply-to:to:cc:in-reply-to:references:content-type:organization:date:message-id:mime-version:x-mailer:content-transfer-encoding; bh=9AyMkrMvhcOCskEa7m9vinNZhE7aVqoDgnnCXH+mHIQ=; b=IhNWWqoyS0pPgqkU442YlASgeRbA7TfyeXSyMBwFLEv/5K6Jp9sk76Wn3h1AiEMLRT7Z+hfWtsPMX0sQCEeI7qVE7Q7HYnaO0VwkZX7MD8n2ZIuyzOgIEOaKG4JDWhjDiz0stvdJ8ooUuUUordIlmACn0UAdcylC1+zFctBbrgA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:subject:from:reply-to:to:cc:in-reply-to:references:content-type:organization:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=hHAHrMKMf6fAleULoBGyK3K9RBa5/WNL4KjdRc4zBdv4Hq9Xkh/H+IBoBlGNFNaGzfVlYfiY/FooUoXytAQ6bT//l46rMq2CsEV8Dt628XxOXHPg1glcqhlXWl8nEUPiNJb1oCHmXTtfsMVvKDnt+Zz2f7IbbvHPdbTgY5Fh7Cc= Received: by 10.90.113.18 with SMTP id l18mr1265498agc.1190264891995; Wed, 19 Sep 2007 22:08:11 -0700 (PDT) Received: from ?192.168.0.7? ( [75.69.253.52]) by mx.google.com with ESMTPS id 32sm2065323aga.2007.09.19.22.08.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 19 Sep 2007 22:08:08 -0700 (PDT) Subject: Re: The problem in installing the linux-2.6-xfs kernel From: hxsrmeng Reply-To: hxsrmeng@gmail.com To: Eric Sandeen Cc: XFS In-Reply-To: <46F1FB7C.9080901@sandeen.net> References: <1190260918.24375.4.camel@OpenSUSE-desktop.Home> <46F1FB7C.9080901@sandeen.net> Content-Type: text/plain Organization: TT Date: Thu, 20 Sep 2007 01:04:35 -0400 Message-Id: <1190264675.19442.12.camel@OpenSUSE-desktop.Home> Mime-Version: 1.0 X-Mailer: Evolution 2.8.2 Content-Transfer-Encoding: 7bit X-archive-position: 12979 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hxsrmeng@gmail.com Precedence: bulk X-list: xfs Thanks. I downloaded this distribution from the cvs@oss.sgi.com, and it is a XFS-relative kernel, so I think it should be OK for me to post this question here. Also, as I mentioned, I am especially interested in playing with the XFS features and I am worrying whether this problem would stop me in doing that. I think the gurus who could answer this question should be here. .... Anyway, I am sorry if you think i post it to a wrong list. On Wed, 2007-09-19 at 23:47 -0500, Eric Sandeen wrote: > hxsrmeng wrote: > > Hi, > > > > When I do: > > $/sbin/mkinitrd -k vmlinuz-2.6-xfs -i initrd-2.6-xfs > > mkinitrd varies from distribution to distribution. I don't know what > the -k and -i options do in your case. > > But, this really isn't particularly on-topic for the xfs list... if > you're having trouble installing a custom kernel, I'd suggest asking on > a list more relevant to your distribution. > > -Eric > > > I got: > > " > > Filesystem modules: > > WARNING: Couldn't open > > directory /var/tmp/mkinitramfs.C23294/mnt/lib/modules/2.6.23-rc4: No > > such file or directory > > FATAL: Could not > > open /var/tmp/mkinitramfs.C23294/mnt/lib/modules/2.6.23-rc4/modules.dep.temp for writing: No such file or directory > > " > > So, does this mean it failed? > > > > If I can still boot this kernel, are the file system features OK? > > Especially, I want to try XFS and "Concurrent Multi-File Data Streams". > > > > Thanks in advance! > > > > > From owner-xfs@oss.sgi.com Thu Sep 20 00:55:16 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Sep 2007 00:55: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.5 required=5.0 tests=AWL,BAYES_05,J_CHICKENPOX_45 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 l8K7sguw017757 for ; Thu, 20 Sep 2007 00:55:13 -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 RAA14023; Thu, 20 Sep 2007 17:54:44 +1000 Date: Thu, 20 Sep 2007 17:59:05 +1000 To: "xfs@oss.sgi.com" , xfs-dev Subject: REVIEW: Improve "." and ".." problem detection and handling in xfs_repair From: "Barry Naujok" Organization: SGI Content-Type: multipart/mixed; boundary=----------Q8903L1J3W44XpzcIOQMJY MIME-Version: 1.0 Message-ID: User-Agent: Opera Mail/9.10 (Win32) X-archive-position: 12982 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 ------------Q8903L1J3W44XpzcIOQMJY Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 Content-Transfer-Encoding: 7bit In a non-shortform directory (ie. the directory contents is stored within the inode on-disk), if "." or ".." are placed in different blocks, the directory cannot be made shortform when everything else in the directory is deleted as two blocks still remain. This prevents the kernel from deleting this directory saying it's "not empty" (see http://oss.sgi.com/archives/xfs/2007-09/msg00142.html ). The attached patch detects "." or ".." not being in the first block and rebuilds it in repair so it may be deleted when required. Also, testing this patch, I found if ".." didn't exist in a directory, yet another directory had an entry for it, it was put in lost+found. The patch now puts ".." back in for the directory referencing it. I also improved the lookup of the parent when rebuilding a directory (it did a hash lookup of ".." instead of the already existing get_inode_parent() call). ------------Q8903L1J3W44XpzcIOQMJY Content-Disposition: attachment; filename=improve_dot_and_dotdot_handling.patch Content-Type: application/octet-stream; name=improve_dot_and_dotdot_handling.patch Content-Transfer-Encoding: Base64 Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQp4ZnNwcm9ncy9yZXBh aXIvaW5jb3JlX2luby5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQoKLS0tIGEveGZzcHJvZ3MvcmVwYWlyL2luY29yZV9pbm8uYwkyMDA3LTA5 LTIwIDE3OjQ1OjMyLjAwMDAwMDAwMCArMTAwMAorKysgYi94ZnNwcm9ncy9y ZXBhaXIvaW5jb3JlX2luby5jCTIwMDctMDktMTkgMTU6NDg6MDYuODQ1OTcz NDE4ICsxMDAwCkBAIC02MjEsNDkgKzYyMSw2MSBAQCBwcmludF91bmNlcnRh aW5faW5vZGVfbGlzdCh4ZnNfYWdudW1iZXJfCiAgKiBpcyB0aGUgTnRoIGJp dCBzZXQgaW4gdGhlIG1hc2sgaXMgc3RvcmVkIGluIHRoZSBOdGggbG9jYXRp b24gaW4KICAqIHRoZSBhcnJheSB3aGVyZSBOIHN0YXJ0cyBhdCAwLgogICov CisKIHZvaWQKLXNldF9pbm9kZV9wYXJlbnQoaW5vX3RyZWVfbm9kZV90ICpp cmVjLCBpbnQgb2Zmc2V0LCB4ZnNfaW5vX3QgcGFyZW50KQotewotCWludAkJ aTsKLQlpbnQJCWNudDsKLQlpbnQJCXRhcmdldDsKLQlfX3VpbnQ2NF90CWJp dG1hc2s7Ci0JcGFyZW50X2VudHJ5X3QJKnRtcDsKK3NldF9pbm9kZV9wYXJl bnQoCisJaW5vX3RyZWVfbm9kZV90CQkqaXJlYywKKwlpbnQJCQlvZmZzZXQs CisJeGZzX2lub190CQlwYXJlbnQpCit7CisJcGFyZW50X2xpc3RfdAkJKnB0 Ymw7CisJaW50CQkJaTsKKwlpbnQJCQljbnQ7CisJaW50CQkJdGFyZ2V0Owor CV9fdWludDY0X3QJCWJpdG1hc2s7CisJcGFyZW50X2VudHJ5X3QJCSp0bXA7 CiAKLQlBU1NFUlQoZnVsbF9pbm9fZXhfZGF0YSA9PSAwKTsKKwlpZiAoZnVs bF9pbm9fZXhfZGF0YSkKKwkJcHRibCA9IGlyZWMtPmlub191bi5leF9kYXRh LT5wYXJlbnRzOworCWVsc2UKKwkJcHRibCA9IGlyZWMtPmlub191bi5wbGlz dDsKIAotCWlmIChpcmVjLT5pbm9fdW4ucGxpc3QgPT0gTlVMTCkgIHsKLQkJ aXJlYy0+aW5vX3VuLnBsaXN0ID0KLQkJCShwYXJlbnRfbGlzdF90KiltYWxs b2Moc2l6ZW9mKHBhcmVudF9saXN0X3QpKTsKLQkJaWYgKCFpcmVjLT5pbm9f dW4ucGxpc3QpCisJaWYgKHB0YmwgPT0gTlVMTCkgIHsKKwkJcHRibCA9IChw YXJlbnRfbGlzdF90ICopbWFsbG9jKHNpemVvZihwYXJlbnRfbGlzdF90KSk7 CisJCWlmICghcHRibCkKIAkJCWRvX2Vycm9yKF8oImNvdWxkbid0IG1hbGxv YyBwYXJlbnQgbGlzdCB0YWJsZVxuIikpOwogCi0JCWlyZWMtPmlub191bi5w bGlzdC0+cG1hc2sgPSAxTEwgPDwgb2Zmc2V0OwotCQlpcmVjLT5pbm9fdW4u cGxpc3QtPnBlbnRyaWVzID0KLQkJCSh4ZnNfaW5vX3QqKW1lbWFsaWduKHNp emVvZih4ZnNfaW5vX3QpLCBzaXplb2YoeGZzX2lub190KSk7Ci0JCWlmICgh aXJlYy0+aW5vX3VuLnBsaXN0LT5wZW50cmllcykKKwkJaWYgKGZ1bGxfaW5v X2V4X2RhdGEpCisJCQlpcmVjLT5pbm9fdW4uZXhfZGF0YS0+cGFyZW50cyA9 IHB0Ymw7CisJCWVsc2UKKwkJCWlyZWMtPmlub191bi5wbGlzdCA9IHB0Ymw7 CisKKwkJcHRibC0+cG1hc2sgPSAxTEwgPDwgb2Zmc2V0OworCQlwdGJsLT5w ZW50cmllcyA9ICh4ZnNfaW5vX3QqKW1lbWFsaWduKHNpemVvZih4ZnNfaW5v X3QpLAorCQkJCQkJCXNpemVvZih4ZnNfaW5vX3QpKTsKKwkJaWYgKCFwdGJs LT5wZW50cmllcykKIAkJCWRvX2Vycm9yKF8oImNvdWxkbid0IG1lbWFsaWdu IHBlbnRyaWVzIHRhYmxlXG4iKSk7CiAjaWZkZWYgREVCVUcKLQkJaXJlYy0+ aW5vX3VuLnBsaXN0LT5jbnQgPSAxOworCQlwdGJsLT5jbnQgPSAxOwogI2Vu ZGlmCi0JCWlyZWMtPmlub191bi5wbGlzdC0+cGVudHJpZXNbMF0gPSBwYXJl bnQ7CisJCXB0YmwtPnBlbnRyaWVzWzBdID0gcGFyZW50OwogCiAJCXJldHVy bjsKIAl9CiAKLQlpZiAoaXJlYy0+aW5vX3VuLnBsaXN0LT5wbWFzayAmICgx TEwgPDwgb2Zmc2V0KSkgIHsKKwlpZiAocHRibC0+cG1hc2sgJiAoMUxMIDw8 IG9mZnNldCkpICB7CiAJCWJpdG1hc2sgPSAxTEw7CiAJCXRhcmdldCA9IDA7 CiAKIAkJZm9yIChpID0gMDsgaSA8IG9mZnNldDsgaSsrKSAgewotCQkJaWYg KGlyZWMtPmlub191bi5wbGlzdC0+cG1hc2sgJiBiaXRtYXNrKQorCQkJaWYg KHB0YmwtPnBtYXNrICYgYml0bWFzaykKIAkJCQl0YXJnZXQrKzsKIAkJCWJp dG1hc2sgPDw9IDE7CiAJCX0KICNpZmRlZiBERUJVRwotCQlBU1NFUlQodGFy Z2V0IDwgaXJlYy0+aW5vX3VuLnBsaXN0LT5jbnQpOworCQlBU1NFUlQodGFy Z2V0IDwgcHRibC0+Y250KTsKICNlbmRpZgotCQlpcmVjLT5pbm9fdW4ucGxp c3QtPnBlbnRyaWVzW3RhcmdldF0gPSBwYXJlbnQ7CisJCXB0YmwtPnBlbnRy aWVzW3RhcmdldF0gPSBwYXJlbnQ7CiAKIAkJcmV0dXJuOwogCX0KQEAgLTY3 Miw3ICs2ODQsNyBAQCBzZXRfaW5vZGVfcGFyZW50KGlub190cmVlX25vZGVf dCAqaXJlYywgCiAJY250ID0gdGFyZ2V0ID0gMDsKIAogCWZvciAoaSA9IDA7 IGkgPCBYRlNfSU5PREVTX1BFUl9DSFVOSzsgaSsrKSAgewotCQlpZiAoaXJl Yy0+aW5vX3VuLnBsaXN0LT5wbWFzayAmIGJpdG1hc2spICB7CisJCWlmIChw dGJsLT5wbWFzayAmIGJpdG1hc2spICB7CiAJCQljbnQrKzsKIAkJCWlmIChp IDwgb2Zmc2V0KQogCQkJCXRhcmdldCsrOwpAQCAtNjgyLDcgKzY5NCw3IEBA IHNldF9pbm9kZV9wYXJlbnQoaW5vX3RyZWVfbm9kZV90ICppcmVjLCAKIAl9 CiAKICNpZmRlZiBERUJVRwotCUFTU0VSVChjbnQgPT0gaXJlYy0+aW5vX3Vu LnBsaXN0LT5jbnQpOworCUFTU0VSVChjbnQgPT0gcHRibC0+Y250KTsKICNl bmRpZgogCUFTU0VSVChjbnQgPj0gdGFyZ2V0KTsKIApAQCAtNjkwLDIzICs3 MDIsMjMgQEAgc2V0X2lub2RlX3BhcmVudChpbm9fdHJlZV9ub2RlX3QgKmly ZWMsIAogCWlmICghdG1wKQogCQlkb19lcnJvcihfKCJjb3VsZG4ndCBtZW1h bGlnbiBwZW50cmllcyB0YWJsZVxuIikpOwogCi0JKHZvaWQpIGJjb3B5KGly ZWMtPmlub191bi5wbGlzdC0+cGVudHJpZXMsIHRtcCwKKwkodm9pZCkgYmNv cHkocHRibC0+cGVudHJpZXMsIHRtcCwKIAkJCXRhcmdldCAqIHNpemVvZihw YXJlbnRfZW50cnlfdCkpOwogCiAJaWYgKGNudCA+IHRhcmdldCkKLQkJKHZv aWQpIGJjb3B5KGlyZWMtPmlub191bi5wbGlzdC0+cGVudHJpZXMgKyB0YXJn ZXQsCisJCSh2b2lkKSBiY29weShwdGJsLT5wZW50cmllcyArIHRhcmdldCwK IAkJCQl0bXAgKyB0YXJnZXQgKyAxLAogCQkJCShjbnQgLSB0YXJnZXQpICog c2l6ZW9mKHBhcmVudF9lbnRyeV90KSk7CiAKLQlmcmVlKGlyZWMtPmlub191 bi5wbGlzdC0+cGVudHJpZXMpOworCWZyZWUocHRibC0+cGVudHJpZXMpOwog Ci0JaXJlYy0+aW5vX3VuLnBsaXN0LT5wZW50cmllcyA9IHRtcDsKKwlwdGJs LT5wZW50cmllcyA9IHRtcDsKIAogI2lmZGVmIERFQlVHCi0JaXJlYy0+aW5v X3VuLnBsaXN0LT5jbnQrKzsKKwlwdGJsLT5jbnQrKzsKICNlbmRpZgotCWly ZWMtPmlub191bi5wbGlzdC0+cGVudHJpZXNbdGFyZ2V0XSA9IHBhcmVudDsK LQlpcmVjLT5pbm9fdW4ucGxpc3QtPnBtYXNrIHw9ICgxTEwgPDwgb2Zmc2V0 KTsKKwlwdGJsLT5wZW50cmllc1t0YXJnZXRdID0gcGFyZW50OworCXB0Ymwt PnBtYXNrIHw9ICgxTEwgPDwgb2Zmc2V0KTsKIH0KIAogeGZzX2lub190Cgo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KeGZzcHJvZ3MvcmVwYWly L3BoYXNlNi5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQoKLS0t IGEveGZzcHJvZ3MvcmVwYWlyL3BoYXNlNi5jCTIwMDctMDktMjAgMTc6NDU6 MzMuMDAwMDAwMDAwICsxMDAwCisrKyBiL3hmc3Byb2dzL3JlcGFpci9waGFz ZTYuYwkyMDA3LTA5LTE5IDE4OjE1OjA2LjEwNTkwOTQ4NSArMTAwMApAQCAt MTYyNCwxNiArMTYyNCwyNSBAQCBsZl9ibG9ja19kaXJfZW50cnlfY2hlY2so eGZzX21vdW50X3QJCSptCiAJCSAqLwogCQlpZiAoaXNfaW5vZGVfcmVhY2hl ZChpcmVjLCBpbm9fb2Zmc2V0KSkgIHsKIAkJCWp1bmtpdCA9IDE7Ci0JCQlk b193YXJuKAotXygiZW50cnkgXCIlc1wiIGluIGRpciAlbGx1IHBvaW50cyB0 byBhbiBhbHJlYWR5IGNvbm5lY3RlZCBkaXIgaW5vZGUgJWxsdSxcbiIpLAor CQkJZG9fd2FybihfKCJlbnRyeSBcIiVzXCIgaW4gZGlyICVsbHUgcG9pbnRz IHRvIGFuICIKKwkJCQkiYWxyZWFkeSBjb25uZWN0ZWQgZGlyIGlub2RlICVs bHUsXG4iKSwKIAkJCQlmbmFtZSwgaW5vLCBsaW5vKTsKIAkJfSBlbHNlIGlm IChwYXJlbnQgPT0gaW5vKSAgewogCQkJYWRkX2lub2RlX3JlYWNoZWQoaXJl YywgaW5vX29mZnNldCk7CiAJCQlhZGRfaW5vZGVfcmVmKGN1cnJlbnRfaXJl YywgY3VycmVudF9pbm9fb2Zmc2V0KTsKLQkJfSBlbHNlICB7CisJCX0gZWxz ZSBpZiAocGFyZW50ID09IE5VTExGU0lOTykgeworCQkJLyogIi4uIiB3YXMg bWlzc2luZywgYnV0IHRoaXMgZW50cnkgcmVmZXJzIHRvIGl0LAorCQkJICAg c28sIHNldCBpdCBhcyB0aGUgcGFyZW50IGFuZCBtYXJrIGZvciByZWJ1aWxk ICovCisJCQlkb193YXJuKF8oImVudHJ5IFwiJXNcIiBpbiBkaXIgaW5vICVs bHUgZG9lc24ndCBoYXZlIGEiCisJCQkJIiAuLiBlbnRyeSwgd2lsbCBzZXQg aXQgaW4gaW5vICVsbHUuXG4iKSwKKwkJCQlmbmFtZSwgaW5vLCBsaW5vKTsK KwkJCXNldF9pbm9kZV9wYXJlbnQoaXJlYywgaW5vX29mZnNldCwgaW5vKTsK KwkJCWFkZF9pbm9kZV9yZWFjaGVkKGlyZWMsIGlub19vZmZzZXQpOworCQkJ YWRkX2lub2RlX3JlZihjdXJyZW50X2lyZWMsIGN1cnJlbnRfaW5vX29mZnNl dCk7CisJCX0gZWxzZSB7CiAJCQlqdW5raXQgPSAxOwotCQkJZG9fd2FybigK LV8oImVudHJ5IFwiJXNcIiBpbiBkaXIgaW5vICVsbHUgbm90IGNvbnNpc3Rl bnQgd2l0aCAuLiB2YWx1ZSAoJWxsdSkgaW4gaW5vICVsbHUsXG4iKSwKKwkJ CWRvX3dhcm4oXygiZW50cnkgXCIlc1wiIGluIGRpciBpbm8gJWxsdSBub3Qg Y29uc2lzdGVudCIKKwkJCQkiIHdpdGggLi4gdmFsdWUgKCVsbHUpIGluIGlu byAlbGx1LFxuIiksCiAJCQkJZm5hbWUsIGlubywgcGFyZW50LCBsaW5vKTsK IAkJfQogCkBAIC0xNzg4LDEwICsxNzk3LDEyIEBAIF8oImNhbid0IG1hcCBs ZWFmIGJsb2NrICVkIGluIGRpciAlbGx1LCAKIAogc3RhdGljIHZvaWQKIGxv bmdmb3JtX2RpcjJfcmVidWlsZCgKLQl4ZnNfbW91bnRfdAkqbXAsCi0JeGZz X2lub190CWlubywKLQl4ZnNfaW5vZGVfdAkqaXAsCi0JZGlyX2hhc2hfdGFi X3QJKmhhc2h0YWIpCisJeGZzX21vdW50X3QJCSptcCwKKwl4ZnNfaW5vX3QJ CWlubywKKwl4ZnNfaW5vZGVfdAkJKmlwLAorCWlub190cmVlX25vZGVfdAkJ KmlyZWMsCisJaW50CQkJaW5vX29mZnNldCwKKwlkaXJfaGFzaF90YWJfdAkJ Kmhhc2h0YWIpCiB7CiAJaW50CQkJZXJyb3I7CiAJaW50CQkJbnJlczsKQEAg LTE4MDAsNyArMTgxMSw2IEBAIGxvbmdmb3JtX2RpcjJfcmVidWlsZCgKIAl4 ZnNfZnNibG9ja190CQlmaXJzdGJsb2NrOwogCXhmc19ibWFwX2ZyZWVfdAkJ Zmxpc3Q7CiAJeGZzX2lub2RlX3QJCXBpcDsKLQlpbnQJCQlieWhhc2g7CiAJ ZGlyX2hhc2hfZW50X3QJCSpwOwogCWludAkJCWNvbW1pdHRlZDsKIAlpbnQJ CQlkb25lOwpAQCAtMTgxMywxOSArMTgyMywxNCBAQCBsb25nZm9ybV9kaXIy X3JlYnVpbGQoCiAJZG9fd2FybihfKCJyZWJ1aWxkaW5nIGRpcmVjdG9yeSBp bm9kZSAlbGx1XG4iKSwgaW5vKTsKIAogCS8qCi0JICogZmlyc3QgYXR0ZW1w dCB0byBsb2NhdGUgdGhlIHBhcmVudCBpbm9kZSwgaWYgaXQgY2FuJ3QgYmUg Zm91bmQsCi0JICogc2V0IGl0IHRvIHRoZSByb290IGlub2RlIGFuZCBpdCds bCBiZSBhZGp1c3RlZCBvciBmaXhlZCBsYXRlcgotCSAqIGlmIGluY29ycmVj dCAodGhlIGlub2RlIG51bWJlciBoZXJlIG5lZWRzIHRvIGJlIHZhbGlkIGZv ciB0aGUKLQkgKiBsaWJ4ZnNfZGlyMl9pbml0KCkgY2FsbCkuCi0JICovCi0J YnloYXNoID0gRElSX0hBU0hfRlVOQyhoYXNodGFiLCBsaWJ4ZnNfZGFfaGFz aG5hbWUoKHVjaGFyX3QqKSIuLiIsIDIpKTsKLQlwaXAuaV9pbm8gPSBtcC0+ bV9zYi5zYl9yb290aW5vOwotCWZvciAocCA9IGhhc2h0YWItPmJ5aGFzaFti eWhhc2hdOyBwOyBwID0gcC0+bmV4dGJ5aGFzaCkgewotCQlpZiAocC0+bmFt ZWxlbiA9PSAyICYmIHAtPm5hbWVbMF0gPT0gJy4nICYmIHAtPm5hbWVbMV0g PT0gJy4nKSB7Ci0JCQlwaXAuaV9pbm8gPSBwLT5pbnVtOwotCQkJYnJlYWs7 Ci0JCX0KLQl9CisJICogZmlyc3QgYXR0ZW1wdCB0byBsb2NhdGUgdGhlIHBh cmVudCBpbm9kZSwgaWYgaXQgY2FuJ3QgYmUKKwkgKiBmb3VuZCwgc2V0IGl0 IHRvIHRoZSByb290IGlub2RlIGFuZCBpdCdsbCBiZSBtb3ZlZCB0byB0aGUK KwkgKiBvcnBoYW5hZ2UgbGF0ZXIgKHRoZSBpbm9kZSBudW1iZXIgaGVyZSBu ZWVkcyB0byBiZSB2YWxpZAorCSAqIGZvciB0aGUgbGlieGZzX2RpcjJfaW5p dCgpIGNhbGwpLgorCSAqLworCXBpcC5pX2lubyA9IGdldF9pbm9kZV9wYXJl bnQoaXJlYywgaW5vX29mZnNldCk7CisJaWYgKHBpcC5pX2lubyA9PSBOVUxM RlNJTk8pCisJCXBpcC5pX2lubyA9IG1wLT5tX3NiLnNiX3Jvb3Rpbm87CiAK IAlYRlNfQk1BUF9JTklUKCZmbGlzdCwgJmZpcnN0YmxvY2spOwogCkBAIC0y MjczLDExICsyMjc4LDI1IEBAIGxvbmdmb3JtX2RpcjJfZW50cnlfY2hlY2tf ZGF0YSgKIAkJICogc2tpcCB0aGUgJy4uJyBlbnRyeSBzaW5jZSBpdCdzIGNo ZWNrZWQgd2hlbiB0aGUKIAkJICogZGlyZWN0b3J5IGlzIHJlYWNoZWQgYnkg c29tZXRoaW5nIGVsc2UuICBpZiBpdCBuZXZlcgogCQkgKiBnZXRzIHJlYWNo ZWQsIGl0J2xsIGJlIG1vdmVkIHRvIHRoZSBvcnBoYW5hZ2UgYW5kIHdlJ2xs Ci0JCSAqIHRha2UgY2FyZSBvZiBpdCB0aGVuLgorCQkgKiB0YWtlIGNhcmUg b2YgaXQgdGhlbi4gSWYgaXQgZG9lc24ndCBleGlzdCBhdCBhbGwsIHRoZQor CQkgKiBkaXJlY3RvcnkgbmVlZHMgdG8gYmUgcmVidWlsdCBmaXJzdCBiZWZv cmUgYmVpbmcgYWRkZWQKKwkJICogdG8gdGhlIG9ycGhhbmFnZS4KIAkJICov CiAJCWlmIChkZXAtPm5hbWVsZW4gPT0gMiAmJiBkZXAtPm5hbWVbMF0gPT0g Jy4nICYmCi0JCSAgICBkZXAtPm5hbWVbMV0gPT0gJy4nKQorCQkJCWRlcC0+ bmFtZVsxXSA9PSAnLicpIHsKKwkJCWlmIChkYV9ibm8gIT0gMCkgeworCQkJ CS8qICIuLiIgc2hvdWxkIGJlIGluIHRoZSBmaXJzdCBibG9jayAqLworCQkJ CW5iYWQrKzsKKwkJCQlpZiAoZW50cnlfanVua2VkKF8oImVudHJ5IFwiJXNc IiAoaW5vICVsbHUpICIKKwkJCQkJCSJpbiBkaXIgJWxsdSBpcyBub3QgaW4g dGhlICIKKwkJCQkJCSJ0aGUgZmlyc3QgYmxvY2siKSwgZm5hbWUsCisJCQkJ CQlpbnVtLCBpcC0+aV9pbm8pKSB7CisJCQkJCWRlcC0+bmFtZVswXSA9ICcv JzsKKwkJCQkJbGlieGZzX2RpcjJfZGF0YV9sb2dfZW50cnkodHAsIGJwLCBk ZXApOworCQkJCX0KKwkJCX0KIAkJCWNvbnRpbnVlOworCQl9CiAJCUFTU0VS VChub19tb2RpZnkgfHwgIXZlcmlmeV9pbnVtKG1wLCBpbnVtKSk7CiAJCS8q CiAJCSAqIHNwZWNpYWwgY2FzZSB0aGUgLiBlbnRyeS4gIHdlIGtub3cgdGhl cmUncyBvbmx5IG9uZQpAQCAtMjI5MSw2ICsyMzEwLDE2IEBAIGxvbmdmb3Jt X2RpcjJfZW50cnlfY2hlY2tfZGF0YSgKIAkJaWYgKGlwLT5pX2lubyA9PSBp bnVtKSAgewogCQkJQVNTRVJUKGRlcC0+bmFtZVswXSA9PSAnLicgJiYgZGVw LT5uYW1lbGVuID09IDEpOwogCQkJYWRkX2lub2RlX3JlZihjdXJyZW50X2ly ZWMsIGN1cnJlbnRfaW5vX29mZnNldCk7CisJCQlpZiAoZGFfYm5vICE9IDAg fHwgZGVwICE9ICh4ZnNfZGlyMl9kYXRhX2VudHJ5X3QgKilkLT51KSB7CisJ CQkJLyogIi4iIHNob3VsZCBiZSB0aGUgZmlyc3QgZW50cnkgKi8KKwkJCQlu YmFkKys7CisJCQkJaWYgKGVudHJ5X2p1bmtlZChfKCJlbnRyeSBcIiVzXCIg aW4gZGlyICVsbHUgaXMgIgorCQkJCQkJIm5vdCB0aGUgZmlyc3QgZW50cnki KSwKKwkJCQkJCWZuYW1lLCBpbnVtLCBpcC0+aV9pbm8pKSB7CisJCQkJCWRl cC0+bmFtZVswXSA9ICcvJzsKKwkJCQkJbGlieGZzX2RpcjJfZGF0YV9sb2df ZW50cnkodHAsIGJwLCBkZXApOworCQkJCX0KKwkJCX0KIAkJCSpuZWVkX2Rv dCA9IDA7CiAJCQljb250aW51ZTsKIAkJfQpAQCAtMjMyNSw2ICsyMzU0LDE1 IEBAIF8oImVudHJ5IFwiJXNcIiBpbiBkaXIgJWxsdSBwb2ludHMgdG8gYW4K IAkJfSBlbHNlIGlmIChwYXJlbnQgPT0gaXAtPmlfaW5vKSAgewogCQkJYWRk X2lub2RlX3JlYWNoZWQoaXJlYywgaW5vX29mZnNldCk7CiAJCQlhZGRfaW5v ZGVfcmVmKGN1cnJlbnRfaXJlYywgY3VycmVudF9pbm9fb2Zmc2V0KTsKKwkJ fSBlbHNlIGlmIChwYXJlbnQgPT0gTlVMTEZTSU5PKSB7CisJCQkvKiAiLi4i IHdhcyBtaXNzaW5nLCBidXQgdGhpcyBlbnRyeSByZWZlcnMgdG8gaXQsCisJ CQkgICBzbywgc2V0IGl0IGFzIHRoZSBwYXJlbnQgYW5kIG1hcmsgZm9yIHJl YnVpbGQgKi8KKwkJCWRvX3dhcm4oXygiZW50cnkgXCIlc1wiIGluIGRpciBp bm8gJWxsdSBkb2Vzbid0IGhhdmUgYSIKKwkJCQkiIC4uIGVudHJ5LCB3aWxs IHNldCBpdCBpbiBpbm8gJWxsdS5cbiIpLAorCQkJCWZuYW1lLCBpcC0+aV9p bm8sIGludW0pOworCQkJc2V0X2lub2RlX3BhcmVudChpcmVjLCBpbm9fb2Zm c2V0LCBpcC0+aV9pbm8pOworCQkJYWRkX2lub2RlX3JlYWNoZWQoaXJlYywg aW5vX29mZnNldCk7CisJCQlhZGRfaW5vZGVfcmVmKGN1cnJlbnRfaXJlYywg Y3VycmVudF9pbm9fb2Zmc2V0KTsKIAkJfSBlbHNlICB7CiAJCQlqdW5raXQg PSAxOwogCQkJZG9fd2FybigKQEAgLTI2MzcsNyArMjY3NSw3IEBAIGxvbmdm b3JtX2RpcjJfZW50cnlfY2hlY2soeGZzX21vdW50X3QJKm0KIAkJCQlpcmVj LCBpbm9fb2Zmc2V0LCAmYnBsaXN0W2RiXSwgaGFzaHRhYiwKIAkJCQkmZnJl ZXRhYiwgZGFfYm5vLCBpc2Jsb2NrKTsKIAl9Ci0JZml4aXQgPSAoKm51bV9p bGxlZ2FsICE9IDApIHx8IGRpcjJfaXNfYmFkaW5vKGlubyk7CisJZml4aXQg PSAoKm51bV9pbGxlZ2FsICE9IDApIHx8IGRpcjJfaXNfYmFkaW5vKGlubykg fHwgKm5lZWRfZG90OwogCiAJLyogY2hlY2sgYnRyZWUgYW5kIGZyZWVzcGFj ZSAqLwogCWlmIChpc2Jsb2NrKSB7CkBAIC0yNjU5LDggKzI2OTcsOSBAQCBs b25nZm9ybV9kaXIyX2VudHJ5X2NoZWNrKHhmc19tb3VudF90CSptCiAJCWZv ciAoaSA9IDA7IGkgPCBmcmVldGFiLT5uYWVudHM7IGkrKykKIAkJCWlmIChi cGxpc3RbaV0pCiAJCQkJbGlieGZzX2RhX2JyZWxzZShOVUxMLCBicGxpc3Rb aV0pOwotCQlsb25nZm9ybV9kaXIyX3JlYnVpbGQobXAsIGlubywgaXAsIGhh c2h0YWIpOworCQlsb25nZm9ybV9kaXIyX3JlYnVpbGQobXAsIGlubywgaXAs IGlyZWMsIGlub19vZmZzZXQsIGhhc2h0YWIpOwogCQkqbnVtX2lsbGVnYWwg PSAwOworCQkqbmVlZF9kb3QgPSAwOwogCX0gZWxzZSB7CiAJCWZvciAoaSA9 IDA7IGkgPCBmcmVldGFiLT5uYWVudHM7IGkrKykKIAkJCWlmIChicGxpc3Rb aV0pCkBAIC0yODY1LDYgKzI5MDQsMTUgQEAgc2hvcnRmb3JtX2Rpcl9lbnRy eV9jaGVjayh4ZnNfbW91bnRfdAkqbQogCQkJfSBlbHNlIGlmIChwYXJlbnQg PT0gaW5vKSAgewogCQkJCWFkZF9pbm9kZV9yZWFjaGVkKGlyZWMsIGlub19v ZmZzZXQpOwogCQkJCWFkZF9pbm9kZV9yZWYoY3VycmVudF9pcmVjLCBjdXJy ZW50X2lub19vZmZzZXQpOworCQkJfSBlbHNlIGlmIChwYXJlbnQgPT0gTlVM TEZTSU5PKSB7CisJCQkJLyogIi4uIiB3YXMgbWlzc2luZywgYnV0IHRoaXMg ZW50cnkgcmVmZXJzIHRvIGl0LAorCQkJCXNvLCBzZXQgaXQgYXMgdGhlIHBh cmVudCBhbmQgbWFyayBmb3IgcmVidWlsZCAqLworCQkJCWRvX3dhcm4oXygi ZW50cnkgXCIlc1wiIGluIGRpciBpbm8gJWxsdSBkb2Vzbid0IGhhdmUgYSIK KwkJCQkJIiAuLiBlbnRyeSwgd2lsbCBzZXQgaXQgaW4gaW5vICVsbHUuXG4i KSwKKwkJCQkJZm5hbWUsIGlubywgbGlubyk7CisJCQkJc2V0X2lub2RlX3Bh cmVudChpcmVjLCBpbm9fb2Zmc2V0LCBpbm8pOworCQkJCWFkZF9pbm9kZV9y ZWFjaGVkKGlyZWMsIGlub19vZmZzZXQpOworCQkJCWFkZF9pbm9kZV9yZWYo Y3VycmVudF9pcmVjLCBjdXJyZW50X2lub19vZmZzZXQpOwogCQkJfSBlbHNl ICB7CiAJCQkJanVua2l0ID0gMTsKIAkJCQlkb193YXJuKF8oImVudHJ5IFwi JXNcIiBpbiBkaXIgJWxsdSBub3QgIgpAQCAtMzI1Nyw2ICszMzA1LDE1IEBA IHNob3J0Zm9ybV9kaXIyX2VudHJ5X2NoZWNrKHhmc19tb3VudF90CSoKIAkJ CX0gZWxzZSBpZiAocGFyZW50ID09IGlubykgIHsKIAkJCQlhZGRfaW5vZGVf cmVhY2hlZChpcmVjLCBpbm9fb2Zmc2V0KTsKIAkJCQlhZGRfaW5vZGVfcmVm KGN1cnJlbnRfaXJlYywgY3VycmVudF9pbm9fb2Zmc2V0KTsKKwkJCX0gZWxz ZSBpZiAocGFyZW50ID09IE5VTExGU0lOTykgeworCQkJCS8qICIuLiIgd2Fz IG1pc3NpbmcsIGJ1dCB0aGlzIGVudHJ5IHJlZmVycyB0byBpdCwKKwkJCQlz bywgc2V0IGl0IGFzIHRoZSBwYXJlbnQgYW5kIG1hcmsgZm9yIHJlYnVpbGQg Ki8KKwkJCQlkb193YXJuKF8oImVudHJ5IFwiJXNcIiBpbiBkaXIgaW5vICVs bHUgZG9lc24ndCBoYXZlIGEiCisJCQkJCSIgLi4gZW50cnksIHdpbGwgc2V0 IGl0IGluIGlubyAlbGx1LlxuIiksCisJCQkJCWZuYW1lLCBpbm8sIGxpbm8p OworCQkJCXNldF9pbm9kZV9wYXJlbnQoaXJlYywgaW5vX29mZnNldCwgaW5v KTsKKwkJCQlhZGRfaW5vZGVfcmVhY2hlZChpcmVjLCBpbm9fb2Zmc2V0KTsK KwkJCQlhZGRfaW5vZGVfcmVmKGN1cnJlbnRfaXJlYywgY3VycmVudF9pbm9f b2Zmc2V0KTsKIAkJCX0gZWxzZSAgewogCQkJCWp1bmtpdCA9IDE7CiAJCQkJ ZG9fd2FybihfKCJlbnRyeSBcIiVzXCIgaW4gZGlyZWN0b3J5IGlub2RlICVs bHUiCg== ------------Q8903L1J3W44XpzcIOQMJY-- From owner-xfs@oss.sgi.com Thu Sep 20 09:09:55 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Sep 2007 09:10: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,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 l8KG9qgf020738 for ; Thu, 20 Sep 2007 09:09:55 -0700 Received: from liberator.sandeen.net (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 D585418003EFA; Thu, 20 Sep 2007 07:59:12 -0500 (CDT) Message-ID: <46F26E9F.8060803@sandeen.net> Date: Thu, 20 Sep 2007 07:59:11 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: hxsrmeng@gmail.com CC: XFS Subject: Re: The problem in installing the linux-2.6-xfs kernel References: <1190260918.24375.4.camel@OpenSUSE-desktop.Home> <46F1FB7C.9080901@sandeen.net> <1190264675.19442.12.camel@OpenSUSE-desktop.Home> In-Reply-To: <1190264675.19442.12.camel@OpenSUSE-desktop.Home> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12989 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 hxsrmeng wrote: > Thanks. > > I downloaded this distribution from the cvs@oss.sgi.com, and it is a > XFS-relative kernel, so I think it should be OK for me to post this > question here. I am talking about the gnu/linux OS distribution that already exists on your computer (debian, red hat, mandrake, suse, ubuntu whatever). How you install a new kernel, particularly how you make an initrd, is somewhat specific to that distribution, not to the kernel itself. In other words, mkinitrd failures are not xfs related. > Also, as I mentioned, I am especially interested in playing with the XFS > features and I am worrying whether this problem would stop me in doing > that. I think the gurus who could answer this question should be > here. .... Anyway, I am sorry if you think i post it to a wrong list. If you can't boot and can't load xfs, it won't work. If you can, it will. -Eric From owner-xfs@oss.sgi.com Thu Sep 20 12:44:32 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Sep 2007 12:44: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=0.0 required=5.0 tests=BAYES_50 autolearn=ham version=3.2.0-pre1-r499012 Received: from web35711.mail.mud.yahoo.com (web35711.mail.mud.yahoo.com [66.163.179.165]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l8KJiUgf000776 for ; Thu, 20 Sep 2007 12:44:31 -0700 Received: (qmail 15051 invoked by uid 60001); 20 Sep 2007 19:17:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=SfMwKGYZxGZC4HNfzJOGVGyX5r54Em51tJUHf2Lm40mVnP8uXwTRJmWNM18jh0K4YK/6HRo910fCkAcRH2LlCEL4KULgRAVCzHojaO4HzY3kdQv/BGk62SqfA6MOaR51N+m3BKRwjd52TXqyISXdYYIRJOziloVwHNu7907mhm0=; X-YMail-OSG: A.L1sIsVM1mErbmiHpzc0hf6GkCFKpZslro_QfqViJ_hGNXTMg89xs9dBUK0VNIhBg-- Received: from [69.124.63.172] by web35711.mail.mud.yahoo.com via HTTP; Thu, 20 Sep 2007 12:17:53 PDT Date: Thu, 20 Sep 2007 12:17:53 -0700 (PDT) From: Mariella Petrini Subject: xfs and Linux Linux 2.6.22 and Memory To: xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <435577.15025.qm@web35711.mail.mud.yahoo.com> X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12990 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mariellapetrini@yahoo.com Precedence: bulk X-list: xfs Hi All, I have compiled xfs that is available with Linux 2.6.22 on a Debian 4.0 The system is a 2 cpus (Intel Xeon 3 GHz) with 4 cores each The system has 8 GB of RAM + 2GB of swap I have 4 Hard Drives on the system and each is formatted using xfs Each filesystem is mounted with noatime option I am including the output generated during one of the format: mkfs.xfs -f /dev/sdb1 meta-data=/dev/sdb1 isize=256 agcount=16, agsize=4881374 blks = sectsz=512 attr=0 data = bsize=4096 blocks=78101984, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 I have been using an sql server to populate the 4 xfs filesystems. So all the files represents part of a relational database. In each filesystem I have 5 top directory and each directory contains 100,000 files, so in total each filesystem has 500,000 regular files + 5 regular directories. The sql server is the only program that writes the regular files into the xfs filesystems. During the time taken to populate the 4 filesystems (2,000,000 files) I have noticed that approximately 5 GB of RAM were taken. Once all the filesystems were populated I have shutdown the sql server (the only process that accesses/reads/writes the filesystems) and the 5 GB of RAM would not be released. At that point I have unmounted the 4 xfs filesystems and the 5 GB of RAM would be released (be available again). QUESTION: Is there any way to release that amount of memory without unmounting the file systems ? Is that caused to some caching mechanism ? Or could that be caused by something else ? Could you please help ? Thanks a lot in advance for your help, Mariella ____________________________________________________________________________________ Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/ From owner-xfs@oss.sgi.com Thu Sep 20 14:02:59 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Sep 2007 14:03: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=-0.6 required=5.0 tests=AWL,BAYES_05,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 l8KL2ugf014162 for ; Thu, 20 Sep 2007 14:02:59 -0700 Received: from liberator.sandeen.net (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 D4BF118003EFA; Thu, 20 Sep 2007 16:02:58 -0500 (CDT) Message-ID: <46F2E001.4040107@sandeen.net> Date: Thu, 20 Sep 2007 16:02:57 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Mariella Petrini CC: xfs@oss.sgi.com Subject: Re: xfs and Linux Linux 2.6.22 and Memory References: <435577.15025.qm@web35711.mail.mud.yahoo.com> In-Reply-To: <435577.15025.qm@web35711.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12991 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 Mariella Petrini wrote: > QUESTION: > > Is there any way to release that amount of memory > without unmounting the file systems ? > Is that caused to some caching mechanism ? > Or could that be caused by something else ? It's most likely the linux VFS caching the dentries & inodes, and therefore caching the xfs inodes as well. cat /proc/sys/fs/dentry-state and /proc/sys/fs/inode-state to see how many are in memory, how many are active, and the age limit. slabtop would fairly easily show you how much is in the dentry_cache & the inode_cache too. Are you actually seeing a problem with this (caching is generally good) or just curious? -Eric From owner-xfs@oss.sgi.com Thu Sep 20 16:34:19 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Sep 2007 16:34: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.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 l8KNYEgf007644 for ; Thu, 20 Sep 2007 16:34: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 JAA08990; Fri, 21 Sep 2007 09:34:10 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l8KNY8dD30719881; Fri, 21 Sep 2007 09:34:09 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l8KNY5qP31935899; Fri, 21 Sep 2007 09:34:05 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 21 Sep 2007 09:34:05 +1000 From: David Chinner To: Eric Sandeen Cc: Mariella Petrini , xfs@oss.sgi.com Subject: Re: xfs and Linux Linux 2.6.22 and Memory Message-ID: <20070920233405.GA995458@sgi.com> References: <435577.15025.qm@web35711.mail.mud.yahoo.com> <46F2E001.4040107@sandeen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46F2E001.4040107@sandeen.net> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12992 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 20, 2007 at 04:02:57PM -0500, Eric Sandeen wrote: > Mariella Petrini wrote: > > > QUESTION: > > > > Is there any way to release that amount of memory > > without unmounting the file systems ? > > Is that caused to some caching mechanism ? > > Or could that be caused by something else ? > > It's most likely the linux VFS caching the dentries & inodes, and > therefore caching the xfs inodes as well. Not just inodes, but file data in the page cache as well. If you want to blow it all away without unmountin filesystems, then you should read up on /proc/sys/vm sysctls (i.e. /proc/sys/vm/drop_caches).... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Sep 20 17:15:59 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Sep 2007 17:16:03 -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 l8L0Frgf013688 for ; Thu, 20 Sep 2007 17:15:57 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA09975; Fri, 21 Sep 2007 10:15:49 +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 l8L0FldD31928599; Fri, 21 Sep 2007 10:15:47 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l8L0FjV031974571; Fri, 21 Sep 2007 10:15:45 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 21 Sep 2007 10:15:45 +1000 From: David Chinner To: Justin Piszcz Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: 2.6.20 (XFS? related) crash after uptime of > 180 days during apt-get dist-upgrade on Debian Testing Message-ID: <20070921001544.GB995458@sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12993 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 19, 2007 at 04:47:38AM -0400, Justin Piszcz wrote: > On Mon, 17 Sep 2007, Justin Piszcz wrote: > > >Including the XFS mailing list in here too because it may be an XFS bug > >looking at the call trace. > > > >System: Debian Testing > >Kernel: 2.6.20 > >Config: Attached > > > >I was running apt-get dist-upgrade as I always do to get the latest > >packages upgraded and the kernel OOPS'd when it was upgrading 'tzdata' and > >the process went into D-state and I had to reboot. > > > >The config file is from 2.6.20 but it had been moved to a 2.6.22 directory > >for an upgrade, but all of the options have been left unchanged. > > > >Here is the *OOPS I captured via dmesg before I rebooted: > > > > > > Also, > > Not sure if this helps but when this happened, any file that was open() > for read/write seem to have also been corrupted.. Is that all files, or just ones that were being changed? > $ /usr/sbin/xfs_bmap -v myconfig.txt.orig > myconfig.txt.orig: > EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL > 0: [0..7]: 64601112..64601119 14 (52040..52047) 8 > $ /usr/sbin/xfs_bmap -v myconfig.txt > myconfig.txt: > EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL > 0: [0..7]: 64625720..64625727 14 (76648..76655) 8 > $ md5sum myconfig* > db8c50ca2c86d2e757ecef1d6b3fcc69 myconfig.txt > 09fb630623b3ae614511cef4c7a21063 myconfig.txt.orig > $ file myconfig.txt myconfig.txt.orig > myconfig.txt: ASCII text > myconfig.txt.orig: data > $ > > $ strings -a myconfig.txt.orig > $ > > $ od -c myconfig.txt.orig > 0000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * > 0003500 \0 \0 \0 \0 \0 \0 > 0003506 > > Seems like it was NULL'd out? A single block of zeros - its possible that the crash occurred between the allocation transaction and the data write - the allocation gets replayed (along with the new file size), but the data write does not (not journalled). This is one of the rarer "NULL files on crash" failure modes fixed in 6.5.22..... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Sep 20 17:51:52 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Sep 2007 17:51:55 -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 l8L0pngf019434 for ; Thu, 20 Sep 2007 17:51:51 -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 l8L0t8HI010377; Fri, 21 Sep 2007 10:55:10 +1000 Received: (from lachlan@localhost) by redback.melbourne.sgi.com (8.13.8/8.13.8/Submit) id l8L0t77V010376; Fri, 21 Sep 2007 10:55:07 +1000 Date: Fri, 21 Sep 2007 10:55:07 +1000 From: Lachlan McIlroy Message-Id: <200709210055.l8L0t77V010376@redback.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 970841 - kill unnessecary ioops indirection X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12994 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 kill unnessecary ioops indirection Currently there is an indirection called ioops in the XFS data I/O path. Various functions are called by functions pointers, but there is no coherence in what this is for, and of course for XFS itself it's entirely unused. This patch removes it instead and significantly reduces source and binary size of XFS while making maintaince easier. Date: Fri Sep 21 10:51:25 AEST 2007 Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-hch 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:29737a fs/xfs/xfs_vnodeops.c - 1.721 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.721&r2=text&tr2=1.720&f=h - kill unnessecary ioops indirection fs/xfs/xfs_iocore.c - 1.54 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iocore.c.diff?r1=text&tr1=1.54&r2=text&tr2=1.53&f=h - kill unnessecary ioops indirection fs/xfs/xfs_vfsops.c - 1.540 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.540&r2=text&tr2=1.539&f=h - kill unnessecary ioops indirection fs/xfs/xfs_dfrag.c - 1.61 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dfrag.c.diff?r1=text&tr1=1.61&r2=text&tr2=1.60&f=h - kill unnessecary ioops indirection fs/xfs/xfs_mount.h - 1.251 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.h.diff?r1=text&tr1=1.251&r2=text&tr2=1.250&f=h - kill unnessecary ioops indirection fs/xfs/xfs_mount.c - 1.411 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.411&r2=text&tr2=1.410&f=h - kill unnessecary ioops indirection fs/xfs/xfs_inode.c - 1.480 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.480&r2=text&tr2=1.479&f=h - kill unnessecary ioops indirection fs/xfs/xfs_iomap.h - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iomap.h.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h - kill unnessecary ioops indirection fs/xfs/xfs_iomap.c - 1.58 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iomap.c.diff?r1=text&tr1=1.58&r2=text&tr2=1.57&f=h - kill unnessecary ioops indirection fs/xfs/linux-2.6/xfs_lrw.h - 1.61 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_lrw.h.diff?r1=text&tr1=1.61&r2=text&tr2=1.60&f=h - kill unnessecary ioops indirection fs/xfs/linux-2.6/xfs_lrw.c - 1.269 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_lrw.c.diff?r1=text&tr1=1.269&r2=text&tr2=1.268&f=h - kill unnessecary ioops indirection fs/xfs/linux-2.6/xfs_aops.c - 1.156 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_aops.c.diff?r1=text&tr1=1.156&r2=text&tr2=1.155&f=h - kill unnessecary ioops indirection fs/xfs/linux-2.6/xfs_ksyms.c - 1.73 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ksyms.c.diff?r1=text&tr1=1.73&r2=text&tr2=1.72&f=h - kill unnessecary ioops indirection From owner-xfs@oss.sgi.com Thu Sep 20 18:49:22 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Sep 2007 18: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.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 l8L1nFgf029707 for ; Thu, 20 Sep 2007 18:49:21 -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 LAA12768; Fri, 21 Sep 2007 11:49:14 +1000 From: donaldd@sgi.com Received: by linuxbuild.melbourne.sgi.com (Postfix, from userid 16365) id BAC703079F69; Fri, 21 Sep 2007 11:49:13 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 970382 - untangle spinlock macros Message-Id: <20070921014913.BAC703079F69@linuxbuild.melbourne.sgi.com> Date: Fri, 21 Sep 2007 11:49:13 +1000 (EST) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12995 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 Unwrap AIL_LOCK Un-obfuscate AIL_LOCK, remove AIL_LOCK->mutex_lock->spin_lock macros, call spin_lock directly, remove extraneous cookie holdover from old xfs code, and change lock type to spinlock_t. Signed-off-by: Eric Sandeen Date: Fri Sep 21 11:45:49 AEST 2007 Workarea: linuxbuild.melbourne.sgi.com:/home/donaldd/isms/2.6.x-xfs Inspected by: sandeen@sandeen.net The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29739a fs/xfs/xfs_extfree_item.c - 1.68 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_extfree_item.c.diff?r1=text&tr1=1.68&r2=text&tr2=1.67&f=h fs/xfs/xfs_buf_item.c - 1.164 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_buf_item.c.diff?r1=text&tr1=1.164&r2=text&tr2=1.163&f=h fs/xfs/xfs_trans_priv.h - 1.29 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans_priv.h.diff?r1=text&tr1=1.29&r2=text&tr2=1.28&f=h fs/xfs/xfs_trans_ail.c - 1.82 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans_ail.c.diff?r1=text&tr1=1.82&r2=text&tr2=1.81&f=h fs/xfs/xfs_inode_item.c - 1.131 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode_item.c.diff?r1=text&tr1=1.131&r2=text&tr2=1.130&f=h fs/xfs/xfs_log_recover.c - 1.325 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_recover.c.diff?r1=text&tr1=1.325&r2=text&tr2=1.324&f=h fs/xfs/xfs_mount.h - 1.252 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.h.diff?r1=text&tr1=1.252&r2=text&tr2=1.251&f=h fs/xfs/xfs_mount.c - 1.412 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.412&r2=text&tr2=1.411&f=h fs/xfs/xfs_inode.c - 1.481 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.481&r2=text&tr2=1.480&f=h fs/xfs/xfs_trans.c - 1.184 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans.c.diff?r1=text&tr1=1.184&r2=text&tr2=1.183&f=h fs/xfs/quota/xfs_dquot_item.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_dquot_item.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h fs/xfs/quota/xfs_dquot.c - 1.30 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_dquot.c.diff?r1=text&tr1=1.30&r2=text&tr2=1.29&f=h From owner-xfs@oss.sgi.com Thu Sep 20 18:53:59 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Sep 2007 18:54:02 -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 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 l8L1rugf031150 for ; Thu, 20 Sep 2007 18:53:58 -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 LAA12842; Fri, 21 Sep 2007 11:53:54 +1000 From: donaldd@sgi.com Received: by linuxbuild.melbourne.sgi.com (Postfix, from userid 16365) id 954D03079F72; Fri, 21 Sep 2007 11:53:54 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 970382 - untangle spinlock macros Message-Id: <20070921015354.954D03079F72@linuxbuild.melbourne.sgi.com> Date: Fri, 21 Sep 2007 11:53:54 +1000 (EST) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12996 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 Unwrap LOG_LOCK. Un-obfuscate LOG_LOCK, remove LOG_LOCK->mutex_lock->spin_lock macros, call spin_lock directly, remove extraneous cookie holdover from old xfs code, and change lock type to spinlock_t. Signed-off-by: Eric Sandeen Date: Fri Sep 21 11:52:54 AEST 2007 Workarea: linuxbuild.melbourne.sgi.com:/home/donaldd/isms/2.6.x-xfs Inspected by: sandeen@sandeen.net The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29740a fs/xfs/xfs_log.c - 1.337 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log.c.diff?r1=text&tr1=1.337&r2=text&tr2=1.336&f=h - Unwrap LOG_LOCK fs/xfs/xfs_log_priv.h - 1.121 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_priv.h.diff?r1=text&tr1=1.121&r2=text&tr2=1.120&f=h - Unwrap LOG_LOCK From owner-xfs@oss.sgi.com Thu Sep 20 19:00:15 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Sep 2007 19:00: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.6 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 l8L20Agf032713 for ; Thu, 20 Sep 2007 19:00:14 -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 MAA13112; Fri, 21 Sep 2007 12:00:08 +1000 From: donaldd@sgi.com Received: by linuxbuild.melbourne.sgi.com (Postfix, from userid 16365) id 78CF53079F83; Fri, 21 Sep 2007 12:00:08 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 970382 - untangle spinlock macros Message-Id: <20070921020008.78CF53079F83@linuxbuild.melbourne.sgi.com> Date: Fri, 21 Sep 2007 12:00:08 +1000 (EST) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12997 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 Unwrap GRANT_LOCK. Un-obfuscate GRANT_LOCK, remove GRANT_LOCK->mutex_lock->spin_lock macros, call spin_lock directly, remove extraneous cookie holdover from old xfs code, and change lock type to spinlock_t. Signed-off-by: Eric Sandeen Date: Fri Sep 21 11:59:22 AEST 2007 Workarea: linuxbuild.melbourne.sgi.com:/home/donaldd/isms/2.6.x-xfs Inspected by: sandeen@sandeen.net The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29741a fs/xfs/xfs_log.c - 1.338 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log.c.diff?r1=text&tr1=1.338&r2=text&tr2=1.337&f=h - Unwrap GRANT_LOCK. fs/xfs/xfs_log_priv.h - 1.122 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_priv.h.diff?r1=text&tr1=1.122&r2=text&tr2=1.121&f=h - Unwrap GRANT_LOCK. fs/xfs/xfs_vnodeops.c - 1.722 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.722&r2=text&tr2=1.721&f=h - Unwrap GRANT_LOCK. From owner-xfs@oss.sgi.com Thu Sep 20 19:14:24 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Sep 2007 19:14: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=0.0 required=5.0 tests=BAYES_50 autolearn=ham version=3.2.0-pre1-r499012 Received: from web35703.mail.mud.yahoo.com (web35703.mail.mud.yahoo.com [66.163.179.157]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l8L2ELgf002908 for ; Thu, 20 Sep 2007 19:14:24 -0700 Received: (qmail 47466 invoked by uid 60001); 21 Sep 2007 02:14:23 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=pbOdV0L/wZITFLssobSJ3nMHYSgk7aEqdHFdOnJ6feUNMdz3gug6+mIE63SIKHSrTneNjLIBx4T4SGE1MNwrrnbADtOGs18q5oBnh+GPbI9hM9h7J6OCu0YJglkvIrABi1iXPTfgaAEA2IYiuQTq2EADMc75VN//HqpM3Nm99J0=; X-YMail-OSG: NaKGVUIVM1n2K7z7GlaKW9oFzqpJn_VUZ7nFtoWd8nI4MZWThnnoppw7Y_ITPiBGK4dUtpjQKk1k1uVOKPFF3RrJKt0bTnXrMbkzTRK3us7T4ZuyZjs5Ah46Vrtydg-- Received: from [69.124.63.172] by web35703.mail.mud.yahoo.com via HTTP; Thu, 20 Sep 2007 19:14:23 PDT Date: Thu, 20 Sep 2007 19:14:23 -0700 (PDT) From: Mariella Petrini Subject: Re: xfs and Linux Linux 2.6.22 and Memory To: Eric Sandeen Cc: xfs@oss.sgi.com, dgc@sgi.com In-Reply-To: <46F2E001.4040107@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <773373.46803.qm@web35703.mail.mud.yahoo.com> X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12998 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mariellapetrini@yahoo.com Precedence: bulk X-list: xfs > > Are you actually seeing a problem with this (caching > is generally good) > or just curious? > I was mostly curious, especially because In some cases after having created all the files I may not need to have all of them cached and I may need to availability of the RAM for other purposes. Thank you all for all the info, Mariella --- Eric Sandeen wrote: > Mariella Petrini wrote: > > > QUESTION: > > > > Is there any way to release that amount of memory > > without unmounting the file systems ? > > Is that caused to some caching mechanism ? > > Or could that be caused by something else ? > > It's most likely the linux VFS caching the dentries > & inodes, and > therefore caching the xfs inodes as well. > > cat /proc/sys/fs/dentry-state and > /proc/sys/fs/inode-state to see how > many are in memory, how many are active, and the age > limit. > > slabtop would fairly easily show you how much is in > the dentry_cache & > the inode_cache too. > > Are you actually seeing a problem with this (caching > is generally good) > or just curious? > > -Eric > > > ____________________________________________________________________________________ Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list&sid=396545469 From owner-xfs@oss.sgi.com Thu Sep 20 19:27:15 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Sep 2007 19:27: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 l8L2RAgf004992 for ; Thu, 20 Sep 2007 19:27:14 -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 MAA13823; Fri, 21 Sep 2007 12:27:08 +1000 From: donaldd@sgi.com Received: by linuxbuild.melbourne.sgi.com (Postfix, from userid 16365) id EB225305C989; Fri, 21 Sep 2007 12:27:07 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 970382 - untangle spinlock macros Message-Id: <20070921022707.EB225305C989@linuxbuild.melbourne.sgi.com> Date: Fri, 21 Sep 2007 12:27:07 +1000 (EST) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12999 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 Unwrap XFS_DQ_PINUNLOCK. Un-obfuscate DQ_PINLOCK, remove DQ_PINLOCK->mutex_lock->spin_lock macros, call spin_lock directly, remove extraneous cookie holdover from old xfs code, and change lock type to spinlock_t. Signed-off-by: Eric Sandeen Date: Fri Sep 21 12:26:20 AEST 2007 Workarea: linuxbuild.melbourne.sgi.com:/home/donaldd/isms/2.6.x-xfs Inspected by: sandeen@sandeen.net The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29742a fs/xfs/quota/xfs_dquot_item.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_dquot_item.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h - Unwrap XFS_DQ_PINUNLOCK fs/xfs/quota/xfs_dquot.h - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_dquot.h.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h - Unwrap XFS_DQ_PINUNLOCK fs/xfs/quota/xfs_qm.h - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm.h.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h - Unwrap XFS_DQ_PINUNLOCK From owner-xfs@oss.sgi.com Thu Sep 20 20:10:33 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Sep 2007 20:10: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.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.2.0-pre1-r499012 Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8L3ASgf010453 for ; Thu, 20 Sep 2007 20:10:33 -0700 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1IYYuV-0005FP-1W for linux-xfs@oss.sgi.com; Thu, 20 Sep 2007 20:10:31 -0700 Message-ID: <12809900.post@talk.nabble.com> Date: Thu, 20 Sep 2007 20:10:31 -0700 (PDT) From: Hxsrmeng To: linux-xfs@oss.sgi.com Subject: Questions about testing the Filestream feature MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: hxsrmeng@gmail.com X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13000 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hxsrmeng@gmail.com Precedence: bulk X-list: xfs Hi all, I need to use the "Filestreams" feature. I wrote a script to write files to two directories concurrently. When I check the file bitmap, I found sometimes the files written in the different directories still interleave extents on disk. I don't know whether there is something wrong with my script, or, I misunderstand something. I am using Opensuse10.2, the kernel is linux-2.6.23-rc4 (source code was check out from cvs of oss.sgi.com). The filestreams feature is enabled with a "-o filestreams" mount option. Here is my script: " 1 #try filestreams 2 a=$1 3 filenumber=`expr $a - 1` 4 filesize=$2 5 6 umount /xfs_disk 7 /sbin/mkfs -t xfs -f /dev/hda5 #>> logfile 8 mount -t xfs -o filestreams /dev/hda5 /xfs_disk 9 #enable filestreams 10 11 cd /xfs_disk 12 for dirname in dira dirb 13 do 14 mkdir $dirname 15 for filename in `seq 0 $filenumber` 16 do 17 dd if=/dev/zero of=$dirname/$filename bs=$filesize count=1 > /dev/null 2>&1 & 18 done 19 done 20 21 wait 22 for dirname in dira dirb 23 do 24 for filename in `seq 0 $filenumber` 25 do 26 /usr/sbin/xfs_bmap -v $dirname/$filename > bmapresult 27 cat bmapresult >> bitmap 28 a="expr `wc -l bmapresult | awk '{print $1}'` - 2" 29 b=`$a` 30 c=`tail -$b bmapresult | awk '{ print $4 }'` 31 echo $dirname/$filename is in AG $c:>>agmap 32 done 33 done " Then I got the information of my xfs device first : meta-data=/dev/hda5 isize=256 agcount=8, agsize=159895 blks = sectsz=512 attr=0 data = bsize=4096 blocks=1279160, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming = version 2 bsize=4096 log = internal log bsize=4096 blocks=2560, version=1 = sectsz=512 sunit=0 blks realtime = none extsz=65536 blocks=0, rtextents=0 First run, I wrote 3 "big" files, which are 768M, to each directories. The files in directory dira share AG 0,2,5,7 and files in directory dirb share AG 1, 3, 4, 6, which I assume should be correct. But the files extents doesn't use contiguous blocks, and all files in the same directory put some of their extents in AG 0. I am not sure whether this is correct. Here is part of file bitmap: " dira/0: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..7615]: 96..7711 0 (96..7711) 7616 1: [7616..7679]: 33312..33375 0 (33312..33375) 64 2: [7680..24063]: 33448..49831 0 (33448..49831) 16384 3: [24064..52999]: 60608..89543 0 (60608..89543) 28936 4: [53000..61191]: 95496..103687 0 (95496..103687) 8192 5: [61192..90791]: 119088..148687 0 (119088..148687) 29600 6: [90792..131751]: 170264..211223 0 (170264..211223) 40960 7: [131752..144223]: 219480..231951 0 (219480..231951) 12472 8: [144224..168799]: 240144..264719 0 (240144..264719) 24576 ... dira/1: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..12791]: 7712..20503 0 (7712..20503) 12792 1: [12792..12863]: 33376..33447 0 (33376..33447) 72 2: [12864..13391]: 49832..50359 0 (49832..50359) 528 3: [13392..19575]: 112904..119087 0 (112904..119087) 6184 4: [19576..27767]: 148688..156879 0 (148688..156879) 8192 5: [27768..35959]: 211224..219415 0 (211224..219415) 8192 6: [35960..44151]: 231952..240143 0 (231952..240143) 8192 7: [44152..68727]: 264784..289359 0 (264784..289359) 24576 8: [68728..79047]: 309400..319719 0 (309400..319719) 10320 " Second run, I wrote 1024 "small" files, which are 1M, to each directories. Files in directory dira use AG 0,1,3 and files in directory b use AG 2,1,5,6,7,4. So files written in directory dirb use the allocation group 1, which should be reserved for directory dira . And, sometimes even one file is written to two AGs. The following is part of file bitmap: " ... dira/498: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..63]: 570848..570911 0 (570848..570911) 64 1: [64..2047]: 1666600..1668583 1 (387440..389423) 1984 dira/499: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..23]: 571672..571695 0 (571672..571695) 24 1: [24..79]: 571776..571831 0 (571776..571831) 56 2: [80..1839]: 1650616..1652375 1 (371456..373215) 1760 3: [1840..1903]: 1662240..1662303 1 (383080..383143) 64 4: [1904..2047]: 1676984..1677127 1 (397824..397967) 144 ... dirb/4: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..2047]: 1279264..1281311 1 (104..2151) 2048 dirb/5: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..63]: 1352136..1352199 1 (72976..73039) 64 1: [64..415]: 1451896..1452247 1 (172736..173087) 352 2: [416..1279]: 1633616..1634479 1 (354456..355319) 864 3: [1280..1343]: 1647288..1647351 1 (368128..368191) 64 4: [1344..2047]: 1677128..1677831 1 (397968..398671) 704 dirb/6: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..2047]: 1285408..1287455 1 (6248..8295) 2048 .... " I don't know whether the filestreams feature may works this way, or I made some mistakes? Thank you so much! -- View this message in context: http://www.nabble.com/Questions-about-testing-the-Filestream-feature-tf4491605.html#a12809900 Sent from the linux-xfs mailing list archive at Nabble.com. From owner-xfs@oss.sgi.com Thu Sep 20 20:14:03 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Sep 2007 20:14: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=-2.3 required=5.0 tests=AWL,BAYES_00, 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 l8L3E0gf011288 for ; Thu, 20 Sep 2007 20:14:02 -0700 X-IronPort-AV: E=Sophos;i="4.20,280,1186324200"; d="scan'208";a="191696574" 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; 21 Sep 2007 12:43:33 +0930 Received: by jdc.jasonjgw.net (Postfix, from userid 1000) id D8AB11000C69B; Fri, 21 Sep 2007 13:13:30 +1000 (EST) Date: Fri, 21 Sep 2007 13:13:30 +1000 From: Jason White To: xfs@oss.sgi.com Subject: Re: xfs and Linux Linux 2.6.22 and Memory Message-ID: <20070921031330.GA15134@jdc.jasonjgw.net> Mail-Followup-To: xfs@oss.sgi.com References: <46F2E001.4040107@sandeen.net> <773373.46803.qm@web35703.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <773373.46803.qm@web35703.mail.mud.yahoo.com> User-Agent: Mutt/1.5.16 (2007-06-11) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13001 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 Thu, Sep 20, 2007 at 07:14:23PM -0700, Mariella Petrini wrote: > I was mostly curious, especially because In some cases > after having created all the files I may not need to > have all of them cached and I may need to availability > of the RAM for other purposes. I may be wrong, but as I understand it, if the RAM is needed for other purposes, cache pages are made available automatically and the size of the cache is reduced as the RAM is allocated by processes. From owner-xfs@oss.sgi.com Thu Sep 20 21:28:06 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Sep 2007 21:28:11 -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 l8L4S1gf026016 for ; Thu, 20 Sep 2007 21:28:04 -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 OAA16114; Fri, 21 Sep 2007 14:27:58 +1000 From: donaldd@sgi.com Received: by linuxbuild.melbourne.sgi.com (Postfix, from userid 16365) id B7C183079FFE; Fri, 21 Sep 2007 14:27:58 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 970382 - untangle spinlock macros Message-Id: <20070921042758.B7C183079FFE@linuxbuild.melbourne.sgi.com> Date: Fri, 21 Sep 2007 14:27:58 +1000 (EST) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13002 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 Unwrap pagb_lock. Un-obfuscate pagb_lock, remove mutex_lock->spin_lock macros, call spin_lock directly, remove extraneous cookie holdover from old xfs code, and change lock type to spinlock_t. Signed-off-by: Eric Sandeen Date: Fri Sep 21 14:27:12 AEST 2007 Workarea: linuxbuild.melbourne.sgi.com:/home/donaldd/isms/2.6.x-xfs Inspected by: sandeen@sandeen.net The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29743a fs/xfs/xfs_ag.h - 1.62 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_ag.h.diff?r1=text&tr1=1.62&r2=text&tr2=1.61&f=h - Unwrap pagb_lock fs/xfs/xfs_alloc.c - 1.188 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_alloc.c.diff?r1=text&tr1=1.188&r2=text&tr2=1.187&f=h - Unwrap pagb_lock From owner-xfs@oss.sgi.com Thu Sep 20 21:32:52 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Sep 2007 21:32: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.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 l8L4Wngf027211 for ; Thu, 20 Sep 2007 21:32:51 -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 OAA16321; Fri, 21 Sep 2007 14:32:48 +1000 From: donaldd@sgi.com Received: by linuxbuild.melbourne.sgi.com (Postfix, from userid 16365) id E7948307A008; Fri, 21 Sep 2007 14:32:47 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 970382 - untangle spinlock macros Message-Id: <20070921043247.E7948307A008@linuxbuild.melbourne.sgi.com> Date: Fri, 21 Sep 2007 14:32:47 +1000 (EST) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13003 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 Unwrap xfs_dabuf_global_lock Un-obfuscate dabuf_global_lock, remove mutex_lock->spin_lock macros, call spin_lock directly, remove extraneous cookie holdover from old xfs code, and change lock type to spinlock_t. Signed-off-by: Eric Sandeen Date: Fri Sep 21 14:32:21 AEST 2007 Workarea: linuxbuild.melbourne.sgi.com:/home/donaldd/isms/2.6.x-xfs Inspected by: sandeen@sandeen.net The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29744a fs/xfs/xfs_da_btree.c - 1.176 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_da_btree.c.diff?r1=text&tr1=1.176&r2=text&tr2=1.175&f=h - Unwrap xfs_dabuf_global_lock fs/xfs/xfs_vfsops.c - 1.541 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.541&r2=text&tr2=1.540&f=h - Unwrap xfs_dabuf_global_lock From owner-xfs@oss.sgi.com Thu Sep 20 21:36:02 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Sep 2007 21:36:07 -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 l8L4Zvgf028053 for ; Thu, 20 Sep 2007 21:36:00 -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 OAA16406; Fri, 21 Sep 2007 14:35:54 +1000 From: donaldd@sgi.com Received: by linuxbuild.melbourne.sgi.com (Postfix, from userid 16365) id BB5D3307A00E; Fri, 21 Sep 2007 14:35:54 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 970382 - untangle spinlock macros Message-Id: <20070921043554.BB5D3307A00E@linuxbuild.melbourne.sgi.com> Date: Fri, 21 Sep 2007 14:35:54 +1000 (EST) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13004 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 Unwrap mru_lock. Un-obfuscate mru_lock, remove mutex_lock->spin_lock macros, call spin_lock directly, remove extraneous cookie holdover from old xfs code. Signed-off-by: Eric Sandeen Date: Fri Sep 21 14:35:22 AEST 2007 Workarea: linuxbuild.melbourne.sgi.com:/home/donaldd/isms/2.6.x-xfs Inspected by: sandeen@sandeen.net The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29745a fs/xfs/xfs_mru_cache.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mru_cache.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h - Unwrap mru_lock From owner-xfs@oss.sgi.com Thu Sep 20 21:45:42 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Sep 2007 21:45: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.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 l8L4jagf029481 for ; Thu, 20 Sep 2007 21:45:40 -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 OAA16617; Fri, 21 Sep 2007 14:45:35 +1000 From: donaldd@sgi.com Received: by linuxbuild.melbourne.sgi.com (Postfix, from userid 16365) id DA755307A01A; Fri, 21 Sep 2007 14:45:34 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 970382 - untangle spinlock macros Message-Id: <20070921044534.DA755307A01A@linuxbuild.melbourne.sgi.com> Date: Fri, 21 Sep 2007 14:45:34 +1000 (EST) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13005 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 Unwrap XFS_SB_LOCK. Un-obfuscate XFS_SB_LOCK, remove XFS_SB_LOCK->mutex_lock->spin_lock macros, call spin_lock directly, remove extraneous cookie holdover from old xfs code, and change lock type to spinlock_t. Signed-off-by: Eric Sandeen Date: Fri Sep 21 14:44:47 AEST 2007 Workarea: linuxbuild.melbourne.sgi.com:/home/donaldd/isms/2.6.x-xfs Inspected by: sandeen@sandeen.net The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29746a fs/xfs/xfs_vfsops.c - 1.542 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.542&r2=text&tr2=1.541&f=h - Unwrap XFS_SB_LOCK fs/xfs/xfs_mount.h - 1.253 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.h.diff?r1=text&tr1=1.253&r2=text&tr2=1.252&f=h - Unwrap XFS_SB_LOCK fs/xfs/xfs_mount.c - 1.413 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.413&r2=text&tr2=1.412&f=h - Unwrap XFS_SB_LOCK fs/xfs/xfs_qmops.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_qmops.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h - Unwrap XFS_SB_LOCK fs/xfs/xfs_attr_leaf.c - 1.108 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr_leaf.c.diff?r1=text&tr1=1.108&r2=text&tr2=1.107&f=h - Unwrap XFS_SB_LOCK fs/xfs/xfs_utils.c - 1.78 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_utils.c.diff?r1=text&tr1=1.78&r2=text&tr2=1.77&f=h - Unwrap XFS_SB_LOCK fs/xfs/xfs_fsops.c - 1.131 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_fsops.c.diff?r1=text&tr1=1.131&r2=text&tr2=1.130&f=h - Unwrap XFS_SB_LOCK fs/xfs/xfs_bmap.c - 1.379 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.c.diff?r1=text&tr1=1.379&r2=text&tr2=1.378&f=h - Unwrap XFS_SB_LOCK fs/xfs/quota/xfs_qm_syscalls.c - 1.36 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm_syscalls.c.diff?r1=text&tr1=1.36&r2=text&tr2=1.35&f=h - Unwrap XFS_SB_LOCK fs/xfs/quota/xfs_qm.c - 1.56 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm.c.diff?r1=text&tr1=1.56&r2=text&tr2=1.55&f=h - Unwrap XFS_SB_LOCK From owner-xfs@oss.sgi.com Thu Sep 20 21:49:54 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Sep 2007 21:49: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 l8L4nkgf030374 for ; Thu, 20 Sep 2007 21:49:51 -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 OAA16727; Fri, 21 Sep 2007 14:49:44 +1000 From: donaldd@sgi.com Received: by linuxbuild.melbourne.sgi.com (Postfix, from userid 16365) id 24416307A03C; Fri, 21 Sep 2007 14:49:44 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 970382 - untangle spinlock macros Message-Id: <20070921044944.24416307A03C@linuxbuild.melbourne.sgi.com> Date: Fri, 21 Sep 2007 14:49:44 +1000 (EST) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13006 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 ktrace kt_lock is unused, remove it. Signed-off-by: Eric Sandeen Date: Fri Sep 21 14:49:14 AEST 2007 Workarea: linuxbuild.melbourne.sgi.com:/home/donaldd/isms/2.6.x-xfs Inspected by: sandeen@sandeen.net The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29747a fs/xfs/support/ktrace.c - 1.27 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/support/ktrace.c.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h - Remove unused kt_lock fs/xfs/support/ktrace.h - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/support/ktrace.h.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h - Remove unused kt_lock From owner-xfs@oss.sgi.com Thu Sep 20 23:16:56 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Sep 2007 23:16: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=0.7 required=5.0 tests=ANY_BOUNCE_MESSAGE,AWL, BAYES_50,VBOUNCE_MESSAGE autolearn=no version=3.2.0-pre1-r499012 Received: from omr-d31.mx.aol.com (omr-d31.mx.aol.com [205.188.249.129]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8L6Grgf010305 for ; Thu, 20 Sep 2007 23:16:55 -0700 Received: from rly-md01.mx.aol.com (rly-md01.mx.aol.com [64.12.138.46]) by omr-d31.mx.aol.com (v117.7) with ESMTP id MAILOMRD317-7e4c46f35f672fb; Fri, 21 Sep 2007 02:06:31 -0400 Received: from localhost (localhost) by rly-md01.mx.aol.com (8.13.8/8.14.1) id l8L66MAm016344; Fri, 21 Sep 2007 02:06:31 -0400 Date: Fri, 21 Sep 2007 02:06:31 -0400 From: Mail Delivery Subsystem Message-Id: <200709210606.l8L66MAm016344@rly-md01.mx.aol.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="l8L66MAm016344.1190354791/rly-md01.mx.aol.com" Subject: Returned mail: see transcript for details Auto-Submitted: auto-generated (failure) X-AOL-INRLY: ord-static-208.57.124.56.mpowercom.net [208.57.124.56] rly-md01 X-AOL-IP: 64.12.138.46 X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13009 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: MAILER-DAEMON@aol.com Precedence: bulk X-list: xfs This is a MIME-encapsulated message --l8L66MAm016344.1190354791/rly-md01.mx.aol.com The original message was received at Fri, 21 Sep 2007 02:06:11 -0400 from ord-static-208.57.124.56.mpowercom.net [208.57.124.56] *** ATTENTION *** Your e-mail is being returned to you because there was a problem with its delivery. The address which was undeliverable is listed in the section labeled: "----- The following addresses had permanent fatal errors -----". The reason your mail is being returned to you is listed in the section labeled: "----- Transcript of Session Follows -----". The line beginning with "<<<" describes the specific reason your e-mail could not be delivered. The next line contains a second error message which is a general translation for other e-mail servers. Please direct further questions regarding this message to your e-mail administrator. --AOL Postmaster ----- The following addresses had permanent fatal errors ----- (reason: 554 TRANSACTION FAILED - Unrepairable Virus Detected. Your mail has not been sent.) ----- Transcript of session follows ----- ... while talking to air-md07.mail.aol.com.: >>> DATA <<< 554 TRANSACTION FAILED - Unrepairable Virus Detected. Your mail has not been sent. 554 5.0.0 Service unavailable --l8L66MAm016344.1190354791/rly-md01.mx.aol.com Content-Type: message/delivery-status Reporting-MTA: dns; rly-md01.mx.aol.com Arrival-Date: Fri, 21 Sep 2007 02:06:11 -0400 Final-Recipient: RFC822; lmathis27@aol.com Action: failed Status: 5.0.0 Remote-MTA: DNS; air-md07.mail.aol.com Diagnostic-Code: SMTP; 554 TRANSACTION FAILED - Unrepairable Virus Detected. Your mail has not been sent. Last-Attempt-Date: Fri, 21 Sep 2007 02:06:31 -0400 --l8L66MAm016344.1190354791/rly-md01.mx.aol.com Content-Type: text/rfc822-headers Received: from oss.sgi.com (ord-static-208.57.124.56.mpowercom.net [208.57.124.56]) by rly-md01.mx.aol.com (v119.9) with ESMTP id MAILRELAYINMD018-8e846f35f423e6; Fri, 21 Sep 2007 02:06:10 -0400 From: linux-xfs@oss.sgi.com To: lmathis27@aol.com Subject: RETURNED MAIL: SEE TRANSCRIPT FOR DETAILS Date: Thu, 9 Nov 2000 15:19:14 -0600 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0011_1C0591AD.86E2C5E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-AOL-IP: 208.57.124.56 X-AOL-SCOLL-SCORE: 0:2:201937312:9395240 X-AOL-SCOLL-URL_COUNT: X-AOL-SCOLL-AUTHENTICATION: listenair ; SPF_helo : X-AOL-SCOLL-AUTHENTICATION: listenair ; SPF_822_from : Message-ID: <200709210206.8e846f35f423e6@rly-md01.mx.aol.com> --l8L66MAm016344.1190354791/rly-md01.mx.aol.com-- From owner-xfs@oss.sgi.com Thu Sep 20 23:27:47 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Sep 2007 23:27: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.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 l8L6Rfgf012541 for ; Thu, 20 Sep 2007 23:27:46 -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 QAA18558; Fri, 21 Sep 2007 16:27:40 +1000 From: donaldd@sgi.com Received: by linuxbuild.melbourne.sgi.com (Postfix, from userid 16365) id 1A03B2F59F9B; Fri, 21 Sep 2007 16:27:40 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 970382 - untangle spinlock macros Message-Id: <20070921062740.1A03B2F59F9B@linuxbuild.melbourne.sgi.com> Date: Fri, 21 Sep 2007 16:27:40 +1000 (EST) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13010 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 Remove spin.h remove spinlock init abstraction macro in spin.h, remove the callers, and remove the file. Move no-op spinlock_destroy to xfs_linux.h Cleanup spinlock locals in xfs_mount.c Signed-off-by: Eric Sandeen Date: Fri Sep 21 16:26:30 AEST 2007 Workarea: linuxbuild.melbourne.sgi.com:/home/donaldd/isms/2.6.x-xfs Inspected by: sandeen@sandeen.net,lachlan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29751a fs/xfs/xfs_log.c - 1.339 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log.c.diff?r1=text&tr1=1.339&r2=text&tr2=1.338&f=h - Remove spin.h fs/xfs/xfs_vfsops.c - 1.543 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.543&r2=text&tr2=1.542&f=h - Remove spin.h fs/xfs/xfs_mount.c - 1.414 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.414&r2=text&tr2=1.413&f=h - Remove spin.h, cleanup local spinlock variables. fs/xfs/xfs_alloc.c - 1.189 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_alloc.c.diff?r1=text&tr1=1.189&r2=text&tr2=1.188&f=h - Remove spin.h fs/xfs/support/debug.c - 1.38 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/support/debug.c.diff?r1=text&tr1=1.38&r2=text&tr2=1.37&f=h - Remove spin.h fs/xfs/support/ktrace.h - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/support/ktrace.h.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h - Remove spin.h fs/xfs/quota/xfs_qm.c - 1.57 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm.c.diff?r1=text&tr1=1.57&r2=text&tr2=1.56&f=h - Remove spin.h fs/xfs/linux-2.6/xfs_linux.h - 1.159 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_linux.h.diff?r1=text&tr1=1.159&r2=text&tr2=1.158&f=h - Remove spin.h fs/xfs/linux-2.6/xfs_buf.c - 1.244 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.c.diff?r1=text&tr1=1.244&r2=text&tr2=1.243&f=h - Remove spin.h fs/xfs/linux-2.6/spin.h - 1.22 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/spin.h.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h - Remove spin.h fs/xfs/xfs_mru_cache.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mru_cache.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h - Remove spin.h From owner-xfs@oss.sgi.com Thu Sep 20 23:33:56 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Sep 2007 23:34:00 -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 l8L6Xqgf013972 for ; Thu, 20 Sep 2007 23:33:54 -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 QAA18834; Fri, 21 Sep 2007 16:33:50 +1000 Message-ID: <46F36639.3050004@sgi.com> Date: Fri, 21 Sep 2007 16:35:37 +1000 From: Vlad Apostolov User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: xfs-dev CC: xfs@oss.sgi.com Subject: Review: get_bulkall() returns incorrect inode state Content-Type: multipart/mixed; boundary="------------050703030108060701050103" X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13011 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 This is a multi-part message in MIME format. --------------050703030108060701050103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In the following scenario xfs_bulkstat() returns incorrect stale inode state: 1. File_A is created and its inode synced to disk. 2. File_A is unlinked and doesn't exist anymore. 3. Filesystem sync is invoked. 4. File_B is created. File_B happens to reclaim File_A's inode. 5. xfs_bulkstat() is called and detects File_B but reports the incorrect File_A inode state. Explanation for the incorrect inode state is that inodes are not immediately synced on file create for performance reasons. This leaves the on-disk inode buffer uninitialized (or with old state from a previous generation inode) and this is what xfs_bulkstat() would report. Solutions: One solution provided by the attached patch is to mark the on-disk inode buffer "dirty" on unlink. When the inode is reclaimed (by a new file create), xfs_bulkstat() would filter this inode by the "dirty" mark. Once the inode is flushed to disk, the on-disk buffer "dirty" mark is automatically removed and a following xfs_bulkstat() would return the correct inode state. A better solution would be if the inode is immediately synced at create. This would make the on-disk inode buffer up to date and xfs_bulkstat() should return the correct inode state. Disadvantages of the above solutions: The first solution marks the inode "dirty" on unlink by setting the on-disk di_nlink field to 0. Note that the in-core di_nlink has already been set to 0 and a corresponding transaction logged by xfs_droplink(). This is an exception from the rule that any on-disk inode buffer changes has to be followed by a disk write (inode flush). Synchronizing the in-core to on-disk di_nlink values in advance (before the actual inode flush to disk) should be fine in this case because the inode is already unlinked and it would never change its di_nlink again for this inode generation. The second solution would be a performance hit as it would require disk write for each new file create to flush the inode to disk. Dave suggested modifying the inode sync code to allow on-disk buffer updates without disk writes. This doesn't seem to be very simple and would require some time for a proper implementation and testing. I have been assigned to do it in the near future. In the mean time we have XFS users that urgently need a solution and the patch bellow seems to fix the problem for them. Regards, Vlad --------------050703030108060701050103 Content-Type: text/x-patch; name="get_bulkall-appears-to-return-stale-information.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="get_bulkall-appears-to-return-stale-information.patch" Index: linux-xfs1/fs/xfs/xfs_inode.c =================================================================== --- linux-xfs1.orig/fs/xfs/xfs_inode.c +++ linux-xfs1/fs/xfs/xfs_inode.c @@ -1952,6 +1952,25 @@ xfs_iunlink( bucket_index = agino % XFS_AGI_UNLINKED_BUCKETS; ASSERT(agi->agi_unlinked[bucket_index]); ASSERT(be32_to_cpu(agi->agi_unlinked[bucket_index]) != agino); + error = xfs_itobp(mp, tp, ip, &dip, &ibp, 0, 0); + + if (error) { + return error; + } + + /* + * Clear the on-disk di_nlink. This is to prevent xfs_bulkstat + * from picking up this inode when it is reclaimed (its incore state + * initialzed but not flushed to disk yet). The in-core di_nlink is + * already cleared in xfs_droplink() and a corresponding transaction + * logged. The hack here just synchronizes the in-core to on-disk + * di_nlink value in advance before the actual inode sync to disk. + * This is OK because the inode is already unlinked and would never + * change its di_nlink again for this inode generation. + * This is a temporary hack that would require a proper fix + * in the future. + */ + dip->di_core.di_nlink = 0; if (be32_to_cpu(agi->agi_unlinked[bucket_index]) != NULLAGINO) { /* @@ -1960,10 +1979,6 @@ xfs_iunlink( * Here we put the head pointer into our next pointer, * and then we fall through to point the head at us. */ - error = xfs_itobp(mp, tp, ip, &dip, &ibp, 0, 0); - if (error) { - return error; - } ASSERT(be32_to_cpu(dip->di_next_unlinked) == NULLAGINO); /* both on-disk, don't endian flip twice */ dip->di_next_unlinked = agi->agi_unlinked[bucket_index]; Index: linux-xfs1/fs/xfs/xfs_itable.c =================================================================== --- linux-xfs1.orig/fs/xfs/xfs_itable.c +++ linux-xfs1/fs/xfs/xfs_itable.c @@ -290,8 +290,16 @@ xfs_bulkstat_use_dinode( return 1; dip = (xfs_dinode_t *) xfs_buf_offset(bp, clustidx << mp->m_sb.sb_inodelog); + /* + * Check the buffer containing the on-disk inode for di_nlink == 0. + * This is to prevent xfs_bulkstat from picking up just reclaimed + * inodes that have their in-core state initialized but not flushed + * to disk yet. This is a temporary hack that would require a proper + * fix in the future. + */ if (be16_to_cpu(dip->di_core.di_magic) != XFS_DINODE_MAGIC || - !XFS_DINODE_GOOD_VERSION(dip->di_core.di_version)) + !XFS_DINODE_GOOD_VERSION(dip->di_core.di_version) || + !dip->di_core.di_nlink) return 0; if (flags & BULKSTAT_FG_QUICK) { *dipp = dip; --------------050703030108060701050103-- From owner-xfs@oss.sgi.com Fri Sep 21 00:55:18 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 21 Sep 2007 00:55: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.7 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 l8L7t6gf002791 for ; Fri, 21 Sep 2007 00:55:15 -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 RAA20496; Fri, 21 Sep 2007 17:55:03 +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 l8L7t1dD32258904; Fri, 21 Sep 2007 17:55:02 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l8L7sx2932259398; Fri, 21 Sep 2007 17:54:59 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 21 Sep 2007 17:54:59 +1000 From: David Chinner To: Hxsrmeng Cc: linux-xfs@oss.sgi.com Subject: Re: Questions about testing the Filestream feature Message-ID: <20070921075459.GJ995458@sgi.com> References: <12809900.post@talk.nabble.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <12809900.post@talk.nabble.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13012 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 20, 2007 at 08:10:31PM -0700, Hxsrmeng wrote: > > Hi all, > > I need to use the "Filestreams" feature. I wrote a script to write files to > two directories concurrently. When I check the file bitmap, I found > sometimes the files written in the different directories still interleave > extents on disk. I don't know whether there is something wrong with my > script, or, I misunderstand something. > > I am using Opensuse10.2, the kernel is linux-2.6.23-rc4 (source code was > check out from cvs of oss.sgi.com). The filestreams feature is enabled with > a "-o filestreams" mount option. > Here is my script: Very similar to xfsqa tests 170-174. > Then I got the information of my xfs device first : > meta-data=/dev/hda5 isize=256 agcount=8, agsize=159895 blks > = sectsz=512 attr=0 > data = bsize=4096 blocks=1279160,imaxpct=25 Ok, so an AG ~600MB in size, and your filesystem is about 5GB. > First run, I wrote 3 "big" files, which are 768M, to each directories. The > files in directory dira share AG 0,2,5,7 and files in directory dirb share > AG 1, 3, 4, 6, which I assume should be correct. Yes, and 3*3*768 = 4GB ~= 80% full. > But the files extents > doesn't use contiguous blocks, filestreams doesn't guarantee contiguous extents - it guarantees sets of files separated by directories don't intertwine. Within the each set you can see non-contiguous allocation, but the sets should not interleave in the same AGs... > and all files in the same directory put some > of their extents in AG 0. AG 0 is the "filestreams failure" allocation group. What you are seeing is that at some point you've filled your AG's up and a stream write couldn't find an unused AG that matched the stream association criteria and it gave up. > I am not sure whether this is correct. Here is > part of file bitmap: > " > dira/0: > EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL > 0: [0..7615]: 96..7711 0 (96..7711) 7616 > 1: [7616..7679]: 33312..33375 0 (33312..33375) 64 > 2: [7680..24063]: 33448..49831 0 (33448..49831) 16384 > 3: [24064..52999]: 60608..89543 0 (60608..89543) 28936 > 4: [53000..61191]: 95496..103687 0 (95496..103687) 8192 > 5: [61192..90791]: 119088..148687 0 (119088..148687) 29600 > 6: [90792..131751]: 170264..211223 0 (170264..211223) 40960 > 7: [131752..144223]: 219480..231951 0 (219480..231951) 12472 > 8: [144224..168799]: 240144..264719 0 (240144..264719) 24576 Ummm - that's a file stat started in AG 0.... > ... > dira/1: > EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL > 0: [0..12791]: 7712..20503 0 (7712..20503) 12792 > 1: [12792..12863]: 33376..33447 0 (33376..33447) 72 > 2: [12864..13391]: 49832..50359 0 (49832..50359) 528 > 3: [13392..19575]: 112904..119087 0 (112904..119087) 6184 > 4: [19576..27767]: 148688..156879 0 (148688..156879) 8192 > 5: [27768..35959]: 211224..219415 0 (211224..219415) 8192 > 6: [35960..44151]: 231952..240143 0 (231952..240143) 8192 > 7: [44152..68727]: 264784..289359 0 (264784..289359) 24576 > 8: [68728..79047]: 309400..319719 0 (309400..319719) 10320 And so is that. Given that they are in the same directory, this is correct behaviour. How much memory in your test box? I suspect that you're getting writeback from kswapd, not pdflush as you are doing buffered I/O and you're getting LRU order writeback rather than nice sequential writeback. It's up to the user/application to prevent intra-stream allocation/fragmentation problems (e.g. preallocation, extent size hints, large direct I/O, etc) and that is what your test application is lacking. filestreams only prevents inter-stream interleaving. Also, you are running close to filesystem full state. That is known to be a no-no for deterministic performance from the filesystem, will cause filesystem fragmentation, and is not the case that filestreams is designed to optimise for. however, I agree that the code is not working optimally. In test 171, there is this comment: # test large numbers of files, single I/O per file, 120s timeout # Get close to filesystem full. # 128 = ENOSPC # 120 = 93.75% full, gets repeatable failures # 112 = 87.5% full, should reliably succeed but doesn't *FIXME* # 100 = 78.1% full, should reliably succeed The test uses a 1GB filesystem to intentionally stress the allocator, and at 78.1% full, we are getting intermittent failures. On some machines (like my test boxes) it passes >95% of the time. On other machines, it passes maybe 5% of the time. So the low space behaviour is known to be less than optimal, but at production sites it is known that they can't use the last 10-15% of the filesystem because of fragmentation issues associated with stripe alignment. Hence low space behaviour of the allocator is not considered something critical because there are other, worse problems at low space that filestreams can't do anything to prevent. > Second run, I wrote 1024 "small" files, which are 1M, to each directories. > Files in directory dira use AG 0,1,3 and files in directory b use AG > 2,1,5,6,7,4. So files written in directory dirb use the allocation group 1, > which should be reserved for directory dira . And, sometimes even one file > is written to two AGs. The following is part of file bitmap: That's true only as long as a stream does not time out. An AG is reserved only as long a the timeout since the last file in a stream was created or allocated to. IOWs, if you use buffered I/O, the 30s writeback delay could time your stream out between file creation and write() syscall and when pdflush writes it back. Then you have no stream association and you will get interleaving. Test 172 tests this behaviour, and we get intermittent failures on that test because the buffered I/O case occasionally succeeds rather than fails like it is supposed to.... What's your stream timeout (/proc/sys/fs/xfs/filestream_centisecs) set to? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Fri Sep 21 02:14:32 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 21 Sep 2007 02:14: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.1 required=5.0 tests=BAYES_50,J_CHICKENPOX_43 autolearn=no version=3.2.0-pre1-r499012 Received: from mail.edu.haifa.ac.il (mail.edu.haifa.ac.il [132.74.40.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8L9ESgf021074 for ; Fri, 21 Sep 2007 02:14:32 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.edu.haifa.ac.il (Postfix) with ESMTP id 780D08E2C; Fri, 21 Sep 2007 11:14:41 +0200 (IST) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Scanned: amavisd-new at edu.haifa.ac.il Received: from mail.edu.haifa.ac.il ([127.0.0.1]) by localhost (mail.edu.haifa.ac.il [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id NF29HEDLC2yg; Fri, 21 Sep 2007 11:14:41 +0200 (IST) Received: from kozanostra (leon.edu.haifa.ac.il [132.74.41.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.edu.haifa.ac.il (Postfix) with ESMTP id 3ABB88E0B; Fri, 21 Sep 2007 11:14:41 +0200 (IST) From: "Leon Kolchinsky" To: "'Hxsrmeng'" , Subject: RE: Review: Concurrent Multi-File Data Streams Date: Fri, 21 Sep 2007 11:13:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acf7KJKXPFo/KZgbT0O+lU5o0k7SygBBbADg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <12789210.post@talk.nabble.com> Message-Id: <20070921091441.3ABB88E0B@mail.edu.haifa.ac.il> X-Virus-Status: Clean X-archive-position: 13014 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: leonk@construct.haifa.ac.il Precedence: bulk X-list: xfs > Is this feature included in the linux-2.6-xfs kernel downloaded from > cvs@oss.sgi.com? > > If it is included, in order to enable it, which control flag should be > set? > > If I write many files concurrently, should each file be stored in > contiguous > blocks in the same AG? > > Thanks > > > David Chinner wrote: > > > > > > Concurrent Multi-File Data Streams > > > > In media spaces, video is often stored in a frame-per-file format. > > When dealing with uncompressed realtime HD video streams in this format, > > it is crucial that files do not get fragmented and that multiple files > > a placed contiguously on disk. > > Hello All, I'm running DSS (Darwin Streaming Server) on one of my servers and that "Concurrent Multi-File Data Streams" thing seems very interesting :) I have a separate partition there I store all movies. Is 2.6.22 kernel already has this patch incorporated already(actually gentoo-sources-2.6.22-r5)? Are there any special mkfs.xfs or mount options I should make to make this thing work or make the FS to be optimized for streaming? Best Regards, Leon Kolchinsky From owner-xfs@oss.sgi.com Fri Sep 21 02:23:51 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 21 Sep 2007 02:23:55 -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_05,J_BACKHAIR_17, J_CHICKENPOX_62,J_CHICKENPOX_63,J_CHICKENPOX_64 autolearn=no 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 l8L9Nkgf022997 for ; Fri, 21 Sep 2007 02:23:50 -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 l8L9NkA5009955 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 21 Sep 2007 11:23:47 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8L9NkOR009953 for xfs@oss.sgi.com; Fri, 21 Sep 2007 11:23:46 +0200 Date: Fri, 21 Sep 2007 11:23:46 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: Re: [PATCH 3/3] xlog_rec_header/xlog_rec_ext_header endianess annotations Message-ID: <20070921092346.GA9917@lst.de> References: <20070920143335.GD13755@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070920143335.GD13755@lst.de> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13015 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 20, 2007 at 04:33:35PM +0200, Christoph Hellwig wrote: > Mostly trivial conversion with one exceptions: h_num_logops was kept > in native endian previously and only converted to big endian in > xlog_sync, but we always keep it big endian now. With todays cpus > fast byteswap instructions that's not an issue but the new variant > keeps the code clean and maintainable. Here's an updated patch to apply ontop of Eric's spinlock changes. Btw, did this series get through to anyone? I didn't recieve it back from the list and the archives don't seem to have it either.. Index: linux-2.6-xfs/fs/xfs/xfs_log.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_log.c 2007-09-21 10:51:01.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_log.c 2007-09-21 10:53:41.000000000 +0200 @@ -1227,12 +1227,12 @@ xlog_alloc_log(xfs_mount_t *mp, head = &iclog->ic_header; memset(head, 0, sizeof(xlog_rec_header_t)); - INT_SET(head->h_magicno, ARCH_CONVERT, XLOG_HEADER_MAGIC_NUM); - INT_SET(head->h_version, ARCH_CONVERT, + head->h_magicno = cpu_to_be32(XLOG_HEADER_MAGIC_NUM); + head->h_version = cpu_to_be32( XFS_SB_VERSION_HASLOGV2(&log->l_mp->m_sb) ? 2 : 1); - INT_SET(head->h_size, ARCH_CONVERT, log->l_iclog_size); + head->h_size = cpu_to_be32(log->l_iclog_size); /* new fields */ - INT_SET(head->h_fmt, ARCH_CONVERT, XLOG_FMT); + head->h_fmt = cpu_to_be32(XLOG_FMT); memcpy(&head->h_fs_uuid, &mp->m_sb.sb_uuid, sizeof(uuid_t)); @@ -1378,7 +1378,7 @@ xlog_sync(xlog_t *log, { xfs_caddr_t dptr; /* pointer to byte sized element */ xfs_buf_t *bp; - int i, ops; + int i; uint count; /* byte count of bwrite */ uint count_init; /* initial count before roundup */ int roundoff; /* roundoff to BB or stripe */ @@ -1417,21 +1417,17 @@ xlog_sync(xlog_t *log, /* real byte length */ if (v2) { - INT_SET(iclog->ic_header.h_len, - ARCH_CONVERT, - iclog->ic_offset + roundoff); + iclog->ic_header.h_len = + cpu_to_be32(iclog->ic_offset + roundoff); } else { - INT_SET(iclog->ic_header.h_len, ARCH_CONVERT, iclog->ic_offset); + iclog->ic_header.h_len = + cpu_to_be32(iclog->ic_offset); } - /* put ops count in correct order */ - ops = iclog->ic_header.h_num_logops; - INT_SET(iclog->ic_header.h_num_logops, ARCH_CONVERT, ops); - bp = iclog->ic_bp; ASSERT(XFS_BUF_FSPRIVATE2(bp, unsigned long) == (unsigned long)1); XFS_BUF_SET_FSPRIVATE2(bp, (unsigned long)2); - XFS_BUF_SET_ADDR(bp, BLOCK_LSN(INT_GET(iclog->ic_header.h_lsn, ARCH_CONVERT))); + XFS_BUF_SET_ADDR(bp, BLOCK_LSN(be64_to_cpu(iclog->ic_header.h_lsn))); XFS_STATS_ADD(xs_log_blocks, BTOBB(count)); @@ -1494,10 +1490,10 @@ xlog_sync(xlog_t *log, * a new cycle. Watch out for the header magic number * case, though. */ - for (i=0; il_icloglock); - iclog->ic_header.h_num_logops += record_cnt; + be32_add(&iclog->ic_header.h_num_logops, record_cnt); iclog->ic_offset += copy_bytes; spin_unlock(&log->l_icloglock); @@ -1813,7 +1809,7 @@ xlog_write(xfs_mount_t * mp, /* start_lsn is the first lsn written to. That's all we need. */ if (! *start_lsn) - *start_lsn = INT_GET(iclog->ic_header.h_lsn, ARCH_CONVERT); + *start_lsn = be64_to_cpu(iclog->ic_header.h_lsn); /* This loop writes out as many regions as can fit in the amount * of space which was allocated by xlog_state_get_iclog_space(). @@ -1983,7 +1979,8 @@ xlog_state_clean_log(xlog_t *log) * We don't need to cover the dummy. */ if (!changed && - (INT_GET(iclog->ic_header.h_num_logops, ARCH_CONVERT) == XLOG_COVER_OPS)) { + (be32_to_cpu(iclog->ic_header.h_num_logops) == + XLOG_COVER_OPS)) { changed = 1; } else { /* @@ -2051,7 +2048,7 @@ xlog_get_lowest_lsn( lowest_lsn = 0; do { if (!(lsn_log->ic_state & (XLOG_STATE_ACTIVE|XLOG_STATE_DIRTY))) { - lsn = INT_GET(lsn_log->ic_header.h_lsn, ARCH_CONVERT); + lsn = be64_to_cpu(lsn_log->ic_header.h_lsn); if ((lsn && !lowest_lsn) || (XFS_LSN_CMP(lsn, lowest_lsn) < 0)) { lowest_lsn = lsn; @@ -2152,11 +2149,9 @@ xlog_state_do_callback( */ lowest_lsn = xlog_get_lowest_lsn(log); - if (lowest_lsn && ( - XFS_LSN_CMP( - lowest_lsn, - INT_GET(iclog->ic_header.h_lsn, ARCH_CONVERT) - )<0)) { + if (lowest_lsn && + XFS_LSN_CMP(lowest_lsn, + be64_to_cpu(iclog->ic_header.h_lsn)) < 0) { iclog = iclog->ic_next; continue; /* Leave this iclog for * another thread */ @@ -2171,11 +2166,10 @@ xlog_state_do_callback( * No one else can be here except us. */ spin_lock(&log->l_grant_lock); - ASSERT(XFS_LSN_CMP( - log->l_last_sync_lsn, - INT_GET(iclog->ic_header.h_lsn, ARCH_CONVERT) - )<=0); - log->l_last_sync_lsn = INT_GET(iclog->ic_header.h_lsn, ARCH_CONVERT); + ASSERT(XFS_LSN_CMP(log->l_last_sync_lsn, + be64_to_cpu(iclog->ic_header.h_lsn)) <= 0); + log->l_last_sync_lsn = + be64_to_cpu(iclog->ic_header.h_lsn); spin_unlock(&log->l_grant_lock); /* @@ -2392,8 +2386,8 @@ restart: xlog_tic_add_region(ticket, log->l_iclog_hsize, XLOG_REG_TYPE_LRHEADER); - INT_SET(head->h_cycle, ARCH_CONVERT, log->l_curr_cycle); - INT_SET(head->h_lsn, ARCH_CONVERT, + head->h_cycle = cpu_to_be32(log->l_curr_cycle); + head->h_lsn = cpu_to_be64( xlog_assign_lsn(log->l_curr_cycle, log->l_curr_block)); ASSERT(log->l_curr_block >= 0); } @@ -2823,7 +2817,7 @@ xlog_state_release_iclog(xlog_t *log, iclog->ic_state == XLOG_STATE_WANT_SYNC) { sync++; iclog->ic_state = XLOG_STATE_SYNCING; - INT_SET(iclog->ic_header.h_tail_lsn, ARCH_CONVERT, log->l_tail_lsn); + iclog->ic_header.h_tail_lsn = cpu_to_be64(log->l_tail_lsn); xlog_verify_tail_lsn(log, iclog, log->l_tail_lsn); /* cycle incremented when incrementing curr_block */ } @@ -2861,7 +2855,7 @@ xlog_state_switch_iclogs(xlog_t *log, if (!eventual_size) eventual_size = iclog->ic_offset; iclog->ic_state = XLOG_STATE_WANT_SYNC; - INT_SET(iclog->ic_header.h_prev_block, ARCH_CONVERT, log->l_prev_block); + iclog->ic_header.h_prev_block = cpu_to_be32(log->l_prev_block); log->l_prev_block = log->l_curr_block; log->l_prev_cycle = log->l_curr_cycle; @@ -2957,7 +2951,7 @@ xlog_state_sync_all(xlog_t *log, uint fl * the previous sync. */ iclog->ic_refcnt++; - lsn = INT_GET(iclog->ic_header.h_lsn, ARCH_CONVERT); + lsn = be64_to_cpu(iclog->ic_header.h_lsn); xlog_state_switch_iclogs(log, iclog, 0); spin_unlock(&log->l_icloglock); @@ -2965,7 +2959,7 @@ xlog_state_sync_all(xlog_t *log, uint fl return XFS_ERROR(EIO); *log_flushed = 1; spin_lock(&log->l_icloglock); - if (INT_GET(iclog->ic_header.h_lsn, ARCH_CONVERT) == lsn && + if (be64_to_cpu(iclog->ic_header.h_lsn) == lsn && iclog->ic_state != XLOG_STATE_DIRTY) goto maybe_sleep; else @@ -3049,9 +3043,9 @@ try_again: } do { - if (INT_GET(iclog->ic_header.h_lsn, ARCH_CONVERT) != lsn) { - iclog = iclog->ic_next; - continue; + if (be64_to_cpu(iclog->ic_header.h_lsn) != lsn) { + iclog = iclog->ic_next; + continue; } if (iclog->ic_state == XLOG_STATE_DIRTY) { @@ -3460,18 +3454,18 @@ xlog_verify_iclog(xlog_t *log, spin_unlock(&log->l_icloglock); /* check log magic numbers */ - ptr = (xfs_caddr_t) &(iclog->ic_header); - if (INT_GET(*(uint *)ptr, ARCH_CONVERT) != XLOG_HEADER_MAGIC_NUM) + if (be32_to_cpu(iclog->ic_header.h_magicno) != XLOG_HEADER_MAGIC_NUM) xlog_panic("xlog_verify_iclog: invalid magic num"); - for (ptr += BBSIZE; ptr < ((xfs_caddr_t)&(iclog->ic_header))+count; + ptr = (xfs_caddr_t) &iclog->ic_header; + for (ptr += BBSIZE; ptr < ((xfs_caddr_t)&iclog->ic_header) + count; ptr += BBSIZE) { - if (INT_GET(*(uint *)ptr, ARCH_CONVERT) == XLOG_HEADER_MAGIC_NUM) + if (be32_to_cpu(*(__be32 *)ptr) == XLOG_HEADER_MAGIC_NUM) xlog_panic("xlog_verify_iclog: unexpected magic num"); } /* check fields */ - len = INT_GET(iclog->ic_header.h_num_logops, ARCH_CONVERT); + len = be32_to_cpu(iclog->ic_header.h_num_logops); ptr = iclog->ic_datap; base_ptr = ptr; ophead = (xlog_op_header_t *)ptr; @@ -3512,9 +3506,9 @@ xlog_verify_iclog(xlog_t *log, if (idx >= (XLOG_HEADER_CYCLE_SIZE / BBSIZE)) { j = idx / (XLOG_HEADER_CYCLE_SIZE / BBSIZE); k = idx % (XLOG_HEADER_CYCLE_SIZE / BBSIZE); - op_len = INT_GET(xhdr[j].hic_xheader.xh_cycle_data[k], ARCH_CONVERT); + op_len = be32_to_cpu(xhdr[j].hic_xheader.xh_cycle_data[k]); } else { - op_len = INT_GET(iclog->ic_header.h_cycle_data[idx], ARCH_CONVERT); + op_len = be32_to_cpu(iclog->ic_header.h_cycle_data[idx]); } } ptr += sizeof(xlog_op_header_t) + op_len; Index: linux-2.6-xfs/fs/xfs/xfs_log_priv.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_log_priv.h 2007-09-21 10:51:01.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_log_priv.h 2007-09-21 10:51:04.000000000 +0200 @@ -63,10 +63,10 @@ static inline xfs_lsn_t xlog_assign_lsn( static inline uint xlog_get_cycle(char *ptr) { - if (INT_GET(*(uint *)ptr, ARCH_CONVERT) == XLOG_HEADER_MAGIC_NUM) - return INT_GET(*((uint *)ptr + 1), ARCH_CONVERT); + if (be32_to_cpu(*(__be32 *)ptr) == XLOG_HEADER_MAGIC_NUM) + return be32_to_cpu(*((__be32 *)ptr + 1)); else - return INT_GET(*(uint *)ptr, ARCH_CONVERT); + return be32_to_cpu(*(__be32 *)ptr); } #define BLK_AVG(blk1, blk2) ((blk1+blk2) >> 1) @@ -85,9 +85,9 @@ static inline uint xlog_get_cycle(char * * * this has endian issues, of course. */ -static inline uint xlog_get_client_id(uint i) +static inline uint xlog_get_client_id(__be32 i) { - return INT_GET(i, ARCH_CONVERT) >> 24; + return be32_to_cpu(i) >> 24; } #define xlog_panic(args...) cmn_err(CE_PANIC, ## args) @@ -287,25 +287,25 @@ typedef struct xlog_op_header { #endif typedef struct xlog_rec_header { - uint h_magicno; /* log record (LR) identifier : 4 */ - uint h_cycle; /* write cycle of log : 4 */ - int h_version; /* LR version : 4 */ - int h_len; /* len in bytes; should be 64-bit aligned: 4 */ - xfs_lsn_t h_lsn; /* lsn of this LR : 8 */ - xfs_lsn_t h_tail_lsn; /* lsn of 1st LR w/ buffers not committed: 8 */ - uint h_chksum; /* may not be used; non-zero if used : 4 */ - int h_prev_block; /* block number to previous LR : 4 */ - int h_num_logops; /* number of log operations in this LR : 4 */ - uint h_cycle_data[XLOG_HEADER_CYCLE_SIZE / BBSIZE]; + __be32 h_magicno; /* log record (LR) identifier : 4 */ + __be32 h_cycle; /* write cycle of log : 4 */ + __be32 h_version; /* LR version : 4 */ + __be32 h_len; /* len in bytes; should be 64-bit aligned: 4 */ + __be64 h_lsn; /* lsn of this LR : 8 */ + __be64 h_tail_lsn; /* lsn of 1st LR w/ buffers not committed: 8 */ + __be32 h_chksum; /* may not be used; non-zero if used : 4 */ + __be32 h_prev_block; /* block number to previous LR : 4 */ + __be32 h_num_logops; /* number of log operations in this LR : 4 */ + __be32 h_cycle_data[XLOG_HEADER_CYCLE_SIZE / BBSIZE]; /* new fields */ - int h_fmt; /* format of log record : 4 */ - uuid_t h_fs_uuid; /* uuid of FS : 16 */ - int h_size; /* iclog size : 4 */ + __be32 h_fmt; /* format of log record : 4 */ + uuid_t h_fs_uuid; /* uuid of FS : 16 */ + __be32 h_size; /* iclog size : 4 */ } xlog_rec_header_t; typedef struct xlog_rec_ext_header { - uint xh_cycle; /* write cycle of log : 4 */ - uint xh_cycle_data[XLOG_HEADER_CYCLE_SIZE / BBSIZE]; /* : 256 */ + __be32 xh_cycle; /* write cycle of log : 4 */ + __be32 xh_cycle_data[XLOG_HEADER_CYCLE_SIZE / BBSIZE]; /* : 256 */ } xlog_rec_ext_header_t; #ifdef __KERNEL__ Index: linux-2.6-xfs/fs/xfs/xfs_log_recover.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_log_recover.c 2007-09-21 10:51:01.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_log_recover.c 2007-09-21 10:51:04.000000000 +0200 @@ -198,7 +198,7 @@ xlog_header_check_dump( cmn_err(CE_DEBUG, " log : uuid = "); for (b = 0; b < 16; b++) cmn_err(CE_DEBUG, "%02x",((uchar_t *)&head->h_fs_uuid)[b]); - cmn_err(CE_DEBUG, ", fmt = %d\n", INT_GET(head->h_fmt, ARCH_CONVERT)); + cmn_err(CE_DEBUG, ", fmt = %d\n", be32_to_cpu(head->h_fmt)); } #else #define xlog_header_check_dump(mp, head) @@ -212,14 +212,14 @@ xlog_header_check_recover( xfs_mount_t *mp, xlog_rec_header_t *head) { - ASSERT(INT_GET(head->h_magicno, ARCH_CONVERT) == XLOG_HEADER_MAGIC_NUM); + ASSERT(be32_to_cpu(head->h_magicno) == XLOG_HEADER_MAGIC_NUM); /* * IRIX doesn't write the h_fmt field and leaves it zeroed * (XLOG_FMT_UNKNOWN). This stops us from trying to recover * a dirty log created in IRIX. */ - if (unlikely(INT_GET(head->h_fmt, ARCH_CONVERT) != XLOG_FMT)) { + if (unlikely(be32_to_cpu(head->h_fmt) != XLOG_FMT)) { xlog_warn( "XFS: dirty log written in incompatible format - can't recover"); xlog_header_check_dump(mp, head); @@ -245,7 +245,7 @@ xlog_header_check_mount( xfs_mount_t *mp, xlog_rec_header_t *head) { - ASSERT(INT_GET(head->h_magicno, ARCH_CONVERT) == XLOG_HEADER_MAGIC_NUM); + ASSERT(be32_to_cpu(head->h_magicno) == XLOG_HEADER_MAGIC_NUM); if (uuid_is_nil(&head->h_fs_uuid)) { /* @@ -447,8 +447,7 @@ xlog_find_verify_log_record( head = (xlog_rec_header_t *)offset; - if (XLOG_HEADER_MAGIC_NUM == - INT_GET(head->h_magicno, ARCH_CONVERT)) + if (XLOG_HEADER_MAGIC_NUM == be32_to_cpu(head->h_magicno)) break; if (!smallmem) @@ -480,7 +479,7 @@ xlog_find_verify_log_record( * record do we update last_blk. */ if (XFS_SB_VERSION_HASLOGV2(&log->l_mp->m_sb)) { - uint h_size = INT_GET(head->h_size, ARCH_CONVERT); + uint h_size = be32_to_cpu(head->h_size); xhdrs = h_size / XLOG_HEADER_CYCLE_SIZE; if (h_size % XLOG_HEADER_CYCLE_SIZE) @@ -489,8 +488,8 @@ xlog_find_verify_log_record( xhdrs = 1; } - if (*last_blk - i + extra_bblks - != BTOBB(INT_GET(head->h_len, ARCH_CONVERT)) + xhdrs) + if (*last_blk - i + extra_bblks != + BTOBB(be32_to_cpu(head->h_len)) + xhdrs) *last_blk = i; out: @@ -823,8 +822,7 @@ xlog_find_tail( if ((error = xlog_bread(log, i, 1, bp))) goto bread_err; offset = xlog_align(log, i, 1, bp); - if (XLOG_HEADER_MAGIC_NUM == - INT_GET(*(uint *)offset, ARCH_CONVERT)) { + if (XLOG_HEADER_MAGIC_NUM == be32_to_cpu(*(__be32 *)offset)) { found = 1; break; } @@ -841,7 +839,7 @@ xlog_find_tail( goto bread_err; offset = xlog_align(log, i, 1, bp); if (XLOG_HEADER_MAGIC_NUM == - INT_GET(*(uint*)offset, ARCH_CONVERT)) { + be32_to_cpu(*(__be32 *)offset)) { found = 2; break; } @@ -855,7 +853,7 @@ xlog_find_tail( /* find blk_no of tail of log */ rhead = (xlog_rec_header_t *)offset; - *tail_blk = BLOCK_LSN(INT_GET(rhead->h_tail_lsn, ARCH_CONVERT)); + *tail_blk = BLOCK_LSN(be64_to_cpu(rhead->h_tail_lsn)); /* * Reset log values according to the state of the log when we @@ -869,11 +867,11 @@ xlog_find_tail( */ log->l_prev_block = i; log->l_curr_block = (int)*head_blk; - log->l_curr_cycle = INT_GET(rhead->h_cycle, ARCH_CONVERT); + log->l_curr_cycle = be32_to_cpu(rhead->h_cycle); if (found == 2) log->l_curr_cycle++; - log->l_tail_lsn = INT_GET(rhead->h_tail_lsn, ARCH_CONVERT); - log->l_last_sync_lsn = INT_GET(rhead->h_lsn, ARCH_CONVERT); + log->l_tail_lsn = be64_to_cpu(rhead->h_tail_lsn); + log->l_last_sync_lsn = be64_to_cpu(rhead->h_lsn); log->l_grant_reserve_cycle = log->l_curr_cycle; log->l_grant_reserve_bytes = BBTOB(log->l_curr_block); log->l_grant_write_cycle = log->l_curr_cycle; @@ -891,8 +889,8 @@ xlog_find_tail( * unmount record rather than the block after it. */ if (XFS_SB_VERSION_HASLOGV2(&log->l_mp->m_sb)) { - int h_size = INT_GET(rhead->h_size, ARCH_CONVERT); - int h_version = INT_GET(rhead->h_version, ARCH_CONVERT); + int h_size = be32_to_cpu(rhead->h_size); + int h_version = be32_to_cpu(rhead->h_version); if ((h_version & XLOG_VERSION_2) && (h_size > XLOG_HEADER_CYCLE_SIZE)) { @@ -906,10 +904,10 @@ xlog_find_tail( hblks = 1; } after_umount_blk = (i + hblks + (int) - BTOBB(INT_GET(rhead->h_len, ARCH_CONVERT))) % log->l_logBBsize; + BTOBB(be32_to_cpu(rhead->h_len))) % log->l_logBBsize; tail_lsn = log->l_tail_lsn; if (*head_blk == after_umount_blk && - INT_GET(rhead->h_num_logops, ARCH_CONVERT) == 1) { + be32_to_cpu(rhead->h_num_logops) == 1) { umount_data_blk = (i + hblks) % log->l_logBBsize; if ((error = xlog_bread(log, umount_data_blk, 1, bp))) { goto bread_err; @@ -1100,14 +1098,13 @@ xlog_add_record( xlog_rec_header_t *recp = (xlog_rec_header_t *)buf; memset(buf, 0, BBSIZE); - INT_SET(recp->h_magicno, ARCH_CONVERT, XLOG_HEADER_MAGIC_NUM); - INT_SET(recp->h_cycle, ARCH_CONVERT, cycle); - INT_SET(recp->h_version, ARCH_CONVERT, + recp->h_magicno = cpu_to_be32(XLOG_HEADER_MAGIC_NUM); + recp->h_cycle = cpu_to_be32(cycle); + recp->h_version = cpu_to_be32( XFS_SB_VERSION_HASLOGV2(&log->l_mp->m_sb) ? 2 : 1); - INT_SET(recp->h_lsn, ARCH_CONVERT, xlog_assign_lsn(cycle, block)); - INT_SET(recp->h_tail_lsn, ARCH_CONVERT, - xlog_assign_lsn(tail_cycle, tail_block)); - INT_SET(recp->h_fmt, ARCH_CONVERT, XLOG_FMT); + recp->h_lsn = cpu_to_be64(xlog_assign_lsn(cycle, block)); + recp->h_tail_lsn = cpu_to_be64(xlog_assign_lsn(tail_cycle, tail_block)); + recp->h_fmt = cpu_to_be32(XLOG_FMT); memcpy(&recp->h_fs_uuid, &log->l_mp->m_sb.sb_uuid, sizeof(uuid_t)); } @@ -2259,7 +2256,7 @@ xlog_recover_do_buffer_trans( * overlap with future reads of those inodes. */ if (XFS_DINODE_MAGIC == - INT_GET(*((__uint16_t *)(xfs_buf_offset(bp, 0))), ARCH_CONVERT) && + be16_to_cpu(*((__be16 *)xfs_buf_offset(bp, 0))) && (XFS_BUF_COUNT(bp) != MAX(log->l_mp->m_sb.sb_blocksize, (__uint32_t)XFS_INODE_CLUSTER_SIZE(log->l_mp)))) { XFS_BUF_STALE(bp); @@ -2629,8 +2626,7 @@ xlog_recover_do_dquot_trans( /* * This type of quotas was turned off, so ignore this record. */ - type = INT_GET(recddq->d_flags, ARCH_CONVERT) & - (XFS_DQ_USER | XFS_DQ_PROJ | XFS_DQ_GROUP); + type = recddq->d_flags & (XFS_DQ_USER | XFS_DQ_PROJ | XFS_DQ_GROUP); ASSERT(type); if (log->l_quotaoffs_flag & type) return (0); @@ -2943,8 +2939,8 @@ xlog_recover_process_data( unsigned long hash; uint flags; - lp = dp + INT_GET(rhead->h_len, ARCH_CONVERT); - num_logops = INT_GET(rhead->h_num_logops, ARCH_CONVERT); + lp = dp + be32_to_cpu(rhead->h_len); + num_logops = be32_to_cpu(rhead->h_num_logops); /* check the log format matches our own - else we can't recover */ if (xlog_header_check_recover(log->l_mp, rhead)) @@ -2967,7 +2963,7 @@ xlog_recover_process_data( if (trans == NULL) { /* not found; add new tid */ if (ohead->oh_flags & XLOG_START_TRANS) xlog_recover_new_tid(&rhash[hash], tid, - INT_GET(rhead->h_lsn, ARCH_CONVERT)); + be64_to_cpu(rhead->h_lsn)); } else { ASSERT(dp + be32_to_cpu(ohead->oh_len) <= lp); flags = ohead->oh_flags & ~XLOG_END_TRANS; @@ -3358,16 +3354,16 @@ xlog_pack_data_checksum( int size) { int i; - uint *up; + __be32 *up; uint chksum = 0; - up = (uint *)iclog->ic_datap; + up = (__be32 *)iclog->ic_datap; /* divide length by 4 to get # words */ for (i = 0; i < (size >> 2); i++) { - chksum ^= INT_GET(*up, ARCH_CONVERT); + chksum ^= be32_to_cpu(*up); up++; } - INT_SET(iclog->ic_header.h_chksum, ARCH_CONVERT, chksum); + iclog->ic_header.h_chksum = cpu_to_be32(chksum); } #else #define xlog_pack_data_checksum(log, iclog, size) @@ -3384,7 +3380,7 @@ xlog_pack_data( { int i, j, k; int size = iclog->ic_offset + roundoff; - uint cycle_lsn; + __be32 cycle_lsn; xfs_caddr_t dp; xlog_in_core_2_t *xhdr; @@ -3395,8 +3391,8 @@ xlog_pack_data( dp = iclog->ic_datap; for (i = 0; i < BTOBB(size) && i < (XLOG_HEADER_CYCLE_SIZE / BBSIZE); i++) { - iclog->ic_header.h_cycle_data[i] = *(uint *)dp; - *(uint *)dp = cycle_lsn; + iclog->ic_header.h_cycle_data[i] = *(__be32 *)dp; + *(__be32 *)dp = cycle_lsn; dp += BBSIZE; } @@ -3405,8 +3401,8 @@ xlog_pack_data( for ( ; i < BTOBB(size); i++) { j = i / (XLOG_HEADER_CYCLE_SIZE / BBSIZE); k = i % (XLOG_HEADER_CYCLE_SIZE / BBSIZE); - xhdr[j].hic_xheader.xh_cycle_data[k] = *(uint *)dp; - *(uint *)dp = cycle_lsn; + xhdr[j].hic_xheader.xh_cycle_data[k] = *(__be32 *)dp; + *(__be32 *)dp = cycle_lsn; dp += BBSIZE; } @@ -3423,21 +3419,21 @@ xlog_unpack_data_checksum( xfs_caddr_t dp, xlog_t *log) { - uint *up = (uint *)dp; + __be32 *up = (__be32 *)dp; uint chksum = 0; int i; /* divide length by 4 to get # words */ - for (i=0; i < INT_GET(rhead->h_len, ARCH_CONVERT) >> 2; i++) { - chksum ^= INT_GET(*up, ARCH_CONVERT); + for (i=0; i < be32_to_cpu(rhead->h_len) >> 2; i++) { + chksum ^= be32_to_cpu(*up); up++; } - if (chksum != INT_GET(rhead->h_chksum, ARCH_CONVERT)) { + if (chksum != be32_to_cpu(rhead->h_chksum)) { if (rhead->h_chksum || ((log->l_flags & XLOG_CHKSUM_MISMATCH) == 0)) { cmn_err(CE_DEBUG, "XFS: LogR chksum mismatch: was (0x%x) is (0x%x)\n", - INT_GET(rhead->h_chksum, ARCH_CONVERT), chksum); + be32_to_cpu(rhead->h_chksum), chksum); cmn_err(CE_DEBUG, "XFS: Disregard message if filesystem was created with non-DEBUG kernel"); if (XFS_SB_VERSION_HASLOGV2(&log->l_mp->m_sb)) { @@ -3461,18 +3457,18 @@ xlog_unpack_data( int i, j, k; xlog_in_core_2_t *xhdr; - for (i = 0; i < BTOBB(INT_GET(rhead->h_len, ARCH_CONVERT)) && + for (i = 0; i < BTOBB(be32_to_cpu(rhead->h_len)) && i < (XLOG_HEADER_CYCLE_SIZE / BBSIZE); i++) { - *(uint *)dp = *(uint *)&rhead->h_cycle_data[i]; + *(__be32 *)dp = *(__be32 *)&rhead->h_cycle_data[i]; dp += BBSIZE; } if (XFS_SB_VERSION_HASLOGV2(&log->l_mp->m_sb)) { xhdr = (xlog_in_core_2_t *)rhead; - for ( ; i < BTOBB(INT_GET(rhead->h_len, ARCH_CONVERT)); i++) { + for ( ; i < BTOBB(be32_to_cpu(rhead->h_len)); i++) { j = i / (XLOG_HEADER_CYCLE_SIZE / BBSIZE); k = i % (XLOG_HEADER_CYCLE_SIZE / BBSIZE); - *(uint *)dp = xhdr[j].hic_xheader.xh_cycle_data[k]; + *(__be32 *)dp = xhdr[j].hic_xheader.xh_cycle_data[k]; dp += BBSIZE; } } @@ -3488,24 +3484,21 @@ xlog_valid_rec_header( { int hlen; - if (unlikely( - (INT_GET(rhead->h_magicno, ARCH_CONVERT) != - XLOG_HEADER_MAGIC_NUM))) { + if (unlikely(be32_to_cpu(rhead->h_magicno) != XLOG_HEADER_MAGIC_NUM)) { XFS_ERROR_REPORT("xlog_valid_rec_header(1)", XFS_ERRLEVEL_LOW, log->l_mp); return XFS_ERROR(EFSCORRUPTED); } if (unlikely( (!rhead->h_version || - (INT_GET(rhead->h_version, ARCH_CONVERT) & - (~XLOG_VERSION_OKBITS)) != 0))) { + (be32_to_cpu(rhead->h_version) & (~XLOG_VERSION_OKBITS))))) { xlog_warn("XFS: %s: unrecognised log version (%d).", - __FUNCTION__, INT_GET(rhead->h_version, ARCH_CONVERT)); + __FUNCTION__, be32_to_cpu(rhead->h_version)); return XFS_ERROR(EIO); } /* LR body must have data or it wouldn't have been written */ - hlen = INT_GET(rhead->h_len, ARCH_CONVERT); + hlen = be32_to_cpu(rhead->h_len); if (unlikely( hlen <= 0 || hlen > INT_MAX )) { XFS_ERROR_REPORT("xlog_valid_rec_header(2)", XFS_ERRLEVEL_LOW, log->l_mp); @@ -3565,9 +3558,8 @@ xlog_do_recovery_pass( error = xlog_valid_rec_header(log, rhead, tail_blk); if (error) goto bread_err1; - h_size = INT_GET(rhead->h_size, ARCH_CONVERT); - if ((INT_GET(rhead->h_version, ARCH_CONVERT) - & XLOG_VERSION_2) && + h_size = be32_to_cpu(rhead->h_size); + if ((be32_to_cpu(rhead->h_version) & XLOG_VERSION_2) && (h_size > XLOG_HEADER_CYCLE_SIZE)) { hblks = h_size / XLOG_HEADER_CYCLE_SIZE; if (h_size % XLOG_HEADER_CYCLE_SIZE) @@ -3604,7 +3596,7 @@ xlog_do_recovery_pass( goto bread_err2; /* blocks in data section */ - bblks = (int)BTOBB(INT_GET(rhead->h_len, ARCH_CONVERT)); + bblks = (int)BTOBB(be32_to_cpu(rhead->h_len)); error = xlog_bread(log, blk_no + hblks, bblks, dbp); if (error) goto bread_err2; @@ -3679,7 +3671,7 @@ xlog_do_recovery_pass( if (error) goto bread_err2; - bblks = (int)BTOBB(INT_GET(rhead->h_len, ARCH_CONVERT)); + bblks = (int)BTOBB(be32_to_cpu(rhead->h_len)); blk_no += hblks; /* Read in data for log record */ @@ -3750,7 +3742,7 @@ xlog_do_recovery_pass( error = xlog_valid_rec_header(log, rhead, blk_no); if (error) goto bread_err2; - bblks = (int)BTOBB(INT_GET(rhead->h_len, ARCH_CONVERT)); + bblks = (int)BTOBB(be32_to_cpu(rhead->h_len)); if ((error = xlog_bread(log, blk_no+hblks, bblks, dbp))) goto bread_err2; offset = xlog_align(log, blk_no+hblks, bblks, dbp); Index: linux-2.6-xfs/fs/xfs/xfsidbg.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfsidbg.c 2007-09-21 10:50:53.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfsidbg.c 2007-09-21 10:51:04.000000000 +0200 @@ -5739,17 +5739,21 @@ xfsidbg_xiclog(xlog_in_core_t *iclog) kdb_printf("xlog_in_core/header at 0x%p/0x%p\n", iclog, iclog->hic_data); kdb_printf("magicno: %x cycle: %d version: %d lsn: 0x%Lx\n", - INT_GET(iclog->ic_header.h_magicno, ARCH_CONVERT), INT_GET(iclog->ic_header.h_cycle, ARCH_CONVERT), - INT_GET(iclog->ic_header.h_version, ARCH_CONVERT), INT_GET(iclog->ic_header.h_lsn, ARCH_CONVERT)); + be32_to_cpu(iclog->ic_header.h_magicno), + be32_to_cpu(iclog->ic_header.h_cycle), + be32_to_cpu(iclog->ic_header.h_version), + be64_to_cpu(iclog->ic_header.h_lsn)); kdb_printf("tail_lsn: 0x%Lx len: %d prev_block: %d num_ops: %d\n", - INT_GET(iclog->ic_header.h_tail_lsn, ARCH_CONVERT), INT_GET(iclog->ic_header.h_len, ARCH_CONVERT), - INT_GET(iclog->ic_header.h_prev_block, ARCH_CONVERT), INT_GET(iclog->ic_header.h_num_logops, ARCH_CONVERT)); + be64_to_cpu(iclog->ic_header.h_tail_lsn), + be32_to_cpu(iclog->ic_header.h_len), + be32_to_cpu(iclog->ic_header.h_prev_block), + be32_to_cpu(iclog->ic_header.h_num_logops)); kdb_printf("cycle_data: "); for (i=0; i<(iclog->ic_size>>BBSHIFT); i++) { - kdb_printf("%x ", INT_GET(iclog->ic_header.h_cycle_data[i], ARCH_CONVERT)); + kdb_printf("%x ", be32_to_cpu(iclog->ic_header.h_cycle_data[i])); } kdb_printf("\n"); - kdb_printf("size: %d\n", INT_GET(iclog->ic_header.h_size, ARCH_CONVERT)); + kdb_printf("size: %d\n", be32_to_cpu(iclog->ic_header.h_size)); kdb_printf("\n"); kdb_printf("--------------------------------------------------\n"); kdb_printf("data: 0x%p &forcesema: 0x%p next: 0x%p bp: 0x%p\n", Index: linux-2.6-xfs/fs/xfs/xfs_log.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_log.h 2007-09-20 16:33:35.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_log.h 2007-09-21 10:51:04.000000000 +0200 @@ -22,8 +22,9 @@ #define CYCLE_LSN(lsn) ((uint)((lsn)>>32)) #define BLOCK_LSN(lsn) ((uint)(lsn)) + /* this is used in a spot where we might otherwise double-endian-flip */ -#define CYCLE_LSN_DISK(lsn) (((uint *)&(lsn))[0]) +#define CYCLE_LSN_DISK(lsn) (((__be32 *)&(lsn))[0]) #ifdef __KERNEL__ /* From owner-xfs@oss.sgi.com Fri Sep 21 15:31:52 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 21 Sep 2007 15:31: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.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from slurp.thebarn.com (cattelan-host202.dsl.visi.com [208.42.117.202]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8LMVoQ3032486 for ; Fri, 21 Sep 2007 15:31:51 -0700 Received: from [IPv6:::1] (slurp.thebarn.com [208.42.117.201]) (authenticated bits=0) by slurp.thebarn.com (8.14.0/8.13.8) with ESMTP id l8LL48G1016461; Fri, 21 Sep 2007 16:04:09 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <46F431C8.5010309@thebarn.com> Date: Fri, 21 Sep 2007 16:04:08 -0500 From: Russell Cattelan User-Agent: Thunderbird 2.0.0.5 (X11/20070813) MIME-Version: 1.0 To: Eric Sandeen CC: Christoph Hellwig , 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> <46E8A848.8010601@sandeen.net> In-Reply-To: <46E8A848.8010601@sandeen.net> Content-Type: multipart/mixed; boundary="------------050308060602040202040303" X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Scanned: ClamAV 0.91.1/4357/Fri Sep 21 04:55:46 2007 on slurp.thebarn.com X-Virus-Status: Clean X-archive-position: 13032 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: xfs This is a multi-part message in MIME format. --------------050308060602040202040303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Eric Sandeen wrote: > 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..... > > So this is a bit late now but please please leave the names they are useful for tracking locks. especially in the freebsd witness code. > ====================== > > 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 > > /* > > > --------------050308060602040202040303 Content-Type: text/x-vcard; charset=utf-8; name="cattelan.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="cattelan.vcf" begin:vcard fn:Russell Cattelan n:Cattelan;Russell email;internet:cattelan@thebarn.com x-mozilla-html:FALSE version:2.1 end:vcard --------------050308060602040202040303-- From owner-xfs@oss.sgi.com Fri Sep 21 17:48:16 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 21 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.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.189]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8M0mDQ3028820 for ; Fri, 21 Sep 2007 17:48:15 -0700 Received: by fk-out-0910.google.com with SMTP id 18so859105fks for ; Fri, 21 Sep 2007 17:48:16 -0700 (PDT) Received: by 10.82.152.16 with SMTP id z16mr5609221bud.1190407781287; Fri, 21 Sep 2007 13:49:41 -0700 (PDT) Received: from ?192.168.0.7? ( [75.69.253.52]) by mx.google.com with ESMTPS id h39sm2613176wxd.2007.09.21.13.49.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 21 Sep 2007 13:49:38 -0700 (PDT) Subject: Re: Questions about testing the Filestream feature From: hxsrmeng Reply-To: hxsrmeng@gmail.com To: David Chinner Cc: XFS In-Reply-To: <20070921075459.GJ995458@sgi.com> References: <12809900.post@talk.nabble.com> <20070921075459.GJ995458@sgi.com> Content-Type: text/plain Organization: TT Date: Fri, 21 Sep 2007 16:45:55 -0400 Message-Id: <1190407555.5765.8.camel@OpenSUSE-desktop.Home> Mime-Version: 1.0 X-Mailer: Evolution 2.8.2 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13033 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hxsrmeng@gmail.com Precedence: bulk X-list: xfs Thank you so much. You really helped me a lot. Sorry that I had to learn something form the net and manuals first to understand what you said.:) My RAM is only 512M and the stream timeout is 3s.......That might be the problem.I will try this on a test box with bigger RAM and set the stream timeout to 30s. > It's up to the > user/application to prevent intra-stream allocation/fragmentation > problems (e.g. preallocation, extent size hints, large direct I/O, etc) > and that is what your test application is lacking. filestreams only > prevents inter-stream interleaving. I'll try to get more information about how to modify my script according to your suggestion.Thank you again! Have a nice weekend! Hxsrmeng On Fri, 2007-09-21 at 17:54 +1000, David Chinner wrote: > On Thu, Sep 20, 2007 at 08:10:31PM -0700, Hxsrmeng wrote: > > > > Hi all, > > > > I need to use the "Filestreams" feature. I wrote a script to write files to > > two directories concurrently. When I check the file bitmap, I found > > sometimes the files written in the different directories still interleave > > extents on disk. I don't know whether there is something wrong with my > > script, or, I misunderstand something. > > > > I am using Opensuse10.2, the kernel is linux-2.6.23-rc4 (source code was > > check out from cvs of oss.sgi.com). The filestreams feature is enabled with > > a "-o filestreams" mount option. > > Here is my script: > > > > Very similar to xfsqa tests 170-174. > > > Then I got the information of my xfs device first : > > meta-data=/dev/hda5 isize=256 agcount=8, agsize=159895 blks > > = sectsz=512 attr=0 > > data = bsize=4096 blocks=1279160,imaxpct=25 > > Ok, so an AG ~600MB in size, and your filesystem is about 5GB. > > > First run, I wrote 3 "big" files, which are 768M, to each directories. The > > files in directory dira share AG 0,2,5,7 and files in directory dirb share > > AG 1, 3, 4, 6, which I assume should be correct. > > Yes, and 3*3*768 = 4GB ~= 80% full. > > > But the files extents > > doesn't use contiguous blocks, > > filestreams doesn't guarantee contiguous extents - it guarantees sets of files > separated by directories don't intertwine. Within the each set you can see > non-contiguous allocation, but the sets should not interleave in the same > AGs... > > > and all files in the same directory put some > > of their extents in AG 0. > > AG 0 is the "filestreams failure" allocation group. What you are seeing is > that at some point you've filled your AG's up and a stream write couldn't find > an unused AG that matched the stream association criteria and it gave up. > > > I am not sure whether this is correct. Here is > > part of file bitmap: > > " > > dira/0: > > EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL > > 0: [0..7615]: 96..7711 0 (96..7711) 7616 > > 1: [7616..7679]: 33312..33375 0 (33312..33375) 64 > > 2: [7680..24063]: 33448..49831 0 (33448..49831) 16384 > > 3: [24064..52999]: 60608..89543 0 (60608..89543) 28936 > > 4: [53000..61191]: 95496..103687 0 (95496..103687) 8192 > > 5: [61192..90791]: 119088..148687 0 (119088..148687) 29600 > > 6: [90792..131751]: 170264..211223 0 (170264..211223) 40960 > > 7: [131752..144223]: 219480..231951 0 (219480..231951) 12472 > > 8: [144224..168799]: 240144..264719 0 (240144..264719) 24576 > > Ummm - that's a file stat started in AG 0.... > > > ... > > dira/1: > > EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL > > 0: [0..12791]: 7712..20503 0 (7712..20503) 12792 > > 1: [12792..12863]: 33376..33447 0 (33376..33447) 72 > > 2: [12864..13391]: 49832..50359 0 (49832..50359) 528 > > 3: [13392..19575]: 112904..119087 0 (112904..119087) 6184 > > 4: [19576..27767]: 148688..156879 0 (148688..156879) 8192 > > 5: [27768..35959]: 211224..219415 0 (211224..219415) 8192 > > 6: [35960..44151]: 231952..240143 0 (231952..240143) 8192 > > 7: [44152..68727]: 264784..289359 0 (264784..289359) 24576 > > 8: [68728..79047]: 309400..319719 0 (309400..319719) 10320 > > And so is that. Given that they are in the same directory, this is correct > behaviour. > > How much memory in your test box? I suspect that you're getting writeback > from kswapd, not pdflush as you are doing buffered I/O and you're getting > LRU order writeback rather than nice sequential writeback. It's up to the > user/application to prevent intra-stream allocation/fragmentation > problems (e.g. preallocation, extent size hints, large direct I/O, etc) > and that is what your test application is lacking. filestreams only > prevents inter-stream interleaving. > > Also, you are running close to filesystem full state. That is known to be > a no-no for deterministic performance from the filesystem, will cause > filesystem fragmentation, and is not the case that filestreams is > designed to optimise for. > > however, I agree that the code is not working optimally. In test 171, > there is this comment: > > # test large numbers of files, single I/O per file, 120s timeout > # Get close to filesystem full. > # 128 = ENOSPC > # 120 = 93.75% full, gets repeatable failures > # 112 = 87.5% full, should reliably succeed but doesn't *FIXME* > # 100 = 78.1% full, should reliably succeed > > The test uses a 1GB filesystem to intentionally stress the allocator, > and at 78.1% full, we are getting intermittent failures. On > some machines (like my test boxes) it passes >95% of the time. > On other machines, it passes maybe 5% of the time. So the low > space behaviour is known to be less than optimal, but at production > sites it is known that they can't use the last 10-15% of the filesystem > because of fragmentation issues associated with stripe alignment. > Hence low space behaviour of the allocator is not considered something > critical because there are other, worse problems at low space > that filestreams can't do anything to prevent. > > > Second run, I wrote 1024 "small" files, which are 1M, to each directories. > > Files in directory dira use AG 0,1,3 and files in directory b use AG > > 2,1,5,6,7,4. So files written in directory dirb use the allocation group 1, > > which should be reserved for directory dira . And, sometimes even one file > > is written to two AGs. The following is part of file bitmap: > > That's true only as long as a stream does not time out. An AG is > reserved only as long a the timeout since the last file in a > stream was created or allocated to. > > IOWs, if you use buffered I/O, the 30s writeback delay could time > your stream out between file creation and write() syscall and > when pdflush writes it back. Then you have no stream association > and you will get interleaving. Test 172 tests this behaviour, > and we get intermittent failures on that test because the buffered > I/O case occasionally succeeds rather than fails like it is supposed > to.... > > What's your stream timeout (/proc/sys/fs/xfs/filestream_centisecs) set to? > > Cheers, > > Dave. From owner-xfs@oss.sgi.com Fri Sep 21 21:39:27 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 21 Sep 2007 21:39: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.4 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 l8M4dPQ3010543 for ; Fri, 21 Sep 2007 21:39:27 -0700 Received: from liberator.sandeen.net (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 991C318003EF9 for ; Fri, 21 Sep 2007 23:39:28 -0500 (CDT) Message-ID: <46F49C80.60007@sandeen.net> Date: Fri, 21 Sep 2007 23:39:28 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: xfs-oss Subject: something very strange w/ filestreams... Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13034 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 if I do: for I in 173 174 178; do ./check $I; done it's not terribly interesting, things seem to go ok, just normal filestreams failures ;-) if I do: ./check 173 174 178 things go very badly; the very first repair in 178 finds a horribly corrupted filesystem, and repair tips over (memory appears corrupted, as witnessed by): > xfs_repair: zone calloc failed (, 572662388 bytes): Cannot allocate memory hm, no zone name, length of 0x22222274? I already provided a metadump image to Barry, but I wonder why the timing(?) seems to make a difference here... first sign of things going awry in repair is: Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... bad length 131072 for agf 0, should be 4096 bad length # 131072 for agi 0, should be 4096 would reset bad agf for ag 0 would reset bad agi for ag 0 .... not sure what's going on here, but it only seems to happen if I do those 2 filestreams test immediately before 178... oh, and this is over LVM, just for fun. -Eric From owner-xfs@oss.sgi.com Sat Sep 22 03:22:40 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 22 Sep 2007 03:22: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=-1.9 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 l8MAMaQ3013977 for ; Sat, 22 Sep 2007 03:22:39 -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 l8MAMcA5015755 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 22 Sep 2007 12:22:38 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8MAMcrK015753 for xfs@oss.sgi.com; Sat, 22 Sep 2007 12:22:38 +0200 Date: Sat, 22 Sep 2007 12:22:38 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: [PATCH] cleanup XFS_IFORK_*/XFS_DFORK* macros Message-ID: <20070922102238.GA15732@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-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13035 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 (try number three, maybe it manages to get through the list this time) Currently XFS_IFORK_* and XFS_DFORK* are implemented by means of XFS_CFORK* macros. But given that XFS_IFORK_* operates on an xfs_inode that embedds and xfs_icdinode_core and XFS_DFORK_* operates on an xfs_dinode that embedds a xfs_dinode_core one will have to do endian swapping while the other doesn't. Instead of having the current mess with the CFORK macros that have byteswapping and non-byteswapping version (which are inconsistantly named while we're at it) just define each family of the macros to stand by itself and simplify the whole matter. A few direct references to the CFORK variants were cleaned up to use IFORK or DFORK to make this possible. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/xfs_dinode.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_dinode.h 2007-08-23 18:52:49.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_dinode.h 2007-09-19 15:16:30.000000000 +0200 @@ -171,69 +171,35 @@ typedef enum xfs_dinode_fmt /* * Inode data & attribute fork sizes, per inode. */ -#define XFS_CFORK_Q(dcp) ((dcp)->di_forkoff != 0) -#define XFS_CFORK_Q_DISK(dcp) ((dcp)->di_forkoff != 0) - -#define XFS_CFORK_BOFF(dcp) ((int)((dcp)->di_forkoff << 3)) -#define XFS_CFORK_BOFF_DISK(dcp) ((int)((dcp)->di_forkoff << 3)) - -#define XFS_CFORK_DSIZE_DISK(dcp,mp) \ - (XFS_CFORK_Q_DISK(dcp) ? XFS_CFORK_BOFF_DISK(dcp) : XFS_LITINO(mp)) -#define XFS_CFORK_DSIZE(dcp,mp) \ - (XFS_CFORK_Q(dcp) ? XFS_CFORK_BOFF(dcp) : XFS_LITINO(mp)) - -#define XFS_CFORK_ASIZE_DISK(dcp,mp) \ - (XFS_CFORK_Q_DISK(dcp) ? XFS_LITINO(mp) - XFS_CFORK_BOFF_DISK(dcp) : 0) -#define XFS_CFORK_ASIZE(dcp,mp) \ - (XFS_CFORK_Q(dcp) ? XFS_LITINO(mp) - XFS_CFORK_BOFF(dcp) : 0) - -#define XFS_CFORK_SIZE_DISK(dcp,mp,w) \ - ((w) == XFS_DATA_FORK ? \ - XFS_CFORK_DSIZE_DISK(dcp, mp) : \ - XFS_CFORK_ASIZE_DISK(dcp, mp)) -#define XFS_CFORK_SIZE(dcp,mp,w) \ - ((w) == XFS_DATA_FORK ? \ - XFS_CFORK_DSIZE(dcp, mp) : XFS_CFORK_ASIZE(dcp, mp)) +#define XFS_DFORK_Q(dip) ((dip)->di_core.di_forkoff != 0) +#define XFS_DFORK_BOFF(dip) ((int)((dip)->di_core.di_forkoff << 3)) #define XFS_DFORK_DSIZE(dip,mp) \ - XFS_CFORK_DSIZE_DISK(&(dip)->di_core, mp) -#define XFS_DFORK_DSIZE_HOST(dip,mp) \ - XFS_CFORK_DSIZE(&(dip)->di_core, mp) + (XFS_DFORK_Q(dip) ? \ + XFS_DFORK_BOFF(dip) : \ + XFS_LITINO(mp)) #define XFS_DFORK_ASIZE(dip,mp) \ - XFS_CFORK_ASIZE_DISK(&(dip)->di_core, mp) -#define XFS_DFORK_ASIZE_HOST(dip,mp) \ - XFS_CFORK_ASIZE(&(dip)->di_core, mp) -#define XFS_DFORK_SIZE(dip,mp,w) \ - XFS_CFORK_SIZE_DISK(&(dip)->di_core, mp, w) -#define XFS_DFORK_SIZE_HOST(dip,mp,w) \ - XFS_CFORK_SIZE(&(dip)->di_core, mp, w) - -#define XFS_DFORK_Q(dip) XFS_CFORK_Q_DISK(&(dip)->di_core) -#define XFS_DFORK_BOFF(dip) XFS_CFORK_BOFF_DISK(&(dip)->di_core) -#define XFS_DFORK_DPTR(dip) ((dip)->di_u.di_c) -#define XFS_DFORK_APTR(dip) \ - ((dip)->di_u.di_c + XFS_DFORK_BOFF(dip)) -#define XFS_DFORK_PTR(dip,w) \ - ((w) == XFS_DATA_FORK ? XFS_DFORK_DPTR(dip) : XFS_DFORK_APTR(dip)) -#define XFS_CFORK_FORMAT(dcp,w) \ - ((w) == XFS_DATA_FORK ? (dcp)->di_format : (dcp)->di_aformat) -#define XFS_CFORK_FMT_SET(dcp,w,n) \ + (XFS_DFORK_Q(dip) ? \ + XFS_LITINO(mp) - XFS_DFORK_BOFF(dip) : \ + 0) +#define XFS_DFORK_SIZE(dip,mp,w) \ ((w) == XFS_DATA_FORK ? \ - ((dcp)->di_format = (n)) : ((dcp)->di_aformat = (n))) -#define XFS_DFORK_FORMAT(dip,w) XFS_CFORK_FORMAT(&(dip)->di_core, w) + XFS_DFORK_DSIZE(dip, mp) : \ + XFS_DFORK_ASIZE(dip, mp)) -#define XFS_CFORK_NEXTENTS_DISK(dcp,w) \ +#define XFS_DFORK_DPTR(dip) ((dip)->di_u.di_c) +#define XFS_DFORK_APTR(dip) \ + ((dip)->di_u.di_c + XFS_DFORK_BOFF(dip)) +#define XFS_DFORK_PTR(dip,w) \ + ((w) == XFS_DATA_FORK ? XFS_DFORK_DPTR(dip) : XFS_DFORK_APTR(dip)) +#define XFS_DFORK_FORMAT(dip,w) \ ((w) == XFS_DATA_FORK ? \ - be32_to_cpu((dcp)->di_nextents) : \ - be16_to_cpu((dcp)->di_anextents)) -#define XFS_CFORK_NEXTENTS(dcp,w) \ - ((w) == XFS_DATA_FORK ? (dcp)->di_nextents : (dcp)->di_anextents) -#define XFS_DFORK_NEXTENTS(dip,w) XFS_CFORK_NEXTENTS_DISK(&(dip)->di_core, w) -#define XFS_DFORK_NEXTENTS_HOST(dip,w) XFS_CFORK_NEXTENTS(&(dip)->di_core, w) - -#define XFS_CFORK_NEXT_SET(dcp,w,n) \ + (dip)->di_core.di_format : \ + (dip)->di_core.di_aformat) +#define XFS_DFORK_NEXTENTS(dip,w) \ ((w) == XFS_DATA_FORK ? \ - ((dcp)->di_nextents = (n)) : ((dcp)->di_anextents = (n))) + be32_to_cpu((dip)->di_core.di_nextents) : \ + be16_to_cpu((dip)->di_core.di_anextents)) #define XFS_BUF_TO_DINODE(bp) ((xfs_dinode_t *)XFS_BUF_PTR(bp)) Index: linux-2.6-xfs/fs/xfs/xfs_inode.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_inode.h 2007-09-19 15:09:31.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_inode.h 2007-09-19 15:16:30.000000000 +0200 @@ -341,17 +341,42 @@ xfs_iflags_test_and_clear(xfs_inode_t *i /* * Fork handling. */ -#define XFS_IFORK_PTR(ip,w) \ - ((w) == XFS_DATA_FORK ? &(ip)->i_df : (ip)->i_afp) -#define XFS_IFORK_Q(ip) XFS_CFORK_Q(&(ip)->i_d) -#define XFS_IFORK_DSIZE(ip) XFS_CFORK_DSIZE(&ip->i_d, ip->i_mount) -#define XFS_IFORK_ASIZE(ip) XFS_CFORK_ASIZE(&ip->i_d, ip->i_mount) -#define XFS_IFORK_SIZE(ip,w) XFS_CFORK_SIZE(&ip->i_d, ip->i_mount, w) -#define XFS_IFORK_FORMAT(ip,w) XFS_CFORK_FORMAT(&ip->i_d, w) -#define XFS_IFORK_FMT_SET(ip,w,n) XFS_CFORK_FMT_SET(&ip->i_d, w, n) -#define XFS_IFORK_NEXTENTS(ip,w) XFS_CFORK_NEXTENTS(&ip->i_d, w) -#define XFS_IFORK_NEXT_SET(ip,w,n) XFS_CFORK_NEXT_SET(&ip->i_d, w, n) +#define XFS_IFORK_Q(ip) ((ip)->i_d.di_forkoff != 0) +#define XFS_IFORK_BOFF(ip) ((int)((ip)->i_d.di_forkoff << 3)) + +#define XFS_IFORK_PTR(ip,w) \ + ((w) == XFS_DATA_FORK ? \ + &(ip)->i_df : \ + (ip)->i_afp) +#define XFS_IFORK_DSIZE(ip) \ + (XFS_IFORK_Q(ip) ? \ + XFS_IFORK_BOFF(ip) : \ + XFS_LITINO((ip)->i_mount)) +#define XFS_IFORK_ASIZE(ip) \ + (XFS_IFORK_Q(ip) ? \ + XFS_LITINO((ip)->i_mount) - XFS_IFORK_BOFF(ip) : \ + 0) +#define XFS_IFORK_SIZE(ip,w) \ + ((w) == XFS_DATA_FORK ? \ + XFS_IFORK_DSIZE(ip) : \ + XFS_IFORK_ASIZE(ip)) +#define XFS_IFORK_FORMAT(ip,w) \ + ((w) == XFS_DATA_FORK ? \ + (ip)->i_d.di_format : \ + (ip)->i_d.di_aformat) +#define XFS_IFORK_FMT_SET(ip,w,n) \ + ((w) == XFS_DATA_FORK ? \ + ((ip)->i_d.di_format = (n)) : \ + ((ip)->i_d.di_aformat = (n))) +#define XFS_IFORK_NEXTENTS(ip,w) \ + ((w) == XFS_DATA_FORK ? \ + (ip)->i_d.di_nextents : \ + (ip)->i_d.di_anextents) +#define XFS_IFORK_NEXT_SET(ip,w,n) \ + ((w) == XFS_DATA_FORK ? \ + ((ip)->i_d.di_nextents = (n)) : \ + ((ip)->i_d.di_anextents = (n))) #ifdef __KERNEL__ @@ -504,7 +529,7 @@ void xfs_dinode_to_disk(struct xfs_dino struct xfs_icdinode *); uint xfs_ip2xflags(struct xfs_inode *); -uint xfs_dic2xflags(struct xfs_dinode_core *); +uint xfs_dic2xflags(struct xfs_dinode *); int xfs_ifree(struct xfs_trans *, xfs_inode_t *, struct xfs_bmap_free *); int xfs_itruncate_start(xfs_inode_t *, uint, xfs_fsize_t); Index: linux-2.6-xfs/fs/xfs/xfs_inode.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_inode.c 2007-09-19 15:09:31.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_inode.c 2007-09-19 15:16:30.000000000 +0200 @@ -826,15 +826,17 @@ xfs_ip2xflags( xfs_icdinode_t *dic = &ip->i_d; return _xfs_dic2xflags(dic->di_flags) | - (XFS_CFORK_Q(dic) ? XFS_XFLAG_HASATTR : 0); + (XFS_IFORK_Q(ip) ? XFS_XFLAG_HASATTR : 0); } uint xfs_dic2xflags( - xfs_dinode_core_t *dic) + xfs_dinode_t *dip) { + xfs_dinode_core_t *dic = &dip->di_core; + return _xfs_dic2xflags(be16_to_cpu(dic->di_flags)) | - (XFS_CFORK_Q_DISK(dic) ? XFS_XFLAG_HASATTR : 0); + (XFS_DFORK_Q(dip) ? XFS_XFLAG_HASATTR : 0); } /* Index: linux-2.6-xfs/fs/xfs/xfs_itable.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_itable.c 2007-09-12 13:56:17.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_itable.c 2007-09-19 15:16:30.000000000 +0200 @@ -170,7 +170,7 @@ xfs_bulkstat_one_dinode( buf->bs_mtime.tv_nsec = be32_to_cpu(dic->di_mtime.t_nsec); buf->bs_ctime.tv_sec = be32_to_cpu(dic->di_ctime.t_sec); buf->bs_ctime.tv_nsec = be32_to_cpu(dic->di_ctime.t_nsec); - buf->bs_xflags = xfs_dic2xflags(dic); + buf->bs_xflags = xfs_dic2xflags(dip); buf->bs_extsize = be32_to_cpu(dic->di_extsize) << mp->m_sb.sb_blocklog; buf->bs_extents = be32_to_cpu(dic->di_nextents); buf->bs_gen = be32_to_cpu(dic->di_gen); @@ -299,7 +299,7 @@ xfs_bulkstat_use_dinode( } /* BULKSTAT_FG_INLINE: if attr fork is local, or not there, use it */ aformat = dip->di_core.di_aformat; - if ((XFS_CFORK_Q(&dip->di_core) == 0) || + if ((XFS_DFORK_Q(dip) == 0) || (aformat == XFS_DINODE_FMT_LOCAL) || (aformat == XFS_DINODE_FMT_EXTENTS && !dip->di_core.di_anextents)) { *dipp = dip; Index: linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/dmapi/xfs_dm.c 2007-09-19 18:50:35.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c 2007-09-19 18:51:01.000000000 +0200 @@ -355,7 +355,7 @@ xfs_ip2dmflags( xfs_inode_t *ip) { return _xfs_dic2dmflags(ip->i_d.di_flags) | - (XFS_CFORK_Q(&ip->i_d) ? DM_XFLAG_HASATTR : 0); + (XFS_IFORK_Q(ip) ? DM_XFLAG_HASATTR : 0); } STATIC uint @@ -363,8 +363,7 @@ xfs_dic2dmflags( xfs_dinode_t *dip) { return _xfs_dic2dmflags(be16_to_cpu(dip->di_core.di_flags)) | - (XFS_CFORK_Q_DISK(&dip->di_core) ? - DM_XFLAG_HASATTR : 0); + (XFS_DFORK_Q(dip) ? DM_XFLAG_HASATTR : 0); } /* From owner-xfs@oss.sgi.com Sat Sep 22 03:34:21 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 22 Sep 2007 03:34: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.9 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 l8MAYJQ3016099 for ; Sat, 22 Sep 2007 03:34:20 -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 l8MAYKA5016236 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 22 Sep 2007 12:34:20 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8MAYKLu016234 for xfs@oss.sgi.com; Sat, 22 Sep 2007 12:34:20 +0200 Date: Sat, 22 Sep 2007 12:34:20 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: [PATCH 1/3] clean up some xfs_log_priv.h macros Message-ID: <20070922103420.GA16223@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-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13036 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 - the various assign lsn macros are replaced by a single inline, xlog_assign_lsn, which is equivalent to ASSIGN_ANY_LSN_HOST except for a more sane calling convention. ASSIGN_LSN_DISK is replaced by xlog_assign_lsn and a manual bytespap, and ASSIGN_LSN by the same, except we pass the cycle and block arguments explicitly instead of a log paramter. The latter two variants only had 2, respectively one user anyway. - the GET_CYCLE is replaced by a xlog_get_cycle inline with exactly the same calling conventions. - GET_CLIENT_ID is replaced by xlog_get_client_id which leaves away the unused arch argument. Instead of conditional defintions depending on host endianess we now do an unconditional swap and shift then, which generates equal code. - the unused XLOG_SET macro is removed. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/xfs_log.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_log.c 2007-08-23 20:36:41.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_log.c 2007-08-23 20:37:05.000000000 +0200 @@ -1142,7 +1142,7 @@ xlog_alloc_log(xfs_mount_t *mp, log->l_flags |= XLOG_ACTIVE_RECOVERY; log->l_prev_block = -1; - ASSIGN_ANY_LSN_HOST(log->l_tail_lsn, 1, 0); + log->l_tail_lsn = xlog_assign_lsn(1, 0); /* log->l_tail_lsn = 0x100000000LL; cycle = 1; current block = 0 */ log->l_last_sync_lsn = log->l_tail_lsn; log->l_curr_cycle = 1; /* 0 is bad since this is initial value */ @@ -1308,8 +1308,7 @@ xlog_grant_push_ail(xfs_mount_t *mp, threshold_block -= log->l_logBBsize; threshold_cycle += 1; } - ASSIGN_ANY_LSN_HOST(threshold_lsn, threshold_cycle, - threshold_block); + threshold_lsn = xlog_assign_lsn(threshold_cycle, threshold_block); /* Don't pass in an lsn greater than the lsn of the last * log record known to be on disk. @@ -2382,7 +2381,8 @@ restart: log->l_iclog_hsize, XLOG_REG_TYPE_LRHEADER); INT_SET(head->h_cycle, ARCH_CONVERT, log->l_curr_cycle); - ASSIGN_LSN(head->h_lsn, log); + INT_SET(head->h_lsn, ARCH_CONVERT, + xlog_assign_lsn(log->l_curr_cycle, log->l_curr_block)); ASSERT(log->l_curr_block >= 0); } @@ -3494,9 +3494,11 @@ xlog_verify_iclog(xlog_t *log, if (idx >= (XLOG_HEADER_CYCLE_SIZE / BBSIZE)) { j = idx / (XLOG_HEADER_CYCLE_SIZE / BBSIZE); k = idx % (XLOG_HEADER_CYCLE_SIZE / BBSIZE); - clientid = GET_CLIENT_ID(xhdr[j].hic_xheader.xh_cycle_data[k], ARCH_CONVERT); + clientid = xlog_get_client_id( + xhdr[j].hic_xheader.xh_cycle_data[k]); } else { - clientid = GET_CLIENT_ID(iclog->ic_header.h_cycle_data[idx], ARCH_CONVERT); + clientid = xlog_get_client_id( + iclog->ic_header.h_cycle_data[idx]); } } if (clientid != XFS_TRANSACTION && clientid != XFS_LOG) Index: linux-2.6-xfs/fs/xfs/xfs_log_priv.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_log_priv.h 2007-08-23 20:36:41.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_log_priv.h 2007-08-23 20:37:34.000000000 +0200 @@ -55,33 +55,22 @@ struct xfs_mount; BTOBB(XLOG_MAX_ICLOGS << (XFS_SB_VERSION_HASLOGV2(&log->l_mp->m_sb) ? \ XLOG_MAX_RECORD_BSHIFT : XLOG_BIG_RECORD_BSHIFT)) -/* - * set lsns - */ -#define ASSIGN_ANY_LSN_HOST(lsn,cycle,block) \ - { \ - (lsn) = ((xfs_lsn_t)(cycle)<<32)|(block); \ - } -#define ASSIGN_ANY_LSN_DISK(lsn,cycle,block) \ - { \ - INT_SET(((uint *)&(lsn))[0], ARCH_CONVERT, (cycle)); \ - INT_SET(((uint *)&(lsn))[1], ARCH_CONVERT, (block)); \ - } -#define ASSIGN_LSN(lsn,log) \ - ASSIGN_ANY_LSN_DISK(lsn,(log)->l_curr_cycle,(log)->l_curr_block); - -#define XLOG_SET(f,b) (((f) & (b)) == (b)) - -#define GET_CYCLE(ptr, arch) \ - (INT_GET(*(uint *)(ptr), arch) == XLOG_HEADER_MAGIC_NUM ? \ - INT_GET(*((uint *)(ptr)+1), arch) : \ - INT_GET(*(uint *)(ptr), arch) \ - ) +static inline xfs_lsn_t xlog_assign_lsn(uint cycle, uint block) +{ + return ((xfs_lsn_t)cycle << 32) | block; +} + +static inline uint xlog_get_cycle(char *ptr) +{ + if (INT_GET(*(uint *)ptr, ARCH_CONVERT) == XLOG_HEADER_MAGIC_NUM) + return INT_GET(*((uint *)ptr + 1), ARCH_CONVERT); + else + return INT_GET(*(uint *)ptr, ARCH_CONVERT); +} #define BLK_AVG(blk1, blk2) ((blk1+blk2) >> 1) - #ifdef __KERNEL__ /* @@ -96,14 +85,10 @@ struct xfs_mount; * * this has endian issues, of course. */ - -#ifndef XFS_NATIVE_HOST -#define GET_CLIENT_ID(i,arch) \ - ((i) & 0xff) -#else -#define GET_CLIENT_ID(i,arch) \ - ((i) >> 24) -#endif +static inline uint xlog_get_client_id(uint i) +{ + return INT_GET(i, ARCH_CONVERT) >> 24; +} #define GRANT_LOCK(log) mutex_spinlock(&(log)->l_grant_lock) #define GRANT_UNLOCK(log, s) mutex_spinunlock(&(log)->l_grant_lock, s) Index: linux-2.6-xfs/fs/xfs/xfs_log_recover.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_log_recover.c 2007-08-23 20:36:41.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_log_recover.c 2007-08-23 20:37:05.000000000 +0200 @@ -311,7 +311,7 @@ xlog_find_cycle_start( if ((error = xlog_bread(log, mid_blk, 1, bp))) return error; offset = xlog_align(log, mid_blk, 1, bp); - mid_cycle = GET_CYCLE(offset, ARCH_CONVERT); + mid_cycle = xlog_get_cycle(offset); if (mid_cycle == cycle) { *last_blk = mid_blk; /* last_half_cycle == mid_cycle */ @@ -371,7 +371,7 @@ xlog_find_verify_cycle( buf = xlog_align(log, i, bcount, bp); for (j = 0; j < bcount; j++) { - cycle = GET_CYCLE(buf, ARCH_CONVERT); + cycle = xlog_get_cycle(buf); if (cycle == stop_on_cycle_no) { *new_blk = i+j; goto out; @@ -550,13 +550,13 @@ xlog_find_head( if ((error = xlog_bread(log, 0, 1, bp))) goto bp_err; offset = xlog_align(log, 0, 1, bp); - first_half_cycle = GET_CYCLE(offset, ARCH_CONVERT); + first_half_cycle = xlog_get_cycle(offset); last_blk = head_blk = log_bbnum - 1; /* get cycle # of last block */ if ((error = xlog_bread(log, last_blk, 1, bp))) goto bp_err; offset = xlog_align(log, last_blk, 1, bp); - last_half_cycle = GET_CYCLE(offset, ARCH_CONVERT); + last_half_cycle = xlog_get_cycle(offset); ASSERT(last_half_cycle != 0); /* @@ -808,7 +808,7 @@ xlog_find_tail( if ((error = xlog_bread(log, 0, 1, bp))) goto bread_err; offset = xlog_align(log, 0, 1, bp); - if (GET_CYCLE(offset, ARCH_CONVERT) == 0) { + if (xlog_get_cycle(offset) == 0) { *tail_blk = 0; /* leave all other log inited values alone */ goto exit; @@ -922,10 +922,12 @@ xlog_find_tail( * log records will point recovery to after the * current unmount record. */ - ASSIGN_ANY_LSN_HOST(log->l_tail_lsn, log->l_curr_cycle, - after_umount_blk); - ASSIGN_ANY_LSN_HOST(log->l_last_sync_lsn, log->l_curr_cycle, - after_umount_blk); + log->l_tail_lsn = + xlog_assign_lsn(log->l_curr_cycle, + after_umount_blk); + log->l_last_sync_lsn = + xlog_assign_lsn(log->l_curr_cycle, + after_umount_blk); *tail_blk = after_umount_blk; /* @@ -1007,7 +1009,7 @@ xlog_find_zeroed( if ((error = xlog_bread(log, 0, 1, bp))) goto bp_err; offset = xlog_align(log, 0, 1, bp); - first_cycle = GET_CYCLE(offset, ARCH_CONVERT); + first_cycle = xlog_get_cycle(offset); if (first_cycle == 0) { /* completely zeroed log */ *blk_no = 0; xlog_put_bp(bp); @@ -1018,7 +1020,7 @@ xlog_find_zeroed( if ((error = xlog_bread(log, log_bbnum-1, 1, bp))) goto bp_err; offset = xlog_align(log, log_bbnum-1, 1, bp); - last_cycle = GET_CYCLE(offset, ARCH_CONVERT); + last_cycle = xlog_get_cycle(offset); if (last_cycle != 0) { /* log completely written to */ xlog_put_bp(bp); return 0; @@ -1102,8 +1104,9 @@ xlog_add_record( INT_SET(recp->h_cycle, ARCH_CONVERT, cycle); INT_SET(recp->h_version, ARCH_CONVERT, XFS_SB_VERSION_HASLOGV2(&log->l_mp->m_sb) ? 2 : 1); - ASSIGN_ANY_LSN_DISK(recp->h_lsn, cycle, block); - ASSIGN_ANY_LSN_DISK(recp->h_tail_lsn, tail_cycle, tail_block); + INT_SET(recp->h_lsn, ARCH_CONVERT, xlog_assign_lsn(cycle, block)); + INT_SET(recp->h_tail_lsn, ARCH_CONVERT, + xlog_assign_lsn(tail_cycle, tail_block)); INT_SET(recp->h_fmt, ARCH_CONVERT, XLOG_FMT); memcpy(&recp->h_fs_uuid, &log->l_mp->m_sb.sb_uuid, sizeof(uuid_t)); } From owner-xfs@oss.sgi.com Sat Sep 22 03:34:27 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 22 Sep 2007 03:34: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,J_CHICKENPOX_62 autolearn=no 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 l8MAYNQ3016141 for ; Sat, 22 Sep 2007 03:34:27 -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 l8MAYPA5016254 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 22 Sep 2007 12:34:25 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8MAYPUw016252 for xfs@oss.sgi.com; Sat, 22 Sep 2007 12:34:25 +0200 Date: Sat, 22 Sep 2007 12:34:25 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: [PATCH 2/3] xlog_op_header endianess annotations Message-ID: <20070922103425.GB16223@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-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13037 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 Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/xfs_log.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_log.c 2007-08-23 20:44:29.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_log.c 2007-08-23 20:44:30.000000000 +0200 @@ -1815,7 +1815,7 @@ xlog_write(xfs_mount_t * mp, */ if (ticket->t_flags & XLOG_TIC_INITED) { logop_head = (xlog_op_header_t *)ptr; - INT_SET(logop_head->oh_tid, ARCH_CONVERT, ticket->t_tid); + logop_head->oh_tid = cpu_to_be32(ticket->t_tid); logop_head->oh_clientid = ticket->t_clientid; logop_head->oh_len = 0; logop_head->oh_flags = XLOG_START_TRANS; @@ -1829,7 +1829,7 @@ xlog_write(xfs_mount_t * mp, /* Copy log operation header directly into data section */ logop_head = (xlog_op_header_t *)ptr; - INT_SET(logop_head->oh_tid, ARCH_CONVERT, ticket->t_tid); + logop_head->oh_tid = cpu_to_be32(ticket->t_tid); logop_head->oh_clientid = ticket->t_clientid; logop_head->oh_res2 = 0; @@ -1864,13 +1864,14 @@ xlog_write(xfs_mount_t * mp, copy_off = partial_copy_len; if (need_copy <= iclog->ic_size - log_offset) { /*complete write */ - INT_SET(logop_head->oh_len, ARCH_CONVERT, copy_len = need_copy); + copy_len = need_copy; + logop_head->oh_len = cpu_to_be32(copy_len); if (partial_copy) logop_head->oh_flags|= (XLOG_END_TRANS|XLOG_WAS_CONT_TRANS); partial_copy_len = partial_copy = 0; } else { /* partial write */ copy_len = iclog->ic_size - log_offset; - INT_SET(logop_head->oh_len, ARCH_CONVERT, copy_len); + logop_head->oh_len = cpu_to_be32(copy_len); logop_head->oh_flags |= XLOG_CONTINUE_TRANS; if (partial_copy) logop_head->oh_flags |= XLOG_WAS_CONT_TRANS; @@ -3510,7 +3511,7 @@ xlog_verify_iclog(xlog_t *log, field_offset = (__psint_t) ((xfs_caddr_t)&(ophead->oh_len) - base_ptr); if (syncing == B_FALSE || (field_offset & 0x1ff)) { - op_len = INT_GET(ophead->oh_len, ARCH_CONVERT); + op_len = be32_to_cpu(ophead->oh_len); } else { idx = BTOBBT((__psint_t)&ophead->oh_len - (__psint_t)iclog->ic_datap); Index: linux-2.6-xfs/fs/xfs/xfs_log_priv.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_log_priv.h 2007-08-23 20:44:29.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_log_priv.h 2007-08-23 20:44:30.000000000 +0200 @@ -286,11 +286,11 @@ typedef struct xlog_ticket { typedef struct xlog_op_header { - xlog_tid_t oh_tid; /* transaction id of operation : 4 b */ - int oh_len; /* bytes in data region : 4 b */ - __uint8_t oh_clientid; /* who sent me this : 1 b */ - __uint8_t oh_flags; /* : 1 b */ - ushort oh_res2; /* 32 bit align : 2 b */ + __be32 oh_tid; /* transaction id of operation : 4 b */ + __be32 oh_len; /* bytes in data region : 4 b */ + __u8 oh_clientid; /* who sent me this : 1 b */ + __u8 oh_flags; /* : 1 b */ + __u16 oh_res2; /* 32 bit align : 2 b */ } xlog_op_header_t; Index: linux-2.6-xfs/fs/xfs/xfs_log_recover.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_log_recover.c 2007-08-23 20:44:29.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_log_recover.c 2007-08-23 20:44:30.000000000 +0200 @@ -2918,7 +2918,7 @@ xlog_recover_process_data( ASSERT(0); return (XFS_ERROR(EIO)); } - tid = INT_GET(ohead->oh_tid, ARCH_CONVERT); + tid = be32_to_cpu(ohead->oh_tid); hash = XLOG_RHASH(tid); trans = xlog_recover_find_tid(rhash[hash], tid); if (trans == NULL) { /* not found; add new tid */ @@ -2926,7 +2926,7 @@ xlog_recover_process_data( xlog_recover_new_tid(&rhash[hash], tid, INT_GET(rhead->h_lsn, ARCH_CONVERT)); } else { - ASSERT(dp+INT_GET(ohead->oh_len, ARCH_CONVERT) <= lp); + ASSERT(dp + be32_to_cpu(ohead->oh_len) <= lp); flags = ohead->oh_flags & ~XLOG_END_TRANS; if (flags & XLOG_WAS_CONT_TRANS) flags &= ~XLOG_CONTINUE_TRANS; @@ -2940,8 +2940,7 @@ xlog_recover_process_data( break; case XLOG_WAS_CONT_TRANS: error = xlog_recover_add_to_cont_trans(trans, - dp, INT_GET(ohead->oh_len, - ARCH_CONVERT)); + dp, be32_to_cpu(ohead->oh_len)); break; case XLOG_START_TRANS: xlog_warn( @@ -2952,8 +2951,7 @@ xlog_recover_process_data( case 0: case XLOG_CONTINUE_TRANS: error = xlog_recover_add_to_trans(trans, - dp, INT_GET(ohead->oh_len, - ARCH_CONVERT)); + dp, be32_to_cpu(ohead->oh_len)); break; default: xlog_warn( @@ -2965,7 +2963,7 @@ xlog_recover_process_data( if (error) return error; } - dp += INT_GET(ohead->oh_len, ARCH_CONVERT); + dp += be32_to_cpu(ohead->oh_len); num_logops--; } return 0; From owner-xfs@oss.sgi.com Sat Sep 22 03:34:33 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 22 Sep 2007 03:34: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,J_BACKHAIR_17, J_CHICKENPOX_62,J_CHICKENPOX_63,J_CHICKENPOX_64 autolearn=no 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 l8MAYTQ3016191 for ; Sat, 22 Sep 2007 03:34:32 -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 l8MAYTA5016267 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 22 Sep 2007 12:34:29 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8MAYTqF016265 for xfs@oss.sgi.com; Sat, 22 Sep 2007 12:34:29 +0200 Date: Sat, 22 Sep 2007 12:34:29 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: [PATCH 3/3] xlog_rec_header/xlog_rec_ext_header endianess annotations Message-ID: <20070922103429.GC16223@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-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13038 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 Mostly trivial conversion with one exceptions: h_num_logops was kept in native endian previously and only converted to big endian in xlog_sync, but we always keep it big endian now. With todays cpus fast byteswap instructions that's not an issue but the new variant keeps the code clean and maintainable. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/xfs_log.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_log.c 2007-08-23 20:44:30.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_log.c 2007-08-23 20:44:35.000000000 +0200 @@ -1208,12 +1208,12 @@ xlog_alloc_log(xfs_mount_t *mp, head = &iclog->ic_header; memset(head, 0, sizeof(xlog_rec_header_t)); - INT_SET(head->h_magicno, ARCH_CONVERT, XLOG_HEADER_MAGIC_NUM); - INT_SET(head->h_version, ARCH_CONVERT, + head->h_magicno = cpu_to_be32(XLOG_HEADER_MAGIC_NUM); + head->h_version = cpu_to_be32( XFS_SB_VERSION_HASLOGV2(&log->l_mp->m_sb) ? 2 : 1); - INT_SET(head->h_size, ARCH_CONVERT, log->l_iclog_size); + head->h_size = cpu_to_be32(log->l_iclog_size); /* new fields */ - INT_SET(head->h_fmt, ARCH_CONVERT, XLOG_FMT); + head->h_fmt = cpu_to_be32(XLOG_FMT); memcpy(&head->h_fs_uuid, &mp->m_sb.sb_uuid, sizeof(uuid_t)); @@ -1360,7 +1360,7 @@ xlog_sync(xlog_t *log, { xfs_caddr_t dptr; /* pointer to byte sized element */ xfs_buf_t *bp; - int i, ops; + int i; uint count; /* byte count of bwrite */ uint count_init; /* initial count before roundup */ int roundoff; /* roundoff to BB or stripe */ @@ -1400,21 +1400,17 @@ xlog_sync(xlog_t *log, /* real byte length */ if (v2) { - INT_SET(iclog->ic_header.h_len, - ARCH_CONVERT, - iclog->ic_offset + roundoff); + iclog->ic_header.h_len = + cpu_to_be32(iclog->ic_offset + roundoff); } else { - INT_SET(iclog->ic_header.h_len, ARCH_CONVERT, iclog->ic_offset); + iclog->ic_header.h_len = + cpu_to_be32(iclog->ic_offset); } - /* put ops count in correct order */ - ops = iclog->ic_header.h_num_logops; - INT_SET(iclog->ic_header.h_num_logops, ARCH_CONVERT, ops); - bp = iclog->ic_bp; ASSERT(XFS_BUF_FSPRIVATE2(bp, unsigned long) == (unsigned long)1); XFS_BUF_SET_FSPRIVATE2(bp, (unsigned long)2); - XFS_BUF_SET_ADDR(bp, BLOCK_LSN(INT_GET(iclog->ic_header.h_lsn, ARCH_CONVERT))); + XFS_BUF_SET_ADDR(bp, BLOCK_LSN(be64_to_cpu(iclog->ic_header.h_lsn))); XFS_STATS_ADD(xs_log_blocks, BTOBB(count)); @@ -1477,10 +1473,10 @@ xlog_sync(xlog_t *log, * a new cycle. Watch out for the header magic number * case, though. */ - for (i=0; iic_header.h_num_logops += record_cnt; + be32_add(&iclog->ic_header.h_num_logops, record_cnt); iclog->ic_offset += copy_bytes; LOG_UNLOCK(log, s); @@ -1799,7 +1795,7 @@ xlog_write(xfs_mount_t * mp, /* start_lsn is the first lsn written to. That's all we need. */ if (! *start_lsn) - *start_lsn = INT_GET(iclog->ic_header.h_lsn, ARCH_CONVERT); + *start_lsn = be64_to_cpu(iclog->ic_header.h_lsn); /* This loop writes out as many regions as can fit in the amount * of space which was allocated by xlog_state_get_iclog_space(). @@ -1969,7 +1965,8 @@ xlog_state_clean_log(xlog_t *log) * We don't need to cover the dummy. */ if (!changed && - (INT_GET(iclog->ic_header.h_num_logops, ARCH_CONVERT) == XLOG_COVER_OPS)) { + (be32_to_cpu(iclog->ic_header.h_num_logops) == + XLOG_COVER_OPS)) { changed = 1; } else { /* @@ -2037,7 +2034,7 @@ xlog_get_lowest_lsn( lowest_lsn = 0; do { if (!(lsn_log->ic_state & (XLOG_STATE_ACTIVE|XLOG_STATE_DIRTY))) { - lsn = INT_GET(lsn_log->ic_header.h_lsn, ARCH_CONVERT); + lsn = be64_to_cpu(lsn_log->ic_header.h_lsn); if ((lsn && !lowest_lsn) || (XFS_LSN_CMP(lsn, lowest_lsn) < 0)) { lowest_lsn = lsn; @@ -2139,11 +2136,9 @@ xlog_state_do_callback( */ lowest_lsn = xlog_get_lowest_lsn(log); - if (lowest_lsn && ( - XFS_LSN_CMP( - lowest_lsn, - INT_GET(iclog->ic_header.h_lsn, ARCH_CONVERT) - )<0)) { + if (lowest_lsn && + XFS_LSN_CMP(lowest_lsn, + be64_to_cpu(iclog->ic_header.h_lsn)) < 0) { iclog = iclog->ic_next; continue; /* Leave this iclog for * another thread */ @@ -2158,11 +2153,9 @@ xlog_state_do_callback( * No one else can be here except us. */ s = GRANT_LOCK(log); - ASSERT(XFS_LSN_CMP( - log->l_last_sync_lsn, - INT_GET(iclog->ic_header.h_lsn, ARCH_CONVERT) - )<=0); - log->l_last_sync_lsn = INT_GET(iclog->ic_header.h_lsn, ARCH_CONVERT); + ASSERT(XFS_LSN_CMP(log->l_last_sync_lsn, + be64_to_cpu(iclog->ic_header.h_lsn)) <= 0); + log->l_last_sync_lsn = be64_to_cpu(iclog->ic_header.h_lsn); GRANT_UNLOCK(log, s); /* @@ -2381,8 +2374,8 @@ restart: XLOG_TIC_ADD_REGION(ticket, log->l_iclog_hsize, XLOG_REG_TYPE_LRHEADER); - INT_SET(head->h_cycle, ARCH_CONVERT, log->l_curr_cycle); - INT_SET(head->h_lsn, ARCH_CONVERT, + head->h_cycle = cpu_to_be32(log->l_curr_cycle); + head->h_lsn = cpu_to_be64( xlog_assign_lsn(log->l_curr_cycle, log->l_curr_block)); ASSERT(log->l_curr_block >= 0); } @@ -2821,7 +2814,7 @@ xlog_state_release_iclog(xlog_t *log, iclog->ic_state == XLOG_STATE_WANT_SYNC) { sync++; iclog->ic_state = XLOG_STATE_SYNCING; - INT_SET(iclog->ic_header.h_tail_lsn, ARCH_CONVERT, log->l_tail_lsn); + iclog->ic_header.h_tail_lsn = cpu_to_be64(log->l_tail_lsn); xlog_verify_tail_lsn(log, iclog, log->l_tail_lsn); /* cycle incremented when incrementing curr_block */ } @@ -2859,7 +2852,7 @@ xlog_state_switch_iclogs(xlog_t *log, if (!eventual_size) eventual_size = iclog->ic_offset; iclog->ic_state = XLOG_STATE_WANT_SYNC; - INT_SET(iclog->ic_header.h_prev_block, ARCH_CONVERT, log->l_prev_block); + iclog->ic_header.h_prev_block = cpu_to_be32(log->l_prev_block); log->l_prev_block = log->l_curr_block; log->l_prev_cycle = log->l_curr_cycle; @@ -2956,7 +2949,7 @@ xlog_state_sync_all(xlog_t *log, uint fl * the previous sync. */ iclog->ic_refcnt++; - lsn = INT_GET(iclog->ic_header.h_lsn, ARCH_CONVERT); + lsn = be64_to_cpu(iclog->ic_header.h_lsn); xlog_state_switch_iclogs(log, iclog, 0); LOG_UNLOCK(log, s); @@ -2964,7 +2957,7 @@ xlog_state_sync_all(xlog_t *log, uint fl return XFS_ERROR(EIO); *log_flushed = 1; s = LOG_LOCK(log); - if (INT_GET(iclog->ic_header.h_lsn, ARCH_CONVERT) == lsn && + if (be64_to_cpu(iclog->ic_header.h_lsn) == lsn && iclog->ic_state != XLOG_STATE_DIRTY) goto maybe_sleep; else @@ -3050,9 +3043,9 @@ try_again: } do { - if (INT_GET(iclog->ic_header.h_lsn, ARCH_CONVERT) != lsn) { - iclog = iclog->ic_next; - continue; + if (be64_to_cpu(iclog->ic_header.h_lsn) != lsn) { + iclog = iclog->ic_next; + continue; } if (iclog->ic_state == XLOG_STATE_DIRTY) { @@ -3466,18 +3459,18 @@ xlog_verify_iclog(xlog_t *log, LOG_UNLOCK(log, s); /* check log magic numbers */ - ptr = (xfs_caddr_t) &(iclog->ic_header); - if (INT_GET(*(uint *)ptr, ARCH_CONVERT) != XLOG_HEADER_MAGIC_NUM) + if (be32_to_cpu(iclog->ic_header.h_magicno) != XLOG_HEADER_MAGIC_NUM) xlog_panic("xlog_verify_iclog: invalid magic num"); - for (ptr += BBSIZE; ptr < ((xfs_caddr_t)&(iclog->ic_header))+count; + ptr = (xfs_caddr_t) &iclog->ic_header; + for (ptr += BBSIZE; ptr < ((xfs_caddr_t)&iclog->ic_header) + count; ptr += BBSIZE) { - if (INT_GET(*(uint *)ptr, ARCH_CONVERT) == XLOG_HEADER_MAGIC_NUM) + if (be32_to_cpu(*(__be32 *)ptr) == XLOG_HEADER_MAGIC_NUM) xlog_panic("xlog_verify_iclog: unexpected magic num"); } /* check fields */ - len = INT_GET(iclog->ic_header.h_num_logops, ARCH_CONVERT); + len = be32_to_cpu(iclog->ic_header.h_num_logops); ptr = iclog->ic_datap; base_ptr = ptr; ophead = (xlog_op_header_t *)ptr; @@ -3518,9 +3511,9 @@ xlog_verify_iclog(xlog_t *log, if (idx >= (XLOG_HEADER_CYCLE_SIZE / BBSIZE)) { j = idx / (XLOG_HEADER_CYCLE_SIZE / BBSIZE); k = idx % (XLOG_HEADER_CYCLE_SIZE / BBSIZE); - op_len = INT_GET(xhdr[j].hic_xheader.xh_cycle_data[k], ARCH_CONVERT); + op_len = be32_to_cpu(xhdr[j].hic_xheader.xh_cycle_data[k]); } else { - op_len = INT_GET(iclog->ic_header.h_cycle_data[idx], ARCH_CONVERT); + op_len = be32_to_cpu(iclog->ic_header.h_cycle_data[idx]); } } ptr += sizeof(xlog_op_header_t) + op_len; Index: linux-2.6-xfs/fs/xfs/xfs_log_priv.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_log_priv.h 2007-08-23 20:44:30.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_log_priv.h 2007-08-23 20:45:10.000000000 +0200 @@ -63,10 +63,10 @@ static inline xfs_lsn_t xlog_assign_lsn( static inline uint xlog_get_cycle(char *ptr) { - if (INT_GET(*(uint *)ptr, ARCH_CONVERT) == XLOG_HEADER_MAGIC_NUM) - return INT_GET(*((uint *)ptr + 1), ARCH_CONVERT); + if (be32_to_cpu(*(__be32 *)ptr) == XLOG_HEADER_MAGIC_NUM) + return be32_to_cpu(*((__be32 *)ptr + 1)); else - return INT_GET(*(uint *)ptr, ARCH_CONVERT); + return be32_to_cpu(*(__be32 *)ptr); } #define BLK_AVG(blk1, blk2) ((blk1+blk2) >> 1) @@ -85,9 +85,9 @@ static inline uint xlog_get_cycle(char * * * this has endian issues, of course. */ -static inline uint xlog_get_client_id(uint i) +static inline uint xlog_get_client_id(__be32 i) { - return INT_GET(i, ARCH_CONVERT) >> 24; + return be32_to_cpu(i) >> 24; } #define GRANT_LOCK(log) mutex_spinlock(&(log)->l_grant_lock) @@ -308,25 +308,25 @@ typedef struct xlog_op_header { #endif typedef struct xlog_rec_header { - uint h_magicno; /* log record (LR) identifier : 4 */ - uint h_cycle; /* write cycle of log : 4 */ - int h_version; /* LR version : 4 */ - int h_len; /* len in bytes; should be 64-bit aligned: 4 */ - xfs_lsn_t h_lsn; /* lsn of this LR : 8 */ - xfs_lsn_t h_tail_lsn; /* lsn of 1st LR w/ buffers not committed: 8 */ - uint h_chksum; /* may not be used; non-zero if used : 4 */ - int h_prev_block; /* block number to previous LR : 4 */ - int h_num_logops; /* number of log operations in this LR : 4 */ - uint h_cycle_data[XLOG_HEADER_CYCLE_SIZE / BBSIZE]; + __be32 h_magicno; /* log record (LR) identifier : 4 */ + __be32 h_cycle; /* write cycle of log : 4 */ + __be32 h_version; /* LR version : 4 */ + __be32 h_len; /* len in bytes; should be 64-bit aligned: 4 */ + __be64 h_lsn; /* lsn of this LR : 8 */ + __be64 h_tail_lsn; /* lsn of 1st LR w/ buffers not committed: 8 */ + __be32 h_chksum; /* may not be used; non-zero if used : 4 */ + __be32 h_prev_block; /* block number to previous LR : 4 */ + __be32 h_num_logops; /* number of log operations in this LR : 4 */ + __be32 h_cycle_data[XLOG_HEADER_CYCLE_SIZE / BBSIZE]; /* new fields */ - int h_fmt; /* format of log record : 4 */ - uuid_t h_fs_uuid; /* uuid of FS : 16 */ - int h_size; /* iclog size : 4 */ + __be32 h_fmt; /* format of log record : 4 */ + uuid_t h_fs_uuid; /* uuid of FS : 16 */ + __be32 h_size; /* iclog size : 4 */ } xlog_rec_header_t; typedef struct xlog_rec_ext_header { - uint xh_cycle; /* write cycle of log : 4 */ - uint xh_cycle_data[XLOG_HEADER_CYCLE_SIZE / BBSIZE]; /* : 256 */ + __be32 xh_cycle; /* write cycle of log : 4 */ + __be32 xh_cycle_data[XLOG_HEADER_CYCLE_SIZE / BBSIZE]; /* : 256 */ } xlog_rec_ext_header_t; #ifdef __KERNEL__ Index: linux-2.6-xfs/fs/xfs/xfs_log_recover.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_log_recover.c 2007-08-23 20:44:30.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_log_recover.c 2007-08-23 20:44:35.000000000 +0200 @@ -198,7 +198,7 @@ xlog_header_check_dump( cmn_err(CE_DEBUG, " log : uuid = "); for (b = 0; b < 16; b++) cmn_err(CE_DEBUG, "%02x",((uchar_t *)&head->h_fs_uuid)[b]); - cmn_err(CE_DEBUG, ", fmt = %d\n", INT_GET(head->h_fmt, ARCH_CONVERT)); + cmn_err(CE_DEBUG, ", fmt = %d\n", be32_to_cpu(head->h_fmt)); } #else #define xlog_header_check_dump(mp, head) @@ -212,14 +212,14 @@ xlog_header_check_recover( xfs_mount_t *mp, xlog_rec_header_t *head) { - ASSERT(INT_GET(head->h_magicno, ARCH_CONVERT) == XLOG_HEADER_MAGIC_NUM); + ASSERT(be32_to_cpu(head->h_magicno) == XLOG_HEADER_MAGIC_NUM); /* * IRIX doesn't write the h_fmt field and leaves it zeroed * (XLOG_FMT_UNKNOWN). This stops us from trying to recover * a dirty log created in IRIX. */ - if (unlikely(INT_GET(head->h_fmt, ARCH_CONVERT) != XLOG_FMT)) { + if (unlikely(be32_to_cpu(head->h_fmt) != XLOG_FMT)) { xlog_warn( "XFS: dirty log written in incompatible format - can't recover"); xlog_header_check_dump(mp, head); @@ -245,7 +245,7 @@ xlog_header_check_mount( xfs_mount_t *mp, xlog_rec_header_t *head) { - ASSERT(INT_GET(head->h_magicno, ARCH_CONVERT) == XLOG_HEADER_MAGIC_NUM); + ASSERT(be32_to_cpu(head->h_magicno) == XLOG_HEADER_MAGIC_NUM); if (uuid_is_nil(&head->h_fs_uuid)) { /* @@ -447,8 +447,7 @@ xlog_find_verify_log_record( head = (xlog_rec_header_t *)offset; - if (XLOG_HEADER_MAGIC_NUM == - INT_GET(head->h_magicno, ARCH_CONVERT)) + if (XLOG_HEADER_MAGIC_NUM == be32_to_cpu(head->h_magicno)) break; if (!smallmem) @@ -480,7 +479,7 @@ xlog_find_verify_log_record( * record do we update last_blk. */ if (XFS_SB_VERSION_HASLOGV2(&log->l_mp->m_sb)) { - uint h_size = INT_GET(head->h_size, ARCH_CONVERT); + uint h_size = be32_to_cpu(head->h_size); xhdrs = h_size / XLOG_HEADER_CYCLE_SIZE; if (h_size % XLOG_HEADER_CYCLE_SIZE) @@ -489,8 +488,8 @@ xlog_find_verify_log_record( xhdrs = 1; } - if (*last_blk - i + extra_bblks - != BTOBB(INT_GET(head->h_len, ARCH_CONVERT)) + xhdrs) + if (*last_blk - i + extra_bblks != + BTOBB(be32_to_cpu(head->h_len)) + xhdrs) *last_blk = i; out: @@ -823,8 +822,7 @@ xlog_find_tail( if ((error = xlog_bread(log, i, 1, bp))) goto bread_err; offset = xlog_align(log, i, 1, bp); - if (XLOG_HEADER_MAGIC_NUM == - INT_GET(*(uint *)offset, ARCH_CONVERT)) { + if (XLOG_HEADER_MAGIC_NUM == be32_to_cpu(*(__be32 *)offset)) { found = 1; break; } @@ -841,7 +839,7 @@ xlog_find_tail( goto bread_err; offset = xlog_align(log, i, 1, bp); if (XLOG_HEADER_MAGIC_NUM == - INT_GET(*(uint*)offset, ARCH_CONVERT)) { + be32_to_cpu(*(__be32 *)offset)) { found = 2; break; } @@ -855,7 +853,7 @@ xlog_find_tail( /* find blk_no of tail of log */ rhead = (xlog_rec_header_t *)offset; - *tail_blk = BLOCK_LSN(INT_GET(rhead->h_tail_lsn, ARCH_CONVERT)); + *tail_blk = BLOCK_LSN(be64_to_cpu(rhead->h_tail_lsn)); /* * Reset log values according to the state of the log when we @@ -869,11 +867,11 @@ xlog_find_tail( */ log->l_prev_block = i; log->l_curr_block = (int)*head_blk; - log->l_curr_cycle = INT_GET(rhead->h_cycle, ARCH_CONVERT); + log->l_curr_cycle = be32_to_cpu(rhead->h_cycle); if (found == 2) log->l_curr_cycle++; - log->l_tail_lsn = INT_GET(rhead->h_tail_lsn, ARCH_CONVERT); - log->l_last_sync_lsn = INT_GET(rhead->h_lsn, ARCH_CONVERT); + log->l_tail_lsn = be64_to_cpu(rhead->h_tail_lsn); + log->l_last_sync_lsn = be64_to_cpu(rhead->h_lsn); log->l_grant_reserve_cycle = log->l_curr_cycle; log->l_grant_reserve_bytes = BBTOB(log->l_curr_block); log->l_grant_write_cycle = log->l_curr_cycle; @@ -891,8 +889,8 @@ xlog_find_tail( * unmount record rather than the block after it. */ if (XFS_SB_VERSION_HASLOGV2(&log->l_mp->m_sb)) { - int h_size = INT_GET(rhead->h_size, ARCH_CONVERT); - int h_version = INT_GET(rhead->h_version, ARCH_CONVERT); + int h_size = be32_to_cpu(rhead->h_size); + int h_version = be32_to_cpu(rhead->h_version); if ((h_version & XLOG_VERSION_2) && (h_size > XLOG_HEADER_CYCLE_SIZE)) { @@ -906,10 +904,10 @@ xlog_find_tail( hblks = 1; } after_umount_blk = (i + hblks + (int) - BTOBB(INT_GET(rhead->h_len, ARCH_CONVERT))) % log->l_logBBsize; + BTOBB(be32_to_cpu(rhead->h_len))) % log->l_logBBsize; tail_lsn = log->l_tail_lsn; if (*head_blk == after_umount_blk && - INT_GET(rhead->h_num_logops, ARCH_CONVERT) == 1) { + be32_to_cpu(rhead->h_num_logops) == 1) { umount_data_blk = (i + hblks) % log->l_logBBsize; if ((error = xlog_bread(log, umount_data_blk, 1, bp))) { goto bread_err; @@ -1100,14 +1098,13 @@ xlog_add_record( xlog_rec_header_t *recp = (xlog_rec_header_t *)buf; memset(buf, 0, BBSIZE); - INT_SET(recp->h_magicno, ARCH_CONVERT, XLOG_HEADER_MAGIC_NUM); - INT_SET(recp->h_cycle, ARCH_CONVERT, cycle); - INT_SET(recp->h_version, ARCH_CONVERT, + recp->h_magicno = cpu_to_be32(XLOG_HEADER_MAGIC_NUM); + recp->h_cycle = cpu_to_be32(cycle); + recp->h_version = cpu_to_be32( XFS_SB_VERSION_HASLOGV2(&log->l_mp->m_sb) ? 2 : 1); - INT_SET(recp->h_lsn, ARCH_CONVERT, xlog_assign_lsn(cycle, block)); - INT_SET(recp->h_tail_lsn, ARCH_CONVERT, - xlog_assign_lsn(tail_cycle, tail_block)); - INT_SET(recp->h_fmt, ARCH_CONVERT, XLOG_FMT); + recp->h_lsn = cpu_to_be64(xlog_assign_lsn(cycle, block)); + recp->h_tail_lsn = cpu_to_be64(xlog_assign_lsn(tail_cycle, tail_block)); + recp->h_fmt = cpu_to_be32(XLOG_FMT); memcpy(&recp->h_fs_uuid, &log->l_mp->m_sb.sb_uuid, sizeof(uuid_t)); } @@ -2214,7 +2211,7 @@ xlog_recover_do_buffer_trans( * overlap with future reads of those inodes. */ if (XFS_DINODE_MAGIC == - INT_GET(*((__uint16_t *)(xfs_buf_offset(bp, 0))), ARCH_CONVERT) && + be16_to_cpu(*((__be16 *)xfs_buf_offset(bp, 0))) && (XFS_BUF_COUNT(bp) != MAX(log->l_mp->m_sb.sb_blocksize, (__uint32_t)XFS_INODE_CLUSTER_SIZE(log->l_mp)))) { XFS_BUF_STALE(bp); @@ -2584,8 +2581,7 @@ xlog_recover_do_dquot_trans( /* * This type of quotas was turned off, so ignore this record. */ - type = INT_GET(recddq->d_flags, ARCH_CONVERT) & - (XFS_DQ_USER | XFS_DQ_PROJ | XFS_DQ_GROUP); + type = recddq->d_flags & (XFS_DQ_USER | XFS_DQ_PROJ | XFS_DQ_GROUP); ASSERT(type); if (log->l_quotaoffs_flag & type) return (0); @@ -2900,8 +2896,8 @@ xlog_recover_process_data( unsigned long hash; uint flags; - lp = dp + INT_GET(rhead->h_len, ARCH_CONVERT); - num_logops = INT_GET(rhead->h_num_logops, ARCH_CONVERT); + lp = dp + be32_to_cpu(rhead->h_len); + num_logops = be32_to_cpu(rhead->h_num_logops); /* check the log format matches our own - else we can't recover */ if (xlog_header_check_recover(log->l_mp, rhead)) @@ -2924,7 +2920,7 @@ xlog_recover_process_data( if (trans == NULL) { /* not found; add new tid */ if (ohead->oh_flags & XLOG_START_TRANS) xlog_recover_new_tid(&rhash[hash], tid, - INT_GET(rhead->h_lsn, ARCH_CONVERT)); + be64_to_cpu(rhead->h_lsn)); } else { ASSERT(dp + be32_to_cpu(ohead->oh_len) <= lp); flags = ohead->oh_flags & ~XLOG_END_TRANS; @@ -3316,16 +3312,16 @@ xlog_pack_data_checksum( int size) { int i; - uint *up; + __be32 *up; uint chksum = 0; - up = (uint *)iclog->ic_datap; + up = (__be32 *)iclog->ic_datap; /* divide length by 4 to get # words */ for (i = 0; i < (size >> 2); i++) { - chksum ^= INT_GET(*up, ARCH_CONVERT); + chksum ^= be32_to_cpu(*up); up++; } - INT_SET(iclog->ic_header.h_chksum, ARCH_CONVERT, chksum); + iclog->ic_header.h_chksum = cpu_to_be32(chksum); } #else #define xlog_pack_data_checksum(log, iclog, size) @@ -3342,7 +3338,7 @@ xlog_pack_data( { int i, j, k; int size = iclog->ic_offset + roundoff; - uint cycle_lsn; + __be32 cycle_lsn; xfs_caddr_t dp; xlog_in_core_2_t *xhdr; @@ -3353,8 +3349,8 @@ xlog_pack_data( dp = iclog->ic_datap; for (i = 0; i < BTOBB(size) && i < (XLOG_HEADER_CYCLE_SIZE / BBSIZE); i++) { - iclog->ic_header.h_cycle_data[i] = *(uint *)dp; - *(uint *)dp = cycle_lsn; + iclog->ic_header.h_cycle_data[i] = *(__be32 *)dp; + *(__be32 *)dp = cycle_lsn; dp += BBSIZE; } @@ -3363,8 +3359,8 @@ xlog_pack_data( for ( ; i < BTOBB(size); i++) { j = i / (XLOG_HEADER_CYCLE_SIZE / BBSIZE); k = i % (XLOG_HEADER_CYCLE_SIZE / BBSIZE); - xhdr[j].hic_xheader.xh_cycle_data[k] = *(uint *)dp; - *(uint *)dp = cycle_lsn; + xhdr[j].hic_xheader.xh_cycle_data[k] = *(__be32 *)dp; + *(__be32 *)dp = cycle_lsn; dp += BBSIZE; } @@ -3381,21 +3377,21 @@ xlog_unpack_data_checksum( xfs_caddr_t dp, xlog_t *log) { - uint *up = (uint *)dp; + __be32 *up = (__be32 *)dp; uint chksum = 0; int i; /* divide length by 4 to get # words */ - for (i=0; i < INT_GET(rhead->h_len, ARCH_CONVERT) >> 2; i++) { - chksum ^= INT_GET(*up, ARCH_CONVERT); + for (i=0; i < be32_to_cpu(rhead->h_len) >> 2; i++) { + chksum ^= be32_to_cpu(*up); up++; } - if (chksum != INT_GET(rhead->h_chksum, ARCH_CONVERT)) { + if (chksum != be32_to_cpu(rhead->h_chksum)) { if (rhead->h_chksum || ((log->l_flags & XLOG_CHKSUM_MISMATCH) == 0)) { cmn_err(CE_DEBUG, "XFS: LogR chksum mismatch: was (0x%x) is (0x%x)\n", - INT_GET(rhead->h_chksum, ARCH_CONVERT), chksum); + be32_to_cpu(rhead->h_chksum), chksum); cmn_err(CE_DEBUG, "XFS: Disregard message if filesystem was created with non-DEBUG kernel"); if (XFS_SB_VERSION_HASLOGV2(&log->l_mp->m_sb)) { @@ -3419,18 +3415,18 @@ xlog_unpack_data( int i, j, k; xlog_in_core_2_t *xhdr; - for (i = 0; i < BTOBB(INT_GET(rhead->h_len, ARCH_CONVERT)) && + for (i = 0; i < BTOBB(be32_to_cpu(rhead->h_len)) && i < (XLOG_HEADER_CYCLE_SIZE / BBSIZE); i++) { - *(uint *)dp = *(uint *)&rhead->h_cycle_data[i]; + *(__be32 *)dp = *(__be32 *)&rhead->h_cycle_data[i]; dp += BBSIZE; } if (XFS_SB_VERSION_HASLOGV2(&log->l_mp->m_sb)) { xhdr = (xlog_in_core_2_t *)rhead; - for ( ; i < BTOBB(INT_GET(rhead->h_len, ARCH_CONVERT)); i++) { + for ( ; i < BTOBB(be32_to_cpu(rhead->h_len)); i++) { j = i / (XLOG_HEADER_CYCLE_SIZE / BBSIZE); k = i % (XLOG_HEADER_CYCLE_SIZE / BBSIZE); - *(uint *)dp = xhdr[j].hic_xheader.xh_cycle_data[k]; + *(__be32 *)dp = xhdr[j].hic_xheader.xh_cycle_data[k]; dp += BBSIZE; } } @@ -3446,24 +3442,21 @@ xlog_valid_rec_header( { int hlen; - if (unlikely( - (INT_GET(rhead->h_magicno, ARCH_CONVERT) != - XLOG_HEADER_MAGIC_NUM))) { + if (unlikely(be32_to_cpu(rhead->h_magicno) != XLOG_HEADER_MAGIC_NUM)) { XFS_ERROR_REPORT("xlog_valid_rec_header(1)", XFS_ERRLEVEL_LOW, log->l_mp); return XFS_ERROR(EFSCORRUPTED); } if (unlikely( (!rhead->h_version || - (INT_GET(rhead->h_version, ARCH_CONVERT) & - (~XLOG_VERSION_OKBITS)) != 0))) { + (be32_to_cpu(rhead->h_version) & (~XLOG_VERSION_OKBITS))))) { xlog_warn("XFS: %s: unrecognised log version (%d).", - __FUNCTION__, INT_GET(rhead->h_version, ARCH_CONVERT)); + __FUNCTION__, be32_to_cpu(rhead->h_version)); return XFS_ERROR(EIO); } /* LR body must have data or it wouldn't have been written */ - hlen = INT_GET(rhead->h_len, ARCH_CONVERT); + hlen = be32_to_cpu(rhead->h_len); if (unlikely( hlen <= 0 || hlen > INT_MAX )) { XFS_ERROR_REPORT("xlog_valid_rec_header(2)", XFS_ERRLEVEL_LOW, log->l_mp); @@ -3523,9 +3516,8 @@ xlog_do_recovery_pass( error = xlog_valid_rec_header(log, rhead, tail_blk); if (error) goto bread_err1; - h_size = INT_GET(rhead->h_size, ARCH_CONVERT); - if ((INT_GET(rhead->h_version, ARCH_CONVERT) - & XLOG_VERSION_2) && + h_size = be32_to_cpu(rhead->h_size); + if ((be32_to_cpu(rhead->h_version) & XLOG_VERSION_2) && (h_size > XLOG_HEADER_CYCLE_SIZE)) { hblks = h_size / XLOG_HEADER_CYCLE_SIZE; if (h_size % XLOG_HEADER_CYCLE_SIZE) @@ -3562,7 +3554,7 @@ xlog_do_recovery_pass( goto bread_err2; /* blocks in data section */ - bblks = (int)BTOBB(INT_GET(rhead->h_len, ARCH_CONVERT)); + bblks = (int)BTOBB(be32_to_cpu(rhead->h_len)); error = xlog_bread(log, blk_no + hblks, bblks, dbp); if (error) goto bread_err2; @@ -3637,7 +3629,7 @@ xlog_do_recovery_pass( if (error) goto bread_err2; - bblks = (int)BTOBB(INT_GET(rhead->h_len, ARCH_CONVERT)); + bblks = (int)BTOBB(be32_to_cpu(rhead->h_len)); blk_no += hblks; /* Read in data for log record */ @@ -3708,7 +3700,7 @@ xlog_do_recovery_pass( error = xlog_valid_rec_header(log, rhead, blk_no); if (error) goto bread_err2; - bblks = (int)BTOBB(INT_GET(rhead->h_len, ARCH_CONVERT)); + bblks = (int)BTOBB(be32_to_cpu(rhead->h_len)); if ((error = xlog_bread(log, blk_no+hblks, bblks, dbp))) goto bread_err2; offset = xlog_align(log, blk_no+hblks, bblks, dbp); Index: linux-2.6-xfs/fs/xfs/xfsidbg.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfsidbg.c 2007-08-23 19:37:43.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfsidbg.c 2007-08-23 20:44:35.000000000 +0200 @@ -5765,17 +5765,21 @@ xfsidbg_xiclog(xlog_in_core_t *iclog) kdb_printf("xlog_in_core/header at 0x%p/0x%p\n", iclog, iclog->hic_data); kdb_printf("magicno: %x cycle: %d version: %d lsn: 0x%Lx\n", - INT_GET(iclog->ic_header.h_magicno, ARCH_CONVERT), INT_GET(iclog->ic_header.h_cycle, ARCH_CONVERT), - INT_GET(iclog->ic_header.h_version, ARCH_CONVERT), INT_GET(iclog->ic_header.h_lsn, ARCH_CONVERT)); + be32_to_cpu(iclog->ic_header.h_magicno), + be32_to_cpu(iclog->ic_header.h_cycle), + be32_to_cpu(iclog->ic_header.h_version), + be64_to_cpu(iclog->ic_header.h_lsn)); kdb_printf("tail_lsn: 0x%Lx len: %d prev_block: %d num_ops: %d\n", - INT_GET(iclog->ic_header.h_tail_lsn, ARCH_CONVERT), INT_GET(iclog->ic_header.h_len, ARCH_CONVERT), - INT_GET(iclog->ic_header.h_prev_block, ARCH_CONVERT), INT_GET(iclog->ic_header.h_num_logops, ARCH_CONVERT)); + be64_to_cpu(iclog->ic_header.h_tail_lsn), + be32_to_cpu(iclog->ic_header.h_len), + be32_to_cpu(iclog->ic_header.h_prev_block), + be32_to_cpu(iclog->ic_header.h_num_logops)); kdb_printf("cycle_data: "); for (i=0; i<(iclog->ic_size>>BBSHIFT); i++) { - kdb_printf("%x ", INT_GET(iclog->ic_header.h_cycle_data[i], ARCH_CONVERT)); + kdb_printf("%x ", be32_to_cpu(iclog->ic_header.h_cycle_data[i])); } kdb_printf("\n"); - kdb_printf("size: %d\n", INT_GET(iclog->ic_header.h_size, ARCH_CONVERT)); + kdb_printf("size: %d\n", be32_to_cpu(iclog->ic_header.h_size)); kdb_printf("\n"); kdb_printf("--------------------------------------------------\n"); kdb_printf("data: 0x%p &forcesema: 0x%p next: 0x%p bp: 0x%p\n", Index: linux-2.6-xfs/fs/xfs/xfs_log.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_log.h 2007-07-29 14:34:45.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_log.h 2007-08-23 20:44:35.000000000 +0200 @@ -22,8 +22,9 @@ #define CYCLE_LSN(lsn) ((uint)((lsn)>>32)) #define BLOCK_LSN(lsn) ((uint)(lsn)) + /* this is used in a spot where we might otherwise double-endian-flip */ -#define CYCLE_LSN_DISK(lsn) (((uint *)&(lsn))[0]) +#define CYCLE_LSN_DISK(lsn) (((__be32 *)&(lsn))[0]) #ifdef __KERNEL__ /* From owner-xfs@oss.sgi.com Sun Sep 23 00:45:10 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 23 Sep 2007 00:45: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.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 l8N7j7Q3014794 for ; Sun, 23 Sep 2007 00:45:09 -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 RAA16548; Sun, 23 Sep 2007 17:45:07 +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 l8N7j4dD34713682; Sun, 23 Sep 2007 17:45:05 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l8N7j0ns34754829; Sun, 23 Sep 2007 17:45:00 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Sun, 23 Sep 2007 17:45:00 +1000 From: David Chinner To: Ming Zhang Cc: David Chinner , Leon Kolchinsky , "'Hxsrmeng'" , xfs@oss.sgi.com Subject: Re: Review: Concurrent Multi-File Data Streams Message-ID: <20070923074500.GO995458@sgi.com> References: <12789210.post@talk.nabble.com> <20070921091441.3ABB88E0B@mail.edu.haifa.ac.il> <20070921125531.GM995458@sgi.com> <1190399077.3795.86.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1190399077.3795.86.camel@localhost.localdomain> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13039 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 21, 2007 at 02:24:37PM -0400, Ming Zhang wrote: > On Fri, 2007-09-21 at 22:55 +1000, David Chinner wrote: > > On Fri, Sep 21, 2007 at 11:13:33AM +0200, Leon Kolchinsky wrote: > > > I'm running DSS (Darwin Streaming Server) on one of my servers and that > > > "Concurrent Multi-File Data Streams" thing seems very interesting :) > > > > Filestreams is needed to optimise concurrent *ingest* of data, > > not playout. > > > > i.e. if you are ingesting multiple real-time streams of data at the > > same time as you are playing out real-time streams and you area > > missing playout deadlines (i.e. dropping frames) due to sub-optimal > > data layout, then it might help you..... > > > > > I have a separate partition there I store all movies. > > > Is 2.6.22 kernel already has this patch incorporated already(actually > > > gentoo-sources-2.6.22-r5)? > > > > It went into .22 so you should have it. > > i did not see xfs_filestream.c in 2.6.22.6 yet. did i miss something > here? No, my mistake - it seems so long since I checked it in. it went into 2.6.23-rc1.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sun Sep 23 00:58:04 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 23 Sep 2007 00:58: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.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 l8N7vxQ3017177 for ; Sun, 23 Sep 2007 00:58:03 -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 RAA16693; Sun, 23 Sep 2007 17:57:59 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l8N7vwdD34554893; Sun, 23 Sep 2007 17:57:59 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l8N7vuP634658006; Sun, 23 Sep 2007 17:57:56 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Sun, 23 Sep 2007 17:57:56 +1000 From: David Chinner To: Eric Sandeen Cc: David Chinner , xfs-dev , xfs-oss Subject: Re: [PATCH 4 of 4] Restore ihashsize mount option as deprecated Message-ID: <20070923075756.GP995458@sgi.com> References: <20070809114548.GG12413810@sgi.com> <46F4390A.5070407@sandeen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46F4390A.5070407@sandeen.net> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13040 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 21, 2007 at 04:35:06PM -0500, Eric Sandeen wrote: > David Chinner wrote: > > > The ihashsize option should remain so that filesystems with > > this set don't fail to mount. Ignore the mount option value > > and issue a deprecation warning to syslog. > > > > Update the ihashsize mount option documentation to indicate this > > behaviour. Update the ikeep/noikeep mount option documentation > > while we are there. > > > > > Hm, but shouldn't some of these mount struct items go too, now? Yes. I thought I killed them - must have missed them in some of the patch juggling I had to do at one point. > (I may go looking for more unused struct members for fun if I have > time...) > > ------------- > > Remove unused xfs_mount and xfs_mount_args structure members > post radix-tree conversion. > > Signed-off-by: Eric Sandeen Looks ok to me... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sun Sep 23 01:31:59 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 23 Sep 2007 01:32:03 -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=BAYES_50,J_CHICKENPOX_43 autolearn=no version=3.2.0-pre1-r499012 Received: from mail.edu.haifa.ac.il (mail.edu.haifa.ac.il [132.74.40.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8N8VvQ3022440 for ; Sun, 23 Sep 2007 01:31:59 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.edu.haifa.ac.il (Postfix) with ESMTP id 6FE3014EC2F; Sun, 23 Sep 2007 10:32:14 +0200 (IST) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Scanned: amavisd-new at edu.haifa.ac.il Received: from mail.edu.haifa.ac.il ([127.0.0.1]) by localhost (mail.edu.haifa.ac.il [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id tX5w6963my2Q; Sun, 23 Sep 2007 10:32:14 +0200 (IST) Received: from kozanostra (leon.edu.haifa.ac.il [132.74.41.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.edu.haifa.ac.il (Postfix) with ESMTP id 3D5018E1B; Sun, 23 Sep 2007 10:32:14 +0200 (IST) From: "Leon Kolchinsky" To: "'Leon Kolchinsky'" , Subject: RE: Tips on xfs creation on MIPS R5000 machine running Linux? Date: Sun, 23 Sep 2007 10:30:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acf6mdps1LQ7z9oBSJupPr4e3J1ZRgDIe6QQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <20070919084929.0146ADE43@mail.edu.haifa.ac.il> Message-Id: <20070923083214.3D5018E1B@mail.edu.haifa.ac.il> X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id l8N8VxQ3022448 X-archive-position: 13041 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: leonk@construct.haifa.ac.il Precedence: bulk X-list: xfs > Hello All, > > > Finally I've got my hands on some nice R5000 Model O2 machine with IRIX > 6.5 > on it. > > # hinv > CPU: MIPS R5000 Processor Chip Revision: 2.1 > FPU: MIPS R5000 Floating Point Coprocessor Revision: 1.0 > 1 180 MHZ IP32 Processor > Main memory size: 256 Mbytes > Secondary unified instruction/data cache size: 512 Kbytes on Processor 0 > Instruction cache size: 32 Kbytes > Data cache size: 32 Kbytes > FLASH PROM version 4.13 > Integral SCSI controller 0: Version ADAPTEC 7880 > Disk drive: unit 1 on SCSI controller 0 > Disk drive: unit 2 on SCSI controller 0 > CDROM: unit 4 on SCSI controller 0 > Integral SCSI controller 1: Version ADAPTEC 7880 > On-board serial ports: tty1 > On-board serial ports: tty2 > On-board EPP/ECP parallel port > CRM graphics installed > Integral Ethernet: ec0, version 1 > Iris Audio Processor: version A3 revision 0 > Video: MVP unit 0 version 1.4 > AV: AV1 Card version 1, O2Cam type 1 version 0 connected. > Vice: TRE > > I'm intending to install Gentoo on this machine and I need some advice. > > Following are the commands I've used to create and mount my partitions on > some old x86 PC. > a) Should I use the same values for all partitions on R5000 ? > > 1) Creating FS: > mkfs.xfs -l internal,size=128m -d agcount=2 –d unwritten=0 /dev/hda1 > > 2) Mount options: > mount -o noatime,nodiratime,logbufs=8 > > Any suggestion for best performance configuration for XFS on this machine? > > b) If I'd like to replace the old 2GB disk to some new 80GB disk. Would > PROM > recognize it? Is there any special procedure? > > c) Anyone has any experience with Gentoo on MIPS as a desktop system > (performance, device recognition (i.e. webcam) etc.)? > > > Best Regards, > Leon Kolchinsky No takers here? There are some former and current SGI people on the list who have some information on the above topic. Could you shed some light on it please? Regards, Leon From owner-xfs@oss.sgi.com Sun Sep 23 02:24:54 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 23 Sep 2007 02:24: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.4 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 l8N9OoQ3031430 for ; Sun, 23 Sep 2007 02:24:52 -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 TAA17916; Sun, 23 Sep 2007 19:24:47 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l8N9OkdD33626652; Sun, 23 Sep 2007 19:24:46 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l8N9Oi0g34801844; Sun, 23 Sep 2007 19:24:44 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Sun, 23 Sep 2007 19:24:44 +1000 From: David Chinner To: Eric Sandeen Cc: xfs-oss Subject: Re: something very strange w/ filestreams... Message-ID: <20070923092444.GQ995458@sgi.com> References: <46F49C80.60007@sandeen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46F49C80.60007@sandeen.net> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13042 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 21, 2007 at 11:39:28PM -0500, Eric Sandeen wrote: > if I do: > > for I in 173 174 178; do ./check $I; done > > it's not terribly interesting, things seem to go ok, just normal > filestreams failures ;-) > > if I do: > > ./check 173 174 178 > > things go very badly; the very first repair in 178 finds a horribly > corrupted filesystem, and repair tips over (memory appears corrupted, as > witnessed by): Well, i get: budgie:~/dgc/xfstests # ./check -l 173 174 178 FSTYP -- xfs (debug) PLATFORM -- Linux/ia64 budgie 2.6.23-rc4-dgc-xfs MKFS_OPTIONS -- -f -bsize=4096 /dev/sdb9 MOUNT_OPTIONS -- /dev/sdb9 /mnt/scratch 173 75s ... 174 16s ... 178 *** glibc detected *** /sbin/xfs_repair: double free or corruption (!prev): 0x600000000000ebc0 *** ======= Backtrace: ========= /lib/libc.so.6.1[0x20000000001a2f50] /lib/libc.so.6.1(__libc_free+0x15f0e8)[0x20000000001a6ce0] /sbin/xfs_repair[0x40000000000320e0] /sbin/xfs_repair[0x4000000000043a90] /sbin/xfs_repair[0x400000000006d230] /lib/libc.so.6.1(__libc_start_main+0xb4018)[0x20000000000fbc20] /sbin/xfs_repair[0x4000000000003520] ======= Memory map: ======== ..... Just executing ./check -l 174 178 isn't sufficient, but ./check -l 172 174 178 triggers it. 172,173,178 does not trigger it, so it's something to do with test 174 running after another filestreams test but before 178. Well, what does test 178 do? Oh, it mkfs's a new filesystem on the scratch device and then hoses the superblock and tries to use secondary superblocks to reconstruct it successfully. I'm guessing that it is finding a superblock from a previous test and incorrectly using that, finding stuff all nasty and inconsistent due to the more recent mkfs.... Given this error: bad length 156382 for agf 0, should be LENGTH bad length # 156382 for agi 0, should be LENGTH I think that is what is happening - those messages only come up when teh agf/agi lengths don't match the superblock, and that points to using the wrong superblock for recovery. Especially as: # mkfs.xfs -f /dev/sdb9 meta-data=/dev/sdb9 isize=256 agcount=8, agsize=156382 blks = sectsz=512 attr=0 data = bsize=4096 blocks=1251056, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=2560, version=1 = sectsz=512 sunit=0 blks, lazy-count=0 realtime =none extsz=4096 blocks=0, rtextents=0 An AG length of 156382 is correct. Hmmm - just a plain: # ./check -l 172 174 ; mkfs.xfs -f /dev/sdb9; dd if=/dev/zero of=/dev/sdb9 bs=512 count=1 ; xfs_repair /dev/sdb9 reproduces the problem. Barry - I think xfs_repair might be finding the incorrect superblock for the repair. Tests 172, 173 and 174 use less than the whole disk, so there are going to be stale superblocks all over the place.... > hm, no zone name, length of 0x22222274? > > I already provided a metadump image to Barry, but I wonder why the > timing(?) seems to make a difference here... first sign of things going > awry in repair is: > > Phase 2 - using internal log > - zero log... > - scan filesystem freespace and inode maps... > bad length 131072 for agf 0, should be 4096 > bad length # 131072 for agi 0, should be 4096 Yes - test 173 uses 1GB filesystem with 64x16MB AGs - 4096 * 4k block size = 16MB AG. definitely looks like a stale superblock being found. Barry, I think that the secondary superblock needs better verification (e.g. that there really are AG headers where the sb says there are supposed to be and all the lengths match up). Eric - you can relax. Filestreams is not hosing your filesystem; xfs_reapir is.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sun Sep 23 02:54:27 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 23 Sep 2007 02:54: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=0.8 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_43 autolearn=no version=3.2.0-pre1-r499012 Received: from stlx01.stz-softwaretechnik.com (stz-softwaretechnik.de [217.160.223.211]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8N9sNQ3003526 for ; Sun, 23 Sep 2007 02:54:26 -0700 Received: from rg by stlx01.stz-softwaretechnik.com with local (Exim 3.36 #1 (Debian)) id 1IZNvP-0001e5-00 for ; Sun, 23 Sep 2007 11:38:51 +0200 Date: Sun, 23 Sep 2007 11:38:41 +0200 From: Ralf Gross To: linux-xfs@oss.sgi.com Subject: mkfs options for a 16x hw raid5 and xfs (mostly large files) Message-ID: <20070923093841.GH19983@p15145560.pureserver.info> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13043 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Ralf-Lists@ralfgross.de Precedence: bulk X-list: xfs Hi, we have a new large raid array, the shelf has 48 disks, the max. amount of disks in a single raid 5 set is 16. There will be one global spare disk, thus we have two raid 5 with 15 data disks and one with 14 data disk. The data on these raid sets will be video data + some meta data. Typically each set of data consist of a 2 GB + 500 MB + 100 MB + 20 KB +2 KB file. There will be some dozen of these sets in a single directory - but not many hundred or thousend. Often the data will be transfernd from the windows clients to the server in some parallel copy jobs at night (eg. 5-10, for each new data directory). The clients will access the data later (mostly) read only, the data will not be changed after it was stored on the file server. Each client then needs a data stream of about 17 MB/s (max. 5 clients are expected to acces the data in parallel). I expect the fs, each will have a size of 10-11 TB, to be filled > 90%. I know this is not ideal, but we need every GB we can get. I already played with different mkfs.xfs options (sw, su) but didn't see much of a difference. The volume sets of the hw raid have the following parameters: 11,xx TB (15 data disks): Chunk Size : 64 KB (values of 64/128/256 KB are possible, I'll try 256 KB next week) Stripe Size : 960 KB (15 x 64 KM) or 10,xx TB (14 data disks): Chunk Size : 64 KB Stripe Size : 896 KB (14 x 64 KB) The created logical volumes have a block size of 512 bytes (the only possible value). Any ideas what options I should use for mkfs.xfs? At the moment I get about 150 MB/s in seq. writing (tiobench) and 160 MB/s in seq. reading. This is ok, but I'm curious what I could get with tuned xfs parameters. The system is running debian etch (amd64) with 16 GB of RAM. The raid array is connect to the server by fibre channel. Ralf From owner-xfs@oss.sgi.com Sun Sep 23 03:26:58 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 23 Sep 2007 03:27: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.5 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 l8NAQtQ3007923 for ; Sun, 23 Sep 2007 03:26:57 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1IZOGV-0001Ov-Bo; Sun, 23 Sep 2007 11:00:39 +0100 Date: Sun, 23 Sep 2007 11:00:39 +0100 From: Christoph Hellwig To: David Chinner Cc: Eric Sandeen , xfs-dev , xfs-oss Subject: Re: [PATCH 4 of 4] Restore ihashsize mount option as deprecated Message-ID: <20070923100039.GA5370@infradead.org> References: <20070809114548.GG12413810@sgi.com> <46F4390A.5070407@sandeen.net> <20070923075756.GP995458@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070923075756.GP995458@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-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13044 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 Did anyone but Dave get Eric's original message? It seems to not have made it to the list. From owner-xfs@oss.sgi.com Sun Sep 23 04:42:08 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 23 Sep 2007 04:42:11 -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,J_CHICKENPOX_64 autolearn=no 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 l8NBg5Q3022702 for ; Sun, 23 Sep 2007 04:42: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 l8NBg7A5009650 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 23 Sep 2007 13:42:07 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8NBg6o0009647 for xfs@oss.sgi.com; Sun, 23 Sep 2007 13:42:06 +0200 Date: Sun, 23 Sep 2007 13:42:06 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: [PATCH] cleanup vnode useage in xfs_ioctl.c Message-ID: <20070923114206.GA9585@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-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13045 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 xfs_ioctl.c passes around vnode pointers quite a lot, but all places already have the Linux inode which is identical to the vnode these days. Clean the code up to always use the Linux inode. Note: this requires '[PATCH 4/4] avoid xfs_getattr in XFS_IOC_FSGETXATTR ioctl' applied first. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ioctl.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ioctl.c 2007-09-19 18:49:59.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ioctl.c 2007-09-19 18:51:21.000000000 +0200 @@ -75,7 +75,6 @@ xfs_find_handle( xfs_handle_t handle; xfs_fsop_handlereq_t hreq; struct inode *inode; - bhv_vnode_t *vp; if (copy_from_user(&hreq, arg, sizeof(hreq))) return -XFS_ERROR(EFAULT); @@ -134,21 +133,16 @@ xfs_find_handle( return -XFS_ERROR(EBADF); } - /* we need the vnode */ - vp = vn_from_inode(inode); - /* now we can grab the fsid */ memcpy(&handle.ha_fsid, XFS_I(inode)->i_mount->m_fixedfsid, sizeof(xfs_fsid_t)); hsize = sizeof(xfs_fsid_t); if (cmd != XFS_IOC_PATH_TO_FSHANDLE) { - xfs_inode_t *ip; + xfs_inode_t *ip = XFS_I(inode); int lock_mode; /* need to get access to the xfs_inode to read the generation */ - ip = xfs_vtoi(vp); - ASSERT(ip); lock_mode = xfs_ilock_map_shared(ip); /* fill in fid section of handle from inode */ @@ -176,21 +170,19 @@ xfs_find_handle( /* - * Convert userspace handle data into vnode (and inode). - * We [ab]use the fact that all the fsop_handlereq ioctl calls - * have a data structure argument whose first component is always - * a xfs_fsop_handlereq_t, so we can cast to and from this type. - * This allows us to optimise the copy_from_user calls and gives - * a handy, shared routine. + * Convert userspace handle data into inode. + * + * We use the fact that all the fsop_handlereq ioctl calls have a data + * structure argument whose first component is always a xfs_fsop_handlereq_t, + * so we can pass that sub structure into this handy, shared routine. * - * If no error, caller must always VN_RELE the returned vp. + * If no error, caller must always iput the returned inode. */ STATIC int xfs_vget_fsop_handlereq( xfs_mount_t *mp, struct inode *parinode, /* parent inode pointer */ xfs_fsop_handlereq_t *hreq, - bhv_vnode_t **vp, struct inode **inode) { void __user *hanp; @@ -199,8 +191,6 @@ xfs_vget_fsop_handlereq( xfs_handle_t *handlep; xfs_handle_t handle; xfs_inode_t *ip; - struct inode *inodep; - bhv_vnode_t *vpp; xfs_ino_t ino; __u32 igen; int error; @@ -241,7 +231,7 @@ xfs_vget_fsop_handlereq( } /* - * Get the XFS inode, building a vnode to go with it. + * Get the XFS inode, building a Linux inode to go with it. */ error = xfs_iget(mp, NULL, ino, 0, XFS_ILOCK_SHARED, &ip, 0); if (error) @@ -253,12 +243,9 @@ xfs_vget_fsop_handlereq( return XFS_ERROR(ENOENT); } - vpp = XFS_ITOV(ip); - inodep = vn_to_inode(vpp); xfs_iunlock(ip, XFS_ILOCK_SHARED); - *vp = vpp; - *inode = inodep; + *inode = ip->i_vnode; return 0; } @@ -275,7 +262,6 @@ xfs_open_by_handle( struct file *filp; struct inode *inode; struct dentry *dentry; - bhv_vnode_t *vp; xfs_fsop_handlereq_t hreq; if (!capable(CAP_SYS_ADMIN)) @@ -283,7 +269,7 @@ xfs_open_by_handle( if (copy_from_user(&hreq, arg, sizeof(xfs_fsop_handlereq_t))) return -XFS_ERROR(EFAULT); - error = xfs_vget_fsop_handlereq(mp, parinode, &hreq, &vp, &inode); + error = xfs_vget_fsop_handlereq(mp, parinode, &hreq, &inode); if (error) return -error; @@ -385,7 +371,6 @@ xfs_readlink_by_handle( { struct inode *inode; xfs_fsop_handlereq_t hreq; - bhv_vnode_t *vp; __u32 olen; void *link; int error; @@ -395,7 +380,7 @@ xfs_readlink_by_handle( if (copy_from_user(&hreq, arg, sizeof(xfs_fsop_handlereq_t))) return -XFS_ERROR(EFAULT); - error = xfs_vget_fsop_handlereq(mp, parinode, &hreq, &vp, &inode); + error = xfs_vget_fsop_handlereq(mp, parinode, &hreq, &inode); if (error) return -error; @@ -438,34 +423,32 @@ xfs_fssetdm_by_handle( struct fsdmidata fsd; xfs_fsop_setdm_handlereq_t dmhreq; struct inode *inode; - bhv_vnode_t *vp; if (!capable(CAP_MKNOD)) return -XFS_ERROR(EPERM); if (copy_from_user(&dmhreq, arg, sizeof(xfs_fsop_setdm_handlereq_t))) return -XFS_ERROR(EFAULT); - error = xfs_vget_fsop_handlereq(mp, parinode, &dmhreq.hreq, &vp, &inode); + error = xfs_vget_fsop_handlereq(mp, parinode, &dmhreq.hreq, &inode); if (error) return -error; if (IS_IMMUTABLE(inode) || IS_APPEND(inode)) { - VN_RELE(vp); - return -XFS_ERROR(EPERM); + error = -XFS_ERROR(EPERM); + goto out; } if (copy_from_user(&fsd, dmhreq.data, sizeof(fsd))) { - VN_RELE(vp); - return -XFS_ERROR(EFAULT); + error = -XFS_ERROR(EFAULT); + goto out; } - error = xfs_set_dmattrs(xfs_vtoi(vp), - fsd.fsd_dmevmask, fsd.fsd_dmstate); + error = -xfs_set_dmattrs(XFS_I(inode), fsd.fsd_dmevmask, + fsd.fsd_dmstate); - VN_RELE(vp); - if (error) - return -error; - return 0; + out: + iput(inode); + return error; } STATIC int @@ -478,7 +461,6 @@ xfs_attrlist_by_handle( attrlist_cursor_kern_t *cursor; xfs_fsop_attrlist_handlereq_t al_hreq; struct inode *inode; - bhv_vnode_t *vp; char *kbuf; if (!capable(CAP_SYS_ADMIN)) @@ -488,8 +470,7 @@ xfs_attrlist_by_handle( if (al_hreq.buflen > XATTR_LIST_MAX) return -XFS_ERROR(EINVAL); - error = xfs_vget_fsop_handlereq(mp, parinode, &al_hreq.hreq, - &vp, &inode); + error = xfs_vget_fsop_handlereq(mp, parinode, &al_hreq.hreq, &inode); if (error) goto out; @@ -509,7 +490,7 @@ xfs_attrlist_by_handle( out_kfree: kfree(kbuf); out_vn_rele: - VN_RELE(vp); + iput(inode); out: return -error; } @@ -598,7 +579,6 @@ xfs_attrmulti_by_handle( xfs_attr_multiop_t *ops; xfs_fsop_attrmulti_handlereq_t am_hreq; struct inode *inode; - bhv_vnode_t *vp; unsigned int i, size; char *attr_name; @@ -607,7 +587,7 @@ xfs_attrmulti_by_handle( if (copy_from_user(&am_hreq, arg, sizeof(xfs_fsop_attrmulti_handlereq_t))) return -XFS_ERROR(EFAULT); - error = xfs_vget_fsop_handlereq(mp, parinode, &am_hreq.hreq, &vp, &inode); + error = xfs_vget_fsop_handlereq(mp, parinode, &am_hreq.hreq, &inode); if (error) goto out; @@ -666,7 +646,7 @@ xfs_attrmulti_by_handle( out_kfree_ops: kfree(ops); out_vn_rele: - VN_RELE(vp); + iput(inode); out: return -error; } @@ -702,7 +682,6 @@ xfs_ioc_fsgeometry( STATIC int xfs_ioc_xattr( - bhv_vnode_t *vp, xfs_inode_t *ip, struct file *filp, unsigned int cmd, @@ -735,7 +714,6 @@ xfs_ioctl( void __user *arg) { struct inode *inode = filp->f_path.dentry->d_inode; - bhv_vnode_t *vp = vn_from_inode(inode); xfs_mount_t *mp = ip->i_mount; int error; @@ -795,7 +773,7 @@ xfs_ioctl( case XFS_IOC_GETXFLAGS: case XFS_IOC_SETXFLAGS: case XFS_IOC_FSSETXATTR: - return xfs_ioc_xattr(vp, ip, filp, cmd, arg); + return xfs_ioc_xattr(ip, filp, cmd, arg); case XFS_IOC_FSSETDM: { struct fsdmidata dmi; @@ -1206,7 +1184,6 @@ xfs_ioc_fsgetxattr( STATIC int xfs_ioc_xattr( - bhv_vnode_t *vp, xfs_inode_t *ip, struct file *filp, unsigned int cmd, @@ -1240,7 +1217,7 @@ xfs_ioc_xattr( error = xfs_setattr(ip, vattr, attr_flags, NULL); if (likely(!error)) - vn_revalidate(vp); /* update flags */ + vn_revalidate(XFS_ITOV(ip)); /* update flags */ error = -error; break; } @@ -1275,7 +1252,7 @@ xfs_ioc_xattr( error = xfs_setattr(ip, vattr, attr_flags, NULL); if (likely(!error)) - vn_revalidate(vp); /* update flags */ + vn_revalidate(XFS_ITOV(ip)); /* update flags */ error = -error; break; } From owner-xfs@oss.sgi.com Sun Sep 23 04:43:39 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 23 Sep 2007 04:43: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.9 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 l8NBhbQ3023157 for ; Sun, 23 Sep 2007 04:43:38 -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 l8NBhdA5009689 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 23 Sep 2007 13:43:39 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8NBhd39009687 for xfs@oss.sgi.com; Sun, 23 Sep 2007 13:43:39 +0200 Date: Sun, 23 Sep 2007 13:43:39 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: [PATCH] cleanup vnode useage in xfs_dm.c Message-ID: <20070923114339.GB9585@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-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13046 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 Avoid passing around the vnode in xfs_dm.c but pass the xfs_inode / Linux inode / struct address_space as apropinquate. p.s. is there a chance we can kill all that 2.4 / early 2.6 compat code in dmapi one day? Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/dmapi/xfs_dm.c 2007-09-19 18:51:01.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c 2007-09-19 18:53:41.000000000 +0200 @@ -217,25 +217,35 @@ xfs_dm_send_data_event( * */ + +#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0) STATIC int prohibited_mr_events( - bhv_vnode_t *vp) + struct address_space *mapping) { - struct address_space *mapping = vn_to_inode(vp)->i_mapping; int prohibited = (1 << DM_EVENT_READ); -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,0) - struct vm_area_struct *vma = NULL; -#endif - if (!VN_MAPPED(vp)) + if (!mapping_mapped(mapping)) return 0; -#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0) spin_lock(&mapping->i_mmap_lock); if (mapping_writably_mapped(mapping)) prohibited |= (1 << DM_EVENT_WRITE); spin_unlock(&mapping->i_mmap_lock); + + return prohibited; +} #else +STATIC int +prohibited_mr_events( + struct address_space *mapping) +{ + int prohibited = (1 << DM_EVENT_READ); + struct vm_area_struct *vma = NULL; + + if (!VN_MAPPED(inode_to_vn(mapping->host))) + return 0; + spin_lock(&mapping->i_shared_lock); for (vma = mapping->i_mmap_shared; vma; vma = vma->vm_next_share) { if (vma->vm_flags & VM_WRITE) { @@ -250,16 +260,16 @@ prohibited_mr_events( } } spin_unlock(&mapping->i_shared_lock); -#endif return prohibited; } +#endif #ifdef DEBUG_RIGHTS STATIC int xfs_vp_to_hexhandle( - bhv_vnode_t *vp, + struct inode *inode, u_int type, char *buffer) { @@ -269,7 +279,11 @@ xfs_vp_to_hexhandle( int error; int i; - if ((error = dm_vp_to_handle(vp, &handle))) + /* + * XXX: dm_vp_to_handle doesn't exist. + * Looks like this debug code is rather dead. + */ + if ((error = dm_vp_to_handle(inode, &handle))) return(error); if (type == DM_FSYS_OBJ) { /* a filesystem handle */ @@ -465,7 +479,6 @@ xfs_ip_to_stat( dm_stat_t *buf) { xfs_icdinode_t *dic = &ip->i_d; - bhv_vnode_t *vp = XFS_ITOV(ip); buf->dt_ino = ino; buf->dt_nlink = dic->di_nlink; @@ -474,8 +487,8 @@ xfs_ip_to_stat( buf->dt_uid = dic->di_uid; buf->dt_gid = dic->di_gid; buf->dt_size = XFS_ISIZE(ip); - buf->dt_dev = new_encode_dev(vp->i_sb->s_dev); - vn_atime_to_time_t(vp, &buf->dt_atime); + buf->dt_dev = XFS_TO_HOST_DEVT(mp); + vn_atime_to_time_t(XFS_ITOV(ip), &buf->dt_atime); buf->dt_mtime = dic->di_mtime.t_sec; buf->dt_ctime = dic->di_ctime.t_sec; buf->dt_xfs_xflags = xfs_ip2dmflags(ip); @@ -554,7 +567,6 @@ xfs_dm_bulkall_iget_one( char *attr_name, caddr_t attr_buf) { - bhv_vnode_t *vp; xfs_inode_t *ip; dm_handle_t handle; u_int xstat_sz = *xstat_szp; @@ -569,10 +581,9 @@ xfs_dm_bulkall_iget_one( xfs_iput_new(ip, XFS_ILOCK_SHARED); return ENOENT; } - vp = XFS_ITOV(ip); xfs_ip_to_stat(mp, ino, ip, &xbuf->dx_statinfo); - dm_ip_to_handle(vn_to_inode(vp), &handle); + dm_ip_to_handle(ip->i_vnode, &handle); xfs_dm_handle_to_xstat(xbuf, xstat_sz, &handle, sizeof(handle)); /* Drop ILOCK_SHARED for call to xfs_attr_get */ @@ -581,7 +592,7 @@ xfs_dm_bulkall_iget_one( memset(&xbuf->dx_attrdata, 0, sizeof(dm_vardata_t)); error = xfs_attr_get(ip, attr_name, attr_buf, &value_len, ATTR_ROOT, sys_cred); - VN_RELE(vp); + iput(ip->i_vnode); DM_EA_XLATE_ERR(error); if (error && (error != ENOATTR)) { @@ -837,7 +848,7 @@ xfs_dm_bulkattr_iget_one( } xfs_ip_to_stat(mp, ino, ip, sbuf); - dm_ip_to_handle(vn_to_inode(XFS_ITOV(ip)), &handle); + dm_ip_to_handle(ip->i_vnode, &handle); xfs_dm_handle_to_stat(sbuf, stat_sz, &handle, sizeof(handle)); xfs_iput(ip, XFS_ILOCK_SHARED); @@ -925,7 +936,7 @@ xfs_dm_bulkattr_one( return error; } -/* xfs_dm_f_get_eventlist - return the dm_eventset_t mask for inode vp. */ +/* xfs_dm_f_get_eventlist - return the dm_eventset_t mask for inode ip. */ STATIC int xfs_dm_f_get_eventlist( @@ -969,7 +980,6 @@ xfs_dm_f_get_eventlist( STATIC int xfs_dm_f_set_eventlist( - bhv_vnode_t *vp, xfs_inode_t *ip, dm_right_t right, dm_eventset_t *eventsetp, /* in kernel space! */ @@ -990,7 +1000,7 @@ xfs_dm_f_set_eventlist( return(EINVAL); max_mask = (1 << maxevent) - 1; - if (VN_ISDIR(vp)) { + if (S_ISDIR(ip->i_d.di_mode)) { valid_events = DM_XFS_VALID_DIRECTORY_EVENTS; } else { /* file or symlink */ valid_events = DM_XFS_VALID_FILE_EVENTS; @@ -1019,7 +1029,7 @@ xfs_dm_f_set_eventlist( ip->i_d.di_dmevmask = (eventset & max_mask) | (ip->i_d.di_dmevmask & ~max_mask); xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); - VN_HOLD(vp); + igrab(ip->i_vnode); xfs_trans_commit(tp, 0); return(0); @@ -1146,7 +1156,7 @@ xfs_dm_direct_ok( STATIC int xfs_dm_rdwr( - bhv_vnode_t *vp, + struct inode *inode, uint fflag, mode_t fmode, dm_off_t off, @@ -1154,13 +1164,12 @@ xfs_dm_rdwr( void __user *bufp, int *rvp) { + xfs_inode_t *ip = XFS_I(inode); int error; int oflags; ssize_t xfer; struct file *file; - struct inode *inode = vn_to_inode(vp); struct dentry *dentry; - xfs_inode_t *ip; if ((off < 0) || (off > i_size_read(inode)) || !S_ISREG(inode->i_mode)) return EINVAL; @@ -1178,7 +1187,6 @@ xfs_dm_rdwr( */ oflags |= O_LARGEFILE | O_NONBLOCK | O_NOATIME; - ip = xfs_vtoi(vp); if (xfs_dm_direct_ok(ip, off, len, bufp)) oflags |= O_DIRECT; @@ -1255,9 +1263,8 @@ xfs_dm_downgrade_right( { #ifdef DEBUG_RIGHTS char buffer[sizeof(dm_handle_t) * 2 + 1]; - bhv_vnode_t *vp = vn_from_inode(inode); - if (!xfs_vp_to_hexhandle(vp, type, buffer)) { + if (!xfs_vp_to_hexhandle(inode, type, buffer)) { printf("dm_downgrade_right: old %d new %d type %d handle %s\n", right, DM_RIGHT_SHARED, type, buffer); } else { @@ -1288,13 +1295,12 @@ xfs_dm_get_allocinfo_rvp( u_int __user *nelemp, int *rvp) { - xfs_inode_t *ip; /* xfs incore inode pointer */ + xfs_inode_t *ip = XFS_I(inode); xfs_mount_t *mp; /* file system mount point */ xfs_fileoff_t fsb_offset; xfs_filblks_t fsb_length; dm_off_t startoff; int elem; - bhv_vnode_t *vp = vn_from_inode(inode); xfs_bmbt_irec_t *bmp = NULL; u_int bmpcnt = 50; u_int bmpsz = sizeof(xfs_bmbt_irec_t) * bmpcnt; @@ -1311,7 +1317,6 @@ xfs_dm_get_allocinfo_rvp( if (copy_from_user( &startoff, offp, sizeof(startoff))) return(-EFAULT); - ip = xfs_vtoi(vp); mp = ip->i_mount; ASSERT(mp); @@ -1819,15 +1824,13 @@ xfs_dm_get_dioinfo( { dm_dioinfo_t dio; xfs_mount_t *mp; - xfs_inode_t *ip; - bhv_vnode_t *vp = vn_from_inode(inode); + xfs_inode_t *ip = XFS_I(inode); /* Returns negative errors to DMAPI */ if (right < DM_RIGHT_SHARED) return(-EACCES); - ip = xfs_vtoi(vp); mp = ip->i_mount; dio.d_miniosz = dio.d_mem = MIN_DIO_SIZE(mp); @@ -2079,8 +2082,7 @@ xfs_dm_get_eventlist( u_int *nelemp) { int error; - bhv_vnode_t *vp = vn_from_inode(inode); - xfs_inode_t *ip = xfs_vtoi(vp); + xfs_inode_t *ip = XFS_I(inode); /* Returns negative errors to DMAPI */ @@ -2104,9 +2106,8 @@ xfs_dm_get_fileattr( dm_stat_t __user *statp) { dm_stat_t stat; - xfs_inode_t *ip; + xfs_inode_t *ip = XFS_I(inode); xfs_mount_t *mp; - bhv_vnode_t *vp = vn_from_inode(inode); /* Returns negative errors to DMAPI */ @@ -2115,7 +2116,6 @@ xfs_dm_get_fileattr( /* Find the mount point. */ - ip = xfs_vtoi(vp); mp = ip->i_mount; xfs_ilock(ip, XFS_ILOCK_SHARED); @@ -2144,16 +2144,14 @@ xfs_dm_get_region( { dm_eventset_t evmask; dm_region_t region; - xfs_inode_t *ip; + xfs_inode_t *ip = XFS_I(inode); u_int elem; - bhv_vnode_t *vp = vn_from_inode(inode); /* Returns negative errors to DMAPI */ if (right < DM_RIGHT_SHARED) return(-EACCES); - ip = xfs_vtoi(vp); evmask = ip->i_d.di_dmevmask; /* read the mask "atomically" */ /* Get the file's current managed region flags out of the @@ -2340,9 +2338,9 @@ xfs_dm_getall_inherit( /* Initialize location pointer for subsequent dm_get_dirattrs, dm_get_bulkattr, and dm_get_bulkall calls. The same initialization must - work for vnode-based routines (dm_get_dirattrs) and filesystem-based + work for inode-based routines (dm_get_dirattrs) and filesystem-based routines (dm_get_bulkattr and dm_get_bulkall). Filesystem-based functions - call this routine using the filesystem's root vnode. + call this routine using the filesystem's root inode. */ /* ARGSUSED */ @@ -2444,12 +2442,11 @@ xfs_dm_probe_hole( { dm_off_t roff; dm_size_t rlen; - xfs_inode_t *ip; + xfs_inode_t *ip = XFS_I(inode); xfs_mount_t *mp; uint lock_flags; xfs_fsize_t realsize; dm_size_t align; - bhv_vnode_t *vp = vn_from_inode(inode); int error; /* Returns negative errors to DMAPI */ @@ -2457,7 +2454,6 @@ xfs_dm_probe_hole( if (right < DM_RIGHT_SHARED) return -EACCES; - ip = xfs_vtoi(vp); if ((ip->i_d.di_mode & S_IFMT) != S_IFREG) return -EINVAL; @@ -2497,11 +2493,10 @@ xfs_dm_punch_hole( { xfs_flock64_t bf; int error = 0; - xfs_inode_t *ip; + xfs_inode_t *ip = XFS_I(inode); xfs_mount_t *mp; dm_size_t align; xfs_fsize_t realsize; - bhv_vnode_t *vp = vn_from_inode(inode); dm_off_t roff; dm_size_t rlen; @@ -2519,7 +2514,6 @@ xfs_dm_punch_hole( if (error) return -EBUSY; - ip = xfs_vtoi(vp); mp = ip->i_mount; down_rw_sems(inode, DM_SEM_FLAG_WR); @@ -2617,14 +2611,12 @@ xfs_dm_read_invis_rvp( void __user *bufp, int *rvp) { - bhv_vnode_t *vp = vn_from_inode(inode); - /* Returns negative errors to DMAPI */ if (right < DM_RIGHT_SHARED) return(-EACCES); - return(-xfs_dm_rdwr(vp, 0, FMODE_READ, off, len, bufp, rvp)); + return(-xfs_dm_rdwr(inode, 0, FMODE_READ, off, len, bufp, rvp)); } @@ -2637,9 +2629,8 @@ xfs_dm_release_right( { #ifdef DEBUG_RIGHTS char buffer[sizeof(dm_handle_t) * 2 + 1]; - bhv_vnode_t *vp = vn_from_inode(inode); - if (!xfs_vp_to_hexhandle(vp, type, buffer)) { + if (!xfs_vp_to_hexhandle(inode, type, buffer)) { printf("dm_release_right: old %d type %d handle %s\n", right, type, buffer); } else { @@ -2692,9 +2683,8 @@ xfs_dm_request_right( { #ifdef DEBUG_RIGHTS char buffer[sizeof(dm_handle_t) * 2 + 1]; - bhv_vnode_t *vp = vn_from_inode(inode); - if (!xfs_vp_to_hexhandle(vp, type, buffer)) { + if (!xfs_vp_to_hexhandle(inode, type, buffer)) { printf("dm_request_right: old %d new %d type %d flags 0x%x " "handle %s\n", right, newright, type, flags, buffer); } else { @@ -2759,15 +2749,14 @@ xfs_dm_set_eventlist( u_int maxevent) { int error; - bhv_vnode_t *vp = vn_from_inode(inode); - xfs_inode_t *ip = xfs_vtoi(vp); + xfs_inode_t *ip = XFS_I(inode); /* Returns negative errors to DMAPI */ if (type == DM_FSYS_OBJ) { error = xfs_dm_fs_set_eventlist(ip->i_mount, right, eventsetp, maxevent); } else { - error = xfs_dm_f_set_eventlist(vp, ip, right, eventsetp, maxevent); + error = xfs_dm_f_set_eventlist(ip, right, eventsetp, maxevent); } return(-error); /* Return negative error to DMAPI */ } @@ -2787,7 +2776,6 @@ xfs_dm_set_fileattr( dm_fileattr_t stat; bhv_vattr_t vat; int error; - bhv_vnode_t *vp = vn_from_inode(inode); /* Returns negative errors to DMAPI */ @@ -2844,7 +2832,7 @@ xfs_dm_set_fileattr( error = xfs_setattr(XFS_I(inode), &vat, ATTR_DMI, NULL); if (!error) - vn_revalidate(vp); /* update Linux inode flags */ + vn_revalidate(vn_from_inode(inode)); /* update Linux inode flags */ return(-error); /* Return negative error to DMAPI */ } @@ -2869,7 +2857,7 @@ xfs_dm_set_region( dm_region_t __user *regbufp, dm_boolean_t __user *exactflagp) { - xfs_inode_t *ip; + xfs_inode_t *ip = XFS_I(inode); xfs_trans_t *tp; xfs_mount_t *mp; dm_region_t region; @@ -2877,7 +2865,6 @@ xfs_dm_set_region( dm_eventset_t mr_mask; int error; u_int exactflag; - bhv_vnode_t *vp = vn_from_inode(inode); /* Returns negative errors to DMAPI */ @@ -2917,9 +2904,7 @@ xfs_dm_set_region( bits, add in the new ones, and update the file's mask. */ - ip = xfs_vtoi(vp); - - if (new_mask & prohibited_mr_events(vp)) { + if (new_mask & prohibited_mr_events(inode->i_mapping)) { /* If the change is simply to remove the READ * bit, then that's always okay. Otherwise, it's busy. */ @@ -2943,7 +2928,7 @@ xfs_dm_set_region( ip->i_d.di_dmevmask = (ip->i_d.di_dmevmask & ~mr_mask) | new_mask; xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); - VN_HOLD(vp); + igrab(inode); xfs_trans_commit(tp, 0); /* Return the proper value for *exactflagp depending upon whether or not @@ -3020,9 +3005,8 @@ xfs_dm_upgrade_right( { #ifdef DEBUG_RIGHTS char buffer[sizeof(dm_handle_t) * 2 + 1]; - bhv_vnode_t *vp = vn_from_inode(inode); - if (!xfs_vp_to_hexhandle(vp, type, buffer)) { + if (!xfs_vp_to_hexhandle(inode, type, buffer)) { printf("dm_upgrade_right: old %d new %d type %d handle %s\n", right, DM_RIGHT_EXCL, type, buffer); } else { @@ -3045,7 +3029,6 @@ xfs_dm_write_invis_rvp( int *rvp) { int fflag = 0; - bhv_vnode_t *vp = vn_from_inode(inode); /* Returns negative errors to DMAPI */ @@ -3054,7 +3037,7 @@ xfs_dm_write_invis_rvp( if (flags & DM_WRITE_SYNC) fflag |= O_SYNC; - return(-xfs_dm_rdwr(vp, fflag, FMODE_WRITE, off, len, bufp, rvp)); + return(-xfs_dm_rdwr(inode, fflag, FMODE_WRITE, off, len, bufp, rvp)); } From owner-xfs@oss.sgi.com Sun Sep 23 04:46:50 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 23 Sep 2007 04:46: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.9 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 l8NBkkQ3024342 for ; Sun, 23 Sep 2007 04:46:49 -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 l8NBklA5009806 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 23 Sep 2007 13:46:48 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8NBklen009804 for xfs@oss.sgi.com; Sun, 23 Sep 2007 13:46:47 +0200 Date: Sun, 23 Sep 2007 13:46:47 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: [PATCH] cleanup vnode useage in xfs_iget.c Message-ID: <20070923114647.GA9717@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-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13047 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 Get rid of vnode useage in xfs_iget.c and pass Linux inode / xfs_inode where apropinquate. And kill some useless helpers while we're at it. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ksyms.c 2007-09-19 19:01:25.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c 2007-09-19 19:03:16.000000000 +0200 @@ -181,7 +181,6 @@ EXPORT_SYMBOL(uuid_hash64); EXPORT_SYMBOL(uuid_is_nil); EXPORT_SYMBOL(uuid_table_remove); EXPORT_SYMBOL(vn_hold); -EXPORT_SYMBOL(vn_initialize); EXPORT_SYMBOL(vn_revalidate); #if defined(CONFIG_XFS_POSIX_ACL) @@ -244,7 +243,6 @@ EXPORT_SYMBOL(xfs_igrow_finish); EXPORT_SYMBOL(xfs_ilock); EXPORT_SYMBOL(xfs_ilock_map_shared); EXPORT_SYMBOL(xfs_ilock_nowait); -EXPORT_SYMBOL(xfs_inode_lock_init); EXPORT_SYMBOL(xfs_internal_inum); EXPORT_SYMBOL(xfs_iput); EXPORT_SYMBOL(xfs_iput_new); Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_vnode.c 2007-09-19 19:00:55.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.c 2007-09-19 19:01:17.000000000 +0200 @@ -82,20 +82,6 @@ vn_ioerror( xfs_do_force_shutdown(ip->i_mount, SHUTDOWN_DEVICE_REQ, f, l); } -bhv_vnode_t * -vn_initialize( - struct inode *inode) -{ - bhv_vnode_t *vp = vn_from_inode(inode); - - XFS_STATS_INC(vn_active); - XFS_STATS_INC(vn_alloc); - - ASSERT(VN_CACHED(vp) == 0); - - return vp; -} - /* * Revalidate the Linux inode from the XFS inode. * Note: i_size _not_ updated; we must hold the inode Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_vnode.h 2007-09-19 18:57:44.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.h 2007-09-19 19:01:12.000000000 +0200 @@ -187,7 +187,6 @@ typedef struct bhv_vattr { (VN_ISREG(vp) && ((mode) & (VSGID|(VEXEC>>3))) == VSGID) extern void vn_init(void); -extern bhv_vnode_t *vn_initialize(struct inode *); extern int vn_revalidate(bhv_vnode_t *); /* @@ -236,11 +235,6 @@ static inline bhv_vnode_t *vn_grab(bhv_v /* * Dealing with bad inodes */ -static inline void vn_mark_bad(bhv_vnode_t *vp) -{ - make_bad_inode(vn_to_inode(vp)); -} - static inline int VN_BAD(bhv_vnode_t *vp) { return is_bad_inode(vn_to_inode(vp)); Index: linux-2.6-xfs/fs/xfs/xfs_iget.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_iget.c 2007-09-19 18:56:23.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_iget.c 2007-09-19 19:10:33.000000000 +0200 @@ -65,7 +65,7 @@ */ STATIC int xfs_iget_core( - bhv_vnode_t *vp, + struct inode *inode, xfs_mount_t *mp, xfs_trans_t *tp, xfs_ino_t ino, @@ -74,9 +74,9 @@ xfs_iget_core( xfs_inode_t **ipp, xfs_daddr_t bno) { + struct inode *old_inode; xfs_inode_t *ip; xfs_inode_t *iq; - bhv_vnode_t *inode_vp; int error; xfs_icluster_t *icl, *new_icl = NULL; unsigned long first_index, mask; @@ -111,8 +111,8 @@ again: goto again; } - inode_vp = XFS_ITOV_NULL(ip); - if (inode_vp == NULL) { + old_inode = ip->i_vnode; + if (old_inode == NULL) { /* * If IRECLAIM is set this inode is * on its way out of the system, @@ -170,13 +170,11 @@ again: goto finish_inode; - } else if (vp != inode_vp) { - struct inode *inode = vn_to_inode(inode_vp); - + } else if (inode != old_inode) { /* The inode is being torn down, pause and * try again. */ - if (inode->i_state & (I_FREEING | I_CLEAR)) { + if (old_inode->i_state & (I_FREEING | I_CLEAR)) { read_unlock(&pag->pag_ici_lock); delay(1); XFS_STATS_INC(xs_ig_frecycle); @@ -189,7 +187,7 @@ again: */ cmn_err(CE_PANIC, "xfs_iget_core: ambiguous vns: vp/0x%p, invp/0x%p", - inode_vp, vp); + old_inode, inode); } /* @@ -231,7 +229,14 @@ finish_inode: xfs_itrace_exit_tag(ip, "xfs_iget.alloc"); - xfs_inode_lock_init(ip, vp); + + mrlock_init(&ip->i_lock, MRLOCK_ALLOW_EQUAL_PRI|MRLOCK_BARRIER, + "xfsino", ip->i_ino); + mrlock_init(&ip->i_iolock, MRLOCK_BARRIER, "xfsio", ip->i_ino); + init_waitqueue_head(&ip->i_ipin_wait); + atomic_set(&ip->i_pincount, 0); + initnsema(&ip->i_flock, 1, "xfsfino"); + if (lock_flags) xfs_ilock(ip, lock_flags); @@ -334,7 +339,7 @@ finish_inode: * If we have a real type for an on-disk inode, we can set ops(&unlock) * now. If it's a new inode being created, xfs_ialloc will handle it. */ - xfs_initialize_vnode(mp, vp, ip); + xfs_initialize_vnode(mp, inode, ip); return 0; } @@ -354,69 +359,58 @@ xfs_iget( xfs_daddr_t bno) { struct inode *inode; - bhv_vnode_t *vp = NULL; + xfs_inode_t *ip; int error; XFS_STATS_INC(xs_ig_attempts); retry: inode = iget_locked(mp->m_super, ino); - if (inode) { - xfs_inode_t *ip; - - vp = vn_from_inode(inode); - if (inode->i_state & I_NEW) { - vn_initialize(inode); - error = xfs_iget_core(vp, mp, tp, ino, flags, - lock_flags, ipp, bno); - if (error) { - vn_mark_bad(vp); - if (inode->i_state & I_NEW) - unlock_new_inode(inode); - iput(inode); - } - } else { - /* - * If the inode is not fully constructed due to - * filehandle mismatches wait for the inode to go - * away and try again. - * - * iget_locked will call __wait_on_freeing_inode - * to wait for the inode to go away. - */ - if (is_bad_inode(inode) || - ((ip = xfs_vtoi(vp)) == NULL)) { - iput(inode); - delay(1); - goto retry; - } - - if (lock_flags != 0) - xfs_ilock(ip, lock_flags); - XFS_STATS_INC(xs_ig_found); - *ipp = ip; - error = 0; + if (!inode) + /* If we got no inode we are out of memory */ + return ENOMEM; + + if (inode->i_state & I_NEW) { + XFS_STATS_INC(vn_active); + XFS_STATS_INC(vn_alloc); + + error = xfs_iget_core(inode, mp, tp, ino, flags, + lock_flags, ipp, bno); + if (error) { + make_bad_inode(inode); + if (inode->i_state & I_NEW) + unlock_new_inode(inode); + iput(inode); } - } else - error = ENOMEM; /* If we got no inode we are out of memory */ + return error; + } - return error; -} + /* + * If the inode is not fully constructed due to + * filehandle mismatches wait for the inode to go + * away and try again. + * + * iget_locked will call __wait_on_freeing_inode + * to wait for the inode to go away. + */ + if (is_bad_inode(inode)) { + iput(inode); + delay(1); + goto retry; + } -/* - * Do the setup for the various locks within the incore inode. - */ -void -xfs_inode_lock_init( - xfs_inode_t *ip, - bhv_vnode_t *vp) -{ - mrlock_init(&ip->i_lock, MRLOCK_ALLOW_EQUAL_PRI|MRLOCK_BARRIER, - "xfsino", ip->i_ino); - mrlock_init(&ip->i_iolock, MRLOCK_BARRIER, "xfsio", ip->i_ino); - init_waitqueue_head(&ip->i_ipin_wait); - atomic_set(&ip->i_pincount, 0); - initnsema(&ip->i_flock, 1, "xfsfino"); + ip = XFS_I(inode); + if (!ip) { + iput(inode); + delay(1); + goto retry; + } + + if (lock_flags != 0) + xfs_ilock(ip, lock_flags); + XFS_STATS_INC(xs_ig_found); + *ipp = ip; + return 0; } /* @@ -456,11 +450,9 @@ void xfs_iput(xfs_inode_t *ip, uint lock_flags) { - bhv_vnode_t *vp = XFS_ITOV(ip); - xfs_itrace_entry(ip); xfs_iunlock(ip, lock_flags); - VN_RELE(vp); + IRELE(ip); } /* @@ -470,20 +462,19 @@ void xfs_iput_new(xfs_inode_t *ip, uint lock_flags) { - bhv_vnode_t *vp = XFS_ITOV(ip); - struct inode *inode = vn_to_inode(vp); + struct inode *inode = ip->i_vnode; xfs_itrace_entry(ip); if ((ip->i_d.di_mode == 0)) { ASSERT(!xfs_iflags_test(ip, XFS_IRECLAIMABLE)); - vn_mark_bad(vp); + make_bad_inode(inode); } if (inode->i_state & I_NEW) unlock_new_inode(inode); if (lock_flags) xfs_iunlock(ip, lock_flags); - VN_RELE(vp); + IRELE(ip); } @@ -496,8 +487,6 @@ xfs_iput_new(xfs_inode_t *ip, void xfs_ireclaim(xfs_inode_t *ip) { - bhv_vnode_t *vp; - /* * Remove from old hash list and mount list. */ @@ -526,9 +515,8 @@ xfs_ireclaim(xfs_inode_t *ip) /* * Pull our behavior descriptor from the vnode chain. */ - vp = XFS_ITOV_NULL(ip); - if (vp) { - vn_to_inode(vp)->i_private = NULL; + if (ip->i_vnode) { + ip->i_vnode->i_private = NULL; ip->i_vnode = NULL; } Index: linux-2.6-xfs/fs/xfs/xfs_inode.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_inode.h 2007-09-19 19:02:28.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_inode.h 2007-09-19 19:03:10.000000000 +0200 @@ -493,7 +493,6 @@ void xfs_ihash_init(struct xfs_mount *) void xfs_ihash_free(struct xfs_mount *); xfs_inode_t *xfs_inode_incore(struct xfs_mount *, xfs_ino_t, struct xfs_trans *); -void xfs_inode_lock_init(xfs_inode_t *, bhv_vnode_t *); int xfs_iget(struct xfs_mount *, struct xfs_trans *, xfs_ino_t, uint, uint, xfs_inode_t **, xfs_daddr_t); void xfs_iput(xfs_inode_t *, uint); From owner-xfs@oss.sgi.com Sun Sep 23 09:14:35 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 23 Sep 2007 09:14: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=-2.5 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.231]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8NGEWQ3007146 for ; Sun, 23 Sep 2007 09:14:35 -0700 Received: by wx-out-0506.google.com with SMTP id s9so1165823wxc for ; Sun, 23 Sep 2007 09:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:subject:from:reply-to:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; bh=5dvPXEFNzAlY2c0ufxHTbtpzn6OycouHAS188M4Dkas=; b=Pd7zbiQefTDcoM2YjBDDYcBvs2U0S9ATOJnKJkEogwovCVKhE9DIordEWgfGejS7DUvy/250UhWB/Q/h60OrtAsLf7U7hHxMxkM7Kdbtk30ZxDouDNk5vNJAk4wPUG6fgS13bNtDMOnEBK0aCFONq2qPRFMkap5+u7d8evOzToE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:subject:from:reply-to:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=fSs7sXO1HiCfPrSXPgNzMZFNHPIfEtGgoVn8AYIW+jsXwplPxCsZZCcd453rs+zEgci7lRvsLQugGfsVqdnDyTAmUhpdeZDXiY5a2WYqVxNSLh9k++T6K3oZMo37CfpZTXTGa8QJlesE5CQ/2XFPMOs4n68MibXcP5NlmMrwHQ0= Received: by 10.90.69.8 with SMTP id r8mr4692095aga.1190562427455; Sun, 23 Sep 2007 08:47:07 -0700 (PDT) Received: from ?192.168.11.200? ( [72.74.209.205]) by mx.google.com with ESMTPS id 8sm2039340hsp.2007.09.23.08.47.06 (version=SSLv3 cipher=RC4-MD5); Sun, 23 Sep 2007 08:47:06 -0700 (PDT) Subject: Re: Review: Concurrent Multi-File Data Streams From: Ming Zhang Reply-To: blackmagic02881@gmail.com To: David Chinner Cc: Leon Kolchinsky , "'Hxsrmeng'" , xfs@oss.sgi.com In-Reply-To: <20070923074500.GO995458@sgi.com> References: <12789210.post@talk.nabble.com> <20070921091441.3ABB88E0B@mail.edu.haifa.ac.il> <20070921125531.GM995458@sgi.com> <1190399077.3795.86.camel@localhost.localdomain> <20070923074500.GO995458@sgi.com> Content-Type: text/plain Date: Sun, 23 Sep 2007 11:47:05 -0400 Message-Id: <1190562425.3795.97.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13051 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: blackmagic02881@gmail.com Precedence: bulk X-list: xfs On Sun, 2007-09-23 at 17:45 +1000, David Chinner wrote: > On Fri, Sep 21, 2007 at 02:24:37PM -0400, Ming Zhang wrote: > > On Fri, 2007-09-21 at 22:55 +1000, David Chinner wrote: > > > On Fri, Sep 21, 2007 at 11:13:33AM +0200, Leon Kolchinsky wrote: > > > > I'm running DSS (Darwin Streaming Server) on one of my servers and that > > > > "Concurrent Multi-File Data Streams" thing seems very interesting :) > > > > > > Filestreams is needed to optimise concurrent *ingest* of data, > > > not playout. > > > > > > i.e. if you are ingesting multiple real-time streams of data at the > > > same time as you are playing out real-time streams and you area > > > missing playout deadlines (i.e. dropping frames) due to sub-optimal > > > data layout, then it might help you..... > > > > > > > I have a separate partition there I store all movies. > > > > Is 2.6.22 kernel already has this patch incorporated already(actually > > > > gentoo-sources-2.6.22-r5)? > > > > > > It went into .22 so you should have it. > > > > i did not see xfs_filestream.c in 2.6.22.6 yet. did i miss something > > here? > > No, my mistake - it seems so long since I checked it in. it went > into 2.6.23-rc1.... thanks. > > Cheers, > > Dave. -- Ming Zhang @#$%^ purging memory... (*!% http://blackmagic02881.wordpress.com/ http://www.linkedin.com/in/blackmagic02881 -------------------------------------------- From owner-xfs@oss.sgi.com Sun Sep 23 15:06:19 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 23 Sep 2007 15:06: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.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 l8NM6FQ3002329 for ; Sun, 23 Sep 2007 15:06:17 -0700 Received: from [134.15.251.1] (melb-sw-corp-251-1.corp.sgi.com [134.15.251.1]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA00178; Mon, 24 Sep 2007 08:06:02 +1000 Message-ID: <46F6E344.20907@sgi.com> Date: Mon, 24 Sep 2007 08:05:56 +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: Eric Sandeen CC: Christoph Hellwig , David Chinner , xfs-dev , xfs-oss , trev , "Kevin G. Snow" Subject: Re: [PATCH 4 of 4] Restore ihashsize mount option as deprecated References: <20070809114548.GG12413810@sgi.com> <46F4390A.5070407@sandeen.net> <20070923075756.GP995458@sgi.com> <20070923100039.GA5370@infradead.org> <46F67BD3.8050706@sandeen.net> In-Reply-To: <46F67BD3.8050706@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13052 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 Eric Sandeen wrote: > Christoph Hellwig wrote: >> Did anyone but Dave get Eric's original message? It seems to not have >> made it to the list. >> > > No, it was yet another lost email on oss. I guess the xfs-dev list got it. > >>From a fairly quick look at logs I have no idea what happened... but > this is clearly a problem that must be solved one way or another. Have we (or can we) agree on a new list handler? The current mechanism has trouble allowing new subscribers and now we see it's loosing mail too. Let's get this fixed and move on. Who owns this on oss? If nobody, then I'll organize it, but first we need consensus on a replacement. 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 Sun Sep 23 15:38:01 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 23 Sep 2007 15:38: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.4 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 l8NMc0Q3007654 for ; Sun, 23 Sep 2007 15:38:00 -0700 Received: from liberator.sandeen.net (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 D6E0818011E8D; Sun, 23 Sep 2007 17:38:02 -0500 (CDT) Message-ID: <46F6EACA.5040607@sandeen.net> Date: Sun, 23 Sep 2007 17:38:02 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: markgw@sgi.com CC: Christoph Hellwig , David Chinner , xfs-dev , xfs-oss , trev , "Kevin G. Snow" Subject: Re: [PATCH 4 of 4] Restore ihashsize mount option as deprecated References: <20070809114548.GG12413810@sgi.com> <46F4390A.5070407@sandeen.net> <20070923075756.GP995458@sgi.com> <20070923100039.GA5370@infradead.org> <46F67BD3.8050706@sandeen.net> <46F6E344.20907@sgi.com> In-Reply-To: <46F6E344.20907@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13053 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 Mark Goodwin wrote: > > Eric Sandeen wrote: >> Christoph Hellwig wrote: >>> Did anyone but Dave get Eric's original message? It seems to not have >>> made it to the list. >>> >> No, it was yet another lost email on oss. I guess the xfs-dev list got it. >> >> >From a fairly quick look at logs I have no idea what happened... but >> this is clearly a problem that must be solved one way or another. > > Have we (or can we) agree on a new list handler? The current mechanism > has trouble allowing new subscribers That appeared to be spamfilter misfires. > and now we see it's loosing mail > too. Not sure anyone has gotten to the bottom of this new problem. -Eric > Let's get this fixed and move on. Who owns this on oss? If nobody, > then I'll organize it, but first we need consensus on a replacement. > > Thanks > From owner-xfs@oss.sgi.com Sun Sep 23 17:20:25 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 23 Sep 2007 17:20:27 -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 l8O0KKQ3028297 for ; Sun, 23 Sep 2007 17:20:23 -0700 Received: from [134.14.55.89] (soarer.melbourne.sgi.com [134.14.55.89]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA02628; Mon, 24 Sep 2007 10:20:20 +1000 Message-ID: <46F7032E.9010004@sgi.com> Date: Mon, 24 Sep 2007 10:22:06 +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 - 964316: Dmapi get_bulkall appears to return incorrect inode information Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13054 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 get_bulkall() could return incorrect inode state In the following scenario xfs_bulkstat() returns incorrect stale inode state: 1. File_A is created and its inode synced to disk. 2. File_A is unlinked and doesn't exist anymore. 3. Filesystem sync is invoked. 4. File_B is created. File_B happens to reclaim File_A's inode. 5. xfs_bulkstat() is called and detects File_B but reports the incorrect File_A inode state. Explanation for the incorrect inode state is that inodes are not immediately synced on file create for performance reasons. This leaves the on-disk inode buffer uninitialized (or with old state from a previous generation inode) and this is what xfs_bulkstat() would report. The patch marks the on-disk inode buffer "dirty" on unlink. When the inode is reclaimed (by a new file create), xfs_bulkstat() would filter this inode by the "dirty" mark. Once the inode is flushed to disk, the on-disk buffer "dirty" mark is automatically removed and a following xfs_bulkstat() would return the correct inode state. Marking the on-disk inode buffer "dirty" on unlink is achieved by setting the on-disk di_nlink field to 0. Note that the in-core di_nlink has already been set to 0 and a corresponding transaction logged by xfs_droplink(). This is an exception from the rule that any on-disk inode buffer changes has to be followed by a disk write (inode flush). Synchronizing the in-core to on-disk di_nlink values in advance (before the actual inode flush to disk) should be fine in this case because the inode is already unlinked and it would never change its di_nlink again for this inode generation. Date: Mon Sep 24 10:14:37 AEST 2007 Workarea: soarer.melbourne.sgi.com:/home/vapo/isms/linux-xfs1 Inspected by: tes, dgc, markgw, aelder, 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:29757a fs/xfs/xfs_itable.c - 1.155 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_itable.c.diff?r1=text&tr1=1.155&r2=text&tr2=1.154&f=h - pv 964316 - get_bulkall() could return incorrect inode stat fs/xfs/xfs_inode.c - 1.483 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.483&r2=text&tr2=1.482&f=h - pv 964316 - get_bulkall() could return incorrect inode stat From owner-xfs@oss.sgi.com Sun Sep 23 21:17:58 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 23 Sep 2007 21:18:03 -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 l8O4HtQ3004118 for ; Sun, 23 Sep 2007 21:17:57 -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 OAA06991; Mon, 24 Sep 2007 14:17:53 +1000 To: "Eric Sandeen" , xfs-oss Subject: Re: something very strange w/ filestreams... From: "Barry Naujok" Organization: SGI Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: <46F49C80.60007@sandeen.net> Content-Transfer-Encoding: 7bit Date: Mon, 24 Sep 2007 14:22:17 +1000 Message-ID: In-Reply-To: <46F49C80.60007@sandeen.net> User-Agent: Opera Mail/9.10 (Win32) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13055 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 Sat, 22 Sep 2007 14:39:28 +1000, Eric Sandeen wrote: > if I do: > > for I in 173 174 178; do ./check $I; done > > it's not terribly interesting, things seem to go ok, just normal > filestreams failures ;-) > > if I do: > > ./check 173 174 178 > > things go very badly; the very first repair in 178 finds a horribly > corrupted filesystem, and repair tips over (memory appears corrupted, as > witnessed by): > >> xfs_repair: zone calloc failed (, 572662388 bytes): Cannot allocate >> memory > > hm, no zone name, length of 0x22222274? > > I already provided a metadump image to Barry, but I wonder why the > timing(?) seems to make a difference here... first sign of things going > awry in repair is: > > Phase 2 - using internal log > - zero log... > - scan filesystem freespace and inode maps... > bad length 131072 for agf 0, should be 4096 > bad length # 131072 for agi 0, should be 4096 > would reset bad agf for ag 0 > would reset bad agi for ag 0 > .... > > not sure what's going on here, but it only seems to happen if I do those > 2 filestreams test immediately before 178... > > oh, and this is over LVM, just for fun. Eric, you have this patch installed don't you? http://oss.sgi.com/archives/xfs/2007-07/msg00139.html From owner-xfs@oss.sgi.com Sun Sep 23 22:47:20 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 23 Sep 2007 22:47: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=-1.3 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 l8O5lGQ3020726 for ; Sun, 23 Sep 2007 22:47:19 -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 PAA08432; Mon, 24 Sep 2007 15:47:09 +1000 Date: Mon, 24 Sep 2007 15:50:57 +1000 To: "David Chinner" , "Eric Sandeen" Subject: Re: something very strange w/ filestreams... From: "Barry Naujok" Organization: SGI Cc: xfs-oss Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: <46F49C80.60007@sandeen.net> <20070923092444.GQ995458@sgi.com> Message-ID: In-Reply-To: <20070923092444.GQ995458@sgi.com> User-Agent: Opera Mail/9.10 (Win32) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by oss.sgi.com id l8O5lKQ3020739 X-archive-position: 13056 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 Sun, 23 Sep 2007 19:24:44 +1000, David Chinner wrote: > Barry - I think xfs_repair might be finding the incorrect superblock > for the repair. Tests 172, 173 and 174 use less than the whole disk, > so there are going to be stale superblocks all over the place.... > >> hm, no zone name, length of 0x22222274? >> >> I already provided a metadump image to Barry, but I wonder why the >> timing(?) seems to make a difference here... first sign of things going >> awry in repair is: >> >> Phase 2 - using internal log >> - zero log... >> - scan filesystem freespace and inode maps... >> bad length 131072 for agf 0, should be 4096 >> bad length # 131072 for agi 0, should be 4096 > > Yes - test 173 uses 1GB filesystem with 64x16MB AGs - 4096 * 4k block > size = 16MB AG. definitely looks like a stale superblock being > found. > > Barry, I think that the secondary superblock needs better verification > (e.g. that there really are AG headers where the sb says there > are supposed to be and all the lengths match up). > > Eric - you can relax. Filestreams is not hosing your filesystem; > xfs_reapir > is.... Test 178 is designed to test mkfs.xfs in http://oss.sgi.com/archives/xfs/2007-07/msg00139.html and will still make xfs_repair go bananas if there is other old AG headers. So, before running this test, you should make sure your test partitions are completely zeroed from mkfs's that occurred before that recent version of mkfs.xfs was installed. I tried on my test box and sure enough, xfs_repair barfed. After zeroing the devices, 172, 174 & 178 sequence succeeded. If you have failures after the zeroing and ONLY using the latest mkfs.xfs then something else is wrong. Also, xfs_copy/xfs_mdrestore of different images could still trigger the problem. There is a TODO to improve xfs_repair's handling of this scenario. Barry. From owner-xfs@oss.sgi.com Mon Sep 24 02:17:18 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Sep 2007 02:17: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 l8O9HEQ3027682 for ; Mon, 24 Sep 2007 02:17:17 -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 TAA12623 for ; Mon, 24 Sep 2007 19:17:17 +1000 Message-ID: <46F7809D.1040900@sgi.com> Date: Mon, 24 Sep 2007 19:17:17 +1000 From: Donald Douwsma User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: xfs-oss Subject: Review: Fix xfsidbg.c compiler warnings on x86_64 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13057 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 Fix compile warnings for xfsidbg.c as seen on x86_64. --- 2.6.x-xfs.orig/fs/xfs/xfsidbg.c +++ 2.6.x-xfs/fs/xfs/xfsidbg.c @@ -1798,10 +1798,10 @@ xfs_itrace_pr_entry(ktrace_entry_t *ktep if ((__psint_t)ktep->val[0] == 0) return 0; - if (kdbnearsym((unsigned int)ktep->val[8], &symtab)) { + if (kdbnearsym((unsigned long)ktep->val[8], &symtab)) { unsigned long offval; - offval = (unsigned int)ktep->val[8] - symtab.sym_start; + offval = (unsigned long)ktep->val[8] - symtab.sym_start; if (offval) sprintf(funcname, "%s+0x%lx", symtab.sym_name, offval); @@ -1871,13 +1871,13 @@ xfs_itrace_pr_entry(ktrace_entry_t *ktep kdb_printf("\n"); - kdb_printf(" cpu = %ld pid = %d ", - (long)ktep->val[6], (pid_t)ktep->val[7]); + kdb_printf(" cpu = %ld pid = %ld ", + (long)ktep->val[6], (long)ktep->val[7]); - if (kdbnearsym((unsigned int)ktep->val[4], &symtab)) { + if (kdbnearsym((unsigned long)ktep->val[4], &symtab)) { unsigned long offval; - offval = (unsigned int)ktep->val[4] - symtab.sym_start; + offval = (unsigned long)ktep->val[4] - symtab.sym_start; if (offval) kdb_printf(" ra = %s+0x%lx", symtab.sym_name, offval); From owner-xfs@oss.sgi.com Mon Sep 24 02:20:25 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Sep 2007 02:20:28 -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 l8O9KMQ3028531 for ; Mon, 24 Sep 2007 02:20:24 -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 TAA12690 for ; Mon, 24 Sep 2007 19:20:25 +1000 Message-ID: <46F78159.5080907@sgi.com> Date: Mon, 24 Sep 2007 19:20:25 +1000 From: Donald Douwsma User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: xfs-oss Subject: Review: fix mount flags as printed by xfsidbg Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13058 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 The xfs mount flags have recently undergone some changes. Update the xfsidbg xmount command to print them correctly. Don --- 2.6.x-xfs.orig/fs/xfs/xfsidbg.c +++ 2.6.x-xfs/fs/xfs/xfsidbg.c @@ -6403,25 +6403,25 @@ xfsidbg_xmount(xfs_mount_t *mp) static char *xmount_flags[] = { "WSYNC", /* 0x0001 */ "INO64", /* 0x0002 */ - "UNUSED_4", /* 0x0004 */ - "UNUSED_8", /* 0x0008 */ + "DMAPI", /* 0x0004 */ + "WAS_CLEAN", /* 0x0008 */ "FSSHUTDOWN", /* 0x0010 */ "NOATIME", /* 0x0020 */ "RETERR", /* 0x0040 */ "NOALIGN", /* 0x0080 */ "ATTR2", /* 0x0100 */ - "UNUSED_200", /* 0x0200 */ + "GRPID", /* 0x0200 */ "NORECOVERY", /* 0x0400 */ "SHARED", /* 0x0800 */ "DFLT_IOSIZE", /* 0x1000 */ "OSYNCISOSYNC", /* 0x2000 */ "32BITINODES", /* 0x4000 */ - "32BITINOOPT", /* 0x8000 */ + "SMALL_INUMS", /* 0x8000 */ "NOUUID", /* 0x10000 */ "BARRIER", /* 0x20000 */ "IDELETE", /* 0x40000 */ "SWALLOC", /* 0x80000 */ - "UNUSED_100000", /* 0x100000 */ + "RDONLY", /* 0x100000 */ "DIRSYNC", /* 0x200000 */ "COMPAT_IOSIZE",/* 0x400000 */ NULL From owner-xfs@oss.sgi.com Mon Sep 24 05:40:49 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Sep 2007 05:40: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.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43, SPF_HELO_PASS 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 l8OCehQ3004100 for ; Mon, 24 Sep 2007 05:40:48 -0700 Received: from liberator.sandeen.net (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 A9F3D18011E93; Mon, 24 Sep 2007 07:40:45 -0500 (CDT) Message-ID: <46F7B04D.70809@sandeen.net> Date: Mon, 24 Sep 2007 07:40:45 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Barry Naujok CC: David Chinner , xfs-oss Subject: Re: something very strange w/ filestreams... References: <46F49C80.60007@sandeen.net> <20070923092444.GQ995458@sgi.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13059 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 Barry Naujok wrote: > On Sun, 23 Sep 2007 19:24:44 +1000, David Chinner wrote: > >> Barry - I think xfs_repair might be finding the incorrect superblock >> for the repair. Tests 172, 173 and 174 use less than the whole disk, >> so there are going to be stale superblocks all over the place.... >> >>> hm, no zone name, length of 0x22222274? >>> >>> I already provided a metadump image to Barry, but I wonder why the >>> timing(?) seems to make a difference here... first sign of things going >>> awry in repair is: >>> >>> Phase 2 - using internal log >>> - zero log... >>> - scan filesystem freespace and inode maps... >>> bad length 131072 for agf 0, should be 4096 >>> bad length # 131072 for agi 0, should be 4096 >> Yes - test 173 uses 1GB filesystem with 64x16MB AGs - 4096 * 4k block >> size = 16MB AG. definitely looks like a stale superblock being >> found. >> >> Barry, I think that the secondary superblock needs better verification >> (e.g. that there really are AG headers where the sb says there >> are supposed to be and all the lengths match up). >> >> Eric - you can relax. Filestreams is not hosing your filesystem; >> xfs_reapir >> is.... > > Test 178 is designed to test mkfs.xfs in > http://oss.sgi.com/archives/xfs/2007-07/msg00139.html and > will still make xfs_repair go bananas if there is other > old AG headers. > > So, before running this test, you should make sure your test > partitions are completely zeroed from mkfs's that occurred > before that recent version of mkfs.xfs was installed. I dd'd over the whole test partition, ran the sequence, and hit the problem. > I tried on my test box and sure enough, xfs_repair barfed. > After zeroing the devices, 172, 174 & 178 sequence succeeded. > > If you have failures after the zeroing and ONLY using the > latest mkfs.xfs then something else is wrong. Also, > xfs_copy/xfs_mdrestore of different images could still > trigger the problem. > > There is a TODO to improve xfs_repair's handling of this > scenario. I do have the patch installed that you mentioned, as long as it's in 2.9.3. but if xfs_repair is double-freeing, then something else is still wrong -Eric From owner-xfs@oss.sgi.com Mon Sep 24 08:31:55 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Sep 2007 08:31: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=0.1 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_43 autolearn=no version=3.2.0-pre1-r499012 Received: from mail.edu.haifa.ac.il (mail.edu.haifa.ac.il [132.74.40.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8OFVpQ3027710 for ; Mon, 24 Sep 2007 08:31:54 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.edu.haifa.ac.il (Postfix) with ESMTP id F17A714F215; Mon, 24 Sep 2007 17:32:11 +0200 (IST) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Scanned: amavisd-new at edu.haifa.ac.il Received: from mail.edu.haifa.ac.il ([127.0.0.1]) by localhost (mail.edu.haifa.ac.il [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id FHgEMtZcfuBk; Mon, 24 Sep 2007 17:32:11 +0200 (IST) Received: from kozanostra (leon.edu.haifa.ac.il [132.74.41.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.edu.haifa.ac.il (Postfix) with ESMTP id A73AC14EC2F; Mon, 24 Sep 2007 17:32:11 +0200 (IST) From: "Leon Kolchinsky" To: "'Eric Sandeen'" Cc: Subject: RE: Tips on xfs creation on MIPS R5000 machine running Linux? Date: Mon, 24 Sep 2007 17:30:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <46F67C7B.6040405@sandeen.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acf99Mc/9PTjO+3MT+KClcyA0ex4iAAxxUuA Message-Id: <20070924153211.A73AC14EC2F@mail.edu.haifa.ac.il> X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id l8OFVtQ3027725 X-archive-position: 13061 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: leonk@construct.haifa.ac.il Precedence: bulk X-list: xfs > Leon Kolchinsky wrote: > > >> 1) Creating FS: > >> mkfs.xfs -l internal,size=128m -d agcount=2 –d unwritten=0 /dev/hda1 > >> > >> 2) Mount options: > >> mount -o noatime,nodiratime,logbufs=8 > > Unless you have a reason not to, I always say start with the defaults > until proven otherwise. > > Why would you want to turn off unwritten extents, or limit the agcount? > Hello Eric, Thanks for your response. Actually these options largely taken from "XFS on steroids" topic from gentoo forums http://forums.gentoo.org/viewtopic-t-488215-highlight-.html?sid=cfa1762e9e57 9e184be80bd66a620abe I want to optimize FS for maximum performance (it's not a production box). What are your suggestions? Regards, Leon From owner-xfs@oss.sgi.com Mon Sep 24 09:14:34 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Sep 2007 09:14: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=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l8OGEVQ3004528 for ; Mon, 24 Sep 2007 09:14:34 -0700 Received: (qmail 85000 invoked from network); 24 Sep 2007 16:14:34 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@75.37.36.18 with login) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 24 Sep 2007 16:14:34 -0000 X-YMail-OSG: qoG6uzsVM1mbxs39c17MmIkHH5kMwGMsMdyDxBqzzoSFmeMpv7Gpam2iXzIgrh9U3l9wQKrI2g-- Received: by tuatara.stupidest.org (Postfix, from userid 10000) id 6577628A39AB; Mon, 24 Sep 2007 09:14:33 -0700 (PDT) Date: Mon, 24 Sep 2007 09:14:33 -0700 From: Chris Wedgwood To: Donald Douwsma Cc: xfs-oss Subject: Re: Review: fix mount flags as printed by xfsidbg Message-ID: <20070924161433.GA4098@puku.stupidest.org> References: <46F78159.5080907@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46F78159.5080907@sgi.com> X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13062 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: xfs On Mon, Sep 24, 2007 at 07:20:25PM +1000, Donald Douwsma wrote: > - "32BITINOOPT", /* 0x8000 */ > + "SMALL_INUMS", /* 0x8000 */ why rename that? From owner-xfs@oss.sgi.com Mon Sep 24 10:32:16 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Sep 2007 10:32: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.5 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_43 autolearn=no version=3.2.0-pre1-r499012 Received: from stlx01.stz-softwaretechnik.com (stz-softwaretechnik.de [217.160.223.211]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8OHWEQ3025338 for ; Mon, 24 Sep 2007 10:32:16 -0700 Received: from rg by stlx01.stz-softwaretechnik.com with local (Exim 3.36 #1 (Debian)) id 1IZrmw-00013b-00 for ; Mon, 24 Sep 2007 19:32:06 +0200 Date: Mon, 24 Sep 2007 19:31:56 +0200 From: Ralf Gross To: linux-xfs@oss.sgi.com Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) Message-ID: <20070924173155.GI19983@p15145560.pureserver.info> References: <20070923093841.GH19983@p15145560.pureserver.info> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070923093841.GH19983@p15145560.pureserver.info> User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13063 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Ralf-Lists@ralfgross.de Precedence: bulk X-list: xfs Ralf Gross schrieb: > > we have a new large raid array, the shelf has 48 disks, the max. > amount of disks in a single raid 5 set is 16. There will be one global > spare disk, thus we have two raid 5 with 15 data disks and one with 14 > data disk. > > The data on these raid sets will be video data + some meta data. > Typically each set of data consist of a 2 GB + 500 MB + 100 MB + 20 KB > +2 KB file. There will be some dozen of these sets in a single > directory - but not many hundred or thousend. > ... > I already played with different mkfs.xfs options (sw, su) but didn't > see much of a difference. > > The volume sets of the hw raid have the following parameters: > > 11,xx TB (15 data disks): > Chunk Size : 64 KB > (values of 64/128/256 KB are possible, I'll try 256 KB next week) > Stripe Size : 960 KB (15 x 64 KB) > ... I did some more benchmarks with the 64KB/256KB chunk size option of the RAID array and 64K/256K sw option for mkfs.xfs. 4 tests: two RAID 5 volumes (sdd + sdh, both in the same 48 disk shelf), each with 15 data disks + 1 parity, 750 GB SATA disks 1. 256KB chunk size (HW RAID, sdd) + su=256K + sw=15 2. 256KB chunk size (HW RAID, sdd) + su=64K + sw=15 3. 64KB chunk size (HW RAID, sdh) + su=256K + sw=15 4. 64KB chunk size (HW RAID, sdh) + su=64K + sw=15 Although the manual of the HW RAID mentions that a 64KB chunk size would be better with more drives, the result for the 256KB chunk size seems to me better and more important than the mkfs options. The same manual states that RAID 5 would be best for databases... A bit ot: will I waste space on the RAID device with a 256K chunk size and small files? Or does this only depend on the block size of the fs (4KB at the moment). 1.) Chunk Size: 256 KB Stripe Size: 3840 KB Array size: 11135 GB Logical Drive Block Size: 512 bytes (only possible value) mkfs.xfs -d su=256k -d sw=15 /dev/sdd1 /mnt# tiobench --numruns 3 --threads 1 --threads 2 --block 4096 --size 20000 Sequential Reads File Blk Num Avg Maximum Lat% Lat% CPU Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff ------ ----- --- ------ ------ --------- ----------- -------- -------- ----- 20000 4096 1 207.80 23.88% 0.055 50.43 0.00000 0.00000 870 20000 4096 2 197.86 44.29% 0.117 373.10 0.00000 0.00000 447 Random Reads File Blk Num Avg Maximum Lat% Lat% CPU Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff ------- ---- --- ------ ------ --------- ----------- -------- -------- ----- 20000 4096 1 2.90 0.569% 4.035 42.83 0.00000 0.00000 510 20000 4096 2 4.47 1.679% 5.201 69.75 0.00000 0.00000 266 Sequential Writes File Blk Num Avg Maximum Lat% Lat% CPU Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff ------- ---- --- ------ ------ --------- ----------- -------- -------- ----- 20000 4096 1 167.84 36.31% 0.055 9151.42 0.00053 0.00000 462 20000 4096 2 170.77 84.39% 0.099 8471.22 0.00066 0.00000 202 Random Writes File Blk Num Avg Maximum Lat% Lat% CPU Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff ------- ---- --- ------ ------ --------- ----------- -------- -------- ----- 20000 4096 1 1.97 0.990% 0.016 0.05 0.00000 0.00000 199 20000 4096 2 1.68 1.739% 0.019 3.04 0.00000 0.00000 97 2.) Chunk Size: 256 KB Stripe Size: 3840 KB Array size: 11135 GB Logical Drive Block Size: 512 bytes (only possible value) mkfs.xfs -d su=64k -d sw=15 /dev/sdd1 Sequential Reads File Blk Num Avg Maximum Lat% Lat% CPU Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- 20000 4096 1 203.15 25.13% 0.056 47.58 0.00000 0.00000 808 20000 4096 2 190.85 44.67% 0.121 370.55 0.00000 0.00000 427 Random Reads File Blk Num Avg Maximum Lat% Lat% CPU Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- 20000 4096 1 1.98 0.592% 5.908 41.81 0.00000 0.00000 335 20000 4096 2 3.55 1.665% 6.417 69.23 0.00000 0.00000 213 Sequential Writes File Blk Num Avg Maximum Lat% Lat% CPU Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- 20000 4096 1 168.97 35.47% 0.054 8338.06 0.00056 0.00000 476 20000 4096 2 159.21 73.18% 0.109 8133.66 0.00103 0.00000 218 Random Writes File Blk Num Avg Maximum Lat% Lat% CPU Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- 20000 4096 1 2.01 1.046% 0.018 2.46 0.00000 0.00000 192 20000 4096 2 1.78 1.668% 0.020 2.98 0.00000 0.00000 107 3.) Chunk Size: 64 KB Stripe Size: 960 KB Array size: 11135 GB Logical Drive Block Size: 512 bytes (only possible value) mkfs.xfs -d su=256k -d sw=15 /dev/sdh1 Sequential Reads File Blk Num Avg Maximum Lat% Lat% CPU Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- 20000 4096 1 189.84 23.00% 0.061 43.77 0.00000 0.00000 825 20000 4096 2 173.20 40.87% 0.134 365.86 0.00000 0.00000 424 Random Reads File Blk Num Avg Maximum Lat% Lat% CPU Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- 20000 4096 1 2.16 0.461% 5.415 38.47 0.00000 0.00000 469 20000 4096 2 2.94 1.379% 7.772 69.02 0.00000 0.00000 213 Sequential Writes File Blk Num Avg Maximum Lat% Lat% CPU Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- 20000 4096 1 130.48 26.59% 0.076 10970.30 0.00097 0.00000 491 20000 4096 2 124.93 59.08% 0.134 10370.07 0.00173 0.00000 211 Random Writes File Blk Num Avg Maximum Lat% Lat% CPU Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- 20000 4096 1 1.73 0.827% 0.018 2.32 0.00000 0.00000 209 20000 4096 2 1.83 1.609% 0.019 2.88 0.00000 0.00000 114 4.) Chunk Size: 64 KB Stripe Size: 960 KB Array size: 11135 GB Logical Drive Block Size: 512 bytes (only possible value) mkfs.xfs -d su=64k -d sw=15 /dev/sdh1 Sequential Reads File Blk Num Avg Maximum Lat% Lat% CPU Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- 20000 4096 1 193.87 21.96% 0.059 59.45 0.00000 0.00000 883 20000 4096 2 185.08 40.73% 0.125 369.16 0.00000 0.00000 454 Random Reads File Blk Num Avg Maximum Lat% Lat% CPU Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- 20000 4096 1 2.88 0.565% 4.061 39.23 0.00000 0.00000 510 20000 4096 2 4.37 1.640% 5.199 75.55 0.00000 0.00000 266 Sequential Writes File Blk Num Avg Maximum Lat% Lat% CPU Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- 20000 4096 1 143.80 31.12% 0.068 10424.88 0.00072 0.00000 462 20000 4096 2 115.01 53.56% 0.147 11421.10 0.00209 0.00000 215 Random Writes File Blk Num Avg Maximum Lat% Lat% CPU Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- 20000 4096 1 2.05 0.753% 0.016 0.09 0.00000 0.00000 273 20000 4096 2 1.86 1.539% 0.018 0.09 0.00000 0.00000 121 Ralf From owner-xfs@oss.sgi.com Mon Sep 24 11:01:09 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Sep 2007 11:01: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.4 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 l8OI16Q3001147 for ; Mon, 24 Sep 2007 11:01:09 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 1CEFC1C000267; Mon, 24 Sep 2007 14:01:09 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 1A3304019B1E; Mon, 24 Sep 2007 14:01:09 -0400 (EDT) Date: Mon, 24 Sep 2007 14:01:09 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Ralf Gross cc: linux-xfs@oss.sgi.com Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) In-Reply-To: <20070924173155.GI19983@p15145560.pureserver.info> Message-ID: References: <20070923093841.GH19983@p15145560.pureserver.info> <20070924173155.GI19983@p15145560.pureserver.info> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13064 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 A bit ot: will I waste space on the RAID device with a 256K chunk size and small files? Or does this only depend on the block size of the fs (4KB at the moment). That's a good question, I believe its only respective of the filesystem size, but will wait for someone to confirm, nice benchmarks! I use a 1 MiB stripe myself as I found that to give the best performance. Justin. On Mon, 24 Sep 2007, Ralf Gross wrote: > Ralf Gross schrieb: >> >> we have a new large raid array, the shelf has 48 disks, the max. >> amount of disks in a single raid 5 set is 16. There will be one global >> spare disk, thus we have two raid 5 with 15 data disks and one with 14 >> data disk. >> >> The data on these raid sets will be video data + some meta data. >> Typically each set of data consist of a 2 GB + 500 MB + 100 MB + 20 KB >> +2 KB file. There will be some dozen of these sets in a single >> directory - but not many hundred or thousend. >> ... >> I already played with different mkfs.xfs options (sw, su) but didn't >> see much of a difference. >> >> The volume sets of the hw raid have the following parameters: >> >> 11,xx TB (15 data disks): >> Chunk Size : 64 KB >> (values of 64/128/256 KB are possible, I'll try 256 KB next week) >> Stripe Size : 960 KB (15 x 64 KB) >> ... > > I did some more benchmarks with the 64KB/256KB chunk size option of > the RAID array and 64K/256K sw option for mkfs.xfs. > > 4 tests: > two RAID 5 volumes (sdd + sdh, both in the same 48 disk shelf), each > with 15 data disks + 1 parity, 750 GB SATA disks > > 1. 256KB chunk size (HW RAID, sdd) + su=256K + sw=15 > 2. 256KB chunk size (HW RAID, sdd) + su=64K + sw=15 > 3. 64KB chunk size (HW RAID, sdh) + su=256K + sw=15 > 4. 64KB chunk size (HW RAID, sdh) + su=64K + sw=15 > > Although the manual of the HW RAID mentions that a 64KB chunk size would be > better with more drives, the result for the 256KB chunk size seems to > me better and more important than the mkfs options. The same manual > states that RAID 5 would be best for databases... > > A bit ot: will I waste space on the RAID device with a 256K chunk size > and small files? Or does this only depend on the block size of the fs > (4KB at the moment). > > 1.) > Chunk Size: 256 KB > Stripe Size: 3840 KB > Array size: 11135 GB > Logical Drive Block Size: 512 bytes (only possible value) > mkfs.xfs -d su=256k -d sw=15 /dev/sdd1 > > /mnt# tiobench --numruns 3 --threads 1 --threads 2 --block 4096 --size 20000 > > Sequential Reads > File Blk Num Avg Maximum Lat% Lat% CPU > Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff > ------ ----- --- ------ ------ --------- ----------- -------- -------- ----- > 20000 4096 1 207.80 23.88% 0.055 50.43 0.00000 0.00000 870 > 20000 4096 2 197.86 44.29% 0.117 373.10 0.00000 0.00000 447 > > Random Reads > File Blk Num Avg Maximum Lat% Lat% CPU > Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff > ------- ---- --- ------ ------ --------- ----------- -------- -------- ----- > 20000 4096 1 2.90 0.569% 4.035 42.83 0.00000 0.00000 510 > 20000 4096 2 4.47 1.679% 5.201 69.75 0.00000 0.00000 266 > > Sequential Writes > File Blk Num Avg Maximum Lat% Lat% CPU > Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff > ------- ---- --- ------ ------ --------- ----------- -------- -------- ----- > 20000 4096 1 167.84 36.31% 0.055 9151.42 0.00053 0.00000 462 > 20000 4096 2 170.77 84.39% 0.099 8471.22 0.00066 0.00000 202 > > Random Writes > File Blk Num Avg Maximum Lat% Lat% CPU > Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff > ------- ---- --- ------ ------ --------- ----------- -------- -------- ----- > 20000 4096 1 1.97 0.990% 0.016 0.05 0.00000 0.00000 199 > 20000 4096 2 1.68 1.739% 0.019 3.04 0.00000 0.00000 97 > > > 2.) > Chunk Size: 256 KB > Stripe Size: 3840 KB > Array size: 11135 GB > Logical Drive Block Size: 512 bytes (only possible value) > mkfs.xfs -d su=64k -d sw=15 /dev/sdd1 > > Sequential Reads > File Blk Num Avg Maximum Lat% Lat% CPU > Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff > ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- > 20000 4096 1 203.15 25.13% 0.056 47.58 0.00000 0.00000 808 > 20000 4096 2 190.85 44.67% 0.121 370.55 0.00000 0.00000 427 > > Random Reads > File Blk Num Avg Maximum Lat% Lat% CPU > Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff > ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- > 20000 4096 1 1.98 0.592% 5.908 41.81 0.00000 0.00000 335 > 20000 4096 2 3.55 1.665% 6.417 69.23 0.00000 0.00000 213 > > Sequential Writes > File Blk Num Avg Maximum Lat% Lat% CPU > Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff > ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- > 20000 4096 1 168.97 35.47% 0.054 8338.06 0.00056 0.00000 476 > 20000 4096 2 159.21 73.18% 0.109 8133.66 0.00103 0.00000 218 > > Random Writes > File Blk Num Avg Maximum Lat% Lat% CPU > Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff > ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- > 20000 4096 1 2.01 1.046% 0.018 2.46 0.00000 0.00000 192 > 20000 4096 2 1.78 1.668% 0.020 2.98 0.00000 0.00000 107 > > 3.) > Chunk Size: 64 KB > Stripe Size: 960 KB > Array size: 11135 GB > Logical Drive Block Size: 512 bytes (only possible value) > mkfs.xfs -d su=256k -d sw=15 /dev/sdh1 > > Sequential Reads > File Blk Num Avg Maximum Lat% Lat% CPU > Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff > ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- > 20000 4096 1 189.84 23.00% 0.061 43.77 0.00000 0.00000 825 > 20000 4096 2 173.20 40.87% 0.134 365.86 0.00000 0.00000 424 > > Random Reads > File Blk Num Avg Maximum Lat% Lat% CPU > Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff > ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- > 20000 4096 1 2.16 0.461% 5.415 38.47 0.00000 0.00000 469 > 20000 4096 2 2.94 1.379% 7.772 69.02 0.00000 0.00000 213 > > Sequential Writes > File Blk Num Avg Maximum Lat% Lat% CPU > Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff > ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- > 20000 4096 1 130.48 26.59% 0.076 10970.30 0.00097 0.00000 491 > 20000 4096 2 124.93 59.08% 0.134 10370.07 0.00173 0.00000 211 > > Random Writes > File Blk Num Avg Maximum Lat% Lat% CPU > Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff > ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- > 20000 4096 1 1.73 0.827% 0.018 2.32 0.00000 0.00000 209 > 20000 4096 2 1.83 1.609% 0.019 2.88 0.00000 0.00000 114 > > > 4.) > Chunk Size: 64 KB > Stripe Size: 960 KB > Array size: 11135 GB > Logical Drive Block Size: 512 bytes (only possible value) > mkfs.xfs -d su=64k -d sw=15 /dev/sdh1 > > Sequential Reads > File Blk Num Avg Maximum Lat% Lat% CPU > Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff > ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- > 20000 4096 1 193.87 21.96% 0.059 59.45 0.00000 0.00000 883 > 20000 4096 2 185.08 40.73% 0.125 369.16 0.00000 0.00000 454 > > Random Reads > File Blk Num Avg Maximum Lat% Lat% CPU > Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff > ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- > 20000 4096 1 2.88 0.565% 4.061 39.23 0.00000 0.00000 510 > 20000 4096 2 4.37 1.640% 5.199 75.55 0.00000 0.00000 266 > > Sequential Writes > File Blk Num Avg Maximum Lat% Lat% CPU > Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff > ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- > 20000 4096 1 143.80 31.12% 0.068 10424.88 0.00072 0.00000 462 > 20000 4096 2 115.01 53.56% 0.147 11421.10 0.00209 0.00000 215 > > Random Writes > File Blk Num Avg Maximum Lat% Lat% CPU > Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff > ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- > 20000 4096 1 2.05 0.753% 0.016 0.09 0.00000 0.00000 273 > 20000 4096 2 1.86 1.539% 0.018 0.09 0.00000 0.00000 121 > > > Ralf > > From owner-xfs@oss.sgi.com Mon Sep 24 11:07:36 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Sep 2007 11:07: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.9 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 l8OI7WQ3003116 for ; Mon, 24 Sep 2007 11:07:35 -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 l8OI7WA5017823 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 24 Sep 2007 20:07:32 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8OI7WEc017820 for xfs@oss.sgi.com; Mon, 24 Sep 2007 20:07:32 +0200 Date: Mon, 24 Sep 2007 20:07:32 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: [PATCH] xfsidbg: kill vnode leftovers Message-ID: <20070924180732.GA17635@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-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13065 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 While we're at fixing up xfsidbg I have this little gem: Kill the kdbm_vn, kdbm_vnode and xi2vnode xfsidbg commands. The last one just printed a Linux inode (despite it's description) and that is much better done by the inode command in kdb/modules/kdbm_pg.c. The latter two both print the vnode (nothing left here) and the inode and again that is better done using the inode command. Interestingly those latter two did exactly the same despite their quite different descriptions which weren't correct for either command. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/xfsidbg.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfsidbg.c 2007-09-23 14:20:56.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfsidbg.c 2007-09-23 14:21:21.000000000 +0200 @@ -1731,39 +1731,6 @@ printflags(register uint64_t flags, return; } - -static void printvnode(bhv_vnode_t *vp, unsigned long addr) -{ - kdb_printf("vnode: 0x%lx\n", addr); - kdb_printf("\n"); -} - -static int kdbm_vnode( - int argc, - const char **argv) -{ - unsigned long addr; - int nextarg = 1; - long offset = 0; - int diag; - bhv_vnode_t vp; - - if (argc != 1) - return KDB_ARGCOUNT; - - diag = kdbgetaddrarg(argc, argv, &nextarg, &addr, &offset, NULL); - - if (diag) - return diag; - - if ((diag = kdb_getarea(vp, addr))) - return diag; - - printvnode(&vp, addr); - - return 0; -} - #ifdef XFS_INODE_TRACE /* * Print a inode trace entry. @@ -1957,76 +1924,6 @@ static int kdbm_iptraceaddr( #endif /* XFS_INODE_TRACE */ -static void printinode(struct inode *ip) -{ - unsigned long addr; - - - if (ip == NULL) - return; - - kdb_printf(" i_ino = %lu i_count = %u i_size %Ld\n", - ip->i_ino, atomic_read(&ip->i_count), - ip->i_size); -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,0) - kdb_printf( - " i_mode = 0x%x i_nlink = %d i_rdev = 0x%x i_state = 0x%lx\n", - ip->i_mode, ip->i_nlink, - kdev_t_to_nr(ip->i_rdev), ip->i_state); -#else - kdb_printf( - " i_mode = 0x%x i_nlink = %d i_rdev = 0x%x i_state = 0x%lx\n", - ip->i_mode, ip->i_nlink, - ip->i_rdev, ip->i_state); -#endif - kdb_printf(" i_list.nxt = 0x%p i_list.prv = 0x%p\n", - ip->i_list.next, ip->i_list.prev); - kdb_printf(" i_dentry.nxt = 0x%p i_dentry.prv = 0x%p\n", - ip->i_dentry.next, - ip->i_dentry.prev); - - addr = (unsigned long)ip; - - kdb_printf(" i_sb = 0x%p i_op = 0x%p i_data = 0x%lx nrpages = %lu\n", - ip->i_sb, ip->i_op, - addr + offsetof(struct inode, i_data), - ip->i_data.nrpages); - - kdb_printf(" vnode ptr 0x%p\n", vn_from_inode(ip)); -} - - -static int kdbm_vn( - int argc, - const char **argv) -{ - int diag; - int nextarg = 1; - long offset = 0; - unsigned long addr; - struct inode *ip; - bhv_vnode_t vp; - - if (argc != 1) - return KDB_ARGCOUNT; - - diag = kdbgetaddrarg(argc, argv, &nextarg, &addr, &offset, NULL); - if (diag) - return diag; - - if ((diag = kdb_getarea(vp, addr))) - return diag; - - ip = vn_to_inode((bhv_vnode_t *)addr); - kdb_printf("--> Inode @ 0x%p\n", ip); - printinode(ip); - - kdb_printf("--> Vnode @ 0x%lx\n", addr); - printvnode(&vp, addr); - return 0; -} - - static char *bp_flag_vals[] = { /* 0 */ "READ", "WRITE", "MAPPED", "PARTIAL", "ASYNC", /* 5 */ "NONE", "DELWRI", "STALE", "FS_MANAGED", "FS_DATAIOD", @@ -2226,35 +2123,6 @@ kdbm_iomap(int argc, const char **argv) return 0; } -static int -kdbm_i2vnode(int argc, const char **argv) -{ - bhv_vnode_t vp; - struct inode *ip; - unsigned long addr; - long offset=0; - int nextarg; - int diag; - - if (argc != 1) - return KDB_ARGCOUNT; - - nextarg = 1; - if ((diag = kdbgetaddrarg(argc, argv, &nextarg, &addr, &offset, NULL))) - return diag; - ip = (struct inode *)addr; - if ((diag = kdb_getarea(vp, (unsigned long)vn_from_inode(ip)))) - return diag; - - kdb_printf("--> Inode @ 0x%p\n", ip); - printinode(ip); - - kdb_printf("--> Vnode @ 0x%p\n", vn_from_inode(ip)); - printvnode(&vp, (unsigned long)vn_from_inode(ip)); - - return 0; -} - #ifdef XFS_BUF_TRACE static int xfs_buf_trace_entry(ktrace_entry_t *ktep) { @@ -2371,8 +2239,6 @@ struct xif { }; static struct xif xfsidbg_funcs[] = { - { "vn", kdbm_vn, "", "Dump inode/vnode/trace"}, - { "vnode", kdbm_vnode, "", "Dump vnode"}, #ifdef XFS_INODE_TRACE { "iptrace", kdbm_iptrace, "", "Dump inode Trace"}, { "iptraceaddr", kdbm_iptraceaddr, "", @@ -2563,7 +2429,6 @@ static struct xif xfsbuf_funcs[] = { { "xbp", kdbm_bp, "", "Display xfs_buf_t" }, { "xbpflags",kdbm_bp_flags, "", "Display xfs_buf flags" }, { "xiomap", kdbm_iomap, "", "Display IOmap" }, - { "xi2vnode",kdbm_i2vnode, "", "Display Vnode" }, { "xbpdelay",kdbm_bpdelay, "0|1", "Display delwri buffers" }, #ifdef XFS_BUF_TRACE { "xbptrace",kdbm_bptrace, "|", "xfs_buf_t trace" }, From owner-xfs@oss.sgi.com Mon Sep 24 11:27:03 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Sep 2007 11:27: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.5 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 l8OIR1Q3008313 for ; Mon, 24 Sep 2007 11:27:03 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1IZsGY-0000n6-Tf; Mon, 24 Sep 2007 19:02:42 +0100 Date: Mon, 24 Sep 2007 19:02:42 +0100 From: Christoph Hellwig To: Donald Douwsma Cc: xfs-oss Subject: Re: Review: fix mount flags as printed by xfsidbg Message-ID: <20070924180242.GA2865@infradead.org> References: <46F78159.5080907@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46F78159.5080907@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-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13067 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 24, 2007 at 07:20:25PM +1000, Donald Douwsma wrote: > The xfs mount flags have recently undergone some changes. > Update the xfsidbg xmount command to print them correctly. > > Don Looks good. From owner-xfs@oss.sgi.com Mon Sep 24 11:27:00 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Sep 2007 11:27: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.5 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 l8OIQtQ3008262 for ; Mon, 24 Sep 2007 11:27:00 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1IZsH5-0000ne-CB; Mon, 24 Sep 2007 19:03:15 +0100 Date: Mon, 24 Sep 2007 19:03:15 +0100 From: Christoph Hellwig To: Chris Wedgwood Cc: Donald Douwsma , xfs-oss Subject: Re: Review: fix mount flags as printed by xfsidbg Message-ID: <20070924180315.GB2865@infradead.org> References: <46F78159.5080907@sgi.com> <20070924161433.GA4098@puku.stupidest.org> Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20070924161433.GA4098@puku.stupidest.org> 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-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13066 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 24, 2007 at 09:14:33AM -0700, Chris Wedgwood wrote: > On Mon, Sep 24, 2007 at 07:20:25PM +1000, Donald Douwsma wrote: > > > - "32BITINOOPT", /* 0x8000 */ > > + "SMALL_INUMS", /* 0x8000 */ > > why rename that? It's just renamed to what's ζctually in the mount flags. We didn't actually have a 32BITINOOPT flag before so it's a bit of a mistery how the original one got there. From owner-xfs@oss.sgi.com Mon Sep 24 11:27:08 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Sep 2007 11:27:10 -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 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 l8OIR3Q3008341 for ; Mon, 24 Sep 2007 11:27:08 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1IZsHS-0000oU-FS; Mon, 24 Sep 2007 19:03:38 +0100 Date: Mon, 24 Sep 2007 19:03:38 +0100 From: Christoph Hellwig To: Donald Douwsma Cc: xfs-oss Subject: Re: Review: Fix xfsidbg.c compiler warnings on x86_64 Message-ID: <20070924180338.GC2865@infradead.org> References: <46F7809D.1040900@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46F7809D.1040900@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-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13068 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 24, 2007 at 07:17:17PM +1000, Donald Douwsma wrote: > Fix compile warnings for xfsidbg.c as seen on x86_64. Looks good. From owner-xfs@oss.sgi.com Mon Sep 24 11:49:28 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Sep 2007 11:49: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.9 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 l8OInOQ3015048 for ; Mon, 24 Sep 2007 11:49:27 -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 l8OInQA5020736 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 24 Sep 2007 20:49:26 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8OInQI4020734 for xfs@oss.sgi.com; Mon, 24 Sep 2007 20:49:26 +0200 Date: Mon, 24 Sep 2007 20:49:26 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: [PATCH] kill superflous buffer locking Message-ID: <20070924184926.GA20661@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-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13069 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 need to lock any page in xfs_buf.c because we operate on our own address_space and all locking is covered by the buffer semaphore. If we ever switch back to main blockdeive address_space as suggested e.g. for fsblock with a similar scheme the locking will have to be totally revised anyway because the current scheme is neither correct nor coherent with itself. Signed-off-by: Christoph Hellwig 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 2007-09-23 13:28:00.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_buf.c 2007-09-23 14:13:43.000000000 +0200 @@ -396,6 +396,7 @@ _xfs_buf_lookup_pages( congestion_wait(WRITE, HZ/50); goto retry; } + unlock_page(page); XFS_STATS_INC(xb_page_found); @@ -405,10 +406,7 @@ _xfs_buf_lookup_pages( ASSERT(!PagePrivate(page)); if (!PageUptodate(page)) { page_count--; - if (blocksize >= PAGE_CACHE_SIZE) { - if (flags & XBF_READ) - bp->b_locked = 1; - } else if (!PagePrivate(page)) { + if (blocksize < PAGE_CACHE_SIZE && !PagePrivate(page)) { if (test_page_region(page, offset, nbytes)) page_count++; } @@ -418,11 +416,6 @@ _xfs_buf_lookup_pages( offset = 0; } - if (!bp->b_locked) { - for (i = 0; i < bp->b_page_count; i++) - unlock_page(bp->b_pages[i]); - } - if (page_count == bp->b_page_count) bp->b_flags |= XBF_DONE; @@ -747,7 +740,6 @@ xfs_buf_associate_memory( bp->b_page_count = ++i; ptr += PAGE_CACHE_SIZE; } - bp->b_locked = 0; bp->b_count_desired = bp->b_buffer_length = len; bp->b_flags |= XBF_MAPPED; @@ -1093,25 +1085,13 @@ xfs_buf_iostart( return status; } -STATIC_INLINE int -_xfs_buf_iolocked( - xfs_buf_t *bp) -{ - ASSERT(bp->b_flags & (XBF_READ | XBF_WRITE)); - if (bp->b_flags & XBF_READ) - return bp->b_locked; - return 0; -} - STATIC_INLINE void _xfs_buf_ioend( xfs_buf_t *bp, int schedule) { - if (atomic_dec_and_test(&bp->b_io_remaining) == 1) { - bp->b_locked = 0; + if (atomic_dec_and_test(&bp->b_io_remaining) == 1) xfs_buf_ioend(bp, schedule); - } } STATIC int @@ -1146,10 +1126,6 @@ xfs_buf_bio_end_io( if (--bvec >= bio->bi_io_vec) prefetchw(&bvec->bv_page->flags); - - if (_xfs_buf_iolocked(bp)) { - unlock_page(page); - } } while (bvec >= bio->bi_io_vec); _xfs_buf_ioend(bp, 1); @@ -1161,13 +1137,12 @@ STATIC void _xfs_buf_ioapply( xfs_buf_t *bp) { - int i, rw, map_i, total_nr_pages, nr_pages; + int rw, map_i, total_nr_pages, nr_pages; struct bio *bio; int offset = bp->b_offset; int size = bp->b_count_desired; sector_t sector = bp->b_bn; unsigned int blocksize = bp->b_target->bt_bsize; - int locking = _xfs_buf_iolocked(bp); total_nr_pages = bp->b_page_count; map_i = 0; @@ -1190,7 +1165,7 @@ _xfs_buf_ioapply( * filesystem block size is not smaller than the page size. */ if ((bp->b_buffer_length < PAGE_CACHE_SIZE) && - (bp->b_flags & XBF_READ) && locking && + (bp->b_flags & XBF_READ) && (blocksize >= PAGE_CACHE_SIZE)) { bio = bio_alloc(GFP_NOIO, 1); @@ -1207,24 +1182,6 @@ _xfs_buf_ioapply( goto submit_io; } - /* Lock down the pages which we need to for the request */ - if (locking && (bp->b_flags & XBF_WRITE) && (bp->b_locked == 0)) { - for (i = 0; size; i++) { - int nbytes = PAGE_CACHE_SIZE - offset; - struct page *page = bp->b_pages[i]; - - if (nbytes > size) - nbytes = size; - - lock_page(page); - - size -= nbytes; - offset = 0; - } - offset = bp->b_offset; - size = bp->b_count_desired; - } - next_chunk: atomic_inc(&bp->b_io_remaining); nr_pages = BIO_MAX_SECTORS >> (PAGE_SHIFT - BBSHIFT); Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_buf.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_buf.h 2007-09-05 11:17:42.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_buf.h 2007-09-23 14:04:36.000000000 +0200 @@ -143,7 +143,6 @@ typedef struct xfs_buf { void *b_fspriv2; void *b_fspriv3; unsigned short b_error; /* error code on I/O */ - unsigned short b_locked; /* page array is locked */ unsigned int b_page_count; /* size of page array */ unsigned int b_offset; /* page offset in first page */ struct page **b_pages; /* array of page pointers */ Index: linux-2.6-xfs/fs/xfs/xfsidbg.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfsidbg.c 2007-09-23 13:33:07.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfsidbg.c 2007-09-23 14:04:36.000000000 +0200 @@ -2110,9 +2110,9 @@ print_xfs_buf( (unsigned long long) bp->b_file_offset, (unsigned long long) bp->b_buffer_length, bp->b_addr); - kdb_printf(" b_bn 0x%llx b_count_desired 0x%lx b_locked %d\n", + kdb_printf(" b_bn 0x%llx b_count_desired 0x%lxn", (unsigned long long)bp->b_bn, - (unsigned long) bp->b_count_desired, (int)bp->b_locked); + (unsigned long) bp->b_count_desired); kdb_printf(" b_queuetime %ld (now=%ld/age=%ld) b_io_remaining %d\n", bp->b_queuetime, jiffies, bp->b_queuetime + age, bp->b_io_remaining.counter); From owner-xfs@oss.sgi.com Mon Sep 24 12:24:30 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Sep 2007 12:24: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.5 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 l8OJORQ3027493 for ; Mon, 24 Sep 2007 12:24:30 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1IZtXe-0001t7-2s; Mon, 24 Sep 2007 20:24:26 +0100 Date: Mon, 24 Sep 2007 20:24:26 +0100 From: Christoph Hellwig To: Andrew Morton Cc: Christoph Hellwig , Dave Hansen , linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: [PATCH 24/25] r/o bind mounts: track number of mount writers Message-ID: <20070924192425.GA6629@infradead.org> Mail-Followup-To: Christoph Hellwig , Andrew Morton , Dave Hansen , linux-kernel@vger.kernel.org, xfs@oss.sgi.com References: <20070920195249.852667D5@kernel> <20070920195320.38C8E20D@kernel> <20070924175411.GA2314@infradead.org> <20070924121035.8d8c6ce2.akpm@linux-foundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070924121035.8d8c6ce2.akpm@linux-foundation.org> 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-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13070 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 24, 2007 at 12:10:35PM -0700, Andrew Morton wrote: > > As we already say in various messages the percpu counters in here > > look rather fishy. I'd recomment to take a look at the per-cpu > > superblock counters in XFS as they've been debugged quite well > > now and could probably be lifted into a generic library for this > > kind of think. The code is mostly in fs/xfs/xfs_mount.c can > > can be spotted by beeing under #ifdef HAVE_PERCPU_SB. > > > > It also handles cases like hotplug cpu nicely that this code > > seems to work around by always iterating over all possible cpus > > which might not be nice on a dual core laptop with a distro kernel > > that also has to support big iron. > > hm. How come xfs invented a new version of percpu_counters? This code actually predates the generic percpu_counters even if it was merged to mainline later. Neither Dave who wrote it nor me who reviewed it before it was merged thought of percpu_counters probably. Then again this code is considerably more complex due to features actually needed in a very hot fastpath. From owner-xfs@oss.sgi.com Mon Sep 24 13:40:20 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Sep 2007 13:40: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.4 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.2.0-pre1-r499012 Received: from stlx01.stz-softwaretechnik.com (stz-softwaretechnik.de [217.160.223.211]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8OKeFQ3013825 for ; Mon, 24 Sep 2007 13:40:20 -0700 Received: from rg by stlx01.stz-softwaretechnik.com with local (Exim 3.36 #1 (Debian)) id 1IZuiu-0001d7-00 for ; Mon, 24 Sep 2007 22:40:08 +0200 Date: Mon, 24 Sep 2007 22:39:58 +0200 From: Ralf Gross To: linux-xfs@oss.sgi.com Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) Message-ID: <20070924203958.GA4082@p15145560.pureserver.info> References: <20070923093841.GH19983@p15145560.pureserver.info> <20070924173155.GI19983@p15145560.pureserver.info> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13071 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Ralf-Lists@ralfgross.de Precedence: bulk X-list: xfs Justin Piszcz schrieb: >> A bit ot: will I waste space on the RAID device with a 256K chunk size >> and small files? Or does this only depend on the block size of the fs >> (4KB at the moment). > > That's a good question, I believe its only respective of the filesystem > size, but will wait for someone to confirm, nice benchmarks! > > I use a 1 MiB stripe myself as I found that to give the best performance. 256KB is the largest chunk size I can choose for a raid set. BTW: the HW-RAID is an Overland Ultamus 4800. The funny thing is, that performance (256KB chunks) is even better without adding any sw/su option to the mkfs command. mkfs.xfs /dev/sdd1 -f Sequential Reads File Blk Num Avg Maximum Lat% Lat% CPU Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- 20000 4096 1 208.33 23.81% 0.055 49.55 0.00000 0.00000 875 20000 4096 2 199.48 43.72% 0.116 376.85 0.00000 0.00000 456 Random Reads File Blk Num Avg Maximum Lat% Lat% CPU Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- 20000 4096 1 2.83 0.604% 4.131 38.81 0.00000 0.00000 469 20000 4096 2 4.53 1.700% 4.995 67.15 0.00000 0.00000 266 Sequential Writes File Blk Num Avg Maximum Lat% Lat% CPU Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- 20000 4096 1 188.15 42.98% 0.047 7547.93 0.00027 0.00000 438 20000 4096 2 167.76 76.89% 0.100 7521.34 0.00078 0.00000 218 Random Writes File Blk Num Avg Maximum Lat% Lat% CPU Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- 20000 4096 1 2.08 0.869% 0.016 0.13 0.00000 0.00000 239 20000 4096 2 1.80 1.501% 0.020 6.28 0.00000 0.00000 12 Ralf From owner-xfs@oss.sgi.com Mon Sep 24 13:43:39 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Sep 2007 13:43: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=0.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_32, 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 l8OKhaQ3014419 for ; Mon, 24 Sep 2007 13:43:39 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 695471C000260; Mon, 24 Sep 2007 16:43:39 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 64B4B4019B1E; Mon, 24 Sep 2007 16:43:39 -0400 (EDT) Date: Mon, 24 Sep 2007 16:43:39 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Ralf Gross cc: linux-xfs@oss.sgi.com Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) In-Reply-To: <20070924203958.GA4082@p15145560.pureserver.info> Message-ID: References: <20070923093841.GH19983@p15145560.pureserver.info> <20070924173155.GI19983@p15145560.pureserver.info> <20070924203958.GA4082@p15145560.pureserver.info> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13072 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, 24 Sep 2007, Ralf Gross wrote: > Justin Piszcz schrieb: >>> A bit ot: will I waste space on the RAID device with a 256K chunk size >>> and small files? Or does this only depend on the block size of the fs >>> (4KB at the moment). >> >> That's a good question, I believe its only respective of the filesystem >> size, but will wait for someone to confirm, nice benchmarks! >> >> I use a 1 MiB stripe myself as I found that to give the best performance. > > 256KB is the largest chunk size I can choose for a raid set. BTW: the HW-RAID > is an Overland Ultamus 4800. > > The funny thing is, that performance (256KB chunks) is even better without > adding any sw/su option to the mkfs command. > > mkfs.xfs /dev/sdd1 -f > > Sequential Reads > File Blk Num Avg Maximum Lat% Lat% CPU > Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff > ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- > 20000 4096 1 208.33 23.81% 0.055 49.55 0.00000 0.00000 875 > 20000 4096 2 199.48 43.72% 0.116 376.85 0.00000 0.00000 456 > > Random Reads > File Blk Num Avg Maximum Lat% Lat% CPU > Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff > ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- > 20000 4096 1 2.83 0.604% 4.131 38.81 0.00000 0.00000 469 > 20000 4096 2 4.53 1.700% 4.995 67.15 0.00000 0.00000 266 > > Sequential Writes > File Blk Num Avg Maximum Lat% Lat% CPU > Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff > ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- > 20000 4096 1 188.15 42.98% 0.047 7547.93 0.00027 0.00000 438 > 20000 4096 2 167.76 76.89% 0.100 7521.34 0.00078 0.00000 218 > > Random Writes > File Blk Num Avg Maximum Lat% Lat% CPU > Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff > ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- > 20000 4096 1 2.08 0.869% 0.016 0.13 0.00000 0.00000 239 > 20000 4096 2 1.80 1.501% 0.020 6.28 0.00000 0.00000 12 > > > Ralf > > I find that to be the case with SW RAID (defaults are best) Although with 16 drives(?) that is awfully slow. I have 6 SATA's I get 160-180 MiB/s raid5 and 250-280 MiB/s raid 0 (sw raid). With 10 raptors I get ~450 MiB/s write and ~550-600 MiB/s read, again XFS+SW raid. Justin. From owner-xfs@oss.sgi.com Mon Sep 24 14:12:04 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Sep 2007 14:12: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=ANY_BOUNCE_MESSAGE,AWL, BAYES_50,VBOUNCE_MESSAGE autolearn=no version=3.2.0-pre1-r499012 Received: from omr-d33.mx.aol.com (omr-d33.mx.aol.com [205.188.249.131]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8OLC1Q3019803 for ; Mon, 24 Sep 2007 14:12:03 -0700 Received: from rly-da07.mx.aol.com (rly-da07.mx.aol.com [205.188.159.53]) by omr-d33.mx.aol.com (v117.7) with ESMTP id MAILOMRD331-7e5646f825bd146; Mon, 24 Sep 2007 17:01:49 -0400 Received: from localhost (localhost) by rly-da07.mx.aol.com (8.13.8/8.14.1) id l8OL1cx5005490; Mon, 24 Sep 2007 17:01:49 -0400 Date: Mon, 24 Sep 2007 17:01:49 -0400 From: Mail Delivery Subsystem Message-Id: <200709242101.l8OL1cx5005490@rly-da07.mx.aol.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="l8OL1cx5005490.1190667709/rly-da07.mx.aol.com" Subject: Returned mail: see transcript for details Auto-Submitted: auto-generated (failure) X-AOL-INRLY: adsl-153-192-138.mia.bellsouth.net [72.153.192.138] rly-da07 X-AOL-IP: 205.188.159.53 X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13073 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: MAILER-DAEMON@aol.com Precedence: bulk X-list: xfs This is a MIME-encapsulated message --l8OL1cx5005490.1190667709/rly-da07.mx.aol.com The original message was received at Mon, 24 Sep 2007 17:01:26 -0400 from adsl-153-192-138.mia.bellsouth.net [72.153.192.138] *** ATTENTION *** Your e-mail is being returned to you because there was a problem with its delivery. The address which was undeliverable is listed in the section labeled: "----- The following addresses had permanent fatal errors -----". The reason your mail is being returned to you is listed in the section labeled: "----- Transcript of Session Follows -----". The line beginning with "<<<" describes the specific reason your e-mail could not be delivered. The next line contains a second error message which is a general translation for other e-mail servers. Please direct further questions regarding this message to your e-mail administrator. --AOL Postmaster ----- The following addresses had permanent fatal errors ----- (reason: 554 TRANSACTION FAILED - Unrepairable Virus Detected. Your mail has not been sent.) ----- Transcript of session follows ----- ... while talking to air-da09.mail.aol.com.: >>> DATA <<< 554 TRANSACTION FAILED - Unrepairable Virus Detected. Your mail has not been sent. 554 5.0.0 Service unavailable --l8OL1cx5005490.1190667709/rly-da07.mx.aol.com Content-Type: message/delivery-status Reporting-MTA: dns; rly-da07.mx.aol.com Arrival-Date: Mon, 24 Sep 2007 17:01:26 -0400 Final-Recipient: RFC822; tiffanie8020@aol.com Action: failed Status: 5.0.0 Remote-MTA: DNS; air-da09.mail.aol.com Diagnostic-Code: SMTP; 554 TRANSACTION FAILED - Unrepairable Virus Detected. Your mail has not been sent. Last-Attempt-Date: Mon, 24 Sep 2007 17:01:49 -0400 --l8OL1cx5005490.1190667709/rly-da07.mx.aol.com Content-Type: text/rfc822-headers Received: from oss.sgi.com (adsl-153-192-138.mia.bellsouth.net [72.153.192.138]) by rly-da07.mx.aol.com (v119.9) with ESMTP id MAILRELAYINDA076-a7e46f825a455; Mon, 24 Sep 2007 17:01:25 -0400 From: xfs@oss.sgi.com To: tiffanie8020@aol.com Subject: Message could not be delivered Date: Mon, 24 Sep 2007 16:58:52 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0007_5F12F1BD.DE916BFC" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-AOL-IP: 72.153.192.138 X-AOL-SCOLL-SCORE: 0:2:327809760:9395240 X-AOL-SCOLL-URL_COUNT: X-AOL-SCOLL-AUTHENTICATION: listenair ; SPF_helo : X-AOL-SCOLL-AUTHENTICATION: listenair ; SPF_822_from : Message-ID: <200709241701.a7e46f825a455@rly-da07.mx.aol.com> --l8OL1cx5005490.1190667709/rly-da07.mx.aol.com-- From owner-xfs@oss.sgi.com Mon Sep 24 14:34:17 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Sep 2007 14:34: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.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_32 autolearn=no version=3.2.0-pre1-r499012 Received: from stlx01.stz-softwaretechnik.com (stz-softwaretechnik.de [217.160.223.211]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8OLYFQ3024111 for ; Mon, 24 Sep 2007 14:34:16 -0700 Received: from rg by stlx01.stz-softwaretechnik.com with local (Exim 3.36 #1 (Debian)) id 1IZvZA-00043u-00 for ; Mon, 24 Sep 2007 23:34:08 +0200 Date: Mon, 24 Sep 2007 23:33:58 +0200 From: Ralf Gross To: linux-xfs@oss.sgi.com Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) Message-ID: <20070924213358.GB4082@p15145560.pureserver.info> References: <20070923093841.GH19983@p15145560.pureserver.info> <20070924173155.GI19983@p15145560.pureserver.info> <20070924203958.GA4082@p15145560.pureserver.info> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13074 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Ralf-Lists@ralfgross.de Precedence: bulk X-list: xfs Justin Piszcz schrieb: > > > On Mon, 24 Sep 2007, Ralf Gross wrote: > > >Justin Piszcz schrieb: > >>>A bit ot: will I waste space on the RAID device with a 256K chunk size > >>>and small files? Or does this only depend on the block size of the fs > >>>(4KB at the moment). > >> > >>That's a good question, I believe its only respective of the filesystem > >>size, but will wait for someone to confirm, nice benchmarks! > >> > >>I use a 1 MiB stripe myself as I found that to give the best performance. > > > >256KB is the largest chunk size I can choose for a raid set. BTW: the > >HW-RAID > >is an Overland Ultamus 4800. > > > >The funny thing is, that performance (256KB chunks) is even better without > >adding any sw/su option to the mkfs command. > > > >mkfs.xfs /dev/sdd1 -f > > > >Sequential Reads > >File Blk Num Avg Maximum Lat% Lat% > >CPU > >Size Size Thr Rate (CPU%) Latency Latency >2s >10s > >Eff > >----- ----- --- ------ ------ --------- ----------- -------- -------- > >----- > >20000 4096 1 208.33 23.81% 0.055 49.55 0.00000 0.00000 > >875 > >20000 4096 2 199.48 43.72% 0.116 376.85 0.00000 0.00000 > >456 > > > >Random Reads > >File Blk Num Avg Maximum Lat% Lat% > >CPU > >Size Size Thr Rate (CPU%) Latency Latency >2s >10s > >Eff > >----- ----- --- ------ ------ --------- ----------- -------- -------- > >----- > >20000 4096 1 2.83 0.604% 4.131 38.81 0.00000 0.00000 > >469 > >20000 4096 2 4.53 1.700% 4.995 67.15 0.00000 0.00000 > >266 > > > >Sequential Writes > >File Blk Num Avg Maximum Lat% Lat% > >CPU > >Size Size Thr Rate (CPU%) Latency Latency >2s >10s > >Eff > >----- ----- --- ------ ------ --------- ----------- -------- -------- > >----- > >20000 4096 1 188.15 42.98% 0.047 7547.93 0.00027 0.00000 > >438 > >20000 4096 2 167.76 76.89% 0.100 7521.34 0.00078 0.00000 > >218 > > > >Random Writes > >File Blk Num Avg Maximum Lat% Lat% > >CPU > >Size Size Thr Rate (CPU%) Latency Latency >2s >10s > >Eff > >----- ----- --- ------ ------ --------- ----------- -------- -------- > >----- > >20000 4096 1 2.08 0.869% 0.016 0.13 0.00000 0.00000 > >239 > >20000 4096 2 1.80 1.501% 0.020 6.28 0.00000 0.00000 > >12 > > > > I find that to be the case with SW RAID (defaults are best) > > Although with 16 drives(?) that is awfully slow. > > I have 6 SATA's I get 160-180 MiB/s raid5 and 250-280 MiB/s raid 0 (sw > raid). > > With 10 raptors I get ~450 MiB/s write and ~550-600 MiB/s read, again > XFS+SW raid. Hm, with the different HW-RAIDs I've used so far (easyRAID, Infortrend, internal Areca controller), I always got 160-200 MiB/s read/write with 7-15 disks. That's one reason why I asked if there are some xfs options I could use for better performance. But I guess fs options won't boost performance that much. Ralf From owner-xfs@oss.sgi.com Mon Sep 24 14:36:52 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Sep 2007 14:36:55 -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_00,J_CHICKENPOX_32, 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 l8OLamQ3024789 for ; Mon, 24 Sep 2007 14:36:52 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 29DED1C000260; Mon, 24 Sep 2007 17:36:52 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 252474019B1E; Mon, 24 Sep 2007 17:36:52 -0400 (EDT) Date: Mon, 24 Sep 2007 17:36:52 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Ralf Gross cc: linux-xfs@oss.sgi.com Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) In-Reply-To: <20070924213358.GB4082@p15145560.pureserver.info> Message-ID: References: <20070923093841.GH19983@p15145560.pureserver.info> <20070924173155.GI19983@p15145560.pureserver.info> <20070924203958.GA4082@p15145560.pureserver.info> <20070924213358.GB4082@p15145560.pureserver.info> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13075 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, 24 Sep 2007, Ralf Gross wrote: > Justin Piszcz schrieb: >> >> >> On Mon, 24 Sep 2007, Ralf Gross wrote: >> >>> Justin Piszcz schrieb: >>>>> A bit ot: will I waste space on the RAID device with a 256K chunk size >>>>> and small files? Or does this only depend on the block size of the fs >>>>> (4KB at the moment). >>>> >>>> That's a good question, I believe its only respective of the filesystem >>>> size, but will wait for someone to confirm, nice benchmarks! >>>> >>>> I use a 1 MiB stripe myself as I found that to give the best performance. >>> >>> 256KB is the largest chunk size I can choose for a raid set. BTW: the >>> HW-RAID >>> is an Overland Ultamus 4800. >>> >>> The funny thing is, that performance (256KB chunks) is even better without >>> adding any sw/su option to the mkfs command. >>> >>> mkfs.xfs /dev/sdd1 -f >>> >>> Sequential Reads >>> File Blk Num Avg Maximum Lat% Lat% >>> CPU >>> Size Size Thr Rate (CPU%) Latency Latency >2s >10s >>> Eff >>> ----- ----- --- ------ ------ --------- ----------- -------- -------- >>> ----- >>> 20000 4096 1 208.33 23.81% 0.055 49.55 0.00000 0.00000 >>> 875 >>> 20000 4096 2 199.48 43.72% 0.116 376.85 0.00000 0.00000 >>> 456 >>> >>> Random Reads >>> File Blk Num Avg Maximum Lat% Lat% >>> CPU >>> Size Size Thr Rate (CPU%) Latency Latency >2s >10s >>> Eff >>> ----- ----- --- ------ ------ --------- ----------- -------- -------- >>> ----- >>> 20000 4096 1 2.83 0.604% 4.131 38.81 0.00000 0.00000 >>> 469 >>> 20000 4096 2 4.53 1.700% 4.995 67.15 0.00000 0.00000 >>> 266 >>> >>> Sequential Writes >>> File Blk Num Avg Maximum Lat% Lat% >>> CPU >>> Size Size Thr Rate (CPU%) Latency Latency >2s >10s >>> Eff >>> ----- ----- --- ------ ------ --------- ----------- -------- -------- >>> ----- >>> 20000 4096 1 188.15 42.98% 0.047 7547.93 0.00027 0.00000 >>> 438 >>> 20000 4096 2 167.76 76.89% 0.100 7521.34 0.00078 0.00000 >>> 218 >>> >>> Random Writes >>> File Blk Num Avg Maximum Lat% Lat% >>> CPU >>> Size Size Thr Rate (CPU%) Latency Latency >2s >10s >>> Eff >>> ----- ----- --- ------ ------ --------- ----------- -------- -------- >>> ----- >>> 20000 4096 1 2.08 0.869% 0.016 0.13 0.00000 0.00000 >>> 239 >>> 20000 4096 2 1.80 1.501% 0.020 6.28 0.00000 0.00000 >>> 12 >>> >> >> I find that to be the case with SW RAID (defaults are best) >> >> Although with 16 drives(?) that is awfully slow. >> >> I have 6 SATA's I get 160-180 MiB/s raid5 and 250-280 MiB/s raid 0 (sw >> raid). >> >> With 10 raptors I get ~450 MiB/s write and ~550-600 MiB/s read, again >> XFS+SW raid. > > Hm, with the different HW-RAIDs I've used so far (easyRAID, > Infortrend, internal Areca controller), I always got 160-200 MiB/s > read/write with 7-15 disks. That's one reason why I asked if there are > some xfs options I could use for better performance. But I guess fs > options won't boost performance that much. > > Ralf > > What do you get when (reading) from the raw device? dd if=/dev/sda bs=1M count=10240 From owner-xfs@oss.sgi.com Mon Sep 24 14:52:43 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Sep 2007 14:52: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=-0.5 required=5.0 tests=AWL,BAYES_05 autolearn=ham version=3.2.0-pre1-r499012 Received: from stlx01.stz-softwaretechnik.com (stz-softwaretechnik.de [217.160.223.211]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8OLqeQ3027191 for ; Mon, 24 Sep 2007 14:52:43 -0700 Received: from rg by stlx01.stz-softwaretechnik.com with local (Exim 3.36 #1 (Debian)) id 1IZvqz-0004Yy-00 for ; Mon, 24 Sep 2007 23:52:33 +0200 Date: Mon, 24 Sep 2007 23:52:23 +0200 From: Ralf Gross To: linux-xfs@oss.sgi.com Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) Message-ID: <20070924215223.GC4082@p15145560.pureserver.info> References: <20070923093841.GH19983@p15145560.pureserver.info> <20070924173155.GI19983@p15145560.pureserver.info> <20070924203958.GA4082@p15145560.pureserver.info> <20070924213358.GB4082@p15145560.pureserver.info> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13076 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Ralf-Lists@ralfgross.de Precedence: bulk X-list: xfs Justin Piszcz schrieb: > >>I find that to be the case with SW RAID (defaults are best) > >> > >>Although with 16 drives(?) that is awfully slow. > >> > >>I have 6 SATA's I get 160-180 MiB/s raid5 and 250-280 MiB/s raid 0 (sw > >>raid). > >> > >>With 10 raptors I get ~450 MiB/s write and ~550-600 MiB/s read, again > >>XFS+SW raid. > > > >Hm, with the different HW-RAIDs I've used so far (easyRAID, > >Infortrend, internal Areca controller), I always got 160-200 MiB/s > >read/write with 7-15 disks. That's one reason why I asked if there are > >some xfs options I could use for better performance. But I guess fs > >options won't boost performance that much. > > What do you get when (reading) from the raw device? > > dd if=/dev/sda bs=1M count=10240 The server has 16 GB RAM, so I tried it with 20 GB of data. dd if=/dev/sdd of=/dev/null bs=1M count=20480 20480+0 Datensδtze ein 20480+0 Datensδtze aus 21474836480 Bytes (21 GB) kopiert, 95,3738 Sekunden, 225 MB/s and a second try: dd if=/dev/sdd of=/dev/null bs=1M count=20480 20480+0 Datensδtze ein 20480+0 Datensδtze aus 21474836480 Bytes (21 GB) kopiert, 123,78 Sekunden, 173 MB/s I'm taoo tired to interprete these numbers at the moment, I'll do some more testing tomorrow. Good night, Ralf From owner-xfs@oss.sgi.com Mon Sep 24 17:11:44 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Sep 2007 17:11: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.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_71, J_CHICKENPOX_72,J_CHICKENPOX_74,SPF_HELO_PASS 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 l8P0BfQ3000813 for ; Mon, 24 Sep 2007 17:11:43 -0700 Received: from liberator.sandeen.net (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 B119B18011E8F for ; Mon, 24 Sep 2007 19:11:44 -0500 (CDT) Message-ID: <46F85240.1060206@sandeen.net> Date: Mon, 24 Sep 2007 19:11:44 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: xfs-oss Subject: [PATCH] lose xfs_hex_dump in favor of print_hex_dump Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13077 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 No need for xfs to have its own hex dumping routine now that the kernel has one. Signed-off-by: Eric Sandeen Index: linux-2.6-xfs/fs/xfs/xfs_error.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_error.c +++ linux-2.6-xfs/fs/xfs/xfs_error.c @@ -230,37 +230,6 @@ xfs_error_report( } } -STATIC void -xfs_hex_dump(void *p, int length) -{ - __uint8_t *uip = (__uint8_t*)p; - int i; - char sbuf[128], *s; - - s = sbuf; - *s = '\0'; - for (i=0; i; Mon, 24 Sep 2007 17:13:31 -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 KAA07324; Tue, 25 Sep 2007 10:13:22 +1000 Date: Tue, 25 Sep 2007 10:17:25 +1000 To: "Eric Sandeen" Subject: Re: something very strange w/ filestreams... From: "Barry Naujok" Organization: SGI Cc: "David Chinner" , xfs-oss Content-Type: multipart/mixed; boundary=----------RRBUyM2iZOu877jLrikszB MIME-Version: 1.0 References: <46F49C80.60007@sandeen.net> <20070923092444.GQ995458@sgi.com> <46F7B04D.70809@sandeen.net> Message-ID: In-Reply-To: <46F7B04D.70809@sandeen.net> User-Agent: Opera Mail/9.10 (Win32) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13078 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 ------------RRBUyM2iZOu877jLrikszB Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 Content-Transfer-Encoding: Quoted-Printable On Mon, 24 Sep 2007 22:40:45 +1000, Eric Sandeen =20= =20 wrote: > Barry Naujok wrote: >> On Sun, 23 Sep 2007 19:24:44 +1000, David Chinner wrote: >> >>> Barry - I think xfs_repair might be finding the incorrect superblock >>> for the repair. Tests 172, 173 and 174 use less than the whole disk, >>> so there are going to be stale superblocks all over the place.... >>> >>>> hm, no zone name, length of 0x22222274? >>>> >>>> I already provided a metadump image to Barry, but I wonder why the >>>> timing(?) seems to make a difference here... first sign of things=20= =20 >>>> going >>>> awry in repair is: >>>> >>>> Phase 2 - using internal log >>>> - zero log... >>>> - scan filesystem freespace and inode maps... >>>> bad length 131072 for agf 0, should be 4096 >>>> bad length # 131072 for agi 0, should be 4096 >>> Yes - test 173 uses 1GB filesystem with 64x16MB AGs - 4096 * 4k block >>> size =3D 16MB AG. definitely looks like a stale superblock being >>> found. >>> >>> Barry, I think that the secondary superblock needs better verification >>> (e.g. that there really are AG headers where the sb says there >>> are supposed to be and all the lengths match up). >>> >>> Eric - you can relax. Filestreams is not hosing your filesystem; >>> xfs_reapir >>> is.... >> >> Test 178 is designed to test mkfs.xfs in >> http://oss.sgi.com/archives/xfs/2007-07/msg00139.html and >> will still make xfs_repair go bananas if there is other >> old AG headers. >> >> So, before running this test, you should make sure your test >> partitions are completely zeroed from mkfs's that occurred >> before that recent version of mkfs.xfs was installed. > > I dd'd over the whole test partition, ran the sequence, and hit the=20=20 > problem. Yeah, worked it out yesterday but never got around to doing another email. It's a combination of the two filestreams tests which do small filesystems and mkfs.xfs doesn't wipe beyond the new filesystem size. Zero the disk, try the attached patch and see if that fixes the problem. Barry.= ------------RRBUyM2iZOu877jLrikszB Content-Disposition: attachment; filename=better_ag_zeroing_in_mkfs.patch Content-Type: application/octet-stream; name=better_ag_zeroing_in_mkfs.patch Content-Transfer-Encoding: Base64 LS0tIGEveGZzcHJvZ3MvbWtmcy94ZnNfbWtmcy5jCTIwMDctMDktMjUgMTA6 MTI6NDIuMDAwMDAwMDAwICsxMDAwCisrKyBiL3hmc3Byb2dzL21rZnMveGZz X21rZnMuYwkyMDA3LTA5LTI1IDEwOjExOjM2Ljk1NTUxNjcyOSArMTAwMApA QCAtNTU4LDE1ICs1NTgsMTIgQEAgemVyb19vbGRfeGZzX3N0cnVjdHVyZXMo CiAJCWdvdG8gZG9uZTsKIAogCS8qCi0JICogYmxvY2sgc2l6ZSBhbmQgYmFz aWMgZ2VvbWV0cnkgc2VlbXMgYWxyaWdodCwgemVybyB0aGUgc2Vjb25kYXJp ZXMsCi0JICogYnV0IGRvbid0IGdvIGJleW9uZCB0aGUgZW5kIG9mIHRoZSBu ZXcgZmlsZXN5c3RlbS4KKwkgKiBibG9jayBzaXplIGFuZCBiYXNpYyBnZW9t ZXRyeSBzZWVtcyBhbHJpZ2h0LCB6ZXJvIHRoZSBzZWNvbmRhcmllcy4KIAkg Ki8KIAliemVybyhidWYsIG5ld19zYi0+c2Jfc2VjdHNpemUpOwogCW9mZiA9 IDA7CiAJZm9yIChpID0gMTsgaSA8IHNiLnNiX2FnY291bnQ7IGkrKykgIHsK IAkJb2ZmICs9IHNiLnNiX2FnYmxvY2tzOwotCQlpZiAob2ZmID49IG5ld19z Yi0+c2JfZGJsb2NrcykKLQkJCWJyZWFrOwogCQlpZiAocHdyaXRlNjQoeGkt PmRmZCwgYnVmLCBuZXdfc2ItPnNiX3NlY3RzaXplLAogCQkJCQlvZmYgPDwg c2Iuc2JfYmxvY2tsb2cpID09IC0xKQogCQkJYnJlYWs7CkBAIC0yMTE1LDYg KzIxMTIsNyBAQCBhbiBBRyBzaXplIHRoYXQgaXMgb25lIHN0cmlwZSB1bml0 IHNtYWxsCiAJCQkJICAgIEJUT0JCKFdIQUNLX1NJWkUpKTsKIAkJYnplcm8o WEZTX0JVRl9QVFIoYnVmKSwgV0hBQ0tfU0laRSk7CiAJCWxpYnhmc193cml0 ZWJ1ZihidWYsIExJQlhGU19FWElUX09OX0ZBSUxVUkUpOworCQlsaWJ4ZnNf cHVyZ2VidWYoYnVmKTsKIAl9CiAKIAkvKgo= ------------RRBUyM2iZOu877jLrikszB-- From owner-xfs@oss.sgi.com Mon Sep 24 17:32:33 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Sep 2007 17:32: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.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l8P0WWQ3006341 for ; Mon, 24 Sep 2007 17:32:33 -0700 Received: (qmail 83053 invoked from network); 25 Sep 2007 00:32:35 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@24.5.75.45 with login) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 25 Sep 2007 00:32:35 -0000 X-YMail-OSG: 2QRQ_egVM1l8wlE.snHo2TzG78stRxh6YZNGZGoBjeeQ2MR5S9CY3sCb6WcMEFbggumoJva0JQ-- Received: by tuatara.stupidest.org (Postfix, from userid 10000) id 0B3A3287C6F0; Mon, 24 Sep 2007 17:32:33 -0700 (PDT) Date: Mon, 24 Sep 2007 17:32:32 -0700 From: Chris Wedgwood To: Eric Sandeen Cc: xfs-oss Subject: Re: [PATCH] lose xfs_hex_dump in favor of print_hex_dump Message-ID: <20070925003232.GA26663@puku.stupidest.org> References: <46F85240.1060206@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46F85240.1060206@sandeen.net> X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13079 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: xfs On Mon, Sep 24, 2007 at 07:11:44PM -0500, Eric Sandeen wrote: > +extern void xfs_hex_dump(void *p, int length); > + > +void > +xfs_hex_dump(void *p, int length) > +{ > + print_hex_dump(KERN_ALERT, "", DUMP_PREFIX_OFFSET, 16, 1, p, length, 1); > +} Is this symbol exported/needed? If not then why not make it a #define or an inline in the header where you have the prototype? From owner-xfs@oss.sgi.com Mon Sep 24 18:31:47 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Sep 2007 18:31: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,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 l8P1VfQ3020704 for ; Mon, 24 Sep 2007 18:31:46 -0700 Received: from liberator.sandeen.net (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 378E918011E99; Mon, 24 Sep 2007 20:31:45 -0500 (CDT) Message-ID: <46F86501.7070605@sandeen.net> Date: Mon, 24 Sep 2007 20:31:45 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Chris Wedgwood CC: xfs-oss Subject: Re: [PATCH] lose xfs_hex_dump in favor of print_hex_dump References: <46F85240.1060206@sandeen.net> <20070925003232.GA26663@puku.stupidest.org> In-Reply-To: <20070925003232.GA26663@puku.stupidest.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13080 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 Chris Wedgwood wrote: > On Mon, Sep 24, 2007 at 07:11:44PM -0500, Eric Sandeen wrote: > >> +extern void xfs_hex_dump(void *p, int length); >> + > >> +void >> +xfs_hex_dump(void *p, int length) >> +{ >> + print_hex_dump(KERN_ALERT, "", DUMP_PREFIX_OFFSET, 16, 1, p, length, 1); >> +} > > Is this symbol exported/needed? If not then why not make it a #define > or an inline in the header where you have the prototype? Yeah, I suppose that might be better.... I just followed the lead of xfs_cmn_err etc. The only reason I left a wrapper was for cattelan's BSD exploits (er, adventures) ;-) I could imagine it getting called from other places, but for now it only has one caller, xfs_corruption_error (so really, even the length argument is never anything other than 16...) -Eric From owner-xfs@oss.sgi.com Mon Sep 24 18:32:57 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Sep 2007 18:32: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,J_CHICKENPOX_43, SPF_HELO_PASS 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 l8P1WtQ3020978 for ; Mon, 24 Sep 2007 18:32:57 -0700 Received: from liberator.sandeen.net (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 1BD0418011E9B; Mon, 24 Sep 2007 20:32:59 -0500 (CDT) Message-ID: <46F8654B.9010203@sandeen.net> Date: Mon, 24 Sep 2007 20:32:59 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Barry Naujok CC: David Chinner , xfs-oss Subject: Re: something very strange w/ filestreams... References: <46F49C80.60007@sandeen.net> <20070923092444.GQ995458@sgi.com> <46F7B04D.70809@sandeen.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13081 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 Barry Naujok wrote: >>> So, before running this test, you should make sure your test >>> partitions are completely zeroed from mkfs's that occurred >>> before that recent version of mkfs.xfs was installed. >> I dd'd over the whole test partition, ran the sequence, and hit the >> problem. > > Yeah, worked it out yesterday but never got around to doing another > email. It's a combination of the two filestreams tests which do > small filesystems and mkfs.xfs doesn't wipe beyond the new > filesystem size. Zero the disk, try the attached patch and see > if that fixes the problem. > > Barry. Ok, but what about that double free? -Eric From owner-xfs@oss.sgi.com Mon Sep 24 20:50:59 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Sep 2007 20:51:03 -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 l8P3osQ3011995 for ; Mon, 24 Sep 2007 20:50:57 -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 NAA11718; Tue, 25 Sep 2007 13:50:49 +1000 Message-ID: <46F88602.4040104@sgi.com> Date: Tue, 25 Sep 2007 13:52:34 +1000 From: Vlad Apostolov User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH] cleanup vnode useage in xfs_dm.c References: <20070923114339.GB9585@lst.de> In-Reply-To: <20070923114339.GB9585@lst.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13082 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 It is looking good Christoph. I also built and tested it with XFS DMAPI QA all went fine. I think it is time to kill the 2.4 / 2.6 compat code as we are going to drop the XFS 2.4 tree soon. Do you have a patch for this or I could do it? Regards, Vlad Christoph Hellwig wrote: > Avoid passing around the vnode in xfs_dm.c but pass the xfs_inode / > Linux inode / struct address_space as apropinquate. > > p.s. is there a chance we can kill all that 2.4 / early 2.6 compat code > in dmapi one day? > > > Signed-off-by: Christoph Hellwig > > Index: linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/dmapi/xfs_dm.c 2007-09-19 18:51:01.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c 2007-09-19 18:53:41.000000000 +0200 > @@ -217,25 +217,35 @@ xfs_dm_send_data_event( > * > */ > > + > +#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0) > STATIC int > prohibited_mr_events( > - bhv_vnode_t *vp) > + struct address_space *mapping) > { > - struct address_space *mapping = vn_to_inode(vp)->i_mapping; > int prohibited = (1 << DM_EVENT_READ); > -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,0) > - struct vm_area_struct *vma = NULL; > -#endif > > - if (!VN_MAPPED(vp)) > + if (!mapping_mapped(mapping)) > return 0; > > -#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0) > spin_lock(&mapping->i_mmap_lock); > if (mapping_writably_mapped(mapping)) > prohibited |= (1 << DM_EVENT_WRITE); > spin_unlock(&mapping->i_mmap_lock); > + > + return prohibited; > +} > #else > +STATIC int > +prohibited_mr_events( > + struct address_space *mapping) > +{ > + int prohibited = (1 << DM_EVENT_READ); > + struct vm_area_struct *vma = NULL; > + > + if (!VN_MAPPED(inode_to_vn(mapping->host))) > + return 0; > + > spin_lock(&mapping->i_shared_lock); > for (vma = mapping->i_mmap_shared; vma; vma = vma->vm_next_share) { > if (vma->vm_flags & VM_WRITE) { > @@ -250,16 +260,16 @@ prohibited_mr_events( > } > } > spin_unlock(&mapping->i_shared_lock); > -#endif > > return prohibited; > } > +#endif > > > #ifdef DEBUG_RIGHTS > STATIC int > xfs_vp_to_hexhandle( > - bhv_vnode_t *vp, > + struct inode *inode, > u_int type, > char *buffer) > { > @@ -269,7 +279,11 @@ xfs_vp_to_hexhandle( > int error; > int i; > > - if ((error = dm_vp_to_handle(vp, &handle))) > + /* > + * XXX: dm_vp_to_handle doesn't exist. > + * Looks like this debug code is rather dead. > + */ > + if ((error = dm_vp_to_handle(inode, &handle))) > return(error); > > if (type == DM_FSYS_OBJ) { /* a filesystem handle */ > @@ -465,7 +479,6 @@ xfs_ip_to_stat( > dm_stat_t *buf) > { > xfs_icdinode_t *dic = &ip->i_d; > - bhv_vnode_t *vp = XFS_ITOV(ip); > > buf->dt_ino = ino; > buf->dt_nlink = dic->di_nlink; > @@ -474,8 +487,8 @@ xfs_ip_to_stat( > buf->dt_uid = dic->di_uid; > buf->dt_gid = dic->di_gid; > buf->dt_size = XFS_ISIZE(ip); > - buf->dt_dev = new_encode_dev(vp->i_sb->s_dev); > - vn_atime_to_time_t(vp, &buf->dt_atime); > + buf->dt_dev = XFS_TO_HOST_DEVT(mp); > + vn_atime_to_time_t(XFS_ITOV(ip), &buf->dt_atime); > buf->dt_mtime = dic->di_mtime.t_sec; > buf->dt_ctime = dic->di_ctime.t_sec; > buf->dt_xfs_xflags = xfs_ip2dmflags(ip); > @@ -554,7 +567,6 @@ xfs_dm_bulkall_iget_one( > char *attr_name, > caddr_t attr_buf) > { > - bhv_vnode_t *vp; > xfs_inode_t *ip; > dm_handle_t handle; > u_int xstat_sz = *xstat_szp; > @@ -569,10 +581,9 @@ xfs_dm_bulkall_iget_one( > xfs_iput_new(ip, XFS_ILOCK_SHARED); > return ENOENT; > } > - vp = XFS_ITOV(ip); > > xfs_ip_to_stat(mp, ino, ip, &xbuf->dx_statinfo); > - dm_ip_to_handle(vn_to_inode(vp), &handle); > + dm_ip_to_handle(ip->i_vnode, &handle); > xfs_dm_handle_to_xstat(xbuf, xstat_sz, &handle, sizeof(handle)); > > /* Drop ILOCK_SHARED for call to xfs_attr_get */ > @@ -581,7 +592,7 @@ xfs_dm_bulkall_iget_one( > memset(&xbuf->dx_attrdata, 0, sizeof(dm_vardata_t)); > error = xfs_attr_get(ip, attr_name, attr_buf, > &value_len, ATTR_ROOT, sys_cred); > - VN_RELE(vp); > + iput(ip->i_vnode); > > DM_EA_XLATE_ERR(error); > if (error && (error != ENOATTR)) { > @@ -837,7 +848,7 @@ xfs_dm_bulkattr_iget_one( > } > > xfs_ip_to_stat(mp, ino, ip, sbuf); > - dm_ip_to_handle(vn_to_inode(XFS_ITOV(ip)), &handle); > + dm_ip_to_handle(ip->i_vnode, &handle); > xfs_dm_handle_to_stat(sbuf, stat_sz, &handle, sizeof(handle)); > > xfs_iput(ip, XFS_ILOCK_SHARED); > @@ -925,7 +936,7 @@ xfs_dm_bulkattr_one( > return error; > } > > -/* xfs_dm_f_get_eventlist - return the dm_eventset_t mask for inode vp. */ > +/* xfs_dm_f_get_eventlist - return the dm_eventset_t mask for inode ip. */ > > STATIC int > xfs_dm_f_get_eventlist( > @@ -969,7 +980,6 @@ xfs_dm_f_get_eventlist( > > STATIC int > xfs_dm_f_set_eventlist( > - bhv_vnode_t *vp, > xfs_inode_t *ip, > dm_right_t right, > dm_eventset_t *eventsetp, /* in kernel space! */ > @@ -990,7 +1000,7 @@ xfs_dm_f_set_eventlist( > return(EINVAL); > max_mask = (1 << maxevent) - 1; > > - if (VN_ISDIR(vp)) { > + if (S_ISDIR(ip->i_d.di_mode)) { > valid_events = DM_XFS_VALID_DIRECTORY_EVENTS; > } else { /* file or symlink */ > valid_events = DM_XFS_VALID_FILE_EVENTS; > @@ -1019,7 +1029,7 @@ xfs_dm_f_set_eventlist( > ip->i_d.di_dmevmask = (eventset & max_mask) | (ip->i_d.di_dmevmask & ~max_mask); > > xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); > - VN_HOLD(vp); > + igrab(ip->i_vnode); > xfs_trans_commit(tp, 0); > > return(0); > @@ -1146,7 +1156,7 @@ xfs_dm_direct_ok( > > STATIC int > xfs_dm_rdwr( > - bhv_vnode_t *vp, > + struct inode *inode, > uint fflag, > mode_t fmode, > dm_off_t off, > @@ -1154,13 +1164,12 @@ xfs_dm_rdwr( > void __user *bufp, > int *rvp) > { > + xfs_inode_t *ip = XFS_I(inode); > int error; > int oflags; > ssize_t xfer; > struct file *file; > - struct inode *inode = vn_to_inode(vp); > struct dentry *dentry; > - xfs_inode_t *ip; > > if ((off < 0) || (off > i_size_read(inode)) || !S_ISREG(inode->i_mode)) > return EINVAL; > @@ -1178,7 +1187,6 @@ xfs_dm_rdwr( > */ > > oflags |= O_LARGEFILE | O_NONBLOCK | O_NOATIME; > - ip = xfs_vtoi(vp); > if (xfs_dm_direct_ok(ip, off, len, bufp)) > oflags |= O_DIRECT; > > @@ -1255,9 +1263,8 @@ xfs_dm_downgrade_right( > { > #ifdef DEBUG_RIGHTS > char buffer[sizeof(dm_handle_t) * 2 + 1]; > - bhv_vnode_t *vp = vn_from_inode(inode); > > - if (!xfs_vp_to_hexhandle(vp, type, buffer)) { > + if (!xfs_vp_to_hexhandle(inode, type, buffer)) { > printf("dm_downgrade_right: old %d new %d type %d handle %s\n", > right, DM_RIGHT_SHARED, type, buffer); > } else { > @@ -1288,13 +1295,12 @@ xfs_dm_get_allocinfo_rvp( > u_int __user *nelemp, > int *rvp) > { > - xfs_inode_t *ip; /* xfs incore inode pointer */ > + xfs_inode_t *ip = XFS_I(inode); > xfs_mount_t *mp; /* file system mount point */ > xfs_fileoff_t fsb_offset; > xfs_filblks_t fsb_length; > dm_off_t startoff; > int elem; > - bhv_vnode_t *vp = vn_from_inode(inode); > xfs_bmbt_irec_t *bmp = NULL; > u_int bmpcnt = 50; > u_int bmpsz = sizeof(xfs_bmbt_irec_t) * bmpcnt; > @@ -1311,7 +1317,6 @@ xfs_dm_get_allocinfo_rvp( > if (copy_from_user( &startoff, offp, sizeof(startoff))) > return(-EFAULT); > > - ip = xfs_vtoi(vp); > mp = ip->i_mount; > ASSERT(mp); > > @@ -1819,15 +1824,13 @@ xfs_dm_get_dioinfo( > { > dm_dioinfo_t dio; > xfs_mount_t *mp; > - xfs_inode_t *ip; > - bhv_vnode_t *vp = vn_from_inode(inode); > + xfs_inode_t *ip = XFS_I(inode); > > /* Returns negative errors to DMAPI */ > > if (right < DM_RIGHT_SHARED) > return(-EACCES); > > - ip = xfs_vtoi(vp); > mp = ip->i_mount; > > dio.d_miniosz = dio.d_mem = MIN_DIO_SIZE(mp); > @@ -2079,8 +2082,7 @@ xfs_dm_get_eventlist( > u_int *nelemp) > { > int error; > - bhv_vnode_t *vp = vn_from_inode(inode); > - xfs_inode_t *ip = xfs_vtoi(vp); > + xfs_inode_t *ip = XFS_I(inode); > > /* Returns negative errors to DMAPI */ > > @@ -2104,9 +2106,8 @@ xfs_dm_get_fileattr( > dm_stat_t __user *statp) > { > dm_stat_t stat; > - xfs_inode_t *ip; > + xfs_inode_t *ip = XFS_I(inode); > xfs_mount_t *mp; > - bhv_vnode_t *vp = vn_from_inode(inode); > > /* Returns negative errors to DMAPI */ > > @@ -2115,7 +2116,6 @@ xfs_dm_get_fileattr( > > /* Find the mount point. */ > > - ip = xfs_vtoi(vp); > mp = ip->i_mount; > > xfs_ilock(ip, XFS_ILOCK_SHARED); > @@ -2144,16 +2144,14 @@ xfs_dm_get_region( > { > dm_eventset_t evmask; > dm_region_t region; > - xfs_inode_t *ip; > + xfs_inode_t *ip = XFS_I(inode); > u_int elem; > - bhv_vnode_t *vp = vn_from_inode(inode); > > /* Returns negative errors to DMAPI */ > > if (right < DM_RIGHT_SHARED) > return(-EACCES); > > - ip = xfs_vtoi(vp); > evmask = ip->i_d.di_dmevmask; /* read the mask "atomically" */ > > /* Get the file's current managed region flags out of the > @@ -2340,9 +2338,9 @@ xfs_dm_getall_inherit( > > /* Initialize location pointer for subsequent dm_get_dirattrs, > dm_get_bulkattr, and dm_get_bulkall calls. The same initialization must > - work for vnode-based routines (dm_get_dirattrs) and filesystem-based > + work for inode-based routines (dm_get_dirattrs) and filesystem-based > routines (dm_get_bulkattr and dm_get_bulkall). Filesystem-based functions > - call this routine using the filesystem's root vnode. > + call this routine using the filesystem's root inode. > */ > > /* ARGSUSED */ > @@ -2444,12 +2442,11 @@ xfs_dm_probe_hole( > { > dm_off_t roff; > dm_size_t rlen; > - xfs_inode_t *ip; > + xfs_inode_t *ip = XFS_I(inode); > xfs_mount_t *mp; > uint lock_flags; > xfs_fsize_t realsize; > dm_size_t align; > - bhv_vnode_t *vp = vn_from_inode(inode); > int error; > > /* Returns negative errors to DMAPI */ > @@ -2457,7 +2454,6 @@ xfs_dm_probe_hole( > if (right < DM_RIGHT_SHARED) > return -EACCES; > > - ip = xfs_vtoi(vp); > if ((ip->i_d.di_mode & S_IFMT) != S_IFREG) > return -EINVAL; > > @@ -2497,11 +2493,10 @@ xfs_dm_punch_hole( > { > xfs_flock64_t bf; > int error = 0; > - xfs_inode_t *ip; > + xfs_inode_t *ip = XFS_I(inode); > xfs_mount_t *mp; > dm_size_t align; > xfs_fsize_t realsize; > - bhv_vnode_t *vp = vn_from_inode(inode); > dm_off_t roff; > dm_size_t rlen; > > @@ -2519,7 +2514,6 @@ xfs_dm_punch_hole( > if (error) > return -EBUSY; > > - ip = xfs_vtoi(vp); > mp = ip->i_mount; > > down_rw_sems(inode, DM_SEM_FLAG_WR); > @@ -2617,14 +2611,12 @@ xfs_dm_read_invis_rvp( > void __user *bufp, > int *rvp) > { > - bhv_vnode_t *vp = vn_from_inode(inode); > - > /* Returns negative errors to DMAPI */ > > if (right < DM_RIGHT_SHARED) > return(-EACCES); > > - return(-xfs_dm_rdwr(vp, 0, FMODE_READ, off, len, bufp, rvp)); > + return(-xfs_dm_rdwr(inode, 0, FMODE_READ, off, len, bufp, rvp)); > } > > > @@ -2637,9 +2629,8 @@ xfs_dm_release_right( > { > #ifdef DEBUG_RIGHTS > char buffer[sizeof(dm_handle_t) * 2 + 1]; > - bhv_vnode_t *vp = vn_from_inode(inode); > > - if (!xfs_vp_to_hexhandle(vp, type, buffer)) { > + if (!xfs_vp_to_hexhandle(inode, type, buffer)) { > printf("dm_release_right: old %d type %d handle %s\n", > right, type, buffer); > } else { > @@ -2692,9 +2683,8 @@ xfs_dm_request_right( > { > #ifdef DEBUG_RIGHTS > char buffer[sizeof(dm_handle_t) * 2 + 1]; > - bhv_vnode_t *vp = vn_from_inode(inode); > > - if (!xfs_vp_to_hexhandle(vp, type, buffer)) { > + if (!xfs_vp_to_hexhandle(inode, type, buffer)) { > printf("dm_request_right: old %d new %d type %d flags 0x%x " > "handle %s\n", right, newright, type, flags, buffer); > } else { > @@ -2759,15 +2749,14 @@ xfs_dm_set_eventlist( > u_int maxevent) > { > int error; > - bhv_vnode_t *vp = vn_from_inode(inode); > - xfs_inode_t *ip = xfs_vtoi(vp); > + xfs_inode_t *ip = XFS_I(inode); > > /* Returns negative errors to DMAPI */ > > if (type == DM_FSYS_OBJ) { > error = xfs_dm_fs_set_eventlist(ip->i_mount, right, eventsetp, maxevent); > } else { > - error = xfs_dm_f_set_eventlist(vp, ip, right, eventsetp, maxevent); > + error = xfs_dm_f_set_eventlist(ip, right, eventsetp, maxevent); > } > return(-error); /* Return negative error to DMAPI */ > } > @@ -2787,7 +2776,6 @@ xfs_dm_set_fileattr( > dm_fileattr_t stat; > bhv_vattr_t vat; > int error; > - bhv_vnode_t *vp = vn_from_inode(inode); > > /* Returns negative errors to DMAPI */ > > @@ -2844,7 +2832,7 @@ xfs_dm_set_fileattr( > > error = xfs_setattr(XFS_I(inode), &vat, ATTR_DMI, NULL); > if (!error) > - vn_revalidate(vp); /* update Linux inode flags */ > + vn_revalidate(vn_from_inode(inode)); /* update Linux inode flags */ > return(-error); /* Return negative error to DMAPI */ > } > > @@ -2869,7 +2857,7 @@ xfs_dm_set_region( > dm_region_t __user *regbufp, > dm_boolean_t __user *exactflagp) > { > - xfs_inode_t *ip; > + xfs_inode_t *ip = XFS_I(inode); > xfs_trans_t *tp; > xfs_mount_t *mp; > dm_region_t region; > @@ -2877,7 +2865,6 @@ xfs_dm_set_region( > dm_eventset_t mr_mask; > int error; > u_int exactflag; > - bhv_vnode_t *vp = vn_from_inode(inode); > > /* Returns negative errors to DMAPI */ > > @@ -2917,9 +2904,7 @@ xfs_dm_set_region( > bits, add in the new ones, and update the file's mask. > */ > > - ip = xfs_vtoi(vp); > - > - if (new_mask & prohibited_mr_events(vp)) { > + if (new_mask & prohibited_mr_events(inode->i_mapping)) { > /* If the change is simply to remove the READ > * bit, then that's always okay. Otherwise, it's busy. > */ > @@ -2943,7 +2928,7 @@ xfs_dm_set_region( > ip->i_d.di_dmevmask = (ip->i_d.di_dmevmask & ~mr_mask) | new_mask; > > xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); > - VN_HOLD(vp); > + igrab(inode); > xfs_trans_commit(tp, 0); > > /* Return the proper value for *exactflagp depending upon whether or not > @@ -3020,9 +3005,8 @@ xfs_dm_upgrade_right( > { > #ifdef DEBUG_RIGHTS > char buffer[sizeof(dm_handle_t) * 2 + 1]; > - bhv_vnode_t *vp = vn_from_inode(inode); > > - if (!xfs_vp_to_hexhandle(vp, type, buffer)) { > + if (!xfs_vp_to_hexhandle(inode, type, buffer)) { > printf("dm_upgrade_right: old %d new %d type %d handle %s\n", > right, DM_RIGHT_EXCL, type, buffer); > } else { > @@ -3045,7 +3029,6 @@ xfs_dm_write_invis_rvp( > int *rvp) > { > int fflag = 0; > - bhv_vnode_t *vp = vn_from_inode(inode); > > /* Returns negative errors to DMAPI */ > > @@ -3054,7 +3037,7 @@ xfs_dm_write_invis_rvp( > > if (flags & DM_WRITE_SYNC) > fflag |= O_SYNC; > - return(-xfs_dm_rdwr(vp, fflag, FMODE_WRITE, off, len, bufp, rvp)); > + return(-xfs_dm_rdwr(inode, fflag, FMODE_WRITE, off, len, bufp, rvp)); > } > > > > From owner-xfs@oss.sgi.com Mon Sep 24 20:52:59 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Sep 2007 20:53:02 -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,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 l8P3qtQ3012401 for ; Mon, 24 Sep 2007 20:52:57 -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 NAA11756; Tue, 25 Sep 2007 13:52:54 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1161) id 80AE758C4C0A; Tue, 25 Sep 2007 13:52:54 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 970978 - Fix a couple mkfs.xfs issues Message-Id: <20070925035254.80AE758C4C0A@chook.melbourne.sgi.com> Date: Tue, 25 Sep 2007 13:52:54 +1000 (EST) From: bnaujok@sgi.com (Barry Naujok) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13083 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 wiping old AG headers and purge whack buffers Date: Tue Sep 25 13:52:20 AEST 2007 Workarea: chook.melbourne.sgi.com:/home/bnaujok/isms/xfs-cmds Inspected by: sandeen@sandeen.net The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:29767a xfsprogs/mkfs/xfs_mkfs.c - 1.82 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/mkfs/xfs_mkfs.c.diff?r1=text&tr1=1.82&r2=text&tr2=1.81&f=h - Fix wiping old AG headers and purge whack buffers From owner-xfs@oss.sgi.com Mon Sep 24 21:39:48 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Sep 2007 21: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=-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 l8P4dhQ3019615 for ; Mon, 24 Sep 2007 21:39:47 -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 OAA12802; Tue, 25 Sep 2007 14:39:42 +1000 Message-ID: <46F89177.6040303@sgi.com> Date: Tue, 25 Sep 2007 14:41:27 +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: xfs-oss Subject: TAKE 970979: [PATCH] cleanup vnode useage in xfs_dm.c Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13084 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 cleanup vnode useage in xfs_dm.c Signed-off-by: Christoph Hellwig Date: Tue Sep 25 14:36:51 AEST 2007 Workarea: soarer.melbourne.sgi.com:/home/vapo/isms/linux-xfs-patch-reviews Inspected by: 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:29769a fs/xfs/dmapi/xfs_dm.c - 1.56 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/xfs_dm.c.diff?r1=text&tr1=1.56&r2=text&tr2=1.55&f=h - pv 970979, author hch@lst.de, rv vapo - cleanup vnode useage in xfs_dm.c From owner-xfs@oss.sgi.com Mon Sep 24 21:41:19 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Sep 2007 21:41: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.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43, SPF_HELO_PASS 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 l8P4fDQ3019986 for ; Mon, 24 Sep 2007 21:41:18 -0700 Received: from liberator.sandeen.net (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 33E4818011E9B; Mon, 24 Sep 2007 23:41:17 -0500 (CDT) Message-ID: <46F8916D.7000900@sandeen.net> Date: Mon, 24 Sep 2007 23:41:17 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Barry Naujok CC: David Chinner , xfs-oss Subject: Re: something very strange w/ filestreams... References: <46F49C80.60007@sandeen.net> <20070923092444.GQ995458@sgi.com> <46F7B04D.70809@sandeen.net> <46F8654B.9010203@sandeen.net> In-Reply-To: <46F8654B.9010203@sandeen.net> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13085 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: > Barry Naujok wrote: > >>>> So, before running this test, you should make sure your test >>>> partitions are completely zeroed from mkfs's that occurred >>>> before that recent version of mkfs.xfs was installed. >>> I dd'd over the whole test partition, ran the sequence, and hit the >>> problem. >> Yeah, worked it out yesterday but never got around to doing another >> email. It's a combination of the two filestreams tests which do >> small filesystems and mkfs.xfs doesn't wipe beyond the new >> filesystem size. Zero the disk, try the attached patch and see >> if that fixes the problem. >> >> Barry. > > Ok, but what about that double free? > > -Eric > > I have a bit of a clue about what's going wrong. first we get the buffer zone allocated: new zone 0x80efd68 for "xfs_buffer", size=116 set a watchpoint on that, also break on setup_bmap: (gdb) watch *((int *)0x80efd68) Hardware watchpoint 1: *(int *) 135200104 (gdb) break setup_bmap (gdb) cont ba_bmap gets allocated, based on some particular sb_agblocks count at the time: setup_bmap(agcount, mp->m_sb.sb_agblocks, mp->m_sb.sb_rextents); on this filesystem it's 4096 at this point, like so: Breakpoint 3, setup_bmap (agno=64, numblocks=4096, rtblocks=0) at incore.c:59 and from some debugging the size of ba_bmap[i] ends up as 2048: ... ba_bmap[31] at 0x80edc58 size 2048 ba_bmap[32] at 0x80ee460 size 2048 ba_bmap[33] at 0x80eec68 size 2048 ... so I set a watch on the zone that ends up corrupted, and: Hardware watchpoint 4: *(int *) 135200104 Old value = 116 New value = 372 0x08063a2f in set_agbno_state (mp=0xbf999188, agno=32, ag_blockno=12818, state=1) at incore.c:278 278 *addr = (((*addr) & (gdb) bt #0 0x08063a2f in set_agbno_state (mp=0xbf999188, agno=32, ag_blockno=12818, state=1) at incore.c:278 #1 0x0807d752 in scanfunc_bno (ablock=0x8187200, level=0, bno=1, agno=32, suspect=0, isroot=1) at scan.c:548 #2 0x0807c017 in scan_sbtree (root=1, nlevels=1, agno=32, suspect=0, func=0x807d430 , isroot=1) at scan.c:66 #3 0x0807d19a in scan_ag (agno=32) at ../include/xfs/swab.h:126 #4 0x0806751b in phase2 (mp=0xbf999188) at phase2.c:148 #5 0x08080d77 in main (argc=Cannot access memory at address 0x8 ) at xfs_repair.c:619 so at this point it looks like we're trying to use an ag_blockno of 12818, when we only allocated based on expecting 4096 blocks per ag? So I guess we've stumbled across another piece of the older, larger filesystem and those values cause us to walk off the end of the ba_map array? Not sure where it goes from here, but bedtime for me. :) -Eric From owner-xfs@oss.sgi.com Mon Sep 24 22:53:22 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Sep 2007 22:53:26 -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 l8P5rFQ3029973 for ; Mon, 24 Sep 2007 22:53:21 -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 PAA14293; Tue, 25 Sep 2007 15:53:11 +1000 Message-ID: <46F8A247.4070607@sgi.com> Date: Tue, 25 Sep 2007 15:53:11 +1000 From: Donald Douwsma User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH] xfsidbg: kill vnode leftovers References: <20070924180732.GA17635@lst.de> In-Reply-To: <20070924180732.GA17635@lst.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13086 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 Christoph Hellwig wrote: > While we're at fixing up xfsidbg I have this little gem: > > Kill the kdbm_vn, kdbm_vnode and xi2vnode xfsidbg commands. > > The last one just printed a Linux inode (despite it's description) > and that is much better done by the inode command in > kdb/modules/kdbm_pg.c. The latter two both print the vnode (nothing > left here) and the inode and again that is better done using the > inode command. Interestingly those latter two did exactly the > same despite their quite different descriptions which weren't > correct for either command. > Thanks Christoph, its good to remove the cruft. 78 commands in there at the moment. Any we can get rid of make it easier to use. Don From owner-xfs@oss.sgi.com Tue Sep 25 01:00:17 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Sep 2007 01:00: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.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 l8P80BQ3030158 for ; Tue, 25 Sep 2007 01:00:15 -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 SAA17017; Tue, 25 Sep 2007 18:00:07 +1000 From: donaldd@sgi.com Received: by linuxbuild.melbourne.sgi.com (Postfix, from userid 16365) id 0F5182F9ED8B; Tue, 25 Sep 2007 18:00:07 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 970982 - Misc xfsidbg updates. Message-Id: <20070925080007.0F5182F9ED8B@linuxbuild.melbourne.sgi.com> Date: Tue, 25 Sep 2007 18:00:07 +1000 (EST) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13087 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 Fix compile warnings for xfsidbg.c as seen on x86_64. Date: Tue Sep 25 17:58:39 AEST 2007 Workarea: linuxbuild.melbourne.sgi.com:/home/donaldd/isms/2.6.x-xfs Inspected by: hch@infradead.org The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29773a fs/xfs/xfsidbg.c - 1.335 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfsidbg.c.diff?r1=text&tr1=1.335&r2=text&tr2=1.334&f=h - Fix compile warnings for xfsidbg.c as seen on x86_64. From owner-xfs@oss.sgi.com Tue Sep 25 01:03:18 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Sep 2007 01:03: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=-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 l8P83FQ3030905 for ; Tue, 25 Sep 2007 01:03:17 -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 SAA17155; Tue, 25 Sep 2007 18:03:14 +1000 From: donaldd@sgi.com Received: by linuxbuild.melbourne.sgi.com (Postfix, from userid 16365) id B13392FAC152; Tue, 25 Sep 2007 18:03:14 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 970982 - Misc xfsidbg updates. Message-Id: <20070925080314.B13392FAC152@linuxbuild.melbourne.sgi.com> Date: Tue, 25 Sep 2007 18:03:14 +1000 (EST) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13088 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 The xfs mount flags have recently undergone some changes. Update the xfsidbg xmount command to print them correctly. Date: Tue Sep 25 18:02:31 AEST 2007 Workarea: linuxbuild.melbourne.sgi.com:/home/donaldd/isms/2.6.x-xfs Inspected by: hch@infradead.org The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29774a fs/xfs/xfsidbg.c - 1.336 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfsidbg.c.diff?r1=text&tr1=1.336&r2=text&tr2=1.335&f=h - Update xfsidbg mount flag processing. From owner-xfs@oss.sgi.com Tue Sep 25 01:05:10 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Sep 2007 01:05: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.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 l8P855Q3031592 for ; Tue, 25 Sep 2007 01:05:09 -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 SAA17234; Tue, 25 Sep 2007 18:05:04 +1000 From: donaldd@sgi.com Received: by linuxbuild.melbourne.sgi.com (Postfix, from userid 16365) id 8714B2FC092A; Tue, 25 Sep 2007 18:05:04 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 970982 - Misc xfsidbg updates. Message-Id: <20070925080504.8714B2FC092A@linuxbuild.melbourne.sgi.com> Date: Tue, 25 Sep 2007 18:05:04 +1000 (EST) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13089 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 the kdbm_vn, kdbm_vnode and xi2vnode xfsidbg commands. The last one just printed a Linux inode (despite it's description) and that is much better done by the inode command in kdb/modules/kdbm_pg.c. The latter two both print the vnode (nothing left here) and the inode and again that is better done using the inode command. Interestingly those latter two did exactly the same despite their quite different descriptions which weren't correct for either command. Signed-off-by: Christoph Hellwig Date: Tue Sep 25 18:04:33 AEST 2007 Workarea: linuxbuild.melbourne.sgi.com:/home/donaldd/isms/2.6.x-xfs Inspected by: donaldd The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29775a fs/xfs/xfsidbg.c - 1.337 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfsidbg.c.diff?r1=text&tr1=1.337&r2=text&tr2=1.336&f=h - Kill the kdbm_vn, kdbm_vnode and xi2vnode xfsidbg commands. From owner-xfs@oss.sgi.com Tue Sep 25 01:56:59 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Sep 2007 01:57:03 -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 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 l8P8uuQ3006842 for ; Tue, 25 Sep 2007 01:56:59 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1Ia5mq-0002df-Ts; Tue, 25 Sep 2007 09:28:56 +0100 Date: Tue, 25 Sep 2007 09:28:56 +0100 From: Christoph Hellwig To: Eric Sandeen Cc: Chris Wedgwood , xfs-oss Subject: Re: [PATCH] lose xfs_hex_dump in favor of print_hex_dump Message-ID: <20070925082856.GA9786@infradead.org> References: <46F85240.1060206@sandeen.net> <20070925003232.GA26663@puku.stupidest.org> <46F86501.7070605@sandeen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46F86501.7070605@sandeen.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-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13090 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 24, 2007 at 08:31:45PM -0500, Eric Sandeen wrote: > >> +void > >> +xfs_hex_dump(void *p, int length) > >> +{ > >> + print_hex_dump(KERN_ALERT, "", DUMP_PREFIX_OFFSET, 16, 1, p, length, 1); > >> +} > > > > Is this symbol exported/needed? If not then why not make it a #define > > or an inline in the header where you have the prototype? > > Yeah, I suppose that might be better.... I just followed the lead of > xfs_cmn_err etc. > > The only reason I left a wrapper was for cattelan's BSD exploits > (er, adventures) ;-) I could imagine it getting called from other places, > but for now it only has one caller, xfs_corruption_error (so really, even > the length argument is never anything other than 16...) No point in making anything in an absolute slowpath inline or a macro. I think the patch is fine as-is. From owner-xfs@oss.sgi.com Tue Sep 25 05:35:20 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Sep 2007 05:35: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.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from stlx01.stz-softwaretechnik.com (stz-softwaretechnik.de [217.160.223.211]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8PCZIQ3012241 for ; Tue, 25 Sep 2007 05:35:20 -0700 Received: from rg by stlx01.stz-softwaretechnik.com with local (Exim 3.36 #1 (Debian)) id 1Ia9d9-0001gb-00 for ; Tue, 25 Sep 2007 14:35:11 +0200 Date: Tue, 25 Sep 2007 14:35:01 +0200 From: Ralf Gross To: linux-xfs@oss.sgi.com Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) Message-ID: <20070925123501.GA20499@p15145560.pureserver.info> References: <20070923093841.GH19983@p15145560.pureserver.info> <20070924173155.GI19983@p15145560.pureserver.info> <20070924203958.GA4082@p15145560.pureserver.info> <20070924213358.GB4082@p15145560.pureserver.info> <20070924215223.GC4082@p15145560.pureserver.info> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20070924215223.GC4082@p15145560.pureserver.info> User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13091 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Ralf-Lists@ralfgross.de Precedence: bulk X-list: xfs Ralf Gross schrieb: > > What do you get when (reading) from the raw device? > > > > dd if=/dev/sda bs=1M count=10240 > > The server has 16 GB RAM, so I tried it with 20 GB of data. > > dd if=/dev/sdd of=/dev/null bs=1M count=20480 > 20480+0 Datensδtze ein > 20480+0 Datensδtze aus > 21474836480 Bytes (21 GB) kopiert, 95,3738 Sekunden, 225 MB/s > > and a second try: > > dd if=/dev/sdd of=/dev/null bs=1M count=20480 > 20480+0 Datensδtze ein > 20480+0 Datensδtze aus > 21474836480 Bytes (21 GB) kopiert, 123,78 Sekunden, 173 MB/s > > I'm taoo tired to interprete these numbers at the moment, I'll do some > more testing tomorrow. There is a second RAID device attached to the server (24x RAID5). The numbers I get from this device are a bit worse than the 16x RAID 5 numbers (150MB/s read with dd). I'm really wondering how people can achieve transfer rates of 400MB/s and more. I know that I'm limited by the FC controller, but I don't even get >200MB/s. Ralf From owner-xfs@oss.sgi.com Tue Sep 25 05:50:15 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Sep 2007 05:50: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=-0.0 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 l8PCoDQ3015336 for ; Tue, 25 Sep 2007 05:50:15 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id D4F831C000267; Tue, 25 Sep 2007 08:50:15 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id C170E4019B78; Tue, 25 Sep 2007 08:50:15 -0400 (EDT) Date: Tue, 25 Sep 2007 08:50:15 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Ralf Gross cc: linux-xfs@oss.sgi.com Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) In-Reply-To: <20070925123501.GA20499@p15145560.pureserver.info> Message-ID: References: <20070923093841.GH19983@p15145560.pureserver.info> <20070924173155.GI19983@p15145560.pureserver.info> <20070924203958.GA4082@p15145560.pureserver.info> <20070924213358.GB4082@p15145560.pureserver.info> <20070924215223.GC4082@p15145560.pureserver.info> <20070925123501.GA20499@p15145560.pureserver.info> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463747160-6325792-1190724615=:11391" X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13092 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 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463747160-6325792-1190724615=:11391 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 25 Sep 2007, Ralf Gross wrote: > Ralf Gross schrieb: >>> What do you get when (reading) from the raw device? >>> >>> dd if=3D/dev/sda bs=3D1M count=3D10240 >> >> The server has 16 GB RAM, so I tried it with 20 GB of data. >> >> dd if=3D/dev/sdd of=3D/dev/null bs=3D1M count=3D20480 >> 20480+0 Datens=E4tze ein >> 20480+0 Datens=E4tze aus >> 21474836480 Bytes (21 GB) kopiert, 95,3738 Sekunden, 225 MB/s >> >> and a second try: >> >> dd if=3D/dev/sdd of=3D/dev/null bs=3D1M count=3D20480 >> 20480+0 Datens=E4tze ein >> 20480+0 Datens=E4tze aus >> 21474836480 Bytes (21 GB) kopiert, 123,78 Sekunden, 173 MB/s >> >> I'm taoo tired to interprete these numbers at the moment, I'll do some >> more testing tomorrow. > > There is a second RAID device attached to the server (24x RAID5). The > numbers I get from this device are a bit worse than the 16x RAID 5 > numbers (150MB/s read with dd). > > I'm really wondering how people can achieve transfer rates of > 400MB/s and more. I know that I'm limited by the FC controller, but > I don't even get >200MB/s. > > Ralf > > Perhaps something is wrong with your setup? Here are my 10 raptors in RAID5 using Software RAID (no hw raid=20 controller): p34:~# dd if=3D/dev/md3 of=3D/dev/null bs=3D1M count=3D16384 16384+0 records in 16384+0 records out 17179869184 bytes (17 GB) copied, 29.8193 seconds, 576 MB/s p34:~# ---1463747160-6325792-1190724615=:11391-- From owner-xfs@oss.sgi.com Tue Sep 25 06:09:49 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Sep 2007 06:09: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=BAYES_40 autolearn=ham version=3.2.0-pre1-r499012 Received: from cernmxlb.cern.ch (cernmx07.cern.ch [137.138.166.171]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8PD9iQ3019024 for ; Tue, 25 Sep 2007 06:09:48 -0700 DomainKey-Status: no signature - Generated by CERN IT/IS DomainKeys v1.0 Keywords: CERN SpamKiller Note: -51 Charset: west-latin X-Filter: CERNMX07 CERN MX v2.0 060921.0942 Release Received: from luba ([128.141.57.230]) by cernmxlb.cern.ch with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 14:57:36 +0200 Received: by luba (Postfix, from userid 32266) id D317012A562; Tue, 25 Sep 2007 14:57:33 +0200 (CEST) Date: Tue, 25 Sep 2007 14:57:33 +0200 From: KELEMEN Peter To: linux-xfs@oss.sgi.com Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) Message-ID: <20070925125733.GA20873@luba.cern.ch> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20070923093841.GH19983@p15145560.pureserver.info> <20070924173155.GI19983@p15145560.pureserver.info> <20070924203958.GA4082@p15145560.pureserver.info> <20070924213358.GB4082@p15145560.pureserver.info> <20070924215223.GC4082@p15145560.pureserver.info> <20070925123501.GA20499@p15145560.pureserver.info> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20070925123501.GA20499@p15145560.pureserver.info> Organization: CERN European Laboratory for Particle Physics, Switzerland X-GPG-KeyID: 1024D/9FF0CABE 2004-04-03 X-GPG-Fingerprint: 6C9E 5917 3B06 E4EE 6356 7BF0 8F3E CAB6 9FF0 CABE X-Comment: Personal opinion. Paragraphs might have been reformatted. X-Copyright: Forwarding or publishing without permission is prohibited. X-Accept-Language: hu,en User-Agent: Mutt/1.5.13 (2006-08-11) X-OriginalArrivalTime: 25 Sep 2007 12:57:36.0967 (UTC) FILETIME=[A5B36D70:01C7FF73] X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13093 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Peter.Kelemen@cern.ch Precedence: bulk X-list: xfs * Ralf Gross (ralf-lists@ralfgross.de) [20070925 14:35]: > There is a second RAID device attached to the server (24x > RAID5). The numbers I get from this device are a bit worse than > the 16x RAID 5 numbers (150MB/s read with dd). You are expecting 24 spindles to align up when you have a write request, which has to be 23*chunksize bytes in order to avoid RMW. Additionally, your array is so big that you're very likely to hit another error while rebuilding. Chop up your monster RAID5 array into smaller arrays and stripe across them. Even better, consider RAID10. Peter -- .+'''+. .+'''+. .+'''+. .+'''+. .+'' Kelemen PΓ©ter / \ / \ Peter.Kelemen@cern.ch .+' `+...+' `+...+' `+...+' `+...+' From owner-xfs@oss.sgi.com Tue Sep 25 06:50:17 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Sep 2007 06:50: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.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from stlx01.stz-softwaretechnik.com (stz-softwaretechnik.de [217.160.223.211]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8PDoCQ3027487 for ; Tue, 25 Sep 2007 06:50:16 -0700 Received: from rg by stlx01.stz-softwaretechnik.com with local (Exim 3.36 #1 (Debian)) id 1IaAne-0005AF-00 for ; Tue, 25 Sep 2007 15:50:06 +0200 Date: Tue, 25 Sep 2007 15:49:56 +0200 From: Ralf Gross To: linux-xfs@oss.sgi.com Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) Message-ID: <20070925134955.GB20499@p15145560.pureserver.info> References: <20070923093841.GH19983@p15145560.pureserver.info> <20070924173155.GI19983@p15145560.pureserver.info> <20070924203958.GA4082@p15145560.pureserver.info> <20070924213358.GB4082@p15145560.pureserver.info> <20070924215223.GC4082@p15145560.pureserver.info> <20070925123501.GA20499@p15145560.pureserver.info> <20070925125733.GA20873@luba.cern.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070925125733.GA20873@luba.cern.ch> User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13094 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Ralf-Lists@ralfgross.de Precedence: bulk X-list: xfs KELEMEN Peter schrieb: > * Ralf Gross (ralf-lists@ralfgross.de) [20070925 14:35]: > > > There is a second RAID device attached to the server (24x > > RAID5). The numbers I get from this device are a bit worse than > > the 16x RAID 5 numbers (150MB/s read with dd). > > You are expecting 24 spindles to align up when you have a write > request, which has to be 23*chunksize bytes in order to avoid RMW. > Additionally, your array is so big that you're very likely to hit > another error while rebuilding. Chop up your monster RAID5 array > into smaller arrays and stripe across them. Even better, consider > RAID10. RAID10 is no option, we need 60+ TB at the moment, mostly large video files. Basically the read/write performance we get with the 16x RAID 5 is sufficient for our needs. The 24x RAID 5 is only a test device. The volumes that will be used in the future are the 16/15x RAIDs (48 disk shelf with 3 volumes). I'm just wondering how people get 400+ MB/s with HW-RAID 5. Ralf From owner-xfs@oss.sgi.com Tue Sep 25 07:09:03 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Sep 2007 07:09: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=3.7 required=5.0 tests=AWL,BAYES_50, FROM_EXCESS_BASE64 autolearn=no version=3.2.0-pre1-r499012 Received: from smtp102-mob.biz.mail.re2.yahoo.com (smtp102-mob.biz.mail.re2.yahoo.com [206.190.36.117]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l8PE90Q3030756 for ; Tue, 25 Sep 2007 07:09:03 -0700 Received: (qmail 9323 invoked from network); 25 Sep 2007 14:09:03 -0000 Received: from unknown (HELO bda202-cell02.bisx.prod.on.blackberry) (thebs413@216.9.248.122 with xymcookie) by smtp102-mob.biz.mail.re2.yahoo.com with SMTP; 25 Sep 2007 14:09:03 -0000 X-YMail-OSG: PVerU1wVM1mLryhoSjOfPsdQ.mwr2MPUwvSNGaFe3FUjV7UNeOgifyj._LN9R_q1FkF.wbhFiF9SsJUOlBhcYW9tsBvrte6qImP3mQRoJrlcGDn8Z_VHbgbvFry3fXZc19LRXyRZ_WiWzBQ- X-rim-org-msg-ref-id: 2119512110 Message-ID: <2119512110-1190729335-cardhu_decombobulator_blackberry.rim.net-718597053-@bxe108.bisx.prod.on.blackberry> Reply-To: b.j.smith@ieee.org X-Priority: Normal References: <20070923093841.GH19983@p15145560.pureserver.info> <20070924173155.GI19983@p15145560.pureserver.info> <20070924203958.GA4082@p15145560.pureserver.info> <20070924213358.GB4082@p15145560.pureserver.info> <20070924215223.GC4082@p15145560.pureserver.info> <20070925123501.GA20499@p15145560.pureserver.info> <20070925125733.GA20873@luba.cern.ch><20070925134955.GB20499@p15145560.pureserver.info> In-Reply-To: <20070925134955.GB20499@p15145560.pureserver.info> Sensitivity: Normal Importance: Normal To: "Ralf Gross" , linux-xfs@oss.sgi.com Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) From: "=?utf-8?B?QnJ5YW4gSiBTbWl0aA==?=" Date: Tue, 25 Sep 2007 14:08:52 +0000 Content-Type: text/plain MIME-Version: 1.0 X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id l8PE93Q3030760 X-archive-position: 13095 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: b.j.smith@ieee.org Precedence: bulk X-list: xfs Use multiple cards on multiple PCI-X/PCIe channels, each with their own RAID-5 (or 6) volume, and then stripe (OS LVM) RAID-0 across the volumes. Depending on your network service and application, you can use either hardware or software for the RAID-5 (or 6). If it's heavily read-only servicing, then software RAID works great, because it's essentially RAID-0 (minus 1 disc). But always use the OS RAID (e.g., LVM stripe) to stripe RAID-0 across all volumes, assuming there is not an OS volume limit (of course ;). Software RAID is extemely fast at XORs, that's not the problem. The problem is how the data stream through the PC's inefficient I/O interconnect. PC's have gotten much better, but the load still detracts from other I/O, that services may contend with. Software RAID-5 writes are, essentially, "programmed I/O." Every single commit has to have it's parity blocked programmed by the CPU, which is difficult to bechmark because the bottleneck is not the CPU, but the LOAD-XOR-STOR of the interconnect. An IOP is designed with ASIC peripherals to do that in-line, real-time. In fact, by the very nature of the IOP driver, the operation is synchronous to the OS' standpoint, unlike software RAID optimizations by the OS. -- Bryan J Smith - mailto:b.j.smith@ieee.org http://thebs413.blogspot.com Sent via BlackBerry from T-Mobile -----Original Message----- From: Ralf Gross Date: Tue, 25 Sep 2007 15:49:56 To:linux-xfs@oss.sgi.com Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) KELEMEN Peter schrieb: > * Ralf Gross (ralf-lists@ralfgross.de) [20070925 14:35]: > > > There is a second RAID device attached to the server (24x > > RAID5). The numbers I get from this device are a bit worse than > > the 16x RAID 5 numbers (150MB/s read with dd). > > You are expecting 24 spindles to align up when you have a write > request, which has to be 23*chunksize bytes in order to avoid RMW. > Additionally, your array is so big that you're very likely to hit > another error while rebuilding. Chop up your monster RAID5 array > into smaller arrays and stripe across them. Even better, consider > RAID10. RAID10 is no option, we need 60+ TB at the moment, mostly large video files. Basically the read/write performance we get with the 16x RAID 5 is sufficient for our needs. The 24x RAID 5 is only a test device. The volumes that will be used in the future are the 16/15x RAIDs (48 disk shelf with 3 volumes). I'm just wondering how people get 400+ MB/s with HW-RAID 5. Ralf From owner-xfs@oss.sgi.com Tue Sep 25 07:10:51 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Sep 2007 07:10:55 -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_50, FROM_EXCESS_BASE64,J_CHICKENPOX_24 autolearn=no version=3.2.0-pre1-r499012 Received: from smtp101-mob.biz.mail.re2.yahoo.com (smtp101-mob.biz.mail.re2.yahoo.com [206.190.36.116]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l8PEAkQ3031471 for ; Tue, 25 Sep 2007 07:10:50 -0700 Received: (qmail 68503 invoked from network); 25 Sep 2007 13:44:10 -0000 Received: from unknown (HELO bda202-cell02.bisx.prod.on.blackberry) (thebs413@216.9.248.122 with xymcookie) by smtp101-mob.biz.mail.re2.yahoo.com with SMTP; 25 Sep 2007 13:44:10 -0000 X-YMail-OSG: 1wG1vP8VM1k.SfA20px3KH5o2Sf3NF_fX3aGU5iO1Va8sSlfqrG8ZlpiLHoaCR7kmKtE5vfcqwfn2YM5FnOAg8eT.S44a120EwM83MIjaaouOYssOHxy.CQhJtJ1WDsAoCvc_HoLPwV1nw0- X-rim-org-msg-ref-id: 2136069753 Message-ID: <2136069753-1190727845-cardhu_decombobulator_blackberry.rim.net-1977171728-@bxe108.bisx.prod.on.blackberry> Reply-To: b.j.smith@ieee.org X-Priority: Normal References: <20070923093841.GH19983@p15145560.pureserver.info><20070924173155.GI19983@p15145560.pureserver.info><20070924203958.GA4082@p15145560.pureserver.info><20070924213358.GB4082@p15145560.pureserver.info><20070924215223.GC4082@p15145560.pureserver.info><20070925123501.GA20499@p15145560.pureserver.info> In-Reply-To: Sensitivity: Normal Importance: Normal To: "Justin Piszcz" , xfs-bounce@oss.sgi.com, "Ralf Gross" Cc: linux-xfs@oss.sgi.com Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) From: "=?utf-8?B?QnJ5YW4gSiBTbWl0aA==?=" Date: Tue, 25 Sep 2007 13:44:01 +0000 Content-Type: text/plain; charset="Windows-1252" MIME-Version: 1.0 X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id l8PEApQ3031508 X-archive-position: 13096 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: b.j.smith@ieee.org Precedence: bulk X-list: xfs There is not a week that goes by without this on some list. Benchmarks not under load are useless, and hardware RAID shows no advantage at all, and can actually be hurt since all data is committed to the I/O controller synchronously at the driver. Furthermore, there is a huge difference between software RAID-5 reads and writes, and read benchmarks are basic RAID-0 (minus one disc) which is always faster with software RAID-0. Again, testing under actual, production load is how you gage performance. If your application is CPU bound, like most web servers, then software RAID-5 is fine because A) little I/O is require, so there is plenty of systen interconnect throughput available for LOAD-XOR-STOR, and B) web servers are heavily reads more than writes. But if your server is a file server, the the amount of inteconnect required for the LOAD-XOR-STO of software RAID-5 detracts from that available for the I/O intensive operations of the file service. You can't measure that at the kernel at all, much less not under load. Benchmark multiple clients hitting the server to see what they get. Furthermore, when you're concerned about I/O, you don't stop at your storage controller, but RX TOE with your HBA GbE NIC(s), your latency v. throughput of your discs, etc... -- Bryan J Smith - mailto:b.j.smith@ieee.org http://thebs413.blogspot.com Sent via BlackBerry from T-Mobile -----Original Message----- From: Justin Piszcz Date: Tue, 25 Sep 2007 08:50:15 To:Ralf Gross Cc:linux-xfs@oss.sgi.com Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) On Tue, 25 Sep 2007, Ralf Gross wrote: > Ralf Gross schrieb: >>> What do you get when (reading) from the raw device? >>> >>> dd if=/dev/sda bs=1M count=10240 >> >> The server has 16 GB RAM, so I tried it with 20 GB of data. >> >> dd if=/dev/sdd of=/dev/null bs=1M count=20480 >> 20480+0 Datensδtze ein >> 20480+0 Datensδtze aus >> 21474836480 Bytes (21 GB) kopiert, 95,3738 Sekunden, 225 MB/s >> >> and a second try: >> >> dd if=/dev/sdd of=/dev/null bs=1M count=20480 >> 20480+0 Datensδtze ein >> 20480+0 Datensδtze aus >> 21474836480 Bytes (21 GB) kopiert, 123,78 Sekunden, 173 MB/s >> >> I'm taoo tired to interprete these numbers at the moment, I'll do some >> more testing tomorrow. > > There is a second RAID device attached to the server (24x RAID5). The > numbers I get from this device are a bit worse than the 16x RAID 5 > numbers (150MB/s read with dd). > > I'm really wondering how people can achieve transfer rates of > 400MB/s and more. I know that I'm limited by the FC controller, but > I don't even get >200MB/s. > > Ralf > > Perhaps something is wrong with your setup? Here are my 10 raptors in RAID5 using Software RAID (no hw raid controller): p34:~# dd if=/dev/md3 of=/dev/null bs=1M count=16384 16384+0 records in 16384+0 records out 17179869184 bytes (17 GB) copied, 29.8193 seconds, 576 MB/s p34:~# From owner-xfs@oss.sgi.com Tue Sep 25 09:07:58 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Sep 2007 09:08: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=-0.9 required=5.0 tests=AWL,BAYES_05 autolearn=ham version=3.2.0-pre1-r499012 Received: from stlx01.stz-softwaretechnik.com (stz-softwaretechnik.de [217.160.223.211]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8PG7tQ3021470 for ; Tue, 25 Sep 2007 09:07:57 -0700 Received: from rg by stlx01.stz-softwaretechnik.com with local (Exim 3.36 #1 (Debian)) id 1IaCwt-0003Zj-00 for ; Tue, 25 Sep 2007 18:07:47 +0200 Date: Tue, 25 Sep 2007 18:07:37 +0200 From: Ralf Gross To: linux-xfs@oss.sgi.com Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) Message-ID: <20070925160737.GC20499@p15145560.pureserver.info> References: <2119512110-1190729335-cardhu_decombobulator_blackberry.rim.net-718597053-@bxe108.bisx.prod.on.blackberry> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2119512110-1190729335-cardhu_decombobulator_blackberry.rim.net-718597053-@bxe108.bisx.prod.on.blackberry> User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13097 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Ralf-Lists@ralfgross.de Precedence: bulk X-list: xfs Bryan J Smith schrieb: > Use multiple cards on multiple PCI-X/PCIe channels, each with > their own RAID-5 (or 6) volume, and then stripe (OS LVM) RAID-0 > across the volumes. The hardware is fixed to one PCI-X FC HBA (4Gb) and two 48x shelfs. The performance I get with this setup is ok for us. The data will be stored in bunches of multiple TB. Only few clients will access the data, maybe 5-10 clients at the same time. > Depending on your network service and application, you can use > either hardware or software for the RAID-5 (or 6). > If it's heavily read-only servicing, then software RAID works great, > because it's essentially RAID-0 (minus 1 disc). > But always use the OS RAID (e.g., LVM stripe) to stripe RAID-0 > across all volumes, assuming there is not an OS volume limit > (of course ;). > [...] I always use SW-RAID for RAID0 and RAID1. But for RAID 5/6 I choose either external arrays or internal controllers (Areca). Ralf From owner-xfs@oss.sgi.com Tue Sep 25 09:48:49 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Sep 2007 09:48: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=-0.1 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 l8PGmjQ3030265 for ; Tue, 25 Sep 2007 09:48:48 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 988E81C000267; Tue, 25 Sep 2007 12:48:48 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 942454019B78; Tue, 25 Sep 2007 12:48:48 -0400 (EDT) Date: Tue, 25 Sep 2007 12:48:48 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Ralf Gross cc: linux-xfs@oss.sgi.com Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) In-Reply-To: <20070925160737.GC20499@p15145560.pureserver.info> Message-ID: References: <2119512110-1190729335-cardhu_decombobulator_blackberry.rim.net-718597053-@bxe108.bisx.prod.on.blackberry> <20070925160737.GC20499@p15145560.pureserver.info> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13098 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 Tue, 25 Sep 2007, Ralf Gross wrote: > Bryan J Smith schrieb: >> Use multiple cards on multiple PCI-X/PCIe channels, each with >> their own RAID-5 (or 6) volume, and then stripe (OS LVM) RAID-0 >> across the volumes. > > The hardware is fixed to one PCI-X FC HBA (4Gb) and two 48x shelfs. > The performance I get with this setup is ok for us. The data will be > stored in bunches of multiple TB. Only few clients will access the > data, maybe 5-10 clients at the same time. > >> Depending on your network service and application, you can use >> either hardware or software for the RAID-5 (or 6). >> If it's heavily read-only servicing, then software RAID works great, >> because it's essentially RAID-0 (minus 1 disc). >> But always use the OS RAID (e.g., LVM stripe) to stripe RAID-0 >> across all volumes, assuming there is not an OS volume limit >> (of course ;). >> [...] > > I always use SW-RAID for RAID0 and RAID1. But for RAID 5/6 I choose > either external arrays or internal controllers (Areca). > > Ralf > > Just out of curisosity have you tried SW RAID5 on this array? Also what do you get if you use RAID0 (hw or sw)? Justin. From owner-xfs@oss.sgi.com Tue Sep 25 09:55:13 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Sep 2007 09:55:18 -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=BAYES_50,J_CHICKENPOX_44 autolearn=no version=3.2.0-pre1-r499012 Received: from web32906.mail.mud.yahoo.com (web32906.mail.mud.yahoo.com [209.191.69.83]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l8PGt8Q3032765 for ; Tue, 25 Sep 2007 09:55:12 -0700 Received: (qmail 84922 invoked by uid 60001); 25 Sep 2007 16:28:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=rgFzOYorPwkxevEcCbIOKUFexlGFkVZZqVoJpEgIhztefB8lVqx+SX0LfmCDkS2HZ30AqeK5L5Ox6mZnMW1oQ1ibHQYCO529WokER6M3mvUqj8ikodjFxxBopDphHp3SetzhkyYOWvB10RGMk2zaVAESExBdpztTXrBUOJGMYw4=; X-YMail-OSG: MTN6ASUVM1lDfuwOCKDdZ.88xCucBLF1sgFx3b5n Received: from [209.114.137.34] by web32906.mail.mud.yahoo.com via HTTP; Tue, 25 Sep 2007 09:28:29 PDT Date: Tue, 25 Sep 2007 09:28:29 -0700 (PDT) From: "Bryan J. Smith" Reply-To: b.j.smith@ieee.org Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) To: Ralf Gross Cc: linux-xfs@oss.sgi.com In-Reply-To: <20070925160737.GC20499@p15145560.pureserver.info> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <152219.84729.qm@web32906.mail.mud.yahoo.com> X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13099 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: thebs413@yahoo.com Precedence: bulk X-list: xfs Ralf Gross wrote: > The hardware is fixed to one PCI-X FC HBA (4Gb) and two 48x shelfs. > The performance I get with this setup is ok for us. The data will > be stored in bunches of multiple TB. Only few clients will access > the data, maybe 5-10 clients at the same time. If raw performance is your ultimate goal, the closer you are to the hardware, and the less overhead in the protocol, the better. Direct SATA channels (software RAID-10), or taking advantage of the 3Ware ASIC+SRAM (hardware RAID-10) is most ideal. I've put in a setup myself that used three (3) 3Ware Escalade 9550SX cards on three (3) different PCI-X channels, and then striped RAID-0 across all three (3) volumes (found little difference between using the OS LVM or the 3Ware manager for the RAID-0 stripe across volumes). Using a buffered RAID-5 hardware solution is not going to get you the best latency or direct DTR, if that is what matters. In most cases, it does not, depending on your application. > I always use SW-RAID for RAID0 and RAID1. But for RAID 5/6 I choose > either external arrays or internal controllers (Areca). Areca is the Intel IOP + firmware. Intel's X-Scale storage processing engines (SPE) seem to best 3Ware's AMCC PowerPC engine. The off-load is massive when I/O is an issue. Unfortunately, I still find I prefer 3Ware's firmware and software support in Linux over Areca, and Intel clearly does not have the dedication to addressing issues that 3Ware does (just like back in the IOP30x/i960 days, sigh). To me, support is key. I've yet to drop a 3Ware volume myself. The only people who seem to drop a volume are typically using 3Ware in JBOD mode, or are "early adopters" of new products. I don't care if it's hardware or software, "early adoption" of anything is just not worth it. I'd rather have reduced performance for "piece-of-mind." 3Ware has a solid history on Linux, and my experiences are the ultimate after 7 years.** [ **NOTE: Don't get me started. The common "proprietary" or "hardware reliance" argument doesn't hold, because 3Ware's volume upward compatibility is proven (I've moved volumes of ATA 6000 to 7000 series, SATA 8000 to 9000, etc...), and they have shared the data organization so you can read them with dmraid as well. I.e., you can always fall back to reading your data off a 3Ware volume with dmraid these days. I've also _never_ had an "ATA timeout" issue with 3Ware cards, because 3Ware updates its firmware regularly to "deal" with troublesome [S]ATA drives. That has bitten me far too many times in Linux with direct [S]ATA -- not Linux's fault, just the fault of hardware [S]ATA PHY chips and their on-drive IDE firmware, something 3Ware has mitigated for me time and time again. ] I'm completely biased though, I assemble file and database servers, not web or other CPU-bound systems. Turning my system interconnect (not the CPU, a PC CPU crunches XOR very fast) into a bottlenecked PIO operation is not ideal for NFS writes or large record SQL commits in my experience. Heck, one look at NetApp's volume w/NVRAM and SPE-accelerated RAID-4 designs will quickly change your opinion as well (and make you wonder if they aren't worth the cost at times as well ;). -- Bryan J. Smith Professional, Technical Annoyance b.j.smith@ieee.org http://thebs413.blogspot.com -------------------------------------------------- Fission Power: An Inconvenient Solution From owner-xfs@oss.sgi.com Tue Sep 25 10:25:56 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Sep 2007 10:26:00 -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_40 autolearn=ham version=3.2.0-pre1-r499012 Received: from stlx01.stz-softwaretechnik.com (stz-softwaretechnik.de [217.160.223.211]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8PHPqQ3012106 for ; Tue, 25 Sep 2007 10:25:56 -0700 Received: from rg by stlx01.stz-softwaretechnik.com with local (Exim 3.36 #1 (Debian)) id 1IaEAL-00071Z-00 for ; Tue, 25 Sep 2007 19:25:45 +0200 Date: Tue, 25 Sep 2007 19:25:35 +0200 From: Ralf Gross To: linux-xfs@oss.sgi.com Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) Message-ID: <20070925172535.GD20499@p15145560.pureserver.info> References: <20070925160737.GC20499@p15145560.pureserver.info> <152219.84729.qm@web32906.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <152219.84729.qm@web32906.mail.mud.yahoo.com> User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13100 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Ralf-Lists@ralfgross.de Precedence: bulk X-list: xfs Bryan J. Smith schrieb: > Ralf Gross wrote: > ... > I'm completely biased though, I assemble file and database servers, > not web or other CPU-bound systems. Turning my system interconnect > (not the CPU, a PC CPU crunches XOR very fast) into a bottlenecked > PIO operation is not ideal for NFS writes or large record SQL commits > in my experience. Heck, one look at NetApp's volume w/NVRAM and > SPE-accelerated RAID-4 designs will quickly change your opinion as > well (and make you wonder if they aren't worth the cost at times as > well ;). Thanks for all the details. Before I leave the office (it's getting dark here): I think the Overland RAID we have (48x Disk) is from the same manufacturer (Xyratex) that builds some devices for NetApp. Our profile is not that performance driven, thus the ~200MB/s read/write performace is ok. We just need cheap storage ;) Still I'm wondering how other people saturate a 4 Gb FC controller with one single RAID 5. At least that's what I've seen in some benchmarks and here on the list. If dd doesn't give me more than 200MB/s, the problem could only be the array, the controller or the FC connection. Given that other setup are similar and not using different controllers and stripes. Ralf From owner-xfs@oss.sgi.com Tue Sep 25 10:41:55 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Sep 2007 10: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=0.1 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.2.0-pre1-r499012 Received: from web32913.mail.mud.yahoo.com (web32913.mail.mud.yahoo.com [209.191.69.113]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l8PHfrQ3015945 for ; Tue, 25 Sep 2007 10:41:55 -0700 Received: (qmail 15593 invoked by uid 60001); 25 Sep 2007 17:41:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=THqIPWRHcNlur4t9NH9Ve+WOT1u00SpO2lCTW3sPFWGkMVkMu8WbF9K7AxxsSCPZF552OIrIAv5MOppPj96nAGFBz7ymIxnnD2M9lr0MLvK4cZ995sG7NQovPsozacDEEA3rpq4ToOpL+0Lcu1wvJkwPcuM55lzS+1JQBDyNSX4=; X-YMail-OSG: eBvyPLoVM1k1ae__5CD0AE_UqMswCsLgAcMbH7Jru4AY_1522C3bYU2Tve3M9MW6yBDO78w.Yer9b6ezsH_0hLF.BjO5FFMwYY.bU.FcxieeoYyeoLI- Received: from [209.114.137.34] by web32913.mail.mud.yahoo.com via HTTP; Tue, 25 Sep 2007 10:41:56 PDT Date: Tue, 25 Sep 2007 10:41:56 -0700 (PDT) From: "Bryan J. Smith" Reply-To: b.j.smith@ieee.org Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) To: Ralf Gross Cc: linux-xfs@oss.sgi.com In-Reply-To: <20070925172535.GD20499@p15145560.pureserver.info> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <625784.15537.qm@web32913.mail.mud.yahoo.com> X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13101 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: thebs413@yahoo.com Precedence: bulk X-list: xfs Ralf Gross wrote: > Thanks for all the details. Before I leave the office (it's getting > dark here): I think the Overland RAID we have (48x Disk) is from > the same manufacturer (Xyratex) that builds some devices for NetApp. There's a lot of cross-fabbing these days. I was referring more to NetApp's combined hardware-OS-volume approach, although that was clearly a poor tangent by myself. > Our profile is not that performance driven, thus the ~200MB/s > read/write performace is ok. We just need cheap storage ;) For what application? That is the question. I mean, sustained software RAID-5 writes can be a PITA. E.g., the dd example prior doesn't even do XOR recalculation, it merely copies the existing parity block with data. Doing sustained software RAID-5 writes can easily drop under 50MBps, as the PC interconnect was not designed to stream data (programmed I/O), only direct it (Direct Memory Access). > Still I'm wondering how other people saturate a 4 Gb FC controller > with one single RAID 5. At least that's what I've seen in some > benchmarks and here on the list. Depends on the solution, the benchmark, etc... > If dd doesn't give me more than 200MB/s, the problem could only be > the array, the controller or the FC connection. I think you're getting confused. There are many factors in how dd performs. Using an OS-managed volume will result in non-blocking I/O, of which dd will scream. Especially when the OS knows it's merely just copying one block to another, unlike the FC array, and doesn't need to recalculate the parity block. I know software RAID proponents like to show those numbers, but they are beyond removed from "real world," they literally leverage the fact that parity doesn't need to be recalculated for the blocks moved. You need to benchmark from your application -- e.g., clients. If you want "raw" disk access benchmarks, then build a software RAID volume with a massive number of SATA channels using "dumb" SATA ASICs. Don't even use an intelligent hardware RAID card in JBOD mode, that will only slow the DTR. > Given that other setup are similar and not using different > controllers and stripes. Again, benchmark from your application -- e.g., clients. Everything else means squat. I cannot stress this enough. The only way I can show otherwise, is with hardware taps (e.g., PCI-X, PCIe). I literally couldn't explain "well enough" to one client was only getting 60MBps and seeing only 10% CPU utilization why their software RAID was the bottleneck until I put in a PCI-X card and showed the amount of traffic on the bus. And even that wasn't the system interconnect (although it should be possible with a HTX card on an AMD solution, although the card would probably cost 5 figures and have some limits). -- Bryan J. Smith Professional, Technical Annoyance b.j.smith@ieee.org http://thebs413.blogspot.com -------------------------------------------------- Fission Power: An Inconvenient Solution From owner-xfs@oss.sgi.com Tue Sep 25 11:00:49 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Sep 2007 11:00: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.3 required=5.0 tests=AWL,BAYES_20 autolearn=ham version=3.2.0-pre1-r499012 Received: from web32907.mail.mud.yahoo.com (web32907.mail.mud.yahoo.com [209.191.69.84]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l8PI0kQ3019402 for ; Tue, 25 Sep 2007 11:00:48 -0700 Received: (qmail 79237 invoked by uid 60001); 25 Sep 2007 18:00:49 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=nn4aSxjBDvKNhWpY3dH3I5Gj6DXbseYmV/orE85CyIrRFUq7ilFfWMXRlnJgwmI3WXRLAoLgboJp2o9Qr/K1UCp2QEzxP4+LSKS/25A8UJpq/WpWMYknk51Ki3QhDkFBewssqxGWMmH3mbVARH4WeQnI1ezD7otvmn2N1QQufE8=; X-YMail-OSG: fF08_eAVM1nZQjWHbucaVB4BgFG.fT6ZJuFUTroO4WUtaOcj_e.XxI4NY.uWJvBkjwCn9Bb4BB2rEod7mAJZ4NNouKZtgcxLgMBqlPn4g939.EIsYew- Received: from [209.114.137.34] by web32907.mail.mud.yahoo.com via HTTP; Tue, 25 Sep 2007 11:00:49 PDT Date: Tue, 25 Sep 2007 11:00:49 -0700 (PDT) From: "Bryan J. Smith" Reply-To: b.j.smith@ieee.org Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) To: Justin Piszcz , Ralf Gross Cc: linux-xfs@oss.sgi.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <498689.78850.qm@web32907.mail.mud.yahoo.com> X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13102 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: thebs413@yahoo.com Precedence: bulk X-list: xfs Justin Piszcz wrote: > Just out of curisosity have you tried SW RAID5 on this array? > Also what do you get if you use RAID0 (hw or sw)? According to him, if I read it correclty, it is an external FC RAID-5 chassis. I.e., all of the logic is in the chassis. So your question is N/A. Although I'm more than ready to be proven incorrect. Furthermore, what benchmark do you use? If dd on the volume itself, software RAID wins, hands down. Doesn't matter what size you give it, it literally copies (and doesn't recalculate) the parity. It's the rawest form of non-blocking I/O, and uses virtually no system interconnect to the CPU (just pushes disk-mem-disk). -- Bryan J. Smith Professional, Technical Annoyance b.j.smith@ieee.org http://thebs413.blogspot.com -------------------------------------------------- Fission Power: An Inconvenient Solution From owner-xfs@oss.sgi.com Tue Sep 25 11:33:48 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Sep 2007 11:33: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 stlx01.stz-softwaretechnik.com (stz-softwaretechnik.de [217.160.223.211]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8PIXfQ3024992 for ; Tue, 25 Sep 2007 11:33:47 -0700 Received: from rg by stlx01.stz-softwaretechnik.com with local (Exim 3.36 #1 (Debian)) id 1IaFDy-0002Sz-00 for ; Tue, 25 Sep 2007 20:33:34 +0200 Date: Tue, 25 Sep 2007 20:33:24 +0200 From: Ralf Gross To: linux-xfs@oss.sgi.com Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) Message-ID: <20070925183324.GE20499@p15145560.pureserver.info> References: <498689.78850.qm@web32907.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <498689.78850.qm@web32907.mail.mud.yahoo.com> User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13103 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Ralf-Lists@ralfgross.de Precedence: bulk X-list: xfs Bryan J. Smith schrieb: > Justin Piszcz wrote: > > Just out of curisosity have you tried SW RAID5 on this array? > > Also what do you get if you use RAID0 (hw or sw)? > > According to him, if I read it correclty, it is an external FC RAID-5 > chassis. I.e., all of the logic is in the chassis. So your question > is N/A. > > Although I'm more than ready to be proven incorrect. No, your're right. It's an external chassis with FC connection to the server. Ralf From owner-xfs@oss.sgi.com Tue Sep 25 12:14:19 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Sep 2007 12:14: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.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from stlx01.stz-softwaretechnik.com (stz-softwaretechnik.de [217.160.223.211]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8PJEFQ3031436 for ; Tue, 25 Sep 2007 12:14:19 -0700 Received: from rg by stlx01.stz-softwaretechnik.com with local (Exim 3.36 #1 (Debian)) id 1IaFrE-0004ST-00 for ; Tue, 25 Sep 2007 21:14:08 +0200 Date: Tue, 25 Sep 2007 21:13:58 +0200 From: Ralf Gross To: linux-xfs@oss.sgi.com Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) Message-ID: <20070925191358.GF20499@p15145560.pureserver.info> References: <20070925172535.GD20499@p15145560.pureserver.info> <625784.15537.qm@web32913.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <625784.15537.qm@web32913.mail.mud.yahoo.com> User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13104 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Ralf-Lists@ralfgross.de Precedence: bulk X-list: xfs Bryan J. Smith schrieb: > > Our profile is not that performance driven, thus the ~200MB/s > > read/write performace is ok. We just need cheap storage ;) > > For what application? That is the question. I mean, sustained > software RAID-5 writes can be a PITA. E.g., the dd example prior > doesn't even do XOR recalculation, it merely copies the existing > parity block with data. Doing sustained software RAID-5 writes can > easily drop under 50MBps, as the PC interconnect was not designed to > stream data (programmed I/O), only direct it (Direct Memory Access). The server should be able to provide five 17MB/s streams (5 win clients). Each file is ~2GB large. The clients will access the data with smb/cifs, I think the main bottleneck will be samba. There will not be much write access, the data that later will be streamed to the clients will be transferend to the server from the win clients first. The files will not be changed afterwards. So there will be weeks where no data is written, and some days where several TB will be transfered to the server in 48 hours. Furthermore, the win clients read the data from external USB/PCIe SATA drives. Sometimes the clients transfers the data from a external enclosure with 5 drives (no raid) to the server. The will also be a limiting factor. > > Still I'm wondering how other people saturate a 4 Gb FC controller > > with one single RAID 5. At least that's what I've seen in some > > benchmarks and here on the list. > > Depends on the solution, the benchmark, etc... I've seen benchmark results from 3ware, areca and other hw raid 5 vendors (bonnie++, tiobench). > > If dd doesn't give me more than 200MB/s, the problem could only be > > the array, the controller or the FC connection. > > I think you're getting confused. > > There are many factors in how dd performs. Using an OS-managed > volume will result in non-blocking I/O, of which dd will scream. > Especially when the OS knows it's merely just copying one block to > another, unlike the FC array, and doesn't need to recalculate the > parity block. I know software RAID proponents like to show those > numbers, but they are beyond removed from "real world," they > literally leverage the fact that parity doesn't need to be > recalculated for the blocks moved. > > You need to benchmark from your application -- e.g., clients. If you > want "raw" disk access benchmarks, then build a software RAID volume > with a massive number of SATA channels using "dumb" SATA ASICs. > Don't even use an intelligent hardware RAID card in JBOD mode, that > will only slow the DTR. > > > Given that other setup are similar and not using different > > controllers and stripes. > > Again, benchmark from your application -- e.g., clients. Everything > else means squat. > > I cannot stress this enough. The only way I can show otherwise, is > with hardware taps (e.g., PCI-X, PCIe). I literally couldn't explain > "well enough" to one client was only getting 60MBps and seeing only > 10% CPU utilization why their software RAID was the bottleneck until > I put in a PCI-X card and showed the amount of traffic on the bus. > And even that wasn't the system interconnect (although it should be > possible with a HTX card on an AMD solution, although the card would > probably cost 5 figures and have some limits). Maybe I'm just confused by the benchmarks I found in the net and my 200MB/s sql. read/write with tiobench are perfectly ok. @Justin Piszcz: could you provide some tiobench numbers for you sw raid 5? Ralf From owner-xfs@oss.sgi.com Tue Sep 25 12:44:27 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Sep 2007 12:44: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 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 l8PJiOQ3008372 for ; Tue, 25 Sep 2007 12:44:27 -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 l8PJiPA5001807 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 25 Sep 2007 21:44:25 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8PJiObL001803; Tue, 25 Sep 2007 21:44:24 +0200 Date: Tue, 25 Sep 2007 21:44:24 +0200 From: Christoph Hellwig To: Vlad Apostolov Cc: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: [PATCH] cleanup vnode useage in xfs_dm.c Message-ID: <20070925194424.GA1714@lst.de> References: <20070923114339.GB9585@lst.de> <46F88602.4040104@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46F88602.4040104@sgi.com> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13105 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 Tue, Sep 25, 2007 at 01:52:34PM +1000, Vlad Apostolov wrote: > It is looking good Christoph. I also built and tested it with XFS DMAPI QA > all went fine. I think it is time to kill the 2.4 / 2.6 compat code as we > are going to drop the XFS 2.4 tree soon. Do you have a patch for this > or I could do it? I have a patch in the queue, as usual :) -- Kill 2.4 compat ifdefs in dmapi. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/dmapi/xfs_dm.c 2007-09-25 10:38:41.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c 2007-09-25 10:41:09.000000000 +0200 @@ -54,62 +54,23 @@ #define MAXNAMLEN MAXNAMELEN -#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0) #define MIN_DIO_SIZE(mp) ((mp)->m_sb.sb_sectsize) #define MAX_DIO_SIZE(mp) (INT_MAX & ~(MIN_DIO_SIZE(mp) - 1)) -#define XFS_TO_HOST_DEVT(mp) new_encode_dev(mp->m_ddev_targp->bt_dev) -#define BREAK_LEASE(inode,flag) break_lease(inode,flag) -#else -#define MIN_DIO_SIZE(mp) ((mp)->m_sb.sb_blocksize) -#define MAX_DIO_SIZE(mp) (INT_MAX & ~(MIN_DIO_SIZE(mp) - 1)) -#define XFS_TO_HOST_DEVT(mp) ((mp)->m_ddev_targp->bt_dev) -#define BREAK_LEASE(inode,flag) get_lease(inode,flag) -#endif static void up_rw_sems(struct inode *ip, int flags) { -#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0) if (flags & DM_FLAGS_IALLOCSEM_WR) up_write(&ip->i_alloc_sem); if (flags & DM_FLAGS_IMUX) mutex_unlock(&ip->i_mutex); -#endif -#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,0)) && \ - (LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,22)) - if (flags & DM_FLAGS_IMUX) - up(&ip->i_sem); - if (flags & DM_FLAGS_IALLOCSEM_RD) - up_read(&ip->i_alloc_sem); - else if (flags & DM_FLAGS_IALLOCSEM_WR) - up_write(&ip->i_alloc_sem); -#endif -#if LINUX_VERSION_CODE <= KERNEL_VERSION(2,4,21) - if (flags & DM_FLAGS_IMUX) - up(&ip->i_sem); -#endif } static void down_rw_sems(struct inode *ip, int flags) { -#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0) if (flags & DM_FLAGS_IMUX) mutex_lock(&ip->i_mutex); if (flags & DM_FLAGS_IALLOCSEM_WR) down_write(&ip->i_alloc_sem); -#endif -#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,0)) && \ - (LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,22)) - if (flags & DM_FLAGS_IALLOCSEM_RD) - down_read(&ip->i_alloc_sem); - else if (flags & DM_FLAGS_IALLOCSEM_WR) - down_write(&ip->i_alloc_sem); - if (flags & DM_FLAGS_IMUX) - down(&ip->i_sem); -#endif -#if LINUX_VERSION_CODE <= KERNEL_VERSION(2,4,21) - if (flags & DM_FLAGS_IMUX) - down(&ip->i_sem); -#endif } @@ -216,9 +177,6 @@ xfs_dm_send_data_event( * Otherwise if the file is memory mapped, no READ event can be set. * */ - - -#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0) STATIC int prohibited_mr_events( struct address_space *mapping) @@ -235,36 +193,6 @@ prohibited_mr_events( return prohibited; } -#else -STATIC int -prohibited_mr_events( - struct address_space *mapping) -{ - int prohibited = (1 << DM_EVENT_READ); - struct vm_area_struct *vma = NULL; - - if (!VN_MAPPED(inode_to_vn(mapping->host))) - return 0; - - spin_lock(&mapping->i_shared_lock); - for (vma = mapping->i_mmap_shared; vma; vma = vma->vm_next_share) { - if (vma->vm_flags & VM_WRITE) { - prohibited |= (1 << DM_EVENT_WRITE); - break; - } - } - for (vma = mapping->i_mmap; vma; vma = vma->vm_next_share) { - if (vma->vm_flags & VM_WRITE) { - prohibited |= (1 << DM_EVENT_WRITE); - break; - } - } - spin_unlock(&mapping->i_shared_lock); - - return prohibited; -} -#endif - #ifdef DEBUG_RIGHTS STATIC int @@ -415,7 +343,7 @@ xfs_dip_to_stat( /*buf->dt_xfs_projid = be16_to_cpu(dic->di_projid);*/ } buf->dt_ino = ino; - buf->dt_dev = XFS_TO_HOST_DEVT(mp); + buf->dt_dev = new_encode_dev(mp->m_ddev_targp->bt_dev); buf->dt_mode = be16_to_cpu(dic->di_mode); buf->dt_uid = be32_to_cpu(dic->di_uid); buf->dt_gid = be32_to_cpu(dic->di_gid); @@ -488,7 +416,7 @@ xfs_ip_to_stat( buf->dt_uid = dic->di_uid; buf->dt_gid = dic->di_gid; buf->dt_size = XFS_ISIZE(ip); - buf->dt_dev = XFS_TO_HOST_DEVT(mp); + buf->dt_dev = new_encode_dev(mp->m_ddev_targp->bt_dev); vn_atime_to_time_t(XFS_ITOV(ip), &buf->dt_atime); buf->dt_mtime = dic->di_mtime.t_sec; buf->dt_ctime = dic->di_ctime.t_sec; @@ -2507,7 +2435,7 @@ xfs_dm_punch_hole( return -EACCES; /* Make sure there are no leases. */ - error = BREAK_LEASE(inode, FMODE_WRITE); + error = break_lease(inode, FMODE_WRITE); if (error) return -EBUSY; From owner-xfs@oss.sgi.com Tue Sep 25 12:45:30 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Sep 2007 12:45: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.9 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 l8PJjQQ3008683 for ; Tue, 25 Sep 2007 12:45:30 -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 l8PJjSA5001857 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 25 Sep 2007 21:45:28 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8PJjSnA001855 for xfs@oss.sgi.com; Tue, 25 Sep 2007 21:45:28 +0200 Date: Tue, 25 Sep 2007 21:45:28 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: [PATCH 1/2] kill xfs_freeze Message-ID: <20070925194528.GA1818@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-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13106 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 No need to have a wrapper just two call two more functions. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_super.c 2007-09-23 13:54:35.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c 2007-09-23 13:56:12.000000000 +0200 @@ -41,6 +41,7 @@ #include "xfs_rtalloc.h" #include "xfs_error.h" #include "xfs_itable.h" +#include "xfs_fsops.h" #include "xfs_rw.h" #include "xfs_acl.h" #include "xfs_attr.h" @@ -684,11 +685,19 @@ xfs_fs_remount( return -error; } +/* + * Second stage of a freeze. The data is already frozen so we only + * need to take care of themetadata. Once that's done write a dummy + * record to dirty the log in case of a crash while frozen. + */ STATIC void xfs_fs_lockfs( struct super_block *sb) { - xfs_freeze(XFS_M(sb)); + struct xfs_mount *mp = XFS_M(sb); + + xfs_attr_quiesce(mp); + xfs_fs_log_dummy(mp); } STATIC int Index: linux-2.6-xfs/fs/xfs/xfs_vfsops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vfsops.c 2007-09-23 13:54:35.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_vfsops.c 2007-09-23 13:56:12.000000000 +0200 @@ -692,7 +692,7 @@ xfs_quiesce_fs( * care of the metadata. New transactions are already blocked, so we need to * wait for any remaining transactions to drain out before proceding. */ -STATIC void +void xfs_attr_quiesce( xfs_mount_t *mp) { Index: linux-2.6-xfs/fs/xfs/xfs_vfsops.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vfsops.h 2007-09-23 13:56:16.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_vfsops.h 2007-09-23 13:56:34.000000000 +0200 @@ -21,8 +21,8 @@ int xfs_vget(struct xfs_mount *mp, bhv_v int xfs_parseargs(struct xfs_mount *mp, char *options, struct xfs_mount_args *args, int update); int xfs_showargs(struct xfs_mount *mp, struct seq_file *m); -void xfs_freeze(struct xfs_mount *mp); void xfs_do_force_shutdown(struct xfs_mount *mp, int flags, char *fname, int lnnum); +void xfs_attr_quiesce(struct xfs_mount *mp); #endif /* _XFS_VFSOPS_H */ From owner-xfs@oss.sgi.com Tue Sep 25 12:47:56 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Sep 2007 12:47: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.9 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 l8PJleQ3009678 for ; Tue, 25 Sep 2007 12:47:55 -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 l8PJlgA5002009 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 25 Sep 2007 21:47:42 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8PJlgCr002007 for xfs@oss.sgi.com; Tue, 25 Sep 2007 21:47:42 +0200 Date: Tue, 25 Sep 2007 21:47:42 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: [PATCH 2/2] kill xfs_statvfs Message-ID: <20070925194741.GB1818@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-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13107 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 Kill xfs_statvfs. We were already filling the Linux struct statfs anyway, and doing this trivial task directly in xfs_fs_statfs makes the code quite a bit cleaner. While I was at it I also moved copying attributes that don't change over the lifetime of the filesystem outside the superblock lock. xfs_fs_fill_super used to get the magic number and blocksize through xfs_statvfs, but assigning them directly is a lot cleaner and will save some stack space during mount. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_super.c 2007-09-23 13:56:43.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c 2007-09-23 14:00:03.000000000 +0200 @@ -664,8 +664,44 @@ xfs_fs_statfs( struct dentry *dentry, struct kstatfs *statp) { - return -xfs_statvfs(XFS_M(dentry->d_sb), statp, - vn_from_inode(dentry->d_inode)); + struct xfs_mount *mp = XFS_M(dentry->d_sb); + xfs_sb_t *sbp = &mp->m_sb; + __uint64_t fakeinos, id; + xfs_extlen_t lsize; + + statp->f_type = XFS_SB_MAGIC; + statp->f_namelen = MAXNAMELEN - 1; + + id = huge_encode_dev(mp->m_ddev_targp->bt_dev); + statp->f_fsid.val[0] = (u32)id; + statp->f_fsid.val[1] = (u32)(id >> 32); + + xfs_icsb_sync_counters_flags(mp, XFS_ICSB_LAZY_COUNT); + + spin_lock(&mp->m_sb_lock); + statp->f_bsize = sbp->sb_blocksize; + lsize = sbp->sb_logstart ? sbp->sb_logblocks : 0; + statp->f_blocks = sbp->sb_dblocks - lsize; + statp->f_bfree = statp->f_bavail = + sbp->sb_fdblocks - XFS_ALLOC_SET_ASIDE(mp); + fakeinos = statp->f_bfree << sbp->sb_inopblog; +#if XFS_BIG_INUMS + fakeinos += mp->m_inoadd; +#endif + statp->f_files = + MIN(sbp->sb_icount + fakeinos, (__uint64_t)XFS_MAXINUMBER); + if (mp->m_maxicount) +#if XFS_BIG_INUMS + if (!mp->m_inoadd) +#endif + statp->f_files = min_t(typeof(statp->f_files), + statp->f_files, + mp->m_maxicount); + statp->f_ffree = statp->f_files - (sbp->sb_icount - sbp->sb_ifree); + spin_unlock(&mp->m_sb_lock); + + XFS_QM_DQSTATVFS(xfs_vtoi(dentry->d_inode), statp); + return 0; } STATIC int @@ -768,7 +804,6 @@ xfs_fs_fill_super( struct inode *rootvp; struct xfs_mount *mp = NULL; struct xfs_mount_args *args = xfs_args_allocate(sb, silent); - struct kstatfs statvfs; int error; mp = xfs_mount_init(); @@ -796,14 +831,10 @@ xfs_fs_fill_super( if (error) goto fail_vfsop; - error = xfs_statvfs(mp, &statvfs, NULL); - if (error) - goto fail_unmount; - sb->s_dirt = 1; - sb->s_magic = statvfs.f_type; - sb->s_blocksize = statvfs.f_bsize; - sb->s_blocksize_bits = ffs(statvfs.f_bsize) - 1; + sb->s_magic = XFS_SB_MAGIC; + sb->s_blocksize = mp->m_sb.sb_blocksize; + sb->s_blocksize_bits = ffs(sb->s_blocksize) - 1; sb->s_maxbytes = xfs_max_file_offset(sb->s_blocksize_bits); sb->s_time_gran = 1; set_posix_acl_flag(sb); Index: linux-2.6-xfs/fs/xfs/xfs_vfsops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vfsops.c 2007-09-23 13:56:12.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_vfsops.c 2007-09-23 13:57:01.000000000 +0200 @@ -839,59 +839,6 @@ xfs_root( } /* - * xfs_statvfs - * - * Fill in the statvfs structure for the given file system. We use - * the superblock lock in the mount structure to ensure a consistent - * snapshot of the counters returned. - */ -int -xfs_statvfs( - xfs_mount_t *mp, - bhv_statvfs_t *statp, - bhv_vnode_t *vp) -{ - __uint64_t fakeinos; - xfs_extlen_t lsize; - xfs_sb_t *sbp; - - sbp = &(mp->m_sb); - - statp->f_type = XFS_SB_MAGIC; - - xfs_icsb_sync_counters_flags(mp, XFS_ICSB_LAZY_COUNT); - spin_lock(&mp->m_sb_lock); - statp->f_bsize = sbp->sb_blocksize; - lsize = sbp->sb_logstart ? sbp->sb_logblocks : 0; - statp->f_blocks = sbp->sb_dblocks - lsize; - statp->f_bfree = statp->f_bavail = - sbp->sb_fdblocks - XFS_ALLOC_SET_ASIDE(mp); - fakeinos = statp->f_bfree << sbp->sb_inopblog; -#if XFS_BIG_INUMS - fakeinos += mp->m_inoadd; -#endif - statp->f_files = - MIN(sbp->sb_icount + fakeinos, (__uint64_t)XFS_MAXINUMBER); - if (mp->m_maxicount) -#if XFS_BIG_INUMS - if (!mp->m_inoadd) -#endif - statp->f_files = min_t(typeof(statp->f_files), - statp->f_files, - mp->m_maxicount); - statp->f_ffree = statp->f_files - (sbp->sb_icount - sbp->sb_ifree); - spin_unlock(&mp->m_sb_lock); - - xfs_statvfs_fsid(statp, mp); - statp->f_namelen = MAXNAMELEN - 1; - - if (vp) - XFS_QM_DQSTATVFS(xfs_vtoi(vp), statp); - return 0; -} - - -/* * xfs_sync flushes any pending I/O to file system vfsp. * * This routine is called by vfs_sync() to make sure that things make it Index: linux-2.6-xfs/fs/xfs/xfs_vfsops.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vfsops.h 2007-09-23 13:57:06.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_vfsops.h 2007-09-23 13:57:10.000000000 +0200 @@ -14,8 +14,6 @@ int xfs_unmount(struct xfs_mount *mp, in int xfs_mntupdate(struct xfs_mount *mp, int *flags, struct xfs_mount_args *args); int xfs_root(struct xfs_mount *mp, bhv_vnode_t **vpp); -int xfs_statvfs(struct xfs_mount *mp, struct kstatfs *statp, - bhv_vnode_t *vp); int xfs_sync(struct xfs_mount *mp, int flags); int xfs_vget(struct xfs_mount *mp, bhv_vnode_t **vpp, struct xfs_fid *xfid); int xfs_parseargs(struct xfs_mount *mp, char *options, 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-23 13:58:17.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_linux.h 2007-09-23 13:58:21.000000000 +0200 @@ -212,10 +212,6 @@ #define xfs_stack_trace() dump_stack() #define xfs_itruncate_data(ip, off) \ (-vmtruncate(vn_to_inode(XFS_ITOV(ip)), (off))) -#define xfs_statvfs_fsid(statp, mp) \ - ({ u64 id = huge_encode_dev((mp)->m_ddev_targp->bt_dev); \ - __kernel_fsid_t *fsid = &(statp)->f_fsid; \ - (fsid->val[0] = (u32)id, fsid->val[1] = (u32)(id >> 32)); }) /* Move the kernel do_div definition off to one side */ From owner-xfs@oss.sgi.com Tue Sep 25 13:21:34 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Sep 2007 13:21: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.8 required=5.0 tests=AWL,BAYES_50,RDNS_DYNAMIC autolearn=no version=3.2.0-pre1-r499012 Received: from ty.sabi.co.UK (82-69-39-138.dsl.in-addr.zen.co.uk [82.69.39.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8PKLSQ3015189 for ; Tue, 25 Sep 2007 13:21:33 -0700 Received: from from [127.0.0.1] (helo=base.ty.sabi.co.UK) by ty.sabi.co.UK with esmtp(Exim 4.66 #1) id 1IZR19-0007Pt-SN for ; Sun, 23 Sep 2007 13:56:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18166.25242.174049.175729@base.ty.sabi.co.UK> Date: Sun, 23 Sep 2007 13:56:58 +0100 X-Face: SMJE]JPYVBO-9UR%/8d'mG.F!@.,l@c[f'[%S8'BZIcbQc3/">GrXDwb#;fTRGNmHr^JFb SAptvwWc,0+z+~p~"Gdr4H$(|N(yF(wwCM2bW0~U?HPEE^fkPGx^u[*[yV.gyB!hDOli}EF[\cW*S H&spRGFL}{`bj1TaD^l/"[ msn( /TH#THs{Hpj>)]f> Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) In-Reply-To: <20070923093841.GH19983@p15145560.pureserver.info> References: <20070923093841.GH19983@p15145560.pureserver.info> X-Mailer: VM 7.17 under 21.5 (beta28) XEmacs Lucid From: pg_xf2@xf2.for.sabi.co.UK (Peter Grandi) X-Disclaimer: This message contains only personal opinions X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13108 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pg_xf2@xf2.for.sabi.co.UK Precedence: bulk X-list: xfs >>> On Sun, 23 Sep 2007 11:38:41 +0200, Ralf Gross >>> said: Ralf> Hi, we have a new large raid array, the shelf has 48 disks, Ralf> the max. amount of disks in a single raid 5 set is 16. Too bad about that petty limitation ;-). Ralf> There will be one global spare disk, thus we have two raid 5 Ralf> with 15 data disks and one with 14 data disk. Ahhh a positive-thinking, can-do, brave design ;-). [ ... ] Ralf> Often the data will be transfernd from the windows clients Ralf> to the server in some parallel copy jobs at night (eg. 5-10, Ralf> for each new data directory). The clients will access the Ralf> data later (mostly) read only, the data will not be changed Ralf> after it was stored on the file server. This is good, and perhaps in some cases one of the few cases in which even RAID5 naysayers might now object too much. Ralf> Each client then needs a data stream of about 17 MB/s Ralf> (max. 5 clients are expected to acces the data in parallel). Do the requirements include as features some (possibly several) hours of ''challenging'' read performance if any disk fails or total loss of data if another disks fails during that time? ;-) IIRC Google have reported 5% per year disk failure rates across a very wide mostly uncorrelated population, you have 48 disks, perhaps 2-3 disks per year will fail. Perhaps more and more often, because they will likely be all from the same manufacturer, model, batch and spinning in the same environment. Ralf> [ ... ] I expect the fs, each will have a size of 10-11 TB, Ralf> to be filled > 90%. I know this is not ideal, but we need Ralf> every GB we can get. That "every GB we can get" is often the key in ''wide RAID5'' stories. Cheap as well as fast and safe, you can have it all with wide RAID5 setups, so the salesmen would say ;-). Ralf> [ ... ] Stripe Size : 960 KB (15 x 64 KM) Ralf> [ ... ] Stripe Size : 896 KB (14 x 64 KB) Pretty long stripes, I wonder what happens when a whole stripe cannot be written at once or it can but is not naturally aligned ;-). Ralf> [ ... ] about 150 MB/s in seq. writing Surprise surprise ;-). Ralf> (tiobench) and 160 MB/s in seq. reading. This is sort of low. If there something that RAID5 can do sort of OK is reads (if there are no faults). I'd look at the underlying storage system and the maximum performance that you can get out of a single disk. I have seen a 45-drive 500GB storage subsystem where each drive can deliver at most 7-10MB/s (even if the same disk standalone in an ordinary PC can do 60-70MB/s), and the supplier actually claims so in their published literature (that RAID product is meant to compete *only* with tape backup subsystems). Your later comment that "The raid array is connect to the server by fibre channel" makes me suspect that it may be the same brand. Ralf> This is ok, As the total aggregate requirement is 5x17MB/s this is probably the case [as long as there are no drive failures ;-)]. Ralf> but I'm curious what I could get with tuned xfs parameters. Looking at the archives of this mailing list the topic ''good mkfs parameters'' reappears frequently, even if usually for smaller arrays, as many have yet to discover the benefits of 15-wide RAID5 setups ;-). Threads like these may help: http://OSS.SGI.com/archives/xfs/2007-01/msg00079.html http://OSS.SGI.com/archives/xfs/2007-05/msg00051.html From owner-xfs@oss.sgi.com Tue Sep 25 13:23:50 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Sep 2007 13:23:55 -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,J_CHICKENPOX_44 autolearn=no version=3.2.0-pre1-r499012 Received: from web32906.mail.mud.yahoo.com (web32906.mail.mud.yahoo.com [209.191.69.83]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l8PKNiQ3015805 for ; Tue, 25 Sep 2007 13:23:50 -0700 Received: (qmail 81205 invoked by uid 60001); 25 Sep 2007 20:23:47 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=Ms9bGzAIsty6dJ1H6AaJzx0Y43GR5drl7fH93iki2/bAqu11OJMnfFlZJa1ipjQVrZU1JlU1dHgF9Ym+/HYfowHYU/liEi/Pr4McpUpFxZRl6+CPuit2+o7eglT6iAz+pVHU2FRE6qqzmZb1M6Z3OSlWKEJ0ykqyGYkWrKTEPmM=; X-YMail-OSG: MTw.JT0VM1nDdjGhrjTJsUhy17DNuV58hTLVGK.IcJr7s_0UFc60ChgnQDI86ULK0mOalWfWoHy_M4SAEVicy7qOF97Kh.gd0dNUjuZGiq9gpUJmjHA- Received: from [209.114.137.34] by web32906.mail.mud.yahoo.com via HTTP; Tue, 25 Sep 2007 13:23:47 PDT Date: Tue, 25 Sep 2007 13:23:47 -0700 (PDT) From: "Bryan J. Smith" Reply-To: b.j.smith@ieee.org Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) To: Ralf Gross , linux-xfs@oss.sgi.com In-Reply-To: <20070925191358.GF20499@p15145560.pureserver.info> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <656917.81056.qm@web32906.mail.mud.yahoo.com> X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13109 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: thebs413@yahoo.com Precedence: bulk X-list: xfs Ralf Gross wrote: > The server should be able to provide five 17MB/s streams (5 win > clients). Each file is ~2GB large. The clients will access the > data with smb/cifs, I think the main bottleneck will be samba. So it's largely read-only SMB access? So we're talking ... - Largely read-only disk access - Largely server TX-only TCP/IP serving Read-only is cheap, and software RAID-5 is essentially RAID-0 (sans one disc). So software RAID-5 is just fine there (assuming there are no volume addressing limitations). Server TX is also cheap, most commodity server NICs (i.e., even those built into mainboards, or typical dual-MAC 96-128KiB SRAM unified buffer) have a TX TCP Off-load Engine (TOE), some even with Linux driver support. You don't need any hardware accelerated RAID or RX TOE (which is far, far more expensive than TX TOE, largely for receive buffer and processing). > Furthermore, the win clients read the data from external USB/PCIe > SATA drives. Ouch. But I won't go there. ;) > Sometimes the clients transfers the data from a external > enclosure with 5 drives (no raid) to the server. The will also be a > limiting factor. Ouch. But I won't go there. ;) > I've seen benchmark results from 3ware, areca and other hw raid 5 > vendors (bonnie++, tiobench). Bonnie++ is really only good for NFS mounts from multiple clients to a server, and then it will vary. Aggregate, median, etc... studies are required. > Maybe I'm just confused by the benchmarks I found in the > net and my 200MB/s sql. read/write with tiobench are > perfectly ok. I've striped RAID-0 over two, RAID-10 volumes on old 3Ware Escalade 8500-8LP series products over two PCI-X (66MHz) busses and reached close to 400MBps reads, and over 200MBps writes. And that was old ASIC+SRAM (only 4MB) technology in the Escalade 8500 series, not even native SATA (PATA with SATA PHY). But I wouldn't get even close to that over the network, especially not for SMB, unless I used a 4xGbE with a RX TOE and a layer-3 switch. -- Bryan J. Smith Professional, Technical Annoyance b.j.smith@ieee.org http://thebs413.blogspot.com -------------------------------------------------- Fission Power: An Inconvenient Solution From owner-xfs@oss.sgi.com Tue Sep 25 14:50:28 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Sep 2007 14:50: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=3.0 required=5.0 tests=BAYES_50,SUBJ_NOTIFICATION autolearn=no version=3.2.0-pre1-r499012 Received: from mail.colum.edu (l9.colum.edu [206.69.212.154] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8PLoOQ3029232 for ; Tue, 25 Sep 2007 14:50:28 -0700 Received: from exmail.admin.colum.edu (10.1.254.228) by hubserver.admin.colum.edu (10.1.254.174) with Microsoft SMTP Server id 8.0.730.1; Tue, 25 Sep 2007 16:39:40 -0500 From: To: linux-xfs@oss.sgi.com Date: Tue, 25 Sep 2007 16:39:32 -0500 MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="9B095B5ADSN=_01C7E0D9BA738C16000CD605exmail.admin.col" X-DSNContext: 335a7efd - 4523 - 00000001 - 80040546 Message-ID: <8mTy1svcW0000cf01@exmail.admin.colum.edu> Subject: Delivery Status Notification (Failure) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13110 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: postmaster@colum.edu Precedence: bulk X-list: xfs --9B095B5ADSN=_01C7E0D9BA738C16000CD605exmail.admin.col Content-Type: text/plain; charset="unicode-1-1-utf-7" This is an automatically generated Delivery Status Notification. Delivery to the following recipients failed. paper@popmail.colum.edu --9B095B5ADSN=_01C7E0D9BA738C16000CD605exmail.admin.col Content-Type: message/delivery-status Reporting-MTA: dns;exmail.admin.colum.edu Received-From-MTA: dns;mail1.colum.edu Arrival-Date: Tue, 25 Sep 2007 16:39:31 -0500 Final-Recipient: rfc822;paper@popmail.colum.edu Action: failed Status: 5.1.1 --9B095B5ADSN=_01C7E0D9BA738C16000CD605exmail.admin.col Content-Type: message/rfc822 Received: from mail1.colum.edu ([206.69.160.58]) by exmail.admin.colum.edu with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Sep 2007 16:39:31 -0500 Received: from rs25s9.datacenter.cha.cantv.net (rs25s9.datacenter.cha.cantv.net [200.44.33.40]) by mail1.colum.edu (8.13.8/8.13.8) with ESMTP id l8PLhSEK005297 for ; Tue, 25 Sep 2007 16:43:29 -0500 (envelope-from linux-xfs@oss.sgi.com) Received: from oss.sgi.com (201-243-66-139.dyn.dsl.cantv.net [201.243.66.139] (may be forged)) by rs25s9.datacenter.cha.cantv.net (8.13.8/8.13.0/3.0) with ESMTP id l8PLclDP005105 for ; Tue, 25 Sep 2007 17:39:20 -0400 Message-Id: <200709252139.l8PLclDP005105@rs25s9.datacenter.cha.cantv.net> X-Matched-Lists: [] From: linux-xfs@oss.sgi.com To: paper@popmail.colum.edu Subject: [PMX:BANNED ZIP] Delivery reports about your e-mail Date: Tue, 25 Sep 2007 17:44:18 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0011_E4BAC446.D99C2742" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Return-Path: linux-xfs@oss.sgi.com X-OriginalArrivalTime: 25 Sep 2007 21:39:32.0076 (UTC) FILETIME=[8EF5DAC0:01C7FFBC] This is a multi-part message in MIME format. ------=_NextPart_000_0011_E4BAC446.D99C2742 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Your message could not be delivered [DO NOT SEND THIS MESSAGE TO IS-SPAM] A zip file was removed from this message. If you were expecting a zip notify the sender to rename the file extension and resend the message. ------=_NextPart_000_0011_E4BAC446.D99C2742-- --9B095B5ADSN=_01C7E0D9BA738C16000CD605exmail.admin.col-- From owner-xfs@oss.sgi.com Tue Sep 25 16:38:54 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Sep 2007 16:38: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.1 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 l8PNcqQ3014606 for ; Tue, 25 Sep 2007 16:38:54 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id BC8151C000260; Tue, 25 Sep 2007 19:38:55 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id B839F4019B78; Tue, 25 Sep 2007 19:38:55 -0400 (EDT) Date: Tue, 25 Sep 2007 19:38:55 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: b.j.smith@ieee.org cc: Ralf Gross , linux-xfs@oss.sgi.com Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) In-Reply-To: <498689.78850.qm@web32907.mail.mud.yahoo.com> Message-ID: References: <498689.78850.qm@web32907.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13111 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 Tue, 25 Sep 2007, Bryan J. Smith wrote: > Justin Piszcz wrote: >> Just out of curisosity have you tried SW RAID5 on this array? >> Also what do you get if you use RAID0 (hw or sw)? > > According to him, if I read it correclty, it is an external FC RAID-5 > chassis. I.e., all of the logic is in the chassis. So your question > is N/A. > > Although I'm more than ready to be proven incorrect. > > Furthermore, what benchmark do you use? If dd on the volume itself, > software RAID wins, hands down. Doesn't matter what size you give > it, it literally copies (and doesn't recalculate) the parity. It's > the rawest form of non-blocking I/O, and uses virtually no system > interconnect to the CPU (just pushes disk-mem-disk). > > -- > Bryan J. Smith Professional, Technical Annoyance > b.j.smith@ieee.org http://thebs413.blogspot.com > -------------------------------------------------- > Fission Power: An Inconvenient Solution > bonnie++, iozone, etc.. all show ~430-460 MiB/s write and ~550 MiB/s read Justin. From owner-xfs@oss.sgi.com Tue Sep 25 17:11:00 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Sep 2007 17:11: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.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 l8Q0AvQ3018759 for ; Tue, 25 Sep 2007 17:10:59 -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 KAA12460; Wed, 26 Sep 2007 10:10:54 +1000 Message-ID: <46F9A38E.6000200@sgi.com> Date: Wed, 26 Sep 2007 10:10:54 +1000 From: Donald Douwsma User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH 1/2] kill xfs_freeze References: <20070925194528.GA1818@lst.de> In-Reply-To: <20070925194528.GA1818@lst.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13112 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 Christoph Hellwig wrote: > No need to have a wrapper just two call two more functions. ... > > Index: linux-2.6-xfs/fs/xfs/xfs_vfsops.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_vfsops.c 2007-09-23 13:54:35.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_vfsops.c 2007-09-23 13:56:12.000000000 +0200 > @@ -692,7 +692,7 @@ xfs_quiesce_fs( > * care of the metadata. New transactions are already blocked, so we need to > * wait for any remaining transactions to drain out before proceding. > */ > -STATIC void > +void > xfs_attr_quiesce( > xfs_mount_t *mp) > { > Index: linux-2.6-xfs/fs/xfs/xfs_vfsops.h > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_vfsops.h 2007-09-23 13:56:16.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_vfsops.h 2007-09-23 13:56:34.000000000 +0200 This has removed all use of xfs_freeze, but I cant see a diff hunk that removes the xfs_freeze implementation from xfs_vfsops.c Don From owner-xfs@oss.sgi.com Wed Sep 26 01:13:49 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 01:13:52 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) 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.3.0-r574664 Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8Q8DkoC028526 for ; Wed, 26 Sep 2007 01:13: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 l8Q8DjA5032444 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 26 Sep 2007 10:13:45 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8Q8DiGX032442; Wed, 26 Sep 2007 10:13:44 +0200 Date: Wed, 26 Sep 2007 10:13:44 +0200 From: Christoph Hellwig To: Vlad Apostolov Cc: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: [PATCH] cleanup vnode useage in xfs_dm.c Message-ID: <20070926081344.GA32414@lst.de> References: <20070923114339.GB9585@lst.de> <46F88602.4040104@sgi.com> <20070925194424.GA1714@lst.de> <46F9B766.8070808@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46F9B766.8070808@sgi.com> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Virus-Scanned: ClamAV 0.91.2/4402/Tue Sep 25 21:33:35 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13113 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 Wed, Sep 26, 2007 at 11:35:34AM +1000, Vlad Apostolov wrote: > Christoph Hellwig wrote: > >I have a patch in the queue, as usual :) > > > >-- > > > >Kill 2.4 compat ifdefs in dmapi. > I checked in the patch in the XFS development tree. I guess you > probably have or are planning patches for the same cleanup in > xfs.h, dmapi_register.c and dmapi_sysent.c? Ah, haven't looked at those. If everyone is fine with that I can send these patches. From owner-xfs@oss.sgi.com Wed Sep 26 01:21:31 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 01:21:34 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_34 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l8Q8LQgv030237 for ; Wed, 26 Sep 2007 01:21:29 -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 SAA24839; Wed, 26 Sep 2007 18:21:20 +1000 From: donaldd@sgi.com Received: by linuxbuild.melbourne.sgi.com (Postfix, from userid 16365) id 86D772FB966D; Wed, 26 Sep 2007 18:21:20 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 971050 - Remove linux-2.4 build support Message-Id: <20070926082120.86D772FB966D@linuxbuild.melbourne.sgi.com> Date: Wed, 26 Sep 2007 18:21:20 +1000 (EST) X-Virus-Scanned: ClamAV 0.91.2/4402/Tue Sep 25 21:33:35 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13114 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 Remove linux-2.4 Makefile wrappers from fs/xfs/quota, fs/xfs/dmapi and fs/dmapi. Date: Wed Sep 26 18:20:13 AEST 2007 Workarea: linuxbuild.melbourne.sgi.com:/home/donaldd/isms/2.6.x-xfs Inspected by: tes,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:29784a fs/xfs/quota/Makefile - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/Makefile.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h - Remove linux-2.4 Makefile wrappers fs/xfs/quota, fs/xfs/dmapi and fs/dmapi. fs/xfs/dmapi/Makefile - 1.27 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/Makefile.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h - Remove linux-2.4 Makefile wrappers fs/xfs/quota, fs/xfs/dmapi and fs/dmapi. fs/xfs/dmapi/Makefile-linux-2.4 - 1.6 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/Makefile-linux-2.4.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h - Remove linux-2.4 Makefile wrappers fs/xfs/quota, fs/xfs/dmapi and fs/dmapi. fs/xfs/quota/Makefile-linux-2.4 - 1.7 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/Makefile-linux-2.4.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h - Remove linux-2.4 Makefile wrappers fs/xfs/quota, fs/xfs/dmapi and fs/dmapi. fs/xfs/quota/Makefile-linux-2.6 - 1.6 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/Makefile-linux-2.6.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h - Remove linux-2.4 Makefile wrappers fs/xfs/quota, fs/xfs/dmapi and fs/dmapi. fs/xfs/dmapi/Makefile-linux-2.6 - 1.7 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/Makefile-linux-2.6.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h - Remove linux-2.4 Makefile wrappers fs/xfs/quota, fs/xfs/dmapi and fs/dmapi. Modid: linux-melb:dmapi:29784b fs/dmapi/Makefile-linux-2.4 - 1.4 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/fs/dmapi/Makefile-linux-2.4.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h - Remove linux-2.4 Makefile wrappers fs/xfs/quota, fs/xfs/dmapi and fs/dmapi. fs/dmapi/Makefile-linux-2.6 - 1.4 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/fs/dmapi/Makefile-linux-2.6.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h - Remove linux-2.4 Makefile wrappers fs/xfs/quota, fs/xfs/dmapi and fs/dmapi. fs/dmapi/Makefile - 1.26 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/fs/dmapi/Makefile.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h - Remove linux-2.4 Makefile wrappers fs/xfs/quota, fs/xfs/dmapi and fs/dmapi. From owner-xfs@oss.sgi.com Wed Sep 26 01:23:56 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 01:24:00 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) 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.3.0-r574664 Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8Q8NsKd030954 for ; Wed, 26 Sep 2007 01:23:56 -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 l8Q8NqA5032766 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 26 Sep 2007 10:23:52 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8Q8Nqvg032764; Wed, 26 Sep 2007 10:23:52 +0200 Date: Wed, 26 Sep 2007 10:23:52 +0200 From: Christoph Hellwig To: Donald Douwsma Cc: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: [PATCH 1/2] kill xfs_freeze Message-ID: <20070926082351.GA32719@lst.de> References: <20070925194528.GA1818@lst.de> <46F9A38E.6000200@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46F9A38E.6000200@sgi.com> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Virus-Scanned: ClamAV 0.91.2/4402/Tue Sep 25 21:33:35 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13116 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 > This has removed all use of xfs_freeze, but I cant see a diff > hunk that removes the xfs_freeze implementation from xfs_vfsops.c Looks like that hunk got lost in a merge. Here's an updated version of the patch that actually removes xfs_freeze: Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_super.c 2007-09-25 15:04:01.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c 2007-09-26 10:13:54.000000000 +0200 @@ -41,6 +41,7 @@ #include "xfs_rtalloc.h" #include "xfs_error.h" #include "xfs_itable.h" +#include "xfs_fsops.h" #include "xfs_rw.h" #include "xfs_acl.h" #include "xfs_attr.h" @@ -684,11 +685,19 @@ xfs_fs_remount( return -error; } +/* + * Second stage of a freeze. The data is already frozen so we only + * need to take care of themetadata. Once that's done write a dummy + * record to dirty the log in case of a crash while frozen. + */ STATIC void xfs_fs_lockfs( struct super_block *sb) { - xfs_freeze(XFS_M(sb)); + struct xfs_mount *mp = XFS_M(sb); + + xfs_attr_quiesce(mp); + xfs_fs_log_dummy(mp); } STATIC int Index: linux-2.6-xfs/fs/xfs/xfs_vfsops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vfsops.c 2007-09-25 15:04:01.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_vfsops.c 2007-09-26 10:14:07.000000000 +0200 @@ -692,7 +692,7 @@ xfs_quiesce_fs( * care of the metadata. New transactions are already blocked, so we need to * wait for any remaining transactions to drain out before proceding. */ -STATIC void +void xfs_attr_quiesce( xfs_mount_t *mp) { @@ -1955,16 +1955,3 @@ xfs_showargs( seq_puts(m, "," MNTOPT_DMAPI); return 0; } - -/* - * Second stage of a freeze. The data is already frozen so we only - * need to take care of themetadata. Once that's done write a dummy - * record to dirty the log in case of a crash while frozen. - */ -void -xfs_freeze( - xfs_mount_t *mp) -{ - xfs_attr_quiesce(mp); - xfs_fs_log_dummy(mp); -} Index: linux-2.6-xfs/fs/xfs/xfs_vfsops.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vfsops.h 2007-09-25 15:04:01.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_vfsops.h 2007-09-26 10:13:54.000000000 +0200 @@ -21,8 +21,8 @@ int xfs_vget(struct xfs_mount *mp, bhv_v int xfs_parseargs(struct xfs_mount *mp, char *options, struct xfs_mount_args *args, int update); int xfs_showargs(struct xfs_mount *mp, struct seq_file *m); -void xfs_freeze(struct xfs_mount *mp); void xfs_do_force_shutdown(struct xfs_mount *mp, int flags, char *fname, int lnnum); +void xfs_attr_quiesce(struct xfs_mount *mp); #endif /* _XFS_VFSOPS_H */ From owner-xfs@oss.sgi.com Wed Sep 26 01:23:47 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 01:23:51 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) 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.3.0-r574664 Received: from stlx01.stz-softwaretechnik.com (stz-softwaretechnik.de [217.160.223.211]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8Q8NhxE030877 for ; Wed, 26 Sep 2007 01:23:46 -0700 Received: from rg by stlx01.stz-softwaretechnik.com with local (Exim 3.36 #1 (Debian)) id 1IaSBA-0004oo-00 for ; Wed, 26 Sep 2007 10:23:32 +0200 Date: Wed, 26 Sep 2007 10:23:22 +0200 From: Ralf Gross To: linux-xfs@oss.sgi.com Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) Message-ID: <20070926082322.GA30287@p15145560.pureserver.info> References: <498689.78850.qm@web32907.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV 0.91.2/4402/Tue Sep 25 21:33:35 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13115 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Ralf-Lists@ralfgross.de Precedence: bulk X-list: xfs Justin Piszcz schrieb: > > > On Tue, 25 Sep 2007, Bryan J. Smith wrote: > > >Justin Piszcz wrote: > >>Just out of curisosity have you tried SW RAID5 on this array? > >>Also what do you get if you use RAID0 (hw or sw)? > > > >According to him, if I read it correclty, it is an external FC RAID-5 > >chassis. I.e., all of the logic is in the chassis. So your question > >is N/A. > > > >Although I'm more than ready to be proven incorrect. > > > >Furthermore, what benchmark do you use? If dd on the volume itself, > >software RAID wins, hands down. Doesn't matter what size you give > >it, it literally copies (and doesn't recalculate) the parity. It's > >the rawest form of non-blocking I/O, and uses virtually no system > >interconnect to the CPU (just pushes disk-mem-disk). > > bonnie++, iozone, etc.. > > all show ~430-460 MiB/s write and ~550 MiB/s read I'm happy :) I was able to boost the read performance by setting blockdev --setra 16384 /dev/sdc I knew this parameter is neccessary for 3ware controllers, but I haven't noticed any difference with areca controllers or ext. raids yet. The write performance may not be ideal, but these read numbers makes much more sense now because the FC controller is the limiting factor. Sequential Reads File Blk Num Avg Maximum Lat% Lat% CPU Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- 20000 4096 1 391.20 50.24% 0.019 43.01 0.00000 0.00000 779 20000 4096 2 387.79 92.22% 0.040 278.71 0.00000 0.00000 420 Random Reads File Blk Num Avg Maximum Lat% Lat% CPU Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- 20000 4096 1 2.87 0.698% 2.720 27.47 0.00000 0.00000 411 20000 4096 2 4.37 2.013% 3.473 47.35 0.00000 0.00000 217 Sequential Writes File Blk Num Avg Maximum Lat% Lat% CPU Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- 20000 4096 1 189.23 42.73% 0.029 5670.66 0.00014 0.00000 443 20000 4096 2 173.92 84.93% 0.064 4590.56 0.00029 0.00000 205 Random Writes File Blk Num Avg Maximum Lat% Lat% CPU Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- 20000 4096 1 1.85 0.662% 0.011 0.05 0.00000 0.00000 279 20000 4096 2 1.68 0.772% 0.012 0.05 0.00000 0.00000 217 Ralf From owner-xfs@oss.sgi.com Wed Sep 26 01:26:31 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 01:26:34 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) 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.3.0-r574664 Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8Q8QRbo032044 for ; Wed, 26 Sep 2007 01:26:31 -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 l8Q8QPA5000381 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 26 Sep 2007 10:26:25 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8Q8QPWg000379; Wed, 26 Sep 2007 10:26:25 +0200 Date: Wed, 26 Sep 2007 10:26:25 +0200 From: Christoph Hellwig To: Timothy Shimmin Cc: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: [PATCH 2/2] kill xfs_statvfs Message-ID: <20070926082625.GB32719@lst.de> References: <20070925194741.GB1818@lst.de> <46F9C09B.1060503@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46F9C09B.1060503@sgi.com> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Virus-Scanned: ClamAV 0.91.2/4402/Tue Sep 25 21:33:35 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13118 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 Wed, Sep 26, 2007 at 12:14:51PM +1000, Timothy Shimmin wrote: > I think I'd prefer: > > + XFS_QM_DQSTATVFS(XFS_I(dentry->d_inode), statp); > instead of: > > + XFS_QM_DQSTATVFS(xfs_vtoi(dentry->d_inode), statp); > > which I found confusing. I agree, here's an updated version: Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_super.c 2007-09-26 10:13:54.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c 2007-09-26 10:23:38.000000000 +0200 @@ -664,8 +664,44 @@ xfs_fs_statfs( struct dentry *dentry, struct kstatfs *statp) { - return -xfs_statvfs(XFS_M(dentry->d_sb), statp, - vn_from_inode(dentry->d_inode)); + struct xfs_mount *mp = XFS_M(dentry->d_sb); + xfs_sb_t *sbp = &mp->m_sb; + __uint64_t fakeinos, id; + xfs_extlen_t lsize; + + statp->f_type = XFS_SB_MAGIC; + statp->f_namelen = MAXNAMELEN - 1; + + id = huge_encode_dev(mp->m_ddev_targp->bt_dev); + statp->f_fsid.val[0] = (u32)id; + statp->f_fsid.val[1] = (u32)(id >> 32); + + xfs_icsb_sync_counters_flags(mp, XFS_ICSB_LAZY_COUNT); + + spin_lock(&mp->m_sb_lock); + statp->f_bsize = sbp->sb_blocksize; + lsize = sbp->sb_logstart ? sbp->sb_logblocks : 0; + statp->f_blocks = sbp->sb_dblocks - lsize; + statp->f_bfree = statp->f_bavail = + sbp->sb_fdblocks - XFS_ALLOC_SET_ASIDE(mp); + fakeinos = statp->f_bfree << sbp->sb_inopblog; +#if XFS_BIG_INUMS + fakeinos += mp->m_inoadd; +#endif + statp->f_files = + MIN(sbp->sb_icount + fakeinos, (__uint64_t)XFS_MAXINUMBER); + if (mp->m_maxicount) +#if XFS_BIG_INUMS + if (!mp->m_inoadd) +#endif + statp->f_files = min_t(typeof(statp->f_files), + statp->f_files, + mp->m_maxicount); + statp->f_ffree = statp->f_files - (sbp->sb_icount - sbp->sb_ifree); + spin_unlock(&mp->m_sb_lock); + + XFS_QM_DQSTATVFS(XFS_I(dentry->d_inode), statp); + return 0; } STATIC int @@ -768,7 +804,6 @@ xfs_fs_fill_super( struct inode *rootvp; struct xfs_mount *mp = NULL; struct xfs_mount_args *args = xfs_args_allocate(sb, silent); - struct kstatfs statvfs; int error; mp = xfs_mount_init(); @@ -796,14 +831,10 @@ xfs_fs_fill_super( if (error) goto fail_vfsop; - error = xfs_statvfs(mp, &statvfs, NULL); - if (error) - goto fail_unmount; - sb->s_dirt = 1; - sb->s_magic = statvfs.f_type; - sb->s_blocksize = statvfs.f_bsize; - sb->s_blocksize_bits = ffs(statvfs.f_bsize) - 1; + sb->s_magic = XFS_SB_MAGIC; + sb->s_blocksize = mp->m_sb.sb_blocksize; + sb->s_blocksize_bits = ffs(sb->s_blocksize) - 1; sb->s_maxbytes = xfs_max_file_offset(sb->s_blocksize_bits); sb->s_time_gran = 1; set_posix_acl_flag(sb); Index: linux-2.6-xfs/fs/xfs/xfs_vfsops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vfsops.c 2007-09-26 10:14:07.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_vfsops.c 2007-09-26 10:22:32.000000000 +0200 @@ -839,59 +839,6 @@ xfs_root( } /* - * xfs_statvfs - * - * Fill in the statvfs structure for the given file system. We use - * the superblock lock in the mount structure to ensure a consistent - * snapshot of the counters returned. - */ -int -xfs_statvfs( - xfs_mount_t *mp, - bhv_statvfs_t *statp, - bhv_vnode_t *vp) -{ - __uint64_t fakeinos; - xfs_extlen_t lsize; - xfs_sb_t *sbp; - - sbp = &(mp->m_sb); - - statp->f_type = XFS_SB_MAGIC; - - xfs_icsb_sync_counters_flags(mp, XFS_ICSB_LAZY_COUNT); - spin_lock(&mp->m_sb_lock); - statp->f_bsize = sbp->sb_blocksize; - lsize = sbp->sb_logstart ? sbp->sb_logblocks : 0; - statp->f_blocks = sbp->sb_dblocks - lsize; - statp->f_bfree = statp->f_bavail = - sbp->sb_fdblocks - XFS_ALLOC_SET_ASIDE(mp); - fakeinos = statp->f_bfree << sbp->sb_inopblog; -#if XFS_BIG_INUMS - fakeinos += mp->m_inoadd; -#endif - statp->f_files = - MIN(sbp->sb_icount + fakeinos, (__uint64_t)XFS_MAXINUMBER); - if (mp->m_maxicount) -#if XFS_BIG_INUMS - if (!mp->m_inoadd) -#endif - statp->f_files = min_t(typeof(statp->f_files), - statp->f_files, - mp->m_maxicount); - statp->f_ffree = statp->f_files - (sbp->sb_icount - sbp->sb_ifree); - spin_unlock(&mp->m_sb_lock); - - xfs_statvfs_fsid(statp, mp); - statp->f_namelen = MAXNAMELEN - 1; - - if (vp) - XFS_QM_DQSTATVFS(xfs_vtoi(vp), statp); - return 0; -} - - -/* * xfs_sync flushes any pending I/O to file system vfsp. * * This routine is called by vfs_sync() to make sure that things make it Index: linux-2.6-xfs/fs/xfs/xfs_vfsops.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vfsops.h 2007-09-26 10:13:54.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_vfsops.h 2007-09-26 10:22:32.000000000 +0200 @@ -14,8 +14,6 @@ int xfs_unmount(struct xfs_mount *mp, in int xfs_mntupdate(struct xfs_mount *mp, int *flags, struct xfs_mount_args *args); int xfs_root(struct xfs_mount *mp, bhv_vnode_t **vpp); -int xfs_statvfs(struct xfs_mount *mp, struct kstatfs *statp, - bhv_vnode_t *vp); int xfs_sync(struct xfs_mount *mp, int flags); int xfs_vget(struct xfs_mount *mp, bhv_vnode_t **vpp, struct xfs_fid *xfid); int xfs_parseargs(struct xfs_mount *mp, char *options, 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-26 10:13:54.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_linux.h 2007-09-26 10:22:32.000000000 +0200 @@ -212,10 +212,6 @@ #define xfs_stack_trace() dump_stack() #define xfs_itruncate_data(ip, off) \ (-vmtruncate(vn_to_inode(XFS_ITOV(ip)), (off))) -#define xfs_statvfs_fsid(statp, mp) \ - ({ u64 id = huge_encode_dev((mp)->m_ddev_targp->bt_dev); \ - __kernel_fsid_t *fsid = &(statp)->f_fsid; \ - (fsid->val[0] = (u32)id, fsid->val[1] = (u32)(id >> 32)); }) /* Move the kernel do_div definition off to one side */ From owner-xfs@oss.sgi.com Wed Sep 26 01:26:24 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 01:26:29 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) 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.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l8Q8QKSU032022 for ; Wed, 26 Sep 2007 01:26: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 SAA24969; Wed, 26 Sep 2007 18:26:15 +1000 From: donaldd@sgi.com Received: by linuxbuild.melbourne.sgi.com (Postfix, from userid 16365) id D92CE300F406; Wed, 26 Sep 2007 18:26:14 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 971050 - Remove linux-2.4 build support Message-Id: <20070926082614.D92CE300F406@linuxbuild.melbourne.sgi.com> Date: Wed, 26 Sep 2007 18:26:14 +1000 (EST) X-Virus-Scanned: ClamAV 0.91.2/4402/Tue Sep 25 21:33:35 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13117 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 Remove fs/xfs/linux-2.4 as building for 2.4 kernels is no longer supported from this tree Date: Wed Sep 26 18:24:41 AEST 2007 Workarea: linuxbuild.melbourne.sgi.com:/home/donaldd/isms/2.6.x-xfs Inspected by: tes The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29785a fs/xfs/linux-2.4/xfs_lrw.h - 1.51 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_lrw.h.diff?r1=text&tr1=1.51&r2=text&tr2=1.50&f=h fs/xfs/linux-2.4/xfs_lrw.c - 1.240 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_lrw.c.diff?r1=text&tr1=1.240&r2=text&tr2=1.239&f=h fs/xfs/linux-2.4/xfs_version.h - 1.173 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_version.h.diff?r1=text&tr1=1.173&r2=text&tr2=1.172&f=h fs/xfs/linux-2.4/xfs_ioctl.c - 1.136 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ioctl.c.diff?r1=text&tr1=1.136&r2=text&tr2=1.135&f=h fs/xfs/linux-2.4/xfs_vfs.h - 1.67 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_vfs.h.diff?r1=text&tr1=1.67&r2=text&tr2=1.66&f=h fs/xfs/linux-2.4/xfs_vfs.c - 1.68 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_vfs.c.diff?r1=text&tr1=1.68&r2=text&tr2=1.67&f=h fs/xfs/linux-2.4/xfs_globals.h - 1.25 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_globals.h.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h fs/xfs/linux-2.4/xfs_globals.c - 1.79 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_globals.c.diff?r1=text&tr1=1.79&r2=text&tr2=1.78&f=h fs/xfs/linux-2.4/xfs_linux.h - 1.164 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_linux.h.diff?r1=text&tr1=1.164&r2=text&tr2=1.163&f=h fs/xfs/linux-2.4/Makefile - 1.211 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/Makefile.diff?r1=text&tr1=1.211&r2=text&tr2=1.210&f=h fs/xfs/linux-2.4/xfs_file.c - 1.131 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_file.c.diff?r1=text&tr1=1.131&r2=text&tr2=1.130&f=h fs/xfs/linux-2.4/xfs_cred.h - 1.28 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_cred.h.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h fs/xfs/linux-2.4/xfs_vnode.c - 1.140 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_vnode.c.diff?r1=text&tr1=1.140&r2=text&tr2=1.139&f=h fs/xfs/linux-2.4/xfs_vnode.h - 1.116 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_vnode.h.diff?r1=text&tr1=1.116&r2=text&tr2=1.115&f=h fs/xfs/linux-2.4/xfs_stats.c - 1.23 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_stats.c.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h fs/xfs/linux-2.4/xfs_stats.h - 1.16 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_stats.h.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h fs/xfs/linux-2.4/xfs_fs_subr.c - 1.50 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_fs_subr.c.diff?r1=text&tr1=1.50&r2=text&tr2=1.49&f=h fs/xfs/linux-2.4/xfs_fs_subr.h - 1.19 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_fs_subr.h.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h fs/xfs/linux-2.4/xfs_super.h - 1.74 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_super.h.diff?r1=text&tr1=1.74&r2=text&tr2=1.73&f=h fs/xfs/linux-2.4/xfs_super.c - 1.338 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_super.c.diff?r1=text&tr1=1.338&r2=text&tr2=1.337&f=h fs/xfs/linux-2.4/xfs_iops.c - 1.230 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_iops.c.diff?r1=text&tr1=1.230&r2=text&tr2=1.229&f=h fs/xfs/linux-2.4/xfs_iops.h - 1.33 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_iops.h.diff?r1=text&tr1=1.33&r2=text&tr2=1.32&f=h fs/xfs/linux-2.4/xfs_aops.c - 1.106 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_aops.c.diff?r1=text&tr1=1.106&r2=text&tr2=1.105&f=h fs/xfs/linux-2.4/xfs_sysctl.c - 1.42 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_sysctl.c.diff?r1=text&tr1=1.42&r2=text&tr2=1.41&f=h fs/xfs/linux-2.4/xfs_sysctl.h - 1.32 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_sysctl.h.diff?r1=text&tr1=1.32&r2=text&tr2=1.31&f=h fs/xfs/linux-2.4/xfs_buf.h - 1.119 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_buf.h.diff?r1=text&tr1=1.119&r2=text&tr2=1.118&f=h fs/xfs/linux-2.4/xfs_buf.c - 1.220 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_buf.c.diff?r1=text&tr1=1.220&r2=text&tr2=1.219&f=h fs/xfs/linux-2.4/kmem.h - 1.35 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/kmem.h.diff?r1=text&tr1=1.35&r2=text&tr2=1.34&f=h fs/xfs/linux-2.4/kmem.c - 1.39 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/kmem.c.diff?r1=text&tr1=1.39&r2=text&tr2=1.38&f=h fs/xfs/linux-2.4/xfs_ksyms.c - 1.50 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ksyms.c.diff?r1=text&tr1=1.50&r2=text&tr2=1.49&f=h fs/xfs/linux-2.4/sema.h - 1.17 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/sema.h.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h fs/xfs/linux-2.4/mrlock.c - 1.24 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/mrlock.c.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h fs/xfs/linux-2.4/mrlock.h - 1.17 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/mrlock.h.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h fs/xfs/linux-2.4/time.h - 1.19 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/time.h.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h fs/xfs/linux-2.4/sv.h - 1.20 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/sv.h.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h fs/xfs/linux-2.4/spin.h - 1.24 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/spin.h.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h fs/xfs/linux-2.4/mutex.h - 1.19 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/mutex.h.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h fs/xfs/linux-2.4/mrlock_rwsem.h - 1.5 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/mrlock_rwsem.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h fs/xfs/linux-2.4/xfs_export.h - 1.3 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_export.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/xfs/linux-2.4/xfs_ioctl32.h - 1.3 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ioctl32.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/xfs/linux-2.4/xfs_ioctl32.c - 1.3 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ioctl32.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/xfs/linux-2.4/xfs_dmapi_priv.h - 1.2 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_dmapi_priv.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h From owner-xfs@oss.sgi.com Wed Sep 26 01:34:22 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 01:34:32 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) 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.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l8Q8YHwv001430 for ; Wed, 26 Sep 2007 01:34:19 -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 SAA25283 for ; Wed, 26 Sep 2007 18:34:16 +1000 From: donaldd@sgi.com Received: by linuxbuild.melbourne.sgi.com (Postfix, from userid 16365) id C441A30A90AD; Wed, 26 Sep 2007 18:34:16 +1000 (EST) To: xfs@oss.sgi.com Subject: PARTIAL TAKE 971050 - Remove linux-2.4 build support Message-Id: <20070926083416.C441A30A90AD@linuxbuild.melbourne.sgi.com> Date: Wed, 26 Sep 2007 18:34:16 +1000 (EST) X-Virus-Scanned: ClamAV 0.91.2/4402/Tue Sep 25 21:33:35 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13119 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 Remove Makefile wrappers in XFS Makefile (and Kbuild) would include Makefile-linux-26 I doubt XFS will really still compile on 2.4; so drop that. This moves Makefile-linux-26 into Makefile and drops Kbuild. Also having wrappers as both Kbuild and Makefile seemed redundant anyways. The patch is relatively large because it renames a file, but no functional changes. Signed-off-by: Andi Kleen Date: Wed Sep 26 14:12:23 AEST 2007 Workarea: linuxbuild.melbourne.sgi.com:/home/donaldd/isms/2.6.x-xfs Inspected by: tes The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29781a fs/xfs/Makefile - 1.59 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/Makefile.diff?r1=text&tr1=1.59&r2=text&tr2=1.58&f=h - Remove Makefile wrappers in XFS. fs/xfs/Makefile-linux-2.6 - 1.215 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/Makefile-linux-2.6.diff?r1=text&tr1=1.215&r2=text&tr2=1.214&f=h - Remove Makefile wrappers in XFS. fs/xfs/Makefile-linux-2.4 - 1.218 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/Makefile-linux-2.4.diff?r1=text&tr1=1.218&r2=text&tr2=1.217&f=h - Remove Makefile wrappers in XFS. fs/xfs/Kbuild - 1.3 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/Kbuild.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h - Remove Makefile wrappers in XFS. From owner-xfs@oss.sgi.com Wed Sep 26 01:42:28 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 01:42:34 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8Q8gMaX003086 for ; Wed, 26 Sep 2007 01:42:28 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 62E291C000260; Wed, 26 Sep 2007 04:42:22 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 617124019B78; Wed, 26 Sep 2007 04:42:22 -0400 (EDT) Date: Wed, 26 Sep 2007 04:42:22 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Ralf Gross cc: linux-xfs@oss.sgi.com Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) In-Reply-To: <20070926082322.GA30287@p15145560.pureserver.info> Message-ID: References: <498689.78850.qm@web32907.mail.mud.yahoo.com> <20070926082322.GA30287@p15145560.pureserver.info> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/4403/Wed Sep 26 00:09:09 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13120 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 Wed, 26 Sep 2007, Ralf Gross wrote: > Justin Piszcz schrieb: >> >> >> On Tue, 25 Sep 2007, Bryan J. Smith wrote: >> >>> Justin Piszcz wrote: >>>> Just out of curisosity have you tried SW RAID5 on this array? >>>> Also what do you get if you use RAID0 (hw or sw)? >>> >>> According to him, if I read it correclty, it is an external FC RAID-5 >>> chassis. I.e., all of the logic is in the chassis. So your question >>> is N/A. >>> >>> Although I'm more than ready to be proven incorrect. >>> >>> Furthermore, what benchmark do you use? If dd on the volume itself, >>> software RAID wins, hands down. Doesn't matter what size you give >>> it, it literally copies (and doesn't recalculate) the parity. It's >>> the rawest form of non-blocking I/O, and uses virtually no system >>> interconnect to the CPU (just pushes disk-mem-disk). >> >> bonnie++, iozone, etc.. >> >> all show ~430-460 MiB/s write and ~550 MiB/s read > > I'm happy :) I was able to boost the read performance by setting > > blockdev --setra 16384 /dev/sdc > > I knew this parameter is neccessary for 3ware controllers, but I > haven't noticed any difference with areca controllers or ext. raids yet. > > The write performance may not be ideal, but these read numbers makes much > more sense now because the FC controller is the limiting factor. > > Sequential Reads > File Blk Num Avg Maximum Lat% Lat% CPU > Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff > ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- > 20000 4096 1 391.20 50.24% 0.019 43.01 0.00000 0.00000 779 > 20000 4096 2 387.79 92.22% 0.040 278.71 0.00000 0.00000 420 > > Random Reads > File Blk Num Avg Maximum Lat% Lat% CPU > Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff > ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- > 20000 4096 1 2.87 0.698% 2.720 27.47 0.00000 0.00000 411 > 20000 4096 2 4.37 2.013% 3.473 47.35 0.00000 0.00000 217 > > Sequential Writes > File Blk Num Avg Maximum Lat% Lat% CPU > Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff > ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- > 20000 4096 1 189.23 42.73% 0.029 5670.66 0.00014 0.00000 443 > 20000 4096 2 173.92 84.93% 0.064 4590.56 0.00029 0.00000 205 > > Random Writes > File Blk Num Avg Maximum Lat% Lat% CPU > Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff > ----- ----- --- ------ ------ --------- ----------- -------- -------- ----- > 20000 4096 1 1.85 0.662% 0.011 0.05 0.00000 0.00000 279 > 20000 4096 2 1.68 0.772% 0.012 0.05 0.00000 0.00000 217 > > > > > Ralf > > What was the command line you used for that output? tiobench.. ? Justin. From owner-xfs@oss.sgi.com Wed Sep 26 01:49:48 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 01:49:52 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) 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.3.0-r574664 Received: from stlx01.stz-softwaretechnik.com (stz-softwaretechnik.de [217.160.223.211]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8Q8njOl004314 for ; Wed, 26 Sep 2007 01:49:48 -0700 Received: from rg by stlx01.stz-softwaretechnik.com with local (Exim 3.36 #1 (Debian)) id 1IaSaN-0005sv-00 for ; Wed, 26 Sep 2007 10:49:35 +0200 Date: Wed, 26 Sep 2007 10:49:25 +0200 From: Ralf Gross To: linux-xfs@oss.sgi.com Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) Message-ID: <20070926084924.GB30287@p15145560.pureserver.info> References: <498689.78850.qm@web32907.mail.mud.yahoo.com> <20070926082322.GA30287@p15145560.pureserver.info> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV 0.91.2/4403/Wed Sep 26 00:09:09 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13121 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Ralf-Lists@ralfgross.de Precedence: bulk X-list: xfs Justin Piszcz schrieb: > What was the command line you used for that output? > tiobench.. ? tiobench --numruns 3 --threads 1 --threads 2 --block 4096 --size 20000 --size 20000 because the server has 16 GB RAM. Ralf From owner-xfs@oss.sgi.com Wed Sep 26 02:52:42 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 02:52:46 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8Q9qeZr014242 for ; Wed, 26 Sep 2007 02:52:42 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 12F1B1C000260; Wed, 26 Sep 2007 05:52:40 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 0E5B64019B78; Wed, 26 Sep 2007 05:52:40 -0400 (EDT) Date: Wed, 26 Sep 2007 05:52:39 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Ralf Gross cc: linux-xfs@oss.sgi.com, linux-raid@vger.kernel.org Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) In-Reply-To: <20070926084924.GB30287@p15145560.pureserver.info> Message-ID: References: <498689.78850.qm@web32907.mail.mud.yahoo.com> <20070926082322.GA30287@p15145560.pureserver.info> <20070926084924.GB30287@p15145560.pureserver.info> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/4403/Wed Sep 26 00:09:09 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13122 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 Wed, 26 Sep 2007, Ralf Gross wrote: > Justin Piszcz schrieb: >> What was the command line you used for that output? >> tiobench.. ? > > tiobench --numruns 3 --threads 1 --threads 2 --block 4096 --size 20000 > > --size 20000 because the server has 16 GB RAM. > > Ralf > > Here is my output on my SW RAID5 keep in mind it is currently being used so the numbers are a little slower than they probably should be: My machine only has 8 GiB of memory but I used the same command you did: This is with the 2.6.22.6 kernel, the 2.6.23-rcX/final when released is supposed to have the SW RAID5 accelerator code, correct? Unit information ================ File size = megabytes Blk Size = bytes Rate = megabytes per second CPU% = percentage of CPU used during the test Latency = milliseconds Lat% = percent of requests that took longer than X seconds CPU Eff = Rate divided by CPU% - throughput per cpu load Sequential Reads File Blk Num Avg Maximum Lat% Lat% CPU Identifier Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff ---------------------------- ------ ----- --- ------ ------ --------- ----------- -------- -------- ----- 2.6.22.6 20000 4096 1 523.01 45.79% 0.022 510.77 0.00000 0.00000 1142 2.6.22.6 20000 4096 2 501.29 85.84% 0.046 855.59 0.00000 0.00000 584 Random Reads File Blk Num Avg Maximum Lat% Lat% CPU Identifier Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff ---------------------------- ------ ----- --- ------ ------ --------- ----------- -------- -------- ----- 2.6.22.6 20000 4096 1 0.90 0.276% 13.003 74.41 0.00000 0.00000 326 2.6.22.6 20000 4096 2 1.61 1.167% 14.443 126.43 0.00000 0.00000 137 Sequential Writes File Blk Num Avg Maximum Lat% Lat% CPU Identifier Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff ---------------------------- ------ ----- --- ------ ------ --------- ----------- -------- -------- ----- 2.6.22.6 20000 4096 1 363.46 75.72% 0.030 2757.45 0.00000 0.00000 480 2.6.22.6 20000 4096 2 394.45 287.9% 0.056 2798.92 0.00000 0.00000 137 Random Writes File Blk Num Avg Maximum Lat% Lat% CPU Identifier Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff ---------------------------- ------ ----- --- ------ ------ --------- ----------- -------- -------- ----- 2.6.22.6 20000 4096 1 3.16 1.752% 0.011 1.02 0.00000 0.00000 180 2.6.22.6 20000 4096 2 3.07 3.769% 0.013 0.10 0.00000 0.00000 82 From owner-xfs@oss.sgi.com Wed Sep 26 05:25:15 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 05:25:23 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8QCPCdR008557 for ; Wed, 26 Sep 2007 05:25:14 -0700 Received: from liberator.sandeen.net (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 CC9DD18011E9B; Wed, 26 Sep 2007 07:25:10 -0500 (CDT) Message-ID: <46FA4FA5.5040405@sandeen.net> Date: Wed, 26 Sep 2007 07:25:09 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: donaldd@sgi.com CC: xfs@oss.sgi.com Subject: Re: PARTIAL TAKE 971050 - Remove linux-2.4 build support References: <20070926082614.D92CE300F406@linuxbuild.melbourne.sgi.com> In-Reply-To: <20070926082614.D92CE300F406@linuxbuild.melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4403/Wed Sep 26 00:09:09 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13123 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 donaldd@sgi.com wrote: > Remove fs/xfs/linux-2.4 as building for 2.4 kernels is no longer supported from this tree > > Date: Wed Sep 26 18:24:41 AEST 2007 > Workarea: linuxbuild.melbourne.sgi.com:/home/donaldd/isms/2.6.x-xfs > Inspected by: tes > > The following file(s) were checked into: > longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb > Yay! :) So, what's to be done about xfs_refcache.c... right now it's 2.4-only, but i'm not convinced that there is similar generic nfs functionality in 2.6, anyone know for sure? -Eric From owner-xfs@oss.sgi.com Wed Sep 26 05:57:02 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 05:57:07 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) 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.3.0-r574664 Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8QCv0q5013139 for ; Wed, 26 Sep 2007 05:57:02 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1IaW0c-0004RJ-MX; Wed, 26 Sep 2007 13:28:54 +0100 Date: Wed, 26 Sep 2007 13:28:54 +0100 From: Christoph Hellwig To: Eric Sandeen Cc: donaldd@sgi.com, xfs@oss.sgi.com Subject: Re: PARTIAL TAKE 971050 - Remove linux-2.4 build support Message-ID: <20070926122854.GA17050@infradead.org> References: <20070926082614.D92CE300F406@linuxbuild.melbourne.sgi.com> <46FA4FA5.5040405@sandeen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46FA4FA5.5040405@sandeen.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-Virus-Scanned: ClamAV 0.91.2/4403/Wed Sep 26 00:09:09 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13124 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 26, 2007 at 07:25:09AM -0500, Eric Sandeen wrote: > So, what's to be done about xfs_refcache.c... right now it's 2.4-only, > but i'm not convinced that there is similar generic nfs functionality in > 2.6, anyone know for sure? We keep the inodes around through nfsd, yes. There's a slight problem with ->release beeing called to early, but Greg is working on fixing that using an open files cache in nfsd. From owner-xfs@oss.sgi.com Wed Sep 26 07:54:40 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 07:54:45 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) 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.3.0-r574664 Received: from stlx01.stz-softwaretechnik.com (stz-softwaretechnik.de [217.160.223.211]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8QEsc1K029831 for ; Wed, 26 Sep 2007 07:54:39 -0700 Received: from rg by stlx01.stz-softwaretechnik.com with local (Exim 3.36 #1 (Debian)) id 1IaYHT-00085c-00 for ; Wed, 26 Sep 2007 16:54:27 +0200 Date: Wed, 26 Sep 2007 16:54:17 +0200 From: Ralf Gross To: linux-xfs@oss.sgi.com Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) Message-ID: <20070926145417.GC30287@p15145560.pureserver.info> References: <20070923093841.GH19983@p15145560.pureserver.info> <18166.25242.174049.175729@base.ty.sabi.co.UK> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18166.25242.174049.175729@base.ty.sabi.co.UK> User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV 0.91.2/4404/Wed Sep 26 05:53:15 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13125 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Ralf-Lists@ralfgross.de Precedence: bulk X-list: xfs Peter Grandi schrieb: > Ralf> Hi, we have a new large raid array, the shelf has 48 disks, > Ralf> the max. amount of disks in a single raid 5 set is 16. > > Too bad about that petty limitation ;-). Yeah, I prefer 24x RAID 5 without spare. Why waste so much space ;) After talking to the people that own the data and wanted to use as much as possible space of the device, we'll start with four 12/11 disk RAID 6 volumes (47 disk + 1 spare). That's ~12% less space than before with five RAID 5 volumes. I think this is a good compromise between safety and max. usable disk space. There's only one point left: will the RAID 6 during a rebuild be able to deliver 2-3 streams of 17MB/s. Write performance is not the point then, but the clients will be running simulations for up to 5 days and need this (more or less) constant data rate. Now that I'm getting ~400 MB/s (which is limited by the FC controller) this should be possible. > Ralf> There will be one global spare disk, thus we have two raid 5 > Ralf> with 15 data disks and one with 14 data disk. > > Ahhh a positive-thinking, can-do, brave design ;-). We have a 60 slot tape lib too (well, we'll have next week...I hope). I know that raid != backup. > [ ... ] > Ralf> Each client then needs a data stream of about 17 MB/s > Ralf> (max. 5 clients are expected to acces the data in parallel). > > Do the requirements include as features some (possibly several) > hours of ''challenging'' read performance if any disk fails or > total loss of data if another disks fails during that time? ;-) The data then is still on USB disks and on tape. Maybe I'll pull out a disk of one of the new RAID 6 volumes and see how much the read performance drops. At the moment only one test bed is active, thus 17 MB/s would be ok. Later with 5 test beds 5 x 17 MB/s are needed (if they are online at the same time). > IIRC Google have reported 5% per year disk failure rates across a > very wide mostly uncorrelated population, you have 48 disks, > perhaps 2-3 disks per year will fail. Perhaps more and more often, > because they will likely be all from the same manufacturer, model, > batch and spinning in the same environment. Hey, these are ENTERPRISE disks ;) As far as I know, we couldn't even use other disks than the ones that the manufacturer provides (modified firmware?). > Ralf> [ ... ] I expect the fs, each will have a size of 10-11 TB, > Ralf> to be filled > 90%. I know this is not ideal, but we need > Ralf> every GB we can get. > > That "every GB we can get" is often the key in ''wide RAID5'' > stories. Cheap as well as fast and safe, you can have it all with > wide RAID5 setups, so the salesmen would say ;-). I think we now have found a reasonable solution. > Ralf> [ ... ] Stripe Size : 960 KB (15 x 64 KM) > Ralf> [ ... ] Stripe Size : 896 KB (14 x 64 KB) > > Pretty long stripes, I wonder what happens when a whole stripe > cannot be written at once or it can but is not naturally aligned > ;-). I'm still confused bye the chunk/stripe and block size values. The block size of the HW-RAID is fixed to 512 bytes, I think that a bit small. Also, I first thought about wasting disk space with larger chunk/stripe sizes (HW RAID), but as the OS/FS doesn't necessarily know about the values, it can't be true - unlike the FS block size which defines the smallest possible file size. > Ralf> [ ... ] about 150 MB/s in seq. writing > > Surprise surprise ;-). > > Ralf> (tiobench) and 160 MB/s in seq. reading. > > This is sort of low. If there something that RAID5 can do sort of > OK is reads (if there are no faults). I'd look at the underlying > storage system and the maximum performance that you can get out of > a single disk. /sbin/blockdev --setra 16384 /dev/sdc was the key to ~400 MB/s read performance. > I have seen a 45-drive 500GB storage subsystem where each drive > can deliver at most 7-10MB/s (even if the same disk standalone in > an ordinary PC can do 60-70MB/s), and the supplier actually claims > so in their published literature (that RAID product is meant to > compete *only* with tape backup subsystems). Your later comment > that "The raid array is connect to the server by fibre channel" > makes me suspect that it may be the same brand. > > Ralf> This is ok, > > As the total aggregate requirement is 5x17MB/s this is probably > the case [as long as there are no drive failures ;-)]. > > Ralf> but I'm curious what I could get with tuned xfs parameters. > > Looking at the archives of this mailing list the topic ''good mkfs > parameters'' reappears frequently, even if usually for smaller > arrays, as many have yet to discover the benefits of 15-wide RAID5 > setups ;-). Threads like these may help: > > http://OSS.SGI.com/archives/xfs/2007-01/msg00079.html > http://OSS.SGI.com/archives/xfs/2007-05/msg00051.html I've seen some of JP's postings before. I couldn't get much more performace with the sw/su options, I got the best results with the default values. But I haven't tried external logs yet. Ralf From owner-xfs@oss.sgi.com Wed Sep 26 08:00:17 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 08:00:28 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=2.0 required=5.0 tests=BAYES_05,HTML_MESSAGE, J_CHICKENPOX_32 autolearn=no version=3.3.0-r574664 Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.224]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8QF0CHZ031003 for ; Wed, 26 Sep 2007 08:00:17 -0700 Received: by nz-out-0506.google.com with SMTP id x3so1312551nzd for ; Wed, 26 Sep 2007 08:00: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:in-reply-to:mime-version:content-type:references; bh=fzNK7Ei2M9eJXLdc6tUA2M4q5vKlMIcPMv0d0NAWVxE=; b=Ppp5ga/Ae5pdCb+/+x6pBoZlNzdZ1NfLPJz41gUlrYFG7vQ9NgXyiGZXC1ln/DMR7iIqegqu7Gl1O1Dqx8TzkOCy7OOTYOyNhdW+FL8EoDrN3+x71TDFwXnTOObRMFCo6uLsxV0LwWjYUjcU3sJjWn44+ix2RHDVHkgTUEtwEe0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=YEnEollXeoTfwaMckhdPlVVMePGqRZOwqS6N8cjVRt4eBUjNZgshRKPoBZsq6XVUYZIY36G0+O1eaw7zAafpWvogr06kShR4itpDQEku+x3QkQttKRXRX4woZxycdmAXmydnKiAsdYqthqYGUz7zWk2TPhn5Hye4vFPTIuHCyKY= Received: by 10.115.90.1 with SMTP id s1mr970788wal.1190814675915; Wed, 26 Sep 2007 06:51:15 -0700 (PDT) Received: by 10.115.89.6 with HTTP; Wed, 26 Sep 2007 06:51:15 -0700 (PDT) Message-ID: Date: Wed, 26 Sep 2007 19:21:15 +0530 From: "Manoj Kumar Pradhan" To: linux-xfs@oss.sgi.com Subject: XFS DMAPI support for RHEL4 In-Reply-To: MIME-Version: 1.0 References: X-Virus-Scanned: ClamAV 0.91.2/4404/Wed Sep 26 05:53:15 2007 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 816 X-archive-position: 13126 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: manojkp80@gmail.com Precedence: bulk X-list: xfs Hi, I am running RHEL with kernel 2.6.9-42ELsmp x86_64. I got the xfs module from http://sandeen.net/rhel4_xfs/ and did a rpmbuild as instructed there, I got the xfs.ko and the module-xfs rpm for the running kernel too but modinfo shows me that the xfs module hence created is not dmapi enabled. [root@asher RPMS]# modinfo xfs filename: /lib/modules/2.6.9-42.ELsmp/kernel/fs/xfs/xfs.ko license: GPL description: SGI XFS with ACLs, security attributes, realtime, large block/inode numbers, no debug enabled author: Silicon Graphics, Inc. depends: vermagic: 2.6.9-42.ELsmp SMP gcc-3.4 When I run a simple app which tries to init dmapi for XFS it fails with ENOSYS. Did I miss anything here? How do I enable DMAPI on this XFS module? Thanks, Manoj [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Wed Sep 26 08:03:39 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 08:03:49 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.4 required=5.0 tests=AWL,BAYES_00, FROM_EXCESS_BASE64,J_CHICKENPOX_24 autolearn=no version=3.3.0-r574664 Received: from smtp101-mob.biz.mail.re2.yahoo.com (smtp101-mob.biz.mail.re2.yahoo.com [206.190.36.116]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l8QF3aSZ031820 for ; Wed, 26 Sep 2007 08:03:38 -0700 Received: (qmail 34117 invoked from network); 26 Sep 2007 15:03:35 -0000 Received: from unknown (HELO bda202-cell02.bisx.prod.on.blackberry) (thebs413@216.9.248.122 with xymcookie) by smtp101-mob.biz.mail.re2.yahoo.com with SMTP; 26 Sep 2007 15:03:35 -0000 X-YMail-OSG: HAqHlIUVM1kREa5bSXAjmIHJ2OxTgBRLPvVfnrh02P708eLUej8w2al7GreX2pS.aRxo2Pppyhx5f2hJjpBVa_vrWOYcILTon1UAemRvguxqAzCrGQM- X-rim-org-msg-ref-id: 1254510454 Message-ID: <1254510454-1190819012-cardhu_decombobulator_blackberry.rim.net-1744849406-@bxe108.bisx.prod.on.blackberry> Reply-To: b.j.smith@ieee.org X-Priority: Normal References: <498689.78850.qm@web32907.mail.mud.yahoo.com><20070926082322.GA30287@p15145560.pureserver.info><20070926084924.GB30287@p15145560.pureserver.info> In-Reply-To: Sensitivity: Normal Importance: Normal To: "Justin Piszcz" , xfs-bounce@oss.sgi.com, "Ralf Gross" Cc: linux-xfs@oss.sgi.com, linux-raid@vger.kernel.org Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) From: "=?utf-8?B?QnJ5YW4gSiBTbWl0aA==?=" Date: Wed, 26 Sep 2007 15:03:29 +0000 Content-Type: text/plain MIME-Version: 1.0 X-Virus-Scanned: ClamAV 0.91.2/4404/Wed Sep 26 05:53:15 2007 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id l8QF3dSZ031830 X-archive-position: 13127 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: b.j.smith@ieee.org Precedence: bulk X-list: xfs Everyone can play local benchmarking games all they want, and software RAID will almost always be faster, significantly at times. What matters is actual, multiple client performance under full load. Anything less is a completely irrelevant. -- Bryan J Smith - mailto:b.j.smith@ieee.org http://thebs413.blogspot.com Sent via BlackBerry from T-Mobile -----Original Message----- From: Justin Piszcz Date: Wed, 26 Sep 2007 05:52:39 To:Ralf Gross Cc:linux-xfs@oss.sgi.com, linux-raid@vger.kernel.org Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) On Wed, 26 Sep 2007, Ralf Gross wrote: > Justin Piszcz schrieb: >> What was the command line you used for that output? >> tiobench.. ? > > tiobench --numruns 3 --threads 1 --threads 2 --block 4096 --size 20000 > > --size 20000 because the server has 16 GB RAM. > > Ralf > > Here is my output on my SW RAID5 keep in mind it is currently being used so the numbers are a little slower than they probably should be: My machine only has 8 GiB of memory but I used the same command you did: This is with the 2.6.22.6 kernel, the 2.6.23-rcX/final when released is supposed to have the SW RAID5 accelerator code, correct? Unit information ================ File size = megabytes Blk Size = bytes Rate = megabytes per second CPU% = percentage of CPU used during the test Latency = milliseconds Lat% = percent of requests that took longer than X seconds CPU Eff = Rate divided by CPU% - throughput per cpu load Sequential Reads File Blk Num Avg Maximum Lat% Lat% CPU Identifier Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff ---------------------------- ------ ----- --- ------ ------ --------- ----------- -------- -------- ----- 2.6.22.6 20000 4096 1 523.01 45.79% 0.022 510.77 0.00000 0.00000 1142 2.6.22.6 20000 4096 2 501.29 85.84% 0.046 855.59 0.00000 0.00000 584 Random Reads File Blk Num Avg Maximum Lat% Lat% CPU Identifier Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff ---------------------------- ------ ----- --- ------ ------ --------- ----------- -------- -------- ----- 2.6.22.6 20000 4096 1 0.90 0.276% 13.003 74.41 0.00000 0.00000 326 2.6.22.6 20000 4096 2 1.61 1.167% 14.443 126.43 0.00000 0.00000 137 Sequential Writes File Blk Num Avg Maximum Lat% Lat% CPU Identifier Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff ---------------------------- ------ ----- --- ------ ------ --------- ----------- -------- -------- ----- 2.6.22.6 20000 4096 1 363.46 75.72% 0.030 2757.45 0.00000 0.00000 480 2.6.22.6 20000 4096 2 394.45 287.9% 0.056 2798.92 0.00000 0.00000 137 Random Writes File Blk Num Avg Maximum Lat% Lat% CPU Identifier Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff ---------------------------- ------ ----- --- ------ ------ --------- ----------- -------- -------- ----- 2.6.22.6 20000 4096 1 3.16 1.752% 0.011 1.02 0.00000 0.00000 180 2.6.22.6 20000 4096 2 3.07 3.769% 0.013 0.10 0.00000 0.00000 82 From owner-xfs@oss.sgi.com Wed Sep 26 08:06:36 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 08:06:43 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_32, SPF_HELO_PASS autolearn=no version=3.3.0-r574664 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8QF6Y7G032641 for ; Wed, 26 Sep 2007 08:06:36 -0700 Received: from liberator.sandeen.net (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 0F79318011E95; Wed, 26 Sep 2007 10:06:34 -0500 (CDT) Message-ID: <46FA7579.9090403@sandeen.net> Date: Wed, 26 Sep 2007 10:06:33 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Manoj Kumar Pradhan CC: linux-xfs@oss.sgi.com Subject: Re: XFS DMAPI support for RHEL4 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4404/Wed Sep 26 05:53:15 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13128 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 Manoj Kumar Pradhan wrote: > Hi, > > I am running RHEL with kernel 2.6.9-42ELsmp x86_64. I got the xfs module > from http://sandeen.net/rhel4_xfs/ and did a rpmbuild as instructed there, I > got the xfs.ko and the module-xfs rpm for the running kernel too but modinfo > shows me that the xfs module hence created is not dmapi enabled. Right, the dmapi module isn't included in that. As far as I can recall, the necessary bits to support DMAPI are not present in the RHEL4 kernel, so this is probably not going to work. Perhaps the sgi guys can chime in if I'm off base. -Eric > [root@asher RPMS]# modinfo xfs > filename: /lib/modules/2.6.9-42.ELsmp/kernel/fs/xfs/xfs.ko > license: GPL > description: SGI XFS with ACLs, security attributes, realtime, large > block/inode numbers, no debug enabled > author: Silicon Graphics, Inc. > depends: > vermagic: 2.6.9-42.ELsmp SMP gcc-3.4 > > When I run a simple app which tries to init dmapi for XFS it fails with > ENOSYS. > Did I miss anything here? How do I enable DMAPI on this XFS module? > > Thanks, > Manoj > > > [[HTML alternate version deleted]] > > From owner-xfs@oss.sgi.com Wed Sep 26 08:16:01 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 08:16:13 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) 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.3.0-r574664 Received: from stlx01.stz-softwaretechnik.com (stz-softwaretechnik.de [217.160.223.211]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8QFFthI002075 for ; Wed, 26 Sep 2007 08:16:00 -0700 Received: from rg by stlx01.stz-softwaretechnik.com with local (Exim 3.36 #1 (Debian)) id 1IaYc4-0000CC-00 for ; Wed, 26 Sep 2007 17:15:44 +0200 Date: Wed, 26 Sep 2007 17:15:34 +0200 From: Ralf Gross To: linux-xfs@oss.sgi.com Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) Message-ID: <20070926151534.GD30287@p15145560.pureserver.info> References: <1254510454-1190819012-cardhu_decombobulator_blackberry.rim.net-1744849406-@bxe108.bisx.prod.on.blackberry> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1254510454-1190819012-cardhu_decombobulator_blackberry.rim.net-1744849406-@bxe108.bisx.prod.on.blackberry> User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV 0.91.2/4404/Wed Sep 26 05:53:15 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13129 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Ralf-Lists@ralfgross.de Precedence: bulk X-list: xfs Bryan J Smith schrieb: > Everyone can play local benchmarking games all they want, > and software RAID will almost always be faster, significantly at times. > > What matters is actual, multiple client performance under full load. > Anything less is a completely irrelevant. You're right, but these benchmarks help to find simple failures or misconfigurations at an earlier stage of the process. Ralf From owner-xfs@oss.sgi.com Wed Sep 26 08:33:48 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 08:33:53 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_32, T_STOX_BOUND_090909_B autolearn=no version=3.3.0-r574664 Received: from slurp.thebarn.com (cattelan-host202.dsl.visi.com [208.42.117.202]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8QFXlTe008430 for ; Wed, 26 Sep 2007 08:33:48 -0700 Received: from [IPv6:::1] (slurp.thebarn.com [208.42.117.201]) (authenticated bits=0) by slurp.thebarn.com (8.14.0/8.13.8) with ESMTP id l8QFXMaF001216; Wed, 26 Sep 2007 10:33:23 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <46FA7BC2.5050903@thebarn.com> Date: Wed, 26 Sep 2007 10:33:22 -0500 From: Russell Cattelan User-Agent: Thunderbird 2.0.0.5 (X11/20070813) MIME-Version: 1.0 To: Eric Sandeen CC: Manoj Kumar Pradhan , linux-xfs@oss.sgi.com Subject: Re: XFS DMAPI support for RHEL4 References: <46FA7579.9090403@sandeen.net> In-Reply-To: <46FA7579.9090403@sandeen.net> Content-Type: multipart/mixed; boundary="------------040907080408040109000409" X-Virus-Scanned: ClamAV 0.91.2/4404/Wed Sep 26 05:53:15 2007 on oss.sgi.com X-Virus-Scanned: ClamAV 0.91.1/4404/Wed Sep 26 07:53:15 2007 on slurp.thebarn.com X-Virus-Status: Clean X-archive-position: 13130 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: xfs This is a multi-part message in MIME format. --------------040907080408040109000409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Eric Sandeen wrote: > Manoj Kumar Pradhan wrote: > >> Hi, >> >> I am running RHEL with kernel 2.6.9-42ELsmp x86_64. I got the xfs module >> from http://sandeen.net/rhel4_xfs/ and did a rpmbuild as instructed there, I >> got the xfs.ko and the module-xfs rpm for the running kernel too but modinfo >> shows me that the xfs module hence created is not dmapi enabled. >> > > Right, the dmapi module isn't included in that. As far as I can recall, > the necessary bits to support DMAPI are not present in the RHEL4 kernel, > so this is probably not going to work. Perhaps the sgi guys can chime > in if I'm off base. > > -Eric > > Isn't there a rhel4 patch floating around someplace? :-) >> [root@asher RPMS]# modinfo xfs >> filename: /lib/modules/2.6.9-42.ELsmp/kernel/fs/xfs/xfs.ko >> license: GPL >> description: SGI XFS with ACLs, security attributes, realtime, large >> block/inode numbers, no debug enabled >> author: Silicon Graphics, Inc. >> depends: >> vermagic: 2.6.9-42.ELsmp SMP gcc-3.4 >> >> When I run a simple app which tries to init dmapi for XFS it fails with >> ENOSYS. >> Did I miss anything here? How do I enable DMAPI on this XFS module? >> >> Thanks, >> Manoj >> >> >> [[HTML alternate version deleted]] >> >> >> > > --------------040907080408040109000409 Content-Type: text/x-vcard; charset=utf-8; name="cattelan.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="cattelan.vcf" begin:vcard fn:Russell Cattelan n:Cattelan;Russell email;internet:cattelan@thebarn.com x-mozilla-html:FALSE version:2.1 end:vcard --------------040907080408040109000409-- From owner-xfs@oss.sgi.com Wed Sep 26 09:24:23 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 09:24:28 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_24, SPF_HELO_PASS autolearn=no version=3.3.0-r574664 Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8QGOLaR015266 for ; Wed, 26 Sep 2007 09:24:22 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id EEC3B1C000260; Wed, 26 Sep 2007 12:24:20 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id ED7CC4019B78; Wed, 26 Sep 2007 12:24:20 -0400 (EDT) Date: Wed, 26 Sep 2007 12:24:20 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: =?utf-8?B?QnJ5YW4gSiBTbWl0aA==?= cc: xfs-bounce@oss.sgi.com, Ralf Gross , linux-xfs@oss.sgi.com, linux-raid@vger.kernel.org Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) In-Reply-To: <1254510454-1190819012-cardhu_decombobulator_blackberry.rim.net-1744849406-@bxe108.bisx.prod.on.blackberry> Message-ID: References: <498689.78850.qm@web32907.mail.mud.yahoo.com><20070926082322.GA30287@p15145560.pureserver.info><20070926084924.GB30287@p15145560.pureserver.info> <1254510454-1190819012-cardhu_decombobulator_blackberry.rim.net-1744849406-@bxe108.bisx.prod.on.blackberry> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/4404/Wed Sep 26 05:53:15 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13131 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 I have a question, when I use multiple writer threads (2 or 3) I see 550-600 MiB/s write speed (vmstat) but when using only 1 thread, ~420-430 MiB/s... Also without tweaking, SW RAID is very slow (180-200 MiB/s) using the same disks. Justin. On Wed, 26 Sep 2007, Bryan J Smith wrote: > Everyone can play local benchmarking games all they want, > and software RAID will almost always be faster, significantly at times. > > What matters is actual, multiple client performance under full load. > Anything less is a completely irrelevant. > -- > Bryan J Smith - mailto:b.j.smith@ieee.org > http://thebs413.blogspot.com > Sent via BlackBerry from T-Mobile > > > -----Original Message----- > From: Justin Piszcz > > Date: Wed, 26 Sep 2007 05:52:39 > To:Ralf Gross > Cc:linux-xfs@oss.sgi.com, linux-raid@vger.kernel.org > Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) > > > > > On Wed, 26 Sep 2007, Ralf Gross wrote: > >> Justin Piszcz schrieb: >>> What was the command line you used for that output? >>> tiobench.. ? >> >> tiobench --numruns 3 --threads 1 --threads 2 --block 4096 --size 20000 >> >> --size 20000 because the server has 16 GB RAM. >> >> Ralf >> >> > > Here is my output on my SW RAID5 keep in mind it is currently being used so the numbers are a little slower than they probably should be: > > My machine only has 8 GiB of memory but I used the same command you did: > > This is with the 2.6.22.6 kernel, the 2.6.23-rcX/final when released is supposed to have the SW RAID5 accelerator code, correct? > > Unit information > ================ > File size = megabytes > Blk Size = bytes > Rate = megabytes per second > CPU% = percentage of CPU used during the test > Latency = milliseconds > Lat% = percent of requests that took longer than X seconds > CPU Eff = Rate divided by CPU% - throughput per cpu load > > Sequential Reads > File Blk Num Avg Maximum Lat% Lat% CPU > Identifier Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff > ---------------------------- ------ ----- --- ------ ------ --------- ----------- -------- -------- ----- > 2.6.22.6 20000 4096 1 523.01 45.79% 0.022 510.77 0.00000 0.00000 1142 > 2.6.22.6 20000 4096 2 501.29 85.84% 0.046 855.59 0.00000 0.00000 584 > > Random Reads > File Blk Num Avg Maximum Lat% Lat% CPU > Identifier Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff > ---------------------------- ------ ----- --- ------ ------ --------- ----------- -------- -------- ----- > 2.6.22.6 20000 4096 1 0.90 0.276% 13.003 74.41 0.00000 0.00000 326 > 2.6.22.6 20000 4096 2 1.61 1.167% 14.443 126.43 0.00000 0.00000 137 > > Sequential Writes > File Blk Num Avg Maximum Lat% Lat% CPU > Identifier Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff > ---------------------------- ------ ----- --- ------ ------ --------- ----------- -------- -------- ----- > 2.6.22.6 20000 4096 1 363.46 75.72% 0.030 2757.45 0.00000 0.00000 480 > 2.6.22.6 20000 4096 2 394.45 287.9% 0.056 2798.92 0.00000 0.00000 137 > > Random Writes > File Blk Num Avg Maximum Lat% Lat% CPU > Identifier Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff > ---------------------------- ------ ----- --- ------ ------ --------- ----------- -------- -------- ----- > 2.6.22.6 20000 4096 1 3.16 1.752% 0.011 1.02 0.00000 0.00000 180 > 2.6.22.6 20000 4096 2 3.07 3.769% 0.013 0.10 0.00000 0.00000 82 > > > > > From owner-xfs@oss.sgi.com Wed Sep 26 09:27:49 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 09:27:55 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8QGRkHD016313 for ; Wed, 26 Sep 2007 09:27:48 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 9062F1C00026A; Wed, 26 Sep 2007 12:27:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 8F59B4019B79; Wed, 26 Sep 2007 12:27:46 -0400 (EDT) Date: Wed, 26 Sep 2007 12:27:46 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Ralf Gross cc: linux-xfs@oss.sgi.com Subject: Re: [UNSURE] Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) In-Reply-To: <20070926145417.GC30287@p15145560.pureserver.info> Message-ID: References: <20070923093841.GH19983@p15145560.pureserver.info> <18166.25242.174049.175729@base.ty.sabi.co.UK> <20070926145417.GC30287@p15145560.pureserver.info> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/4404/Wed Sep 26 05:53:15 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13132 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 Wed, 26 Sep 2007, Ralf Gross wrote: > Peter Grandi schrieb: >> Ralf> Hi, we have a new large raid array, the shelf has 48 disks, >> Ralf> the max. amount of disks in a single raid 5 set is 16. >> >> Too bad about that petty limitation ;-). > > Yeah, I prefer 24x RAID 5 without spare. Why waste so much space ;) > > After talking to the people that own the data and wanted to use as > much as possible space of the device, we'll start with four 12/11 > disk RAID 6 volumes (47 disk + 1 spare). That's ~12% less space than > before with five RAID 5 volumes. I think this is a good compromise > between safety and max. usable disk space. > > There's only one point left: will the RAID 6 during a rebuild be able > to deliver 2-3 streams of 17MB/s. Write performance is not the point > then, but the clients will be running simulations for up to 5 days and > need this (more or less) constant data rate. Now that I'm getting > ~400 MB/s (which is limited by the FC controller) this should be > possible. > >> Ralf> There will be one global spare disk, thus we have two raid 5 >> Ralf> with 15 data disks and one with 14 data disk. >> >> Ahhh a positive-thinking, can-do, brave design ;-). > > We have a 60 slot tape lib too (well, we'll have next week...I hope). > I know that raid != backup. > >> [ ... ] >> Ralf> Each client then needs a data stream of about 17 MB/s >> Ralf> (max. 5 clients are expected to acces the data in parallel). >> >> Do the requirements include as features some (possibly several) >> hours of ''challenging'' read performance if any disk fails or >> total loss of data if another disks fails during that time? ;-) > > The data then is still on USB disks and on tape. Maybe I'll pull out > a disk of one of the new RAID 6 volumes and see how much the read > performance drops. At the moment only one test bed is active, thus 17 > MB/s would be ok. Later with 5 test beds 5 x 17 MB/s are needed (if > they are online at the same time). > >> IIRC Google have reported 5% per year disk failure rates across a >> very wide mostly uncorrelated population, you have 48 disks, >> perhaps 2-3 disks per year will fail. Perhaps more and more often, >> because they will likely be all from the same manufacturer, model, >> batch and spinning in the same environment. > > Hey, these are ENTERPRISE disks ;) As far as I know, we couldn't even > use other disks than the ones that the manufacturer provides (modified > firmware?). > >> Ralf> [ ... ] I expect the fs, each will have a size of 10-11 TB, >> Ralf> to be filled > 90%. I know this is not ideal, but we need >> Ralf> every GB we can get. >> >> That "every GB we can get" is often the key in ''wide RAID5'' >> stories. Cheap as well as fast and safe, you can have it all with >> wide RAID5 setups, so the salesmen would say ;-). > > I think we now have found a reasonable solution. > >> Ralf> [ ... ] Stripe Size : 960 KB (15 x 64 KM) >> Ralf> [ ... ] Stripe Size : 896 KB (14 x 64 KB) >> >> Pretty long stripes, I wonder what happens when a whole stripe >> cannot be written at once or it can but is not naturally aligned >> ;-). > > I'm still confused bye the chunk/stripe and block size values. The > block size of the HW-RAID is fixed to 512 bytes, I think that a bit > small. > > Also, I first thought about wasting disk space with larger > chunk/stripe sizes (HW RAID), but as the OS/FS doesn't necessarily > know about the values, it can't be true - unlike the FS block size > which defines the smallest possible file size. > >> Ralf> [ ... ] about 150 MB/s in seq. writing >> >> Surprise surprise ;-). >> >> Ralf> (tiobench) and 160 MB/s in seq. reading. >> >> This is sort of low. If there something that RAID5 can do sort of >> OK is reads (if there are no faults). I'd look at the underlying >> storage system and the maximum performance that you can get out of >> a single disk. > > /sbin/blockdev --setra 16384 /dev/sdc > > was the key to ~400 MB/s read performance. > >> I have seen a 45-drive 500GB storage subsystem where each drive >> can deliver at most 7-10MB/s (even if the same disk standalone in >> an ordinary PC can do 60-70MB/s), and the supplier actually claims >> so in their published literature (that RAID product is meant to >> compete *only* with tape backup subsystems). Your later comment >> that "The raid array is connect to the server by fibre channel" >> makes me suspect that it may be the same brand. >> >> Ralf> This is ok, >> >> As the total aggregate requirement is 5x17MB/s this is probably >> the case [as long as there are no drive failures ;-)]. >> >> Ralf> but I'm curious what I could get with tuned xfs parameters. >> >> Looking at the archives of this mailing list the topic ''good mkfs >> parameters'' reappears frequently, even if usually for smaller >> arrays, as many have yet to discover the benefits of 15-wide RAID5 >> setups ;-). Threads like these may help: >> >> http://OSS.SGI.com/archives/xfs/2007-01/msg00079.html >> http://OSS.SGI.com/archives/xfs/2007-05/msg00051.html > > I've seen some of JP's postings before. I couldn't get much more > performace with the sw/su options, I got the best results with the > default values. But I haven't tried external logs yet. > > Ralf > > /sbin/blockdev --setra 16384 /dev/sdc was the key to ~400 MB/s read performance. Nice, what do you get for write speed? Justin. From owner-xfs@oss.sgi.com Wed Sep 26 09:54:34 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 09:54:37 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) 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.3.0-r574664 Received: from stlx01.stz-softwaretechnik.com (stz-softwaretechnik.de [217.160.223.211]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8QGsWTs022116 for ; Wed, 26 Sep 2007 09:54:34 -0700 Received: from rg by stlx01.stz-softwaretechnik.com with local (Exim 3.36 #1 (Debian)) id 1Iaa9W-0005WB-00 for ; Wed, 26 Sep 2007 18:54:22 +0200 Date: Wed, 26 Sep 2007 18:54:12 +0200 From: Ralf Gross To: linux-xfs@oss.sgi.com Subject: Re: [UNSURE] Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) Message-ID: <20070926165412.GE30287@p15145560.pureserver.info> References: <20070923093841.GH19983@p15145560.pureserver.info> <18166.25242.174049.175729@base.ty.sabi.co.UK> <20070926145417.GC30287@p15145560.pureserver.info> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV 0.91.2/4404/Wed Sep 26 05:53:15 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13133 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Ralf-Lists@ralfgross.de Precedence: bulk X-list: xfs Justin Piszcz schrieb: > > > > /sbin/blockdev --setra 16384 /dev/sdc > > > > was the key to ~400 MB/s read performance. > > Nice, what do you get for write speed? Still 170-200 MB/s. The command above just tunes the read ahead value. Ralf From owner-xfs@oss.sgi.com Wed Sep 26 09:59:52 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 09:59:57 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) 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.3.0-r574664 Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8QGxoSd023277 for ; Wed, 26 Sep 2007 09:59:52 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 0021E1C000260; Wed, 26 Sep 2007 12:59:49 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id F051C4019B78; Wed, 26 Sep 2007 12:59:49 -0400 (EDT) Date: Wed, 26 Sep 2007 12:59:49 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Ralf Gross cc: linux-xfs@oss.sgi.com Subject: Re: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) In-Reply-To: <20070926165412.GE30287@p15145560.pureserver.info> Message-ID: References: <20070923093841.GH19983@p15145560.pureserver.info> <18166.25242.174049.175729@base.ty.sabi.co.UK> <20070926145417.GC30287@p15145560.pureserver.info> <20070926165412.GE30287@p15145560.pureserver.info> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/4404/Wed Sep 26 05:53:15 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13134 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 Wed, 26 Sep 2007, Ralf Gross wrote: > Justin Piszcz schrieb: >>> >>> /sbin/blockdev --setra 16384 /dev/sdc >>> >>> was the key to ~400 MB/s read performance. >> >> Nice, what do you get for write speed? > > Still 170-200 MB/s. The command above just tunes the read ahead value. > > Ralf > > Yes, I understand; what is the equivalent tweak for HW RAID? I have tried to tweak some HW RAIDS (3ware 9550SX's) with ~10 drives and one can set the read ahead for better reads but writes are still slow, that 3ware 'tuning' doc always get passed around but it never helps much at least in my testing. I wonder where the bottleneck lies. Justin. From owner-xfs@oss.sgi.com Wed Sep 26 10:08:28 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 10:08:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) 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.3.0-r574664 Received: from web32908.mail.mud.yahoo.com (web32908.mail.mud.yahoo.com [209.191.69.108]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l8QH8Qdl025458 for ; Wed, 26 Sep 2007 10:08:28 -0700 Received: (qmail 67635 invoked by uid 60001); 26 Sep 2007 17:08:25 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=6r5UNRg3liJWbc8ypaGTc6kqU7Ree7dIgR6hxFiK7E1gp94DlR572cRi5GUrM5eK1PrREO8DzAkCphTDIWEf50Q4H6UFLKcnMhxNGXDO09En/O6GSc0rIO9mC/LCZwiL8Ih4AZzKOaHMlya0w/h6pAxW2v3iHr/5TEmKoRMdxCI=; X-YMail-OSG: CE0j1PwVM1mWK59qcJvdTvHVLGBZV6RnlI0hEWZer.CmbqKmxwgvU_hM1ZUy7K_BgUNxvsyGoNrPWTRHg0O1Sd2bg.I97CJm2epvM7XbAzAdarY2bRk- Received: from [209.114.137.34] by web32908.mail.mud.yahoo.com via HTTP; Wed, 26 Sep 2007 10:08:25 PDT Date: Wed, 26 Sep 2007 10:08:25 -0700 (PDT) From: "Bryan J. Smith" Reply-To: b.j.smith@ieee.org Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) To: Ralf Gross , linux-xfs@oss.sgi.com In-Reply-To: <20070926151534.GD30287@p15145560.pureserver.info> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <696865.53046.qm@web32908.mail.mud.yahoo.com> X-Virus-Scanned: ClamAV 0.91.2/4404/Wed Sep 26 05:53:15 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13135 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: thebs413@yahoo.com Precedence: bulk X-list: xfs Ralf Gross wrote: > You're right, but these benchmarks help to find simple failures or > misconfigurations at an earlier stage of the process. Yes, as long as you are comparing to a benchmark of a known, similar quantity. It's not uncommon for Linux's RAID-5 to be 2-3x faster at dd and single file operations, especially if there are no, actual parity operations. -- Bryan J. Smith Professional, Technical Annoyance b.j.smith@ieee.org http://thebs413.blogspot.com -------------------------------------------------- Fission Power: An Inconvenient Solution From owner-xfs@oss.sgi.com Wed Sep 26 10:13:11 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 10:13:16 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) 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.3.0-r574664 Received: from web32913.mail.mud.yahoo.com (web32913.mail.mud.yahoo.com [209.191.69.113]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l8QHD94Q026622 for ; Wed, 26 Sep 2007 10:13:11 -0700 Received: (qmail 46800 invoked by uid 60001); 26 Sep 2007 17:13:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=HBtdVvutl5ZrT112+5a44TKKEkdizsZEsP3oX6e/3JQ26fX2EKYRbRVKRtx9KMroaK78rMzTS2T4DKam7C3QfVjA2/osAtAeQYaqFxSHUimwhsaZmT47Puued6lfe9HReMigGwXhoaAncES8fN8nSf1Y3uO56n/epnHprSJn22c=; X-YMail-OSG: _Z0MPKEVM1lKhh9ky5.OAJ5x1zOLUFI1qZZEOBv.s3NJC0Ydo5N4XFS_yjHBbFAOT9.4HC1B19y7VKp7Q6SQUqZ4rSCbVeeCQqHsW2VUrkrwlnIVcOM- Received: from [209.114.137.34] by web32913.mail.mud.yahoo.com via HTTP; Wed, 26 Sep 2007 10:13:08 PDT Date: Wed, 26 Sep 2007 10:13:08 -0700 (PDT) From: "Bryan J. Smith" Reply-To: b.j.smith@ieee.org Subject: Re: [UNSURE] Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) To: Ralf Gross , linux-xfs@oss.sgi.com In-Reply-To: <20070926165412.GE30287@p15145560.pureserver.info> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <295084.46754.qm@web32913.mail.mud.yahoo.com> X-Virus-Scanned: ClamAV 0.91.2/4404/Wed Sep 26 05:53:15 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13136 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: thebs413@yahoo.com Precedence: bulk X-list: xfs Ralf Gross wrote: > Still 170-200 MB/s. The command above just tunes the read ahead > value. Don't expect your commits to an external subsystem to be anywhere near as fast as software RAID in simple disk benchmarks. -- Bryan J. Smith Professional, Technical Annoyance b.j.smith@ieee.org http://thebs413.blogspot.com -------------------------------------------------- Fission Power: An Inconvenient Solution From owner-xfs@oss.sgi.com Wed Sep 26 10:27:31 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 10:27:34 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) 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.3.0-r574664 Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8QHRShC029806 for ; Wed, 26 Sep 2007 10:27:31 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 9A2A51C000260; Wed, 26 Sep 2007 13:27:28 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 98A694019B78; Wed, 26 Sep 2007 13:27:28 -0400 (EDT) Date: Wed, 26 Sep 2007 13:27:28 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: b.j.smith@ieee.org cc: Ralf Gross , linux-xfs@oss.sgi.com Subject: Re: [UNSURE] Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) In-Reply-To: <295084.46754.qm@web32913.mail.mud.yahoo.com> Message-ID: References: <295084.46754.qm@web32913.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/4404/Wed Sep 26 05:53:15 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13137 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 Wed, 26 Sep 2007, Bryan J. Smith wrote: > Ralf Gross wrote: >> Still 170-200 MB/s. The command above just tunes the read ahead >> value. > > Don't expect your commits to an external subsystem to be anywhere > near as fast as software RAID in simple disk benchmarks. > > > -- > Bryan J. Smith Professional, Technical Annoyance > b.j.smith@ieee.org http://thebs413.blogspot.com > -------------------------------------------------- > Fission Power: An Inconvenient Solution > > So what tunables do the 9550/9650SE users utilize to achieve > 500 MiB/s write on HW RAID5/6? Justin. From owner-xfs@oss.sgi.com Wed Sep 26 10:35:18 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 10:35:23 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from web32915.mail.mud.yahoo.com (web32915.mail.mud.yahoo.com [209.191.69.115]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l8QHZEpC031623 for ; Wed, 26 Sep 2007 10:35:18 -0700 Received: (qmail 8959 invoked by uid 60001); 26 Sep 2007 17:35:14 -0000 X-YMail-OSG: q_x4PO4VM1l7b9MTN9P1q6RYgGyEQaY3cCXoGB4C8lrKUXpsp7G.nX.ERsV.I9LOyw-- Received: from [209.114.137.34] by web32915.mail.mud.yahoo.com via HTTP; Wed, 26 Sep 2007 10:35:13 PDT X-RocketYMMF: thebs413 Date: Wed, 26 Sep 2007 10:35:13 -0700 (PDT) From: "Bryan J. Smith" Reply-To: b.j.smith@ieee.org Subject: Re: [UNSURE] Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) To: Justin Piszcz , b.j.smith@ieee.org Cc: Ralf Gross , linux-xfs@oss.sgi.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <957634.8098.qm@web32915.mail.mud.yahoo.com> X-Virus-Scanned: ClamAV 0.91.2/4404/Wed Sep 26 05:53:15 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13138 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: b.j.smith@ieee.org Precedence: bulk X-list: xfs Justin Piszcz wrote: > So what tunables do the 9550/9650SE users utilize to achieve > 500 > MiB/s write on HW RAID5/6? Don't know. But I've never claimed it was capable of it either. At the same time, I've seen software RAID do over 500MBps, only to drop to under 50MBps aggregate client DTR under load. -- Bryan J. Smith Professional, Technical Annoyance b.j.smith@ieee.org http://thebs413.blogspot.com -------------------------------------------------- Fission Power: An Inconvenient Solution From owner-xfs@oss.sgi.com Wed Sep 26 10:37:18 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 10:37:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) 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.3.0-r574664 Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8QHbGOk032490 for ; Wed, 26 Sep 2007 10:37:18 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 718AC1C000267; Wed, 26 Sep 2007 13:37:16 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 6EAA44019B78; Wed, 26 Sep 2007 13:37:16 -0400 (EDT) Date: Wed, 26 Sep 2007 13:37:16 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: "Bryan J. Smith" cc: Ralf Gross , linux-xfs@oss.sgi.com Subject: Re: [UNSURE] Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) In-Reply-To: <957634.8098.qm@web32915.mail.mud.yahoo.com> Message-ID: References: <957634.8098.qm@web32915.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/4404/Wed Sep 26 05:53:15 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13139 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 Wed, 26 Sep 2007, Bryan J. Smith wrote: > Justin Piszcz wrote: >> So what tunables do the 9550/9650SE users utilize to achieve > 500 >> MiB/s write on HW RAID5/6? > > Don't know. But I've never claimed it was capable of it either. > > At the same time, I've seen software RAID do over 500MBps, only to > drop to under 50MBps aggregate client DTR under load. Do you have any type of benchmarks to similate the load you are mentioning? What did HW RAID drop to when the same test was run with SW RAID / 50 MBps under load? Did it achieve better performance due to an on-board / raid-card controller cache, or? Justin. From owner-xfs@oss.sgi.com Wed Sep 26 10:38:44 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 10:38:51 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from web32906.mail.mud.yahoo.com (web32906.mail.mud.yahoo.com [209.191.69.83]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l8QHccK8000641 for ; Wed, 26 Sep 2007 10:38:44 -0700 Received: (qmail 62784 invoked by uid 60001); 26 Sep 2007 17:11:56 -0000 X-YMail-OSG: dv_9qYwVM1kcmd7LfIXCo9eu_6xFlXnGGS39gX3ZbsuhIFrya0V44n_8_xGr7ZXMRzy5uKLQJttKBBrAvkHysqFRcvsSymEmQRfkonlB7pshOKU- Received: from [209.114.137.34] by web32906.mail.mud.yahoo.com via HTTP; Wed, 26 Sep 2007 10:11:56 PDT X-RocketYMMF: thebs413 Date: Wed, 26 Sep 2007 10:11:56 -0700 (PDT) From: "Bryan J. Smith" Reply-To: b.j.smith@ieee.org Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) To: Justin Piszcz , Bryan J Smith Cc: xfs-bounce@oss.sgi.com, Ralf Gross , linux-xfs@oss.sgi.com, linux-raid@vger.kernel.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <673292.62672.qm@web32906.mail.mud.yahoo.com> X-Virus-Scanned: ClamAV 0.91.2/4404/Wed Sep 26 05:53:15 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13142 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: b.j.smith@ieee.org Precedence: bulk X-list: xfs Justin Piszcz wrote: > I have a question, when I use multiple writer threads (2 or 3) I > see 550-600 MiB/s write speed (vmstat) but when using only 1 thread, > ~420-430 MiB/s... It's called scheduling buffer flushes, as well as the buffering itself. > Also without tweaking, SW RAID is very slow (180-200 > MiB/s) using the same disks. But how much of that tweaking is actually just buffering? That's a continued theme (and issue). Unless you can force completely synchronous writes, you honestly don't know. Using a larger size than memory is not anywhere near the same. Plus it makes software RAID utterly n/a in comparison to hardware RAID, where the driver is waiting until the commit to actual NVRAM or disc is complete. -- Bryan J. Smith Professional, Technical Annoyance b.j.smith@ieee.org http://thebs413.blogspot.com -------------------------------------------------- Fission Power: An Inconvenient Solution From owner-xfs@oss.sgi.com Wed Sep 26 10:38:35 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 10:38:43 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) 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.3.0-r574664 Received: from web32910.mail.mud.yahoo.com (web32910.mail.mud.yahoo.com [209.191.69.110]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l8QHcXbn000586 for ; Wed, 26 Sep 2007 10:38:34 -0700 Received: (qmail 41661 invoked by uid 60001); 26 Sep 2007 17:38:33 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=Qa1WfpfPjBlJYDGxpgf2mc1/sOgCafbGdFXGVh0Sue0qa9EoT0pOyoDWKf+mIRTQJFXtoYBkbBwJ/khnjXwINxEfnZW16Gt+MVwZe22grp/641ER9oaQ8wrM63whB76ipaursWV/7zO8fhqu3T1p0VtGcaibJIVhub3gtUh5lek=; X-YMail-OSG: F8C59bYVM1k2X_j3Ojoz3lcukEbgCMVKYe1ksaGtMOTkwMZd3YuwmMin2t4DaEdDNpT40s6cDtph73Ch4EJ6e9cGxoufMMMt5MH2lJ3cQeJRQQ_Kae0- Received: from [209.114.137.34] by web32910.mail.mud.yahoo.com via HTTP; Wed, 26 Sep 2007 10:38:33 PDT Date: Wed, 26 Sep 2007 10:38:33 -0700 (PDT) From: "Bryan J. Smith" Reply-To: b.j.smith@ieee.org Subject: Re: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) To: Justin Piszcz , Ralf Gross Cc: linux-xfs@oss.sgi.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <216020.40502.qm@web32910.mail.mud.yahoo.com> X-Virus-Scanned: ClamAV 0.91.2/4404/Wed Sep 26 05:53:15 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13141 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: thebs413@yahoo.com Precedence: bulk X-list: xfs Justin Piszcz wrote: > I wonder where the bottleneck lies. The microcontroller. Listen, for the last time, hardware RAID is _not_ for non-blocking I/O. Hardware RAID is for in-line XOR streaming off-load, so it doesn't tie up a system interconnect (which isn't an ideal use for it). A hardware RAID card is when you have other things going on in your interconnect that you don't want the parity LOAD-XOR-STOR to take away from what it could be using for the service. It will _never_ have the "raw performance" of OS optimized software RAID. At the same time, OS optimized software RAID's impact on the system interconnect is one of those "unmeasurable" details _unless_ you actually benchmark your application. I have repeatedly had issues with elementary UDP/IP NFS performance when the PIO of software RAID is hogging the system interconnect. Same deal for large numbers of large database record commits. -- Bryan J. Smith Professional, Technical Annoyance b.j.smith@ieee.org http://thebs413.blogspot.com -------------------------------------------------- Fission Power: An Inconvenient Solution From owner-xfs@oss.sgi.com Wed Sep 26 10:38:34 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 10:38:42 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) 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.3.0-r574664 Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8QHcXDo000585 for ; Wed, 26 Sep 2007 10:38:34 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id F28651C000267; Wed, 26 Sep 2007 13:38:32 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id D7BE14019B78; Wed, 26 Sep 2007 13:38:32 -0400 (EDT) Date: Wed, 26 Sep 2007 13:38:32 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: "Bryan J. Smith" cc: Ralf Gross , linux-xfs@oss.sgi.com Subject: Re: [UNSURE] Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) In-Reply-To: Message-ID: References: <957634.8098.qm@web32915.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/4404/Wed Sep 26 05:53:15 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13140 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 Wed, 26 Sep 2007, Justin Piszcz wrote: > > > On Wed, 26 Sep 2007, Bryan J. Smith wrote: > >> Justin Piszcz wrote: >>> So what tunables do the 9550/9650SE users utilize to achieve > 500 >>> MiB/s write on HW RAID5/6? >> >> Don't know. But I've never claimed it was capable of it either. >> >> At the same time, I've seen software RAID do over 500MBps, only to >> drop to under 50MBps aggregate client DTR under load. > > Do you have any type of benchmarks to similate the load you are mentioning? > What did HW RAID drop to when the same test was run with SW RAID / 50 MBps > under load? Did it achieve better performance due to an on-board / raid-card > controller cache, or? > > Justin. > > simulate* rather. From owner-xfs@oss.sgi.com Wed Sep 26 10:41:46 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 10:41:50 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8QHfeMH002393 for ; Wed, 26 Sep 2007 10:41:45 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id D09AA1C000260; Wed, 26 Sep 2007 13:41:40 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id CF4244019B78; Wed, 26 Sep 2007 13:41:40 -0400 (EDT) Date: Wed, 26 Sep 2007 13:41:40 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: b.j.smith@ieee.org cc: Ralf Gross , linux-xfs@oss.sgi.com Subject: Re: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) In-Reply-To: <216020.40502.qm@web32910.mail.mud.yahoo.com> Message-ID: References: <216020.40502.qm@web32910.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/4404/Wed Sep 26 05:53:15 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13143 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 Wed, 26 Sep 2007, Bryan J. Smith wrote: > Justin Piszcz wrote: >> I wonder where the bottleneck lies. > > The microcontroller. > > Listen, for the last time, hardware RAID is _not_ for non-blocking > I/O. Hardware RAID is for in-line XOR streaming off-load, so it > doesn't tie up a system interconnect (which isn't an ideal use for > it). I agree and this makes sense but in real-world loads it makes me wonder, at least with the 2.4 kernel. I see hosts where total streaming does not take place, instead lots of little files are copied on and off a host and with the 2.4 kernel (RHEL3) the system 'feels' as if it were buried even though the load is not that high ~9-10-15. Using ext3 on a 9 or 10 disk RAID5 with default RAID parameters on a 3ware 9550SX card. Justin. > > A hardware RAID card is when you have other things going on in your > interconnect that you don't want the parity LOAD-XOR-STOR to take > away from what it could be using for the service. > > It will _never_ have the "raw performance" of OS optimized software > RAID. At the same time, OS optimized software RAID's impact on the > system interconnect is one of those "unmeasurable" details _unless_ > you actually benchmark your application. > > I have repeatedly had issues with elementary UDP/IP NFS performance > when the PIO of software RAID is hogging the system interconnect. > Same deal for large numbers of large database record commits. Understood. > > > -- > Bryan J. Smith Professional, Technical Annoyance > b.j.smith@ieee.org http://thebs413.blogspot.com > -------------------------------------------------- > Fission Power: An Inconvenient Solution > From owner-xfs@oss.sgi.com Wed Sep 26 10:49:36 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 10:49:40 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from web32905.mail.mud.yahoo.com (web32905.mail.mud.yahoo.com [209.191.69.82]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l8QHnWZP004200 for ; Wed, 26 Sep 2007 10:49:36 -0700 Received: (qmail 2561 invoked by uid 60001); 26 Sep 2007 17:49:31 -0000 X-YMail-OSG: Nt2pqvgVM1kuNdqxND4xbxjaevoVWOIQX.IpKJg9pKJ.ZDWWbxLtq5GJyeCecpU6FrWszuatXWp5TGoYqoWKyqMDP.yKYtsAamF31BlS2ura1To- Received: from [209.114.137.34] by web32905.mail.mud.yahoo.com via HTTP; Wed, 26 Sep 2007 10:49:31 PDT X-RocketYMMF: thebs413 Date: Wed, 26 Sep 2007 10:49:31 -0700 (PDT) From: "Bryan J. Smith" Reply-To: b.j.smith@ieee.org Subject: Re: [UNSURE] Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) To: Justin Piszcz , "Bryan J. Smith" Cc: Ralf Gross , linux-xfs@oss.sgi.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <730488.2449.qm@web32905.mail.mud.yahoo.com> X-Virus-Scanned: ClamAV 0.91.2/4404/Wed Sep 26 05:53:15 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13144 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: b.j.smith@ieee.org Precedence: bulk X-list: xfs Justin Piszcz wrote: > Do you have any type of benchmarks to similate the load you are > mentioning? Yes, write different, non-zero, 100GB data files from 30 NFSv3 sync clients at the same time. You can easily script firing that off and get the number of seconds it takes to commit. Use NFS with UDP to avoid the overhead of TCP. > What did HW RAID drop to when the same test was run with SW > RAID / 50 MBps under load? I saw an aggregate commit average of around 150MBps using a pair of 8-channel 3Ware Escalade 9550SX cards (each on their own PCI-X bus), with a LVM stripe between them. Understand the test literally took 5 hours to run! The software RAID-50, two "dumb" SATA 8-channel Marvell cards (each on their own PCI-X bus), with a LVM stripe between them, was not completed after 15 hours (overnight). So I finally terminated it. Each system had a 4x GbE trunk to a layer-3 switch. I would have run the same test with SMB TCP/IP, possibly with a LeWiz 4x GbE RX TOE HBA, except I honestly didn't have the time to wait on it. > Did it achieve better performance due to an on-board / > raid-card controller cache, or? Has nothing to do with cache. The OS is far better at scheduling and buffering in the system RAM, in addition to the fact that it does an async buffer, whereas many HW RAID drivers are sync to the NVRAM of the HW RAID card (that's part of the problem with comparisons). It has to do with the fact in software RAID-5 you are streaming 100% of the data through the general system interconnect for the LOAD-XOR-STO operation. XORs are extrmely fast. LOAD/STO through a general purpose CPU is not. It's the same reason why we don't use general purpose CPUs for layer-3 switches either, but a "core" CPU with NPE (network processor engine) ASICs. Same deal with most HW RAID cards, a "core" CPU with SPE ASICs -- for off-load from the general CPU system interconnect. XORs are done "in-line" with the transfer, instead of hogging up the system interconnect. It's the direct difference between PIO and DMA. An in-line NPE/SPE ASIC basically acts like a DMA transfer, real-time. A general purpose CPU and its interconnect cannot do that, so it has all the issues of PIO. PIO in a general purpose CPU is to be avoided at all costs when you have other needs for the system interconnect, like I/O. If you don't have much else bothering the I/O, like in a web server or read-only system (where you're not doing the writes), then it doesn't matter, and software RAID-5 is great. -- Bryan J. Smith Professional, Technical Annoyance b.j.smith@ieee.org http://thebs413.blogspot.com -------------------------------------------------- Fission Power: An Inconvenient Solution From owner-xfs@oss.sgi.com Wed Sep 26 10:55:23 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 10:55:29 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) 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.3.0-r574664 Received: from web32904.mail.mud.yahoo.com (web32904.mail.mud.yahoo.com [209.191.69.81]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l8QHtKKd005615 for ; Wed, 26 Sep 2007 10:55:23 -0700 Received: (qmail 46294 invoked by uid 60001); 26 Sep 2007 17:55:19 -0000 X-YMail-OSG: Jd5vppwVM1mG6nMrVLOtjfkN0mfni2i.iTG25gLs7YePLL34AJpa5YEBHRUPUtj7oOuh0c2p3TNLbyrub0K3iPBXqTPqD9JwYXbD2MlkNKiBp2E- Received: from [209.114.137.34] by web32904.mail.mud.yahoo.com via HTTP; Wed, 26 Sep 2007 10:55:19 PDT X-RocketYMMF: thebs413 Date: Wed, 26 Sep 2007 10:55:19 -0700 (PDT) From: "Bryan J. Smith" Reply-To: b.j.smith@ieee.org Subject: Re: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) To: Justin Piszcz , b.j.smith@ieee.org Cc: Ralf Gross , linux-xfs@oss.sgi.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <347332.44288.qm@web32904.mail.mud.yahoo.com> X-Virus-Scanned: ClamAV 0.91.2/4404/Wed Sep 26 05:53:15 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13145 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: b.j.smith@ieee.org Precedence: bulk X-list: xfs Justin Piszcz wrote: > I agree and this makes sense but in real-world loads it makes me > wonder, at least with the 2.4 kernel. It took 3Ware (actually AMCC) a good 18 months to get the firmware and driver tuned well. I purposely avoided any new 3Ware solution until a good 12-18 months after release because of such. The 9550SX series was the first microcontroller approach (PowerPC 400 series) done by 3Ware. All of their prior designs were an older 64-bit ASIC design with SRAM (and only DRAM slapped on, poorly, in the 9500S), which only worked well for RAID-0/1/10, not 5. That was well into the 2.6 era. I'd say you're well out of date with what 3Ware, let alone the Intel X-Scale-based Areca, are actually capable of with RAID-5/6 now. -- Bryan P.S. Both AMD and Intel are currently putting serious R&D into the first embedded x86 designs with added ASICs for Network, Storage, etc... I.e., this is going to be mainstream shortly, as AMD got out of 29000 long ago, and Intel is putting less and less focus on IOP33x/34x X-Scale. NPE, SPE and other units can literally handle DTRs that are 10x of what a general CPU/interconnect LOAD-op-STOR can do. I.e., Don't be surprised when your 2009+ server mainboard ICH is actually an embedded x86 processor with NPE and SPE units. That will finally remove the whole "separate card" in general. -- Bryan J. Smith Professional, Technical Annoyance b.j.smith@ieee.org http://thebs413.blogspot.com -------------------------------------------------- Fission Power: An Inconvenient Solution From owner-xfs@oss.sgi.com Wed Sep 26 14:10:38 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 14:10:44 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.2 required=5.0 tests=ANY_BOUNCE_MESSAGE,AWL, BAYES_50,VBOUNCE_MESSAGE autolearn=no version=3.3.0-r574664 Received: from omr-m35.mx.aol.com (omr-m35.mx.aol.com [64.12.136.101]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8QLAaFv008101 for ; Wed, 26 Sep 2007 14:10:38 -0700 Received: from rly-dd02.mx.aol.com (rly-dd02.mx.aol.com [205.188.156.239]) by omr-m35.mx.aol.com (v117.7) with ESMTP id MAILOMRM356-7f3d46facac89b; Wed, 26 Sep 2007 17:10:32 -0400 Received: from localhost (localhost) by rly-dd02.mx.aol.com (8.14.1/8.14.1) id l8QLAMiP023071; Wed, 26 Sep 2007 17:10:32 -0400 Date: Wed, 26 Sep 2007 17:10:32 -0400 From: Mail Delivery Subsystem Message-Id: <200709262110.l8QLAMiP023071@rly-dd02.mx.aol.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="l8QLAMiP023071.1190841032/rly-dd02.mx.aol.com" Subject: Returned mail: see transcript for details Auto-Submitted: auto-generated (failure) X-AOL-INRLY: host121.sleepys.com [65.200.161.121] rly-dd02 X-AOL-IP: 205.188.156.239 X-Virus-Scanned: ClamAV 0.91.2/4409/Wed Sep 26 13:17:09 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13146 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: MAILER-DAEMON@aol.com Precedence: bulk X-list: xfs This is a MIME-encapsulated message --l8QLAMiP023071.1190841032/rly-dd02.mx.aol.com The original message was received at Wed, 26 Sep 2007 17:10:10 -0400 from host121.sleepys.com [65.200.161.121] *** ATTENTION *** Your e-mail is being returned to you because there was a problem with its delivery. The address which was undeliverable is listed in the section labeled: "----- The following addresses had permanent fatal errors -----". The reason your mail is being returned to you is listed in the section labeled: "----- Transcript of Session Follows -----". The line beginning with "<<<" describes the specific reason your e-mail could not be delivered. The next line contains a second error message which is a general translation for other e-mail servers. Please direct further questions regarding this message to your e-mail administrator. --AOL Postmaster ----- The following addresses had permanent fatal errors ----- (reason: 554 TRANSACTION FAILED - Unrepairable Virus Detected. Your mail has not been sent.) ----- Transcript of session follows ----- ... while talking to air-dd06.mail.aol.com.: >>> DATA <<< 554 TRANSACTION FAILED - Unrepairable Virus Detected. Your mail has not been sent. 554 5.0.0 Service unavailable --l8QLAMiP023071.1190841032/rly-dd02.mx.aol.com Content-Type: message/delivery-status Reporting-MTA: dns; rly-dd02.mx.aol.com Arrival-Date: Wed, 26 Sep 2007 17:10:10 -0400 Final-Recipient: RFC822; francicash@aol.com Action: failed Status: 5.0.0 Remote-MTA: DNS; air-dd06.mail.aol.com Diagnostic-Code: SMTP; 554 TRANSACTION FAILED - Unrepairable Virus Detected. Your mail has not been sent. Last-Attempt-Date: Wed, 26 Sep 2007 17:10:32 -0400 --l8QLAMiP023071.1190841032/rly-dd02.mx.aol.com Content-Type: text/rfc822-headers Received: from oss.sgi.com (host121.sleepys.com [65.200.161.121]) by rly-dd02.mx.aol.com (v119.11) with ESMTP id MAILRELAYINDD028-b6646facaac30a; Wed, 26 Sep 2007 17:10:07 -0400 From: linux-xfs@oss.sgi.com To: francicash@aol.com Subject: Returned mail: Data format error Date: Wed, 26 Sep 2007 17:10:03 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0010_E7B3315C.665B9C98" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-AOL-IP: 65.200.161.121 X-AOL-SCOLL-SCORE:0:2:290205952:9395240 X-AOL-SCOLL-URL_COUNT: X-AOL-SCOLL-AUTHENTICATION: listenair ; SPF_helo : X-AOL-SCOLL-AUTHENTICATION: listenair ; SPF_822_from : Message-ID: <200709261710.b6646facaac30a@rly-dd02.mx.aol.com> --l8QLAMiP023071.1190841032/rly-dd02.mx.aol.com-- From owner-xfs@oss.sgi.com Wed Sep 26 17:51:27 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 17:51:29 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) 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.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l8R0pL2G024736 for ; Wed, 26 Sep 2007 17:51:25 -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 KAA21853; Thu, 27 Sep 2007 10:50:57 +1000 Message-ID: <46FAFE71.9070000@sgi.com> Date: Thu, 27 Sep 2007 10:50:57 +1000 From: Donald Douwsma User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Christoph Hellwig CC: Eric Sandeen , xfs@oss.sgi.com Subject: Re: PARTIAL TAKE 971050 - Remove linux-2.4 build support References: <20070926082614.D92CE300F406@linuxbuild.melbourne.sgi.com> <46FA4FA5.5040405@sandeen.net> <20070926122854.GA17050@infradead.org> In-Reply-To: <20070926122854.GA17050@infradead.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4411/Wed Sep 26 14:43:35 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13147 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 Christoph Hellwig wrote: > On Wed, Sep 26, 2007 at 07:25:09AM -0500, Eric Sandeen wrote: >> So, what's to be done about xfs_refcache.c... right now it's 2.4-only, >> but i'm not convinced that there is similar generic nfs functionality in >> 2.6, anyone know for sure? > > We keep the inodes around through nfsd, yes. There's a slight problem > with ->release beeing called to early, but Greg is working on fixing > that using an open files cache in nfsd. Cool I'll keep that in mind, I'm going to remove support/Makefile which is 2.4 specific as well. Are there any other 2.4 isms you guys know of? Don From owner-xfs@oss.sgi.com Wed Sep 26 18:54:25 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 18:54:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8R1sNqo001820 for ; Wed, 26 Sep 2007 18:54:25 -0700 Received: from liberator.sandeen.net (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 1C1811803C929; Wed, 26 Sep 2007 20:54:23 -0500 (CDT) Message-ID: <46FB0D4E.4070704@sandeen.net> Date: Wed, 26 Sep 2007 20:54:22 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Donald Douwsma CC: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: PARTIAL TAKE 971050 - Remove linux-2.4 build support References: <20070926082614.D92CE300F406@linuxbuild.melbourne.sgi.com> <46FA4FA5.5040405@sandeen.net> <20070926122854.GA17050@infradead.org> <46FAFE71.9070000@sgi.com> In-Reply-To: <46FAFE71.9070000@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4411/Wed Sep 26 14:43:35 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13148 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: > Christoph Hellwig wrote: > >> On Wed, Sep 26, 2007 at 07:25:09AM -0500, Eric Sandeen wrote: >> >>> So, what's to be done about xfs_refcache.c... right now it's 2.4-only, >>> but i'm not convinced that there is similar generic nfs functionality in >>> 2.6, anyone know for sure? >>> >> We keep the inodes around through nfsd, yes. There's a slight problem >> with ->release beeing called to early, but Greg is working on fixing >> that using an open files cache in nfsd. >> > > Cool I'll keep that in mind, > > I'm going to remove support/Makefile which is 2.4 specific as well. > Are there any other 2.4 isms you guys know of? > > Don > > > It may be worth diffing the linux-2.4/* and linux-2.6/* to see if there are any no-ops in 2.6 there only for 2.4... I believe there are. linux-2.6/mutex.h could probably go away... hm, there are quite a few 2 or 3 line headers in there, dunno if it makes sense to have them split out... maybe. you could lose HAVE_SPLICE and HAVE_FOP_OPEN_EXEC I think Hmm I wonder if custom do_div is still needed. -Eric From owner-xfs@oss.sgi.com Wed Sep 26 19:15:07 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 19:15:10 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8R2F6m7004926 for ; Wed, 26 Sep 2007 19:15:07 -0700 Received: from liberator.sandeen.net (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 60F821803C92D; Wed, 26 Sep 2007 21:15:06 -0500 (CDT) Message-ID: <46FB1229.2070706@sandeen.net> Date: Wed, 26 Sep 2007 21:15:05 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Christoph Hellwig CC: Donald Douwsma , xfs@oss.sgi.com Subject: Re: PARTIAL TAKE 971050 - Remove linux-2.4 build support References: <20070926082614.D92CE300F406@linuxbuild.melbourne.sgi.com> <46FA4FA5.5040405@sandeen.net> <20070926122854.GA17050@infradead.org> In-Reply-To: <20070926122854.GA17050@infradead.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4411/Wed Sep 26 14:43:35 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13149 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 26, 2007 at 07:25:09AM -0500, Eric Sandeen wrote: >> So, what's to be done about xfs_refcache.c... right now it's 2.4-only, >> but i'm not convinced that there is similar generic nfs functionality in >> 2.6, anyone know for sure? > > We keep the inodes around through nfsd, yes. There's a slight problem > with ->release beeing called to early, but Greg is working on fixing > that using an open files cache in nfsd. hch, could you point me to where? I went looking once... -Eric From owner-xfs@oss.sgi.com Wed Sep 26 19:47:36 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 19:47:39 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8R2lY85011251 for ; Wed, 26 Sep 2007 19:47:36 -0700 Received: from liberator.sandeen.net (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 B68521803C97E for ; Wed, 26 Sep 2007 21:47:33 -0500 (CDT) Message-ID: <46FB19C4.8070703@sandeen.net> Date: Wed, 26 Sep 2007 21:47:32 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: xfs-oss Subject: [PATCH] fix up out-of-tree xfs builds Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4411/Wed Sep 26 14:43:35 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13150 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 Fix up xfs out-of-tree builds. (a.k.a. external modules) Change -I include directives to find headers in the out-of-tree spot. This allows a directory containing only xfs files to be built as: # make -C /path/to/kernel M=`pwd` Signed-off-by: Eric Sandeen Index: linux/fs/xfs/Makefile =================================================================== --- linux.orig/fs/xfs/Makefile +++ linux/fs/xfs/Makefile @@ -16,7 +16,7 @@ # Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA # -EXTRA_CFLAGS += -Ifs/xfs -Ifs/xfs/linux-2.6 -funsigned-char +EXTRA_CFLAGS += -I$(src) -I$(src)/linux-2.6 -funsigned-char XFS_LINUX := linux-2.6 Index: linux/fs/xfs/dmapi/Makefile =================================================================== --- linux.orig/fs/xfs/dmapi/Makefile +++ linux/fs/xfs/dmapi/Makefile @@ -16,8 +16,8 @@ # Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA # -EXTRA_CFLAGS += -I $(TOPDIR)/fs/xfs -I $(TOPDIR)/fs/xfs/linux-2.6 -EXTRA_CFLAGS += -I $(TOPDIR)/fs/dmapi +EXTRA_CFLAGS += -I$(src)/.. -I$(src)/../linux-2.6 +EXTRA_CFLAGS += -I$(TOPDIR)/fs/dmapi ifeq ($(CONFIG_XFS_DEBUG),y) EXTRA_CFLAGS += -g -DDEBUG Index: linux/fs/xfs/quota/Makefile =================================================================== --- linux.orig/fs/xfs/quota/Makefile +++ linux/fs/xfs/quota/Makefile @@ -16,7 +16,7 @@ # Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA # -EXTRA_CFLAGS += -I $(TOPDIR)/fs/xfs -I $(TOPDIR)/fs/xfs/linux-2.6 +EXTRA_CFLAGS += -I$(src)/.. -I$(src)/../linux-2.6 ifeq ($(CONFIG_XFS_DEBUG),y) EXTRA_CFLAGS += -g From owner-xfs@oss.sgi.com Wed Sep 26 19:51:08 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 19:51:10 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_34, SPF_HELO_PASS autolearn=no version=3.3.0-r574664 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8R2p7Lq012451 for ; Wed, 26 Sep 2007 19:51:08 -0700 Received: from liberator.sandeen.net (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 378E71803C92E; Wed, 26 Sep 2007 21:51:07 -0500 (CDT) Message-ID: <46FB1A9A.7020101@sandeen.net> Date: Wed, 26 Sep 2007 21:51:06 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: donaldd@sgi.com CC: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: Re: PARTIAL TAKE 971050 - Remove linux-2.4 build support References: <20070926082120.86D772FB966D@linuxbuild.melbourne.sgi.com> In-Reply-To: <20070926082120.86D772FB966D@linuxbuild.melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4411/Wed Sep 26 14:43:35 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13151 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 donaldd@sgi.com wrote: > Remove linux-2.4 Makefile wrappers from fs/xfs/quota, fs/xfs/dmapi and fs/dmapi. > > Date: Wed Sep 26 18:20:13 AEST 2007 > Workarea: linuxbuild.melbourne.sgi.com:/home/donaldd/isms/2.6.x-xfs > Inspected by: tes,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:29784a support/Makefile can go away too, it's 2.4 only. -Eric From owner-xfs@oss.sgi.com Wed Sep 26 20:51:46 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Sep 2007 20:51:50 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) 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.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l8R3phrv002173 for ; Wed, 26 Sep 2007 20:51:45 -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 NAA25113; Thu, 27 Sep 2007 13:51:37 +1000 From: donaldd@sgi.com Received: by linuxbuild.melbourne.sgi.com (Postfix, from userid 16365) id 8AE11303F3CB; Thu, 27 Sep 2007 13:51:37 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 971050 - Remove linux-2.4 build support Message-Id: <20070927035137.8AE11303F3CB@linuxbuild.melbourne.sgi.com> Date: Thu, 27 Sep 2007 13:51:37 +1000 (EST) X-Virus-Scanned: ClamAV 0.91.2/4411/Wed Sep 26 14:43:35 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13152 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 Remove fs/xfs/support/Makefile as building for 2.4 kernels is no longer supported from this tree Date: Thu Sep 27 13:49:55 AEST 2007 Workarea: linuxbuild.melbourne.sgi.com:/home/donaldd/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:29791a fs/xfs/support/Makefile - 1.23 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/support/Makefile.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h From owner-xfs@oss.sgi.com Thu Sep 27 04:02:55 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 27 Sep 2007 04:03:00 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.8 required=5.0 tests=BAYES_80,MSGID_FROM_MTA_HEADER autolearn=no version=3.3.0-r574664 Received: from mx05.syd.iprimus.net.au (mx05.syd.iprimus.net.au [210.50.30.235]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8RB2qNr004599 for ; Thu, 27 Sep 2007 04:02:55 -0700 Message-Id: <200709271102.l8RB2qNr004599@oss.sgi.com> Received: from localhost by mx05.syd.iprimus.net.au; 27 Sep 2007 20:51:11 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Date: 27 Sep 2007 20:51:16 +1000 To: xfs@oss.sgi.com From: "Mail Delivery System" Subject: mx05.syd.iprimus.net.au Virus infected message detected X-Virus-Scanned: ClamAV 0.91.2/4411/Wed Sep 26 14:43:35 2007 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id l8RB2tNr004618 X-archive-position: 13153 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: postmaster@iprimus.com.au Precedence: bulk X-list: xfs The following viruses were detected in a message (MID 68677981): 'W32/MyDoom-O' Actions taken: Message archived Message dropped Original Envelope Sender: From xfs@oss.sgi.com Thu Sep 27 20:51:11 2007 Message Headers: From: xfs@oss.sgi.com To: neera.burra@undp.org Subject: Date: Thu, 27 Sep 2007 18:49:34 +0800 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_6C788823.E38121C1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 From owner-xfs@oss.sgi.com Thu Sep 27 08:22:55 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 27 Sep 2007 08:23:00 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) 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.3.0-r574664 Received: from stlx01.stz-softwaretechnik.com (stz-softwaretechnik.de [217.160.223.211]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8RFMrvD011614 for ; Thu, 27 Sep 2007 08:22:54 -0700 Received: from rg by stlx01.stz-softwaretechnik.com with local (Exim 3.36 #1 (Debian)) id 1IavCL-0000YP-00 for ; Thu, 27 Sep 2007 17:22:41 +0200 Date: Thu, 27 Sep 2007 17:22:31 +0200 From: Ralf Gross To: linux-xfs@oss.sgi.com Subject: Re: mkfs options for a 16x hw raid5 and xfs (mostly large files) Message-ID: <20070927152231.GF30287@p15145560.pureserver.info> References: <20070923093841.GH19983@p15145560.pureserver.info> <18166.25242.174049.175729@base.ty.sabi.co.UK> <20070926145417.GC30287@p15145560.pureserver.info> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070926145417.GC30287@p15145560.pureserver.info> User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV 0.91.2/4411/Wed Sep 26 14:43:35 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13154 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Ralf-Lists@ralfgross.de Precedence: bulk X-list: xfs Ralf Gross schrieb: > Peter Grandi schrieb: > > Ralf> Hi, we have a new large raid array, the shelf has 48 disks, > > Ralf> the max. amount of disks in a single raid 5 set is 16. > > > > Too bad about that petty limitation ;-). > > Yeah, I prefer 24x RAID 5 without spare. Why waste so much space ;) > > After talking to the people that own the data and wanted to use as > much as possible space of the device, we'll start with four 12/11 > disk RAID 6 volumes (47 disk + 1 spare). That's ~12% less space than > before with five RAID 5 volumes. I think this is a good compromise > between safety and max. usable disk space. Ok, the init of the new 12 disk RAID 6 volume is complete. The numbers I get now are a bit dissapointing: ~210 MB/s for read and ~110 MB/s for write. I know that RAID 6 is slower than RAID 5, and that less data disks (10 instead of 15) also slow things down. But 390 MB/s read performance compared to 220 MB/s is a bit suprising. Particularly because the RAID 5 read performance was limited by the FC (I think). I thought I still would get 1/3 of the RAID 5 read throughput because of the 5 fewer disks of the RAID 6. I have to test this again with a larger chunk size (256k), we'll how much this affects read/write performance. Ralf From owner-xfs@oss.sgi.com Thu Sep 27 17:41:04 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 27 Sep 2007 17:41:07 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_64, J_CHICKENPOX_65,J_CHICKENPOX_66 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l8S0exaJ006819 for ; Thu, 27 Sep 2007 17:41:02 -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 KAA26052; Fri, 28 Sep 2007 10:40:51 +1000 Message-ID: <46FC4DFB.40709@sgi.com> Date: Fri, 28 Sep 2007 10:42:35 +1000 From: Vlad Apostolov User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH] kill xfs_dm_fsops.c References: <20070916120523.GB31602@lst.de> In-Reply-To: <20070916120523.GB31602@lst.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4415/Thu Sep 27 13:02:21 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13155 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 It is looking good Christoph. I will merge it to the XFS dev tree shortly. Regards, Vlad Christoph Hellwig wrote: > No point having a separate file for these few methods, especially if > we want to merge the crufty ops vector into the dmapiops one day. > > > Signed-off-by: Christoph Hellwig > > Index: linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/dmapi/xfs_dm.c 2007-09-15 10:35:50.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c 2007-09-15 10:37:46.000000000 +0200 > @@ -46,6 +46,7 @@ > #include "xfs_attr.h" > #include "xfs_attr_leaf.h" > #include "xfs_inode_item.h" > +#include "xfs_vfsops.h" > #include "xfs_vnodeops.h" > #include > #include > @@ -3071,9 +3072,10 @@ xfs_dm_obj_ref_hold( > static fsys_function_vector_t xfs_fsys_vector[DM_FSYS_MAX]; > > > -int > -xfs_dm_get_fsys_vector( > - caddr_t addr) > +STATIC int > +xfs_dm_get_dmapiops( > + struct super_block *sb, > + void *addr) > { > static int initialized = 0; > dm_fcntl_vector_t *vecrq; > @@ -3357,6 +3359,81 @@ xfs_dmops_t xfs_dmcore_xfs = { > }; > EXPORT_SYMBOL(xfs_dmcore_xfs); > > +STATIC const struct file_operations * > +xfs_dm_get_invis_ops( > + struct inode *ip) > +{ > + return &xfs_invis_file_operations; > +} > + > +STATIC int > +xfs_dm_fh_to_inode( > + struct super_block *sb, > + struct inode **ip, > + dm_fid_t *dmfid) > +{ > + bhv_vnode_t *vp = NULL; > + xfs_mount_t *mp = XFS_M(sb); > + int error; > + struct xfs_fid xfid; > + > + /* Returns negative errors to DMAPI */ > + > + *ip = NULL; > + memcpy(&xfid, dmfid, sizeof(*dmfid)); > + if (xfid.fid_len) { /* file object handle */ > + error = xfs_vget(mp, &vp, &xfid); > + } > + else { /* filesystem handle */ > + error = xfs_root(mp, &vp); > + } > + if (vp && (error == 0)) > + *ip = vn_to_inode(vp); > + return -error; /* Return negative error to DMAPI */ > +} > + > +STATIC int > +xfs_dm_inode_to_fh( > + struct inode *inode, > + dm_fid_t *dmfid, > + dm_fsid_t *dmfsid) > +{ > + xfs_inode_t *ip = XFS_I(inode); > + int error; > + struct xfs_fid xfid; > + > + /* Returns negative errors to DMAPI */ > + > + if (ip->i_mount->m_fixedfsid == NULL) > + return -EINVAL; > + error = xfs_fid2(ip, &xfid); > + if (error) > + return -error; /* Return negative error to DMAPI */ > + > + memcpy(dmfid, &xfid, sizeof(*dmfid)); > + memcpy(dmfsid, ip->i_mount->m_fixedfsid, sizeof(*dmfsid)); > + return 0; > +} > + > +STATIC void > +xfs_dm_get_fsid( > + struct super_block *sb, > + dm_fsid_t *fsid) > +{ > + memcpy(fsid, XFS_M(sb)->m_fixedfsid, sizeof(*fsid)); > +} > + > +/* > + * Filesystem operations accessed by the DMAPI core. > + */ > +static struct filesystem_dmapi_operations xfs_dmapiops = { > + .get_fsys_vector = xfs_dm_get_dmapiops, > + .fh_to_inode = xfs_dm_fh_to_inode, > + .get_invis_ops = xfs_dm_get_invis_ops, > + .inode_to_fh = xfs_dm_inode_to_fh, > + .get_fsid = xfs_dm_get_fsid, > +}; > + > static int __init > xfs_dm_init(void) > { > Index: linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.h > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/dmapi/xfs_dm.h 2007-09-15 10:35:50.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.h 2007-09-15 10:36:07.000000000 +0200 > @@ -18,9 +18,6 @@ > #ifndef __XFS_DM_H__ > #define __XFS_DM_H__ > > -extern int xfs_dm_get_fsys_vector(caddr_t); > - > extern struct file_system_type xfs_fs_type; > -extern struct filesystem_dmapi_operations xfs_dmapiops; > > #endif /* __XFS_DM_H__ */ > Index: linux-2.6-xfs/fs/xfs/dmapi/Makefile-linux-2.6 > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/dmapi/Makefile-linux-2.6 2007-09-15 10:35:50.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/dmapi/Makefile-linux-2.6 2007-09-15 10:36:07.000000000 +0200 > @@ -25,5 +25,4 @@ endif > > obj-$(CONFIG_XFS_DMAPI) += xfs_dmapi.o > > -xfs_dmapi-y += xfs_dm_fsops.o \ > - xfs_dm.o > +xfs_dmapi-y += xfs_dm.o > Index: linux-2.6-xfs/fs/xfs/dmapi/xfs_dm_fsops.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/dmapi/xfs_dm_fsops.c 2007-09-15 10:36:19.000000000 +0200 > +++ /dev/null 1970-01-01 00:00:00.000000000 +0000 > @@ -1,135 +0,0 @@ > -/* > - * Copyright (c) 2000-2006 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 "xfs.h" > -#include "xfs_fs.h" > -#include "xfs_types.h" > -#include "xfs_bit.h" > -#include "xfs_log.h" > -#include "xfs_inum.h" > -#include "xfs_clnt.h" > -#include "xfs_trans.h" > -#include "xfs_sb.h" > -#include "xfs_ag.h" > -#include "xfs_dir2.h" > -#include "xfs_alloc.h" > -#include "xfs_dmapi.h" > -#include "xfs_mount.h" > -#include "xfs_bmap_btree.h" > -#include "xfs_alloc_btree.h" > -#include "xfs_ialloc_btree.h" > -#include "xfs_dir2_sf.h" > -#include "xfs_attr_sf.h" > -#include "xfs_dinode.h" > -#include "xfs_inode.h" > -#include "xfs_btree.h" > -#include "xfs_ialloc.h" > -#include "xfs_itable.h" > -#include "xfs_bmap.h" > -#include "xfs_rw.h" > -#include "xfs_acl.h" > -#include "xfs_attr.h" > -#include "xfs_inode_item.h" > -#include "xfs_vnodeops.h" > -#include "xfs_vfsops.h" > -#include > -#include > -#include "xfs_dm.h" > - > - > -STATIC const struct file_operations * > -xfs_dm_get_invis_ops( > - struct inode *ip) > -{ > - return &xfs_invis_file_operations; > -} > - > -STATIC int > -xfs_dm_fh_to_inode( > - struct super_block *sb, > - struct inode **ip, > - dm_fid_t *dmfid) > -{ > - bhv_vnode_t *vp = NULL; > - xfs_mount_t *mp = XFS_M(sb); > - int error; > - struct xfs_fid xfid; > - > - /* Returns negative errors to DMAPI */ > - > - *ip = NULL; > - memcpy(&xfid, dmfid, sizeof(*dmfid)); > - if (xfid.fid_len) { /* file object handle */ > - error = xfs_vget(mp, &vp, &xfid); > - } > - else { /* filesystem handle */ > - error = xfs_root(mp, &vp); > - } > - if (vp && (error == 0)) > - *ip = vn_to_inode(vp); > - return -error; /* Return negative error to DMAPI */ > -} > - > -STATIC int > -xfs_dm_inode_to_fh( > - struct inode *inode, > - dm_fid_t *dmfid, > - dm_fsid_t *dmfsid) > -{ > - xfs_inode_t *ip = XFS_I(inode); > - int error; > - struct xfs_fid xfid; > - > - /* Returns negative errors to DMAPI */ > - > - if (ip->i_mount->m_fixedfsid == NULL) > - return -EINVAL; > - error = xfs_fid2(ip, &xfid); > - if (error) > - return -error; /* Return negative error to DMAPI */ > - > - memcpy(dmfid, &xfid, sizeof(*dmfid)); > - memcpy(dmfsid, ip->i_mount->m_fixedfsid, sizeof(*dmfsid)); > - return 0; > -} > - > -STATIC int > -xfs_dm_get_dmapiops( > - struct super_block *sb, > - void *addr) > -{ > - return -xfs_dm_get_fsys_vector(addr); > -} > - > -STATIC void > -xfs_dm_get_fsid( > - struct super_block *sb, > - dm_fsid_t *fsid) > -{ > - memcpy(fsid, XFS_M(sb)->m_fixedfsid, sizeof(*fsid)); > -} > - > -/* > - * Filesystem operations accessed by the DMAPI core. > - */ > -struct filesystem_dmapi_operations xfs_dmapiops = { > - .get_fsys_vector = xfs_dm_get_dmapiops, > - .fh_to_inode = xfs_dm_fh_to_inode, > - .get_invis_ops = xfs_dm_get_invis_ops, > - .inode_to_fh = xfs_dm_inode_to_fh, > - .get_fsid = xfs_dm_get_fsid, > -}; > > From owner-xfs@oss.sgi.com Thu Sep 27 17:53:20 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 27 Sep 2007 17:53:24 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) 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.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l8S0rGRi009166 for ; Thu, 27 Sep 2007 17:53:18 -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 KAA26338; Fri, 28 Sep 2007 10:53:11 +1000 Message-ID: <46FC50DF.2050907@sgi.com> Date: Fri, 28 Sep 2007 10:54:55 +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: xfs mailing list Subject: TAKE 971182 - [PATCH] kill xfs_dm_fsops.c Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4415/Thu Sep 27 13:02:21 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13156 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 kill xfs_dm_fsops.c No point having a separate file for these few methods, especially if we want to merge the crufty ops vector into the dmapiops one day. Signed-off-by: Christoph Hellwig Date: Fri Sep 28 10:51:03 AEST 2007 Workarea: soarer.melbourne.sgi.com:/home/vapo/isms/linux-xfs-patch-reviews Inspected by: 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:29798a fs/xfs/dmapi/Makefile - 1.28 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/Makefile.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h - pv 971182, author hch@lst.de, rv vapo - kill xfs_dm_fsops.c fs/xfs/dmapi/xfs_dm_fsops.c - 1.14 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/xfs_dm_fsops.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h - pv 971182, author hch@lst.de, rv vapo - kill xfs_dm_fsops.c fs/xfs/dmapi/xfs_dm.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/xfs_dm.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h - pv 971182, author hch@lst.de, rv vapo - kill xfs_dm_fsops.c fs/xfs/dmapi/xfs_dm.c - 1.58 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/xfs_dm.c.diff?r1=text&tr1=1.58&r2=text&tr2=1.57&f=h - pv 971182, author hch@lst.de, rv vapo - kill xfs_dm_fsops.c From owner-xfs@oss.sgi.com Fri Sep 28 00:37:15 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 28 Sep 2007 00:37:21 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) 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.3.0-r574664 Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.250]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8S7bDOd015631 for ; Fri, 28 Sep 2007 00:37:15 -0700 Received: by an-out-0708.google.com with SMTP id c38so482471ana for ; Fri, 28 Sep 2007 00:37:13 -0700 (PDT) Received: by 10.115.49.16 with SMTP id b16mr3530754wak.1190958945732; Thu, 27 Sep 2007 22:55:45 -0700 (PDT) Received: by 10.115.89.6 with HTTP; Thu, 27 Sep 2007 22:55:45 -0700 (PDT) Message-ID: Date: Fri, 28 Sep 2007 11:25:45 +0530 From: "Manoj Kumar Pradhan" To: xfs@oss.sgi.com Subject: kernel 2.6.9-42ELsmp MIME-Version: 1.0 X-Virus-Scanned: ClamAV 0.91.2/4418/Thu Sep 27 23:17:12 2007 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 553 X-archive-position: 13157 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: manojkp80@gmail.com Precedence: bulk X-list: xfs Hi, I am trying to build my RH kernel for XFS dmapi support. I learnt from your site that the correct kernel can be cvs checkout from oss.sgi.com. I tried the procedure indicated there to do so, but i cant login to ': psrever:cvs@oss.sgi.com:/cvs' with password "cvs". It says connection timed out. Is there any other way to get the kernel? Also I learnt that XFS dmapi is not supported on RHEL4, is it? Is there any list of RHEL kernel releases which can support XFS with DMAPI on x86_64 platforms? Thanks, Manoj [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Fri Sep 28 01:00:23 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 28 Sep 2007 01:00:27 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00, T_STOX_BOUND_090909_B autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l8S80J8r018845 for ; Fri, 28 Sep 2007 01:00:22 -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 SAA05657 for ; Fri, 28 Sep 2007 18:00:18 +1000 Message-ID: <46FCB57C.1040204@sgi.com> Date: Fri, 28 Sep 2007 18:04:12 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: [PATCH] Ensure sync flushes all dirty data to disk Content-Type: multipart/mixed; boundary="------------060608020509020208080001" X-Virus-Scanned: ClamAV 0.91.2/4418/Thu Sep 27 23:17:12 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13158 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. --------------060608020509020208080001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In xfs_fs_sync_super() treat a sync the same as a filesystem freeze. This is needed to force the log to disk for inodes which are not marked dirty in the Linux inode (the inodes are marked dirty on completion of the log I/O) and so sync_inodes() will not flush them. In xfs_fs_write_inode() a synchronous flush will not get an EAGAIN from xfs_inode_flush() and if an asynchronous flush returns EAGAIN we should pass it on to the caller. If we get an error while flushing the inode then re-dirty it so we can try again later. --------------060608020509020208080001 Content-Type: text/x-patch; name="sync.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sync.diff" --- fs/xfs/linux-2.6/xfs_super.c_1.398 2007-09-28 12:37:17.000000000 +1000 +++ fs/xfs/linux-2.6/xfs_super.c 2007-09-28 17:22:24.000000000 +1000 @@ -409,13 +409,8 @@ xfs_fs_write_inode( flags |= FLUSH_SYNC; } error = xfs_inode_flush(XFS_I(inode), flags); - if (error == EAGAIN) { - if (sync) - error = xfs_inode_flush(XFS_I(inode), - flags | FLUSH_LOG); - else - error = 0; - } + if (error) + mark_inode_dirty_sync(inode); return -error; } @@ -620,7 +615,7 @@ xfs_fs_sync_super( int error; int flags; - if (unlikely(sb->s_frozen == SB_FREEZE_WRITE)) { + if (wait || unlikely(sb->s_frozen == SB_FREEZE_WRITE)) { /* * First stage of freeze - no more writers will make progress * now we are here, so we flush delwri and delalloc buffers @@ -631,7 +626,7 @@ xfs_fs_sync_super( */ flags = SYNC_DATA_QUIESCE; } else - flags = SYNC_FSDATA | (wait ? SYNC_WAIT : 0); + flags = SYNC_FSDATA; error = xfs_sync(mp, flags); sb->s_dirt = 0; --------------060608020509020208080001-- From owner-xfs@oss.sgi.com Fri Sep 28 01:06:46 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 28 Sep 2007 01:07:58 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) 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.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l8S86fAT020026 for ; Fri, 28 Sep 2007 01:06:45 -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 SAA05886; Fri, 28 Sep 2007 18:06:35 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1116) id E8CD958C4C0A; Fri, 28 Sep 2007 18:06:34 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: PARTIAL TAKE 971186 - kill xfs_statvfs Message-Id: <20070928080634.E8CD958C4C0A@chook.melbourne.sgi.com> Date: Fri, 28 Sep 2007 18:06:34 +1000 (EST) From: tes@sgi.com (Tim Shimmin) X-Virus-Scanned: ClamAV 0.91.2/4418/Thu Sep 27 23:17:12 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13159 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 Kill off xfs_statvfs. We were already filling the Linux struct statfs anyway, and doing this trivial task directly in xfs_fs_statfs makes the code quite a bit cleaner. While I was at it I also moved copying attributes that don't change over the lifetime of the filesystem outside the superblock lock. xfs_fs_fill_super used to get the magic number and blocksize through xfs_statvfs, but assigning them directly is a lot cleaner and will save some stack space during mount. Signed-off-by: Christoph Hellwig Date: Fri Sep 28 18:05:12 AEST 2007 Workarea: chook.melbourne.sgi.com:/build/tes/2.6.x-xfs-quilt 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:29802a fs/xfs/xfs_vfsops.c - 1.544 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.544&r2=text&tr2=1.543&f=h fs/xfs/linux-2.6/xfs_linux.h - 1.160 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_linux.h.diff?r1=text&tr1=1.160&r2=text&tr2=1.159&f=h fs/xfs/linux-2.6/xfs_super.c - 1.399 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c.diff?r1=text&tr1=1.399&r2=text&tr2=1.398&f=h fs/xfs/xfs_vfsops.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h - Kill off xfs_statvfs. From owner-xfs@oss.sgi.com Fri Sep 28 06:16:23 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 28 Sep 2007 06:16:26 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8SDGJAp012643 for ; Fri, 28 Sep 2007 06:16:23 -0700 Received: from liberator.sandeen.net (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 91D2C1803C910 for ; Fri, 28 Sep 2007 08:16:19 -0500 (CDT) Message-ID: <46FCFEA3.5030704@sandeen.net> Date: Fri, 28 Sep 2007 08:16:19 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: xfs-oss Subject: [PATCH 2/2] use generic routines for xfs_highbit Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4419/Fri Sep 28 00:36:28 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13161 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 We can use the fls & fls64 routines (many of which have arch-specific assembly implementations) to implement xfs_highbit and xfs_highbit64. Tested on x86. Signed-off-by: Eric Sandeen Index: linux-2.6.22.i386/fs/xfs/xfs_bit.c =================================================================== --- linux-2.6.22.i386.orig/fs/xfs/xfs_bit.c +++ linux-2.6.22.i386/fs/xfs/xfs_bit.c @@ -25,46 +25,6 @@ * XFS bit manipulation routines, used in non-realtime code. */ -#ifndef HAVE_ARCH_HIGHBIT -/* - * Index of high bit number in byte, -1 for none set, 0..7 otherwise. - */ -static const char xfs_highbit[256] = { - -1, 0, 1, 1, 2, 2, 2, 2, /* 00 .. 07 */ - 3, 3, 3, 3, 3, 3, 3, 3, /* 08 .. 0f */ - 4, 4, 4, 4, 4, 4, 4, 4, /* 10 .. 17 */ - 4, 4, 4, 4, 4, 4, 4, 4, /* 18 .. 1f */ - 5, 5, 5, 5, 5, 5, 5, 5, /* 20 .. 27 */ - 5, 5, 5, 5, 5, 5, 5, 5, /* 28 .. 2f */ - 5, 5, 5, 5, 5, 5, 5, 5, /* 30 .. 37 */ - 5, 5, 5, 5, 5, 5, 5, 5, /* 38 .. 3f */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 40 .. 47 */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 48 .. 4f */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 50 .. 57 */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 58 .. 5f */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 60 .. 67 */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 68 .. 6f */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 70 .. 77 */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 78 .. 7f */ - 7, 7, 7, 7, 7, 7, 7, 7, /* 80 .. 87 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* 88 .. 8f */ - 7, 7, 7, 7, 7, 7, 7, 7, /* 90 .. 97 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* 98 .. 9f */ - 7, 7, 7, 7, 7, 7, 7, 7, /* a0 .. a7 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* a8 .. af */ - 7, 7, 7, 7, 7, 7, 7, 7, /* b0 .. b7 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* b8 .. bf */ - 7, 7, 7, 7, 7, 7, 7, 7, /* c0 .. c7 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* c8 .. cf */ - 7, 7, 7, 7, 7, 7, 7, 7, /* d0 .. d7 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* d8 .. df */ - 7, 7, 7, 7, 7, 7, 7, 7, /* e0 .. e7 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* e8 .. ef */ - 7, 7, 7, 7, 7, 7, 7, 7, /* f0 .. f7 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* f8 .. ff */ -}; -#endif - /* * xfs_highbit32: get high bit set out of 32-bit argument, -1 if none set. */ @@ -72,25 +32,9 @@ inline int xfs_highbit32( __uint32_t v) { -#ifdef HAVE_ARCH_HIGHBIT - return highbit32(v); -#else - int i; - - if (v & 0xffff0000) - if (v & 0xff000000) - i = 24; - else - i = 16; - else if (v & 0x0000ffff) - if (v & 0x0000ff00) - i = 8; - else - i = 0; - else - return -1; - return i + xfs_highbit[(v >> i) & 0xff]; -#endif + if (v) + return fls(v) - 1; + return -1; } /* @@ -120,11 +64,9 @@ int xfs_highbit64( __uint64_t v) { - __uint32_t h = (__uint32_t)(v >> 32); - - if (h) - return xfs_highbit32(h) + 32; - return xfs_highbit32((__uint32_t)v); + if (v) + return fls64(v) - 1; + return -1; } From owner-xfs@oss.sgi.com Fri Sep 28 06:16:03 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 28 Sep 2007 06:16:06 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8SDFweK012540 for ; Fri, 28 Sep 2007 06:16:03 -0700 Received: from liberator.sandeen.net (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 B40321803C910 for ; Fri, 28 Sep 2007 08:15:56 -0500 (CDT) Message-ID: <46FCFE8C.9020405@sandeen.net> Date: Fri, 28 Sep 2007 08:15:56 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: xfs-oss Subject: [PATCH 1/2] Use generic routines for xfs_next_bit Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4419/Fri Sep 28 00:36:28 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13160 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 We can use find_next_bit, which is assembly on some arches, to implement xfs_next_bit. Tested on x86. Signed-off-by: Eric Sandeen Index: linux-2.6.22.i386/fs/xfs/xfs_bit.c =================================================================== --- linux-2.6.22.i386.orig/fs/xfs/xfs_bit.c +++ linux-2.6.22.i386/fs/xfs/xfs_bit.c @@ -192,32 +192,16 @@ found: */ int xfs_next_bit(uint *map, uint size, uint start_bit) { - uint * p = ((unsigned int *) map) + (start_bit >> BIT_TO_WORD_SHIFT); - uint result = start_bit & ~(NBWORD - 1); - uint tmp; + int result; - size <<= BIT_TO_WORD_SHIFT; + size <<= BIT_TO_WORD_SHIFT; + if (start_bit >= size) /* beyond end of bitmap */ + return -1; - if (start_bit >= size) - return -1; - size -= result; - start_bit &= (NBWORD - 1); - if (start_bit) { - tmp = *p++; - /* set to zero first offset bits prior to start */ - tmp &= (~0U << start_bit); - if (tmp != 0U) - goto found; - result += NBWORD; - size -= NBWORD; - } - while (size) { - if ((tmp = *p++) != 0U) - goto found; - result += NBWORD; - size -= NBWORD; - } - return -1; -found: - return result + ffs(tmp) - 1; + result = find_next_bit((unsigned long *)map, size, start_bit); + + if (result == size) /* no bits set */ + return -1; + + return result; } From owner-xfs@oss.sgi.com Fri Sep 28 07:40:27 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 28 Sep 2007 07:40:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_40,J_CHICKENPOX_34, SPF_HELO_PASS autolearn=no version=3.3.0-r574664 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8SEeMYl031525 for ; Fri, 28 Sep 2007 07:40:27 -0700 Received: from liberator.sandeen.net (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 D58171803C910; Fri, 28 Sep 2007 09:40:22 -0500 (CDT) Message-ID: <46FD1256.6080201@sandeen.net> Date: Fri, 28 Sep 2007 09:40:22 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Manoj Kumar Pradhan CC: xfs@oss.sgi.com Subject: Re: kernel 2.6.9-42ELsmp References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4419/Fri Sep 28 00:36:28 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13162 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 Manoj Kumar Pradhan wrote: > Hi, > > I am trying to build my RH kernel for XFS dmapi support. I learnt from your > site that the correct kernel can be cvs checkout from oss.sgi.com. I tried > the procedure indicated there to do so, but i cant login to ': > psrever:cvs@oss.sgi.com:/cvs' with password "cvs". It says connection timed > out. You might try again: liberator:~/cvs sandeen$ export CVSROOT=':pserver:cvs@oss.sgi.com:/cvs' liberator:~/cvs sandeen$ cvs login Logging in to :pserver:cvs@oss.sgi.com:2401/cvs CVS password: liberator:~/cvs sandeen$ cvs co linux-2.6-xfs cvs checkout: Updating linux-2.g-xfs U linux-2.6-xfs/COPYING U linux-2.6-xfs/CREDITS ^Ccvs [checkout aborted]: received interrupt signal liberator:~/cvs sandeen$ works for me. Note, though, that the kernel you'll be checking out is not a RHEL4 kernel, but something more bleeding-edge, 2.6.23-rcX or so. > Is there any other way to get the kernel? > Also I learnt that XFS dmapi is not supported on RHEL4, is it? Like I said last time, no, at least not as far as I can remember. Although, now that I think harder, I think most of what dmapi needs is there, though, so depending on what you're doing, it may mostly work. Sorry, but I just don't remember all the details. Feel free to get the dmapi sources from the 2.6 tree, build against rhel4, and test. With some minor massaging, you could build dmapi as an external module. What are your plans for using it, if I may ask? > Is there any list of RHEL kernel releases which can support XFS with DMAPI > on x86_64 platforms? None that are official. SGI has shipped dmapi-capable RHEL4 kernels with CXFS, and that part is all GPL, so perhaps someone @sgi could take pity on you, or if you find someone who runs CXFS on RHEL4, they could give you the src.rpms :) -Eric From owner-xfs@oss.sgi.com Fri Sep 28 08:47:52 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 28 Sep 2007 08:47:58 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.0 required=5.0 tests=BAYES_50,RCVD_IN_PSBL, VIRUS_WARNING179 autolearn=no version=3.3.0-r574664 Received: from mx.sidi.istruzione.it (mx4.sidi.istruzione.it [193.206.15.65]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8SFloel014218 for ; Fri, 28 Sep 2007 08:47:52 -0700 Received: from localhost (unknown [127.0.0.1]) by mx4.sidi.istruzione.it (Mail Service) with ESMTP id 226055063D for ; Fri, 28 Sep 2007 17:27:48 +0200 (CEST) Content-Type: multipart/report; report-type=delivery-status; boundary="----------=_1190993268-8711-0" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Subject: VIRUS (Worm.SomeFool.P): IN UNA E-MAIL DA LEI INVIATA In-Reply-To: <20070928152746.12ED250644@mx4.sidi.istruzione.it> Message-ID: From: "Content-filter at mx4.sidi.istruzione.it" To: Date: Fri, 28 Sep 2007 17:27:48 +0200 (CEST) X-Virus-Scanned: ClamAV 0.91.2/4419/Fri Sep 28 00:36:28 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13163 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: postmaster@mx4.sidi.istruzione.it Precedence: bulk X-list: xfs This is a multi-part message in MIME format... ------------=_1190993268-8711-0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit VIRUS ALERT Il sistema di scansione ha rilevato un problema in una email presumibilmente inviata da Lei -> (), per il seguente destinatario: -> lucia.landi4@istruzione.it La consegna del messaggio non e' potuta avvenire Di seguito i riferimenti della e-Mail inviata: ------------------------- BEGIN HEADERS ----------------------------- Return-Path: Received: from istruzione.it (unknown [79.3.89.88]) by mx4.sidi.istruzione.it (Mail Service) with ESMTP id 12ED250644 for ; Fri, 28 Sep 2007 17:27:46 +0200 (CEST) From: linux-xfs@oss.sgi.com To: lucia.landi4@istruzione.it Subject: Re: Re: approved excel document Date: Fri, 28 Sep 2007 17:28:35 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016----=_NextPart_000_0016" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: <20070928152746.12ED250644@mx4.sidi.istruzione.it> -------------------------- END HEADERS ------------------------------ ------------=_1190993268-8711-0 Content-Type: message/delivery-status; name="dsn_status" Content-Disposition: inline; filename="dsn_status" Content-Transfer-Encoding: 7bit Content-Description: Delivery error report Reporting-MTA: dns; mx4.sidi.istruzione.it Received-From-MTA: smtp; mx.sidi.istruzione.it ([127.0.0.1]) Arrival-Date: Fri, 28 Sep 2007 17:27:47 +0200 (CEST) Original-Recipient: rfc822;lucia.landi4@istruzione.it Final-Recipient: rfc822;lucia.landi4@istruzione.it Action: failed Status: 5.7.1 Diagnostic-Code: smtp; 550-5.7.1 Rejected, id=08711-08 - VIRUS: 550 5.7.1 Worm.SomeFool.P Last-Attempt-Date: Fri, 28 Sep 2007 17:27:48 +0200 (CEST) ------------=_1190993268-8711-0 Content-Type: text/rfc822-headers; name="header" Content-Disposition: inline; filename="header" Content-Transfer-Encoding: 7bit Content-Description: Message headers Return-Path: Received: from istruzione.it (unknown [79.3.89.88]) by mx4.sidi.istruzione.it (Mail Service) with ESMTP id 12ED250644 for ; Fri, 28 Sep 2007 17:27:46 +0200 (CEST) From: linux-xfs@oss.sgi.com To: lucia.landi4@istruzione.it Subject: Re: Re: approved excel document Date: Fri, 28 Sep 2007 17:28:35 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016----=_NextPart_000_0016" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: <20070928152746.12ED250644@mx4.sidi.istruzione.it> ------------=_1190993268-8711-0-- From owner-xfs@oss.sgi.com Fri Sep 28 09:48:27 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 28 Sep 2007 09:48:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_40, T_STOX_BOUND_090909_B autolearn=ham version=3.3.0-r574664 Received: from slurp.thebarn.com (cattelan-host202.dsl.visi.com [208.42.117.202]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8SGmOiI028354 for ; Fri, 28 Sep 2007 09:48:27 -0700 Received: from [IPv6:::1] (slurp.thebarn.com [208.42.117.201]) (authenticated bits=0) by slurp.thebarn.com (8.14.0/8.13.8) with ESMTP id l8SGmKIY079338; Fri, 28 Sep 2007 11:48:21 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <46FD3054.9060803@thebarn.com> Date: Fri, 28 Sep 2007 11:48:20 -0500 From: Russell Cattelan User-Agent: Thunderbird 2.0.0.5 (X11/20070813) MIME-Version: 1.0 To: Manoj Kumar Pradhan CC: xfs@oss.sgi.com Subject: Re: kernel 2.6.9-42ELsmp References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------010607070702050807050907" X-Virus-Scanned: ClamAV 0.91.2/4420/Fri Sep 28 08:43:46 2007 on oss.sgi.com X-Virus-Scanned: ClamAV 0.91.1/4419/Fri Sep 28 02:36:28 2007 on slurp.thebarn.com X-Virus-Status: Clean X-archive-position: 13164 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: xfs This is a multi-part message in MIME format. --------------010607070702050807050907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Manoj Kumar Pradhan wrote: > Hi, > > I am trying to build my RH kernel for XFS dmapi support. I learnt from your > site that the correct kernel can be cvs checkout from oss.sgi.com. I tried > the procedure indicated there to do so, but i cant login to ': > psrever:cvs@oss.sgi.com:/cvs' with password "cvs". It says connection timed > > out. > Check your CVSROOT agin... the above line is not correct. http://oss.sgi.com/projects/xfs/source.html > Is there any other way to get the kernel? > Also I learnt that XFS dmapi is not supported on RHEL4, is it? > Is there any list of RHEL kernel releases which can support XFS with DMAPI > on x86_64 platforms? > The cvs tree on oss is not a rhel4 tree tho, it is a current linux release + latest xfs and kdb > Thanks, > Manoj > > > [[HTML alternate version deleted]] > > --------------010607070702050807050907 Content-Type: text/x-vcard; charset=utf-8; name="cattelan.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="cattelan.vcf" begin:vcard fn:Russell Cattelan n:Cattelan;Russell email;internet:cattelan@thebarn.com x-mozilla-html:FALSE version:2.1 end:vcard --------------010607070702050807050907-- From owner-xfs@oss.sgi.com Fri Sep 28 15:13:23 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 28 Sep 2007 15:13:28 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) 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.3.0-r574664 Received: from mx1.whoi.edu (tassadar.whoi.edu [128.128.76.63]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8SMDKRJ023234 for ; Fri, 28 Sep 2007 15:13:22 -0700 Received: by mx1.whoi.edu (Postfix, from userid 103) id ADB94162B61; Fri, 28 Sep 2007 17:40:47 -0400 (EDT) Received: from puck.litech.org (puck.litech.org [66.218.0.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.whoi.edu (Postfix) with ESMTP id 8FA95162B6A for ; Fri, 28 Sep 2007 17:40:44 -0400 (EDT) Date: Fri, 28 Sep 2007 17:40:43 -0400 (EDT) From: Benjamin Carr X-X-Sender: benc@puck.litech.org To: xfs@oss.sgi.com Subject: Truncated Filesystem Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Status: Clean X-Virus-Scanned: ClamAV 0.91.2/4420/Fri Sep 28 08:43:46 2007 on oss.sgi.com X-archive-position: 13165 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bcarr@whoi.edu Precedence: bulk X-list: xfs For the second time in two weeks, a system restart has resulted in a truncated filesystem on my server. The server is running 64bit SuSE with a fibrechannel connection to a Promise VTrak M500f. The array is populated with Hitachi 1TB drives. The filesystem should be ~12TB but is only 1.8TB after the system is brough online. I have tried to collect the relevant information for diagnosing the problem. I sought help on #xfs and was referred to the mailing list for help. If you can think of any other useflul information please let me know. -Ben ---------------------------------------------------------------------------- messages: Sep 28 16:14:13 climate kernel: attempt to access beyond end of device Sep 28 16:14:13 climate kernel: sdc1: rw=0, want=25390571776, limit=3915735307 Sep 28 16:14:13 climate kernel: I/O error in filesystem ("sdc1") meta-data dev sdc1 block 0x5e96560ff ("xfs_read_buf") error 5 buf count 512 Sep 28 16:14:13 climate kernel: XFS: size check 2 failed climate:/var/log # file -s /dev/sdc1 /dev/sdc1: SGI XFS filesystem data (blksz 4096, inosz 256, v2 dirs) climate:/var/log # grep sdc /proc/partitions 8 32 12695301632 sdc 8 33 1957867653 sdc1 climate:/var/log # xfs_db -r /dev/sdc1 xfs_db> sb 0 xfs_db> p magicnum = 0x58465342 blocksize = 4096 dblocks = 3173821472 rblocks = 0 rextents = 0 uuid = 55e7458f-309a-43e4-90ca-91e72ac63f48 logstart = 2147483652 rootino = 128 rbmino = 129 rsumino = 130 rextsize = 16 agblocks = 99181921 agcount = 32 rbmblocks = 0 logblocks = 32768 versionnum = 0x3084 sectsize = 512 inodesize = 256 inopblock = 16 fname = "\000\000\000\000\000\000\000\000\000\000\000\000" blocklog = 12 sectlog = 9 inodelog = 8 inopblog = 4 agblklog = 27 rextslog = 0 inprogress = 0 imax_pct = 25 icount = 1472 ifree = 76 fdblocks = 3166809019 frextents = 0 uquotino = 0 gquotino = 0 qflags = 0 flags = 0 shared_vn = 0 inoalignmt = 2 unit = 0 width = 0 dirblklog = 0 logsectlog = 0 logsectsize = 0 logsunit = 0 features2 = 0 xfs_db> sb 1 xfs_db> p magicnum = 0x58465342 blocksize = 4096 dblocks = 3173821472 rblocks = 0 rextents = 0 uuid = 55e7458f-309a-43e4-90ca-91e72ac63f48 logstart = 2147483652 rootino = null rbmino = null rsumino = null rextsize = 16 agblocks = 99181921 agcount = 32 rbmblocks = 0 logblocks = 32768 versionnum = 0x3084 sectsize = 512 inodesize = 256 inopblock = 16 fname = "\000\000\000\000\000\000\000\000\000\000\000\000" blocklog = 12 sectlog = 9 inodelog = 8 inopblog = 4 agblklog = 27 rextslog = 0 inprogress = 1 imax_pct = 25 icount = 0 ifree = 0 fdblocks = 3173788576 frextents = 0 uquotino = 0 gquotino = 0 qflags = 0 flags = 0 shared_vn = 0 inoalignmt = 2 unit = 0 width = 0 dirblklog = 0 logsectlog = 0 logsectsize = 0 logsunit = 0 features2 = 0 xfs_db> sb 1 xfs_db> p magicnum = 0x58465342 blocksize = 4096 dblocks = 3173821472 rblocks = 0 rextents = 0 uuid = 55e7458f-309a-43e4-90ca-91e72ac63f48 logstart = 2147483652 rootino = null rbmino = null rsumino = null rextsize = 16 agblocks = 99181921 agcount = 32 rbmblocks = 0 logblocks = 32768 versionnum = 0x3084 sectsize = 512 inodesize = 256 inopblock = 16 fname = "\000\000\000\000\000\000\000\000\000\000\000\000" blocklog = 12 sectlog = 9 inodelog = 8 inopblog = 4 agblklog = 27 rextslog = 0 inprogress = 1 imax_pct = 25 icount = 0 ifree = 0 fdblocks = 3173788576 frextents = 0 uquotino = 0 gquotino = 0 qflags = 0 flags = 0 shared_vn = 0 inoalignmt = 2 unit = 0 width = 0 dirblklog = 0 logsectlog = 0 logsectsize = 0 logsunit = 0 features2 = 0 climate:~ # time xfs_check /dev/sdc1 XFS: totally zeroed log can't seek in filesystem at bb 3967276840 can't read superblock for ag 5 can't seek in filesystem at bb 4760732208 can't read superblock for ag 6 can't seek in filesystem at bb 5554187576 can't read superblock for ag 7 can't seek in filesystem at bb 6347642944 can't read superblock for ag 8 can't seek in filesystem at bb 7141098312 can't read superblock for ag 9 can't seek in filesystem at bb 7934553680 can't read superblock for ag 10 can't seek in filesystem at bb 8728009048 can't read superblock for ag 11 can't seek in filesystem at bb 9521464416 can't read superblock for ag 12 can't seek in filesystem at bb 10314919784 can't read superblock for ag 13 can't seek in filesystem at bb 11108375152 can't read superblock for ag 14 can't seek in filesystem at bb 11901830520 can't read superblock for ag 15 can't seek in filesystem at bb 12695285888 can't read superblock for ag 16 can't seek in filesystem at bb 13488741256 can't read superblock for ag 17 can't seek in filesystem at bb 14282196624 can't read superblock for ag 18 can't seek in filesystem at bb 15075651992 can't read superblock for ag 19 can't seek in filesystem at bb 15869107360 can't read superblock for ag 20 can't seek in filesystem at bb 16662562728 can't read superblock for ag 21 can't seek in filesystem at bb 17456018096 can't read superblock for ag 22 can't seek in filesystem at bb 18249473464 can't read superblock for ag 23 can't seek in filesystem at bb 19042928832 can't read superblock for ag 24 can't seek in filesystem at bb 19836384200 can't read superblock for ag 25 can't seek in filesystem at bb 20629839568 can't read superblock for ag 26 can't seek in filesystem at bb 21423294936 can't read superblock for ag 27 can't seek in filesystem at bb 22216750304 can't read superblock for ag 28 can't seek in filesystem at bb 23010205672 can't read superblock for ag 29 can't seek in filesystem at bb 23803661040 can't read superblock for ag 30 can't seek in filesystem at bb 24597116408 can't read superblock for ag 31 From owner-xfs@oss.sgi.com Fri Sep 28 15:22:16 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 28 Sep 2007 15:22:20 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8SMMFkM024703 for ; Fri, 28 Sep 2007 15:22:16 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 894B61C00022B; Fri, 28 Sep 2007 18:22:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 8422E4019BD2; Fri, 28 Sep 2007 18:22:08 -0400 (EDT) Date: Fri, 28 Sep 2007 18:22:08 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Benjamin Carr cc: xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: Truncated Filesystem In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/4420/Fri Sep 28 08:43:46 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13166 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 Including LKML on this one as it may be a partition size limit? Sdc1 is not 11TB. Justin. On Fri, 28 Sep 2007, Benjamin Carr wrote: > For the second time in two weeks, a system restart has resulted in a > truncated filesystem on my server. The server is running 64bit SuSE with a > fibrechannel connection to a Promise VTrak M500f. The array is populated > with Hitachi 1TB drives. The filesystem should be ~12TB but is only 1.8TB > after the system is brough online. > > I have tried to collect the relevant information for diagnosing the > problem. I sought help on #xfs and was referred to the mailing list for > help. > > If you can think of any other useflul information please let me know. > > -Ben > > ---------------------------------------------------------------------------- > > messages: > Sep 28 16:14:13 climate kernel: attempt to access beyond end of device > Sep 28 16:14:13 climate kernel: sdc1: rw=0, want=25390571776, > limit=3915735307 > Sep 28 16:14:13 climate kernel: I/O error in filesystem ("sdc1") meta-data > dev sdc1 block 0x5e96560ff ("xfs_read_buf") error 5 buf count 512 > Sep 28 16:14:13 climate kernel: XFS: size check 2 failed > > climate:/var/log # file -s /dev/sdc1 > /dev/sdc1: SGI XFS filesystem data (blksz 4096, inosz 256, v2 dirs) > > climate:/var/log # grep sdc /proc/partitions > 8 32 12695301632 sdc > 8 33 1957867653 sdc1 > > climate:/var/log # xfs_db -r /dev/sdc1 > xfs_db> sb 0 > xfs_db> p > magicnum = 0x58465342 > blocksize = 4096 > dblocks = 3173821472 > rblocks = 0 > rextents = 0 > uuid = 55e7458f-309a-43e4-90ca-91e72ac63f48 > logstart = 2147483652 > rootino = 128 > rbmino = 129 > rsumino = 130 > rextsize = 16 > agblocks = 99181921 > agcount = 32 > rbmblocks = 0 > logblocks = 32768 > versionnum = 0x3084 > sectsize = 512 > inodesize = 256 > inopblock = 16 > fname = "\000\000\000\000\000\000\000\000\000\000\000\000" > blocklog = 12 > sectlog = 9 > inodelog = 8 > inopblog = 4 > agblklog = 27 > rextslog = 0 > inprogress = 0 > imax_pct = 25 > icount = 1472 > ifree = 76 > fdblocks = 3166809019 > frextents = 0 > uquotino = 0 > gquotino = 0 > qflags = 0 > flags = 0 > shared_vn = 0 > inoalignmt = 2 > unit = 0 > width = 0 > dirblklog = 0 > logsectlog = 0 > logsectsize = 0 > logsunit = 0 > features2 = 0 > xfs_db> sb 1 > xfs_db> p > magicnum = 0x58465342 > blocksize = 4096 > dblocks = 3173821472 > rblocks = 0 > rextents = 0 > uuid = 55e7458f-309a-43e4-90ca-91e72ac63f48 > logstart = 2147483652 > rootino = null > rbmino = null > rsumino = null > rextsize = 16 > agblocks = 99181921 > agcount = 32 > rbmblocks = 0 > logblocks = 32768 > versionnum = 0x3084 > sectsize = 512 > inodesize = 256 > inopblock = 16 > fname = "\000\000\000\000\000\000\000\000\000\000\000\000" > blocklog = 12 > sectlog = 9 > inodelog = 8 > inopblog = 4 > agblklog = 27 > rextslog = 0 > inprogress = 1 > imax_pct = 25 > icount = 0 > ifree = 0 > fdblocks = 3173788576 > frextents = 0 > uquotino = 0 > gquotino = 0 > qflags = 0 > flags = 0 > shared_vn = 0 > inoalignmt = 2 > unit = 0 > width = 0 > dirblklog = 0 > logsectlog = 0 > logsectsize = 0 > logsunit = 0 > features2 = 0 > xfs_db> sb 1 > xfs_db> p > magicnum = 0x58465342 > blocksize = 4096 > dblocks = 3173821472 > rblocks = 0 > rextents = 0 > uuid = 55e7458f-309a-43e4-90ca-91e72ac63f48 > logstart = 2147483652 > rootino = null > rbmino = null > rsumino = null > rextsize = 16 > agblocks = 99181921 > agcount = 32 > rbmblocks = 0 > logblocks = 32768 > versionnum = 0x3084 > sectsize = 512 > inodesize = 256 > inopblock = 16 > fname = "\000\000\000\000\000\000\000\000\000\000\000\000" > blocklog = 12 > sectlog = 9 > inodelog = 8 > inopblog = 4 > agblklog = 27 > rextslog = 0 > inprogress = 1 > imax_pct = 25 > icount = 0 > ifree = 0 > fdblocks = 3173788576 > frextents = 0 > uquotino = 0 > gquotino = 0 > qflags = 0 > flags = 0 > shared_vn = 0 > inoalignmt = 2 > unit = 0 > width = 0 > dirblklog = 0 > logsectlog = 0 > logsectsize = 0 > logsunit = 0 > features2 = 0 > > climate:~ # time xfs_check /dev/sdc1 > XFS: totally zeroed log > can't seek in filesystem at bb 3967276840 > can't read superblock for ag 5 > can't seek in filesystem at bb 4760732208 > can't read superblock for ag 6 > can't seek in filesystem at bb 5554187576 > can't read superblock for ag 7 > can't seek in filesystem at bb 6347642944 > can't read superblock for ag 8 > can't seek in filesystem at bb 7141098312 > can't read superblock for ag 9 > can't seek in filesystem at bb 7934553680 > can't read superblock for ag 10 > can't seek in filesystem at bb 8728009048 > can't read superblock for ag 11 > can't seek in filesystem at bb 9521464416 > can't read superblock for ag 12 > can't seek in filesystem at bb 10314919784 > can't read superblock for ag 13 > can't seek in filesystem at bb 11108375152 > can't read superblock for ag 14 > can't seek in filesystem at bb 11901830520 > can't read superblock for ag 15 > can't seek in filesystem at bb 12695285888 > can't read superblock for ag 16 > can't seek in filesystem at bb 13488741256 > can't read superblock for ag 17 > can't seek in filesystem at bb 14282196624 > can't read superblock for ag 18 > can't seek in filesystem at bb 15075651992 > can't read superblock for ag 19 > can't seek in filesystem at bb 15869107360 > can't read superblock for ag 20 > can't seek in filesystem at bb 16662562728 > can't read superblock for ag 21 > can't seek in filesystem at bb 17456018096 > can't read superblock for ag 22 > can't seek in filesystem at bb 18249473464 > can't read superblock for ag 23 > can't seek in filesystem at bb 19042928832 > can't read superblock for ag 24 > can't seek in filesystem at bb 19836384200 > can't read superblock for ag 25 > can't seek in filesystem at bb 20629839568 > can't read superblock for ag 26 > can't seek in filesystem at bb 21423294936 > can't read superblock for ag 27 > can't seek in filesystem at bb 22216750304 > can't read superblock for ag 28 > can't seek in filesystem at bb 23010205672 > can't read superblock for ag 29 > can't seek in filesystem at bb 23803661040 > can't read superblock for ag 30 > can't seek in filesystem at bb 24597116408 > can't read superblock for ag 31 > > From owner-xfs@oss.sgi.com Fri Sep 28 16:36:41 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 28 Sep 2007 16:36:44 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8SNae9d008858 for ; Fri, 28 Sep 2007 16:36:41 -0700 Received: from liberator.sandeen.net (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 6F7F518075632; Fri, 28 Sep 2007 18:36:37 -0500 (CDT) Message-ID: <46FD9006.6050807@sandeen.net> Date: Fri, 28 Sep 2007 18:36:38 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Justin Piszcz CC: Benjamin Carr , xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: Truncated Filesystem References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4422/Fri Sep 28 14:44:56 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13167 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 Justin Piszcz wrote: > Including LKML on this one as it may be a partition size limit? Sdc1 is > not 11TB. > > Justin. Yup saw the same thing: (1957867653*1024)/1024/1024/1024/1024 = 1.82T I'm afraid you don't have a truncated filesystem, you have a truncated block device. I'm afraid this is not an xfs problem... you need to figure out what happened to sdc1 (for example, why doesn't it extend to the end of sdc?) -Eric From owner-xfs@oss.sgi.com Fri Sep 28 17:35:33 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 28 Sep 2007 17:35:37 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from terminus.zytor.com ([198.137.202.10]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8T0ZV0C024209 for ; Fri, 28 Sep 2007 17:35:32 -0700 Received: from mail.hos.anvin.org (c-67-169-144-158.hsd1.ca.comcast.net [67.169.144.158]) (authenticated bits=0) by terminus.zytor.com (8.14.1/8.13.8) with ESMTP id l8T00ZPE017425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Sep 2007 17:00:36 -0700 Received: from tazenda.hos.anvin.org (tazenda.hos.anvin.org [172.27.0.16]) by mail.hos.anvin.org (8.13.8/8.13.8) with ESMTP id l8T00YdD012668; Fri, 28 Sep 2007 17:00:34 -0700 Received: from tazenda.hos.anvin.org (localhost.localdomain [127.0.0.1]) by tazenda.hos.anvin.org (8.14.1/8.13.6) with ESMTP id l8T00Vm9007826; Fri, 28 Sep 2007 17:00:33 -0700 Message-ID: <46FD959E.5030009@zytor.com> Date: Fri, 28 Sep 2007 17:00:30 -0700 From: "H. Peter Anvin" User-Agent: Thunderbird 2.0.0.0 (X11/20070419) MIME-Version: 1.0 To: Eric Sandeen CC: Justin Piszcz , Benjamin Carr , xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: Truncated Filesystem References: <46FD9006.6050807@sandeen.net> In-Reply-To: <46FD9006.6050807@sandeen.net> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4422/Fri Sep 28 14:44:56 2007 on oss.sgi.com X-Virus-Scanned: ClamAV 0.91.2/4421/Fri Sep 28 14:09:13 2007 on terminus.zytor.com X-Virus-Status: Clean X-archive-position: 13168 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hpa@zytor.com Precedence: bulk X-list: xfs Eric Sandeen wrote: > Justin Piszcz wrote: >> Including LKML on this one as it may be a partition size limit? Sdc1 is >> not 11TB. >> >> Justin. > > Yup saw the same thing: > > (1957867653*1024)/1024/1024/1024/1024 = 1.82T > > I'm afraid you don't have a truncated filesystem, you have a truncated > block device. I'm afraid this is not an xfs problem... you need to > figure out what happened to sdc1 (for example, why doesn't it extend to > the end of sdc?) > What kind of partition table is it? MS-DOS partition tables have a 2 TB limit. -hpa From owner-xfs@oss.sgi.com Fri Sep 28 17:49:18 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 28 Sep 2007 17:49:21 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) 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.3.0-r574664 Received: from mx1.whoi.edu (zeratul.whoi.edu [128.128.76.62]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8T0nEob028543 for ; Fri, 28 Sep 2007 17:49:18 -0700 Received: by mx1.whoi.edu (Postfix, from userid 103) id 72DE3169E01; Fri, 28 Sep 2007 20:49:15 -0400 (EDT) Received: from puck.litech.org (puck.litech.org [66.218.0.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.whoi.edu (Postfix) with ESMTP id E1B3A169DE9; Fri, 28 Sep 2007 20:49:12 -0400 (EDT) Date: Fri, 28 Sep 2007 20:49:12 -0400 (EDT) From: Benjamin Carr X-X-Sender: benc@puck.litech.org To: "H. Peter Anvin" Cc: Eric Sandeen , Justin Piszcz , xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: Truncated Filesystem In-Reply-To: <46FD959E.5030009@zytor.com> Message-ID: References: <46FD9006.6050807@sandeen.net> <46FD959E.5030009@zytor.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Status: Clean X-Virus-Scanned: ClamAV 0.91.2/4423/Fri Sep 28 16:56:49 2007 on oss.sgi.com X-archive-position: 13169 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bcarr@whoi.edu Precedence: bulk X-list: xfs > What kind of partition table is it? MS-DOS partition tables have a 2 TB > limit. Hadn't thought of that, doesn't look good. -Ben sudo fdisk -l /dev/sdc1 benc's password: Disk /dev/sdc1: 2004.8 GB, 2004856477184 bytes 255 heads, 63 sectors/track, 243743 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk /dev/sdc1 doesn't contain a valid partition table From owner-xfs@oss.sgi.com Fri Sep 28 17:59:14 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 28 Sep 2007 17:59:17 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from terminus.zytor.com ([198.137.202.10]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8T0xCDb031513 for ; Fri, 28 Sep 2007 17:59:14 -0700 Received: from mail.hos.anvin.org (c-67-169-144-158.hsd1.ca.comcast.net [67.169.144.158]) (authenticated bits=0) by terminus.zytor.com (8.14.1/8.13.8) with ESMTP id l8T0x7DC027690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Sep 2007 17:59:08 -0700 Received: from tazenda.hos.anvin.org (tazenda.hos.anvin.org [172.27.0.16]) by mail.hos.anvin.org (8.13.8/8.13.8) with ESMTP id l8T0x6lZ013088; Fri, 28 Sep 2007 17:59:06 -0700 Received: from tazenda.hos.anvin.org (localhost.localdomain [127.0.0.1]) by tazenda.hos.anvin.org (8.14.1/8.13.6) with ESMTP id l8T0x6Q7016763; Fri, 28 Sep 2007 17:59:06 -0700 Message-ID: <46FDA35A.8040504@zytor.com> Date: Fri, 28 Sep 2007 17:59:06 -0700 From: "H. Peter Anvin" User-Agent: Thunderbird 2.0.0.0 (X11/20070419) MIME-Version: 1.0 To: Benjamin Carr CC: Eric Sandeen , Justin Piszcz , xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: Truncated Filesystem References: <46FD9006.6050807@sandeen.net> <46FD959E.5030009@zytor.com> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4423/Fri Sep 28 16:56:49 2007 on oss.sgi.com X-Virus-Scanned: ClamAV 0.91.2/4423/Fri Sep 28 16:56:49 2007 on terminus.zytor.com X-Virus-Status: Clean X-archive-position: 13170 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hpa@zytor.com Precedence: bulk X-list: xfs Benjamin Carr wrote: >> What kind of partition table is it? MS-DOS partition tables have a 2 TB >> limit. > > Hadn't thought of that, doesn't look good. > -Ben > > sudo fdisk -l /dev/sdc1 ^^^^^^^^^ Uh... > benc's password: > > Disk /dev/sdc1: 2004.8 GB, 2004856477184 bytes > 255 heads, 63 sectors/track, 243743 cylinders > Units = cylinders of 16065 * 512 = 8225280 bytes > > Disk /dev/sdc1 doesn't contain a valid partition table > From owner-xfs@oss.sgi.com Fri Sep 28 18:06:27 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 28 Sep 2007 18:06:30 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) 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.3.0-r574664 Received: from mx1.whoi.edu (zeratul.whoi.edu [128.128.76.62]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8T16PMN003050 for ; Fri, 28 Sep 2007 18:06:27 -0700 Received: by mx1.whoi.edu (Postfix, from userid 103) id 7EEDA169E9A; Fri, 28 Sep 2007 21:06:26 -0400 (EDT) Received: from puck.litech.org (puck.litech.org [66.218.0.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.whoi.edu (Postfix) with ESMTP id AC92C169E6A; Fri, 28 Sep 2007 21:06:23 -0400 (EDT) Date: Fri, 28 Sep 2007 21:06:22 -0400 (EDT) From: Benjamin Carr X-X-Sender: benc@puck.litech.org To: "H. Peter Anvin" Cc: Eric Sandeen , Justin Piszcz , xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: Truncated Filesystem In-Reply-To: <46FDA35A.8040504@zytor.com> Message-ID: References: <46FD9006.6050807@sandeen.net> <46FD959E.5030009@zytor.com> <46FDA35A.8040504@zytor.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Status: Clean X-Virus-Scanned: ClamAV 0.91.2/4423/Fri Sep 28 16:56:49 2007 on oss.sgi.com X-archive-position: 13171 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bcarr@whoi.edu Precedence: bulk X-list: xfs > > sudo fdisk -l /dev/sdc1 > ^^^^^^^^^ Uh... yeah, long day: Disk /dev/sdc: 12999.9 GB, 12999988871168 bytes 255 heads, 63 sectors/track, 1580491 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdc1 1 243744 1957867653+ 83 Linux From owner-xfs@oss.sgi.com Fri Sep 28 18:16:47 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 28 Sep 2007 18:16:51 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from terminus.zytor.com ([198.137.202.10]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8T1Gjdd008610 for ; Fri, 28 Sep 2007 18:16:47 -0700 Received: from mail.hos.anvin.org (c-67-169-144-158.hsd1.ca.comcast.net [67.169.144.158]) (authenticated bits=0) by terminus.zytor.com (8.14.1/8.13.8) with ESMTP id l8T1Gedp030557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Sep 2007 18:16:42 -0700 Received: from tazenda.hos.anvin.org (tazenda.hos.anvin.org [172.27.0.16]) by mail.hos.anvin.org (8.13.8/8.13.8) with ESMTP id l8T1Gebp013228; Fri, 28 Sep 2007 18:16:40 -0700 Received: from tazenda.hos.anvin.org (localhost.localdomain [127.0.0.1]) by tazenda.hos.anvin.org (8.14.1/8.13.6) with ESMTP id l8T1Ge2O017233; Fri, 28 Sep 2007 18:16:40 -0700 Message-ID: <46FDA778.1070500@zytor.com> Date: Fri, 28 Sep 2007 18:16:40 -0700 From: "H. Peter Anvin" User-Agent: Thunderbird 2.0.0.0 (X11/20070419) MIME-Version: 1.0 To: Benjamin Carr CC: Eric Sandeen , Justin Piszcz , xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: Truncated Filesystem References: <46FD9006.6050807@sandeen.net> <46FD959E.5030009@zytor.com> <46FDA35A.8040504@zytor.com> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4423/Fri Sep 28 16:56:49 2007 on oss.sgi.com X-Virus-Scanned: ClamAV 0.91.2/4423/Fri Sep 28 16:56:49 2007 on terminus.zytor.com X-Virus-Status: Clean X-archive-position: 13172 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hpa@zytor.com Precedence: bulk X-list: xfs Benjamin Carr wrote: >>> sudo fdisk -l /dev/sdc1 >> ^^^^^^^^^ Uh... > > yeah, long day: > > Disk /dev/sdc: 12999.9 GB, 12999988871168 bytes > 255 heads, 63 sectors/track, 1580491 cylinders > Units = cylinders of 16065 * 512 = 8225280 bytes > > Device Boot Start End Blocks Id System > /dev/sdc1 1 243744 1957867653+ 83 Linux > Looks like an MS-DOS partition table, indeed. -hpa From owner-xfs@oss.sgi.com Fri Sep 28 19:14:59 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 28 Sep 2007 19:15:03 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) 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.3.0-r574664 Received: from hogwarts.egr.duke.edu (hogwarts.egr.duke.edu [152.3.195.84]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8T2EtMi021245 for ; Fri, 28 Sep 2007 19:14:58 -0700 Received: from hogwarts.egr.duke.edu (localhost.localdomain [127.0.0.1]) by hogwarts.egr.duke.edu (8.13.1/8.13.1) with ESMTP id l8T1nuBL023205; Fri, 28 Sep 2007 21:49:56 -0400 Received: from localhost (jlb@localhost) by hogwarts.egr.duke.edu (8.13.1/8.13.1/Submit) with ESMTP id l8T1ntIx023202; Fri, 28 Sep 2007 21:49:55 -0400 X-Authentication-Warning: hogwarts.egr.duke.edu: jlb owned process doing -bs Date: Fri, 28 Sep 2007 21:49:55 -0400 (EDT) From: Joshua Baker-LePain X-X-Sender: jlb@hogwarts.egr.duke.edu To: Benjamin Carr cc: "H. Peter Anvin" , Eric Sandeen , Justin Piszcz , xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: Truncated Filesystem In-Reply-To: Message-ID: References: <46FD9006.6050807@sandeen.net> <46FD959E.5030009@zytor.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/4423/Fri Sep 28 16:56:49 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13173 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jlb17@duke.edu Precedence: bulk X-list: xfs On Fri, 28 Sep 2007 at 8:49pm, Benjamin Carr wrote >> What kind of partition table is it? MS-DOS partition tables have a 2 TB >> limit. > > Hadn't thought of that, doesn't look good. > -Ben > > sudo fdisk -l /dev/sdc1 > benc's password: Issue number one -- don't use fdisk, as it doesn't support devices that big. Use parted instead: parted /dev/sdc mklabel gpt mkpart primary ext2 0 11TB quit where you may have to sub some other value for the "11TB" in the mkpart line -- I forget the exact syntax. -- Joshua Baker-LePain QB3 Shared Cluster Sysadmin UCSF From owner-xfs@oss.sgi.com Fri Sep 28 19:15:23 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 28 Sep 2007 19:15:26 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from mx1.whoi.edu (zeratul.whoi.edu [128.128.76.62]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8T2FLQL021425 for ; Fri, 28 Sep 2007 19:15:22 -0700 Received: by mx1.whoi.edu (Postfix, from userid 103) id 06790169E9A; Fri, 28 Sep 2007 22:15:22 -0400 (EDT) Received: from puck.litech.org (puck.litech.org [66.218.0.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.whoi.edu (Postfix) with ESMTP id 6D739169E6A; Fri, 28 Sep 2007 22:15:19 -0400 (EDT) Date: Fri, 28 Sep 2007 22:15:18 -0400 (EDT) From: Benjamin Carr X-X-Sender: benc@puck.litech.org To: Joshua Baker-LePain Cc: "H. Peter Anvin" , Eric Sandeen , Justin Piszcz , xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: Truncated Filesystem In-Reply-To: Message-ID: References: <46FD9006.6050807@sandeen.net> <46FD959E.5030009@zytor.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Status: Clean X-Virus-Scanned: ClamAV 0.91.2/4423/Fri Sep 28 16:56:49 2007 on oss.sgi.com X-archive-position: 13174 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bcarr@whoi.edu Precedence: bulk X-list: xfs > >> What kind of partition table is it? MS-DOS partition tables have a 2 TB > >> limit. > Issue number one -- don't use fdisk, as it doesn't support devices that > big. Use parted instead: climate:~ benc$ sudo parted /dev/sdc check 1 Warning: Partition 1 is 2005GB, but the file system is 13TB. Yeah, that is a problem. From owner-xfs@oss.sgi.com Sat Sep 29 00:25:00 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 29 Sep 2007 00:25:11 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) 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.3.0-r574664 Received: from the-village.bc.nu (outpipe-village-512-1.bc.nu [81.2.110.250] (may be forged)) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8T7OuHC009549 for ; Sat, 29 Sep 2007 00:25:00 -0700 Received: from the-village.bc.nu (localhost.localdomain [127.0.0.1]) by the-village.bc.nu (8.14.1/8.13.8) with ESMTP id l8T6Qrcc001941; Sat, 29 Sep 2007 07:26:54 +0100 Date: Sat, 29 Sep 2007 07:26:53 +0100 From: Alan Cox To: Benjamin Carr Cc: "H. Peter Anvin" , Eric Sandeen , Justin Piszcz , xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: Truncated Filesystem Message-ID: <20070929072653.4e706888@the-village.bc.nu> In-Reply-To: References: <46FD9006.6050807@sandeen.net> <46FD959E.5030009@zytor.com> X-Mailer: Claws Mail 2.10.0 (GTK+ 2.10.14; i386-redhat-linux-gnu) Organization: Red Hat UK Cyf., Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, Y Deyrnas Gyfunol. Cofrestrwyd yng Nghymru a Lloegr o'r rhif cofrestru 3798903 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4427/Fri Sep 28 22:48:58 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13175 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: xfs On Fri, 28 Sep 2007 20:49:12 -0400 (EDT) Benjamin Carr wrote: > > What kind of partition table is it? MS-DOS partition tables have a 2 TB > > limit. > > Hadn't thought of that, doesn't look good. > -Ben > > sudo fdisk -l /dev/sdc1 > benc's password: That would be on /dev/sdc surely ? From owner-xfs@oss.sgi.com Sat Sep 29 02:26:39 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 29 Sep 2007 02:26:42 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_DYNAMIC autolearn=no version=3.3.0-r574664 Received: from ty.sabi.co.UK (82-69-39-138.dsl.in-addr.zen.co.uk [82.69.39.138]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8T9QapA024685 for ; Sat, 29 Sep 2007 02:26:39 -0700 Received: from from [127.0.0.1] (helo=base.ty.sabi.co.UK) by ty.sabi.co.UK with esmtp(Exim 4.66 #1) id 1IbYaz-0003IA-W0 for ; Sat, 29 Sep 2007 10:26:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18174.6741.713682.563043@base.ty.sabi.co.UK> Date: Sat, 29 Sep 2007 10:26:45 +0100 X-Face: SMJE]JPYVBO-9UR%/8d'mG.F!@.,l@c[f'[%S8'BZIcbQc3/">GrXDwb#;fTRGNmHr^JFb SAptvwWc,0+z+~p~"Gdr4H$(|N(yF(wwCM2bW0~U?HPEE^fkPGx^u[*[yV.gyB!hDOli}EF[\cW*S H&spRGFL}{`bj1TaD^l/"[ msn( /TH#THs{Hpj>)]f> Subject: Re: Truncated Filesystem In-Reply-To: References: <46FD9006.6050807@sandeen.net> <46FD959E.5030009@zytor.com> X-Mailer: VM 7.17 under 21.5 (beta28) XEmacs Lucid From: pg_mh@sabi.co.UK (Peter Grandi) X-Disclaimer: This message contains only personal opinions X-Virus-Scanned: ClamAV 0.91.2/4429/Fri Sep 28 23:49:25 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13176 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pg_mh@sabi.co.UK Precedence: bulk X-list: xfs >>> On Fri, 28 Sep 2007 22:15:18 -0400 (EDT), Benjamin Carr >>> said: [ ... ] bcarr> climate:~ benc$ sudo parted /dev/sdc check 1 bcarr> Warning: Partition 1 is 2005GB, but the file system is 13TB. bcarr> Yeah, that is a problem. Note that unless you have a compelling reason to partition it may be easiest to use the block devices directly, or else your next question will likely be about poor performance because of misaligned striping :-). From owner-xfs@oss.sgi.com Sat Sep 29 03:12:04 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 29 Sep 2007 03:12:09 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) 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.3.0-r574664 Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8TAC06K005189 for ; Sat, 29 Sep 2007 03:12:04 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1IbYoK-0007cw-RL; Sat, 29 Sep 2007 10:40:32 +0100 Date: Sat, 29 Sep 2007 10:40:32 +0100 From: Christoph Hellwig To: donaldd@sgi.com Cc: xfs@oss.sgi.com Subject: Re: PARTIAL TAKE 971050 - Remove linux-2.4 build support Message-ID: <20070929094032.GA29241@infradead.org> References: <20070926083416.C441A30A90AD@linuxbuild.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070926083416.C441A30A90AD@linuxbuild.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-Virus-Scanned: ClamAV 0.91.2/4429/Fri Sep 28 23:49:25 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13177 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 26, 2007 at 06:34:16PM +1000, donaldd@sgi.com wrote: > Remove Makefile wrappers in XFS > > Makefile (and Kbuild) would include Makefile-linux-26 > I doubt XFS will really still compile on 2.4; so drop that. This > moves Makefile-linux-26 into Makefile and drops Kbuild. > Also having wrappers as both Kbuild and Makefile seemed redundant > anyways. After pulling this patch I can't build XFS anymore, because in the CVS export there's a zero-size fs/xfs/Kbuild file left and the kernel build thus doesn't actually look at fs/xfs/Makefile. Can someone from SGI check if the file really isn't deleted in ptools or whether is is a fuckup in the cvs export script? From owner-xfs@oss.sgi.com Sat Sep 29 03:12:07 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 29 Sep 2007 03:12:12 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) 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.3.0-r574664 Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8TAC5No005212 for ; Sat, 29 Sep 2007 03:12:06 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1IbYw7-0007hR-BT; Sat, 29 Sep 2007 10:48:35 +0100 Date: Sat, 29 Sep 2007 10:48:35 +0100 From: Christoph Hellwig To: Eric Sandeen Cc: Christoph Hellwig , xfs-oss Subject: Re: [PATCH V2] refactor xfs_mountfs for clarity & stack savings Message-ID: <20070929094835.GA29582@infradead.org> References: <46D37A82.2080608@sandeen.net> <20070828195221.GA7237@infradead.org> <46D48BDE.5000903@sandeen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46D48BDE.5000903@sandeen.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-Virus-Scanned: ClamAV 0.91.2/4429/Fri Sep 28 23:49:25 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13178 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 Any chance we can get this commited? On Tue, Aug 28, 2007 at 03:55:58PM -0500, Eric Sandeen wrote: > Refactoring xfs_mountfs() to call sub-functions for logical > chunks can help save a bit of stack, and can make it easier to > read this long function. > > The mount path is one of the longest common callchains, easily > getting to within a few bytes of the end of a 4k stack when > over lvm, quotas are enabled, and quotacheck must be done. > > With this change on top of the other stack-related changes > I've sent, I can get xfs to survive a normal xfsqa run on > 4k stacks over lvm. > > Signed-off-by: Eric Sandeen > > 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 > @@ -734,49 +734,13 @@ xfs_initialize_perag_data(xfs_mount_t *m > } > > /* > - * xfs_mountfs > - * > - * This function does the following on an initial mount of a file system: > - * - reads the superblock from disk and init the mount struct > - * - if we're a 32-bit kernel, do a size check on the superblock > - * so we don't mount terabyte filesystems > - * - init mount struct realtime fields > - * - allocate inode hash table for fs > - * - init directory manager > - * - perform recovery and init the log manager > + * Update alignment values based on mount options and sb values > */ > -int > -xfs_mountfs( > - xfs_mount_t *mp, > - int mfsi_flags) > +STATIC int > +xfs_update_alignment(xfs_mount_t *mp, int mfsi_flags, __uint64_t *update_flags) > { > - xfs_buf_t *bp; > xfs_sb_t *sbp = &(mp->m_sb); > - xfs_inode_t *rip; > - bhv_vnode_t *rvp = NULL; > - int readio_log, writeio_log; > - xfs_daddr_t d; > - __uint64_t resblks; > - __int64_t update_flags; > - uint quotamount, quotaflags; > - int agno; > - int uuid_mounted = 0; > - int error = 0; > > - if (mp->m_sb_bp == NULL) { > - if ((error = xfs_readsb(mp, mfsi_flags))) { > - return error; > - } > - } > - xfs_mount_common(mp, sbp); > - > - /* > - * Check if sb_agblocks is aligned at stripe boundary > - * If sb_agblocks is NOT aligned turn off m_dalign since > - * allocator alignment is within an ag, therefore ag has > - * to be aligned at stripe boundary. > - */ > - update_flags = 0LL; > if (mp->m_dalign && !(mfsi_flags & XFS_MFSI_SECOND)) { > /* > * If stripe unit and stripe width are not multiples > @@ -787,8 +751,7 @@ xfs_mountfs( > if (mp->m_flags & XFS_MOUNT_RETERR) { > cmn_err(CE_WARN, > "XFS: alignment check 1 failed"); > - error = XFS_ERROR(EINVAL); > - goto error1; > + return XFS_ERROR(EINVAL); > } > mp->m_dalign = mp->m_swidth = 0; > } else { > @@ -798,8 +761,7 @@ xfs_mountfs( > mp->m_dalign = XFS_BB_TO_FSBT(mp, mp->m_dalign); > if (mp->m_dalign && (sbp->sb_agblocks % mp->m_dalign)) { > if (mp->m_flags & XFS_MOUNT_RETERR) { > - error = XFS_ERROR(EINVAL); > - goto error1; > + return XFS_ERROR(EINVAL); > } > xfs_fs_cmn_err(CE_WARN, mp, > "stripe alignment turned off: sunit(%d)/swidth(%d) incompatible with agsize(%d)", > @@ -816,8 +778,7 @@ xfs_mountfs( > "stripe alignment turned off: sunit(%d) less than bsize(%d)", > mp->m_dalign, > mp->m_blockmask +1); > - error = XFS_ERROR(EINVAL); > - goto error1; > + return XFS_ERROR(EINVAL); > } > mp->m_swidth = 0; > } > @@ -830,11 +791,11 @@ xfs_mountfs( > if (XFS_SB_VERSION_HASDALIGN(sbp)) { > if (sbp->sb_unit != mp->m_dalign) { > sbp->sb_unit = mp->m_dalign; > - update_flags |= XFS_SB_UNIT; > + *update_flags |= XFS_SB_UNIT; > } > if (sbp->sb_width != mp->m_swidth) { > sbp->sb_width = mp->m_swidth; > - update_flags |= XFS_SB_WIDTH; > + *update_flags |= XFS_SB_WIDTH; > } > } > } else if ((mp->m_flags & XFS_MOUNT_NOALIGN) != XFS_MOUNT_NOALIGN && > @@ -843,49 +804,45 @@ xfs_mountfs( > mp->m_swidth = sbp->sb_width; > } > > - xfs_alloc_compute_maxlevels(mp); > - xfs_bmap_compute_maxlevels(mp, XFS_DATA_FORK); > - xfs_bmap_compute_maxlevels(mp, XFS_ATTR_FORK); > - xfs_ialloc_compute_maxlevels(mp); > + return 0; > +} > > - if (sbp->sb_imax_pct) { > - __uint64_t icount; > +/* > + * Set the maximum inode count for this filesystem > + */ > +STATIC void > +xfs_set_maxicount(xfs_mount_t *mp) > +{ > + xfs_sb_t *sbp = &(mp->m_sb); > + __uint64_t icount; > > - /* Make sure the maximum inode count is a multiple of the > - * units we allocate inodes in. > + if (sbp->sb_imax_pct) { > + /* > + * Make sure the maximum inode count is a multiple > + * of the units we allocate inodes in. > */ > - > icount = sbp->sb_dblocks * sbp->sb_imax_pct; > do_div(icount, 100); > do_div(icount, mp->m_ialloc_blks); > mp->m_maxicount = (icount * mp->m_ialloc_blks) << > sbp->sb_inopblog; > - } else > + } else { > mp->m_maxicount = 0; > - > - mp->m_maxioffset = xfs_max_file_offset(sbp->sb_blocklog); > - > - /* > - * XFS uses the uuid from the superblock as the unique > - * identifier for fsid. We can not use the uuid from the volume > - * since a single partition filesystem is identical to a single > - * partition volume/filesystem. > - */ > - if ((mfsi_flags & XFS_MFSI_SECOND) == 0 && > - (mp->m_flags & XFS_MOUNT_NOUUID) == 0) { > - if (xfs_uuid_mount(mp)) { > - error = XFS_ERROR(EINVAL); > - goto error1; > - } > - uuid_mounted=1; > } > +} > + > +/* > + * Set the default minimum read and write sizes unless > + * already specified in a mount option. > + * We use smaller I/O sizes when the file system > + * is being used for NFS service (wsync mount option). > + */ > +STATIC void > +xfs_set_rw_sizes(xfs_mount_t *mp) > +{ > + xfs_sb_t *sbp = &(mp->m_sb); > + int readio_log, writeio_log; > > - /* > - * Set the default minimum read and write sizes unless > - * already specified in a mount option. > - * We use smaller I/O sizes when the file system > - * is being used for NFS service (wsync mount option). > - */ > if (!(mp->m_flags & XFS_MOUNT_DFLT_IOSIZE)) { > if (mp->m_flags & XFS_MOUNT_WSYNC) { > readio_log = XFS_WSYNC_READIO_LOG; > @@ -911,17 +868,14 @@ xfs_mountfs( > mp->m_writeio_log = writeio_log; > } > mp->m_writeio_blocks = 1 << (mp->m_writeio_log - sbp->sb_blocklog); > +} > > - /* > - * Set the inode cluster size. > - * This may still be overridden by the file system > - * block size if it is larger than the chosen cluster size. > - */ > - mp->m_inode_cluster_size = XFS_INODE_BIG_CLUSTER_SIZE; > - > - /* > - * Set whether we're using inode alignment. > - */ > +/* > + * Set whether we're using inode alignment. > + */ > +STATIC void > +xfs_set_inoalignment(xfs_mount_t *mp) > +{ > if (XFS_SB_VERSION_HASALIGN(&mp->m_sb) && > mp->m_sb.sb_inoalignmt >= > XFS_B_TO_FSBT(mp, mp->m_inode_cluster_size)) > @@ -937,14 +891,22 @@ xfs_mountfs( > mp->m_sinoalign = mp->m_dalign; > else > mp->m_sinoalign = 0; > - /* > - * Check that the data (and log if separate) are an ok size. > - */ > +} > + > +/* > + * Check that the data (and log if separate) are an ok size. > + */ > +STATIC int > +xfs_check_sizes(xfs_mount_t *mp, int mfsi_flags) > +{ > + xfs_buf_t *bp; > + xfs_daddr_t d; > + int error; > + > d = (xfs_daddr_t)XFS_FSB_TO_BB(mp, mp->m_sb.sb_dblocks); > if (XFS_BB_TO_FSB(mp, d) != mp->m_sb.sb_dblocks) { > cmn_err(CE_WARN, "XFS: size check 1 failed"); > - error = XFS_ERROR(E2BIG); > - goto error1; > + return XFS_ERROR(E2BIG); > } > error = xfs_read_buf(mp, mp->m_ddev_targp, > d - XFS_FSS_TO_BB(mp, 1), > @@ -953,10 +915,9 @@ xfs_mountfs( > xfs_buf_relse(bp); > } else { > cmn_err(CE_WARN, "XFS: size check 2 failed"); > - if (error == ENOSPC) { > + if (error == ENOSPC) > error = XFS_ERROR(E2BIG); > - } > - goto error1; > + return error; > } > > if (((mfsi_flags & XFS_MFSI_CLIENT) == 0) && > @@ -964,8 +925,7 @@ xfs_mountfs( > d = (xfs_daddr_t)XFS_FSB_TO_BB(mp, mp->m_sb.sb_logblocks); > if (XFS_BB_TO_FSB(mp, d) != mp->m_sb.sb_logblocks) { > cmn_err(CE_WARN, "XFS: size check 3 failed"); > - error = XFS_ERROR(E2BIG); > - goto error1; > + return XFS_ERROR(E2BIG); > } > error = xfs_read_buf(mp, mp->m_logdev_targp, > d - XFS_FSB_TO_BB(mp, 1), > @@ -974,17 +934,110 @@ xfs_mountfs( > xfs_buf_relse(bp); > } else { > cmn_err(CE_WARN, "XFS: size check 3 failed"); > - if (error == ENOSPC) { > + if (error == ENOSPC) > error = XFS_ERROR(E2BIG); > - } > + return error; > + } > + } > + return 0; > +} > + > +/* > + * xfs_mountfs > + * > + * This function does the following on an initial mount of a file system: > + * - reads the superblock from disk and init the mount struct > + * - if we're a 32-bit kernel, do a size check on the superblock > + * so we don't mount terabyte filesystems > + * - init mount struct realtime fields > + * - allocate inode hash table for fs > + * - init directory manager > + * - perform recovery and init the log manager > + */ > +int > +xfs_mountfs( > + xfs_mount_t *mp, > + int mfsi_flags) > +{ > + xfs_sb_t *sbp = &(mp->m_sb); > + xfs_inode_t *rip; > + bhv_vnode_t *rvp = NULL; > + __uint64_t resblks; > + __int64_t update_flags = 0LL; > + uint quotamount, quotaflags; > + int agno; > + int uuid_mounted = 0; > + int error = 0; > + > + if (mp->m_sb_bp == NULL) { > + error = xfs_readsb(mp, mfsi_flags); > + if (error) > + return error; > + } > + xfs_mount_common(mp, sbp); > + > + /* > + * Check if sb_agblocks is aligned at stripe boundary > + * If sb_agblocks is NOT aligned turn off m_dalign since > + * allocator alignment is within an ag, therefore ag has > + * to be aligned at stripe boundary. > + */ > + error = xfs_update_alignment(mp, mfsi_flags, &update_flags); > + if (error) > + goto error1; > + > + xfs_alloc_compute_maxlevels(mp); > + xfs_bmap_compute_maxlevels(mp, XFS_DATA_FORK); > + xfs_bmap_compute_maxlevels(mp, XFS_ATTR_FORK); > + xfs_ialloc_compute_maxlevels(mp); > + > + xfs_set_maxicount(mp); > + > + mp->m_maxioffset = xfs_max_file_offset(sbp->sb_blocklog); > + > + /* > + * XFS uses the uuid from the superblock as the unique > + * identifier for fsid. We can not use the uuid from the volume > + * since a single partition filesystem is identical to a single > + * partition volume/filesystem. > + */ > + if ((mfsi_flags & XFS_MFSI_SECOND) == 0 && > + (mp->m_flags & XFS_MOUNT_NOUUID) == 0) { > + if (xfs_uuid_mount(mp)) { > + error = XFS_ERROR(EINVAL); > goto error1; > } > } > > /* > + * Set the minimum read and write sizes > + */ > + xfs_set_rw_sizes(mp); > + > + /* > + * Set the inode cluster size. > + * This may still be overridden by the file system > + * block size if it is larger than the chosen cluster size. > + */ > + mp->m_inode_cluster_size = XFS_INODE_BIG_CLUSTER_SIZE; > + > + /* > + * Set inode alignment fields > + */ > + xfs_set_inoalignment(mp); > + > + /* > + * Check that the data (and log if separate) are an ok size. > + */ > + error = xfs_check_sizes(mp, mfsi_flags); > + if (error) > + goto error1; > + > + /* > * Initialize realtime fields in the mount structure > */ > - if ((error = xfs_rtmount_init(mp))) { > + error = xfs_rtmount_init(mp); > + if (error) { > cmn_err(CE_WARN, "XFS: RT mount failed"); > goto error1; > } > @@ -1102,7 +1155,8 @@ xfs_mountfs( > /* > * Initialize realtime inode pointers in the mount structure > */ > - if ((error = xfs_rtmount_inodes(mp))) { > + error = xfs_rtmount_inodes(mp); > + if (error) { > /* > * Free up the root inode. > */ > @@ -1120,7 +1174,8 @@ xfs_mountfs( > /* > * Initialise the XFS quota management subsystem for this mount > */ > - if ((error = XFS_QM_INIT(mp, "amount, "aflags))) > + error = XFS_QM_INIT(mp, "amount, "aflags); > + if (error) > goto error4; > > /* > @@ -1137,7 +1192,8 @@ xfs_mountfs( > /* > * Complete the quota initialisation, post-log-replay component. > */ > - if ((error = XFS_QM_MOUNT(mp, quotamount, quotaflags, mfsi_flags))) > + error = XFS_QM_MOUNT(mp, quotamount, quotaflags, mfsi_flags); > + if (error) > goto error4; > > /* > > > ---end quoted text--- From owner-xfs@oss.sgi.com Sat Sep 29 03:27:40 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 29 Sep 2007 03:27:43 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) 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.3.0-r574664 Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8TARa6s010269 for ; Sat, 29 Sep 2007 03:27:40 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1IbYtV-0007gH-1o; Sat, 29 Sep 2007 10:45:53 +0100 Date: Sat, 29 Sep 2007 10:45:52 +0100 From: Christoph Hellwig To: Christoph Hellwig Cc: xfs@oss.sgi.com Subject: Re: [PATCH] kill XFS_INOBT_IS_FREE_DISK Message-ID: <20070929094552.GC29241@infradead.org> References: <20070919161202.GA18130@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070919161202.GA18130@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-Virus-Scanned: ClamAV 0.91.2/4429/Fri Sep 28 23:49:25 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13179 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 19, 2007 at 06:12:03PM +0200, Christoph Hellwig wrote: > This macro is unused an all other acros in this family operate on native > types, so we most likely won't grow a user either. Could anyone put this trivial remove one line patch in? > Signed-off-by: Christoph Hellwig > > Index: linux-2.6.23-rc6/fs/xfs/xfs_ialloc_btree.h > =================================================================== > --- linux-2.6.23-rc6.orig/fs/xfs/xfs_ialloc_btree.h 2007-09-18 16:27:08.000000000 +0200 > +++ linux-2.6.23-rc6/fs/xfs/xfs_ialloc_btree.h 2007-09-18 16:27:18.000000000 +0200 > @@ -81,8 +81,6 @@ typedef struct xfs_btree_sblock xfs_inob > #define XFS_INOBT_MASK(i) ((xfs_inofree_t)1 << (i)) > #define XFS_INOBT_IS_FREE(rp,i) \ > (((rp)->ir_free & XFS_INOBT_MASK(i)) != 0) > -#define XFS_INOBT_IS_FREE_DISK(rp,i) \ > - ((be64_to_cpu((rp)->ir_free) & XFS_INOBT_MASK(i)) != 0) > #define XFS_INOBT_SET_FREE(rp,i) ((rp)->ir_free |= XFS_INOBT_MASK(i)) > #define XFS_INOBT_CLR_FREE(rp,i) ((rp)->ir_free &= ~XFS_INOBT_MASK(i)) > > > ---end quoted text--- From owner-xfs@oss.sgi.com Sat Sep 29 03:27:44 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 29 Sep 2007 03:27:49 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) 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.3.0-r574664 Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8TARfNF010293 for ; Sat, 29 Sep 2007 03:27:44 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1IbYof-0007dA-HK; Sat, 29 Sep 2007 10:40:53 +0100 Date: Sat, 29 Sep 2007 10:40:53 +0100 From: Christoph Hellwig To: Christoph Hellwig Cc: xfs@oss.sgi.com Subject: Re: [PATCH] kill probe_* sysctl leftovers Message-ID: <20070929094053.GB29241@infradead.org> References: <20070902201727.GA29823@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070902201727.GA29823@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-Virus-Scanned: ClamAV 0.91.2/4429/Fri Sep 28 23:49:25 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13180 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 Sun, Sep 02, 2007 at 10:17:27PM +0200, Christoph Hellwig wrote: > 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. ping. > 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, > > ---end quoted text--- From owner-xfs@oss.sgi.com Sat Sep 29 04:09:25 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 29 Sep 2007 04:09:27 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) 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.3.0-r574664 Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8TB9M0W021762 for ; Sat, 29 Sep 2007 04:09:24 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id l8TB9LF3002516 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 29 Sep 2007 13:09:21 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8TB9L1J002514 for xfs@oss.sgi.com; Sat, 29 Sep 2007 13:09:21 +0200 Date: Sat, 29 Sep 2007 13:09:21 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: sync_blockdev in xfs_flush_device_work Message-ID: <20070929110921.GA2466@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-Virus-Scanned: ClamAV 0.91.2/4429/Fri Sep 28 23:49:25 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13181 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 How is the sync_blockdev in the ENOSP path going to help it? It only syncs the block device mapping which XFS doesn't use it at all. From owner-xfs@oss.sgi.com Sat Sep 29 09:29:15 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 29 Sep 2007 09:29:23 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) 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.3.0-r574664 Received: from slurp.thebarn.com (cattelan-host202.dsl.visi.com [208.42.117.202]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8TGTCuC020913 for ; Sat, 29 Sep 2007 09:29:15 -0700 Received: from funky.thebarn.com (slurp.thebarn.com [208.42.117.201]) (authenticated bits=0) by slurp.thebarn.com (8.14.0/8.13.8) with ESMTP id l8TGT0mA016446; Sat, 29 Sep 2007 11:29:02 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <46FE7CF2.9070806@thebarn.com> Date: Sat, 29 Sep 2007 11:27:30 -0500 From: Russell Cattelan User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Christoph Hellwig CC: donaldd@sgi.com, xfs@oss.sgi.com Subject: Re: PARTIAL TAKE 971050 - Remove linux-2.4 build support References: <20070926083416.C441A30A90AD@linuxbuild.melbourne.sgi.com> <20070929094032.GA29241@infradead.org> In-Reply-To: <20070929094032.GA29241@infradead.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4429/Fri Sep 28 23:49:25 2007 on oss.sgi.com X-Virus-Scanned: ClamAV 0.91.1/4429/Sat Sep 29 01:49:25 2007 on slurp.thebarn.com X-Virus-Status: Clean X-archive-position: 13182 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: xfs Christoph Hellwig wrote: > On Wed, Sep 26, 2007 at 06:34:16PM +1000, donaldd@sgi.com wrote: > >> Remove Makefile wrappers in XFS >> >> Makefile (and Kbuild) would include Makefile-linux-26 >> I doubt XFS will really still compile on 2.4; so drop that. This >> moves Makefile-linux-26 into Makefile and drops Kbuild. >> Also having wrappers as both Kbuild and Makefile seemed redundant >> anyways. >> > > After pulling this patch I can't build XFS anymore, because > in the CVS export there's a zero-size fs/xfs/Kbuild file left and the > kernel build thus doesn't actually look at fs/xfs/Makefile. > > Can someone from SGI check if the file really isn't deleted in ptools > or whether is is a fuckup in the cvs export script? > > I might be a combination of both, the Attic processing is a bit tricky. I'll try and figure out what is going wrong and get the SGI guys to adjust things if need be. From owner-xfs@oss.sgi.com Sat Sep 29 10:08:47 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 29 Sep 2007 10:08:51 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.9 required=5.0 tests=AWL,BAYES_50,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8TH8k2d031926 for ; Sat, 29 Sep 2007 10:08:47 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 6E10D1C000264; Sat, 29 Sep 2007 13:08:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 6B1454019BD2; Sat, 29 Sep 2007 13:08:45 -0400 (EDT) Date: Sat, 29 Sep 2007 13:08:45 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: linux-kernel@vger.kernel.org cc: linux-raid@vger.kernel.org, xfs@oss.sgi.com Subject: Bonnie++ with 1024k stripe SW/RAID5 causes kernel to goto D-state Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/4429/Fri Sep 28 23:49:25 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13183 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 Kernel: 2.6.23-rc8 (older kernels do this as well) When running the following command: /usr/bin/time /usr/sbin/bonnie++ -d /x/test -s 16384 -m p34 -n 16:100000:16:64 It hangs unless I increase various parameters md/raid such as the stripe_cache_size etc.. # ps auxww | grep D USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 276 0.0 0.0 0 0 ? D 12:14 0:00 [pdflush] root 277 0.0 0.0 0 0 ? D 12:14 0:00 [pdflush] root 1639 0.0 0.0 0 0 ? D< 12:14 0:00 [xfsbufd] root 1767 0.0 0.0 8100 420 ? Ds 12:14 0:00 root 2895 0.0 0.0 5916 632 ? Ds 12:15 0:00 /sbin/syslogd -r See the bottom for more details. Is this normal? Does md only work without tuning up to a certain stripe size? I use a RAID 5 with 1024k stripe which works fine with many optimizations, but if I just boot the system and run bonnie++ on it without applying the optimizations, it will hang in d-state. When I run the optimizations, then it exits out of D-state, pretty weird? (again, without this, bonnie++ will hang in d-state.. until this is run) Optimization script: #!/bin/bash # source profile . /etc/profile # Tell user what's going on. echo "Optimizing RAID Arrays..." # Define DISKS. cd /sys/block DISKS=$(/bin/ls -1d sd[a-z]) # This step must come first. # See: http://www.3ware.com/KB/article.aspx?id=11050 echo "Setting max_sectors_kb to 128 KiB" for i in $DISKS do echo "Setting /dev/$i to 128 KiB..." echo 128 > /sys/block/"$i"/queue/max_sectors_kb done # This step comes next. echo "Setting nr_requests to 512 KiB" for i in $DISKS do echo "Setting /dev/$i to 512K KiB" echo 512 > /sys/block/"$i"/queue/nr_requests done # Set read-ahead. echo "Setting read-ahead to 64 MiB for /dev/md3" blockdev --setra 65536 /dev/md3 # Set stripe-cache_size for RAID5. echo "Setting stripe_cache_size to 16 MiB for /dev/md3" echo 16384 > /sys/block/md3/md/stripe_cache_size # Set minimum and maximum raid rebuild speed to 30MB/s. echo "Setting minimum and maximum resync speed to 30 MiB/s..." echo 30000 > /sys/block/md0/md/sync_speed_min echo 30000 > /sys/block/md0/md/sync_speed_max echo 30000 > /sys/block/md1/md/sync_speed_min echo 30000 > /sys/block/md1/md/sync_speed_max echo 30000 > /sys/block/md2/md/sync_speed_min echo 30000 > /sys/block/md2/md/sync_speed_max echo 30000 > /sys/block/md3/md/sync_speed_min echo 30000 > /sys/block/md3/md/sync_speed_max # Disable NCQ on all disks. echo "Disabling NCQ on all disks..." for i in $DISKS do echo "Disabling NCQ on $i" echo 1 > /sys/block/"$i"/device/queue_depth done -- Once this runs, everything works fine again. -- # mdadm -D /dev/md3 /dev/md3: Version : 00.90.03 Creation Time : Wed Aug 22 10:38:53 2007 Raid Level : raid5 Array Size : 1318680576 (1257.59 GiB 1350.33 GB) Used Dev Size : 146520064 (139.73 GiB 150.04 GB) Raid Devices : 10 Total Devices : 10 Preferred Minor : 3 Persistence : Superblock is persistent Update Time : Sat Sep 29 13:05:15 2007 State : active, resyncing Active Devices : 10 Working Devices : 10 Failed Devices : 0 Spare Devices : 0 Layout : left-symmetric Chunk Size : 1024K Rebuild Status : 8% complete UUID : e37a12d1:1b0b989a:083fb634:68e9eb49 (local to host p34.internal.lan) Events : 0.4211 Number Major Minor RaidDevice State 0 8 33 0 active sync /dev/sdc1 1 8 49 1 active sync /dev/sdd1 2 8 65 2 active sync /dev/sde1 3 8 81 3 active sync /dev/sdf1 4 8 97 4 active sync /dev/sdg1 5 8 113 5 active sync /dev/sdh1 6 8 129 6 active sync /dev/sdi1 7 8 145 7 active sync /dev/sdj1 8 8 161 8 active sync /dev/sdk1 9 8 177 9 active sync /dev/sdl1 -- NOTE: This bug is reproducible every time: Example: $ /usr/bin/time /usr/sbin/bonnie++ -d /x/test -s 16384 -m p34 -n 16:100000:16:64 Writing with putc()... It writes for 4-5 minutes and then...... SILENCE + D-STATE, I was too late this time :( $ ps auxww | grep D USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 276 1.2 0.0 0 0 ? D 12:50 0:03 [pdflush] root 2901 0.0 0.0 5916 632 ? Ds 12:50 0:00 /sbin/syslogd - r user 4571 48.0 0.0 11644 1084 pts/1 D+ 12:51 1:55 /usr/sbin/bonn ie++ -d /x/test -s 16384 -m p34 -n 16:100000:16:64 root 4612 1.0 0.0 0 0 ? D 12:52 0:01 [pdflush] root 4624 5.0 0.0 40964 7436 ? D 12:55 0:00 /usr/bin/perl - w /app/rrd-cputemp/bin/rrd_cputemp.pl root 4684 0.0 0.0 31968 1416 ? D 12:55 0:00 /usr/bin/rateup /var/www/monitor/mrtg/ eth0 1191084902 -Z u 265975 843609 125000000 c #00cc00 # 0000ff #006600 #ff00ff k 1000 i /var/www/monitor/mrtg/eth0-day.png -125000000 -1 25000000 400 100 1 1 1 300 0 4 1 %Y-%m-%d %H:%M 0 i /var/www/monitor/mrtg/eth0-w eek.png -125000000 -125000000 400 100 1 1 1 1800 0 4 1 %Y-%m-%d %H:%M 0 i /var/w ww/monitor/mrtg/eth0-month.png -125000000 -125000000 400 100 1 1 1 7200 0 4 1 %Y -%m-%d %H:%M 0 root 4686 0.0 0.0 4420 932 ? D 12:55 0:00 /usr/sbin/hddte mp -n /dev/sdf user 4688 0.0 0.0 4232 800 pts/5 S+ 12:55 0:00 grep --color D $ If you are not logged as root already, it is sometimes too late to su to root and run the optimizations: $ su - Password: Justin. From owner-xfs@oss.sgi.com Sat Sep 29 12:13:38 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 29 Sep 2007 12:13:42 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8TJDawo003611 for ; Sat, 29 Sep 2007 12:13:38 -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 l8TIXtQm021096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 29 Sep 2007 14:33:55 -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 l8TIXtbl012392; Sat, 29 Sep 2007 14:33:55 -0400 Received: from [10.13.248.15] (vpn-248-15.boston.redhat.com [10.13.248.15]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id l8TIXsQO011092; Sat, 29 Sep 2007 14:33:55 -0400 Message-ID: <46FE9A90.8040402@redhat.com> Date: Sat, 29 Sep 2007 14:33:52 -0400 From: Chris Snook User-Agent: Thunderbird 2.0.0.5 (X11/20070727) MIME-Version: 1.0 To: Justin Piszcz CC: linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, xfs@oss.sgi.com Subject: Re: Bonnie++ with 1024k stripe SW/RAID5 causes kernel to goto D-state References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4429/Fri Sep 28 23:49:25 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13184 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: csnook@redhat.com Precedence: bulk X-list: xfs Justin Piszcz wrote: > Kernel: 2.6.23-rc8 (older kernels do this as well) > > When running the following command: > /usr/bin/time /usr/sbin/bonnie++ -d /x/test -s 16384 -m p34 -n > 16:100000:16:64 > > It hangs unless I increase various parameters md/raid such as the > stripe_cache_size etc.. > > # ps auxww | grep D > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > root 276 0.0 0.0 0 0 ? D 12:14 0:00 [pdflush] > root 277 0.0 0.0 0 0 ? D 12:14 0:00 [pdflush] > root 1639 0.0 0.0 0 0 ? D< 12:14 0:00 [xfsbufd] > root 1767 0.0 0.0 8100 420 ? Ds 12:14 0:00 > root 2895 0.0 0.0 5916 632 ? Ds 12:15 0:00 > /sbin/syslogd -r > > See the bottom for more details. > > Is this normal? Does md only work without tuning up to a certain stripe > size? I use a RAID 5 with 1024k stripe which works fine with many > optimizations, but if I just boot the system and run bonnie++ on it > without applying the optimizations, it will hang in d-state. When I run > the optimizations, then it exits out of D-state, pretty weird? Not at all. 1024k stripes are way outside the norm. If you do something way outside the norm, and don't tune for it in advance, don't be terribly surprised when something like bonnie++ brings your box to its knees. That's not to say we couldn't make md auto-tune itself more intelligently, but this isn't really a bug. With a sufficiently huge amount of RAM, you'd be able to dynamically allocate the buffers that you're not pre-allocating with stripe_cache_size, but bonnie++ is eating that up in this case. -- Chris From owner-xfs@oss.sgi.com Sat Sep 29 23:31:31 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 29 Sep 2007 23:31:36 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.0 required=5.0 tests=BAYES_99 autolearn=no version=3.3.0-r574664 Received: from smtp-out4.libero.it (smtp-out4.libero.it [212.52.84.46]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8U6VTiP019911 for ; Sat, 29 Sep 2007 23:31:30 -0700 Received: from localhost (172.31.0.54) by smtp-out4.libero.it (7.3.120) id 4688F3500993FC82 for linux-xfs@oss.sgi.com; Sun, 30 Sep 2007 08:07:19 +0200 Received: from smtp-out4.libero.it ([172.31.0.40]) by localhost (asav-out12.libero.it [192.168.32.40]) (amavisd-new, port 10024) with ESMTP id B9rzsJP8Q1Iz for ; Sun, 30 Sep 2007 08:07:19 +0200 (CEST) Received: from mailrelay07.libero.it (192.168.32.94) by smtp-out4.libero.it (7.3.120) id 4611FEBC11CD9C89 for linux-xfs@oss.sgi.com; Sun, 30 Sep 2007 08:07:19 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAKfZ/kbAqBEM/2dsb2JhbAAM Received: from unknown (HELO libero.it) ([192.168.17.10]) by outrelay07.libero.it with ESMTP; 30 Sep 2007 08:07:13 +0200 Date: Sun, 30 Sep 2007 08:07:18 +0200 Message-Id: Subject: information. MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 From: "yulianashley" X-XaM3-API-Version: 4.3 (R1) (B3pl19) X-SenderIP: 24.132.226.52 To: undisclosed-recipients:; X-Virus-Scanned: ClamAV 0.91.2/4433/Sat Sep 29 16:13:47 2007 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id l8U6VViP019917 X-archive-position: 13185 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: yulianashley@libero.it Precedence: bulk X-list: xfs We are pleased to inform you of the announcement today 29th September, 2007 of winners of the Staats Loterij Sweepstakes International Promo held on 24th September 2007. please contact claims release officer;Name: Mr.Jude Fabian Tel: +31-643-663-271 Email:fiduciaryclm@aim.com Cheers ------------------------------------------------------ Leggi GRATIS le tue mail con il telefonino i-mode™ di Wind http://i-mode.wind.it/ From owner-xfs@oss.sgi.com Sat Sep 29 23:35:20 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 29 Sep 2007 23:35:28 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.0 required=5.0 tests=AWL,BAYES_99,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from smtp-out1.libero.it ([212.52.80.101]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8U6ZInO020660; Sat, 29 Sep 2007 23:35:19 -0700 Received: from localhost (172.31.0.47) by smtp-out1.libero.it (7.3.120) id 4688F3170977B374; Sun, 30 Sep 2007 08:11:11 +0200 Received: from smtp-out3.libero.it ([172.31.0.39]) by localhost (asav-out6.libero.it [192.168.32.34]) (amavisd-new, port 10024) with ESMTP id kaJQeSjy+gGM; Sun, 30 Sep 2007 08:11:11 +0200 (CEST) Received: from MailRelay10.libero.it (192.168.32.119) by smtp-out3.libero.it (7.3.120) id 4611FDB611CFB9E0; Sun, 30 Sep 2007 08:11:11 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAB7a/kbAqBEK/2dsb2JhbAAM Received: from unknown (HELO libero.it) ([192.168.17.10]) by outrelay10.libero.it with ESMTP; 30 Sep 2007 08:11:06 +0200 Date: Sun, 30 Sep 2007 08:11:11 +0200 Message-Id: Subject: information. MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 From: "yulianashley" X-XaM3-API-Version: 4.3 (R1) (B3pl19) X-SenderIP: 24.132.226.52 To: undisclosed-recipients:; X-Virus-Scanned: ClamAV 0.91.2/4433/Sat Sep 29 16:13:47 2007 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id l8U6ZKnO020663 X-archive-position: 13186 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: yulianashley@libero.it Precedence: bulk X-list: xfs We are pleased to inform you of the announcement today 29th September, 2007 of winners of the Staats Loterij Sweepstakes International Promo held on 24th September 2007. please contact claims release officer;Name: Mr.Jude Fabian Tel: +31-643-663-271 Email:fiduciaryclm@aim.com Cheers ------------------------------------------------------ Leggi GRATIS le tue mail con il telefonino i-mode™ di Wind http://i-mode.wind.it/ From owner-xfs@oss.sgi.com Sun Sep 30 12:50:15 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 30 Sep 2007 12:50:19 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=AWL,BAYES_40 autolearn=ham version=3.3.0-r574664 Received: from mail.lichtvoll.de (mondschein.lichtvoll.de [194.150.191.11]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l8UJoDI0031356 for ; Sun, 30 Sep 2007 12:50:14 -0700 Received: from localhost (dslb-084-056-111-168.pools.arcor-ip.net [84.56.111.168]) by mail.lichtvoll.de (Postfix) with ESMTP id 60A615ADFD for ; Sun, 30 Sep 2007 21:24:49 +0200 (CEST) From: Martin Steigerwald To: xfs@oss.sgi.com Subject: Creation time in XFS Date: Sun, 30 Sep 2007 21:24:37 +0200 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709302124.38164.Martin@lichtvoll.de> X-Virus-Scanned: ClamAV 0.91.2/4442/Sun Sep 30 05:20:50 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13187 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Hi! Does XFS support creation time too or are there plans to support it? Ext3 seems to do since 2.6.23: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ef7f38359ea8b3e9c7f2cae9a4d4935f55ca9e80 http://tinyurl.com/3drb65 Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Sun Sep 30 17:44:21 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 30 Sep 2007 17:44:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_55 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l910iHUW002992 for ; Sun, 30 Sep 2007 17:44:20 -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 KAA12716; Mon, 1 Oct 2007 10:44:12 +1000 Message-ID: <470042DC.2040009@sgi.com> Date: Mon, 01 Oct 2007 10:44:12 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Martin Steigerwald CC: xfs@oss.sgi.com Subject: Re: Creation time in XFS References: <200709302124.38164.Martin@lichtvoll.de> In-Reply-To: <200709302124.38164.Martin@lichtvoll.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4443/Sun Sep 30 15:16:01 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13188 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 Martin Steigerwald wrote: > Hi! > > Does XFS support creation time too or are there plans to support it? > > Ext3 seems to do since 2.6.23: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ef7f38359ea8b3e9c7f2cae9a4d4935f55ca9e80 > > http://tinyurl.com/3drb65 > > Ciao, Hi Martin, No XFS does not support creation time. It just has the regular atime,mtime and ctime. There are no plans that I've heard to support it. Not much involved to support it AFAICT but it would either involve changing the ondisk format of the inode or storing it in an EA. Storing it in an EA would be yet another one for the EA creation on inode allocation scenarios (done presently for default ACLs and and also in other future data). I wonder how this creation time is being exported currently? --Tim From owner-xfs@oss.sgi.com Sun Sep 30 19:59:39 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 30 Sep 2007 19:59:43 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l912xaRM017100 for ; Sun, 30 Sep 2007 19:59:39 -0700 Received: from liberator.sandeen.net (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 C78AE1807A955; Sun, 30 Sep 2007 21:59:35 -0500 (CDT) Message-ID: <47006297.3080209@sandeen.net> Date: Sun, 30 Sep 2007 21:59:35 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Martin Steigerwald CC: xfs@oss.sgi.com Subject: Re: Creation time in XFS References: <200709302124.38164.Martin@lichtvoll.de> In-Reply-To: <200709302124.38164.Martin@lichtvoll.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4443/Sun Sep 30 15:16:01 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13189 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 Steigerwald wrote: > Hi! > > Does XFS support creation time too or are there plans to support it? > > Ext3 seems to do since 2.6.23: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ef7f38359ea8b3e9c7f2cae9a4d4935f55ca9e80 well, that's ext4, not ext3, just FWIW. -Eric