From owner-linux-xfs@oss.sgi.com Sun May 1 19:32:26 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 01 May 2005 19:32:28 -0700 (PDT) Received: from boing.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j422WO7J022513 for ; Sun, 1 May 2005 19:32:25 -0700 Received: from boing.melbourne.sgi.com (localhost [127.0.0.1]) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j422W8fE871618; Mon, 2 May 2005 12:32:09 +1000 (AEST) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j422W3sN872798; Mon, 2 May 2005 12:32:03 +1000 (AEST) Date: Mon, 2 May 2005 12:32:03 +1000 From: Tim Shimmin To: John Bartoszewski Cc: linux-xfs@oss.sgi.com Subject: Re: Old XFS_GEOMETRY change Message-ID: <20050502123203.O114500@boing.melbourne.sgi.com> References: <20050429174136.GA21813@ugrad.cs.ualberta.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20050429174136.GA21813@ugrad.cs.ualberta.ca>; from johnb@ugrad.cs.ualberta.ca on Fri, Apr 29, 2005 at 11:41:36AM -0600 X-Virus-Scanned: ClamAV 0.83/861/Sat Apr 30 02:28:52 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5126 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 508 Lines: 16 On Fri, Apr 29, 2005 at 11:41:36AM -0600, John Bartoszewski wrote: > Would something like 'old_xfsdump -l0 - /dev/hda2 | new_xfrestore - .' > work? > Yep (Aside: I normally give a mount-point and not a device - xfsdump only works on mounted filesystems. I think if it has a device then it uses getmntent() to match with a mnt-pt). Both the on-disk and on-tape dump formats haven't changed. We need to keep them constant for compatibility with IRIX and to allow one to restore old tapes etc... --Tim From owner-linux-xfs@oss.sgi.com Sun May 1 22:09:10 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 01 May 2005 22:09:13 -0700 (PDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.198]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j425997J030063 for ; Sun, 1 May 2005 22:09:10 -0700 Received: by wproxy.gmail.com with SMTP id 68so1626765wra for ; Sun, 01 May 2005 22:09:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MSHU5RR9ZavlYRbB5jDBxdYT3lzcZRNirIyK38Tg8T2V9iLPhHXj82NnxPMSf96z1DEu+LI55t37ZMTQHTas6lanGCAd75SpOWRzLAW5gkou9DrIlNV0zOk4yEZR5MuZupxSTj6mH6G12GY7sb4HHUkQz4oajIJRVwqvjc710HI= Received: by 10.54.125.14 with SMTP id x14mr390764wrc; Sun, 01 May 2005 22:08:59 -0700 (PDT) Received: by 10.54.8.70 with HTTP; Sun, 1 May 2005 22:08:59 -0700 (PDT) Message-ID: <1ae2376005050122085c397533@mail.gmail.com> Date: Mon, 2 May 2005 15:08:59 +1000 From: Simon Hill Reply-To: Simon Hill To: linux-xfs@oss.sgi.com Subject: Re: xfs_repair woes In-Reply-To: <20050401120032.K3561661@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <1ae237600503311613296b2a2c@mail.gmail.com> <20050401120032.K3561661@wobbly.melbourne.sgi.com> X-Virus-Scanned: ClamAV 0.83/861/Sat Apr 30 02:28:52 2005 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 j4259A7J030065 X-archive-position: 5127 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: red.underscore.one@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 1250 Lines: 34 How do I get xfs_db (or whatever app) to give me a nice sortable list of inodes and sizes? On 4/1/05, Nathan Scott wrote: > On Fri, Apr 01, 2005 at 10:13:19AM +1000, Simon Hill wrote: > > Hi guys, > > > > For some magical reason, I lost my partition table today. I got it > > back with gpart, but now when I run xfs_repair on the partition, it > > says: > > Phase 6 - check inode connectivity... > > - resetting contents of realtime bitmap and summary nodes > > - ensuring existence of lost+found directory > > - traversing filesystem starting at /... > > rebuilding directory inode 128 > > unknown magic number 0 for block 8388608 in directory inode 527071481 > > rebuilding directory inode 527071481 > > xfs_repair: pwrite64 failed: No space left on device > > xfs_repair: pwrite64 failed: No space left on device > > > > Any ideas how I fix this? > > Looks like you have insufficient space for repair to reconstruct > a valid filesystem. I think you'll have to go in with xfs_db in > expert mode and clear out some inodes. I've never been in this > situation myself, so not sure whats the best approach for you to > use here to ensure repair sees this as free space.. > > cheers. > > -- > Nathan > From owner-linux-xfs@oss.sgi.com Sun May 1 23:32:31 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 01 May 2005 23:32:34 -0700 (PDT) Received: from psi12.psi.ch (psi12.psi.ch [129.129.190.112]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j426WT7J001291 for ; Sun, 1 May 2005 23:32:30 -0700 Received: from 129.129.190.113 by psi12.psi.ch (InterScan E-Mail VirusWall NT); Mon, 02 May 2005 08:32:11 +0200 Received: from [129.129.194.181] (pc4568.psi.ch [129.129.194.181]) by psi13.psi.ch with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JGA4A19Y; Mon, 2 May 2005 08:32:10 +0200 Message-ID: <4275C96A.7050900@psi.ch> Date: Mon, 02 May 2005 08:32:10 +0200 From: Peter Huesser User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Invalid packet 21 count! 15 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/861/Sat Apr 30 02:28:52 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5128 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: peter.huesser@psi.ch Precedence: bulk X-list: linux-xfs Content-Length: 253 Lines: 13 Hello I use xfs on a scientific linux (version 303) installation with the 2.4.21-27.0.2.EL.XFSsmp kernel. My /var/log/messages file is full of "Invalid packet 21 count! 15" error messages. Does somebody has an idea what is wrong. Cheers PH From owner-linux-xfs@oss.sgi.com Mon May 2 05:05:55 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 May 2005 05:05:59 -0700 (PDT) Received: from ns.efotek.com (218-36-73-1.rev.krline.net [218.36.73.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42C5s7J024850 for ; Mon, 2 May 2005 05:05:55 -0700 Received: from kmhh0021note (kmhh0021-linux [218.36.73.49]) by ns.efotek.com (8.11.4/8.11.4) with ESMTP id j42C3KU19234 for ; Mon, 2 May 2005 21:03:20 +0900 (KST) From: =?ks_c_5601-1987?B?sPi47cjGLWVmb3Rlaw==?= To: Subject: cvs server connect error Date: Mon, 2 May 2005 21:06:12 +0900 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Importance: Normal X-Virus-Scanned: ClamAV 0.83/861/Sat Apr 30 02:28:52 2005 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 5129 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kmhh0021@efotek.com Precedence: bulk X-list: linux-xfs Content-Length: 395 Lines: 17 Is the cvs server login? I am unable to update xfs-linux. $ export CVSROOT=':pserver:cvs@oss.sgi.com:/cvs' $ cvs login Logging in to :pserver:cvs@oss.sgi.com:2401/cvs CVS password: cvs [login aborted]: connect to oss.sgi.com(192.48.159.27):2401 failed: Connection refused I am also posting this to see if it will help my problem. Thanks, [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Mon May 2 15:33:44 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 May 2005 15:33:47 -0700 (PDT) Received: from pimout4-ext.prodigy.net (pimout4-ext.prodigy.net [207.115.63.98]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42MXh7J012363 for ; Mon, 2 May 2005 15:33:43 -0700 Received: from taniwha.stupidest.org (adsl-67-124-119-21.dsl.snfc21.pacbell.net [67.124.119.21]) by pimout4-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j42MXLqi151878; Mon, 2 May 2005 18:33:21 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 19106528F22; Mon, 2 May 2005 15:33:21 -0700 (PDT) Date: Mon, 2 May 2005 15:33:21 -0700 From: Chris Wedgwood To: Peter Huesser Cc: linux-xfs@oss.sgi.com Subject: Re: Invalid packet 21 count! 15 Message-ID: <20050502223321.GA15361@taniwha.stupidest.org> References: <4275C96A.7050900@psi.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4275C96A.7050900@psi.ch> X-Virus-Scanned: ClamAV 0.83/863/Mon May 2 09:32:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5133 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 330 Lines: 10 On Mon, May 02, 2005 at 08:32:10AM +0200, Peter Huesser wrote: > I use xfs on a scientific linux (version 303) installation with the > 2.4.21-27.0.2.EL.XFSsmp kernel. My /var/log/messages file is full of > > "Invalid packet 21 count! 15" that's not related to XFS the filesystem, you'll have to see where they are coming from From owner-linux-xfs@oss.sgi.com Mon May 2 18:24:42 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 May 2005 18:24:44 -0700 (PDT) Received: from imo-m14.mx.aol.com (imo-m14.mx.aol.com [64.12.138.204]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j431Of7J025487 for ; Mon, 2 May 2005 18:24:41 -0700 Received: from AndyLiebman@aol.com by imo-m14.mx.aol.com (mail_out_v38_r1.7.) id 4.1a4.373405e4 (17377) for ; Mon, 2 May 2005 21:24:21 -0400 (EDT) From: AndyLiebman@aol.com Message-ID: <1a4.373405e4.2fa82cc5@aol.com> Date: Mon, 2 May 2005 21:24:21 EDT Subject: Never mind question about xfs_grow To: linux-xfs@oss.sgi.com MIME-Version: 1.0 X-Mailer: 9.0 Security Edition for Windows sub 1200 X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 5135 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: AndyLiebman@aol.com Precedence: bulk X-list: linux-xfs Content-Length: 256 Lines: 11 Sorry to ask my previous question. I was mislead by some other printed information that I needed to look for xfs_grow. But now I see that the command is xfs_growfs! Seems straightforward enough. Andy Liebman [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Mon May 2 18:17:19 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 May 2005 18:17:21 -0700 (PDT) Received: from imo-d05.mx.aol.com (imo-d05.mx.aol.com [205.188.157.37]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j431HH7J025056 for ; Mon, 2 May 2005 18:17:18 -0700 Received: from AndyLiebman@aol.com by imo-d05.mx.aol.com (mail_out_v38_r1.7.) id 4.1ab.37ca7ff7 (4214) for ; Mon, 2 May 2005 21:17:04 -0400 (EDT) From: AndyLiebman@aol.com Message-ID: <1ab.37ca7ff7.2fa82b0f@aol.com> Date: Mon, 2 May 2005 21:17:03 EDT Subject: Please Advise on XFS-grow To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: 9.0 Security Edition for Windows sub 1200 X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5134 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: AndyLiebman@aol.com Precedence: bulk X-list: linux-xfs Content-Length: 812 Lines: 20 Can somebody point me to solid documentation on how to use xfs_grow in Linux? My situation is simple. With 3ware's latest 9.2.0 Linux driver for their 9500S series of SATA RAID cards, it is possible to add disks to a RAID-5 array to increase the array's size. So, for example, if you have a 12-port card with 8 drives, it's possible to add 4 drives to the array in the future and perform what 3ware calls a "migration" action. (With migration, you can also change the stripe size of the array). However, after completing the migration, it's still necessary to grow the filesystem in order to take advantage of the extra space. So, my question is -- how do I grow an xfs filesystem on Linux? And, of course, retain my existing data? Thanks in advance for the pointers. Andy Liebman From owner-linux-xfs@oss.sgi.com Mon May 2 18:25:39 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 May 2005 18:25:42 -0700 (PDT) Received: from imo-d06.mx.aol.com (imo-d06.mx.aol.com [205.188.157.38]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j431Pc7J025684 for ; Mon, 2 May 2005 18:25:39 -0700 Received: from AndyLiebman@aol.com by imo-d06.mx.aol.com (mail_out_v38_r1.7.) id 4.1c5.27446cf8 (17377) for ; Mon, 2 May 2005 21:25:15 -0400 (EDT) From: AndyLiebman@aol.com Message-ID: <1c5.27446cf8.2fa82cfb@aol.com> Date: Mon, 2 May 2005 21:25:15 EDT Subject: Never mind question about xfs_grow To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: 9.0 Security Edition for Windows sub 1200 X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5136 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: AndyLiebman@aol.com Precedence: bulk X-list: linux-xfs Content-Length: 221 Lines: 9 Sorry to ask my previous question. I was mislead by some other printed information that I needed to look for xfs_grow. But now I see that the command is xfs_growfs! Seems straightforward enough. Andy Liebman From owner-linux-xfs@oss.sgi.com Mon May 2 20:28:08 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 May 2005 20:28:11 -0700 (PDT) Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j433S77J003748 for ; Mon, 2 May 2005 20:28:08 -0700 X-ORBL: [67.124.119.21] Received: from taniwha.stupidest.org (adsl-67-124-119-21.dsl.snfc21.pacbell.net [67.124.119.21]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j433RtWx112782; Mon, 2 May 2005 23:27:55 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 53B84528F26; Mon, 2 May 2005 20:27:54 -0700 (PDT) Date: Mon, 2 May 2005 20:27:54 -0700 From: Chris Wedgwood To: AndyLiebman@aol.com Cc: linux-xfs@oss.sgi.com Subject: Re: Please Advise on XFS-grow Message-ID: <20050503032754.GA20574@taniwha.stupidest.org> References: <1ab.37ca7ff7.2fa82b0f@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1ab.37ca7ff7.2fa82b0f@aol.com> X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5138 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 405 Lines: 16 On Mon, May 02, 2005 at 09:17:03PM -0400, AndyLiebman@aol.com wrote: > So, my question is -- how do I grow an xfs filesystem on Linux? And, > of course, retain my existing data? after the block devices has grown (use /proc/partitions to verify this if you like): xfs_growfs /path/to/fs man xfs_growfs for more details (btw, what happens if you loose power or a drive during the RAID migration?) From owner-linux-xfs@oss.sgi.com Mon May 2 23:55:08 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 May 2005 23:55:10 -0700 (PDT) Received: from psi11.psi.ch (psi11.psi.ch [129.129.190.111]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j436t67J011159 for ; Mon, 2 May 2005 23:55:07 -0700 Received: from 129.129.190.113 by psi11.psi.ch (InterScan E-Mail VirusWall NT); Tue, 03 May 2005 08:54:49 +0200 Received: from [129.129.194.181] (pc4568.psi.ch [129.129.194.181]) by psi13.psi.ch with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JGA4A5AW; Tue, 3 May 2005 08:54:48 +0200 Message-ID: <42772037.5030102@psi.ch> Date: Tue, 03 May 2005 08:54:47 +0200 From: Peter Huesser User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com, cw@f00f.org Subject: Re: Invalid packet 21 count! 15 References: <4275C96A.7050900@psi.ch> <20050502223321.GA15361@taniwha.stupidest.org> In-Reply-To: <20050502223321.GA15361@taniwha.stupidest.org> Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-dc81e663-db37-4bf9-89ba-9d8139133a23" X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5140 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: peter.huesser@psi.ch Precedence: bulk X-list: linux-xfs Content-Length: 2128 Lines: 75 This is a multi-part message in MIME format. ------=_NextPartTM-000-dc81e663-db37-4bf9-89ba-9d8139133a23 Content-Type: multipart/alternative; boundary="------------010004050705010404000407" --------------010004050705010404000407 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Chris Wedgwood wrote: >On Mon, May 02, 2005 at 08:32:10AM +0200, Peter Huesser wrote: > > > >>I use xfs on a scientific linux (version 303) installation with the >>2.4.21-27.0.2.EL.XFSsmp kernel. My /var/log/messages file is full of >> >> "Invalid packet 21 count! 15" >> >> > >that's not related to XFS the filesystem, you'll have to see where >they are coming from > > Thank's. I guess you are right. I found something on a redhat webpage: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132788 Pedro --------------010004050705010404000407 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Chris Wedgwood wrote: 
On Mon, May 02, 2005 at 08:32:10AM +0200, Peter Huesser wrote:

  
I use xfs on a scientific linux (version 303) installation with the
2.4.21-27.0.2.EL.XFSsmp kernel. My /var/log/messages file is full of

 "Invalid packet 21 count! 15"
    

that's not related to XFS the filesystem, you'll have to see where
they are coming from

Thank's. I guess you are right. I found something on a redhat webpage: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132788

Pedro

--------------010004050705010404000407-- ------=_NextPartTM-000-dc81e663-db37-4bf9-89ba-9d8139133a23-- From owner-linux-xfs@oss.sgi.com Tue May 3 09:35:31 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 May 2005 09:35:35 -0700 (PDT) Received: from plounts.uits.indiana.edu (plounts.uits.indiana.edu [129.79.1.73]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43GZU7J025074 for ; Tue, 3 May 2005 09:35:31 -0700 Received: from iu-mssg-smtp04.ads.iu.edu (iu-mssg-smtp04.exchange.iu.edu [129.79.1.223]) by plounts.uits.indiana.edu (8.12.10/8.12.10/IUPO) with ESMTP id j43GYhQA000456 for ; Tue, 3 May 2005 11:35:15 -0500 (EST) Received: from iu-mssg-mbx05.ads.iu.edu ([129.79.1.214]) by iu-mssg-smtp04.ads.iu.edu with Microsoft SMTPSVC(5.0.2195.6713); Tue, 3 May 2005 11:35:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: Recommend XFS enabled Linux Distribution Date: Tue, 3 May 2005 11:35:14 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Recommend XFS enabled Linux Distribution Thread-Index: AcVP/RiKwVrdH6BkRBKU38I/NL0gMQAAF/fH From: "Wilkins, Vern" To: X-OriginalArrivalTime: 03 May 2005 16:35:15.0643 (UTC) FILETIME=[15D400B0:01C54FFE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j43GZV7J025077 X-archive-position: 5144 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vwilkins@indiana.edu Precedence: bulk X-list: linux-xfs Content-Length: 1701 Lines: 49 I use Gentoo exclusively. It's definitely not for everyone, but I've used at least a dozen distributions pretty heavily and have phased out using anything else over the last few years. Not so much fun to install and you aren't going to get commercial support like with RedHat, Suse, etc, but much easier to maintain in the long run. Vern Senior Technology Specialist Indiana University Libraries -----Original Message----- From: linux-xfs-bounce@oss.sgi.com on behalf of zwlu@ucdavis.edu Sent: Tue 5/3/2005 11:07 AM To: linux-xfs@oss.sgi.com Cc: Subject: Recommend XFS enabled Linux Distribution Hi XFS gurus, I am building a Linux based File server used mainly as user home directories. These are mainly students who conduct research in computer graphics, data analysis. Here are my hardware: DELL Poweredge 2850 server with Apple Xserve Raid (~ 1.8 TB) with fibre connection between the two. I have installed RHEL4 (x86_64) and enabled XFS (by consulting at the archive here). XFS appears to work okay, but I have not tested the system heavily yet. I am a little bit of uncomfortable with the fact that XFS is not officially supported on RHEL4. RHEL4 will stay on the 2.6.9 kernel for as long as they can, while the XFS patches will not make into the Redhat kernel source there. I am wondering what other people on this list is using currently. SUSE? I also wonder if the Veritas Netbackup will work the distribution, right now we are using Netbackup Data Center 4.5MP8 here. Thank you very much for share your thoughts. -- Zhi-Wei Lu Institute for Data Analysis and Visualization (IDAV) UC Davis Phone: (530)-752-0494 Davis, CA 95616 Fax: (530)-752-8894 From owner-linux-xfs@oss.sgi.com Tue May 3 09:45:09 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 May 2005 09:45:14 -0700 (PDT) Received: from mail.linux-sxs.org (mail.linux-sxs.org [64.116.183.6]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43Gj77J025728 for ; Tue, 3 May 2005 09:45:08 -0700 Received: from mail.linux-sxs.org (localhost [127.0.0.1]) by mail.linux-sxs.org (8.13.4/8.13.4/Debian-1) with ESMTP id j43GjFAL016198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 May 2005 11:45:17 -0500 Received: from localhost (netllama@localhost) by mail.linux-sxs.org (8.13.4/8.13.4/Submit) with ESMTP id j43GjFuf016195; Tue, 3 May 2005 11:45:15 -0500 X-Authentication-Warning: mail.linux-sxs.org: netllama owned process doing -bs Date: Tue, 3 May 2005 11:45:15 -0500 (EST) From: Net Llama! To: "Wilkins, Vern" cc: linux-xfs@oss.sgi.com Subject: RE: Recommend XFS enabled Linux Distribution In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: milter-sender/0.62.837 (localhost [127.0.0.1]); Tue, 03 May 2005 11:45:17 -0500 Received-SPF: pass (mail.linux-sxs.org: domain of netllama@linux-sxs.org designates 127.0.0.1 as permitted sender) receiver=mail.linux-sxs.org; client-ip=127.0.0.1; helo=mail.linux-sxs.org; envelope-from=netllama@linux-sxs.org; x-software=spfmilter 0.95 http://www.acme.com/software/spfmilter/ with libspf2; X-archive-position: 5145 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 1877 Lines: 47 How many boxes are you currently maintaining? On Tue, 3 May 2005, Wilkins, Vern wrote: > I use Gentoo exclusively. It's definitely not for everyone, but I've used at least a dozen distributions pretty heavily and have phased out using anything else over the last few years. Not so much fun to install and you aren't going to get commercial support like with RedHat, Suse, etc, but much easier to maintain in the long run. > > Vern > Senior Technology Specialist > Indiana University Libraries > > > -----Original Message----- > From: linux-xfs-bounce@oss.sgi.com on behalf of zwlu@ucdavis.edu > Sent: Tue 5/3/2005 11:07 AM > To: linux-xfs@oss.sgi.com > Cc: > Subject: Recommend XFS enabled Linux Distribution > Hi XFS gurus, > > I am building a Linux based File server used mainly as user home directories. > These are mainly students who conduct research in computer graphics, > data analysis. Here are my hardware: > > DELL Poweredge 2850 server with Apple Xserve Raid (~ 1.8 TB) with fibre > connection between the two. > > I have installed RHEL4 (x86_64) and enabled XFS (by consulting > at the archive here). XFS appears to work okay, but I have not > tested the system heavily yet. I am a little bit of uncomfortable with the > fact that XFS is not officially supported on RHEL4. RHEL4 will stay on the > 2.6.9 kernel for as long as they can, while the XFS patches will not make into > the Redhat kernel source there. > > I am wondering what other people on this list is using currently. SUSE? > I also wonder if the Veritas Netbackup will work the distribution, right now > we are using Netbackup Data Center 4.5MP8 here. > > Thank you very much for share your thoughts. > > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org LlamaLand http://netllama.linux-sxs.org From owner-linux-xfs@oss.sgi.com Tue May 3 10:51:28 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 May 2005 10:51:31 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43HpS7J030038 for ; Tue, 3 May 2005 10:51:28 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j43JXfQo014062 for ; Tue, 3 May 2005 12:33:41 -0700 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j43HpER07331674; Tue, 3 May 2005 12:51:14 -0500 (CDT) Message-ID: <4277BA12.4020206@sgi.com> Date: Tue, 03 May 2005 12:51:14 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Net Llama!" CC: "Wilkins, Vern" , linux-xfs@oss.sgi.com Subject: Re: Recommend XFS enabled Linux Distribution References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5146 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 126 Lines: 5 SuSE SLES9 would be a good choice. SGI works with SuSE to ensure that the xfs code in that distro is in good shape. -Eric From owner-linux-xfs@oss.sgi.com Tue May 3 10:58:19 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 May 2005 10:58:23 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43HwI7J030947 for ; Tue, 3 May 2005 10:58:19 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j43Hw6xT005353 for ; Tue, 3 May 2005 12:58:06 -0500 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j43Hw40F14351156; Tue, 3 May 2005 12:58:05 -0500 (CDT) Message-ID: <4277BBAC.10005@sgi.com> Date: Tue, 03 May 2005 12:58:04 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Bartoszewski CC: linux-xfs@oss.sgi.com Subject: Re: Old XFS_GEOMETRY change References: <20050429174136.GA21813@ugrad.cs.ualberta.ca> In-Reply-To: <20050429174136.GA21813@ugrad.cs.ualberta.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5147 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 640 Lines: 23 John Bartoszewski wrote: > I think I've run into the problem listed here: > > http://oss.sgi.com/archives/linux-xfs/2002-09/msg00010.html > > Which is that the xfs file system was created with the old XFS_GEOMETRY > ioctl and all the tools I have use the new XFS_GEOMETRY ioctl. > > Has someone written a conversion tool? > > Where do I find the old headers to rebuild the tools? > > Would something like 'old_xfsdump -l0 - /dev/hda2 | new_xfrestore - .' > work? > > Thanks, > John > This has more to do with the kernel you're running vs. your userspace, not the on-disk format. What kernel & userspace are you running... -eric From owner-linux-xfs@oss.sgi.com Tue May 3 11:03:58 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 May 2005 11:04:04 -0700 (PDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.192]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43I3w7J031501 for ; Tue, 3 May 2005 11:03:58 -0700 Received: by wproxy.gmail.com with SMTP id 68so2136923wra for ; Tue, 03 May 2005 11:03:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QJD6AImmiLoLeBmwFsTJSatzmFt5nuyFpCWJ11ooIJ0lP8J1GJLQaxJHuwWMtL6wcZf6P8z95FKzGGo/oj3IvE0x1ONg//pYQr4H4aWIss+gn9Ne/yGSUN3uCGzsBsG63pl8dHehwGkL7Tu/FD2CDi7duAgsUfpRCsGm+/GAOdI= Received: by 10.54.91.6 with SMTP id o6mr18580wrb; Tue, 03 May 2005 11:03:45 -0700 (PDT) Received: by 10.54.2.40 with HTTP; Tue, 3 May 2005 11:03:45 -0700 (PDT) Message-ID: <87f94c37050503110379fbacdf@mail.gmail.com> Date: Tue, 3 May 2005 14:03:45 -0400 From: Greg Freemyer Reply-To: Greg Freemyer To: Eric Sandeen Subject: Re: Recommend XFS enabled Linux Distribution Cc: Net Llama! , "Wilkins, Vern" , linux-xfs@oss.sgi.com In-Reply-To: <4277BA12.4020206@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <4277BA12.4020206@sgi.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j43I3w7J031503 X-archive-position: 5148 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: greg.freemyer@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 429 Lines: 16 On 5/3/05, Eric Sandeen wrote: > SuSE SLES9 would be a good choice. SGI works with SuSE to ensure that > the xfs code in that distro is in good shape. > > -Eric > If you go with SLES9, be sure to get SP2 (in beta right now). SUSE has a lot of device mapper (LVM2), multipath, and drbd issues resolved in SP2 from what I understand. Greg -- Greg Freemyer The Norcross Group Forensics for the 21st Century From owner-linux-xfs@oss.sgi.com Tue May 3 12:02:41 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 May 2005 12:02:50 -0700 (PDT) Received: from rrzmta2.rz.uni-regensburg.de (rrzmta2.rz.uni-regensburg.de [132.199.1.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43J2e7J001944 for ; Tue, 3 May 2005 12:02:41 -0700 Received: from rrzmta2.rz.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 877E314A14; Tue, 3 May 2005 21:02:35 +0200 (CEST) Received: from pc50794.physik.uni-regensburg.de (pc50794.physik.uni-regensburg.de [132.199.98.140]) by rrzmta2.rz.uni-regensburg.de (Postfix) with ESMTP id EE381149CE; Tue, 3 May 2005 21:02:34 +0200 (CEST) Received: from guc28561 by pc50794.physik.uni-regensburg.de with local (Exim 3.35 #1 (Debian)) id 1DT2f4-0003ih-00; Tue, 03 May 2005 21:02:26 +0200 Date: Tue, 3 May 2005 21:02:26 +0200 From: Christian Guggenberger To: Greg Freemyer Cc: Eric Sandeen , Net Llama! , "Wilkins, Vern" , linux-xfs@oss.sgi.com Subject: Re: Recommend XFS enabled Linux Distribution Message-ID: <20050503190226.GA14228@pc50794.physik.uni-regensburg.de> Reply-To: christian.guggenberger@physik.uni-regensburg.de References: <4277BA12.4020206@sgi.com> <87f94c37050503110379fbacdf@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87f94c37050503110379fbacdf@mail.gmail.com> User-Agent: Mutt/1.3.28i X-archive-position: 5149 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Content-Length: 563 Lines: 19 On Tue, May 03, 2005 at 02:03:45PM -0400, Greg Freemyer wrote: > On 5/3/05, Eric Sandeen wrote: > > SuSE SLES9 would be a good choice. SGI works with SuSE to ensure that > > the xfs code in that distro is in good shape. > > > > -Eric > > > If you go with SLES9, be sure to get SP2 (in beta right now). SUSE > has a lot of device mapper (LVM2), multipath, and drbd issues resolved > in SP2 from what I understand. > could you me point to some details regarding the lvm2 issues solved in the beta of SP2? thanks in advance, - Christian From owner-linux-xfs@oss.sgi.com Tue May 3 12:16:16 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 May 2005 12:16:21 -0700 (PDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43JGF7J002968 for ; Tue, 3 May 2005 12:16:16 -0700 Received: by wproxy.gmail.com with SMTP id 68so14627wra for ; Tue, 03 May 2005 12:16:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mfAzPvmEWcgmLMU254/x9KsR8955kwaGVIbSkFRjGRXiYcyLoIsAl6nm2arv3OP2m2mwfgMuvVRtOS1nF8EdEbFcnurMclBzC0p4sLGk1pJHyFv71u1Clib7P6rkzvqZC6KGwd8XZ7ia87rF50GcM60l0lTmPIvEHNvgpDIfTrs= Received: by 10.54.147.4 with SMTP id u4mr49165wrd; Tue, 03 May 2005 12:16:00 -0700 (PDT) Received: by 10.54.2.40 with HTTP; Tue, 3 May 2005 12:16:00 -0700 (PDT) Message-ID: <87f94c370505031216331c83dd@mail.gmail.com> Date: Tue, 3 May 2005 15:16:00 -0400 From: Greg Freemyer Reply-To: Greg Freemyer To: christian.guggenberger@physik.uni-regensburg.de Subject: Re: Recommend XFS enabled Linux Distribution Cc: Eric Sandeen , Net Llama! , "Wilkins, Vern" , linux-xfs@oss.sgi.com In-Reply-To: <20050503190226.GA14228@pc50794.physik.uni-regensburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <4277BA12.4020206@sgi.com> <87f94c37050503110379fbacdf@mail.gmail.com> <20050503190226.GA14228@pc50794.physik.uni-regensburg.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j43JGG7J002970 X-archive-position: 5150 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: greg.freemyer@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 1258 Lines: 37 On 5/3/05, Christian Guggenberger wrote: > On Tue, May 03, 2005 at 02:03:45PM -0400, Greg Freemyer wrote: > > On 5/3/05, Eric Sandeen wrote: > > > SuSE SLES9 would be a good choice. SGI works with SuSE to ensure that > > > the xfs code in that distro is in good shape. > > > > > > -Eric > > > > > If you go with SLES9, be sure to get SP2 (in beta right now). SUSE > > has a lot of device mapper (LVM2), multipath, and drbd issues resolved > > in SP2 from what I understand. > > > > could you me point to some details regarding the lvm2 issues solved in the > beta of SP2? > LVM2 is the userspace counterpart of the kernel DM (device mapper). I am not aware of any userspace issues, but I believe that a DM issues have been fixed and SuSE did a complete audit of the DM multipath logic in preparation for SP2. Specifically I believe Lars Marowsky-Bree is the official SLES maintainer for the 3 areas I mentioned above. I have seen him routinely post bugs/fixes on the dm-devel mailing list for the last several months. I have also seen a message of his that said SP2 was closely following any dm issues. HTH Greg -- Greg Freemyer The Norcross Group Forensics for the 21st Century From owner-linux-xfs@oss.sgi.com Wed May 4 00:42:51 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 May 2005 00:42:56 -0700 (PDT) Received: from redix.it (host49-169.pool8172.interbusiness.it [81.72.169.49]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j447gn7J012290 for ; Wed, 4 May 2005 00:42:50 -0700 Received: (qmail 2977 invoked by uid 72); 4 May 2005 07:42:33 -0000 Received: by mail.redix.it (tmda-sendmail, from uid 72); Wed, 04 May 2005 09:42:33 +0200 (CEST) Received: from 192.168.0.150 (SquirrelMail authenticated user roberto) by mail.redix.it:443 with HTTP; Wed, 4 May 2005 09:42:32 +0200 (CEST) Message-ID: <1089.192.168.0.150.1115192552.squirrel@mail.redix.it:443> In-Reply-To: <4277BA12.4020206@sgi.com> References: <4277BA12.4020206@sgi.com> Date: Wed, 4 May 2005 09:42:32 +0200 (CEST) Subject: Re: Recommend XFS enabled Linux Distribution To: "Eric Sandeen" Cc: linux-xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) From: Roberto X-archive-position: 5151 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roberto@redix.it Precedence: bulk X-list: linux-xfs Content-Length: 173 Lines: 11 > SuSE SLES9 would be a good choice. SGI works with SuSE to ensure that > the xfs code in that distro is in good shape. > > -Eric > What about SUSE prof. 9.3 ? Roberto From owner-linux-xfs@oss.sgi.com Wed May 4 01:00:49 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 May 2005 01:00:57 -0700 (PDT) Received: from mail.charite.de (mail.charite.de [160.45.207.131]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4480n7J013227 for ; Wed, 4 May 2005 01:00:49 -0700 Received: from postamt.charite.de (postamt.charite.de [160.45.207.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.charite.de (Postfix) with ESMTP id DF3DE2208C1; Wed, 4 May 2005 10:00:38 +0200 (CEST) Received: by postamt.charite.de (Postfix, from userid 7945) id A69E9220713; Wed, 4 May 2005 10:00:31 +0200 (CEST) Date: Wed, 4 May 2005 10:00:31 +0200 From: Ralf Hildebrandt To: zwlu@ucdavis.edu Cc: linux-xfs@oss.sgi.com Subject: Re: Recommend XFS enabled Linux Distribution Message-ID: <20050504080031.GH26975@charite.de> References: <200505031607.j43G7hXH011447@alegre.cipic.ucdavis.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200505031607.j43G7hXH011447@alegre.cipic.ucdavis.edu> User-Agent: Mutt/1.5.9i X-archive-position: 5152 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Ralf.Hildebrandt@charite.de Precedence: bulk X-list: linux-xfs Content-Length: 547 Lines: 14 * zwlu@ucdavis.edu : > DELL Poweredge 2850 server with Apple Xserve Raid (~ 1.8 TB) with fibre > connection between the two. Ah, we have those boxes as well. We run Debian. The sarge installer offers XFS as a choice. -- Ralf Hildebrandt (i.A. des IT-Zentrums) Ralf.Hildebrandt@charite.de Charite - Universitätsmedizin Berlin Tel. +49 (0)30-450 570-155 Gemeinsame Einrichtung von FU- und HU-Berlin Fax. +49 (0)30-450 570-962 IT-Zentrum Standort CBF send no mail to spamtrap@charite.de From owner-linux-xfs@oss.sgi.com Wed May 4 06:27:46 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 May 2005 06:27:49 -0700 (PDT) Received: from cirse.extra.cea.fr (cirse.extra.cea.fr [132.166.172.102]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44DRe7J030237 for ; Wed, 4 May 2005 06:27:45 -0700 Received: from cincidele.saclay.cea.fr (cincidele.saclay.cea.fr [132.166.192.111]) by cirse.extra.cea.fr (8.12.10/8.12.10/CEAnet-Internet.4.0) with ESMTP id j44DRMAN013494 for ; Wed, 4 May 2005 15:27:22 +0200 (MEST) Received: from pisaure.intra.cea.fr (unverified) by cincidele.saclay.cea.fr (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Wed, 4 May 2005 15:27:21 +0200 Received: from nenuphar.saclay.cea.fr (nenuphar.saclay.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.12.11/8.12.11) with ESMTP id j44DPkN9011923; Wed, 4 May 2005 15:25:46 +0200 (envelope-from degremont@ocre.cea.fr) Received: from ocre.cea.fr ([132.165.65.70]) by nenuphar.saclay.cea.fr (8.12.10/8.12.10/CEAnet-internes.4.0) with ESMTP id j44DRKZa020395; Wed, 4 May 2005 15:27:20 +0200 (MEST) Message-ID: <4278CDB8.3060309@ocre.cea.fr> Date: Wed, 04 May 2005 15:27:20 +0200 From: Aurelien Degremont - Stagiaire User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us MIME-Version: 1.0 To: Dean Roehrich CC: linux-xfs@oss.sgi.com Subject: Re: vfs_altfsid & dm_fsid References: <20050428021133.A885C4FE57@chewtoy.americas.sgi.com> In-Reply-To: <20050428021133.A885C4FE57@chewtoy.americas.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 5153 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: degremont@ocre.cea.fr Precedence: bulk X-list: linux-xfs Content-Length: 2420 Lines: 70 Dean Roehrich a écrit: > If your filesystem of choice doesn't have an fsid, then you could just > generate one that is valid while the filesystem is mounted and is not written > to the filesystem, or you could come up with something else. Whatever you > choose for an fsid should fit into a 64-bit type. > 1) The fsid should be a parameter to dm_send_mount_event() and > dm_send_namesp_event() and dm_send_unmount_event(). > The get_fsid op in struct filesystem_dmapi_operations should be > dropped. Ok, so we need to modify : xfs_dm_mount() xfs_dm_send_namesp_event() xfs_dm_send_unmount_event() The fsid could be taken in vfsp. > 2) The dm_fsys_vector_t should be folded into struct > filesystem_dmapi_operations. The new ops vector should be > a parameter to dm_send_mount_event(). > The part where today we copy the ops vector from > fsys_function_vector_t to dm_fsys_vector_t seems cumbersome and > just makes things hard to understand, so maybe > that copy should be skipped and some of these datatypes could > be removed. > The get_fsys_vector op in struct filesystem_dmapi_operations should be > dropped. Remove dm_query_fsys_for_vector() dm_fsys_vector() Move the fsys_vector pointer to dmapiops. Add a bitmask that informs which functions id set when registering. Change all the dm_sys_vector calls in dmapi. Maybe the dm_vector_map should be replace by a list_head ? > 3) It would be nice to keep in mind distributed filesystems and stackable > filesystems; try to make it easier, not harder, to move in those > directions. Unfortunately, I have no experience with the Linux > view of stackable filesystems and I don't quite know how to approach > that problem. Ok, I'm not specialist neither. I'll try... > 4) The new, unified, ops vector should be kept on a > per-filesystem-instance basis, rather than one ops vector to be > shared by all filesystems. So, all the by_fstype should be changed to by_fsid ? So, we're back to the issue : "how fetch the fsid only knowing the superblock ?" Maybe, we can store a mapping between the superblock and the fsid in the dm_fsys_map ? But I don't like using the sb pointer address as id (especially concerning distributed fs) If you have a better solution... > Does that sum up the things that interest you? Yes, It did :). I'd like to discuss all of this. As soon as we agree, I could start to patch this. Aurelien From owner-linux-xfs@oss.sgi.com Wed May 4 08:12:00 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 May 2005 08:12:14 -0700 (PDT) Received: from julesburg.uits.indiana.edu (julesburg.uits.indiana.edu [129.79.1.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44FBx7J005461 for ; Wed, 4 May 2005 08:11:59 -0700 Received: from iu-mssg-smtp04.ads.iu.edu (iu-mssg-smtp04.exchange.iu.edu [129.79.1.223]) by julesburg.uits.indiana.edu (8.12.10/8.12.10/IUPO) with ESMTP id j44FBQaX010591; Wed, 4 May 2005 10:11:33 -0500 (EST) Received: from iu-mssg-mbx05.ads.iu.edu ([129.79.1.214]) by iu-mssg-smtp04.ads.iu.edu with Microsoft SMTPSVC(5.0.2195.6713); Wed, 4 May 2005 10:11:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: Recommend XFS enabled Linux Distribution Date: Wed, 4 May 2005 10:10:43 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Recommend XFS enabled Linux Distribution Thread-Index: AcVP/227xIwRiH61QEGgplbTiKpXDAAubnX9 From: "Wilkins, Vern" To: "Net Llama!" Cc: X-OriginalArrivalTime: 04 May 2005 15:11:20.0679 (UTC) FILETIME=[872B3770:01C550BB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j44FC07J005463 X-archive-position: 5154 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vwilkins@indiana.edu Precedence: bulk X-list: linux-xfs Content-Length: 3298 Lines: 66 >How many boxes are you currently maintaining? Just three Gentoo servers, a few windows 2003 servers, and a lot of Windows and Gentoo workstations. Our department has several additional Gentoo servers managed by other staff, and across campus there are numerous larger departments with a lot of Gentoo workstations and servers. I probably shouldn't say which ones for security reasons, but we have had numerous departments on campus move completely from FreeBSD and/or other Linux distributions to Gentoo. I notice there's a lot of rivalry and distribution loyalty with Linux now, and a lot of people really dislike Gentoo, but my point is just that it has worked really well for us. I don't manage a lot of Gentoo servers, and they are all running only a few services, but I can say from the workstation side, that managing more machines does not result in a linear increase in workload. We've always had a very diverse infrastructure of Windows, Netware, various Linux/Unix servers and managed them more or less individually. As we've consolidated and come up with more centralized ways of managing our machines, it's all gotten a lot easier, but especially the management of the Gentoo machines. Vern -----Original Message----- From: Net Llama! [mailto:netllama@linux-sxs.org] Sent: Tue 5/3/2005 11:45 AM To: Wilkins, Vern Cc: linux-xfs@oss.sgi.com Subject: RE: Recommend XFS enabled Linux Distribution How many boxes are you currently maintaining? On Tue, 3 May 2005, Wilkins, Vern wrote: > I use Gentoo exclusively. It's definitely not for everyone, but I've used at least a dozen distributions pretty heavily and have phased out using anything else over the last few years. Not so much fun to install and you aren't going to get commercial support like with RedHat, Suse, etc, but much easier to maintain in the long run. > > Vern > Senior Technology Specialist > Indiana University Libraries > > > -----Original Message----- > From: linux-xfs-bounce@oss.sgi.com on behalf of zwlu@ucdavis.edu > Sent: Tue 5/3/2005 11:07 AM > To: linux-xfs@oss.sgi.com > Cc: > Subject: Recommend XFS enabled Linux Distribution > Hi XFS gurus, > > I am building a Linux based File server used mainly as user home directories. > These are mainly students who conduct research in computer graphics, > data analysis. Here are my hardware: > > DELL Poweredge 2850 server with Apple Xserve Raid (~ 1.8 TB) with fibre > connection between the two. > > I have installed RHEL4 (x86_64) and enabled XFS (by consulting > at the archive here). XFS appears to work okay, but I have not > tested the system heavily yet. I am a little bit of uncomfortable with the > fact that XFS is not officially supported on RHEL4. RHEL4 will stay on the > 2.6.9 kernel for as long as they can, while the XFS patches will not make into > the Redhat kernel source there. > > I am wondering what other people on this list is using currently. SUSE? > I also wonder if the Veritas Netbackup will work the distribution, right now > we are using Netbackup Data Center 4.5MP8 here. > > Thank you very much for share your thoughts. > > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org LlamaLand http://netllama.linux-sxs.org From owner-linux-xfs@oss.sgi.com Wed May 4 20:27:13 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 May 2005 20:27:19 -0700 (PDT) Received: from ausmail.coremetrics.com (mail.coremetrics.com [66.45.103.238]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j453RC7J003126 for ; Wed, 4 May 2005 20:27:12 -0700 Received: by ausmail.core.coremetrics.com with Internet Mail Service (5.5.2657.72) id ; Wed, 4 May 2005 22:26:57 -0500 Message-ID: <85063BBE668FD411944400D0B744267A10BBD1F7@ausmail.core.coremetrics.com> From: "Harris, Jeff" To: linux-xfs@oss.sgi.com Subject: Running into a roadblock with RHES3, the 27.0.2 kernel, and QLogi c 2300 drivers Date: Wed, 4 May 2005 22:26:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 5155 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: JHarris@coremetrics.com Precedence: bulk X-list: linux-xfs Content-Length: 1552 Lines: 59 Hello, we're trying to get a working XFS kernel on our RHES3 servers in order to support a migration project. Since the standard patches won't work against Redhat's kernels, we had to go with the 27.0.2 testing kernel from the ftp site. The included Qla2300 driver in Redhat's kernel is broken when working with Engenio products (IBM Fast, Storagetek, etc), and we have to replace it with another. When building the qlogic driver, we run into no compile errors, however, we're running into long division problems with undefined symbols in the modules. The specific symbol is __udivdi3. [root@pares3 qlogic-7.03.00]# depmod -ae depmod: *** Unresolved symbols in /lib/modules/2.4.21-27.0.2.EL.sgi9custom/kernel/drivers/addon/qla2200/qla220 0.o depmod: __udivdi3 depmod: *** Unresolved symbols in /lib/modules/2.4.21-27.0.2.EL.sgi9custom/kernel/drivers/addon/qla2200/qla230 0.o depmod: __udivdi3 In order to get this far, I actually had to make mrproper and recompile the entire kernel tree into a custom kernel. It's basically the same as the sgi9BOOT kernel. Just to be clear, this kernel boots up just fine and seems to be working okay, we just can't get our module in it. I think I might have changed the cpu optimizations to Pentium 4. This is running on i386, so I'm not sure why it's using 64bit symbols. Can someone shed some light on this? -- Jeff Harris - jharris@coremetrics.com Senior Systems Administrator CoreMetrics [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Thu May 5 16:52:03 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 May 2005 16:52:07 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j45Nq0Ov014887 for ; Thu, 5 May 2005 16:52:01 -0700 Received: from mail.ocs.com.au (kao1.melbourne.sgi.com [134.14.55.179]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA10641 for ; Fri, 6 May 2005 09:51:41 +1000 Received: from ocs3.ocs.com.au (ocs3.ocs.com.au [192.168.255.3]) by mail.ocs.com.au (Postfix) with ESMTP id 65E751800B5; Fri, 6 May 2005 09:51:27 +1000 (EST) Received: by ocs3.ocs.com.au (Postfix, from userid 16331) id 1B40870010B; Fri, 6 May 2005 09:51:21 +1000 (EST) Received: from ocs3.ocs.com.au (localhost [127.0.0.1]) by ocs3.ocs.com.au (Postfix) with ESMTP id 17E361000D8; Fri, 6 May 2005 09:51:21 +1000 (EST) X-Mailer: exmh version 2.6.3_20040314 03/14/2004 with nmh-1.0.4 From: Keith Owens To: "Harris, Jeff" Cc: linux-xfs@oss.sgi.com Subject: Re: Running into a roadblock with RHES3, the 27.0.2 kernel, and QLogi c 2300 drivers In-reply-to: Your message of "Wed, 04 May 2005 22:26:55 EST." <85063BBE668FD411944400D0B744267A10BBD1F7@ausmail.core.coremetrics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 06 May 2005 09:51:21 +1000 Message-ID: <12101.1115337081@ocs3.ocs.com.au> X-archive-position: 5157 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1135 Lines: 19 On Wed, 4 May 2005 22:26:55 -0500 , "Harris, Jeff" wrote: >Hello, we're trying to get a working XFS kernel on our RHES3 servers in >order to support a migration project. Since the standard patches won't work >against Redhat's kernels, we had to go with the 27.0.2 testing kernel from >the ftp site. The included Qla2300 driver in Redhat's kernel is broken when >working with Engenio products (IBM Fast, Storagetek, etc), and we have to >replace it with another. When building the qlogic driver, we run into no >compile errors, however, we're running into long division problems with >undefined symbols in the modules. The specific symbol is __udivdi3. That is generated by division involving 64 bit numbers on a 32 bit ix86. Dig through the object code (objdump -Sr foo.o) to find the references to __udivdi3, look at the source code for the offending functions to find the division and replace them with do_div() from include/asm-i386/div64.h. Beware that do_div() modifies its first parameter in place, so if you just want the result then you need to copy the first value to a scratch variable first. From owner-linux-xfs@oss.sgi.com Thu May 5 19:20:44 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 May 2005 19:20:49 -0700 (PDT) Received: from ausmail.coremetrics.com (mail.coremetrics.com [66.45.103.238]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j462KhOv025693 for ; Thu, 5 May 2005 19:20:44 -0700 Received: by ausmail.core.coremetrics.com with Internet Mail Service (5.5.2657.72) id ; Thu, 5 May 2005 21:20:25 -0500 Message-ID: <85063BBE668FD411944400D0B744267A10BBD66B@ausmail.core.coremetrics.com> From: "Harris, Jeff" To: Keith Owens , "Harris, Jeff" Cc: linux-xfs@oss.sgi.com Subject: RE: Running into a roadblock with RHES3, the 27.0.2 kernel, and Q Logi c 2300 drivers Date: Thu, 5 May 2005 21:20:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 5158 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: JHarris@coremetrics.com Precedence: bulk X-list: linux-xfs Content-Length: 1669 Lines: 40 Well, I found it last night, sorry for not posting. It's coming from enabling > 2TB volumes in the kernel config. LBD I believe. Soon as we turned that off all was well! Thanks for the troubleshooting tips though, I'll use those next time. :) Jeff -----Original Message----- From: Keith Owens [mailto:kaos@sgi.com] Sent: Thursday, May 05, 2005 6:51 PM To: Harris, Jeff Cc: linux-xfs@oss.sgi.com Subject: Re: Running into a roadblock with RHES3, the 27.0.2 kernel, and QLogi c 2300 drivers On Wed, 4 May 2005 22:26:55 -0500 , "Harris, Jeff" wrote: >Hello, we're trying to get a working XFS kernel on our RHES3 servers in >order to support a migration project. Since the standard patches won't work >against Redhat's kernels, we had to go with the 27.0.2 testing kernel from >the ftp site. The included Qla2300 driver in Redhat's kernel is broken when >working with Engenio products (IBM Fast, Storagetek, etc), and we have to >replace it with another. When building the qlogic driver, we run into no >compile errors, however, we're running into long division problems with >undefined symbols in the modules. The specific symbol is __udivdi3. That is generated by division involving 64 bit numbers on a 32 bit ix86. Dig through the object code (objdump -Sr foo.o) to find the references to __udivdi3, look at the source code for the offending functions to find the division and replace them with do_div() from include/asm-i386/div64.h. Beware that do_div() modifies its first parameter in place, so if you just want the result then you need to copy the first value to a scratch variable first. [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Fri May 6 06:09:47 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 06 May 2005 06:09:50 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46D9kOv009215 for ; Fri, 6 May 2005 06:09:47 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j46D9TxT015748 for ; Fri, 6 May 2005 08:09:29 -0500 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j46D9SR07528539; Fri, 6 May 2005 08:09:28 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1DU2a8-0006CW-00; Fri, 06 May 2005 08:09:28 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: PARTIAL TAKE 935317 - fix nopage prototype Message-Id: From: Christoph Hellwig Date: Fri, 06 May 2005 08:09:28 -0500 X-archive-position: 5159 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 412 Lines: 13 Date: Fri May 6 06:09:21 PDT 2005 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.6.x Inspected by: felixb The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:192204a fs/xfs/linux-2.6/xfs_file.c - 1.122 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_file.c.diff?r1=text&tr1=1.122&r2=text&tr2=1.121&f=h From owner-linux-xfs@oss.sgi.com Sat May 7 10:15:11 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 May 2005 10:15:17 -0700 (PDT) Received: from cmsout03.mbox.net (cmsout03.mbox.net [165.212.64.33]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j47HFBOv025416 for ; Sat, 7 May 2005 10:15:11 -0700 Received: from cmsout03.mbox.net (cmsout03.mbox.net [165.212.64.33]) by cmsout03.mbox.net (Postfix) with ESMTP id A1450136 for ; Sat, 7 May 2005 17:14:51 +0000 (GMT) Received: from uadvg130.cms.usa.net [165.212.11.130] by cmsout03.mbox.net via smtad (C8.MAIN.3.21U); Sat, 07 May 2005 17:14:51 GMT X-USANET-Source: 165.212.11.130 IN xis@usa.net uadvg130.cms.usa.net X-USANET-MsgId: XID591JegRoz1464X03 Received: from cmsweb14.cms.usa.net [165.212.8.14] by uadvg130.cms.usa.net (ASMTP/) via mtad (C8.MAIN.3.21E) with ESMTP id 480JegRoY0010M30; Sat, 07 May 2005 17:14:50 GMT X-USANET-Auth: 165.212.8.14 AUTO xis@usa.net cmsweb14.cms.usa.net Received: from 24.117.22.95 [24.117.22.95] by cmsweb14.cms.usa.net (USANET web-mailer CM.0402.7.24); Sat, 07 May 2005 17:14:49 -0000 Date: Sat, 07 May 2005 11:14:49 -0600 From: ROGER NOEL To: Subject: XFS Block size X-Mailer: USANET web-mailer (CM.0402.7.24) Mime-Version: 1.0 Message-ID: <374JegRox6768S14.1115486089@cmsweb14.cms.usa.net> Content-Type: text/plain; charset=ISO-8859-1 Z-USANET-MsgId: XID480JegRoY0010X30 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j47HFBOv025418 X-archive-position: 5160 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xis@usa.net Precedence: bulk X-list: linux-xfs Content-Length: 681 Lines: 17 Hi, I'm new to Linux, recently installed SUSE Ent 9 and was disappointed to find the max disk block size in XFS was only 4K even though documentation on XFS indicated it could support block size up to 64K. I found a reference on you pake that indicated other block size as a 'kernel compile option' on Intel 64 platform. Please advise or provide me with a good source on how this can be accomplished. It is of particular importance to my application that writes typical files above 20GB. Having bigger block size has made a huge performance difference under windows and I would like to give Linux an honest shot and providing comparable performance. Thanks. From owner-linux-xfs@oss.sgi.com Sat May 7 16:14:13 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 May 2005 16:14:20 -0700 (PDT) Received: from ylpvm29.prodigy.net (ylpvm29-ext.prodigy.net [207.115.57.60]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j47NEDOv008381 for ; Sat, 7 May 2005 16:14:13 -0700 Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by ylpvm29.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j47NDpIC017628 for ; Sat, 7 May 2005 19:13:51 -0400 X-ORBL: [67.124.119.21] Received: from taniwha.stupidest.org (adsl-67-124-119-21.dsl.snfc21.pacbell.net [67.124.119.21]) by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j47NDov9136070; Sat, 7 May 2005 19:13:53 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 57E56528F22; Sat, 7 May 2005 16:13:50 -0700 (PDT) Date: Sat, 7 May 2005 16:13:50 -0700 From: Chris Wedgwood To: ROGER NOEL Cc: linux-xfs@oss.sgi.com Subject: Re: XFS Block size Message-ID: <20050507231350.GA7738@taniwha.stupidest.org> References: <374JegRox6768S14.1115486089@cmsweb14.cms.usa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <374JegRox6768S14.1115486089@cmsweb14.cms.usa.net> X-archive-position: 5161 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 1333 Lines: 39 On Sat, May 07, 2005 at 11:14:49AM -0600, ROGER NOEL wrote: > I'm new to Linux, recently installed SUSE Ent 9 and was disappointed > to find the max disk block size in XFS was only 4K even though > documentation on XFS indicated it could support block size up to > 64K. Strictly speaking this is a Linux limitation not an XFS limitation (well, it depnds how you look at it I guess). > I found a reference on you pake that indicated other block size as a > 'kernel compile option' on Intel 64 platform. If you use ia64 with 64k pages yes, ia64 with 16k page will have a 16k block size limit. x86-64 has a 4k limit. > Please advise or provide me with a good source on how this can be > accomplished. man mkfs.xfs > It is of particular importance to my application that writes typical > files above 20GB. I do this all the time. 4K blocks work just fine and I doubt there will be much benefit using larger blocks even on platforms where you can. > Having bigger block size has made a huge performance difference > under windows and I would like to give Linux an honest shot and > providing comparable performance. I don't think under Linux is will make that much of a difference. If you really want to use larger blocks (assuming your platform is 4K-page-size inflicted) you might want to use a realtime subvolume volume. From owner-linux-xfs@oss.sgi.com Sat May 7 18:21:04 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 May 2005 18:21:13 -0700 (PDT) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j481L2Ov016635 for ; Sat, 7 May 2005 18:21:03 -0700 Received: (qmail invoked by alias); 08 May 2005 01:20:39 -0000 Received: from G1532.g.pppool.de (EHLO [192.168.10.11]) [80.185.21.50] by mail.gmx.net (mp019) with SMTP; 08 May 2005 03:20:39 +0200 X-Authenticated: #2986359 Message-ID: <427D6961.6080000@gmx.net> Date: Sun, 08 May 2005 03:20:33 +0200 From: Christian User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050326) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ReiserFS List CC: linux-crypto@nl.linux.org, Ext3-users@redhat.com, JFS Discussion , "linux-xfs@oss.sgi.com" Subject: 2.6.12-rc3-mm2 benchmarks X-Enigmail-Version: 0.90.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-archive-position: 5162 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: evilninja@gmx.net Precedence: bulk X-list: linux-xfs Content-Length: 756 Lines: 31 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [!! i've Cc'ed several fs lists, please remove when when replying !!] hi all, from time to time i do some benchmarks for several filesystems and several crypto-algorithms too, details here: http://nerdbynature.de/bench/ latest results here: http://nerdbynature.de/bench/prinz/2.6.12-rc3-mm2/bonnie.html http://nerdbynature.de/bench/prinz/2.6.12-rc3-mm2/tiobench.txt Christian. - -- BOFH excuse #173: Recursive traversal of loopback mount points -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCfWlhC/PVm5+NVoYRAmCBAJ9D+UrpvNJ+AoJijJwCN3DVs1Da/QCgkMoC Ea5VVCQ1Q2XrJNahJQoif1c= =m8tN -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Mon May 9 09:03:07 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 May 2005 09:03:21 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j49G37Ov015820 for ; Mon, 9 May 2005 09:03:07 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j49Hk3mG019987 for ; Mon, 9 May 2005 10:46:04 -0700 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j49G1i0F14716625; Mon, 9 May 2005 11:01:44 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1DVAhT-0007UQ-00; Mon, 09 May 2005 11:01:43 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: PARTIAL TAKE 935317 - fix non-dmapi builds Message-Id: From: Christoph Hellwig Date: Mon, 09 May 2005 11:01:43 -0500 X-archive-position: 5164 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 462 Lines: 15 Date: Mon May 9 09:01:44 PDT 2005 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.6.x Inspected by: roehrich The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:192307a fs/xfs/linux-2.6/xfs_file.c - 1.123 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_file.c.diff?r1=text&tr1=1.123&r2=text&tr2=1.122&f=h - linvfs_mprotect exists only in dmapi builds From owner-linux-xfs@oss.sgi.com Mon May 9 09:58:08 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 May 2005 09:58:12 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.197]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j49Gw6Ov018017 for ; Mon, 9 May 2005 09:58:08 -0700 Received: by zproxy.gmail.com with SMTP id 16so4185798nzp for ; Mon, 09 May 2005 09:57:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=LVWZBK1Fy3KlxxGSMVqM8XsZBSHDERTMImtZkwI99MKeIdyg8AHxv7FSdHpBocyrEmV6/qO3/648B5f9DblJQH1C1XrMlWDnutQ+TpLGfMRBLijhUzf8dqXg3Zh8ogSn17N3h58sE4ggjfmiTYm5yM6sv52ozNSlaMRR8TGR678= Received: by 10.36.42.19 with SMTP id p19mr1182377nzp; Mon, 09 May 2005 09:57:43 -0700 (PDT) Received: by 10.36.34.19 with HTTP; Mon, 9 May 2005 09:57:43 -0700 (PDT) Message-ID: Date: Mon, 9 May 2005 09:57:43 -0700 From: Dan Lake Reply-To: Dan Lake To: linux-xfs@oss.sgi.com Subject: linux-2.4-xfs cvs problems? Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j49Gw9Ov018019 X-archive-position: 5165 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dplake@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 188 Lines: 8 Attempting to checkout linux-2.4-xfs aborts: cvs [checkout aborted]: Could not map memory to RCS archive /cvs/linux-2.4-xfs/fs/xfs/Makefile-linux-2.6,v: No such file or directory =danl From owner-linux-xfs@oss.sgi.com Mon May 9 13:10:23 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 May 2005 13:10:32 -0700 (PDT) Received: from BlueMonday.tradepage.co.za (smtp.wirelessza.co.za [196.15.251.88]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j49KAJOv028737 for ; Mon, 9 May 2005 13:10:22 -0700 Received: from picturenet.co.za (wbs-196-2-118-175.wbs.co.za [196.2.118.175]) by BlueMonday.tradepage.co.za (8.12.11/8.12.11) with ESMTP id j49KDfLF006775 for ; Mon, 9 May 2005 22:13:44 +0200 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by picturenet.co.za (Postfix) with ESMTP id 1186D21F7 for ; Mon, 9 May 2005 22:10:26 +0200 (SAST) From: Leon Vismer Reply-To: lvismer@picturenet.co.za To: linux-xfs@oss.sgi.com Subject: XFS on 2.4 Tib raid Date: Mon, 9 May 2005 22:10:25 +0200 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505092210.25667.lvismer@picturenet.co.za> X-archive-position: 5166 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lvismer@picturenet.co.za Precedence: bulk X-list: linux-xfs Content-Length: 1286 Lines: 36 Hi I am using an ATTO scsi card speaking to an Infortrend 2.4 Tib raid system. Some system config settings: Distro: debian sarge Kernel: 2.6.11 (kernel-image-2.6.11-1-686) XFS: xfsprogs (2.6.28-1) I created a filesystem using: mkfs.xfs -L iftraid -f /dev/sdc After copying about 300Mb onto the newly mounted filesystem I get the following errors, and the machine basically needs to be rebooted to recover properly: May 9 16:53:29 localhost kernel: [pdflush+0/48] pdflush+0x0/0x30 May 9 16:53:29 localhost kernel: [writeback_inodes+172/176] writeback_inodes+0xac/0xb0 May 9 16:53:29 localhost kernel: [wb_kupdate+150/272] wb_kupdate+0x96/0x110 May 9 16:53:29 localhost kernel: [__pdflush+164/368] __pdflush+0xa4/0x170 May 9 16:53:29 localhost kernel: [pdflush+38/48] pdflush+0x26/0x30 May 9 16:53:29 localhost kernel: [wb_kupdate+0/272] wb_kupdate+0x0/0x110 May 9 16:53:29 localhost kernel: [pdflush+0/48] pdflush+0x0/0x30 May 9 16:53:29 localhost kernel: [kthread+170/176] kthread+0xaa/0xb0 May 9 16:53:29 localhost kernel: [kthread+0/176] kthread+0x0/0xb0 May 9 16:53:29 localhost kernel: [kernel_thread_helper+5/24] kernel_thread_helper+0x5/0x18 How can I go about fixing this problem? Any help would be greatly appreciated. Many thanks Leon Vismer From owner-linux-xfs@oss.sgi.com Mon May 9 14:32:02 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 May 2005 14:32:15 -0700 (PDT) Received: from mail.linux-sxs.org (mail.linux-sxs.org [64.116.183.6]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j49LVsOv031966 for ; Mon, 9 May 2005 14:31:55 -0700 Received: from mail.linux-sxs.org (localhost [127.0.0.1]) by mail.linux-sxs.org (8.13.4/8.13.4/Debian-1) with ESMTP id j49KRaLC026810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 9 May 2005 15:27:43 -0500 Received: from localhost (netllama@localhost) by mail.linux-sxs.org (8.13.4/8.13.4/Submit) with ESMTP id j49KRZTG026807 for ; Mon, 9 May 2005 15:27:36 -0500 X-Authentication-Warning: mail.linux-sxs.org: netllama owned process doing -bs Date: Mon, 9 May 2005 15:27:35 -0500 (EST) From: Net Llama! To: linux-xfs@oss.sgi.com Subject: 8k stacks - where did they go? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: milter-sender/0.62.837 (localhost [127.0.0.1]); Mon, 09 May 2005 15:27:43 -0500 Received-SPF: pass (mail.linux-sxs.org: domain of netllama@linux-sxs.org designates 127.0.0.1 as permitted sender) receiver=mail.linux-sxs.org; client-ip=127.0.0.1; helo=mail.linux-sxs.org; envelope-from=netllama@linux-sxs.org; x-software=spfmilter 0.95 http://www.acme.com/software/spfmilter/ with libspf2; X-archive-position: 5167 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 469 Lines: 12 I'm about to build a 2.6.11.8 kernel on EM64T hardware, and i can't, for the life of me, find the 8K stacks option. Or more accurately, I can't find CONFIG_4KSTACKS to set it to N. Did this option get ripped out in favor of hardcoding 8k stacks by default, or am i just stupid today? -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org LlamaLand http://netllama.linux-sxs.org From owner-linux-xfs@oss.sgi.com Mon May 9 14:39:39 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 May 2005 14:39:45 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j49LddOv032522 for ; Mon, 9 May 2005 14:39:39 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j49NMaCN027452 for ; Mon, 9 May 2005 16:22:37 -0700 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j49LdF0F14731750; Mon, 9 May 2005 16:39:15 -0500 (CDT) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1DVFy7-0000lI-00; Mon, 09 May 2005 16:39:15 -0500 Date: Mon, 9 May 2005 16:39:14 -0500 From: Nathan Straz To: Net Llama! Cc: linux-xfs@oss.sgi.com Subject: Re: 8k stacks - where did they go? Message-ID: <20050509213914.GE26337@sgi.com> Mail-Followup-To: Net Llama! , linux-xfs@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-archive-position: 5168 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nstraz@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 648 Lines: 15 On Mon, May 09, 2005 at 03:27:35PM -0500, Net Llama! wrote: > I'm about to build a 2.6.11.8 kernel on EM64T hardware, and i can't, for > the life of me, find the 8K stacks option. Or more accurately, I can't > find CONFIG_4KSTACKS to set it to N. > > Did this option get ripped out in favor of hardcoding 8k stacks by > default, or am i just stupid today? Nope, that's just an i386 config option. It doesn't exist on x86_64. -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Mon May 9 14:57:41 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 May 2005 14:58:04 -0700 (PDT) Received: from mail.linux-sxs.org (mail.linux-sxs.org [64.116.183.6]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j49LvdOv000799 for ; Mon, 9 May 2005 14:57:40 -0700 Received: from mail.linux-sxs.org (localhost [127.0.0.1]) by mail.linux-sxs.org (8.13.4/8.13.4/Debian-1) with ESMTP id j49KrTqq027128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 9 May 2005 15:53:30 -0500 Received: from localhost (netllama@localhost) by mail.linux-sxs.org (8.13.4/8.13.4/Submit) with ESMTP id j49KrTJc027125; Mon, 9 May 2005 15:53:29 -0500 X-Authentication-Warning: mail.linux-sxs.org: netllama owned process doing -bs Date: Mon, 9 May 2005 15:53:29 -0500 (EST) From: Net Llama! To: Nathan Straz cc: linux-xfs@oss.sgi.com Subject: Re: 8k stacks - where did they go? In-Reply-To: <20050509213914.GE26337@sgi.com> Message-ID: References: <20050509213914.GE26337@sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: milter-sender/0.62.837 (localhost [127.0.0.1]); Mon, 09 May 2005 15:53:31 -0500 Received-SPF: pass (mail.linux-sxs.org: domain of netllama@linux-sxs.org designates 127.0.0.1 as permitted sender) receiver=mail.linux-sxs.org; client-ip=127.0.0.1; helo=mail.linux-sxs.org; envelope-from=netllama@linux-sxs.org; x-software=spfmilter 0.95 http://www.acme.com/software/spfmilter/ with libspf2; X-archive-position: 5169 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 704 Lines: 18 On Mon, 9 May 2005, Nathan Straz wrote: > On Mon, May 09, 2005 at 03:27:35PM -0500, Net Llama! wrote: > > I'm about to build a 2.6.11.8 kernel on EM64T hardware, and i can't, for > > the life of me, find the 8K stacks option. Or more accurately, I can't > > find CONFIG_4KSTACKS to set it to N. > > > > Did this option get ripped out in favor of hardcoding 8k stacks by > > default, or am i just stupid today? > > Nope, that's just an i386 config option. It doesn't exist on x86_64. So i get 8k by default on x86_64 ? -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org LlamaLand http://netllama.linux-sxs.org From owner-linux-xfs@oss.sgi.com Mon May 9 15:06:45 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 May 2005 15:06:48 -0700 (PDT) Received: from ylpvm12.prodigy.net (ylpvm12-ext.prodigy.net [207.115.57.43]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j49M6iOv001690 for ; Mon, 9 May 2005 15:06:44 -0700 Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by ylpvm12.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j49M6Heg006438 for ; Mon, 9 May 2005 18:06:17 -0400 X-ORBL: [67.124.119.21] Received: from taniwha.stupidest.org (adsl-67-124-119-21.dsl.snfc21.pacbell.net [67.124.119.21]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j49M6E9Z150240; Mon, 9 May 2005 18:06:18 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 79A25528F22; Mon, 9 May 2005 15:06:13 -0700 (PDT) Date: Mon, 9 May 2005 15:06:13 -0700 From: Chris Wedgwood To: Net Llama! Cc: Nathan Straz , linux-xfs@oss.sgi.com Subject: Re: 8k stacks - where did they go? Message-ID: <20050509220613.GA22371@taniwha.stupidest.org> References: <20050509213914.GE26337@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-archive-position: 5170 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 217 Lines: 7 On Mon, May 09, 2005 at 03:53:29PM -0500, Net Llama! wrote: > So i get 8k by default on x86_64 ? For now x86_64 uses 8K stacks (there has been talk of this changing to 4K stacks eventually in some distros though). From owner-linux-xfs@oss.sgi.com Mon May 9 15:17:10 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 May 2005 15:17:15 -0700 (PDT) Received: from mail.linux-sxs.org (mail.linux-sxs.org [64.116.183.6]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j49MH9Ov002417 for ; Mon, 9 May 2005 15:17:10 -0700 Received: from mail.linux-sxs.org (localhost [127.0.0.1]) by mail.linux-sxs.org (8.13.4/8.13.4/Debian-1) with ESMTP id j49LClQU027402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 9 May 2005 16:12:48 -0500 Received: from localhost (netllama@localhost) by mail.linux-sxs.org (8.13.4/8.13.4/Submit) with ESMTP id j49LCkD2027395; Mon, 9 May 2005 16:12:47 -0500 X-Authentication-Warning: mail.linux-sxs.org: netllama owned process doing -bs Date: Mon, 9 May 2005 16:12:46 -0500 (EST) From: Net Llama! To: Chris Wedgwood cc: Nathan Straz , linux-xfs@oss.sgi.com Subject: Re: 8k stacks - where did they go? In-Reply-To: <20050509220613.GA22371@taniwha.stupidest.org> Message-ID: References: <20050509213914.GE26337@sgi.com> <20050509220613.GA22371@taniwha.stupidest.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: milter-sender/0.62.837 (localhost [127.0.0.1]); Mon, 09 May 2005 16:12:48 -0500 Received-SPF: pass (mail.linux-sxs.org: domain of netllama@linux-sxs.org designates 127.0.0.1 as permitted sender) receiver=mail.linux-sxs.org; client-ip=127.0.0.1; helo=mail.linux-sxs.org; envelope-from=netllama@linux-sxs.org; x-software=spfmilter 0.95 http://www.acme.com/software/spfmilter/ with libspf2; X-archive-position: 5171 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 563 Lines: 18 On Mon, 9 May 2005, Chris Wedgwood wrote: > On Mon, May 09, 2005 at 03:53:29PM -0500, Net Llama! wrote: > > > So i get 8k by default on x86_64 ? > > For now x86_64 uses 8K stacks (there has been talk of this changing to > 4K stacks eventually in some distros though). OK, thanks. I don't suppose you (or anyone else) knows if the 2.6.9-5-smp-x86_64 kernel in RHEL4 is using 8k? -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org LlamaLand http://netllama.linux-sxs.org From owner-linux-xfs@oss.sgi.com Mon May 9 16:11:33 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 May 2005 16:11:36 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j49NBWOv005333 for ; Mon, 9 May 2005 16:11:32 -0700 Received: from mumble.melbourne.sgi.com (mumble.melbourne.sgi.com [134.14.55.227]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA21956; Tue, 10 May 2005 09:11:00 +1000 Received: from mumble.melbourne.sgi.com (localhost [127.0.0.1]) by mumble.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j49NAwXf087466; Tue, 10 May 2005 09:10:59 +1000 (EST) Received: (from dgc@localhost) by mumble.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j49NAttm087459; Tue, 10 May 2005 09:10:55 +1000 (EST) Date: Tue, 10 May 2005 09:10:55 +1000 From: Dave Chinner To: Leon Vismer Cc: linux-xfs@oss.sgi.com Subject: Re: XFS on 2.4 Tib raid Message-ID: <20050510091055.C86925@melbourne.sgi.com> References: <200505092210.25667.lvismer@picturenet.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200505092210.25667.lvismer@picturenet.co.za>; from lvismer@picturenet.co.za on Mon, May 09, 2005 at 10:10:25PM +0200 X-archive-position: 5172 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1674 Lines: 47 On Mon, May 09, 2005 at 10:10:25PM +0200, Leon Vismer wrote: > Hi > > I am using an ATTO scsi card speaking to an Infortrend 2.4 Tib raid system. > > Some system config settings: > Distro: debian sarge > Kernel: 2.6.11 (kernel-image-2.6.11-1-686) > XFS: xfsprogs (2.6.28-1) > > I created a filesystem using: > mkfs.xfs -L iftraid -f /dev/sdc > > After copying about 300Mb onto the newly mounted filesystem I get the What sort of data was being copied? > following errors, and the machine basically needs to be rebooted to recover > properly: > > May 9 16:53:29 localhost kernel: [pdflush+0/48] pdflush+0x0/0x30 > May 9 16:53:29 localhost kernel: [writeback_inodes+172/176] > writeback_inodes+0xac/0xb0 > May 9 16:53:29 localhost kernel: [wb_kupdate+150/272] wb_kupdate+0x96/0x110 > May 9 16:53:29 localhost kernel: [__pdflush+164/368] __pdflush+0xa4/0x170 > May 9 16:53:29 localhost kernel: [pdflush+38/48] pdflush+0x26/0x30 > May 9 16:53:29 localhost kernel: [wb_kupdate+0/272] wb_kupdate+0x0/0x110 > May 9 16:53:29 localhost kernel: [pdflush+0/48] pdflush+0x0/0x30 > May 9 16:53:29 localhost kernel: [kthread+170/176] kthread+0xaa/0xb0 > May 9 16:53:29 localhost kernel: [kthread+0/176] kthread+0x0/0xb0 > May 9 16:53:29 localhost kernel: [kernel_thread_helper+5/24] > kernel_thread_helper+0x5/0x18 What's the actual error? This is the stack trace that's part of the error message, but does not inidcate what the error was. Can you include the error messages that were emitted before the stack trace? BTW, were there I/O errors on the RAID device(s)? Cheers, Dave. -- Dave Chinner R&D Software Engineer SGI Australian Software Group From owner-linux-xfs@oss.sgi.com Mon May 9 16:19:31 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 May 2005 16:19:36 -0700 (PDT) Received: from ylpvm12.prodigy.net (ylpvm12-ext.prodigy.net [207.115.57.43]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j49NJUOv010282 for ; Mon, 9 May 2005 16:19:31 -0700 Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by ylpvm12.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j49NJ6eg022927 for ; Mon, 9 May 2005 19:19:06 -0400 X-ORBL: [67.124.119.21] Received: from taniwha.stupidest.org (adsl-67-124-119-21.dsl.snfc21.pacbell.net [67.124.119.21]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j49NJ49Z024272; Mon, 9 May 2005 19:19:05 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 92DFA528F22; Mon, 9 May 2005 16:19:04 -0700 (PDT) Date: Mon, 9 May 2005 16:19:04 -0700 From: Chris Wedgwood To: Net Llama! Cc: Nathan Straz , linux-xfs@oss.sgi.com Subject: Re: 8k stacks - where did they go? Message-ID: <20050509231904.GA23560@taniwha.stupidest.org> References: <20050509213914.GE26337@sgi.com> <20050509220613.GA22371@taniwha.stupidest.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-archive-position: 5173 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 367 Lines: 10 On Mon, May 09, 2005 at 04:12:46PM -0500, Net Llama! wrote: > I don't suppose you (or anyone else) knows if the 2.6.9-5-smp-x86_64 > kernel in RHEL4 is using 8k? AFAIK everyone is usong 8K stacks for x86-64 kernels right now. FWIW x86-64 seems like it probably uses *less* stack space than x86 (quite a bit in some cases) so I wouldn't worry too much at present. From owner-linux-xfs@oss.sgi.com Mon May 9 16:21:50 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 May 2005 16:21:53 -0700 (PDT) Received: from ylpvm12.prodigy.net (ylpvm12-ext.prodigy.net [207.115.57.43]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j49NLoOv010708 for ; Mon, 9 May 2005 16:21:50 -0700 Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by ylpvm12.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j49NLPee031466 for ; Mon, 9 May 2005 19:21:25 -0400 X-ORBL: [67.124.119.21] Received: from taniwha.stupidest.org (adsl-67-124-119-21.dsl.snfc21.pacbell.net [67.124.119.21]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j49NLQ9Z130168; Mon, 9 May 2005 19:21:26 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 711A4528F22; Mon, 9 May 2005 16:21:26 -0700 (PDT) Date: Mon, 9 May 2005 16:21:26 -0700 From: Chris Wedgwood To: Leon Vismer Cc: linux-xfs@oss.sgi.com Subject: Re: XFS on 2.4 Tib raid Message-ID: <20050509232126.GC23560@taniwha.stupidest.org> References: <200505092210.25667.lvismer@picturenet.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505092210.25667.lvismer@picturenet.co.za> X-archive-position: 5174 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 385 Lines: 11 On Mon, May 09, 2005 at 10:10:25PM +0200, Leon Vismer wrote: > I am using an ATTO scsi card speaking to an Infortrend 2.4 Tib raid > system. Does the combination of kernel, drivers and raid cards work reliably for volumes that large without wrapping? Some do not and when you write towards the end of large volumes you end up stomping on data in the middle/start of the volume :-( From owner-linux-xfs@oss.sgi.com Mon May 9 21:51:59 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 May 2005 21:52:05 -0700 (PDT) Received: from gwyn.kn-bremen.de (gwyn.kn-bremen.de [212.63.36.242]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4A4pnOv024479 for ; Mon, 9 May 2005 21:51:58 -0700 Received: from gwyn.kn-bremen.de (gwyn [127.0.0.1]) by gwyn.kn-bremen.de (8.12.9/8.12.9/Debian-5) with ESMTP id j4A4pGk8023300 for ; Tue, 10 May 2005 06:51:17 +0200 Received: (from uucp@localhost) by gwyn.kn-bremen.de (8.12.9/8.12.8/Debian-1) with UUCP id j4A4pGSg023298 for linux-xfs@oss.sgi.com; Tue, 10 May 2005 06:51:16 +0200 Received: (from ms@localhost) by lucien.oneiros.kn-bremen.de (8.9.3/8.9.3) id BAA09761 for linux-xfs@oss.sgi.com; Tue, 10 May 2005 01:20:14 +0200 X-Authentication-Warning: lucien.oneiros.kn-bremen.de: ms set sender to martin@oneiros.de using -f Date: Tue, 10 May 2005 01:20:14 +0200 From: Martin =?iso-8859-1?Q?Schr=F6der?= To: linux-xfs@oss.sgi.com Subject: Re: 8k stacks - where did they go? Message-ID: <20050509232014.GA7205@lucien.kn-bremen.de> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20050509213914.GE26337@sgi.com> <20050509220613.GA22371@taniwha.stupidest.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i X-archive-position: 5175 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: martin@oneiros.de Precedence: bulk X-list: linux-xfs Content-Length: 270 Lines: 11 On 2005-05-09 16:12:46 -0500, Net Llama! wrote: > I don't suppose you (or anyone else) knows if the 2.6.9-5-smp-x86_64 > kernel in RHEL4 is using 8k? Why don't you ask RH, who sold you this OS? Best regards Martin -- http://www.tm.oneiros.de From owner-linux-xfs@oss.sgi.com Tue May 10 01:14:31 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 May 2005 01:14:35 -0700 (PDT) Received: from ns2.nd.co.za (ns2.nd.co.za [196.2.147.80]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4A8ESOv004128 for ; Tue, 10 May 2005 01:14:30 -0700 Received: from net-152-111-124-210.mweb.co.za ([152.111.124.210] helo=server.picturenet.co.za) by ns2.nd.co.za with esmtp (Exim 4.43) id 1DVQ34-0000rA-7d; Tue, 10 May 2005 10:25:02 +0200 Received: (from nobody@localhost) by server.picturenet.co.za (8.8.8/8.6.9) id IAA07703; Tue, 10 May 2005 08:13:57 GMT From: lvismer@picturenet.co.za Received: by server.picturenet.co.za via recvmail id 7701; Tue, 10 May 2005 08:13:56 +0000 (GMT) Received: from leonv by picturenet.co.za with local (Exim 4.31) id 1DVPiZ-0000DO-E8; Tue, 10 May 2005 10:03:51 +0200 Received: from server.picturenet.co.za (server.picturenet.co.za [192.168.1.1]) by picturenet.co.za (IMP) with HTTP for ; Tue, 10 May 2005 10:03:51 +0200 Message-ID: <1115712231.42806ae75b4d1@picturenet.co.za> Date: Tue, 10 May 2005 10:03:51 +0200 To: dgc@sgi.com Cc: linux-xfs@oss.sgi.com Subject: Re: XFS on 2.4 Tib raid References: <200505092210.25667.lvismer@picturenet.co.za> <200505100656.20204.lvismer@picturenet.co.za> <200505101008.47081.naude@picturenet.co.za> In-Reply-To: <200505101008.47081.naude@picturenet.co.za> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.4 X-Originating-IP: 192.168.1.1 X-archive-position: 5176 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lvismer@picturenet.co.za Precedence: bulk X-list: linux-xfs Content-Length: 3079 Lines: 83 Hi Dave > > Hi > > > > I am using an ATTO scsi card speaking to an Infortrend 2.4 Tib raid > > system. > > > > Some system config settings: > > Distro: debian sarge > > Kernel: 2.6.11 (kernel-image-2.6.11-1-686) > > XFS: xfsprogs (2.6.28-1) > > > > I created a filesystem using: > > mkfs.xfs -L iftraid -f /dev/sdc > > > > After copying about 300Mb onto the newly mounted filesystem I get the > > What sort of data was being copied? > I am copying jpeg files 1-2mb in size. > What's the actual error? This is the stack trace that's part of the > error message, but does not inidcate what the error was. Can you > include the error messages that were emitted before the stack trace? > I include the full error from /var/log/messages. As one copies files it stops at some point and the following error loops and the machine needs to be rebooted. 0x0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Filesystem "sdc": XFS internal error xfs_alloc_read_agf at line 2195 of file fs/ xfs/xfs_alloc.c. Caller 0xd0b638ca [] xfs_alloc_read_agf+0x12d/0x1f0 [xfs] [] xfs_alloc_fix_freelist+0x47a/0x490 [xfs] [] xfs_alloc_fix_freelist+0x47a/0x490 [xfs] [] xfs_alloc_fix_freelist+0x47a/0x490 [xfs] [] handle_IRQ_event+0x30/0x70 [] scheduler_tick+0x133/0x290 [] timer_interrupt+0x4b/0x100 [] handle_IRQ_event+0x30/0x70 [] xfs_alloc_vextent+0x2cd/0x500 [xfs] [] smp_apic_timer_interrupt+0x2f/0x80 [] xfs_bmap_alloc+0xd08/0x1c60 [xfs] [] scheduler_tick+0x9e/0x290 [] xfs_bmbt_get_state+0x2f/0x40 [xfs] [] xfs_bmapi+0x5b8/0x1780 [xfs] [] xfs_bmbt_get_state+0x2f/0x40 [xfs] [] xfs_bmap_do_search_extents+0xfc/0x430 [xfs] [] acpi_copy_wakeup_routine+0x1b/0xa0 [] kmem_zone_zalloc+0x35/0x60 [xfs] [] xfs_log_reserve+0xbf/0xd0 [xfs] [] xfs_iomap_write_allocate+0x2ba/0x580 [xfs] [] __do_softirq+0x7b/0x90 [] do_IRQ+0x1e/0x30 [] xfs_iomap+0x3ff/0x560 [xfs] [] xfs_map_blocks+0x58/0x90 [xfs] [] xfs_page_state_convert+0x4d4/0x610 [xfs] [] handle_IRQ_event+0x30/0x70 [] __do_softirq+0x7b/0x90 [] linvfs_writepage+0x67/0x100 [xfs] [] pageout+0xb4/0x100 [] __remove_from_page_cache+0x24/0x50 [] shrink_list+0x1e3/0x3f0 [] shrink_cache+0x16c/0x300 [] drain_cpu_caches+0x45/0x50 [] shrink_slab+0x88/0x190 [] shrink_zone+0xba/0xf0 [] balance_pgdat+0x2b8/0x3b0 [] kswapd+0xe9/0x110 [] autoremove_wake_function+0x0/0x60 [] autoremove_wake_function+0x0/0x60 [] kswapd+0x0/0x110 [] kernel_thread_helper+0x5/0x18 > BTW, were there I/O errors on the RAID device(s)? > No io errors on the raid device Many thanks Leon Vismer ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From owner-linux-xfs@oss.sgi.com Tue May 10 03:27:18 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 May 2005 03:27:36 -0700 (PDT) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.6]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4AARGOv009093 for ; Tue, 10 May 2005 03:27:18 -0700 Received: from ngbaux (ngbaux.msd.bae.co.uk [141.245.68.234]) by smtp1.bae.co.uk (Switch-2.2.8/Switch-2.2.8) with ESMTP id j4AAQnJ00147 for ; Tue, 10 May 2005 11:26:50 +0100 (BST) Received: from glkas0106.GREENLNK.NET ([141.245.68.243]) by ngbaux.net.bae.co.uk (PMDF V5.2-33 #44998) with ESMTP id <0IG900CPPRM9YT@ngbaux.net.bae.co.uk> for linux-xfs@oss.sgi.com; Tue, 10 May 2005 11:25:21 +0100 (BST) Received: from amsms00001.Jupiterlnk.net ([10.15.188.199]) by glkas0106.GREENLNK.NET with InterScan Messaging Security Suite; Tue, 10 May 2005 11:27:16 +0100 Received: by amsmsg0003.greenlnk.NET with Internet Mail Service (5.5.2653.19) id ; Tue, 10 May 2005 11:29:50 +0100 Content-return: allowed Date: Tue, 10 May 2005 11:26:36 +0100 From: "Brandon, Nicholas" Subject: XFS options for writing streaming data (contiguous data) To: "'linux-xfs@oss.sgi.com'" Message-id: <8393EBB4684F9A4F8A6049813438456A05F23F9C@amsms01002.jupiterlnk.net> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain; charset="iso-8859-1" X-archive-position: 5177 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nicholas.brandon@baesystems.com Precedence: bulk X-list: linux-xfs Content-Length: 1661 Lines: 38 I'm new to XFS and researching the use of XFS as the filesystem for an application that writes sequential data streamed from gigabit Ethernet. This data is then read at the fastest possible throughput for further processing. After reviewing the mailing list archive, I am unsure of what options (both in the app and at filesystem creation) should be used to ensure the greatest throughput (currently estimated at 40MB/s+). The application will be written in C++ on a Linux 2.6 system. Is there a way to increased the buffered i/o for a file to be larger than 64K (XFS_IOC_SETBIOSIZE in man xfs(5)) or would this have minimal effect on read/write performance? Is buffered i/o part of the delayed allocation that I have read from other sources? (http://www-106.ibm.com/developerworks/linux/library/l-fs9.html) If I know the size of the data before receiving it, should I use the XFS_IOC_RESVSP64 (man xfs(5)) in the application with unwritten=0 option set for the filesystem? Using this technique, would it be reasonable to assume the XFS overhead is low enough for the throughput to be near the hardware benchmarks (sustained read/write)? I appreciate your time answering all these questions. Regards Nick ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From owner-linux-xfs@oss.sgi.com Tue May 10 04:40:49 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 May 2005 04:41:12 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4ABenOv015924 for ; Tue, 10 May 2005 04:40:49 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4ADNnJN010940 for ; Tue, 10 May 2005 06:23:49 -0700 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4ABeM0F14764868; Tue, 10 May 2005 06:40:22 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1DVT66-0004CJ-00; Tue, 10 May 2005 06:40:22 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 908809 - rename various pagebuf symbols to xfsbuf Message-Id: From: Christoph Hellwig Date: Tue, 10 May 2005 06:40:22 -0500 X-archive-position: 5178 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 497 Lines: 15 This is actually from Nathan, but I have patches ontop of it that I want to push out. Date: Tue May 10 04:39:55 PDT 2005 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.6.x Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:192348a fs/xfs/linux-2.6/xfs_buf.c - 1.195 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.c.diff?r1=text&tr1=1.195&r2=text&tr2=1.194&f=h From owner-linux-xfs@oss.sgi.com Tue May 10 10:12:15 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 May 2005 10:12:22 -0700 (PDT) Received: from pimout4-ext.prodigy.net (pimout4-ext.prodigy.net [207.115.63.98]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4AHCFOv002278 for ; Tue, 10 May 2005 10:12:15 -0700 Received: from taniwha.stupidest.org (adsl-67-124-119-21.dsl.snfc21.pacbell.net [67.124.119.21]) by pimout4-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j4AHBlqi185532; Tue, 10 May 2005 13:11:47 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 2EC1D528F22; Tue, 10 May 2005 10:11:47 -0700 (PDT) Date: Tue, 10 May 2005 10:11:47 -0700 From: Chris Wedgwood To: "Brandon, Nicholas" Cc: "'linux-xfs@oss.sgi.com'" Subject: Re: XFS options for writing streaming data (contiguous data) Message-ID: <20050510171147.GA11009@taniwha.stupidest.org> References: <8393EBB4684F9A4F8A6049813438456A05F23F9C@amsms01002.jupiterlnk.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8393EBB4684F9A4F8A6049813438456A05F23F9C@amsms01002.jupiterlnk.net> X-archive-position: 5179 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 1934 Lines: 52 On Tue, May 10, 2005 at 11:26:36AM +0100, Brandon, Nicholas wrote: > I'm new to XFS and researching the use of XFS as the filesystem for > an application that writes sequential data streamed from gigabit > Ethernet. This data is then read at the fastest possible throughput > for further processing. How much data are we talking about and how long before it's read? (ie. can this fit in memory). > After reviewing the mailing list archive, I am unsure of what > options (both in the app and at filesystem creation) should be used > to ensure the greatest throughput (currently estimated at 40MB/s+). 40MB/s is pretty low. I don't think you'll need to do anything overly clever. > Is there a way to increased the buffered i/o for a file to be larger > than 64K (XFS_IOC_SETBIOSIZE in man xfs(5)) or would this have > minimal effect on read/write performance? Check the mount option "biosize". > Is buffered i/o part of the delayed allocation that I have read from > other sources? No. > (http://www-106.ibm.com/developerworks/linux/library/l-fs9.html) That article wasn't overly useful when it was written let alone now. > If I know the size of the data before receiving it, should I use the > XFS_IOC_RESVSP64 (man xfs(5)) in the application with unwritten=0 > option set for the filesystem? XFS_IOC_RESVSP64 probably won't hurt (sometimes it's *really* handy but it depends). unwritten=0 for the fs I doubt will make much difference (not to mention the fact it probably doesn't do what you think it does). > Using this technique, would it be reasonable to assume the XFS > overhead is low enough for the throughput to be near the hardware > benchmarks (sustained read/write)? 40MB/s? Easily I should think. For streaming data it's more of an issue of having some idea of your access patterns and having some control over how memory is used (ie. often it makes sense to use dio and control the buffering yourself). From owner-linux-xfs@oss.sgi.com Tue May 10 10:56:29 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 May 2005 10:56:34 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4AHuSOv005563 for ; Tue, 10 May 2005 10:56:28 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4AHu4xT021590 for ; Tue, 10 May 2005 12:56:04 -0500 Received: from chewtoy.americas.sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4AHu0R07808050; Tue, 10 May 2005 12:56:01 -0500 (CDT) Received: from chewtoy (localhost [127.0.0.1]) by chewtoy.americas.sgi.com (Postfix) with ESMTP id 629744FE8A; Tue, 10 May 2005 12:56:00 -0500 (CDT) To: Aurelien Degremont - Stagiaire Cc: linux-xfs@oss.sgi.com Subject: Re: vfs_altfsid & dm_fsid Date: Tue, 10 May 2005 12:56:00 -0500 From: Dean Roehrich Message-Id: <20050510175600.629744FE8A@chewtoy.americas.sgi.com> X-archive-position: 5180 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2773 Lines: 76 >From: Aurelien Degremont - Stagiaire >Dean Roehrich a écrit: >> If your filesystem of choice doesn't have an fsid, then you could just >> generate one that is valid while the filesystem is mounted and is not writte >n >> to the filesystem, or you could come up with something else. Whatever you >> choose for an fsid should fit into a 64-bit type. > > >> 1) The fsid should be a parameter to dm_send_mount_event() and >> dm_send_namesp_event() and dm_send_unmount_event(). >> The get_fsid op in struct filesystem_dmapi_operations should be >> dropped. > >Ok, so we need to modify : > xfs_dm_mount() > xfs_dm_send_namesp_event() > xfs_dm_send_unmount_event() > Well, more than that. I have some changes for this that I'll send in another email, if you're willing to look over this. >> 2) The dm_fsys_vector_t should be folded into struct >> filesystem_dmapi_operations. The new ops vector should be >> a parameter to dm_send_mount_event(). >> The part where today we copy the ops vector from >> fsys_function_vector_t to dm_fsys_vector_t seems cumbersome and >> just makes things hard to understand, so maybe >> that copy should be skipped and some of these datatypes could >> be removed. >> The get_fsys_vector op in struct filesystem_dmapi_operations should be >> dropped. > >Remove > dm_query_fsys_for_vector() > dm_fsys_vector() > >Move the fsys_vector pointer to dmapiops. >Add a bitmask that informs which functions id set when registering. > >Change all the dm_sys_vector calls in dmapi. > >Maybe the dm_vector_map should be replace by a list_head ? I'm sure now that we can throw away dmapi_register() and dmapi_unregister(), and we can send &filesystem_dmapi_operations as a parameter in the mount event. This assumes the fsid changes have been finished. Looking at filesystem_dmapi_operations in its current form, all of those vectors are valid only after dm_send_mount_event() has been called. We will have to change a few things with respect to ->inode_to_fh; this is used only by dm_ip_to_handle(), but all callers of dm_ip_to_handle() followup with a call to dm_find_fsreg_and_lock(). We have enough info in the fsreg so that we could search the dm_registers list by sb. So, all callers of dm_ip_to_handle() would be changed to call a new dm_find_fsreg_by_sb_and_lock() first and then dm_ip_to_handle() second. >> 3) It would be nice to keep in mind distributed filesystems and stackable >> filesystems; try to make it easier, not harder, to move in those >> directions. Unfortunately, I have no experience with the Linux >> view of stackable filesystems and I don't quite know how to approach >> that problem. > >Ok, I'm not specialist neither. I'll try... I think we're almost there. Dean From owner-linux-xfs@oss.sgi.com Tue May 10 11:52:43 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 May 2005 11:52:46 -0700 (PDT) Received: from slurp.thebarn.com (cattelan-host201.dsl.visi.com [208.42.117.201]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4AIqgOv008292 for ; Tue, 10 May 2005 11:52:42 -0700 Received: from rumela.com ([219.131.56.148]) by slurp.thebarn.com (8.13.4/8.13.1) with SMTP id j4AIpK0d031132; Tue, 10 May 2005 13:52:13 -0500 (CDT) (envelope-from mareenes@rumela.com) Message-ID: From: "dalton sutherland" To: "Earl Bissell" Subject: Check these wonderful lovvprices on rneds novv. Date: Tue, 10 May 2005 22:26:40 -0400 MIME-Version: 1.0 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1158 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 5181 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mareenes@rumela.com Precedence: bulk X-list: linux-xfs Content-Length: 38 Lines: 4 [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Tue May 10 15:45:38 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 May 2005 15:45:44 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4AMjbOv026562 for ; Tue, 10 May 2005 15:45:38 -0700 Received: from mumble.melbourne.sgi.com (mumble.melbourne.sgi.com [134.14.55.227]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA23839; Wed, 11 May 2005 08:44:57 +1000 Received: from mumble.melbourne.sgi.com (localhost [127.0.0.1]) by mumble.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j4AMiuXf091982; Wed, 11 May 2005 08:44:56 +1000 (EST) Received: (from dgc@localhost) by mumble.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j4AMiohE091955; Wed, 11 May 2005 08:44:50 +1000 (EST) Date: Wed, 11 May 2005 08:44:50 +1000 From: Dave Chinner To: lvismer@picturenet.co.za Cc: linux-xfs@oss.sgi.com Subject: Re: XFS on 2.4 Tib raid Message-ID: <20050511084450.A91712@melbourne.sgi.com> References: <200505092210.25667.lvismer@picturenet.co.za> <200505100656.20204.lvismer@picturenet.co.za> <200505101008.47081.naude@picturenet.co.za> <1115712231.42806ae75b4d1@picturenet.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1115712231.42806ae75b4d1@picturenet.co.za>; from lvismer@picturenet.co.za on Tue, May 10, 2005 at 10:03:51AM +0200 X-archive-position: 5182 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1949 Lines: 58 On Tue, May 10, 2005 at 10:03:51AM +0200, lvismer@picturenet.co.za wrote: > > > I am using an ATTO scsi card speaking to an Infortrend 2.4 Tib raid > > > system. > > > > > > I created a filesystem using: > > > mkfs.xfs -L iftraid -f /dev/sdc So you haven't created a partition table on the device at all? > > What's the actual error? This is the stack trace that's part of the > > error message, but does not inidcate what the error was. Can you > > include the error messages that were emitted before the stack trace? > > > I include the full error from /var/log/messages. As one copies > files it stops at some point and the following error loops and the > machine needs to be rebooted. > > 0x0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > Filesystem "sdc": XFS internal error xfs_alloc_read_agf at line 2195 of file fs/ > xfs/xfs_alloc.c. Caller 0xd0b638ca > [] xfs_alloc_read_agf+0x12d/0x1f0 [xfs] > [] xfs_alloc_fix_freelist+0x47a/0x490 [xfs] > [] xfs_alloc_vextent+0x2cd/0x500 [xfs] So we're trying to allocate an extent and the AGF read from disk is full of zeros. Can you do the following: - write a known pattern to the disk before making the filesystem (0xa5 is a good one) - make the filesystem - run xfs_check on the device before mounting to validate the filesystem was made properly - mount the filesystem - run your copy until it breaks - run xfs_check on the filesystem (if you needed to reboot to get here, you should mount and unmount the filesystem to replay the log first) - run xfs_repair on the filesystem if xfs_check finds errors And post the output of any errors that are found? If there really is a AGF full of zeros (or 0xa5!) in the filesystem, xfs_check will find it. BTW, did you build the kernel with CONFIG_LBD=y (i.e. support block devices larger than 2TiB)? Cheers, Dave. -- Dave Chinner R&D Software Engineer SGI Australian Software Group From owner-linux-xfs@oss.sgi.com Tue May 10 22:27:35 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 May 2005 22:27:40 -0700 (PDT) Received: from BlueMonday.tradepage.co.za (smtp.wirelessza.co.za [196.15.251.88]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4B5RWOv013465 for ; Tue, 10 May 2005 22:27:34 -0700 Received: from picturenet.co.za (wbs-196-2-112-122.wbs.co.za [196.2.112.122]) by BlueMonday.tradepage.co.za (8.12.11/8.12.11) with ESMTP id j4B5UuZp008173; Wed, 11 May 2005 07:30:57 +0200 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by picturenet.co.za (Postfix) with ESMTP id 6C3C121FB; Wed, 11 May 2005 07:27:34 +0200 (SAST) From: Leon Vismer Reply-To: lvismer@picturenet.co.za To: Dave Chinner , naude@mail.picturenet.co.za Subject: Re: XFS on 2.4 Tib raid Date: Wed, 11 May 2005 07:27:34 +0200 User-Agent: KMail/1.8 Cc: linux-xfs@oss.sgi.com References: <200505092210.25667.lvismer@picturenet.co.za> <1115712231.42806ae75b4d1@picturenet.co.za> <20050511084450.A91712@melbourne.sgi.com> In-Reply-To: <20050511084450.A91712@melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505110727.34199.lvismer@picturenet.co.za> X-archive-position: 5183 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lvismer@picturenet.co.za Precedence: bulk X-list: linux-xfs Content-Length: 2837 Lines: 79 Hi Dave On Wednesday 11 May 2005 00:44, Dave Chinner wrote: > On Tue, May 10, 2005 at 10:03:51AM +0200, lvismer@picturenet.co.za wrote: > > > > I am using an ATTO scsi card speaking to an Infortrend 2.4 Tib raid > > > > system. > > > > > > > > I created a filesystem using: > > > > mkfs.xfs -L iftraid -f /dev/sdc > > So you haven't created a partition table on the device at all? > No, however the device mounted 100% > > > What's the actual error? This is the stack trace that's part of the > > > error message, but does not inidcate what the error was. Can you > > > include the error messages that were emitted before the stack trace? > > > > I include the full error from /var/log/messages. As one copies > > files it stops at some point and the following error loops and the > > machine needs to be rebooted. > > > > 0x0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > Filesystem "sdc": XFS internal error xfs_alloc_read_agf at line 2195 of > > file fs/ xfs/xfs_alloc.c. Caller 0xd0b638ca > > [] xfs_alloc_read_agf+0x12d/0x1f0 [xfs] > > [] xfs_alloc_fix_freelist+0x47a/0x490 [xfs] > > [] xfs_alloc_vextent+0x2cd/0x500 [xfs] > > So we're trying to allocate an extent and the AGF read from disk > is full of zeros. > > Can you do the following: > > - write a known pattern to the disk before making the > filesystem (0xa5 is a good one) > The reason we did not originally create a partition is that the fdisk utils could not address the 2.4 Tib device. It returned a size of 200Mb or something similar. > - make the filesystem > - run xfs_check on the device before mounting to validate > the filesystem was made properly > - mount the filesystem > - run your copy until it breaks > - run xfs_check on the filesystem (if you needed to reboot > to get here, you should mount and unmount the filesystem > to replay the log first) > - run xfs_repair on the filesystem if xfs_check finds > errors > > And post the output of any errors that are found? > Dave, unfortunately we were under presure to get the device going as the clients current storage was not sufficient. We in the end created two partitions on the 2,4 Tib InforTrend (2048Gib and 234Gib). We create XFS on both sdc and sdd filesystems, mounted them and managed to copy 400Gig onto sdc without a single suspicious message. It would have been nice to use the full size. > If there really is a AGF full of zeros (or 0xa5!) in the filesystem, > xfs_check will find it. > > BTW, did you build the kernel with CONFIG_LBD=y (i.e. support block > devices larger than 2TiB)? > I am using the 2.6.11 kernel from Debian sid and according to the /boot/config-2.6.11-1-i386 file (the .config used to build the shipped kernel) CONFIG_LBD is set to Y. Many thanks for all the help -- Leon > Cheers, > > Dave. From owner-linux-xfs@oss.sgi.com Tue May 10 23:29:47 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 May 2005 23:29:50 -0700 (PDT) Received: from quail.cita.utoronto.ca (quail.cita.utoronto.ca [128.100.76.6]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4B6TkOv016128 for ; Tue, 10 May 2005 23:29:46 -0700 Received: from cita.utoronto.ca (lemming.cita.utoronto.ca [128.100.76.53]) by quail.cita.utoronto.ca (8.12.11/8.12.11) with ESMTP id j4B6T20Z024070; Wed, 11 May 2005 02:29:02 -0400 Received: from lemming.cita.utoronto.ca (localhost [127.0.0.1]) by cita.utoronto.ca (8.13.1/8.13.1) with ESMTP id j4B6T27e003602; Wed, 11 May 2005 02:29:02 -0400 Received: (from rjh@localhost) by lemming.cita.utoronto.ca (8.13.1/8.13.1/Submit) id j4B6T1Kt003601; Wed, 11 May 2005 02:29:01 -0400 Date: Wed, 11 May 2005 02:29:01 -0400 From: Robin Humble To: Leon Vismer Cc: Dave Chinner , naude@mail.picturenet.co.za, linux-xfs@oss.sgi.com Subject: Re: XFS on 2.4 Tib raid Message-ID: <20050511062901.GB3430@lemming.cita.utoronto.ca> References: <200505092210.25667.lvismer@picturenet.co.za> <1115712231.42806ae75b4d1@picturenet.co.za> <20050511084450.A91712@melbourne.sgi.com> <200505110727.34199.lvismer@picturenet.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505110727.34199.lvismer@picturenet.co.za> User-Agent: Mutt/1.4.1i X-archive-position: 5184 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rjh@cita.utoronto.ca Precedence: bulk X-list: linux-xfs Content-Length: 605 Lines: 20 On Wed, May 11, 2005 at 07:27:34AM +0200, Leon Vismer wrote: >The reason we did not originally create a partition is that the fdisk utils >could not address the 2.4 Tib device. It returned a size of 200Mb or >something similar. it's a limitation of the partition table format. use parted to create a EFI aka ia64 aka GPT partition table. eg. parted /dev/sda (parted) mklabel gpt (parted) mkpart primary 0 2384080 ... (parted) quit your kernel will need the 'advanced' partition table support too, but that's commonly switched on in distro kernels so shouldn't be a problem. cheers, robin From owner-linux-xfs@oss.sgi.com Wed May 11 02:11:07 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 May 2005 02:11:11 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4B9B7Ov026142 for ; Wed, 11 May 2005 02:11:07 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4B9AgxT030305 for ; Wed, 11 May 2005 04:10:42 -0500 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4B9Ae0F14822058; Wed, 11 May 2005 04:10:41 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1DVnEn-00010a-00; Wed, 11 May 2005 04:10:41 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 907752 - fix mkfs.xfs manpage: stripe width isn't returned by stat Message-Id: From: Christoph Hellwig Date: Wed, 11 May 2005 04:10:41 -0500 X-archive-position: 5185 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 414 Lines: 13 Date: Wed May 11 02:10:43 PDT 2005 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-cmds Inspected by: sandeen The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-cmds/master Modid: master:xfs-cmds:192427a xfsprogs/man/man8/mkfs.xfs.8 - 1.24 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/man/man8/mkfs.xfs.8.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h From owner-linux-xfs@oss.sgi.com Wed May 11 03:46:51 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 May 2005 03:46:56 -0700 (PDT) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.6]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4BAknOv029742 for ; Wed, 11 May 2005 03:46:50 -0700 Received: from ngbaux (ngbaux.msd.bae.co.uk [141.245.68.234]) by smtp1.bae.co.uk (Switch-2.2.8/Switch-2.2.8) with ESMTP id j4BAkMJ22288 for ; Wed, 11 May 2005 11:46:23 +0100 (BST) Received: from glkas0106.GREENLNK.NET ([141.245.68.243]) by ngbaux.net.bae.co.uk (PMDF V5.2-33 #44998) with ESMTP id <0IGB00DIGN7I00@ngbaux.net.bae.co.uk> for linux-xfs@oss.sgi.com; Wed, 11 May 2005 11:45:19 +0100 (BST) Received: from amsms00001.Jupiterlnk.net ([10.15.188.199]) by glkas0106.GREENLNK.NET with InterScan Messaging Security Suite; Wed, 11 May 2005 11:47:02 +0100 Received: by amsmsg0003.greenlnk.NET with Internet Mail Service (5.5.2653.19) id ; Wed, 11 May 2005 11:49:37 +0100 Date: Wed, 11 May 2005 11:46:22 +0100 From: "Brandon, Nicholas" Subject: RE: XFS options for writing streaming data (contiguous data) To: "'Chris Wedgwood'" Cc: "'linux-xfs@oss.sgi.com'" Message-id: <8393EBB4684F9A4F8A6049813438456A05F23FA2@amsms01002.jupiterlnk.net> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain; charset="iso-8859-1" X-archive-position: 5186 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nicholas.brandon@baesystems.com Precedence: bulk X-list: linux-xfs Content-Length: 2578 Lines: 69 Thanks Chris for the information, I've tried to answer your questions below (and add some more) > I'm new to XFS and researching the use of XFS as the filesystem for > an application that writes sequential data streamed from gigabit > Ethernet. This data is then read at the fastest possible throughput > for further processing. How much data are we talking about and how long before it's read? (ie. can this fit in memory). It will run between 1 - 5 hrs so will not fit in memory. At the moment the disk subsystem will likely be RAID5 or RAID0 > Is there a way to increased the buffered i/o for a file to be larger > than 64K (XFS_IOC_SETBIOSIZE in man xfs(5)) or would this have > minimal effect on read/write performance? Check the mount option "biosize". I did and I believe the max is 2^16 bytes. Would this be beneficial if this can be theoretically increased? > Is buffered i/o part of the delayed allocation that I have read from > other sources? No. Okay, Is there any valid documentation or user variables to control how delayed allocation works? > If I know the size of the data before receiving it, should I use the > XFS_IOC_RESVSP64 (man xfs(5)) in the application with unwritten=0 > option set for the filesystem? XFS_IOC_RESVSP64 probably won't hurt (sometimes it's *really* handy but it depends). unwritten=0 for the fs I doubt will make much difference (not to mention the fact it probably doesn't do what you think it does). I mentioned unwritten=0 because from the man pages it seems that it is not the default setting and when unwritten=1, the writing performance of XFS_IOC_RESVSP64 would drop rather than improve. > Using this technique, would it be reasonable to assume the XFS > overhead is low enough for the throughput to be near the hardware > benchmarks (sustained read/write)? 40MB/s? Easily I should think. For streaming data it's more of an issue of having some idea of your access patterns and having some control over how memory is used (ie. often it makes sense to use dio and control the buffering yourself). Do you have any links to using/writing apps for dio? Many Thanks ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From owner-linux-xfs@oss.sgi.com Wed May 11 04:57:12 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 May 2005 04:57:17 -0700 (PDT) Received: from smtp.wirelessza.co.za (smtp.wirelessza.co.za [196.15.251.88]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4BBv9Ov003504 for ; Wed, 11 May 2005 04:57:10 -0700 Received: from [196.2.112.122] (helo=picturenet.co.za) by smtp.wirelessza.co.za with esmtp (Exim 4.51) id 1DVptG-00084c-Qr; Wed, 11 May 2005 14:00:42 +0200 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by picturenet.co.za (Postfix) with ESMTP id 95E3521FE; Wed, 11 May 2005 13:57:13 +0200 (SAST) From: Leon Vismer Reply-To: lvismer@picturenet.co.za To: Dave Chinner , linux-xfs@oss.sgi.com, naude@mail.picturenet.co.za Subject: Re: XFS on 2.4 Tib raid Date: Wed, 11 May 2005 13:57:12 +0200 User-Agent: KMail/1.8 References: <200505092210.25667.lvismer@picturenet.co.za> <1115712231.42806ae75b4d1@picturenet.co.za> <20050511084450.A91712@melbourne.sgi.com> In-Reply-To: <20050511084450.A91712@melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505111357.13113.lvismer@picturenet.co.za> X-archive-position: 5187 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lvismer@picturenet.co.za Precedence: bulk X-list: linux-xfs Content-Length: 15430 Lines: 358 Hi Dave I did the following: # parted /dev/sdc parted> mklabel gpt parted> mkpart primary 0 2384080 parted> quit I saw the following in tail /var/log/messages May 11 13:37:40 mail kernel: program parted is using a deprecated SCSI ioctl, please convert it to SG_IO May 11 13:37:50 mail kernel: sym1:4:0:phase change 2-7 16@01b75f60 resid=10. # xfs_check /dev/sdc1 (gives the following) bad sb magic # 0xb0b25aab in ag 30 bad sb version # 0x9d8b in ag 30 bad agf magic # 0x9be1c556 in ag 30 bad agf version # 0xf2c55d8a in ag 30 bad agi magic # 0xe0467f8a in ag 30 bad agi version # 0xb4f92355 in ag 30 can't seek in filesystem at bb 426861406330510323 can't read agfl block for ag 2915391330 can't seek in filesystem at bb 426861438191846816 can't read btree block 2915391330/3982667062 can't seek in filesystem at bb 426861412315354400 can't read btree block 2915391330/748105510 can't seek in filesystem at bb 426861435013558208 can't read btree block 2915391330/3585380986 agf_freeblks 1761148316, counted 0 in ag 30 agf_longest 2463815067, counted 0 in ag 30 agi_count 2563941498, counted 0 in ag 30 agi_freecount 3663028107, counted 0 in ag 30 agi unlinked bucket 0 is 462714605 in ag 30 (inode=16568841965) agi unlinked bucket 1 is 1724631010 in ag 30 (inode=16757016546) agi unlinked bucket 2 is 4215237414 in ag 30 (inode=17100139302) agi unlinked bucket 3 is 3231072623 in ag 30 (inode=16115974511) agi unlinked bucket 4 is 2859018972 in ag 30 (inode=16817662684) agi unlinked bucket 5 is 2760201574 in ag 30 (inode=16718845286) agi unlinked bucket 6 is 3855234389 in ag 30 (inode=16740136277) agi unlinked bucket 7 is 3405867853 in ag 30 (inode=16290769741) agi unlinked bucket 8 is 1827066604 in ag 30 (inode=16859452140) agi unlinked bucket 9 is 3401839999 in ag 30 (inode=16286741887) agi unlinked bucket 10 is 1390827773 in ag 30 (inode=16423213309) agi unlinked bucket 11 is 1180067325 in ag 30 (inode=16212452861) agi unlinked bucket 12 is 3699362302 in ag 30 (inode=16584264190) agi unlinked bucket 13 is 3058210065 in ag 30 (inode=17016853777) agi unlinked bucket 14 is 1077317540 in ag 30 (inode=16109703076) agi unlinked bucket 15 is 4205651413 in ag 30 (inode=17090553301) agi unlinked bucket 16 is 2894855762 in ag 30 (inode=16853499474) agi unlinked bucket 17 is 3366759320 in ag 30 (inode=16251661208) agi unlinked bucket 18 is 3837338121 in ag 30 (inode=16722240009) agi unlinked bucket 19 is 246785257 in ag 30 (inode=16352912617) agi unlinked bucket 20 is 3164927206 in ag 30 (inode=17123570918) agi unlinked bucket 21 is 2584733074 in ag 30 (inode=16543376786) agi unlinked bucket 22 is 1073273742 in ag 30 (inode=17179401102) agi unlinked bucket 23 is 1078564132 in ag 30 (inode=16110949668) agi unlinked bucket 24 is 3071981037 in ag 30 (inode=17030624749) agi unlinked bucket 25 is 3155280692 in ag 30 (inode=17113924404) agi unlinked bucket 26 is 2661588059 in ag 30 (inode=16620231771) agi unlinked bucket 27 is 4261928854 in ag 30 (inode=17146830742) agi unlinked bucket 28 is 1478809154 in ag 30 (inode=16511194690) agi unlinked bucket 29 is 1530263199 in ag 30 (inode=16562648735) agi unlinked bucket 30 is 1965008675 in ag 30 (inode=16997394211) agi unlinked bucket 31 is 2129756125 in ag 30 (inode=17162141661) agi unlinked bucket 32 is 1790905946 in ag 30 (inode=16823291482) agi unlinked bucket 33 is 612504315 in ag 30 (inode=16718631675) agi unlinked bucket 34 is 2367087999 in ag 30 (inode=16325731711) agi unlinked bucket 35 is 2036780234 in ag 30 (inode=17069165770) agi unlinked bucket 36 is 3748229838 in ag 30 (inode=16633131726) agi unlinked bucket 37 is 656196899 in ag 30 (inode=16762324259) agi unlinked bucket 38 is 2597802675 in ag 30 (inode=16556446387) agi unlinked bucket 39 is 1727913098 in ag 30 (inode=16760298634) agi unlinked bucket 40 is 2900347851 in ag 30 (inode=16858991563) agi unlinked bucket 41 is 140805993 in ag 30 (inode=16246933353) agi unlinked bucket 42 is 2746809821 in ag 30 (inode=16705453533) agi unlinked bucket 43 is 3270611966 in ag 30 (inode=16155513854) agi unlinked bucket 44 is 120717675 in ag 30 (inode=16226845035) agi unlinked bucket 45 is 1402607980 in ag 30 (inode=16434993516) agi unlinked bucket 46 is 4177169118 in ag 30 (inode=17062071006) agi unlinked bucket 47 is 2608780005 in ag 30 (inode=16567423717) agi unlinked bucket 48 is 2696235053 in ag 30 (inode=16654878765) agi unlinked bucket 49 is 1494642567 in ag 30 (inode=16527028103) agi unlinked bucket 50 is 3971373067 in ag 30 (inode=16856274955) agi unlinked bucket 51 is 2234035046 in ag 30 (inode=16192678758) agi unlinked bucket 52 is 1210913975 in ag 30 (inode=16243299511) agi unlinked bucket 53 is 2388247726 in ag 30 (inode=16346891438) agi unlinked bucket 54 is 1707649758 in ag 30 (inode=16740035294) agi unlinked bucket 55 is 950720200 in ag 30 (inode=17056847560) agi unlinked bucket 56 is 2822954051 in ag 30 (inode=16781597763) agi unlinked bucket 57 is 3945987840 in ag 30 (inode=16830889728) agi unlinked bucket 58 is 2475018245 in ag 30 (inode=16433661957) agi unlinked bucket 59 is 66143967 in ag 30 (inode=16172271327) agi unlinked bucket 60 is 374620976 in ag 30 (inode=16480748336) agi unlinked bucket 61 is 1415867961 in ag 30 (inode=16448253497) agi unlinked bucket 62 is 1494057121 in ag 30 (inode=16526442657) agi unlinked bucket 63 is 1636941515 in ag 30 (inode=16669327051) bad sb magic # 0x9cb156fe in ag 31 bad sb version # 0x5c55 in ag 31 bad agf magic # 0x362aef53 in ag 31 bad agf version # 0x1573498a in ag 31 bad agi magic # 0xf27db7fb in ag 31 bad agi version # 0xb199b154 in ag 31 can't seek in filesystem at bb 425981987078782683 can't read agfl block for ag 2909385045 can't seek in filesystem at bb 425981993282677816 can't read btree block 2909385045/775486892 can't seek in filesystem at bb 425981998602996096 can't read btree block 2909385045/1440526677 can't seek in filesystem at bb 425981999647932048 can't read btree block 2909385045/1571143671 agf_freeblks 2326620443, counted 0 in ag 31 agf_longest 360132570, counted 0 in ag 31 agi_count 2334420026, counted 0 in ag 31 agi_freecount 3060805593, counted 0 in ag 31 agi unlinked bucket 0 is 83776965 in ag 31 (inode=16726775237) agi unlinked bucket 1 is 1836045795 in ag 31 (inode=16868431331) agi unlinked bucket 2 is 4267464407 in ag 31 (inode=17152366295) agi unlinked bucket 3 is 2103323737 in ag 31 (inode=17135709273) agi unlinked bucket 4 is 1525630295 in ag 31 (inode=17094886743) agi unlinked bucket 5 is 364345899 in ag 31 (inode=17007344171) agi unlinked bucket 6 is 2333571627 in ag 31 (inode=16829086251) agi unlinked bucket 7 is 2326657722 in ag 31 (inode=16822172346) agi unlinked bucket 8 is 3849629434 in ag 31 (inode=16734531322) agi unlinked bucket 9 is 3135458031 in ag 31 (inode=17094101743) agi unlinked bucket 10 is 2865027426 in ag 31 (inode=16823671138) agi unlinked bucket 11 is 2941998428 in ag 31 (inode=16900642140) agi unlinked bucket 12 is 1432868311 in ag 31 (inode=17002124759) agi unlinked bucket 13 is 358479221 in ag 31 (inode=17001477493) agi unlinked bucket 14 is 3311269231 in ag 31 (inode=16733042031) agi unlinked bucket 15 is 4071799381 in ag 31 (inode=16956701269) agi unlinked bucket 16 is 3209953024 in ag 31 (inode=17168596736) agi unlinked bucket 17 is 723146157 in ag 31 (inode=16829273517) agi unlinked bucket 18 is 1727987890 in ag 31 (inode=16760373426) agi unlinked bucket 19 is 3637689322 in ag 31 (inode=17059462122) agi unlinked bucket 20 is 4076798006 in ag 31 (inode=16961699894) agi unlinked bucket 21 is 883654319 in ag 31 (inode=16989781679) agi unlinked bucket 22 is 775203674 in ag 31 (inode=16881331034) agi unlinked bucket 23 is 427779866 in ag 31 (inode=17070778138) agi unlinked bucket 24 is 1438602860 in ag 31 (inode=17007859308) agi unlinked bucket 25 is 1773590197 in ag 31 (inode=16805975733) agi unlinked bucket 26 is 2762837293 in ag 31 (inode=16721481005) agi unlinked bucket 27 is 2935663775 in ag 31 (inode=16894307487) agi unlinked bucket 28 is 3415029177 in ag 31 (inode=16836801977) agi unlinked bucket 29 is 1636925287 in ag 31 (inode=16669310823) agi unlinked bucket 30 is 441938335 in ag 31 (inode=17084936607) agi unlinked bucket 31 is 4239157515 in ag 31 (inode=17124059403) agi unlinked bucket 32 is 1499987712 in ag 31 (inode=17069244160) agi unlinked bucket 33 is 723146186 in ag 31 (inode=16829273546) agi unlinked bucket 34 is 3539927189 in ag 31 (inode=16961699989) agi unlinked bucket 35 is 2519393938 in ag 31 (inode=17014908562) agi unlinked bucket 36 is 1442524042 in ag 31 (inode=17011780490) agi unlinked bucket 37 is 3151402431 in ag 31 (inode=17110046143) agi unlinked bucket 38 is 1729452322 in ag 31 (inode=16761837858) agi unlinked bucket 39 is 2894841416 in ag 31 (inode=16853485128) agi unlinked bucket 40 is 4185894072 in ag 31 (inode=17070795960) agi unlinked bucket 41 is 2857988512 in ag 31 (inode=16816632224) agi unlinked bucket 42 is 3925303262 in ag 31 (inode=16810205150) agi unlinked bucket 43 is 1538259740 in ag 31 (inode=17107516188) agi unlinked bucket 44 is 1525231515 in ag 31 (inode=17094487963) agi unlinked bucket 45 is 3384200701 in ag 31 (inode=16805973501) agi unlinked bucket 46 is 3410567162 in ag 31 (inode=16832339962) agi unlinked bucket 47 is 3098354139 in ag 31 (inode=17056997851) agi unlinked bucket 48 is 3413808191 in ag 31 (inode=16835580991) agi unlinked bucket 49 is 4013806751 in ag 31 (inode=16898708639) agi unlinked bucket 50 is 3971107991 in ag 31 (inode=16856009879) agi unlinked bucket 51 is 742286517 in ag 31 (inode=16848413877) agi unlinked bucket 52 is 4214010495 in ag 31 (inode=17098912383) agi unlinked bucket 53 is 2911549813 in ag 31 (inode=16870193525) agi unlinked bucket 54 is 1835982843 in ag 31 (inode=16868368379) agi unlinked bucket 55 is 3950794005 in ag 31 (inode=16835695893) agi unlinked bucket 56 is 4264191327 in ag 31 (inode=17149093215) agi unlinked bucket 57 is 2317233546 in ag 31 (inode=16812748170) agi unlinked bucket 58 is 2720922833 in ag 31 (inode=16679566545) agi unlinked bucket 59 is 1832384401 in ag 31 (inode=16864769937) agi unlinked bucket 60 is 3802764410 in ag 31 (inode=16687666298) agi unlinked bucket 61 is 2510520014 in ag 31 (inode=17006034638) agi unlinked bucket 62 is 716535181 in ag 31 (inode=16822662541) agi unlinked bucket 63 is 1066866403 in ag 31 (inode=17172993763) After seeing all of this I ran: # xfs_repair /dev/sdc1 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... bad on-disk superblock 30 - bad magic number primary/secondary superblock 30 conflict - AG superblock geometry info conflicts with filesystem geometry bad magic # 0x0 for agf 30 bad version # 0 for agf 30 bad sequence # 0 for agf 30 bad length 0 for agf 30, should be 18302063 bad magic # 0x0 for agi 30 bad version # 0 for agi 30 bad sequence # 0 for agi 30 bad length # 0 for agi 30, should be 18302063 reset bad sb for ag 30 reset bad agf for ag 30 reset bad agi for ag 30 bad agbno 0 for btbno root, agno 30 bad agbno 0 for btbcnt root, agno 30 bad agbno 0 for inobt root, agno 30 bad on-disk superblock 31 - bad magic number primary/secondary superblock 31 conflict - AG superblock geometry info conflicts with filesystem geometry bad magic # 0x0 for agf 31 bad version # 0 for agf 31 bad sequence # 0 for agf 31 bad length 0 for agf 31, should be 18302063 bad magic # 0x0 for agi 31 bad version # 0 for agi 31 bad sequence # 0 for agi 31 bad length # 0 for agi 31, should be 18302063 reset bad sb for ag 31 reset bad agf for ag 31 reset bad agi for ag 31 bad agbno 0 for btbno root, agno 31 bad agbno 0 for btbcnt root, agno 31 bad agbno 0 for inobt root, agno 31 - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... error following ag 30 unlinked list error following ag 31 unlinked list - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 - agno = 30 - agno = 31 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 - agno = 30 - agno = 31 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done The running xfs_check again gives the same as above Many thanks -- Leon > > I include the full error from /var/log/messages. As one copies > > files it stops at some point and the following error loops and the > > machine needs to be rebooted. > > > > 0x0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > Filesystem "sdc": XFS internal error xfs_alloc_read_agf at line 2195 of > > file fs/ xfs/xfs_alloc.c. Caller 0xd0b638ca > > [] xfs_alloc_read_agf+0x12d/0x1f0 [xfs] > > [] xfs_alloc_fix_freelist+0x47a/0x490 [xfs] > > [] xfs_alloc_vextent+0x2cd/0x500 [xfs] > > So we're trying to allocate an extent and the AGF read from disk > is full of zeros. > > Can you do the following: > > - write a known pattern to the disk before making the > filesystem (0xa5 is a good one) > - make the filesystem > - run xfs_check on the device before mounting to validate > the filesystem was made properly > - mount the filesystem > - run your copy until it breaks > - run xfs_check on the filesystem (if you needed to reboot > to get here, you should mount and unmount the filesystem > to replay the log first) > - run xfs_repair on the filesystem if xfs_check finds > errors > > And post the output of any errors that are found? > > If there really is a AGF full of zeros (or 0xa5!) in the filesystem, > xfs_check will find it. > > BTW, did you build the kernel with CONFIG_LBD=y (i.e. support block > devices larger than 2TiB)? > > Cheers, > > Dave. From owner-linux-xfs@oss.sgi.com Wed May 11 06:33:14 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 May 2005 06:33:20 -0700 (PDT) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4BDXDOv007015 for ; Wed, 11 May 2005 06:33:14 -0700 Received: from imp2-q.free.fr (imp2-q.free.fr [212.27.42.2]) by postfix3-2.free.fr (Postfix) with ESMTP id E0E43C167 for ; Wed, 11 May 2005 15:32:42 +0200 (CEST) Received: by imp2-q.free.fr (Postfix, from userid 33) id D00F96534F; Wed, 11 May 2005 15:32:42 +0200 (MEST) Received: from lns-vlq-30-str-82-254-32-140.adsl.proxad.net (lns-vlq-30-str-82-254-32-140.adsl.proxad.net [82.254.32.140]) by imp2-q.free.fr (IMP) with HTTP for ; Wed, 11 May 2005 15:32:42 +0200 Message-ID: <1115818362.4282097ab98b9@imp2-q.free.fr> Date: Wed, 11 May 2005 15:32:42 +0200 From: "jdf [zionarea.org]" To: linux-xfs@oss.sgi.com Subject: cannot mount a partition (error 990) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.5 X-Originating-IP: 82.254.32.140 X-archive-position: 5189 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: zionarea@free.fr Precedence: bulk X-list: linux-xfs Content-Length: 609 Lines: 27 Hi, I'm very annoyed. After a crash, my working partition (containing things about years) cannot be remounted anymore. fsck does nothing at all. Error is, according to dmesg: XFS mounting filesystem hdxy XFS: log has mismatched uuid - can't recover XFS: failed to find log head XFS: log mount/recovery failed: error 990 XFS: log mount failed I tried xfs_repair -n /dev/hdxy the result is: xfs_repair: can't determine device size What should I do in order not to loose all my data ? I really hope there's a solution even if I got older data. Unfortunately, I didn't backup anything. Please help me ! From owner-linux-xfs@oss.sgi.com Wed May 11 07:47:20 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 May 2005 07:47:37 -0700 (PDT) Received: from dmzraw2.extranet.tce.com (dmzraw2.extranet.tce.com [157.254.234.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4BElJOv009746 for ; Wed, 11 May 2005 07:47:19 -0700 Received: from smtprelay.indy.tce.com (ismtprelay.indy.tce.com [157.254.96.114]) by dmzraw2.extranet.tce.com (8.12.5/8.12.5) with ESMTP id j4BEkseB029947 for ; Wed, 11 May 2005 14:46:54 GMT Received: from boulsmailbh02.eu.thmulti.com (localhost [127.0.0.1]) by smtprelay.indy.tce.com (8.9.3/8.9.1) with ESMTP id OAA26583 for ; Wed, 11 May 2005 14:46:52 GMT Received: from wdtssmail01.eu.thmulti.com ([141.11.216.71]) by boulsmailbh02.eu.thmulti.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 11 May 2005 16:46:34 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: Every new file goes into a new ag Date: Wed, 11 May 2005 16:46:33 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Every new file goes into a new ag Thread-Index: AcVWODmDQvoNCIe4T0y/OrhOzLCmAQ== From: "Bub Thomas" To: Cc: "Braehler Uwe" , "Lindenkreuz Morris" , "Waldschmidt Stefan" X-OriginalArrivalTime: 11 May 2005 14:46:34.0759 (UTC) FILETIME=[3A621170:01C55638] Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 5190 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: thomas.bub@thomson.net Precedence: bulk X-list: linux-xfs Content-Length: 1029 Lines: 32 Hi there, I just got XFS running under RedHat EL 3.0. Since I need high bandwidth for media playout, where in our case each and every frame of a film image sequence is a new file, I need file sequences being physically close to each other. I'm struggling with the fact that consecutive files on a new filesystem don't get consecutive inode numbers. It seems that every new file ends up in a new ag. Thus the read performance for consecutive files is very poor I tried it with two different kernels which are 2.4.21-27.0.2.EL.sgi9.i386 and 2.4.21-15.0.4.EL.sgi3.i38. with both the effect is the same. My filesystem is located on a JBOD array on 14 FC-2 disks with less then 2 TByte and the kernel config CONFIG_LBD not set. The volume on the JBOD I use is made with LVM. Any help welcome. Thomas Bub _____________________________________ Thomas Bub Thomson grass valley Brunnenweg 9 D-64331 Weiterstadt Phone: +49-(0)-6150-104-147 Fax: +49-(0)-6150-104-656 E-Mail: Thomas.Bub@Thomson.net [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Wed May 11 08:16:30 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 May 2005 08:16:35 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4BFGUOv011669 for ; Wed, 11 May 2005 08:16:30 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4BGxeuE021370 for ; Wed, 11 May 2005 09:59:40 -0700 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4BFF30F14838362; Wed, 11 May 2005 10:15:04 -0500 (CDT) Message-ID: <42822177.3010607@sgi.com> Date: Wed, 11 May 2005 10:15:03 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bub Thomas CC: linux-xfs@oss.sgi.com, Braehler Uwe , Lindenkreuz Morris , Waldschmidt Stefan Subject: Re: Every new file goes into a new ag References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5191 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1725 Lines: 38 If you have a "rotorstep" systune in your xfs codebase you might play with that; otherwise try making the size of your inode bigger (at mkfs time) so that you don't get into inode32 mode. (or, if you're on a 64-bit machine, mount with the "inode64" option to make 64-bit inodes). for large filesystems, xfs must ensure that inode numbers don't go over 32 bits. To do that, inodes are allocated in the lower part of the fileysstem, and files are allocated round-robin through the AGs. rotorstep changes that round-robin behavior to switch to a new AG every (X) new files, instead of every (1) new file. If you can get out of inode32 mode by either mounting with 64-bit inodes on a 64-bit machine, or making the inode size larger (affects the inode numbering scheme) then files created in a single directory will generally be allocated in the same AG. -Eric Bub Thomas wrote: > Hi there, > I just got XFS running under RedHat EL 3.0. > Since I need high bandwidth for media playout, where in our case each > and every frame of a film image sequence is a new file, I need file > sequences being physically close to each other. > I'm struggling with the fact that consecutive files on a new filesystem > don't get consecutive inode numbers. It seems that every new file ends > up in a new ag. > Thus the read performance for consecutive files is very poor > I tried it with two different kernels which are > 2.4.21-27.0.2.EL.sgi9.i386 and 2.4.21-15.0.4.EL.sgi3.i38. with both the > effect is the same. > My filesystem is located on a JBOD array on 14 FC-2 disks with less then > 2 TByte and the kernel config CONFIG_LBD not set. > The volume on the JBOD I use is made with LVM. > Any help welcome. > Thomas Bub From owner-linux-xfs@oss.sgi.com Wed May 11 08:18:43 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 May 2005 08:18:49 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4BFIhOv012159 for ; Wed, 11 May 2005 08:18:43 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4BH1rR4022012 for ; Wed, 11 May 2005 10:01:53 -0700 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4BFHG0F14836924; Wed, 11 May 2005 10:17:16 -0500 (CDT) Message-ID: <428221FC.8050203@sgi.com> Date: Wed, 11 May 2005 10:17:16 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: lvismer@picturenet.co.za CC: linux-xfs@oss.sgi.com Subject: Re: XFS on 2.4 Tib raid References: <200505092210.25667.lvismer@picturenet.co.za> In-Reply-To: <200505092210.25667.lvismer@picturenet.co.za> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5192 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 291 Lines: 14 Leon Vismer wrote: > Hi > > I am using an ATTO scsi card speaking to an Infortrend 2.4 Tib raid system. > > Some system config settings: > Distro: debian sarge > Kernel: 2.6.11 (kernel-image-2.6.11-1-686) > XFS: xfsprogs (2.6.28-1) Just to be sure, have you enabled CONFIG_LBD? -Eric From owner-linux-xfs@oss.sgi.com Wed May 11 08:42:33 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 May 2005 08:42:52 -0700 (PDT) Received: from dmzraw2.extranet.tce.com (dmzraw2.extranet.tce.com [157.254.234.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4BFgWOv017245 for ; Wed, 11 May 2005 08:42:33 -0700 Received: from smtprelay.indy.tce.com (ismtprelay.indy.tce.com [157.254.96.114]) by dmzraw2.extranet.tce.com (8.12.5/8.12.5) with ESMTP id j4BFg7eB017471; Wed, 11 May 2005 15:42:07 GMT Received: from boulsmailbh02.eu.thmulti.com (localhost [127.0.0.1]) by smtprelay.indy.tce.com (8.9.3/8.9.1) with ESMTP id PAA06639; Wed, 11 May 2005 15:42:06 GMT Received: from wdtssmail01.eu.thmulti.com ([141.11.216.71]) by boulsmailbh02.eu.thmulti.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 11 May 2005 17:42:05 +0200 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: Every new file goes into a new ag Date: Wed, 11 May 2005 17:41:54 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Every new file goes into a new ag Thread-Index: AcVWPJ/5GEKz0lxPQmipwhrYpYY0vwAAk2eQ From: "Bub Thomas" To: "Eric Sandeen" Cc: , "Braehler Uwe" , "Lindenkreuz Morris" , "Waldschmidt Stefan" X-OriginalArrivalTime: 11 May 2005 15:42:05.0200 (UTC) FILETIME=[FB7B0900:01C5563F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j4BFgXOv017247 X-archive-position: 5193 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: thomas.bub@thomson.net Precedence: bulk X-list: linux-xfs Content-Length: 2306 Lines: 60 Eric, I can't find any rotorstep within my xfs kernel codebase. Any idea how I can get this in? I'm running on a 32 bit machine that's why I can't use idnode64 right? My machine currently shows me isize=256. Am I right that mkfs -t xfs -i size=512 would double the inode size? I'll give this a try tomorrow then. Thanks Thomas -----Original Message----- From: Eric Sandeen [mailto:sandeen@sgi.com] Sent: Wednesday, May 11, 2005 5:15 PM To: Bub Thomas Cc: linux-xfs@oss.sgi.com; Braehler Uwe; Lindenkreuz Morris; Waldschmidt Stefan Subject: Re: Every new file goes into a new ag If you have a "rotorstep" systune in your xfs codebase you might play with that; otherwise try making the size of your inode bigger (at mkfs time) so that you don't get into inode32 mode. (or, if you're on a 64-bit machine, mount with the "inode64" option to make 64-bit inodes). for large filesystems, xfs must ensure that inode numbers don't go over 32 bits. To do that, inodes are allocated in the lower part of the fileysstem, and files are allocated round-robin through the AGs. rotorstep changes that round-robin behavior to switch to a new AG every (X) new files, instead of every (1) new file. If you can get out of inode32 mode by either mounting with 64-bit inodes on a 64-bit machine, or making the inode size larger (affects the inode numbering scheme) then files created in a single directory will generally be allocated in the same AG. -Eric Bub Thomas wrote: > Hi there, > I just got XFS running under RedHat EL 3.0. > Since I need high bandwidth for media playout, where in our case each > and every frame of a film image sequence is a new file, I need file > sequences being physically close to each other. > I'm struggling with the fact that consecutive files on a new filesystem > don't get consecutive inode numbers. It seems that every new file ends > up in a new ag. > Thus the read performance for consecutive files is very poor > I tried it with two different kernels which are > 2.4.21-27.0.2.EL.sgi9.i386 and 2.4.21-15.0.4.EL.sgi3.i38. with both the > effect is the same. > My filesystem is located on a JBOD array on 14 FC-2 disks with less then > 2 TByte and the kernel config CONFIG_LBD not set. > The volume on the JBOD I use is made with LVM. > Any help welcome. > Thomas Bub From owner-linux-xfs@oss.sgi.com Wed May 11 09:20:51 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 May 2005 09:21:06 -0700 (PDT) Received: from cirse.extra.cea.fr (cirse.extra.cea.fr [132.166.172.102]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4BGKmOv018965 for ; Wed, 11 May 2005 09:20:50 -0700 Received: from argiope.saclay.cea.fr (argiope.saclay.cea.fr [132.166.192.108]) by cirse.extra.cea.fr (8.12.10/8.12.10/CEAnet-Internet.4.0) with ESMTP id j4BGKMAN025085 for ; Wed, 11 May 2005 18:20:22 +0200 (MEST) Received: from pisaure.intra.cea.fr (unverified) by argiope.saclay.cea.fr (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Wed, 11 May 2005 18:20:21 +0200 Received: from nenuphar.saclay.cea.fr (nenuphar.saclay.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.12.11/8.12.11) with ESMTP id j4BGITFr003133; Wed, 11 May 2005 18:18:29 +0200 (envelope-from degremont@ocre.cea.fr) Received: from ocre.cea.fr ([132.165.65.70]) by nenuphar.saclay.cea.fr (8.12.10/8.12.10/CEAnet-internes.4.0) with ESMTP id j4BGKIZa002384; Wed, 11 May 2005 18:20:18 +0200 (MEST) Message-ID: <428230C2.5050406@ocre.cea.fr> Date: Wed, 11 May 2005 18:20:18 +0200 From: Aurelien Degremont - Stagiaire User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com, Dean Roehrich Subject: [DMAPI] code error in dm_ip_to_handle() Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 5194 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: degremont@ocre.cea.fr Precedence: bulk X-list: linux-xfs Content-Length: 2226 Lines: 66 Hello, I'm still working on DMAPI code and I found a problem in dm_ip_to_handle() function. In fact, the problem is not specific to this function, I just found it here. To sum up, I found, in the XFS+DMAPI code, along all the different calls, you successively cast some structures and recopy data without verifying their content. With XFS, all is ok because 2 errors fix each others, but, when i try adding dmapi support to ext3, the problem appears. In order to create a dmapi handle, you must call dm_ip_to_handle(). This function will fill a dm_handle_t structure. The data recopied came from a dm_fsfid structure which do not have the same fields. ex: memcpy( &[DM_HANDLE_T], &[DM_FSID_T], ...) This copy the content of the len field without errors. **But the first byte of the fid_data buffer will be recopied in the padding field (dm_fid_pad) of the dm_fid structure !** (which is not what is expected) When DMAPI will try to extract the inode number, it will be wrong ! This code works correctly with XFS because XFS uses the same kind of structure as DMAPI, and so, when the datas are copied, the padding is ok. XFS will copied the data from : xfs_fid2_t --> fid_t -//pad error//-> dm_fsfid_t -//pad error//-> dm_fid_t Their 2 errors with byte alignement when data are cast and copied, but the first is the opposite of the second, so the data are correct at the end. This is not true when you correctly fill the dm_fsfid_t structure :) ________________________________________________________ #define MAXDMFSFIDSZ 46 typedef struct dm_fsfid { __u16 fid_len; /* length of data in bytes */ unsigned char fid_data[MAXDMFSFIDSZ]; /* data (fid_len worth) */ } dm_fsfid_t; struct dm_fid { __u16 dm_fid_len; /* length of remainder */ __u16 dm_fid_pad; __u32 dm_fid_gen; /* generation number */ __u64 dm_fid_ino; /* 64 bits inode number */ }; typedef struct dm_fid dm_fid_t; struct dm_handle { union { __s64 align; /* force alignment of ha_fid */ dm_fsid_t _ha_fsid; /* unique file system identifier */ } ha_u; dm_fid_t ha_fid; /* file system specific file ID */ }; typedef struct dm_handle dm_handle_t; ________________________________________________________ Aurélien From owner-linux-xfs@oss.sgi.com Wed May 11 09:38:58 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 May 2005 09:39:01 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4BGcvOv020267 for ; Wed, 11 May 2005 09:38:58 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4BGcWxT005486 for ; Wed, 11 May 2005 11:38:32 -0500 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4BGcVR07874552; Wed, 11 May 2005 11:38:31 -0500 (CDT) Message-ID: <42823507.8060406@sgi.com> Date: Wed, 11 May 2005 11:38:31 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bub Thomas CC: linux-xfs@oss.sgi.com, Braehler Uwe , Lindenkreuz Morris , Waldschmidt Stefan Subject: Re: Every new file goes into a new ag References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5195 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 578 Lines: 21 Bub Thomas wrote: > Eric, > I can't find any rotorstep within my xfs kernel codebase. Any idea how I > can get this in? Depends on where you got your xfs code, I guess - I think it should be in cvs at least. > I'm running on a 32 bit machine that's why I can't use idnode64 right? > My machine currently shows me isize=256. > Am I right that mkfs -t xfs -i size=512 would double the inode size? That's right - doubling the size of the inode will double the size of the fs that can keep inodes under 32 bits. -Eric > I'll give this a try tomorrow then. > Thanks > Thomas From owner-linux-xfs@oss.sgi.com Wed May 11 13:15:26 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 May 2005 13:15:32 -0700 (PDT) Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4BKFPOv000620 for ; Wed, 11 May 2005 13:15:26 -0700 Received: from imp1-q.free.fr (imp1-q.free.fr [212.27.42.1]) by postfix4-2.free.fr (Postfix) with ESMTP id B46B4319294 for ; Wed, 11 May 2005 22:14:58 +0200 (CEST) Received: by imp1-q.free.fr (Postfix, from userid 33) id DA7573B5B7; Wed, 11 May 2005 22:05:49 +0200 (MEST) Received: from lns-vlq-30-str-82-254-32-140.adsl.proxad.net (lns-vlq-30-str-82-254-32-140.adsl.proxad.net [82.254.32.140]) by imp1-q.free.fr (IMP) with HTTP for ; Wed, 11 May 2005 22:05:49 +0200 Message-ID: <1115841949.4282659dbbf38@imp1-q.free.fr> Date: Wed, 11 May 2005 22:05:49 +0200 From: "jdf [zionarea.org]" To: linux-xfs@oss.sgi.com Subject: Re: cannot mount a partition (error 990) References: <1115818362.4282097ab98b9@imp2-q.free.fr> In-Reply-To: <1115818362.4282097ab98b9@imp2-q.free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.5 X-Originating-IP: 82.254.32.140 X-archive-position: 5196 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: zionarea@free.fr Precedence: bulk X-list: linux-xfs Content-Length: 824 Lines: 37 I went more deeply to the list archive and found a good solving solution to my problem. It's now working well again. Selon "jdf [zionarea.org]" : > > Hi, > > I'm very annoyed. After a crash, my working partition (containing > things about years) cannot be remounted anymore. > fsck does nothing at all. > > Error is, according to dmesg: > > XFS mounting filesystem hdxy > XFS: log has mismatched uuid - can't recover > XFS: failed to find log head > XFS: log mount/recovery failed: error 990 > XFS: log mount failed > > I tried xfs_repair -n /dev/hdxy > > the result is: > > xfs_repair: can't determine device size > > What should I do in order not to loose all my data ? I really hope > there's a solution even if I got older data. Unfortunately, I didn't > backup anything. > > Please help me ! > From owner-linux-xfs@oss.sgi.com Wed May 11 13:47:05 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 May 2005 13:47:09 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4BKl5Ov001920 for ; Wed, 11 May 2005 13:47:05 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4BMUHfP026345 for ; Wed, 11 May 2005 15:30:17 -0700 Received: from chewtoy.americas.sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4BKjcR07888611; Wed, 11 May 2005 15:45:38 -0500 (CDT) Received: from chewtoy (localhost [127.0.0.1]) by chewtoy.americas.sgi.com (Postfix) with ESMTP id 831CA4FE8A; Wed, 11 May 2005 15:45:38 -0500 (CDT) To: Aurelien Degremont - Stagiaire Cc: linux-xfs@oss.sgi.com Subject: Re: [DMAPI] code error in dm_ip_to_handle() Date: Wed, 11 May 2005 15:45:38 -0500 From: Dean Roehrich Message-Id: <20050511204538.831CA4FE8A@chewtoy.americas.sgi.com> X-archive-position: 5197 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2615 Lines: 77 Maybe we should throw out struct dm_fsfid and just use struct dm_fid? Then XFS, for example, would have to translate its fid_t into a struct dm_fid on its own and DMAPI shouldn't have to guess about how they match up. I wonder how that would work? Dean >From: Aurelien Degremont - Stagiaire >Hello, > >I'm still working on DMAPI code and I found a problem in >dm_ip_to_handle() function. In fact, the problem is not specific to this >function, I just found it here. > >To sum up, I found, in the XFS+DMAPI code, along all the different >calls, you successively cast some structures and recopy data without >verifying their content. With XFS, all is ok because 2 errors fix each >others, but, when i try adding dmapi support to ext3, the problem appears. > >In order to create a dmapi handle, you must call dm_ip_to_handle(). >This function will fill a dm_handle_t structure. The data recopied came >from a dm_fsfid structure which do not have the same fields. > >ex: memcpy( &[DM_HANDLE_T], &[DM_FSID_T], ...) > >This copy the content of the len field without errors. >**But the first byte of the fid_data buffer will be recopied in the >padding field (dm_fid_pad) of the dm_fid structure !** (which is not >what is expected) >When DMAPI will try to extract the inode number, it will be wrong ! > >This code works correctly with XFS because XFS uses the same kind of >structure as DMAPI, and so, when the datas are copied, the padding is ok. >XFS will copied the data from : > >xfs_fid2_t --> fid_t -//pad error//-> dm_fsfid_t -//pad error//-> dm_fid_t > >Their 2 errors with byte alignement when data are cast and copied, but >the first is the opposite of the second, so the data are correct at the end. > >This is not true when you correctly fill the dm_fsfid_t structure :) > >________________________________________________________ >#define MAXDMFSFIDSZ 46 > >typedef struct dm_fsfid { > __u16 fid_len; /* length of data in bytes */ > unsigned char fid_data[MAXDMFSFIDSZ]; /* data (fid_len worth) */ >} dm_fsfid_t; > >struct dm_fid { > __u16 dm_fid_len; /* length of remainder */ > __u16 dm_fid_pad; > __u32 dm_fid_gen; /* generation number */ > __u64 dm_fid_ino; /* 64 bits inode number */ >}; >typedef struct dm_fid dm_fid_t; > > >struct dm_handle { > union { > __s64 align; /* force alignment of ha_fid */ > dm_fsid_t _ha_fsid; /* unique file system identifier */ > } ha_u; > dm_fid_t ha_fid; /* file system specific file ID */ >}; >typedef struct dm_handle dm_handle_t; >________________________________________________________ > > > > >Aurélien > From owner-linux-xfs@oss.sgi.com Wed May 11 14:14:04 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 May 2005 14:14:09 -0700 (PDT) Received: from smtp.wirelessza.co.za (smtp.wirelessza.co.za [196.15.251.88]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4BLE2Ov003576 for ; Wed, 11 May 2005 14:14:04 -0700 Received: from [196.2.118.34] (helo=picturenet.co.za) by smtp.wirelessza.co.za with esmtp (Exim 4.51) id 1DVyaK-0001yB-Fy; Wed, 11 May 2005 23:17:40 +0200 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by picturenet.co.za (Postfix) with ESMTP id 0B782227C; Wed, 11 May 2005 23:14:18 +0200 (SAST) From: Leon Vismer Reply-To: lvismer@picturenet.co.za To: Eric Sandeen , naude@mail.picturenet.co.za Subject: Re: XFS on 2.4 Tib raid Date: Wed, 11 May 2005 23:14:17 +0200 User-Agent: KMail/1.8 Cc: linux-xfs@oss.sgi.com References: <200505092210.25667.lvismer@picturenet.co.za> <428221FC.8050203@sgi.com> In-Reply-To: <428221FC.8050203@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505112314.17750.lvismer@picturenet.co.za> X-archive-position: 5198 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lvismer@picturenet.co.za Precedence: bulk X-list: linux-xfs Content-Length: 550 Lines: 25 Hi Eric On Wednesday 11 May 2005 17:17, Eric Sandeen wrote: > Leon Vismer wrote: > > Hi > > > > I am using an ATTO scsi card speaking to an Infortrend 2.4 Tib raid > > system. > > > > Some system config settings: > > Distro: debian sarge > > Kernel: 2.6.11 (kernel-image-2.6.11-1-686) > > XFS: xfsprogs (2.6.28-1) > > Just to be sure, have you enabled CONFIG_LBD? > We did not recompile the kernel per-se however in /boot/config-2.6.11-1-686 (other distros /proc/config.gz) under the Parallel IDE protocol modules CONFIG_LBD=y -- Leon > -Eric From owner-linux-xfs@oss.sgi.com Wed May 11 16:27:40 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 May 2005 16:27:44 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4BNReOv016452 for ; Wed, 11 May 2005 16:27:40 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4C1Area032027 for ; Wed, 11 May 2005 18:10:53 -0700 Received: from tulip-e236.americas.sgi.com (tulip-e236.americas.sgi.com [128.162.236.208]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4BNQAR07896635; Wed, 11 May 2005 18:26:10 -0500 (CDT) Received: from [128.162.233.33] (chewtoy.americas.sgi.com [128.162.233.33]) by tulip-e236.americas.sgi.com (8.12.9/ASC-news-1.4) with ESMTP id j4BNQ9fc3944495; Wed, 11 May 2005 18:26:10 -0500 (CDT) Message-ID: <42829491.2080502@sgi.com> Date: Wed, 11 May 2005 18:26:09 -0500 From: Dean Roehrich User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040906 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aurelien Degremont - Stagiaire CC: linux-xfs@oss.sgi.com Subject: Re: vfs_altfsid & dm_fsid References: <20050428021133.A885C4FE57@chewtoy.americas.sgi.com> <4278CDB8.3060309@ocre.cea.fr> In-Reply-To: <4278CDB8.3060309@ocre.cea.fr> X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------000009040703060608010402" X-archive-position: 5199 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 21691 Lines: 746 This is a multi-part message in MIME format. --------------000009040703060608010402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Aurelien Degremont - Stagiaire wrote: > Dean Roehrich a icrit: > >> If your filesystem of choice doesn't have an fsid, then you could just >> generate one that is valid while the filesystem is mounted and is not >> written >> to the filesystem, or you could come up with something else. >> Whatever you >> choose for an fsid should fit into a 64-bit type. > > > >> 1) The fsid should be a parameter to dm_send_mount_event() and >> dm_send_namesp_event() and dm_send_unmount_event(). >> The get_fsid op in struct filesystem_dmapi_operations should be >> dropped. > > > Ok, so we need to modify : > xfs_dm_mount() > xfs_dm_send_namesp_event() > xfs_dm_send_unmount_event() > > The fsid could be taken in vfsp. Let's see if I can get the attachment right.... There should be an attachment here that has a draft of the fsid changes. This is lightly tested. Dean --------------000009040703060608010402 Content-Type: text/plain; name="dm_fsid" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dm_fsid" Index: lbs3.5-rpms-a/linux/linux/fs/xfs/xfs_dmapi.c =================================================================== --- lbs3.5-rpms-a.orig/linux/linux/fs/xfs/xfs_dmapi.c 2005-05-11 14:18:17.000000000 -0700 +++ lbs3.5-rpms-a/linux/linux/fs/xfs/xfs_dmapi.c 2005-05-11 14:19:02.000000000 -0700 @@ -209,7 +209,8 @@ xfs_dm_send_data_event( #endif error = dm_send_data_event(event, inode, DM_RIGHT_NULL, - offset, length, flags); + offset, length, flags, + (dm_fsid_t*)vp->v_vfsp->vfs_altfsid); error = -error; /* DMAPI returns negative errors */ if (flags & DM_FLAGS_ISEM) @@ -3124,7 +3125,8 @@ xfs_dm_send_destroy_event( /* Returns positive errors to XFS */ - error = dm_send_destroy_event(LINVFS_GET_IP(vp), vp_right); + error = dm_send_destroy_event(LINVFS_GET_IP(vp), vp_right, + (dm_fsid_t*)vp->v_vfsp->vfs_altfsid); error = -error; /* DMAPI returns negative errors */ return error; /* Return positive error to XFS */ @@ -3153,7 +3155,8 @@ xfs_dm_send_namesp_event( LINVFS_GET_IP(vp1), vp1_right, vp2 ? LINVFS_GET_IP(vp2) : NULL, vp2_right, name1, name2, - mode, retcode, flags); + mode, retcode, flags, + (dm_fsid_t*)vp1->v_vfsp->vfs_altfsid); error = -error; /* DMAPI returns negative errors */ return error; /* Return positive error to XFS */ @@ -3170,7 +3173,8 @@ xfs_dm_send_unmount_event( int flags) { dm_send_unmount_event(vfsp->vfs_super, vp ? LINVFS_GET_IP(vp) : NULL, - vfsp_right, mode, retcode, flags); + vfsp_right, mode, retcode, flags, + (dm_fsid_t*)vfsp->vfs_altfsid); } @@ -3244,16 +3248,6 @@ xfs_dm_get_dmapiops( return -error; /* Return negative error to DMAPI */ } -static void -xfs_dm_get_fsid( - struct super_block *sb, - dm_fsid_t *fsid) -{ - vfs_t *vfsp = LINVFS_GET_VFS(sb); - memcpy(fsid, vfsp->vfs_altfsid, sizeof(*fsid)); -} - - /* * Filesystem operations accessed by the DMAPI core. */ @@ -3262,7 +3256,6 @@ struct filesystem_dmapi_operations xfs_d .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, }; /* @@ -3312,7 +3305,8 @@ xfs_dm_mount( DM_RIGHT_NULL, NULL, DM_RIGHT_NULL, LINVFS_GET_IP(rootvp), DM_RIGHT_NULL, - args->mtpt, args->fsname); + args->mtpt, args->fsname, + (dm_fsid_t*)vfsp->vfs_altfsid); error = -error; /* DMAPI returns negative errs */ } } Index: lbs3.5-rpms-a/linux/linux/fs/dmapi/dmapi_session.c =================================================================== --- lbs3.5-rpms-a.orig/linux/linux/fs/dmapi/dmapi_session.c 2005-05-11 14:18:17.000000000 -0700 +++ lbs3.5-rpms-a/linux/linux/fs/dmapi/dmapi_session.c 2005-05-11 14:18:28.000000000 -0700 @@ -1395,7 +1395,7 @@ dm_enqueue( int dm_enqueue_normal_event( - struct super_block *sb, + dm_fsid_t *fsid, dm_tokevent_t *tevp, int flags) { @@ -1440,7 +1440,7 @@ dm_enqueue_normal_event( is locked upon return from dm_waitfor_disp_session(). */ - if ((error = dm_waitfor_disp_session(sb, tevp, &s, &lc)) != 0) + if ((error = dm_waitfor_disp_session(fsid, tevp, &s, &lc)) != 0) return(error); return(dm_enqueue(s, lc, tevp, sync, flags, 0)); @@ -1466,7 +1466,8 @@ dm_enqueue_normal_event( int dm_enqueue_mount_event( struct super_block *sb, - dm_tokevent_t *tevp) + dm_tokevent_t *tevp, + dm_fsid_t *fsid) { dm_session_t *s; dm_sessid_t sid; @@ -1475,7 +1476,7 @@ dm_enqueue_mount_event( /* Make the mounting filesystem visible to other DMAPI calls. */ - if ((error = dm_add_fsys_entry(sb, tevp)) != 0){ + if ((error = dm_add_fsys_entry(sb, tevp, fsid)) != 0){ return(error); } @@ -1506,10 +1507,10 @@ dm_enqueue_mount_event( */ if (error >= 0) { - dm_change_fsys_entry(sb, DM_STATE_MOUNTED); + dm_change_fsys_entry(fsid, DM_STATE_MOUNTED); error = 0; } else { - dm_remove_fsys_entry(sb); + dm_remove_fsys_entry(fsid); } return(error); } @@ -1657,7 +1658,7 @@ dm_flush_events( */ int dm_release_threads( - struct super_block *sb, + dm_fsid_t *fsid, struct inode *inode, /* may be null */ int errno) { @@ -1668,14 +1669,8 @@ dm_release_threads( dm_sessid_t *sidlist; int i; int found_events = 0; - dm_fsid_t fsid; - struct filesystem_dmapi_operations *dops; - ASSERT(sb); - dops = dm_fsys_ops_by_fstype(sb->s_type); - ASSERT(dops); - dops->get_fsid(sb, &fsid); - dm_release_disp_threads(&fsid, inode, errno); + dm_release_disp_threads(fsid, inode, errno); /* Loop until we can get the right amount of temp space, being careful not to hold a mutex during the allocation. Usually only one trip. @@ -1708,14 +1703,14 @@ dm_release_threads( for (i = 0; i < sesscnt; i++) { sid = sidlist[i]; if( dm_find_session_and_lock( sid, &s, &lc ) == 0 ){ - found_events = dm_flush_events( s, &fsid, inode, + found_events = dm_flush_events( s, fsid, inode, &s->sn_evt_writerq, 1, errno ); if (found_events) sv_broadcast(&s->sn_writerq); - dm_flush_events(s, &fsid, inode, &s->sn_newq, 0, errno); - dm_flush_events(s, &fsid, inode, &s->sn_delq, 0, errno); + dm_flush_events(s, fsid, inode, &s->sn_newq, 0, errno); + dm_flush_events(s, fsid, inode, &s->sn_delq, 0, errno); mutex_spinunlock( &s->sn_qlock, lc ); } Index: lbs3.5-rpms-a/linux/linux/fs/dmapi/dmapi_private.h =================================================================== --- lbs3.5-rpms-a.orig/linux/linux/fs/dmapi/dmapi_private.h 2005-05-11 14:18:17.000000000 -0700 +++ lbs3.5-rpms-a/linux/linux/fs/dmapi/dmapi_private.h 2005-05-11 14:18:28.000000000 -0700 @@ -344,13 +344,14 @@ void dm_evt_rele_tevp( int droprights); int dm_enqueue_normal_event( - struct super_block *sbp, + dm_fsid_t *fsid, dm_tokevent_t *tevp, int flags); int dm_enqueue_mount_event( struct super_block *sbp, - dm_tokevent_t *tevp); + dm_tokevent_t *tevp, + dm_fsid_t *fsid); int dm_enqueue_sendmsg_event( dm_sessid_t targetsid, @@ -439,7 +440,7 @@ int dm_get_allocinfo_rvp( int *rvp); int dm_waitfor_destroy_attrname( - struct super_block *sb, + dm_fsid_t *fsid, dm_attrname_t *attrnamep); void dm_clear_fsreg( @@ -447,14 +448,15 @@ void dm_clear_fsreg( int dm_add_fsys_entry( struct super_block *sb, - dm_tokevent_t *tevp); + dm_tokevent_t *tevp, + dm_fsid_t *fsid); void dm_change_fsys_entry( - struct super_block *sb, + dm_fsid_t *fsid, dm_fsstate_t newstate); void dm_remove_fsys_entry( - struct super_block *sb); + dm_fsid_t *fsid); dm_fsys_vector_t *dm_fsys_vector( struct inode *ip); @@ -465,7 +467,7 @@ struct filesystem_dmapi_operations *dm_f void dm_fsys_vector_free(void); int dm_waitfor_disp_session( - struct super_block *sb, + dm_fsid_t *fsid, dm_tokevent_t *tevp, dm_session_t **sessionpp, unsigned long *lcp); Index: lbs3.5-rpms-a/linux/linux/fs/dmapi/dmapi_register.c =================================================================== --- lbs3.5-rpms-a.orig/linux/linux/fs/dmapi/dmapi_register.c 2005-05-11 14:18:17.000000000 -0700 +++ lbs3.5-rpms-a/linux/linux/fs/dmapi/dmapi_register.c 2005-05-11 14:18:28.000000000 -0700 @@ -201,18 +201,13 @@ dm_find_fsreg_and_lock( int dm_add_fsys_entry( struct super_block *sb, - dm_tokevent_t *tevp) + dm_tokevent_t *tevp, + dm_fsid_t *fsid) { dm_fsreg_t *fsrp; int msgsize; void *msg; unsigned long lc; /* lock cookie */ - dm_fsid_t fsid; - struct filesystem_dmapi_operations *dops; - - dops = dm_fsys_ops_by_fstype(sb->s_type); - ASSERT(dops); - dops->get_fsid(sb, &fsid); /* Allocate and initialize a dm_fsreg_t structure for the filesystem. */ @@ -234,7 +229,7 @@ dm_add_fsys_entry( fsrp->fr_sb = sb; fsrp->fr_tevp = tevp; - memcpy(&fsrp->fr_fsid, &fsid, sizeof(fsid)); + memcpy(&fsrp->fr_fsid, fsid, sizeof(*fsid)); fsrp->fr_msg = msg; fsrp->fr_msgsize = msgsize; fsrp->fr_state = DM_STATE_MOUNTING; @@ -248,7 +243,7 @@ dm_add_fsys_entry( lc = mutex_spinlock(&dm_reg_lock); - if (!dm_find_fsreg(&fsid)) { + if (!dm_find_fsreg(fsid)) { fsrp->fr_next = dm_registers; dm_registers = fsrp; dm_fsys_cnt++; @@ -292,26 +287,16 @@ dm_add_fsys_entry( void dm_change_fsys_entry( - struct super_block *sb, + dm_fsid_t *fsid, dm_fsstate_t newstate) { dm_fsreg_t *fsrp; int seq_error; unsigned long lc; /* lock cookie */ - dm_fsid_t fsid; - struct filesystem_dmapi_operations *dops; - /* Find the filesystem referenced by the sb's fsid_t. This should - always succeed. - */ - - dops = dm_fsys_ops_by_fstype(sb->s_type); - ASSERT(dops); - dops->get_fsid(sb, &fsid); - - if ((fsrp = dm_find_fsreg_and_lock(&fsid, &lc)) == NULL) { + if ((fsrp = dm_find_fsreg_and_lock(fsid, &lc)) == NULL) { panic("dm_change_fsys_entry: can't find DMAPI fsrp for " - "sb %p\n", sb); + "fsid 0x%llx\n", (unsigned long long)*fsid); } /* Make sure that the new state is acceptable given the current state @@ -390,17 +375,11 @@ dm_change_fsys_entry( void dm_remove_fsys_entry( - struct super_block *sb) + dm_fsid_t *fsid) { dm_fsreg_t **fsrpp; dm_fsreg_t *fsrp; unsigned long lc; /* lock cookie */ - struct filesystem_dmapi_operations *dops; - dm_fsid_t fsid; - - dops = dm_fsys_ops_by_fstype(sb->s_type); - ASSERT(dops); - dops->get_fsid(sb, &fsid); /* Find the filesystem referenced by the sb's fsid_t and dequeue it after verifying that the fr_state shows a filesystem that is @@ -411,14 +390,14 @@ dm_remove_fsys_entry( fsrpp = &dm_registers; while ((fsrp = *fsrpp) != NULL) { - if (!memcmp(&fsrp->fr_fsid, &fsid, sizeof(fsrp->fr_fsid))) + if (!memcmp(&fsrp->fr_fsid, fsid, sizeof(fsrp->fr_fsid))) break; fsrpp = &fsrp->fr_next; } if (fsrp == NULL) { mutex_spinunlock(&dm_reg_lock, lc); panic("dm_remove_fsys_entry: can't find DMAPI fsrp for " - "sb %p\n", sb); + "fsid 0x%llx\n", (unsigned long long)fsid); } nested_spinlock(&fsrp->fr_lock); @@ -673,7 +652,7 @@ dm_find_mount_tevp_and_lock( static int dm_waitfor_disp( - struct super_block *sb, + dm_fsid_t *fsid, dm_tokevent_t *tevp, dm_fsreg_t **fsrpp, unsigned long *lc1p, /* addr of first returned lock cookie */ @@ -683,14 +662,8 @@ dm_waitfor_disp( dm_eventtype_t event = tevp->te_msg.ev_type; dm_session_t *s; dm_fsreg_t *fsrp; - dm_fsid_t fsid; - struct filesystem_dmapi_operations *dops; - - dops = dm_fsys_ops_by_fstype(sb->s_type); - ASSERT(dops); - dops->get_fsid(sb, &fsid); - if ((fsrp = dm_find_fsreg_and_lock(&fsid, lc1p)) == NULL) + if ((fsrp = dm_find_fsreg_and_lock(fsid, lc1p)) == NULL) return -ENOENT; /* If no session is registered for this event in the specified @@ -760,7 +733,7 @@ dm_waitfor_disp( int dm_waitfor_disp_session( - struct super_block *sb, + dm_fsid_t *fsid, dm_tokevent_t *tevp, dm_session_t **sessionpp, unsigned long *lcp) @@ -772,7 +745,7 @@ dm_waitfor_disp_session( if (tevp->te_msg.ev_type < 0 || tevp->te_msg.ev_type > DM_EVENT_MAX) return(-EIO); - error = dm_waitfor_disp(sb, tevp, &fsrp, lcp, sessionpp, &lc2); + error = dm_waitfor_disp(fsid, tevp, &fsrp, lcp, sessionpp, &lc2); if (!error) mutex_spinunlock(&fsrp->fr_lock, lc2); /* rev. cookie order*/ return(error); @@ -787,7 +760,7 @@ dm_waitfor_disp_session( int dm_waitfor_destroy_attrname( - struct super_block *sbp, + dm_fsid_t *fsid, dm_attrname_t *attrnamep) { dm_tokevent_t *tevp; @@ -799,7 +772,7 @@ dm_waitfor_destroy_attrname( void *msgp; tevp = dm_evt_create_tevp(DM_EVENT_DESTROY, 1, (void**)&msgp); - error = dm_waitfor_disp(sbp, tevp, &fsrp, &lc1, &s, &lc2); + error = dm_waitfor_disp(fsid, tevp, &fsrp, &lc1, &s, &lc2); if (!error) { *attrnamep = fsrp->fr_rattr; /* attribute or zeros */ mutex_spinunlock(&s->sn_qlock, lc2); /* rev. cookie order */ Index: lbs3.5-rpms-a/linux/linux/fs/dmapi/dmapi_kern.h =================================================================== --- lbs3.5-rpms-a.orig/linux/linux/fs/dmapi/dmapi_kern.h 2005-05-11 14:18:17.000000000 -0700 +++ lbs3.5-rpms-a/linux/linux/fs/dmapi/dmapi_kern.h 2005-05-11 14:18:28.000000000 -0700 @@ -71,6 +71,7 @@ struct dm_handle_t; #define DM_CLVL_INIT 0 /* DMAPI prior to X/Open compliance */ #define DM_CLVL_XOPEN 1 /* X/Open compliant DMAPI */ +#define DMAPI_USES_FSID /* * Filesystem operations accessed by the DMAPI core. @@ -82,7 +83,6 @@ struct filesystem_dmapi_operations { struct file_operations * (*get_invis_ops)(struct inode *ip); int (*inode_to_fh)(struct inode *ip, struct dm_fsfid *fid, dm_fsid_t *fsid ); - void (*get_fsid)(struct super_block *sb, dm_fsid_t *fsid); #define HAVE_DM_QUEUE_FLUSH int (*flushing)(struct inode *ip); }; @@ -96,11 +96,13 @@ int dm_send_data_event( dm_right_t vp_right, dm_off_t off, size_t len, - int flags); + int flags, + dm_fsid_t *fsid); int dm_send_destroy_event( struct inode *ip, - dm_right_t vp_right); + dm_right_t vp_right, + dm_fsid_t *fsid); int dm_send_mount_event( struct super_block *sb, @@ -110,7 +112,8 @@ int dm_send_mount_event( struct inode *rootip, dm_right_t rootvp_right, char *name1, - char *name2); + char *name2, + dm_fsid_t *fsid); int dm_send_namesp_event( dm_eventtype_t event, @@ -123,7 +126,8 @@ int dm_send_namesp_event( char *name2, mode_t mode, int retcode, - int flags); + int flags, + dm_fsid_t *fsid); void dm_send_unmount_event( struct super_block *sbp, @@ -131,7 +135,8 @@ void dm_send_unmount_event( dm_right_t sbp_right, mode_t mode, int retcode, - int flags); + int flags, + dm_fsid_t *fsid); int dm_code_level(void); @@ -141,7 +146,7 @@ int dm_ip_to_handle ( #define HAVE_DM_RELEASE_THREADS_ERRNO int dm_release_threads( - struct super_block *sb, + dm_fsid_t *fsid, struct inode *inode, int errno); Index: lbs3.5-rpms-a/linux/linux/fs/dmapi/dmapi_event.c =================================================================== --- lbs3.5-rpms-a.orig/linux/linux/fs/dmapi/dmapi_event.c 2005-05-11 14:18:17.000000000 -0700 +++ lbs3.5-rpms-a/linux/linux/fs/dmapi/dmapi_event.c 2005-05-11 14:18:28.000000000 -0700 @@ -196,15 +196,10 @@ static dm_tokdata_t * dm_sb_data( struct super_block *sb, struct inode *ip, /* will be NULL for DM_EVENT_UNMOUNT */ - dm_right_t right) + dm_right_t right, + dm_fsid_t *fsid) { dm_tokdata_t *tdp; - struct filesystem_dmapi_operations *dops; - dm_fsid_t fsid; - - dops = dm_fsys_ops_by_fstype(sb->s_type); - ASSERT(dops); - dops->get_fsid(sb, &fsid); tdp = kmem_cache_alloc(dm_tokdata_cachep, SLAB_KERNEL); if (tdp == NULL) { @@ -225,9 +220,9 @@ dm_sb_data( tdp->td_ip = ip; tdp->td_vcount = 0; - memcpy(&tdp->td_handle.ha_fsid, &fsid, sizeof(fsid)); - memset((char *)&tdp->td_handle.ha_fsid + sizeof(fsid), 0, - sizeof(tdp->td_handle) - sizeof(fsid)); + memcpy(&tdp->td_handle.ha_fsid, fsid, sizeof(*fsid)); + memset((char *)&tdp->td_handle.ha_fsid + sizeof(*fsid), 0, + sizeof(tdp->td_handle) - sizeof(*fsid)); return(tdp); } @@ -258,7 +253,8 @@ dm_send_data_event( dm_right_t vp_right, /* current right for ip */ dm_off_t offset, size_t length, - int flags) /* 0 or DM_FLAGS_NDELAY */ + int flags, /* 0 or DM_FLAGS_NDELAY */ + dm_fsid_t *fsid) { dm_data_event_t *datap; dm_tokevent_t *tevp; @@ -291,7 +287,7 @@ dm_send_data_event( /* Queue the message and wait for the reply. */ - error = dm_enqueue_normal_event(ip->i_sb, tevp, flags); + error = dm_enqueue_normal_event(fsid, tevp, flags); /* If no errors occurred, we must leave with the same rights we had upon entry. If errors occurred, we must leave with no rights. @@ -314,7 +310,8 @@ dm_send_data_event( int dm_send_destroy_event( struct inode *ip, - dm_right_t vp_right) /* always DM_RIGHT_NULL */ + dm_right_t vp_right, /* always DM_RIGHT_NULL */ + dm_fsid_t *fsid) { dm_fsys_vector_t *fsys_vector; dm_tokevent_t *tevp; @@ -329,7 +326,7 @@ dm_send_destroy_event( if (tdp == NULL) return -ENOMEM; - if ((error = dm_waitfor_destroy_attrname(ip->i_sb, &attrname)) != 0) + if ((error = dm_waitfor_destroy_attrname(fsid, &attrname)) != 0) return(error); /* If a return-on-destroy attribute name exists for this filesystem, @@ -384,7 +381,7 @@ dm_send_destroy_event( /* Queue the message asynchronously. */ - error = dm_enqueue_normal_event(ip->i_sb, tevp, 0); + error = dm_enqueue_normal_event(fsid, tevp, 0); /* Since we had no rights upon entry, we have none to reobtain before leaving. @@ -410,7 +407,8 @@ dm_send_mount_event( struct inode *rootip, dm_right_t rootvp_right, char *name1, /* mount path */ - char *name2) /* filesystem device name */ + char *name2, /* filesystem device name */ + dm_fsid_t *fsid) { int error; dm_tokevent_t *tevp = NULL; @@ -425,7 +423,7 @@ dm_send_mount_event( if it is a different filesystem type which does not support DMAPI. */ - tdp1 = dm_sb_data(sb, rootip, vfsp_right); + tdp1 = dm_sb_data(sb, rootip, vfsp_right, fsid); if (tdp1 == NULL) goto out_nomem; @@ -492,7 +490,7 @@ dm_send_mount_event( /* Queue the message and wait for the reply. */ - error = dm_enqueue_mount_event(sb, tevp); + error = dm_enqueue_mount_event(sb, tevp, fsid); /* If no errors occurred, we must leave with the same rights we had upon entry. If errors occurred, we must leave with no rights. @@ -540,7 +538,8 @@ dm_send_unmount_event( dm_right_t vfsp_right, mode_t mode, int retcode, /* errno, if unmount failed */ - int flags) + int flags, + dm_fsid_t *fsid) { dm_namesp_event_t *np; dm_tokevent_t *tevp; @@ -553,9 +552,9 @@ dm_send_unmount_event( */ if (retcode != 0) { /* unmount was unsuccessful */ - dm_change_fsys_entry(sb, DM_STATE_MOUNTED); + dm_change_fsys_entry(fsid, DM_STATE_MOUNTED); } else { - dm_change_fsys_entry(sb, DM_STATE_UNMOUNTED); + dm_change_fsys_entry(fsid, DM_STATE_UNMOUNTED); } /* If the event wasn't in the filesystem dm_eventset_t, just remove @@ -564,7 +563,7 @@ dm_send_unmount_event( if (flags & DM_FLAGS_UNWANTED) { if (retcode == 0) - dm_remove_fsys_entry(sb); + dm_remove_fsys_entry(fsid); return; } @@ -572,7 +571,7 @@ dm_send_unmount_event( for it. */ - tdp1 = dm_sb_data(sb, ip, vfsp_right); + tdp1 = dm_sb_data(sb, ip, vfsp_right, fsid); if (tdp1 == NULL) return; @@ -598,10 +597,10 @@ dm_send_unmount_event( message and ignore any error return for DM_EVENT_UNMOUNT. */ - (void)dm_enqueue_normal_event(sb, tevp, flags); + (void)dm_enqueue_normal_event(fsid, tevp, flags); if (retcode == 0) - dm_remove_fsys_entry(sb); + dm_remove_fsys_entry(fsid); dm_evt_rele_tevp(tevp, 0); } @@ -626,7 +625,8 @@ dm_send_namesp_event( char *name2, mode_t mode, int retcode, - int flags) + int flags, + dm_fsid_t *fsid) { dm_namesp_event_t *np; dm_tokevent_t *tevp; @@ -651,7 +651,7 @@ dm_send_namesp_event( */ if (flags & DM_FLAGS_UNWANTED) { - dm_change_fsys_entry(sb, DM_STATE_UNMOUNTING); + dm_change_fsys_entry(fsid, DM_STATE_UNMOUNTING); return(0); } if (ip1 == NULL) { @@ -661,7 +661,7 @@ dm_send_namesp_event( */ return(0); } - tdp1 = dm_sb_data(sb, ip1, vp1_right); + tdp1 = dm_sb_data(sb, ip1, vp1_right, fsid); if (tdp1 == NULL) return -ENOMEM; tdp2 = dm_ip_data(ip2, vp2_right, /* reference held */ 1); @@ -674,7 +674,7 @@ dm_send_namesp_event( case DM_EVENT_NOSPACE: /* vp1_right is the filesystem right. */ - tdp1 = dm_sb_data(sb, ip1, vp1_right); + tdp1 = dm_sb_data(sb, ip1, vp1_right, fsid); if (tdp1 == NULL) return -ENOMEM; tdp2 = dm_ip_data(ip2, vp2_right, /* reference held */ 1); /* additional info - not in the spec */ @@ -753,7 +753,7 @@ dm_send_namesp_event( /* Queue the message and wait for the reply. */ - error = dm_enqueue_normal_event(sb, tevp, flags); + error = dm_enqueue_normal_event(fsid, tevp, flags); /* If no errors occurred, we must leave with the same rights we had upon entry. If errors occurred, we must leave with no rights. @@ -762,7 +762,7 @@ dm_send_namesp_event( dm_evt_rele_tevp(tevp, error); if (!error && event == DM_EVENT_PREUNMOUNT) { - dm_change_fsys_entry(sb, DM_STATE_UNMOUNTING); + dm_change_fsys_entry(fsid, DM_STATE_UNMOUNTING); } return(error); --------------000009040703060608010402-- From owner-linux-xfs@oss.sgi.com Wed May 11 17:41:02 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 May 2005 17:41:06 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4C0f0Ov019544 for ; Wed, 11 May 2005 17:41:01 -0700 Received: from mumble.melbourne.sgi.com (mumble.melbourne.sgi.com [134.14.55.227]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA26292; Thu, 12 May 2005 10:40:23 +1000 Received: from mumble.melbourne.sgi.com (localhost [127.0.0.1]) by mumble.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j4C0eEXf093791; Thu, 12 May 2005 10:40:18 +1000 (EST) Received: (from dgc@localhost) by mumble.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j4C0e22T095050; Thu, 12 May 2005 10:40:02 +1000 (EST) Date: Thu, 12 May 2005 10:40:02 +1000 From: Dave Chinner To: Leon Vismer Cc: linux-xfs@oss.sgi.com, naude@mail.picturenet.co.za Subject: Re: XFS on 2.4 Tib raid Message-ID: <20050512104002.D94938@melbourne.sgi.com> References: <200505092210.25667.lvismer@picturenet.co.za> <1115712231.42806ae75b4d1@picturenet.co.za> <20050511084450.A91712@melbourne.sgi.com> <200505111357.13113.lvismer@picturenet.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200505111357.13113.lvismer@picturenet.co.za>; from lvismer@picturenet.co.za on Wed, May 11, 2005 at 01:57:12PM +0200 X-archive-position: 5200 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1505 Lines: 49 On Wed, May 11, 2005 at 01:57:12PM +0200, Leon Vismer wrote: > Hi Dave > > I did the following: > > # parted /dev/sdc > parted> mklabel gpt > parted> mkpart primary 0 2384080 > parted> quit > > I saw the following in tail /var/log/messages > > May 11 13:37:40 mail kernel: program parted is using a deprecated SCSI ioctl, > please convert it to SG_IO > May 11 13:37:50 mail kernel: sym1:4:0:phase change 2-7 16@01b75f60 resid=10. > > # xfs_check /dev/sdc1 (gives the following) > > bad sb magic # 0xb0b25aab in ag 30 > bad sb version # 0x9d8b in ag 30 > bad agf magic # 0x9be1c556 in ag 30 > bad agf version # 0xf2c55d8a in ag 30 > bad agi magic # 0xe0467f8a in ag 30 > bad agi version # 0xb4f92355 in ag 30 ..... Looks like binary file data in AG 30 and 31. Given that mkfs probably gave you 32 AGs in your filesystem, these 2 AGs are the only ones that lie totally above the 2TiB filesystem offset. From this, I'm almost certain that accesses to blocks > 2TiB are wrapping back to block zero. Can you rebuild a kernel yourself so we are certain that it is built with CONFIG_LBD=y? Hmmm - just a random though - the SCSI protocol is limited to addressing 2^32 sectors, which is 2TiB on a 512 byte sector size device. You're trying to address a 2.4TiB SCSI device - what sector size is your RAID controller using? If you set it to 1k or 2k and use the mkfs option "-s size=xxxx" do you see this same problem? Cheers, Dave. -- Dave Chinner R&D Software Engineer SGI Australian Software Group From owner-linux-xfs@oss.sgi.com Wed May 11 19:01:45 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 May 2005 19:01:49 -0700 (PDT) Received: from amanpulo.hosting.qsr.com.ph (amanpulo.hosting.qsr.com.ph [64.34.170.22]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4C21iOv022638 for ; Wed, 11 May 2005 19:01:45 -0700 Received: from localhost (localhost [127.0.0.1]) by amanpulo.hosting.qsr.com.ph (Postfix) with ESMTP id 9E1E11C507CF for ; Thu, 12 May 2005 10:01:18 +0800 (PHT) Received: from musang.free.net.ph (unknown [202.163.197.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by amanpulo.hosting.qsr.com.ph (Postfix) with ESMTP id 4017F1C507CC for ; Thu, 12 May 2005 10:01:15 +0800 (PHT) Received: by musang.free.net.ph (Postfix, from userid 1000) id 112B160010A; Thu, 12 May 2005 10:01:20 +0800 (PHT) Date: Thu, 12 May 2005 10:01:20 +0800 From: Federico Sevilla III To: linux-xfs@oss.sgi.com Subject: Re: cannot mount a partition (error 990) Message-ID: <20050512020120.GC4811@free.net.ph> Mail-Followup-To: linux-xfs@oss.sgi.com References: <1115818362.4282097ab98b9@imp2-q.free.fr> <1115841949.4282659dbbf38@imp1-q.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115841949.4282659dbbf38@imp1-q.free.fr> X-Personal-URL: http://jijo.free.net.ph User-Agent: Mutt/1.5.9i X-archive-position: 5202 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jijo@free.net.ph Precedence: bulk X-list: linux-xfs Content-Length: 472 Lines: 13 On Wed, May 11, 2005 at 10:05:49PM +0200, jdf [zionarea.org] wrote: > I went more deeply to the list archive and found a good solving > solution to my problem. It's now working well again. I'm curious, just for future reference, and to help with future searches of the archive: how did you fix the problem? --> Jijo -- Federico Sevilla III : jijo.free.net.ph : When we speak of free software GNU/Linux Specialist : GnuPG 0x93B746BE : we refer to freedom, not price. From owner-linux-xfs@oss.sgi.com Wed May 11 20:43:44 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 May 2005 20:43:47 -0700 (PDT) Received: from twinlark.arctic.org (twinlark.arctic.org [207.7.145.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4C3hhOv029657 for ; Wed, 11 May 2005 20:43:44 -0700 Received: (qmail 673 invoked from network); 12 May 2005 03:43:17 -0000 Received: from unknown (HELO localhost) (127.0.0.1) by 127.0.0.1 with ESMTPS (AES256-SHA); 12 May 2005 03:43:17 -0000 Date: Wed, 11 May 2005 20:43:17 -0700 (PDT) From: dean gaudet To: linux-xfs@oss.sgi.com Subject: 2.4.30 xfs + lvm snapshot oops Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5203 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dean-list-linux-xfs@arctic.org Precedence: bulk X-list: linux-xfs Content-Length: 4367 Lines: 108 i'm running 2.4.30 + linux-2.4.22-VFS-lock.patch and lvm 1.0.8... my nightly backups use a snapshot. i don't do xfs_freeze before/after because i'm using the VFS lock patch (and besides it freezes the system solid if i do xfs_freeze -- i suspect the lvm userland tools want some access to /var, which is the fs i'm snapshotting). it's been working fine every night for about a month, but last night i got this oops. let me know if there's any other info which would be useful. thanks -dean ksymoops 2.4.9 on i686 2.4.30. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.30/ (default) -m /boot/System.map (specified) Access to block zero: fs: inode: 133 start_block : 1000000000000 start_off : 0 blkcnt : 0 extent-state : 190 kernel BUG at debug.c:106! invalid operand: 0000 CPU: 2 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: 0000007d ebx: 00000000 ecx: 00000002 edx: f6b51f84 esi: c0310e00 edi: c03d6300 ebp: 00000293 esp: d0b37b28 ds: 0018 es: 0018 ss: 0018 Process rdiff-backup (pid: 29874, stackpage=d0b37000) Stack: c031dd5e c030b35f c03d6300 e976a950 c0310e00 00000000 d0b37c60 c019cf37 00000000 c0310e00 e07fc7c0 00000085 00000000 00000000 00010000 00000000 00000000 00000000 00000000 00000190 00000000 00000000 c5ac0c00 c019e399 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 6a 00 7b b3 30 c0 83 c4 0c 5b 5e 5f 5d c3 89 f6 83 ec >>EIP; c01f689e <===== >>edx; f6b51f84 <_end+36746984/385d5a60> >>esi; c0310e00 >>edi; c03d6300 >>esp; d0b37b28 <_end+1072c528/385d5a60> Trace; c019cf37 Trace; c019e399 Trace; c010aca9 Trace; c010d5b8 Trace; c02bbc43 Trace; c02bd410 Trace; c023e718 Trace; c023e8d7 Trace; c01c92fa Trace; c01eaff7 Trace; c028c502 Trace; c023f484 Trace; c0144fcd Trace; c01450db Trace; c01eb246 Trace; c0145c3b Trace; c0138b7f Trace; c0130c12 Trace; c01eb210 Trace; c013135d Trace; c01315f9 Trace; c0131c00 Trace; c0131c00 Trace; c0131db7 Trace; c0131c00 Trace; c01ef9bd Trace; c029db1e <__kfree_skb+fe/160> Trace; c01ebb0d Trace; c01426d9 Trace; c0108ebb Code; c01f689e 00000000 <_EIP>: Code; c01f689e <===== 0: 0f 0b ud2a <===== Code; c01f68a0 2: 6a 00 push $0x0 Code; c01f68a2 4: 7b b3 jnp ffffffb9 <_EIP+0xffffffb9> Code; c01f68a4 6: 30 c0 xor %al,%al Code; c01f68a6 8: 83 c4 0c add $0xc,%esp Code; c01f68a9 b: 5b pop %ebx Code; c01f68aa c: 5e pop %esi Code; c01f68ab d: 5f pop %edi Code; c01f68ac e: 5d pop %ebp Code; c01f68ad f: c3 ret Code; c01f68ae 10: 89 f6 mov %esi,%esi Code; c01f68b0 12: 83 ec 00 sub $0x0,%esp From owner-linux-xfs@oss.sgi.com Wed May 11 22:10:38 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 May 2005 22:10:42 -0700 (PDT) Received: from smtp.wirelessza.co.za (smtp.wirelessza.co.za [196.15.251.88]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4C5AZOv001107 for ; Wed, 11 May 2005 22:10:37 -0700 Received: from [196.2.118.134] (helo=picturenet.co.za) by smtp.wirelessza.co.za with esmtp (Exim 4.51) id 1DW61V-0006gM-UV; Thu, 12 May 2005 07:14:14 +0200 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by picturenet.co.za (Postfix) with ESMTP id A8D191C9C; Thu, 12 May 2005 07:10:50 +0200 (SAST) From: Leon Vismer Reply-To: lvismer@picturenet.co.za To: Dave Chinner Subject: Re: XFS on 2.4 Tib raid Date: Thu, 12 May 2005 07:10:49 +0200 User-Agent: KMail/1.8 Cc: linux-xfs@oss.sgi.com, naude@mail.picturenet.co.za References: <200505092210.25667.lvismer@picturenet.co.za> <200505111357.13113.lvismer@picturenet.co.za> <20050512104002.D94938@melbourne.sgi.com> In-Reply-To: <20050512104002.D94938@melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505120710.50194.lvismer@picturenet.co.za> X-archive-position: 5204 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lvismer@picturenet.co.za Precedence: bulk X-list: linux-xfs Content-Length: 1759 Lines: 59 Hi Dave On Thursday 12 May 2005 02:40, Dave Chinner wrote: > On Wed, May 11, 2005 at 01:57:12PM +0200, Leon Vismer wrote: > > Hi Dave > > > > I did the following: > > > > # parted /dev/sdc > > parted> mklabel gpt > > parted> mkpart primary 0 2384080 > > parted> quit > > > > I saw the following in tail /var/log/messages > > > > May 11 13:37:40 mail kernel: program parted is using a deprecated SCSI > > ioctl, please convert it to SG_IO > > May 11 13:37:50 mail kernel: sym1:4:0:phase change 2-7 16@01b75f60 > > resid=10. > > > > # xfs_check /dev/sdc1 (gives the following) > > > > bad sb magic # 0xb0b25aab in ag 30 > > bad sb version # 0x9d8b in ag 30 > > bad agf magic # 0x9be1c556 in ag 30 > > bad agf version # 0xf2c55d8a in ag 30 > > bad agi magic # 0xe0467f8a in ag 30 > > bad agi version # 0xb4f92355 in ag 30 > > ..... > > Looks like binary file data in AG 30 and 31. Given that mkfs > probably gave you 32 AGs in your filesystem, these 2 AGs are the > only ones that lie totally above the 2TiB filesystem offset. > > From this, I'm almost certain that accesses to blocks > 2TiB are > wrapping back to block zero. Can you rebuild a kernel yourself > so we are certain that it is built with CONFIG_LBD=y? > I will do this, > Hmmm - just a random though - the SCSI protocol is limited to > addressing 2^32 sectors, which is 2TiB on a 512 byte sector > size device. You're trying to address a 2.4TiB SCSI device - > what sector size is your RAID controller using? If you > set it to 1k or 2k and use the mkfs option "-s size=xxxx" > do you see this same problem? > I tried mkfs.xfs -s size=1024 -f /dev/sdc1 and xfs_check returned the same info. I also tries size=2048 and size=4096, both with the same results Thanks -- Leon > Cheers, > > Dave. From owner-linux-xfs@oss.sgi.com Thu May 12 00:43:19 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 May 2005 00:43:25 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4C7hEOv011690 for ; Thu, 12 May 2005 00:43:19 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1DW8LE-0003AT-1z; Thu, 12 May 2005 08:42:44 +0100 Date: Thu, 12 May 2005 08:42:44 +0100 From: Christoph Hellwig To: Dave Chinner Cc: Leon Vismer , linux-xfs@oss.sgi.com, naude@mail.picturenet.co.za Subject: Re: XFS on 2.4 Tib raid Message-ID: <20050512074243.GA12161@infradead.org> References: <200505092210.25667.lvismer@picturenet.co.za> <1115712231.42806ae75b4d1@picturenet.co.za> <20050511084450.A91712@melbourne.sgi.com> <200505111357.13113.lvismer@picturenet.co.za> <20050512104002.D94938@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050512104002.D94938@melbourne.sgi.com> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 5205 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 218 Lines: 6 On Thu, May 12, 2005 at 10:40:02AM +1000, Dave Chinner wrote: > Hmmm - just a random though - the SCSI protocol is limited to > addressing 2^32 sectors, Not true anymore when using 16byte DCBs, which Linux 2.6 does. From owner-linux-xfs@oss.sgi.com Thu May 12 06:16:22 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 May 2005 06:16:39 -0700 (PDT) Received: from cirse.extra.cea.fr (cirse.extra.cea.fr [132.166.172.102]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4CDGGOv003194 for ; Thu, 12 May 2005 06:16:21 -0700 Received: from argiope.saclay.cea.fr (argiope.saclay.cea.fr [132.166.192.108]) by cirse.extra.cea.fr (8.12.10/8.12.10/CEAnet-Internet.4.0) with ESMTP id j4CDFnAN008670 for ; Thu, 12 May 2005 15:15:49 +0200 (MEST) Received: from pisaure.intra.cea.fr (unverified) by argiope.saclay.cea.fr (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Thu, 12 May 2005 15:15:49 +0200 Received: from nenuphar.saclay.cea.fr (nenuphar.saclay.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.12.11/8.12.11) with ESMTP id j4CDDuEH025777; Thu, 12 May 2005 15:13:57 +0200 (envelope-from degremont@ocre.cea.fr) Received: from ocre.cea.fr ([132.165.65.70]) by nenuphar.saclay.cea.fr (8.12.10/8.12.10/CEAnet-internes.4.0) with ESMTP id j4CDFlZa001635; Thu, 12 May 2005 15:15:48 +0200 (MEST) Message-ID: <42835703.90300@ocre.cea.fr> Date: Thu, 12 May 2005 15:15:47 +0200 From: Aurelien Degremont - Stagiaire User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us MIME-Version: 1.0 To: Dean Roehrich CC: linux-xfs@oss.sgi.com Subject: Re: [DMAPI] code error in dm_ip_to_handle() References: <20050511204538.831CA4FE8A@chewtoy.americas.sgi.com> In-Reply-To: <20050511204538.831CA4FE8A@chewtoy.americas.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 5206 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: degremont@ocre.cea.fr Precedence: bulk X-list: linux-xfs Content-Length: 2303 Lines: 45 Dean Roehrich a écrit: > Maybe we should throw out struct dm_fsfid and just use struct dm_fid? Then > XFS, for example, would have to translate its fid_t into a struct dm_fid on > its own and DMAPI shouldn't have to guess about how they match up. I > wonder how that would work? We must wondered what are the purpose of each structure ? - dm_fsfid : Just a **opaque** buffer. The FS is responsible for what it put there. But with this structure, DMAPI **could not know the meaning of the buffer content**. It must use it as it is. It is just an ID it will deal with using fh_to_inode(), mainly. - dm_fid : An file identifier using VFS information : its inode and a generation number. The content of the ID is known and so DMAPI could use this ino and gen number if needed. (What's the purpose of the dm_fid_len and dm_fid_pad field ? Something about alignment or data size ? Maybe we could get rid of them ?) The question is : Does DMAPI need the inode number of the filehandles ? After some searches it seems this data is only used in dmapi_session.c, when dealing with hash_event. I don't know the purpose of them. But concerning repeated_event(), it looks like the inode number is only used in order to compare 2 handles. I think, this comparison must be done using the whole structure (memcmp) or at least using the ino AND the gen number. The ino number is not enough. So, if the inode number is used somewhere in DMAPI, the filehandle must contain the inode number or the FS must provided a way to fetch the inode number from the filehandle. I think the first way is easier. So it seems we could indeed replace the dm_fsfid by dm_fid. So the FS will just set the inode number and the gen number ? Are the len useless ? I think so. So, if we use this solution, do we really need a specific function in the fs-side ? This information could be automatically gathered from the VFS layer in the DMAPI call like dm_ip_to_handle(). If we choose the solution where the structure has an 'ino' field, the FS must set the ino inside, I don't want that the FS could set whatever it wants in dm_fid. So : - Replace the dm_fsfid by dm_fid : Yes - Remove the useless field of this structure - Automatically fill it in DMAPI. Remove the corresponding dmapiops. Aurelien From owner-linux-xfs@oss.sgi.com Thu May 12 06:45:34 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 May 2005 06:45:45 -0700 (PDT) Received: from web30505.mail.mud.yahoo.com (web30505.mail.mud.yahoo.com [68.142.200.118]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4CDjYOv004779 for ; Thu, 12 May 2005 06:45:34 -0700 Received: (qmail 46575 invoked by uid 60001); 12 May 2005 13:45:07 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=6T8VDgGieHwBBC9PPj0mFl3cpmJlTF3T6xPdPv2DG/77HY+QclgCzK2OrUOezxGZZ20roY0hlSR/AgxEcqAhZ/mS3HsqfpyW98vmhowAXMfdw9sE3Rw1izh9jYxtqbkCW0PWLdMPdtli7c/Tx+C28sKX6DbvoaUdtDTscB2k1mg= ; Message-ID: <20050512134507.46573.qmail@web30505.mail.mud.yahoo.com> Received: from [63.194.112.130] by web30505.mail.mud.yahoo.com via HTTP; Thu, 12 May 2005 06:45:07 PDT Date: Thu, 12 May 2005 06:45:07 -0700 (PDT) From: Tim Harvey Subject: SATA RAID5 XFS LVM kernel hang on 2.6.11-1.14_FC3 To: linux-xfs@oss.sgi.com, linux-lvm@redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 5207 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tim_harvey@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 2910 Lines: 73 Greetings, I'm attempting to run a XFS on LVM over RAID5 array with the following configuration: ASUS TUSI-M Motherboard, Celeron 1GHz, 256MB SDRAM Promise SATAII-150-TX4 4-port RAID controller 4 x Seagate ST300 300GB SATA NQC drives Linux FC3 system with 2.6.11-1.14_FC3 I've been trying to determine the cause of a kernel hang that occurs when I start to transfer a large ammount of data to the array over an NFS/SMB mount. After anywhere from hours to a few seconds large transfers, the console starts spewing endlessly the following: do_IRQ: stack overflow: 312 [] do_IRQ+0x83/0x85 [] common_interrupt+0x1a/0x20 [] cfq_set_request+0x1b2/0x4fd [] autoremove_wake_function+0x0/0x37 [] cfq_set_request+0x0/0x4fd [] elv_set_request+0x20/0x23 [] get_request+0x21a/0x56e [] __make_request+0x15b/0x629 [] generic_make_request+0x19e/0x279 [] autoremove_wake_function+0x0/0x37 [] autoremove_wake_function+0x0/0x37 [] handle_stripe+0xf7e/0x16a3 [raid5] [] raid5_build_block+0x65/0x70 [raid5] [] get_active_stripe+0x29e/0x560 [raid5] [] make_request+0x349/0x539 [raid5] [] autoremove_wake_function+0x0/0x37 [] mempool_alloc+0x72/0x2a9 [] autoremove_wake_function+0x0/0x37 [] generic_make_request+0x19e/0x279 [] autoremove_wake_function+0x0/0x37 [] autoremove_wake_function+0x0/0x37 [] bio_clone+0xa1/0xa6 [] __map_bio+0x30/0xc8 [dm_mod] [] __clone_and_map+0xcd/0x309 [dm_mod] [] __split_bio+0x9d/0x10b [dm_mod] [] dm_request+0x5f/0x88 [dm_mod] [] generic_make_request+0x19e/0x279 [] autoremove_wake_function+0x0/0x37 [] autoremove_wake_function+0x0/0x37 [] prep_new_page+0x5c/0x5f [] autoremove_wake_function+0x0/0x37 [] submit_bio+0x4b/0xc5 [] autoremove_wake_function+0x0/0x37 [] bio_add_page+0x29/0x2f [] _pagebuf_ioapply+0x164/0x2d9 [xfs] [] pagebuf_iorequest+0x33/0x14a [xfs] [] _pagebuf_find+0xd9/0x2f3 [xfs] [] _pagebuf_map_pages+0x64/0x84 [xfs] [] xfs_buf_get_flags+0xc4/0x108 [xfs] [] pagebuf_iostart+0x53/0x8c [xfs] [] xfs_buf_read_flags+0x4f/0x6c [xfs] [] xfs_trans_read_buf+0x1b9/0x31b [xfs] ... I would like ot give a more detailed report, but I'm not really sure what to do next. It would seem that something in RAID5 code is recursing endlessly? I'm not quite sure how to proceed as I'm not getting an oops and the system is non responsive (other than spewing the endless stack dump) Someone on the linux-raid list thought there is/was an issue with XFS and 4K stacks... is this true? Any help would be greatly appreciated, Tim From owner-linux-xfs@oss.sgi.com Thu May 12 08:37:40 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 May 2005 08:37:54 -0700 (PDT) Received: from dmzraw2.extranet.tce.com (dmzraw2.extranet.tce.com [157.254.234.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4CFbdOv013366 for ; Thu, 12 May 2005 08:37:40 -0700 Received: from smtprelay.indy.tce.com (ismtprelay.indy.tce.com [157.254.96.114]) by dmzraw2.extranet.tce.com (8.12.5/8.12.5) with ESMTP id j4CFb1eB014961; Thu, 12 May 2005 15:37:06 GMT Received: from boulsmailbh01.eu.thmulti.com (localhost [127.0.0.1]) by smtprelay.indy.tce.com (8.9.3/8.9.1) with ESMTP id PAA06026; Thu, 12 May 2005 15:37:00 GMT Received: from wdtssmail01.eu.thmulti.com ([141.11.216.71]) by boulsmailbh01.eu.thmulti.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 12 May 2005 17:36:43 +0200 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: Every new file goes into a new ag Date: Thu, 12 May 2005 17:36:41 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Every new file goes into a new ag Thread-Index: AcVWR+q+IgEtQ2plRNaPC35ROzEYDgAv8Ebw From: "Bub Thomas" To: "Eric Sandeen" Cc: , "Braehler Uwe" , "Lindenkreuz Morris" , "Waldschmidt Stefan" X-OriginalArrivalTime: 12 May 2005 15:36:43.0910 (UTC) FILETIME=[6663D260:01C55708] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j4CFbeOv013368 X-archive-position: 5208 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: thomas.bub@thomson.net Precedence: bulk X-list: linux-xfs Content-Length: 1246 Lines: 41 Eric, the tip with the inode size helped in getting the files contiguous on disk. However the performance of the filesystem 250 MByte/sec is much worth compared to the raw lvm volume which is 400 MByte/sec. A local ADIC cvfs filesystem delivers 375 MByte/sec on the same disks. I'm trying to get you and David Chatterton into a new thread discussing this soon, see one of my following mails. Thanks so far. Thomas -----Original Message----- From: Eric Sandeen [mailto:sandeen@sgi.com] Sent: Wednesday, May 11, 2005 6:39 PM To: Bub Thomas Cc: linux-xfs@oss.sgi.com; Braehler Uwe; Lindenkreuz Morris; Waldschmidt Stefan Subject: Re: Every new file goes into a new ag Bub Thomas wrote: > Eric, > I can't find any rotorstep within my xfs kernel codebase. Any idea how I > can get this in? Depends on where you got your xfs code, I guess - I think it should be in cvs at least. > I'm running on a 32 bit machine that's why I can't use idnode64 right? > My machine currently shows me isize=256. > Am I right that mkfs -t xfs -i size=512 would double the inode size? That's right - doubling the size of the inode will double the size of the fs that can keep inodes under 32 bits. -Eric > I'll give this a try tomorrow then. > Thanks > Thomas From owner-linux-xfs@oss.sgi.com Thu May 12 09:13:43 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 May 2005 09:13:48 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4CGDgOv015085 for ; Thu, 12 May 2005 09:13:42 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4CHv06Y010950 for ; Thu, 12 May 2005 10:57:00 -0700 Received: from chewtoy.americas.sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4CGCDR07943359; Thu, 12 May 2005 11:12:14 -0500 (CDT) Received: from chewtoy (localhost [127.0.0.1]) by chewtoy.americas.sgi.com (Postfix) with ESMTP id 29B464FE8A; Thu, 12 May 2005 11:12:13 -0500 (CDT) To: Aurelien Degremont - Stagiaire Cc: linux-xfs@oss.sgi.com Subject: Re: [DMAPI] code error in dm_ip_to_handle() Date: Thu, 12 May 2005 11:12:12 -0500 From: Dean Roehrich Message-Id: <20050512161213.29B464FE8A@chewtoy.americas.sgi.com> X-archive-position: 5209 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2657 Lines: 54 >From: Aurelien Degremont - Stagiaire >Dean Roehrich a écrit: >> Maybe we should throw out struct dm_fsfid and just use struct dm_fid? Then >> XFS, for example, would have to translate its fid_t into a struct dm_fid on >> its own and DMAPI shouldn't have to guess about how they match up. I >> wonder how that would work? > >We must wondered what are the purpose of each structure ? > - dm_fsfid : Just a **opaque** buffer. The FS is responsible for what >it put there. But with this structure, DMAPI **could not know the >meaning of the buffer content**. It must use it as it is. It is just an >ID it will deal with using fh_to_inode(), mainly. > - dm_fid : An file identifier using VFS information : its inode and a >generation number. The content of the ID is known and so DMAPI could use > this ino and gen number if needed. >(What's the purpose of the dm_fid_len and dm_fid_pad field ? Something >about alignment or data size ? Maybe we could get rid of them ?) The dm_fid_len field is used to distinguish between filesystem handles and file handles. That has to stay in place. >The question is : Does DMAPI need the inode number of the filehandles ? >After some searches it seems this data is only used in dmapi_session.c, >when dealing with hash_event. I don't know the purpose of them. But >concerning repeated_event(), it looks like the inode number is only used >in order to compare 2 handles. I think, this comparison must be done >using the whole structure (memcmp) or at least using the ino AND the gen > number. The ino number is not enough. I could agree to that, but what do we give to the hash function? >So, if the inode number is used somewhere in DMAPI, the filehandle must >contain the inode number or the FS must provided a way to fetch the >inode number from the filehandle. I think the first way is easier. So it >seems we could indeed replace the dm_fsfid by dm_fid. So the FS will >just set the inode number and the gen number ? Are the len useless ? I >think so. So, if we use this solution, do we really need a specific >function in the fs-side ? This information could be automatically >gathered from the VFS layer in the DMAPI call like dm_ip_to_handle(). >If we choose the solution where the structure has an 'ino' field, the FS >must set the ino inside, I don't want that the FS could set whatever it >wants in dm_fid. It is the FS which must convert between handles and filesystem objects, so the handle better make sense to the FS. Whenever DMAPI needs this conversion, it should call to the FS. So, no, DMAPI should not control the 'dm_fid_ino' field. Dean From owner-linux-xfs@oss.sgi.com Thu May 12 09:21:46 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 May 2005 09:21:51 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4CGLhOv016086 for ; Thu, 12 May 2005 09:21:44 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4CI514m012626 for ; Thu, 12 May 2005 11:05:02 -0700 Received: from chewtoy.americas.sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4CGLGR07944918; Thu, 12 May 2005 11:21:16 -0500 (CDT) Received: from chewtoy (localhost [127.0.0.1]) by chewtoy.americas.sgi.com (Postfix) with ESMTP id DC1514FE8A; Thu, 12 May 2005 11:21:15 -0500 (CDT) To: Aurelien Degremont - Stagiaire Cc: linux-xfs@oss.sgi.com Subject: Re: vfs_altfsid & dm_fsid Date: Thu, 12 May 2005 11:21:15 -0500 From: Dean Roehrich Message-Id: <20050512162115.DC1514FE8A@chewtoy.americas.sgi.com> X-archive-position: 5210 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 20895 Lines: 719 >From: Aurelien Degremont - Stagiaire >Dean Roehrich a écrit: >> If your filesystem of choice doesn't have an fsid, then you could just >> generate one that is valid while the filesystem is mounted and is not writte >n >> to the filesystem, or you could come up with something else. Whatever you >> choose for an fsid should fit into a 64-bit type. > > >> 1) The fsid should be a parameter to dm_send_mount_event() and >> dm_send_namesp_event() and dm_send_unmount_event(). >> The get_fsid op in struct filesystem_dmapi_operations should be >> dropped. > >Ok, so we need to modify : > xfs_dm_mount() > xfs_dm_send_namesp_event() > xfs_dm_send_unmount_event() > >The fsid could be taken in vfsp. My last attempt to send this as an attachment didn't work... so you'll have to take it this way. This is lightly tested. Dean Index: lbs-a/linux/linux/fs/xfs/xfs_dmapi.c =================================================================== --- lbs-a.orig/linux/linux/fs/xfs/xfs_dmapi.c 2005-05-11 19:39:34.000000000 -0700 +++ lbs-a/linux/linux/fs/xfs/xfs_dmapi.c 2005-05-11 20:06:21.000000000 -0700 @@ -209,7 +209,8 @@ xfs_dm_send_data_event( #endif error = dm_send_data_event(event, inode, DM_RIGHT_NULL, - offset, length, flags); + offset, length, flags, + (dm_fsid_t*)vp->v_vfsp->vfs_altfsid); error = -error; /* DMAPI returns negative errors */ if (flags & DM_FLAGS_ISEM) @@ -3124,7 +3125,8 @@ xfs_dm_send_destroy_event( /* Returns positive errors to XFS */ - error = dm_send_destroy_event(LINVFS_GET_IP(vp), vp_right); + error = dm_send_destroy_event(LINVFS_GET_IP(vp), vp_right, + (dm_fsid_t*)vp->v_vfsp->vfs_altfsid); error = -error; /* DMAPI returns negative errors */ return error; /* Return positive error to XFS */ @@ -3153,7 +3155,8 @@ xfs_dm_send_namesp_event( LINVFS_GET_IP(vp1), vp1_right, vp2 ? LINVFS_GET_IP(vp2) : NULL, vp2_right, name1, name2, - mode, retcode, flags); + mode, retcode, flags, + (dm_fsid_t*)vp1->v_vfsp->vfs_altfsid); error = -error; /* DMAPI returns negative errors */ return error; /* Return positive error to XFS */ @@ -3170,7 +3173,8 @@ xfs_dm_send_unmount_event( int flags) { dm_send_unmount_event(vfsp->vfs_super, vp ? LINVFS_GET_IP(vp) : NULL, - vfsp_right, mode, retcode, flags); + vfsp_right, mode, retcode, flags, + (dm_fsid_t*)vfsp->vfs_altfsid); } @@ -3244,16 +3248,6 @@ xfs_dm_get_dmapiops( return -error; /* Return negative error to DMAPI */ } -static void -xfs_dm_get_fsid( - struct super_block *sb, - dm_fsid_t *fsid) -{ - vfs_t *vfsp = LINVFS_GET_VFS(sb); - memcpy(fsid, vfsp->vfs_altfsid, sizeof(*fsid)); -} - - /* * Filesystem operations accessed by the DMAPI core. */ @@ -3262,7 +3256,6 @@ struct filesystem_dmapi_operations xfs_d .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, }; /* @@ -3312,7 +3305,8 @@ xfs_dm_mount( DM_RIGHT_NULL, NULL, DM_RIGHT_NULL, LINVFS_GET_IP(rootvp), DM_RIGHT_NULL, - args->mtpt, args->fsname); + args->mtpt, args->fsname, + (dm_fsid_t*)vfsp->vfs_altfsid); error = -error; /* DMAPI returns negative errs */ } } Index: lbs-a/linux/linux/fs/dmapi/dmapi_session.c =================================================================== --- lbs-a.orig/linux/linux/fs/dmapi/dmapi_session.c 2005-05-11 19:39:18.000000000 -0700 +++ lbs-a/linux/linux/fs/dmapi/dmapi_session.c 2005-05-11 19:39:51.000000000 -0700 @@ -1395,7 +1395,7 @@ dm_enqueue( int dm_enqueue_normal_event( - struct super_block *sb, + dm_fsid_t *fsid, dm_tokevent_t *tevp, int flags) { @@ -1440,7 +1440,7 @@ dm_enqueue_normal_event( is locked upon return from dm_waitfor_disp_session(). */ - if ((error = dm_waitfor_disp_session(sb, tevp, &s, &lc)) != 0) + if ((error = dm_waitfor_disp_session(fsid, tevp, &s, &lc)) != 0) return(error); return(dm_enqueue(s, lc, tevp, sync, flags, 0)); @@ -1466,7 +1466,8 @@ dm_enqueue_normal_event( int dm_enqueue_mount_event( struct super_block *sb, - dm_tokevent_t *tevp) + dm_tokevent_t *tevp, + dm_fsid_t *fsid) { dm_session_t *s; dm_sessid_t sid; @@ -1475,7 +1476,7 @@ dm_enqueue_mount_event( /* Make the mounting filesystem visible to other DMAPI calls. */ - if ((error = dm_add_fsys_entry(sb, tevp)) != 0){ + if ((error = dm_add_fsys_entry(sb, tevp, fsid)) != 0){ return(error); } @@ -1506,10 +1507,10 @@ dm_enqueue_mount_event( */ if (error >= 0) { - dm_change_fsys_entry(sb, DM_STATE_MOUNTED); + dm_change_fsys_entry(fsid, DM_STATE_MOUNTED); error = 0; } else { - dm_remove_fsys_entry(sb); + dm_remove_fsys_entry(fsid); } return(error); } @@ -1657,7 +1658,7 @@ dm_flush_events( */ int dm_release_threads( - struct super_block *sb, + dm_fsid_t *fsid, struct inode *inode, /* may be null */ int errno) { @@ -1668,14 +1669,8 @@ dm_release_threads( dm_sessid_t *sidlist; int i; int found_events = 0; - dm_fsid_t fsid; - struct filesystem_dmapi_operations *dops; - ASSERT(sb); - dops = dm_fsys_ops_by_fstype(sb->s_type); - ASSERT(dops); - dops->get_fsid(sb, &fsid); - dm_release_disp_threads(&fsid, inode, errno); + dm_release_disp_threads(fsid, inode, errno); /* Loop until we can get the right amount of temp space, being careful not to hold a mutex during the allocation. Usually only one trip. @@ -1708,14 +1703,14 @@ dm_release_threads( for (i = 0; i < sesscnt; i++) { sid = sidlist[i]; if( dm_find_session_and_lock( sid, &s, &lc ) == 0 ){ - found_events = dm_flush_events( s, &fsid, inode, + found_events = dm_flush_events( s, fsid, inode, &s->sn_evt_writerq, 1, errno ); if (found_events) sv_broadcast(&s->sn_writerq); - dm_flush_events(s, &fsid, inode, &s->sn_newq, 0, errno); - dm_flush_events(s, &fsid, inode, &s->sn_delq, 0, errno); + dm_flush_events(s, fsid, inode, &s->sn_newq, 0, errno); + dm_flush_events(s, fsid, inode, &s->sn_delq, 0, errno); mutex_spinunlock( &s->sn_qlock, lc ); } Index: lbs-a/linux/linux/fs/dmapi/dmapi_private.h =================================================================== --- lbs-a.orig/linux/linux/fs/dmapi/dmapi_private.h 2005-05-11 19:39:18.000000000 -0700 +++ lbs-a/linux/linux/fs/dmapi/dmapi_private.h 2005-05-11 19:39:51.000000000 -0700 @@ -344,13 +344,14 @@ void dm_evt_rele_tevp( int droprights); int dm_enqueue_normal_event( - struct super_block *sbp, + dm_fsid_t *fsid, dm_tokevent_t *tevp, int flags); int dm_enqueue_mount_event( struct super_block *sbp, - dm_tokevent_t *tevp); + dm_tokevent_t *tevp, + dm_fsid_t *fsid); int dm_enqueue_sendmsg_event( dm_sessid_t targetsid, @@ -439,7 +440,7 @@ int dm_get_allocinfo_rvp( int *rvp); int dm_waitfor_destroy_attrname( - struct super_block *sb, + dm_fsid_t *fsid, dm_attrname_t *attrnamep); void dm_clear_fsreg( @@ -447,14 +448,15 @@ void dm_clear_fsreg( int dm_add_fsys_entry( struct super_block *sb, - dm_tokevent_t *tevp); + dm_tokevent_t *tevp, + dm_fsid_t *fsid); void dm_change_fsys_entry( - struct super_block *sb, + dm_fsid_t *fsid, dm_fsstate_t newstate); void dm_remove_fsys_entry( - struct super_block *sb); + dm_fsid_t *fsid); dm_fsys_vector_t *dm_fsys_vector( struct inode *ip); @@ -465,7 +467,7 @@ struct filesystem_dmapi_operations *dm_f void dm_fsys_vector_free(void); int dm_waitfor_disp_session( - struct super_block *sb, + dm_fsid_t *fsid, dm_tokevent_t *tevp, dm_session_t **sessionpp, unsigned long *lcp); Index: lbs-a/linux/linux/fs/dmapi/dmapi_register.c =================================================================== --- lbs-a.orig/linux/linux/fs/dmapi/dmapi_register.c 2005-05-11 19:39:18.000000000 -0700 +++ lbs-a/linux/linux/fs/dmapi/dmapi_register.c 2005-05-11 19:39:51.000000000 -0700 @@ -201,18 +201,13 @@ dm_find_fsreg_and_lock( int dm_add_fsys_entry( struct super_block *sb, - dm_tokevent_t *tevp) + dm_tokevent_t *tevp, + dm_fsid_t *fsid) { dm_fsreg_t *fsrp; int msgsize; void *msg; unsigned long lc; /* lock cookie */ - dm_fsid_t fsid; - struct filesystem_dmapi_operations *dops; - - dops = dm_fsys_ops_by_fstype(sb->s_type); - ASSERT(dops); - dops->get_fsid(sb, &fsid); /* Allocate and initialize a dm_fsreg_t structure for the filesystem. */ @@ -234,7 +229,7 @@ dm_add_fsys_entry( fsrp->fr_sb = sb; fsrp->fr_tevp = tevp; - memcpy(&fsrp->fr_fsid, &fsid, sizeof(fsid)); + memcpy(&fsrp->fr_fsid, fsid, sizeof(*fsid)); fsrp->fr_msg = msg; fsrp->fr_msgsize = msgsize; fsrp->fr_state = DM_STATE_MOUNTING; @@ -248,7 +243,7 @@ dm_add_fsys_entry( lc = mutex_spinlock(&dm_reg_lock); - if (!dm_find_fsreg(&fsid)) { + if (!dm_find_fsreg(fsid)) { fsrp->fr_next = dm_registers; dm_registers = fsrp; dm_fsys_cnt++; @@ -292,26 +287,16 @@ dm_add_fsys_entry( void dm_change_fsys_entry( - struct super_block *sb, + dm_fsid_t *fsid, dm_fsstate_t newstate) { dm_fsreg_t *fsrp; int seq_error; unsigned long lc; /* lock cookie */ - dm_fsid_t fsid; - struct filesystem_dmapi_operations *dops; - /* Find the filesystem referenced by the sb's fsid_t. This should - always succeed. - */ - - dops = dm_fsys_ops_by_fstype(sb->s_type); - ASSERT(dops); - dops->get_fsid(sb, &fsid); - - if ((fsrp = dm_find_fsreg_and_lock(&fsid, &lc)) == NULL) { + if ((fsrp = dm_find_fsreg_and_lock(fsid, &lc)) == NULL) { panic("dm_change_fsys_entry: can't find DMAPI fsrp for " - "sb %p\n", sb); + "fsid 0x%llx\n", (unsigned long long)*fsid); } /* Make sure that the new state is acceptable given the current state @@ -390,17 +375,11 @@ dm_change_fsys_entry( void dm_remove_fsys_entry( - struct super_block *sb) + dm_fsid_t *fsid) { dm_fsreg_t **fsrpp; dm_fsreg_t *fsrp; unsigned long lc; /* lock cookie */ - struct filesystem_dmapi_operations *dops; - dm_fsid_t fsid; - - dops = dm_fsys_ops_by_fstype(sb->s_type); - ASSERT(dops); - dops->get_fsid(sb, &fsid); /* Find the filesystem referenced by the sb's fsid_t and dequeue it after verifying that the fr_state shows a filesystem that is @@ -411,14 +390,14 @@ dm_remove_fsys_entry( fsrpp = &dm_registers; while ((fsrp = *fsrpp) != NULL) { - if (!memcmp(&fsrp->fr_fsid, &fsid, sizeof(fsrp->fr_fsid))) + if (!memcmp(&fsrp->fr_fsid, fsid, sizeof(fsrp->fr_fsid))) break; fsrpp = &fsrp->fr_next; } if (fsrp == NULL) { mutex_spinunlock(&dm_reg_lock, lc); panic("dm_remove_fsys_entry: can't find DMAPI fsrp for " - "sb %p\n", sb); + "fsid 0x%llx\n", (unsigned long long)fsid); } nested_spinlock(&fsrp->fr_lock); @@ -673,7 +652,7 @@ dm_find_mount_tevp_and_lock( static int dm_waitfor_disp( - struct super_block *sb, + dm_fsid_t *fsid, dm_tokevent_t *tevp, dm_fsreg_t **fsrpp, unsigned long *lc1p, /* addr of first returned lock cookie */ @@ -683,14 +662,8 @@ dm_waitfor_disp( dm_eventtype_t event = tevp->te_msg.ev_type; dm_session_t *s; dm_fsreg_t *fsrp; - dm_fsid_t fsid; - struct filesystem_dmapi_operations *dops; - - dops = dm_fsys_ops_by_fstype(sb->s_type); - ASSERT(dops); - dops->get_fsid(sb, &fsid); - if ((fsrp = dm_find_fsreg_and_lock(&fsid, lc1p)) == NULL) + if ((fsrp = dm_find_fsreg_and_lock(fsid, lc1p)) == NULL) return -ENOENT; /* If no session is registered for this event in the specified @@ -760,7 +733,7 @@ dm_waitfor_disp( int dm_waitfor_disp_session( - struct super_block *sb, + dm_fsid_t *fsid, dm_tokevent_t *tevp, dm_session_t **sessionpp, unsigned long *lcp) @@ -772,7 +745,7 @@ dm_waitfor_disp_session( if (tevp->te_msg.ev_type < 0 || tevp->te_msg.ev_type > DM_EVENT_MAX) return(-EIO); - error = dm_waitfor_disp(sb, tevp, &fsrp, lcp, sessionpp, &lc2); + error = dm_waitfor_disp(fsid, tevp, &fsrp, lcp, sessionpp, &lc2); if (!error) mutex_spinunlock(&fsrp->fr_lock, lc2); /* rev. cookie order*/ return(error); @@ -787,7 +760,7 @@ dm_waitfor_disp_session( int dm_waitfor_destroy_attrname( - struct super_block *sbp, + dm_fsid_t *fsid, dm_attrname_t *attrnamep) { dm_tokevent_t *tevp; @@ -799,7 +772,7 @@ dm_waitfor_destroy_attrname( void *msgp; tevp = dm_evt_create_tevp(DM_EVENT_DESTROY, 1, (void**)&msgp); - error = dm_waitfor_disp(sbp, tevp, &fsrp, &lc1, &s, &lc2); + error = dm_waitfor_disp(fsid, tevp, &fsrp, &lc1, &s, &lc2); if (!error) { *attrnamep = fsrp->fr_rattr; /* attribute or zeros */ mutex_spinunlock(&s->sn_qlock, lc2); /* rev. cookie order */ Index: lbs-a/linux/linux/fs/dmapi/dmapi_kern.h =================================================================== --- lbs-a.orig/linux/linux/fs/dmapi/dmapi_kern.h 2005-05-11 19:39:18.000000000 -0700 +++ lbs-a/linux/linux/fs/dmapi/dmapi_kern.h 2005-05-11 20:06:46.000000000 -0700 @@ -82,7 +82,6 @@ struct filesystem_dmapi_operations { struct file_operations * (*get_invis_ops)(struct inode *ip); int (*inode_to_fh)(struct inode *ip, struct dm_fsfid *fid, dm_fsid_t *fsid ); - void (*get_fsid)(struct super_block *sb, dm_fsid_t *fsid); #define HAVE_DM_QUEUE_FLUSH int (*flushing)(struct inode *ip); }; @@ -96,11 +95,13 @@ int dm_send_data_event( dm_right_t vp_right, dm_off_t off, size_t len, - int flags); + int flags, + dm_fsid_t *fsid); int dm_send_destroy_event( struct inode *ip, - dm_right_t vp_right); + dm_right_t vp_right, + dm_fsid_t *fsid); int dm_send_mount_event( struct super_block *sb, @@ -110,7 +111,8 @@ int dm_send_mount_event( struct inode *rootip, dm_right_t rootvp_right, char *name1, - char *name2); + char *name2, + dm_fsid_t *fsid); int dm_send_namesp_event( dm_eventtype_t event, @@ -123,7 +125,8 @@ int dm_send_namesp_event( char *name2, mode_t mode, int retcode, - int flags); + int flags, + dm_fsid_t *fsid); void dm_send_unmount_event( struct super_block *sbp, @@ -131,7 +134,8 @@ void dm_send_unmount_event( dm_right_t sbp_right, mode_t mode, int retcode, - int flags); + int flags, + dm_fsid_t *fsid); int dm_code_level(void); @@ -141,7 +145,7 @@ int dm_ip_to_handle ( #define HAVE_DM_RELEASE_THREADS_ERRNO int dm_release_threads( - struct super_block *sb, + dm_fsid_t *fsid, struct inode *inode, int errno); Index: lbs-a/linux/linux/fs/dmapi/dmapi_event.c =================================================================== --- lbs-a.orig/linux/linux/fs/dmapi/dmapi_event.c 2005-05-11 19:39:18.000000000 -0700 +++ lbs-a/linux/linux/fs/dmapi/dmapi_event.c 2005-05-11 19:39:51.000000000 -0700 @@ -196,15 +196,10 @@ static dm_tokdata_t * dm_sb_data( struct super_block *sb, struct inode *ip, /* will be NULL for DM_EVENT_UNMOUNT */ - dm_right_t right) + dm_right_t right, + dm_fsid_t *fsid) { dm_tokdata_t *tdp; - struct filesystem_dmapi_operations *dops; - dm_fsid_t fsid; - - dops = dm_fsys_ops_by_fstype(sb->s_type); - ASSERT(dops); - dops->get_fsid(sb, &fsid); tdp = kmem_cache_alloc(dm_tokdata_cachep, SLAB_KERNEL); if (tdp == NULL) { @@ -225,9 +220,9 @@ dm_sb_data( tdp->td_ip = ip; tdp->td_vcount = 0; - memcpy(&tdp->td_handle.ha_fsid, &fsid, sizeof(fsid)); - memset((char *)&tdp->td_handle.ha_fsid + sizeof(fsid), 0, - sizeof(tdp->td_handle) - sizeof(fsid)); + memcpy(&tdp->td_handle.ha_fsid, fsid, sizeof(*fsid)); + memset((char *)&tdp->td_handle.ha_fsid + sizeof(*fsid), 0, + sizeof(tdp->td_handle) - sizeof(*fsid)); return(tdp); } @@ -258,7 +253,8 @@ dm_send_data_event( dm_right_t vp_right, /* current right for ip */ dm_off_t offset, size_t length, - int flags) /* 0 or DM_FLAGS_NDELAY */ + int flags, /* 0 or DM_FLAGS_NDELAY */ + dm_fsid_t *fsid) { dm_data_event_t *datap; dm_tokevent_t *tevp; @@ -291,7 +287,7 @@ dm_send_data_event( /* Queue the message and wait for the reply. */ - error = dm_enqueue_normal_event(ip->i_sb, tevp, flags); + error = dm_enqueue_normal_event(fsid, tevp, flags); /* If no errors occurred, we must leave with the same rights we had upon entry. If errors occurred, we must leave with no rights. @@ -314,7 +310,8 @@ dm_send_data_event( int dm_send_destroy_event( struct inode *ip, - dm_right_t vp_right) /* always DM_RIGHT_NULL */ + dm_right_t vp_right, /* always DM_RIGHT_NULL */ + dm_fsid_t *fsid) { dm_fsys_vector_t *fsys_vector; dm_tokevent_t *tevp; @@ -329,7 +326,7 @@ dm_send_destroy_event( if (tdp == NULL) return -ENOMEM; - if ((error = dm_waitfor_destroy_attrname(ip->i_sb, &attrname)) != 0) + if ((error = dm_waitfor_destroy_attrname(fsid, &attrname)) != 0) return(error); /* If a return-on-destroy attribute name exists for this filesystem, @@ -384,7 +381,7 @@ dm_send_destroy_event( /* Queue the message asynchronously. */ - error = dm_enqueue_normal_event(ip->i_sb, tevp, 0); + error = dm_enqueue_normal_event(fsid, tevp, 0); /* Since we had no rights upon entry, we have none to reobtain before leaving. @@ -410,7 +407,8 @@ dm_send_mount_event( struct inode *rootip, dm_right_t rootvp_right, char *name1, /* mount path */ - char *name2) /* filesystem device name */ + char *name2, /* filesystem device name */ + dm_fsid_t *fsid) { int error; dm_tokevent_t *tevp = NULL; @@ -425,7 +423,7 @@ dm_send_mount_event( if it is a different filesystem type which does not support DMAPI. */ - tdp1 = dm_sb_data(sb, rootip, vfsp_right); + tdp1 = dm_sb_data(sb, rootip, vfsp_right, fsid); if (tdp1 == NULL) goto out_nomem; @@ -492,7 +490,7 @@ dm_send_mount_event( /* Queue the message and wait for the reply. */ - error = dm_enqueue_mount_event(sb, tevp); + error = dm_enqueue_mount_event(sb, tevp, fsid); /* If no errors occurred, we must leave with the same rights we had upon entry. If errors occurred, we must leave with no rights. @@ -540,7 +538,8 @@ dm_send_unmount_event( dm_right_t vfsp_right, mode_t mode, int retcode, /* errno, if unmount failed */ - int flags) + int flags, + dm_fsid_t *fsid) { dm_namesp_event_t *np; dm_tokevent_t *tevp; @@ -553,9 +552,9 @@ dm_send_unmount_event( */ if (retcode != 0) { /* unmount was unsuccessful */ - dm_change_fsys_entry(sb, DM_STATE_MOUNTED); + dm_change_fsys_entry(fsid, DM_STATE_MOUNTED); } else { - dm_change_fsys_entry(sb, DM_STATE_UNMOUNTED); + dm_change_fsys_entry(fsid, DM_STATE_UNMOUNTED); } /* If the event wasn't in the filesystem dm_eventset_t, just remove @@ -564,7 +563,7 @@ dm_send_unmount_event( if (flags & DM_FLAGS_UNWANTED) { if (retcode == 0) - dm_remove_fsys_entry(sb); + dm_remove_fsys_entry(fsid); return; } @@ -572,7 +571,7 @@ dm_send_unmount_event( for it. */ - tdp1 = dm_sb_data(sb, ip, vfsp_right); + tdp1 = dm_sb_data(sb, ip, vfsp_right, fsid); if (tdp1 == NULL) return; @@ -598,10 +597,10 @@ dm_send_unmount_event( message and ignore any error return for DM_EVENT_UNMOUNT. */ - (void)dm_enqueue_normal_event(sb, tevp, flags); + (void)dm_enqueue_normal_event(fsid, tevp, flags); if (retcode == 0) - dm_remove_fsys_entry(sb); + dm_remove_fsys_entry(fsid); dm_evt_rele_tevp(tevp, 0); } @@ -626,7 +625,8 @@ dm_send_namesp_event( char *name2, mode_t mode, int retcode, - int flags) + int flags, + dm_fsid_t *fsid) { dm_namesp_event_t *np; dm_tokevent_t *tevp; @@ -651,7 +651,7 @@ dm_send_namesp_event( */ if (flags & DM_FLAGS_UNWANTED) { - dm_change_fsys_entry(sb, DM_STATE_UNMOUNTING); + dm_change_fsys_entry(fsid, DM_STATE_UNMOUNTING); return(0); } if (ip1 == NULL) { @@ -661,7 +661,7 @@ dm_send_namesp_event( */ return(0); } - tdp1 = dm_sb_data(sb, ip1, vp1_right); + tdp1 = dm_sb_data(sb, ip1, vp1_right, fsid); if (tdp1 == NULL) return -ENOMEM; tdp2 = dm_ip_data(ip2, vp2_right, /* reference held */ 1); @@ -674,7 +674,7 @@ dm_send_namesp_event( case DM_EVENT_NOSPACE: /* vp1_right is the filesystem right. */ - tdp1 = dm_sb_data(sb, ip1, vp1_right); + tdp1 = dm_sb_data(sb, ip1, vp1_right, fsid); if (tdp1 == NULL) return -ENOMEM; tdp2 = dm_ip_data(ip2, vp2_right, /* reference held */ 1); /* additional info - not in the spec */ @@ -753,7 +753,7 @@ dm_send_namesp_event( /* Queue the message and wait for the reply. */ - error = dm_enqueue_normal_event(sb, tevp, flags); + error = dm_enqueue_normal_event(fsid, tevp, flags); /* If no errors occurred, we must leave with the same rights we had upon entry. If errors occurred, we must leave with no rights. @@ -762,7 +762,7 @@ dm_send_namesp_event( dm_evt_rele_tevp(tevp, error); if (!error && event == DM_EVENT_PREUNMOUNT) { - dm_change_fsys_entry(sb, DM_STATE_UNMOUNTING); + dm_change_fsys_entry(fsid, DM_STATE_UNMOUNTING); } return(error); From owner-linux-xfs@oss.sgi.com Thu May 12 12:37:36 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 May 2005 12:37:45 -0700 (PDT) Received: from hell.org.pl (hell.org.pl [62.233.239.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4CJbYOv029181 for ; Thu, 12 May 2005 12:37:35 -0700 Received: (qmail 31583 invoked by uid 777); 12 May 2005 19:36:48 -0000 Date: Thu, 12 May 2005 21:36:48 +0200 From: Karol Kozimor To: linux-xfs@oss.sgi.com Cc: linux-kernel@vger.kernel.org Subject: [XFS] 2.6.12-rc4: Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 Message-ID: <20050512193647.GA22976@hell.org.pl> Mail-Followup-To: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline User-Agent: Mutt/1.4.2i X-archive-position: 5211 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sziwan@hell.org.pl Precedence: bulk X-list: linux-xfs Content-Length: 27514 Lines: 671 Hi, Just happened to notice, a couple of WARNs and possibly minor fs corruption (after the system booted I went straight with SysRq+U, B and still got some garbage in the logs). Traces below. -- Karol 'sziwan' Kozimor sziwan@hell.org.pl VFS: Mounted root (xfs filesystem) readonly. Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 [] xfs_page_state_convert+0x334/0x660 [] radix_tree_gang_lookup_tag+0x49/0x70 [] linvfs_writepage+0x5c/0xf0 [] mpage_writepages+0x23f/0x3a0 [] xfs_mod_incore_sb_batch+0x5c/0xc0 [] linvfs_writepage+0x0/0xf0 [] pagebuf_rele+0x19/0x100 [] xfs_trans_unlock_chunk+0x9d/0xf0 [] linvfs_write_inode+0x36/0x70 [] __sync_single_inode+0x6a/0x200 [] __writeback_single_inode+0x60/0x150 [] handle_mm_fault+0xce/0x170 [] do_page_fault+0x174/0x562 [] sync_sb_inodes+0x19d/0x2b0 [] sync_inodes_sb+0x6e/0xa0 [] fsync_super+0xa/0x80 [] do_remount_sb+0x3d/0xe0 [] do_remount+0x93/0xd0 [] do_mount+0x16a/0x180 [] copy_mount_options+0x59/0xc0 [] sys_mount+0x7f/0xd0 [] syscall_call+0x7/0xb [...] Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 [] xfs_page_state_convert+0x334/0x660 [] submit_bio+0x57/0xf0 [] autoremove_wake_function+0x0/0x50 [] _pagebuf_ioapply+0x1d4/0x280 [] radix_tree_gang_lookup_tag+0x49/0x70 [] linvfs_writepage+0x5c/0xf0 [] mpage_writepages+0x23f/0x3a0 [] pagebuf_iostart+0x44/0xb0 [] linvfs_writepage+0x0/0xf0 [] xfs_inode_flush+0xd7/0x1d0 [] linvfs_write_inode+0x36/0x70 [] __sync_single_inode+0x6a/0x200 [] __writeback_single_inode+0x60/0x150 [] xfs_trans_first_ail+0x16/0x30 [] xfs_log_need_covered+0x73/0xc0 [] xfs_syncsub+0x117/0x270 [] sync_sb_inodes+0x19d/0x2b0 [] pdflush+0x0/0x20 [] writeback_inodes+0xf3/0x120 [] wb_kupdate+0x95/0x100 [] __pdflush+0xd5/0x200 [] pdflush+0x1a/0x20 [] wb_kupdate+0x0/0x100 [] pdflush+0x0/0x20 [] kthread+0x98/0xa0 [] kthread+0x0/0xa0 [] kernel_thread_helper+0x5/0x18 Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 [] xfs_page_state_convert+0x334/0x660 [] submit_bio+0x57/0xf0 [] autoremove_wake_function+0x0/0x50 [] radix_tree_gang_lookup_tag+0x49/0x70 [] linvfs_writepage+0x5c/0xf0 [] mpage_writepages+0x23f/0x3a0 [] pagebuf_iostart+0x44/0xb0 [] linvfs_writepage+0x0/0xf0 [] xfs_inode_flush+0xd7/0x1d0 [] linvfs_write_inode+0x36/0x70 [] __sync_single_inode+0x6a/0x200 [] __writeback_single_inode+0x60/0x150 [] xfs_trans_first_ail+0x16/0x30 [] xfs_log_need_covered+0x73/0xc0 [] xfs_syncsub+0x117/0x270 [] sync_sb_inodes+0x19d/0x2b0 [] pdflush+0x0/0x20 [] writeback_inodes+0xf3/0x120 [] wb_kupdate+0x95/0x100 [] __pdflush+0xd5/0x200 [] pdflush+0x1a/0x20 [] wb_kupdate+0x0/0x100 [] pdflush+0x0/0x20 [] kthread+0x98/0xa0 [] kthread+0x0/0xa0 [] kernel_thread_helper+0x5/0x18 Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 [] xfs_page_state_convert+0x334/0x660 [] submit_bio+0x57/0xf0 [] autoremove_wake_function+0x0/0x50 [] radix_tree_gang_lookup_tag+0x49/0x70 [] linvfs_writepage+0x5c/0xf0 [] mpage_writepages+0x23f/0x3a0 [] pagebuf_iostart+0x44/0xb0 [] linvfs_writepage+0x0/0xf0 [] linvfs_write_inode+0x36/0x70 [] __sync_single_inode+0x6a/0x200 [] __writeback_single_inode+0x60/0x150 [] xfs_trans_first_ail+0x16/0x30 [] xfs_log_need_covered+0x73/0xc0 [] xfs_syncsub+0x117/0x270 [] sync_sb_inodes+0x19d/0x2b0 [] pdflush+0x0/0x20 [] writeback_inodes+0xf3/0x120 [] wb_kupdate+0x95/0x100 [] __pdflush+0xd5/0x200 [] pdflush+0x1a/0x20 [] wb_kupdate+0x0/0x100 [] pdflush+0x0/0x20 [] kthread+0x98/0xa0 [] kthread+0x0/0xa0 [] kernel_thread_helper+0x5/0x18 Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 [] xfs_page_state_convert+0x334/0x660 [] submit_bio+0x57/0xf0 [] autoremove_wake_function+0x0/0x50 [] radix_tree_gang_lookup_tag+0x49/0x70 [] linvfs_writepage+0x5c/0xf0 [] mpage_writepages+0x23f/0x3a0 [] pagebuf_iostart+0x44/0xb0 [] linvfs_writepage+0x0/0xf0 [] linvfs_write_inode+0x36/0x70 [] __sync_single_inode+0x6a/0x200 [] __writeback_single_inode+0x60/0x150 [] xfs_trans_first_ail+0x16/0x30 [] xfs_log_need_covered+0x73/0xc0 [] xfs_syncsub+0x117/0x270 [] sync_sb_inodes+0x19d/0x2b0 [] pdflush+0x0/0x20 [] writeback_inodes+0xf3/0x120 [] wb_kupdate+0x95/0x100 [] __pdflush+0xd5/0x200 [] pdflush+0x1a/0x20 [] wb_kupdate+0x0/0x100 [] pdflush+0x0/0x20 [] kthread+0x98/0xa0 [] kthread+0x0/0xa0 [] kernel_thread_helper+0x5/0x18 Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 [] xfs_page_state_convert+0x334/0x660 [] generic_make_request+0x150/0x1f0 [] radix_tree_gang_lookup_tag+0x49/0x70 [] linvfs_writepage+0x5c/0xf0 [] mpage_writepages+0x23f/0x3a0 [] linvfs_writepage+0x0/0xf0 [] _pagebuf_ioapply+0x1d4/0x280 [] pagebuf_rele+0x19/0x100 [] __sync_single_inode+0x6a/0x200 [] __writeback_single_inode+0x60/0x150 [] xfs_trans_first_ail+0x16/0x30 [] xfs_log_need_covered+0x73/0xc0 [] xfs_syncsub+0x117/0x270 [] sync_sb_inodes+0x19d/0x2b0 [] pdflush+0x0/0x20 [] writeback_inodes+0xf3/0x120 [] wb_kupdate+0x95/0x100 [] __pdflush+0xd5/0x200 [] pdflush+0x1a/0x20 [] wb_kupdate+0x0/0x100 [] pdflush+0x0/0x20 [] kthread+0x98/0xa0 [] kthread+0x0/0xa0 [] kernel_thread_helper+0x5/0x18 Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 [] xfs_page_state_convert+0x334/0x660 [] submit_bio+0x57/0xf0 [] autoremove_wake_function+0x0/0x50 [] radix_tree_gang_lookup_tag+0x49/0x70 [] linvfs_writepage+0x5c/0xf0 [] mpage_writepages+0x23f/0x3a0 [] pagebuf_iostart+0x44/0xb0 [] linvfs_writepage+0x0/0xf0 [] linvfs_write_inode+0x36/0x70 [] __sync_single_inode+0x6a/0x200 [] __writeback_single_inode+0x60/0x150 [] xfs_trans_first_ail+0x16/0x30 [] xfs_log_need_covered+0x73/0xc0 [] xfs_syncsub+0x117/0x270 [] sync_sb_inodes+0x19d/0x2b0 [] pdflush+0x0/0x20 [] writeback_inodes+0xf3/0x120 [] wb_kupdate+0x95/0x100 [] __pdflush+0xd5/0x200 [] pdflush+0x1a/0x20 [] wb_kupdate+0x0/0x100 [] pdflush+0x0/0x20 [] kthread+0x98/0xa0 [] kthread+0x0/0xa0 [] kernel_thread_helper+0x5/0x18 Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 [] xfs_page_state_convert+0x334/0x660 [] submit_bio+0x57/0xf0 [] autoremove_wake_function+0x0/0x50 [] radix_tree_gang_lookup_tag+0x49/0x70 [] linvfs_writepage+0x5c/0xf0 [] mpage_writepages+0x23f/0x3a0 [] pagebuf_iostart+0x44/0xb0 [] linvfs_writepage+0x0/0xf0 [] linvfs_write_inode+0x36/0x70 [] __sync_single_inode+0x6a/0x200 [] __writeback_single_inode+0x60/0x150 [] xfs_trans_first_ail+0x16/0x30 [] xfs_log_need_covered+0x73/0xc0 [] xfs_syncsub+0x117/0x270 [] sync_sb_inodes+0x19d/0x2b0 [] pdflush+0x0/0x20 [] writeback_inodes+0xf3/0x120 [] wb_kupdate+0x95/0x100 [] __pdflush+0xd5/0x200 [] pdflush+0x1a/0x20 [] wb_kupdate+0x0/0x100 [] pdflush+0x0/0x20 [] kthread+0x98/0xa0 [] kthread+0x0/0xa0 [] kernel_thread_helper+0x5/0x18 Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 [] xfs_page_state_convert+0x334/0x660 [] submit_bio+0x57/0xf0 [] autoremove_wake_function+0x0/0x50 [] radix_tree_gang_lookup_tag+0x49/0x70 [] linvfs_writepage+0x5c/0xf0 [] mpage_writepages+0x23f/0x3a0 [] pagebuf_iostart+0x44/0xb0 [] linvfs_writepage+0x0/0xf0 [] linvfs_write_inode+0x36/0x70 [] __sync_single_inode+0x6a/0x200 [] __writeback_single_inode+0x60/0x150 [] xfs_trans_first_ail+0x16/0x30 [] xfs_log_need_covered+0x73/0xc0 [] xfs_syncsub+0x117/0x270 [] sync_sb_inodes+0x19d/0x2b0 [] pdflush+0x0/0x20 [] writeback_inodes+0xf3/0x120 [] wb_kupdate+0x95/0x100 [] __pdflush+0xd5/0x200 [] pdflush+0x1a/0x20 [] wb_kupdate+0x0/0x100 [] pdflush+0x0/0x20 [] kthread+0x98/0xa0 [] kthread+0x0/0xa0 [] kernel_thread_helper+0x5/0x18 Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 [] xfs_page_state_convert+0x334/0x660 [] submit_bio+0x57/0xf0 [] autoremove_wake_function+0x0/0x50 [] radix_tree_gang_lookup_tag+0x49/0x70 [] linvfs_writepage+0x5c/0xf0 [] mpage_writepages+0x23f/0x3a0 [] pagebuf_iostart+0x44/0xb0 [] linvfs_writepage+0x0/0xf0 [] linvfs_write_inode+0x36/0x70 [] __sync_single_inode+0x6a/0x200 [] __writeback_single_inode+0x60/0x150 [] xfs_trans_first_ail+0x16/0x30 [] xfs_log_need_covered+0x73/0xc0 [] xfs_syncsub+0x117/0x270 [] sync_sb_inodes+0x19d/0x2b0 [] pdflush+0x0/0x20 [] writeback_inodes+0xf3/0x120 [] wb_kupdate+0x95/0x100 [] __pdflush+0xd5/0x200 [] pdflush+0x1a/0x20 [] wb_kupdate+0x0/0x100 [] pdflush+0x0/0x20 [] kthread+0x98/0xa0 [] kthread+0x0/0xa0 [] kernel_thread_helper+0x5/0x18 Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 [] xfs_page_state_convert+0x334/0x660 [] submit_bio+0x57/0xf0 [] autoremove_wake_function+0x0/0x50 [] radix_tree_gang_lookup_tag+0x49/0x70 [] linvfs_writepage+0x5c/0xf0 [] mpage_writepages+0x23f/0x3a0 [] pagebuf_iostart+0x44/0xb0 [] linvfs_writepage+0x0/0xf0 [] linvfs_write_inode+0x36/0x70 [] __sync_single_inode+0x6a/0x200 [] __writeback_single_inode+0x60/0x150 [] xfs_trans_first_ail+0x16/0x30 [] xfs_log_need_covered+0x73/0xc0 [] xfs_syncsub+0x117/0x270 [] sync_sb_inodes+0x19d/0x2b0 [] pdflush+0x0/0x20 [] writeback_inodes+0xf3/0x120 [] wb_kupdate+0x95/0x100 [] __pdflush+0xd5/0x200 [] pdflush+0x1a/0x20 [] wb_kupdate+0x0/0x100 [] pdflush+0x0/0x20 [] kthread+0x98/0xa0 [] kthread+0x0/0xa0 [] kernel_thread_helper+0x5/0x18 Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 [] xfs_page_state_convert+0x334/0x660 [] submit_bio+0x57/0xf0 [] autoremove_wake_function+0x0/0x50 [] radix_tree_gang_lookup_tag+0x49/0x70 [] linvfs_writepage+0x5c/0xf0 [] mpage_writepages+0x23f/0x3a0 [] pagebuf_iostart+0x44/0xb0 [] linvfs_writepage+0x0/0xf0 [] xfs_inode_flush+0xd7/0x1d0 [] linvfs_write_inode+0x36/0x70 [] __sync_single_inode+0x6a/0x200 [] __writeback_single_inode+0x60/0x150 [] xfs_trans_first_ail+0x16/0x30 [] xfs_log_need_covered+0x73/0xc0 [] xfs_syncsub+0x117/0x270 [] sync_sb_inodes+0x19d/0x2b0 [] pdflush+0x0/0x20 [] writeback_inodes+0xf3/0x120 [] wb_kupdate+0x95/0x100 [] __pdflush+0xd5/0x200 [] pdflush+0x1a/0x20 [] wb_kupdate+0x0/0x100 [] pdflush+0x0/0x20 [] kthread+0x98/0xa0 [] kthread+0x0/0xa0 [] kernel_thread_helper+0x5/0x18 Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 [] xfs_page_state_convert+0x334/0x660 [] submit_bio+0x57/0xf0 [] autoremove_wake_function+0x0/0x50 [] radix_tree_gang_lookup_tag+0x49/0x70 [] linvfs_writepage+0x5c/0xf0 [] mpage_writepages+0x23f/0x3a0 [] pagebuf_iostart+0x44/0xb0 [] linvfs_writepage+0x0/0xf0 [] xfs_inode_flush+0xd7/0x1d0 [] linvfs_write_inode+0x36/0x70 [] __sync_single_inode+0x6a/0x200 [] __writeback_single_inode+0x60/0x150 [] xfs_trans_first_ail+0x16/0x30 [] xfs_log_need_covered+0x73/0xc0 [] xfs_syncsub+0x117/0x270 [] sync_sb_inodes+0x19d/0x2b0 [] pdflush+0x0/0x20 [] writeback_inodes+0xf3/0x120 [] wb_kupdate+0x95/0x100 [] __pdflush+0xd5/0x200 [] pdflush+0x1a/0x20 [] wb_kupdate+0x0/0x100 [] pdflush+0x0/0x20 [] kthread+0x98/0xa0 [] kthread+0x0/0xa0 [] kernel_thread_helper+0x5/0x18 Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 [] xfs_page_state_convert+0x334/0x660 [] submit_bio+0x57/0xf0 [] autoremove_wake_function+0x0/0x50 [] radix_tree_gang_lookup_tag+0x49/0x70 [] linvfs_writepage+0x5c/0xf0 [] mpage_writepages+0x23f/0x3a0 [] pagebuf_iostart+0x44/0xb0 [] linvfs_writepage+0x0/0xf0 [] xfs_inode_flush+0xd7/0x1d0 [] linvfs_write_inode+0x36/0x70 [] __sync_single_inode+0x6a/0x200 [] __writeback_single_inode+0x60/0x150 [] xfs_trans_first_ail+0x16/0x30 [] xfs_log_need_covered+0x73/0xc0 [] xfs_syncsub+0x117/0x270 [] sync_sb_inodes+0x19d/0x2b0 [] pdflush+0x0/0x20 [] writeback_inodes+0xf3/0x120 [] wb_kupdate+0x95/0x100 [] __pdflush+0xd5/0x200 [] pdflush+0x1a/0x20 [] wb_kupdate+0x0/0x100 [] pdflush+0x0/0x20 [] kthread+0x98/0xa0 [] kthread+0x0/0xa0 [] kernel_thread_helper+0x5/0x18 Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 [] xfs_page_state_convert+0x334/0x660 [] submit_bio+0x57/0xf0 [] autoremove_wake_function+0x0/0x50 [] radix_tree_gang_lookup_tag+0x49/0x70 [] linvfs_writepage+0x5c/0xf0 [] mpage_writepages+0x23f/0x3a0 [] pagebuf_iostart+0x44/0xb0 [] linvfs_writepage+0x0/0xf0 [] xfs_inode_flush+0xd7/0x1d0 [] linvfs_write_inode+0x36/0x70 [] __sync_single_inode+0x6a/0x200 [] __writeback_single_inode+0x60/0x150 [] xfs_trans_first_ail+0x16/0x30 [] xfs_log_need_covered+0x73/0xc0 [] xfs_syncsub+0x117/0x270 [] sync_sb_inodes+0x19d/0x2b0 [] pdflush+0x0/0x20 [] writeback_inodes+0xf3/0x120 [] wb_kupdate+0x95/0x100 [] __pdflush+0xd5/0x200 [] pdflush+0x1a/0x20 [] wb_kupdate+0x0/0x100 [] pdflush+0x0/0x20 [] kthread+0x98/0xa0 [] kthread+0x0/0xa0 [] kernel_thread_helper+0x5/0x18 Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 [] xfs_page_state_convert+0x334/0x660 [] submit_bio+0x57/0xf0 [] autoremove_wake_function+0x0/0x50 [] radix_tree_gang_lookup_tag+0x49/0x70 [] linvfs_writepage+0x5c/0xf0 [] mpage_writepages+0x23f/0x3a0 [] pagebuf_iostart+0x44/0xb0 [] linvfs_writepage+0x0/0xf0 [] xfs_inode_flush+0xd7/0x1d0 [] linvfs_write_inode+0x36/0x70 [] __sync_single_inode+0x6a/0x200 [] __writeback_single_inode+0x60/0x150 [] xfs_trans_first_ail+0x16/0x30 [] xfs_log_need_covered+0x73/0xc0 [] xfs_syncsub+0x117/0x270 [] sync_sb_inodes+0x19d/0x2b0 [] pdflush+0x0/0x20 [] writeback_inodes+0xf3/0x120 [] wb_kupdate+0x95/0x100 [] __pdflush+0xd5/0x200 [] pdflush+0x1a/0x20 [] wb_kupdate+0x0/0x100 [] pdflush+0x0/0x20 [] kthread+0x98/0xa0 [] kthread+0x0/0xa0 [] kernel_thread_helper+0x5/0x18 Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 [] xfs_page_state_convert+0x334/0x660 [] submit_bio+0x57/0xf0 [] autoremove_wake_function+0x0/0x50 [] radix_tree_gang_lookup_tag+0x49/0x70 [] linvfs_writepage+0x5c/0xf0 [] mpage_writepages+0x23f/0x3a0 [] pagebuf_iostart+0x44/0xb0 [] linvfs_writepage+0x0/0xf0 [] xfs_inode_flush+0xd7/0x1d0 [] linvfs_write_inode+0x36/0x70 [] __sync_single_inode+0x6a/0x200 [] __writeback_single_inode+0x60/0x150 [] xfs_trans_first_ail+0x16/0x30 [] xfs_log_need_covered+0x73/0xc0 [] xfs_syncsub+0x117/0x270 [] sync_sb_inodes+0x19d/0x2b0 [] pdflush+0x0/0x20 [] writeback_inodes+0xf3/0x120 [] wb_kupdate+0x95/0x100 [] __pdflush+0xd5/0x200 [] pdflush+0x1a/0x20 [] wb_kupdate+0x0/0x100 [] pdflush+0x0/0x20 [] kthread+0x98/0xa0 [] kthread+0x0/0xa0 [] kernel_thread_helper+0x5/0x18 Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 [] xfs_page_state_convert+0x334/0x660 [] submit_bio+0x57/0xf0 [] autoremove_wake_function+0x0/0x50 [] radix_tree_gang_lookup_tag+0x49/0x70 [] linvfs_writepage+0x5c/0xf0 [] mpage_writepages+0x23f/0x3a0 [] pagebuf_iostart+0x44/0xb0 [] linvfs_writepage+0x0/0xf0 [] xfs_inode_flush+0xd7/0x1d0 [] linvfs_write_inode+0x36/0x70 [] __sync_single_inode+0x6a/0x200 [] __writeback_single_inode+0x60/0x150 [] xfs_trans_first_ail+0x16/0x30 [] xfs_log_need_covered+0x73/0xc0 [] xfs_syncsub+0x117/0x270 [] sync_sb_inodes+0x19d/0x2b0 [] pdflush+0x0/0x20 [] writeback_inodes+0xf3/0x120 [] wb_kupdate+0x95/0x100 [] __pdflush+0xd5/0x200 [] pdflush+0x1a/0x20 [] wb_kupdate+0x0/0x100 [] pdflush+0x0/0x20 [] kthread+0x98/0xa0 [] kthread+0x0/0xa0 [] kernel_thread_helper+0x5/0x18 Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 [] xfs_page_state_convert+0x334/0x660 [] submit_bio+0x57/0xf0 [] autoremove_wake_function+0x0/0x50 [] radix_tree_gang_lookup_tag+0x49/0x70 [] linvfs_writepage+0x5c/0xf0 [] mpage_writepages+0x23f/0x3a0 [] pagebuf_iostart+0x44/0xb0 [] linvfs_writepage+0x0/0xf0 [] xfs_inode_flush+0xd7/0x1d0 [] linvfs_write_inode+0x36/0x70 [] __sync_single_inode+0x6a/0x200 [] __writeback_single_inode+0x60/0x150 [] xfs_trans_first_ail+0x16/0x30 [] xfs_log_need_covered+0x73/0xc0 [] xfs_syncsub+0x117/0x270 [] sync_sb_inodes+0x19d/0x2b0 [] pdflush+0x0/0x20 [] writeback_inodes+0xf3/0x120 [] wb_kupdate+0x95/0x100 [] __pdflush+0xd5/0x200 [] pdflush+0x1a/0x20 [] wb_kupdate+0x0/0x100 [] pdflush+0x0/0x20 [] kthread+0x98/0xa0 [] kthread+0x0/0xa0 [] kernel_thread_helper+0x5/0x18 Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 [] xfs_page_state_convert+0x334/0x660 [] submit_bio+0x57/0xf0 [] autoremove_wake_function+0x0/0x50 [] radix_tree_gang_lookup_tag+0x49/0x70 [] linvfs_writepage+0x5c/0xf0 [] mpage_writepages+0x23f/0x3a0 [] pagebuf_iostart+0x44/0xb0 [] linvfs_writepage+0x0/0xf0 [] xfs_inode_flush+0xd7/0x1d0 [] linvfs_write_inode+0x36/0x70 [] __sync_single_inode+0x6a/0x200 [] __writeback_single_inode+0x60/0x150 [] xfs_trans_first_ail+0x16/0x30 [] xfs_log_need_covered+0x73/0xc0 [] xfs_syncsub+0x117/0x270 [] sync_sb_inodes+0x19d/0x2b0 [] pdflush+0x0/0x20 [] writeback_inodes+0xf3/0x120 [] wb_kupdate+0x95/0x100 [] __pdflush+0xd5/0x200 [] pdflush+0x1a/0x20 [] wb_kupdate+0x0/0x100 [] pdflush+0x0/0x20 [] kthread+0x98/0xa0 [] kthread+0x0/0xa0 [] kernel_thread_helper+0x5/0x18 Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 [] xfs_page_state_convert+0x334/0x660 [] submit_bio+0x57/0xf0 [] autoremove_wake_function+0x0/0x50 [] radix_tree_gang_lookup_tag+0x49/0x70 [] linvfs_writepage+0x5c/0xf0 [] mpage_writepages+0x23f/0x3a0 [] pagebuf_iostart+0x44/0xb0 [] linvfs_writepage+0x0/0xf0 [] xfs_inode_flush+0xd7/0x1d0 [] xfs_inode_flush+0xd7/0x1d0 [] linvfs_write_inode+0x36/0x70 [] __sync_single_inode+0x6a/0x200 [] __writeback_single_inode+0x60/0x150 [] scheduler_tick+0x18a/0x380 [] run_timer_softirq+0x132/0x1d0 [] generic_forget_inode+0x54/0x140 [] sync_sb_inodes+0x19d/0x2b0 [] sync_inodes_sb+0x6e/0xa0 [] pdflush+0x0/0x20 [] fsync_super+0xa/0x80 [] do_remount_sb+0x3d/0xe0 [] do_emergency_remount+0xda/0xf0 [] __pdflush+0xd5/0x200 [] pdflush+0x1a/0x20 [] do_emergency_remount+0x0/0xf0 [] pdflush+0x0/0x20 [] kthread+0x98/0xa0 [] kthread+0x0/0xa0 [] kernel_thread_helper+0x5/0x18 Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 [] xfs_page_state_convert+0x334/0x660 [] submit_bio+0x57/0xf0 [] autoremove_wake_function+0x0/0x50 [] radix_tree_gang_lookup_tag+0x49/0x70 [] linvfs_writepage+0x5c/0xf0 [] mpage_writepages+0x23f/0x3a0 [] pagebuf_iostart+0x44/0xb0 [] linvfs_writepage+0x0/0xf0 [] xfs_inode_flush+0xd7/0x1d0 [] xfs_inode_flush+0xd7/0x1d0 [] linvfs_write_inode+0x36/0x70 [] __sync_single_inode+0x6a/0x200 [] __writeback_single_inode+0x60/0x150 [] scheduler_tick+0x18a/0x380 [] run_timer_softirq+0x132/0x1d0 [] generic_forget_inode+0x54/0x140 [] sync_sb_inodes+0x19d/0x2b0 [] sync_inodes_sb+0x6e/0xa0 [] pdflush+0x0/0x20 [] fsync_super+0xa/0x80 [] do_remount_sb+0x3d/0xe0 [] do_emergency_remount+0xda/0xf0 [] __pdflush+0xd5/0x200 [] pdflush+0x1a/0x20 [] do_emergency_remount+0x0/0xf0 [] pdflush+0x0/0x20 [] kthread+0x98/0xa0 [] kthread+0x0/0xa0 [] kernel_thread_helper+0x5/0x18 Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 [] xfs_page_state_convert+0x334/0x660 [] submit_bio+0x57/0xf0 [] autoremove_wake_function+0x0/0x50 [] radix_tree_gang_lookup_tag+0x49/0x70 [] linvfs_writepage+0x5c/0xf0 [] mpage_writepages+0x23f/0x3a0 [] pagebuf_iostart+0x44/0xb0 [] linvfs_writepage+0x0/0xf0 [] xfs_inode_flush+0xd7/0x1d0 [] xfs_inode_flush+0xd7/0x1d0 [] linvfs_write_inode+0x36/0x70 [] __sync_single_inode+0x6a/0x200 [] __writeback_single_inode+0x60/0x150 [] scheduler_tick+0x18a/0x380 [] run_timer_softirq+0x132/0x1d0 [] generic_forget_inode+0x54/0x140 [] sync_sb_inodes+0x19d/0x2b0 [] sync_inodes_sb+0x6e/0xa0 [] pdflush+0x0/0x20 [] fsync_super+0xa/0x80 [] do_remount_sb+0x3d/0xe0 [] do_emergency_remount+0xda/0xf0 [] __pdflush+0xd5/0x200 [] pdflush+0x1a/0x20 [] do_emergency_remount+0x0/0xf0 [] pdflush+0x0/0x20 [] kthread+0x98/0xa0 [] kthread+0x0/0xa0 [] kernel_thread_helper+0x5/0x18 Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 [] xfs_page_state_convert+0x334/0x660 [] submit_bio+0x57/0xf0 [] autoremove_wake_function+0x0/0x50 [] radix_tree_gang_lookup_tag+0x49/0x70 [] linvfs_writepage+0x5c/0xf0 [] mpage_writepages+0x23f/0x3a0 [] pagebuf_iostart+0x44/0xb0 [] linvfs_writepage+0x0/0xf0 [] xfs_inode_flush+0xd7/0x1d0 [] xfs_inode_flush+0xd7/0x1d0 [] linvfs_write_inode+0x36/0x70 [] __sync_single_inode+0x6a/0x200 [] __writeback_single_inode+0x60/0x150 [] scheduler_tick+0x18a/0x380 [] run_timer_softirq+0x132/0x1d0 [] generic_forget_inode+0x54/0x140 [] sync_sb_inodes+0x19d/0x2b0 [] sync_inodes_sb+0x6e/0xa0 [] pdflush+0x0/0x20 [] fsync_super+0xa/0x80 [] do_remount_sb+0x3d/0xe0 [] do_emergency_remount+0xda/0xf0 [] __pdflush+0xd5/0x200 [] pdflush+0x1a/0x20 [] do_emergency_remount+0x0/0xf0 [] pdflush+0x0/0x20 [] kthread+0x98/0xa0 [] kthread+0x0/0xa0 [] kernel_thread_helper+0x5/0x18 Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 [] xfs_page_state_convert+0x334/0x660 [] submit_bio+0x57/0xf0 [] autoremove_wake_function+0x0/0x50 [] radix_tree_gang_lookup_tag+0x49/0x70 [] linvfs_writepage+0x5c/0xf0 [] mpage_writepages+0x23f/0x3a0 [] pagebuf_iostart+0x44/0xb0 [] linvfs_writepage+0x0/0xf0 [] xfs_inode_flush+0xd7/0x1d0 From owner-linux-xfs@oss.sgi.com Fri May 13 04:13:02 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 May 2005 04:13:06 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4DBD1Ov020554 for ; Fri, 13 May 2005 04:13:01 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4DBCXxT018312 for ; Fri, 13 May 2005 06:12:33 -0500 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4DBCWR07999147; Fri, 13 May 2005 06:12:32 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1DWY5o-0005QU-00; Fri, 13 May 2005 06:12:32 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 934679 - Fix a false-positive WARN_ON Message-Id: From: Christoph Hellwig Date: Fri, 13 May 2005 06:12:32 -0500 X-archive-position: 5212 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 406 Lines: 13 Date: Fri May 13 04:12:37 PDT 2005 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.6.x Inspected by: dgc The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:192569a fs/xfs/linux-2.6/xfs_aops.c - 1.87 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_aops.c.diff?r1=text&tr1=1.87&r2=text&tr2=1.86&f=h From owner-linux-xfs@oss.sgi.com Fri May 13 04:18:24 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 May 2005 04:18:28 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4DBINOv021256 for ; Fri, 13 May 2005 04:18:23 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4DBHtxT019159 for ; Fri, 13 May 2005 06:17:55 -0500 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4DBHs0F14952192; Fri, 13 May 2005 06:17:54 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1DWYB0-0005Z2-00; Fri, 13 May 2005 06:17:54 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 934679 - fix some more compiler warnings in the vnode tracing code Message-Id: From: Christoph Hellwig Date: Fri, 13 May 2005 06:17:54 -0500 X-archive-position: 5213 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 410 Lines: 12 Date: Fri May 13 04:18:00 PDT 2005 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.6.x Inspected by: dgc The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:192570a fs/xfs/linux-2.6/xfs_vnode.c - 1.127 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vnode.c.diff?r1=text&tr1=1.127&r2=text&tr2=1.126&f=h From owner-linux-xfs@oss.sgi.com Fri May 13 06:00:31 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 May 2005 06:00:34 -0700 (PDT) Received: from cirse.extra.cea.fr (cirse.extra.cea.fr [132.166.172.102]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4DD0UOv029866 for ; Fri, 13 May 2005 06:00:30 -0700 Received: from argiope.saclay.cea.fr (argiope.saclay.cea.fr [132.166.192.108]) by cirse.extra.cea.fr (8.12.10/8.12.10/CEAnet-Internet.4.0) with ESMTP id j4DD01AN010652 for ; Fri, 13 May 2005 15:00:01 +0200 (MEST) Received: from pisaure.intra.cea.fr (unverified) by argiope.saclay.cea.fr (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Fri, 13 May 2005 15:00:01 +0200 Received: from nenuphar.saclay.cea.fr (nenuphar.saclay.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.12.11/8.12.11) with ESMTP id j4DCw6cq010438; Fri, 13 May 2005 14:58:07 +0200 (envelope-from degremont@ocre.cea.fr) Received: from ocre.cea.fr ([132.165.65.70]) by nenuphar.saclay.cea.fr (8.12.10/8.12.10/CEAnet-internes.4.0) with ESMTP id j4DD00Za006133; Fri, 13 May 2005 15:00:00 +0200 (MEST) Message-ID: <4284A4D0.20002@ocre.cea.fr> Date: Fri, 13 May 2005 15:00:00 +0200 From: Aurelien Degremont - Stagiaire User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us MIME-Version: 1.0 To: Dean Roehrich CC: linux-xfs@oss.sgi.com Subject: Re: [DMAPI] code error in dm_ip_to_handle() References: <20050512161213.29B464FE8A@chewtoy.americas.sgi.com> In-Reply-To: <20050512161213.29B464FE8A@chewtoy.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5215 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: degremont@ocre.cea.fr Precedence: bulk X-list: linux-xfs Content-Length: 1629 Lines: 41 > The dm_fid_len field is used to distinguish between filesystem handles and > file handles. That has to stay in place. Ok. I miss this. About it, I don't understand how the dm_fid_len is filled. I don't find where in the code, you set its len to 0 when its a filesystem handle ? How do you know this ? (But I found in xfs_dm_fh_to_inode(), where you test the fid_len) >>The question is : Does DMAPI need the inode number of the filehandles ? >>After some searches it seems this data is only used in dmapi_session.c, >>when dealing with hash_event. I don't know the purpose of them. But >>concerning repeated_event(), it looks like the inode number is only used >>in order to compare 2 handles. I think, this comparison must be done >>using the whole structure (memcmp) or at least using the ino AND the gen >> number. The ino number is not enough. > I could agree to that, but what do we give to the hash function? I don't know the purpose of this hash function, so i couldn't help you here. But, at least, check also the i_gen number equality, or do a memcmp() between the two handle structures rather then just the ino value. > It is the FS which must convert between handles and filesystem objects, so the > handle better make sense to the FS. Whenever DMAPI needs this conversion, it > should call to the FS. So, no, DMAPI should not control the 'dm_fid_ino' > field. Ok, so let the FS free of whatever tricks it wants or needs (thinking about distributed filesystem by example...) Ok. So, do we remove the dm_fsfid_t ? Replace it by a dm_fid as you proposed ? I think it's a good idea. Aurelien From owner-linux-xfs@oss.sgi.com Fri May 13 08:30:21 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 May 2005 08:30:29 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4DFUKOv008569 for ; Fri, 13 May 2005 08:30:20 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4DFTqxT031598 for ; Fri, 13 May 2005 10:29:52 -0500 Received: from chewtoy.americas.sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4DFTmR08011927; Fri, 13 May 2005 10:29:48 -0500 (CDT) Received: from chewtoy (localhost [127.0.0.1]) by chewtoy.americas.sgi.com (Postfix) with ESMTP id 909404FE8A; Fri, 13 May 2005 10:29:47 -0500 (CDT) To: Aurelien Degremont - Stagiaire Cc: linux-xfs@oss.sgi.com Subject: Re: [DMAPI] code error in dm_ip_to_handle() Date: Fri, 13 May 2005 10:29:47 -0500 From: Dean Roehrich Message-Id: <20050513152947.909404FE8A@chewtoy.americas.sgi.com> X-archive-position: 5216 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2571 Lines: 62 >From: Aurelien Degremont - Stagiaire > > >> The dm_fid_len field is used to distinguish between filesystem handles and >> file handles. That has to stay in place. > >Ok. I miss this. >About it, I don't understand how the dm_fid_len is filled. I don't find >where in the code, you set its len to 0 when its a filesystem handle ? >How do you know this ? > >(But I found in xfs_dm_fh_to_inode(), where you test the fid_len) Certainly, dm_handle_to_ip() is intended to return any type of handle, including filesystem handles. In the case of XFS, when a filesystem handle is requested we contruct it from the filesystem's root vnode. I suppose dm_handle_to_ip() could be called with the handle from the mount event. That handle would have a fid_len of 0, due to the memset() in dm_sb_data()...the HSM would call to things like dm_get_config() and dm_set_disp() with that handle. >>>The question is : Does DMAPI need the inode number of the filehandles ? >>>After some searches it seems this data is only used in dmapi_session.c, >>>when dealing with hash_event. I don't know the purpose of them. But >>>concerning repeated_event(), it looks like the inode number is only used >>>in order to compare 2 handles. I think, this comparison must be done >>>using the whole structure (memcmp) or at least using the ino AND the gen >>> number. The ino number is not enough. > >> I could agree to that, but what do we give to the hash function? > >I don't know the purpose of this hash function, so i couldn't help you >here. But, at least, check also the i_gen number equality, or do a >memcmp() between the two handle structures rather then just the ino value. This is going to need more work if we add the generation number to the checks, but I agree we have a hole here. This hash is used for async events. The best example is events from I/O via nfsd. It may take a while for the HSM to respond to the event, and nfsd may timeout and retry the I/O, sending another event. On a large-scale system, this can quickly fill the dmapi queues and suck up kernel memory, especially if the HSM is waiting on finicky tapes. To address this, we check to see if a new async event matches one that is already in the queues, and if so, we return it with EAGAIN and keep just the one event in the queues. >Ok. So, do we remove the dm_fsfid_t ? Replace it by a dm_fid as you >proposed ? I think it's a good idea. I would like to see how it works out, if you're willing to do the code. Have you been able to try that fsid patch yet? Dean From owner-linux-xfs@oss.sgi.com Fri May 13 08:48:08 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 May 2005 08:48:11 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4DFm7Ov009867 for ; Fri, 13 May 2005 08:48:07 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4DHVXlv028994 for ; Fri, 13 May 2005 10:31:33 -0700 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4DFlb0F14965840; Fri, 13 May 2005 10:47:38 -0500 (CDT) Message-ID: <4284CC19.2070604@sgi.com> Date: Fri, 13 May 2005 10:47:37 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Harvey CC: linux-xfs@oss.sgi.com, linux-lvm@redhat.com Subject: Re: SATA RAID5 XFS LVM kernel hang on 2.6.11-1.14_FC3 References: <20050512134507.46573.qmail@web30505.mail.mud.yahoo.com> In-Reply-To: <20050512134507.46573.qmail@web30505.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5217 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 689 Lines: 30 Tim Harvey wrote: > After anywhere from hours to a few seconds large transfers, the console starts > spewing endlessly the following: > > do_IRQ: stack overflow: 312 > [] do_IRQ+0x83/0x85 > [] common_interrupt+0x1a/0x20 > [] cfq_set_request+0x1b2/0x4fd ... > Someone on the linux-raid list thought there is/was an issue with XFS and 4K > stacks... is this true? That could be true, esp. when you've stacked on a volume manager. > do_IRQ: stack overflow: 312 is quite a hint that this is exactly what's happening. I'd be interested in a post of the entire stack from the do_IRQ notice. -Eric > Any help would be greatly appreciated, > > Tim > From owner-linux-xfs@oss.sgi.com Fri May 13 08:55:25 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 May 2005 08:55:28 -0700 (PDT) Received: from cirse.extra.cea.fr (cirse.extra.cea.fr [132.166.172.102]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4DFtOOv010477 for ; Fri, 13 May 2005 08:55:25 -0700 Received: from argiope.saclay.cea.fr (argiope.saclay.cea.fr [132.166.192.108]) by cirse.extra.cea.fr (8.12.10/8.12.10/CEAnet-Internet.4.0) with ESMTP id j4DFstAN018416 for ; Fri, 13 May 2005 17:54:55 +0200 (MEST) Received: from pisaure.intra.cea.fr (unverified) by argiope.saclay.cea.fr (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Fri, 13 May 2005 17:54:55 +0200 Received: from nenuphar.saclay.cea.fr (nenuphar.saclay.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.12.11/8.12.11) with ESMTP id j4DFr18c010449; Fri, 13 May 2005 17:53:01 +0200 (envelope-from degremont@ocre.cea.fr) Received: from ocre.cea.fr ([132.165.65.70]) by nenuphar.saclay.cea.fr (8.12.10/8.12.10/CEAnet-internes.4.0) with ESMTP id j4DFssZa021533; Fri, 13 May 2005 17:54:54 +0200 (MEST) Message-ID: <4284CDCE.9090905@ocre.cea.fr> Date: Fri, 13 May 2005 17:54:54 +0200 From: Aurelien Degremont - Stagiaire User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com CC: Dean Roehrich Subject: Re: vfs_altfsid & dm_fsid References: <20050428021133.A885C4FE57@chewtoy.americas.sgi.com> <4278CDB8.3060309@ocre.cea.fr> <42829491.2080502@sgi.com> In-Reply-To: <42829491.2080502@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 5218 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: degremont@ocre.cea.fr Precedence: bulk X-list: linux-xfs Content-Length: 1382 Lines: 33 > Let's see if I can get the attachment right.... > > There should be an attachment here that has a draft of the fsid > changes. This is lightly tested. This looks ok but as you said, it need testing, i can do some of them, but i haven't a huge HSM system with dmapi support to be sure all is ok. The only problem i'm concerned is about the dm_send_mount_event code. (It's not a very important problem, just details :-)) You're currently adding more and more stuff to this function. Particularly concerning the filesystem registration code (dmapi_register() removal). I don't like having a function called "Send a mount message" like many others (send_namesp_event, ...) doing a job it isn't intended to do. I spent some time to understand the dm_send_mount_event() and dm_send_unmount_event() are the functions that registered and unregistered the filesystem. Moreover, it all these changes are done, the dm_send_mount_event() will have a lot of parameters, and I don't think a code with functions with 11 or 12 parameter is a good code. Maybe something cleaner could be done here... 'dm_register_and_send_mount_event' (like dm_find_fsreg_and_lock ? :)) Not really short but at least, very clear :). It is seems a good idea to register the filesystem in the same time it is mounted, but this implies a huge and ugly dmapi send mount event function ;) Aurélien From owner-linux-xfs@oss.sgi.com Fri May 13 08:57:51 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 May 2005 08:57:55 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4DFvpOv010925 for ; Fri, 13 May 2005 08:57:51 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1DWcXP-0001tf-8x; Fri, 13 May 2005 16:57:19 +0100 Date: Fri, 13 May 2005 16:57:19 +0100 From: Christoph Hellwig To: Aurelien Degremont - Stagiaire Cc: linux-xfs@oss.sgi.com, Dean Roehrich Subject: Re: vfs_altfsid & dm_fsid Message-ID: <20050513155719.GA7277@infradead.org> References: <20050428021133.A885C4FE57@chewtoy.americas.sgi.com> <4278CDB8.3060309@ocre.cea.fr> <42829491.2080502@sgi.com> <4284CDCE.9090905@ocre.cea.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4284CDCE.9090905@ocre.cea.fr> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 5219 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 302 Lines: 7 On Fri, May 13, 2005 at 05:54:54PM +0200, Aurelien Degremont - Stagiaire wrote: > 'dm_register_and_send_mount_event' (like dm_find_fsreg_and_lock ? :)) > Not really short but at least, very clear :). Just add separate dmapi_add_mount / dmapi_remove_function functions. Much more readable in the end. From owner-linux-xfs@oss.sgi.com Fri May 13 09:04:20 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 May 2005 09:04:24 -0700 (PDT) Received: from cirse.extra.cea.fr (cirse.extra.cea.fr [132.166.172.102]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4DG4JOv011481 for ; Fri, 13 May 2005 09:04:20 -0700 Received: from argiope.saclay.cea.fr (argiope.saclay.cea.fr [132.166.192.108]) by cirse.extra.cea.fr (8.12.10/8.12.10/CEAnet-Internet.4.0) with ESMTP id j4DG3oAN021782 for ; Fri, 13 May 2005 18:03:50 +0200 (MEST) Received: from pisaure.intra.cea.fr (unverified) by argiope.saclay.cea.fr (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Fri, 13 May 2005 18:03:50 +0200 Received: from nenuphar.saclay.cea.fr (nenuphar.saclay.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.12.11/8.12.11) with ESMTP id j4DG1uii011414; Fri, 13 May 2005 18:01:56 +0200 (envelope-from degremont@ocre.cea.fr) Received: from ocre.cea.fr ([132.165.65.70]) by nenuphar.saclay.cea.fr (8.12.10/8.12.10/CEAnet-internes.4.0) with ESMTP id j4DG3nZa022353; Fri, 13 May 2005 18:03:49 +0200 (MEST) Message-ID: <4284CFE5.60004@ocre.cea.fr> Date: Fri, 13 May 2005 18:03:49 +0200 From: Aurelien Degremont - Stagiaire User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us MIME-Version: 1.0 To: Dean Roehrich CC: linux-xfs@oss.sgi.com Subject: Re: [DMAPI] code error in dm_ip_to_handle() References: <20050513152947.909404FE8A@chewtoy.americas.sgi.com> In-Reply-To: <20050513152947.909404FE8A@chewtoy.americas.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 5220 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: degremont@ocre.cea.fr Precedence: bulk X-list: linux-xfs Content-Length: 868 Lines: 26 Dean Roehrich a écrit: > Certainly, dm_handle_to_ip() is intended to return any type of handle, > including filesystem handles. In the case of XFS, when a filesystem handle is > requested we contruct it from the filesystem's root vnode. > > I suppose dm_handle_to_ip() could be called with the handle from the mount > event. That handle would have a fid_len of 0, due to the memset() in > dm_sb_data()...the HSM would call to things like dm_get_config() and > dm_set_disp() with that handle. Yes, in fh_to_inode(), we could recognize the fshandle, using the fid_len value. But, in inode_to_fh(), how know that we must return a fshandle (with the dm_fid part filled with 0) or a filehandle (ino, len and gen filled) ? What's the difference between dm_path_to_fshandle("/") and dm_path_to_handle("/") ? (Assuming / is a DMAPI compatible filesystem) Aurelien From owner-linux-xfs@oss.sgi.com Fri May 13 09:33:31 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 May 2005 09:33:36 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4DGXSOv015397 for ; Fri, 13 May 2005 09:33:31 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4DIGsks004739 for ; Fri, 13 May 2005 11:16:54 -0700 Received: from chewtoy.americas.sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4DGVxR08015698; Fri, 13 May 2005 11:31:59 -0500 (CDT) Received: from chewtoy (localhost [127.0.0.1]) by chewtoy.americas.sgi.com (Postfix) with ESMTP id C74B94FE8A; Fri, 13 May 2005 11:31:58 -0500 (CDT) To: Aurelien Degremont - Stagiaire Cc: linux-xfs@oss.sgi.com Subject: Re: [DMAPI] code error in dm_ip_to_handle() Date: Fri, 13 May 2005 11:31:58 -0500 From: Dean Roehrich Message-Id: <20050513163158.C74B94FE8A@chewtoy.americas.sgi.com> X-archive-position: 5221 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 256 Lines: 16 >From: Aurelien Degremont - Stagiaire >What's the difference between >dm_path_to_fshandle("/") hlen = DM_FSHSIZE >dm_path_to_handle("/") ? hlen = DM_HSIZE(handle) Both use dm_ip_to_handle(), and get a full filehandle. Dean From owner-linux-xfs@oss.sgi.com Fri May 13 09:57:57 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 May 2005 09:58:01 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4DGvuOv020239 for ; Fri, 13 May 2005 09:57:57 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4DGvSxT015188 for ; Fri, 13 May 2005 11:57:28 -0500 Received: from chewtoy.americas.sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4DGvRR08016340; Fri, 13 May 2005 11:57:27 -0500 (CDT) Received: from chewtoy (localhost [127.0.0.1]) by chewtoy.americas.sgi.com (Postfix) with ESMTP id 98D874FE8A; Fri, 13 May 2005 11:57:27 -0500 (CDT) To: Aurelien Degremont - Stagiaire Cc: linux-xfs@oss.sgi.com Subject: Re: vfs_altfsid & dm_fsid Date: Fri, 13 May 2005 11:57:27 -0500 From: Dean Roehrich Message-Id: <20050513165727.98D874FE8A@chewtoy.americas.sgi.com> X-archive-position: 5222 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2412 Lines: 62 >From: Aurelien Degremont - Stagiaire >'dm_register_and_send_mount_event' (like dm_find_fsreg_and_lock ? :)) >Not really short but at least, very clear :). > >It is seems a good idea to register the filesystem in the same time it >is mounted, but this implies a huge and ugly dmapi send mount event >function ;) Even in its current form, dm_send_mount_event() is a dual-purpose call. It's responsible for registering the filesystem with dmapi, and for sending a mount event. I think you, and Christoph, would be advocating a split between dm_send_mount_event() and dm_add_fsys_entry(). Moving dm_add_fsys_entry() from dm_enqueue_mount_event() to dm_send_mount_event() is an obvious first move. Maybe the tokevent would not be created for the dm_add_fsys_entry() call, but would be attached to the dm_fsreg_t later, before dm_enqueue_mount_event() is called. I'm not sure how much breakage we'll run into. That would allow something like this: int dm_register_filesystem( struct super_block *sb, dm_fsid_t *fsid, struct filesystem_dmapi_operations *dops) This would be a stripped-down version of today's dm_send_mount_event() but would call dm_add_fsys_entry() to create a stripped-down dm_fsreg_t entry. int dm_send_mount_event( struct super_block *sb, /* filesystem being mounted */ dm_right_t vfsp_right, struct inode *ip, /* mounted on directory */ dm_right_t vp_right, struct inode *rootip, dm_right_t rootvp_right, char *name1, /* mount path */ char *name2) /* filesystem device name */ This interface would not change. This would create the tokevent and various tokdata structures, find the dm_fsreg_t entry and add more pieces to it, and call to dm_enqueue_mount_event(). I don't know what kind of problems we'll have to address if the dm_fsreg_t entry is not fully populated, if only for a moment. On the other hand, I sometimes wonder if we could change dm_send_mount_event() to throw away the 'ip' and 'vp_right' parameters--they're never used on Linux today, anyway, and apparently this hasn't caused any problems for our HSM people. The spec allows the mounted-on directory info to be invalid. Then we could swap those parameters for the two new parameters we want to add and call it square :) Dean From owner-linux-xfs@oss.sgi.com Sat May 14 11:47:52 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 14 May 2005 11:47:55 -0700 (PDT) Received: from pimout4-ext.prodigy.net (pimout4-ext.prodigy.net [207.115.63.98]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4EIlqOv001084 for ; Sat, 14 May 2005 11:47:52 -0700 Received: from taniwha.stupidest.org (adsl-63-205-185-30.dsl.snfc21.pacbell.net [63.205.185.30]) by pimout4-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j4EIlCqi119548; Sat, 14 May 2005 14:47:13 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id D85DA528F27; Sat, 14 May 2005 11:47:11 -0700 (PDT) Date: Sat, 14 May 2005 11:47:11 -0700 From: Chris Wedgwood To: Gregory Brauer Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: kernel OOPS for XFS in xfs_iget_core (using NFS+SMP+MD) Message-ID: <20050514184711.GA27565@taniwha.stupidest.org> References: <428511F8.6020303@wildbrain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <428511F8.6020303@wildbrain.com> X-archive-position: 5223 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 475 Lines: 11 On Fri, May 13, 2005 at 01:45:44PM -0700, Gregory Brauer wrote: > I have seen some references to a similar bug in other kernel list > posts from October 2004 and am trying to figure out if this is the > same problem, or something new related to the xfs_iget_core patch in > 2.6.11. This seems to be a very hard to reproduce bug, but we've > seen this problem twice in a week of testing under Fedora > Core 3 on the following kernel: does disabling CONFIG_4K_STACKS help? From owner-linux-xfs@oss.sgi.com Sat May 14 18:33:18 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 14 May 2005 18:33:32 -0700 (PDT) Received: from note.orchestra.cse.unsw.EDU.AU (note.orchestra.cse.unsw.EDU.AU [129.94.242.24]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4F1XGOv017806 for ; Sat, 14 May 2005 18:33:17 -0700 Received: From wagner With LocalMail ; Sun, 15 May 2005 11:32:24 +1000 From: Darren Williams To: Karol Kozimor Date: Sun, 15 May 2005 11:32:24 +1000 Cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org, nathans@sgi.com Subject: Re: [XFS] 2.6.12-rc4: Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 Message-ID: <20050515013224.GL31449@cse.unsw.EDU.AU> References: <20050512193647.GA22976@hell.org.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050512193647.GA22976@hell.org.pl> User-Agent: Mutt/1.5.6+20040523i X-archive-position: 5224 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dsw@gelato.unsw.edu.au Precedence: bulk X-list: linux-xfs Content-Length: 30239 Lines: 711 Hi Karol The guys from SGI suggested this patch, it reduces the messages but not completely on our Ia64 box. [SGI] We hit this internally as well with our tests. Christoph suggested the following: We're trylocking now if wbc->sync_mode is WB_SYNC_NONE, so having page_dirty set on startio isn't fatal. It should go away with the patch below: Index: linux-2.6/fs/xfs/linux-2.6/xfs_aops.c =================================================================== --- linux-2.6.orig/fs/xfs/linux-2.6/xfs_aops.c 2005-05-06 13:36:10.000000000 +0200 +++ linux-2.6/fs/xfs/linux-2.6/xfs_aops.c 2005-05-10 10:33:37.000000000 +0200 @@ -886,7 +886,7 @@ SetPageUptodate(page); if (startio) { - WARN_ON(page_dirty); + WARN_ON(page_dirty && wbc->sync_mode != WB_SYNC_NONE); xfs_submit_page(page, wbc, bh_arr, cnt, 0, !page_dirty); } On Thu, 12 May 2005, Karol Kozimor wrote: > Hi, > Just happened to notice, a couple of WARNs and possibly minor fs > corruption (after the system booted I went straight with SysRq+U, B and > still got some garbage in the logs). > Traces below. > > -- > Karol 'sziwan' Kozimor > sziwan@hell.org.pl > > VFS: Mounted root (xfs filesystem) readonly. > Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 > [] xfs_page_state_convert+0x334/0x660 > [] radix_tree_gang_lookup_tag+0x49/0x70 > [] linvfs_writepage+0x5c/0xf0 > [] mpage_writepages+0x23f/0x3a0 > [] xfs_mod_incore_sb_batch+0x5c/0xc0 > [] linvfs_writepage+0x0/0xf0 > [] pagebuf_rele+0x19/0x100 > [] xfs_trans_unlock_chunk+0x9d/0xf0 > [] linvfs_write_inode+0x36/0x70 > [] __sync_single_inode+0x6a/0x200 > [] __writeback_single_inode+0x60/0x150 > [] handle_mm_fault+0xce/0x170 > [] do_page_fault+0x174/0x562 > [] sync_sb_inodes+0x19d/0x2b0 > [] sync_inodes_sb+0x6e/0xa0 > [] fsync_super+0xa/0x80 > [] do_remount_sb+0x3d/0xe0 > [] do_remount+0x93/0xd0 > [] do_mount+0x16a/0x180 > [] copy_mount_options+0x59/0xc0 > [] sys_mount+0x7f/0xd0 > [] syscall_call+0x7/0xb > [...] > Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 > [] xfs_page_state_convert+0x334/0x660 > [] submit_bio+0x57/0xf0 > [] autoremove_wake_function+0x0/0x50 > [] _pagebuf_ioapply+0x1d4/0x280 > [] radix_tree_gang_lookup_tag+0x49/0x70 > [] linvfs_writepage+0x5c/0xf0 > [] mpage_writepages+0x23f/0x3a0 > [] pagebuf_iostart+0x44/0xb0 > [] linvfs_writepage+0x0/0xf0 > [] xfs_inode_flush+0xd7/0x1d0 > [] linvfs_write_inode+0x36/0x70 > [] __sync_single_inode+0x6a/0x200 > [] __writeback_single_inode+0x60/0x150 > [] xfs_trans_first_ail+0x16/0x30 > [] xfs_log_need_covered+0x73/0xc0 > [] xfs_syncsub+0x117/0x270 > [] sync_sb_inodes+0x19d/0x2b0 > [] pdflush+0x0/0x20 > [] writeback_inodes+0xf3/0x120 > [] wb_kupdate+0x95/0x100 > [] __pdflush+0xd5/0x200 > [] pdflush+0x1a/0x20 > [] wb_kupdate+0x0/0x100 > [] pdflush+0x0/0x20 > [] kthread+0x98/0xa0 > [] kthread+0x0/0xa0 > [] kernel_thread_helper+0x5/0x18 > Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 > [] xfs_page_state_convert+0x334/0x660 > [] submit_bio+0x57/0xf0 > [] autoremove_wake_function+0x0/0x50 > [] radix_tree_gang_lookup_tag+0x49/0x70 > [] linvfs_writepage+0x5c/0xf0 > [] mpage_writepages+0x23f/0x3a0 > [] pagebuf_iostart+0x44/0xb0 > [] linvfs_writepage+0x0/0xf0 > [] xfs_inode_flush+0xd7/0x1d0 > [] linvfs_write_inode+0x36/0x70 > [] __sync_single_inode+0x6a/0x200 > [] __writeback_single_inode+0x60/0x150 > [] xfs_trans_first_ail+0x16/0x30 > [] xfs_log_need_covered+0x73/0xc0 > [] xfs_syncsub+0x117/0x270 > [] sync_sb_inodes+0x19d/0x2b0 > [] pdflush+0x0/0x20 > [] writeback_inodes+0xf3/0x120 > [] wb_kupdate+0x95/0x100 > [] __pdflush+0xd5/0x200 > [] pdflush+0x1a/0x20 > [] wb_kupdate+0x0/0x100 > [] pdflush+0x0/0x20 > [] kthread+0x98/0xa0 > [] kthread+0x0/0xa0 > [] kernel_thread_helper+0x5/0x18 > Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 > [] xfs_page_state_convert+0x334/0x660 > [] submit_bio+0x57/0xf0 > [] autoremove_wake_function+0x0/0x50 > [] radix_tree_gang_lookup_tag+0x49/0x70 > [] linvfs_writepage+0x5c/0xf0 > [] mpage_writepages+0x23f/0x3a0 > [] pagebuf_iostart+0x44/0xb0 > [] linvfs_writepage+0x0/0xf0 > [] linvfs_write_inode+0x36/0x70 > [] __sync_single_inode+0x6a/0x200 > [] __writeback_single_inode+0x60/0x150 > [] xfs_trans_first_ail+0x16/0x30 > [] xfs_log_need_covered+0x73/0xc0 > [] xfs_syncsub+0x117/0x270 > [] sync_sb_inodes+0x19d/0x2b0 > [] pdflush+0x0/0x20 > [] writeback_inodes+0xf3/0x120 > [] wb_kupdate+0x95/0x100 > [] __pdflush+0xd5/0x200 > [] pdflush+0x1a/0x20 > [] wb_kupdate+0x0/0x100 > [] pdflush+0x0/0x20 > [] kthread+0x98/0xa0 > [] kthread+0x0/0xa0 > [] kernel_thread_helper+0x5/0x18 > Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 > [] xfs_page_state_convert+0x334/0x660 > [] submit_bio+0x57/0xf0 > [] autoremove_wake_function+0x0/0x50 > [] radix_tree_gang_lookup_tag+0x49/0x70 > [] linvfs_writepage+0x5c/0xf0 > [] mpage_writepages+0x23f/0x3a0 > [] pagebuf_iostart+0x44/0xb0 > [] linvfs_writepage+0x0/0xf0 > [] linvfs_write_inode+0x36/0x70 > [] __sync_single_inode+0x6a/0x200 > [] __writeback_single_inode+0x60/0x150 > [] xfs_trans_first_ail+0x16/0x30 > [] xfs_log_need_covered+0x73/0xc0 > [] xfs_syncsub+0x117/0x270 > [] sync_sb_inodes+0x19d/0x2b0 > [] pdflush+0x0/0x20 > [] writeback_inodes+0xf3/0x120 > [] wb_kupdate+0x95/0x100 > [] __pdflush+0xd5/0x200 > [] pdflush+0x1a/0x20 > [] wb_kupdate+0x0/0x100 > [] pdflush+0x0/0x20 > [] kthread+0x98/0xa0 > [] kthread+0x0/0xa0 > [] kernel_thread_helper+0x5/0x18 > Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 > [] xfs_page_state_convert+0x334/0x660 > [] generic_make_request+0x150/0x1f0 > [] radix_tree_gang_lookup_tag+0x49/0x70 > [] linvfs_writepage+0x5c/0xf0 > [] mpage_writepages+0x23f/0x3a0 > [] linvfs_writepage+0x0/0xf0 > [] _pagebuf_ioapply+0x1d4/0x280 > [] pagebuf_rele+0x19/0x100 > [] __sync_single_inode+0x6a/0x200 > [] __writeback_single_inode+0x60/0x150 > [] xfs_trans_first_ail+0x16/0x30 > [] xfs_log_need_covered+0x73/0xc0 > [] xfs_syncsub+0x117/0x270 > [] sync_sb_inodes+0x19d/0x2b0 > [] pdflush+0x0/0x20 > [] writeback_inodes+0xf3/0x120 > [] wb_kupdate+0x95/0x100 > [] __pdflush+0xd5/0x200 > [] pdflush+0x1a/0x20 > [] wb_kupdate+0x0/0x100 > [] pdflush+0x0/0x20 > [] kthread+0x98/0xa0 > [] kthread+0x0/0xa0 > [] kernel_thread_helper+0x5/0x18 > Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 > [] xfs_page_state_convert+0x334/0x660 > [] submit_bio+0x57/0xf0 > [] autoremove_wake_function+0x0/0x50 > [] radix_tree_gang_lookup_tag+0x49/0x70 > [] linvfs_writepage+0x5c/0xf0 > [] mpage_writepages+0x23f/0x3a0 > [] pagebuf_iostart+0x44/0xb0 > [] linvfs_writepage+0x0/0xf0 > [] linvfs_write_inode+0x36/0x70 > [] __sync_single_inode+0x6a/0x200 > [] __writeback_single_inode+0x60/0x150 > [] xfs_trans_first_ail+0x16/0x30 > [] xfs_log_need_covered+0x73/0xc0 > [] xfs_syncsub+0x117/0x270 > [] sync_sb_inodes+0x19d/0x2b0 > [] pdflush+0x0/0x20 > [] writeback_inodes+0xf3/0x120 > [] wb_kupdate+0x95/0x100 > [] __pdflush+0xd5/0x200 > [] pdflush+0x1a/0x20 > [] wb_kupdate+0x0/0x100 > [] pdflush+0x0/0x20 > [] kthread+0x98/0xa0 > [] kthread+0x0/0xa0 > [] kernel_thread_helper+0x5/0x18 > Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 > [] xfs_page_state_convert+0x334/0x660 > [] submit_bio+0x57/0xf0 > [] autoremove_wake_function+0x0/0x50 > [] radix_tree_gang_lookup_tag+0x49/0x70 > [] linvfs_writepage+0x5c/0xf0 > [] mpage_writepages+0x23f/0x3a0 > [] pagebuf_iostart+0x44/0xb0 > [] linvfs_writepage+0x0/0xf0 > [] linvfs_write_inode+0x36/0x70 > [] __sync_single_inode+0x6a/0x200 > [] __writeback_single_inode+0x60/0x150 > [] xfs_trans_first_ail+0x16/0x30 > [] xfs_log_need_covered+0x73/0xc0 > [] xfs_syncsub+0x117/0x270 > [] sync_sb_inodes+0x19d/0x2b0 > [] pdflush+0x0/0x20 > [] writeback_inodes+0xf3/0x120 > [] wb_kupdate+0x95/0x100 > [] __pdflush+0xd5/0x200 > [] pdflush+0x1a/0x20 > [] wb_kupdate+0x0/0x100 > [] pdflush+0x0/0x20 > [] kthread+0x98/0xa0 > [] kthread+0x0/0xa0 > [] kernel_thread_helper+0x5/0x18 > Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 > [] xfs_page_state_convert+0x334/0x660 > [] submit_bio+0x57/0xf0 > [] autoremove_wake_function+0x0/0x50 > [] radix_tree_gang_lookup_tag+0x49/0x70 > [] linvfs_writepage+0x5c/0xf0 > [] mpage_writepages+0x23f/0x3a0 > [] pagebuf_iostart+0x44/0xb0 > [] linvfs_writepage+0x0/0xf0 > [] linvfs_write_inode+0x36/0x70 > [] __sync_single_inode+0x6a/0x200 > [] __writeback_single_inode+0x60/0x150 > [] xfs_trans_first_ail+0x16/0x30 > [] xfs_log_need_covered+0x73/0xc0 > [] xfs_syncsub+0x117/0x270 > [] sync_sb_inodes+0x19d/0x2b0 > [] pdflush+0x0/0x20 > [] writeback_inodes+0xf3/0x120 > [] wb_kupdate+0x95/0x100 > [] __pdflush+0xd5/0x200 > [] pdflush+0x1a/0x20 > [] wb_kupdate+0x0/0x100 > [] pdflush+0x0/0x20 > [] kthread+0x98/0xa0 > [] kthread+0x0/0xa0 > [] kernel_thread_helper+0x5/0x18 > Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 > [] xfs_page_state_convert+0x334/0x660 > [] submit_bio+0x57/0xf0 > [] autoremove_wake_function+0x0/0x50 > [] radix_tree_gang_lookup_tag+0x49/0x70 > [] linvfs_writepage+0x5c/0xf0 > [] mpage_writepages+0x23f/0x3a0 > [] pagebuf_iostart+0x44/0xb0 > [] linvfs_writepage+0x0/0xf0 > [] linvfs_write_inode+0x36/0x70 > [] __sync_single_inode+0x6a/0x200 > [] __writeback_single_inode+0x60/0x150 > [] xfs_trans_first_ail+0x16/0x30 > [] xfs_log_need_covered+0x73/0xc0 > [] xfs_syncsub+0x117/0x270 > [] sync_sb_inodes+0x19d/0x2b0 > [] pdflush+0x0/0x20 > [] writeback_inodes+0xf3/0x120 > [] wb_kupdate+0x95/0x100 > [] __pdflush+0xd5/0x200 > [] pdflush+0x1a/0x20 > [] wb_kupdate+0x0/0x100 > [] pdflush+0x0/0x20 > [] kthread+0x98/0xa0 > [] kthread+0x0/0xa0 > [] kernel_thread_helper+0x5/0x18 > Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 > [] xfs_page_state_convert+0x334/0x660 > [] submit_bio+0x57/0xf0 > [] autoremove_wake_function+0x0/0x50 > [] radix_tree_gang_lookup_tag+0x49/0x70 > [] linvfs_writepage+0x5c/0xf0 > [] mpage_writepages+0x23f/0x3a0 > [] pagebuf_iostart+0x44/0xb0 > [] linvfs_writepage+0x0/0xf0 > [] linvfs_write_inode+0x36/0x70 > [] __sync_single_inode+0x6a/0x200 > [] __writeback_single_inode+0x60/0x150 > [] xfs_trans_first_ail+0x16/0x30 > [] xfs_log_need_covered+0x73/0xc0 > [] xfs_syncsub+0x117/0x270 > [] sync_sb_inodes+0x19d/0x2b0 > [] pdflush+0x0/0x20 > [] writeback_inodes+0xf3/0x120 > [] wb_kupdate+0x95/0x100 > [] __pdflush+0xd5/0x200 > [] pdflush+0x1a/0x20 > [] wb_kupdate+0x0/0x100 > [] pdflush+0x0/0x20 > [] kthread+0x98/0xa0 > [] kthread+0x0/0xa0 > [] kernel_thread_helper+0x5/0x18 > Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 > [] xfs_page_state_convert+0x334/0x660 > [] submit_bio+0x57/0xf0 > [] autoremove_wake_function+0x0/0x50 > [] radix_tree_gang_lookup_tag+0x49/0x70 > [] linvfs_writepage+0x5c/0xf0 > [] mpage_writepages+0x23f/0x3a0 > [] pagebuf_iostart+0x44/0xb0 > [] linvfs_writepage+0x0/0xf0 > [] xfs_inode_flush+0xd7/0x1d0 > [] linvfs_write_inode+0x36/0x70 > [] __sync_single_inode+0x6a/0x200 > [] __writeback_single_inode+0x60/0x150 > [] xfs_trans_first_ail+0x16/0x30 > [] xfs_log_need_covered+0x73/0xc0 > [] xfs_syncsub+0x117/0x270 > [] sync_sb_inodes+0x19d/0x2b0 > [] pdflush+0x0/0x20 > [] writeback_inodes+0xf3/0x120 > [] wb_kupdate+0x95/0x100 > [] __pdflush+0xd5/0x200 > [] pdflush+0x1a/0x20 > [] wb_kupdate+0x0/0x100 > [] pdflush+0x0/0x20 > [] kthread+0x98/0xa0 > [] kthread+0x0/0xa0 > [] kernel_thread_helper+0x5/0x18 > Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 > [] xfs_page_state_convert+0x334/0x660 > [] submit_bio+0x57/0xf0 > [] autoremove_wake_function+0x0/0x50 > [] radix_tree_gang_lookup_tag+0x49/0x70 > [] linvfs_writepage+0x5c/0xf0 > [] mpage_writepages+0x23f/0x3a0 > [] pagebuf_iostart+0x44/0xb0 > [] linvfs_writepage+0x0/0xf0 > [] xfs_inode_flush+0xd7/0x1d0 > [] linvfs_write_inode+0x36/0x70 > [] __sync_single_inode+0x6a/0x200 > [] __writeback_single_inode+0x60/0x150 > [] xfs_trans_first_ail+0x16/0x30 > [] xfs_log_need_covered+0x73/0xc0 > [] xfs_syncsub+0x117/0x270 > [] sync_sb_inodes+0x19d/0x2b0 > [] pdflush+0x0/0x20 > [] writeback_inodes+0xf3/0x120 > [] wb_kupdate+0x95/0x100 > [] __pdflush+0xd5/0x200 > [] pdflush+0x1a/0x20 > [] wb_kupdate+0x0/0x100 > [] pdflush+0x0/0x20 > [] kthread+0x98/0xa0 > [] kthread+0x0/0xa0 > [] kernel_thread_helper+0x5/0x18 > Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 > [] xfs_page_state_convert+0x334/0x660 > [] submit_bio+0x57/0xf0 > [] autoremove_wake_function+0x0/0x50 > [] radix_tree_gang_lookup_tag+0x49/0x70 > [] linvfs_writepage+0x5c/0xf0 > [] mpage_writepages+0x23f/0x3a0 > [] pagebuf_iostart+0x44/0xb0 > [] linvfs_writepage+0x0/0xf0 > [] xfs_inode_flush+0xd7/0x1d0 > [] linvfs_write_inode+0x36/0x70 > [] __sync_single_inode+0x6a/0x200 > [] __writeback_single_inode+0x60/0x150 > [] xfs_trans_first_ail+0x16/0x30 > [] xfs_log_need_covered+0x73/0xc0 > [] xfs_syncsub+0x117/0x270 > [] sync_sb_inodes+0x19d/0x2b0 > [] pdflush+0x0/0x20 > [] writeback_inodes+0xf3/0x120 > [] wb_kupdate+0x95/0x100 > [] __pdflush+0xd5/0x200 > [] pdflush+0x1a/0x20 > [] wb_kupdate+0x0/0x100 > [] pdflush+0x0/0x20 > [] kthread+0x98/0xa0 > [] kthread+0x0/0xa0 > [] kernel_thread_helper+0x5/0x18 > Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 > [] xfs_page_state_convert+0x334/0x660 > [] submit_bio+0x57/0xf0 > [] autoremove_wake_function+0x0/0x50 > [] radix_tree_gang_lookup_tag+0x49/0x70 > [] linvfs_writepage+0x5c/0xf0 > [] mpage_writepages+0x23f/0x3a0 > [] pagebuf_iostart+0x44/0xb0 > [] linvfs_writepage+0x0/0xf0 > [] xfs_inode_flush+0xd7/0x1d0 > [] linvfs_write_inode+0x36/0x70 > [] __sync_single_inode+0x6a/0x200 > [] __writeback_single_inode+0x60/0x150 > [] xfs_trans_first_ail+0x16/0x30 > [] xfs_log_need_covered+0x73/0xc0 > [] xfs_syncsub+0x117/0x270 > [] sync_sb_inodes+0x19d/0x2b0 > [] pdflush+0x0/0x20 > [] writeback_inodes+0xf3/0x120 > [] wb_kupdate+0x95/0x100 > [] __pdflush+0xd5/0x200 > [] pdflush+0x1a/0x20 > [] wb_kupdate+0x0/0x100 > [] pdflush+0x0/0x20 > [] kthread+0x98/0xa0 > [] kthread+0x0/0xa0 > [] kernel_thread_helper+0x5/0x18 > Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 > [] xfs_page_state_convert+0x334/0x660 > [] submit_bio+0x57/0xf0 > [] autoremove_wake_function+0x0/0x50 > [] radix_tree_gang_lookup_tag+0x49/0x70 > [] linvfs_writepage+0x5c/0xf0 > [] mpage_writepages+0x23f/0x3a0 > [] pagebuf_iostart+0x44/0xb0 > [] linvfs_writepage+0x0/0xf0 > [] xfs_inode_flush+0xd7/0x1d0 > [] linvfs_write_inode+0x36/0x70 > [] __sync_single_inode+0x6a/0x200 > [] __writeback_single_inode+0x60/0x150 > [] xfs_trans_first_ail+0x16/0x30 > [] xfs_log_need_covered+0x73/0xc0 > [] xfs_syncsub+0x117/0x270 > [] sync_sb_inodes+0x19d/0x2b0 > [] pdflush+0x0/0x20 > [] writeback_inodes+0xf3/0x120 > [] wb_kupdate+0x95/0x100 > [] __pdflush+0xd5/0x200 > [] pdflush+0x1a/0x20 > [] wb_kupdate+0x0/0x100 > [] pdflush+0x0/0x20 > [] kthread+0x98/0xa0 > [] kthread+0x0/0xa0 > [] kernel_thread_helper+0x5/0x18 > Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 > [] xfs_page_state_convert+0x334/0x660 > [] submit_bio+0x57/0xf0 > [] autoremove_wake_function+0x0/0x50 > [] radix_tree_gang_lookup_tag+0x49/0x70 > [] linvfs_writepage+0x5c/0xf0 > [] mpage_writepages+0x23f/0x3a0 > [] pagebuf_iostart+0x44/0xb0 > [] linvfs_writepage+0x0/0xf0 > [] xfs_inode_flush+0xd7/0x1d0 > [] linvfs_write_inode+0x36/0x70 > [] __sync_single_inode+0x6a/0x200 > [] __writeback_single_inode+0x60/0x150 > [] xfs_trans_first_ail+0x16/0x30 > [] xfs_log_need_covered+0x73/0xc0 > [] xfs_syncsub+0x117/0x270 > [] sync_sb_inodes+0x19d/0x2b0 > [] pdflush+0x0/0x20 > [] writeback_inodes+0xf3/0x120 > [] wb_kupdate+0x95/0x100 > [] __pdflush+0xd5/0x200 > [] pdflush+0x1a/0x20 > [] wb_kupdate+0x0/0x100 > [] pdflush+0x0/0x20 > [] kthread+0x98/0xa0 > [] kthread+0x0/0xa0 > [] kernel_thread_helper+0x5/0x18 > Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 > [] xfs_page_state_convert+0x334/0x660 > [] submit_bio+0x57/0xf0 > [] autoremove_wake_function+0x0/0x50 > [] radix_tree_gang_lookup_tag+0x49/0x70 > [] linvfs_writepage+0x5c/0xf0 > [] mpage_writepages+0x23f/0x3a0 > [] pagebuf_iostart+0x44/0xb0 > [] linvfs_writepage+0x0/0xf0 > [] xfs_inode_flush+0xd7/0x1d0 > [] linvfs_write_inode+0x36/0x70 > [] __sync_single_inode+0x6a/0x200 > [] __writeback_single_inode+0x60/0x150 > [] xfs_trans_first_ail+0x16/0x30 > [] xfs_log_need_covered+0x73/0xc0 > [] xfs_syncsub+0x117/0x270 > [] sync_sb_inodes+0x19d/0x2b0 > [] pdflush+0x0/0x20 > [] writeback_inodes+0xf3/0x120 > [] wb_kupdate+0x95/0x100 > [] __pdflush+0xd5/0x200 > [] pdflush+0x1a/0x20 > [] wb_kupdate+0x0/0x100 > [] pdflush+0x0/0x20 > [] kthread+0x98/0xa0 > [] kthread+0x0/0xa0 > [] kernel_thread_helper+0x5/0x18 > Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 > [] xfs_page_state_convert+0x334/0x660 > [] submit_bio+0x57/0xf0 > [] autoremove_wake_function+0x0/0x50 > [] radix_tree_gang_lookup_tag+0x49/0x70 > [] linvfs_writepage+0x5c/0xf0 > [] mpage_writepages+0x23f/0x3a0 > [] pagebuf_iostart+0x44/0xb0 > [] linvfs_writepage+0x0/0xf0 > [] xfs_inode_flush+0xd7/0x1d0 > [] linvfs_write_inode+0x36/0x70 > [] __sync_single_inode+0x6a/0x200 > [] __writeback_single_inode+0x60/0x150 > [] xfs_trans_first_ail+0x16/0x30 > [] xfs_log_need_covered+0x73/0xc0 > [] xfs_syncsub+0x117/0x270 > [] sync_sb_inodes+0x19d/0x2b0 > [] pdflush+0x0/0x20 > [] writeback_inodes+0xf3/0x120 > [] wb_kupdate+0x95/0x100 > [] __pdflush+0xd5/0x200 > [] pdflush+0x1a/0x20 > [] wb_kupdate+0x0/0x100 > [] pdflush+0x0/0x20 > [] kthread+0x98/0xa0 > [] kthread+0x0/0xa0 > [] kernel_thread_helper+0x5/0x18 > Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 > [] xfs_page_state_convert+0x334/0x660 > [] submit_bio+0x57/0xf0 > [] autoremove_wake_function+0x0/0x50 > [] radix_tree_gang_lookup_tag+0x49/0x70 > [] linvfs_writepage+0x5c/0xf0 > [] mpage_writepages+0x23f/0x3a0 > [] pagebuf_iostart+0x44/0xb0 > [] linvfs_writepage+0x0/0xf0 > [] xfs_inode_flush+0xd7/0x1d0 > [] linvfs_write_inode+0x36/0x70 > [] __sync_single_inode+0x6a/0x200 > [] __writeback_single_inode+0x60/0x150 > [] xfs_trans_first_ail+0x16/0x30 > [] xfs_log_need_covered+0x73/0xc0 > [] xfs_syncsub+0x117/0x270 > [] sync_sb_inodes+0x19d/0x2b0 > [] pdflush+0x0/0x20 > [] writeback_inodes+0xf3/0x120 > [] wb_kupdate+0x95/0x100 > [] __pdflush+0xd5/0x200 > [] pdflush+0x1a/0x20 > [] wb_kupdate+0x0/0x100 > [] pdflush+0x0/0x20 > [] kthread+0x98/0xa0 > [] kthread+0x0/0xa0 > [] kernel_thread_helper+0x5/0x18 > Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 > [] xfs_page_state_convert+0x334/0x660 > [] submit_bio+0x57/0xf0 > [] autoremove_wake_function+0x0/0x50 > [] radix_tree_gang_lookup_tag+0x49/0x70 > [] linvfs_writepage+0x5c/0xf0 > [] mpage_writepages+0x23f/0x3a0 > [] pagebuf_iostart+0x44/0xb0 > [] linvfs_writepage+0x0/0xf0 > [] xfs_inode_flush+0xd7/0x1d0 > [] xfs_inode_flush+0xd7/0x1d0 > [] linvfs_write_inode+0x36/0x70 > [] __sync_single_inode+0x6a/0x200 > [] __writeback_single_inode+0x60/0x150 > [] scheduler_tick+0x18a/0x380 > [] run_timer_softirq+0x132/0x1d0 > [] generic_forget_inode+0x54/0x140 > [] sync_sb_inodes+0x19d/0x2b0 > [] sync_inodes_sb+0x6e/0xa0 > [] pdflush+0x0/0x20 > [] fsync_super+0xa/0x80 > [] do_remount_sb+0x3d/0xe0 > [] do_emergency_remount+0xda/0xf0 > [] __pdflush+0xd5/0x200 > [] pdflush+0x1a/0x20 > [] do_emergency_remount+0x0/0xf0 > [] pdflush+0x0/0x20 > [] kthread+0x98/0xa0 > [] kthread+0x0/0xa0 > [] kernel_thread_helper+0x5/0x18 > Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 > [] xfs_page_state_convert+0x334/0x660 > [] submit_bio+0x57/0xf0 > [] autoremove_wake_function+0x0/0x50 > [] radix_tree_gang_lookup_tag+0x49/0x70 > [] linvfs_writepage+0x5c/0xf0 > [] mpage_writepages+0x23f/0x3a0 > [] pagebuf_iostart+0x44/0xb0 > [] linvfs_writepage+0x0/0xf0 > [] xfs_inode_flush+0xd7/0x1d0 > [] xfs_inode_flush+0xd7/0x1d0 > [] linvfs_write_inode+0x36/0x70 > [] __sync_single_inode+0x6a/0x200 > [] __writeback_single_inode+0x60/0x150 > [] scheduler_tick+0x18a/0x380 > [] run_timer_softirq+0x132/0x1d0 > [] generic_forget_inode+0x54/0x140 > [] sync_sb_inodes+0x19d/0x2b0 > [] sync_inodes_sb+0x6e/0xa0 > [] pdflush+0x0/0x20 > [] fsync_super+0xa/0x80 > [] do_remount_sb+0x3d/0xe0 > [] do_emergency_remount+0xda/0xf0 > [] __pdflush+0xd5/0x200 > [] pdflush+0x1a/0x20 > [] do_emergency_remount+0x0/0xf0 > [] pdflush+0x0/0x20 > [] kthread+0x98/0xa0 > [] kthread+0x0/0xa0 > [] kernel_thread_helper+0x5/0x18 > Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 > [] xfs_page_state_convert+0x334/0x660 > [] submit_bio+0x57/0xf0 > [] autoremove_wake_function+0x0/0x50 > [] radix_tree_gang_lookup_tag+0x49/0x70 > [] linvfs_writepage+0x5c/0xf0 > [] mpage_writepages+0x23f/0x3a0 > [] pagebuf_iostart+0x44/0xb0 > [] linvfs_writepage+0x0/0xf0 > [] xfs_inode_flush+0xd7/0x1d0 > [] xfs_inode_flush+0xd7/0x1d0 > [] linvfs_write_inode+0x36/0x70 > [] __sync_single_inode+0x6a/0x200 > [] __writeback_single_inode+0x60/0x150 > [] scheduler_tick+0x18a/0x380 > [] run_timer_softirq+0x132/0x1d0 > [] generic_forget_inode+0x54/0x140 > [] sync_sb_inodes+0x19d/0x2b0 > [] sync_inodes_sb+0x6e/0xa0 > [] pdflush+0x0/0x20 > [] fsync_super+0xa/0x80 > [] do_remount_sb+0x3d/0xe0 > [] do_emergency_remount+0xda/0xf0 > [] __pdflush+0xd5/0x200 > [] pdflush+0x1a/0x20 > [] do_emergency_remount+0x0/0xf0 > [] pdflush+0x0/0x20 > [] kthread+0x98/0xa0 > [] kthread+0x0/0xa0 > [] kernel_thread_helper+0x5/0x18 > Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 > [] xfs_page_state_convert+0x334/0x660 > [] submit_bio+0x57/0xf0 > [] autoremove_wake_function+0x0/0x50 > [] radix_tree_gang_lookup_tag+0x49/0x70 > [] linvfs_writepage+0x5c/0xf0 > [] mpage_writepages+0x23f/0x3a0 > [] pagebuf_iostart+0x44/0xb0 > [] linvfs_writepage+0x0/0xf0 > [] xfs_inode_flush+0xd7/0x1d0 > [] xfs_inode_flush+0xd7/0x1d0 > [] linvfs_write_inode+0x36/0x70 > [] __sync_single_inode+0x6a/0x200 > [] __writeback_single_inode+0x60/0x150 > [] scheduler_tick+0x18a/0x380 > [] run_timer_softirq+0x132/0x1d0 > [] generic_forget_inode+0x54/0x140 > [] sync_sb_inodes+0x19d/0x2b0 > [] sync_inodes_sb+0x6e/0xa0 > [] pdflush+0x0/0x20 > [] fsync_super+0xa/0x80 > [] do_remount_sb+0x3d/0xe0 > [] do_emergency_remount+0xda/0xf0 > [] __pdflush+0xd5/0x200 > [] pdflush+0x1a/0x20 > [] do_emergency_remount+0x0/0xf0 > [] pdflush+0x0/0x20 > [] kthread+0x98/0xa0 > [] kthread+0x0/0xa0 > [] kernel_thread_helper+0x5/0x18 > Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 > [] xfs_page_state_convert+0x334/0x660 > [] submit_bio+0x57/0xf0 > [] autoremove_wake_function+0x0/0x50 > [] radix_tree_gang_lookup_tag+0x49/0x70 > [] linvfs_writepage+0x5c/0xf0 > [] mpage_writepages+0x23f/0x3a0 > [] pagebuf_iostart+0x44/0xb0 > [] linvfs_writepage+0x0/0xf0 > [] xfs_inode_flush+0xd7/0x1d0 > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -------------------------------------------------- Darren Williams Gelato@UNSW -------------------------------------------------- From owner-linux-xfs@oss.sgi.com Sun May 15 05:36:08 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 15 May 2005 05:36:13 -0700 (PDT) Received: from flyingAngel.upjs.sk (gprs185-222.eurotel.cz [160.218.185.222]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4FCZtOv022027 for ; Sun, 15 May 2005 05:35:59 -0700 Received: by flyingAngel.upjs.sk (Postfix, from userid 500) id C0DB7100125; Sun, 15 May 2005 14:35:15 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by flyingAngel.upjs.sk (Postfix) with ESMTP id 9D9E6180122 for ; Sun, 15 May 2005 14:35:15 +0200 (CEST) Date: Sun, 15 May 2005 14:35:15 +0200 (CEST) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: linux-xfs@oss.sgi.com Subject: current CVS tree is unable to mount XFS FS on x86_64 Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="168429056-1878416461-1116160515=:17859" X-archive-position: 5225 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ja@mail.upjs.sk Precedence: bulk X-list: linux-xfs Content-Length: 19714 Lines: 319 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --168429056-1878416461-1116160515=:17859 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello. I upgraded my kernel code to current XFS CVS and kernel is no longer able to mount xfs FS. 2.6.11.9 from kernel.org works without problem. Platform is x86_64. XFS_VERSION_STRING "SGI-XFS CVS-2005-05-14_05:00_UTC" I enabled all debug options in kernel config (see attached .config.gz). Please ask me if you need additional information. jan Kernel output after mount: slab error in cache_free_debugcheck(): cache `xfs_bmap_free_item': double free, or memory outside object was overwritten Call Trace:{cache_free_debugcheck+295} {kmem_cache_free+55} {xfs_mountfs+1208} {xfs_setsize_buftarg_flags+61} {xfs_mount+1560} {linvfs_fill_super+0} {vfs_mount+164} {linvfs_fill_super+145} {sget+2626} {set_bdev_super+0} {get_sb_bdev+293} {__kmalloc+196} {do_kern_mount+181} {do_mount+2580} {do_page_fault+1175} {pagevec_lookup+23} {invalidate_mapping_pages+242} {error_exit+0} {copy_mount_options+183} {sys_mount+151} {system_call+126} ffff81001de0d370: redzone 1: 0x170fc2a5, redzone 2: 0xffff81000000000a. XFS mounting filesystem hda6 slab error in cache_free_debugcheck(): cache `xfs_bmap_free_item': double free, or memory outside object was overwritten Call Trace:{cache_free_debugcheck+295} {kmem_cache_free+55} {xlog_find_zeroed+268} {xlog_find_head+59} {xlog_find_tail+60} {xlog_recover+32} {xfs_log_mount+268} {xfs_initialize_perag+80} {xfs_mountfs+2001} {xfs_setsize_buftarg_flags+61} {xfs_mount+1560} {linvfs_fill_super+0} {vfs_mount+164} {linvfs_fill_super+145} {sget+2626} {set_bdev_super+0} {get_sb_bdev+293} {__kmalloc+196} {do_kern_mount+181} {do_mount+2580} {do_page_fault+1175} {pagevec_lookup+23} {invalidate_mapping_pages+242} {error_exit+0} {copy_mount_options+183} {sys_mount+151} {system_call+126} ffff81001de0d1c0: redzone 1: 0x170fc2a5, redzone 2: 0xa. slab error in cache_free_debugcheck(): cache `xfs_bmap_free_item': double free, or memory outside object was overwritten Call Trace:{cache_free_debugcheck+295} {kmem_cache_free+55} {xlog_find_verify_cycle+284} {xlog_find_head+492} {xlog_find_tail+60} {xlog_recover+32} {xfs_log_mount+268} {xfs_initialize_perag+80} {xfs_mountfs+2001} {xfs_setsize_buftarg_flags+61} {xfs_mount+1560} {linvfs_fill_super+0} {vfs_mount+164} {linvfs_fill_super+145} {sget+2626} {set_bdev_super+0} {get_sb_bdev+293} {__kmalloc+196} {do_kern_mount+181} {do_mount+2580} {do_page_fault+1175} {pagevec_lookup+23} {invalidate_mapping_pages+242} {error_exit+0} {copy_mount_options+183} {sys_mount+151} {system_call+126} ffff81001de0d190: redzone 1: 0x170fc2a5, redzone 2: 0xa. slab error in cache_free_debugcheck(): cache `xfs_bmap_free_item': double free, or memory outside object was overwritten Call Trace:{cache_free_debugcheck+295} {kmem_cache_free+55} {xlog_find_verify_log_record+568} {xlog_find_head+794} {xlog_find_tail+60} {xlog_recover+32} {xfs_log_mount+268} {xfs_initialize_perag+80} {xfs_mountfs+2001} {xfs_setsize_buftarg_flags+61} {xfs_mount+1560} {linvfs_fill_super+0} {vfs_mount+164} {linvfs_fill_super+145} {sget+2626} {set_bdev_super+0} {get_sb_bdev+293} {__kmalloc+196} {do_kern_mount+181} {do_mount+2580} {do_page_fault+1175} {pagevec_lookup+23} {invalidate_mapping_pages+242} {error_exit+0} {copy_mount_options+183} {sys_mount+151} {system_call+126} ffff81001de0d190: redzone 1: 0x170fc2a5, redzone 2: 0xa. XFS assertion failed: list_empty(&bp->pb_hash_list), file: fs/xfs/linux-2.6/xfs_buf.c, line: 349 ----------- [cut here ] --------- [please bite here ] --------- Kernel BUG at debug:56 invalid operand: 0000 [1] CPU 0 Modules linked in: ohci1394 ieee1394 emu10k1_gp gameport i2c_nforce2 i2c_core evdev ehci_hcd forcedeth dm_mod Pid: 2517, comm: mount Not tainted 2.6.11 RIP: 0010:[] {assfail+26} RSP: 0018:ffff81001cfcf918 EFLAGS: 00010292 RAX: 0000000000000061 RBX: ffff81001de0d1c8 RCX: 0000000000000150 RDX: 0000000000000000 RSI: 0000000000038afc RDI: ffffffff804e6d40 RBP: 0000000000000001 R08: 00000000000927bf R09: 0000000000000002 R10: 00000000ffffffff R11: 0000000000000000 R12: ffff81001e4b1af8 R13: 000000000000010f R14: ffff81001de0d1c8 R15: 0000000000002580 FS: 00002aaaaade4700(0000) GS:ffffffff80596d00(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00002aaaaac501d0 CR3: 000000001dbd1000 CR4: 00000000000006e0 Process mount (pid: 2517, threadinfo ffff81001cfce000, task ffff810001989070) Stack: ffff81001e4b1af8 ffffffff802b3c3e 000000000000010f 0000000000000000 0000000000002580 ffffffff8028b135 000000001d244b3c ffff81001cfcf9f8 ffffffffffffffff 0000000000001192 Call Trace:{pagebuf_free+78} {xlog_find_head+1077} {xlog_find_tail+60} {xlog_recover+32} {xfs_log_mount+268} {xfs_initialize_perag+80} {xfs_mountfs+2001} {xfs_setsize_buftarg_flags+61} {xfs_mount+1560} {linvfs_fill_super+0} {vfs_mount+164} {linvfs_fill_super+145} {sget+2626} {set_bdev_super+0} {get_sb_bdev+293} {__kmalloc+196} {do_kern_mount+181} {do_mount+2580} {do_page_fault+1175} {pagevec_lookup+23} {invalidate_mapping_pages+242} {error_exit+0} {copy_mount_options+183} {sys_mount+151} {system_call+126} Code: 0f 0b 6e 58 42 80 ff ff ff ff 38 00 48 83 c4 08 c3 66 66 90 RIP {assfail+26} RSP -- --168429056-1878416461-1116160515=:17859 Content-Type: APPLICATION/x-gunzip; name=".config.gz" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=".config.gz" H4sICEE/h0ICAy5jb25maWcAjDxLc9s40vf9Faydw5dUbWJJthV5qnKAQFDC iCBgAtRjLizFZhx9kSWvHjPxv98GKUogCVBziGN2N5uNRqMfQMO//es3Dx0P 29flYfW0XK/fvZdsk+2Wh+zZe13+zLyn7eb76uV373m7+b+Dlz2vDvBGuNoc f3k/s90mW3t/Zbv9arv53et97n/udgEtlwePLd+97p3X6/1+e/d7t+/1Op37 f/32L8yjgI7S+aCf9u++vpfP/bshVZdHQF8eGEsuD/FMEpaOSERiilMpaBRy PLngSwxGIR3GSJHUJyFaVFinmIk5Ho8uQILicJGKmEbK4DUWRKWKMhID7DfP hBKWhJp5rLC32nub7cHbZ4e6EFSi1GeoKR3lDAkAg0KA7/Y5A10fjrvV4d1b Z3+BTrdvB1Dp/qIwMhfwJiORQuGFHw4JilLMmaAhuYCHMZ+QKOVRKtn5M6N8 XtdazuPbhTGoD4VTEkvKo6///ncJlrNcwPJpIadU4AtAcEnnKXtMSEJM5Qyl D2rkmEiZIoyVRTnAC6vQfAklPrVRhhwYJkEqxzRQX7v353nhSoSJMX0TPvyD YJUmZAoKusDppPilCcmFNGUgbEh8n/gWMSYoDOWCSZO8hKXwv/lKk4DMVYxS gaS0sA4SReaGGQoeVjSDccoFWCD9k6QBj1MJv9hUOmaEGVaBQSw6ioB9hBXM q/zaaeBCNCShFcG5sMH/SFgOPwunaLQoPm2KlNtauF0+L7+tway3z0f4b398 e9vuDherY9xPQiKNRZ4D0gSWM/IbYBg7biL5UPKQwCoEKoFiZmoOQCejltb5 OTGWMT6R1WeynEcgLFeQ2G2fsv1+u/MO72+Zt9w8e98zvW4zY6GyyaAih5DY KsDZUYnE8lntpcIueDE8JulwoUBV/TsrslgcfROnJK76uxHnfooErVg8oxjW APeJVTz9GpOxEwdiU98hOOXlx0yBtZ+pwZmKK64VvJX1gyImhAllxUUJQzYX jGKl3awZO+SMchUOq3IxTBqAFOIACZtue4xin8aP0uLQ40ftUobkbCvbv7Md ePXN8iV7zTaHpkcXFXsVDALVMBlZxyh5oGYohslOpCCR31hvCAvqfUDPfy03 TxC4cR6zjxDF4ZO5nRbi0M0h231fPmUfPVlfkZrFZVz6KR1yrmogrZgYpkNV Y2KOkyEh9vnL0Qi7cUOkgOPCMo8FOlEKolNVlCn1Ca/BAlSnOgUjHtfgakxi hsLGIBCo2C0nHTI3UnFYi0PkJsCJVBzmWfrKOdIQ4UlIpUoXkJOY3jZHN0yk qiVZGyTBdW3wGalrQuD6vEOEVmY8KYTnkHpQsPavr6e0BRxXsMv+e8w2T+/e HpLH1eblYk+AToOYPFbC2QnmHMeZQCpkmF4FDC+DIKG0oH0SoCRU4O+mKaRL EDUYijBxiHChTSTEAIEwaROpydRKoTUs0ZSAmmz486cceB75BPj7FvYKDcOz fwGoVr73do5Jz7uVzsSrOXYuTsRnaR6V7Ihy6Vf8O/gZ4oMZiBRDSgWJMXeG gsI8QB4QsuGZ9j+WO/BIF+/nfDVfqtrBBA0mw+O+5OB9AHv1ssPT54+GKzVN GB5S8NKQD1ZhjJ2TwbMMScRjn8TEh1Bhjzz6RUmduJCMEF7kojtpIsSIbIxJ YAzRRA+HYYpu8HL3DMP8aKRKBpOctMnh0xO85X3brZ5f8hTkBKbeeHt4Wx9f DC9/KV+K5FlL1uBIfmVPx0OeuH1f6R/bHdQle+/GI6/H9bIWwIY0ChiUQmFQ qQAKKKPSVhlRdNs7FU/U9Og5HPHEXPRQ1ZhO4FSDNOCQh3T75bLws79WT5nn n9fCpfRZPZ3AHm8aIziWyEchj2wuAOKdrivSgMYsD8PDhIbGCg1mqU5MqyEx d3GpH1PILxuKZtnrdvfuqezpx2a73r68nwQH82bK/2hKBs/NmV9CIbeGMlFP bjO5hlxY8FhdPMwJAHNug0E5HHabCHBUFAKk7YWABkbkNRAy0VWqBcd1vG2C u73B3Tlj0gab5yrr5bt1GUSi6RnW26ef3nOhPMM0wwlMwDQNfJD/wgDF1JHu 6hewgKiAWtGYQl3bQqO/6SP80O+0kiS1mqlBgMExg50zHlnMsSTShdples6v xguh+AnXYBwN/dYPy/mgXfJhKzpGrEVgwMKoEqjQu+d6hUYU6mMWSEhyEyjy 9BbEmW04tJUY2I8hixIThf2pb4RRE6z3DQKItF8HRuivEMzy8qlhUBAH5NOP TFetZiylXAK1n0Zar+91KJJNmE+QH0K+1MTgoJIUIYVSDk4iJWrcTOwVuoF/ gt6wgN3EUKI2VjuYtLHzc1J1ATytq2y5hxI8A7e4fTrqYiT35Der5+zz4ddB e3nvR7Z+u1ltvm89KBj0IsmziYqLNFinEmRqNYSxn9aWWpOLT+XEVMQJlEJ0 UFQX6Ffex77NwqlODwVplQ5ogpALsbhGJbEj9mslKATCUo5V2LQikP3px+oN AOWE3Xw7vnxf/TK9lGZyKiArEbRcyczv33XadVDJfIrnVI51jIKK1MaUB8GQ 17KJGkmLSHozqt/rtvuAP7udzhWxfYZOSZtN6xqb7/jYpLy8naJE8boBAYpH 4UIbUquUiOB+bz5vpwlp935+2zIUxPwvd/O5bRyQ4NC5aPfyeoLbRYDMOwhJ Ow1eDHq4/3DbTiTv73udqyS37SRjoW6vSKxJ+v32IIO7vU77hwQor5UgkoMv d937diY+7nVgklMe+v+MMCKzdsmns4lsp6CUoRG5QgOa7rbPlwzxQ4dcUaSK We+hXZFTisA65g5L1x4IxezqYrWsMjoduldnfWVewkLDVeYutkjgmrFNI00n r5+LOjGQdk4nFsUO7Yfn1f7nf7zD8i37j4f9TxD/PzaTRFmJI3gcF1D7dmOJ 5tJBcOYa21KXkvmo3EWR29fM1AFUANnnl88grff/x5/Zt+2vc0noQQ12WL1B XRYmUbV60Wopwiag7FuImgR+14WOkm6SkI9GNBrZlat2y80+FwUdDrvVt+PB DGf5+1LvoSkFmddrBR7gM7j6QZr/zHH2j663f38qDsUuOxwNbd/OUrDxOaSY 1HcPDqgeXEuhEKNeaNfQCLd/AFH8pf0DBYHTI52JHhxcGBkhLYN2VRCo22mK 3QnbgVE+VZDEVXbfS2CKxpi6xctJwBO2DAAI6h68wSGaNmwhh8PyZlSSK99/ lIrH12Sc312joOFVCnmFIgmv6Qp88FUKRWTbmIeJhJVJsZvCZ/Pb7kO3xayI K2k/Y2HSuJsiSFQCiaXPGaItTmbkV+uY2nIXLfrUxWCbBIBHXUfmUIQG0TJC yljLNCzY/S0ewNLstQnfYnKP+QSBPxNXaQJ8laTbG3Rcy+cxRJCszBvLR8O7 bd5HE/SuEdy2KTgn6PVaCfq33RYCH98+3P9qx3dUC75+dFBsqOnQ+KmaRngf cmett5TCqRn4md8smJmxk8DAc0LljuIKSDPrNCBdcxZKmF2BJ+x9G7LvQubR XSDH0gKC/DRj0ZLJ+ewivM+KfaIKREZIyDGvAhmNYx5XQH+SmJfpS3DUrT+e Ppxt5HBn6YJEH7A3i2RCiNe9fbjzPgSrXTaDfx8t2xtApYnOCdPx2/59f8he bdu4JXE6JfGQS+I+Uj1T8gRsyprKlhRFB0fZf8SZudlT0lyw4CRycV0b0k0J oJQNF9G8TQQOAdlUgthtD9un7drg29CAPh49vVPHyaHomXZbQaRivJC6balV J2rs4O1PHYgYzSi3wDETFihU1kqUw6U93mJeGlu3rSg7/L3d/VxtXpoWFRFV zo5B1jyfR3hCKpvo+jllRefWpf+AKHAW+RKzKCyJqNHfA7TphCyM4RayXIYi ioWOkaO6AALkT/X5I/gLnigSu8hqu+WmvICmbchRbM9EUCx8a0OXbkHjE2r2 8+iRQR5ZHWpKpKhBqNDnOTWgSqKIGEcPMByFhU/RqGK1Zyj8Ou03/Yv43Zuu dofjcu3JbKdPfiqNERUbEulUOlRZZX3RVEDDWhvEGeiIUloiMLnvq/XBIsxF lCjQDiUCt4MnFS1ohMob6wxNV+lThuJJzaaK1yCxVhyCqBK2lZ1TBUrUNAxA GmOXkQFWBUq0oJE+zEbODxYNhLUhUpEfdcs6nCGFxxCaGVV2FORnKBoRO5Ih bEeIiVIL4XwrnjgweUSunLOZaMUd8sdEn6jbcQRHdoQvsbBj0Li2qkxVkWik xg75VOhAYMGkQ/YxCQWJ7Tjdm+FQotOYCzSfRS6myPdj9+TEBIWsabAnedoM vZSLMedcaKHdsz9Gcmy1xJNXqEEVikfg2GKi+1QdSEj8HZjEjbLPVoSUBQT+ CTIiv+46TpwYkrAaY+QTp/Cntgo7GpyfDo12pESM2CSSERPpEEmKbdjCHdW0 H41Cl4SWNXfCWBbWCWNbWWeNNGf/hMIhkpIGCxfaYTvntxMJRkIbH4YcyaVd bl1AEJLtvhIQdksEREOJ8yA22r30U96ndE659Uqq9hR+MPvRP9YiaX3lGUed jmPvmPqOPfNpiKJ00Ol1H61oHyaW2FOlMMQ9R2CaO6RDof3QaN6zF20hEkNn HuXrzg+7aAT+d0g9g+E2E7tcwY9bqYvZm+3O+75c7bz/HrNjVum505/Nz5ir KafU3gyqwD9oEBRJWkXQEg1mpi878MBHC+eoSmJ72/KZYvh4sa4SOFZDCzCQ uAkVsVkqlFBwQE2gDCyfUuQxtECHQRM4snL1ZXX5lnD4n7AmmEbAxnTDGvHI ZXUeiAT9ImX2oka5N5ANAPh1GvlkXuWoEblx3DngTT7BrEma3PaMtokCkLc2 1i1D42hk7cE4vXVKNuuyyGkljzThjmQ6xyMzr80LCJ228pCa7ZIlfITMUDRC RYY7bDLQWxj1OdZwau5/nL8GQU6Vju9UHnqHbH8oFlplSJA4urbgAa3vcjiX kUbmLbUx/OIo4saIQTR27IfS2NWGpOwKhvoU1GhYmp8wtqh0UPDIrx39XDzW Y4JC+qdDUpU0d3dQjDfZwWjNMsrIus8umg8PP/R9soP3odvxwMd1Ox32bXX4 WHVvRDeSFVXz+R5D5YhwjIRYMEgM7VuICdQHzDktUxL5PE5vITFsyKeO69Ub eN7X1frd25wsw70rUdSxoaPQHouutUcit41qY4TQ2rq1hzLE/EG32623Dl3w PhKKYJ2bxwF1lPXDuzvb1aS8AYPk5cMl3I5ie5VMCKw919Y8cSECmKbIHowh /ZOEUcdM9Sb1/tUzctC9fcDCiVLccb5A5YNLfEGx89Qhgeo2wo7chaI0HtOI tNo6cC7t3Gj2J5HjsMcPexOnlu1CRnJwO3A0f4CTQXhsV+WChCGfBdTWhBgP uv0H0zRyAEybcJyGTR4GoePYSOtpSkKOqbInHoqOeHR7RYsWNdL5yJ6fyR5t 7hmq7c9s48V6M9DitVQzIdM71utsv/cgR/U+bLabTz+Wr7vl82pbc1q5Gy/3 HPm3/XadHbLL67qLe385tXjbZZ8g4/3c7X6stijHVLhlKN745lGJbvTaqDCt NICTuNaPbubnpNnMJnar/as3Ujf+MTuA3MWXPixvvt28fNTt5nnz+rej9WuQ yUl2f+dwdTPwSaFOnE66mS033qq8pFRRP+TFdhfi+3aDG1PhMEVRc8olWFRy Fngstnj07q6dPD3vABowJBcRrjPSsFRZj2c0WrcjVjZPNHAo/dPWqMmKOw6J w5YdXddxI4RKR0CHt3SvCA8tDbLSj2CiT4cwldWmMY1FBdb59mO7ebfdRRBj bnGOdPN2PDhbgmgkkvP+fbLPdmt9wFcxGpMyZTzR50DTypZoBZMKiRLr8UuV TOKYkCidf+12enftNIuvX/qD+vf+4IvaIUGNQEn7IUKBJVM9itf6S2Rq3WnO dUhvePNa0AgxUt22lByimAm/XFI9wSCE3N/bO8PPJOGd9RrmCUtY0u1Mulbm U/jh6HE80wRs0Om2k2B51+9ae06qdxLyx5QOOne9SvtLDoafmpl9weQUWA16 +IvjjLcgEVAVORrtTwSYCtlziZqGdAjopnAxmjlmunHMWLGRCVnkTb/GjfkT BFw+SFq52V5iILVxDeJME06ukszVVZKIzJT1poOxuMwr4fCY1vRTAIsrK477 3ppgKufzOUItaxAWKVTpeNK2THmCx8VCd8tMzTvYBUxgKSZxHZoUDq28VPlj uVs+6dOhxp2WqVHzTPMtRu2fjb9WMTNgFcNBYRoVnX++7R6ZzHar5brpKE6v Dnr3HQtHDU4tQcJKl99Ptlt7SRLFaYJiJb/e2VmQuYLijDTFjyDv0hQAycdh vxN1YoV5bKhMn84+DFKhFpVNsfJSH4Ctt8HyS9CmJwuFTRPnoF3z27qPI7ac DTJa3UdlFLLzyA8tW4Gz5eHpx/P2xdOZVy1PUnjsc3sVDyYSA0fuKICn9us7 sarcBfCVY5c0vn3o2xvuoCQPqa2mDorWXMjjve/r7dvbe96rW8b+wiIrnST1 qx3lB0bGrRx40IVx/udlLiIAML/VnzI8tnDw48pBEjymyg/sQUkj425vYGej s33Cozo3NkJOZq4mQzZDU/vigkhguVtY+Rs1jnIvGuExwZPi79o0rbCHLSlX zzyd6eEU6z+EkBv1+SW0ftnuVocfr/vKeykKR3xIK0lFCRY4sHvZMx5Z5RuD zf+93GX5tWBrPwgurm7c3rfwB3z/th1vvfqRY5n/5b7fGFMOTeXdYNBzv6j3 a+pvUlduUyC7HQc7qPWqExPluza9Ov/TdUvnJ8rrmCEdjVuoYi7R1HW5QVMU aFfT7a9eR0eCoft1fS/i4b4N33dcUDmhH/pzN1ol7k+7WnRPOBi6G825z7nb lMCM9UQ1TPlsxjLb7Le7PcT+1ZvLniWB8OJoPs1RMkU+g8Kk+w9o7v8BTf86 ze2Vb8mhc9fsROLLbv+KxIE+z2of+Ci87w4ka6WhavCllSBkDm9wIfhyf43g 2ie+DK4QDDrXCK4JObgm5FU9PLTLwP7X2JU1J45r4b9C9Uu/zFRjjMHcW/Mg b0EDXtqSge4Xik6YNDVJSAGpW/n3V4ttJFtH8NCp5nxHq4/WswhtnIkzs/IU oT91J/Z8SErC8TRwZ9M72FK7kLAROvEnyMqz9t2pD5nHX3mWU9+D/GOuXJPR dN4PU5Hz+0ixREFDuclCXJenN/ow8b3p+DbPzN43bPfme8C+jM8sMk4B3xff YOFL8g2WAIido5QzN9xhRruXl93563ng/Pm/A5sQf33oW1qnb+59OD+aLmlx kLJ5JzWbh7/unw47w7mKG8pule3M6vC0Pw6S40mGOWyCSEgyetq9X7Rjkkwf UH/sq+tuTV5/D1EK3HpzhvAGvp7NACfAOn0BrFwSJgh5o/HkNssMUuzF5dYd urYqEMrvt4mF42deosxehanjji0c6SawoFERWtB5vMFVus3LjhG6me0hTnGG bT2+8X0LnK/YBzWKeck1A6oAKbv5COe8ZBrDii3JxKZfDGuFG56YfZO+giM6 PB8u7IQsJTk4HXdPjzuh2W7Cj6iViowOnrKRQi6uW89a1qukR6LhpkvDvYR0 JefDZgA+nHbvvw+Pxs19AleKxEsZ9KeOqvnG9SyDp8P5nQcUkYfJ/uFm9YD6 dylCN66Qa1fNj7cn5UaB35o2VW5Dr8nIqIJ1gE6Pvw+X/SOPEKikyxRbBPaj jjCqkYow1QnzdRQXOokdAVMcYZ1I4u9VnIXd/AgPeFXr+xVyTgiPxaNcjTJi ijdszOeqNUtdpT6xLU5AWjbs0FeH+ulUm4ZNg69rFaPXHht1EFbzkpZFgGF1 E+CnN7mLJF1DB1EcLnnvgeWktEArEK1vkypn4nlDOI+iGg8dQ9wmbK4oCmfT LY/IGHZry46j3thzwJIswQausAipkcJMle87Qys8ssOuBf5JXdd4YyJkhe3O N902C6KIjBLyEL9g1vzaH/Jpk/DId4CCDVoJhWzJFA2d4QSEF3n54IwgLzg5 xhCkZGBwlo48OPcyjd2RDZ1N7KgHp55HBBYjysMnZXC1f6QJtHhJISZjyERB dGqKbcnZftZxp8MbODxGYuLMXN8KT2C4XlNdkAFWUHEUh7EztQiEwEdjQEzF xaW/GXbltKHDg5rkGQ5XOAAU/nImRP7IMoBq/MbssdqMdLdQqZ8lgWmbzhMw SAR+zsEsOUdFNqMf/YPW+/6tXmNJo4bWdJkFN03WekuQ+ZQCfGKBh2lHADX0 Olm0lmcRbqmf3cz6Xo/d0nozU4chtgj8lcGeA2E7mNzGYtgsmjlcCwsO5xb0 lhAKJuvkIuvBhILb3d9gKbCt0+3xUCRPTqwVXYkdkoVDrtaehSPhGm8LLqZp ax1R5Mz026J2wPW2uIyo6LzYqBKbqGZby8/Se3YAf9sfP84ig54rpEzD7UcT oucUoCxa44jOtaianP1HhlIcsjGS5YDNIGczBDTW8JyawsSKuaOUXjjbeRjp dWoR7jXbWoqwds2P5ws/F1xOx5cXdhboact56pglEnm+9qikWGK6xSTXyxNY med0O6+CLaU6mjf5dTqoqulw1yx9x+lytG2pFf7hy+58NgVGsU+v4tMtq5iy Ws+7hkkaF7hJFgWEKfB1rkpSqaPNafyfgWgVzUuuQti/8TCjZxHi5Q/ho/9V RsE5nP9tJPjr4JUd3HYv5+Pg137wtt8/7Z/+KwLZqTnN9y/vIobd6/G0H/AY djxoqeZSqbDrn7UmtgPCAJVrHnBYiyarpUQUJSgwg0kZx2GemkFMotFwCOTK D4BGZF6wXfhwbwZJFJXDGYx5nhkTof3nOVUHi2pX0hkic9wZHYzQmGUp9nds mksA8WCgNMm6jk0cDYIj42xd2wGhhqxJhLByIw9YWnFB4wUIr1EIXMnKYikK QFREU04RhQtPhdUICMcPaIk2ILwpENxqdrrblnGa09g4U+DX3TNg0yoqFoU+ sCmX4z8s8063tVkbr1X1ZQAFnBHKnS0pCO7ziAQlCOIgtaVd8D0HWofwyrLy HAeefOPx0IJms9AZjmCcribA4ty4lJiuAXnSEFG4zgu0hiz9hRQyKYLC13O8 pGxJ8eBvzf6ZHDN4tYVRDTAiK0KmI3Nra9MituayhBft+q3T3V3DrauMadsT oApxiifw52AooM+Uq2RckjVawgOsxLlnGSLL+CGnfAKAOSzL/DKGsfCHeKYA /uBz7jdJF5jeYmEdvIK3Ajiyz5w0JmaxQDT9FpGl8lla6GH39Ly/mKx+eY4P iNeqr6dJw28kElZNJlFhsMH+8Z/D2yHgOwiT7pz9zTDfpfZtjw6nV6F/720D 46h98iXhYdClqbP2GBMdbRPlLrQmbDc8jp3ynk9Nlq8loVB7bqIBSRxWJTba hjMWd6tuuWuCoRzXVo57o5y/dRNQ9hN8oYFllAYidLLyJleMmXwlRHbJVRnR kIXBkVlf0bDUsf+T3GR/ds2+23AVMjZeZbB1QFN55bcxv7+BfDQGOOqQSE7Z gs1tTIm5e9VyhQxuEtI/021kjT/V3/FG2G+rLzkkXAFseqaHAd+rXA8AyIlR CnnwbOxduOlUXc1T311zEndmj/XXiDKWNDEvXmWeiuaaDejAGosGGqoq6PIN siYPdkDh3vzao2Q07xWqYWMpMnK6EcFFv0WrSEwZvRmDHRpnk8lQF7J8iVVH xp+MSf2k8reWpIqS3u9s2brPRDn5liD6LaPmWiQ8poL66BZhKTTKqsuSiAdX 5FMpXDVR8DOU741MOM65YSBhbfpyOB9935v96SjR3DPa60+pDznvP56O4sWJ Xo3rWK+Kiw0nLHQzXvKDJER/e2EFfToGFVSbStRUNWQRc5oWelmCIDMzW1xW bKFbBoDw1ui26JjVtfrcNCHmixq9uxSPT3ikoATG5laoWFYgHMRw0gCGLKlC 0Wyzjn1jqWcBY9+zzRhG+dMiEFaZhbbZx4sNAumKbdYZt/z3ytXc6znFbPHA IRlpBZuWQwar8R3Yr37WUSdvFaGhYivNNWtR5ydLq24t+JqijkBSZaX6FKT8 vX1QdcOMwMYQp20XZeAZAVIsUle7o08DUCIwAGRhAabJIwSPBPNMtDtdDiK+ Cf181w+zBSopD06atfHXDP0r59OWtY0yt7uwHeZguXt7/tg97/tvr2VaBIgl aWbUv758XP7xv6hIMwdvx+5UC7GgYlPXbFSnMwH2jBqT7xm91HWWEVgR37ur jDtq6wPmhB0m5x6m0T1M7j1M43uY7ukCwMarwzS7zTRz78hp5g3vyemOfpqN 76iTP4X7ie1x+EZh698SM4e7IUFyxkAHyACRECtGMmqZjpncE+cGcG+24nY7 vZsck5sc05scs5sczu3GOGOgS1sGr9tTixz72xLMWcAVkGtFE1+Jb8r2N3r0 TsWlPE+4V3bfDGghH6T+vXv8V4uLJG1PFzxwiLLpTxEPtMzWfvFSSuumMOfv 3iGqRkoRyclSveavab33p3W6fBOzi9bPFXfJ/PjbpakLrzhGs2arHoSYdk9X 4s3TLnEh3iYlXa5ljBatddv+UT5AbXiqbxEbPeGabbLuHShp3IV8nZcLS7Jt iAoUsC9JO0GpWgauVOOP1QEGzjUX+89ytbzFwwRGd/KWDTx9vl+Oz9LgsK/4 lI9pKZ9A/N7OeSzJLjGrloqpW01Mo7GB5vVoZI4cE3Ek3Ix6ZM8Z9cjrwkSN 1NBwNS0QUT3IvAewL2akc6doLU5iTUeGzHnoWs9I7beExqifZxn2u2wxRz9R 1OfNqgATQ5s74RSajsfsfMo9ANVog00Fy9AdhYYaktY3t3XYeRRCo6g85JvX h1+n3elzcDp+XA5ve02Kwm0YYqp1YKgG4VrioFuBn4zGpwS9JYJ6bd//AUoj q6W+fwAA --168429056-1878416461-1116160515=:17859-- From owner-linux-xfs@oss.sgi.com Mon May 16 00:34:23 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 May 2005 00:34:27 -0700 (PDT) Received: from cirse.extra.cea.fr (cirse.extra.cea.fr [132.166.172.102]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4G7YMOv028766 for ; Mon, 16 May 2005 00:34:23 -0700 Received: from argiope.saclay.cea.fr (argiope.saclay.cea.fr [132.166.192.108]) by cirse.extra.cea.fr (8.12.10/8.12.10/CEAnet-Internet.4.0) with ESMTP id j4G7XmAN025303 for ; Mon, 16 May 2005 09:33:48 +0200 (MEST) Received: from pisaure.intra.cea.fr (unverified) by argiope.saclay.cea.fr (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Mon, 16 May 2005 09:33:48 +0200 Received: from nenuphar.saclay.cea.fr (nenuphar.saclay.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.12.11/8.12.11) with ESMTP id j4G7VkJh012404; Mon, 16 May 2005 09:31:48 +0200 (envelope-from degremont@ocre.cea.fr) Received: from ocre.cea.fr ([132.165.65.70]) by nenuphar.saclay.cea.fr (8.12.10/8.12.10/CEAnet-internes.4.0) with ESMTP id j4G7XjZa004587; Mon, 16 May 2005 09:33:45 +0200 (MEST) Message-ID: <42884CD9.2080209@ocre.cea.fr> Date: Mon, 16 May 2005 09:33:45 +0200 From: Aurelien Degremont - Stagiaire User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us MIME-Version: 1.0 To: Dean Roehrich CC: linux-xfs@oss.sgi.com Subject: Re: [DMAPI] code error in dm_ip_to_handle() References: <20050513163158.C74B94FE8A@chewtoy.americas.sgi.com> In-Reply-To: <20050513163158.C74B94FE8A@chewtoy.americas.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 5227 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: degremont@ocre.cea.fr Precedence: bulk X-list: linux-xfs Content-Length: 592 Lines: 28 Dean Roehrich a écrit: >>What's the difference between >>dm_path_to_fshandle("/") > > > hlen = DM_FSHSIZE > > >>dm_path_to_handle("/") ? > > > hlen = DM_HSIZE(handle) > > > Both use dm_ip_to_handle(), and get a full filehandle. Ok, ok But, in inode_to_fh(), how know that we must return a fshandle (with the dm_fid part filled with 0) or a filehandle (ino, len and gen filled) ? Could you explain the behaviour of inode_to_fh() ? (Especially the differences related to fshandle/filehandle) dm_handle_to_ip() is always called using a filehandle ? (never a fshandle ?) Aurelien From owner-linux-xfs@oss.sgi.com Mon May 16 02:42:05 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 May 2005 02:42:13 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4G9g4Ov001471 for ; Mon, 16 May 2005 02:42:05 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1DXc6L-0005RB-Dp; Mon, 16 May 2005 10:41:29 +0100 Date: Mon, 16 May 2005 10:41:29 +0100 From: Christoph Hellwig To: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [XFS] 2.6.12-rc4: Badness in xfs_page_state_convert at fs/xfs/linux-2.6/xfs_aops.c:889 Message-ID: <20050516094129.GB20828@infradead.org> Mail-Followup-To: Christoph Hellwig , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org References: <20050512193647.GA22976@hell.org.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050512193647.GA22976@hell.org.pl> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 5228 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 345 Lines: 9 On Thu, May 12, 2005 at 09:36:48PM +0200, Karol Kozimor wrote: > Hi, > Just happened to notice, a couple of WARNs and possibly minor fs > corruption (after the system booted I went straight with SysRq+U, B and > still got some garbage in the logs). > Traces below. should be fixed in current CVS. I'll send the patch to Linux once he's back. From owner-linux-xfs@oss.sgi.com Mon May 16 03:53:07 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 May 2005 03:53:17 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4GAr6Ov005967 for ; Mon, 16 May 2005 03:53:07 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1DXdD7-0005fB-LK; Mon, 16 May 2005 11:52:33 +0100 Date: Mon, 16 May 2005 11:52:33 +0100 From: Christoph Hellwig To: Jan Derfinak Cc: linux-xfs@oss.sgi.com Subject: Re: current CVS tree is unable to mount XFS FS on x86_64 Message-ID: <20050516105233.GA21698@infradead.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 5229 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 775 Lines: 18 On Sun, May 15, 2005 at 02:35:15PM +0200, Jan Derfinak wrote: > Hello. > > I upgraded my kernel code to current XFS CVS and kernel is no longer able to > mount xfs FS. 2.6.11.9 from kernel.org works without problem. > Platform is x86_64. > XFS_VERSION_STRING "SGI-XFS CVS-2005-05-14_05:00_UTC" > I enabled all debug options in kernel config (see attached .config.gz). > Please ask me if you need additional information. I've seen the same issue on my x86_64 box (although it's actually runnin an i386 kernel!). Unfortunately I managed to reboot the box in a way so that grub can't mount root anymore because it's XFS implementation is a POS. If you have some time could you try binary-searching what day they issue appeared? If not I'll do once I'll get a little time. From owner-linux-xfs@oss.sgi.com Mon May 16 04:16:35 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 May 2005 04:16:41 -0700 (PDT) Received: from flyingAngel.upjs.sk (user.novell.cz [195.47.104.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4GBGYOv007987 for ; Mon, 16 May 2005 04:16:34 -0700 Received: by flyingAngel.upjs.sk (Postfix, from userid 500) id 80F69100085; Mon, 16 May 2005 13:15:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by flyingAngel.upjs.sk (Postfix) with ESMTP id 7FACD180123; Mon, 16 May 2005 13:15:53 +0200 (CEST) Date: Mon, 16 May 2005 13:15:53 +0200 (CEST) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: Christoph Hellwig Cc: linux-xfs@oss.sgi.com Subject: Re: current CVS tree is unable to mount XFS FS on x86_64 In-Reply-To: <20050516105233.GA21698@infradead.org> Message-ID: References: <20050516105233.GA21698@infradead.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5230 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ja@mail.upjs.sk Precedence: bulk X-list: linux-xfs Content-Length: 1084 Lines: 31 On Mon, 16 May 2005, Christoph Hellwig wrote: > On Sun, May 15, 2005 at 02:35:15PM +0200, Jan Derfinak wrote: > > Hello. > > > > I upgraded my kernel code to current XFS CVS and kernel is no longer able to > > mount xfs FS. 2.6.11.9 from kernel.org works without problem. > > Platform is x86_64. > > XFS_VERSION_STRING "SGI-XFS CVS-2005-05-14_05:00_UTC" > > I enabled all debug options in kernel config (see attached .config.gz). > > Please ask me if you need additional information. > > I've seen the same issue on my x86_64 box (although it's actually runnin > an i386 kernel!). Unfortunately I managed to reboot the box in a way so > that grub can't mount root anymore because it's XFS implementation is a Fortunately, I use lilo and only non XFS partition in my system is small root partition so, I can boot and grab logs. > POS. If you have some time could you try binary-searching what day > they issue appeared? > > If not I'll do once I'll get a little time. I just leaving office for business trip and I will be back in 3 days. I can try after my return. jan -- From owner-linux-xfs@oss.sgi.com Mon May 16 06:25:08 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 May 2005 06:25:31 -0700 (PDT) Received: from cirse.extra.cea.fr (cirse.extra.cea.fr [132.166.172.102]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4GDP7Ov018997 for ; Mon, 16 May 2005 06:25:08 -0700 Received: from cincidele.saclay.cea.fr (cincidele.saclay.cea.fr [132.166.192.111]) by cirse.extra.cea.fr (8.12.10/8.12.10/CEAnet-Internet.4.0) with ESMTP id j4GDOYAN000388 for ; Mon, 16 May 2005 15:24:34 +0200 (MEST) Received: from pisaure.intra.cea.fr (unverified) by cincidele.saclay.cea.fr (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Mon, 16 May 2005 15:24:34 +0200 Received: from nenuphar.saclay.cea.fr (nenuphar.saclay.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.12.11/8.12.11) with ESMTP id j4GDMXXe025198; Mon, 16 May 2005 15:22:33 +0200 (envelope-from degremont@ocre.cea.fr) Received: from ocre.cea.fr ([132.165.65.70]) by nenuphar.saclay.cea.fr (8.12.10/8.12.10/CEAnet-internes.4.0) with ESMTP id j4GDOXZa013913; Mon, 16 May 2005 15:24:33 +0200 (MEST) Message-ID: <42889F11.3090206@ocre.cea.fr> Date: Mon, 16 May 2005 15:24:33 +0200 From: Aurelien Degremont - Stagiaire User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us MIME-Version: 1.0 To: Dean Roehrich CC: linux-xfs@oss.sgi.com Subject: Re: [DMAPI] code error in dm_ip_to_handle() References: <20050513152947.909404FE8A@chewtoy.americas.sgi.com> In-Reply-To: <20050513152947.909404FE8A@chewtoy.americas.sgi.com> Content-Type: multipart/mixed; boundary="------------070507020701030908000807" X-archive-position: 5231 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: degremont@ocre.cea.fr Precedence: bulk X-list: linux-xfs Content-Length: 4896 Lines: 151 This is a multi-part message in MIME format. --------------070507020701030908000807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Dean Roehrich a écrit: >>Ok. So, do we remove the dm_fsfid_t ? Replace it by a dm_fid as you >>proposed ? I think it's a good idea. > > > I would like to see how it works out, if you're willing to do the code. > > Have you been able to try that fsid patch yet? Here is a very small patch that change the parameter of fh_to_inode() and inode_to_fh(). I just replace the dm_fsfid_t by a dm_fid_t. As the code still used those data and copied them simply, it did not need much changes. I just adapted the XFS code in order be compatible with those changes, but I do not modify some function like xfs_fid2(). This could be needed but I prefer that you directly modify the XFS-part if you wish it. Aurelien --------------070507020701030908000807 Content-Type: text/plain; name="dmapi_fsfid.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmapi_fsfid.diff" diff -ru fs/dmapi/dmapi_kern.h ../linux-2.6-xfs.cvs/fs/dmapi/dmapi_kern.h --- fs/dmapi/dmapi_kern.h 2005-03-30 20:16:37.000000000 +0200 +++ ../linux-2.6-xfs.cvs/fs/dmapi/dmapi_kern.h 2005-05-16 12:54:08.000000000 +0200 @@ -78,9 +78,9 @@ struct filesystem_dmapi_operations { int (*get_fsys_vector)(struct super_block *sb, void *addr); int (*fh_to_inode)(struct super_block *sb, struct inode **ip, - struct dm_fsfid *fid); + dm_fid_t *fid); struct file_operations * (*get_invis_ops)(struct inode *ip); - int (*inode_to_fh)(struct inode *ip, struct dm_fsfid *fid, + int (*inode_to_fh)(struct inode *ip, dm_fid_t *fid, dm_fsid_t *fsid ); void (*get_fsid)(struct super_block *sb, dm_fsid_t *fsid); #define HAVE_DM_QUEUE_FLUSH diff -ru fs/dmapi/dmapi_register.c ../linux-2.6-xfs.cvs/fs/dmapi/dmapi_register.c --- fs/dmapi/dmapi_register.c 2005-03-30 20:10:03.000000000 +0200 +++ ../linux-2.6-xfs.cvs/fs/dmapi/dmapi_register.c 2005-05-16 13:14:40.000000000 +0200 @@ -503,7 +508,7 @@ short type; unsigned long lc; /* lock cookie */ int error = 0; - dm_fsfid_t *fidp; + dm_fid_t *fidp; struct super_block *sb; struct inode *ip; int filetype; @@ -512,12 +517,12 @@ if ((fsrp = dm_find_fsreg_and_lock(&handlep->ha_fsid, &lc)) == NULL) return(NULL); - fidp = (dm_fsfid_t*)&handlep->ha_fid; + fidp = (dm_fid_t*)&handlep->ha_fid; /* If mounting, and we are not asking for a filesystem handle, - * then fail the request. (fid_len==0 for fshandle) + * then fail the request. (dm_fid_len==0 for fshandle) */ if ((fsrp->fr_state == DM_STATE_MOUNTING) && - (fidp->fid_len != 0)) { + (fidp->dm_fid_len != 0)) { mutex_spinunlock(&fsrp->fr_lock, lc); return(NULL); } @@ -567,7 +572,7 @@ return(NULL); filetype = ip->i_mode & S_IFMT; - if (fidp->fid_len == 0) { + if (fidp->dm_fid_len == 0) { type = DM_TDT_VFS; } else if (filetype == S_IFREG) { type = DM_TDT_REG; @@ -589,7 +594,7 @@ dm_handle_t *handlep) { int error; - struct dm_fsfid fid; + dm_fid_t fid; dm_fsid_t fsid; int hsize; struct filesystem_dmapi_operations *dops; @@ -602,7 +607,7 @@ return(error); memcpy(&handlep->ha_fsid, &fsid, sizeof(fsid)); - memcpy(&handlep->ha_fid, &fid, fid.fid_len + sizeof fid.fid_len); + memcpy(&handlep->ha_fid, &fid, fid.dm_fid_len + sizeof fid.dm_fid_len); hsize = DM_HSIZE(*handlep); memset((char *)handlep + hsize, 0, sizeof(*handlep) - hsize); return(0); diff -ru fs/xfs/xfs_dmapi.c ../linux-2.6-xfs.cvs/fs/xfs/xfs_dmapi.c --- fs/xfs/xfs_dmapi.c 2005-04-08 04:46:25.000000000 +0200 +++ ../linux-2.6-xfs.cvs/fs/xfs/xfs_dmapi.c 2005-05-16 13:09:46.000000000 +0200 @@ -3382,7 +3382,7 @@ xfs_dm_fh_to_inode( struct super_block *sb, struct inode **ip, - struct dm_fsfid *dmfsfid) + dm_fid_t *dmfid) { vnode_t *vp = NULL; vfs_t *vfsp = LINVFS_GET_VFS(sb); @@ -3392,7 +3392,7 @@ /* Returns negative errors to DMAPI */ *ip = NULL; - memcpy(&fid, dmfsfid, sizeof(*dmfsfid)); + memcpy(&fid, dmfid, sizeof(*dmfid)); if (fid.fid_len) { /* file object handle */ VFS_VGET(vfsp, &vp, &fid, error); } @@ -3407,7 +3407,7 @@ static int xfs_dm_inode_to_fh( struct inode *ip, - struct dm_fsfid *dmfsfid, + dm_fid_t *dmfid, dm_fsid_t *dmfsid) { vnode_t *vp = LINVFS_GET_VP(ip); @@ -3421,7 +3421,14 @@ VOP_FID2(vp, &fid, error); if (error) return -error; /* Return negative error to DMAPI */ - memcpy(dmfsfid, &fid, sizeof(*dmfsfid)); + + /* + * VOP_FID2 returns a fid_t structure but we know + * it is filled with a xfs_fid2_t. So we can copy it + * directly in a dm_fid_t. Maybe this part of the XFS + * code could be fixed (enhanced). + */ + memcpy(dmfid, &fid, sizeof(*dmfid)); memcpy(dmfsid, vp->v_vfsp->vfs_altfsid, sizeof(*dmfsid)); return 0; } --------------070507020701030908000807-- From owner-linux-xfs@oss.sgi.com Mon May 16 06:38:41 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 May 2005 06:38:49 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4GDccOv020160 for ; Mon, 16 May 2005 06:38:38 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4GFMPFi014526 for ; Mon, 16 May 2005 08:22:25 -0700 Received: from chewtoy.americas.sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4GDc5R08196927; Mon, 16 May 2005 08:38:05 -0500 (CDT) Received: from chewtoy (localhost [127.0.0.1]) by chewtoy.americas.sgi.com (Postfix) with ESMTP id AD8574FE8A; Mon, 16 May 2005 08:38:04 -0500 (CDT) To: Aurelien Degremont - Stagiaire Cc: linux-xfs@oss.sgi.com Subject: Re: [DMAPI] code error in dm_ip_to_handle() Date: Mon, 16 May 2005 08:38:04 -0500 From: Dean Roehrich Message-Id: <20050516133804.AD8574FE8A@chewtoy.americas.sgi.com> X-archive-position: 5232 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1683 Lines: 46 >From: Aurelien Degremont - Stagiaire >Ok, ok >But, in inode_to_fh(), how know that we must return a fshandle (with the >dm_fid part filled with 0) or a filehandle (ino, len and gen filled) ? > >Could you explain the behaviour of inode_to_fh() ? (Especially the >differences related to fshandle/filehandle) dm_ip_to_handle() and ->inode_to_fh() always return a filehandle. >dm_handle_to_ip() is always called using a filehandle ? (never a fshandle ?) It looks like this no longer behaves the same as the original Irix code. On Irix, if dm_handle_to_ip() is going to call VFS_ROOT then it doesn't overwrite the handle that was passed to dm_handle_to_ip(). So, does it matter? The Irix code in dm_handle_to_ip() looks like this: if (handlep->ha_fid.fid_len == 0) { /* filesystem handle */ VFS_ROOT(fsrp->fr_vfsp, &vp, error); } else { /* file object handle */ VFS_VGET(fsrp->fr_vfsp, &vp, &handlep->ha_fid, error); } Where the Linux code in dm_handle_to_ip() now looks like this: if (dmapiops->fh_to_inode) error = dmapiops->fh_to_inode(sb, &ip, (void*)fidp); ...which becomes this in xfs_dm_fh_to_inode: memcpy(&fid, dmfsfid, sizeof(*dmfsfid)); if (fid.fid_len) { /* file object handle */ VFS_VGET(vfsp, &vp, &fid, error); } else { /* filesystem handle */ VFS_ROOT(vfsp, &vp, error); } On linux we never replace the handle that was passed to dm_handle_to_ip(); we just verify that it's valid and that it's the expected type. Dean From owner-linux-xfs@oss.sgi.com Mon May 16 07:01:36 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 May 2005 07:01:58 -0700 (PDT) Received: from cirse.extra.cea.fr (cirse.extra.cea.fr [132.166.172.102]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4GE1UOv022035 for ; Mon, 16 May 2005 07:01:35 -0700 Received: from cincidele.saclay.cea.fr (cincidele.saclay.cea.fr [132.166.192.111]) by cirse.extra.cea.fr (8.12.10/8.12.10/CEAnet-Internet.4.0) with ESMTP id j4GE0vAN017326 for ; Mon, 16 May 2005 16:00:57 +0200 (MEST) Received: from pisaure.intra.cea.fr (unverified) by cincidele.saclay.cea.fr (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Mon, 16 May 2005 16:00:57 +0200 Received: from nenuphar.saclay.cea.fr (nenuphar.saclay.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.12.11/8.12.11) with ESMTP id j4GDwuhB029895; Mon, 16 May 2005 15:58:57 +0200 (envelope-from degremont@ocre.cea.fr) Received: from ocre.cea.fr ([132.165.65.70]) by nenuphar.saclay.cea.fr (8.12.10/8.12.10/CEAnet-internes.4.0) with ESMTP id j4GE0tZa024701; Mon, 16 May 2005 16:00:55 +0200 (MEST) Message-ID: <4288A797.6080507@ocre.cea.fr> Date: Mon, 16 May 2005 16:00:55 +0200 From: Aurelien Degremont - Stagiaire User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us MIME-Version: 1.0 To: Dean Roehrich , linux-xfs@oss.sgi.com Subject: Re: [DMAPI] code error in dm_ip_to_handle() References: <20050516133804.AD8574FE8A@chewtoy.americas.sgi.com> In-Reply-To: <20050516133804.AD8574FE8A@chewtoy.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5233 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: degremont@ocre.cea.fr Precedence: bulk X-list: linux-xfs Content-Length: 898 Lines: 34 To sum up : - inode_to_fh() only need to fill a dmfsfid (currently :)) with something like that : fid.dm_fid_len = sizeof(dm_fid_t) - sizeof(fid.dm_fid_len); fid.dm_fid_pad = 0; fid.dm_fid_gen = ip->i_generation; fid.dm_fid_ino = ip->i_ino; memcpy(dmfsfid, &fid, sizeof(fid)); (The dm_fid_len don't need to be set to 0) - fh_to_inode() must test the fid_len field and return the root inode number if its value is zero. dm_fid_t fid; /* FS HANDLE */ if (dmfsfid->fid_len == 0) ino = EXT3_ROOT_INO; /* FILE HANDLE */ else { memcpy(&fid, dmfsfid, sizeof(fid)); ino = fid.dm_fid_ino; /* Some alignement checks ? */ } The other modification are managed by the DMAPI code and the FS code don't need to bother with it ? Aurelien From owner-linux-xfs@oss.sgi.com Mon May 16 07:50:48 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 May 2005 07:51:21 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4GEomOv024752 for ; Mon, 16 May 2005 07:50:48 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4GGYZTo029062 for ; Mon, 16 May 2005 09:34:35 -0700 Received: from chewtoy.americas.sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4GEnER08200594; Mon, 16 May 2005 09:49:14 -0500 (CDT) Received: from chewtoy (localhost [127.0.0.1]) by chewtoy.americas.sgi.com (Postfix) with ESMTP id 4C3244FE8A; Mon, 16 May 2005 09:49:14 -0500 (CDT) To: Aurelien Degremont - Stagiaire Cc: linux-xfs@oss.sgi.com Subject: Re: [DMAPI] code error in dm_ip_to_handle() Date: Mon, 16 May 2005 09:49:14 -0500 From: Dean Roehrich Message-Id: <20050516144914.4C3244FE8A@chewtoy.americas.sgi.com> X-archive-position: 5234 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 726 Lines: 25 >From: Aurelien Degremont - Stagiaire > >To sum up : > - inode_to_fh() only need to fill a dmfsfid (currently :)) with >something like that : > > fid.dm_fid_len = sizeof(dm_fid_t) - sizeof(fid.dm_fid_len); > fid.dm_fid_pad = 0; > fid.dm_fid_gen = ip->i_generation; > fid.dm_fid_ino = ip->i_ino; > memcpy(dmfsfid, &fid, sizeof(fid)); > >(The dm_fid_len don't need to be set to 0) Okay. > - fh_to_inode() must test the fid_len field and return the root inode >number if its value is zero. No. fh_to_inode() doesn't have to modify the dm_fsfid at all. It just needs to check that it refers to a valid inode, and then it needs to return that inode. Dean From owner-linux-xfs@oss.sgi.com Mon May 16 08:05:26 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 May 2005 08:05:49 -0700 (PDT) Received: from cirse.extra.cea.fr (cirse.extra.cea.fr [132.166.172.102]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4GF5NOv025704 for ; Mon, 16 May 2005 08:05:25 -0700 Received: from argiope.saclay.cea.fr (argiope.saclay.cea.fr [132.166.192.108]) by cirse.extra.cea.fr (8.12.10/8.12.10/CEAnet-Internet.4.0) with ESMTP id j4GF4nAN014791 for ; Mon, 16 May 2005 17:04:49 +0200 (MEST) Received: from pisaure.intra.cea.fr (unverified) by argiope.saclay.cea.fr (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Mon, 16 May 2005 17:04:49 +0200 Received: from nenuphar.saclay.cea.fr (nenuphar.saclay.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.12.11/8.12.11) with ESMTP id j4GF2nVk004265; Mon, 16 May 2005 17:02:49 +0200 (envelope-from degremont@ocre.cea.fr) Received: from ocre.cea.fr ([132.165.65.70]) by nenuphar.saclay.cea.fr (8.12.10/8.12.10/CEAnet-internes.4.0) with ESMTP id j4GF4mZa008661; Mon, 16 May 2005 17:04:48 +0200 (MEST) Message-ID: <4288B690.4070008@ocre.cea.fr> Date: Mon, 16 May 2005 17:04:48 +0200 From: Aurelien Degremont - Stagiaire User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us MIME-Version: 1.0 To: Dean Roehrich CC: linux-xfs@oss.sgi.com Subject: Re: [DMAPI] code error in dm_ip_to_handle() References: <20050516144914.4C3244FE8A@chewtoy.americas.sgi.com> In-Reply-To: <20050516144914.4C3244FE8A@chewtoy.americas.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 5235 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: degremont@ocre.cea.fr Precedence: bulk X-list: linux-xfs Content-Length: 1510 Lines: 56 Dean Roehrich a écrit: >> - fh_to_inode() must test the fid_len field and return the root inode >>number if its value is zero. > > > No. fh_to_inode() doesn't have to modify the dm_fsfid at all. It just needs > to check that it refers to a valid inode, and then it needs to return that > inode. I'm sorry if I was unclear here. I never said dmfsfid need to be modified. We just check its fid_len, return the root inode if null or return the file inode refers by the filehandle otherwise. When the inode number is known, try to get it with a iget(), if the iget succeeded, the inode was correct, else, return an error. Here is my full function code, I think it agrees with your explanations : static int ext3_dm_fh_to_inode( struct super_block *sb, struct inode **ip, struct dm_fsfid *dmfsfid) { int error = 0; ino_t ino = 0; dm_fid_t fid; /* * Read the inode number from the handle and fetch the corresponding * inode. */ /* FS HANDLE */ if (dmfsfid->fid_len == 0) ino = EXT3_ROOT_INO; /* Else FILE HANDLE */ else { memcpy(&fid, dmfsfid, sizeof(fid)); ino = fid.dm_fid_ino; /* memcpy() here ? */ } *ip = iget(sb, ino); if (*ip == NULL) error = EIO; return -error; /* Return negative error to DMAPI */ } Aurelien From owner-linux-xfs@oss.sgi.com Mon May 16 08:18:50 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 May 2005 08:19:07 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4GFIoOv027724 for ; Mon, 16 May 2005 08:18:50 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4GH2bnw001221 for ; Mon, 16 May 2005 10:02:37 -0700 Received: from chewtoy.americas.sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4GFIGR08202920; Mon, 16 May 2005 10:18:16 -0500 (CDT) Received: from chewtoy (localhost [127.0.0.1]) by chewtoy.americas.sgi.com (Postfix) with ESMTP id 24CF74FE8A; Mon, 16 May 2005 10:18:16 -0500 (CDT) To: Aurelien Degremont - Stagiaire Cc: linux-xfs@oss.sgi.com Subject: Re: [DMAPI] code error in dm_ip_to_handle() Date: Mon, 16 May 2005 10:18:15 -0500 From: Dean Roehrich Message-Id: <20050516151816.24CF74FE8A@chewtoy.americas.sgi.com> X-archive-position: 5236 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1073 Lines: 37 >From: Aurelien Degremont - Stagiaire >Dean Roehrich a écrit: >>> - fh_to_inode() must test the fid_len field and return the root inode >>>number if its value is zero. >> >> >> No. fh_to_inode() doesn't have to modify the dm_fsfid at all. It just need >s >> to check that it refers to a valid inode, and then it needs to return that >> inode. > >I'm sorry if I was unclear here. >I never said dmfsfid need to be modified. We just check its fid_len, >return the root inode if null or return the file inode refers by the >filehandle otherwise. >When the inode number is known, try to get it with a iget(), if the iget >succeeded, the inode was correct, else, return an error. Yes, that sounds right. > else > { > memcpy(&fid, dmfsfid, sizeof(fid)); > ino = fid.dm_fid_ino; /* memcpy() here ? */ > } > > > *ip = iget(sb, ino); > if (*ip == NULL) > error = EIO; For the filehandle case, you need to verify that dm_fid_gen matches i_generation. Dean From owner-linux-xfs@oss.sgi.com Mon May 16 10:31:13 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 May 2005 10:31:25 -0700 (PDT) Received: from mail00hq.adic.com (mail.adic.com [63.81.117.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4GHVBOv006273 for ; Mon, 16 May 2005 10:31:11 -0700 Received: from mail02hq.adic.com ([172.16.9.18]) by mail00hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 16 May 2005 10:30:33 -0700 Received: from [172.16.82.67] ([172.16.82.67]) by mail02hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 16 May 2005 10:30:33 -0700 Message-ID: <4288D8B8.4070302@xfs.org> Date: Mon, 16 May 2005 12:30:32 -0500 From: Steve Lord User-Agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324) X-Accept-Language: en-us, en MIME-Version: 1.0 To: XFS Linux Subject: [Fwd: XFS lstat() _very_ slow on SMP] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2005 17:30:33.0629 (UTC) FILETIME=[F6DF3CD0:01C55A3C] X-archive-position: 5237 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 3836 Lines: 88 Forwarding from lkml to somewhere where it might be seen. Steve -------- Original Message -------- Subject: XFS lstat() _very_ slow on SMP Date: Mon, 16 May 2005 18:25:06 +0200 From: Jan Kasprzak To: linux-kernel@vger.kernel.org Hi all, I have a big XFS volume on my fileserver, and I have noticed that making an incremental backup of this volume is _very_ slow. The incremental backup essentially checks mtime of all files on this volume, and it takes ~4ms of _system_ time (i.e. no iowait or what) to do a lstat(). The server is quad opteron with 26GB of RAM, 2.6.11.x kernel. The volume in question is this big: $ df -i /export/home Filesystem Inodes IUsed IFree IUse% Mounted on /dev/array-vg/home 2147502080 7917653 2139584427 1% /export/home $ df -k /export/home Filesystem 1K-blocks Used Available Use% Mounted on /dev/array-vg/home 2147371008 558965100 1588405908 27% /export/home As you can see it has ~8 milion of files. At 4ms per file it takes almost 9 hours of system time just to select the files to back up. I've tried to narrow this problem in the following way: I've created a new logical volume, put an empty XFS filesystem on it, and created 16.7M files in the three-level directory structure (256 subdirs at each level, 256 files in each leaf directory). It took about a day of _system_ time to create this structure, and another day to run "find /mnt1 -type f -mtime +1000 -print" on it. I did a strace -c of this find command, and it looks like this: % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 99.97 68713.490033 4048 16974597 lstat [...] So the find(1) spent almost all of its time in lstat() syscall, and each call took about 4ms of system time. Real time was almost the same as the system time, so disk subsystem was not a bottleneck here. When I tried to umount this test volume, the umount(8) did not finish even after 5 minutes, and it was cycling somewhere in kernel (according to top(1) it used 25% of CPU time, i.e. one CPU out of 4). In addition to this, all other filesystem-related processes started to lock up in kernel, possibly waiting for some lock held by umount command. I had to reset this server after 5 minutes. I tried to run the same test on a single-CPU Athlon FX-51 with 512M RAM, and only 128*128*128 (2M) files, and got the following numbers: create find -type f -mtime +1000 cost of lstat() XFS 10m15s real, 4m22s system 7m30s real, 3m17s system 107us ext3 1m10s real, 0m30s system 1m26s real, 0m10s system 9us So XFS lstat() is almost 12-times slower than ext3 one even on single-CPU x86_64. I've tried to boot a SMP kernel as well, but there was no measurable difference in speed. So XFS is slow even on this box, but going 4-way SMP makes the problem two magnitudes worse. The problem is definitely in XFS on SMP (or maybe in filling up the dentry/inode cache, because the cost of lstat() on smaller trees is not so big). I will do more benchmarks if you want (I can test it on SMP x86 as well, for example). -Yenya -- | Jan "Yenya" Kasprzak | | GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E | | http://www.fi.muni.cz/~kas/ Czech Linux Homepage: http://www.linux.cz/ | -- Yes. CVS is much denser. -- -- CVS is also total crap. So your point is? --Linus Torvalds -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From owner-linux-xfs@oss.sgi.com Mon May 16 12:53:17 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 May 2005 12:53:22 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4GJrGOv028323 for ; Mon, 16 May 2005 12:53:16 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4GJqgxT028852 for ; Mon, 16 May 2005 14:52:42 -0500 Received: from chewtoy.americas.sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4GJqfR08226166; Mon, 16 May 2005 14:52:41 -0500 (CDT) Received: from chewtoy (localhost [127.0.0.1]) by chewtoy.americas.sgi.com (Postfix) with ESMTP id 86BD04FE8A; Mon, 16 May 2005 14:52:40 -0500 (CDT) To: Aurelien Degremont - Stagiaire Cc: linux-xfs@oss.sgi.com Subject: Re: [DMAPI] code error in dm_ip_to_handle() Date: Mon, 16 May 2005 14:52:40 -0500 From: Dean Roehrich Message-Id: <20050516195240.86BD04FE8A@chewtoy.americas.sgi.com> X-archive-position: 5238 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2321 Lines: 74 >From: Aurelien Degremont - Stagiaire >Here is a very small patch that change the parameter of fh_to_inode() >and inode_to_fh(). >I just replace the dm_fsfid_t by a dm_fid_t. I've been using your patch today. So far it's good. Here's the rest of it, to completely remove dm_fsfid. Do these dm_copyin_handle() changes look right to you? Dean Index: lbs-a/linux/linux/fs/dmapi/dmapi.h =================================================================== --- lbs-a.orig/linux/linux/fs/dmapi/dmapi.h 2005-04-26 16:43:14.000000000 -0700 +++ lbs-a/linux/linux/fs/dmapi/dmapi.h 2005-05-16 08:41:52.000000000 -0700 @@ -482,11 +482,6 @@ typedef struct dm_xstat dm_xstat_t; #define MAXDMFSFIDSZ 46 -typedef struct dm_fsfid { - __u16 fid_len; /* length of data in bytes */ - unsigned char fid_data[MAXDMFSFIDSZ]; /* data (fid_len worth) */ -} dm_fsfid_t; - struct dm_fid { __u16 dm_fid_len; /* length of remainder */ __u16 dm_fid_pad; Index: lbs-a/linux/linux/fs/dmapi/dmapi_right.c =================================================================== --- lbs-a.orig/linux/linux/fs/dmapi/dmapi_right.c 2005-04-26 13:36:49.000000000 -0700 +++ lbs-a/linux/linux/fs/dmapi/dmapi_right.c 2005-05-16 08:45:58.000000000 -0700 @@ -51,29 +51,27 @@ dm_copyin_handle( dm_handle_t *handlep) /* output, copy of data */ { u_short len; - dm_fsfid_t *fidp; + dm_fid_t *fidp; - fidp = (dm_fsfid_t*)&handlep->ha_fid; + fidp = (dm_fid_t*)&handlep->ha_fid; if (hlen < sizeof(handlep->ha_fsid) || hlen > sizeof(*handlep)) - return(-EBADF); + return -EBADF; if (copy_from_user(handlep, hanp, hlen)) - return(-EFAULT); + return -EFAULT; if (hlen < sizeof(*handlep)) memset((char *)handlep + hlen, 0, sizeof(*handlep) - hlen); if (hlen == sizeof(handlep->ha_fsid)) - return(0); /* FS handle, nothing more to check */ + return 0; /* FS handle, nothing more to check */ - len = hlen - sizeof(handlep->ha_fsid) - sizeof(fidp->fid_len); + len = hlen - sizeof(handlep->ha_fsid) - sizeof(fidp->dm_fid_len); - if (fidp->fid_len != len || - *((short *) fidp->fid_data)) { - return(-EBADF); - } - return(0); + if ((fidp->dm_fid_len != len) || fidp->dm_fid_pad) + return -EBADF; + return 0; } /* Allocate and initialize a tevp structure. Called from both application and From owner-linux-xfs@oss.sgi.com Mon May 16 20:45:34 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 May 2005 20:45:38 -0700 (PDT) Received: from mail.cis.nctu.edu.tw (mail.cis.nctu.edu.tw [140.113.23.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4H3jXOv029761 for ; Mon, 16 May 2005 20:45:33 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.cis.nctu.edu.tw (8.12.10/8.12.9) with ESMTP id j4H3ixDB065617 for ; Tue, 17 May 2005 11:44:59 +0800 (CST) (envelope-from weafon@cis.nctu.edu.tw) Received: from mail.cis.nctu.edu.tw ([127.0.0.1]) by localhost (mail.cis.nctu.edu.tw [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 63707-06 for ; Tue, 17 May 2005 11:44:59 +0800 (CST) Received: from weafon1400w (emperor.cis.nctu.edu.tw [140.113.88.149]) (authenticated bits=0 as gis92804 with LOGIN) by mail.cis.nctu.edu.tw (8.12.10/8.12.9) with ESMTP id j4H3iwig065609 for ; Tue, 17 May 2005 11:44:59 +0800 (CST) (envelope-from weafon@cis.nctu.edu.tw) Message-ID: <001a01c55a92$d90dea20$9558718c@weafon1400w> From: "weafon" To: Subject: [Question] how to know which blocks are used? Date: Tue, 17 May 2005 11:45:19 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 5240 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: weafon@cis.nctu.edu.tw Precedence: bulk X-list: linux-xfs Content-Length: 973 Lines: 25 Hi, I am writing a code for copying the XFS-format disk to another space disk. The code is run without the support of XFS lib. That is, the code has to read the structure of XFS by itself. I went to know which block is used because I only plan to copy the used block for saving time. As I known, in XFS, a B+tree is used, instead of the tranditional bitmap structure, to describe the free space. When I view the raw data of a XFS partition, I see XFSB, AGF, AGI, and "freelist" structure. What I cannot understand is why only a short freelist [00 ~ 03] exists in the first AG even when there are 0xffff4 free blocks in the AG. There are only 4 blocks described by the freelist. Ps. is there any doc explaining the relation between the internal structures, such as 'freelist' and AGF, or explaining how the XFS code build a b+tree from the AGF ad freelist? Thx. Regards, Shih-Chiang Tsao http://speed.cis.nctu.edu.tw/~weafon [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Tue May 17 00:05:07 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 May 2005 00:05:21 -0700 (PDT) Received: from cirse.extra.cea.fr (cirse.extra.cea.fr [132.166.172.102]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4H751Ov009816 for ; Tue, 17 May 2005 00:05:06 -0700 Received: from cincidele.saclay.cea.fr (cincidele.saclay.cea.fr [132.166.192.111]) by cirse.extra.cea.fr (8.12.10/8.12.10/CEAnet-Internet.4.0) with ESMTP id j4H74MAN022563 for ; Tue, 17 May 2005 09:04:23 +0200 (MEST) Received: from pisaure.intra.cea.fr (unverified) by cincidele.saclay.cea.fr (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Tue, 17 May 2005 09:04:22 +0200 Received: from nenuphar.saclay.cea.fr (nenuphar.saclay.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.12.11/8.12.11) with ESMTP id j4H72KBa015437; Tue, 17 May 2005 09:02:21 +0200 (envelope-from degremont@ocre.cea.fr) Received: from ocre.cea.fr ([132.165.65.70]) by nenuphar.saclay.cea.fr (8.12.10/8.12.10/CEAnet-internes.4.0) with ESMTP id j4H74LZa001038; Tue, 17 May 2005 09:04:21 +0200 (MEST) Message-ID: <42899775.9000805@ocre.cea.fr> Date: Tue, 17 May 2005 09:04:21 +0200 From: Aurelien Degremont - Stagiaire User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us MIME-Version: 1.0 To: Dean Roehrich CC: linux-xfs@oss.sgi.com Subject: Re: [DMAPI] code error in dm_ip_to_handle() References: <20050516195240.86BD04FE8A@chewtoy.americas.sgi.com> In-Reply-To: <20050516195240.86BD04FE8A@chewtoy.americas.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 5241 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: degremont@ocre.cea.fr Precedence: bulk X-list: linux-xfs Content-Length: 498 Lines: 21 Dean Roehrich a écrit: >>From: Aurelien Degremont - Stagiaire > > >>Here is a very small patch that change the parameter of fh_to_inode() >>and inode_to_fh(). >>I just replace the dm_fsfid_t by a dm_fid_t. > > > I've been using your patch today. So far it's good. > > Here's the rest of it, to completely remove dm_fsfid. Do these > dm_copyin_handle() changes look right to you? Looks good to me. You fixed what I missed. I think now this point is ok. Aurelien From owner-linux-xfs@oss.sgi.com Tue May 17 01:00:17 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 May 2005 01:00:29 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4H80EOv022089 for ; Tue, 17 May 2005 01:00:17 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1DXwzL-0006aD-SY; Tue, 17 May 2005 08:59:39 +0100 Date: Tue, 17 May 2005 08:59:39 +0100 From: Christoph Hellwig To: weafon Cc: linux-xfs@oss.sgi.com Subject: Re: [Question] how to know which blocks are used? Message-ID: <20050517075939.GA25031@infradead.org> References: <001a01c55a92$d90dea20$9558718c@weafon1400w> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001a01c55a92$d90dea20$9558718c@weafon1400w> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 5242 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 432 Lines: 10 On Tue, May 17, 2005 at 11:45:19AM +0800, weafon wrote: > Hi, > I am writing a code for copying the XFS-format disk to another space disk. > The code is run without the support of XFS lib. > That is, the code has to read the structure of XFS by itself. > > I went to know which block is used because I only plan to copy the used block for saving time. xfs_copy is doing exactly that. Either use it or look at it what it does. From owner-linux-xfs@oss.sgi.com Tue May 17 01:52:39 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 May 2005 01:53:03 -0700 (PDT) Received: from cirse.extra.cea.fr (cirse.extra.cea.fr [132.166.172.102]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4H8qcOv024494 for ; Tue, 17 May 2005 01:52:39 -0700 Received: from cincidele.saclay.cea.fr (cincidele.saclay.cea.fr [132.166.192.111]) by cirse.extra.cea.fr (8.12.10/8.12.10/CEAnet-Internet.4.0) with ESMTP id j4H8q4AN027297 for ; Tue, 17 May 2005 10:52:04 +0200 (MEST) Received: from pisaure.intra.cea.fr (unverified) by cincidele.saclay.cea.fr (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Tue, 17 May 2005 10:52:03 +0200 Received: from nenuphar.saclay.cea.fr (nenuphar.saclay.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.12.11/8.12.11) with ESMTP id j4H8o1fL009946; Tue, 17 May 2005 10:50:01 +0200 (envelope-from degremont@ocre.cea.fr) Received: from ocre.cea.fr ([132.165.65.70]) by nenuphar.saclay.cea.fr (8.12.10/8.12.10/CEAnet-internes.4.0) with ESMTP id j4H8q2Za024819; Tue, 17 May 2005 10:52:02 +0200 (MEST) Message-ID: <4289B0B2.3020604@ocre.cea.fr> Date: Tue, 17 May 2005 10:52:02 +0200 From: Aurelien Degremont - Stagiaire User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us MIME-Version: 1.0 To: Dean Roehrich CC: linux-xfs@oss.sgi.com Subject: Re: [DMAPI] code error in dm_ip_to_handle() References: <20050516195240.86BD04FE8A@chewtoy.americas.sgi.com> In-Reply-To: <20050516195240.86BD04FE8A@chewtoy.americas.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 5243 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: degremont@ocre.cea.fr Precedence: bulk X-list: linux-xfs Content-Length: 1060 Lines: 30 Dean Roehrich a écrit: >>From: Aurelien Degremont - Stagiaire > > >>Here is a very small patch that change the parameter of fh_to_inode() >>and inode_to_fh(). >>I just replace the dm_fsfid_t by a dm_fid_t. > > > I've been using your patch today. So far it's good. > > Here's the rest of it, to completely remove dm_fsfid. Do these > dm_copyin_handle() changes look right to you? > It was really a good idea to fix this since I found, in the dmapi user space library, in the parse_handle() function, that you copy the opaque buffer ha_fid in a xfs_fid2_t structure (argh ! an xfs reference in a code which is supposed to be independent :)). And from this xfs_fid2, the igen and ino are extracted even if the ha_fid is supposed to be opaque ! The igen and ino number should have been extracted using FS specific call (from fsys_vector). But, now this is solved, fortunately :) since we used dm_fid_t. (As dmapi.h is included in this file, maybe the XFS struct could be replaced by their DMAPI equivalent ?) Aurélien From owner-linux-xfs@oss.sgi.com Tue May 17 15:05:59 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 May 2005 15:06:04 -0700 (PDT) Received: from dinoslab.com ([222.122.13.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4HM5uF3009555 for ; Tue, 17 May 2005 15:05:59 -0700 Message-Id: <200505172205.j4HM5uF3009555@oss.sgi.com> Received: (qmail 8803 invoked for bounce); 17 May 2005 22:05:21 -0000 Date: 17 May 2005 22:05:21 -0000 From: mailmaster@ware.epart.com To: linux-xfs@oss.sgi.com Subject: failure notice Content-Type: text/plain; charset=euc-kr X-archive-position: 5244 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mailmaster@ware.epart.com Precedence: bulk X-list: linux-xfs Content-Length: 278 Lines: 7 Hi. This is the qmail-send program at ware.epart.com. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. < yooshin@neotelematics.com >: Sorry, no mailbox here by that name. (#5.1.1) From owner-linux-xfs@oss.sgi.com Tue May 17 18:48:19 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 May 2005 18:48:23 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I1mIF3005394 for ; Tue, 17 May 2005 18:48:18 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4I1lhxT025561 for ; Tue, 17 May 2005 20:47:43 -0500 Received: from chewtoy.americas.sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4I1lhR08313439; Tue, 17 May 2005 20:47:43 -0500 (CDT) Received: from chewtoy (localhost [127.0.0.1]) by chewtoy.americas.sgi.com (Postfix) with ESMTP id EBD074FE8A; Tue, 17 May 2005 20:47:42 -0500 (CDT) To: Aurelien Degremont - Stagiaire Cc: linux-xfs@oss.sgi.com Subject: Re: [DMAPI] code error in dm_ip_to_handle() Date: Tue, 17 May 2005 20:47:42 -0500 From: Dean Roehrich Message-Id: <20050518014742.EBD074FE8A@chewtoy.americas.sgi.com> X-archive-position: 5246 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 725 Lines: 18 >From: Aurelien Degremont - Stagiaire >It was really a good idea to fix this since I found, in the dmapi user >space library, in the parse_handle() function, that you copy the opaque >buffer ha_fid in a xfs_fid2_t structure (argh ! an xfs reference in a >code which is supposed to be independent :)). And from this xfs_fid2, >the igen and ino are extracted even if the ha_fid is supposed to be >opaque ! The igen and ino number should have been extracted using FS >specific call (from fsys_vector). > >But, now this is solved, fortunately :) since we used dm_fid_t. Can you give me a patch for the library to convert it from xfs_fid2_t to dm_fid_t? Let XFS continue to use xfs_fid2_t. Dean From owner-linux-xfs@oss.sgi.com Tue May 17 18:45:47 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 May 2005 18:45:53 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I1jiF3005237 for ; Tue, 17 May 2005 18:45:45 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4I1j9xT024960 for ; Tue, 17 May 2005 20:45:09 -0500 Received: from chewtoy.americas.sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4I1j8R08315639; Tue, 17 May 2005 20:45:08 -0500 (CDT) Received: from chewtoy (localhost [127.0.0.1]) by chewtoy.americas.sgi.com (Postfix) with ESMTP id 519074FE8A; Tue, 17 May 2005 20:45:08 -0500 (CDT) To: Aurelien Degremont - Stagiaire Cc: linux-xfs@oss.sgi.com Subject: Re: [DMAPI] code error in dm_ip_to_handle() Date: Tue, 17 May 2005 20:45:08 -0500 From: Dean Roehrich Message-Id: <20050518014508.519074FE8A@chewtoy.americas.sgi.com> X-archive-position: 5245 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1028 Lines: 32 >From: Aurelien Degremont - Stagiaire >Dean Roehrich a écrit: >>>From: Aurelien Degremont - Stagiaire >> >> >>>Here is a very small patch that change the parameter of fh_to_inode() >>>and inode_to_fh(). >>>I just replace the dm_fsfid_t by a dm_fid_t. >> >> >> I've been using your patch today. So far it's good. >> >> Here's the rest of it, to completely remove dm_fsfid. Do these >> dm_copyin_handle() changes look right to you? > >Looks good to me. >You fixed what I missed. > >I think now this point is ok. Thanks, I'll get this in today. I have to jump ahead. I need to have one struct filesystem_dmapi_operations per mounted filesystem to solve a problem I'm dealing with now, and I have to do it without changing any of DMAPI's external interfaces. To accomplish this I'm checking in a change that nearly rewrites dmapi_mountinfo.c, and I'll be checking that in first. I still intend to move this code in the direction you and I have been discussing. Dean From owner-linux-xfs@oss.sgi.com Tue May 17 22:52:21 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 May 2005 22:52:25 -0700 (PDT) Received: from ns8.sony.co.jp (NS8.Sony.CO.JP [137.153.0.33]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I5qIF3026295 for ; Tue, 17 May 2005 22:52:21 -0700 Received: from mail6.sony.co.jp (mail6.sony.co.jp [43.0.1.208]) Received: from mail6.sony.co.jp (localhost [127.0.0.1]) by mail6.sony.co.jp (R8/Sony) with ESMTP id j4I5pevL005355 for ; Wed, 18 May 2005 14:51:40 +0900 (JST) Received: from cpgsgw.sys1.cpg.sony.co.jp ([43.14.53.1]) by mail6.sony.co.jp (R8/Sony) with ESMTP id j4I5peOR005333 for ; Wed, 18 May 2005 14:51:40 +0900 (JST) Received: from dsf38.sys1.cpg.sony.co.jp ([43.14.15.86]) by cpgsgw.sys1.cpg.sony.co.jp (8.8.8+Sun/3.6W/980617(siva)) with SMTP id OAA27312 for ; Wed, 18 May 2005 14:51:39 +0900 (JST) Date: Wed, 18 May 2005 14:51:08 +0900 From: Kenji Munakata To: linux-xfs@oss.sgi.com Subject: problem in TAKE 908809 Message-Id: <20050518145108.725f0ba1.munaken@sys1.cpg.sony.co.jp> X-Mailer: Microsoft Express Outlook Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5247 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: munaken@sys1.cpg.sony.co.jp Precedence: bulk X-list: linux-xfs Content-Length: 478 Lines: 17 Hi, XFS doesn't work correctly since TAKE 908809. I think that the evaluation of error is wrong. --- fs/xfs/linux-2.6/xfs_buf.c.org 2005-05-18 13:55:00.481733706 +0900 +++ fs/xfs/linux-2.6/xfs_buf.c 2005-05-18 13:18:07.000000000 +0900 @@ -1956,7 +1956,7 @@ pagebuf_init(void) #endif error = xfs_buf_daemons_start(); - if (!error) + if (error) goto out_free_buf_zone; pagebuf_shake = kmem_shake_register(xfsbufd_wakeup); From owner-linux-xfs@oss.sgi.com Wed May 18 00:10:55 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 May 2005 00:11:13 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I7AsF3031632 for ; Wed, 18 May 2005 00:10:55 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1DYIh6-00043g-Ss; Wed, 18 May 2005 08:10:16 +0100 Date: Wed, 18 May 2005 08:10:16 +0100 From: Christoph Hellwig To: Kenji Munakata Cc: linux-xfs@oss.sgi.com Subject: Re: problem in TAKE 908809 Message-ID: <20050518071016.GA15511@infradead.org> References: <20050518145108.725f0ba1.munaken@sys1.cpg.sony.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050518145108.725f0ba1.munaken@sys1.cpg.sony.co.jp> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 5248 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 371 Lines: 12 On Wed, May 18, 2005 at 02:51:08PM +0900, Kenji Munakata wrote: > Hi, > > XFS doesn't work correctly since TAKE 908809. > I think that the evaluation of error is wrong. Thanks a lot! That's the x86/x86_64 problems we've seen. For some reason ppc doesn't complain about allocating from deleted kmem_caches and xfs works just fine neverless. I'll check it in ASAP. From owner-linux-xfs@oss.sgi.com Wed May 18 01:59:03 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 May 2005 01:59:13 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I8x2F3007801 for ; Wed, 18 May 2005 01:59:02 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4I8wQxT013060 for ; Wed, 18 May 2005 03:58:26 -0500 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4I8wP0F15260493; Wed, 18 May 2005 03:58:25 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1DYKNl-0006KE-00; Wed, 18 May 2005 03:58:25 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 908809 - Fix pagebuf slab initialization Message-Id: From: Christoph Hellwig Date: Wed, 18 May 2005 03:58:25 -0500 X-archive-position: 5249 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 486 Lines: 15 Thanks a lot to Kenji Munakata for spotting this one. Date: Wed May 18 01:58:18 PDT 2005 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.6.x Inspected by: munaken@sys1.cpg.sony.co.jp The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:192756a fs/xfs/linux-2.6/xfs_buf.c - 1.196 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.c.diff?r1=text&tr1=1.196&r2=text&tr2=1.195&f=h From owner-linux-xfs@oss.sgi.com Wed May 18 02:18:55 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 May 2005 02:19:08 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I9ItF3008877 for ; Wed, 18 May 2005 02:18:55 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4IB2t6Y027781 for ; Wed, 18 May 2005 04:02:55 -0700 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4I9IIR08335366; Wed, 18 May 2005 04:18:18 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1DYKh0-0006ez-00; Wed, 18 May 2005 04:18:18 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 936255 - Remove dead code. Message-Id: From: Christoph Hellwig Date: Wed, 18 May 2005 04:18:18 -0500 X-archive-position: 5250 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1737 Lines: 33 Patch from Adrian Bunk Date: Wed May 18 02:18:24 PDT 2005 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.6.x Inspected by: sandeen The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:192759a fs/xfs/xfs_trans_inode.c - 1.49 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans_inode.c.diff?r1=text&tr1=1.49&r2=text&tr2=1.48&f=h fs/xfs/xfs_bmap_btree.h - 1.67 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap_btree.h.diff?r1=text&tr1=1.67&r2=text&tr2=1.66&f=h fs/xfs/xfs_bmap_btree.c - 1.146 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap_btree.c.diff?r1=text&tr1=1.146&r2=text&tr2=1.145&f=h fs/xfs/xfs_inode.c - 1.412 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.412&r2=text&tr2=1.411&f=h fs/xfs/xfs_trans.c - 1.161 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans.c.diff?r1=text&tr1=1.161&r2=text&tr2=1.160&f=h fs/xfs/xfs_trans.h - 1.129 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans.h.diff?r1=text&tr1=1.129&r2=text&tr2=1.128&f=h fs/xfs/xfs_fsops.c - 1.103 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_fsops.c.diff?r1=text&tr1=1.103&r2=text&tr2=1.102&f=h fs/xfs/xfs_rename.c - 1.60 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_rename.c.diff?r1=text&tr1=1.60&r2=text&tr2=1.59&f=h fs/xfs/quota/xfs_dquot.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_dquot.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h fs/xfs/quota/xfs_dquot.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_dquot.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h From owner-linux-xfs@oss.sgi.com Wed May 18 02:30:07 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 May 2005 02:30:15 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I9U7F3009712 for ; Wed, 18 May 2005 02:30:07 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4IBE7eA030566 for ; Wed, 18 May 2005 04:14:07 -0700 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4I9TU0F15262452; Wed, 18 May 2005 04:29:30 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1DYKrq-0006xa-00; Wed, 18 May 2005 04:29:30 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 936255 - mark various symbols static Message-Id: From: Christoph Hellwig Date: Wed, 18 May 2005 04:29:30 -0500 X-archive-position: 5251 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 5937 Lines: 90 Patch from Adrian Bunk Date: Wed May 18 02:29:33 PDT 2005 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.6.x Inspected by: sandeen The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:192760a fs/xfs/xfs_log.c - 1.304 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log.c.diff?r1=text&tr1=1.304&r2=text&tr2=1.303&f=h fs/xfs/xfs_extfree_item.c - 1.58 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_extfree_item.c.diff?r1=text&tr1=1.58&r2=text&tr2=1.57&f=h fs/xfs/xfs_buf_item.c - 1.151 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_buf_item.c.diff?r1=text&tr1=1.151&r2=text&tr2=1.150&f=h fs/xfs/xfs_log_priv.h - 1.105 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_priv.h.diff?r1=text&tr1=1.105&r2=text&tr2=1.104&f=h fs/xfs/xfs_da_btree.c - 1.152 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_da_btree.c.diff?r1=text&tr1=1.152&r2=text&tr2=1.151&f=h fs/xfs/xfs_da_btree.h - 1.58 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_da_btree.h.diff?r1=text&tr1=1.58&r2=text&tr2=1.57&f=h fs/xfs/xfs_bit.c - 1.28 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bit.c.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h fs/xfs/xfs_vnodeops.c - 1.643 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.643&r2=text&tr2=1.642&f=h fs/xfs/xfs_inode_item.c - 1.118 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode_item.c.diff?r1=text&tr1=1.118&r2=text&tr2=1.117&f=h fs/xfs/xfs_log_recover.c - 1.295 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_recover.c.diff?r1=text&tr1=1.295&r2=text&tr2=1.294&f=h fs/xfs/xfs_vfsops.c - 1.466 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.466&r2=text&tr2=1.465&f=h fs/xfs/xfs_dir_leaf.c - 1.124 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir_leaf.c.diff?r1=text&tr1=1.124&r2=text&tr2=1.123&f=h fs/xfs/xfs_dir_leaf.h - 1.42 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir_leaf.h.diff?r1=text&tr1=1.42&r2=text&tr2=1.41&f=h fs/xfs/xfs_mount.h - 1.199 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.h.diff?r1=text&tr1=1.199&r2=text&tr2=1.198&f=h fs/xfs/xfs_mount.c - 1.356 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.356&r2=text&tr2=1.355&f=h fs/xfs/xfs_btree.c - 1.109 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_btree.c.diff?r1=text&tr1=1.109&r2=text&tr2=1.108&f=h fs/xfs/xfs_btree.h - 1.58 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_btree.h.diff?r1=text&tr1=1.58&r2=text&tr2=1.57&f=h fs/xfs/xfs_dir2_data.c - 1.26 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_data.c.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h fs/xfs/xfs_dir2_data.h - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_data.h.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h fs/xfs/xfs_inode.c - 1.413 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.413&r2=text&tr2=1.412&f=h fs/xfs/xfs_inode.h - 1.200 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.h.diff?r1=text&tr1=1.200&r2=text&tr2=1.199&f=h fs/xfs/xfs_dir2_leaf.c - 1.38 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_leaf.c.diff?r1=text&tr1=1.38&r2=text&tr2=1.37&f=h fs/xfs/xfs_dir2_leaf.h - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_leaf.h.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h fs/xfs/xfs_attr_leaf.h - 1.36 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr_leaf.h.diff?r1=text&tr1=1.36&r2=text&tr2=1.35&f=h fs/xfs/xfs_attr_leaf.c - 1.80 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr_leaf.c.diff?r1=text&tr1=1.80&r2=text&tr2=1.79&f=h fs/xfs/xfs_trans.c - 1.162 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans.c.diff?r1=text&tr1=1.162&r2=text&tr2=1.161&f=h fs/xfs/xfs_error.c - 1.50 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_error.c.diff?r1=text&tr1=1.50&r2=text&tr2=1.49&f=h fs/xfs/xfs_error.h - 1.39 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_error.h.diff?r1=text&tr1=1.39&r2=text&tr2=1.38&f=h fs/xfs/xfs_alloc.c - 1.174 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_alloc.c.diff?r1=text&tr1=1.174&r2=text&tr2=1.173&f=h fs/xfs/xfs_bmap.h - 1.87 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.h.diff?r1=text&tr1=1.87&r2=text&tr2=1.86&f=h fs/xfs/xfs_bmap.c - 1.324 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.c.diff?r1=text&tr1=1.324&r2=text&tr2=1.323&f=h fs/xfs/xfs_attr.c - 1.120 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr.c.diff?r1=text&tr1=1.120&r2=text&tr2=1.119&f=h fs/xfs/xfs_attr.h - 1.32 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr.h.diff?r1=text&tr1=1.32&r2=text&tr2=1.31&f=h fs/xfs/quota/xfs_trans_dquot.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_trans_dquot.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h fs/xfs/quota/xfs_qm_bhv.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm_bhv.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h fs/xfs/quota/xfs_dquot_item.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_dquot_item.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h fs/xfs/quota/xfs_dquot.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_dquot.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h fs/xfs/quota/xfs_qm.h - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h fs/xfs/quota/xfs_qm.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h From owner-linux-xfs@oss.sgi.com Wed May 18 06:07:07 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 May 2005 06:07:20 -0700 (PDT) Received: from cirse.extra.cea.fr (cirse.extra.cea.fr [132.166.172.102]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4ID71F3023354 for ; Wed, 18 May 2005 06:07:06 -0700 Received: from argiope.saclay.cea.fr (argiope.saclay.cea.fr [132.166.192.108]) by cirse.extra.cea.fr (8.12.10/8.12.10/CEAnet-Internet.4.0) with ESMTP id j4ID6PAN008135 for ; Wed, 18 May 2005 15:06:25 +0200 (MEST) Received: from pisaure.intra.cea.fr (unverified) by argiope.saclay.cea.fr (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Wed, 18 May 2005 15:06:24 +0200 Received: from nenuphar.saclay.cea.fr (nenuphar.saclay.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.12.11/8.12.11) with ESMTP id j4ID4KoT030003; Wed, 18 May 2005 15:04:20 +0200 (envelope-from degremont@ocre.cea.fr) Received: from ocre.cea.fr ([132.165.65.70]) by nenuphar.saclay.cea.fr (8.12.10/8.12.10/CEAnet-internes.4.0) with ESMTP id j4ID6NZa004861; Wed, 18 May 2005 15:06:23 +0200 (MEST) Message-ID: <428B3DCF.5080904@ocre.cea.fr> Date: Wed, 18 May 2005 15:06:23 +0200 From: Aurelien Degremont - Stagiaire User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us MIME-Version: 1.0 To: Dean Roehrich CC: linux-xfs@oss.sgi.com Subject: Re: [DMAPI] code error in dm_ip_to_handle() References: <20050518014742.EBD074FE8A@chewtoy.americas.sgi.com> In-Reply-To: <20050518014742.EBD074FE8A@chewtoy.americas.sgi.com> Content-Type: multipart/mixed; boundary="------------090609040202050203090103" X-archive-position: 5252 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: degremont@ocre.cea.fr Precedence: bulk X-list: linux-xfs Content-Length: 3695 Lines: 125 This is a multi-part message in MIME format. --------------090609040202050203090103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Dean Roehrich a écrit: > Can you give me a patch for the library to convert it from xfs_fid2_t to > dm_fid_t? > > Let XFS continue to use xfs_fid2_t. Ok, that's done. See the attached file. I found another small error concerning the handle validity checks. (I guess) In order to be sure the fsid is not null, you test the 32-bits MSB against 0 and the 32-bits LSB against 0, of the fsid. if (!handle.ha_fsid.val[0] || !handle.ha_fsid.val[1]) return(DM_HANDLE_BAD); If my fsid is, by example, "0x00000000000009F4A", it is correct ? But this test will detect the left part is null and so declares it BAD. So I changed the test to verify only, the fsid value is not null. if (! handle.ha_fsid) return(DM_HANDLE_BAD); Aurelien --------------090609040202050203090103 Content-Type: text/plain; name="libdm_xfs_refs.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="libdm_xfs_refs.diff" diff -u libdm.orig/dm_handle.c libdm/dm_handle.c --- libdm.orig/dm_handle.c 2005-05-18 09:54:42.000000000 +0200 +++ libdm/dm_handle.c 2005-05-18 13:00:20.000000000 +0200 @@ -32,8 +32,8 @@ */ #ifdef linux -#include -#include +#include /* Do we really need those includes ? */ +#include #else #include #include @@ -153,8 +153,8 @@ dm_ino_t *inop, dm_igen_t *igenp) { - xfs_handle_t handle; - xfs_fid2_t *xfid2; + dm_handle_t handle; + dm_fid_t *dmfid; fid_t *fidp; if (hanp == DM_GLOBAL_HANP && hlen == DM_GLOBAL_HLEN) @@ -164,7 +164,7 @@ return(DM_HANDLE_BAD); memcpy(&handle, hanp, hlen); - if (!handle.ha_fsid.val[0] || !handle.ha_fsid.val[1]) + if (! handle.ha_fsid) return(DM_HANDLE_BAD); if (fsidp) memcpy(fsidp, &handle.ha_fsid, sizeof(handle.ha_fsid)); @@ -176,18 +176,18 @@ if (fidp->fid_len != (hlen - sizeof(handle.ha_fsid) - sizeof(fidp->fid_len))) return(DM_HANDLE_BAD); #else - if (handle.ha_fid.fid_len != (hlen - sizeof(handle.ha_fsid) - sizeof(handle.ha_fid.fid_len))) + if (handle.ha_fid.dm_fid_len != (hlen - sizeof(handle.ha_fsid) - sizeof(handle.ha_fid.dm_fid_len))) return(DM_HANDLE_BAD); #endif - xfid2 = (struct xfs_fid2 *)&handle.ha_fid; - if (xfid2->fid_len == sizeof *xfid2 - sizeof xfid2->fid_len) { - if (xfid2->fid_pad) + dmfid = (struct dm_fid_t *)&handle.ha_fid; + if (dmfid->dm_fid_len == sizeof *dmfid - sizeof dmfid->dm_fid_len) { + if (dmfid->dm_fid_pad) return(DM_HANDLE_BAD); if (inop) - *inop = xfid2->fid_ino; + *inop = dmfid->dm_fid_ino; if (igenp) - *igenp = xfid2->fid_gen; + *igenp = dmfid->dm_fid_gen; } else { return(DM_HANDLE_BAD); } @@ -291,17 +291,17 @@ void **hanpp, size_t *hlenp) { - xfs_fid2_t *xfid2; + dm_fid_t *fid; /* XXX */ - xfs_handle_t handle; + dm_handle_t handle; memcpy(&handle.ha_fsid, fsidp, sizeof(handle.ha_fsid)); - xfid2 = (struct xfs_fid2 *)&handle.ha_fid; - xfid2->fid_pad = 0; - xfid2->fid_gen = (__u32)*igenp; - xfid2->fid_ino = *inop; - xfid2->fid_len = sizeof(*xfid2) - sizeof(xfid2->fid_len); - *hlenp = sizeof(*xfid2) + sizeof(handle.ha_fsid); + fid = (struct dm_fid *)&handle.ha_fid; + fid->dm_fid_pad = 0; + fid->dm_fid_gen = (__u32)*igenp; + fid->dm_fid_ino = *inop; + fid->dm_fid_len = sizeof(*fid) - sizeof(fid->dm_fid_len); + *hlenp = sizeof(*fid) + sizeof(handle.ha_fsid); if ((*hanpp = malloc(*hlenp)) == NULL) { errno = ENOMEM; return -1; --------------090609040202050203090103-- From owner-linux-xfs@oss.sgi.com Wed May 18 07:10:44 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 May 2005 07:10:51 -0700 (PDT) Received: from s14.s14avahost.net (s14.s14avahost.net [66.98.146.55]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4IEAhF3029215 for ; Wed, 18 May 2005 07:10:44 -0700 Received: from host217-37-158-154.in-addr.btopenworld.com ([217.37.158.154] helo=[192.168.27.54]) by s14.s14avahost.net with esmtpa (Exim 4.44) id 1DYPFN-0006DU-Sv for linux-xfs@oss.sgi.com; Wed, 18 May 2005 09:10:06 -0500 Message-ID: <428B4CC0.70702@katalix.com> Date: Wed, 18 May 2005 15:10:08 +0100 From: James Chapman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en, en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Files >4GB in XFS realtime partition Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PopBeforeSMTPSenders: jchapman@katalix.com X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s14.s14avahost.net X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - katalix.com X-Source: X-Source-Args: X-Source-Dir: X-archive-position: 5253 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jchapman@katalix.com Precedence: bulk X-list: linux-xfs Content-Length: 396 Lines: 14 I'm seeing corrupt data when trying to read/write files >4GB in a realtime partition. Are there any known bugs in this area? Corruption only occurs when the file grows larger than 4GB. No problems are seen when using non-realtime XFS partitions. Kernel: 2.4.29 Arch: MIPS -- James Chapman Katalix Systems Ltd http://www.katalix.com Catalysts for your Embedded Linux software development From owner-linux-xfs@oss.sgi.com Wed May 18 08:21:08 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 May 2005 08:21:21 -0700 (PDT) Received: from server260.mjz.name (server260.mjz.name [65.98.68.194]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4IFL7F3007165 for ; Wed, 18 May 2005 08:21:08 -0700 Received: from fw.bitband.com ([213.8.50.174] helo=shaul2-laptop.bitband.com) by server260.mjz.name with esmtpa (Exim 4.50) id 1DYQLa-00049j-V2 for linux-xfs@oss.sgi.com; Wed, 18 May 2005 11:20:35 -0400 Subject: Bad Sectors Behavior From: Nir Dremer To: linux-xfs@oss.sgi.com Content-Type: text/plain Date: Wed, 18 May 2005 18:20:26 +0300 Message-Id: <1116429626.8348.63.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server260.mjz.name X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - dremer.org X-Source: X-Source-Args: X-Source-Dir: X-archive-position: 5254 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mailing@dremer.org Precedence: bulk X-list: linux-xfs Content-Length: 185 Lines: 11 I'm looking for official documentation explaining XFS behavior when new Bad Sectors are detected on the file-system. Is there such documentation? Thanks, Nir Dremer www.dremer.org From owner-linux-xfs@oss.sgi.com Wed May 18 10:35:17 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 May 2005 10:35:20 -0700 (PDT) Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4IHZGF3016745 for ; Wed, 18 May 2005 10:35:17 -0700 Received: from pimout3-ext.prodigy.net (pimout3-int.prodigy.net [207.115.4.218]) by ylpvm43.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j4IHYh9S032382 for ; Wed, 18 May 2005 13:34:46 -0400 X-ORBL: [63.205.185.30] Received: from taniwha.stupidest.org (adsl-63-205-185-30.dsl.snfc21.pacbell.net [63.205.185.30]) by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j4IHYaRb174636; Wed, 18 May 2005 13:34:36 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 3EB23528F26; Wed, 18 May 2005 10:34:36 -0700 (PDT) Date: Wed, 18 May 2005 10:34:36 -0700 From: Chris Wedgwood To: Nir Dremer Cc: linux-xfs@oss.sgi.com Subject: Re: Bad Sectors Behavior Message-ID: <20050518173436.GA12000@taniwha.stupidest.org> References: <1116429626.8348.63.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1116429626.8348.63.camel@localhost> X-archive-position: 5255 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 335 Lines: 9 On Wed, May 18, 2005 at 06:20:26PM +0300, Nir Dremer wrote: > I'm looking for official documentation explaining XFS behavior when > new Bad Sectors are detected on the file-system. XFS doesn't handle bad sectors, if such an error occurs the filesystem will barf and return EFSCORRUPTED (990 presently as Linux doesn't define this). From owner-linux-xfs@oss.sgi.com Wed May 18 10:38:57 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 May 2005 10:39:10 -0700 (PDT) Received: from hermes.wildbrain.com (mail.wildbrain.com [209.130.193.228]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4IHcuF3017154 for ; Wed, 18 May 2005 10:38:56 -0700 Received: from [10.20.2.11] (magellan.wildbrain.com [10.20.2.11]) (authenticated bits=0) by hermes.wildbrain.com (8.12.8/8.12.8) with ESMTP id j4IHc7BW008305; Wed, 18 May 2005 10:38:08 -0700 Message-ID: <428B7D7F.9000107@wildbrain.com> Date: Wed, 18 May 2005 10:38:07 -0700 From: Gregory Brauer User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com CC: Chris Wedgwood Subject: Re: kernel OOPS for XFS in xfs_iget_core (using NFS+SMP+MD) References: <428511F8.6020303@wildbrain.com> <20050514184711.GA27565@taniwha.stupidest.org> In-Reply-To: <20050514184711.GA27565@taniwha.stupidest.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-WB-MailScanner: Found to be clean X-WB-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-2.445, required 5, BAYES_00 -2.60, TW_JB 0.08, TW_UH 0.08) X-MailScanner-From: greg@wildbrain.com X-archive-position: 5256 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: greg@wildbrain.com Precedence: bulk X-list: linux-xfs Content-Length: 5326 Lines: 112 Chris Wedgwood wrote: > On Fri, May 13, 2005 at 01:45:44PM -0700, Gregory Brauer wrote: > > >>I have seen some references to a similar bug in other kernel list >>posts from October 2004 and am trying to figure out if this is the >>same problem, or something new related to the xfs_iget_core patch in >>2.6.11. This seems to be a very hard to reproduce bug, but we've >>seen this problem twice in a week of testing under Fedora >>Core 3 on the following kernel: > > > does disabling CONFIG_4K_STACKS help? No. Here is the oops for a kernel.org kernel 2.6.11.10 compiled with the same config file that FC3 uses for their kernel (2.6.11-1.14_FC3) except with the CONFIG_4KSTACKS=y line commented out. This one died after about 8 hours of testing. May 18 02:59:47 violet kernel: xfs_iget_core: ambiguous vns: vp/0xf53f8ac8, invp/0xe49ccc4c May 18 02:59:47 violet kernel: ------------[ cut here ]------------ May 18 02:59:47 violet kernel: kernel BUG at fs/xfs/support/debug.c:106! May 18 02:59:47 violet kernel: invalid operand: 0000 [#1] May 18 02:59:47 violet kernel: SMP May 18 02:59:47 violet kernel: Modules linked in: nfsd lockd md5 ipv6 parport_pc lp parport sunrpc xfs exportfs dm_mod video button battery ac uhci_h cd hw_random i2c_i801 i2c_core e1000 bonding floppy ext3 jbd raid0 3w_xxxx sd_mod scsi_mod May 18 02:59:47 violet kernel: CPU: 0 May 18 02:59:47 violet kernel: EIP: 0060:[] Not tainted VLI May 18 02:59:47 violet kernel: EFLAGS: 00010246 (2.6.11.10) May 18 02:59:47 violet kernel: EIP is at cmn_err+0xa5/0xd0 [xfs] May 18 02:59:47 violet kernel: eax: 00000000 ebx: f920a178 ecx: f921e484 edx: 00000200 May 18 02:59:47 violet kernel: esi: f92099f8 edi: f921fa1e ebp: 00000000 esp: f643db48 May 18 02:59:47 violet kernel: ds: 007b es: 007b ss: 0068 May 18 02:59:47 violet kernel: Process nfsd (pid: 6177, threadinfo=f643c000 task=f6ab4560) May 18 02:59:47 violet kernel: Stack: f92099f8 f92099bf f921f9e0 00000282 f643c000 f920a178 00000000 dc8444ac May 18 02:59:47 violet kernel: f91d5fe4 00000000 f920a178 f53f8ac8 e49ccc4c f71d7c00 f92053b3 ed7c01f4 May 18 02:59:47 violet kernel: 00000000 e49ccc70 ed7c01f0 00000000 f707f400 e49ccc4c dc8444ac e49ccc70 May 18 02:59:47 violet kernel: Call Trace: May 18 02:59:47 violet kernel: [] xfs_iget_core+0x514/0x610 [xfs] May 18 02:59:47 violet kernel: [] linvfs_alloc_inode+0x23/0x30 [xfs] May 18 02:59:47 violet kernel: [] xfs_iget+0xd4/0x170 [xfs] May 18 02:59:47 violet kernel: [] xfs_vget+0x6b/0xf0 [xfs] May 18 02:59:47 violet kernel: [] alloc_skb+0x41/0xf0 May 18 02:59:47 violet kernel: [] vfs_vget+0x2d/0x40 [xfs] May 18 02:59:47 violet kernel: [] linvfs_get_dentry+0x39/0x70 [xfs] May 18 02:59:47 violet kernel: [] find_exported_dentry+0x2d/0x630 [exportfs] May 18 02:59:47 violet kernel: [] ip_append_data+0x57c/0x850 May 18 02:59:47 violet kernel: [] udp_sendmsg+0x2f9/0x6d0 May 18 02:59:47 violet kernel: [] e1000_xmit_frame+0x557/0x8e0 [e1000] May 18 02:59:47 violet kernel: [] packet_rcv_spkt+0xd2/0x260 May 18 02:59:47 violet kernel: [] qdisc_restart+0x20/0x230 May 18 02:59:47 violet kernel: [] dev_queue_xmit+0x26b/0x300 May 18 02:59:47 violet kernel: [] ip_finish_output+0xda/0x290 May 18 02:59:47 violet kernel: [] sock_sendmsg+0x118/0x150 May 18 02:59:47 violet kernel: [] ip_push_pending_frames+0x240/0x490 May 18 02:59:47 violet kernel: [] autoremove_wake_function+0x0/0x50 May 18 02:59:47 violet kernel: [] udp_push_pending_frames+0x139/0x270 May 18 02:59:47 violet kernel: [] recalc_task_prio+0x88/0x150 May 18 02:59:47 violet kernel: [] svc_expkey_lookup+0x40a/0x430 [nfsd] May 18 02:59:47 violet kernel: [] linvfs_decode_fh+0x63/0xd0 [xfs] May 18 02:59:47 violet kernel: [] nfsd_acceptable+0x0/0x100 [nfsd] May 18 02:59:47 violet kernel: [] linvfs_decode_fh+0x0/0xd0 [xfs] May 18 02:59:47 violet kernel: [] fh_verify+0x1d8/0x5a0 [nfsd] May 18 02:59:47 violet kernel: [] nfsd_acceptable+0x0/0x100 [nfsd] May 18 02:59:47 violet kernel: [] nfsd_lookup+0x43/0x4d0 [nfsd] May 18 02:59:47 violet kernel: [] nfsd_proc_lookup+0x54/0xa0 [nfsd] May 18 02:59:47 violet kernel: [] nfssvc_decode_diropargs+0x0/0xd0 [nfsd] May 18 02:59:47 violet kernel: [] nfsd_dispatch+0x8a/0x210 [nfsd] May 18 02:59:47 violet kernel: [] svc_authenticate+0x86/0xd0 [sunrpc] May 18 02:59:47 violet kernel: [] svc_process+0x551/0x640 [sunrpc] May 18 02:59:47 violet kernel: [] smp_call_function_interrupt+0x3c/0x60 May 18 02:59:47 violet kernel: [] call_function_interrupt+0x1c/0x24 May 18 02:59:47 violet kernel: [] nfsd+0x190/0x310 [nfsd] May 18 02:59:47 violet kernel: [] nfsd+0x0/0x310 [nfsd] May 18 02:59:47 violet kernel: [] kernel_thread_helper+0x5/0x10 May 18 02:59:47 violet kernel: Code: b8 e0 f9 21 f9 89 44 24 08 8b 04 ad a0 e4 21 f9 89 44 24 04 e8 ed cd f1 c6 8b 54 24 0c b8 84 e4 21 f9 e8 bf 4d 1 2 c7 85 ed 75 08 <0f> 0b 6a 00 df 99 20 f9 8b 5c 24 10 8b 74 24 14 8b 7c 24 18 8b Greg From owner-linux-xfs@oss.sgi.com Wed May 18 11:00:10 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 May 2005 11:00:23 -0700 (PDT) Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4II09F3020432 for ; Wed, 18 May 2005 11:00:10 -0700 Received: from pimout1-ext.prodigy.net (pimout1-int.prodigy.net [207.115.5.65]) by ylpvm15.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j4IHxXPJ003445 for ; Wed, 18 May 2005 13:59:33 -0400 X-ORBL: [63.205.185.30] Received: from taniwha.stupidest.org (adsl-63-205-185-30.dsl.snfc21.pacbell.net [63.205.185.30]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j4IHxQf1076510; Wed, 18 May 2005 13:59:28 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id C7C07528F26; Wed, 18 May 2005 10:59:25 -0700 (PDT) Date: Wed, 18 May 2005 10:59:25 -0700 From: Chris Wedgwood To: Gregory Brauer Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: kernel OOPS for XFS in xfs_iget_core (using NFS+SMP+MD) Message-ID: <20050518175925.GA22738@taniwha.stupidest.org> References: <428511F8.6020303@wildbrain.com> <20050514184711.GA27565@taniwha.stupidest.org> <428B7D7F.9000107@wildbrain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <428B7D7F.9000107@wildbrain.com> X-archive-position: 5257 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 234 Lines: 7 On Wed, May 18, 2005 at 10:38:07AM -0700, Gregory Brauer wrote: > May 18 02:59:47 violet kernel: xfs_iget_core: ambiguous vns: vp/0xf53f8ac8, invp/0xe49ccc4c I'm pretty sure it's NFS that aggravates this --- can anyone recall why? From owner-linux-xfs@oss.sgi.com Wed May 18 12:53:35 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 May 2005 12:53:44 -0700 (PDT) Received: from unthought.net (unthought.net [212.97.129.88]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4IJrUF3028699 for ; Wed, 18 May 2005 12:53:35 -0700 Received: by unthought.net (Postfix, from userid 1000) id A015CAEA8; Wed, 18 May 2005 21:52:51 +0200 (CEST) Date: Wed, 18 May 2005 21:52:51 +0200 From: Jakob Oestergaard To: Chris Wedgwood Cc: Gregory Brauer , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: kernel OOPS for XFS in xfs_iget_core (using NFS+SMP+MD) Message-ID: <20050518195251.GY422@unthought.net> Mail-Followup-To: Jakob Oestergaard , Chris Wedgwood , Gregory Brauer , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com References: <428511F8.6020303@wildbrain.com> <20050514184711.GA27565@taniwha.stupidest.org> <428B7D7F.9000107@wildbrain.com> <20050518175925.GA22738@taniwha.stupidest.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050518175925.GA22738@taniwha.stupidest.org> User-Agent: Mutt/1.3.28i X-archive-position: 5258 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jakob@unthought.net Precedence: bulk X-list: linux-xfs Content-Length: 759 Lines: 23 On Wed, May 18, 2005 at 10:59:25AM -0700, Chris Wedgwood wrote: > On Wed, May 18, 2005 at 10:38:07AM -0700, Gregory Brauer wrote: > > > May 18 02:59:47 violet kernel: xfs_iget_core: ambiguous vns: vp/0xf53f8ac8, invp/0xe49ccc4c > > I'm pretty sure it's NFS that aggravates this --- can anyone recall > why? Not why no - but there where *major* problems with SMP+NFS+XFS up until 2.6.11. I run 2.6.11(.8/9) on both SMP (dual athlon) and NUMA (64 bit kernel on dual opteron) with NFS and XFS and haven't yet seen any problems (knock the wood). Seriously, any 2.6 earlier than .11 is *unusable* for file serving over NFS (at least with XFS which at the moment is the only FS with journalled quota so at least for me that's the only option). -- / jakob From owner-linux-xfs@oss.sgi.com Wed May 18 13:02:55 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 May 2005 13:03:09 -0700 (PDT) Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4IK2sF3029908 for ; Wed, 18 May 2005 13:02:55 -0700 Received: from chaos.egr.duke.edu (localhost.localdomain [127.0.0.1]) by chaos.egr.duke.edu (8.12.11/8.12.11) with ESMTP id j4IK08hC005018; Wed, 18 May 2005 16:00:08 -0400 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.12.11/8.12.11/Submit) with ESMTP id j4IK08eI005014; Wed, 18 May 2005 16:00:08 -0400 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Wed, 18 May 2005 16:00:08 -0400 (EDT) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: Jakob Oestergaard cc: Chris Wedgwood , Gregory Brauer , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: kernel OOPS for XFS in xfs_iget_core (using NFS+SMP+MD) In-Reply-To: <20050518195251.GY422@unthought.net> Message-ID: References: <428511F8.6020303@wildbrain.com> <20050514184711.GA27565@taniwha.stupidest.org> <428B7D7F.9000107@wildbrain.com> <20050518175925.GA22738@taniwha.stupidest.org> <20050518195251.GY422@unthought.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5259 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jlb17@duke.edu Precedence: bulk X-list: linux-xfs Content-Length: 1241 Lines: 32 On Wed, 18 May 2005 at 9:52pm, Jakob Oestergaard wrote > On Wed, May 18, 2005 at 10:59:25AM -0700, Chris Wedgwood wrote: > > On Wed, May 18, 2005 at 10:38:07AM -0700, Gregory Brauer wrote: > > > > > May 18 02:59:47 violet kernel: xfs_iget_core: ambiguous vns: vp/0xf53f8ac8, invp/0xe49ccc4c > > > > I'm pretty sure it's NFS that aggravates this --- can anyone recall > > why? > > Not why no - but there where *major* problems with SMP+NFS+XFS up until > 2.6.11. > > I run 2.6.11(.8/9) on both SMP (dual athlon) and NUMA (64 bit kernel on > dual opteron) with NFS and XFS and haven't yet seen any problems (knock > the wood). > > Seriously, any 2.6 earlier than .11 is *unusable* for file serving over > NFS (at least with XFS which at the moment is the only FS with > journalled quota so at least for me that's the only option). Do you have a test case that would show this up? I've been testing a centos-4 based server with the RH-derived 2.6.9-based kernel tweaked to disable 4K stacks and enable XFS and haven't run into any issues yet. This includes running the parallel IOR benchmark from 10 clients (and getting 200MiB/s throughput on reads). -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Wed May 18 13:20:52 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 May 2005 13:21:05 -0700 (PDT) Received: from unthought.net (unthought.net [212.97.129.88]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4IKKqF3031081 for ; Wed, 18 May 2005 13:20:52 -0700 Received: by unthought.net (Postfix, from userid 1000) id 0E761B084; Wed, 18 May 2005 22:20:14 +0200 (CEST) Date: Wed, 18 May 2005 22:20:14 +0200 From: Jakob Oestergaard To: Joshua Baker-LePain Cc: Chris Wedgwood , Gregory Brauer , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: kernel OOPS for XFS in xfs_iget_core (using NFS+SMP+MD) Message-ID: <20050518202014.GZ422@unthought.net> Mail-Followup-To: Jakob Oestergaard , Joshua Baker-LePain , Chris Wedgwood , Gregory Brauer , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com References: <428511F8.6020303@wildbrain.com> <20050514184711.GA27565@taniwha.stupidest.org> <428B7D7F.9000107@wildbrain.com> <20050518175925.GA22738@taniwha.stupidest.org> <20050518195251.GY422@unthought.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-archive-position: 5260 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jakob@unthought.net Precedence: bulk X-list: linux-xfs Content-Length: 1268 Lines: 34 On Wed, May 18, 2005 at 04:00:08PM -0400, Joshua Baker-LePain wrote: ... > > > > Seriously, any 2.6 earlier than .11 is *unusable* for file serving over > > NFS (at least with XFS which at the moment is the only FS with > > journalled quota so at least for me that's the only option). > > Do you have a test case that would show this up? I've been testing a > centos-4 based server with the RH-derived 2.6.9-based kernel tweaked to > disable 4K stacks and enable XFS and haven't run into any issues yet. > This includes running the parallel IOR benchmark from 10 clients (and > getting 200MiB/s throughput on reads). Server must be SMP Two clients; on each of them untar/cat/delete kernel trees. You want a few million files on the FS in order to confuse the server sufficiently for it to screw up severely. Make sure you keep lots of things going concurrently on the clients. And don't run as root - common problems are also that files get wrong ownership/modes (a file created by one unprivileged user shows up as belonging to another unprivileged user - files can show up with modes d---------) I guess RH could have patched up a 2.6.9 to include whatever fixes (more than one!) for the issues that were resolved from 2.6.9 to 2.6.11. -- / jakob From owner-linux-xfs@oss.sgi.com Wed May 18 13:50:26 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 May 2005 13:50:39 -0700 (PDT) Received: from hermes.wildbrain.com (mail.wildbrain.com [209.130.193.228]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4IKoPF3000577 for ; Wed, 18 May 2005 13:50:25 -0700 Received: from [10.20.2.11] (magellan.wildbrain.com [10.20.2.11]) (authenticated bits=0) by hermes.wildbrain.com (8.12.8/8.12.8) with ESMTP id j4IKhGBW018388; Wed, 18 May 2005 13:43:16 -0700 Message-ID: <428BA8E4.2040108@wildbrain.com> Date: Wed, 18 May 2005 13:43:16 -0700 From: Gregory Brauer User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com CC: Joshua Baker-LePain , Jakob Oestergaard , Chris Wedgwood Subject: Re: kernel OOPS for XFS in xfs_iget_core (using NFS+SMP+MD) References: <428511F8.6020303@wildbrain.com> <20050514184711.GA27565@taniwha.stupidest.org> <428B7D7F.9000107@wildbrain.com> <20050518175925.GA22738@taniwha.stupidest.org> <20050518195251.GY422@unthought.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-WB-MailScanner: Found to be clean X-WB-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-1.845, required 5, BAYES_00 -2.60, J_CHICKENPOX_45 0.60, TW_JB 0.08, TW_UH 0.08) X-MailScanner-From: greg@wildbrain.com X-archive-position: 5261 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: greg@wildbrain.com Precedence: bulk X-list: linux-xfs Content-Length: 2816 Lines: 80 Joshua Baker-LePain wrote: > Do you have a test case that would show this up? I've been testing a > centos-4 based server with the RH-derived 2.6.9-based kernel tweaked to > disable 4K stacks and enable XFS and haven't run into any issues yet. > This includes running the parallel IOR benchmark from 10 clients (and > getting 200MiB/s throughput on reads). > For Jakob, Note that the last OOPS I posted was for 2.6.11.10. For Joshua, We first saw the problem after 5 days in production, but since then we took the server out of production and used the script nfs_fsstress.sh located in this package: http://prdownloads.sourceforge.net/ltp/ltp-full-20050505.tgz?download We run the script on 5 client machines that are running RedHat 9 with kernel-smp-2.4.20-20.9 and nfs-utils-1.0.1-3.9.1.legacy and are NFS mounting our 2.6 kernel server. The longest time to OOPS has been about 8 hours. We have not tried the parallel IOR benchmark. (Where can we get that?) You didn't mention if you are using md at all. We have a software RAID-0 of 4 x 3ware 8506-4 controllers running the latest 3ware driver from their site. The filesystem is XFS. The network driver is e1000 (two interfaces, not bonded). The system is a dual Xeon. We upped the number of NFS daemons from 8 to 64. The nfs_fsstress.sh client mounts the servers both UDP and TCP, and our in-production oops likely happened with a combination of both protocols in use simultaneously as well. We've seen the OOPS with both the default and with 32K read and write NFS block sizes. The machine was stable for over a year with RedHat 9 and 2.4.20. I'm grasping for any subtle details that might help... Here is our list of loaded modules: Our server configuration is Module Size Used by nfsd 185569 65 exportfs 9921 1 nfsd lockd 59625 2 nfsd md5 8001 1 ipv6 236769 16 parport_pc 29701 1 lp 15405 0 parport 37129 2 parport_pc,lp sunrpc 135077 28 nfsd,lockd xfs 487809 1 dm_mod 57925 0 video 19653 0 button 10577 0 battery 13253 0 ac 8773 0 uhci_hcd 33497 0 hw_random 9429 0 i2c_i801 11981 0 i2c_core 24513 1 i2c_i801 e1000 84629 0 bonding 59817 0 floppy 56913 0 ext3 117961 2 jbd 57177 1 ext3 raid0 11840 1 3w_xxxx 30561 4 sd_mod 20545 4 scsi_mod 116033 2 3w_xxxx,sd_mod Let me know if there is anything else I can provide. Thanks. Greg From owner-linux-xfs@oss.sgi.com Wed May 18 14:00:31 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 May 2005 14:00:43 -0700 (PDT) Received: from hermes.wildbrain.com (mail.wildbrain.com [209.130.193.228]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4IL0UF3001731 for ; Wed, 18 May 2005 14:00:31 -0700 Received: from [10.20.2.11] (magellan.wildbrain.com [10.20.2.11]) (authenticated bits=0) by hermes.wildbrain.com (8.12.8/8.12.8) with ESMTP id j4IKrMBW020861; Wed, 18 May 2005 13:53:22 -0700 Message-ID: <428BAB42.8030501@wildbrain.com> Date: Wed, 18 May 2005 13:53:22 -0700 From: Gregory Brauer User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com CC: Jakob Oestergaard , Joshua Baker-LePain , Chris Wedgwood Subject: Re: kernel OOPS for XFS in xfs_iget_core (using NFS+SMP+MD) References: <428511F8.6020303@wildbrain.com> <20050514184711.GA27565@taniwha.stupidest.org> <428B7D7F.9000107@wildbrain.com> <20050518175925.GA22738@taniwha.stupidest.org> <20050518195251.GY422@unthought.net> <20050518202014.GZ422@unthought.net> In-Reply-To: <20050518202014.GZ422@unthought.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-WB-MailScanner: Found to be clean X-WB-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-2.599, required 5, autolearn=not spam, BAYES_00 -2.60) X-MailScanner-From: greg@wildbrain.com X-archive-position: 5262 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: greg@wildbrain.com Precedence: bulk X-list: linux-xfs Content-Length: 673 Lines: 18 Jakob Oestergaard wrote: > You want a few million files on the FS in order to confuse the server > sufficiently for it to screw up severely. Here we reproduced the OOPS with an fresh and empty XFS volume using the nfs_fsstress.sh script. > And don't run as root - common problems are also that files get wrong > ownership/modes (a file created by one unprivileged user shows up as > belonging to another unprivileged user - files can show up with modes > d---------) Our nfs_fsstress.sh tests were running as root and writing only root-owned files (with no_root_squash, of course) and reproduced the OOPS twice. We haven't seen the privileges problem yet. Greg From owner-linux-xfs@oss.sgi.com Wed May 18 18:06:59 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 May 2005 18:07:05 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4J16vF3020403 for ; Wed, 18 May 2005 18:06:58 -0700 Received: from mumble.melbourne.sgi.com (mumble.melbourne.sgi.com [134.14.55.227]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA07242; Thu, 19 May 2005 11:06:10 +1000 Received: from mumble.melbourne.sgi.com (localhost [127.0.0.1]) by mumble.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j4J165Xf112348; Thu, 19 May 2005 11:06:05 +1000 (EST) Received: (from dgc@localhost) by mumble.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j4J1627e112373; Thu, 19 May 2005 11:06:02 +1000 (EST) Date: Thu, 19 May 2005 11:06:02 +1000 From: Dave Chinner To: Steve Lord Cc: XFS Linux , kas@fi.muni.cz Subject: Re: [Fwd: XFS lstat() _very_ slow on SMP] Message-ID: <20050519110602.U61431@melbourne.sgi.com> References: <4288D8B8.4070302@xfs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <4288D8B8.4070302@xfs.org>; from lord@xfs.org on Mon, May 16, 2005 at 12:30:32PM -0500 X-archive-position: 5264 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1203 Lines: 38 On Mon, May 16, 2005 at 12:30:32PM -0500, Steve Lord wrote: > Forwarding from lkml to somewhere where it might be seen. > > Steve > > -------- Original Message -------- > Subject: XFS lstat() _very_ slow on SMP > Date: Mon, 16 May 2005 18:25:06 +0200 > From: Jan Kasprzak > To: linux-kernel@vger.kernel.org > > Hi all, > > I have a big XFS volume on my fileserver, and I have noticed that > making an incremental backup of this volume is _very_ slow. The incremental > backup essentially checks mtime of all files on this volume, and it > takes ~4ms of _system_ time (i.e. no iowait or what) to do a lstat(). > > The server is quad opteron with 26GB of RAM, 2.6.11.x kernel. > The volume in question is this big: > > $ df -i /export/home > Filesystem Inodes IUsed IFree IUse% Mounted on > /dev/array-vg/home 2147502080 7917653 2139584427 1% /export/home > $ df -k /export/home > Filesystem 1K-blocks Used Available Use% Mounted on > /dev/array-vg/home 2147371008 558965100 1588405908 27% /export/home Have you tried setting the ihashsize mount option? Cheers, Dave. -- Dave Chinner R&D Software Engineer SGI Australian Software Group From owner-linux-xfs@oss.sgi.com Thu May 19 03:36:21 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 May 2005 03:36:25 -0700 (PDT) Received: from flyingAngel.upjs.sk (user.novell.cz [195.47.104.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JAaKF3030636 for ; Thu, 19 May 2005 03:36:21 -0700 Received: by flyingAngel.upjs.sk (Postfix, from userid 500) id 40C4412505F; Thu, 19 May 2005 12:35:31 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by flyingAngel.upjs.sk (Postfix) with ESMTP id 4055B18196A; Thu, 19 May 2005 12:35:31 +0200 (CEST) Date: Thu, 19 May 2005 12:35:31 +0200 (CEST) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: Dave Chinner Cc: Steve Lord , XFS Linux , kas@fi.muni.cz Subject: Re: [Fwd: XFS lstat() _very_ slow on SMP] In-Reply-To: <20050519110602.U61431@melbourne.sgi.com> Message-ID: References: <4288D8B8.4070302@xfs.org> <20050519110602.U61431@melbourne.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5265 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ja@mail.upjs.sk Precedence: bulk X-list: linux-xfs Content-Length: 230 Lines: 13 On Thu, 19 May 2005, Dave Chinner wrote: Hello. > Have you tried setting the ihashsize mount option? Is there any reason why this and other options from xfs_vfsops.c are undocumented? Is safe to change their values? jan -- From owner-linux-xfs@oss.sgi.com Thu May 19 09:03:24 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 May 2005 09:03:30 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JG3LF3011519 for ; Thu, 19 May 2005 09:03:21 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4JHlVDZ014902 for ; Thu, 19 May 2005 10:47:31 -0700 Received: from chewtoy.americas.sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4JG1eR08425275; Thu, 19 May 2005 11:01:40 -0500 (CDT) Received: from chewtoy (localhost [127.0.0.1]) by chewtoy.americas.sgi.com (Postfix) with ESMTP id C21634FE8A; Thu, 19 May 2005 11:01:39 -0500 (CDT) To: Aurelien Degremont - Stagiaire Cc: linux-xfs@oss.sgi.com Subject: Re: [DMAPI] code error in dm_ip_to_handle() Date: Thu, 19 May 2005 11:01:39 -0500 From: Dean Roehrich Message-Id: <20050519160139.C21634FE8A@chewtoy.americas.sgi.com> X-archive-position: 5266 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 3769 Lines: 142 >From: Aurelien Degremont - Stagiaire >diff -u libdm.orig/dm_handle.c libdm/dm_handle.c >--- libdm.orig/dm_handle.c 2005-05-18 09:54:42.000000000 +0200 >+++ libdm/dm_handle.c 2005-05-18 13:00:20.000000000 +0200 >@@ -32,8 +32,8 @@ > */ > > #ifdef linux >-#include >-#include >+#include /* Do we really need those includes ? */ >+#include We don't need them anymore. > #else >- if (handle.ha_fid.fid_len != (hlen - sizeof(handle.ha_fsid) - sizeof(ha >ndle.ha_fid.fid_len))) >+ if (handle.ha_fid.dm_fid_len != (hlen - sizeof(handle.ha_fsid) - sizeof >(handle.ha_fid.dm_fid_len))) > return(DM_HANDLE_BAD); > #endif You took the non-linux branch on that #if-#else. >+ dmfid = (struct dm_fid_t *)&handle.ha_fid; Don't need the cast. >+ fid = (struct dm_fid *)&handle.ha_fid; Don't need the cast. Okay, here's an updated version. Dean Index: lbs-rpms-a/xfs-cmds/dmapi/libdm/dm_handle.c =================================================================== --- lbs-rpms-a.orig/xfs-cmds/dmapi/libdm/dm_handle.c 2004-10-03 17:20:59.000000000 -0700 +++ lbs-rpms-a/xfs-cmds/dmapi/libdm/dm_handle.c 2005-05-18 20:05:58.000000000 -0700 @@ -31,15 +31,9 @@ * http://oss.sgi.com/projects/GenInfo/SGIGPLNoticeExplan/ */ -#ifdef linux -#include -#include -#else -#include #include #include #include -#endif #include #include @@ -153,9 +147,8 @@ parse_handle( dm_ino_t *inop, dm_igen_t *igenp) { - xfs_handle_t handle; - xfs_fid2_t *xfid2; - fid_t *fidp; + dm_handle_t handle; + dm_fid_t *dmfid; if (hanp == DM_GLOBAL_HANP && hlen == DM_GLOBAL_HLEN) return(DM_HANDLE_GLOBAL); @@ -164,30 +157,24 @@ parse_handle( return(DM_HANDLE_BAD); memcpy(&handle, hanp, hlen); - if (!handle.ha_fsid.val[0] || !handle.ha_fsid.val[1]) + if (! handle.ha_fsid) return(DM_HANDLE_BAD); if (fsidp) memcpy(fsidp, &handle.ha_fsid, sizeof(handle.ha_fsid)); if (hlen == sizeof(handle.ha_fsid)) return(DM_HANDLE_FILESYSTEM); -#ifdef linux - fidp = (fid_t*)&handle.ha_fid; - if (fidp->fid_len != (hlen - sizeof(handle.ha_fsid) - sizeof(fidp->fid_len))) + if (handle.ha_fid.dm_fid_len != (hlen - sizeof(handle.ha_fsid) - sizeof(handle.ha_fid.dm_fid_len))) return(DM_HANDLE_BAD); -#else - if (handle.ha_fid.fid_len != (hlen - sizeof(handle.ha_fsid) - sizeof(handle.ha_fid.fid_len))) - return(DM_HANDLE_BAD); -#endif - xfid2 = (struct xfs_fid2 *)&handle.ha_fid; - if (xfid2->fid_len == sizeof *xfid2 - sizeof xfid2->fid_len) { - if (xfid2->fid_pad) + dmfid = &handle.ha_fid; + if (dmfid->dm_fid_len == sizeof *dmfid - sizeof dmfid->dm_fid_len) { + if (dmfid->dm_fid_pad) return(DM_HANDLE_BAD); if (inop) - *inop = xfid2->fid_ino; + *inop = dmfid->dm_fid_ino; if (igenp) - *igenp = xfid2->fid_gen; + *igenp = dmfid->dm_fid_gen; } else { return(DM_HANDLE_BAD); } @@ -291,17 +278,16 @@ dm_make_handle( void **hanpp, size_t *hlenp) { - xfs_fid2_t *xfid2; -/* XXX */ - xfs_handle_t handle; + dm_fid_t *fid; + dm_handle_t handle; memcpy(&handle.ha_fsid, fsidp, sizeof(handle.ha_fsid)); - xfid2 = (struct xfs_fid2 *)&handle.ha_fid; - xfid2->fid_pad = 0; - xfid2->fid_gen = (__u32)*igenp; - xfid2->fid_ino = *inop; - xfid2->fid_len = sizeof(*xfid2) - sizeof(xfid2->fid_len); - *hlenp = sizeof(*xfid2) + sizeof(handle.ha_fsid); + fid = &handle.ha_fid; + fid->dm_fid_pad = 0; + fid->dm_fid_gen = (__u32)*igenp; + fid->dm_fid_ino = *inop; + fid->dm_fid_len = sizeof(*fid) - sizeof(fid->dm_fid_len); + *hlenp = sizeof(*fid) + sizeof(handle.ha_fsid); if ((*hanpp = malloc(*hlenp)) == NULL) { errno = ENOMEM; return -1; From owner-linux-xfs@oss.sgi.com Thu May 19 11:44:49 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 May 2005 11:44:53 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JIimF3005381 for ; Thu, 19 May 2005 11:44:48 -0700 Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4JIi4xT024495 for ; Thu, 19 May 2005 13:44:05 -0500 Received: from naboo.americas.sgi.com (localhost [127.0.0.1]) by naboo.americas.sgi.com (8.13.3/8.13.3) with ESMTP id j4HHbOVl023832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 May 2005 12:37:25 -0500 Received: (from cattelan@localhost) by naboo.americas.sgi.com (8.13.3/8.13.3/Submit) id j4HHbMPE023831; Tue, 17 May 2005 12:37:22 -0500 Date: Tue, 17 May 2005 12:37:22 -0500 From: Russell Cattelan Message-Id: <200505171737.j4HHbMPE023831@naboo.americas.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.snlinux@engr.sgi.com Subject: TAKE 936205 - X-archive-position: 5267 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@naboo.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 453 Lines: 14 Export a missing symbol needed by a kdb function Date: Tue May 17 10:37:13 PDT 2005 Workarea: naboo.americas.sgi.com:/go/space/XFS/xfs-linux Inspected by: felixb@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:192716a linux-2.4/xfs_ksyms.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ksyms.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h From owner-linux-xfs@oss.sgi.com Thu May 19 12:44:33 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 May 2005 12:44:41 -0700 (PDT) Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JJiWF3020689 for ; Thu, 19 May 2005 12:44:32 -0700 Received: from chaos.egr.duke.edu (localhost.localdomain [127.0.0.1]) by chaos.egr.duke.edu (8.12.11/8.12.11) with ESMTP id j4JJhqrW007338; Thu, 19 May 2005 15:43:52 -0400 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.12.11/8.12.11/Submit) with ESMTP id j4JJhmwd007334; Thu, 19 May 2005 15:43:52 -0400 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Thu, 19 May 2005 15:43:48 -0400 (EDT) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: Gregory Brauer cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Jakob Oestergaard , Chris Wedgwood Subject: Re: kernel OOPS for XFS in xfs_iget_core (using NFS+SMP+MD) In-Reply-To: <428BA8E4.2040108@wildbrain.com> Message-ID: References: <428511F8.6020303@wildbrain.com> <20050514184711.GA27565@taniwha.stupidest.org> <428B7D7F.9000107@wildbrain.com> <20050518175925.GA22738@taniwha.stupidest.org> <20050518195251.GY422@unthought.net> <428BA8E4.2040108@wildbrain.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5268 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jlb17@duke.edu Precedence: bulk X-list: linux-xfs Content-Length: 2263 Lines: 51 On Wed, 18 May 2005 at 1:43pm, Gregory Brauer wrote > Joshua Baker-LePain wrote: > > Do you have a test case that would show this up? I've been testing a > > centos-4 based server with the RH-derived 2.6.9-based kernel tweaked to > > disable 4K stacks and enable XFS and haven't run into any issues yet. > > This includes running the parallel IOR benchmark from 10 clients (and > > getting 200MiB/s throughput on reads). > > > > We first saw the problem after 5 days in production, but since then > we took the server out of production and used the script > nfs_fsstress.sh located in this package: > > http://prdownloads.sourceforge.net/ltp/ltp-full-20050505.tgz?download > > We run the script on 5 client machines that are running RedHat 9 > with kernel-smp-2.4.20-20.9 and nfs-utils-1.0.1-3.9.1.legacy and > are NFS mounting our 2.6 kernel server. The longest time to OOPS My clients are all RHEL3. I'll give the nfs_fsstress scripts a shot. > has been about 8 hours. We have not tried the parallel IOR > benchmark. (Where can we get that?) http://www.llnl.gov/asci/purple/benchmarks/limited/ior/ > You didn't mention if you are using md at all. We have a > software RAID-0 of 4 x 3ware 8506-4 controllers running the > latest 3ware driver from their site. The filesystem is XFS. > The network driver is e1000 (two interfaces, not bonded). The > system is a dual Xeon. We upped the number of NFS daemons > from 8 to 64. The nfs_fsstress.sh client mounts the servers > both UDP and TCP, and our in-production oops likely happened > with a combination of both protocols in use simultaneously as > well. We've seen the OOPS with both the default and with 32K > read and write NFS block sizes. The machine was stable for > over a year with RedHat 9 and 2.4.20. The server I'll be testing is dual Xeon, 2GB RAM, 2 x 3ware 9500-12 controllers running the 9.1.5.2 firmware and using the stock centos-4 drivers. (I see a huge performance hit using the latest 3ware driver set, 9.2.) The 3wares are doing hardware RAID5, and I do software RAID0 across 'em. Networking is the same -- 2 e1000s, not bonded. I'm running 256 NFS daemons, well, just because. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Thu May 19 12:57:48 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 May 2005 12:57:52 -0700 (PDT) Received: from smtp2.activestate.com (gw.activestate.com [209.17.183.249]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JJvmF3022811 for ; Thu, 19 May 2005 12:57:48 -0700 Received: from rock.activestate.com (rock.ActiveState.com [192.168.3.223]) by smtp2.activestate.com (8.12.11/8.12.11) with ESMTP id j4JJv6Vk013318 for ; Thu, 19 May 2005 12:57:06 -0700 (envelope-from daves@activestate.com) Received: from [127.0.0.1] (localhost [127.0.0.1]) by rock.activestate.com (8.13.1/8.13.1) with ESMTP id j4JJv57V016826 for ; Thu, 19 May 2005 12:57:05 -0700 Message-ID: <428CEF90.3000309@activestate.com> Date: Thu, 19 May 2005 12:57:04 -0700 From: David Sparks Reply-To: daves@activestate.com User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050330) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: slipstream update of xfsprogs-2.6.25? X-Enigmail-Version: 0.90.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 5269 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: daves@activestate.com Precedence: bulk X-list: linux-xfs Content-Length: 471 Lines: 17 What happened to the sources for xfsprogs-2.6.25? I noticed a md5 and size change recently but the version # is the same? This seems to be just a slipstream update but has caused some inconvenience with a web cache of sources I run. I hope this isn't standard practice to re-use version #s and filenames. -rw-r--r-- 1 apache apache 850424 Oct 10 2004 xfsprogs-2.6.25.src.tar.gz vs -rw-r--r-- 1 apache apache 850313 May 9 18:06 xfsprogs-2.6.25.src.tar.gz ds From owner-linux-xfs@oss.sgi.com Thu May 19 14:01:13 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 May 2005 14:01:17 -0700 (PDT) Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JL1CF3027915 for ; Thu, 19 May 2005 14:01:12 -0700 Received: from chaos.egr.duke.edu (localhost.localdomain [127.0.0.1]) by chaos.egr.duke.edu (8.12.11/8.12.11) with ESMTP id j4JL0WVa008103; Thu, 19 May 2005 17:00:32 -0400 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.12.11/8.12.11/Submit) with ESMTP id j4JL0MNX008099; Thu, 19 May 2005 17:00:32 -0400 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Thu, 19 May 2005 17:00:22 -0400 (EDT) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: Gregory Brauer cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Jakob Oestergaard , Chris Wedgwood Subject: Re: kernel OOPS for XFS in xfs_iget_core (using NFS+SMP+MD) In-Reply-To: Message-ID: References: <428511F8.6020303@wildbrain.com> <20050514184711.GA27565@taniwha.stupidest.org> <428B7D7F.9000107@wildbrain.com> <20050518175925.GA22738@taniwha.stupidest.org> <20050518195251.GY422@unthought.net> <428BA8E4.2040108@wildbrain.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5270 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jlb17@duke.edu Precedence: bulk X-list: linux-xfs Content-Length: 5119 Lines: 84 On Thu, 19 May 2005 at 3:43pm, Joshua Baker-LePain wrote > On Wed, 18 May 2005 at 1:43pm, Gregory Brauer wrote > > We first saw the problem after 5 days in production, but since then > > we took the server out of production and used the script > > nfs_fsstress.sh located in this package: > > > > http://prdownloads.sourceforge.net/ltp/ltp-full-20050505.tgz?download > > > > We run the script on 5 client machines that are running RedHat 9 > > with kernel-smp-2.4.20-20.9 and nfs-utils-1.0.1-3.9.1.legacy and > > are NFS mounting our 2.6 kernel server. The longest time to OOPS > > My clients are all RHEL3 (well, centos 3 actually). I'll give the > nfs_fsstress scripts a shot. Hrm. That didn't take long. I've got 6 clients (3 per interface) going with nfs_fsstress.sh, and I saw the following in the logs on the server after about 20 minutes. Note, however, that I can still access the FS, both locally on the server and via NFS. The scripts are still going, but some have already reported errors (obviously). The server error: May 19 16:47:10 norbert kernel: xfs_da_do_buf: bno 8388608 May 19 16:47:10 norbert kernel: dir: inode 2162706 May 19 16:47:10 norbert kernel: Filesystem "md0": XFS internal error xfs_da_do_buf(1) at line 2176 of file fs/xfs/xfs_da_btree.c. Caller 0xf8c90148 May 19 16:47:10 norbert kernel: [] xfs_da_do_buf+0x357/0x70d [xfs] May 19 16:47:10 norbert kernel: [] xfs_da_read_buf+0x19/0x1e [xfs] May 19 16:47:10 norbert kernel: [] buffered_rmqueue+0x17d/0x1a5 May 19 16:47:10 norbert kernel: [] xfs_da_read_buf+0x19/0x1e [xfs] May 19 16:47:10 norbert kernel: [] xfs_da_node_lookup_int+0x9d/0x2c0 [xfs] May 19 16:47:10 norbert kernel: [] xfs_da_node_lookup_int+0x9d/0x2c0 [xfs] May 19 16:47:10 norbert kernel: [] kmem_zone_alloc+0x3b/0x70 [xfs] May 19 16:47:10 norbert kernel: [] xfs_dir2_node_lookup+0x34/0x96 [xfs] May 19 16:47:10 norbert kernel: [] xfs_dir2_lookup+0xde/0x107 [xfs] May 19 16:47:10 norbert kernel: [] avc_has_perm_noaudit+0x8d/0xda May 19 16:47:10 norbert kernel: [] avc_has_perm_noaudit+0x8d/0xda May 19 16:47:10 norbert kernel: [] xfs_dir_lookup_int+0x26/0xa8 [xfs] May 19 16:47:10 norbert kernel: [] xfs_lookup+0x40/0x69 [xfs] May 19 16:47:10 norbert kernel: [] wake_up_inode+0x6/0x29 May 19 16:47:10 norbert kernel: [] vfs_init_vnode+0x1e/0x22 [xfs] May 19 16:47:10 norbert kernel: [] linvfs_get_parent+0x43/0x75 [xfs] May 19 16:47:10 norbert kernel: [] __cond_resched+0x14/0x39 May 19 16:47:10 norbert kernel: [] __cond_resched+0x14/0x39 May 19 16:47:10 norbert kernel: [] d_alloc+0x197/0x1a1 May 19 16:47:10 norbert kernel: [] d_alloc_anon+0xd1/0xee May 19 16:47:10 norbert kernel: [] __cond_resched+0x14/0x39 May 19 16:47:10 norbert kernel: [] find_exported_dentry+0x303/0x5e8 [exportfs] May 19 16:47:10 norbert kernel: [] skb_copy_datagram_iovec+0x4f/0x1e1 May 19 16:47:10 norbert kernel: [] release_sock+0xf/0x4f May 19 16:47:10 norbert kernel: [] tcp_recvmsg+0x64a/0x681 May 19 16:47:10 norbert kernel: [] sock_common_recvmsg+0x30/0x46 May 19 16:47:10 norbert kernel: [] sock_recvmsg+0xef/0x10c May 19 16:47:10 norbert kernel: [] dst_output+0x0/0x1a May 19 16:47:10 norbert kernel: [] recalc_task_prio+0x128/0x133 May 19 16:47:10 norbert kernel: [] activate_task+0x88/0x95 May 19 16:47:10 norbert kernel: [] try_to_wake_up+0x222/0x22d May 19 16:47:10 norbert kernel: [] __wake_up_common+0x36/0x51 May 19 16:47:11 norbert kernel: [] __wake_up+0x29/0x3c May 19 16:47:11 norbert kernel: [] svc_sock_enqueue+0x1d6/0x212 [sunrpc] May 19 16:47:11 norbert kernel: [] svc_tcp_recvfrom+0x304/0x376 [sunrpc] May 19 16:47:11 norbert kernel: [] svc_expkey_lookup+0x1fc/0x330 [nfsd] May 19 16:47:11 norbert kernel: [] export_decode_fh+0x61/0x6d [exportfs] May 19 16:47:11 norbert kernel: [] nfsd_acceptable+0x0/0xba [nfsd] May 19 16:47:11 norbert kernel: [] export_decode_fh+0x0/0x6d [exportfs] May 19 16:47:11 norbert kernel: [] fh_verify+0x3bc/0x5bd [nfsd] May 19 16:47:11 norbert kernel: [] nfsd_acceptable+0x0/0xba [nfsd] May 19 16:47:11 norbert kernel: [] nfsd3_proc_getattr+0x6f/0x77 [nfsd] May 19 16:47:11 norbert kernel: [] nfs3svc_decode_fhandle+0x0/0x8d [nfsd] May 19 16:47:11 norbert kernel: [] nfsd_dispatch+0xba/0x16f [nfsd] May 19 16:47:11 norbert kernel: [] svc_process+0x420/0x6d6 [sunrpc] May 19 16:47:11 norbert kernel: [] nfsd+0x1cc/0x332 [nfsd] May 19 16:47:11 norbert kernel: [] nfsd+0x0/0x332 [nfsd] May 19 16:47:11 norbert kernel: [] kernel_thread_helper+0x5/0xb May 19 16:47:11 norbert kernel: nfsd: non-standard errno: -990 -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Thu May 19 14:10:04 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 May 2005 14:10:09 -0700 (PDT) Received: from viper.oldcity.dca.net (viper.oldcity.dca.net [216.158.38.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4JLA3F3028651 for ; Thu, 19 May 2005 14:10:03 -0700 Received: (qmail 10962 invoked from network); 19 May 2005 21:09:24 -0000 Received: from unknown (HELO mindpipe) (207.245.115.154) by viper with SMTP; 19 May 2005 21:09:24 -0000 Subject: Re: kernel OOPS for XFS in xfs_iget_core (using NFS+SMP+MD) From: Lee Revell To: Joshua Baker-LePain Cc: Gregory Brauer , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Jakob Oestergaard , Chris Wedgwood In-Reply-To: References: <428511F8.6020303@wildbrain.com> <20050514184711.GA27565@taniwha.stupidest.org> <428B7D7F.9000107@wildbrain.com> <20050518175925.GA22738@taniwha.stupidest.org> <20050518195251.GY422@unthought.net> <428BA8E4.2040108@wildbrain.com> Content-Type: text/plain Date: Thu, 19 May 2005 17:09:23 -0400 Message-Id: <1116536963.23186.2.camel@mindpipe> Mime-Version: 1.0 X-Mailer: Evolution 2.3.1 Content-Transfer-Encoding: 7bit X-archive-position: 5271 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rlrevell@joe-job.com Precedence: bulk X-list: linux-xfs Content-Length: 4053 Lines: 55 On Thu, 2005-05-19 at 17:00 -0400, Joshua Baker-LePain wrote: > May 19 16:47:10 norbert kernel: Filesystem "md0": XFS internal error xfs_da_do_buf(1) at line 2176 of file fs/xfs/xfs_da_btree.c. Caller 0xf8c90148 > May 19 16:47:10 norbert kernel: [] xfs_da_do_buf+0x357/0x70d [xfs] > May 19 16:47:10 norbert kernel: [] xfs_da_read_buf+0x19/0x1e [xfs] > May 19 16:47:10 norbert kernel: [] buffered_rmqueue+0x17d/0x1a5 > May 19 16:47:10 norbert kernel: [] xfs_da_read_buf+0x19/0x1e [xfs] > May 19 16:47:10 norbert kernel: [] xfs_da_node_lookup_int+0x9d/0x2c0 [xfs] > May 19 16:47:10 norbert kernel: [] xfs_da_node_lookup_int+0x9d/0x2c0 [xfs] > May 19 16:47:10 norbert kernel: [] kmem_zone_alloc+0x3b/0x70 [xfs] > May 19 16:47:10 norbert kernel: [] xfs_dir2_node_lookup+0x34/0x96 [xfs] > May 19 16:47:10 norbert kernel: [] xfs_dir2_lookup+0xde/0x107 [xfs] > May 19 16:47:10 norbert kernel: [] avc_has_perm_noaudit+0x8d/0xda > May 19 16:47:10 norbert kernel: [] avc_has_perm_noaudit+0x8d/0xda > May 19 16:47:10 norbert kernel: [] xfs_dir_lookup_int+0x26/0xa8 [xfs] > May 19 16:47:10 norbert kernel: [] xfs_lookup+0x40/0x69 [xfs] > May 19 16:47:10 norbert kernel: [] wake_up_inode+0x6/0x29 > May 19 16:47:10 norbert kernel: [] vfs_init_vnode+0x1e/0x22 [xfs] > May 19 16:47:10 norbert kernel: [] linvfs_get_parent+0x43/0x75 [xfs] > May 19 16:47:10 norbert kernel: [] __cond_resched+0x14/0x39 > May 19 16:47:10 norbert kernel: [] __cond_resched+0x14/0x39 > May 19 16:47:10 norbert kernel: [] d_alloc+0x197/0x1a1 > May 19 16:47:10 norbert kernel: [] d_alloc_anon+0xd1/0xee > May 19 16:47:10 norbert kernel: [] __cond_resched+0x14/0x39 > May 19 16:47:10 norbert kernel: [] find_exported_dentry+0x303/0x5e8 [exportfs] > May 19 16:47:10 norbert kernel: [] skb_copy_datagram_iovec+0x4f/0x1e1 > May 19 16:47:10 norbert kernel: [] release_sock+0xf/0x4f > May 19 16:47:10 norbert kernel: [] tcp_recvmsg+0x64a/0x681 > May 19 16:47:10 norbert kernel: [] sock_common_recvmsg+0x30/0x46 > May 19 16:47:10 norbert kernel: [] sock_recvmsg+0xef/0x10c > May 19 16:47:10 norbert kernel: [] dst_output+0x0/0x1a > May 19 16:47:10 norbert kernel: [] recalc_task_prio+0x128/0x133 > May 19 16:47:10 norbert kernel: [] activate_task+0x88/0x95 > May 19 16:47:10 norbert kernel: [] try_to_wake_up+0x222/0x22d > May 19 16:47:10 norbert kernel: [] __wake_up_common+0x36/0x51 > May 19 16:47:11 norbert kernel: [] __wake_up+0x29/0x3c > May 19 16:47:11 norbert kernel: [] svc_sock_enqueue+0x1d6/0x212 [sunrpc] > May 19 16:47:11 norbert kernel: [] svc_tcp_recvfrom+0x304/0x376 [sunrpc] > May 19 16:47:11 norbert kernel: [] svc_expkey_lookup+0x1fc/0x330 [nfsd] > May 19 16:47:11 norbert kernel: [] export_decode_fh+0x61/0x6d [exportfs] > May 19 16:47:11 norbert kernel: [] nfsd_acceptable+0x0/0xba [nfsd] > May 19 16:47:11 norbert kernel: [] export_decode_fh+0x0/0x6d [exportfs] > May 19 16:47:11 norbert kernel: [] fh_verify+0x3bc/0x5bd [nfsd] > May 19 16:47:11 norbert kernel: [] nfsd_acceptable+0x0/0xba [nfsd] > May 19 16:47:11 norbert kernel: [] nfsd3_proc_getattr+0x6f/0x77 [nfsd] > May 19 16:47:11 norbert kernel: [] nfs3svc_decode_fhandle+0x0/0x8d [nfsd] > May 19 16:47:11 norbert kernel: [] nfsd_dispatch+0xba/0x16f [nfsd] > May 19 16:47:11 norbert kernel: [] svc_process+0x420/0x6d6 [sunrpc] > May 19 16:47:11 norbert kernel: [] nfsd+0x1cc/0x332 [nfsd] > May 19 16:47:11 norbert kernel: [] nfsd+0x0/0x332 [nfsd] > May 19 16:47:11 norbert kernel: [] kernel_thread_helper+0x5/0xb Couldn't this be a stack overflow? That's a very large kernel stack. Lee From owner-linux-xfs@oss.sgi.com Thu May 19 14:16:43 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 May 2005 14:16:46 -0700 (PDT) Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JLGgF3029482 for ; Thu, 19 May 2005 14:16:43 -0700 Received: from chaos.egr.duke.edu (localhost.localdomain [127.0.0.1]) by chaos.egr.duke.edu (8.12.11/8.12.11) with ESMTP id j4JLG3nj008128; Thu, 19 May 2005 17:16:03 -0400 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.12.11/8.12.11/Submit) with ESMTP id j4JLG3xB008124; Thu, 19 May 2005 17:16:03 -0400 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Thu, 19 May 2005 17:16:03 -0400 (EDT) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: Lee Revell cc: Gregory Brauer , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Jakob Oestergaard , Chris Wedgwood Subject: Re: kernel OOPS for XFS in xfs_iget_core (using NFS+SMP+MD) In-Reply-To: <1116536963.23186.2.camel@mindpipe> Message-ID: References: <428511F8.6020303@wildbrain.com> <20050514184711.GA27565@taniwha.stupidest.org> <428B7D7F.9000107@wildbrain.com> <20050518175925.GA22738@taniwha.stupidest.org> <20050518195251.GY422@unthought.net> <428BA8E4.2040108@wildbrain.com> <1116536963.23186.2.camel@mindpipe> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5272 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jlb17@duke.edu Precedence: bulk X-list: linux-xfs Content-Length: 492 Lines: 15 On Thu, 19 May 2005 at 5:09pm, Lee Revell wrote > On Thu, 2005-05-19 at 17:00 -0400, Joshua Baker-LePain wrote: > > May 19 16:47:10 norbert kernel: Filesystem "md0": XFS internal error xfs_da_do_buf(1) at line 2176 of file fs/xfs/xfs_da_btree.c. Caller 0xf8c90148 *snip* > > Couldn't this be a stack overflow? That's a very large kernel stack. I am using 8K stacks, and that's all the kernel messages I see. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Thu May 19 14:27:52 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 May 2005 14:27:56 -0700 (PDT) Received: from ylpvm12.prodigy.net (ylpvm12-ext.prodigy.net [207.115.57.43]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JLRpF3030638 for ; Thu, 19 May 2005 14:27:52 -0700 Received: from pimout4-ext.prodigy.net (pimout4-ext.prodigy.net [207.115.63.98]) by ylpvm12.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j4JLR9ee027902 for ; Thu, 19 May 2005 17:27:09 -0400 X-ORBL: [63.205.185.30] Received: from taniwha.stupidest.org (adsl-63-205-185-30.dsl.snfc21.pacbell.net [63.205.185.30]) by pimout4-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j4JLR3Qg071776; Thu, 19 May 2005 17:27:04 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id E883A528F22; Thu, 19 May 2005 14:27:03 -0700 (PDT) Date: Thu, 19 May 2005 14:27:03 -0700 From: Chris Wedgwood To: Joshua Baker-LePain Cc: Gregory Brauer , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Jakob Oestergaard Subject: Re: kernel OOPS for XFS in xfs_iget_core (using NFS+SMP+MD) Message-ID: <43e211ed9b147428f39b5739644d1125.IBX@taniwha.stupidest.org> References: <428511F8.6020303@wildbrain.com> <20050514184711.GA27565@taniwha.stupidest.org> <428B7D7F.9000107@wildbrain.com> <20050518175925.GA22738@taniwha.stupidest.org> <20050518195251.GY422@unthought.net> <428BA8E4.2040108@wildbrain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-archive-position: 5273 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 1565 Lines: 39 On Thu, May 19, 2005 at 05:00:22PM -0400, Joshua Baker-LePain wrote: > May 19 16:47:10 norbert kernel: xfs_da_do_buf: bno 8388608 > May 19 16:47:10 norbert kernel: dir: inode 2162706 > May 19 16:47:10 norbert kernel: Filesystem "md0": XFS internal error xfs_da_do_buf(1) at line 2176 of file fs/xfs/xfs_da_btree.c. Caller 0xf8c90148 > May 19 16:47:10 norbert kernel: [] xfs_da_do_buf+0x357/0x70d [xfs] This isn't what was reported before. Maybe check inode 2162706 on disk using xfs_db and make sure it looks OK? As pointed out it is a really long call-chain --- I'm guessing it's OK but it could still be a stack overflow problem as with 8K stacks you don't have separate IRQ stacks. If you like you could apply the following patch and *enable* CONFIG_4KSTACKS. In this case is badly named as you will really have 8K process stacks and 4K irq stacks after applying this. Index: cw-current/include/asm-i386/thread_info.h =================================================================== --- cw-current.orig/include/asm-i386/thread_info.h 2004-12-15 14:35:00.296402459 -0800 +++ cw-current/include/asm-i386/thread_info.h 2004-12-15 14:38:20.129259160 -0800 @@ -54,12 +54,12 @@ #define PREEMPT_ACTIVE 0x10000000 #ifdef CONFIG_4KSTACKS -#define THREAD_SIZE (4096) +#define THREAD_SIZE (8192) #else #define THREAD_SIZE (8192) #endif -#define STACK_WARN (THREAD_SIZE/8) +#define STACK_WARN (THREAD_SIZE/2) /* * macros/functions for gaining access to the thread information structure * From owner-linux-xfs@oss.sgi.com Thu May 19 14:30:19 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 May 2005 14:30:25 -0700 (PDT) Received: from mail00hq.adic.com (mail.adic.com [63.81.117.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JLUJF3031218 for ; Thu, 19 May 2005 14:30:19 -0700 Received: from mail02hq.adic.com ([172.16.9.18]) by mail00hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 19 May 2005 14:29:39 -0700 Received: from [172.16.82.67] ([172.16.82.67]) by mail02hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 19 May 2005 14:29:38 -0700 Message-ID: <428D0540.4000107@xfs.org> Date: Thu, 19 May 2005 16:29:36 -0500 From: Steve Lord User-Agent: Mozilla Thunderbird 1.0.2-1.3.3 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joshua Baker-LePain CC: Lee Revell , Gregory Brauer , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Jakob Oestergaard , Chris Wedgwood Subject: Re: kernel OOPS for XFS in xfs_iget_core (using NFS+SMP+MD) References: <428511F8.6020303@wildbrain.com> <20050514184711.GA27565@taniwha.stupidest.org> <428B7D7F.9000107@wildbrain.com> <20050518175925.GA22738@taniwha.stupidest.org> <20050518195251.GY422@unthought.net> <428BA8E4.2040108@wildbrain.com> <1116536963.23186.2.camel@mindpipe> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 May 2005 21:29:38.0610 (UTC) FILETIME=[DC62E120:01C55CB9] X-archive-position: 5274 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 1138 Lines: 34 Joshua Baker-LePain wrote: > On Thu, 19 May 2005 at 5:09pm, Lee Revell wrote > > >>On Thu, 2005-05-19 at 17:00 -0400, Joshua Baker-LePain wrote: >> >>>May 19 16:47:10 norbert kernel: Filesystem "md0": XFS internal error xfs_da_do_buf(1) at line 2176 of file fs/xfs/xfs_da_btree.c. Caller 0xf8c90148 > > *snip* > >>Couldn't this be a stack overflow? That's a very large kernel stack. > > > I am using 8K stacks, and that's all the kernel messages I see. > The stack backtrace just converts all the code addresses it sees on the stack, so you get extra false positives in there, it is not as large as it seems. Try setting /proc/sys/fs/xfs/error_level to 1 and running again, it should spout out some more information about what it thinks is corrupted. Does xfs_repair report anything after this has happened, it looks like it is trying to read a directory block up from disk to satisfy a lookup request and failing for some reason. My suspicion is that the filesystem will look ok (unmount it, then remount to reply the log, then unmount again before running repair). anything else in the syslog shortly before this? Steve From owner-linux-xfs@oss.sgi.com Thu May 19 14:33:29 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 May 2005 14:33:34 -0700 (PDT) Received: from mail00hq.adic.com (mail.adic.com [63.81.117.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JLXRF3031641 for ; Thu, 19 May 2005 14:33:27 -0700 Received: from mail02hq.adic.com ([172.16.9.18]) by mail00hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 19 May 2005 14:32:50 -0700 Received: from [172.16.82.67] ([172.16.82.67]) by mail02hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 19 May 2005 14:32:49 -0700 Message-ID: <428D05FF.6090305@xfs.org> Date: Thu, 19 May 2005 16:32:47 -0500 From: Steve Lord User-Agent: Mozilla Thunderbird 1.0.2-1.3.3 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Lord CC: Joshua Baker-LePain , Lee Revell , Gregory Brauer , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Jakob Oestergaard , Chris Wedgwood Subject: Re: kernel OOPS for XFS in xfs_iget_core (using NFS+SMP+MD) References: <428511F8.6020303@wildbrain.com> <20050514184711.GA27565@taniwha.stupidest.org> <428B7D7F.9000107@wildbrain.com> <20050518175925.GA22738@taniwha.stupidest.org> <20050518195251.GY422@unthought.net> <428BA8E4.2040108@wildbrain.com> <1116536963.23186.2.camel@mindpipe> <428D0540.4000107@xfs.org> In-Reply-To: <428D0540.4000107@xfs.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 May 2005 21:32:49.0462 (UTC) FILETIME=[4E249560:01C55CBA] X-archive-position: 5275 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 265 Lines: 13 Steve Lord wrote: > > Try setting /proc/sys/fs/xfs/error_level to 1 and running again, > it should spout out some more information about what it thinks > is corrupted. > Never mind, you already did that didn't you. I will now go back to my day job..... Steve From owner-linux-xfs@oss.sgi.com Thu May 19 14:36:05 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 May 2005 14:36:12 -0700 (PDT) Received: from ylpvm12.prodigy.net (ylpvm12-ext.prodigy.net [207.115.57.43]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JLa5F3032305 for ; Thu, 19 May 2005 14:36:05 -0700 Received: from pimout4-ext.prodigy.net (pimout4-ext.prodigy.net [207.115.63.98]) by ylpvm12.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j4JLZNeg003127 for ; Thu, 19 May 2005 17:35:23 -0400 X-ORBL: [63.205.185.30] Received: from taniwha.stupidest.org (adsl-63-205-185-30.dsl.snfc21.pacbell.net [63.205.185.30]) by pimout4-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j4JLZMQg185980; Thu, 19 May 2005 17:35:22 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id B019F528F22; Thu, 19 May 2005 14:35:22 -0700 (PDT) Date: Thu, 19 May 2005 14:35:22 -0700 From: Chris Wedgwood To: Steve Lord Cc: Joshua Baker-LePain , Lee Revell , Gregory Brauer , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Jakob Oestergaard Subject: Re: kernel OOPS for XFS in xfs_iget_core (using NFS+SMP+MD) Message-ID: References: <428B7D7F.9000107@wildbrain.com> <20050518175925.GA22738@taniwha.stupidest.org> <20050518195251.GY422@unthought.net> <428BA8E4.2040108@wildbrain.com> <1116536963.23186.2.camel@mindpipe> <428D0540.4000107@xfs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <428D0540.4000107@xfs.org> X-archive-position: 5276 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 315 Lines: 9 On Thu, May 19, 2005 at 04:29:36PM -0500, Steve Lord wrote: > Joshua Baker-LePain wrote: > Does xfs_repair report anything after this has happened, it looks > like it is trying to read a directory block up from disk to satisfy > a lookup request and failing for some reason. bit corruption? bad hardware maybe? From owner-linux-xfs@oss.sgi.com Thu May 19 14:39:14 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 May 2005 14:39:18 -0700 (PDT) Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JLdEF3001185 for ; Thu, 19 May 2005 14:39:14 -0700 Received: from chaos.egr.duke.edu (localhost.localdomain [127.0.0.1]) by chaos.egr.duke.edu (8.12.11/8.12.11) with ESMTP id j4JLcY3M008168; Thu, 19 May 2005 17:38:34 -0400 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.12.11/8.12.11/Submit) with ESMTP id j4JLcYFR008164; Thu, 19 May 2005 17:38:34 -0400 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Thu, 19 May 2005 17:38:34 -0400 (EDT) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: Steve Lord cc: Lee Revell , Gregory Brauer , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Jakob Oestergaard , Chris Wedgwood Subject: Re: kernel OOPS for XFS in xfs_iget_core (using NFS+SMP+MD) In-Reply-To: <428D05FF.6090305@xfs.org> Message-ID: References: <428511F8.6020303@wildbrain.com> <20050514184711.GA27565@taniwha.stupidest.org> <428B7D7F.9000107@wildbrain.com> <20050518175925.GA22738@taniwha.stupidest.org> <20050518195251.GY422@unthought.net> <428BA8E4.2040108@wildbrain.com> <1116536963.23186.2.camel@mindpipe> <428D0540.4000107@xfs.org> <428D05FF.6090305@xfs.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5277 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jlb17@duke.edu Precedence: bulk X-list: linux-xfs Content-Length: 499 Lines: 19 On Thu, 19 May 2005 at 4:32pm, Steve Lord wrote > Steve Lord wrote: > > > > Try setting /proc/sys/fs/xfs/error_level to 1 and running again, > > it should spout out some more information about what it thinks > > is corrupted. > > > Never mind, you already did that didn't you. I will now go back to > my day job..... Actually, I hadn't. And 'cat /proc/sys/fs/xfs/error_level' says '3'. Is 1 more or less verbose? -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Thu May 19 14:42:41 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 May 2005 14:42:45 -0700 (PDT) Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JLgeF3003294 for ; Thu, 19 May 2005 14:42:40 -0700 Received: from chaos.egr.duke.edu (localhost.localdomain [127.0.0.1]) by chaos.egr.duke.edu (8.12.11/8.12.11) with ESMTP id j4JLg1mR008176; Thu, 19 May 2005 17:42:01 -0400 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.12.11/8.12.11/Submit) with ESMTP id j4JLg1kd008172; Thu, 19 May 2005 17:42:01 -0400 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Thu, 19 May 2005 17:42:01 -0400 (EDT) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: Gregory Brauer cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Jakob Oestergaard , Chris Wedgwood Subject: Re: kernel OOPS for XFS in xfs_iget_core (using NFS+SMP+MD) In-Reply-To: Message-ID: References: <428511F8.6020303@wildbrain.com> <20050514184711.GA27565@taniwha.stupidest.org> <428B7D7F.9000107@wildbrain.com> <20050518175925.GA22738@taniwha.stupidest.org> <20050518195251.GY422@unthought.net> <428BA8E4.2040108@wildbrain.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5278 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jlb17@duke.edu Precedence: bulk X-list: linux-xfs Content-Length: 2995 Lines: 77 And now I've got some OOPSes: Unable to handle kernel NULL pointer dereference at virtual address 00000000 printing eip: 00000000 *pde = 37137001 Oops: 0000 [#1] SMP Modules linked in: ipt_REJECT ipt_state ip_conntrack iptable_filter ip_tables nfsd exportfs lockd xfs md5 ipv6 parport_pc lp parport i2c_dev i2c_core sunrpc raid0 dm_mod button battery ac uhci_hcd hw_random e1000 floppy ext3 jbd 3w_9xxx 3w_xxxx sd_mod scsi_mod CPU: 2 EIP: 0060:[<00000000>] Not tainted VLI EFLAGS: 00010286 (2.6.9-5.0.5.EL.XFSsmp) EIP is at 0x0 eax: ca9a8dac ebx: c03f03e0 ecx: 00000000 edx: d8cc689c esi: d8cc689c edi: f2be7f04 ebp: 00000000 esp: f2be7ee8 ds: 007b es: 007b ss: 0068 Process nfsd (pid: 3255, threadinfo=f2be6000 task=f0a5e830) Stack: c0161332 ca9a8dac ffffffff e8f5608d 112f5575 f6b56f24 c01613a6 112f5575 00000005 e8f56088 ca9a8e1c ca9a8e1c ca9a8dac f6b56f24 e8f55804 f8c18aa8 e8f56088 f7fba800 f699c940 f7fba800 00000246 e8f4a000 e8f55800 e8f559d4 Call Trace: [] __lookup_hash+0x70/0x89 [] lookup_one_len+0x54/0x63 [] nfsd_lookup+0x321/0x3ad [nfsd] [] nfsd3_proc_lookup+0xa9/0xb3 [nfsd] [] nfs3svc_decode_diropargs+0x0/0xfa [nfsd] [] nfsd_dispatch+0xba/0x16f [nfsd] [] svc_process+0x420/0x6d6 [sunrpc] [] nfsd+0x1cc/0x332 [nfsd] [] nfsd+0x0/0x332 [nfsd] [] kernel_thread_helper+0x5/0xb Code: Bad EIP value. <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000 printing eip: 00000000 *pde = 1d5c4001 Oops: 0000 [#2] SMP Modules linked in: ipt_REJECT ipt_state ip_conntrack iptable_filter ip_tables nfsd exportfs lockd xfs md5 ipv6 parport_pc lp parport i2c_dev i2c_core sunrpc raid0 dm_mod button battery ac uhci_hcd hw_random e1000 floppy ext3 jbd 3w_9xxx 3w_xxxx sd_mod scsi_mod CPU: 0 EIP: 0060:[<00000000>] Not tainted VLI EFLAGS: 00010286 (2.6.9-5.0.5.EL.XFSsmp) EIP is at 0x0 eax: c325cc30 ebx: c03f03e0 ecx: 00000000 edx: f0ee79cc esi: f0ee79cc edi: e9d99f0c ebp: 00000000 esp: e9d99ef0 ds: 007b es: 007b ss: 0068 Process nfsd (pid: 3353, threadinfo=e9d98000 task=ea2130b0) Stack: c0161332 c325cc30 ffffffff d61f10cf 002249be dad2017c c01613a6 002249be 00000003 d61f10cc c325cca0 c325cca0 c325cc30 dad2017c e88a9000 f8c18aa8 d61f10cc f7d74c00 f699ca00 c234b780 f7d74d60 ea3f7800 e88a9000 ea3f78e8 Call Trace: [] __lookup_hash+0x70/0x89 [] lookup_one_len+0x54/0x63 [] nfsd_lookup+0x321/0x3ad [nfsd] [] nfsd_proc_lookup+0x5f/0x71 [nfsd] [] nfssvc_decode_diropargs+0x0/0xa7 [nfsd] [] nfsd_dispatch+0xba/0x16f [nfsd] [] svc_process+0x420/0x6d6 [sunrpc] [] nfsd+0x1cc/0x332 [nfsd] [] nfsd+0x0/0x332 [nfsd] [] kernel_thread_helper+0x5/0xb Code: Bad EIP value. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Thu May 19 14:43:42 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 May 2005 14:43:45 -0700 (PDT) Received: from mail00hq.adic.com (mail.adic.com [63.81.117.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JLhfF3003893 for ; Thu, 19 May 2005 14:43:41 -0700 Received: from mail02hq.adic.com ([172.16.9.18]) by mail00hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 19 May 2005 14:43:04 -0700 Received: from [172.16.82.67] ([172.16.82.67]) by mail02hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 19 May 2005 14:43:03 -0700 Message-ID: <428D0864.2080503@xfs.org> Date: Thu, 19 May 2005 16:43:00 -0500 From: Steve Lord User-Agent: Mozilla Thunderbird 1.0.2-1.3.3 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joshua Baker-LePain CC: Lee Revell , Gregory Brauer , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Jakob Oestergaard , Chris Wedgwood Subject: Re: kernel OOPS for XFS in xfs_iget_core (using NFS+SMP+MD) References: <428511F8.6020303@wildbrain.com> <20050514184711.GA27565@taniwha.stupidest.org> <428B7D7F.9000107@wildbrain.com> <20050518175925.GA22738@taniwha.stupidest.org> <20050518195251.GY422@unthought.net> <428BA8E4.2040108@wildbrain.com> <1116536963.23186.2.camel@mindpipe> <428D0540.4000107@xfs.org> <428D05FF.6090305@xfs.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 May 2005 21:43:03.0349 (UTC) FILETIME=[BC0C4E50:01C55CBB] X-archive-position: 5279 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 512 Lines: 23 Joshua Baker-LePain wrote: > On Thu, 19 May 2005 at 4:32pm, Steve Lord wrote > > >>Steve Lord wrote: >> >>>Try setting /proc/sys/fs/xfs/error_level to 1 and running again, >>>it should spout out some more information about what it thinks >>>is corrupted. >>> >> >>Never mind, you already did that didn't you. I will now go back to >>my day job..... > > > Actually, I hadn't. And 'cat /proc/sys/fs/xfs/error_level' says '3'. Is > 1 more or less verbose? > Less, 3 is the default now that I look. Steve From owner-linux-xfs@oss.sgi.com Thu May 19 14:49:20 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 May 2005 14:49:24 -0700 (PDT) Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JLnJF3004735 for ; Thu, 19 May 2005 14:49:20 -0700 Received: from chaos.egr.duke.edu (localhost.localdomain [127.0.0.1]) by chaos.egr.duke.edu (8.12.11/8.12.11) with ESMTP id j4JLmbf2008203; Thu, 19 May 2005 17:48:37 -0400 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.12.11/8.12.11/Submit) with ESMTP id j4JLma1g008199; Thu, 19 May 2005 17:48:36 -0400 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Thu, 19 May 2005 17:48:36 -0400 (EDT) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: Gregory Brauer cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Jakob Oestergaard , Chris Wedgwood Subject: Re: kernel OOPS for XFS in xfs_iget_core (using NFS+SMP+MD) In-Reply-To: Message-ID: References: <428511F8.6020303@wildbrain.com> <20050514184711.GA27565@taniwha.stupidest.org> <428B7D7F.9000107@wildbrain.com> <20050518175925.GA22738@taniwha.stupidest.org> <20050518195251.GY422@unthought.net> <428BA8E4.2040108@wildbrain.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5280 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jlb17@duke.edu Precedence: bulk X-list: linux-xfs Content-Length: 428 Lines: 14 On Thu, 19 May 2005 at 5:42pm, Joshua Baker-LePain wrote > And now I've got some OOPSes: But, looking at 'em (instead of just blindly sending 'em along), I don't see XFS anywhere in them. The "interesting" thing is that, of the nfs_fsstress logs in /tmp on all the clients, only the NFSv3 over TCP log is showing errors on any of the clients. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Thu May 19 14:50:10 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 May 2005 14:50:19 -0700 (PDT) Received: from viper.oldcity.dca.net (viper.oldcity.dca.net [216.158.38.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4JLoAF3005147 for ; Thu, 19 May 2005 14:50:10 -0700 Received: (qmail 12011 invoked from network); 19 May 2005 21:49:31 -0000 Received: from unknown (HELO mindpipe) (207.245.115.154) by viper with SMTP; 19 May 2005 21:49:31 -0000 Subject: Re: kernel OOPS for XFS in xfs_iget_core (using NFS+SMP+MD) From: Lee Revell To: Joshua Baker-LePain Cc: Gregory Brauer , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Jakob Oestergaard , Chris Wedgwood In-Reply-To: References: <428511F8.6020303@wildbrain.com> <20050514184711.GA27565@taniwha.stupidest.org> <428B7D7F.9000107@wildbrain.com> <20050518175925.GA22738@taniwha.stupidest.org> <20050518195251.GY422@unthought.net> <428BA8E4.2040108@wildbrain.com> Content-Type: text/plain Date: Thu, 19 May 2005 17:49:30 -0400 Message-Id: <1116539371.23186.6.camel@mindpipe> Mime-Version: 1.0 X-Mailer: Evolution 2.3.1 Content-Transfer-Encoding: 7bit X-archive-position: 5281 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rlrevell@joe-job.com Precedence: bulk X-list: linux-xfs Content-Length: 254 Lines: 11 On Thu, 2005-05-19 at 17:42 -0400, Joshua Baker-LePain wrote: > And now I've got some OOPSes: Did these come after the Oops you first posted, or had you rebooted since? If you have not rebooted since the previous Oops, then these are not useful. Lee From owner-linux-xfs@oss.sgi.com Thu May 19 14:53:07 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 May 2005 14:53:11 -0700 (PDT) Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JLr5F3006441 for ; Thu, 19 May 2005 14:53:07 -0700 Received: from chaos.egr.duke.edu (localhost.localdomain [127.0.0.1]) by chaos.egr.duke.edu (8.12.11/8.12.11) with ESMTP id j4JLqP8u008252; Thu, 19 May 2005 17:52:25 -0400 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.12.11/8.12.11/Submit) with ESMTP id j4JLqPpF008248; Thu, 19 May 2005 17:52:25 -0400 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Thu, 19 May 2005 17:52:25 -0400 (EDT) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: Lee Revell cc: Gregory Brauer , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Jakob Oestergaard , Chris Wedgwood Subject: Re: kernel OOPS for XFS in xfs_iget_core (using NFS+SMP+MD) In-Reply-To: <1116539371.23186.6.camel@mindpipe> Message-ID: References: <428511F8.6020303@wildbrain.com> <20050514184711.GA27565@taniwha.stupidest.org> <428B7D7F.9000107@wildbrain.com> <20050518175925.GA22738@taniwha.stupidest.org> <20050518195251.GY422@unthought.net> <428BA8E4.2040108@wildbrain.com> <1116539371.23186.6.camel@mindpipe> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5282 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jlb17@duke.edu Precedence: bulk X-list: linux-xfs Content-Length: 455 Lines: 18 On Thu, 19 May 2005 at 5:49pm, Lee Revell wrote > On Thu, 2005-05-19 at 17:42 -0400, Joshua Baker-LePain wrote: > > And now I've got some OOPSes: > > Did these come after the Oops you first posted, or had you rebooted > since? > > If you have not rebooted since the previous Oops, then these are not > useful. No reboot. Bah. Too tired. Too much to do. Need caffeine. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Thu May 19 15:04:30 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 May 2005 15:04:34 -0700 (PDT) Received: from hermes.wildbrain.com (mail.wildbrain.com [209.130.193.228]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JM4TF3007233 for ; Thu, 19 May 2005 15:04:29 -0700 Received: from [10.20.2.11] (magellan.wildbrain.com [10.20.2.11]) (authenticated bits=0) by hermes.wildbrain.com (8.12.8/8.12.8) with ESMTP id j4JM3ABW012147; Thu, 19 May 2005 15:03:11 -0700 Message-ID: <428D0D1E.9070607@wildbrain.com> Date: Thu, 19 May 2005 15:03:10 -0700 From: Gregory Brauer User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com CC: Joshua Baker-LePain , Jakob Oestergaard , Chris Wedgwood Subject: Re: kernel OOPS for XFS in xfs_iget_core (using NFS+SMP+MD) References: <428511F8.6020303@wildbrain.com> <20050514184711.GA27565@taniwha.stupidest.org> <428B7D7F.9000107@wildbrain.com> <20050518175925.GA22738@taniwha.stupidest.org> <20050518195251.GY422@unthought.net> <428BA8E4.2040108@wildbrain.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-WB-MailScanner: Found to be clean X-WB-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-2.291, required 5, BAYES_00 -2.60, TW_DF 0.08, TW_FC 0.08, TW_JB 0.08, TW_UH 0.08) X-MailScanner-From: greg@wildbrain.com X-archive-position: 5283 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: greg@wildbrain.com Precedence: bulk X-list: linux-xfs Content-Length: 5221 Lines: 103 Joshua Baker-LePain wrote: > On Thu, 19 May 2005 at 5:42pm, Joshua Baker-LePain wrote > > >>And now I've got some OOPSes: > > > But, looking at 'em (instead of just blindly sending 'em along), I don't > see XFS anywhere in them. The "interesting" thing is that, of the > nfs_fsstress logs in /tmp on all the clients, only the NFSv3 over TCP log > is showing errors on any of the clients. As noted, you seem to have stumbled upon some other bug. We have another data point to report, this time with kernel-smp-2.6.10-1.741_FC3. The one difference here worth noting is that when this error was triggered with this kernel, the machine did not lock up hard as with 2.6.11.1 and 2.6.11.10. You could still log into the machine, but processes that attempted to access the XFS filesystem would hang. Greg May 19 13:44:20 violet kernel: xfs_iget_core: ambiguous vns: vp/0xed506a90, invp/0xed506798 May 19 13:44:20 violet kernel: ------------[ cut here ]------------ May 19 13:44:20 violet kernel: kernel BUG at fs/xfs/support/debug.c:106! May 19 13:44:20 violet kernel: invalid operand: 0000 [#1] May 19 13:44:20 violet kernel: SMP May 19 13:44:20 violet kernel: Modules linked in: nfsd exportfs lockd md5 ipv6 parport_pc lp parport sunrpc xfs dm_mod video button battery ac uhci_hcd hw_random i2c_i801 i2c_core e1000 floppy ext3 jbd raid0 3w_xxxx sd_mod scsi_mod May 19 13:44:20 violet kernel: CPU: 0 May 19 13:44:20 violet kernel: EIP: 0060:[] Not tainted VLI May 19 13:44:20 violet kernel: EFLAGS: 00010246 (2.6.10-1.741_FC3smp) May 19 13:44:20 violet kernel: EIP is at cmn_err+0x8d/0x9b [xfs] May 19 13:44:20 violet kernel: eax: 00000000 ebx: f8a2b743 ecx: f8a3faa4 edx: 00000200 May 19 13:44:20 violet kernel: esi: f8a2e17d edi: f8a4205e ebp: 00000000 esp: f6bdfbb4 May 19 13:44:20 violet kernel: ds: 007b es: 007b ss: 0068 May 19 13:44:20 violet kernel: Process nfsd (pid: 4054, threadinfo=f6bdf000 task=f6bcf530) May 19 13:44:20 violet kernel: Stack: 00000293 ed5067bc f73dc3d0 503b6809 00000000 f8a02731 00000000 f8a2b743 May 19 13:44:20 violet kernel: ed506a90 ed506798 f747ea00 00000000 f74d7000 ed506798 cf8fbc2c ed5067bc May 19 13:44:20 violet kernel: c03a5340 ed506798 f6bdf000 f8a02be7 503b6809 00000000 00000000 00000008 May 19 13:44:20 violet kernel: Call Trace: May 19 13:44:20 violet kernel: [] xfs_iget_core+0x12d/0x55f [xfs] May 19 13:44:20 violet kernel: [] xfs_iget+0x84/0x139 [xfs] May 19 13:44:20 violet kernel: [] xfs_vget+0x43/0xae [xfs] May 19 13:44:20 violet kernel: [] vfs_vget+0x1a/0x1d [xfs] May 19 13:44:20 violet kernel: [] linvfs_get_dentry+0x3b/0x6c [xfs] May 19 13:44:20 violet kernel: [] find_exported_dentry+0x2d/0x5a5 [exportfs] May 19 13:44:20 violet kernel: [] copy_to_user+0x49/0x51 May 19 13:44:20 violet kernel: [] memcpy_toiovec+0x27/0x47 May 19 13:44:20 violet kernel: [] skb_copy_datagram_iovec+0x4f/0x1e1 May 19 13:44:20 violet kernel: [] release_sock+0xf/0x4f May 19 13:44:20 violet kernel: [] tcp_recvmsg+0x61e/0x659 May 19 13:44:20 violet kernel: [] sock_common_recvmsg+0x30/0x46 May 19 13:44:20 violet kernel: [] sock_recvmsg+0xef/0x10c May 19 13:44:20 violet kernel: [] recalc_task_prio+0x128/0x133 May 19 13:44:20 violet kernel: [] activate_task+0x88/0x95 May 19 13:44:20 violet kernel: [] try_to_wake_up+0x222/0x22d May 19 13:44:20 violet kernel: [] __wake_up_common+0x36/0x51 May 19 13:44:20 violet kernel: [] __wake_up+0x29/0x3c May 19 13:44:20 violet kernel: [] svc_sock_enqueue+0x1d6/0x212 [sunrpc] May 19 13:44:20 violet kernel: [] svc_expkey_lookup+0x1fc/0x330 [nfsd] May 19 13:44:20 violet kernel: [] export_decode_fh+0x61/0x6d [exportfs] May 19 13:44:20 violet kernel: [] nfsd_acceptable+0x0/0xba [nfsd] May 19 13:44:20 violet kernel: [] export_decode_fh+0x0/0x6d [exportfs] May 19 13:44:20 violet kernel: [] fh_verify+0x347/0x4be [nfsd] May 19 13:44:20 violet kernel: [] nfsd_acceptable+0x0/0xba [nfsd] May 19 13:44:20 violet kernel: [] svcauth_unix_accept+0x207/0x27a [sunrpc] May 19 13:44:20 violet kernel: [] schedule_timeout+0x9a/0xae May 19 13:44:20 violet kernel: [] nfsd_access+0x1f/0xd8 [nfsd] May 19 13:44:20 violet kernel: [] nfsd3_proc_access+0x86/0x8e [nfsd] May 19 13:44:20 violet kernel: [] nfs3svc_decode_accessargs+0x0/0x7a [nfsd] May 19 13:44:20 violet kernel: [] nfsd_dispatch+0xba/0x16e [nfsd] May 19 13:44:20 violet kernel: [] svc_process+0x331/0x56e [sunrpc] May 19 13:44:20 violet kernel: [] nfsd+0x190/0x2db [nfsd] May 19 13:44:20 violet kernel: [] nfsd+0x0/0x2db [nfsd] May 19 13:44:20 violet kernel: [] kernel_thread_helper+0x5/0xb May 19 13:44:20 violet kernel: Code: 68 20 20 a4 f8 ff 34 ad c0 fa a3 f8 68 7d e1 a2 f8 e8 54 4a 6f c7 8b 54 24 0c b8 a4 fa a3 f8 e8 f0 21 89 c7 83 c4 0c 85 ed 75 08 <0f> 0b 6a 00 64 e1 a2 f8 58 5b 5e 5f 5d c3 55 89 c5 83 e5 07 57 From owner-linux-xfs@oss.sgi.com Thu May 19 15:07:07 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 May 2005 15:07:16 -0700 (PDT) Received: from cfa.harvard.edu (cfa.harvard.edu [131.142.10.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JM76F3007915 for ; Thu, 19 May 2005 15:07:06 -0700 Received: from titan (titan [131.142.24.40]) by cfa.harvard.edu (8.12.9-20030924/8.12.9/cfunix Mast-Sol 1.0) with ESMTP id j4JM6P7F029886 for ; Thu, 19 May 2005 18:06:26 -0400 (EDT) Date: Thu, 19 May 2005 18:06:25 -0400 (EDT) From: Gaspar Bakos Reply-To: gbakos@cfa.harvard.edu To: linux-xfs@oss.sgi.com Subject: XFS, RAID-5, 3ware Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5284 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gbakos@cfa.harvard.edu Precedence: bulk X-list: linux-xfs Content-Length: 3585 Lines: 93 Hi, This is an old topic, with some earlier correspondence, but details are still not clear. I have a 3ware hardware RAID-5 array of 8 300Gb disks. The stripe size is 256k. By the way, 3ware recommends small stripe size for sequental access (video). and large strip for random access (DB, random files, etc.) I wonder if there is any experience related to this statement. I am trying to collect the considerations when creating a good performance, stable XFS filesystem on this ~2TB partition. (System: FC3, kernel: 2.6.11smp on dual opteron, mkfs.xfs version 2.6.13). These considerations depend on the purpose of the partition; I am trying to set up big databases, and also smaller files of ~100Kb, but not anything like few Kb. What I would use is: mkfs.xfs -f -b size=4k -d su=256k,sw=7 -i size=1k -l size=128m,su=256k \ /dev/sdc1 -L "big" Questions: 1. -b size: how to determine the optimal size? Currently I am using the default, which is 4K. This has an effect primarily on the disk-access? Larger block-size, faster access I guess. On the other hand, less efficient use of space? http://www.newsforge.com/article.pl?sid=03/10/07/1943256: " with XFS, the block size can theoretically be any power-of-two multiple of 512 bytes up to 64KB (65536 bytes), although in practice you can only mount a filesystem with block sizes up to 4KB or 8KB using common CPUs" Is this true? 2. -d su: the strip size of the RAID-5 sw: n-1, where n is the number of disks agcount: my understanding is that this is quite well optimized in an automated way, thus I use the default. 3. -i size: how to determine the optimal size? many small files; use large inode size? few large files: use small inode? What I read somewhere: ... can't exceed half the allocation block size, though.) One impact of the inode size option relates to small file access times; because XFS tries to store small files within the inode whenever possible, specifying a large inode enables storing larger files within the inode. Doing so will speed access to these files. Therefore, if a partition will store many small files (under 2KB), you may want to increase the inode size. Depending on the exact mix of file sizes, the result may save or waste disk space. If few files will be smaller than 2KB, there's little point to increasing the inode size. ... 4. -l size: The default value for my setup turns out to be log =internal log bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks This corresponds to size=128m su: should be set to the stripe size of the RAID-5 array for optimal performance? --------------------------- Let me know if there are any comments, and I you see that we are doing something crazy: root$ mkfs.xfs -f -b size=4k -d su=256k,sw=7 -i size=1k -l size=128m,su=256k \ /dev/sdc1 -L "big" log stripe unit specified, using v2 logs meta-data=/dev/sdc1 isize=1024 agcount=32, agsize=16021184 blks = sectsz=512 data = bsize=4096 blocks=512676288, imaxpct=25 = sunit=64 swidth=448 blks, unwritten=1 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=32768, version=2 = sectsz=512 sunit=64 blks realtime =none extsz=65536 blocks=0, rtextents=0 ------------------- Cheers, Gaspar From owner-linux-xfs@oss.sgi.com Thu May 19 15:51:13 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 May 2005 15:51:16 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4JMpBF3011093 for ; Thu, 19 May 2005 15:51:12 -0700 Received: from mumble.melbourne.sgi.com (mumble.melbourne.sgi.com [134.14.55.227]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA03059; Fri, 20 May 2005 08:50:26 +1000 Received: from mumble.melbourne.sgi.com (localhost [127.0.0.1]) by mumble.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j4JMoIXf115276; Fri, 20 May 2005 08:50:21 +1000 (EST) Received: (from dgc@localhost) by mumble.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j4JMoBKt113776; Fri, 20 May 2005 08:50:11 +1000 (EST) Date: Fri, 20 May 2005 08:50:11 +1000 From: Dave Chinner To: Jan Derfinak Cc: Steve Lord , XFS Linux , kas@fi.muni.cz Subject: Re: [Fwd: XFS lstat() _very_ slow on SMP] Message-ID: <20050520085010.Z19332@melbourne.sgi.com> References: <4288D8B8.4070302@xfs.org> <20050519110602.U61431@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from ja@mail.upjs.sk on Thu, May 19, 2005 at 12:35:31PM +0200 X-archive-position: 5285 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 634 Lines: 25 On Thu, May 19, 2005 at 12:35:31PM +0200, Jan Derfinak wrote: > On Thu, 19 May 2005, Dave Chinner wrote: > > Hello. > > > Have you tried setting the ihashsize mount option? > > Is there any reason why this and other options from xfs_vfsops.c are > undocumented? Is safe to change their values? Mount options and sysctls are documented in the kernel source tree in Documentation/filesystems/xfs.txt. Yes, we missed updating this file for the recent ihashsize addition - I've opened a bug to remind us to update it. Thanks for pointing it out. Cheers, Dave. -- Dave Chinner R&D Software Engineer SGI Australian Software Group From owner-linux-xfs@oss.sgi.com Thu May 19 18:02:09 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 May 2005 18:02:12 -0700 (PDT) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4K128F3024754 for ; Thu, 19 May 2005 18:02:09 -0700 X-ORBL: [63.205.185.30] Received: from taniwha.stupidest.org (adsl-63-205-185-30.dsl.snfc21.pacbell.net [63.205.185.30]) by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j4K11SI7235716; Thu, 19 May 2005 21:01:28 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 7937A528F22; Thu, 19 May 2005 18:01:28 -0700 (PDT) Date: Thu, 19 May 2005 18:01:28 -0700 From: Chris Wedgwood To: Gaspar Bakos Cc: linux-xfs@oss.sgi.com Subject: Re: XFS, RAID-5, 3ware Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-archive-position: 5286 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 3421 Lines: 108 On Thu, May 19, 2005 at 06:06:25PM -0400, Gaspar Bakos wrote: > I have a 3ware hardware RAID-5 array of 8 300Gb disks. The stripe > size is 256k. By the way, 3ware recommends small stripe size for > sequental access (video). and large strip for random access (DB, > random files, etc.) I wonder if there is any experience related to > this statement. It depends on what your average write size is and also the alignment of writes too. > mkfs.xfs -f -b size=4k -d su=256k,sw=7 -i size=1k -l size=128m,su=256k \ > /dev/sdc1 -L "big" -isize=512 would be fine -lversion=2 maybe > size: how to determine the optimal size? page-size > Currently I am using the default, which is 4K. yup > 2. -d > su: the strip size of the RAID-5 > sw: n-1, where n is the number of disks > agcount: my understanding is that this is quite well optimized in an > automated way, thus I use the default. the defaults here don't work optimally for hardware raid as there is no way to reasonably determine the underlying geometry of the device like their is for softraid. you are manually specifying these so i'm not sure it matters > 3. -i > size: how to determine the optimal size? 512-bytes is the minimum you can get away with to spread inodes out evenly over a volume larger than 2TB > many small files; use large inode size? not neceessarily > few large files: use small inode? not neceessarily > What I read somewhere: > can't exceed half the allocation block size, though.) One impact of > the inode size option relates to small file access times; because > XFS tries to store small files within the inode whenever > possible, this is only true for special files (like directories), normal files will not be stored in the inode > specifying a large inode enables storing larger files within the > inode. Doing so will speed access to these files. Therefore, if > a partition will store many small files (under 2KB), you may > want to increase the inode size. Depending on the exact mix of > file sizes, the result may save or waste disk space. inodes are allocated on demand (and the mount option "noikeep" means they will be pruned when not needed) so I'm not sure what this is all about > If few files will be smaller than 2KB, there's little point to > increasing the inode size. i'm not sure what their logic is there > 4. -l > size: > The default value for my setup turns out to be > log =internal log bsize=4096 blocks=32768, version=1 > = sectsz=512 sunit=0 blks > This corresponds to size=128m > su: should be set to the stripe size of the RAID-5 array for > optimal performance? yes, i think if you specify it for the data and use v2 logs it will get this right though? > Let me know if there are any comments, and I you see that we are doing > something crazy: > > root$ mkfs.xfs -f -b size=4k -d su=256k,sw=7 -i size=1k -l size=128m,su=256k \ > /dev/sdc1 -L "big" > log stripe unit specified, using v2 logs ah cool, it does this automagically i think i would try a few things out and see how it goes. i don't know how much cache in the raid-controller and what your write patterns will be but a 256k strip-unit seems really large to me and i would experiement with different values with your workload and see how it works out From owner-linux-xfs@oss.sgi.com Fri May 20 01:04:59 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 May 2005 01:05:02 -0700 (PDT) Received: from cirse.extra.cea.fr (cirse.extra.cea.fr [132.166.172.102]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4K84wF3031272 for ; Fri, 20 May 2005 01:04:59 -0700 Received: from argiope.saclay.cea.fr (argiope.saclay.cea.fr [132.166.192.108]) by cirse.extra.cea.fr (8.12.10/8.12.10/CEAnet-Internet.4.0) with ESMTP id j4K84IIj018869 for ; Fri, 20 May 2005 10:04:18 +0200 (MEST) Received: from pisaure.intra.cea.fr (unverified) by argiope.saclay.cea.fr (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Fri, 20 May 2005 10:04:18 +0200 Received: from nenuphar.saclay.cea.fr (nenuphar.saclay.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.12.11/8.12.11) with ESMTP id j4K828b3028908; Fri, 20 May 2005 10:02:10 +0200 (envelope-from degremont@ocre.cea.fr) Received: from ocre.cea.fr ([132.165.65.70]) by nenuphar.saclay.cea.fr (8.12.10/8.12.10/CEAnet-internes.4.0) with ESMTP id j4K84FZa027461; Fri, 20 May 2005 10:04:15 +0200 (MEST) Message-ID: <428D99FF.8060205@ocre.cea.fr> Date: Fri, 20 May 2005 10:04:15 +0200 From: Aurelien Degremont - Stagiaire User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us MIME-Version: 1.0 To: Dean Roehrich CC: linux-xfs@oss.sgi.com Subject: Re: [DMAPI] code error in dm_ip_to_handle() References: <20050519160139.C21634FE8A@chewtoy.americas.sgi.com> In-Reply-To: <20050519160139.C21634FE8A@chewtoy.americas.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 5287 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: degremont@ocre.cea.fr Precedence: bulk X-list: linux-xfs Content-Length: 103 Lines: 7 Dean Roehrich a écrit: > Okay, here's an updated version. It looks good. Let's go with it. Aurelien From owner-linux-xfs@oss.sgi.com Fri May 20 01:10:43 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 May 2005 01:10:48 -0700 (PDT) Received: from ylpvm12.prodigy.net (ylpvm12-ext.prodigy.net [207.115.57.43]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4K8AgF3032560 for ; Fri, 20 May 2005 01:10:43 -0700 Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by ylpvm12.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j4K89veg009359 for ; Fri, 20 May 2005 04:09:58 -0400 X-ORBL: [63.205.185.30] Received: from taniwha.stupidest.org (adsl-63-205-185-30.dsl.snfc21.pacbell.net [63.205.185.30]) by pimout2-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j4K89sM1276168; Fri, 20 May 2005 04:10:00 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id B10EF528F22; Fri, 20 May 2005 01:09:54 -0700 (PDT) Date: Fri, 20 May 2005 01:09:54 -0700 From: Chris Wedgwood To: Christoph Hellwig Cc: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: Re: TAKE 936255 - Remove dead code. Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-archive-position: 5288 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 1372 Lines: 32 Recent cleanups making some functions static now generate warnings. Trivial fixes: Index: taniwha-kernel-050519/fs/xfs/xfs_btree.c =================================================================== --- taniwha-kernel-050519.orig/fs/xfs/xfs_btree.c 2005-05-20 00:59:56.801805205 -0700 +++ taniwha-kernel-050519/fs/xfs/xfs_btree.c 2005-05-20 01:07:04.247715873 -0700 @@ -93,7 +93,7 @@ * Retrieve the block pointer from the cursor at the given level. * This may be a bmap btree root or from a buffer. */ -xfs_btree_block_t * /* generic btree block pointer */ +STATIC xfs_btree_block_t * /* generic btree block pointer */ xfs_btree_get_block( xfs_btree_cur_t *cur, /* btree cursor */ int level, /* level in btree */ Index: taniwha-kernel-050519/fs/xfs/xfs_dir2_leaf.c =================================================================== --- taniwha-kernel-050519.orig/fs/xfs/xfs_dir2_leaf.c 2005-05-20 00:59:56.812805872 -0700 +++ taniwha-kernel-050519/fs/xfs/xfs_dir2_leaf.c 2005-05-20 01:07:04.245715752 -0700 @@ -79,7 +79,7 @@ int *indexp, xfs_dabuf_t **dbpp); static void xfs_dir2_leaf_log_bests(struct xfs_trans *tp, struct xfs_dabuf *bp, int first, int last); -extern void xfs_dir2_leaf_log_tail(struct xfs_trans *tp, struct xfs_dabuf *bp); +STATIC void xfs_dir2_leaf_log_tail(struct xfs_trans *tp, struct xfs_dabuf *bp); /* From owner-linux-xfs@oss.sgi.com Fri May 20 01:11:58 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 May 2005 01:12:01 -0700 (PDT) Received: from cirse.extra.cea.fr (cirse.extra.cea.fr [132.166.172.102]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4K8BvF3000555 for ; Fri, 20 May 2005 01:11:57 -0700 Received: from argiope.saclay.cea.fr (argiope.saclay.cea.fr [132.166.192.108]) by cirse.extra.cea.fr (8.12.10/8.12.10/CEAnet-Internet.4.0) with ESMTP id j4K8BIIj022709 for ; Fri, 20 May 2005 10:11:18 +0200 (MEST) Received: from pisaure.intra.cea.fr (unverified) by argiope.saclay.cea.fr (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Fri, 20 May 2005 10:11:18 +0200 Received: from nenuphar.saclay.cea.fr (nenuphar.saclay.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.12.11/8.12.11) with ESMTP id j4K899Kj030238; Fri, 20 May 2005 10:09:10 +0200 (envelope-from degremont@ocre.cea.fr) Received: from ocre.cea.fr ([132.165.65.70]) by nenuphar.saclay.cea.fr (8.12.10/8.12.10/CEAnet-internes.4.0) with ESMTP id j4K8BHZa028624; Fri, 20 May 2005 10:11:17 +0200 (MEST) Message-ID: <428D9BA5.8090307@ocre.cea.fr> Date: Fri, 20 May 2005 10:11:17 +0200 From: Aurelien Degremont - Stagiaire User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us MIME-Version: 1.0 To: Dean Roehrich CC: linux-xfs@oss.sgi.com Subject: Re: [DMAPI] code error in dm_ip_to_handle() References: <20050518014508.519074FE8A@chewtoy.americas.sgi.com> In-Reply-To: <20050518014508.519074FE8A@chewtoy.americas.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 5289 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: degremont@ocre.cea.fr Precedence: bulk X-list: linux-xfs Content-Length: 680 Lines: 15 Dean Roehrich a écrit: > I have to jump ahead. I need to have one struct filesystem_dmapi_operations > per mounted filesystem to solve a problem I'm dealing with now, and I have to > do it without changing any of DMAPI's external interfaces. To accomplish this > I'm checking in a change that nearly rewrites dmapi_mountinfo.c, and I'll be > checking that in first. I still intend to move this code in the direction you > and I have been discussing. I looked to your changes in the CVS. This is interesting and this will help us doing the changes we've prepared. I like the new 'list_head' lists and the 'sb' indexing. Let's see how to changes will be done now... Aurelien From owner-linux-xfs@oss.sgi.com Fri May 20 05:47:28 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 May 2005 05:47:34 -0700 (PDT) Received: from tirith.ics.muni.cz (tirith.ics.muni.cz [147.251.4.36]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KClQF3024195 for ; Fri, 20 May 2005 05:47:27 -0700 Received: from anxur.fi.muni.cz (anxur.fi.muni.cz [147.251.48.3]) by tirith.ics.muni.cz (8.13.2/8.13.2) with ESMTP id j4KCkhx3014256; Fri, 20 May 2005 14:46:44 +0200 Received: by anxur.fi.muni.cz (Postfix, from userid 11561) id 459A722AF5B; Fri, 20 May 2005 14:46:43 +0200 (CEST) Date: Fri, 20 May 2005 14:46:43 +0200 From: Jan Kasprzak To: Dave Chinner Cc: Steve Lord , XFS Linux Subject: Re: [Fwd: XFS lstat() _very_ slow on SMP] Message-ID: <20050520124643.GA5380@fi.muni.cz> References: <4288D8B8.4070302@xfs.org> <20050519110602.U61431@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050519110602.U61431@melbourne.sgi.com> User-Agent: Mutt/1.4.1i X-Muni-Spam-TestIP: 147.251.48.3 X-Muni-Envelope-From: kas@fi.muni.cz X-Muni-Virus-Test: Clean X-archive-position: 5290 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kas@fi.muni.cz Precedence: bulk X-list: linux-xfs Content-Length: 611 Lines: 18 Dave Chinner wrote: : Have you tried setting the ihashsize mount option? : No. I use the defaults. I can try it, just tell me a reasonable value to try (I suppose that it expects a numeric argument). Thanks, -Yenya -- | Jan "Yenya" Kasprzak | | GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E | | http://www.fi.muni.cz/~kas/ Czech Linux Homepage: http://www.linux.cz/ | -- Yes. CVS is much denser. -- -- CVS is also total crap. So your point is? --Linus Torvalds -- From owner-linux-xfs@oss.sgi.com Fri May 20 06:27:48 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 May 2005 06:27:54 -0700 (PDT) Received: from flyingAngel.upjs.sk (user.novell.cz [195.47.104.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KDRlF3027739 for ; Fri, 20 May 2005 06:27:48 -0700 Received: by flyingAngel.upjs.sk (Postfix, from userid 500) id D63D310015E; Fri, 20 May 2005 15:26:58 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by flyingAngel.upjs.sk (Postfix) with ESMTP id D4F51180123; Fri, 20 May 2005 15:26:58 +0200 (CEST) Date: Fri, 20 May 2005 15:26:58 +0200 (CEST) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: Jan Kasprzak Cc: Dave Chinner , Steve Lord , XFS Linux Subject: Re: [Fwd: XFS lstat() _very_ slow on SMP] In-Reply-To: <20050520124643.GA5380@fi.muni.cz> Message-ID: References: <4288D8B8.4070302@xfs.org> <20050519110602.U61431@melbourne.sgi.com> <20050520124643.GA5380@fi.muni.cz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5291 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ja@mail.upjs.sk Precedence: bulk X-list: linux-xfs Content-Length: 431 Lines: 19 On Fri, 20 May 2005, Jan Kasprzak wrote: > Dave Chinner wrote: > : Have you tried setting the ihashsize mount option? > : > No. I use the defaults. I can try it, just tell me > a reasonable value to try (I suppose that it expects > a numeric argument). According to http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=linux&db=relnotes&fname=/usr/relnotes/sgi-propack-3-for-linux-sp5 65536 is good choice. jan -- From owner-linux-xfs@oss.sgi.com Fri May 20 07:17:46 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 May 2005 07:17:52 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KEHhF3031787 for ; Fri, 20 May 2005 07:17:46 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1DZ8JB-0001h3-Vl; Fri, 20 May 2005 15:17:02 +0100 Date: Fri, 20 May 2005 15:17:01 +0100 From: Christoph Hellwig To: Chris Wedgwood Cc: Christoph Hellwig , linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: Re: TAKE 936255 - Remove dead code. Message-ID: <20050520141701.GA6252@infradead.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 5292 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 229 Lines: 7 On Fri, May 20, 2005 at 01:09:54AM -0700, Chris Wedgwood wrote: > Recent cleanups making some functions static now generate warnings. Hmm, I didn't see this warnings. What compiler do you use? The Patches looks fine, though. From owner-linux-xfs@oss.sgi.com Fri May 20 07:42:03 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 May 2005 07:42:10 -0700 (PDT) Received: from mail.cohaesio.net (penguin.cohaesio.net [212.97.129.34]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KEg1F3000758 for ; Fri, 20 May 2005 07:42:02 -0700 Received: from cohsrv1.cohaesio.com (cohsrv1.cohaesio.com [212.97.128.131]) by mail.cohaesio.net (Postfix) with ESMTP id 40265FB455; Fri, 20 May 2005 16:41:22 +0200 (CEST) Received: from homer.cohaesio.com ([212.97.128.136]) by cohsrv1.cohaesio.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 May 2005 16:41:22 +0200 From: Anders Saaby Organization: Cohaesio A/S To: Jan Derfinak Subject: Re: [Fwd: XFS lstat() _very_ slow on SMP] Date: Fri, 20 May 2005 16:42:04 +0200 User-Agent: KMail/1.8 Cc: Jan Kasprzak , Dave Chinner , Steve Lord , XFS Linux References: <4288D8B8.4070302@xfs.org> <20050520124643.GA5380@fi.muni.cz> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505201642.04484.as@cohaesio.com> X-OriginalArrivalTime: 20 May 2005 14:41:22.0118 (UTC) FILETIME=[FDC09660:01C55D49] X-archive-position: 5293 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: as@cohaesio.com Precedence: bulk X-list: linux-xfs Content-Length: 1011 Lines: 33 On Friday 20 May 2005 15:26, Jan Derfinak wrote: > On Fri, 20 May 2005, Jan Kasprzak wrote: > > Dave Chinner wrote: > > : Have you tried setting the ihashsize mount option? > > > > No. I use the defaults. I can try it, just tell me > > a reasonable value to try (I suppose that it expects > > a numeric argument). > > According to > http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=linux&db=relnot >es&fname=/usr/relnotes/sgi-propack-3-for-linux-sp5 > > 65536 is good choice. Actually from my experience with several high load XFS/NFS servers, a prime number works slightly better: http://marc.theaimsgroup.com/?l=linux-xfs&m=110785998700647&w=2 ...My 5 cents. -- Med venlig hilsen - Best regards - Meilleures salutations Anders Saaby Systems Engineer ------------------------------------------------ Cohaesio A/S - Maglebjergvej 5D - DK-2800 Lyngby Phone: +45 45 880 888 - Fax: +45 45 880 777 Mail: as@cohaesio.com - http://www.cohaesio.com ------------------------------------------------ From owner-linux-xfs@oss.sgi.com Fri May 20 09:06:16 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 May 2005 09:06:25 -0700 (PDT) Received: from ylpvm12.prodigy.net (ylpvm12-ext.prodigy.net [207.115.57.43]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KG6DF3010210 for ; Fri, 20 May 2005 09:06:15 -0700 Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by ylpvm12.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j4KG5Uei025702 for ; Fri, 20 May 2005 12:05:30 -0400 X-ORBL: [63.205.185.30] Received: from taniwha.stupidest.org (adsl-63-205-185-30.dsl.snfc21.pacbell.net [63.205.185.30]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j4KG5EPN156144; Fri, 20 May 2005 12:05:21 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 387CE528F22; Fri, 20 May 2005 09:05:16 -0700 (PDT) Date: Fri, 20 May 2005 09:05:16 -0700 From: Chris Wedgwood To: Christoph Hellwig Cc: Christoph Hellwig , linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: Re: TAKE 936255 - Remove dead code. Message-ID: References: <20050520141701.GA6252@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050520141701.GA6252@infradead.org> X-archive-position: 5294 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 238 Lines: 9 On Fri, May 20, 2005 at 03:17:01PM +0100, Christoph Hellwig wrote: > Hmm, I didn't see this warnings. What compiler do you use? gcc (GCC) 3.3.6 (Debian 1:3.3.6-5) Maybe you had CONFIG_XFS_DEBUG on which turns STATIC off or similar? From owner-linux-xfs@oss.sgi.com Fri May 20 12:22:15 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 May 2005 12:22:19 -0700 (PDT) Received: from MM01SNLNTO.sandia.gov (mm01snlnto.sandia.gov [132.175.109.20]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KJMFF3016587 for ; Fri, 20 May 2005 12:22:15 -0700 Received: from 132.175.109.1 by mm02snlnto.sandia.gov with ESMTP ( Tumbleweed MMS SMTP Relay 01 (MMS v5.6.3)); Fri, 20 May 2005 13:21:21 -0600 X-Server-Uuid: 914ACFB1-8EBC-470E-882B-54A00EED9786 Received: from ES23SNLNT.srn.sandia.gov (ec04snlnt.sandia.gov [134.253.164.156] (may be forged)) by mailgate.sandia.gov ( 8.13.3/8.13.3) with ESMTP id j4KJLKfl022076 for ; Fri, 20 May 2005 13:21:20 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 MIME-Version: 1.0 Subject: DMAPI support Date: Fri, 20 May 2005 13:21:19 -0600 Message-ID: <46EAC19F3066C14BB20DF799A649C5F4012D2405@ES23SNLNT.srn.sandia.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DMAPI support Thread-Index: AcVdcRmHtd5Mh4tYTU+6tHND5z0DpA== From: "Barnaby, Marty L" To: linux-xfs@oss.sgi.com X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.5.20.22 X-WSS-ID: 6E90E73B1J0339379-01-01 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 5295 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mlbarna@sandia.gov Precedence: bulk X-list: linux-xfs Content-Length: 202 Lines: 9 I thought XFS supported the XDSM DMI standard, but I don't see anything about it. Can you point me to where I should look? Marty Barnaby Sandia National Laborites [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Sat May 21 10:42:24 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 21 May 2005 10:42:27 -0700 (PDT) Received: from hannibal.dreamhost.com (hannibal.dreamhost.com [205.196.208.25]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4LHgOF3011273 for ; Sat, 21 May 2005 10:42:24 -0700 Received: from [192.168.111.200] (cpe-70-93-153-244.socal.res.rr.com [70.93.153.244]) by hannibal.dreamhost.com (Postfix) with ESMTP id 63D2017511A for ; Sat, 21 May 2005 10:41:43 -0700 (PDT) Message-ID: <428F72EF.1060302@delusion.com> Date: Sat, 21 May 2005 10:42:07 -0700 From: Deanan User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Kernel bug on SLES 9 References: <42657615.9090404@tippett.com> In-Reply-To: <42657615.9090404@tippett.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5297 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: delusion@delusion.com Precedence: bulk X-list: linux-xfs Content-Length: 3963 Lines: 88 Has anyone seen the error below before? I was basically writing about 60G sequentially in 16mb files and it occured a few times at about 55Gb into the write. The system is SLES 9 x86-64 with 2G of ram. The filesystem was made using the defaults on top of an md raid 0 of 3 disks (chunk size 512). Cheers, Deanan May 20 19:56:29 e09 kernel: ----------- [cut here ] --------- [please bite here ] --------- May 20 19:56:29 e09 kernel: Kernel BUG at xfs_aops:980 May 20 19:56:29 e09 kernel: invalid operand: 0000 [1] SMP May 20 19:56:29 e09 kernel: CPU 1 May 20 19:56:29 e09 kernel: Pid: 6491, comm: StoragePerforma Tainted: G U 2.6.5-7.97-smpDalsa May 20 19:56:29 e09 kernel: RIP: 0010:[] {:xfs:linvfs_get_block_core+372} May 20 19:56:29 e09 kernel: RSP: 0018:000001006ccf3878 EFLAGS: 00010202 May 20 19:56:29 e09 kernel: RAX: 0000000000000005 RBX: 00000000002fe000 RCX: 000001006eab8e48 May 20 19:56:29 e09 kernel: RDX: 0000000000000001 RSI: 000001006eaa8980 RDI: 0000010074600828 May 20 19:56:29 e09 kernel: RBP: 000001006eab96b0 R08: 000001006ccf3838 R09: 0000000000000001 May 20 19:56:29 e09 kernel: R10: 0000000000300000 R11: 0000000000000001 R12: 000001006eaa4878 May 20 19:56:29 e09 kernel: R13: 0000000000000000 R14: 0000000000000002 R15: 0000000000000001 May 20 19:56:29 e09 kernel: FS: 0000000062d31960(005b) GS:ffffffff804e7e80(0000) knlGS:0000000000000000 May 20 19:56:29 e09 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b May 20 19:56:29 e09 kernel: CR2: 00000000006eb000 CR3: 000000007ff16000 CR4: 00000000000006e0 May 20 19:56:29 e09 kernel: Process StoragePerforma (pid: 6491, threadinfo 000001006ccf2000, task 000001007b26c3d0) May 20 19:56:29 e09 kernel: Stack: 00000000000d837f 0000000100001000 ffffffffffffffff 000001007408c480 May 20 19:56:29 e09 kernel: 00000000002fe000 0000000000002000 0000000000000000 0000010000000005 May 20 19:56:29 e09 kernel: 0000010001003950 0000000000000000 May 20 19:56:29 e09 kernel: Call Trace:{:xfs:linvfs_get_blocks_direct+22} May 20 19:56:29 e09 kernel: {__blockdev_direct_IO+1410} {pagevec_lookup_tag+26} May 20 19:56:29 e09 kernel: {:xfs:linvfs_direct_IO+187} {:xfs:linvfs_get_blocks_direct+0} May 20 19:56:29 e09 kernel: {:xfs:linvfs_unwritten_convert_direct+0} May 20 19:56:29 e09 kernel: {generic_file_direct_IO+100} {__generic_file_aio_write_nolock+819} May 20 19:56:29 e09 kernel: {pagevec_lookup+23} {truncate_inode_pages+591} May 20 19:56:29 e09 kernel: {__filemap_fdatawrite_range+154} May 20 19:56:29 e09 kernel: {generic_file_aio_write_nolock+77} May 20 19:56:29 e09 kernel: {:xfs:xfs_write+946} {:xfs:linvfs_write+126} May 20 19:56:29 e09 kernel: {do_sync_write+164} {:xfs:xfs_iunlock+102} May 20 19:56:29 e09 kernel: {autoremove_wake_function+0} {:xfs:linvfs_permission+20} May 20 19:56:29 e09 kernel: {permission+55} {may_open+108} May 20 19:56:29 e09 kernel: {file_ra_state_init+32} {dentry_open_it+310} May 20 19:56:29 e09 kernel: {filp_open+113} {vfs_write+243} May 20 19:56:29 e09 kernel: {sys_write+157} {sys_open+231} May 20 19:56:29 e09 kernel: {system_call+124} May 20 19:56:29 e09 kernel: May 20 19:56:29 e09 kernel: Code: 0f 0b 63 e7 1f a0 ff ff ff ff d4 03 45 85 ed 74 0e f0 49 0f May 20 19:56:29 e09 kernel: RIP {:xfs:linvfs_get_block_core+372} RSP <000001006ccf3878> From owner-linux-xfs@oss.sgi.com Sun May 22 07:13:30 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 22 May 2005 07:13:33 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4MEDOF3007661 for ; Sun, 22 May 2005 07:13:24 -0700 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4MFvtgq016290 for ; Sun, 22 May 2005 08:57:55 -0700 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id j4MECfad56768321; Sun, 22 May 2005 07:12:41 -0700 (PDT) Message-ID: <42909358.10507@sgi.com> Date: Sun, 22 May 2005 09:12:40 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Wedgwood CC: Nir Dremer , linux-xfs@oss.sgi.com Subject: Re: Bad Sectors Behavior References: <1116429626.8348.63.camel@localhost> <20050518173436.GA12000@taniwha.stupidest.org> In-Reply-To: <20050518173436.GA12000@taniwha.stupidest.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5299 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 515 Lines: 18 Chris Wedgwood wrote: > On Wed, May 18, 2005 at 06:20:26PM +0300, Nir Dremer wrote: > > >>I'm looking for official documentation explaining XFS behavior when >>new Bad Sectors are detected on the file-system. > > > XFS doesn't handle bad sectors, if such an error occurs the filesystem > will barf and return EFSCORRUPTED (990 presently as Linux doesn't > define this). > The standard answer is usually that if you see bad sectors, your drive can no longer remap them, and it's time for a new drive. -Eric From owner-linux-xfs@oss.sgi.com Sun May 22 07:21:23 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 22 May 2005 07:21:27 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4MELNF3008396 for ; Sun, 22 May 2005 07:21:23 -0700 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4MG5sFk018123 for ; Sun, 22 May 2005 09:05:54 -0700 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id j4MEJead56773493; Sun, 22 May 2005 07:19:40 -0700 (PDT) Message-ID: <429094FB.307@sgi.com> Date: Sun, 22 May 2005 09:19:39 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Chapman CC: linux-xfs@oss.sgi.com Subject: Re: Files >4GB in XFS realtime partition References: <428B4CC0.70702@katalix.com> In-Reply-To: <428B4CC0.70702@katalix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5300 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 473 Lines: 16 James Chapman wrote: > I'm seeing corrupt data when trying to read/write files >4GB in a > realtime partition. Are there any known bugs in this area? Corruption > only occurs when the file grows larger than 4GB. No problems are seen > when using non-realtime XFS partitions. > > Kernel: 2.4.29 > Arch: MIPS > Interesting, we'll have to try to reproduce this in-house. Anything special about your test case? Don't suppose you can test it on non-MIPS....? -Eri From owner-linux-xfs@oss.sgi.com Sun May 22 07:38:06 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 22 May 2005 07:38:11 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4MEc5F3009260 for ; Sun, 22 May 2005 07:38:06 -0700 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4MGMZej021644 for ; Sun, 22 May 2005 09:22:35 -0700 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id j4MEaKad56789447; Sun, 22 May 2005 07:36:21 -0700 (PDT) Message-ID: <429098E4.3010604@sgi.com> Date: Sun, 22 May 2005 09:36:20 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: daves@activestate.com CC: linux-xfs@oss.sgi.com Subject: Re: slipstream update of xfsprogs-2.6.25? References: <428CEF90.3000309@activestate.com> In-Reply-To: <428CEF90.3000309@activestate.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5301 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 969 Lines: 31 David Sparks wrote: > What happened to the sources for xfsprogs-2.6.25? > > I noticed a md5 and size change recently but the version # is the same? > This seems to be just a slipstream update but has caused some > inconvenience with a web cache of sources I run. > > I hope this isn't standard practice to re-use version #s and filenames. > > -rw-r--r-- 1 apache apache 850424 Oct 10 2004 xfsprogs-2.6.25.src.tar.gz > > vs > > -rw-r--r-- 1 apache apache 850313 May 9 18:06 xfsprogs-2.6.25.src.tar.gz > > > ds > Hm, not generally... sometimes, at worst, packages get rebuilt with new timestamps for the same version nr. I'll have to dig to see what changed in xfsprogs w/o a VERSION change, and flog the perpetrator. ;-) Ok after a little digging it doesn't look like much; someone got this version of xfstests running on irix, tweaked aclocal.m4 for BSD, and synced up one of the header files with the kernel. let the floggings commence! -Eric From owner-linux-xfs@oss.sgi.com Sun May 22 20:19:56 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 22 May 2005 20:19:59 -0700 (PDT) Received: from mta1.lbl.gov (mta1.lbl.gov [128.3.41.24]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4N3JuF3018372 for ; Sun, 22 May 2005 20:19:56 -0700 Received: from mta1.lbl.gov ([127.0.0.1]) by mta1.lbl.gov (8.12.10/8.12.10) with ESMTP id j4N3JBn3029924 for ; Sun, 22 May 2005 20:19:11 -0700 (PDT) Received: from lbl.gov (adsl-69-104-81-65.dsl.pltn13.pacbell.net [69.104.81.65]) by mta1.lbl.gov (8.12.10/8.12.10) with ESMTP id j4N3JAP8029921 for ; Sun, 22 May 2005 20:19:10 -0700 (PDT) Message-ID: <42914BAE.9030306@lbl.gov> Date: Sun, 22 May 2005 20:19:10 -0700 From: Damian Hazen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.3) Gecko/20050113 Red Hat/1.4.3-3.0.7.centos.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: XFS Linux Subject: SLES 9 and DMAPI fixes Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5303 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dhazen@lbl.gov Precedence: bulk X-list: linux-xfs Content-Length: 658 Lines: 21 Hi - Anyone know what the conduit is for getting DMAPI fixes into SLES 9? From looking at their KOTD kernels, they seem to be picking up some of the fixes but not all of them. And, these are essential ones too that have been fixed for several months like: Fix to prevent create events from causing kernel oops http://oss.sgi.com/bugzilla/show_bug.cgi?id=363 Fix to get dm_get_dirattrs working again: http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/xfs/xfs_dmapi.c.diff?r1=1.108;r2=1.109 Fix for filehandle leak http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/xfs/xfs_dmapi.c.diff?r1=1.113;r2=1.114 etc. Thanks for any info, -Damian From owner-linux-xfs@oss.sgi.com Mon May 23 08:49:00 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 May 2005 08:49:18 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4NFmwF3013531 for ; Mon, 23 May 2005 08:48:58 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4NHXb4Z006874 for ; Mon, 23 May 2005 10:33:37 -0700 Received: from chewtoy.americas.sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4NFlDR08688165; Mon, 23 May 2005 10:47:13 -0500 (CDT) Received: from chewtoy (localhost [127.0.0.1]) by chewtoy.americas.sgi.com (Postfix) with ESMTP id D8BCE4FE8A; Mon, 23 May 2005 10:47:12 -0500 (CDT) To: "Barnaby, Marty L" Cc: linux-xfs@oss.sgi.com Subject: Re: DMAPI support Date: Mon, 23 May 2005 10:47:12 -0500 From: Dean Roehrich Message-Id: <20050523154712.D8BCE4FE8A@chewtoy.americas.sgi.com> X-archive-position: 5304 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 298 Lines: 12 >From: "Barnaby, Marty L" >I thought XFS supported the XDSM DMI standard, but I don't see anything >about it. Can you point me to where I should look? It can be found in our linux 2.6 source tree: http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/ Under fs/dmapi. Dean From owner-linux-xfs@oss.sgi.com Mon May 23 08:58:38 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 May 2005 08:58:52 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4NFwbF3014312 for ; Mon, 23 May 2005 08:58:38 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4NHhHpb010048 for ; Mon, 23 May 2005 10:43:17 -0700 Received: from chewtoy.americas.sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4NFurR08687592; Mon, 23 May 2005 10:56:53 -0500 (CDT) Received: from chewtoy (localhost [127.0.0.1]) by chewtoy.americas.sgi.com (Postfix) with ESMTP id 958F54FE8A; Mon, 23 May 2005 10:56:53 -0500 (CDT) To: Damian Hazen Cc: XFS Linux Subject: Re: SLES 9 and DMAPI fixes Date: Mon, 23 May 2005 10:56:53 -0500 From: Dean Roehrich Message-Id: <20050523155653.958F54FE8A@chewtoy.americas.sgi.com> X-archive-position: 5305 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 800 Lines: 29 >From: Damian Hazen >Hi - > >Anyone know what the conduit is for getting DMAPI fixes into SLES 9? > From looking at their KOTD kernels, they seem to be picking up some of >the fixes but not all of them. And, these are essential ones too that >have been fixed for several months like: > >Fix to prevent create events from causing kernel oops >http://oss.sgi.com/bugzilla/show_bug.cgi?id=363 That will be in SLES9 SP2. >Fix to get dm_get_dirattrs working again: >http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/xfs/xfs_dmapi.c.diff?r1 >=1.108;r2=1.109 Sorry, we overlooked that one. It won't be in SLES9 SP2. >Fix for filehandle leak >http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/xfs/xfs_dmapi.c.diff?r1 >=1.113;r2=1.114 That will be in SLES9 SP2. Dean From owner-linux-xfs@oss.sgi.com Mon May 23 09:42:19 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 May 2005 09:42:29 -0700 (PDT) Received: from mta1.lbl.gov (mta1.lbl.gov [128.3.41.24]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4NGgIF3017161 for ; Mon, 23 May 2005 09:42:19 -0700 Received: from mta1.lbl.gov ([127.0.0.1]) by mta1.lbl.gov (8.12.10/8.12.10) with ESMTP id j4NGfWn3029630 for ; Mon, 23 May 2005 09:41:33 -0700 (PDT) Received: from [128.55.16.112] (ketch.nersc.gov [128.55.16.112]) by mta1.lbl.gov (8.12.10/8.12.10) with ESMTP id j4NGfWP8029623; Mon, 23 May 2005 09:41:32 -0700 (PDT) Message-ID: <429207BB.8010601@lbl.gov> Date: Mon, 23 May 2005 09:41:31 -0700 From: Damian Hazen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Roehrich CC: XFS Linux Subject: Re: SLES 9 and DMAPI fixes References: <20050523155653.958F54FE8A@chewtoy.americas.sgi.com> In-Reply-To: <20050523155653.958F54FE8A@chewtoy.americas.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5306 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dhazen@lbl.gov Precedence: bulk X-list: linux-xfs Content-Length: 946 Lines: 41 Dean Roehrich wrote: >>Fix to prevent create events from causing kernel oops >>http://oss.sgi.com/bugzilla/show_bug.cgi?id=363 > > > That will be in SLES9 SP2. > > > >>Fix to get dm_get_dirattrs working again: >>http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/xfs/xfs_dmapi.c.diff?r1 >>=1.108;r2=1.109 > > > Sorry, we overlooked that one. It won't be in SLES9 SP2. > I'll build a patch for our use. I think all the changes for this are in xfs_dmapi.c. Is that correct? > > >>Fix for filehandle leak >>http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/xfs/xfs_dmapi.c.diff?r1 >>=1.113;r2=1.114 > > > That will be in SLES9 SP2. Thanks for the info. I've been looking at the SP2 daily builds: ftp://ftp.suse.com/pub/projects/kernel/kotd/sles9-i386/SLES9_SP2_BRANCH/ and didn't see the fixes mentioned above. Have they just not been worked into the daily builds yet or is there some disconnect? Thanks, -Damian From owner-linux-xfs@oss.sgi.com Mon May 23 09:50:49 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 May 2005 09:50:56 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4NGonF3017840 for ; Mon, 23 May 2005 09:50:49 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4NGo5xT024545 for ; Mon, 23 May 2005 11:50:05 -0500 Received: from chewtoy.americas.sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4NGo5R08689511; Mon, 23 May 2005 11:50:05 -0500 (CDT) Received: from chewtoy (localhost [127.0.0.1]) by chewtoy.americas.sgi.com (Postfix) with ESMTP id 018824FE8C; Mon, 23 May 2005 11:50:04 -0500 (CDT) To: Damian Hazen Cc: XFS Linux Subject: Re: SLES 9 and DMAPI fixes Date: Mon, 23 May 2005 11:50:04 -0500 From: Dean Roehrich Message-Id: <20050523165004.018824FE8C@chewtoy.americas.sgi.com> X-archive-position: 5307 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1071 Lines: 49 >From: Damian Hazen >Dean Roehrich wrote: > >>>Fix to prevent create events from causing kernel oops >>>http://oss.sgi.com/bugzilla/show_bug.cgi?id=363 >> >> >> That will be in SLES9 SP2. >> >> >> >>>Fix to get dm_get_dirattrs working again: >>>http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/xfs/xfs_dmapi.c.diff? >r1 >>>=1.108;r2=1.109 >> >> >> Sorry, we overlooked that one. It won't be in SLES9 SP2. >> > >I'll build a patch for our use. I think all the changes for this are in >xfs_dmapi.c. Is that correct? Yes. >>>Fix for filehandle leak >>>http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/xfs/xfs_dmapi.c.diff? >r1 >>>=1.113;r2=1.114 >> >> >> That will be in SLES9 SP2. > > >Thanks for the info. I've been looking at the SP2 daily builds: > >ftp://ftp.suse.com/pub/projects/kernel/kotd/sles9-i386/SLES9_SP2_BRANCH/ > >and didn't see the fixes mentioned above. Have they just not been worked into > >the daily builds yet or is there some disconnect? Oh, there's certainly a disconnect--lately it's me :) Dean From owner-linux-xfs@oss.sgi.com Mon May 23 10:59:40 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 May 2005 10:59:44 -0700 (PDT) Received: from mta1.lbl.gov (mta1.lbl.gov [128.3.41.24]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4NHxeF3022002 for ; Mon, 23 May 2005 10:59:40 -0700 Received: from mta1.lbl.gov ([127.0.0.1]) by mta1.lbl.gov (8.12.10/8.12.10) with ESMTP id j4NHwsn3001712 for ; Mon, 23 May 2005 10:58:55 -0700 (PDT) Received: from [128.55.16.112] (ketch.nersc.gov [128.55.16.112]) by mta1.lbl.gov (8.12.10/8.12.10) with ESMTP id j4NHwrP8001703; Mon, 23 May 2005 10:58:54 -0700 (PDT) Message-ID: <429219DD.9090501@lbl.gov> Date: Mon, 23 May 2005 10:58:53 -0700 From: Damian Hazen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Roehrich CC: XFS Linux Subject: Re: SLES 9 and DMAPI fixes References: <20050523165004.018824FE8C@chewtoy.americas.sgi.com> In-Reply-To: <20050523165004.018824FE8C@chewtoy.americas.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5308 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dhazen@lbl.gov Precedence: bulk X-list: linux-xfs Content-Length: 616 Lines: 25 Dean Roehrich wrote: >> >>Thanks for the info. I've been looking at the SP2 daily builds: >> >>ftp://ftp.suse.com/pub/projects/kernel/kotd/sles9-i386/SLES9_SP2_BRANCH/ >> >>and didn't see the fixes mentioned above. Have they just not been worked into >> >>the daily builds yet or is there some disconnect? > > > > Oh, there's certainly a disconnect--lately it's me :) > > Dean > > Sounds like I should wait a bit for things to get reconnected. If it happens that some of the fixes you have end up not getting picked up in SP2, would you mind letting me know so I can roll my own patch? Thanks, -Damian From owner-linux-xfs@oss.sgi.com Mon May 23 12:14:52 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 May 2005 12:14:56 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4NJEpF3026201 for ; Mon, 23 May 2005 12:14:52 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4NJE8xT017819 for ; Mon, 23 May 2005 14:14:08 -0500 Received: from chewtoy.americas.sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4NJE7R08701001; Mon, 23 May 2005 14:14:07 -0500 (CDT) Received: from chewtoy (localhost [127.0.0.1]) by chewtoy.americas.sgi.com (Postfix) with ESMTP id 6E45B4FE8C; Mon, 23 May 2005 14:14:07 -0500 (CDT) To: Damian Hazen Cc: XFS Linux Subject: Re: SLES 9 and DMAPI fixes Date: Mon, 23 May 2005 14:14:07 -0500 From: Dean Roehrich Message-Id: <20050523191407.6E45B4FE8C@chewtoy.americas.sgi.com> X-archive-position: 5309 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 310 Lines: 12 >From: Damian Hazen >Sounds like I should wait a bit for things to get reconnected. If it happens >that some of the fixes you have end up not getting picked up in SP2, would you > >mind letting me know so I can roll my own patch? Well, the thought was worth a chuckle or two. :) Dean From owner-linux-xfs@oss.sgi.com Mon May 23 19:46:59 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 May 2005 19:47:03 -0700 (PDT) Received: from cfa.harvard.edu (cfa.harvard.edu [131.142.10.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O2kwF3008370 for ; Mon, 23 May 2005 19:46:59 -0700 Received: from titan (titan [131.142.24.40]) by cfa.harvard.edu (8.12.9-20030924/8.12.9/cfunix Mast-Sol 1.0) with ESMTP id j4O2kERi011021; Mon, 23 May 2005 22:46:14 -0400 (EDT) Date: Mon, 23 May 2005 22:46:13 -0400 (EDT) From: Gaspar Bakos Reply-To: gbakos@cfa.harvard.edu To: Chris Wedgwood cc: linux-xfs@oss.sgi.com Subject: Re: XFS, RAID-5, 3ware In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5310 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gbakos@cfa.harvard.edu Precedence: bulk X-list: linux-xfs Content-Length: 1262 Lines: 50 Hi, Chris, RE: > > mkfs.xfs -f -b size=4k -d su=256k,sw=7 -i size=1k -l size=128m,su=256k \ > > /dev/sdc1 -L "big" > -isize=512 would be fine > -lversion=2 maybe > > size: how to determine the optimal size? > page-size Here you refer to the kernel page-size? > 512-bytes is the minimum you can get away with to spread inodes out > evenly over a volume larger than 2TB Ok, I see. > > 4. -l > > size: > > The default value for my setup turns out to be > > log =internal log bsize=4096 blocks=32768, version=1 > > = sectsz=512 sunit=0 blks > > This corresponds to size=128m > > > su: should be set to the stripe size of the RAID-5 array for > > optimal performance? > > yes, i think if you specify it for the data and use v2 logs it will > get this right though? Indeed. I didn't know this, but it is a nice feature. Basically, the following are equivalent: mkfs.xfs -f -b size=4k -d su=256k,sw=7 -i size=1k -l version=2 /dev/sdc1 -L "big" or mkfs.xfs -f -b size=4k -d su=256k,sw=7 -i size=1k -l size=128m,su=256 /dev/sdc1 -L "big" > i think i would try a few things out and see how it goes. i don't What tests do you think of? bonnie++? Cheers, Gaspar From owner-linux-xfs@oss.sgi.com Mon May 23 20:08:55 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 May 2005 20:08:58 -0700 (PDT) Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O38sF3010081 for ; Mon, 23 May 2005 20:08:55 -0700 Received: from pimout2-ext.prodigy.net (pimout2-int.prodigy.net [207.115.4.217]) by ylpvm43.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j4O38FKf003126 for ; Mon, 23 May 2005 23:08:15 -0400 X-ORBL: [63.205.187.115] Received: from taniwha.stupidest.org (adsl-63-205-187-115.dsl.snfc21.pacbell.net [63.205.187.115]) by pimout2-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j4O387HW434242; Mon, 23 May 2005 23:08:07 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 6A889528F22; Mon, 23 May 2005 20:08:07 -0700 (PDT) Date: Mon, 23 May 2005 20:08:07 -0700 From: Chris Wedgwood To: Gaspar Bakos Cc: linux-xfs@oss.sgi.com Subject: Re: XFS, RAID-5, 3ware Message-ID: <20050524030807.GA17879@taniwha.stupidest.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-archive-position: 5311 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 606 Lines: 21 On Mon, May 23, 2005 at 10:46:13PM -0400, Gaspar Bakos wrote: > Here you refer to the kernel page-size? yes > > 512-bytes is the minimum you can get away with to spread inodes out > > evenly over a volume larger than 2TB > > Ok, I see. i should qualify that though that for >4TB you will need larger inodes again but at that point i think using a 32-bit CPU won't be very common > What tests do you think of? whatever matches you usage pattern, this is why i mentioned that the strip-size doesn't necessarily have some *magic* value --- it will vary somewhat depending on what your writes look like From owner-linux-xfs@oss.sgi.com Mon May 23 23:37:46 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 May 2005 23:37:49 -0700 (PDT) Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O6bjF3024231 for ; Mon, 23 May 2005 23:37:45 -0700 Received: from srascb.sra.co.jp (srascb [133.137.8.65]) by sraigw.sra.co.jp (Postfix) with ESMTP id 8655A62753 for ; Tue, 24 May 2005 15:36:52 +0900 (JST) Received: from srascb.sra.co.jp (localhost [127.0.0.1]) by localhost.sra.co.jp (Postfix) with ESMTP id 6ECD510CD06 for ; Tue, 24 May 2005 15:36:52 +0900 (JST) Received: from srasvg.sra.co.jp (srasvg [133.137.160.65]) by srascb.sra.co.jp (Postfix) with ESMTP id 5E91E10CD04 for ; Tue, 24 May 2005 15:36:52 +0900 (JST) Received: from [133.137.44.227] (ext301 [133.137.44.227]) by srasvg.sra.co.jp (8.9.3p2/3.7W-srambox) with ESMTP id PAA07886 for ; Tue, 24 May 2005 15:36:52 +0900 Date: Tue, 24 May 2005 15:38:54 +0900 From: Takeshi HASEGAWA To: linux-xfs@oss.sgi.com Subject: reproducing script: __lookup_hash oops Message-Id: <20050524153553.C952.HASEGAW@sra.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Mailer: Becky! ver. 2.12.01 [ja] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j4O6bkF3024274 X-archive-position: 5312 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hasegaw@sra.co.jp Precedence: bulk X-list: linux-xfs Content-Length: 1365 Lines: 59 Hi, I wrote a reproducing script for kernel oops in __lookup_hash(), which has been discussed in last week. I confirmed the bug on two of Turbolinux 10 Server boxes, based on 2.6.8 kernel. Got same errors on SMP and non-SMP kernels. on NFS server: - export a XFS filesystem. on NFS client: - prepare a test script, and fsstress from LTP or somewhere. - mount the NFS export. - run the script. -- #!/bin/sh TESTDIR=/export/xfstest ./fsstress -d $TESTDIR -l 0 -p 10 & while true; do find $TESTDIR -exec touch -c {} \; ; done -- Maybe you'll get oops soon(less than a minute) using this test. I confirmed it passes for a hour with no errors on ext3 filesystem. caused oopses: =========================== STACK TRACE OF FAILING TASK =========================== ================================================================ STACK TRACE FOR TASK: 0xf6d4b110 (nfsd) 0 __lookup_hash+111 [0xc016a4af] 1 lookup_hash+17 [0xc016a4f1] 2 lookup_one_len+90 [0xc016a55a] 3 nfsd_lookup+257 [0xf8ab7eb1] 4 nfsd3_proc_lookup+139 [0xf8abfb6b] 5 nfsd_dispatch+183 [0xf8ab5697] 6 svc_process+1221 [0xf8a68215] 7 smp_apic_timer_interrupt+149 [0xc0117975] 8 nfsd+447 [0xf8ab542f] 9 nfsd [0xf8ab5270] 10 kernel_thread_helper+5 [0xc010526d] ================================================================ -- Takeshi HASEGAWA Software Research Associates, Inc. From owner-linux-xfs@oss.sgi.com Mon May 23 23:50:10 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 May 2005 23:50:14 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O6o7F3026241 for ; Mon, 23 May 2005 23:50:10 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1DaTEA-0001us-Gg; Tue, 24 May 2005 07:49:22 +0100 Date: Tue, 24 May 2005 07:49:22 +0100 From: Christoph Hellwig To: Takeshi HASEGAWA Cc: linux-xfs@oss.sgi.com Subject: Re: reproducing script: __lookup_hash oops Message-ID: <20050524064922.GA7278@infradead.org> References: <20050524153553.C952.HASEGAW@sra.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050524153553.C952.HASEGAW@sra.co.jp> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 5313 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 620 Lines: 21 On Tue, May 24, 2005 at 03:38:54PM +0900, Takeshi HASEGAWA wrote: > Hi, > > I wrote a reproducing script for kernel oops in __lookup_hash(), > which has been discussed in last week. > > I confirmed the bug on two of Turbolinux 10 Server boxes, > based on 2.6.8 kernel. Got same errors on SMP and non-SMP > kernels. > > on NFS server: > - export a XFS filesystem. > > on NFS client: > - prepare a test script, and fsstress from LTP or somewhere. > - mount the NFS export. > - run the script. 2.6.8 has a huge amount of NFS problems, both in common code and in XFS. Please try 2.6.12-rc or current oss.sgi.com CVS. From owner-linux-xfs@oss.sgi.com Wed May 25 19:48:21 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 May 2005 19:48:24 -0700 (PDT) Received: from kelaix2.kel.co.jp ([202.224.137.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4Q2mAXq023856 for ; Wed, 25 May 2005 19:48:20 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost.kel.co.jp (Postfix) with SMTP id 2C8311A8065 for ; Thu, 26 May 2005 11:47:11 +0900 (JST) Received: from FD3S (unknown [10.14.10.23]) by kelaix2.kel.co.jp (Postfix) with SMTP id 084511A8032; Thu, 26 May 2005 11:47:09 +0900 (JST) Message-ID: <06d001c5619d$35b6f670$170a0e0a@FD3S> From: "Shinya Sakamoto" To: Subject: msg00264; Cant create new files Date: Thu, 26 May 2005 11:47:08 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-2022-jp"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-archive-position: 5316 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sakamoto@kel.co.jp Precedence: bulk X-list: linux-xfs Content-Length: 748 Lines: 20 Hello all, Our xfs fileserver had a trouble. It was unable to create a file with "no space left on device" message but had 0.6TB (40%) space available. When we delete one file, we can create one file. In other words, it was unable to increase in number of files/directories. xfs_check and xfs_repair results no errors and no fixes. We look for the cause and solution, then we find the msg00264 (2003-07) is very similer to our situation. But, we cannot find what was the cause and solution in the thread. Does somebody know how it goes or what was the cause and solution? Or, if someone who had similar situation and found the solution, please let us know about it. Any infomation will be appriciate for us. Regards, Shinya Sakamoto From owner-linux-xfs@oss.sgi.com Wed May 25 19:56:39 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 May 2005 19:56:47 -0700 (PDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4Q2udXq024553 for ; Wed, 25 May 2005 19:56:39 -0700 Received: by wproxy.gmail.com with SMTP id 68so1058837wra for ; Wed, 25 May 2005 19:55:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:organization:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:from; b=lsqjWtsX0R9fCLMo4IzFyu02vCP8dBS52ME/dmM+dITvJC01JaL+1Cl0DqgYUMtHIkymAdzND+IBSu+koWS/dDSNrMyVBJDIy9vy4mcS6c4cRAN4TdC0ORrlzneX/vk7P8K3AXitaTBYi5OeSq6LjtDOlRmLfBm0W89F27eIImo= Received: by 10.54.8.41 with SMTP id 41mr1647942wrh; Wed, 25 May 2005 19:55:52 -0700 (PDT) Received: from ?10.0.0.1? ([67.121.190.234]) by mx.gmail.com with ESMTP id d6sm939311wra.2005.05.25.19.55.51; Wed, 25 May 2005 19:55:52 -0700 (PDT) Message-ID: <42953ABA.4000106@linux-sxs.org> Date: Wed, 25 May 2005 19:55:54 -0700 Organization: HAL V User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: msg00264; Cant create new files References: <06d001c5619d$35b6f670$170a0e0a@FD3S> In-Reply-To: <06d001c5619d$35b6f670$170a0e0a@FD3S> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit From: Net Llama! X-archive-position: 5317 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 1235 Lines: 34 Which kernel version? Which version of xfsprogs? Are you using LVM or NFS, or anything else? How big are the files? Is this x86 or x86_64? On 05/25/2005 07:47 PM, Shinya Sakamoto wrote: > Hello all, > > Our xfs fileserver had a trouble. It was unable to create a file with "no > space left on device" message but had 0.6TB (40%) space available. When we > delete one file, we can create one file. In other words, it was unable to > increase in number of files/directories. xfs_check and xfs_repair results no > errors and no fixes. > > We look for the cause and solution, then we find the msg00264 (2003-07) is > very similer to our situation. But, we cannot find what was the cause and > solution in the thread. > > Does somebody know how it goes or what was the cause and solution? Or, if > someone who had similar situation and found the solution, please let us know > about it. Any infomation will be appriciate for us. > > Regards, > Shinya Sakamoto > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ L. Friedman netllama@linux-sxs.org LlamaLand http://netllama.linux-sxs.org 19:50:01 up 44 days, 6:04, 1 user, load average: 0.47, 0.45, 0.34 From owner-linux-xfs@oss.sgi.com Wed May 25 20:08:57 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 May 2005 20:09:00 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4Q38tXq025312 for ; Wed, 25 May 2005 20:08:56 -0700 Received: from mumble.melbourne.sgi.com (mumble.melbourne.sgi.com [134.14.55.227]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA12025; Thu, 26 May 2005 13:07:55 +1000 Received: from mumble.melbourne.sgi.com (localhost [127.0.0.1]) by mumble.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j4Q37qXf132303; Thu, 26 May 2005 13:07:53 +1000 (EST) Received: (from dgc@localhost) by mumble.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j4Q37lB9130988; Thu, 26 May 2005 13:07:47 +1000 (EST) Date: Thu, 26 May 2005 13:07:46 +1000 From: Dave Chinner To: Shinya Sakamoto Cc: linux-xfs@oss.sgi.com Subject: Re: msg00264; Cant create new files Message-ID: <20050526130746.T19332@melbourne.sgi.com> References: <06d001c5619d$35b6f670$170a0e0a@FD3S> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <06d001c5619d$35b6f670$170a0e0a@FD3S>; from sakamoto@kel.co.jp on Thu, May 26, 2005 at 11:47:08AM +0900 X-archive-position: 5318 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 574 Lines: 19 On Thu, May 26, 2005 at 11:47:08AM +0900, Shinya Sakamoto wrote: > Hello all, > > Our xfs fileserver had a trouble. It was unable to create a file with "no > space left on device" message but had 0.6TB (40%) space available. When we > delete one file, we can create one file. In other words, it was unable to > increase in number of files/directories. xfs_check and xfs_repair results no > errors and no fixes. Sounds like you've run out of inode space. what does `df -i` tell you? Cheers, Dave. -- Dave Chinner R&D Software Engineer SGI Australian Software Group From owner-linux-xfs@oss.sgi.com Wed May 25 22:42:20 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 May 2005 22:42:23 -0700 (PDT) Received: from geyser.gps.caltech.edu (geyser.gps.caltech.edu [131.215.65.56]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4Q5gIXq003439 for ; Wed, 25 May 2005 22:42:20 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by geyser.gps.caltech.edu (Postfix) with ESMTP id 30AF3D02EB3E for ; Wed, 25 May 2005 22:41:31 -0700 (PDT) Received: from geyser.gps.caltech.edu ([127.0.0.1]) by localhost (geyser.gps.caltech.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27704-01 for ; Wed, 25 May 2005 22:41:30 -0700 (PDT) Received: from [192.168.123.100] (netblock-72-25-87-90.dslextreme.com [72.25.87.90]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by geyser.gps.caltech.edu (Postfix) with ESMTP id AD718D0134AB for ; Wed, 25 May 2005 22:41:30 -0700 (PDT) From: David Kewley Organization: Caltech ITS To: linux-xfs@oss.sgi.com Subject: 4k stacks on 32-bit, 8k stacks on 64-bit Date: Wed, 25 May 2005 22:41:26 -0700 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200505252241.26815.kewley@gps.caltech.edu> X-archive-position: 5319 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kewley@gps.caltech.edu Precedence: bulk X-list: linux-xfs Content-Length: 532 Lines: 16 How is xfs doing these days with 4k stacks on x86 systems, or 8k stacks on x86_64? I'm running RHEL 4, with xfs enabled in a kernel directly derived from the RHEL 4 kernel. I'm on x86_64, and until today, I thought I was safe stackwise because x86_64 keeps 8k stacks even when x86 is 4k. But Dave Jones has confirmed that stack objects are twice as big on x86_64 as on x86, so I'm in as much danger for stack overflow as x86 is with 4k stacks. Agreed so far? How big is the danger, and what can I do to avoid it? David From owner-linux-xfs@oss.sgi.com Wed May 25 22:50:04 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 May 2005 22:50:12 -0700 (PDT) Received: from kelaix1.kel.co.jp (kel-gw.kel.co.jp [202.224.137.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4Q5o3Xq004386 for ; Wed, 25 May 2005 22:50:03 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost.kel.co.jp (Postfix) with SMTP id E0C061B4166; Thu, 26 May 2005 14:49:15 +0900 (JST) Received: from FD3S (unknown [10.14.10.23]) by kelaix1.kel.co.jp (Postfix) with SMTP id B0B531B416E; Thu, 26 May 2005 14:49:11 +0900 (JST) Message-ID: <003c01c561b6$a43a3f30$170a0e0a@FD3S> From: "Shinya Sakamoto" To: "Dave Chinner" Cc: References: <06d001c5619d$35b6f670$170a0e0a@FD3S> <20050526130746.T19332@melbourne.sgi.com> Subject: Re: msg00264; Cant create new files Date: Thu, 26 May 2005 14:49:11 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-archive-position: 5320 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sakamoto@kel.co.jp Precedence: bulk X-list: linux-xfs Content-Length: 2424 Lines: 66 Hello Dave, Thanks for your response. `df -i` and `-k` were listed below. We have four 2TB and a 0.9TB. The problem was only in /dev/pool/lvol2. # of inodes seemed to be fine. # of files/directories were almost 5000. # df -k Filesystem 1k-blocks Used Available Use% Mounted on /dev/pool/lvol1 2147287040 2146338596 948444 100% /shares/nas3_0 /dev/pool/lvol2 2147287040 1214659232 932627808 57% /shares/nas3_1 /dev/pool/lvol3 2147287040 1577714296 569572744 74% /shares/nas3_2 /dev/pool/lvol4 2147287040 1651783800 495503240 77% /shares/nas3_3 /dev/pool/lvol5 933511888 787869104 145642784 85% /shares/nas3_4 # df -i Filesystem Inodes IUsed IFree IUse% Mounted on /dev/pool/lvol1 3820400 17414 3802986 1% /shares/nas3_0 /dev/pool/lvol2 4294967295 5824 4294961471 1% /shares/nas3_1 /dev/pool/lvol3 4294967295 31879 4294935416 1% /shares/nas3_2 /dev/pool/lvol4 1982069792 16476 1982053316 1% /shares/nas3_3 /dev/pool/lvol5 582608256 14384 582593872 1% /shares/nas3_4 As you may guess, we have already abandon to fix it. Once we backup data, eliminated only the lvol2 and make it again, then restore data. Now, the lvol2 works fine, it can be create files even if the # of files is greater than used to be. So, I would like to know what was the cause and if there was other solution or not. I wonder if there might be a bug which `df -i` think inodes available but actually no inodes. Could you please advise us if you have such a information? Best regards, Shinya Sakamoto ----- Original Message ----- From: "Dave Chinner" To: "Shinya Sakamoto" Cc: Sent: Thursday, May 26, 2005 12:07 PM Subject: Re: msg00264; Cant create new files > On Thu, May 26, 2005 at 11:47:08AM +0900, Shinya Sakamoto wrote: >> Hello all, >> >> Our xfs fileserver had a trouble. It was unable to create a file with "no >> space left on device" message but had 0.6TB (40%) space available. When >> we >> delete one file, we can create one file. In other words, it was unable to >> increase in number of files/directories. xfs_check and xfs_repair results >> no >> errors and no fixes. > > Sounds like you've run out of inode space. what does `df -i` tell you? > > Cheers, > > Dave. > -- > Dave Chinner > R&D Software Engineer > SGI Australian Software Group From owner-linux-xfs@oss.sgi.com Thu May 26 10:35:18 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 May 2005 10:35:21 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QHZIXq026949 for ; Thu, 26 May 2005 10:35:18 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4QHYSxT013731 for ; Thu, 26 May 2005 12:34:28 -0500 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4QHYQ0F15774378; Thu, 26 May 2005 12:34:27 -0500 (CDT) Message-ID: <429608A2.8060702@sgi.com> Date: Thu, 26 May 2005 12:34:26 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Kewley CC: linux-xfs@oss.sgi.com Subject: Re: 4k stacks on 32-bit, 8k stacks on 64-bit References: <200505252241.26815.kewley@gps.caltech.edu> In-Reply-To: <200505252241.26815.kewley@gps.caltech.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5321 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1244 Lines: 34 David Kewley wrote: > How is xfs doing these days with 4k stacks on x86 systems, or 8k stacks on > x86_64? The former may be dicey in some situations (stacking - nfs, volume managers, etc), I'd expect the latter to be OK. > I'm running RHEL 4, with xfs enabled in a kernel directly derived from the > RHEL 4 kernel. I'm on x86_64, and until today, I thought I was safe > stackwise because x86_64 keeps 8k stacks even when x86 is 4k. But Dave Jones > has confirmed that stack objects are twice as big on x86_64 as on x86, Only some stack objects will be bigger - longs (and pointers) will be 64 bits instead of 32. But I don't think you'll see a wholesale 2x increase on average. x86_64 also passes args differently and that uses a little stack space IIRC. Further, x86_64 does not move softirqs to the irq stack today, so that can add to the troubles. But overall it's my (un?)educated guess that x86_64 should be in better shape. > so I'm > in as much danger for stack overflow as x86 is with 4k stacks. > > Agreed so far? > > How big is the danger, and what can I do to avoid it? If you just run local xfs without stacking other drivers above/below it in the IO chain, you'll be less likely to hit a problem. -Eric From owner-linux-xfs@oss.sgi.com Thu May 26 15:19:46 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 May 2005 15:19:49 -0700 (PDT) Received: from geyser.gps.caltech.edu (geyser.gps.caltech.edu [131.215.65.56]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QMJjXq027598 for ; Thu, 26 May 2005 15:19:46 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by geyser.gps.caltech.edu (Postfix) with ESMTP id DE381D024331 for ; Thu, 26 May 2005 15:18:57 -0700 (PDT) Received: from geyser.gps.caltech.edu ([127.0.0.1]) by localhost (geyser.gps.caltech.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01088-06 for ; Thu, 26 May 2005 15:18:57 -0700 (PDT) Received: from aeolis.gps.caltech.edu (aeolis.gps.caltech.edu [131.215.64.76]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by geyser.gps.caltech.edu (Postfix) with ESMTP id 99376D0134D3 for ; Thu, 26 May 2005 15:18:57 -0700 (PDT) From: David Kewley Organization: Caltech GPS / ITS SMS To: linux-xfs@oss.sgi.com Subject: Re: 4k stacks on 32-bit, 8k stacks on 64-bit Date: Thu, 26 May 2005 15:18:56 -0700 User-Agent: KMail/1.8 References: <200505252241.26815.kewley@gps.caltech.edu> <429608A2.8060702@sgi.com> In-Reply-To: <429608A2.8060702@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505261518.56673.kewley@gps.caltech.edu> X-archive-position: 5322 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kewley@gps.caltech.edu Precedence: bulk X-list: linux-xfs Content-Length: 473 Lines: 18 On Thursday 26 May 2005 10:34, Eric Sandeen wrote: > If you just run local xfs without stacking other drivers above/below > it in the IO chain, you'll be less likely to hit a problem. Thanks Eric. Unfortunately, my typical application has a stack like this: 3w-9xxx (JBOD since hw RAID5 is extremely slow in my hands) md (RAID 6) lvm2 xfs nfs What's your educated guess about the likelihood of hitting problems with this stack, assuming ~10 busy nfs clients? David From owner-linux-xfs@oss.sgi.com Thu May 26 21:24:18 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 May 2005 21:24:23 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4R4OIXq024519 for ; Thu, 26 May 2005 21:24:18 -0700 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4R69ORL001962 for ; Thu, 26 May 2005 23:09:24 -0700 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id j4R4NSad57884997; Thu, 26 May 2005 21:23:29 -0700 (PDT) Message-ID: <4296A0C0.30503@sgi.com> Date: Thu, 26 May 2005 23:23:28 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Kewley CC: linux-xfs@oss.sgi.com Subject: Re: 4k stacks on 32-bit, 8k stacks on 64-bit References: <200505252241.26815.kewley@gps.caltech.edu> <429608A2.8060702@sgi.com> <200505261518.56673.kewley@gps.caltech.edu> In-Reply-To: <200505261518.56673.kewley@gps.caltech.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5323 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 577 Lines: 23 David Kewley wrote: > On Thursday 26 May 2005 10:34, Eric Sandeen wrote: > >>If you just run local xfs without stacking other drivers above/below >>it in the IO chain, you'll be less likely to hit a problem. > > > Thanks Eric. Unfortunately, my typical application has a stack like > this: > > 3w-9xxx (JBOD since hw RAID5 is extremely slow in my hands) > md (RAID 6) > lvm2 > xfs > nfs > > What's your educated guess about the likelihood of hitting problems with > this stack, assuming ~10 busy nfs clients? on ia32 you're doomed. on x86_64 I'd test it. :) -Eric From owner-linux-xfs@oss.sgi.com Thu May 26 21:52:34 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 May 2005 21:52:36 -0700 (PDT) Received: from geyser.gps.caltech.edu (geyser.gps.caltech.edu [131.215.65.56]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4R4qXXq025674 for ; Thu, 26 May 2005 21:52:33 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by geyser.gps.caltech.edu (Postfix) with ESMTP id 95E97D02EB40 for ; Thu, 26 May 2005 21:51:43 -0700 (PDT) Received: from geyser.gps.caltech.edu ([127.0.0.1]) by localhost (geyser.gps.caltech.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02949-01 for ; Thu, 26 May 2005 21:51:43 -0700 (PDT) Received: from [192.168.123.100] (netblock-72-25-87-90.dslextreme.com [72.25.87.90]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by geyser.gps.caltech.edu (Postfix) with ESMTP id 0DF38D02EB3E for ; Thu, 26 May 2005 21:51:42 -0700 (PDT) From: David Kewley Organization: Caltech ITS To: linux-xfs@oss.sgi.com Subject: Re: 4k stacks on 32-bit, 8k stacks on 64-bit Date: Thu, 26 May 2005 21:51:39 -0700 User-Agent: KMail/1.6.2 References: <200505252241.26815.kewley@gps.caltech.edu> <200505261518.56673.kewley@gps.caltech.edu> <4296A0C0.30503@sgi.com> In-Reply-To: <4296A0C0.30503@sgi.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200505262151.39251.kewley@gps.caltech.edu> X-archive-position: 5324 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kewley@gps.caltech.edu Precedence: bulk X-list: linux-xfs Content-Length: 1212 Lines: 34 Eric Sandeen wrote on Thursday 26 May 2005 21:23: > David Kewley wrote: > > On Thursday 26 May 2005 10:34, Eric Sandeen wrote: > >>If you just run local xfs without stacking other drivers above/below > >>it in the IO chain, you'll be less likely to hit a problem. > > > > Thanks Eric. Unfortunately, my typical application has a stack like > > this: > > > > 3w-9xxx (JBOD since hw RAID5 is extremely slow in my hands) > > md (RAID 6) > > lvm2 > > xfs > > nfs > > > > What's your educated guess about the likelihood of hitting problems with > > this stack, assuming ~10 busy nfs clients? > > on ia32 you're doomed. on x86_64 I'd test it. :) I'd love to test it thoroughly, but my customers want this NOW, and I'm not willing to take the risk with their data. :/ So I'm going with the RHEL4 default, which is ext3, on the expectation that RH has done thorough testing for its customers. All the same, I think I'll ask on the RHEL4 mailing list (nahant-list). If I manage to free up some testing time with a similar setup in the future, I certainly will test it & let y'all know what I find. I *do* seem to have a lot of requests for multi-TB servers these days. :) Thanks for your feedback! David From owner-linux-xfs@oss.sgi.com Fri May 27 00:01:59 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 May 2005 00:02:10 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4R71vXq000554 for ; Fri, 27 May 2005 00:01:58 -0700 Received: from mumble.melbourne.sgi.com (mumble.melbourne.sgi.com [134.14.55.227]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA15367; Fri, 27 May 2005 17:01:00 +1000 Received: from mumble.melbourne.sgi.com (localhost [127.0.0.1]) by mumble.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j4R70tXf136190; Fri, 27 May 2005 17:00:55 +1000 (EST) Received: (from dgc@localhost) by mumble.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j4R70mIh132785; Fri, 27 May 2005 17:00:48 +1000 (EST) Date: Fri, 27 May 2005 17:00:48 +1000 From: Dave Chinner To: Shinya Sakamoto Cc: linux-xfs@oss.sgi.com Subject: Re: msg00264; Cant create new files Message-ID: <20050527170048.D19332@melbourne.sgi.com> References: <06d001c5619d$35b6f670$170a0e0a@FD3S> <20050526130746.T19332@melbourne.sgi.com> <003c01c561b6$a43a3f30$170a0e0a@FD3S> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <003c01c561b6$a43a3f30$170a0e0a@FD3S>; from sakamoto@kel.co.jp on Thu, May 26, 2005 at 02:49:11PM +0900 X-archive-position: 5325 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2102 Lines: 50 On Thu, May 26, 2005 at 02:49:11PM +0900, Shinya Sakamoto wrote: > Hello Dave, > > Thanks for your response. > `df -i` and `-k` were listed below. We have four 2TB and a 0.9TB. The > problem was only in /dev/pool/lvol2. # of inodes seemed to be fine. # of > files/directories were almost 5000. > > # df -k > Filesystem 1k-blocks Used Available Use% Mounted on > /dev/pool/lvol1 2147287040 2146338596 948444 100% /shares/nas3_0 > /dev/pool/lvol2 2147287040 1214659232 932627808 57% /shares/nas3_1 > /dev/pool/lvol3 2147287040 1577714296 569572744 74% /shares/nas3_2 > /dev/pool/lvol4 2147287040 1651783800 495503240 77% /shares/nas3_3 > /dev/pool/lvol5 933511888 787869104 145642784 85% /shares/nas3_4 > > # df -i > Filesystem Inodes IUsed IFree IUse% Mounted on > /dev/pool/lvol1 3820400 17414 3802986 1% /shares/nas3_0 > /dev/pool/lvol2 4294967295 5824 4294961471 1% /shares/nas3_1 > /dev/pool/lvol3 4294967295 31879 4294935416 1% /shares/nas3_2 The number of inodes looks wrong - 4294967295 = 2^32 - 1 = -1. If these filesystems were all built with the same mkfs command, I'd expect them all to report the same number here. What does an strace of the df -i command show (the statfs calls in particular)? > /dev/pool/lvol4 1982069792 16476 1982053316 1% /shares/nas3_3 > /dev/pool/lvol5 582608256 14384 582593872 1% /shares/nas3_4 > > As you may guess, we have already abandon to fix it. Once we backup data, > eliminated only the lvol2 and make it again, then restore data. Now, the > lvol2 works fine, it can be create files even if the # of files is greater > than used to be. So, I would like to know what was the cause and if there > was other solution or not. IIRC, an extremely fragmented filesystem can cause this sort of behaviour. Have you tried running xfs_bmap on some of the files to determine if they are fragmented at all? Do you run xfs_fsr at all on these filesystems? Cheers, Dave. -- Dave Chinner R&D Software Engineer SGI Australian Software Group From owner-linux-xfs@oss.sgi.com Fri May 27 01:48:19 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 May 2005 01:48:22 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4R8mJXq010327 for ; Fri, 27 May 2005 01:48:19 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4RAXQ2T009758 for ; Fri, 27 May 2005 03:33:26 -0700 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4R8kRR08948528; Fri, 27 May 2005 03:46:27 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1DbaU7-0004nz-00; Fri, 27 May 2005 03:46:27 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 936890 - rewrite xfs_iflush_all Message-Id: From: Christoph Hellwig Date: Fri, 27 May 2005 03:46:27 -0500 X-archive-position: 5326 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 680 Lines: 17 Date: Fri May 27 01:46:04 PDT 2005 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.6.x Inspected by: cattelan The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:193349a fs/xfs/xfs_mount.c - 1.357 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.357&r2=text&tr2=1.356&f=h fs/xfs/xfs_inode.c - 1.414 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.414&r2=text&tr2=1.413&f=h fs/xfs/xfs_inode.h - 1.201 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.h.diff?r1=text&tr1=1.201&r2=text&tr2=1.200&f=h From owner-linux-xfs@oss.sgi.com Fri May 27 21:13:13 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 May 2005 21:13:23 -0700 (PDT) Received: from crumbria.it ([151.8.104.60]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4S4D8Xq017154 for ; Fri, 27 May 2005 21:13:11 -0700 Received: from (10.10.10.3) by webshield.crumbria.it via smtp id 1351_aae8b0e2_cf2e_11d9_85c3_0002b3eef440; Sat, 28 May 2005 06:12:13 +0200 (CEST) Received: from crumbria.it [127.0.0.1] by crumbria.it [127.0.0.1] (with RAW) (MDaemon.PRO.v8.0.2.R) for ; Fri, 27 May 2005 14:54:33 +0200 Date: Fri, 27 May 2005 14:54:33 +0200 From: giottoli.tom@crumbria.it Reply-To: giottoli.tom@crumbria.it Subject: Re: Approved document To: linux-xfs@oss.sgi.com X-MDaemon-Deliver-To: linux-xfs@oss.sgi.com Message-ID: Mime-Version: 1.0 X-Actual-From: giottoli.tom@crumbria.it X-Return-Path: <> Content-Type: text/plain; charset=US-ASCII X-archive-position: 5327 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: giottoli.tom@crumbria.it Precedence: bulk X-list: linux-xfs Content-Length: 121 Lines: 8 conferma automatica di ricezione della e-mail: Tom Giottoli Amministratore Sistema Regione Umbria Consiglio Regionale From owner-linux-xfs@oss.sgi.com Sat May 28 02:30:23 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 28 May 2005 02:30:26 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4S9UMXq031632 for ; Sat, 28 May 2005 02:30:23 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1DbxLn-00052y-Lk; Sat, 28 May 2005 10:11:23 +0100 Date: Sat, 28 May 2005 10:11:23 +0100 From: Christoph Hellwig To: Jan Kasprzak Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS lstat() _very_ slow on SMP Message-ID: <20050528091123.GA19330@infradead.org> Mail-Followup-To: Christoph Hellwig , Jan Kasprzak , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com References: <20050516162506.GB19415@fi.muni.cz> <20050518140258.GA22587@infradead.org> <20050518174530.GF19173@fi.muni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050518174530.GF19173@fi.muni.cz> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 5328 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 2809 Lines: 53 On Wed, May 18, 2005 at 07:45:30PM +0200, Jan Kasprzak wrote: > Christoph Hellwig wrote: > : On Mon, May 16, 2005 at 06:25:06PM +0200, Jan Kasprzak wrote: > : > Hi all, > : > > : > I have a big XFS volume on my fileserver, and I have noticed that > : > making an incremental backup of this volume is _very_ slow. The incremental > : > backup essentially checks mtime of all files on this volume, and it > : > takes ~4ms of _system_ time (i.e. no iowait or what) to do a lstat(). > : > : Thanks a lot for the report, I'll investigate what's going on once I get > : a little time. (Early next week I hope) > > Hmm, I feel like I am hunting ghosts - after a fresh reboot > of the 4-CPU server I did four runs of 128*128*128 files with various > sizes of the underlying filesystem (in order to eliminate the volume > size as a problematic factor). I've got the following numbers: > > Volume size create time find -mtime +1000 cost of lseek() > 5GB 55m77 real 52m51 sys 1m1 real 0m53 sys 19 usecs > 25GB 58m15 real 55m27 sys 83m47 real 82m15 sys 2171 usecs (!!!!!!) > 125GB 67m0 real 61m35 sys 0m55 real 0m48 sys 18 usecs > 625GB 68m30 real 62m38 sys 0m57 real 0m49 sys 18 usecs > > So the results are probably not dependent on the volume size, > but on something totally random (such as which cpu the command > ends up running on or something like that), or on the system uptime > (and implied fragmentation of memory or what). > > I've tried to re-run the same test the next day (i.e. on > server with longer uptime), but the server crashed - my test script > ended locked up somewhere in kernel (probably holding some locks), > and then other processes started to lock up after accessing the file > system (my top(1) was running OK, but when I tried to "touch newfile" > in another shell, it locked up as well). So I had to reset this server > again. > > I am not really sure where exactly the problem is. I think > it is related to XFS, big memory of this server (26 GB), four CPUs, > and maybe even the x86_64 architecture. I was not able to reproduce > the problem on the same HW using ext3fs, and the problem is also > a magnitude smaller on 2-way system with 4GB of RAM. Maybe I should > try to reproduce this on our Altix box to eliminate the x86_64 as the > possible source of problems. > > I use the attached "bigtree.pl" to create the directory structure > ("time ./bigtree.pl /new-volume 3 128" for 128*128*128 files), and then > "strace -c find /new-volume -type f -mtime +1000 -print" (the numbers > without strace are almost the same, so strace is not a problem here). I couldn't reproduce the odd case here. Could you try to get some profiling data with oprofile for the odd and one of the normal cases? From owner-linux-xfs@oss.sgi.com Sun May 29 11:38:52 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 29 May 2005 11:39:00 -0700 (PDT) Received: from tirith.ics.muni.cz (tirith.ics.muni.cz [147.251.4.36]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4TIcoXq002304 for ; Sun, 29 May 2005 11:38:51 -0700 Received: from anxur.fi.muni.cz (anxur.fi.muni.cz [147.251.48.3]) by tirith.ics.muni.cz (8.13.2/8.13.2) with ESMTP id j4TIbpGB024164; Sun, 29 May 2005 20:37:52 +0200 Received: by anxur.fi.muni.cz (Postfix, from userid 11561) id ECFB922AF3E; Sun, 29 May 2005 20:37:50 +0200 (CEST) Date: Sun, 29 May 2005 20:37:50 +0200 From: Jan Kasprzak To: Christoph Hellwig , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS lstat() _very_ slow on SMP Message-ID: <20050529183750.GA5274@fi.muni.cz> References: <20050516162506.GB19415@fi.muni.cz> <20050518140258.GA22587@infradead.org> <20050518174530.GF19173@fi.muni.cz> <20050528091123.GA19330@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050528091123.GA19330@infradead.org> User-Agent: Mutt/1.4.1i X-Muni-Spam-TestIP: 147.251.48.3 X-Muni-Envelope-From: kas@fi.muni.cz X-Muni-Virus-Test: Clean X-archive-position: 5330 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kas@fi.muni.cz Precedence: bulk X-list: linux-xfs Content-Length: 920 Lines: 19 Christoph Hellwig wrote: : > ("time ./bigtree.pl /new-volume 3 128" for 128*128*128 files), and then : > "strace -c find /new-volume -type f -mtime +1000 -print" (the numbers : > without strace are almost the same, so strace is not a problem here). : : I couldn't reproduce the odd case here. Could you try to get some profiling : data with oprofile for the odd and one of the normal cases? I have solved this by adding "ihashsize=65537" to /etc/fstab. Now my find(1) is limited by the disk speed instead of system time. -Y. -- | Jan "Yenya" Kasprzak | | GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E | | http://www.fi.muni.cz/~kas/ Czech Linux Homepage: http://www.linux.cz/ | -- Yes. CVS is much denser. -- -- CVS is also total crap. So your point is? --Linus Torvalds -- From owner-linux-xfs@oss.sgi.com Mon May 30 07:04:36 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 May 2005 07:04:46 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4UE4VXq029522 for ; Mon, 30 May 2005 07:04:36 -0700 Received: from quatar.cs.tu-berlin.de [130.149.17.111] (helo=quatar) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0ML29c-1Dckml0t0k-0008Ss; Mon, 30 May 2005 15:58:31 +0200 Date: Mon, 30 May 2005 15:58:27 +0200 (MEST) From: Udo Wolter X-X-Sender: uwp@quatar Reply-To: uwp@dicke-aersche.de To: linux-xfs@oss.sgi.com Subject: XFS & cryptoloop problems Message-ID: X-message-flag: Microsoft & Outlook wegwerfen - Linux nehmen ! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Provags-ID: kundenserver.de abuse@kundenserver.de login:3106c298ae0df7732ff6407e2ab764cf X-archive-position: 5331 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: uwp@dicke-aersche.de Precedence: bulk X-list: linux-xfs Content-Length: 9811 Lines: 161 Hi! I'm using XFS for more than 2 years now and normally I've been very happy with it. Since some months I'm using cryptoloop to crypt my disks and put XFS systems onto that loop, e.g.: losetup -e twofish /dev/loop0 /dev/sda5 mkfs.xfs /dev/loop0 Now it's perfectly mountable and usable. I also using IDE-disks as USB-disks for having the convenience to swap them, switch them on and off etc. So, even though it's device sda, it's still an IDE disk behind it. Yesterday one of my disks had problems. During a filetransfer to the disk it just got stuck and I had to reboot. After reboot I wanted to mount the disk again: mount -o encryption=twofish /dev/sda5 /mnt I got this: XFS mounting filesystem loop0 Starting XFS recovery on filesystem: loop0 (dev: loop0) Access to block zero: fs: inode: 61277749 start_block : 0 start_off : 0 blkcnt : 0 extent-state : 0 ------------[ cut here ]------------ kernel BUG at fs/xfs/support/debug.c:106! invalid operand: 0000 [#1] PREEMPT SMP Modules linked in: ipt_MASQUERADE iptable_nat ip_conntrack_irc bridge tun ipv6 lp binfmt_misc iptable_filter ip_tables ide_cd cdrom parport_pc parport 8250_pnp 8250 serial_core pcspkr rtc 8139cp i2c_i801 sd_mod usblp uhci_hcd eth1394 intel_mch_agp intel_agp ohci1394 ieee1394 usb_storage ehci_hcd usbcore i2c_isa it87 i2c_sensor evdev i2c_core cryptoloop loop blowfish psmouse snd_seq_oss snd_seq_midi snd_seq_midi_event snd_seq snd_ice1724 snd_ice17xx_ak4xxx snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_ak4xxx_adda snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore ip_conntrack_ftp ip_conntrack pppoe pppox ppp_generic slhc r128 drm agpgart 8139too mii crc32 e1000 af_packet CPU: 0 EIP: 0060:[] Not tainted VLI EFLAGS: 00010246 (2.6.11.6-grsec) EIP is at cmn_err+0xa1/0xc0 eax: 00000000 ebx: c03e2b20 ecx: 00000000 edx: 00000001 esi: 00000000 edi: c04bcb40 ebp: 00000000 esp: f56399c4 ds: 007b es: 007b ss: 0068 Process mount (pid: 8341, threadinfo=f5639000 task=f5b92000) Stack: c03d4128 c03d9fc8 c04bcb40 00000286 c03e2b20 00000000 00000001 f5639ad8 c0242d87 00000000 c03e2b20 f5a33c40 03a70635 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 f546d62c Call Trace: [] xfs_bmap_search_extents+0x107/0x130 [] xfs_bunmapi+0x1b3/0x10c0 [] __alloc_pages+0x2e3/0x420 [] _spin_lock+0x16/0x90 [] _spin_unlock+0xd/0x30 [] cache_alloc_refill+0x142/0x230 [] xfs_trans_log_inode+0x2d/0x60 [] xfs_itruncate_finish+0x1fa/0x460 [] xfs_inactive+0x50d/0x560 [] pagebuf_offset+0x33/0x40 [] xfs_itobp+0x114/0x260 [] vn_rele+0xd1/0xe0 [] linvfs_clear_inode+0x18/0x30 [] clear_inode+0xe6/0x130 [] generic_delete_inode+0x128/0x150 [] _atomic_dec_and_lock+0x31/0x50 [] iput+0x63/0x90 [] xlog_recover_process_iunlinks+0x33e/0x3e0 [] xlog_recover_finish+0xa8/0xe0 [] xfs_log_mount_finish+0x2c/0x30 [] xfs_mountfs+0x826/0xef0 [] _spin_unlock+0xd/0x30 [] xfs_readsb+0x198/0x200 [] xfs_ioinit+0x1f/0x40 [] xfs_mount+0x2ae/0x4c0 [] vfs_mount+0x43/0x50 [] linvfs_fill_super+0x9e/0x200 [] snprintf+0x27/0x30 [] disk_name+0xb4/0xc0 [] sb_set_blocksize+0x2e/0x60 [] get_sb_bdev+0x10a/0x150 [] alloc_vfsmnt+0x90/0xd0 [] linvfs_get_sb+0x30/0x40 [] linvfs_fill_super+0x0/0x200 [] do_kern_mount+0x57/0xe0 [] do_new_mount+0xbb/0x100 [] do_mount+0x181/0x1d0 [] copy_mount_options+0x63/0xc0 [] sys_mount+0x9f/0xe0 [] syscall_call+0x7/0xb Code: b8 40 cb 4b c0 89 44 24 08 8b 04 ad 80 27 42 c0 89 44 24 04 e8 41 59 ec ff 8b 54 24 0c b8 64 27 42 c0 e8 83 97 11 00 85 ed 75 08 <0f> 0b 6a 00 d8 9f 3d c0 83 c4 10 5b 5e 5f 5d c3 eb 0d 90 90 90 It's a 2.6.11.6 kernel with grsecurity enabled. Ok, I thought, maybe it's something old or weird. After this I took the disk and hung it to another PC, similar problem: May 30 10:25:43 roeddirs kernel: XFS mounting filesystem loop0 May 30 10:25:43 roeddirs kernel: Starting XFS recovery on filesystem: loop0 (dev: loop0) May 30 10:25:43 roeddirs kernel: ------------[ cut here ]------------ May 30 10:25:43 roeddirs kernel: PREEMPT SMP May 30 10:25:43 roeddirs kernel: Modules linked in: lp ide_cd cdrom ns558 gameport parport_pc parport 8250_pnp sd_mod dvb_ttpci dvb_core saa7146_vv video_buf saa7146 v4l1_compat v4l2_common videodev ves1820 stv0299 tda8083 stv0297 sp8870 firmware_class ves1x93 ttpci_eeprom i2c_i801 i2c_core ehci_hcd usb_storage uhci_hcd usbcore intel_mch_agp intel_agp ipv6 binfmt_misc tun crc32 eth1394 8250 serial_core cryptoloop loop blowfish video1394 evdev ohci1394 ieee1394 psmouse snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc hpt366 autofs4 af_packet nls_iso8859_1 ntfs reiserfs agpgart e1000 rtc May 30 10:25:43 roeddirs kernel: CPU: 0 May 30 10:25:43 roeddirs kernel: EIP: 0060:[] Not tainted VLI May 30 10:25:43 roeddirs kernel: EFLAGS: 00010246 (2.6.11.10) May 30 10:25:43 roeddirs kernel: EIP is at cmn_err+0xa1/0xc0 May 30 10:25:43 roeddirs kernel: eax: 00000000 ebx: c03835e0 ecx: f6288020 edx: 00000000 May 30 10:25:43 roeddirs kernel: esi: 00000000 edi: c049fb40 ebp: 00000000 esp: f56a59cc May 30 10:25:43 roeddirs kernel: ds: 007b es: 007b ss: 0068 May 30 10:25:43 roeddirs kernel: Process mount (pid: 4613, threadinfo=f56a4000 task=f6288550) May 30 10:25:43 roeddirs kernel: Stack: c0374bf8 c037aa98 c049fb40 00000202 c03835e0 00000000 00000001 f56a5ae0 May 30 10:25:43 roeddirs kernel: c01f6c07 00000000 c03835e0 f7cb98c0 03a70635 00000000 00000000 00000000 May 30 10:25:43 roeddirs kernel: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 f5f5692c May 30 10:25:43 roeddirs kernel: Call Trace: May 30 10:25:43 roeddirs kernel: [] xfs_bmap_search_extents+0x107/0x130 May 30 10:25:43 roeddirs kernel: [] xfs_bunmapi+0x1b3/0x10c0 May 30 10:25:43 roeddirs kernel: [] scheduler_tick+0x63/0x320 May 30 10:25:43 roeddirs kernel: [] __alloc_pages+0x2e3/0x420 May 30 10:25:43 roeddirs kernel: [] cache_alloc_refill+0x140/0x230 May 30 10:25:43 roeddirs kernel: [] xfs_trans_log_inode+0x2d/0x60 May 30 10:25:43 roeddirs kernel: [] xfs_itruncate_finish+0x1fa/0x460 May 30 10:25:43 roeddirs kernel: [] xfs_inactive+0x50d/0x560 May 30 10:25:43 roeddirs kernel: [] pagebuf_offset+0x33/0x40 May 30 10:25:43 roeddirs kernel: [] xfs_itobp+0x114/0x260 May 30 10:25:43 roeddirs kernel: [] vn_rele+0xd1/0xe0 May 30 10:25:43 roeddirs kernel: [] linvfs_clear_inode+0x18/0x30 May 30 10:25:43 roeddirs kernel: [] clear_inode+0xe6/0x130 May 30 10:25:43 roeddirs kernel: [] generic_delete_inode+0x128/0x150 May 30 10:25:43 roeddirs kernel: [] _atomic_dec_and_lock+0x31/0x50 May 30 10:25:43 roeddirs kernel: [] iput+0x63/0x90 May 30 10:25:43 roeddirs kernel: [] xlog_recover_process_iunlinks+0x33e/0x3e0 May 30 10:25:43 roeddirs kernel: [] xlog_recover_finish+0xa8/0xe0 May 30 10:25:43 roeddirs kernel: [] xfs_log_mount_finish+0x2c/0x30 May 30 10:25:43 roeddirs kernel: [] xfs_mountfs+0x826/0xef0 May 30 10:25:43 roeddirs kernel: [] xfs_readsb+0x198/0x200 May 30 10:25:43 roeddirs kernel: [] xfs_ioinit+0x1f/0x40 May 30 10:25:43 roeddirs kernel: [] xfs_mount+0x2ae/0x4c0 May 30 10:25:43 roeddirs kernel: [] vfs_mount+0x43/0x50 May 30 10:25:43 roeddirs kernel: [] linvfs_fill_super+0x9e/0x200 May 30 10:25:43 roeddirs kernel: [] snprintf+0x27/0x30 May 30 10:25:43 roeddirs kernel: [] disk_name+0xb4/0xc0 May 30 10:25:43 roeddirs kernel: [] sb_set_blocksize+0x2e/0x60 May 30 10:25:43 roeddirs kernel: [] get_sb_bdev+0x10a/0x150 May 30 10:25:43 roeddirs kernel: [] alloc_vfsmnt+0x90/0xd0 May 30 10:25:43 roeddirs kernel: [] linvfs_get_sb+0x30/0x40 May 30 10:25:43 roeddirs kernel: [] linvfs_fill_super+0x0/0x200 May 30 10:25:43 roeddirs kernel: [] do_kern_mount+0x57/0xe0 May 30 10:25:43 roeddirs kernel: [] do_new_mount+0x9c/0xe0 May 30 10:25:43 roeddirs kernel: [] do_mount+0x157/0x1b0 May 30 10:25:43 roeddirs kernel: [] dput+0x152/0x1d0 May 30 10:25:43 roeddirs kernel: [] copy_mount_options+0x63/0xc0 May 30 10:25:43 roeddirs kernel: [] sys_mount+0x9f/0xe0 May 30 10:25:43 roeddirs kernel: [] syscall_call+0x7/0xb May 30 10:25:43 roeddirs kernel: Code: b8 40 fb 49 c0 89 44 24 08 8b 04 ad 80 dc 3b c0 89 44 24 04 e8 f1 85 ec ff 8b 54 24 0c b8 64 dc 3b c0 e8 f3 bd 10 00 85 ed 75 08 <0f> 0b 6a 00 a8 aa 37 c0 83 c4 10 5b 5e 5f 5d c3 eb 0d 90 90 90 This time it's a standard 2.6.11.10 kernel. Both kernels have SMP/SMT enabled because they should do hyperthreading (intel machines). What I'll try to do is to losetup the disk again and copy the looped disk with dd to another disk. Maybe I'm getting my data back. BTW, the mount itself hung up with segmentation fault. Any hints for this problem? Thanx! Mermgfurt, Udo -- Udo Wolter | /"\ email: uwp@dicke-aersche.de | \ / ASCII RIBBON CAMPAIGN www: www.dicke-aersche.de | X AGAINST HTML MAIL dark: heaven@lutz-ziffer.de | / \ From owner-linux-xfs@oss.sgi.com Tue May 31 00:49:42 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 31 May 2005 00:49:46 -0700 (PDT) Received: from junior.physik.fu-berlin.de (junior.physik.fu-berlin.de [160.45.32.227]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4V7ndXq011198 for ; Tue, 31 May 2005 00:49:41 -0700 Received: from p54bd41c2.dip.t-dialin.net ([84.189.65.194] helo=puariko.homeip.net) by mail.atrpms.net with esmtps (TLSv1:AES256-SHA:256) (/C=DE/ST=Berlin/L=Berlin/O=nirvana)(verified=1) (Exim 4.51) id 1Dd1UE-00006R-7N; Tue, 31 May 2005 09:48:43 +0200 Received: (from thimm@localhost) by neu.nirvana (8.13.1/8.12.11/Submit) id j4V7mKe1014254; Tue, 31 May 2005 09:48:20 +0200 Date: Tue, 31 May 2005 09:48:20 +0200 From: Axel Thimm To: linux-xfs@oss.sgi.com Subject: out of the tree compilation and 4KSTACKS Message-ID: <20050531074820.GM8770@neu.nirvana> Reply-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+9faIjRurCDpBc7U" Content-Disposition: inline User-Agent: Mutt/1.4.2i X-HELO-Warning: Remote host 84.189.65.194 (p54bd41c2.dip.t-dialin.net) incorrectly presented itself as puariko.homeip.net X-Scanned: No viruses found. X-Scan-Signature: f3509aaee8e12bb0f004ef065a602f8b X-archive-position: 5333 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@ATrpms.net Precedence: bulk X-list: linux-xfs Content-Length: 870 Lines: 33 --+9faIjRurCDpBc7U Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, is it possible to add xfs support to a 2.6.9 kernel (e.g. the RHEL4 kernel) as an external kernel module? Would that make sense w/ 4KSTACKS? ATrpms is preparing RHEL3/4 support (75% of the packages have already made it) and there have already been requests on XFS support for RHEL4. I wouldn't like to maintain a separate kernel series again, though. BTW what happened to 1.3.3, was it released? --=20 Axel.Thimm at ATrpms.net --+9faIjRurCDpBc7U Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCnBbEQBVS1GOamfERArBMAJ9Aa1NmmTm9svfYbIIbv8eAJy2xMgCeNkXq MhUHr8iw4BjgePe6QCtnVXk= =svzJ -----END PGP SIGNATURE----- --+9faIjRurCDpBc7U-- From owner-linux-xfs@oss.sgi.com Tue May 31 02:27:36 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 31 May 2005 02:27:41 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4V9RaXq017160 for ; Tue, 31 May 2005 02:27:36 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4VBDE4q006969 for ; Tue, 31 May 2005 04:13:14 -0700 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4V9PfR09210984; Tue, 31 May 2005 04:25:41 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1Dd30H-0004mI-00; Tue, 31 May 2005 04:25:41 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: PARTIAL TAKE 936891 - simplify XFS_PURGE_INODE Message-Id: From: Christoph Hellwig Date: Tue, 31 May 2005 04:25:41 -0500 X-archive-position: 5334 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 410 Lines: 13 Date: Tue May 31 02:25:10 PDT 2005 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.6.x Inspected by: felixb The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:193408a fs/xfs/quota/xfs_quota_priv.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_quota_priv.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h From owner-linux-xfs@oss.sgi.com Tue May 31 02:58:22 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 31 May 2005 02:58:25 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4V9wLXq020642 for ; Tue, 31 May 2005 02:58:21 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4V9vRxT001672 for ; Tue, 31 May 2005 04:57:27 -0500 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4V9vQR09217861; Tue, 31 May 2005 04:57:26 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1Dd3V0-00064h-00; Tue, 31 May 2005 04:57:26 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: PARTIAL TAKE 936977 - remove xfs_incore_relse Message-Id: From: Christoph Hellwig Date: Tue, 31 May 2005 04:57:26 -0500 X-archive-position: 5335 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1028 Lines: 21 Date: Tue May 31 02:57:12 PDT 2005 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.4.x Inspected by: cattelan The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:193409a fs/xfs/xfs_mount.c - 1.358 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.358&r2=text&tr2=1.357&f=h fs/xfs/linux-2.6/xfs_buf.h - 1.103 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.h.diff?r1=text&tr1=1.103&r2=text&tr2=1.102&f=h fs/xfs/linux-2.6/xfs_buf.c - 1.197 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.c.diff?r1=text&tr1=1.197&r2=text&tr2=1.196&f=h fs/xfs/linux-2.4/xfs_buf.h - 1.109 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_buf.h.diff?r1=text&tr1=1.109&r2=text&tr2=1.108&f=h fs/xfs/linux-2.4/xfs_buf.c - 1.205 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_buf.c.diff?r1=text&tr1=1.205&r2=text&tr2=1.204&f=h From owner-linux-xfs@oss.sgi.com Tue May 31 03:31:49 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 31 May 2005 03:31:52 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VAVnXq023508 for ; Tue, 31 May 2005 03:31:49 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4VCHRBq021772 for ; Tue, 31 May 2005 05:17:27 -0700 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4VATs0F16066484; Tue, 31 May 2005 05:29:54 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1Dd40Q-0006Vk-00; Tue, 31 May 2005 05:29:54 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 936979 - Message-Id: From: Christoph Hellwig Date: Tue, 31 May 2005 05:29:54 -0500 X-archive-position: 5336 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 452 Lines: 14 Date: Tue May 31 03:29:43 PDT 2005 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.6.x Inspected by: felixb The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: linux:dmapi:193411a fs/dmapi/dmapi_mountinfo.c - 1.28 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/dmapi/dmapi_mountinfo.c.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h - use a proper prototype for ftype_list From owner-linux-xfs@oss.sgi.com Tue May 31 14:27:26 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 31 May 2005 14:27:31 -0700 (PDT) Received: from relay00.uchicago.edu (relay00.uchicago.edu [128.135.12.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VLRQXq010530 for ; Tue, 31 May 2005 14:27:26 -0700 Received: from [128.135.92.53] (moviemac.bsd.uchicago.edu [128.135.92.53]) by relay00.uchicago.edu (8.12.10/8.12.9) with ESMTP id j4VLQV4m027869 for ; Tue, 31 May 2005 16:26:31 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v622) Content-Transfer-Encoding: 7bit Message-Id: <9c4afc4cfd08b8eb6fa84f701c776c5c@uchicago.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed To: linux-xfs@oss.sgi.com From: Xander Meadow Subject: getting data from a corrupted file system Date: Tue, 31 May 2005 16:26:31 -0500 X-Mailer: Apple Mail (2.622) X-archive-position: 5337 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xmeadow@uchicago.edu Precedence: bulk X-list: linux-xfs Content-Length: 1133 Lines: 26 Hi, I was running a Raid5 from consensys that ran xfs version 1.3.1 with ACLs. We had a power outage and although the raidzone didn't go down (it's connect to a UPS) I think something went wrong with it. The machine is partitioned into two large segments, each 1.4 TB and I've been denied access from one of the ever since the power outage. I believe it is due to a corrupted file system. I tried running xfs_repair multiple times and it seemed to be getting farther each time I ran it, but it would always crash with the error: xfs_repair: buf calloc failed (4312 bytes): Cannot allocate memory After a while of running xfs_repair it finally got to the point where it would try to repair the same disconnect inodes every single time, so I stopped running xfs_repair. However, if I ran xfs_repair with the -n flag then it would run all the way through without a problem. What I'm wondering is, is there any way for me to get my data back? Are there any companies that are particularly good a recovering data from xfs machines? Are there any tricks I can try besides xfs_repair? Thanks very much. >Xander From owner-linux-xfs@oss.sgi.com Tue May 31 14:29:21 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 31 May 2005 14:29:25 -0700 (PDT) Received: from pimout4-ext.prodigy.net (pimout4-ext.prodigy.net [207.115.63.98]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VLTLXq010631 for ; Tue, 31 May 2005 14:29:21 -0700 Received: from taniwha.stupidest.org (adsl-63-202-173-158.dsl.snfc21.pacbell.net [63.202.173.158]) by pimout4-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j4VLSPPA208370 for ; Tue, 31 May 2005 17:28:25 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id D9212528F2D; Tue, 31 May 2005 14:28:23 -0700 (PDT) Date: Tue, 31 May 2005 14:28:23 -0700 From: Chris Wedgwood To: linux-xfs@oss.sgi.com Subject: Re: out of the tree compilation and 4KSTACKS Message-ID: <462608.672469a40d5f4a17f7b1f43a4517535a.ANY@taniwha.stupidest.org> References: <20050531074820.GM8770@neu.nirvana> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050531074820.GM8770@neu.nirvana> X-archive-position: 5338 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 330 Lines: 12 On Tue, May 31, 2005 at 09:48:20AM +0200, Axel Thimm wrote: > is it possible to add xfs support to a 2.6.9 kernel (e.g. the RHEL4 > kernel) as an external kernel module? yes > Would that make sense w/ 4KSTACKS? it does but it won't give you 8K stacks, the stack size is a property of the kernel and modules will inherit this From owner-linux-xfs@oss.sgi.com Tue May 31 14:55:26 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 31 May 2005 14:55:30 -0700 (PDT) Received: from junior.physik.fu-berlin.de (junior.physik.fu-berlin.de [160.45.32.227]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VLtLXq012917 for ; Tue, 31 May 2005 14:55:26 -0700 Received: from p54bd41c2.dip.t-dialin.net ([84.189.65.194] helo=puariko.homeip.net) by mail.atrpms.net with esmtps (TLSv1:AES256-SHA:256) (/C=DE/ST=Berlin/L=Berlin/O=nirvana)(verified=1) (Exim 4.51) id 1DdEge-0006lO-NG; Tue, 31 May 2005 23:54:20 +0200 Received: (from thimm@localhost) by neu.nirvana (8.13.1/8.12.11/Submit) id j4VLs3BY029498; Tue, 31 May 2005 23:54:03 +0200 Date: Tue, 31 May 2005 23:54:02 +0200 From: Axel Thimm To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com Subject: Re: out of the tree compilation and 4KSTACKS Message-ID: <20050531215402.GE23991@neu.nirvana> Reply-To: linux-xfs@oss.sgi.com References: <20050531074820.GM8770@neu.nirvana> <462608.672469a40d5f4a17f7b1f43a4517535a.ANY@taniwha.stupidest.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4Epv4kl9IRBfg3rk" Content-Disposition: inline In-Reply-To: <462608.672469a40d5f4a17f7b1f43a4517535a.ANY@taniwha.stupidest.org> User-Agent: Mutt/1.4.2i X-HELO-Warning: Remote host 84.189.65.194 (p54bd41c2.dip.t-dialin.net) incorrectly presented itself as puariko.homeip.net X-Scanned: No viruses found. X-Scan-Signature: 39cb6fb40f79335b877d4b42d770e347 X-archive-position: 5339 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@ATrpms.net Precedence: bulk X-list: linux-xfs Content-Length: 1250 Lines: 44 --4Epv4kl9IRBfg3rk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 31, 2005 at 02:28:23PM -0700, Chris Wedgwood wrote: > On Tue, May 31, 2005 at 09:48:20AM +0200, Axel Thimm wrote: >=20 > > is it possible to add xfs support to a 2.6.9 kernel (e.g. the RHEL4 > > kernel) as an external kernel module? >=20 > yes Hm, any pointers to "how"? ;) > > Would that make sense w/ 4KSTACKS? >=20 > it does but it won't give you 8K stacks, the stack size is a property > of the kernel and modules will inherit this Sure, that's clear. What I mean is: If you turn on xfs in RHEL4's kernel is it considered safe with 4KSTACKS? If not, that would make the whole point of building the kernel modules out of the tree meaningless. lkml and this list sometimes consider NFS & XFS a dangerous combination stackwise. Urban legend or is there truth to it? --=20 Axel.Thimm at ATrpms.net --4Epv4kl9IRBfg3rk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCnNz6QBVS1GOamfERAmCbAJ4/lXmc9oFScru+mt5u89iOokBRfgCfX03s 65gzocpV3dnPlCes5jIzUAQ= =jajn -----END PGP SIGNATURE----- --4Epv4kl9IRBfg3rk-- From owner-linux-xfs@oss.sgi.com Tue May 31 14:58:13 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 31 May 2005 14:58:15 -0700 (PDT) Received: from mss1.myactv.net (mss1.myactv.net [24.89.0.26]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4VLwCXq013699 for ; Tue, 31 May 2005 14:58:13 -0700 Received: (qmail 17764 invoked from network); 31 May 2005 21:57:13 -0000 Received: from dyn-153-113-195.myactv.net (HELO ?192.168.0.203?) (24.153.113.195) by new.mss1.myactv.net with SMTP; 31 May 2005 21:57:13 -0000 Subject: XFS module for RHEL4 From: Wayne Steenburg To: linux-xfs@oss.sgi.com Content-Type: text/plain Date: Tue, 31 May 2005 17:57:13 -0400 Message-Id: <1117576633.5018.12.camel@FC3Work> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 7bit X-archive-position: 5340 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: w.steenburg@myactv.net Precedence: bulk X-list: linux-xfs Content-Length: 150 Lines: 5 How would one go about compiling the XFS modules for the stock RHEL4 kernel? Redhat decided not to include it for whatever reason. Wayne Steenburg From owner-linux-xfs@oss.sgi.com Tue May 31 15:27:03 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 31 May 2005 15:27:06 -0700 (PDT) Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VMR2Xq018181 for ; Tue, 31 May 2005 15:27:03 -0700 Received: from pimout2-ext.prodigy.net (pimout2-int.prodigy.net [207.115.4.217]) by ylpvm43.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j4VMPwKd013128 for ; Tue, 31 May 2005 18:26:10 -0400 X-ORBL: [63.202.173.158] Received: from taniwha.stupidest.org (adsl-63-202-173-158.dsl.snfc21.pacbell.net [63.202.173.158]) by pimout2-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j4VMPnM3400362 for ; Tue, 31 May 2005 18:25:49 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 7337E528F2D; Tue, 31 May 2005 15:25:48 -0700 (PDT) Date: Tue, 31 May 2005 15:25:48 -0700 From: Chris Wedgwood To: linux-xfs@oss.sgi.com Subject: Re: out of the tree compilation and 4KSTACKS Message-ID: <477395.f3b7fdadc14ce50b8c44d1f319df1ab6.IBX@taniwha.stupidest.org> References: <20050531074820.GM8770@neu.nirvana> <462608.672469a40d5f4a17f7b1f43a4517535a.ANY@taniwha.stupidest.org> <20050531215402.GE23991@neu.nirvana> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050531215402.GE23991@neu.nirvana> X-archive-position: 5341 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 1255 Lines: 42 On Tue, May 31, 2005 at 11:54:02PM +0200, Axel Thimm wrote: > Hm, any pointers to "how"? ;) make -C M=`pwd` sort of thing. linux/Documentation/kbuild/modules.txt will probably explain it better than I can. > Sure, that's clear. What I mean is: If you turn on xfs in RHEL4's > kernel is it considered safe with 4KSTACKS? It is on already on RHEL isn't it? As to whether it's safe it depends who you ask. Various people from Red Hat insist that 4K stacks are desirable because they see order-1 allocations failing sometimes which make sense, however, x86-64 still uses 8K stacks and nobody is pushing hard for 4K stacks there. > If not, that would make the whole point of building the kernel > modules out of the tree meaningless. It has no advantages unless it's newer code. I would just just a tree from oss.sgi.com or mainline instead. > lkml and this list sometimes consider NFS & XFS a dangerous > combination stackwise. Urban legend or is there truth to it? For x86: XFS + 4KSTACKS used to fail trivially. Things have been improved greatly (the xfsqa tests now apparently pass with 4KSTACKS). With 4KSTACKS using NFS, loop, dm, RAID, LVM in combination with XFS will still break in some cases. From owner-linux-xfs@oss.sgi.com Tue May 31 15:44:59 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 31 May 2005 15:45:04 -0700 (PDT) Received: from pimout4-ext.prodigy.net (pimout4-ext.prodigy.net [207.115.63.98]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VMiwXq023415 for ; Tue, 31 May 2005 15:44:58 -0700 Received: from taniwha.stupidest.org (adsl-63-202-173-158.dsl.snfc21.pacbell.net [63.202.173.158]) by pimout4-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j4VMi3PA048104; Tue, 31 May 2005 18:44:03 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 3CD42528F2D; Tue, 31 May 2005 15:44:03 -0700 (PDT) Date: Tue, 31 May 2005 15:44:03 -0700 From: Chris Wedgwood To: Xander Meadow Cc: linux-xfs@oss.sgi.com Subject: Re: getting data from a corrupted file system Message-ID: <325673.f49b164f31c289627bd3b6908b08b9e3.ANY@taniwha.stupidest.org> References: <9c4afc4cfd08b8eb6fa84f701c776c5c@uchicago.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9c4afc4cfd08b8eb6fa84f701c776c5c@uchicago.edu> X-archive-position: 5342 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 366 Lines: 11 On Tue, May 31, 2005 at 04:26:31PM -0500, Xander Meadow wrote: > xfs_repair: buf calloc failed (4312 bytes): Cannot allocate memory how much memory does the system have? have you tried making sure there is enough swap? > What I'm wondering is, is there any way for me to get my data back? probably --- i just wonder how much memory xfs_repair is trying to use From owner-linux-xfs@oss.sgi.com Tue May 31 20:43:19 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 31 May 2005 20:43:23 -0700 (PDT) Received: from junior.physik.fu-berlin.de (junior.physik.fu-berlin.de [160.45.32.227]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j513hGXq031219 for ; Tue, 31 May 2005 20:43:19 -0700 Received: from p54bd41c2.dip.t-dialin.net ([84.189.65.194] helo=puariko.homeip.net) by mail.atrpms.net with esmtps (TLSv1:AES256-SHA:256) (/C=DE/ST=Berlin/L=Berlin/O=nirvana)(verified=1) (Exim 4.51) id 1DdK7K-0004NR-6E; Wed, 01 Jun 2005 05:42:13 +0200 Received: (from thimm@localhost) by neu.nirvana (8.13.1/8.12.11/Submit) id j513g2sg032572; Wed, 1 Jun 2005 05:42:02 +0200 Date: Wed, 1 Jun 2005 05:42:02 +0200 From: Axel Thimm To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com Subject: Re: out of the tree compilation and 4KSTACKS Message-ID: <20050601034202.GA31105@neu.nirvana> Reply-To: linux-xfs@oss.sgi.com References: <20050531074820.GM8770@neu.nirvana> <462608.672469a40d5f4a17f7b1f43a4517535a.ANY@taniwha.stupidest.org> <20050531215402.GE23991@neu.nirvana> <477395.f3b7fdadc14ce50b8c44d1f319df1ab6.IBX@taniwha.stupidest.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline In-Reply-To: <477395.f3b7fdadc14ce50b8c44d1f319df1ab6.IBX@taniwha.stupidest.org> User-Agent: Mutt/1.4.2i X-HELO-Warning: Remote host 84.189.65.194 (p54bd41c2.dip.t-dialin.net) incorrectly presented itself as puariko.homeip.net X-Scanned: No viruses found. X-Scan-Signature: 104ef725d1aa66b09d4aba9cc6cfc07b X-archive-position: 5343 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@ATrpms.net Precedence: bulk X-list: linux-xfs Content-Length: 2151 Lines: 74 --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 31, 2005 at 03:25:48PM -0700, Chris Wedgwood wrote: > On Tue, May 31, 2005 at 11:54:02PM +0200, Axel Thimm wrote: >=20 > > Hm, any pointers to "how"? ;) >=20 > make -C M=3D`pwd` >=20 > sort of thing. >=20 > linux/Documentation/kbuild/modules.txt will probably explain it better > than I can. >=20 > > Sure, that's clear. What I mean is: If you turn on xfs in RHEL4's > > kernel is it considered safe with 4KSTACKS? >=20 > It is on already on RHEL isn't it? No. That's the whole point of this exercise ;) > As to whether it's safe it depends who you ask. >=20 > Various people from Red Hat insist that 4K stacks are desirable > because they see order-1 allocations failing sometimes which make > sense, however, x86-64 still uses 8K stacks and nobody is pushing hard > for 4K stacks there. >=20 > > If not, that would make the whole point of building the kernel > > modules out of the tree meaningless. >=20 > It has no advantages unless it's newer code. I would just just a tree > from oss.sgi.com or mainline instead. The advantage is no xfs vs xfs. > > lkml and this list sometimes consider NFS & XFS a dangerous > > combination stackwise. Urban legend or is there truth to it? >=20 > For x86: >=20 > XFS + 4KSTACKS used to fail trivially. >=20 > Things have been improved greatly (the xfsqa tests now apparently > pass with 4KSTACKS). >=20 > With 4KSTACKS using NFS, loop, dm, RAID, LVM in combination with > XFS will still break in some cases. That's a blocker then, typical RHEL4 uses LVM2 partitioned disks if not told otherwise, and the rest is also not something you can have users live w/o. :( Thanks for the update! --=20 Axel.Thimm at ATrpms.net --fdj2RfSjLxBAspz7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCnS6JQBVS1GOamfERAv9KAKCG7nBy3Ehe7cfDMC2SbNONTBrbWwCfbrUu OLzhQfzgJ95LTF3C5+a5aE0= =naCh -----END PGP SIGNATURE----- --fdj2RfSjLxBAspz7-- From owner-linux-xfs@oss.sgi.com Tue May 31 21:01:13 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 31 May 2005 21:01:16 -0700 (PDT) Received: from ylpvm29.prodigy.net (ylpvm29-ext.prodigy.net [207.115.57.60]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5141CXq000395 for ; Tue, 31 May 2005 21:01:13 -0700 Received: from pimout3-ext.prodigy.net (pimout3-int.prodigy.net [207.115.4.218]) by ylpvm29.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j51407Cg022231 for ; Wed, 1 Jun 2005 00:00:07 -0400 X-ORBL: [63.202.173.158] Received: from taniwha.stupidest.org (adsl-63-202-173-158.dsl.snfc21.pacbell.net [63.202.173.158]) by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j5140BIJ360942; Wed, 1 Jun 2005 00:00:16 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 48FD2528F41; Tue, 31 May 2005 21:00:09 -0700 (PDT) Date: Tue, 31 May 2005 21:00:09 -0700 From: Chris Wedgwood To: linux-xfs@oss.sgi.com Cc: Axel Thimm Subject: Re: out of the tree compilation and 4KSTACKS Message-ID: <20050601040009.GA11354@taniwha.stupidest.org> References: <20050531074820.GM8770@neu.nirvana> <462608.672469a40d5f4a17f7b1f43a4517535a.ANY@taniwha.stupidest.org> <20050531215402.GE23991@neu.nirvana> <477395.f3b7fdadc14ce50b8c44d1f319df1ab6.IBX@taniwha.stupidest.org> <20050601034202.GA31105@neu.nirvana> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050601034202.GA31105@neu.nirvana> X-archive-position: 5344 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 464 Lines: 15 On Wed, Jun 01, 2005 at 05:42:02AM +0200, Axel Thimm wrote: > > It is on already on RHEL isn't it? > > No. That's the whole point of this exercise ;) I'm saying I thought RH kernels defaulted to using CONFIG_4KSTACKS don't they? > The advantage is no xfs vs xfs. When I talked (bitched?) to some RH people about the problems with XFS and 4KSTACKS they claimed that ext3 is faster than XFS is pretty much any meaningful benchmark on 8-CPU machines or smaller. From owner-linux-xfs@oss.sgi.com Tue May 31 21:18:10 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 31 May 2005 21:18:13 -0700 (PDT) Received: from kevlar.burdell.org (66-23-228-155.clients.speedfactory.net [66.23.228.155]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j514I9Xq001703 for ; Tue, 31 May 2005 21:18:09 -0700 Received: by kevlar.burdell.org (Postfix, from userid 1189) id 970E866C82; Tue, 31 May 2005 23:53:47 -0400 (EDT) Date: Tue, 31 May 2005 23:53:47 -0400 From: Sonny Rao To: Wayne Steenburg Cc: linux-xfs@oss.sgi.com Subject: Re: XFS module for RHEL4 Message-ID: <20050601035347.GB20301@kevlar.burdell.org> References: <1117576633.5018.12.camel@FC3Work> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1117576633.5018.12.camel@FC3Work> User-Agent: Mutt/1.4.2.1i X-archive-position: 5345 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sonny@burdell.org Precedence: bulk X-list: linux-xfs Content-Length: 1253 Lines: 29 On Tue, May 31, 2005 at 05:57:13PM -0400, Wayne Steenburg wrote: > How would one go about compiling the XFS modules for the stock RHEL4 > kernel? Redhat decided not to include it for whatever reason. > More precisely, RedHat decided it couldn't support any filesystem other than Ext3 (hint, if you paid for RHEL 4 and want XFS, you could complai^H^H^H^H ask RedHat to reevaluate their choices of supported filesystems) On to the (possibly) useful portion of this post, You need to get the kernel source RPM and use the rpmbuild command to setup the kernel tree appropriately.. I believe the command is "rpmbuild -bp" for "prep" which means untar and apply patches in RPM-speak. This will put the kernel tree in the "BUILD" directory where you can then go in and theoretically change whatever kernel options you want and rebuild. If you want the module to load into the supplied kernel, you should start with their config file and just build the XFS module. There could be other steps I'm missing (like adding the proper extraversion junk to the Makefile, possibly) because I haven't had the misfortune of doing this in a while, but that should get you started. And don't forget to let them hear your opinion on this subject :-) Sonny From owner-linux-xfs@oss.sgi.com Tue May 31 21:20:46 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 31 May 2005 21:20:49 -0700 (PDT) Received: from kevlar.burdell.org (66-23-228-155.clients.speedfactory.net [66.23.228.155]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j514KkXq002159 for ; Tue, 31 May 2005 21:20:46 -0700 Received: by kevlar.burdell.org (Postfix, from userid 1189) id 39F1166C82; Tue, 31 May 2005 23:56:25 -0400 (EDT) Date: Tue, 31 May 2005 23:56:25 -0400 From: Sonny Rao To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com, Axel Thimm Subject: Re: out of the tree compilation and 4KSTACKS Message-ID: <20050601035625.GC20301@kevlar.burdell.org> References: <20050531074820.GM8770@neu.nirvana> <462608.672469a40d5f4a17f7b1f43a4517535a.ANY@taniwha.stupidest.org> <20050531215402.GE23991@neu.nirvana> <477395.f3b7fdadc14ce50b8c44d1f319df1ab6.IBX@taniwha.stupidest.org> <20050601034202.GA31105@neu.nirvana> <20050601040009.GA11354@taniwha.stupidest.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050601040009.GA11354@taniwha.stupidest.org> User-Agent: Mutt/1.4.2.1i X-archive-position: 5346 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sonny@burdell.org Precedence: bulk X-list: linux-xfs Content-Length: 364 Lines: 12 On Tue, May 31, 2005 at 09:00:09PM -0700, Chris Wedgwood wrote: > When I talked (bitched?) to some RH people about the problems with XFS > and 4KSTACKS they claimed that ext3 is faster than XFS is pretty much > any meaningful benchmark on 8-CPU machines or smaller. LOL Why are their customers, or should I say "sheep", standing for this kind of crap ? Sonny From owner-linux-xfs@oss.sgi.com Tue May 31 21:30:39 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 31 May 2005 21:30:43 -0700 (PDT) Received: from junior.physik.fu-berlin.de (junior.physik.fu-berlin.de [160.45.32.227]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j514UcXq002805 for ; Tue, 31 May 2005 21:30:39 -0700 Received: from p54bd41c2.dip.t-dialin.net ([84.189.65.194] helo=puariko.homeip.net) by mail.atrpms.net with esmtps (TLSv1:AES256-SHA:256) (/C=DE/ST=Berlin/L=Berlin/O=nirvana)(verified=1) (Exim 4.51) id 1DdKr9-0001DZ-Ta; Wed, 01 Jun 2005 06:29:35 +0200 Received: (from thimm@localhost) by neu.nirvana (8.13.1/8.12.11/Submit) id j514TP33001411; Wed, 1 Jun 2005 06:29:25 +0200 Date: Wed, 1 Jun 2005 06:29:25 +0200 From: Axel Thimm To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com Subject: Re: out of the tree compilation and 4KSTACKS Message-ID: <20050601042925.GB31105@neu.nirvana> Reply-To: linux-xfs@oss.sgi.com References: <20050531074820.GM8770@neu.nirvana> <462608.672469a40d5f4a17f7b1f43a4517535a.ANY@taniwha.stupidest.org> <20050531215402.GE23991@neu.nirvana> <477395.f3b7fdadc14ce50b8c44d1f319df1ab6.IBX@taniwha.stupidest.org> <20050601034202.GA31105@neu.nirvana> <20050601040009.GA11354@taniwha.stupidest.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0eh6TmSyL6TZE2Uz" Content-Disposition: inline In-Reply-To: <20050601040009.GA11354@taniwha.stupidest.org> User-Agent: Mutt/1.4.2i X-HELO-Warning: Remote host 84.189.65.194 (p54bd41c2.dip.t-dialin.net) incorrectly presented itself as puariko.homeip.net X-Scanned: No viruses found. X-Scan-Signature: 39cb6fb40f79335b877d4b42d770e347 X-archive-position: 5347 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@ATrpms.net Precedence: bulk X-list: linux-xfs Content-Length: 1307 Lines: 44 --0eh6TmSyL6TZE2Uz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 31, 2005 at 09:00:09PM -0700, Chris Wedgwood wrote: > On Wed, Jun 01, 2005 at 05:42:02AM +0200, Axel Thimm wrote: > > > > Sure, that's clear. What I mean is: If you turn on xfs in > > > > RHEL4's kernel is it considered safe with 4KSTACKS? > > >=20 > > > It is on already on RHEL isn't it? > > > > No. That's the whole point of this exercise ;) >=20 > I'm saying I thought RH kernels defaulted to using CONFIG_4KSTACKS > don't they? Yes, they are. > > The advantage is no xfs vs xfs. >=20 > When I talked (bitched?) to some RH people about the problems with XFS > and 4KSTACKS they claimed that ext3 is faster than XFS is pretty much > any meaningful benchmark on 8-CPU machines or smaller. Sounds like you talked to Arjan. He does has radical views. The real reason are (lack of) support resources for non-ext3 filesystems. --=20 Axel.Thimm at ATrpms.net --0eh6TmSyL6TZE2Uz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCnTmlQBVS1GOamfERAsjQAJ40I/brX42CW0fLGN3x0UVBaoVMxACfSJwm uhCaPPXYadq7SA+R4u6rHlM= =uihH -----END PGP SIGNATURE----- --0eh6TmSyL6TZE2Uz-- From owner-linux-xfs@oss.sgi.com Tue May 31 23:07:08 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 31 May 2005 23:07:12 -0700 (PDT) Received: from quail.cita.utoronto.ca (quail.cita.utoronto.ca [128.100.76.6]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51677Xq009976 for ; Tue, 31 May 2005 23:07:08 -0700 Received: from cita.utoronto.ca (lemming.cita.utoronto.ca [128.100.76.53]) by quail.cita.utoronto.ca (8.12.11/8.12.11) with ESMTP id j51659Rk017880; Wed, 1 Jun 2005 02:05:09 -0400 Received: from lemming.cita.utoronto.ca (localhost [127.0.0.1]) by cita.utoronto.ca (8.13.1/8.13.1) with ESMTP id j516599a007449; Wed, 1 Jun 2005 02:05:09 -0400 Received: (from rjh@localhost) by lemming.cita.utoronto.ca (8.13.1/8.13.1/Submit) id j516599S007448; Wed, 1 Jun 2005 02:05:09 -0400 Date: Wed, 1 Jun 2005 02:05:09 -0400 From: Robin Humble To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com, Axel Thimm Subject: Re: out of the tree compilation and 4KSTACKS Message-ID: <20050601060509.GA7359@lemming.cita.utoronto.ca> References: <20050531074820.GM8770@neu.nirvana> <462608.672469a40d5f4a17f7b1f43a4517535a.ANY@taniwha.stupidest.org> <20050531215402.GE23991@neu.nirvana> <477395.f3b7fdadc14ce50b8c44d1f319df1ab6.IBX@taniwha.stupidest.org> <20050601034202.GA31105@neu.nirvana> <20050601040009.GA11354@taniwha.stupidest.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050601040009.GA11354@taniwha.stupidest.org> User-Agent: Mutt/1.4.1i X-archive-position: 5348 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rjh@cita.utoronto.ca Precedence: bulk X-list: linux-xfs Content-Length: 371 Lines: 11 On Tue, May 31, 2005 at 09:00:09PM -0700, Chris Wedgwood wrote: >When I talked (bitched?) to some RH people about the problems with XFS >and 4KSTACKS they claimed that ext3 is faster than XFS is pretty much >any meaningful benchmark on 8-CPU machines or smaller. I think RedHat are mistaken. http://oss.sgi.com/archives/linux-xfs/2005-03/msg00189.html cheers, robin From owner-linux-xfs@oss.sgi.com Tue May 31 23:19:00 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 31 May 2005 23:19:04 -0700 (PDT) Received: from quail.cita.utoronto.ca (quail.cita.utoronto.ca [128.100.76.6]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j516J0Xq010776 for ; Tue, 31 May 2005 23:19:00 -0700 Received: from cita.utoronto.ca (lemming.cita.utoronto.ca [128.100.76.53]) by quail.cita.utoronto.ca (8.12.11/8.12.11) with ESMTP id j516I2J7020504; Wed, 1 Jun 2005 02:18:02 -0400 Received: from lemming.cita.utoronto.ca (localhost [127.0.0.1]) by cita.utoronto.ca (8.13.1/8.13.1) with ESMTP id j516I2Yi009851; Wed, 1 Jun 2005 02:18:02 -0400 Received: (from rjh@localhost) by lemming.cita.utoronto.ca (8.13.1/8.13.1/Submit) id j516I2lF009850; Wed, 1 Jun 2005 02:18:02 -0400 Date: Wed, 1 Jun 2005 02:18:02 -0400 From: Robin Humble To: linux-xfs@oss.sgi.com Cc: Wayne Steenburg , sonny@burdell.org Subject: Re: XFS module for RHEL4 Message-ID: <20050601061802.GB7359@lemming.cita.utoronto.ca> References: <1117576633.5018.12.camel@FC3Work> <20050601035347.GB20301@kevlar.burdell.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050601035347.GB20301@kevlar.burdell.org> User-Agent: Mutt/1.4.1i X-archive-position: 5349 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rjh@cita.utoronto.ca Precedence: bulk X-list: linux-xfs Content-Length: 1100 Lines: 27 On Tue, May 31, 2005 at 11:53:47PM -0400, Sonny Rao wrote: >On Tue, May 31, 2005 at 05:57:13PM -0400, Wayne Steenburg wrote: >> How would one go about compiling the XFS modules for the stock RHEL4 >> kernel? Redhat decided not to include it for whatever reason. this is almost a FAQ. >You need to get the kernel source RPM and use the rpmbuild command to >setup the kernel tree appropriately.. I believe the command is >"rpmbuild -bp" for "prep" which means untar and apply patches in if you want 8k stacks as well (highly recommended for servers) then unfortunately it's not quite that simple. you need to stop some of the RedHat patches being applied, as (for some unknown and possibly insane reason) RedHat removed the 8k stack option entirely... OTOH, I run fc3 at home with the default kernel (4k stacks) and XFS and it's very stable. So for simple workloads and setups 4k stacks are usually fine. Anyway, this post has a (possibly slightly outdated) recipe for compiling a RHEL4 kernel with 8k stacks and XFS: http://oss.sgi.com/archives/linux-xfs/2005-03/msg00189.html cheers, robin