From owner-linux-xfs@oss.sgi.com Mon May 1 02:50:13 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 May 2006 02:50:16 -0700 (PDT) Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k419mBn2007741 for ; Mon, 1 May 2006 02:50:12 -0700 Received: from localhost.localdomain (i-83-67-36-194.freedom2surf.net [83.67.36.194]) by mail.ukfsn.org (Postfix) with ESMTP id 1A858E7077; Mon, 1 May 2006 10:37:16 +0100 (BST) Received: from [10.0.0.90] (helo=[10.0.0.90]) by localhost.localdomain with esmtp (Exim 4.50) id 1FaUvM-0006NO-A8; Mon, 01 May 2006 10:42:36 +0100 Message-ID: <4455D7E7.1040203@dgreaves.com> Date: Mon, 01 May 2006 10:41:59 +0100 From: David Greaves User-Agent: Mail/News 1.5 (X11/20060228) MIME-Version: 1.0 To: Nathan Scott Cc: "'linux-kernel@vger.kernel.org'" , linux-xfs@oss.sgi.com, nickpiggin@yahoo.com.au Subject: Re: Bad page state in process 'nfsd' with xfs References: <4452797F.70700@dgreaves.com> <20060501080427.H1771752@wobbly.melbourne.sgi.com> In-Reply-To: <20060501080427.H1771752@wobbly.melbourne.sgi.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 7701 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: david@dgreaves.com Precedence: bulk X-list: linux-xfs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nathan Scott wrote: > Hi there, > > On Fri, Apr 28, 2006 at 09:22:23PM +0100, David Greaves wrote: > > But, the warning is triggered by the page count (16777216 above), and > that is 0x1000000 -- which is a huge, improbable count; that looks to > me like it could very well be the result of a single bit error too. > > You may have a hardware problem - try running memtest I guess. Thanks guys It's in use a lot so I'll schedule some downtime, blow out the dust and run memtest (though I've done that before and it has been clean). I'll let you know how it goes... David - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEVdfn8LvjTle4P1gRAiHTAKCBakrWQCpHgo8qyfN6ZNryAxi3bQCdFkDn vQe781l5bQvq1a5BG2nF5sk= =jdAy -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Mon May 1 08:29:17 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 May 2006 08:29:19 -0700 (PDT) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.206]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with SMTP id k41FRE3P014076 for ; Mon, 1 May 2006 08:29:15 -0700 Received: (qmail 59252 invoked from network); 1 May 2006 15:21:39 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@70.132.14.41 with login) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 1 May 2006 15:21:39 -0000 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id F3FB651FAC3; Mon, 1 May 2006 08:21:37 -0700 (PDT) Date: Mon, 1 May 2006 08:21:37 -0700 From: Chris Wedgwood To: David Greaves Cc: Nathan Scott , "'linux-kernel@vger.kernel.org'" , linux-xfs@oss.sgi.com, nickpiggin@yahoo.com.au Subject: Re: Bad page state in process 'nfsd' with xfs Message-ID: <20060501152137.GB24771@taniwha.stupidest.org> References: <4452797F.70700@dgreaves.com> <20060501080427.H1771752@wobbly.melbourne.sgi.com> <4455D7E7.1040203@dgreaves.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4455D7E7.1040203@dgreaves.com> X-archive-position: 7703 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: 401 Lines: 13 On Mon, May 01, 2006 at 10:41:59AM +0100, David Greaves wrote: > It's in use a lot so I'll schedule some downtime, blow out the dust > and run memtest (though I've done that before and it has been > clean). memtest doesn't always find bad memory sadly finding bad memory is hard, and sometimes it's exacerbated by complicated factors (heat from drives for example) i wish ecc memory was standard From owner-linux-xfs@oss.sgi.com Mon May 1 18:06:18 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 May 2006 18:06:21 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with SMTP id k4214E4g009518 for ; Mon, 1 May 2006 18:06:16 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA06840 for ; Tue, 2 May 2006 09:47:39 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 4826249AC116; Tue, 2 May 2006 09:47:38 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 907752 - acl Message-Id: <20060501234738.4826249AC116@chook.melbourne.sgi.com> Date: Tue, 2 May 2006 09:47:38 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7704 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: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1074 Lines: 23 Merge simple nftw-vs-symlinks handling fixes, based on suggestions from Andreas. Date: Tue May 2 09:46:43 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: nathans,agruen@suse.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:25861a acl/VERSION - 1.77 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/VERSION.diff?r1=text&tr1=1.77&r2=text&tr2=1.76&f=h acl/doc/CHANGES - 1.86 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/doc/CHANGES.diff?r1=text&tr1=1.86&r2=text&tr2=1.85&f=h acl/debian/changelog - 1.74 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/debian/changelog.diff?r1=text&tr1=1.74&r2=text&tr2=1.73&f=h acl/setfacl/setfacl.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/setfacl/setfacl.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h acl/getfacl/getfacl.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/getfacl/getfacl.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h From owner-linux-xfs@oss.sgi.com Thu May 4 14:23:32 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 May 2006 14:23:39 -0700 (PDT) Received: from orca.ele.uri.edu (orca.ele.uri.edu [131.128.51.63]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k44LLQ54026179 for ; Thu, 4 May 2006 14:23:28 -0700 Received: from [192.168.1.4] (c-71-232-42-50.hsd1.ma.comcast.net [71.232.42.50]) (authenticated bits=0) by orca.ele.uri.edu (8.13.4/8.13.4) with ESMTP id k44LFfHN013440 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 4 May 2006 17:15:41 -0400 Subject: multiple write stream performance From: Ming Zhang Reply-To: mingz@ele.uri.edu To: xfs Content-Type: text/plain Date: Thu, 04 May 2006 17:15:35 -0400 Message-Id: <1146777335.3609.173.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 131.128.51.63 X-archive-position: 7711 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: mingz@ele.uri.edu Precedence: bulk X-list: linux-xfs Content-Length: 1131 Lines: 33 Hi, all I have a 8*300GB DISK RAID0 used to hold temporary large size media files. Usually application will write those ~10GB files to it sequentially. Now I found that if I have one file write to it, I can get like ~260MB/s, but if i have 4 concurrent file write, i can only get aggregated 192MB/s, with 16 concurrent writes, the aggregated throughput becomes ~100MB/s. Anybody know why I got such a bad write performance? I guess it is because of seek back and forth. This shows that spaces are still allocated to file with large chunks. thus lead to the seek when writing different files. but why xfs can not allocate space better? [root@dualxeon bonnie++-1.03a]# xfs_bmap /tmp/t/v8 /tmp/t/v8: 0: [0..49279]: 336480..385759 1: [49280..192127]: 39321664..39464511 2: [192128..229887]: 39485504..39523263 3: [229888..267391]: 39571904..39609407 4: [267392..590207]: 52509888..52832703 5: [590208..620671]: 52847168..52877631 6: [620672..663807]: 91995584..92038719 7: [663808..677503]: 92098112..92111807 8: [677504..691327]: 92130624..92144447 Ming From owner-linux-xfs@oss.sgi.com Thu May 4 16:39:49 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 May 2006 16:39:52 -0700 (PDT) Received: from orca.ele.uri.edu (orca.ele.uri.edu [131.128.51.63]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k44NblD9011558 for ; Thu, 4 May 2006 16:39:49 -0700 Received: from [192.168.1.4] (c-71-232-42-50.hsd1.ma.comcast.net [71.232.42.50]) (authenticated bits=0) by orca.ele.uri.edu (8.13.4/8.13.4) with ESMTP id k44NW7Ie021389 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 4 May 2006 19:32:08 -0400 Subject: Re: multiple write stream performance From: Ming Zhang Reply-To: mingz@ele.uri.edu To: chatz@melbourne.sgi.com Cc: xfs In-Reply-To: <445A8112.7050803@melbourne.sgi.com> References: <1146777335.3609.173.camel@localhost.localdomain> <445A8112.7050803@melbourne.sgi.com> Content-Type: text/plain Date: Thu, 04 May 2006 19:32:01 -0400 Message-Id: <1146785522.3609.186.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 131.128.51.63 X-archive-position: 7712 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: mingz@ele.uri.edu Precedence: bulk X-list: linux-xfs Content-Length: 3270 Lines: 87 On Fri, 2006-05-05 at 08:32 +1000, David Chatterton wrote: > Ming, > > What are the I/O characteristics of the application? Typically I > have seen direct I/O for video data at reasonable sizes, and > smaller buffered I/O for audio data in media apps. In the > worse case they mix buffered and direct to the same file. The > larger the I/O requests the better in terms of reducing > fragmentation. I feel that I here want the fragmentation. I will have 10-20 large size (~10GB) multimedia files write at same time to this RAID0. then later a background program will dump them to tape. so i want the concurrent write to be as soon as possible. so if xfs allocate 0 ~ (16MB-512) to file1, 16MB ~ (32MB-51) file2,..., then when write to file 1 to file N concurrently. the disk heads have to move back and forth among these places and thus leave the the poor performance i saw. ps, what u mean DDN, the full name is ___? ming > > Some applications take advantage of the preallocation APIs and > know that they are ingesting X GBs, and preallocate that space. > This may still be fragmented, but in most circumstnaces the > fragmentation is far less than without preallocation. > > Performance degrading with multiple writers is not unexpected > if they are jumping around a lot, and there is limited cache > of the controller etc. That is why for customers with demanding > media workloads we recommend storage like DDN that have very > large caches and can absorb lots of streams. But that costs > a lot more than a jbod! > > Coming soon we will introduce to XFS on linux a new mount option > that will put writers to files in different directories into > different allocation groups. If you only have one writer per > directory, then fragementation in those files can be significantly > better since the writers aren't fighting for space in the same > region of the filesystem. That will help here but I'm not sure > it will solve your problem. > > Thanks, > > David > > > Ming Zhang wrote: > > Hi, all > > > > I have a 8*300GB DISK RAID0 used to hold temporary large size media > > files. Usually application will write those ~10GB files to it > > sequentially. > > > > Now I found that if I have one file write to it, I can get like > > ~260MB/s, but if i have 4 concurrent file write, i can only get > > aggregated 192MB/s, with 16 concurrent writes, the aggregated throughput > > becomes ~100MB/s. > > > > Anybody know why I got such a bad write performance? I guess it is > > because of seek back and forth. > > > > This shows that spaces are still allocated to file with large chunks. > > thus lead to the seek when writing different files. but why xfs can not > > allocate space better? > > > > [root@dualxeon bonnie++-1.03a]# xfs_bmap /tmp/t/v8 > > /tmp/t/v8: > > 0: [0..49279]: 336480..385759 > > 1: [49280..192127]: 39321664..39464511 > > 2: [192128..229887]: 39485504..39523263 > > 3: [229888..267391]: 39571904..39609407 > > 4: [267392..590207]: 52509888..52832703 > > 5: [590208..620671]: 52847168..52877631 > > 6: [620672..663807]: 91995584..92038719 > > 7: [663808..677503]: 92098112..92111807 > > 8: [677504..691327]: 92130624..92144447 > > > > Ming > > > > > From owner-linux-xfs@oss.sgi.com Thu May 4 18:49:09 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 May 2006 18:49:13 -0700 (PDT) Received: from orca.ele.uri.edu (orca.ele.uri.edu [131.128.51.63]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k451l7B4023565 for ; Thu, 4 May 2006 18:49:09 -0700 Received: from [192.168.1.4] (c-71-232-42-50.hsd1.ma.comcast.net [71.232.42.50]) (authenticated bits=0) by orca.ele.uri.edu (8.13.4/8.13.4) with ESMTP id k451fU56023604 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 4 May 2006 21:41:30 -0400 Subject: Re: multiple write stream performance From: Ming Zhang Reply-To: mingz@ele.uri.edu To: chatz@melbourne.sgi.com Cc: xfs In-Reply-To: <1146785522.3609.186.camel@localhost.localdomain> References: <1146777335.3609.173.camel@localhost.localdomain> <445A8112.7050803@melbourne.sgi.com> <1146785522.3609.186.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 04 May 2006 21:38:09 -0400 Message-Id: <1146793089.3609.223.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 131.128.51.63 X-archive-position: 7713 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: mingz@ele.uri.edu Precedence: bulk X-list: linux-xfs Content-Length: 3700 Lines: 100 Hi David Or we put fragmentation issue aside first. How could I allow multiple write streams to come in concurrently and get full speed potential by avoiding seek as much as possible? Thanks! Ming On Thu, 2006-05-04 at 19:32 -0400, Ming Zhang wrote: > On Fri, 2006-05-05 at 08:32 +1000, David Chatterton wrote: > > Ming, > > > > What are the I/O characteristics of the application? Typically I > > have seen direct I/O for video data at reasonable sizes, and > > smaller buffered I/O for audio data in media apps. In the > > worse case they mix buffered and direct to the same file. The > > larger the I/O requests the better in terms of reducing > > fragmentation. > > I feel that I here want the fragmentation. I will have 10-20 large size > (~10GB) multimedia files write at same time to this RAID0. then later a > background program will dump them to tape. so i want the concurrent > write to be as soon as possible. > > so if xfs allocate 0 ~ (16MB-512) to file1, 16MB ~ (32MB-51) file2,..., > then when write to file 1 to file N concurrently. the disk heads have to > move back and forth among these places and thus leave the the poor > performance i saw. > > ps, what u mean DDN, the full name is ___? > > ming > > > > > > Some applications take advantage of the preallocation APIs and > > know that they are ingesting X GBs, and preallocate that space. > > This may still be fragmented, but in most circumstnaces the > > fragmentation is far less than without preallocation. > > > > Performance degrading with multiple writers is not unexpected > > if they are jumping around a lot, and there is limited cache > > of the controller etc. That is why for customers with demanding > > media workloads we recommend storage like DDN that have very > > large caches and can absorb lots of streams. But that costs > > a lot more than a jbod! > > > > Coming soon we will introduce to XFS on linux a new mount option > > that will put writers to files in different directories into > > different allocation groups. If you only have one writer per > > directory, then fragementation in those files can be significantly > > better since the writers aren't fighting for space in the same > > region of the filesystem. That will help here but I'm not sure > > it will solve your problem. > > > > Thanks, > > > > David > > > > > > Ming Zhang wrote: > > > Hi, all > > > > > > I have a 8*300GB DISK RAID0 used to hold temporary large size media > > > files. Usually application will write those ~10GB files to it > > > sequentially. > > > > > > Now I found that if I have one file write to it, I can get like > > > ~260MB/s, but if i have 4 concurrent file write, i can only get > > > aggregated 192MB/s, with 16 concurrent writes, the aggregated throughput > > > becomes ~100MB/s. > > > > > > Anybody know why I got such a bad write performance? I guess it is > > > because of seek back and forth. > > > > > > This shows that spaces are still allocated to file with large chunks. > > > thus lead to the seek when writing different files. but why xfs can not > > > allocate space better? > > > > > > [root@dualxeon bonnie++-1.03a]# xfs_bmap /tmp/t/v8 > > > /tmp/t/v8: > > > 0: [0..49279]: 336480..385759 > > > 1: [49280..192127]: 39321664..39464511 > > > 2: [192128..229887]: 39485504..39523263 > > > 3: [229888..267391]: 39571904..39609407 > > > 4: [267392..590207]: 52509888..52832703 > > > 5: [590208..620671]: 52847168..52877631 > > > 6: [620672..663807]: 91995584..92038719 > > > 7: [663808..677503]: 92098112..92111807 > > > 8: [677504..691327]: 92130624..92144447 > > > > > > Ming > > > > > > > > > From owner-linux-xfs@oss.sgi.com Thu May 4 19:11:21 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 May 2006 19:11:23 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1.americas.sgi.com [198.149.16.13]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k4529ZDf026100 for ; Thu, 4 May 2006 19:11:21 -0700 Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k44MZAnx007500 for ; Thu, 4 May 2006 17:35:10 -0500 Received: from outhouse.melbourne.sgi.com (outhouse.melbourne.sgi.com [134.14.52.145]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k44MX58s3059014; Thu, 4 May 2006 15:33:08 -0700 (PDT) Received: from [134.14.52.212] (shiva212.melbourne.sgi.com [134.14.52.212]) by outhouse.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k44MX0rV1980866; Fri, 5 May 2006 08:33:01 +1000 (AEST) Message-ID: <445A8112.7050803@melbourne.sgi.com> Date: Fri, 05 May 2006 08:32:50 +1000 From: David Chatterton Reply-To: chatz@melbourne.sgi.com Organization: SGI User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mingz@ele.uri.edu CC: xfs Subject: Re: multiple write stream performance References: <1146777335.3609.173.camel@localhost.localdomain> In-Reply-To: <1146777335.3609.173.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7714 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: chatz@melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2542 Lines: 69 Ming, What are the I/O characteristics of the application? Typically I have seen direct I/O for video data at reasonable sizes, and smaller buffered I/O for audio data in media apps. In the worse case they mix buffered and direct to the same file. The larger the I/O requests the better in terms of reducing fragmentation. Some applications take advantage of the preallocation APIs and know that they are ingesting X GBs, and preallocate that space. This may still be fragmented, but in most circumstnaces the fragmentation is far less than without preallocation. Performance degrading with multiple writers is not unexpected if they are jumping around a lot, and there is limited cache of the controller etc. That is why for customers with demanding media workloads we recommend storage like DDN that have very large caches and can absorb lots of streams. But that costs a lot more than a jbod! Coming soon we will introduce to XFS on linux a new mount option that will put writers to files in different directories into different allocation groups. If you only have one writer per directory, then fragementation in those files can be significantly better since the writers aren't fighting for space in the same region of the filesystem. That will help here but I'm not sure it will solve your problem. Thanks, David Ming Zhang wrote: > Hi, all > > I have a 8*300GB DISK RAID0 used to hold temporary large size media > files. Usually application will write those ~10GB files to it > sequentially. > > Now I found that if I have one file write to it, I can get like > ~260MB/s, but if i have 4 concurrent file write, i can only get > aggregated 192MB/s, with 16 concurrent writes, the aggregated throughput > becomes ~100MB/s. > > Anybody know why I got such a bad write performance? I guess it is > because of seek back and forth. > > This shows that spaces are still allocated to file with large chunks. > thus lead to the seek when writing different files. but why xfs can not > allocate space better? > > [root@dualxeon bonnie++-1.03a]# xfs_bmap /tmp/t/v8 > /tmp/t/v8: > 0: [0..49279]: 336480..385759 > 1: [49280..192127]: 39321664..39464511 > 2: [192128..229887]: 39485504..39523263 > 3: [229888..267391]: 39571904..39609407 > 4: [267392..590207]: 52509888..52832703 > 5: [590208..620671]: 52847168..52877631 > 6: [620672..663807]: 91995584..92038719 > 7: [663808..677503]: 92098112..92111807 > 8: [677504..691327]: 92130624..92144447 > > Ming > > From owner-linux-xfs@oss.sgi.com Fri May 5 11:12:24 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 05 May 2006 11:12:27 -0700 (PDT) Received: from orca.ele.uri.edu (orca.ele.uri.edu [131.128.51.63]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k45IAL1a020263 for ; Fri, 5 May 2006 11:12:23 -0700 Received: from [192.168.1.4] (c-71-232-42-50.hsd1.ma.comcast.net [71.232.42.50]) (authenticated bits=0) by orca.ele.uri.edu (8.13.4/8.13.4) with ESMTP id k45I4ivD024265 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 5 May 2006 14:04:45 -0400 Subject: how to get the metadata From: Ming Zhang Reply-To: mingz@ele.uri.edu To: xfs Content-Type: text/plain Date: Fri, 05 May 2006 14:04:39 -0400 Message-Id: <1146852279.3609.300.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 131.128.51.63 X-archive-position: 7717 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: mingz@ele.uri.edu Precedence: bulk X-list: linux-xfs Content-Length: 622 Lines: 20 Hi When mkfs.xfs, we can get this information. But how can i get this with a existing xfs? Thanks! meta-data=/dev/vg1/v1 isize=256 agcount=3, agsize=131072000 blks = sectsz=512 data = bsize=4096 blocks=393216000, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 Ming From owner-linux-xfs@oss.sgi.com Fri May 5 11:15:56 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 05 May 2006 11:16:00 -0700 (PDT) Received: from service.eng.exegy.net (68-191-203-42.static.stls.mo.charter.com [68.191.203.42]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k45IDsiS020747 for ; Fri, 5 May 2006 11:15:56 -0700 Received: from HANAFORD.eng.exegy.net (hanaford.eng.exegy.net [10.19.1.4]) by service.eng.exegy.net (8.13.1/8.13.1) with ESMTP id k45I8Fxo015193 for ; Fri, 5 May 2006 13:08:15 -0500 Received: from [10.19.4.98] ([10.19.4.98]) by HANAFORD.eng.exegy.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 May 2006 13:08:15 -0500 Message-ID: <445B948F.7050203@exegy.com> Date: Fri, 05 May 2006 13:08:15 -0500 From: Dave Lloyd User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: xfs Subject: Re: how to get the metadata References: <1146852279.3609.300.camel@localhost.localdomain> In-Reply-To: <1146852279.3609.300.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 May 2006 18:08:15.0710 (UTC) FILETIME=[E168E7E0:01C6706E] X-archive-position: 7718 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: dlloyd@exegy.com Precedence: bulk X-list: linux-xfs Content-Length: 779 Lines: 32 Ming Zhang wrote: > Hi > > When mkfs.xfs, we can get this information. But how can i get this with > a existing xfs? Thanks! > > meta-data=/dev/vg1/v1 isize=256 agcount=3, > agsize=131072000 blks > = sectsz=512 > data = bsize=4096 blocks=393216000, > imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=1 > naming =version 2 bsize=4096 > log =internal bsize=4096 blocks=32768, version=1 > = sectsz=512 sunit=0 blks > realtime =none extsz=65536 blocks=0, rtextents=0 > > > Ming > > > > Try xfs_growfs -n -- Dave Lloyd Test Engineer, Exegy, Inc. 314.450.5342 dlloyd@exegy.com From owner-linux-xfs@oss.sgi.com Fri May 5 12:44:11 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 05 May 2006 12:45:13 -0700 (PDT) Received: from orca.ele.uri.edu (orca.ele.uri.edu [131.128.51.63]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k45JgApZ003074 for ; Fri, 5 May 2006 12:44:11 -0700 Received: from [192.168.1.4] (c-71-232-42-50.hsd1.ma.comcast.net [71.232.42.50]) (authenticated bits=0) by orca.ele.uri.edu (8.13.4/8.13.4) with ESMTP id k45JaOCb020482 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 5 May 2006 15:36:25 -0400 Subject: Re: how to get the metadata From: Ming Zhang Reply-To: mingz@ele.uri.edu To: Dave Lloyd Cc: xfs In-Reply-To: <445B948F.7050203@exegy.com> References: <1146852279.3609.300.camel@localhost.localdomain> <445B948F.7050203@exegy.com> Content-Type: text/plain Date: Fri, 05 May 2006 15:36:19 -0400 Message-Id: <1146857779.3609.306.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 131.128.51.63 X-archive-position: 7719 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: mingz@ele.uri.edu Precedence: bulk X-list: linux-xfs Content-Length: 1033 Lines: 37 o, yes. u are right. thx! -n Specifies that no change to the filesystem is to be made. The filesystem geometry is printed, and argument checking is performed, but no growth occurs. ming On Fri, 2006-05-05 at 13:08 -0500, Dave Lloyd wrote: > Ming Zhang wrote: > > Hi > > > > When mkfs.xfs, we can get this information. But how can i get this with > > a existing xfs? Thanks! > > > > meta-data=/dev/vg1/v1 isize=256 agcount=3, > > agsize=131072000 blks > > = sectsz=512 > > data = bsize=4096 blocks=393216000, > > imaxpct=25 > > = sunit=0 swidth=0 blks, unwritten=1 > > naming =version 2 bsize=4096 > > log =internal bsize=4096 blocks=32768, version=1 > > = sectsz=512 sunit=0 blks > > realtime =none extsz=65536 blocks=0, rtextents=0 > > > > > > Ming > > > > > > > > > > Try xfs_growfs -n > From owner-linux-xfs@oss.sgi.com Mon May 8 04:20:17 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 08 May 2006 04:20:21 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with SMTP id k48BICUm013943 for ; Mon, 8 May 2006 04:20:16 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA06042; Mon, 8 May 2006 21:12:27 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 78E234A588CB; Mon, 8 May 2006 21:12:25 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 952681 - fix agfl refcount leak Message-Id: <20060508111225.78E234A588CB@chook.melbourne.sgi.com> Date: Mon, 8 May 2006 21:12:25 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7720 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: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 483 Lines: 14 Fix a possible metadata buffer (AGFL) refcount leak when fixing an AG freelist. Date: Mon May 8 21:11:41 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: tes@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:25902a xfs_alloc.c - 1.179 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_alloc.c.diff?r1=text&tr1=1.179&r2=text&tr2=1.178&f=h From owner-linux-xfs@oss.sgi.com Thu May 11 23:15:29 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 May 2006 23:15:38 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with SMTP id k4C6DP6I009347 for ; Thu, 11 May 2006 23:15:27 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA00076; Fri, 12 May 2006 16:07:42 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 83F484A588E2; Fri, 12 May 2006 16:07:35 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 952736 - fix noatime for mmap Message-Id: <20060512060735.83F484A588E2@chook.melbourne.sgi.com> Date: Fri, 12 May 2006 16:07:35 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7724 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: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 651 Lines: 16 Fix a noatime regression related to updating inode atime field on mmap only. Date: Fri May 12 16:07:18 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: sjv@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:25922a linux-2.6/xfs_file.c - 1.134 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_file.c.diff?r1=text&tr1=1.134&r2=text&tr2=1.133&f=h linux-2.4/xfs_file.c - 1.124 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_file.c.diff?r1=text&tr1=1.124&r2=text&tr2=1.123&f=h From owner-linux-xfs@oss.sgi.com Fri May 12 14:07:27 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 12 May 2006 14:07:30 -0700 (PDT) Received: from g0.machinephasesystems.com (dsl092-191-029.sfo1.dsl.speakeasy.net [66.92.191.29]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k4CL5NjH012609 for ; Fri, 12 May 2006 14:07:25 -0700 Received: from [192.168.1.67] (g.machinephasesystems.com [66.92.191.28]) by g0.machinephasesystems.com (8.13.6/8.13.6) with ESMTP id k4CJVO48011425 for ; Fri, 12 May 2006 12:31:24 -0700 Message-ID: <4464E3B5.8020602@wink.com> Date: Fri, 12 May 2006 12:36:21 -0700 From: Peter Broadwell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: deep chmod|chown -R begin to start OOMkiller Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7725 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@wink.com Precedence: bulk X-list: linux-xfs Content-Length: 19221 Lines: 229 I seem to be having the same problem as CHIKAMA Masaki was having in December 7, 2005, namely "chown -R" running very slowly when hitting lots of files (~17 million in my case). My machine doesn't have the same constraints that David pointed to as at least part of the problem. I have fast disks, and lots of memory (though perhaps still bad logfile sizes) So I thought I'd feed into the discussion a bit, hoping for any other ideas... I'm most interested in anything to (safely) speed this up on a live file system as it has been running for nearly 24 hours so far... not hung or corrupted anything as far as I can tell. Following is possibly interesting info from uname, /proc/meminfo, /proc/slabinfo, ... (I don't have OOMkiller though): Thanks - ;;peter = = = = (start of info) = = = = peter@cl1 /data $ uname -sr Linux 2.6.14-gentoo-r2 peter@cl1 /data $ cat /proc/meminfo MemTotal: 8058120 kB MemFree: 2770704 kB Buffers: 12 kB Cached: 3412304 kB SwapCached: 6860 kB Active: 2914928 kB Inactive: 1673712 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 8058120 kB LowFree: 2770704 kB SwapTotal: 32129968 kB SwapFree: 32114220 kB Dirty: 16 kB Writeback: 0 kB Mapped: 1191804 kB Slab: 666680 kB CommitLimit: 36159028 kB Committed_AS: 1313628 kB PageTables: 4564 kB VmallocTotal: 34359738367 kB VmallocUsed: 24420 kB VmallocChunk: 34359713687 kB HugePages_Total: 0 HugePages_Free: 0 Hugepagesize: 2048 kB peter@cl1 /data $ cat /proc/slabinfo slabinfo - version: 2.1 # name : tunables : slabdata rpc_buffers 8 8 2048 2 1 : tunables 24 12 8 : slabdata 4 4 0 rpc_tasks 8 10 384 10 1 : tunables 54 27 8 : slabdata 1 1 0 rpc_inode_cache 8 12 832 4 1 : tunables 54 27 8 : slabdata 3 3 0 fib6_nodes 7 118 64 59 1 : tunables 120 60 8 : slabdata 2 2 0 ip6_dst_cache 7 24 320 12 1 : tunables 54 27 8 : slabdata 2 2 0 ndisc_cache 1 15 256 15 1 : tunables 120 60 8 : slabdata 1 1 0 RAWv6 4 4 896 4 1 : tunables 54 27 8 : slabdata 1 1 0 UDPv6 1 4 896 4 1 : tunables 54 27 8 : slabdata 1 1 0 tw_sock_TCPv6 0 0 192 20 1 : tunables 120 60 8 : slabdata 0 0 0 request_sock_TCPv6 0 0 128 30 1 : tunables 120 60 8 : slabdata 0 0 0 TCPv6 6 10 1536 5 2 : tunables 24 12 8 : slabdata 2 2 0 UNIX 41 54 640 6 1 : tunables 54 27 8 : slabdata 9 9 0 tcp_bind_bucket 34 448 32 112 1 : tunables 120 60 8 : slabdata 4 4 0 inet_peer_cache 0 0 64 59 1 : tunables 120 60 8 : slabdata 0 0 0 ip_fib_alias 14 118 64 59 1 : tunables 120 60 8 : slabdata 2 2 0 ip_fib_hash 14 118 64 59 1 : tunables 120 60 8 : slabdata 2 2 0 ip_dst_cache 36 48 320 12 1 : tunables 54 27 8 : slabdata 4 4 0 arp_cache 8 30 256 15 1 : tunables 120 60 8 : slabdata 2 2 0 RAW 3 11 704 11 2 : tunables 54 27 8 : slabdata 1 1 0 UDP 16 20 768 5 1 : tunables 54 27 8 : slabdata 4 4 0 tw_sock_TCP 23 40 192 20 1 : tunables 120 60 8 : slabdata 2 2 0 request_sock_TCP 8 30 128 30 1 : tunables 120 60 8 : slabdata 1 1 0 TCP 15 25 1408 5 2 : tunables 24 12 8 : slabdata 5 5 0 uhci_urb_priv 0 0 88 44 1 : tunables 120 60 8 : slabdata 0 0 0 scsi_cmd_cache 29 35 512 7 1 : tunables 54 27 8 : slabdata 5 5 0 cfq_ioc_pool 0 0 96 40 1 : tunables 120 60 8 : slabdata 0 0 0 cfq_pool 0 0 160 24 1 : tunables 120 60 8 : slabdata 0 0 0 crq_pool 0 0 88 44 1 : tunables 120 60 8 : slabdata 0 0 0 deadline_drq 607 760 96 40 1 : tunables 120 60 8 : slabdata 18 19 480 as_arq 0 0 112 34 1 : tunables 120 60 8 : slabdata 0 0 0 mqueue_inode_cache 1 4 896 4 1 : tunables 54 27 8 : slabdata 1 1 0 xfs_chashlist 205900 385952 32 112 1 : tunables 120 60 8 : slabdata 3446 3446 0 xfs_ili 273754 273760 192 20 1 : tunables 120 60 8 : slabdata 13688 13688 0 xfs_ifork 0 0 64 59 1 : tunables 120 60 8 : slabdata 0 0 0 xfs_efi_item 0 0 352 11 1 : tunables 54 27 8 : slabdata 0 0 0 xfs_efd_item 0 0 360 11 1 : tunables 54 27 8 : slabdata 0 0 0 xfs_buf_item 1 21 184 21 1 : tunables 120 60 8 : slabdata 1 1 0 xfs_dabuf 45 288 24 144 1 : tunables 120 60 8 : slabdata 2 2 0 xfs_da_state 0 0 488 8 1 : tunables 54 27 8 : slabdata 0 0 0 xfs_trans 186 351 872 9 2 : tunables 54 27 8 : slabdata 32 39 81 xfs_inode 275317 275317 528 7 1 : tunables 54 27 8 : slabdata 39331 39331 0 xfs_btree_cur 0 0 192 20 1 : tunables 120 60 8 : slabdata 0 0 0 xfs_bmap_free_item 0 0 24 144 1 : tunables 120 60 8 : slabdata 0 0 0 xfs_buf 288 414 408 9 1 : tunables 54 27 8 : slabdata 45 46 216 xfs_ioend 32 54 144 27 1 : tunables 120 60 8 : slabdata 2 2 0 xfs_vnode 275316 275316 632 6 1 : tunables 54 27 8 : slabdata 45886 45886 0 ntfs_big_inode_cache 0 0 896 4 1 : tunables 54 27 8 : slabdata 0 0 0 ntfs_inode_cache 0 0 272 14 1 : tunables 54 27 8 : slabdata 0 0 0 ntfs_name_cache 0 0 512 8 1 : tunables 54 27 8 : slabdata 0 0 0 ntfs_attr_ctx_cache 0 0 64 59 1 : tunables 120 60 8 : slabdata 0 0 0 ntfs_index_ctx_cache 0 0 128 30 1 : tunables 120 60 8 : slabdata 0 0 0 nfs_write_data 36 36 832 9 2 : tunables 54 27 8 : slabdata 4 4 0 nfs_read_data 32 35 768 5 1 : tunables 54 27 8 : slabdata 7 7 0 nfs_inode_cache 1 4 912 4 1 : tunables 54 27 8 : slabdata 1 1 0 nfs_page 0 0 128 30 1 : tunables 120 60 8 : slabdata 0 0 0 isofs_inode_cache 0 0 632 6 1 : tunables 54 27 8 : slabdata 0 0 0 fat_inode_cache 0 0 664 6 1 : tunables 54 27 8 : slabdata 0 0 0 fat_cache 0 0 32 112 1 : tunables 120 60 8 : slabdata 0 0 0 hugetlbfs_inode_cache 1 6 600 6 1 : tunables 54 27 8 : slabdata 1 1 0 ext2_inode_cache 0 0 744 5 1 : tunables 54 27 8 : slabdata 0 0 0 ext2_xattr 0 0 88 44 1 : tunables 120 60 8 : slabdata 0 0 0 journal_handle 0 0 24 144 1 : tunables 120 60 8 : slabdata 0 0 0 journal_head 0 0 96 40 1 : tunables 120 60 8 : slabdata 0 0 0 revoke_table 0 0 16 202 1 : tunables 120 60 8 : slabdata 0 0 0 revoke_record 0 0 32 112 1 : tunables 120 60 8 : slabdata 0 0 0 ext3_inode_cache 0 0 792 5 1 : tunables 54 27 8 : slabdata 0 0 0 ext3_xattr 0 0 88 44 1 : tunables 120 60 8 : slabdata 0 0 0 reiser_inode_cache 0 0 704 5 1 : tunables 54 27 8 : slabdata 0 0 0 dnotify_cache 0 0 40 92 1 : tunables 120 60 8 : slabdata 0 0 0 eventpoll_pwq 0 0 72 53 1 : tunables 120 60 8 : slabdata 0 0 0 eventpoll_epi 0 0 192 20 1 : tunables 120 60 8 : slabdata 0 0 0 inotify_event_cache 0 0 40 92 1 : tunables 120 60 8 : slabdata 0 0 0 inotify_watch_cache 1 59 64 59 1 : tunables 120 60 8 : slabdata 1 1 0 kioctx 0 0 320 12 1 : tunables 54 27 8 : slabdata 0 0 0 kiocb 0 0 256 15 1 : tunables 120 60 8 : slabdata 0 0 0 fasync_cache 0 0 24 144 1 : tunables 120 60 8 : slabdata 0 0 0 shmem_inode_cache 840 850 792 5 1 : tunables 54 27 8 : slabdata 170 170 0 posix_timers_cache 0 0 168 23 1 : tunables 120 60 8 : slabdata 0 0 0 uid_cache 9 118 64 59 1 : tunables 120 60 8 : slabdata 2 2 0 sgpool-128 32 32 4096 1 1 : tunables 24 12 8 : slabdata 32 32 0 sgpool-64 32 32 2048 2 1 : tunables 24 12 8 : slabdata 16 16 0 sgpool-32 32 32 1024 4 1 : tunables 54 27 8 : slabdata 8 8 0 sgpool-16 45 48 512 8 1 : tunables 54 27 8 : slabdata 6 6 0 sgpool-8 52 60 256 15 1 : tunables 120 60 8 : slabdata 4 4 0 blkdev_ioc 114 201 56 67 1 : tunables 120 60 8 : slabdata 3 3 0 blkdev_queue 31 44 712 11 2 : tunables 54 27 8 : slabdata 4 4 0 blkdev_requests 311 630 264 15 1 : tunables 54 27 8 : slabdata 40 42 216 biovec-(256) 256 256 4096 1 1 : tunables 24 12 8 : slabdata 256 256 0 biovec-128 256 256 2048 2 1 : tunables 24 12 8 : slabdata 128 128 0 biovec-64 256 256 1024 4 1 : tunables 54 27 8 : slabdata 64 64 0 biovec-16 285 285 256 15 1 : tunables 120 60 8 : slabdata 19 19 0 biovec-4 864 1652 64 59 1 : tunables 120 60 8 : slabdata 27 28 480 biovec-1 482 1616 16 202 1 : tunables 120 60 8 : slabdata 8 8 108 bio 860 1500 128 30 1 : tunables 120 60 8 : slabdata 50 50 480 file_lock_cache 6 24 160 24 1 : tunables 120 60 8 : slabdata 1 1 0 sock_inode_cache 93 130 704 5 1 : tunables 54 27 8 : slabdata 26 26 0 skbuff_fclone_cache 20 32 448 8 1 : tunables 54 27 8 : slabdata 3 4 0 skbuff_head_cache 555 1035 256 15 1 : tunables 120 60 8 : slabdata 69 69 0 acpi_operand 1127 1166 72 53 1 : tunables 120 60 8 : slabdata 22 22 0 acpi_parse_ext 0 0 64 59 1 : tunables 120 60 8 : slabdata 0 0 0 acpi_parse 0 0 40 92 1 : tunables 120 60 8 : slabdata 0 0 0 acpi_state 0 0 88 44 1 : tunables 120 60 8 : slabdata 0 0 0 proc_inode_cache 667 690 616 6 1 : tunables 54 27 8 : slabdata 115 115 0 sigqueue 32 46 168 23 1 : tunables 120 60 8 : slabdata 2 2 0 radix_tree_node 232625 303359 536 7 1 : tunables 54 27 8 : slabdata 43337 43337 0 bdev_cache 22 28 832 4 1 : tunables 54 27 8 : slabdata 7 7 0 sysfs_dir_cache 2946 3021 72 53 1 : tunables 120 60 8 : slabdata 57 57 0 mnt_cache 26 60 192 20 1 : tunables 120 60 8 : slabdata 3 3 0 inode_cache 1080 1085 584 7 1 : tunables 54 27 8 : slabdata 155 155 0 dentry_cache 252909 252909 224 17 1 : tunables 120 60 8 : slabdata 14877 14877 0 filp 883 1365 256 15 1 : tunables 120 60 8 : slabdata 91 91 0 names_cache 3 5 4096 1 1 : tunables 24 12 8 : slabdata 3 5 0 idr_layer_cache 77 84 528 7 1 : tunables 54 27 8 : slabdata 12 12 0 buffer_head 52111 139612 88 44 1 : tunables 120 60 8 : slabdata 3173 3173 0 mm_struct 67 77 1152 7 2 : tunables 24 12 8 : slabdata 11 11 0 vm_area_struct 2672 2814 184 21 1 : tunables 120 60 8 : slabdata 134 134 0 fs_cache 76 118 64 59 1 : tunables 120 60 8 : slabdata 2 2 0 files_cache 66 72 896 4 1 : tunables 54 27 8 : slabdata 18 18 0 signal_cache 109 120 640 6 1 : tunables 54 27 8 : slabdata 20 20 0 sighand_cache 103 108 2112 3 2 : tunables 24 12 8 : slabdata 36 36 0 task_struct 123 128 1728 4 2 : tunables 24 12 8 : slabdata 32 32 0 anon_vma 987 1440 24 144 1 : tunables 120 60 8 : slabdata 10 10 0 shared_policy_node 0 0 56 67 1 : tunables 120 60 8 : slabdata 0 0 0 numa_policy 39 404 16 202 1 : tunables 120 60 8 : slabdata 2 2 0 size-131072(DMA) 0 0 131072 1 32 : tunables 8 4 0 : slabdata 0 0 0 size-131072 0 0 131072 1 32 : tunables 8 4 0 : slabdata 0 0 0 size-65536(DMA) 0 0 65536 1 16 : tunables 8 4 0 : slabdata 0 0 0 size-65536 2 2 65536 1 16 : tunables 8 4 0 : slabdata 2 2 0 size-32768(DMA) 0 0 32768 1 8 : tunables 8 4 0 : slabdata 0 0 0 size-32768 20 20 32768 1 8 : tunables 8 4 0 : slabdata 20 20 0 size-16384(DMA) 0 0 16384 1 4 : tunables 8 4 0 : slabdata 0 0 0 size-16384 0 0 16384 1 4 : tunables 8 4 0 : slabdata 0 0 0 size-8192(DMA) 0 0 8192 1 2 : tunables 8 4 0 : slabdata 0 0 0 size-8192 17 17 8192 1 2 : tunables 8 4 0 : slabdata 17 17 0 size-4096(DMA) 0 0 4096 1 1 : tunables 24 12 8 : slabdata 0 0 0 size-4096 269 270 4096 1 1 : tunables 24 12 8 : slabdata 269 270 0 size-2048(DMA) 0 0 2048 2 1 : tunables 24 12 8 : slabdata 0 0 0 size-2048 708 736 2048 2 1 : tunables 24 12 8 : slabdata 363 368 0 size-1024(DMA) 0 0 1024 4 1 : tunables 54 27 8 : slabdata 0 0 0 size-1024 350 368 1024 4 1 : tunables 54 27 8 : slabdata 92 92 0 size-512(DMA) 0 0 512 8 1 : tunables 54 27 8 : slabdata 0 0 0 size-512 619 640 512 8 1 : tunables 54 27 8 : slabdata 80 80 0 size-256(DMA) 0 0 256 15 1 : tunables 120 60 8 : slabdata 0 0 0 size-256 82 105 256 15 1 : tunables 120 60 8 : slabdata 7 7 0 size-192(DMA) 0 0 192 20 1 : tunables 120 60 8 : slabdata 0 0 0 size-192 1560 2000 192 20 1 : tunables 120 60 8 : slabdata 100 100 0 size-128(DMA) 0 0 128 30 1 : tunables 120 60 8 : slabdata 0 0 0 size-64(DMA) 0 0 64 59 1 : tunables 120 60 8 : slabdata 0 0 0 size-64 2672 9027 64 59 1 : tunables 120 60 8 : slabdata 153 153 0 size-32(DMA) 0 0 32 112 1 : tunables 120 60 8 : slabdata 0 0 0 size-128 3807 4950 128 30 1 : tunables 120 60 8 : slabdata 165 165 300 size-32 703 784 32 112 1 : tunables 120 60 8 : slabdata 7 7 0 kmem_cache 155 155 704 5 1 : tunables 54 27 8 : slabdata 31 31 0 peter@cl1 /data $ peter@cl1 /data $ df -k Filesystem 1K-blocks Used Available Use% Mounted on /dev/md/0 22479104 13991500 8487604 63% / udev 4029060 244 4028816 1% /dev /dev/md/1 449447808 338816792 110631016 76% /data none 4029060 0 4029060 0% /dev/shm cl4:/data 451279232 112298760 338980472 25% /mnt/cl4-data peter@cl1 /data $ xfs_info /data meta-data=/dev/md1 isize=256 agcount=16, agsize=7024672 blks = sectsz=512 data = bsize=4096 blocks=112394720, imaxpct=25 = sunit=16 swidth=64 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=262144 blocks=0, rtextents=0 peter@cl1 /data $ = = = = (end of info) = = = = From owner-linux-xfs@oss.sgi.com Mon May 15 02:42:46 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 15 May 2006 02:42:49 -0700 (PDT) Received: from mta1.gsf.de (mta1.gsf.de [146.107.3.111]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k4F9ehrv016174 for ; Mon, 15 May 2006 02:42:45 -0700 Received: from [127.0.0.1] (acouchis.gsf.de [146.107.217.183]) by mta1.gsf.de (Postfix) with ESMTP id 19D7A5388C for ; Mon, 15 May 2006 08:57:45 +0200 (CEST) Message-ID: <4468263B.6080609@gsf.de> Date: Mon, 15 May 2006 08:56:59 +0200 From: Yogesh Bhanu Reply-To: yogesh@gsf.de Organization: IBI/MIPS User-Agent: Thunderbird 1.5.0.2 (X11/20060308) MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfs_repair failing Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7731 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: yogesh@gsf.de Precedence: bulk X-list: linux-xfs Content-Length: 1128 Lines: 28 Hi all , My SLES9 xfs file server has runinto some problems, It started with storage acting flaky, though xfs had switched the filesystem inquestion offline. After I have fixed the problem on the storage. I tried running xfs_repair.(Before that I have mounted the file system in question). The system ends up with the following error message. xfs_repair -v -n /dev/vg01/data01 Phase 1 - find and verify superblock... Phase 2 - using internal log - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 imap claims a free inode 292381 is in use, would correct imap and clear inode xfs_repair: read failed: Input/output error cannot read inode 292448, disk block 146224, cnt 32 Any Ideas , to fix the error or should I head for backups. System configuration . SLES 9 with SP3 on AMD Opteron (246) Dual Processor system with 8 GB RAM . Storage is connected (DS4300) by FC and uses LVM to mount 3.5 TB volume. From owner-linux-xfs@oss.sgi.com Mon May 15 03:05:52 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 15 May 2006 03:05:55 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k4FA3piu018511 for ; Mon, 15 May 2006 03:05:52 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 55D4A15EA99; Mon, 15 May 2006 06:03:49 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 52E43100EC460; Mon, 15 May 2006 06:03:49 -0400 (EDT) Date: Mon, 15 May 2006 06:03:49 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34 To: Yogesh Bhanu cc: linux-xfs@oss.sgi.com Subject: Re: xfs_repair failing In-Reply-To: <4468263B.6080609@gsf.de> Message-ID: References: <4468263B.6080609@gsf.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 7732 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: jpiszcz@lucidpixels.com Precedence: bulk X-list: linux-xfs Content-Length: 1301 Lines: 36 Any errors in dmesg/logs? xfs_repair: read failed: Input/output error Looks like a bad disk? On Mon, 15 May 2006, Yogesh Bhanu wrote: > Hi all , > My SLES9 xfs file server has runinto some problems, > It started with storage acting flaky, though xfs had switched the filesystem > inquestion offline. After I have fixed the problem on the storage. I tried > running xfs_repair.(Before that I have mounted the file system in question). > The system ends up with the following error message. > > xfs_repair -v -n /dev/vg01/data01 > Phase 1 - find and verify superblock... > Phase 2 - using internal log > - scan filesystem freespace and inode maps... > - found root inode chunk > Phase 3 - for each AG... > - scan (but don't clear) agi unlinked lists... > - process known inodes and perform inode discovery... > - agno = 0 > imap claims a free inode 292381 is in use, would correct imap and clear inode > xfs_repair: read failed: Input/output error > cannot read inode 292448, disk block 146224, cnt 32 > > Any Ideas , to fix the error or should I head for backups. > > System configuration . SLES 9 with SP3 on AMD Opteron (246) Dual Processor > system with 8 GB RAM . Storage is connected (DS4300) by FC and uses LVM to > mount 3.5 TB volume. > > From owner-linux-xfs@oss.sgi.com Mon May 15 03:15:46 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 15 May 2006 03:15:49 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with SMTP id k4FADhBc019752 for ; Mon, 15 May 2006 03:15:45 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA01575; Mon, 15 May 2006 20:13:35 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id ECFFF4A588D2; Mon, 15 May 2006 20:13:33 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 952342 - fix repair compilation Message-Id: <20060515101333.ECFFF4A588D2@chook.melbourne.sgi.com> Date: Mon, 15 May 2006 20:13:33 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7733 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: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 860 Lines: 19 Fix compilation for xfs_repair after recent optimisations. __inline -> static inline, and remove debug-only copies of some routines. Date: Mon May 15 20:12:57 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:25940a xfsprogs/repair/incore.h - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/incore.h.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h xfsprogs/repair/avl.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/avl.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h xfsprogs/repair/incore_ino.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/incore_ino.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h From owner-linux-xfs@oss.sgi.com Mon May 15 04:02:36 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 15 May 2006 04:02:41 -0700 (PDT) Received: from mail.cohaesio.net (penguin.cohaesio.net [212.97.129.34]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k4FB0X3J024556 for ; Mon, 15 May 2006 04:02:35 -0700 Received: from cohsrv1.cohaesio.com (cohsrv1.cohaesio.com [212.97.128.131]) by mail.cohaesio.net (Postfix) with ESMTP id 30229FB4CD; Mon, 15 May 2006 11:59:35 +0200 (CEST) Received: from homer.cohaesio.com ([212.97.128.136]) by cohsrv1.cohaesio.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 May 2006 11:59:47 +0200 From: Anders Saaby Organization: Cohaesio A/S To: Peter Broadwell Subject: Re: deep chmod|chown -R begin to start OOMkiller Date: Mon, 15 May 2006 11:59:34 +0200 User-Agent: KMail/1.9.1 Cc: linux-xfs@oss.sgi.com References: <4464E3B5.8020602@wink.com> In-Reply-To: <4464E3B5.8020602@wink.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605151159.34802.as@cohaesio.com> X-OriginalArrivalTime: 15 May 2006 09:59:47.0578 (UTC) FILETIME=[4C885DA0:01C67806] X-archive-position: 7734 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: 20283 Lines: 318 Hi, Do you have high CPU usage when running the chown? - Or just processes hanging i D-state? On Friday 12 May 2006 21:36, Peter Broadwell wrote: > I seem to be having the same problem as CHIKAMA Masaki was having in > December 7, 2005, namely "chown -R" running very slowly when hitting lots > of files (~17 million in my case). > > My machine doesn't have the same constraints that David pointed to as at > least part of the problem. > I have fast disks, and lots of memory (though perhaps still bad logfile > sizes) So I thought I'd feed into the discussion a bit, hoping for any > other ideas... > > I'm most interested in anything to (safely) speed this up on a live file > system as it has been running for nearly 24 hours so far... not hung or > corrupted anything as far as I can tell. > > Following is possibly interesting info from uname, /proc/meminfo, > /proc/slabinfo, ... (I don't have OOMkiller though): > > Thanks - > > ;;peter > > = = = = (start of info) = = = = > > peter@cl1 /data $ uname -sr > Linux 2.6.14-gentoo-r2 > peter@cl1 /data $ cat /proc/meminfo > MemTotal: 8058120 kB > MemFree: 2770704 kB > Buffers: 12 kB > Cached: 3412304 kB > SwapCached: 6860 kB > Active: 2914928 kB > Inactive: 1673712 kB > HighTotal: 0 kB > HighFree: 0 kB > LowTotal: 8058120 kB > LowFree: 2770704 kB > SwapTotal: 32129968 kB > SwapFree: 32114220 kB > Dirty: 16 kB > Writeback: 0 kB > Mapped: 1191804 kB > Slab: 666680 kB > CommitLimit: 36159028 kB > Committed_AS: 1313628 kB > PageTables: 4564 kB > VmallocTotal: 34359738367 kB > VmallocUsed: 24420 kB > VmallocChunk: 34359713687 kB > HugePages_Total: 0 > HugePages_Free: 0 > Hugepagesize: 2048 kB > peter@cl1 /data $ cat /proc/slabinfo > slabinfo - version: 2.1 > # name > : tunables : slabdata > > rpc_buffers 8 8 2048 2 1 : tunables 24 12 8 > : slabdata 4 4 0 rpc_tasks 8 10 384 10 > 1 : tunables 54 27 8 : slabdata 1 1 0 > rpc_inode_cache 8 12 832 4 1 : tunables 54 27 8 > : slabdata 3 3 0 fib6_nodes 7 118 64 59 > 1 : tunables 120 60 8 : slabdata 2 2 0 > ip6_dst_cache 7 24 320 12 1 : tunables 54 27 8 > : slabdata 2 2 0 ndisc_cache 1 15 256 15 > 1 : tunables 120 60 8 : slabdata 1 1 0 RAWv6 > 4 4 896 4 1 : tunables 54 27 8 : slabdata > 1 1 0 UDPv6 1 4 896 4 1 : > tunables 54 27 8 : slabdata 1 1 0 tw_sock_TCPv6 > 0 0 192 20 1 : tunables 120 60 8 : slabdata 0 > 0 0 request_sock_TCPv6 0 0 128 30 1 : tunables > 120 60 8 : slabdata 0 0 0 TCPv6 6 > 10 1536 5 2 : tunables 24 12 8 : slabdata 2 2 > 0 UNIX 41 54 640 6 1 : tunables 54 27 > 8 : slabdata 9 9 0 tcp_bind_bucket 34 448 32 > 112 1 : tunables 120 60 8 : slabdata 4 4 0 > inet_peer_cache 0 0 64 59 1 : tunables 120 60 8 > : slabdata 0 0 0 ip_fib_alias 14 118 64 59 > 1 : tunables 120 60 8 : slabdata 2 2 0 ip_fib_hash > 14 118 64 59 1 : tunables 120 60 8 : slabdata > 2 2 0 ip_dst_cache 36 48 320 12 1 : > tunables 54 27 8 : slabdata 4 4 0 arp_cache > 8 30 256 15 1 : tunables 120 60 8 : slabdata 2 > 2 0 RAW 3 11 704 11 2 : tunables 54 > 27 8 : slabdata 1 1 0 UDP 16 20 > 768 5 1 : tunables 54 27 8 : slabdata 4 4 0 > tw_sock_TCP 23 40 192 20 1 : tunables 120 60 8 > : slabdata 2 2 0 request_sock_TCP 8 30 128 30 > 1 : tunables 120 60 8 : slabdata 1 1 0 TCP > 15 25 1408 5 2 : tunables 24 12 8 : slabdata > 5 5 0 uhci_urb_priv 0 0 88 44 1 : > tunables 120 60 8 : slabdata 0 0 0 scsi_cmd_cache > 29 35 512 7 1 : tunables 54 27 8 : slabdata 5 > 5 0 cfq_ioc_pool 0 0 96 40 1 : tunables 120 > 60 8 : slabdata 0 0 0 cfq_pool 0 0 > 160 24 1 : tunables 120 60 8 : slabdata 0 0 0 > crq_pool 0 0 88 44 1 : tunables 120 60 8 > : slabdata 0 0 0 deadline_drq 607 760 96 40 > 1 : tunables 120 60 8 : slabdata 18 19 480 as_arq > 0 0 112 34 1 : tunables 120 60 8 : slabdata > 0 0 0 mqueue_inode_cache 1 4 896 4 1 : > tunables 54 27 8 : slabdata 1 1 0 xfs_chashlist > 205900 385952 32 112 1 : tunables 120 60 8 : slabdata 3446 > 3446 0 xfs_ili 273754 273760 192 20 1 : tunables > 120 60 8 : slabdata 13688 13688 0 xfs_ifork 0 > 0 64 59 1 : tunables 120 60 8 : slabdata 0 0 > 0 xfs_efi_item 0 0 352 11 1 : tunables 54 27 > 8 : slabdata 0 0 0 xfs_efd_item 0 0 360 > 11 1 : tunables 54 27 8 : slabdata 0 0 0 > xfs_buf_item 1 21 184 21 1 : tunables 120 60 8 > : slabdata 1 1 0 xfs_dabuf 45 288 24 144 > 1 : tunables 120 60 8 : slabdata 2 2 0 xfs_da_state > 0 0 488 8 1 : tunables 54 27 8 : slabdata > 0 0 0 xfs_trans 186 351 872 9 2 : > tunables 54 27 8 : slabdata 32 39 81 xfs_inode > 275317 275317 528 7 1 : tunables 54 27 8 : slabdata 39331 > 39331 0 xfs_btree_cur 0 0 192 20 1 : tunables > 120 60 8 : slabdata 0 0 0 xfs_bmap_free_item 0 > 0 24 144 1 : tunables 120 60 8 : slabdata 0 0 > 0 xfs_buf 288 414 408 9 1 : tunables 54 27 > 8 : slabdata 45 46 216 xfs_ioend 32 54 144 > 27 1 : tunables 120 60 8 : slabdata 2 2 0 xfs_vnode > 275316 275316 632 6 1 : tunables 54 27 8 : slabdata > 45886 45886 0 ntfs_big_inode_cache 0 0 896 4 1 : > tunables 54 27 8 : slabdata 0 0 0 ntfs_inode_cache > 0 0 272 14 1 : tunables 54 27 8 : slabdata 0 > 0 0 ntfs_name_cache 0 0 512 8 1 : tunables 54 > 27 8 : slabdata 0 0 0 ntfs_attr_ctx_cache 0 0 > 64 59 1 : tunables 120 60 8 : slabdata 0 0 0 > ntfs_index_ctx_cache 0 0 128 30 1 : tunables 120 60 > 8 : slabdata 0 0 0 nfs_write_data 36 36 832 > 9 2 : tunables 54 27 8 : slabdata 4 4 0 > nfs_read_data 32 35 768 5 1 : tunables 54 27 8 > : slabdata 7 7 0 nfs_inode_cache 1 4 912 4 > 1 : tunables 54 27 8 : slabdata 1 1 0 nfs_page > 0 0 128 30 1 : tunables 120 60 8 : slabdata > 0 0 0 isofs_inode_cache 0 0 632 6 1 : > tunables 54 27 8 : slabdata 0 0 0 fat_inode_cache > 0 0 664 6 1 : tunables 54 27 8 : slabdata 0 > 0 0 fat_cache 0 0 32 112 1 : tunables 120 > 60 8 : slabdata 0 0 0 hugetlbfs_inode_cache 1 > 6 600 6 1 : tunables 54 27 8 : slabdata 1 1 > 0 ext2_inode_cache 0 0 744 5 1 : tunables 54 27 > 8 : slabdata 0 0 0 ext2_xattr 0 0 88 > 44 1 : tunables 120 60 8 : slabdata 0 0 0 > journal_handle 0 0 24 144 1 : tunables 120 60 8 > : slabdata 0 0 0 journal_head 0 0 96 40 > 1 : tunables 120 60 8 : slabdata 0 0 0 revoke_table > 0 0 16 202 1 : tunables 120 60 8 : slabdata > 0 0 0 revoke_record 0 0 32 112 1 : > tunables 120 60 8 : slabdata 0 0 0 ext3_inode_cache > 0 0 792 5 1 : tunables 54 27 8 : slabdata 0 > 0 0 ext3_xattr 0 0 88 44 1 : tunables 120 > 60 8 : slabdata 0 0 0 reiser_inode_cache 0 0 > 704 5 1 : tunables 54 27 8 : slabdata 0 0 0 > dnotify_cache 0 0 40 92 1 : tunables 120 60 8 > : slabdata 0 0 0 eventpoll_pwq 0 0 72 53 > 1 : tunables 120 60 8 : slabdata 0 0 0 > eventpoll_epi 0 0 192 20 1 : tunables 120 60 8 > : slabdata 0 0 0 inotify_event_cache 0 0 40 > 92 1 : tunables 120 60 8 : slabdata 0 0 0 > inotify_watch_cache 1 59 64 59 1 : tunables 120 60 > 8 : slabdata 1 1 0 kioctx 0 0 320 > 12 1 : tunables 54 27 8 : slabdata 0 0 0 kiocb > 0 0 256 15 1 : tunables 120 60 8 : slabdata > 0 0 0 fasync_cache 0 0 24 144 1 : > tunables 120 60 8 : slabdata 0 0 0 shmem_inode_cache > 840 850 792 5 1 : tunables 54 27 8 : slabdata 170 > 170 0 posix_timers_cache 0 0 168 23 1 : tunables > 120 60 8 : slabdata 0 0 0 uid_cache 9 > 118 64 59 1 : tunables 120 60 8 : slabdata 2 2 > 0 sgpool-128 32 32 4096 1 1 : tunables 24 12 > 8 : slabdata 32 32 0 sgpool-64 32 32 2048 > 2 1 : tunables 24 12 8 : slabdata 16 16 0 sgpool-32 > 32 32 1024 4 1 : tunables 54 27 8 : slabdata > 8 8 0 sgpool-16 45 48 512 8 1 : > tunables 54 27 8 : slabdata 6 6 0 sgpool-8 > 52 60 256 15 1 : tunables 120 60 8 : slabdata 4 > 4 0 blkdev_ioc 114 201 56 67 1 : tunables 120 > 60 8 : slabdata 3 3 0 blkdev_queue 31 44 > 712 11 2 : tunables 54 27 8 : slabdata 4 4 0 > blkdev_requests 311 630 264 15 1 : tunables 54 27 8 > : slabdata 40 42 216 biovec-(256) 256 256 4096 1 > 1 : tunables 24 12 8 : slabdata 256 256 0 biovec-128 > 256 256 2048 2 1 : tunables 24 12 8 : slabdata > 128 128 0 biovec-64 256 256 1024 4 1 : > tunables 54 27 8 : slabdata 64 64 0 biovec-16 > 285 285 256 15 1 : tunables 120 60 8 : slabdata 19 > 19 0 biovec-4 864 1652 64 59 1 : tunables 120 > 60 8 : slabdata 27 28 480 biovec-1 482 1616 > 16 202 1 : tunables 120 60 8 : slabdata 8 8 108 > bio 860 1500 128 30 1 : tunables 120 60 8 > : slabdata 50 50 480 file_lock_cache 6 24 160 24 > 1 : tunables 120 60 8 : slabdata 1 1 0 > sock_inode_cache 93 130 704 5 1 : tunables 54 27 8 > : slabdata 26 26 0 skbuff_fclone_cache 20 32 448 > 8 1 : tunables 54 27 8 : slabdata 3 4 0 > skbuff_head_cache 555 1035 256 15 1 : tunables 120 60 8 > : slabdata 69 69 0 acpi_operand 1127 1166 72 53 > 1 : tunables 120 60 8 : slabdata 22 22 0 > acpi_parse_ext 0 0 64 59 1 : tunables 120 60 8 > : slabdata 0 0 0 acpi_parse 0 0 40 92 > 1 : tunables 120 60 8 : slabdata 0 0 0 acpi_state > 0 0 88 44 1 : tunables 120 60 8 : slabdata > 0 0 0 proc_inode_cache 667 690 616 6 1 : > tunables 54 27 8 : slabdata 115 115 0 sigqueue > 32 46 168 23 1 : tunables 120 60 8 : slabdata 2 > 2 0 radix_tree_node 232625 303359 536 7 1 : tunables 54 > 27 8 : slabdata 43337 43337 0 bdev_cache 22 28 > 832 4 1 : tunables 54 27 8 : slabdata 7 7 0 > sysfs_dir_cache 2946 3021 72 53 1 : tunables 120 60 8 > : slabdata 57 57 0 mnt_cache 26 60 192 20 > 1 : tunables 120 60 8 : slabdata 3 3 0 inode_cache > 1080 1085 584 7 1 : tunables 54 27 8 : slabdata > 155 155 0 dentry_cache 252909 252909 224 17 1 : > tunables 120 60 8 : slabdata 14877 14877 0 filp > 883 1365 256 15 1 : tunables 120 60 8 : slabdata 91 > 91 0 names_cache 3 5 4096 1 1 : tunables 24 > 12 8 : slabdata 3 5 0 idr_layer_cache 77 84 > 528 7 1 : tunables 54 27 8 : slabdata 12 12 0 > buffer_head 52111 139612 88 44 1 : tunables 120 60 8 > : slabdata 3173 3173 0 mm_struct 67 77 1152 7 > 2 : tunables 24 12 8 : slabdata 11 11 0 > vm_area_struct 2672 2814 184 21 1 : tunables 120 60 8 > : slabdata 134 134 0 fs_cache 76 118 64 59 > 1 : tunables 120 60 8 : slabdata 2 2 0 files_cache > 66 72 896 4 1 : tunables 54 27 8 : slabdata > 18 18 0 signal_cache 109 120 640 6 1 : > tunables 54 27 8 : slabdata 20 20 0 sighand_cache > 103 108 2112 3 2 : tunables 24 12 8 : slabdata 36 > 36 0 task_struct 123 128 1728 4 2 : tunables 24 > 12 8 : slabdata 32 32 0 anon_vma 987 1440 > 24 144 1 : tunables 120 60 8 : slabdata 10 10 0 > shared_policy_node 0 0 56 67 1 : tunables 120 60 8 > : slabdata 0 0 0 numa_policy 39 404 16 202 > 1 : tunables 120 60 8 : slabdata 2 2 0 > size-131072(DMA) 0 0 131072 1 32 : tunables 8 4 0 > : slabdata 0 0 0 size-131072 0 0 131072 1 > 32 : tunables 8 4 0 : slabdata 0 0 0 > size-65536(DMA) 0 0 65536 1 16 : tunables 8 4 0 > : slabdata 0 0 0 size-65536 2 2 65536 1 > 16 : tunables 8 4 0 : slabdata 2 2 0 > size-32768(DMA) 0 0 32768 1 8 : tunables 8 4 0 > : slabdata 0 0 0 size-32768 20 20 32768 1 > 8 : tunables 8 4 0 : slabdata 20 20 0 > size-16384(DMA) 0 0 16384 1 4 : tunables 8 4 0 > : slabdata 0 0 0 size-16384 0 0 16384 1 > 4 : tunables 8 4 0 : slabdata 0 0 0 > size-8192(DMA) 0 0 8192 1 2 : tunables 8 4 0 > : slabdata 0 0 0 size-8192 17 17 8192 1 > 2 : tunables 8 4 0 : slabdata 17 17 0 > size-4096(DMA) 0 0 4096 1 1 : tunables 24 12 8 > : slabdata 0 0 0 size-4096 269 270 4096 1 > 1 : tunables 24 12 8 : slabdata 269 270 0 > size-2048(DMA) 0 0 2048 2 1 : tunables 24 12 8 > : slabdata 0 0 0 size-2048 708 736 2048 2 > 1 : tunables 24 12 8 : slabdata 363 368 0 > size-1024(DMA) 0 0 1024 4 1 : tunables 54 27 8 > : slabdata 0 0 0 size-1024 350 368 1024 4 > 1 : tunables 54 27 8 : slabdata 92 92 0 > size-512(DMA) 0 0 512 8 1 : tunables 54 27 8 > : slabdata 0 0 0 size-512 619 640 512 8 > 1 : tunables 54 27 8 : slabdata 80 80 0 > size-256(DMA) 0 0 256 15 1 : tunables 120 60 8 > : slabdata 0 0 0 size-256 82 105 256 15 > 1 : tunables 120 60 8 : slabdata 7 7 0 > size-192(DMA) 0 0 192 20 1 : tunables 120 60 8 > : slabdata 0 0 0 size-192 1560 2000 192 20 > 1 : tunables 120 60 8 : slabdata 100 100 0 > size-128(DMA) 0 0 128 30 1 : tunables 120 60 8 > : slabdata 0 0 0 size-64(DMA) 0 0 64 59 > 1 : tunables 120 60 8 : slabdata 0 0 0 size-64 > 2672 9027 64 59 1 : tunables 120 60 8 : slabdata > 153 153 0 size-32(DMA) 0 0 32 112 1 : > tunables 120 60 8 : slabdata 0 0 0 size-128 > 3807 4950 128 30 1 : tunables 120 60 8 : slabdata 165 > 165 300 size-32 703 784 32 112 1 : tunables 120 > 60 8 : slabdata 7 7 0 kmem_cache 155 155 > 704 5 1 : tunables 54 27 8 : slabdata 31 31 0 > peter@cl1 /data $ > > peter@cl1 /data $ df -k > Filesystem 1K-blocks Used Available Use% Mounted on > /dev/md/0 22479104 13991500 8487604 63% / > udev 4029060 244 4028816 1% /dev > /dev/md/1 449447808 338816792 110631016 76% /data > none 4029060 0 4029060 0% /dev/shm > cl4:/data 451279232 112298760 338980472 25% /mnt/cl4-data > peter@cl1 /data $ xfs_info /data > meta-data=/dev/md1 isize=256 agcount=16, agsize=7024672 > blks = sectsz=512 > data = bsize=4096 blocks=112394720, imaxpct=25 > = sunit=16 swidth=64 blks, unwritten=1 > naming =version 2 bsize=4096 > log =internal bsize=4096 blocks=32768, version=1 > = sectsz=512 sunit=0 blks > realtime =none extsz=262144 blocks=0, rtextents=0 > peter@cl1 /data $ > > = = = = (end of info) = = = = -- 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 Mon May 15 04:18:15 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 15 May 2006 04:18:19 -0700 (PDT) Received: from mail.cohaesio.net (penguin.cohaesio.net [212.97.129.34]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k4FBGEne026951 for ; Mon, 15 May 2006 04:18:15 -0700 Received: from cohsrv1.cohaesio.com (cohsrv1.cohaesio.com [212.97.128.131]) by mail.cohaesio.net (Postfix) with ESMTP id 2F3ABFB55C; Mon, 15 May 2006 11:54:20 +0200 (CEST) Received: from homer.cohaesio.com ([212.97.128.136]) by cohsrv1.cohaesio.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 May 2006 11:54:32 +0200 From: Anders Saaby Organization: Cohaesio A/S To: yogesh@gsf.de Subject: Re: xfs_repair failing Date: Mon, 15 May 2006 11:54:19 +0200 User-Agent: KMail/1.9.1 Cc: linux-xfs@oss.sgi.com References: <4468263B.6080609@gsf.de> In-Reply-To: <4468263B.6080609@gsf.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605151154.19782.as@cohaesio.com> X-OriginalArrivalTime: 15 May 2006 09:54:32.0531 (UTC) FILETIME=[90C00230:01C67805] X-archive-position: 7735 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: 491 Lines: 18 Hi, On Monday 15 May 2006 08:56, Yogesh Bhanu wrote: > xfs_repair: read failed: Input/output error Look like a disk error... - Did you check dmesg output? -- 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 Mon May 15 06:59:47 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 15 May 2006 06:59:49 -0700 (PDT) Received: from mta1.gsf.de (mta1.gsf.de [146.107.3.111]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k4FDvjTm016181 for ; Mon, 15 May 2006 06:59:47 -0700 Received: from [127.0.0.1] (acouchis.gsf.de [146.107.217.183]) by mta1.gsf.de (Postfix) with ESMTP id 48FB25382E for ; Mon, 15 May 2006 15:57:44 +0200 (CEST) Message-ID: <446888D8.9050003@gsf.de> Date: Mon, 15 May 2006 15:57:44 +0200 From: Yogesh Bhanu Reply-To: yogesh@gsf.de Organization: IBI/MIPS User-Agent: Thunderbird 1.5.0.2 (X11/20060308) MIME-Version: 1.0 Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_repair failing References: <4468263B.6080609@gsf.de> <200605151154.19782.as@cohaesio.com> In-Reply-To: <200605151154.19782.as@cohaesio.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7736 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: yogesh@gsf.de Precedence: bulk X-list: linux-xfs Content-Length: 483 Lines: 14 Hi , Thanks for the pointers, Justin, Anders Well after rebuilding the raid . I thought all was back to Normal, there were no more errors either in storage logs or in system logs(var/log/messages). But when I ran xfs_repair, there were again the similar scsi sense error messages in /var/log/messages and also in storage there were some error logs, As another disk was about to fail. I 'm rebuilding raid now so hopefully after this rebuild we are clean. Thanks yogesh From owner-linux-xfs@oss.sgi.com Mon May 15 07:41:51 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 15 May 2006 07:41:54 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with SMTP id k4FEdmHN020457 for ; Mon, 15 May 2006 07:41:50 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA04883; Mon, 15 May 2006 23:29:42 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k4FDTdh31492147; Mon, 15 May 2006 23:29:40 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k4FDTaqR1490716; Mon, 15 May 2006 23:29:36 +1000 (AEST) Date: Mon, 15 May 2006 23:29:36 +1000 From: David Chinner To: Peter Broadwell Cc: linux-xfs@oss.sgi.com Subject: Re: deep chmod|chown -R begin to start OOMkiller Message-ID: <20060515132936.GN1331387@melbourne.sgi.com> References: <4464E3B5.8020602@wink.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4464E3B5.8020602@wink.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 7737 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: 2573 Lines: 65 On Fri, May 12, 2006 at 12:36:21PM -0700, Peter Broadwell wrote: > I seem to be having the same problem as CHIKAMA Masaki was having in > December 7, 2005, > namely "chown -R" running very slowly when hitting lots of files (~17 > million in my case). The problem is different because there's no OOM killer being invoked, right? All you see is a slowdown? How much CPU time is the chmod consuming? > I'm most interested in anything to (safely) speed this up on a live file > system as it > has been running for nearly 24 hours so far... not hung or corrupted > anything as far > as I can tell. Well, doing a chmod on a single file requires an inode read, a log write, and eventually a inode write. > xfs_chashlist 205900 385952 32 112 1 : tunables 120 60 8 > xfs_ili 273754 273760 192 20 1 : tunables 120 60 8 > xfs_inode 275317 275317 528 7 1 : tunables 54 27 8 > xfs_vnode 275316 275316 632 6 1 : tunables 54 27 8 > dentry_cache 252909 252909 224 17 1 : tunables 120 60 8 From the inode to cluster ratio (xfs_inode/xfs_chashlist), you've got very sparse inode clusters, so each inode read and write will do a disk I/O. So, two I/Os per file chmod() plus a log write every few files plus directory reads. That makes it roughly 40 million I/Os to do your recursive chmod. On a single disk sustaining 200 I/Os per second, I'd expect it to take more than a couple of days to complete the recursive chmod. Your filesystem is going to be slow while this is going on as well. > peter@cl1 /data $ df -k > Filesystem 1K-blocks Used Available Use% Mounted on > /dev/md/1 449447808 338816792 110631016 76% /data peter@cl1 /data $ xfs_info /data .... data = bsize=4096 blocks=112394720, imaxpct=25 = sunit=16 swidth=64 blks, unwritten=1 So a 64k stripe unit and 4-unit wide stripe. What RAID level are you using for your stripe? What's the spindle speed of the disks? log =internal bsize=4096 blocks=32768, version=1 With a 128MB version 1 log. If you were using version 2 logs, I'd suggest using a larger log buffer size to reduce the number of log writes. That would help quite a bit. Other than that, I can't think of much you could tune to help here. When you need to do that many I/Os, the only thing that speeds it up is to have lots of spindles... Cheers, Dave. -- Dave Chinner R&D Software Enginner SGI Australian Software Group From owner-linux-xfs@oss.sgi.com Mon May 15 17:02:04 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 15 May 2006 17:02:09 -0700 (PDT) Received: from g0.machinephasesystems.com (dsl092-191-029.sfo1.dsl.speakeasy.net [66.92.191.29]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k4G0026o013754 for ; Mon, 15 May 2006 17:02:04 -0700 Received: from [192.168.1.67] (g.machinephasesystems.com [66.92.191.28]) by g0.machinephasesystems.com (8.13.6/8.13.6) with ESMTP id k4FLqo9s005602; Mon, 15 May 2006 14:52:50 -0700 Message-ID: <4468F967.6090202@wink.com> Date: Mon, 15 May 2006 14:57:59 -0700 From: Peter Broadwell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: David Chinner CC: linux-xfs@oss.sgi.com Subject: Re: deep chmod|chown -R begin to start OOMkiller References: <4464E3B5.8020602@wink.com> <20060515132936.GN1331387@melbourne.sgi.com> In-Reply-To: <20060515132936.GN1331387@melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7738 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@wink.com Precedence: bulk X-list: linux-xfs Content-Length: 3348 Lines: 83 David - Thanks first off for your reply as well. It was your old postings that inspired me to even ask my question... You're right that their is no OOMKiller on my system, so the problem is perhaps unrelated - I'm not sure how OOMKIller would make it different, but I don't know realy what OOMKiller does at a low level. As for load, the chown process would garner only 3-5% of the CPU according to top, but the load average would increase by 1 to 2, bringing it up to ~7. Trying to re-run a small subset of the chowns (to the same user) just now showed similar behavior, but when I ran it a second time it was *very* fast. ;-) As for version of the log, can I upgrade to version 2 on a running system? ;;peter David Chinner wrote: > On Fri, May 12, 2006 at 12:36:21PM -0700, Peter Broadwell wrote: >> I seem to be having the same problem as CHIKAMA Masaki was having in >> December 7, 2005, >> namely "chown -R" running very slowly when hitting lots of files (~17 >> million in my case). > > The problem is different because there's no OOM killer > being invoked, right? All you see is a slowdown? How much CPU > time is the chmod consuming? > >> I'm most interested in anything to (safely) speed this up on a live file >> system as it >> has been running for nearly 24 hours so far... not hung or corrupted >> anything as far >> as I can tell. > > Well, doing a chmod on a single file requires an inode read, > a log write, and eventually a inode write. > >> xfs_chashlist 205900 385952 32 112 1 : tunables 120 60 8 >> xfs_ili 273754 273760 192 20 1 : tunables 120 60 8 >> xfs_inode 275317 275317 528 7 1 : tunables 54 27 8 >> xfs_vnode 275316 275316 632 6 1 : tunables 54 27 8 >> dentry_cache 252909 252909 224 17 1 : tunables 120 60 8 > > From the inode to cluster ratio (xfs_inode/xfs_chashlist), you've > got very sparse inode clusters, so each inode read and write will do > a disk I/O. So, two I/Os per file chmod() plus a log write every few > files plus directory reads. That makes it roughly 40 million I/Os > to do your recursive chmod. > > On a single disk sustaining 200 I/Os per second, I'd expect it to > take more than a couple of days to complete the recursive chmod. Your > filesystem is going to be slow while this is going on as well. > >> peter@cl1 /data $ df -k >> Filesystem 1K-blocks Used Available Use% Mounted on >> /dev/md/1 449447808 338816792 110631016 76% /data > > peter@cl1 /data $ xfs_info /data > .... > data = bsize=4096 blocks=112394720, imaxpct=25 > = sunit=16 swidth=64 blks, unwritten=1 > > So a 64k stripe unit and 4-unit wide stripe. What RAID level are you > using for your stripe? What's the spindle speed of the disks? > > log =internal bsize=4096 blocks=32768, version=1 > > With a 128MB version 1 log. > > If you were using version 2 logs, I'd suggest using a larger > log buffer size to reduce the number of log writes. That would > help quite a bit. Other than that, I can't think of much you > could tune to help here. When you need to do that many I/Os, > the only thing that speeds it up is to have lots of spindles... > > Cheers, > > Dave. From owner-linux-xfs@oss.sgi.com Mon May 15 17:02:06 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 15 May 2006 17:02:12 -0700 (PDT) Received: from g0.machinephasesystems.com (dsl092-191-029.sfo1.dsl.speakeasy.net [66.92.191.29]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k4G0026q013754 for ; Mon, 15 May 2006 17:02:05 -0700 Received: from [192.168.1.67] (g.machinephasesystems.com [66.92.191.28]) by g0.machinephasesystems.com (8.13.6/8.13.6) with ESMTP id k4FLPjR3005465; Mon, 15 May 2006 14:25:45 -0700 Message-ID: <4468F30E.3030405@wink.com> Date: Mon, 15 May 2006 14:30:54 -0700 From: Peter Broadwell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: Anders Saaby CC: linux-xfs@oss.sgi.com Subject: Re: deep chmod|chown -R begin to start OOMkiller References: <4464E3B5.8020602@wink.com> <200605151159.34802.as@cohaesio.com> In-Reply-To: <200605151159.34802.as@cohaesio.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7739 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@wink.com Precedence: bulk X-list: linux-xfs Content-Length: 21125 Lines: 333 Anders - First, thanks for the reply. Yes, high CPU load, around 6-7 on a dual AMD Opteron system but much of it may be caused by other things running. Is there some tool that can isolate the load vs. D-state hang on a per-process instance? My chown did finally finish, some 63 hrs later for about 75 chowns/sec. This is running on system with 4 SATA 7200 rpm drives configured with software RAID 10 so it is essencialy 2 spindles and we are seeing about 1/3 of the theoretical maximum. Would of course be nice to do better, but perhaps is in bounds for reality? In looking around I did see a ioctl, XFS_IOC_FSBULKSTAT, that seemed like it might give a different approach to doing this, but looked like it was read only (and lots of work to get anything going with it...) Is this a worthwhile avenue to look at more deeply? ;;peter Anders Saaby wrote: > Hi, > > Do you have high CPU usage when running the chown? - Or just processes hanging > i D-state? > > On Friday 12 May 2006 21:36, Peter Broadwell wrote: >> I seem to be having the same problem as CHIKAMA Masaki was having in >> December 7, 2005, namely "chown -R" running very slowly when hitting lots >> of files (~17 million in my case). >> >> My machine doesn't have the same constraints that David pointed to as at >> least part of the problem. >> I have fast disks, and lots of memory (though perhaps still bad logfile >> sizes) So I thought I'd feed into the discussion a bit, hoping for any >> other ideas... >> >> I'm most interested in anything to (safely) speed this up on a live file >> system as it has been running for nearly 24 hours so far... not hung or >> corrupted anything as far as I can tell. >> >> Following is possibly interesting info from uname, /proc/meminfo, >> /proc/slabinfo, ... (I don't have OOMkiller though): >> >> Thanks - >> >> ;;peter >> >> = = = = (start of info) = = = = >> >> peter@cl1 /data $ uname -sr >> Linux 2.6.14-gentoo-r2 >> peter@cl1 /data $ cat /proc/meminfo >> MemTotal: 8058120 kB >> MemFree: 2770704 kB >> Buffers: 12 kB >> Cached: 3412304 kB >> SwapCached: 6860 kB >> Active: 2914928 kB >> Inactive: 1673712 kB >> HighTotal: 0 kB >> HighFree: 0 kB >> LowTotal: 8058120 kB >> LowFree: 2770704 kB >> SwapTotal: 32129968 kB >> SwapFree: 32114220 kB >> Dirty: 16 kB >> Writeback: 0 kB >> Mapped: 1191804 kB >> Slab: 666680 kB >> CommitLimit: 36159028 kB >> Committed_AS: 1313628 kB >> PageTables: 4564 kB >> VmallocTotal: 34359738367 kB >> VmallocUsed: 24420 kB >> VmallocChunk: 34359713687 kB >> HugePages_Total: 0 >> HugePages_Free: 0 >> Hugepagesize: 2048 kB >> peter@cl1 /data $ cat /proc/slabinfo >> slabinfo - version: 2.1 >> # name >> : tunables : slabdata >> >> rpc_buffers 8 8 2048 2 1 : tunables 24 12 8 >> : slabdata 4 4 0 rpc_tasks 8 10 384 10 >> 1 : tunables 54 27 8 : slabdata 1 1 0 >> rpc_inode_cache 8 12 832 4 1 : tunables 54 27 8 >> : slabdata 3 3 0 fib6_nodes 7 118 64 59 >> 1 : tunables 120 60 8 : slabdata 2 2 0 >> ip6_dst_cache 7 24 320 12 1 : tunables 54 27 8 >> : slabdata 2 2 0 ndisc_cache 1 15 256 15 >> 1 : tunables 120 60 8 : slabdata 1 1 0 RAWv6 >> 4 4 896 4 1 : tunables 54 27 8 : slabdata >> 1 1 0 UDPv6 1 4 896 4 1 : >> tunables 54 27 8 : slabdata 1 1 0 tw_sock_TCPv6 >> 0 0 192 20 1 : tunables 120 60 8 : slabdata 0 >> 0 0 request_sock_TCPv6 0 0 128 30 1 : tunables >> 120 60 8 : slabdata 0 0 0 TCPv6 6 >> 10 1536 5 2 : tunables 24 12 8 : slabdata 2 2 >> 0 UNIX 41 54 640 6 1 : tunables 54 27 >> 8 : slabdata 9 9 0 tcp_bind_bucket 34 448 32 >> 112 1 : tunables 120 60 8 : slabdata 4 4 0 >> inet_peer_cache 0 0 64 59 1 : tunables 120 60 8 >> : slabdata 0 0 0 ip_fib_alias 14 118 64 59 >> 1 : tunables 120 60 8 : slabdata 2 2 0 ip_fib_hash >> 14 118 64 59 1 : tunables 120 60 8 : slabdata >> 2 2 0 ip_dst_cache 36 48 320 12 1 : >> tunables 54 27 8 : slabdata 4 4 0 arp_cache >> 8 30 256 15 1 : tunables 120 60 8 : slabdata 2 >> 2 0 RAW 3 11 704 11 2 : tunables 54 >> 27 8 : slabdata 1 1 0 UDP 16 20 >> 768 5 1 : tunables 54 27 8 : slabdata 4 4 0 >> tw_sock_TCP 23 40 192 20 1 : tunables 120 60 8 >> : slabdata 2 2 0 request_sock_TCP 8 30 128 30 >> 1 : tunables 120 60 8 : slabdata 1 1 0 TCP >> 15 25 1408 5 2 : tunables 24 12 8 : slabdata >> 5 5 0 uhci_urb_priv 0 0 88 44 1 : >> tunables 120 60 8 : slabdata 0 0 0 scsi_cmd_cache >> 29 35 512 7 1 : tunables 54 27 8 : slabdata 5 >> 5 0 cfq_ioc_pool 0 0 96 40 1 : tunables 120 >> 60 8 : slabdata 0 0 0 cfq_pool 0 0 >> 160 24 1 : tunables 120 60 8 : slabdata 0 0 0 >> crq_pool 0 0 88 44 1 : tunables 120 60 8 >> : slabdata 0 0 0 deadline_drq 607 760 96 40 >> 1 : tunables 120 60 8 : slabdata 18 19 480 as_arq >> 0 0 112 34 1 : tunables 120 60 8 : slabdata >> 0 0 0 mqueue_inode_cache 1 4 896 4 1 : >> tunables 54 27 8 : slabdata 1 1 0 xfs_chashlist >> 205900 385952 32 112 1 : tunables 120 60 8 : slabdata 3446 >> 3446 0 xfs_ili 273754 273760 192 20 1 : tunables >> 120 60 8 : slabdata 13688 13688 0 xfs_ifork 0 >> 0 64 59 1 : tunables 120 60 8 : slabdata 0 0 >> 0 xfs_efi_item 0 0 352 11 1 : tunables 54 27 >> 8 : slabdata 0 0 0 xfs_efd_item 0 0 360 >> 11 1 : tunables 54 27 8 : slabdata 0 0 0 >> xfs_buf_item 1 21 184 21 1 : tunables 120 60 8 >> : slabdata 1 1 0 xfs_dabuf 45 288 24 144 >> 1 : tunables 120 60 8 : slabdata 2 2 0 xfs_da_state >> 0 0 488 8 1 : tunables 54 27 8 : slabdata >> 0 0 0 xfs_trans 186 351 872 9 2 : >> tunables 54 27 8 : slabdata 32 39 81 xfs_inode >> 275317 275317 528 7 1 : tunables 54 27 8 : slabdata 39331 >> 39331 0 xfs_btree_cur 0 0 192 20 1 : tunables >> 120 60 8 : slabdata 0 0 0 xfs_bmap_free_item 0 >> 0 24 144 1 : tunables 120 60 8 : slabdata 0 0 >> 0 xfs_buf 288 414 408 9 1 : tunables 54 27 >> 8 : slabdata 45 46 216 xfs_ioend 32 54 144 >> 27 1 : tunables 120 60 8 : slabdata 2 2 0 xfs_vnode >> 275316 275316 632 6 1 : tunables 54 27 8 : slabdata >> 45886 45886 0 ntfs_big_inode_cache 0 0 896 4 1 : >> tunables 54 27 8 : slabdata 0 0 0 ntfs_inode_cache >> 0 0 272 14 1 : tunables 54 27 8 : slabdata 0 >> 0 0 ntfs_name_cache 0 0 512 8 1 : tunables 54 >> 27 8 : slabdata 0 0 0 ntfs_attr_ctx_cache 0 0 >> 64 59 1 : tunables 120 60 8 : slabdata 0 0 0 >> ntfs_index_ctx_cache 0 0 128 30 1 : tunables 120 60 >> 8 : slabdata 0 0 0 nfs_write_data 36 36 832 >> 9 2 : tunables 54 27 8 : slabdata 4 4 0 >> nfs_read_data 32 35 768 5 1 : tunables 54 27 8 >> : slabdata 7 7 0 nfs_inode_cache 1 4 912 4 >> 1 : tunables 54 27 8 : slabdata 1 1 0 nfs_page >> 0 0 128 30 1 : tunables 120 60 8 : slabdata >> 0 0 0 isofs_inode_cache 0 0 632 6 1 : >> tunables 54 27 8 : slabdata 0 0 0 fat_inode_cache >> 0 0 664 6 1 : tunables 54 27 8 : slabdata 0 >> 0 0 fat_cache 0 0 32 112 1 : tunables 120 >> 60 8 : slabdata 0 0 0 hugetlbfs_inode_cache 1 >> 6 600 6 1 : tunables 54 27 8 : slabdata 1 1 >> 0 ext2_inode_cache 0 0 744 5 1 : tunables 54 27 >> 8 : slabdata 0 0 0 ext2_xattr 0 0 88 >> 44 1 : tunables 120 60 8 : slabdata 0 0 0 >> journal_handle 0 0 24 144 1 : tunables 120 60 8 >> : slabdata 0 0 0 journal_head 0 0 96 40 >> 1 : tunables 120 60 8 : slabdata 0 0 0 revoke_table >> 0 0 16 202 1 : tunables 120 60 8 : slabdata >> 0 0 0 revoke_record 0 0 32 112 1 : >> tunables 120 60 8 : slabdata 0 0 0 ext3_inode_cache >> 0 0 792 5 1 : tunables 54 27 8 : slabdata 0 >> 0 0 ext3_xattr 0 0 88 44 1 : tunables 120 >> 60 8 : slabdata 0 0 0 reiser_inode_cache 0 0 >> 704 5 1 : tunables 54 27 8 : slabdata 0 0 0 >> dnotify_cache 0 0 40 92 1 : tunables 120 60 8 >> : slabdata 0 0 0 eventpoll_pwq 0 0 72 53 >> 1 : tunables 120 60 8 : slabdata 0 0 0 >> eventpoll_epi 0 0 192 20 1 : tunables 120 60 8 >> : slabdata 0 0 0 inotify_event_cache 0 0 40 >> 92 1 : tunables 120 60 8 : slabdata 0 0 0 >> inotify_watch_cache 1 59 64 59 1 : tunables 120 60 >> 8 : slabdata 1 1 0 kioctx 0 0 320 >> 12 1 : tunables 54 27 8 : slabdata 0 0 0 kiocb >> 0 0 256 15 1 : tunables 120 60 8 : slabdata >> 0 0 0 fasync_cache 0 0 24 144 1 : >> tunables 120 60 8 : slabdata 0 0 0 shmem_inode_cache >> 840 850 792 5 1 : tunables 54 27 8 : slabdata 170 >> 170 0 posix_timers_cache 0 0 168 23 1 : tunables >> 120 60 8 : slabdata 0 0 0 uid_cache 9 >> 118 64 59 1 : tunables 120 60 8 : slabdata 2 2 >> 0 sgpool-128 32 32 4096 1 1 : tunables 24 12 >> 8 : slabdata 32 32 0 sgpool-64 32 32 2048 >> 2 1 : tunables 24 12 8 : slabdata 16 16 0 sgpool-32 >> 32 32 1024 4 1 : tunables 54 27 8 : slabdata >> 8 8 0 sgpool-16 45 48 512 8 1 : >> tunables 54 27 8 : slabdata 6 6 0 sgpool-8 >> 52 60 256 15 1 : tunables 120 60 8 : slabdata 4 >> 4 0 blkdev_ioc 114 201 56 67 1 : tunables 120 >> 60 8 : slabdata 3 3 0 blkdev_queue 31 44 >> 712 11 2 : tunables 54 27 8 : slabdata 4 4 0 >> blkdev_requests 311 630 264 15 1 : tunables 54 27 8 >> : slabdata 40 42 216 biovec-(256) 256 256 4096 1 >> 1 : tunables 24 12 8 : slabdata 256 256 0 biovec-128 >> 256 256 2048 2 1 : tunables 24 12 8 : slabdata >> 128 128 0 biovec-64 256 256 1024 4 1 : >> tunables 54 27 8 : slabdata 64 64 0 biovec-16 >> 285 285 256 15 1 : tunables 120 60 8 : slabdata 19 >> 19 0 biovec-4 864 1652 64 59 1 : tunables 120 >> 60 8 : slabdata 27 28 480 biovec-1 482 1616 >> 16 202 1 : tunables 120 60 8 : slabdata 8 8 108 >> bio 860 1500 128 30 1 : tunables 120 60 8 >> : slabdata 50 50 480 file_lock_cache 6 24 160 24 >> 1 : tunables 120 60 8 : slabdata 1 1 0 >> sock_inode_cache 93 130 704 5 1 : tunables 54 27 8 >> : slabdata 26 26 0 skbuff_fclone_cache 20 32 448 >> 8 1 : tunables 54 27 8 : slabdata 3 4 0 >> skbuff_head_cache 555 1035 256 15 1 : tunables 120 60 8 >> : slabdata 69 69 0 acpi_operand 1127 1166 72 53 >> 1 : tunables 120 60 8 : slabdata 22 22 0 >> acpi_parse_ext 0 0 64 59 1 : tunables 120 60 8 >> : slabdata 0 0 0 acpi_parse 0 0 40 92 >> 1 : tunables 120 60 8 : slabdata 0 0 0 acpi_state >> 0 0 88 44 1 : tunables 120 60 8 : slabdata >> 0 0 0 proc_inode_cache 667 690 616 6 1 : >> tunables 54 27 8 : slabdata 115 115 0 sigqueue >> 32 46 168 23 1 : tunables 120 60 8 : slabdata 2 >> 2 0 radix_tree_node 232625 303359 536 7 1 : tunables 54 >> 27 8 : slabdata 43337 43337 0 bdev_cache 22 28 >> 832 4 1 : tunables 54 27 8 : slabdata 7 7 0 >> sysfs_dir_cache 2946 3021 72 53 1 : tunables 120 60 8 >> : slabdata 57 57 0 mnt_cache 26 60 192 20 >> 1 : tunables 120 60 8 : slabdata 3 3 0 inode_cache >> 1080 1085 584 7 1 : tunables 54 27 8 : slabdata >> 155 155 0 dentry_cache 252909 252909 224 17 1 : >> tunables 120 60 8 : slabdata 14877 14877 0 filp >> 883 1365 256 15 1 : tunables 120 60 8 : slabdata 91 >> 91 0 names_cache 3 5 4096 1 1 : tunables 24 >> 12 8 : slabdata 3 5 0 idr_layer_cache 77 84 >> 528 7 1 : tunables 54 27 8 : slabdata 12 12 0 >> buffer_head 52111 139612 88 44 1 : tunables 120 60 8 >> : slabdata 3173 3173 0 mm_struct 67 77 1152 7 >> 2 : tunables 24 12 8 : slabdata 11 11 0 >> vm_area_struct 2672 2814 184 21 1 : tunables 120 60 8 >> : slabdata 134 134 0 fs_cache 76 118 64 59 >> 1 : tunables 120 60 8 : slabdata 2 2 0 files_cache >> 66 72 896 4 1 : tunables 54 27 8 : slabdata >> 18 18 0 signal_cache 109 120 640 6 1 : >> tunables 54 27 8 : slabdata 20 20 0 sighand_cache >> 103 108 2112 3 2 : tunables 24 12 8 : slabdata 36 >> 36 0 task_struct 123 128 1728 4 2 : tunables 24 >> 12 8 : slabdata 32 32 0 anon_vma 987 1440 >> 24 144 1 : tunables 120 60 8 : slabdata 10 10 0 >> shared_policy_node 0 0 56 67 1 : tunables 120 60 8 >> : slabdata 0 0 0 numa_policy 39 404 16 202 >> 1 : tunables 120 60 8 : slabdata 2 2 0 >> size-131072(DMA) 0 0 131072 1 32 : tunables 8 4 0 >> : slabdata 0 0 0 size-131072 0 0 131072 1 >> 32 : tunables 8 4 0 : slabdata 0 0 0 >> size-65536(DMA) 0 0 65536 1 16 : tunables 8 4 0 >> : slabdata 0 0 0 size-65536 2 2 65536 1 >> 16 : tunables 8 4 0 : slabdata 2 2 0 >> size-32768(DMA) 0 0 32768 1 8 : tunables 8 4 0 >> : slabdata 0 0 0 size-32768 20 20 32768 1 >> 8 : tunables 8 4 0 : slabdata 20 20 0 >> size-16384(DMA) 0 0 16384 1 4 : tunables 8 4 0 >> : slabdata 0 0 0 size-16384 0 0 16384 1 >> 4 : tunables 8 4 0 : slabdata 0 0 0 >> size-8192(DMA) 0 0 8192 1 2 : tunables 8 4 0 >> : slabdata 0 0 0 size-8192 17 17 8192 1 >> 2 : tunables 8 4 0 : slabdata 17 17 0 >> size-4096(DMA) 0 0 4096 1 1 : tunables 24 12 8 >> : slabdata 0 0 0 size-4096 269 270 4096 1 >> 1 : tunables 24 12 8 : slabdata 269 270 0 >> size-2048(DMA) 0 0 2048 2 1 : tunables 24 12 8 >> : slabdata 0 0 0 size-2048 708 736 2048 2 >> 1 : tunables 24 12 8 : slabdata 363 368 0 >> size-1024(DMA) 0 0 1024 4 1 : tunables 54 27 8 >> : slabdata 0 0 0 size-1024 350 368 1024 4 >> 1 : tunables 54 27 8 : slabdata 92 92 0 >> size-512(DMA) 0 0 512 8 1 : tunables 54 27 8 >> : slabdata 0 0 0 size-512 619 640 512 8 >> 1 : tunables 54 27 8 : slabdata 80 80 0 >> size-256(DMA) 0 0 256 15 1 : tunables 120 60 8 >> : slabdata 0 0 0 size-256 82 105 256 15 >> 1 : tunables 120 60 8 : slabdata 7 7 0 >> size-192(DMA) 0 0 192 20 1 : tunables 120 60 8 >> : slabdata 0 0 0 size-192 1560 2000 192 20 >> 1 : tunables 120 60 8 : slabdata 100 100 0 >> size-128(DMA) 0 0 128 30 1 : tunables 120 60 8 >> : slabdata 0 0 0 size-64(DMA) 0 0 64 59 >> 1 : tunables 120 60 8 : slabdata 0 0 0 size-64 >> 2672 9027 64 59 1 : tunables 120 60 8 : slabdata >> 153 153 0 size-32(DMA) 0 0 32 112 1 : >> tunables 120 60 8 : slabdata 0 0 0 size-128 >> 3807 4950 128 30 1 : tunables 120 60 8 : slabdata 165 >> 165 300 size-32 703 784 32 112 1 : tunables 120 >> 60 8 : slabdata 7 7 0 kmem_cache 155 155 >> 704 5 1 : tunables 54 27 8 : slabdata 31 31 0 >> peter@cl1 /data $ >> >> peter@cl1 /data $ df -k >> Filesystem 1K-blocks Used Available Use% Mounted on >> /dev/md/0 22479104 13991500 8487604 63% / >> udev 4029060 244 4028816 1% /dev >> /dev/md/1 449447808 338816792 110631016 76% /data >> none 4029060 0 4029060 0% /dev/shm >> cl4:/data 451279232 112298760 338980472 25% /mnt/cl4-data >> peter@cl1 /data $ xfs_info /data >> meta-data=/dev/md1 isize=256 agcount=16, agsize=7024672 >> blks = sectsz=512 >> data = bsize=4096 blocks=112394720, imaxpct=25 >> = sunit=16 swidth=64 blks, unwritten=1 >> naming =version 2 bsize=4096 >> log =internal bsize=4096 blocks=32768, version=1 >> = sectsz=512 sunit=0 blks >> realtime =none extsz=262144 blocks=0, rtextents=0 >> peter@cl1 /data $ >> >> = = = = (end of info) = = = = > From owner-linux-xfs@oss.sgi.com Mon May 15 20:14:16 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 15 May 2006 20:14:18 -0700 (PDT) Received: from g0.machinephasesystems.com (dsl092-191-029.sfo1.dsl.speakeasy.net [66.92.191.29]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k4G3CDkT003130 for ; Mon, 15 May 2006 20:14:16 -0700 Received: from [192.168.1.67] (g.machinephasesystems.com [66.92.191.28]) by g0.machinephasesystems.com (8.13.6/8.13.6) with ESMTP id k4G36uYk007208; Mon, 15 May 2006 20:06:56 -0700 Message-ID: <44694306.9030407@wink.com> Date: Mon, 15 May 2006 20:12:06 -0700 From: Peter Broadwell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: David Chinner CC: Anders Saaby , linux-xfs@oss.sgi.com Subject: Re: deep chmod|chown -R begin to start OOMkiller References: <4464E3B5.8020602@wink.com> <20060515132936.GN1331387@melbourne.sgi.com> <4468F967.6090202@wink.com> <4464E3B5.8020602@wink.com> <200605151159.34802.as@cohaesio.com> <4468F30E.3030405@wink.com> <20060516013408.GB1390195@melbourne.sgi.com> In-Reply-To: <20060516013408.GB1390195@melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7742 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@wink.com Precedence: bulk X-list: linux-xfs Content-Length: 2416 Lines: 59 David Chinner wrote: > On Mon, May 15, 2006 at 02:30:54PM -0700, Peter Broadwell wrote: >> My chown did finally finish, some 63 hrs later for about 75 chowns/sec. >> This is running on system with 4 SATA 7200 rpm drives configured with >> software RAID 10 so it is essencialy 2 spindles and we are seeing >> about 1/3 of the theoretical maximum. > > If you call a SWAG a "theoretical maximum". All your results indicate > is that my guess was in the same ballpark as reality. Such a well informed SWAG is indication of good breeding ;-) >> In looking around I did see a ioctl, XFS_IOC_FSBULKSTAT, that seemed >> like it might give a different approach to doing this, but looked like it >> was read only (and lots of work to get anything going with it...) >> Is this a worthwhile avenue to look at more deeply? > > Read only, and does not follow any directory structure - it just reads > the inodes off disk in ascending block order.... Well, *if* I had to do this often I would think a write version of this ioctl might reduce by at least 1/3 the number of disk writes, no? It also seems funny that I could copy the whole disk in less time that it took me to chown files that are filling up less than 1/2 of it... Fortunately I don't expect to have to do this again, and if I do, I'll know it will be a long running process. Thanks again for your help in understanding what is probably happening. ;;peter > On Mon, May 15, 2006 at 02:57:59PM -0700, Peter Broadwell wrote: >> As for load, the chown process would garner only 3-5% of the CPU according >> to top, but the load average would increase by 1 to 2, bringing it up to ~7. > > A single process being I/O bound like this will contribute 1 to the > load average. > >> Trying to re-run a small subset of the chowns (to the same user) just now >> showed similar behavior, but when I ran it a second time it was *very* >> fast. ;-) > > My guess would be that the first time it ran it needed to read all > the inodes in off disk. The second time they were in cache, and the > subset probably fit in the log so the only I/O would be log I/O. > Hence the second run would be very fast.... > >> As for version of the log, can I upgrade to version 2 on a running system? > > I know there is on Irix (xfs_chver) which is a perl script wrapper for > xfs_db, but I'm not sure if there is an equivalent shipped on linux. > Nathan? > > Cheers, > > Dave. From owner-linux-xfs@oss.sgi.com Mon May 15 22:11:56 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 15 May 2006 22:11:58 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with SMTP id k4G59q7M021577 for ; Mon, 15 May 2006 22:11:55 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA27952; Tue, 16 May 2006 15:09:49 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k4G59kh32087520; Tue, 16 May 2006 15:09:46 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k4G59hwG2087302; Tue, 16 May 2006 15:09:43 +1000 (AEST) Date: Tue, 16 May 2006 15:09:43 +1000 From: David Chinner To: Peter Broadwell Cc: David Chinner , Anders Saaby , linux-xfs@oss.sgi.com Subject: Re: deep chmod|chown -R begin to start OOMkiller Message-ID: <20060516050943.GI1390195@melbourne.sgi.com> References: <4464E3B5.8020602@wink.com> <20060515132936.GN1331387@melbourne.sgi.com> <4468F967.6090202@wink.com> <4464E3B5.8020602@wink.com> <200605151159.34802.as@cohaesio.com> <4468F30E.3030405@wink.com> <20060516013408.GB1390195@melbourne.sgi.com> <44694306.9030407@wink.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44694306.9030407@wink.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 7744 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: 1498 Lines: 41 On Mon, May 15, 2006 at 08:12:06PM -0700, Peter Broadwell wrote: > David Chinner wrote: > >>In looking around I did see a ioctl, XFS_IOC_FSBULKSTAT, that seemed > >>like it might give a different approach to doing this, but looked like it > >>was read only (and lots of work to get anything going with it...) > >>Is this a worthwhile avenue to look at more deeply? > > > >Read only, and does not follow any directory structure - it just reads > >the inodes off disk in ascending block order.... > > Well, *if* I had to do this often I would think a write version of this > ioctl might reduce by at least 1/3 the number of disk writes, no? If you wanted to change every inode in the filesystem, then yes, it could be done this way (e.g. an inode cluster at a time). And the difference in I/Os would be more like an order of magnitude. However, a write version is not quite that simple because you still have to log all the changes you make..... > It also seems funny that I could copy the whole disk in less time that > it took me to chown files that are filling up less than 1/2 of it... Yep, that's the difference between doing large sequential I/Os for the disk copy and small, random I/Os for the chown... > Fortunately I don't expect to have to do this again, and if I do, > I'll know it will be a long running process. > > Thanks again for your help in understanding what is probably happening. np. Cheers, Dave. -- Dave Chinner R&D Software Enginner SGI Australian Software Group From owner-linux-xfs@oss.sgi.com Tue May 16 01:55:35 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 May 2006 01:55:39 -0700 (PDT) Received: from ccerelbas02.cce.hp.com (ccerelbas02.cce.hp.com [161.114.21.105]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k4G8rYkc021477 for ; Tue, 16 May 2006 01:55:35 -0700 Received: from mailrelay01.cce.cpqcorp.net (relay.dec.com [16.47.68.171]) by ccerelbas02.cce.hp.com (Postfix) with ESMTP id 1998B34020 for ; Tue, 16 May 2006 01:21:40 -0500 (CDT) Received: from flyingAngel.upjs.sk (alienangel.emea.hpqcorp.net [16.55.206.67]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 917771633 for ; Tue, 16 May 2006 01:21:40 -0500 (CDT) Received: by flyingAngel.upjs.sk (Postfix, from userid 500) id 71E661DE9A5; Tue, 16 May 2006 08:21:28 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by flyingAngel.upjs.sk (Postfix) with ESMTP id 6BBB798 for ; Tue, 16 May 2006 08:21:28 +0200 (CEST) Date: Tue, 16 May 2006 08:21:27 +0200 (CEST) From: Jan Derfinak To: linux-xfs@oss.sgi.com Subject: CVS access Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 7745 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: 432 Lines: 15 Hello. Last few days I have problem to update kernel from SGI cvs tree. I like to ask what is wrong? Thanks. jan xfs/linux-2.6-xfs %49> cvs -z5 update -dP cvs update: Updating . cvs update: failed to create lock directory for /cvs/linux-2.6-xfs' (/var/lock/cvs/linux-2.6-xfs/#cvs.lock): Permission denied cvs update: failed to obtain dir lock in repository /cvs/linux-2.6-xfs' cvs [update aborted]: read lock failed - giving up From owner-linux-xfs@oss.sgi.com Wed May 17 15:15:33 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 May 2006 15:15:39 -0700 (PDT) Received: from coraid.com (ns1.coraid.com [65.14.39.133]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k4HMDV9u005552 for ; Wed, 17 May 2006 15:15:32 -0700 Received: from coraid.com ([205.185.197.207]) by coraid.com; Wed May 17 15:35:26 EDT 2006 Date: Wed, 17 May 2006 15:36:06 -0400 From: "Ed L. Cashin" To: linux-xfs@oss.sgi.com Subject: xfs_repair on large fs: out of memory Message-ID: <20060517193606.GO32378@coraid.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11+cvs20060126 X-archive-position: 7750 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: ecashin@coraid.com Precedence: bulk X-list: linux-xfs Content-Length: 1648 Lines: 42 Hi. In trying to run xfs_repair on a 13 TB filesystem, the program either runs out of memory ... host02:~# sysctl vm.overcommit_memory=2 vm.overcommit_memory = 2 host02:~# /opt/xfsprogs-2.7.11/sbin/xfs_repair -v -n /dev/mapper/vg-lv Phase 1 - find and verify superblock... fatal error -- couldn't allocate block map, size = 106834464 host02:~# ... or just uses up all the system's memory and is killed if I use a more liberal vm.overcommit_memory setting. An strace shows that mmap is being called repeatedly. ... mmap(NULL, 53420032, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b2201d65000 mmap(NULL, 53420032, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b2205057000 mmap(NULL, 53420032, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b2208349000 mmap(NULL, 53420032, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b220b63b000 +++ killed by SIGKILL +++ Process 3146 detached This machine has a gigabyte of memory. It's running an x86_64 2.6.16.13 kernel. I think that the XFS log is not OK because on mount attempts the messages below appear in the logs. kernel: XFS mounting filesystem dm-0 kernel: Starting XFS recovery on filesystem: dm-0 (logdev: internal) kernel: XFS: xlog_recover_process_data: bad clientid kernel: XFS: log mount/recovery failed: error 5 kernel: XFS: log mount failed Based on the "bad clientid" message, I think that "xfs_repair -L" would be the next logical step, but it seems like there must be a bug in xfs_repair if it runs out of memory instead of telling me that. -- Ed L Cashin From owner-linux-xfs@oss.sgi.com Wed May 17 15:26:11 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 May 2006 15:26:14 -0700 (PDT) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with SMTP id k4HMO8Eh006862 for ; Wed, 17 May 2006 15:26:11 -0700 Received: (qmail 19718 invoked from network); 17 May 2006 22:24:01 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@67.164.15.140 with login) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 17 May 2006 22:24:01 -0000 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 501CB51FAC0; Wed, 17 May 2006 15:23:53 -0700 (PDT) Date: Wed, 17 May 2006 15:23:53 -0700 From: Chris Wedgwood To: "Ed L. Cashin" Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_repair on large fs: out of memory Message-ID: <20060517222353.GA32668@taniwha.stupidest.org> References: <20060517193606.GO32378@coraid.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060517193606.GO32378@coraid.com> X-archive-position: 7751 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: 437 Lines: 14 On Wed, May 17, 2006 at 03:36:06PM -0400, Ed L. Cashin wrote: > Hi. In trying to run xfs_repair on a 13 TB filesystem, the program > either runs out of memory ... [...] > This machine has a gigabyte of memory. It's running an x86_64 > 2.6.16.13 kernel. I forget the ratio/math for working this out (Steve Lord posted a summary of this some time ago) but 1GB isn't nearly enough to run xfs_repair on a moderately sized filesystem. From owner-linux-xfs@oss.sgi.com Wed May 17 15:35:52 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 May 2006 15:35:58 -0700 (PDT) Received: from smtp108.sbc.mail.mud.yahoo.com (smtp108.sbc.mail.mud.yahoo.com [68.142.198.207]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with SMTP id k4HMXplj007857 for ; Wed, 17 May 2006 15:35:52 -0700 Received: (qmail 77714 invoked from network); 17 May 2006 22:33:44 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@67.164.15.140 with login) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 17 May 2006 22:33:44 -0000 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 580EB51FAC0; Wed, 17 May 2006 15:33:41 -0700 (PDT) Date: Wed, 17 May 2006 15:33:41 -0700 From: Chris Wedgwood To: "Ed L. Cashin" Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_repair on large fs: out of memory Message-ID: <20060517223341.GA604@taniwha.stupidest.org> References: <20060517193606.GO32378@coraid.com> <20060517222353.GA32668@taniwha.stupidest.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060517222353.GA32668@taniwha.stupidest.org> X-archive-position: 7752 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: 11 On Wed, May 17, 2006 at 03:23:53PM -0700, Chris Wedgwood wrote: > I forget the ratio/math for working this out (Steve Lord posted a > summary of this some time ago) but 1GB isn't nearly enough to run > xfs_repair on a moderately sized filesystem. Of course it should still not fail the way you describe with overcommit. Is there an rlimit set that is biting you? From owner-linux-xfs@oss.sgi.com Wed May 17 15:53:56 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 May 2006 15:53:59 -0700 (PDT) Received: from mx2.quantum.com (mx2.quantum.com [146.174.252.112]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k4HMpswp009189 for ; Wed, 17 May 2006 15:53:56 -0700 Received: from ppoq3mim2.QUANTUM.COM (imcq32.quantum.com [10.50.4.172]) by mx2.quantum.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k4HMfFT1010102 for ; Wed, 17 May 2006 16:41:15 -0600 Received: from ppoq3mim1.QUANTUM.COM ([10.50.2.135]) by ppoq3mim2.QUANTUM.COM with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 May 2006 16:51:50 -0600 Received: from irvq3mbha.QUANTUM.COM ([192.168.3.244]) by ppoq3mim1.QUANTUM.COM with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 May 2006 16:51:50 -0600 Received: from irvq3msg1.QUANTUM.COM ([192.168.3.26]) by irvq3mbha.QUANTUM.COM with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 May 2006 15:51:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: dmapi xfs mount issues Date: Wed, 17 May 2006 15:51:40 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: dmapi xfs mount issues Thread-Index: AcZ6A4XTguutQncgSRKIbhNTBdKYngAAFRCg From: "Tridib Chakravarty" To: X-OriginalArrivalTime: 17 May 2006 22:51:40.0797 (UTC) FILETIME=[763042D0:01C67A04] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id k4HMruwp009317 X-archive-position: 7753 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: Tridib.Chakravarty@quantum.com Precedence: bulk X-list: linux-xfs Content-Length: 5649 Lines: 122 I am working off of the latest xfs tree and am having issues with dmapi. I load xfs-dmapi and then on a mount I get a segfault. Upon turning on debugging, I found that the fs_type that the fs is mounting (xfs) in this case does not find a match to the ftype_list. The debug shows that the list is fine but there probably is an issue with the super block being passed by the xfs send_mount_event. I saw one other guy mention this issue in the archive but I did'nt see an answer. Let me know if somebody can help. Thanks. -tC TRACE STARTS HERE ----------------------------------------------------- May 17 14:27:14 linux kernel: SGI-XFS CVS-2006-05-16_07:00_UTC with ACLs, security attributes, realtime, large block/inode numbers, tracing, debug enab led May 17 14:27:14 linux kernel: xfs_dmapi: module license 'unspecified' taints kernel. May 17 14:27:14 linux kernel: SGI XFS Data Management API subsystem May 17 14:27:14 linux kernel: ftype_list/348: Current ftype_list May 17 14:27:14 linux kernel: ftype_list/351: FS 0xffff8100bb9e84e0, ftype 0xffffffff8834eae0 xfs May 17 14:27:14 linux kernel: ftype_list/353: Done ftype_list May 17 14:27:38 linux kernel: SGI XFS Quota Management subsystem May 17 14:27:38 linux kernel: XFS mounting filesystem hdd1 May 17 14:27:38 linux kernel: Ending clean XFS mount for filesystem: hdd1 May 17 14:27:38 linux kernel: ftype_list/348: Current ftype_list May 17 14:27:38 linux kernel: ftype_list/351: FS 0xffff8100bb9e84e0, ftype 0xffffffff8834eae0 xfs May 17 14:27:38 linux kernel: ftype_list/353: Done ftype_list May 17 14:27:38 linux kernel: sb_list/330: Current sb_list May 17 14:27:38 linux kernel: sb_list/335: Done sb_list May 17 14:27:38 linux kernel: ftype_list/348: Current ftype_list May 17 14:27:38 linux kernel: ftype_list/351: FS 0xffff8100bb9e84e0, ftype 0xffffffff8834eae0 xfs May 17 14:27:38 linux kernel: ftype_list/353: Done ftype_list May 17 14:27:38 linux kernel: DMAPI assertion failed: proto, file: fs/dmapi/dmapi_mountinfo.c, line: 328 May 17 14:27:38 linux kernel: ----------- [cut here ] --------- [please bite here ] --------- May 17 14:27:38 linux kernel: Kernel BUG at fs/dmapi/dmapi_port.h:72 May 17 14:27:38 linux kernel: invalid opcode: 0000 [1] SMP May 17 14:27:38 linux kernel: CPU 0 May 17 14:27:38 linux kernel: Modules linked in: xfs_quota xfs_dmapi xfs dmapi usbserial parport_pc lp parport floppy edd thermal processor fan button battery ac snd_pcm_oss snd_mixer_oss snd_seq_midi snd_seq_midi_event snd_seq snd_ens1371 gameport snd_rawmidi snd_seq_device snd_ac97_codec snd_ac97_bu s snd_pcm snd_timer snd soundcore snd_page_alloc af_packet ip_conntrack_ftp ip_conntrack evdev joydev sg st sd_mod sr_mod scsi_mod ipv6 ohci_hcd i2c_am d8111 i2c_core hw_random dm_mod e100 mii usbcore reiserfs May 17 14:27:38 linux kernel: Pid: 9068, comm: mount Tainted: P 2.6.16 #7 May 17 14:27:38 linux kernel: RIP: 0010:[] {:dmapi:dm_fsys_ops+88} May 17 14:27:38 linux kernel: RSP: 0018:ffff8100be817a08 EFLAGS: 00010296 May 17 14:27:38 linux kernel: RAX: 000000000000004e RBX: ffff81003ab9e4f8 RCX: 000000000003ffff May 17 14:27:38 linux kernel: RDX: 0000000000000000 RSI: 0000000000000292 RDI: ffffffff8040a8c0 May 17 14:27:38 linux kernel: RBP: 0000000000000000 R08: 0000000000000034 R09: 0000000000000002 May 17 14:27:38 linux kernel: R10: 00000000ffffffff R11: 0000000000000000 R12: ffffffff8834e4c0 May 17 14:27:38 linux kernel: R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 May 17 14:27:38 linux kernel: FS: 00002b02b00f24c0(0000) GS:ffffffff8050d000(0000) knlGS:0000000000000000 May 17 14:27:38 linux kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b May 17 14:27:38 linux kernel: CR2: 00002b838901c728 CR3: 00000000bc216000 CR4: 00000000000006e0 May 17 14:27:38 linux kernel: Process mount (pid: 9068, threadinfo ffff8100be816000, task ffff8100beaaf800) May 17 14:27:38 linux kernel: Stack: ffff81003faffa8c 0000000000000001 000000d0bb9e84e0 ffff81003b905000 May 17 14:27:38 linux kernel: ffff81003faffa60 0000000000000010 ffff81003c3cd000 ffff81003ab9e4f8 May 17 14:27:38 linux kernel: ffff81003abbcbb0 ffff81003ab9e528 May 17 14:27:38 linux kernel: Call Trace: {:dmapi:dm_ip_to_handle+42} May 17 14:27:38 linux kernel: {:dmapi:dm_ip_data+249} {:dmapi:dm_send_mount_event+128} May 17 14:27:38 linux kernel: {:xfs:xfs_fs_fill_super+0} {:xfs:xfs_fs_fill_super+0} May 17 14:27:38 linux kernel: {:xfs_dmapi:xfs_dm_mount+237} {:xfs:vfs_mount+133} May 17 14:27:38 linux kernel: {:xfs:xfs_fs_fill_super+152} {__down_write+18} May 17 14:27:38 linux kernel: {strlcpy+78} {get_filesystem+18} May 17 14:27:38 linux kernel: {sget+945} {set_bdev_super+0} May 17 14:27:38 linux kernel: {get_sb_bdev+269} {do_kern_mount+183} May 17 14:27:38 linux kernel: {do_mount+1779} {__up_read+33} May 17 14:27:38 linux kernel: {do_page_fault+1017} {blk_end_sync_rq+0} May 17 14:27:38 linux kernel: {ide_cacheflush_p+105} {__alloc_pages+79} May 17 14:27:38 linux kernel: {__get_free_pages+31} {sys_mount+156} May 17 14:27:38 linux kernel: {system_call+126} May 17 14:27:38 linux kernel: From owner-linux-xfs@oss.sgi.com Wed May 17 16:42:17 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 May 2006 16:42:20 -0700 (PDT) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with SMTP id k4HNeEoS017205 for ; Wed, 17 May 2006 16:42:17 -0700 Received: (qmail 88517 invoked from network); 17 May 2006 23:40:11 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@70.132.6.214 with login) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 17 May 2006 23:40:11 -0000 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 889FD51FAC0; Wed, 17 May 2006 16:40:07 -0700 (PDT) Date: Wed, 17 May 2006 16:40:07 -0700 From: Chris Wedgwood To: "Ed L. Cashin" Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_repair on large fs: out of memory Message-ID: <20060517234007.GA1885@taniwha.stupidest.org> References: <20060517193606.GO32378@coraid.com> <20060517222353.GA32668@taniwha.stupidest.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060517222353.GA32668@taniwha.stupidest.org> X-archive-position: 7754 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: 508 Lines: 13 On Wed, May 17, 2006 at 03:23:53PM -0700, Chris Wedgwood wrote: > I forget the ratio/math for working this out (Steve Lord posted a > summary of this some time ago) but 1GB isn't nearly enough to run > xfs_repair on a moderately sized filesystem. I'm not sure this helps, but you got me thinking and I made a quick test here. On a near empty 13TB fs (I got bored after copying about 20GB of data on to it) I see xfs_repair here use a little under 2GB. Clearly when it's full this number will be higher. From owner-linux-xfs@oss.sgi.com Wed May 17 22:43:44 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 May 2006 22:43:47 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with SMTP id k4I5fehR013319 for ; Wed, 17 May 2006 22:43:42 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA29529 for ; Thu, 18 May 2006 15:41:36 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k4I5fYgw099384 for ; Thu, 18 May 2006 15:41:35 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id k4I5cGu5002281 for ; Thu, 18 May 2006 15:38:17 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id k4I5cGJC002279 for linux-xfs@oss.sgi.com; Thu, 18 May 2006 15:38:16 +1000 Date: Thu, 18 May 2006 15:38:15 +1000 From: Nathan Scott To: linux-xfs@oss.sgi.com Subject: Re: CVS access Message-ID: <20060518053815.GB2224@frodo> 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: 7756 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: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 517 Lines: 18 On Tue, May 16, 2006 at 08:21:27AM +0200, Jan Derfinak wrote: > Last few days I have problem to update kernel from SGI cvs tree. > ... > cvs [update aborted]: read lock failed - giving up Russells fixed this now. BTW, we're about to start merging in changes to xfsprogs to make a threaded version of xfs_repair (and libxfs). So, take the CVS xfsprogs userspace with a pinch of salt for a little while, until that settles down - may be a few weeks till its all merged in and stable once more. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed May 17 23:07:19 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 May 2006 23:07:22 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with SMTP id k4I65ERw015474 for ; Wed, 17 May 2006 23:07:18 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA00055; Thu, 18 May 2006 16:05:06 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id D406F494A268; Thu, 18 May 2006 16:05:04 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 952342 - userspace cache Message-Id: <20060518060504.D406F494A268@chook.melbourne.sgi.com> Date: Thu, 18 May 2006 16:05:04 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7757 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: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1046 Lines: 23 Initial version of a generic cache, which will provide a buffer/inode cache shortly. Uses pthread-based locking for mutex on shared structures. Date: Thu May 18 16:04:39 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: mvalluri,tes The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:25963a xfsprogs/include/list.h - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/list.h xfsprogs/include/cache.h - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/cache.h xfsprogs/libxfs/cache.c - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/cache.c xfsprogs/include/Makefile - 1.27 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/Makefile.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h xfsprogs/libxfs/Makefile - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/Makefile.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h From owner-linux-xfs@oss.sgi.com Wed May 17 23:36:33 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 May 2006 23:36:38 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with SMTP id k4I6YTJR018495 for ; Wed, 17 May 2006 23:36:31 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA00730; Thu, 18 May 2006 16:34:21 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id B8AFC494A26C; Thu, 18 May 2006 16:34:19 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 952342 - xfsprogs surgery Message-Id: <20060518063419.B8AFC494A26C@chook.melbourne.sgi.com> Date: Thu, 18 May 2006 16:34:19 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7758 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: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 5674 Lines: 126 Fix some leaked references on buffers in dabufs in phase6. Date: Thu May 18 16:07:53 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: mvalluri The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:25964a xfsprogs/repair/phase6.c - 1.25 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/phase6.c.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h Fix missed iput on realtime inodes in phase6 of repair. Date: Thu May 18 16:13:34 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: mvalluri The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:25965a xfsprogs/repair/phase6.c - 1.26 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/phase6.c.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h Fix buffer refcount leak on an AGFL buffer. Date: Thu May 18 16:17:18 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: mvalluri The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:25966a xfsprogs/libxfs/xfs_alloc.c - 1.27 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_alloc.c.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h Implement buffer and inode caching in libxfs, groundwork for a parallel version of xfs_repair. Date: Thu May 18 16:19:42 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: mvalluri The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:25967a xfsprogs/mkfs/xfs_mkfs.c - 1.73 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/mkfs/xfs_mkfs.c.diff?r1=text&tr1=1.73&r2=text&tr2=1.72&f=h xfsprogs/include/libxfs.h - 1.47 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/libxfs.h.diff?r1=text&tr1=1.47&r2=text&tr2=1.46&f=h xfsprogs/include/libxlog.h - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/libxlog.h.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h xfsprogs/repair/phase6.c - 1.27 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/phase6.c.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h xfsprogs/repair/xfs_repair.c - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/xfs_repair.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h xfsprogs/repair/scan.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/scan.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h xfsprogs/libxfs/rdwr.c - 1.27 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/rdwr.c.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h xfsprogs/libxfs/xfs.h - 1.56 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs.h.diff?r1=text&tr1=1.56&r2=text&tr2=1.55&f=h xfsprogs/libxfs/trans.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/trans.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h xfsprogs/libxfs/init.c - 1.42 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/init.c.diff?r1=text&tr1=1.42&r2=text&tr2=1.41&f=h xfsprogs/libxfs/xfs_mount.c - 1.24 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_mount.c.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h xfsprogs/libxfs/xfs_inode.c - 1.31 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_inode.c.diff?r1=text&tr1=1.31&r2=text&tr2=1.30&f=h xfsprogs/libxfs/util.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/util.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h Provide a mechanism for batch writeout of buffer cache nodes. Date: Thu May 18 16:23:17 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: mvalluri The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:25968a xfsprogs/libxfs/rdwr.c - 1.28 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/rdwr.c.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h xfsprogs/include/cache.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/cache.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h xfsprogs/libxfs/cache.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/cache.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h Bump xfsprogs version to 2.8.x, fix some minor build issues. Date: Thu May 18 16:32:51 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: mvalluri The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:25970a xfsprogs/VERSION - 1.150 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/VERSION.diff?r1=text&tr1=1.150&r2=text&tr2=1.149&f=h xfsprogs/doc/CHANGES - 1.203 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/doc/CHANGES.diff?r1=text&tr1=1.203&r2=text&tr2=1.202&f=h xfsprogs/debian/changelog - 1.137 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/debian/changelog.diff?r1=text&tr1=1.137&r2=text&tr2=1.136&f=h xfsprogs/libxfs/init.c - 1.43 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/init.c.diff?r1=text&tr1=1.43&r2=text&tr2=1.42&f=h xfsprogs/include/linux.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/linux.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h From owner-linux-xfs@oss.sgi.com Thu May 18 12:06:05 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 May 2006 12:06:08 -0700 (PDT) Received: from slurp.thebarn.com (cattelan-host201.dsl.visi.com [208.42.117.201]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k4IJ43Ap017182 for ; Thu, 18 May 2006 12:06:05 -0700 Received: from [10.0.0.12] (ease.thebarn.com [10.0.0.12]) (authenticated bits=0) by slurp.thebarn.com (8.13.5/8.13.5) with ESMTP id k4IHdiH7035950 for ; Thu, 18 May 2006 12:39:45 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <446CB160.7030808@thebarn.com> Date: Thu, 18 May 2006 12:39:44 -0500 From: Russell Cattelan User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: linux-xfs list name change? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7761 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@thebarn.com Precedence: bulk X-list: linux-xfs Content-Length: 654 Lines: 20 Nathan and I have been talking about changing the name of the "linux-xfs" on oss to just "xfs". Since there is enough interest outside of linux, specfically at the moment the FreeBSD port and possibly the Mac port in the future. We would create an alias that would direct linux-xfs -> xfs so people wouldn't be to lost or confused by the change. The only real change that might have to happen on the part of list members would be any filter rules that key on linux-xfs. Please let us know if this change would cause any great hardships? Also we will probably drop the linux-xfs-announce list since that list has no traffic what-so-ever. -Russell From owner-linux-xfs@oss.sgi.com Thu May 18 17:21:12 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 May 2006 17:21:16 -0700 (PDT) Received: from ty.sabi.co.UK (82-69-39-138.dsl.in-addr.zen.co.uk [82.69.39.138]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k4J0J8tT016722 for ; Thu, 18 May 2006 17:21:12 -0700 Received: from from [127.0.0.1] (helo=base.ty.sabi.co.UK) by ty.sabi.co.UK with esmtp(Exim 4.62 #1) id 1FgVqq-0002Tx-E5 for ; Thu, 18 May 2006 00:54:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17515.47047.714968.295409@base.ty.sabi.co.UK> Date: Thu, 18 May 2006 00:54:47 +0100 X-Face: SMJE]JPYVBO-9UR%/8d'mG.F!@.,l@c[f'[%S8'BZIcbQc3/">GrXDwb#;fTRGNmHr^JFb SAptvwWc,0+z+~p~"Gdr4H$(|N(yF(wwCM2bW0~U?HPEE^fkPGx^u[*[yV.gyB!hDOli}EF[\cW*S H&spRGFL}{`bj1TaD^l/"[ msn( /TH#THs{Hpj>)]f> Subject: Re: xfs_repair on large fs: out of memory In-Reply-To: <20060517222353.GA32668@taniwha.stupidest.org> References: <20060517193606.GO32378@coraid.com> <20060517222353.GA32668@taniwha.stupidest.org> X-Mailer: VM 7.17 under 21.4 (patch 19) XEmacs Lucid From: pg_xfs@xfs.for.sabi.co.UK (Peter Grandi) X-Disclaimer: This message contains only personal opinions X-archive-position: 7762 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: pg_xfs@xfs.for.sabi.co.UK Precedence: bulk X-list: linux-xfs Content-Length: 1286 Lines: 35 >>> On Wed, 17 May 2006 15:23:53 -0700, Chris Wedgwood >>> said: cw> On Wed, May 17, 2006 at 03:36:06PM -0400, Ed L. Cashin cw> wrote: >> Hi. In trying to run xfs_repair on a 13 TB filesystem, I think I am not alone on this list in being very curious how long does the check+repair take. ed> the program either runs out of memory ... [ ... ] This ed> machine has a gigabyte of memory. It's running an x86_64 ed> 2.6.16.13 kernel. Also, how do you backup that filesystem? How long does it take? cw> I forget the ratio/math for working this out (Steve Lord cw> posted a summary of this some time ago) but 1GB isn't nearly cw> enough to run xfs_repair on a moderately sized filesystem. The summary is this one probably, from a little while ago: http://OSS.SGI.com/archives/linux-xfs/2005-08/msg00045.html It suggests that a 13TB filesystem might need from 10 to 20 gigabytes of RAM, after all only less than 0.2% of its size. As a point of order I still think that perhaps one (I could volunteer) should do a mailing list FAQ with a URL to which put at the bottom of every message. But then most people who want help on this list want their answer without wasting their time searching the archive, so probably they would not pointlessly read any FAQ either... From owner-xfs@oss.sgi.com Tue May 23 13:34:28 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 23 May 2006 13:34:32 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1.americas.sgi.com [198.149.16.13]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k4NKYQeZ025609 for ; Tue, 23 May 2006 13:34:27 -0700 Received: from omx2.sgi.com ([198.149.32.25]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k4NJZqnx003709 for ; Tue, 23 May 2006 14:35:53 -0500 Received: from imr2.americas.sgi.com (imr2.americas.sgi.com [198.149.16.18]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k4NLsLDE021819 for ; Tue, 23 May 2006 14:54:21 -0700 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by imr2.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k4NJt07p30662510; Tue, 23 May 2006 12:55:00 -0700 (PDT) Received: from attica.americas.sgi.com (attica.americas.sgi.com [128.162.236.44]) by poppy-e236.americas.sgi.com (8.12.9/ASC-news-1.4) with ESMTP id k4NJZmSQ14100149; Tue, 23 May 2006 14:35:48 -0500 (CDT) Received: by attica.americas.sgi.com (Postfix, from userid 9762) id EEBF610F3336; Tue, 23 May 2006 14:35:47 -0500 (CDT) To: linux-xfs@sgi.com, sgi.bugs.xfs@sgi.com Subject: TAKE 947395 - Fixing potential deadlock in space allocation and freeing due to ENOSPC Message-Id: <20060523193547.EEBF610F3336@attica.americas.sgi.com> Date: Tue, 23 May 2006 14:35:47 -0500 (CDT) From: yingping@sgi.com (Yingping Lu) X-archive-position: 7784 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: yingping@sgi.com Precedence: bulk X-list: xfs Content-Length: 2665 Lines: 51 In actual allocation of file system blocks and freeing extents, the transaction within each such operation may involve multiple locking of AGF buffer. While the freeing extent function has sorted the extents based on AGF number before entering into transaction, however, when the file system space is very limited, the allocation of space would try every AGF to get space allocated, this could potentially cause out-of-order locking, thus deadlock could happen. This fix mitigates the scarce space for allocation by setting aside a few blocks without reservation, and avoid deadlock by maintaining ascending order of AGF locking. Date: Tue May 23 12:28:08 PDT 2006 Workarea: attica.americas.sgi.com:/data/lwork/attica3/yingping/xfs_kern_947395 Inspected by: felixb,nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:210801a xfs_bmap_btree.c - 1.152 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap_btree.c.diff?r1=text&tr1=1.152&r2=text&tr2=1.151&f=h - Ensure no out-of-order locking of AGF in specifying allocation type for calling xfs_alloc_vextent. xfs_mount.c - 1.378 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.378&r2=text&tr2=1.377&f=h - Set aside a few blocks that will not be reserved in delayed allocation. This will mitigate the situation where the allocator has to search for any possible AGF for space when space is very limited. xfs_alloc.c - 1.180 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_alloc.c.diff?r1=text&tr1=1.180&r2=text&tr2=1.179&f=h - Changed xfs_alloc_vextent, xfs_free_extent and xfs_alloc_fix_freelist. In xfs_alloc_vextent, we ensure the locking of AGF from the same transaction does not run out of order by forcing the AGF number is greater than the previous one in the second invocation. In xfs_alloc_fix_freelist, we distinguish the call from xfs_alloc_vextent from xfs_free_extent. Free space checking is enforced for call from xfs_alloc_vextent. xfs_alloc.h - 1.60 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_alloc.h.diff?r1=text&tr1=1.60&r2=text&tr2=1.59&f=h - Add a new flag XFS_ALLOC_FLAG_FREEING to indicate whether the caller is freeing or allocating. Add a field firstblock in structure xfs_alloc_arg to indicate whether this is the first allocation request. xfs_bmap.c - 1.349 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.c.diff?r1=text&tr1=1.349&r2=text&tr2=1.348&f=h - Ensure no out-of-order locking of AGF in specifying allocation type for calling xfs_alloc_vextent. From owner-xfs@oss.sgi.com Tue May 23 15:11:12 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 23 May 2006 15:11:15 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k4NMB8eZ002855 for ; Tue, 23 May 2006 15:11:10 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA28816 for ; Wed, 24 May 2006 08:11:03 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 70DFA4A588C9; Wed, 24 May 2006 08:11:01 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 907752 - Swedish acls Message-Id: <20060523221101.70DFA4A588C9@chook.melbourne.sgi.com> Date: Wed, 24 May 2006 08:11:01 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7786 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 1016 Lines: 22 Swedish translation of acl messages. Thanks to Daniel Nylander, via Debian. Date: Wed May 24 08:10:00 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: nathans,Daniel Nylander The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:26002a acl/po/sv.po - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/po/sv.po acl/VERSION - 1.78 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/VERSION.diff?r1=text&tr1=1.78&r2=text&tr2=1.77&f=h acl/doc/CHANGES - 1.87 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/doc/CHANGES.diff?r1=text&tr1=1.87&r2=text&tr2=1.86&f=h acl/debian/changelog - 1.75 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/debian/changelog.diff?r1=text&tr1=1.75&r2=text&tr2=1.74&f=h acl/po/Makefile - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/po/Makefile.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h From owner-xfs@oss.sgi.com Tue May 23 15:22:47 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 23 May 2006 15:22:55 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k4NMMfeZ004532 for ; Tue, 23 May 2006 15:22:45 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA29096; Wed, 24 May 2006 08:22:28 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k4NMMMgw268596; Wed, 24 May 2006 08:22:23 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k4NMMJVR267553; Wed, 24 May 2006 08:22:19 +1000 (EST) Date: Wed, 24 May 2006 08:22:19 +1000 From: Nathan Scott To: Jan Engelhardt Cc: xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: XFS write speed drop Message-ID: <20060524082218.A267844@wobbly.melbourne.sgi.com> References: <20060522105326.A212600@wobbly.melbourne.sgi.com> <20060523084309.A239136@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jengelh@linux01.gwdg.de on Tue, May 23, 2006 at 03:23:31PM +0200 X-archive-position: 7787 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 1085 Lines: 27 On Tue, May 23, 2006 at 03:23:31PM +0200, Jan Engelhardt wrote: > >> CASE 1: Copying from one disk to another > >> ======================================== > >> Copying a compiled 2.6.17-rc4 tree; 306907 KB in 28566 files in 2090 > >> directories. > > > >OK, we can call this a metadata intensive workload - lots of small > >files, lots of creates. Barriers will hurt the most here, as we'd > >already have been log I/O bound most likely, and I'd expect barriers > >to only slow that further. > > > Yes and the most important thing is that someone made -o barrier the > default and did not notice. Someone else? :-D Not sure what you're trying to say here. Yes, barriers are on by default now if the hardware supports them, yes, they will slow things down relative to write-cache-without-barriers, and yes we all knew that ... its not the case that someone "did not notice" or forgot about something. There is no doubt that this is the right thing to be doing by default - there's no way that I can tell from inside XFS in the kernel that you have a UPS. ;) cheers. -- Nathan From owner-xfs@oss.sgi.com Tue May 23 16:18:19 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 23 May 2006 16:18:22 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k4NNIEeZ009386 for ; Tue, 23 May 2006 16:18:17 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA00447; Wed, 24 May 2006 09:17:52 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k4NNHkgw269637; Wed, 24 May 2006 09:17:49 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k4NNHgx0268287; Wed, 24 May 2006 09:17:42 +1000 (EST) Date: Wed, 24 May 2006 09:17:41 +1000 From: Nathan Scott To: Jan Engelhardt Cc: xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: XFS write speed drop Message-ID: <20060524091741.D267844@wobbly.melbourne.sgi.com> References: <20060522105326.A212600@wobbly.melbourne.sgi.com> <20060523084309.A239136@wobbly.melbourne.sgi.com> <20060524082218.A267844@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060524082218.A267844@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Wed, May 24, 2006 at 08:22:19AM +1000 X-archive-position: 7788 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 1532 Lines: 38 On Wed, May 24, 2006 at 08:22:19AM +1000, Nathan Scott wrote: > On Tue, May 23, 2006 at 03:23:31PM +0200, Jan Engelhardt wrote: > > >> CASE 1: Copying from one disk to another > > >> ======================================== > > >> Copying a compiled 2.6.17-rc4 tree; 306907 KB in 28566 files in 2090 > > >> directories. > > > > > >OK, we can call this a metadata intensive workload - lots of small > > >files, lots of creates. Barriers will hurt the most here, as we'd > > >already have been log I/O bound most likely, and I'd expect barriers > > >to only slow that further. > > > > > Yes and the most important thing is that someone made -o barrier the > > default and did not notice. Someone else? :-D > > Not sure what you're trying to say here. Yes, barriers are on > by default now if the hardware supports them, yes, they will > slow things down relative to write-cache-without-barriers, and > yes we all knew that ... its not the case that someone "did not > notice" or forgot about something. There is no doubt that this > is the right thing to be doing by default - there's no way that > I can tell from inside XFS in the kernel that you have a UPS. ;) Oh, I realised I've slightly misread your mail, you said... | I do not actually need barriers (or an UPS, to poke on another thread), | because power failures are rather rare in Germany. Hmm, even harder for us to detect at runtime, in the kernel, that you're in Germany. :) Power failures aren't the only thing to cause crashes, however. cheers. -- Nathan From owner-xfs@oss.sgi.com Tue May 23 18:41:50 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 23 May 2006 18:41:54 -0700 (PDT) Received: from cyrus.iparadigms.com (cyrus.iparadigms.com [64.140.48.8]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k4O1fneZ029621 for ; Tue, 23 May 2006 18:41:50 -0700 Received: from localhost (unknown [127.0.0.1]) by cyrus.iparadigms.com (Postfix) with ESMTP id C2C945FADF0; Tue, 23 May 2006 18:41:43 -0700 (PDT) Received: from cyrus.iparadigms.com ([127.0.0.1]) by localhost (cyrus.iparadigms.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21075-07; Tue, 23 May 2006 18:41:37 -0700 (PDT) Received: from [192.168.51.36] (209-209-36-196.static.oak.inreach.net [209.209.36.196]) by cyrus.iparadigms.com (Postfix) with ESMTP id C16E35FADED; Tue, 23 May 2006 18:41:36 -0700 (PDT) Message-ID: <4473B9D0.5040602@iparadigms.com> Date: Tue, 23 May 2006 18:41:36 -0700 From: fitzboy User-Agent: Mozilla Thunderbird 0.9 (X11/20041124) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nathan Scott CC: linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: tuning for large files in xfs References: <447209A8.2040704@iparadigms.com> <20060523085116.B239136@wobbly.melbourne.sgi.com> <44725C27.90601@iparadigms.com> <20060523115938.A242207@wobbly.melbourne.sgi.com> In-Reply-To: <20060523115938.A242207@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7789 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: fitzboy@iparadigms.com Precedence: bulk X-list: xfs Content-Length: 5275 Lines: 125 Nathan Scott wrote: > Hi Tim, > > On Mon, May 22, 2006 at 05:49:43PM -0700, fitzboy wrote: > >>Nathan Scott wrote: >> >>>Can you send xfs_info output for the filesystem and the output >>>from xfs_bmap -vvp on this file? >> >>xfs_info: >>meta-data=/mnt/array/disk1 isize=2048 agcount=410, agsize=524288 > > > Thats odd - why such a large number of allocation groups? I read online in multiple places that the largest allocation groups should get is 4g, so I made mine 2g. However, having said that, I did test with different allocation sizes and the effect was not that dramatic. I will retest again though, just to verify. I was also thinking that the more AGs the better since I do a lot of parallel reads/writes... granted it doesn't change the file system all that much (the file only grows or get existing blocks get modified), so I am not sure if the number of AGs matter, does it? >>meta-data=/mnt/array/disk1 isize=2048 agcount=410, agsize=524288 blks >> = sectsz=512 >>data = bsize=4096 blocks=214670562, imaxpct=25 >> = sunit=16 swidth=192 blks, unwritten=1 >>naming =version 2 bsize=4096 >>log =internal bsize=4096 blocks=8192, version=1 >> = sectsz=512 sunit=0 blks >>realtime =none extsz=65536 blocks=0, rtextents=0 >> >>it is mounted rw,noatime,nodiratime >>generally I am doing 32k reads from the application, so I would like >>larger blocksize (32k would be ideal), but can't go above 2k on intel... > > > 4K you mean (thats what you've got above, and thats your max with > a 4K pagesize). > Sorry, I meant that moving the Inode size to 2k (over 256bytes) gave me a sizeable increase in performance... I assume that is because the extent map can be smaller now (since blocks are much larger, less blocks to keep track of). Of course, ideal would be to have InodeSize be large and blocksize to be 32k... but I hit the limits on both... > I thought you said you had a 2TB file? The filesystem above is > 4096 * 214670562 blocks, i.e. 818GB. Perhaps its a sparse file? > I guess I could look closer at the bmap and figure that out for > myself. ;) On my production servers the file is 2TB, but on this testing enviroment I have, the file is only 767G of a 819G partition... This is sufficient to tell because the performance is already hindered alot even at 767G, going to 2TB just makes it worse... >>I made the file my copying it over via dd from another machine onto a >>clean partition... then from that point we just append to the end of it, >>or modify existing data... > > >>I am attaching the extent map > > > Interesting. So, the allocator did an OK job for you, at least > initially - everything is contiguous (within the bounds of the > small agsize you set) until extent #475, and I guess that'd have > been the end of the initial copied file. After that it chops > about a bit (goes back to earlier AGs and uses the small amounts > of space in each I'm guessing), then gets back into nice long > contiguous extent allocations in the high AGs. > > Anyway, you should be able to alleviate the problem by: > > - Using a small number of larger AGs (say 32 or so) instead of > a large number of small AGs. this'll give you most bang for > your buck I expect. > [ If you use a mkfs.xfs binary from an xfsprogs anytime since > November 2003, this will automatically scale for you - did you > use a very old mkfs? Or set the agcount/size values by hand? > Current mkfs would give you this: > # mkfs.xfs -isize=2k -dfile,name=/dev/null,size=214670562b -N > meta-data=/dev/null isize=2048 agcount=32, agsize=6708455 blks > ...which is just what you want here. ] I set it by hand. I rebuilt the partition and am now copying over the file again to see the results... > > - Preallocate the space in the file - i.e. before running the > dd you can do an "xfs_io -c 'resvsp 0 2t' /mnt/array/disk1/xxx" > (preallocates 2 terabytes) and then overwrite that. Yhis will > give you an optimal layout. I tried this a couple of times, but it seemed to wedge the machine... I would do: 1) touch a file (just to create it), 2) do the above command which would then show effect in du, but the file size was still 0 3) I then opened that file (without O_TRUNC or O_APPEND) and started to write out to it. It would work fine for a few minutes but after about 5 or 7GB the machine would freeze... nothing in syslog, only a brief message on console about come cpu state being bad... > > - Not sure about your stripe unit/width settings, I would need > to know details about your RAID. But maybe theres tweaking that > could be done there too. stripe unit is 64k, array is a RAID5 with 14 disks, so I say sw=13 (one disk is parity). I set this when I made the array, though it doesn't seem to matter much either. > > - Your extent map is fairly large, the 2.6.17 kernel will have > some improvements in the way the memory management is done here > which may help you a bit too. > we have plenty of memory on the machines, shouldn't be an issue... I am a little cautious about moving to a new kernel though... From owner-xfs@oss.sgi.com Tue May 23 19:24:18 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 23 May 2006 19:24:21 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k4O2OEeZ000934 for ; Tue, 23 May 2006 19:24:16 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA04875; Wed, 24 May 2006 12:23:59 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k4O2Nugw272455; Wed, 24 May 2006 12:23:56 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k4O2NoNd273777; Wed, 24 May 2006 12:23:50 +1000 (EST) Date: Wed, 24 May 2006 12:23:50 +1000 From: Nathan Scott To: fitzboy Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: tuning for large files in xfs Message-ID: <20060524122350.J270972@wobbly.melbourne.sgi.com> References: <447209A8.2040704@iparadigms.com> <20060523085116.B239136@wobbly.melbourne.sgi.com> <44725C27.90601@iparadigms.com> <20060523115938.A242207@wobbly.melbourne.sgi.com> <4473B9D0.5040602@iparadigms.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4473B9D0.5040602@iparadigms.com>; from fitzboy@iparadigms.com on Tue, May 23, 2006 at 06:41:36PM -0700 X-archive-position: 7790 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 2557 Lines: 60 On Tue, May 23, 2006 at 06:41:36PM -0700, fitzboy wrote: > I read online in multiple places that the largest allocation groups > should get is 4g, Thats not correct (for a few years now). > I was also thinking that the more AGs the better since I do a lot of > parallel reads/writes... granted it doesn't change the file system all > that much (the file only grows or get existing blocks get modified), so > I am not sure if the number of AGs matter, does it? Yes, it can matter. For large extents like you have here, AGs introduce a discontinuity that you'd otherwise not have. > Sorry, I meant that moving the Inode size to 2k (over 256bytes) gave me > a sizeable increase in performance... I assume that is because the > extent map can be smaller now (since blocks are much larger, less blocks > to keep track of). Of course, ideal would be to have InodeSize be large > and blocksize to be 32k... but I hit the limits on both... It means that more extents/btree records fit inline in the inode, as theres more space available after the stat data. 2k is your best choice for inode size, stick with that. > > - Preallocate the space in the file - i.e. before running the > > dd you can do an "xfs_io -c 'resvsp 0 2t' /mnt/array/disk1/xxx" > > (preallocates 2 terabytes) and then overwrite that. Yhis will > > give you an optimal layout. > > I tried this a couple of times, but it seemed to wedge the machine... I > would do: 1) touch a file (just to create it), 2) do the above command Oh, use the -f (create) option and you won't need a touch. > which would then show effect in du, but the file size was still 0 3) I > then opened that file (without O_TRUNC or O_APPEND) and started to write > out to it. It would work fine for a few minutes but after about 5 or 7GB > the machine would freeze... nothing in syslog, only a brief message on > console about come cpu state being bad... Hmm - I'd be interested to hear if that happens with a recent kernel. > > - Your extent map is fairly large, the 2.6.17 kernel will have > > some improvements in the way the memory management is done here > > which may help you a bit too. > > we have plenty of memory on the machines, shouldn't be an issue... I am > a little cautious about moving to a new kernel though... Its not the amount of memory that was the issue here, its more the way we were using it that was a problem for kernels of the vintage you're using here. You will definately see better performance in a 2.6.17 kernel with that large extent map. cheers. -- Nathan From owner-xfs@oss.sgi.com Tue May 23 20:47:43 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 23 May 2006 20:47:47 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k4O3ldeZ012754 for ; Tue, 23 May 2006 20:47:41 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA06627; Wed, 24 May 2006 13:47:22 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 778AE4A588C9; Wed, 24 May 2006 13:47:22 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 953212 - fsr vs dir arguments Message-Id: <20060524034722.778AE4A588C9@chook.melbourne.sgi.com> Date: Wed, 24 May 2006 13:47:22 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7791 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 497 Lines: 15 Fix fsr handling of directory argument, using strcmp on paths is bad. Debian bug 368423. Date: Wed May 24 13:47:02 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: bnaujok The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:26006a xfsdump/fsr/xfs_fsr.c - 1.25 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/fsr/xfs_fsr.c.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h From owner-xfs@oss.sgi.com Tue May 23 20:53:46 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 23 May 2006 20:53:51 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k4O3reeZ013344 for ; Tue, 23 May 2006 20:53:44 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA06714; Wed, 24 May 2006 13:53:30 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 5853E4A588C9; Wed, 24 May 2006 13:53:28 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 953213 - xfsdump builds Message-Id: <20060524035328.5853E4A588C9@chook.melbourne.sgi.com> Date: Wed, 24 May 2006 13:53:28 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7792 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 9175 Lines: 127 Update xfsdump build to use xfs.h instead of libxfs.h, fixing a recent namespace collision on list symbols. Date: Wed May 24 13:53:01 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: tes The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:26007a xfsdump/include/swap.h - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/include/swap.h xfsdump/fsr/xfs_fsr.c - 1.26 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/fsr/xfs_fsr.c.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h xfsdump/dump/var.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/dump/var.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h xfsdump/dump/content.c - 1.41 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/dump/content.c.diff?r1=text&tr1=1.41&r2=text&tr2=1.40&f=h xfsdump/dump/inomap.c - 1.25 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/dump/inomap.c.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h xfsdump/include/Makefile - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/include/Makefile.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h xfsdump/restore/mmap.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/restore/mmap.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h xfsdump/restore/namreg.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/restore/namreg.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h xfsdump/restore/node.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/restore/node.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h xfsdump/restore/tree.c - 1.31 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/restore/tree.c.diff?r1=text&tr1=1.31&r2=text&tr2=1.30&f=h xfsdump/restore/bag.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/restore/bag.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h xfsdump/restore/content.c - 1.45 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/restore/content.c.diff?r1=text&tr1=1.45&r2=text&tr2=1.44&f=h xfsdump/restore/dirattr.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/restore/dirattr.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h xfsdump/restore/win.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/restore/win.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h xfsdump/restore/inomap.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/restore/inomap.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h xfsdump/invutil/invutil.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/invutil/invutil.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h xfsdump/inventory/inv_core.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/inventory/inv_core.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h xfsdump/inventory/testmain.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/inventory/testmain.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h xfsdump/inventory/inv_oref.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/inventory/inv_oref.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h xfsdump/inventory/inv_stobj.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/inventory/inv_stobj.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h xfsdump/inventory/inv_mgr.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/inventory/inv_mgr.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h xfsdump/inventory/inv_fstab.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/inventory/inv_fstab.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h xfsdump/inventory/inv_files.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/inventory/inv_files.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h xfsdump/inventory/inv_api.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/inventory/inv_api.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h xfsdump/inventory/inv_idx.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/inventory/inv_idx.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h xfsdump/librmt/rmtlib.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/librmt/rmtlib.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h xfsdump/librmt/rmtioctl.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/librmt/rmtioctl.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h xfsdump/common/content_common.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/content_common.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h xfsdump/common/stream.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/stream.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h xfsdump/common/global.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/global.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h xfsdump/common/openutil.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/openutil.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h xfsdump/common/drive.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/drive.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h xfsdump/common/fs.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/fs.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h xfsdump/common/mlog.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/mlog.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h xfsdump/common/dlog.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/dlog.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h xfsdump/common/ring.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/ring.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h xfsdump/common/media.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/media.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h xfsdump/common/path.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/path.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h xfsdump/common/arch_xlate.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/arch_xlate.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h xfsdump/common/arch_xlate.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/arch_xlate.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h xfsdump/common/drive_scsitape.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/drive_scsitape.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h xfsdump/common/lock.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/lock.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h xfsdump/common/qlock.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/qlock.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h xfsdump/common/util.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/util.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h xfsdump/common/cldmgr.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/cldmgr.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h xfsdump/common/drive_minrmt.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/drive_minrmt.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h xfsdump/common/main.c - 1.31 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/main.c.diff?r1=text&tr1=1.31&r2=text&tr2=1.30&f=h xfsdump/common/drive_simple.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/drive_simple.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h xfsdump/invutil/list.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/invutil/list.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h xfsdump/invutil/stobj.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/invutil/stobj.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h xfsdump/invutil/screen.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/invutil/screen.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h xfsdump/invutil/menu.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/invutil/menu.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h xfsdump/invutil/cmenu.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/invutil/cmenu.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h xfsdump/invutil/fstab.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/invutil/fstab.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h xfsdump/invutil/invidx.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/invutil/invidx.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h xfsdump/common/hsmapi.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/hsmapi.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h xfsdump/common/hsmapi.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/hsmapi.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h From owner-xfs@oss.sgi.com Tue May 23 23:21:25 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 23 May 2006 23:22:29 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k4O6LLeZ025471 for ; Tue, 23 May 2006 23:21:23 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA08686; Wed, 24 May 2006 15:20:54 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k4O5Knh37442798; Wed, 24 May 2006 15:20:49 +1000 (AEST) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k4O5KlJ47446902; Wed, 24 May 2006 15:20:47 +1000 (AEST) Date: Wed, 24 May 2006 15:20:47 +1000 (AEST) From: Timothy Shimmin Message-Id: <200605240520.k4O5KlJ47446902@snort.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE 952214 - log recovery compat on 32/64 bit X-archive-position: 7793 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@snort.melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 1962 Lines: 44 The change here is to allow a dirty log XFS filesystem be replayed on a same endian machine but of different word size (eg. i386 and x86_64). --Tim inode items and EFI/EFDs have different ondisk format for 32bit and 64bit kernels allow recovery to handle both versions and do the necessary decoding Date: Wed May 24 15:09:04 AEST 2006 Workarea: snort.melbourne.sgi.com:/home/tes/isms/xfs-linux-3264 Inspected by: nathans@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26011a xfs_extfree_item.h - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_extfree_item.h.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h - 32 and 64 bit variants of the EFIs and EFDs format structures. At the moment, the EFD format variants are just used to test if the data on recovery is of a valid size. xfs_extfree_item.c - 1.63 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_extfree_item.c.diff?r1=text&tr1=1.63&r2=text&tr2=1.62&f=h - Code to convert the 32 bit and 64 bit versions of EFIs to the native version. We don't convert the EFDs extents because their extents are never used. xfs_inode_item.c - 1.126 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode_item.c.diff?r1=text&tr1=1.126&r2=text&tr2=1.125&f=h - Code to convert the 32 bit and 64 bit versions of inode_log_format structures. xfs_inode_item.h - 1.48 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode_item.h.diff?r1=text&tr1=1.48&r2=text&tr2=1.47&f=h - 32 and 64 bit variants of the inode log format structures. Delete the structure for the v1 variant which was used on IRIX 5.3. xfs_log_recover.c - 1.308 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_recover.c.diff?r1=text&tr1=1.308&r2=text&tr2=1.307&f=h - Decode the inode log format structs for recovery. Decode the EFI log format structs for recovery. From owner-xfs@oss.sgi.com Wed May 24 00:41:28 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 24 May 2006 00:41:37 -0700 (PDT) Received: from ext.storadinc.com (64.221.212.177.ptr.us.xo.net [64.221.212.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k4O7fPeZ003986 for ; Wed, 24 May 2006 00:41:27 -0700 Received: from agami.com ([192.168.168.101]) by ext.storadinc.com (8.12.5/8.12.5) with ESMTP id k4O6bNno012688 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 23 May 2006 23:37:23 -0700 Received: from mx1.agami.com (mx1.agami.com [10.123.10.30]) by agami.com (8.12.11/8.12.11) with ESMTP id k4O6bIFZ020813 for ; Tue, 23 May 2006 23:37:18 -0700 Received: from [10.12.12.141] ([10.12.12.141]) by mx1.agami.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 May 2006 23:37:17 -0700 Message-ID: <4473FDA1.4070805@agami.com> Date: Wed, 24 May 2006 12:00:57 +0530 From: Shailendra Tripathi User-Agent: Mozilla Thunderbird 0.9 (X11/20041127) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Timothy Shimmin CC: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: Re: TAKE 952214 - log recovery compat on 32/64 bit References: <200605240520.k4O5KlJ47446902@snort.melbourne.sgi.com> In-Reply-To: <200605240520.k4O5KlJ47446902@snort.melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 May 2006 06:37:17.0573 (UTC) FILETIME=[80487B50:01C67EFC] X-Scanned-By: MIMEDefang 2.36 X-archive-position: 7794 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: stripathi@agami.com Precedence: bulk X-list: xfs Content-Length: 4239 Lines: 98 Hi Tim, There is another problem in XFS recovery on non-XFS native endian machines. xlog_recover_do_inode_buffer () { .... logged_nextp = (xfs_agino_t *) ((char *)(item->ri_buf[item_index].i_addr) + (next_unlinked_offset -reg_buf_offset)); ... buffer_nextp = (xfs_agino_t *)xfs_buf_offset(bp, next_unlinked_offset); INT_SET(*buffer_nextp, ARCH_CONVERT, *logged_nextp); } Please note that all the fields in the log (rather all the data in the log) is already converted into proper endian format. However, INT_SET(*buffer_nextp, ARCH_CONVERT, *logged_nextp); converts it again which is wrong. It should be ARCH_NOCONVERT here. Here is why, then we don't see any problem in recovery: xlog_recover_process_iunlinks () ... } else { xlog_recover_clear_agi_bucket(mp, agno, bucket); agino = NULLAGINO; } This code assumes that if you detect any bad inode, just clear off the AGI unlinked tree. I have seen this code been hit in recovery. It has potential of loosing the inode and corresponding data blocks forever. The xfs_logprint shows CLEAR_AGI_BUCKET after recovery once in a while. The code assumes this to be bad inode. However, the truth is that most of the time this has been done because of double native conversion. I have patch for it on pretty old build (2.6.7) and, hence, not submitting. Regards, Shailendra Timothy Shimmin wrote: > The change here is to allow a dirty log XFS filesystem be replayed on a same > endian machine but of different word size (eg. i386 and x86_64). > > > --Tim > > inode items and EFI/EFDs have different ondisk format for 32bit and 64bit kernels > allow recovery to handle both versions and do the necessary decoding > > Date: Wed May 24 15:09:04 AEST 2006 > Workarea: snort.melbourne.sgi.com:/home/tes/isms/xfs-linux-3264 > Inspected by: nathans@sgi.com > > The following file(s) were checked into: > longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb > > > Modid: xfs-linux-melb:xfs-kern:26011a > xfs_extfree_item.h - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/> xfs_extfree_item.h.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h > http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_extfree_item.h.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h > - 32 and 64 bit variants of the EFIs and EFDs format structures. > At the moment, the EFD format variants are just used to test if the > data on recovery is of a valid size. > > xfs_extfree_item.c - 1.63 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/> xfs_extfree_item.c.diff?r1=text&tr1=1.63&r2=text&tr2=1.62&f=h > http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_extfree_item.c.diff?r1=text&tr1=1.63&r2=text&tr2=1.62&f=h > - Code to convert the 32 bit and 64 bit versions of EFIs to the native version. > We don't convert the EFDs extents because their extents are never used. > > xfs_inode_item.c - 1.126 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/> xfs_inode_item.c.diff?r1=text&tr1=1.126&r2=text&tr2=1.125&f=h > http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode_item.c.diff?r1=text&tr1=1.126&r2=text&tr2=1.125&f=h > - Code to convert the 32 bit and 64 bit versions of inode_log_format structures. > > xfs_inode_item.h - 1.48 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/> xfs_inode_item.h.diff?r1=text&tr1=1.48&r2=text&tr2=1.47&f=h > http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode_item.h.diff?r1=text&tr1=1.48&r2=text&tr2=1.47&f=h > - 32 and 64 bit variants of the inode log format structures. > Delete the structure for the v1 variant which was used on IRIX 5.3. > > xfs_log_recover.c - 1.308 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/> xfs_log_recover.c.diff?r1=text&tr1=1.308&r2=text&tr2=1.307&f=h > http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_recover.c.diff?r1=text&tr1=1.308&r2=text&tr2=1.307&f=h > - Decode the inode log format structs for recovery. > Decode the EFI log format structs for recovery. > > > From owner-xfs@oss.sgi.com Wed May 24 01:19:28 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 24 May 2006 01:19:35 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1.americas.sgi.com [198.149.16.13]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k4O8JReZ007315 for ; Wed, 24 May 2006 01:19:28 -0700 Received: from imr2.americas.sgi.com (imr2.americas.sgi.com [198.149.16.18]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k4O7GInx027023 for ; Wed, 24 May 2006 02:16:18 -0500 Received: from omx2.sgi.com ([198.149.32.25]) by imr2.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k4O7ZT7p30739925 for ; Wed, 24 May 2006 00:35:29 -0700 (PDT) Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k4O9Ypar017764 for ; Wed, 24 May 2006 02:34:51 -0700 Received: from omx2.sgi.com ([198.149.32.25]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k4O7GF8s7343651 for ; Wed, 24 May 2006 00:16:15 -0700 (PDT) Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k4O9Ynfj017761 for ; Wed, 24 May 2006 02:34:49 -0700 Received: from omx2.sgi.com ([198.149.32.25]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k4O7GC8s7344311 for ; Wed, 24 May 2006 00:16:12 -0700 (PDT) Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k4O9YkUV017755 for ; Wed, 24 May 2006 02:34:46 -0700 Received: from omx2.sgi.com ([198.149.32.25]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k4O7G98s7344665 for ; Wed, 24 May 2006 00:16:09 -0700 (PDT) Received: from classic.engr.sgi.com (classic.engr.sgi.com [163.154.5.111]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k4O9YiLK017751 for ; Wed, 24 May 2006 02:34:44 -0700 Received: from classic.engr.sgi.com (localhost [127.0.0.1]) by classic.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k4O7G10q586781; Wed, 24 May 2006 00:16:01 -0700 (PDT) Received: (from jeremy@localhost) by classic.engr.sgi.com (SGI-8.12.5/8.12.5/Submit) id k4O7G18N586860; Wed, 24 May 2006 00:16:01 -0700 (PDT) Date: Wed, 24 May 2006 00:16:00 -0700 From: Jeremy Higdon To: Nathan Scott Cc: Jan Engelhardt , xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: XFS write speed drop Message-ID: <20060524071600.GF586512@sgi.com> References: <20060522105326.A212600@wobbly.melbourne.sgi.com> <20060523084309.A239136@wobbly.melbourne.sgi.com> <20060524082218.A267844@wobbly.melbourne.sgi.com> <20060524091741.D267844@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060524091741.D267844@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.1i X-archive-position: 7795 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jeremy@SGI.com Precedence: bulk X-list: xfs Content-Length: 1301 Lines: 29 On Wed, May 24, 2006 at 09:17:41AM +1000, Nathan Scott wrote: > On Wed, May 24, 2006 at 08:22:19AM +1000, Nathan Scott wrote: > > > > Not sure what you're trying to say here. Yes, barriers are on > > by default now if the hardware supports them, yes, they will > > slow things down relative to write-cache-without-barriers, and > > yes we all knew that ... its not the case that someone "did not > > notice" or forgot about something. There is no doubt that this > > is the right thing to be doing by default - there's no way that > > I can tell from inside XFS in the kernel that you have a UPS. ;) > > Oh, I realised I've slightly misread your mail, you said... > > | I do not actually need barriers (or an UPS, to poke on another thread), > | because power failures are rather rare in Germany. > > Hmm, even harder for us to detect at runtime, in the kernel, > that you're in Germany. :) > > Power failures aren't the only thing to cause crashes, however. There have been several examples of filesystem corruption without power failures too, though that is a common cause. It can even happen on a normal system shutdown if there is no synchronize operation to the disk at shutdown time, depending on how much data is in the cache and how long you have until the ATA chip is reset. jeremy From owner-xfs@oss.sgi.com Wed May 24 23:51:18 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 24 May 2006 23:52:26 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k4P6pDeZ010413 for ; Wed, 24 May 2006 23:51:15 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA09516; Thu, 25 May 2006 15:46:24 +1000 From: Timothy Shimmin Organization: SGI To: Shailendra Tripathi Subject: Re: TAKE 952214 - log recovery compat on 32/64 bit Date: Thu, 25 May 2006 15:42:48 +1000 User-Agent: KMail/1.8.2 Cc: linux-xfs@oss.sgi.com References: <200605240520.k4O5KlJ47446902@snort.melbourne.sgi.com> <4473FDA1.4070805@agami.com> In-Reply-To: <4473FDA1.4070805@agami.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605251542.48716.tes@sgi.com> X-archive-position: 7797 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Content-Length: 2737 Lines: 74 Hi Shailendra, On Wednesday 24 May 2006 4:30 pm, Shailendra Tripathi wrote: > Hi Tim, > There is another problem in XFS recovery on non-XFS native > endian machines. > That's no good. > xlog_recover_do_inode_buffer () { > .... > logged_nextp = (xfs_agino_t *) > ((char *)(item->ri_buf[item_index].i_addr) + > (next_unlinked_offset -reg_buf_offset)); > ... > > buffer_nextp = (xfs_agino_t *)xfs_buf_offset(bp, > next_unlinked_offset); > INT_SET(*buffer_nextp, ARCH_CONVERT, *logged_nextp); > } > > Please note that all the fields in the log (rather all the data in the > log) is already converted into proper endian format. However, > > INT_SET(*buffer_nextp, ARCH_CONVERT, *logged_nextp); > converts it again which is wrong. It should be ARCH_NOCONVERT here. > Okay, I had a better look at the code, and I see what you mean. The di_next_unlinked field is always stored endian converted. It has to be converted to native only when it is used to find the inode that it is pointing to by its agino#. So in the case above, we are extracting out the already endian converted di_next_unlinked field from the logged region data and endian converting it again and then storing back into the di_next_field of the buffer of inodes. Which will flip it back to native, when we really want it to remain in ondisk format. Yes, we should just be doing a straight assignment here as we do in IRIX. > > Here is why, then we don't see any problem in recovery: > > xlog_recover_process_iunlinks () > ... > } else { > > xlog_recover_clear_agi_bucket(mp, agno, > bucket); > agino = NULLAGINO; > } > > This code assumes that if you detect any bad inode, just clear off the > AGI unlinked tree. Or the list off the AGI unlinked bucket. Yep. > I have seen this code been hit in recovery. It has > potential of loosing the inode and corresponding data blocks forever. > > The xfs_logprint shows CLEAR_AGI_BUCKET after recovery once in a while. Yeah that's no good but it is good evidence of the problem. > The code assumes this to be bad inode. However, the truth is that most > of the time this has been done because of double native conversion. > I have patch for it on pretty old build (2.6.7) and, hence, not submitting. > Feel free to submit any old patches that you have and just state for which release. They would be most appreciated. In this case, the recovery code hasn't probably changed much either and the patch is a simple one :) Thanks a lot for pointing this out, I'll check this fix in soon. Kind regards, Tim. From owner-xfs@oss.sgi.com Thu May 25 03:21:19 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 25 May 2006 03:21:22 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k4PALDeZ030508 for ; Thu, 25 May 2006 03:21:15 -0700 Received: from SGIGORT (mtv-vpn-sw-corp-0-22.corp.sgi.com [134.15.0.22]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA13371; Thu, 25 May 2006 19:17:06 +1000 Reply-To: From: "Mike Gigante" To: "'Timothy Shimmin'" , "'Shailendra Tripathi'" Cc: Subject: RE: TAKE 952214 - log recovery compat on 32/64 bit Date: Thu, 25 May 2006 19:16:55 +1000 Organization: Fileserving Technologies Message-ID: <00d501c67fdb$fceaa7c0$0e370e86@SGIGORT> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZ/yNMwhxAOEzaMRtusenFCFObetAAEvzMg In-Reply-To: <200605251542.48716.tes@sgi.com> X-archive-position: 7798 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mg@sgi.com Precedence: bulk X-list: xfs Content-Length: 256 Lines: 9 > Feel free to submit any old patches that you have and > just state for which release. They would be most appreciated. Also, it would be good to provide test cases which you used to reproduce the initial problem and verify the fix was correct. Mike From owner-xfs@oss.sgi.com Thu May 25 12:15:51 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 25 May 2006 12:15:55 -0700 (PDT) Received: from cyrus.iparadigms.com (cyrus.iparadigms.com [64.140.48.8]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k4PJFmeZ026278 for ; Thu, 25 May 2006 12:15:50 -0700 Received: from localhost (unknown [127.0.0.1]) by cyrus.iparadigms.com (Postfix) with ESMTP id 68C405D6070; Thu, 25 May 2006 12:15:40 -0700 (PDT) Received: from cyrus.iparadigms.com ([127.0.0.1]) by localhost (cyrus.iparadigms.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94159-08; Thu, 25 May 2006 12:15:33 -0700 (PDT) Received: from [192.168.51.36] (209-209-36-196.static.oak.inreach.net [209.209.36.196]) by cyrus.iparadigms.com (Postfix) with ESMTP id A00EE5BEFD0; Thu, 25 May 2006 12:15:33 -0700 (PDT) Message-ID: <44760255.2090408@iparadigms.com> Date: Thu, 25 May 2006 12:15:33 -0700 From: fitzboy User-Agent: Mozilla Thunderbird 0.9 (X11/20041124) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nathan Scott CC: linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: tuning for large files in xfs References: <447209A8.2040704@iparadigms.com> <20060523085116.B239136@wobbly.melbourne.sgi.com> <44725C27.90601@iparadigms.com> <20060523115938.A242207@wobbly.melbourne.sgi.com> <4473B9D0.5040602@iparadigms.com> <20060524122350.J270972@wobbly.melbourne.sgi.com> In-Reply-To: <20060524122350.J270972@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7800 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: fitzboy@iparadigms.com Precedence: bulk X-list: xfs Content-Length: 4083 Lines: 108 here are the results: under 2.6.8 kernel with agsize=2g (440 some AGs): 6.9ms avg access under 2.6.8 kernel with agcount=32: 6.2ms under 2.6.17 kernel with partition made in 2.6.8 with agcount=32: 6.2ms under 2.6.17 kernel just reading from /dev/sdb1: 6.2ms under 2.6.17 kernel with new partition (made under 2.6.17) with agcount=32, file created via the xfs_io reserve call: 6.9 ms under 2.6.17 kernel just reading from /dev/sdb1: 6.9ms (not sure why this changed from 6.2 the day before)... So it seems like going to 32 AGs helped about 10%, but other then that not much else is making much of a difference... now I am moving on and trying to break the RAID up and testing individual disks to see their performance... Nathan Scott wrote: > On Tue, May 23, 2006 at 06:41:36PM -0700, fitzboy wrote: > >>I read online in multiple places that the largest allocation groups >>should get is 4g, > > > Thats not correct (for a few years now). > > >>I was also thinking that the more AGs the better since I do a lot of >>parallel reads/writes... granted it doesn't change the file system all >>that much (the file only grows or get existing blocks get modified), so >>I am not sure if the number of AGs matter, does it? > > > Yes, it can matter. For large extents like you have here, AGs > introduce a discontinuity that you'd otherwise not have. > > >>Sorry, I meant that moving the Inode size to 2k (over 256bytes) gave me >>a sizeable increase in performance... I assume that is because the >>extent map can be smaller now (since blocks are much larger, less blocks >>to keep track of). Of course, ideal would be to have InodeSize be large >>and blocksize to be 32k... but I hit the limits on both... > > > It means that more extents/btree records fit inline in the inode, > as theres more space available after the stat data. 2k is your > best choice for inode size, stick with that. > > >>>- Preallocate the space in the file - i.e. before running the >>>dd you can do an "xfs_io -c 'resvsp 0 2t' /mnt/array/disk1/xxx" >>>(preallocates 2 terabytes) and then overwrite that. Yhis will >>>give you an optimal layout. >> >>I tried this a couple of times, but it seemed to wedge the machine... I >>would do: 1) touch a file (just to create it), 2) do the above command > > > Oh, use the -f (create) option and you won't need a touch. > > >>which would then show effect in du, but the file size was still 0 3) I >>then opened that file (without O_TRUNC or O_APPEND) and started to write >>out to it. It would work fine for a few minutes but after about 5 or 7GB >>the machine would freeze... nothing in syslog, only a brief message on >>console about come cpu state being bad... > > > Hmm - I'd be interested to hear if that happens with a recent > kernel. > > >>>- Your extent map is fairly large, the 2.6.17 kernel will have >>>some improvements in the way the memory management is done here >>>which may help you a bit too. >> >>we have plenty of memory on the machines, shouldn't be an issue... I am >>a little cautious about moving to a new kernel though... > > > Its not the amount of memory that was the issue here, its more the > way we were using it that was a problem for kernels of the vintage > you're using here. You will definately see better performance in > a 2.6.17 kernel with that large extent map. > > cheers. > -- Timothy Fitz Lead Programmer iParadigms, LLC 1624 Franklin St., 7th Floor Oakland, CA 94612 p. +1-510-287-9720 x233 f. +1-510-444-1952 e. fitzboy@iparadigms.com The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by replying to the message and deleting it from your computer. From owner-xfs@oss.sgi.com Thu May 25 20:20:35 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 25 May 2006 20:20:38 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k4Q3KVeZ008675 for ; Thu, 25 May 2006 20:20:33 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA06321; Fri, 26 May 2006 13:20:24 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k4Q3KGh38768093; Fri, 26 May 2006 13:20:17 +1000 (AEST) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k4Q3KFTV8789569; Fri, 26 May 2006 13:20:15 +1000 (AEST) Date: Fri, 26 May 2006 13:20:15 +1000 (AEST) From: Timothy Shimmin Message-Id: <200605260320.k4Q3KFTV8789569@snort.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: PARTIAL TAKE 953263 - unlinked list qa test X-archive-position: 7801 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@snort.melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 1122 Lines: 35 Test out pv#953263 by creating AGI unlinked lists for recovery and looking in logprint for CLEAR_AGI_BUCKET transactions. Date: Fri May 26 13:18:34 AEST 2006 Workarea: snort.melbourne.sgi.com:/home/tes/isms/xfs-cmds Inspected by: tes@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:26042a xfstests/121 - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/121 - Test for pv#953263. xfstests/121.out - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/121.out - output of 121 xfstests/src/multi_open_unlink.c - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/src/multi_open_unlink.c - open and unlink a bunch of files and sleep used by test 121 xfstests/group - 1.85 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/group.diff?r1=text&tr1=1.85&r2=text&tr2=1.84&f=h - add 121 xfstests/src/Makefile - 1.36 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/src/Makefile.diff?r1=text&tr1=1.36&r2=text&tr2=1.35&f=h - add multi_open_unlink From owner-xfs@oss.sgi.com Thu May 25 20:30:48 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 25 May 2006 20:30:56 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k4Q3UdeZ009572 for ; Thu, 25 May 2006 20:30:44 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA06647; Fri, 26 May 2006 13:30:27 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k4Q3ULh38788416; Fri, 26 May 2006 13:30:22 +1000 (AEST) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k4Q3UKwv8791059; Fri, 26 May 2006 13:30:20 +1000 (AEST) Date: Fri, 26 May 2006 13:30:20 +1000 (AEST) From: Timothy Shimmin Message-Id: <200605260330.k4Q3UKwv8791059@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 953263 - bug in recovery processing of unlinked list X-archive-position: 7802 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@snort.melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 923 Lines: 24 We were over zealous with doing endian conversions. We endian converted the logged version of di_next_unlinked which is actually always stored in the correct ondisk format. This was pointed out to us by Shailendra Tripathi. The bug is evident in the xfs qa test of 121. --Tim Date: Fri May 26 13:28:27 AEST 2006 Workarea: snort.melbourne.sgi.com:/home/tes/isms/xfs-linux Inspected by: stripathi@agami.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26044a xfs_log_recover.c - 1.309 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_recover.c.diff?r1=text&tr1=1.309&r2=text&tr2=1.308&f=h - We endian converted the logged version of di_next_unlinked which is actually always stored in the correct ondisk format. Bug and solution reported by stripathi@agami.com. Go back to original IRIX line for this. From owner-xfs@oss.sgi.com Thu May 25 20:52:35 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 25 May 2006 20:52:39 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k4Q3nteb010897 for ; Thu, 25 May 2006 20:52:33 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA05792; Fri, 26 May 2006 12:50:14 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 7D6B14A588D4; Fri, 26 May 2006 12:50:14 +1000 (EST) To: xfs@oss.sgi.com, slinx-xfs@engr.sgi.com Subject: PARTIAL TAKE 952967 - BUG() in generic_delete_inode() Message-Id: <20060526025014.7D6B14A588D4@chook.melbourne.sgi.com> Date: Fri, 26 May 2006 12:50:14 +1000 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 7803 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 654 Lines: 18 Stop a BUG from occurring in generic_delete_inode by preventing transaction completion from marking the inode dirty while it is being cleaned up on it's way out of the system. Date: Fri May 26 12:48:51 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:26040a fs/xfs/xfs_inode.c - 1.440 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.440&r2=text&tr2=1.439&f=h - Do not mark inode dirty in xfs_iunpin if it is currently being freed. From owner-xfs@oss.sgi.com Fri May 26 01:25:40 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 26 May 2006 01:26:43 -0700 (PDT) Received: from embla.aitel.hist.no (embla.aitel.hist.no [158.38.50.22]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k4Q8PceZ001438 for ; Fri, 26 May 2006 01:25:39 -0700 Received: (qmail 30044 invoked from network); 26 May 2006 07:23:30 -0000 Received: from unknown (HELO ?158.38.51.68?) (158.38.51.68) by embla.aitel.hist.no with SMTP; 26 May 2006 07:23:30 -0000 Message-ID: <4476AC3B.5030704@aitel.hist.no> Date: Fri, 26 May 2006 09:20:27 +0200 From: Helge Hafting User-Agent: Thunderbird 1.5.0.2 (X11/20060516) MIME-Version: 1.0 To: Jan Engelhardt CC: Nathan Scott , linux-xfs@oss.sgi.com, Linux Kernel Mailing List Subject: Re: XFS write speed drop References: <20060522105326.A212600@wobbly.melbourne.sgi.com> <20060523084309.A239136@wobbly.melbourne.sgi.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7804 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: helge.hafting@aitel.hist.no Precedence: bulk X-list: xfs Content-Length: 466 Lines: 12 Jan Engelhardt wrote: > Well as mentioned, -o nobarrier solved it, and that's it. I do not actually > need barriers (or an UPS, to poke on another thread), because power > failures are rather rare in Germany. Then there are mistakes like someone stepping on the power cord, pulling out the wrong one, drilling holes in the wall, there are kernel crashes, there is lightning, there is the possibility that some component inside the box just breaks. Helge Hafting From owner-xfs@oss.sgi.com Fri May 26 01:51:34 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 26 May 2006 01:51:37 -0700 (PDT) Received: from linux01.gwdg.de (linux01.gwdg.de [134.76.13.21]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k4Q8pVeZ003066 for ; Fri, 26 May 2006 01:51:33 -0700 Received: from linux01.gwdg.de (localhost [127.0.0.1]) by linux01.gwdg.de (8.13.3/8.13.3/SuSE Linux 0.7) with ESMTP id k4Q8pNnp022314; Fri, 26 May 2006 10:51:26 +0200 Received: from localhost (jengelh@localhost) by linux01.gwdg.de (8.13.3/8.13.3/Submit) with ESMTP id k4Q8pMT6022308; Fri, 26 May 2006 10:51:22 +0200 Date: Fri, 26 May 2006 10:51:19 +0200 (MEST) From: Jan Engelhardt To: Helge Hafting cc: Nathan Scott , linux-xfs@oss.sgi.com, Linux Kernel Mailing List Subject: Re: XFS write speed drop In-Reply-To: <4476AC3B.5030704@aitel.hist.no> Message-ID: References: <20060522105326.A212600@wobbly.melbourne.sgi.com> <20060523084309.A239136@wobbly.melbourne.sgi.com> <4476AC3B.5030704@aitel.hist.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 7805 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jengelh@linux01.gwdg.de Precedence: bulk X-list: xfs Content-Length: 809 Lines: 23 >> Well as mentioned, -o nobarrier solved it, and that's it. I do not >> actually need barriers (or an UPS, to poke on another thread), because >> power failures are rather rare in Germany. > > Then there are mistakes like someone stepping on the power > cord, pulling out the wrong one, drilling holes in the wall, > there are kernel crashes, there is lightning, > there is the possibility that some > component inside the box just breaks. > A mathematician has fear of flying because there could possibly be a terrorist bomb inside the plane. What does he do? Taking an bomb with himself, because the probablity that there are two bombs inside a plane is lower than one. What I am wanting to say is that the factors you mentioned just do not happen here, at this one - home - box. Jan Engelhardt -- From owner-xfs@oss.sgi.com Fri May 26 05:46:32 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 26 May 2006 05:46:39 -0700 (PDT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.192.81]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k4QCkVeZ023727 for ; Fri, 26 May 2006 05:46:32 -0700 Received: from c-24-147-19-128.hsd1.ma.comcast.net (c-71-233-168-2.hsd1.ma.comcast.net[71.233.168.2](misconfigured sender)) by comcast.net (rwcrmhc11) with ESMTP id <20060526122953m1100k0mfve>; Fri, 26 May 2006 12:29:53 +0000 Received: from c-24-147-19-128.hsd1.ma.comcast.net (localhost [127.0.0.1]) by c-24-147-19-128.hsd1.ma.comcast.net (8.13.6/8.13.1) with ESMTP id k4QCTqdf001684; Fri, 26 May 2006 08:29:52 -0400 (EDT) (envelope-from rodrigc@c-24-147-19-128.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-24-147-19-128.hsd1.ma.comcast.net (8.13.6/8.13.1/Submit) id k4QCTqD9001683; Fri, 26 May 2006 08:29:52 -0400 (EDT) (envelope-from rodrigc) Date: Fri, 26 May 2006 08:29:52 -0400 From: Craig Rodrigues To: xfs@oss.sgi.com Cc: freebsd-xfs@xfs.org Subject: mkfs.xfs in xfsprogs-2.7.11 is broken on FreeBSD? Message-ID: <20060526122952.GA1639@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-archive-position: 7806 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: rodrigc@crodrigues.org Precedence: bulk X-list: xfs Content-Length: 419 Lines: 24 Hi, I haven't tested xfsprogs in a while, but I just noticed that mksfs in xfsprogs-2.7.11 on FreeBSD seems to be broken: % mkfs.xfs /dev/ad0s4 % file - < /dev/ad0s4 /dev/stdin: data If I revert to xfsprogs-2.6.25, then I get: % mkfs.xfs /dev/ad0s4 % file - < /dev/ad0s4 /dev/stdin: SGI XFS filesystem data (blksz 4096, inosz 256, v2 dirs) Any ideas? Thanks. -- Craig Rodrigues rodrigc@crodrigues.org From owner-xfs@oss.sgi.com Fri May 26 11:33:20 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 26 May 2006 11:33:22 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1.americas.sgi.com [198.149.16.13]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k4QIXJeZ022165 for ; Fri, 26 May 2006 11:33:20 -0700 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k4QHTqnx023626 for ; Fri, 26 May 2006 12:29:52 -0500 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 k4QHTonB38389383; Fri, 26 May 2006 10:29:50 -0700 (PDT) Message-ID: <44773B0F.8010406@sgi.com> Date: Fri, 26 May 2006 12:29:51 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Craig Rodrigues CC: xfs@oss.sgi.com, freebsd-xfs@xfs.org Subject: Re: mkfs.xfs in xfsprogs-2.7.11 is broken on FreeBSD? References: <20060526122952.GA1639@crodrigues.org> In-Reply-To: <20060526122952.GA1639@crodrigues.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7807 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: xfs Content-Length: 750 Lines: 27 Craig Rodrigues wrote: > Hi, > > I haven't tested xfsprogs in a while, but I just noticed > that mksfs in xfsprogs-2.7.11 on FreeBSD seems to be broken: > > % mkfs.xfs /dev/ad0s4 > > % file - < /dev/ad0s4 > /dev/stdin: data > > > If I revert to xfsprogs-2.6.25, then I get: > % mkfs.xfs /dev/ad0s4 > > % file - < /dev/ad0s4 > /dev/stdin: SGI XFS filesystem data (blksz 4096, inosz 256, v2 dirs) > > Any ideas? any errors out of the newer mkfs? Can you divide & conquer a bit to see when it stopped working? What does the first 512 bytes of /dev/ad0s4 look like with the new code; maybe diff that hexdump against one from 2.6.25? What does the kernel say when you try to mount it? Not sure what should have broken any of this... -Eric From owner-xfs@oss.sgi.com Fri May 26 12:25:55 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 26 May 2006 12:25:57 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k4QJPpeZ031366 for ; Fri, 26 May 2006 12:25:53 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA26910; Sat, 27 May 2006 05:25:39 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k4QJPagw350434; Sat, 27 May 2006 05:25:36 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k4QJPYBT350899; Sat, 27 May 2006 05:25:34 +1000 (EST) Date: Sat, 27 May 2006 05:25:34 +1000 From: Nathan Scott To: Craig Rodrigues Cc: xfs@oss.sgi.com Subject: Re: mkfs.xfs in xfsprogs-2.7.11 is broken on FreeBSD? Message-ID: <20060527052534.C349096@wobbly.melbourne.sgi.com> References: <20060526122952.GA1639@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060526122952.GA1639@crodrigues.org>; from rodrigc@crodrigues.org on Fri, May 26, 2006 at 08:29:52AM -0400 X-archive-position: 7808 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 436 Lines: 19 On Fri, May 26, 2006 at 08:29:52AM -0400, Craig Rodrigues wrote: > Hi, > > I haven't tested xfsprogs in a while, but I just noticed > that mksfs in xfsprogs-2.7.11 on FreeBSD seems to be broken: > ... > Any ideas? Russell mentioned there was an endianness issue in the current Freebsd specific headers (iirc) - I don't have a patch though; this is probably a symptom of that. Russell, could you (re?)send that? cheers. -- Nathan From owner-xfs@oss.sgi.com Fri May 26 12:28:38 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 26 May 2006 12:28:44 -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 k4QJSYeZ031775 for ; Fri, 26 May 2006 12:28:38 -0700 Received: from [10.0.0.12] (ease.thebarn.com [10.0.0.12]) (authenticated bits=0) by slurp.thebarn.com (8.13.5/8.13.5) with ESMTP id k4QJSNO7011337 for ; Fri, 26 May 2006 14:28:24 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <447756D7.80300@thebarn.com> Date: Fri, 26 May 2006 14:28:23 -0500 From: Russell Cattelan User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: xfs@oss.sgi.com Subject: Re: mkfs.xfs in xfsprogs-2.7.11 is broken on FreeBSD? References: <20060526122952.GA1639@crodrigues.org> In-Reply-To: <20060526122952.GA1639@crodrigues.org> Content-Type: multipart/mixed; boundary="------------020008020701030509020806" X-archive-position: 7809 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: xfs Content-Length: 3136 Lines: 116 This is a multi-part message in MIME format. --------------020008020701030509020806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Craig Rodrigues wrote: >Hi, > >I haven't tested xfsprogs in a while, but I just noticed >that mksfs in xfsprogs-2.7.11 on FreeBSD seems to be broken: > >% mkfs.xfs /dev/ad0s4 > >% file - < /dev/ad0s4 >/dev/stdin: data > > >If I revert to xfsprogs-2.6.25, then I get: >% mkfs.xfs /dev/ad0s4 > >% file - < /dev/ad0s4 >/dev/stdin: SGI XFS filesystem data (blksz 4096, inosz 256, v2 dirs) > >Any ideas? > >Thanks. > > Yup that is because xfs_arch.h is not correctly detecting the host endianness, so all the filesystems created by mkfs are defaulting to native byte ordering. # xfs_db -r /dev/md0 xfs_db: unexpected XFS SB magic number 0x42534658 xfs_db: size check failed xfs_db: read failed: Input/output error xfs_db: data size check failed vs # xfs_db -r /dev/md0 xfs_db> sb 0 xfs_db> print magicnum = 0x58465342 Including the changes I have currently but we probably need to move the endian checking to xfs_freebsd.h and then have xfs_arch.h pick up an XFS defined var. Ohh also note the incorrect use of strcpy vs strcmp. --------------020008020701030509020806 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="freebsd" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="freebsd" Index: xfs-cmds/xfsprogs/include/xfs_arch.h =================================================================== --- xfs-cmds.orig/xfsprogs/include/xfs_arch.h 2006-01-04 20:55:00.000000000 -0600 +++ xfs-cmds/xfsprogs/include/xfs_arch.h 2006-05-25 14:56:12.000000000 -0500 @@ -36,8 +36,10 @@ #if __BYTE_ORDER == __BIG_ENDIAN #define XFS_NATIVE_HOST 1 +#warning XFS_NATIVE_HOST 1 #else #undef XFS_NATIVE_HOST +#warning XFS_NATIVE_HOST undef #endif #ifdef XFS_NATIVE_HOST Index: xfs-cmds/xfsprogs/include/freebsd.h =================================================================== --- xfs-cmds.orig/xfsprogs/include/freebsd.h 2006-04-27 23:02:55.000000000 -0500 +++ xfs-cmds/xfsprogs/include/freebsd.h 2006-05-25 14:55:25.000000000 -0500 @@ -67,7 +67,10 @@ typedef enum { B_FALSE,B_TRUE } boolean_ static __inline__ int xfsctl(const char *path, int fd, int cmd, void *p) { - return ioctl(fd, cmd, p); + int err = 0; + err = ioctl(fd, cmd, p); + printf("xfsctl err %d cmd 0x%x\n",err,cmd); + return err; } static __inline__ int platform_test_xfs_fd(int fd) @@ -75,7 +78,7 @@ static __inline__ int platform_test_xfs_ struct statfs buf; if (fstatfs(fd, &buf) < 0) return 0; - return strcpy(buf.f_fstypename, "xfs") == 0; + return strncmp(buf.f_fstypename, "xfs",strlen("xfs")) == 0; } static __inline__ int platform_test_xfs_path(const char *path) @@ -83,7 +86,7 @@ static __inline__ int platform_test_xfs_ struct statfs buf; if (statfs(path, &buf) < 0) return 0; - return strcpy(buf.f_fstypename, "xfs") == 0; + return strncmp(buf.f_fstypename, "xfs",strlen("xfs")) == 0; } static __inline__ int platform_fstatfs(int fd, struct statfs *buf) --------------020008020701030509020806-- From owner-xfs@oss.sgi.com Fri May 26 12:50:23 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 26 May 2006 12:50:29 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k4QJoJeZ001720 for ; Fri, 26 May 2006 12:50:21 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA27607; Sat, 27 May 2006 05:50:04 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k4QJo1gw350670; Sat, 27 May 2006 05:50:02 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k4QJnwgu350526; Sat, 27 May 2006 05:49:58 +1000 (EST) Date: Sat, 27 May 2006 05:49:58 +1000 From: Nathan Scott To: Russell Cattelan Cc: xfs@oss.sgi.com Subject: Re: mkfs.xfs in xfsprogs-2.7.11 is broken on FreeBSD? Message-ID: <20060527054958.F349096@wobbly.melbourne.sgi.com> References: <20060526122952.GA1639@crodrigues.org> <447756D7.80300@thebarn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <447756D7.80300@thebarn.com>; from cattelan@thebarn.com on Fri, May 26, 2006 at 02:28:23PM -0500 X-archive-position: 7810 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 653 Lines: 23 On Fri, May 26, 2006 at 02:28:23PM -0500, Russell Cattelan wrote: > > Yup that is because xfs_arch.h is not correctly detecting the host > endianness, > so all the filesystems created by mkfs are defaulting to native byte > ordering. > ... > Including the changes I have currently but we probably need to > move the endian checking to xfs_freebsd.h and then have > xfs_arch.h pick up an XFS defined var. After a bit more digging, it seems the BSDs use macros without the leading "__" - I'll get this all fixed up shortly. > Ohh also note the incorrect use of strcpy vs strcmp. *cough* ... er, yes, that too I'll merge in. :) cheers. -- Nathan From owner-xfs@oss.sgi.com Fri May 26 14:38:51 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 26 May 2006 14:38:55 -0700 (PDT) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [63.240.77.81]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k4QLcoeZ013627 for ; Fri, 26 May 2006 14:38:51 -0700 Received: from c-24-147-19-128.hsd1.ma.comcast.net (c-71-233-168-2.hsd1.ma.comcast.net[71.233.168.2](misconfigured sender)) by comcast.net (sccrmhc11) with ESMTP id <2006052620211901100c4aere>; Fri, 26 May 2006 20:21:19 +0000 Received: from c-24-147-19-128.hsd1.ma.comcast.net (localhost [127.0.0.1]) by c-24-147-19-128.hsd1.ma.comcast.net (8.13.6/8.13.1) with ESMTP id k4QKLJmb003661 for ; Fri, 26 May 2006 16:21:19 -0400 (EDT) (envelope-from rodrigc@c-24-147-19-128.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-24-147-19-128.hsd1.ma.comcast.net (8.13.6/8.13.1/Submit) id k4QKLJki003660 for xfs@oss.sgi.com; Fri, 26 May 2006 16:21:19 -0400 (EDT) (envelope-from rodrigc) Date: Fri, 26 May 2006 16:21:19 -0400 From: Craig Rodrigues To: xfs@oss.sgi.com Subject: Re: mkfs.xfs in xfsprogs-2.7.11 is broken on FreeBSD? Message-ID: <20060526202119.GA3631@crodrigues.org> References: <20060526122952.GA1639@crodrigues.org> <20060527052534.C349096@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="jRHKVT23PllUwdXP" Content-Disposition: inline In-Reply-To: <20060527052534.C349096@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 7811 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: rodrigc@crodrigues.org Precedence: bulk X-list: xfs Content-Length: 3378 Lines: 74 --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, May 26, 2006 at 12:29:51PM -0500, Eric Sandeen wrote: > any errors out of the newer mkfs? Can you divide & conquer a bit to see > when it stopped working? What does the first 512 bytes of /dev/ad0s4 look > like with the new code; maybe diff that hexdump against one from 2.6.25? > What does the kernel say when you try to mount it? Not sure what should > have broken any of this... > > -Eric mkfs.xfs does not report any errors. I think it is an endian problem as Nathan mentioned. I am attaching two hexdumps one from xfsprogs-2.6.25 (good), and the other from xfsprogs-2.7.11 (bad). On Sat, May 27, 2006 at 05:25:34AM +1000, Nathan Scott wrote: > Russell mentioned there was an endianness issue in the current > Freebsd specific headers (iirc) - I don't have a patch though; > this is probably a symptom of that. Which headers should I be looking at? -- Craig Rodrigues rodrigc@crodrigues.org --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="xfsprogs2.6.25_good.txt" 00000000 58 46 53 42 00 00 10 00 00 00 00 00 00 8b 3c 80 |XFSB..........<.| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 0b 04 80 32 b3 ec da 11 a7 9c 00 40 ca 58 61 ca |...2.......@.Xa.| 00000030 00 00 00 00 00 80 00 04 00 00 00 00 00 00 00 80 |................| 00000040 00 00 00 00 00 00 00 81 00 00 00 00 00 00 00 82 |................| 00000050 00 00 00 10 00 08 b3 c8 00 00 00 10 00 00 00 00 |................| 00000060 00 00 11 67 30 84 02 00 01 00 00 10 00 00 00 00 |...g0...........| 00000070 00 00 00 00 00 00 00 00 0c 09 08 04 14 00 00 19 |................| 00000080 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 3d |.......@.......=| 00000090 00 00 00 00 00 8b 2a d5 00 00 00 00 00 00 00 00 |......*.........| 000000a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000b0 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 00 |................| 000000c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000200 --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="xfsprogs.2.7.11_bad.txt" 00000000 42 53 46 58 00 10 00 00 80 3c 8b 00 00 00 00 00 |BSFX.....<......| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 08 23 0e 92 f4 ec da 11 a4 66 00 40 ca 58 61 ca |.#.......f.@.Xa.| 00000030 04 00 80 00 00 00 00 00 80 00 00 00 00 00 00 00 |................| 00000040 81 00 00 00 00 00 00 00 82 00 00 00 00 00 00 00 |................| 00000050 10 00 00 00 c8 b3 08 00 10 00 00 00 00 00 00 00 |................| 00000060 67 11 00 00 84 30 00 02 00 01 10 00 00 00 00 00 |g....0..........| 00000070 00 00 00 00 00 00 00 00 0c 09 08 04 14 00 00 19 |................| 00000080 40 00 00 00 00 00 00 00 3d 00 00 00 00 00 00 00 |@.......=.......| 00000090 d5 2a 8b 00 00 00 00 00 00 00 00 00 00 00 00 00 |.*..............| 000000a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000b0 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 |................| 000000c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000200 --jRHKVT23PllUwdXP-- From owner-xfs@oss.sgi.com Fri May 26 15:15:26 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 26 May 2006 15:15:28 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k4QMFMeZ017484 for ; Fri, 26 May 2006 15:15:24 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA00112; Sat, 27 May 2006 08:15:07 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k4QMF3gw352234; Sat, 27 May 2006 08:15:04 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k4QMF13s353549; Sat, 27 May 2006 08:15:01 +1000 (EST) Date: Sat, 27 May 2006 08:15:00 +1000 From: Nathan Scott To: Russell Cattelan , Craig Rodrigues Cc: xfs@oss.sgi.com Subject: Re: mkfs.xfs in xfsprogs-2.7.11 is broken on FreeBSD? Message-ID: <20060527081500.A353132@wobbly.melbourne.sgi.com> References: <20060526122952.GA1639@crodrigues.org> <20060527052534.C349096@wobbly.melbourne.sgi.com> <20060526202119.GA3631@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060526202119.GA3631@crodrigues.org>; from rodrigc@crodrigues.org on Fri, May 26, 2006 at 04:21:19PM -0400 X-archive-position: 7812 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 1650 Lines: 53 On Fri, May 26, 2006 at 04:21:19PM -0400, Craig Rodrigues wrote: > On Sat, May 27, 2006 at 05:25:34AM +1000, Nathan Scott wrote: > > Russell mentioned there was an endianness issue in the current > > Freebsd specific headers (iirc) - I don't have a patch though; > > this is probably a symptom of that. > > Which headers should I be looking at? Try the patch below, lemme know if it fixes things. > 00000000 58 46 53 42 00 00 10 00 00 00 00 00 00 8b 3c 80 |XFSB..........<.| ... > 00000000 42 53 46 58 00 10 00 00 80 3c 8b 00 00 00 00 00 |BSFX.....<......| Heh. -- Nathan Index: xfsprogs/include/freebsd.h =================================================================== --- xfsprogs.orig/include/freebsd.h 2006-04-28 10:09:16.000000000 +1000 +++ xfsprogs/include/freebsd.h 2006-05-27 08:08:52.451376664 +1000 @@ -28,6 +28,9 @@ #include #include +#define __BYTE_ORDER BYTE_ORDER +#define __LITTLE_ENDIAN LITTLE_ENDIAN +#define __BIG_ENDIAN BIG_ENDIAN /* FreeBSD file API is 64-bit aware */ #define fstat64 fstat @@ -75,7 +78,7 @@ static __inline__ int platform_test_xfs_ struct statfs buf; if (fstatfs(fd, &buf) < 0) return 0; - return strcpy(buf.f_fstypename, "xfs") == 0; + return strncmp(buf.f_fstypename, "xfs", 4) == 0; } static __inline__ int platform_test_xfs_path(const char *path) @@ -83,7 +86,7 @@ static __inline__ int platform_test_xfs_ struct statfs buf; if (statfs(path, &buf) < 0) return 0; - return strcpy(buf.f_fstypename, "xfs") == 0; + return strncmp(buf.f_fstypename, "xfs", 4) == 0; } static __inline__ int platform_fstatfs(int fd, struct statfs *buf) From owner-xfs@oss.sgi.com Fri May 26 15:52:05 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 26 May 2006 15:52:10 -0700 (PDT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.192.83]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k4QMq4eZ021262 for ; Fri, 26 May 2006 15:52:05 -0700 Received: from c-24-147-19-128.hsd1.ma.comcast.net (c-71-233-168-2.hsd1.ma.comcast.net[71.233.168.2](misconfigured sender)) by comcast.net (rwcrmhc13) with ESMTP id <20060526224655m1300a1r88e>; Fri, 26 May 2006 22:46:56 +0000 Received: from c-24-147-19-128.hsd1.ma.comcast.net (localhost [127.0.0.1]) by c-24-147-19-128.hsd1.ma.comcast.net (8.13.6/8.13.1) with ESMTP id k4QMksIF017093; Fri, 26 May 2006 18:46:54 -0400 (EDT) (envelope-from rodrigc@c-24-147-19-128.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-24-147-19-128.hsd1.ma.comcast.net (8.13.6/8.13.1/Submit) id k4QMkrSC017092; Fri, 26 May 2006 18:46:53 -0400 (EDT) (envelope-from rodrigc) Date: Fri, 26 May 2006 18:46:53 -0400 From: Craig Rodrigues To: Nathan Scott Cc: Russell Cattelan , xfs@oss.sgi.com Subject: Re: mkfs.xfs in xfsprogs-2.7.11 is broken on FreeBSD? Message-ID: <20060526224653.GA17071@crodrigues.org> References: <20060526122952.GA1639@crodrigues.org> <20060527052534.C349096@wobbly.melbourne.sgi.com> <20060526202119.GA3631@crodrigues.org> <20060527081500.A353132@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ew6BAiZeqk4r7MaW" Content-Disposition: inline In-Reply-To: <20060527081500.A353132@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 7813 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: rodrigc@crodrigues.org Precedence: bulk X-list: xfs Content-Length: 2038 Lines: 78 --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, May 27, 2006 at 08:15:00AM +1000, Nathan Scott wrote: > Try the patch below, lemme know if it fixes things. I had to use a variant of your patch, because it complained about __swab16, __swab32, __swab64 not being defined. With this patch, I get a proper superblock. Do you still need __u8, __u16 and friends to compile xfsprogs? I also had that patch to take them out of freebsd.h from before. -- Craig Rodrigues rodrigc@crodrigues.org --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-freebsd2.h" --- include/freebsd.h.orig Mon Jan 16 22:46:48 2006 +++ include/freebsd.h Fri May 26 18:40:16 2006 @@ -27,7 +27,14 @@ #include #include -#include +#include +#define __BYTE_ORDER BYTE_ORDER +#define __LITTLE_ENDIAN LITTLE_ENDIAN +#define __BIG_ENDIAN BIG_ENDIAN + +#define __swab16 bswap16 +#define __swab32 bswap16 +#define __swab64 bswap16 /* FreeBSD file API is 64-bit aware */ #define fstat64 fstat @@ -39,15 +46,6 @@ #define fdatasync fsync #define memalign(a,size) valloc(size) -typedef u_int8_t __u8; -typedef int8_t __s8; -typedef u_int16_t __u16; -typedef int16_t __s16; -typedef u_int32_t __u32; -typedef int32_t __s32; -typedef u_int64_t __u64; -typedef int64_t __s64; - #define constpp char * const * #define EFSCORRUPTED 990 /* Filesystem is corrupted */ @@ -84,7 +82,7 @@ struct statfs buf; if (fstatfs(fd, &buf) < 0) return 0; - return strcpy(buf.f_fstypename, "xfs") == 0; + return strncmp(buf.f_fstypename, "xfs", 4) == 0; } static __inline__ int platform_test_xfs_path(const char *path) @@ -92,7 +90,7 @@ struct statfs buf; if (statfs(path, &buf) < 0) return 0; - return strcpy(buf.f_fstypename, "xfs") == 0; + return strncmp(buf.f_fstypename, "xfs", 4) == 0; } static __inline__ int platform_fstatfs(int fd, struct statfs *buf) --ew6BAiZeqk4r7MaW-- From owner-xfs@oss.sgi.com Fri May 26 15:52:16 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 26 May 2006 15:52:24 -0700 (PDT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.200.83]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k4QMqAeZ021282 for ; Fri, 26 May 2006 15:52:11 -0700 Received: from c-24-147-19-128.hsd1.ma.comcast.net (c-71-233-168-2.hsd1.ma.comcast.net[71.233.168.2](misconfigured sender)) by comcast.net (sccrmhc13) with ESMTP id <20060526225159013007uobge>; Fri, 26 May 2006 22:51:59 +0000 Received: from c-24-147-19-128.hsd1.ma.comcast.net (localhost [127.0.0.1]) by c-24-147-19-128.hsd1.ma.comcast.net (8.13.6/8.13.1) with ESMTP id k4QMpwVC017161; Fri, 26 May 2006 18:51:58 -0400 (EDT) (envelope-from rodrigc@c-24-147-19-128.hsd1.ma.comcast.net) Received: (from root@localhost) by c-24-147-19-128.hsd1.ma.comcast.net (8.13.6/8.13.1/Submit) id k4QMpwmQ017160; Fri, 26 May 2006 18:51:58 -0400 (EDT) (envelope-from rodrigc) Date: Fri, 26 May 2006 18:51:58 -0400 From: Charlie Root To: Craig Rodrigues Cc: xfs@oss.sgi.com, cattelan@xfs.org Subject: Re: Another mkfs.xfs problem under FreeBSD Message-ID: <20060526225158.GA17144@crodrigues.org> References: <20060526224941.GA17105@crodrigues.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline In-Reply-To: <20060526224941.GA17105@crodrigues.org> User-Agent: Mutt/1.4.2.1i X-archive-position: 7814 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: root@crodrigues.org Precedence: bulk X-list: xfs Content-Length: 2249 Lines: 54 --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, May 26, 2006 at 06:49:41PM -0400, Craig Rodrigues wrote: > Hi, > > I just noticed another problem with mkfs.xfs on FreeBSD, > with Nathan's latest patch and my modification. > > mkfs.xfs /dev/ad0s4 > meta-data=/dev/ad0s4 isize=256 agcount=16, agsize=570312 blks > = sectsz=512 attr=0 > data = bsize=4096 blocks=9124992, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=1 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=4455, version=1 > = sectsz=512 sunit=0 blks > realtime =none extsz=65536 blocks=0, rtextents=0 > mkfs.xfs: Inode allocation failed [28 - No space left on device] > > > What is this "Inode allocation failed" caused by? I am attaching a hexdump of the superblock. -- Craig Rodrigues rodrigc@crodrigues.org --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="xfsprogs.2.7.11_bad2.txt" 00000000 58 46 53 42 00 00 10 00 00 00 00 00 00 8b 3c 80 |XFSB..........<.| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 b8 c2 83 94 09 ed da 11 a4 66 00 40 ca 58 61 ca |.........f.@.Xa.| 00000030 00 00 00 00 00 80 00 04 ff ff ff ff ff ff ff ff |................| 00000040 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| 00000050 00 00 00 10 00 08 b3 c8 00 00 00 10 00 00 00 00 |................| 00000060 00 00 11 67 30 84 02 00 01 00 00 10 00 00 00 00 |...g0...........| 00000070 00 00 00 00 00 00 00 00 0c 09 08 04 14 00 01 19 |................| 00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000090 00 00 00 00 00 8b 2a d9 00 00 00 00 00 00 00 00 |......*.........| 000000a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000b0 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 00 |................| 000000c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000200 --Nq2Wo0NMKNjxTN9z-- From owner-xfs@oss.sgi.com Fri May 26 16:04:38 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 26 May 2006 16:04:42 -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 k4QN4beZ023178 for ; Fri, 26 May 2006 16:04:38 -0700 Received: from [10.0.0.12] (ease.thebarn.com [10.0.0.12]) (authenticated bits=0) by slurp.thebarn.com (8.13.5/8.13.5) with ESMTP id k4QN4KbJ016583; Fri, 26 May 2006 18:04:21 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <44778973.7040201@thebarn.com> Date: Fri, 26 May 2006 18:04:19 -0500 From: Russell Cattelan User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Craig Rodrigues CC: xfs@oss.sgi.com Subject: Re: Another mkfs.xfs problem under FreeBSD References: <20060526224941.GA17105@crodrigues.org> In-Reply-To: <20060526224941.GA17105@crodrigues.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7815 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: xfs Content-Length: 1340 Lines: 42 Craig Rodrigues wrote: >Hi, > >I just noticed another problem with mkfs.xfs on FreeBSD, >with Nathan's latest patch and my modification. > >mkfs.xfs /dev/ad0s4 >meta-data=/dev/ad0s4 isize=256 agcount=16, agsize=570312 blks > = sectsz=512 attr=0 >data = bsize=4096 blocks=9124992, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=1 >naming =version 2 bsize=4096 >log =internal log bsize=4096 blocks=4455, version=1 > = sectsz=512 sunit=0 blks >realtime =none extsz=65536 blocks=0, rtextents=0 >mkfs.xfs: Inode allocation failed [28 - No space left on device] > > >What is this "Inode allocation failed" caused by? > > > where does your s4 partition start? XFS puts it's superblock starting at block 0 but freebsd does not like that. (something about protected blocks?) I've been using partion d that starts a few blocks in. # disklabel -r /dev/da1s1 # /dev/da1s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] c: 17848152 0 unused 0 0 # "raw" part, don't edit d: 17848142 10 4.2BSD 0 0 0 Try that and see if it work. Otherwise there is something else amuck. From owner-xfs@oss.sgi.com Fri May 26 16:12:44 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 26 May 2006 16:12:46 -0700 (PDT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [204.127.192.82]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k4QNCheZ024311 for ; Fri, 26 May 2006 16:12:44 -0700 Received: from c-24-147-19-128.hsd1.ma.comcast.net (c-71-233-168-2.hsd1.ma.comcast.net[71.233.168.2](misconfigured sender)) by comcast.net (rwcrmhc12) with ESMTP id <20060526224942m1200is6vpe>; Fri, 26 May 2006 22:49:42 +0000 Received: from c-24-147-19-128.hsd1.ma.comcast.net (localhost [127.0.0.1]) by c-24-147-19-128.hsd1.ma.comcast.net (8.13.6/8.13.1) with ESMTP id k4QMngK9017125; Fri, 26 May 2006 18:49:42 -0400 (EDT) (envelope-from rodrigc@c-24-147-19-128.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-24-147-19-128.hsd1.ma.comcast.net (8.13.6/8.13.1/Submit) id k4QMnfax017124; Fri, 26 May 2006 18:49:41 -0400 (EDT) (envelope-from rodrigc) Date: Fri, 26 May 2006 18:49:41 -0400 From: Craig Rodrigues To: xfs@oss.sgi.com Cc: cattelan@xfs.org Subject: Another mkfs.xfs problem under FreeBSD Message-ID: <20060526224941.GA17105@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-archive-position: 7816 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: rodrigc@crodrigues.org Precedence: bulk X-list: xfs Content-Length: 817 Lines: 23 Hi, I just noticed another problem with mkfs.xfs on FreeBSD, with Nathan's latest patch and my modification. mkfs.xfs /dev/ad0s4 meta-data=/dev/ad0s4 isize=256 agcount=16, agsize=570312 blks = sectsz=512 attr=0 data = bsize=4096 blocks=9124992, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=4455, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 mkfs.xfs: Inode allocation failed [28 - No space left on device] What is this "Inode allocation failed" caused by? -- Craig Rodrigues rodrigc@crodrigues.org From owner-xfs@oss.sgi.com Fri May 26 16:46:30 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 26 May 2006 16:46:33 -0700 (PDT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [216.148.227.151]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k4QNkUeZ031670 for ; Fri, 26 May 2006 16:46:30 -0700 Received: from c-24-147-19-128.hsd1.ma.comcast.net (c-71-233-168-2.hsd1.ma.comcast.net[71.233.168.2](misconfigured sender)) by comcast.net (rwcrmhc11) with ESMTP id <20060526233844m1100k0mhle>; Fri, 26 May 2006 23:38:44 +0000 Received: from c-24-147-19-128.hsd1.ma.comcast.net (localhost [127.0.0.1]) by c-24-147-19-128.hsd1.ma.comcast.net (8.13.6/8.13.1) with ESMTP id k4QNceEw017387; Fri, 26 May 2006 19:38:40 -0400 (EDT) (envelope-from rodrigc@c-24-147-19-128.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-24-147-19-128.hsd1.ma.comcast.net (8.13.6/8.13.1/Submit) id k4QNcebD017386; Fri, 26 May 2006 19:38:40 -0400 (EDT) (envelope-from rodrigc) Date: Fri, 26 May 2006 19:38:40 -0400 From: Craig Rodrigues To: Russell Cattelan Cc: xfs@oss.sgi.com Subject: Re: Another mkfs.xfs problem under FreeBSD Message-ID: <20060526233840.GA17368@crodrigues.org> References: <20060526224941.GA17105@crodrigues.org> <44778973.7040201@thebarn.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline In-Reply-To: <44778973.7040201@thebarn.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 7817 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: rodrigc@crodrigues.org Precedence: bulk X-list: xfs Content-Length: 2838 Lines: 60 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, May 26, 2006 at 06:04:19PM -0500, Russell Cattelan wrote: > where does your s4 partition start? I don't think that is relevant, because I have used the same partition with xfsprogs 2.6.25 without a problem. I am attaching the two superblocks. For the bad superblock, there seems to be a lot of 'ffffffff' in the middle. -- Craig Rodrigues rodrigc@crodrigues.org --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="xfsprogs2.6.25_good.txt" 00000000 58 46 53 42 00 00 10 00 00 00 00 00 00 8b 3c 80 |XFSB..........<.| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 0b 04 80 32 b3 ec da 11 a7 9c 00 40 ca 58 61 ca |...2.......@.Xa.| 00000030 00 00 00 00 00 80 00 04 00 00 00 00 00 00 00 80 |................| 00000040 00 00 00 00 00 00 00 81 00 00 00 00 00 00 00 82 |................| 00000050 00 00 00 10 00 08 b3 c8 00 00 00 10 00 00 00 00 |................| 00000060 00 00 11 67 30 84 02 00 01 00 00 10 00 00 00 00 |...g0...........| 00000070 00 00 00 00 00 00 00 00 0c 09 08 04 14 00 00 19 |................| 00000080 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 3d |.......@.......=| 00000090 00 00 00 00 00 8b 2a d5 00 00 00 00 00 00 00 00 |......*.........| 000000a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000b0 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 00 |................| 000000c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000200 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="xfsprogs.2.7.11_bad2.txt" 00000000 58 46 53 42 00 00 10 00 00 00 00 00 00 8b 3c 80 |XFSB..........<.| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 b8 c2 83 94 09 ed da 11 a4 66 00 40 ca 58 61 ca |.........f.@.Xa.| 00000030 00 00 00 00 00 80 00 04 ff ff ff ff ff ff ff ff |................| 00000040 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| 00000050 00 00 00 10 00 08 b3 c8 00 00 00 10 00 00 00 00 |................| 00000060 00 00 11 67 30 84 02 00 01 00 00 10 00 00 00 00 |...g0...........| 00000070 00 00 00 00 00 00 00 00 0c 09 08 04 14 00 01 19 |................| 00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000090 00 00 00 00 00 8b 2a d9 00 00 00 00 00 00 00 00 |......*.........| 000000a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000b0 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 00 |................| 000000c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000200 --nFreZHaLTZJo0R7j-- From owner-xfs@oss.sgi.com Sat May 27 06:27:10 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 27 May 2006 06:27:14 -0700 (PDT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [63.240.77.83]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k4RDR9eZ015239 for ; Sat, 27 May 2006 06:27:10 -0700 Received: from c-24-147-19-128.hsd1.ma.comcast.net (c-71-233-168-2.hsd1.ma.comcast.net[71.233.168.2](misconfigured sender)) by comcast.net (sccrmhc13) with ESMTP id <200605271322560130081kpre>; Sat, 27 May 2006 13:22:56 +0000 Received: from c-24-147-19-128.hsd1.ma.comcast.net (localhost [127.0.0.1]) by c-24-147-19-128.hsd1.ma.comcast.net (8.13.6/8.13.1) with ESMTP id k4RDMuq5072667 for ; Sat, 27 May 2006 09:22:57 -0400 (EDT) (envelope-from rodrigc@c-24-147-19-128.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-24-147-19-128.hsd1.ma.comcast.net (8.13.6/8.13.1/Submit) id k4RDMuPn072666 for xfs@oss.sgi.com; Sat, 27 May 2006 09:22:56 -0400 (EDT) (envelope-from rodrigc) Date: Sat, 27 May 2006 09:22:56 -0400 From: Craig Rodrigues To: xfs@oss.sgi.com Subject: Fix for endian macros on FreeBSD Message-ID: <20060527132256.GA72643@crodrigues.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-archive-position: 7818 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: rodrigc@crodrigues.org Precedence: bulk X-list: xfs Content-Length: 1077 Lines: 45 --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, OK, I finally figured things out, and fixed the endian macros for FreeBSD in xfsprogs, and got a mkfs.xfs which does not generate a scrambled superblock. Can you commit this fix to CVS? Thanks. -- Craig Rodrigues rodrigc@crodrigues.org --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="a.txt" =================================================================== RCS file: freebsd.h,v retrieving revision 1.5 diff -u -r1.5 freebsd.h --- freebsd.h 2006/04/28 04:02:55 1.5 +++ freebsd.h 2006/05/27 13:19:50 @@ -27,7 +27,13 @@ #include #include -#include +#include +#define __BYTE_ORDER BYTE_ORDER +#define __BIG_ENDIAN BIG_ENDIAN +#define __LITTLE_ENDIAN LITTLE_ENDIAN +#define __swab16(x) bswap16(x) +#define __swab32(x) bswap32(x) +#define __swab64(x) bswap64(x) /* FreeBSD file API is 64-bit aware */ #define fstat64 fstat --7JfCtLOvnd9MIVvH-- From owner-xfs@oss.sgi.com Sat May 27 11:34:25 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 27 May 2006 11:34:29 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k4RIYOeZ010048 for ; Sat, 27 May 2006 11:34:25 -0700 Received: by ug-out-1314.google.com with SMTP id e2so129057ugf for ; Sat, 27 May 2006 11:34:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=K5iF5dmDL0zkbDwO31wlM9idQU/IIvmhRenVnFmCfvX+4Czptp7npH6+QnBblDasJSD69Ynwuic+PfOb395J9naT+VRj0jeIvlTN+zQJmAvI93fKOuVkScqKnxIqJ2iUr1Op2Zir3wxDSI50RTvO/XUFIwFWYeyLTSSxoNWgu6A= Received: by 10.66.216.20 with SMTP id o20mr485796ugg; Sat, 27 May 2006 09:57:42 -0700 (PDT) Received: by 10.67.100.14 with HTTP; Sat, 27 May 2006 09:57:42 -0700 (PDT) Message-ID: Date: Sat, 27 May 2006 18:57:42 +0200 From: "Jeroni Brunet" To: xfs@oss.sgi.com Subject: slow reading problem MIME-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 7819 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jeroni@gmail.com Precedence: bulk X-list: xfs Content-Length: 736 Lines: 18 hi, I've got a problem with one of my xfs partitions on linux. I've got 3 partitions with xfs filesystem and one of them is very slow on reading data (about 5Mb/s) with large files. The other ones work correctly and on writing all of them work correctly (at about 30 - 40 MB/s). This partition has 140GB and about 50GB of free space, then I believe it's not a fragmentation problem. Can you give me any answer? I've tried to do "xfs_repair" but nothing changes. Thanks, PD: the "broken" partition is located on the same disk as a good one, the hardware is ok (also hdparm gives good results on all disks tested with cache and without it and the parameters are all the same and they are correct) [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Sat May 27 12:43:57 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 27 May 2006 12:44:02 -0700 (PDT) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k4RJhueZ028522 for ; Sat, 27 May 2006 12:43:57 -0700 Received: (qmail 95632 invoked from network); 27 May 2006 18:43:45 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@71.202.63.228 with login) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 27 May 2006 18:43:45 -0000 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 41E6B529BA9; Sat, 27 May 2006 11:43:43 -0700 (PDT) Date: Sat, 27 May 2006 11:43:43 -0700 From: Chris Wedgwood To: Jeroni Brunet Cc: xfs@oss.sgi.com Subject: Re: slow reading problem Message-ID: <20060527184343.GB17101@taniwha.stupidest.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-archive-position: 7820 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: xfs Content-Length: 505 Lines: 15 On Sat, May 27, 2006 at 06:57:42PM +0200, Jeroni Brunet wrote: > This partition has 140GB and about 50GB of free space, then I > believe it's not a fragmentation problem. Can you give me any > answer? what does xfs_bmap -v show for one of the 'slow reading files'? > I've tried to do "xfs_repair" but nothing changes. if the slow reads are because of horrible fragmentation (p2p applications are bad at this for example) then xfs_repair won't change that, you will need to look at xfs_fsr From owner-xfs@oss.sgi.com Sat May 27 12:59:51 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 27 May 2006 12:59:53 -0700 (PDT) Received: from elfstone.noviforum.si (elfstone.noviforum.si [193.189.169.107]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k4RJxneZ031425 for ; Sat, 27 May 2006 12:59:50 -0700 Received: from localhost (localhost [127.0.0.1]) by elfstone.noviforum.si (ESMTP) with ESMTP id 8D8281B919 for ; Sat, 27 May 2006 19:56:24 +0200 (CEST) Received: from dacun.noviforum.si (dacun.noviforum.si [192.168.2.26]) by elfstone.noviforum.si (ESMTP) with ESMTP id 6089B1B913 for ; Sat, 27 May 2006 19:56:24 +0200 (CEST) Subject: From: Gorazd Golob To: linux-xfs@oss.sgi.com Content-Type: text/plain Date: Sat, 27 May 2006 19:59:36 +0200 Message-Id: <1148752776.16365.6.camel@dacun.noviforum.si> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-archive-position: 7821 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: gorazd.golob@noviforum.si Precedence: bulk X-list: xfs Content-Length: 402 Lines: 15 Hi! Anyone have idea what does that mean? [376278.129936] Filesystem "sdb1": Corruption of in-memory data detected. Shutting down filesystem: sdb1 [376278.135533] Please umount the filesystem, and rectify the problem(s) Kernel is 2.6.15.6-1, SMP, x86_64 bit. Also I'm not able to unmount file system - and according to lsof it's not in use. umout is telling me "device is busy". Thanks, gorazd From owner-xfs@oss.sgi.com Sat May 27 13:01:25 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 27 May 2006 13:01:28 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k4RK1NeZ031879 for ; Sat, 27 May 2006 13:01:25 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 75327163824; Sat, 27 May 2006 16:01:17 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 73C57100EC460; Sat, 27 May 2006 16:01:17 -0400 (EDT) Date: Sat, 27 May 2006 16:01:17 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34 To: Gorazd Golob cc: linux-xfs@oss.sgi.com Subject: Re: your mail In-Reply-To: <1148752776.16365.6.camel@dacun.noviforum.si> Message-ID: References: <1148752776.16365.6.camel@dacun.noviforum.si> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 7822 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Content-Length: 495 Lines: 21 Are you using loop-aes? On Sat, 27 May 2006, Gorazd Golob wrote: > Hi! > > Anyone have idea what does that mean? > > [376278.129936] Filesystem "sdb1": Corruption of in-memory data > detected. Shutting down filesystem: sdb1 > [376278.135533] Please umount the filesystem, and rectify the problem(s) > > Kernel is 2.6.15.6-1, SMP, x86_64 bit. Also I'm not able to unmount file > system - and according to lsof it's not in use. umout is telling me > "device is busy". > > Thanks, gorazd > > > From owner-xfs@oss.sgi.com Sat May 27 13:33:14 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 27 May 2006 13:33:17 -0700 (PDT) Received: from elfstone.noviforum.si (elfstone.noviforum.si [193.189.169.107]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k4RKXAeZ004570 for ; Sat, 27 May 2006 13:33:14 -0700 Received: from localhost (localhost [127.0.0.1]) by elfstone.noviforum.si (ESMTP) with ESMTP id 3FFEB1B91D for ; Sat, 27 May 2006 21:27:22 +0200 (CEST) Received: from dacun.noviforum.si (dacun.noviforum.si [192.168.2.26]) by elfstone.noviforum.si (ESMTP) with ESMTP id 0B0AF1B913 for ; Sat, 27 May 2006 21:27:22 +0200 (CEST) Subject: Corruption of in-memory data From: Gorazd Golob To: xfs@oss.sgi.com Content-Type: text/plain Date: Sat, 27 May 2006 21:30:34 +0200 Message-Id: <1148758234.16365.12.camel@dacun.noviforum.si> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-archive-position: 7823 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: gorazd.golob@noviforum.si Precedence: bulk X-list: xfs Content-Length: 559 Lines: 17 Hi! Anyone have idea what does that mean? [376278.129936] Filesystem "sdb1": Corruption of in-memory data detected. Shutting down filesystem: sdb1 [376278.135533] Please umount the filesystem, and rectify the problem(s) Kernel is 2.6.15.6-1, SMP, x86_64 bit. Also I'm not able to unmount file system - and according to lsof it's not in use. umount is telling me "device is busy" (can be some thread inside some java app) Also I have to mention that system have ecc ram and edac kernel feature didn't count any errors on system memory.. Thanks, gorazd From owner-xfs@oss.sgi.com Sat May 27 14:06:33 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 27 May 2006 14:07:34 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k4RL6UeZ011094 for ; Sat, 27 May 2006 14:06:32 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA19987; Sun, 28 May 2006 07:06:15 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k4RL6Cgw389321; Sun, 28 May 2006 07:06:13 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k4RL69NV388750; Sun, 28 May 2006 07:06:09 +1000 (EST) Date: Sun, 28 May 2006 07:06:09 +1000 From: Nathan Scott To: Craig Rodrigues Cc: xfs@oss.sgi.com Subject: Re: Fix for endian macros on FreeBSD Message-ID: <20060528070609.A387938@wobbly.melbourne.sgi.com> References: <20060527132256.GA72643@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060527132256.GA72643@crodrigues.org>; from rodrigc@crodrigues.org on Sat, May 27, 2006 at 09:22:56AM -0400 X-archive-position: 7824 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 587 Lines: 20 On Sat, May 27, 2006 at 09:22:56AM -0400, Craig Rodrigues wrote: > Hi, > > OK, I finally figured things out, and fixed the endian > macros for FreeBSD in xfsprogs, and got a mkfs.xfs > which does not generate a scrambled superblock. > > Can you commit this fix to CVS? Will do. It seems to me the HAVE_SWABMACROS macro is no longer useful, can you try a build with that #define removed from your freebsd.h please (and also the 3 INT_SWAPXX macros removed)? As you're now defining __swabXX in terms of bswapXX, pretty sure those are all redundant - let me know. cheers. -- Nathan From owner-xfs@oss.sgi.com Sat May 27 15:00:56 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 27 May 2006 15:00:59 -0700 (PDT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [63.240.77.83]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k4RM0teZ021024 for ; Sat, 27 May 2006 15:00:56 -0700 Received: from c-24-147-19-128.hsd1.ma.comcast.net (c-71-233-168-2.hsd1.ma.comcast.net[71.233.168.2](misconfigured sender)) by comcast.net (sccrmhc13) with ESMTP id <20060527215544013007vkm3e>; Sat, 27 May 2006 21:55:44 +0000 Received: from c-24-147-19-128.hsd1.ma.comcast.net (localhost [127.0.0.1]) by c-24-147-19-128.hsd1.ma.comcast.net (8.13.6/8.13.1) with ESMTP id k4RLtjJT000632; Sat, 27 May 2006 17:55:45 -0400 (EDT) (envelope-from rodrigc@c-24-147-19-128.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-24-147-19-128.hsd1.ma.comcast.net (8.13.6/8.13.1/Submit) id k4RLtig3000631; Sat, 27 May 2006 17:55:44 -0400 (EDT) (envelope-from rodrigc) Date: Sat, 27 May 2006 17:55:44 -0400 From: Craig Rodrigues To: Nathan Scott Cc: xfs@oss.sgi.com Subject: Re: Fix for endian macros on FreeBSD Message-ID: <20060527215544.GA89826@crodrigues.org> References: <20060527132256.GA72643@crodrigues.org> <20060528070609.A387938@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060528070609.A387938@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 7825 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: rodrigc@crodrigues.org Precedence: bulk X-list: xfs Content-Length: 434 Lines: 12 On Sun, May 28, 2006 at 07:06:09AM +1000, Nathan Scott wrote: > Will do. It seems to me the HAVE_SWABMACROS macro is no longer > useful, can you try a build with that #define removed from your > freebsd.h please (and also the 3 INT_SWAPXX macros removed)? As Removing HAVE_SWABMACROS and the 3 INT_SWAPXX macros from freebsd.h seems to work, so go ahead an remove them. Thanks! -- Craig Rodrigues rodrigc@crodrigues.org From owner-xfs@oss.sgi.com Sat May 27 15:04:55 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 27 May 2006 15:04:57 -0700 (PDT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [204.127.192.82]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k4RM4neZ021944 for ; Sat, 27 May 2006 15:04:54 -0700 Received: from c-24-147-19-128.hsd1.ma.comcast.net (c-71-233-168-2.hsd1.ma.comcast.net[71.233.168.2](misconfigured sender)) by comcast.net (rwcrmhc12) with ESMTP id <20060527220443m1200iu5u2e>; Sat, 27 May 2006 22:04:43 +0000 Received: from c-24-147-19-128.hsd1.ma.comcast.net (localhost [127.0.0.1]) by c-24-147-19-128.hsd1.ma.comcast.net (8.13.6/8.13.1) with ESMTP id k4RM4iAj005007; Sat, 27 May 2006 18:04:44 -0400 (EDT) (envelope-from rodrigc@c-24-147-19-128.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-24-147-19-128.hsd1.ma.comcast.net (8.13.6/8.13.1/Submit) id k4RM4heq005006; Sat, 27 May 2006 18:04:43 -0400 (EDT) (envelope-from rodrigc) Date: Sat, 27 May 2006 18:04:43 -0400 From: Craig Rodrigues To: Nathan Scott Cc: xfs@oss.sgi.com Subject: Re: Fix for endian macros on FreeBSD Message-ID: <20060527220443.GA4996@crodrigues.org> References: <20060527132256.GA72643@crodrigues.org> <20060528070609.A387938@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="9amGYk9869ThD9tj" Content-Disposition: inline In-Reply-To: <20060528070609.A387938@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 7826 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: rodrigc@crodrigues.org Precedence: bulk X-list: xfs Content-Length: 2241 Lines: 75 --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, May 28, 2006 at 07:06:09AM +1000, Nathan Scott wrote: > Will do. It seems to me the HAVE_SWABMACROS macro is no longer > useful, can you try a build with that #define removed from your > freebsd.h please (and also the 3 INT_SWAPXX macros removed)? As Here is a patch that works for me. I had to change to use __bswap16 instead of bswap16, because of issues with macros expanding inside macros . -- Craig Rodrigues rodrigc@crodrigues.org --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="a.txt" Index: freebsd.h =================================================================== RCS file: /cvs/xfs-cmds/xfsprogs/include/freebsd.h,v retrieving revision 1.5 diff -u -u -r1.5 freebsd.h --- freebsd.h 28 Apr 2006 04:02:55 -0000 1.5 +++ freebsd.h 27 May 2006 22:03:19 -0000 @@ -27,7 +27,13 @@ #include #include -#include +#include +#define __BYTE_ORDER BYTE_ORDER +#define __BIG_ENDIAN BIG_ENDIAN +#define __LITTLE_ENDIAN LITTLE_ENDIAN +#define __swab16(x) __bswap16(x) +#define __swab32(x) __bswap32(x) +#define __swab64(x) __bswap64(x) /* FreeBSD file API is 64-bit aware */ #define fstat64 fstat @@ -60,10 +66,6 @@ #define O_LARGEFILE 0 #define HAVE_FID 1 -#define HAVE_SWABMACROS 1 -#define INT_SWAP16(type,var) ((typeof(type))(__bswap16((__u16)(var)))) -#define INT_SWAP32(type,var) ((typeof(type))(__bswap32((__u32)(var)))) -#define INT_SWAP64(type,var) ((typeof(type))(__bswap64((__u64)(var)))) static __inline__ int xfsctl(const char *path, int fd, int cmd, void *p) { @@ -75,7 +77,7 @@ struct statfs buf; if (fstatfs(fd, &buf) < 0) return 0; - return strcpy(buf.f_fstypename, "xfs") == 0; + return strncmp(buf.f_fstypename, "xfs", 4) == 0; } static __inline__ int platform_test_xfs_path(const char *path) @@ -83,7 +85,7 @@ struct statfs buf; if (statfs(path, &buf) < 0) return 0; - return strcpy(buf.f_fstypename, "xfs") == 0; + return strncmp(buf.f_fstypename, "xfs", 4) == 0; } static __inline__ int platform_fstatfs(int fd, struct statfs *buf) --9amGYk9869ThD9tj-- From owner-xfs@oss.sgi.com Sat May 27 15:43:33 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 27 May 2006 15:43:37 -0700 (PDT) Received: from mx1.pretago.de (mx1.pretago.de [89.110.132.150] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k4RMhVeZ028306 for ; Sat, 27 May 2006 15:43:33 -0700 Received: from localhost (localhost [127.0.0.1]) by mx1.pretago.de (Postfix) with ESMTP id 51C182EC0E9; Sat, 27 May 2006 23:39:16 +0200 (CEST) Received: from mx1.pretago.de ([127.0.0.1]) by localhost (mx1 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15962-07; Sat, 27 May 2006 23:39:15 +0200 (CEST) Received: from noname (17.113.46.212.dsl.getacom.de [212.46.113.17]) (using TLSv1 with cipher EXP1024-RC4-SHA (56/128 bits)) (No client certificate requested) by mx1.pretago.de (Postfix) with ESMTP id BEDCD2EC0E5; Sat, 27 May 2006 23:39:15 +0200 (CEST) From: Markus Schoder To: xfs@oss.sgi.com Subject: XFS and noatime Date: Sat, 27 May 2006 23:39:12 +0200 User-Agent: KMail/1.9.1 Cc: Markus Schoder MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605272339.12352.lists@gammarayburst.de> X-archive-position: 7827 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lists@gammarayburst.de Precedence: bulk X-list: xfs Content-Length: 191 Lines: 8 Seems that XFS updates the atime for binary files that are executed even if noatime is specified on mount. Is this the intended behaviour? ext3 for example behaves differently. -- Markus From owner-xfs@oss.sgi.com Sat May 27 15:57:12 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 27 May 2006 15:57:15 -0700 (PDT) Received: from elfstone.noviforum.si (elfstone.noviforum.si [193.189.169.107]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k4RMvAeZ030280 for ; Sat, 27 May 2006 15:57:11 -0700 Received: from localhost (localhost [127.0.0.1]) by elfstone.noviforum.si (ESMTP) with ESMTP id 55C771B919; Sun, 28 May 2006 00:53:45 +0200 (CEST) Received: from dacun.noviforum.si (dacun.noviforum.si [192.168.2.26]) by elfstone.noviforum.si (ESMTP) with ESMTP id 1B7571B913; Sun, 28 May 2006 00:53:44 +0200 (CEST) Subject: Re: your mail From: Gorazd Golob To: Justin Piszcz Cc: linux-xfs@oss.sgi.com In-Reply-To: References: <1148752776.16365.6.camel@dacun.noviforum.si> Content-Type: text/plain Date: Sun, 28 May 2006 00:56:58 +0200 Message-Id: <1148770618.16702.8.camel@dacun.noviforum.si> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-archive-position: 7828 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: gorazd.golob@noviforum.si Precedence: bulk X-list: xfs Content-Length: 614 Lines: 24 nope - real device.. On Sat, 2006-05-27 at 16:01 -0400, Justin Piszcz wrote: > Are you using loop-aes? > > On Sat, 27 May 2006, Gorazd Golob wrote: > > > Hi! > > > > Anyone have idea what does that mean? > > > > [376278.129936] Filesystem "sdb1": Corruption of in-memory data > > detected. Shutting down filesystem: sdb1 > > [376278.135533] Please umount the filesystem, and rectify the problem(s) > > > > Kernel is 2.6.15.6-1, SMP, x86_64 bit. Also I'm not able to unmount file > > system - and according to lsof it's not in use. umout is telling me > > "device is busy". > > > > Thanks, gorazd > > > > > > From owner-xfs@oss.sgi.com Sat May 27 16:52:26 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 27 May 2006 16:52:29 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k4RNqOeZ011551 for ; Sat, 27 May 2006 16:52:25 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id D3163163824; Sat, 27 May 2006 19:52:17 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id B173A100EC460; Sat, 27 May 2006 19:52:17 -0400 (EDT) Date: Sat, 27 May 2006 19:52:17 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34 To: Gorazd Golob cc: linux-xfs@oss.sgi.com Subject: Re: your mail In-Reply-To: <1148770618.16702.8.camel@dacun.noviforum.si> Message-ID: References: <1148752776.16365.6.camel@dacun.noviforum.si> <1148770618.16702.8.camel@dacun.noviforum.si> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 7829 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Content-Length: 955 Lines: 37 The first thing everyone is going to tell you to do is upgrade your kernel to the latest stable, as of this minute that is 2.6.16.18. See if you can reproduce the problem there. You'll probably have to reboot/boot knoppix and run xfs_repair on the existing filesystem first, though. On Sun, 28 May 2006, Gorazd Golob wrote: > nope - real device.. > > On Sat, 2006-05-27 at 16:01 -0400, Justin Piszcz wrote: >> Are you using loop-aes? >> >> On Sat, 27 May 2006, Gorazd Golob wrote: >> >>> Hi! >>> >>> Anyone have idea what does that mean? >>> >>> [376278.129936] Filesystem "sdb1": Corruption of in-memory data >>> detected. Shutting down filesystem: sdb1 >>> [376278.135533] Please umount the filesystem, and rectify the problem(s) >>> >>> Kernel is 2.6.15.6-1, SMP, x86_64 bit. Also I'm not able to unmount file >>> system - and according to lsof it's not in use. umout is telling me >>> "device is busy". >>> >>> Thanks, gorazd >>> >>> >>> > > From owner-xfs@oss.sgi.com Sat May 27 21:51:38 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 27 May 2006 21:51:47 -0700 (PDT) Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k4S4paeZ000530 for ; Sat, 27 May 2006 21:51:38 -0700 Received: from [62.30.165.31] (helo=vaio.housecafe.de) by mail.g-house.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1FkCDw-0000aK-Oc; Sun, 28 May 2006 05:45:52 +0200 Date: Sun, 28 May 2006 04:45:47 +0100 (BST) From: Christian Kujau X-X-Sender: dummy@vaio.testbed.de To: Christian , xfs@oss.sgi.com Subject: Re: XFS and noatime In-Reply-To: <200605272339.12352.lists@gammarayburst.de> Message-ID: References: <200605272339.12352.lists@gammarayburst.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 7830 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: evil@g-house.de Precedence: bulk X-list: xfs Content-Length: 1561 Lines: 48 On Sat, 27 May 2006, Markus Schoder wrote: > Seems that XFS updates the atime for binary files that are executed even > if noatime is specified on mount. hm, indeed: $ stat /bin/ls File: `/bin/ls' Size: 80008 Blocks: 160 IO Block: 4096 regular file Device: 805h/2053d Inode: 29524420 Links: 1 Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2006-05-28 04:27:20.524953761 +0100 Modify: 2006-03-02 20:08:55.000000000 +0000 Change: 2006-03-24 19:20:03.575659048 +0000 $ ls -d . . $ stat /bin/ls File: `/bin/ls' Size: 80008 Blocks: 160 IO Block: 4096 regular file Device: 805h/2053d Inode: 29524420 Links: 1 Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2006-05-28 04:39:56.024473625 +0100 Modify: 2006-03-02 20:08:55.000000000 +0000 Change: 2006-03-24 19:20:03.575659048 +0000 And it does not happen only after executing files, as I'm writing this /etc/passwd's atime have changed (and no, nobody else is on the box ;)) $ stat /etc/passwd File: `/etc/passwd' Size: 2441 Blocks: 8 IO Block: 4096 regular file Device: 805h/2053d Inode: 8389875 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2006-05-28 04:43:18.553907666 +0100 Modify: 2006-05-27 01:39:39.319279976 +0100 Change: 2006-05-27 01:39:39.329284198 +0100 2.6.17-rc3, i386, /dev/sda5 on / type xfs (rw,noatime) Christian. -- BOFH excuse #435: Internet shut down due to maintenance From owner-xfs@oss.sgi.com Sun May 28 08:34:10 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 28 May 2006 08:34:13 -0700 (PDT) Received: from mx1.pretago.de (mx1.pretago.de [89.110.132.150] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k4SFY7eZ005174 for ; Sun, 28 May 2006 08:34:10 -0700 Received: from localhost (localhost [127.0.0.1]) by mx1.pretago.de (Postfix) with ESMTP id 0081C2EC0E9; Sun, 28 May 2006 17:34:02 +0200 (CEST) Received: from mx1.pretago.de ([127.0.0.1]) by localhost (mx1 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05890-05; Sun, 28 May 2006 17:34:02 +0200 (CEST) Received: from noname (17.113.46.212.dsl.getacom.de [212.46.113.17]) (using TLSv1 with cipher EXP1024-RC4-SHA (56/128 bits)) (No client certificate requested) by mx1.pretago.de (Postfix) with ESMTP id 5C9452EC0E5; Sun, 28 May 2006 17:34:02 +0200 (CEST) From: Markus Schoder To: xfs@oss.sgi.com Subject: Re: XFS and noatime Date: Sun, 28 May 2006 17:33:56 +0200 User-Agent: KMail/1.9.1 Cc: Markus Schoder MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605281733.56889.lists@gammarayburst.de> X-archive-position: 7832 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lists@gammarayburst.de Precedence: bulk X-list: xfs Content-Length: 1168 Lines: 32 Christian Kujau wrote: > On Sat, 27 May 2006, Markus Schoder wrote: > > Seems that XFS updates the atime for binary files that are executed > > even if noatime is specified on mount. > > And it does not happen only after executing files, as I'm writing > this /etc/passwd's atime have changed (and no, nobody else is on the > box ;)) > > $ stat /etc/passwd > File: `/etc/passwd' > Size: 2441 Blocks: 8 IO Block: 4096 regular > file Device: 805h/2053d Inode: 8389875 Links: 1 > Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) > Access: 2006-05-28 04:43:18.553907666 +0100 > Modify: 2006-05-27 01:39:39.319279976 +0100 > Change: 2006-05-27 01:39:39.329284198 +0100 Oh no, looks like mmaping a file also changes atime (checked it with a tiny test progam). The stat command mmaps /etc/passwd probably to look up username and groupname (implicitly through libc I guess). This also explains why I get frequent disk accesses on a mostly idle box. Anybody knows wether this is easy to fix? I am on 2.6.16.18, amd64 by the way. -- Markus PS: Would it be possible to keep me on CC since I am not subscribed? From owner-xfs@oss.sgi.com Sun May 28 09:03:56 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 28 May 2006 09:03:59 -0700 (PDT) Received: from elfstone.noviforum.si (elfstone.noviforum.si [193.189.169.107]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k4SG3seZ008856 for ; Sun, 28 May 2006 09:03:56 -0700 Received: from localhost (localhost [127.0.0.1]) by elfstone.noviforum.si (ESMTP) with ESMTP id 7924D1B913 for ; Sun, 28 May 2006 18:00:22 +0200 (CEST) Received: from dacun.noviforum.si (dacun.noviforum.si [192.168.2.26]) by elfstone.noviforum.si (ESMTP) with ESMTP id 55A431B912 for ; Sun, 28 May 2006 18:00:22 +0200 (CEST) Subject: Re: Corruption of in-memory data From: Gorazd Golob To: xfs@oss.sgi.com In-Reply-To: <1148758234.16365.12.camel@dacun.noviforum.si> References: <1148758234.16365.12.camel@dacun.noviforum.si> Content-Type: text/plain Date: Sun, 28 May 2006 18:03:43 +0200 Message-Id: <1148832223.17036.34.camel@dacun.noviforum.si> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-archive-position: 7833 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: gorazd.golob@noviforum.si Precedence: bulk X-list: xfs Content-Length: 1041 Lines: 33 hi! I forgot to paste one line before that kernel msg; Whole message is: [446868.954403] xfs_force_shutdown(sdb1,0x8) called from line 1031 of file fs/xfs/xfs_trans.c. Return address = 0xffffffff802e7d5d [446868.995464] Filesystem "sdb1": Corruption of in-memory data detected. Shutting down filesystem: sdb1 [446869.000960] Please umount the filesystem, and rectify the problem(s) On Sat, 2006-05-27 at 21:30 +0200, Gorazd Golob wrote: > Hi! > > Anyone have idea what does that mean? > > [376278.129936] Filesystem "sdb1": Corruption of in-memory data > detected. Shutting down filesystem: sdb1 > [376278.135533] Please umount the filesystem, and rectify the problem(s) > > Kernel is 2.6.15.6-1, SMP, x86_64 bit. Also I'm not able to unmount file > system - and according to lsof it's not in use. umount is telling me > "device is busy" (can be some thread inside some java app) > > Also I have to mention that system have ecc ram and edac kernel feature > didn't count any errors on system memory.. > > Thanks, gorazd > > From owner-xfs@oss.sgi.com Sun May 28 15:23:07 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 28 May 2006 15:23:11 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k4SMN4eZ023036 for ; Sun, 28 May 2006 15:23:06 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA11104; Mon, 29 May 2006 08:22:43 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k4SMMdgw416815; Mon, 29 May 2006 08:22:40 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k4SMMYjM416103; Mon, 29 May 2006 08:22:34 +1000 (EST) Date: Mon, 29 May 2006 08:22:34 +1000 From: Nathan Scott To: Gorazd Golob Cc: xfs@oss.sgi.com Subject: Re: Corruption of in-memory data Message-ID: <20060529082234.A416157@wobbly.melbourne.sgi.com> References: <1148758234.16365.12.camel@dacun.noviforum.si> <1148832223.17036.34.camel@dacun.noviforum.si> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1148832223.17036.34.camel@dacun.noviforum.si>; from gorazd.golob@noviforum.si on Sun, May 28, 2006 at 06:03:43PM +0200 X-archive-position: 7835 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 1115 Lines: 36 Hi, On Sun, May 28, 2006 at 06:03:43PM +0200, Gorazd Golob wrote: > hi! > > I forgot to paste one line before that kernel msg; > Whole message is: > > [446868.954403] xfs_force_shutdown(sdb1,0x8) called from line 1031 of > file fs/xfs/xfs_trans.c. Return address = 0xffffffff802e7d5d > [446868.995464] Filesystem "sdb1": Corruption of in-memory data > detected. Shutting down filesystem: sdb1 > [446869.000960] Please umount the filesystem, and rectify the problem(s) > > On Sat, 2006-05-27 at 21:30 +0200, Gorazd Golob wrote: > > Hi! > > > > Anyone have idea what does that mean? > > > > [376278.129936] Filesystem "sdb1": Corruption of in-memory data > > detected. Shutting down filesystem: sdb1 > > [376278.135533] Please umount the filesystem, and rectify the problem(s) This is unfortuately a very generic "something went wrong" sort of message - something, somewhere (could be in/outside XFS) caused an error that caused a dirty transaction to have to be cancelled, and thats fatal. To answer your off-list mail, you might be able to remount read-only and run repair with -d. cheers. -- Nathan From owner-xfs@oss.sgi.com Sun May 28 15:26:25 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 28 May 2006 15:26:29 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k4SMQJeZ023477 for ; Sun, 28 May 2006 15:26:24 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA11144; Mon, 29 May 2006 08:26:07 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k4SMQ4gw415659; Mon, 29 May 2006 08:26:04 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k4SMPxTp416950; Mon, 29 May 2006 08:25:59 +1000 (EST) Date: Mon, 29 May 2006 08:25:58 +1000 From: Nathan Scott To: Markus Schoder Cc: xfs@oss.sgi.com Subject: Re: XFS and noatime Message-ID: <20060529082558.B416157@wobbly.melbourne.sgi.com> References: <200605272339.12352.lists@gammarayburst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200605272339.12352.lists@gammarayburst.de>; from lists@gammarayburst.de on Sat, May 27, 2006 at 11:39:12PM +0200 X-archive-position: 7836 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 432 Lines: 14 On Sat, May 27, 2006 at 11:39:12PM +0200, Markus Schoder wrote: > Seems that XFS updates the atime for binary files that are executed even > if noatime is specified on mount. > Is this the intended behaviour? ext3 for example behaves differently. It wasn't intended, no; it regressed one/two 2.6.x point releases ago. It has been fixed in CVS, and is queued up for the next merge which will be post 2.6.17. cheers. -- Nathan From owner-xfs@oss.sgi.com Sun May 28 15:27:39 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 28 May 2006 15:27:42 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k4SMRZeZ023846 for ; Sun, 28 May 2006 15:27:37 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA11151; Mon, 29 May 2006 08:27:19 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k4SMRHgw416964; Mon, 29 May 2006 08:27:17 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k4SMRFpZ417345; Mon, 29 May 2006 08:27:15 +1000 (EST) Date: Mon, 29 May 2006 08:27:14 +1000 From: Nathan Scott To: Markus Schoder Cc: xfs@oss.sgi.com Subject: Re: XFS and noatime Message-ID: <20060529082714.C416157@wobbly.melbourne.sgi.com> References: <200605281733.56889.lists@gammarayburst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200605281733.56889.lists@gammarayburst.de>; from lists@gammarayburst.de on Sun, May 28, 2006 at 05:33:56PM +0200 X-archive-position: 7837 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 242 Lines: 11 On Sun, May 28, 2006 at 05:33:56PM +0200, Markus Schoder wrote: > Oh no, looks like mmaping a file also changes atime (checked it with a > tiny test progam). Its the same issue, executing a binary involves mmaping it. cheers. -- Nathan From owner-xfs@oss.sgi.com Sun May 28 17:18:43 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 28 May 2006 17:18:49 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k4T0IeeZ006759 for ; Sun, 28 May 2006 17:18:42 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA13150; Mon, 29 May 2006 10:18:28 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id DAD864A588D4; Mon, 29 May 2006 10:18:26 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 953338 - endianness fix Message-Id: <20060529001826.DAD864A588D4@chook.melbourne.sgi.com> Date: Mon, 29 May 2006 10:18:26 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7838 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 1461 Lines: 27 Fix an endianness issue in the FreeBSD headers, remove a no-longer-needed HAVE macro too. Date: Mon May 29 10:17:44 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: rodrigc@crodrigues.org,cattelan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:26062a xfsprogs/VERSION - 1.151 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/VERSION.diff?r1=text&tr1=1.151&r2=text&tr2=1.150&f=h xfsprogs/doc/CHANGES - 1.204 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/doc/CHANGES.diff?r1=text&tr1=1.204&r2=text&tr2=1.203&f=h xfsprogs/include/xfs_arch.h - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_arch.h.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h xfsprogs/debian/changelog - 1.138 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/debian/changelog.diff?r1=text&tr1=1.138&r2=text&tr2=1.137&f=h xfsprogs/include/irix.h - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/irix.h.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h xfsprogs/include/freebsd.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/freebsd.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h xfsprogs/include/darwin.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/darwin.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h From owner-xfs@oss.sgi.com Sun May 28 17:34:01 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 28 May 2006 17:34:05 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k4T0XweZ008780 for ; Sun, 28 May 2006 17:34:00 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA13457; Mon, 29 May 2006 10:33:42 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k4T0Xcgw419651; Mon, 29 May 2006 10:33:38 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k4T0XX5E419833; Mon, 29 May 2006 10:33:33 +1000 (EST) Date: Mon, 29 May 2006 10:33:33 +1000 From: Nathan Scott To: Craig Rodrigues Cc: xfs@oss.sgi.com Subject: Re: Fix for endian macros on FreeBSD Message-ID: <20060529103333.A416915@wobbly.melbourne.sgi.com> References: <20060527132256.GA72643@crodrigues.org> <20060528070609.A387938@wobbly.melbourne.sgi.com> <20060527220443.GA4996@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060527220443.GA4996@crodrigues.org>; from rodrigc@crodrigues.org on Sat, May 27, 2006 at 06:04:43PM -0400 X-archive-position: 7839 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 521 Lines: 15 On Sat, May 27, 2006 at 06:04:43PM -0400, Craig Rodrigues wrote: > On Sun, May 28, 2006 at 07:06:09AM +1000, Nathan Scott wrote: > > Will do. It seems to me the HAVE_SWABMACROS macro is no longer > > useful, can you try a build with that #define removed from your > > freebsd.h please (and also the 3 INT_SWAPXX macros removed)? As > > Here is a patch that works for me. I had to change > to use __bswap16 instead of bswap16, because of > issues with macros expanding inside macros . OK, merged, thanks. -- Nathan From owner-xfs@oss.sgi.com Sun May 28 20:21:36 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 28 May 2006 20:21:39 -0700 (PDT) Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k4T3LYeZ032386 for ; Sun, 28 May 2006 20:21:35 -0700 Received: from [62.30.165.31] (helo=vaio.housecafe.de) by mail.g-house.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1FkXBg-0007fD-3z for xfs@oss.sgi.com; Mon, 29 May 2006 04:08:56 +0200 Date: Mon, 29 May 2006 03:08:53 +0100 (BST) From: Christian X-X-Sender: dummy@vaio.testbed.de To: xfs@oss.sgi.com Subject: Re: XFS and noatime In-Reply-To: <20060529082558.B416157@wobbly.melbourne.sgi.com> Message-ID: References: <200605272339.12352.lists@gammarayburst.de> <20060529082558.B416157@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 7840 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: evilninja@gmx.net Precedence: bulk X-list: xfs Content-Length: 341 Lines: 13 On Mon, 29 May 2006, Nathan Scott wrote: > It wasn't intended, no; it regressed one/two 2.6.x point releases > ago. It has been fixed in CVS, and is queued up for the next merge > which will be post 2.6.17. ah, that's good news then. thanks for your reply, Nathan. Christian. -- BOFH excuse #435: Internet shut down due to maintenance From owner-xfs@oss.sgi.com Sun May 28 23:06:34 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 28 May 2006 23:06:37 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k4T66VeZ016256 for ; Sun, 28 May 2006 23:06:33 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA19838 for ; Mon, 29 May 2006 16:06:23 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 1F2FE49E5DEB; Mon, 29 May 2006 16:06:23 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - merge back XFS changes from mainline Message-Id: <20060529060623.1F2FE49E5DEB@chook.melbourne.sgi.com> Date: Mon, 29 May 2006 16:06:23 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7841 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 5232 Lines: 128 Merge back use of slab-spreading memory allocation flag use from mainline. Date: Mon May 29 14:58:51 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: pj The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26068a linux-2.6/kmem.h - 1.37 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/kmem.h.diff?r1=text&tr1=1.37&r2=text&tr2=1.36&f=h Invalidate page loses its return code in 2.6.17, merge back from mainline. Date: Mon May 29 15:00:53 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: neilb The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26069a linux-2.6/xfs_aops.c - 1.125 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_aops.c.diff?r1=text&tr1=1.125&r2=text&tr2=1.124&f=h get_block is replaced by get_blocks in 2.6.17, merge back my mainline update. Date: Mon May 29 15:07:44 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: badari The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26070a linux-2.6/xfs_iops.c - 1.247 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_iops.c.diff?r1=text&tr1=1.247&r2=text&tr2=1.246&f=h linux-2.6/xfs_aops.c - 1.126 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_aops.c.diff?r1=text&tr1=1.126&r2=text&tr2=1.125&f=h linux-2.6/xfs_aops.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_aops.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h Merge back a new include and GFP_NOWAIT mem alloc macro use from mainline. Date: Mon May 29 15:10:42 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: pj,clameter The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26071a linux-2.6/xfs_buf.c - 1.222 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.c.diff?r1=text&tr1=1.222&r2=text&tr2=1.221&f=h Pull back various small mainline tidbits - percpu api changes mainly. Date: Mon May 29 15:38:22 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26073a xfs_vnodeops.c - 1.674 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.674&r2=text&tr2=1.673&f=h linux-2.6/xfs_vnode.h - 1.117 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vnode.h.diff?r1=text&tr1=1.117&r2=text&tr2=1.116&f=h linux-2.6/xfs_stats.c - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_stats.c.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h linux-2.6/xfs_super.c - 1.364 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c.diff?r1=text&tr1=1.364&r2=text&tr2=1.363&f=h linux-2.6/xfs_sysctl.c - 1.37 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_sysctl.c.diff?r1=text&tr1=1.37&r2=text&tr2=1.36&f=h linux-2.4/xfs_linux.h - 1.155 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_linux.h.diff?r1=text&tr1=1.155&r2=text&tr2=1.154&f=h Merge back the splice support code I added directly into mainline. Date: Mon May 29 16:02:00 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26074a linux-2.6/xfs_lrw.h - 1.53 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_lrw.h.diff?r1=text&tr1=1.53&r2=text&tr2=1.52&f=h linux-2.6/xfs_lrw.c - 1.241 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_lrw.c.diff?r1=text&tr1=1.241&r2=text&tr2=1.240&f=h linux-2.6/xfs_linux.h - 1.145 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_linux.h.diff?r1=text&tr1=1.145&r2=text&tr2=1.144&f=h linux-2.6/xfs_file.c - 1.135 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_file.c.diff?r1=text&tr1=1.135&r2=text&tr2=1.134&f=h linux-2.6/xfs_vnode.h - 1.118 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vnode.h.diff?r1=text&tr1=1.118&r2=text&tr2=1.117&f=h Merge back the const struct file_operations change from mainline. Date: Mon May 29 16:05:50 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26075a linux-2.6/xfs_file.c - 1.136 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_file.c.diff?r1=text&tr1=1.136&r2=text&tr2=1.135&f=h linux-2.6/xfs_iops.h - 1.29 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_iops.h.diff?r1=text&tr1=1.29&r2=text&tr2=1.28&f=h From owner-xfs@oss.sgi.com Mon May 29 18:15:32 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 29 May 2006 18:15:35 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k4U1FReZ000396 for ; Mon, 29 May 2006 18:15:31 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA09776 for ; Tue, 30 May 2006 11:15:19 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 9A78E49E5DEB; Tue, 30 May 2006 11:15:19 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - merge lockdep tweak Message-Id: <20060530011519.9A78E49E5DEB@chook.melbourne.sgi.com> Date: Tue, 30 May 2006 11:15:19 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7845 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 785 Lines: 23 lock validator: lockdep: small xfs init_rwsem() cleanup init_rwsem() has no return value. This is not a problem if init_rwsem() is a function, but it's a problem if it's a do { ... } while (0) macro. (which lockdep introduces) Signed-off-by: Ingo Molnar Signed-off-by: Arjan van de Ven Signed-off-by: Andrew Morton Date: Tue May 30 11:14:09 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: mingo The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26082a linux-2.6/mrlock.h - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/mrlock.h.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h From owner-xfs@oss.sgi.com Mon May 29 23:59:17 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 29 May 2006 23:59:23 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k4U6xDeZ026348 for ; Mon, 29 May 2006 23:59:15 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA16537 for ; Tue, 30 May 2006 16:59:05 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 1B7334875746; Tue, 30 May 2006 16:59:05 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - missing brelse on an error path Message-Id: <20060530065905.1B7334875746@chook.melbourne.sgi.com> Date: Tue, 30 May 2006 16:59:05 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7846 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 462 Lines: 14 Fix a buffer refcount leak in dir2 code on a forced shutdown. Date: Tue May 30 16:58:27 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: dgc The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26097a xfs_dir2_node.c - 1.55 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_node.c.diff?r1=text&tr1=1.55&r2=text&tr2=1.54&f=h From owner-xfs@oss.sgi.com Tue May 30 00:18:49 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 30 May 2006 00:18:52 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k4U7IjeZ029947 for ; Tue, 30 May 2006 00:18:47 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA17074; Tue, 30 May 2006 17:18:33 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 19C3F4875746; Tue, 30 May 2006 17:18:32 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 917976 - combat NULL files... Message-Id: <20060530071832.19C3F4875746@chook.melbourne.sgi.com> Date: Tue, 30 May 2006 17:18:32 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7847 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 2037 Lines: 35 Start writeout earlier (on last close) in the case where we have a truncate down followed by delayed allocation (buffered writes) - worst case scenario for the notorious NULL files problem. This reduces the window where we are exposed to that problem significantly. Date: Tue May 30 17:17:34 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: dgc The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26100a xfs_vnodeops.c - 1.676 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.676&r2=text&tr2=1.675&f=h linux-2.6/xfs_file.c - 1.138 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_file.c.diff?r1=text&tr1=1.138&r2=text&tr2=1.137&f=h linux-2.6/xfs_vnode.h - 1.120 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vnode.h.diff?r1=text&tr1=1.120&r2=text&tr2=1.119&f=h linux-2.6/xfs_fs_subr.c - 1.46 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_fs_subr.c.diff?r1=text&tr1=1.46&r2=text&tr2=1.45&f=h linux-2.6/xfs_aops.c - 1.129 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_aops.c.diff?r1=text&tr1=1.129&r2=text&tr2=1.128&f=h linux-2.4/xfs_file.c - 1.125 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_file.c.diff?r1=text&tr1=1.125&r2=text&tr2=1.124&f=h linux-2.4/xfs_vnode.h - 1.109 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_vnode.h.diff?r1=text&tr1=1.109&r2=text&tr2=1.108&f=h linux-2.4/xfs_fs_subr.c - 1.47 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_fs_subr.c.diff?r1=text&tr1=1.47&r2=text&tr2=1.46&f=h linux-2.4/xfs_aops.c - 1.102 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_aops.c.diff?r1=text&tr1=1.102&r2=text&tr2=1.101&f=h dmapi/xfs_dm.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/xfs_dm.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h From owner-xfs@oss.sgi.com Tue May 30 00:21:39 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 30 May 2006 00:21:42 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k4U7LZeZ002231 for ; Tue, 30 May 2006 00:21:37 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA17128 for ; Tue, 30 May 2006 17:21:28 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 2DD7D4875746; Tue, 30 May 2006 17:21:28 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - remove dead code Message-Id: <20060530072128.2DD7D4875746@chook.melbourne.sgi.com> Date: Tue, 30 May 2006 17:21:28 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7848 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 713 Lines: 18 Remove dead code from come bulkstat paths. Date: Tue May 30 17:21:11 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: vapo The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26102a xfs_itable.c - 1.137 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_itable.c.diff?r1=text&tr1=1.137&r2=text&tr2=1.136&f=h xfs_itable.h - 1.48 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_itable.h.diff?r1=text&tr1=1.48&r2=text&tr2=1.47&f=h quota/xfs_qm.c - 1.40 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm.c.diff?r1=text&tr1=1.40&r2=text&tr2=1.39&f=h From owner-xfs@oss.sgi.com Tue May 30 00:24:52 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 30 May 2006 00:24:57 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k4U7OmeZ002952 for ; Tue, 30 May 2006 00:24:50 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA17181; Tue, 30 May 2006 17:24:36 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 6E0844875746; Tue, 30 May 2006 17:24:36 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 953338 - portability tweaks Message-Id: <20060530072436.6E0844875746@chook.melbourne.sgi.com> Date: Tue, 30 May 2006 17:24:36 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7849 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 1726 Lines: 32 Portability changes: remove prdev, stick to one diagnostic interface. Date: Tue May 30 17:23:55 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: sjv The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26103a xfs_buf_item.c - 1.157 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_buf_item.c.diff?r1=text&tr1=1.157&r2=text&tr2=1.156&f=h xfs_rtalloc.c - 1.99 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_rtalloc.c.diff?r1=text&tr1=1.99&r2=text&tr2=1.98&f=h xfs_log_recover.c - 1.311 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_recover.c.diff?r1=text&tr1=1.311&r2=text&tr2=1.310&f=h xfs_trans_item.c - 1.45 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans_item.c.diff?r1=text&tr1=1.45&r2=text&tr2=1.44&f=h xfs_vfsops.c - 1.503 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.503&r2=text&tr2=1.502&f=h xfs_mount.c - 1.379 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.379&r2=text&tr2=1.378&f=h xfs_inode.c - 1.442 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.442&r2=text&tr2=1.441&f=h xfs_trans_buf.c - 1.125 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans_buf.c.diff?r1=text&tr1=1.125&r2=text&tr2=1.124&f=h support/debug.h - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/support/debug.h.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h support/debug.c - 1.32 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/support/debug.c.diff?r1=text&tr1=1.32&r2=text&tr2=1.31&f=h From owner-xfs@oss.sgi.com Tue May 30 01:06:11 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 30 May 2006 01:06:15 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k4U867eZ006013 for ; Tue, 30 May 2006 01:06:09 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA18076; Tue, 30 May 2006 18:05:54 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 547754875746; Tue, 30 May 2006 18:05:53 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 953338 - porting changes Message-Id: <20060530080553.547754875746@chook.melbourne.sgi.com> Date: Tue, 30 May 2006 18:05:53 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7850 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 16275 Lines: 250 Resolve a namespace collision on vfs/vfsops for FreeBSD porters. Date: Tue May 30 17:41:40 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: cattelan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26106a xfsidbg.c - 1.298 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfsidbg.c.diff?r1=text&tr1=1.298&r2=text&tr2=1.297&f=h xfs_log.c - 1.320 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log.c.diff?r1=text&tr1=1.320&r2=text&tr2=1.319&f=h xfs_dmapi.h - 1.57 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dmapi.h.diff?r1=text&tr1=1.57&r2=text&tr2=1.56&f=h xfs_iocore.c - 1.50 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iocore.c.diff?r1=text&tr1=1.50&r2=text&tr2=1.49&f=h xfs_vfsops.c - 1.504 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.504&r2=text&tr2=1.503&f=h xfs_iget.c - 1.213 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iget.c.diff?r1=text&tr1=1.213&r2=text&tr2=1.212&f=h xfs_mount.h - 1.222 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.h.diff?r1=text&tr1=1.222&r2=text&tr2=1.221&f=h xfs_mount.c - 1.380 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.380&r2=text&tr2=1.379&f=h xfs_inode.c - 1.443 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.443&r2=text&tr2=1.442&f=h xfs_inode.h - 1.213 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.h.diff?r1=text&tr1=1.213&r2=text&tr2=1.212&f=h xfs_fsops.c - 1.116 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_fsops.c.diff?r1=text&tr1=1.116&r2=text&tr2=1.115&f=h xfs_quota.h - 1.46 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_quota.h.diff?r1=text&tr1=1.46&r2=text&tr2=1.45&f=h quota/xfs_qm_bhv.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm_bhv.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h quota/xfs_qm_syscalls.c - 1.26 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm_syscalls.c.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h linux-2.6/xfs_vfs.h - 1.60 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vfs.h.diff?r1=text&tr1=1.60&r2=text&tr2=1.59&f=h linux-2.6/xfs_vfs.c - 1.69 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vfs.c.diff?r1=text&tr1=1.69&r2=text&tr2=1.68&f=h linux-2.6/xfs_vnode.c - 1.139 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vnode.c.diff?r1=text&tr1=1.139&r2=text&tr2=1.138&f=h linux-2.6/xfs_vnode.h - 1.121 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vnode.h.diff?r1=text&tr1=1.121&r2=text&tr2=1.120&f=h linux-2.6/xfs_super.c - 1.365 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c.diff?r1=text&tr1=1.365&r2=text&tr2=1.364&f=h linux-2.4/xfs_vfs.h - 1.60 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_vfs.h.diff?r1=text&tr1=1.60&r2=text&tr2=1.59&f=h linux-2.4/xfs_vfs.c - 1.63 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_vfs.c.diff?r1=text&tr1=1.63&r2=text&tr2=1.62&f=h linux-2.4/xfs_vnode.h - 1.110 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_vnode.h.diff?r1=text&tr1=1.110&r2=text&tr2=1.109&f=h linux-2.4/xfs_super.c - 1.330 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_super.c.diff?r1=text&tr1=1.330&r2=text&tr2=1.329&f=h linux-2.6/xfs_export.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_export.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h dmapi/xfs_dm_fsops.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/xfs_dm_fsops.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h dmapi/xfs_dm_bhv.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/xfs_dm_bhv.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h dmapi/xfs_dm.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/xfs_dm.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h Resolve a namespace collision on vnode/vnodeops for FreeBSD porters. Date: Tue May 30 18:03:24 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: cattelan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26107a xfsidbg.c - 1.299 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfsidbg.c.diff?r1=text&tr1=1.299&r2=text&tr2=1.298&f=h xfs_vnodeops.c - 1.677 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.677&r2=text&tr2=1.676&f=h xfs_itable.c - 1.138 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_itable.c.diff?r1=text&tr1=1.138&r2=text&tr2=1.137&f=h xfs_cap.h - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_cap.h.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h xfs_vfsops.c - 1.505 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.505&r2=text&tr2=1.504&f=h xfs_dfrag.c - 1.54 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dfrag.c.diff?r1=text&tr1=1.54&r2=text&tr2=1.53&f=h xfs_iget.c - 1.214 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iget.c.diff?r1=text&tr1=1.214&r2=text&tr2=1.213&f=h xfs_mount.h - 1.223 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.h.diff?r1=text&tr1=1.223&r2=text&tr2=1.222&f=h xfs_mount.c - 1.381 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.381&r2=text&tr2=1.380&f=h xfs_acl.h - 1.33 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_acl.h.diff?r1=text&tr1=1.33&r2=text&tr2=1.32&f=h xfs_acl.c - 1.60 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_acl.c.diff?r1=text&tr1=1.60&r2=text&tr2=1.59&f=h xfs_inode.c - 1.444 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.444&r2=text&tr2=1.443&f=h xfs_inode.h - 1.214 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.h.diff?r1=text&tr1=1.214&r2=text&tr2=1.213&f=h xfs_utils.c - 1.70 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_utils.c.diff?r1=text&tr1=1.70&r2=text&tr2=1.69&f=h xfs_utils.h - 1.34 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_utils.h.diff?r1=text&tr1=1.34&r2=text&tr2=1.33&f=h xfs_bmap.c - 1.351 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.c.diff?r1=text&tr1=1.351&r2=text&tr2=1.350&f=h xfs_rename.c - 1.66 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_rename.c.diff?r1=text&tr1=1.66&r2=text&tr2=1.65&f=h xfs_attr.c - 1.137 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr.c.diff?r1=text&tr1=1.137&r2=text&tr2=1.136&f=h xfs_attr.h - 1.35 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr.h.diff?r1=text&tr1=1.35&r2=text&tr2=1.34&f=h quota/xfs_qm_bhv.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm_bhv.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h quota/xfs_qm_syscalls.c - 1.27 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm_syscalls.c.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h xfs_refcache.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_refcache.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h linux-2.6/xfs_lrw.h - 1.54 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_lrw.h.diff?r1=text&tr1=1.54&r2=text&tr2=1.53&f=h linux-2.6/xfs_lrw.c - 1.244 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_lrw.c.diff?r1=text&tr1=1.244&r2=text&tr2=1.243&f=h linux-2.6/xfs_ioctl.c - 1.134 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ioctl.c.diff?r1=text&tr1=1.134&r2=text&tr2=1.133&f=h linux-2.6/xfs_vfs.h - 1.61 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vfs.h.diff?r1=text&tr1=1.61&r2=text&tr2=1.60&f=h linux-2.6/xfs_vfs.c - 1.70 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vfs.c.diff?r1=text&tr1=1.70&r2=text&tr2=1.69&f=h linux-2.6/xfs_file.c - 1.139 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_file.c.diff?r1=text&tr1=1.139&r2=text&tr2=1.138&f=h linux-2.6/xfs_vnode.c - 1.140 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vnode.c.diff?r1=text&tr1=1.140&r2=text&tr2=1.139&f=h linux-2.6/xfs_vnode.h - 1.122 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vnode.h.diff?r1=text&tr1=1.122&r2=text&tr2=1.121&f=h linux-2.6/xfs_fs_subr.c - 1.47 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_fs_subr.c.diff?r1=text&tr1=1.47&r2=text&tr2=1.46&f=h linux-2.6/xfs_super.h - 1.69 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.h.diff?r1=text&tr1=1.69&r2=text&tr2=1.68&f=h linux-2.6/xfs_super.c - 1.366 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c.diff?r1=text&tr1=1.366&r2=text&tr2=1.365&f=h linux-2.6/xfs_iops.c - 1.249 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_iops.c.diff?r1=text&tr1=1.249&r2=text&tr2=1.248&f=h linux-2.6/xfs_aops.c - 1.130 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_aops.c.diff?r1=text&tr1=1.130&r2=text&tr2=1.129&f=h linux-2.4/xfs_lrw.h - 1.49 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_lrw.h.diff?r1=text&tr1=1.49&r2=text&tr2=1.48&f=h linux-2.4/xfs_lrw.c - 1.234 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_lrw.c.diff?r1=text&tr1=1.234&r2=text&tr2=1.233&f=h linux-2.4/xfs_ioctl.c - 1.129 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ioctl.c.diff?r1=text&tr1=1.129&r2=text&tr2=1.128&f=h linux-2.4/xfs_vfs.h - 1.61 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_vfs.h.diff?r1=text&tr1=1.61&r2=text&tr2=1.60&f=h linux-2.4/xfs_vfs.c - 1.64 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_vfs.c.diff?r1=text&tr1=1.64&r2=text&tr2=1.63&f=h linux-2.4/xfs_file.c - 1.126 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_file.c.diff?r1=text&tr1=1.126&r2=text&tr2=1.125&f=h linux-2.4/xfs_vnode.c - 1.137 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_vnode.c.diff?r1=text&tr1=1.137&r2=text&tr2=1.136&f=h linux-2.4/xfs_vnode.h - 1.111 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_vnode.h.diff?r1=text&tr1=1.111&r2=text&tr2=1.110&f=h linux-2.4/xfs_fs_subr.c - 1.48 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_fs_subr.c.diff?r1=text&tr1=1.48&r2=text&tr2=1.47&f=h linux-2.4/xfs_super.h - 1.73 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_super.h.diff?r1=text&tr1=1.73&r2=text&tr2=1.72&f=h linux-2.4/xfs_super.c - 1.331 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_super.c.diff?r1=text&tr1=1.331&r2=text&tr2=1.330&f=h linux-2.4/xfs_iops.c - 1.224 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_iops.c.diff?r1=text&tr1=1.224&r2=text&tr2=1.223&f=h linux-2.4/xfs_aops.c - 1.103 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_aops.c.diff?r1=text&tr1=1.103&r2=text&tr2=1.102&f=h linux-2.6/xfs_ioctl32.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ioctl32.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h linux-2.6/xfs_export.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_export.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h linux-2.6/xfs_aops.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_aops.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h dmapi/xfs_dm_fsops.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/xfs_dm_fsops.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h dmapi/xfs_dm_bhv.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/xfs_dm_bhv.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h dmapi/xfs_dm.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/xfs_dm.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h Resolve a namespace collision on remaining vtypes for FreeBSD porters. Date: Tue May 30 18:05:05 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: cattelan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26108a xfs_rw.h - 1.79 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_rw.h.diff?r1=text&tr1=1.79&r2=text&tr2=1.78&f=h xfs_vnodeops.c - 1.678 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.678&r2=text&tr2=1.677&f=h xfs_vfsops.c - 1.506 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.506&r2=text&tr2=1.505&f=h xfs_mount.h - 1.224 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.h.diff?r1=text&tr1=1.224&r2=text&tr2=1.223&f=h xfs_acl.h - 1.34 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_acl.h.diff?r1=text&tr1=1.34&r2=text&tr2=1.33&f=h xfs_acl.c - 1.61 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_acl.c.diff?r1=text&tr1=1.61&r2=text&tr2=1.60&f=h xfs_utils.c - 1.71 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_utils.c.diff?r1=text&tr1=1.71&r2=text&tr2=1.70&f=h xfs_utils.h - 1.35 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_utils.h.diff?r1=text&tr1=1.35&r2=text&tr2=1.34&f=h xfs_rename.c - 1.67 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_rename.c.diff?r1=text&tr1=1.67&r2=text&tr2=1.66&f=h quota/xfs_qm_bhv.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm_bhv.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h linux-2.6/xfs_lrw.c - 1.245 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_lrw.c.diff?r1=text&tr1=1.245&r2=text&tr2=1.244&f=h linux-2.6/xfs_ioctl.c - 1.135 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ioctl.c.diff?r1=text&tr1=1.135&r2=text&tr2=1.134&f=h linux-2.6/xfs_vfs.h - 1.62 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vfs.h.diff?r1=text&tr1=1.62&r2=text&tr2=1.61&f=h linux-2.6/xfs_vfs.c - 1.71 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vfs.c.diff?r1=text&tr1=1.71&r2=text&tr2=1.70&f=h linux-2.6/xfs_vnode.c - 1.141 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vnode.c.diff?r1=text&tr1=1.141&r2=text&tr2=1.140&f=h linux-2.6/xfs_vnode.h - 1.123 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vnode.h.diff?r1=text&tr1=1.123&r2=text&tr2=1.122&f=h linux-2.6/xfs_iops.c - 1.250 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_iops.c.diff?r1=text&tr1=1.250&r2=text&tr2=1.249&f=h linux-2.4/xfs_lrw.c - 1.235 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_lrw.c.diff?r1=text&tr1=1.235&r2=text&tr2=1.234&f=h linux-2.4/xfs_ioctl.c - 1.130 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ioctl.c.diff?r1=text&tr1=1.130&r2=text&tr2=1.129&f=h linux-2.4/xfs_vfs.h - 1.62 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_vfs.h.diff?r1=text&tr1=1.62&r2=text&tr2=1.61&f=h linux-2.4/xfs_vfs.c - 1.65 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_vfs.c.diff?r1=text&tr1=1.65&r2=text&tr2=1.64&f=h linux-2.4/xfs_vnode.c - 1.138 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_vnode.c.diff?r1=text&tr1=1.138&r2=text&tr2=1.137&f=h linux-2.4/xfs_vnode.h - 1.112 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_vnode.h.diff?r1=text&tr1=1.112&r2=text&tr2=1.111&f=h linux-2.4/xfs_iops.c - 1.225 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_iops.c.diff?r1=text&tr1=1.225&r2=text&tr2=1.224&f=h dmapi/xfs_dm.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/xfs_dm.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h From owner-xfs@oss.sgi.com Tue May 30 01:14:55 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 30 May 2006 01:14:58 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k4U8EpeZ007438 for ; Tue, 30 May 2006 01:14:53 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA18173 for ; Tue, 30 May 2006 18:14:44 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 677F74875746; Tue, 30 May 2006 18:14:44 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 904192 - remove unused parameter Message-Id: <20060530081444.677F74875746@chook.melbourne.sgi.com> Date: Tue, 30 May 2006 18:14:44 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7851 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 444 Lines: 14 Remove unused parameter from di2xflags routine. Date: Tue May 30 18:14:24 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: vapo The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26110a xfs_inode.c - 1.445 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.445&r2=text&tr2=1.444&f=h From owner-xfs@oss.sgi.com Tue May 30 01:16:27 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 30 May 2006 01:16:30 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k4U8GNeZ007826 for ; Tue, 30 May 2006 01:16:26 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA18197 for ; Tue, 30 May 2006 18:16:16 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id D93D84875746; Tue, 30 May 2006 18:16:14 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - fix fsstress warnings Message-Id: <20060530081614.D93D84875746@chook.melbourne.sgi.com> Date: Tue, 30 May 2006 18:16:14 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7852 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 614 Lines: 17 Fix up debug code so that bulkstat wont generate thousands of fsstress warnings. Date: Tue May 30 18:15:57 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: vapo The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26111a xfs_ialloc.c - 1.188 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_ialloc.c.diff?r1=text&tr1=1.188&r2=text&tr2=1.187&f=h xfs_inode.c - 1.446 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.446&r2=text&tr2=1.445&f=h From owner-xfs@oss.sgi.com Tue May 30 01:17:44 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 30 May 2006 01:17:47 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k4U8HfeZ008223 for ; Tue, 30 May 2006 01:17:43 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA18319 for ; Tue, 30 May 2006 18:17:33 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id D0BE54875746; Tue, 30 May 2006 18:17:33 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - fix bp command Message-Id: <20060530081733.D0BE54875746@chook.melbourne.sgi.com> Date: Tue, 30 May 2006 18:17:33 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7853 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 439 Lines: 14 Fix a kdb command name conflict - bp vs bp. Date: Tue May 30 18:17:15 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: sandeen The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26112a xfsidbg.c - 1.300 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfsidbg.c.diff?r1=text&tr1=1.300&r2=text&tr2=1.299&f=h From owner-xfs@oss.sgi.com Tue May 30 21:39:18 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 30 May 2006 21:39:21 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k4V4dEeZ016782 for ; Tue, 30 May 2006 21:39:16 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA15693; Wed, 31 May 2006 14:38:57 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k4V4crgw480915; Wed, 31 May 2006 14:38:54 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k4V4cnV2482357; Wed, 31 May 2006 14:38:49 +1000 (EST) Date: Wed, 31 May 2006 14:38:49 +1000 From: Nathan Scott To: Janos Haar Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: XFS related hang (was Re: How to send a break? - dump from frozen 64bit linux) Message-ID: <20060531143849.C478554@wobbly.melbourne.sgi.com> References: <01b701c6818d$4bcd37b0$1800a8c0@dcccs> <20060527234350.GA13881@voodoo.jdc.home> <004501c68225$00add170$1800a8c0@dcccs> <9a8748490605280917l73f5751cmf40674fc22726c43@mail.gmail.com> <01d801c6827c$fba04ca0$1800a8c0@dcccs> <01a801c683d2$e7a79c10$1800a8c0@dcccs> <200605301903.k4UJ3xQU008919@turing-police.cc.vt.edu> <1149038431.21827.20.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1149038431.21827.20.camel@localhost.localdomain>; from rostedt@goodmis.org on Tue, May 30, 2006 at 09:20:31PM -0400 X-archive-position: 7857 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 2562 Lines: 65 On Tue, May 30, 2006 at 09:20:31PM -0400, Steven Rostedt wrote: > Added all those listed in the MAINTAINERS file for XFS. Thanks Steve. > On Tue, 2006-05-30 at 15:03 -0400, Valdis.Kletnieks@vt.edu wrote: > > On Tue, 30 May 2006 12:22:01 +0200, Janos Haar said: > > Half the processes on the box seem wedged at that same mutex_lock. I can't > > seem to find an xfs_qm_shake in my source tree though. Its in fs/xfs/quota/xfs_qm.c. > kswapd0 D ffff81011fe03c38 0 297 1 1287 19 (L-TLB) > ffff81011fe03c38 0000000000000004 000000000000000a ffff81011f92ba68 > ffff81011f92b850 ffffffff805a23a0 0000149f99fa7d7c 000000000003bcde > 000000002f2c46e0 ffff81008bc37180 > Call Trace: {schedule_timeout+34} > {xfs_qm_dqunpin_wait+220} {debug_mutex_free_waiter+141} So, we're waiting here on a synchronisation variable that'll be released once the dquot metadata buffer write completes. > So it is now waiting to be woken up by something that calls: > > xfs_qm_dquot_logitem_unpin which seems to be the function to wake it > up. Mhmm, that'd be called by the I/O completion handler on the buffer containing that dquot. > And decyphering all the macro crap it seems that the function that wakes > it up is xfs_trans_chunk_committed, or xfs_trans_uncommit. Right (the former, at this point in the code). > The above xfs_qm_dqunpin_wait still looks awfully racy, and the > xfs_log_force, which I'm assuming wakes up whoever is suppose to wake up > kswapd0, doesn't have a return code check. So if it failed to do The logforce isn't race-critical here - its ensuring writeout of previously logged buffers is started before we go to sleep waiting for the driver to wake us up when its done. An earlier I/O error on the journal is the only thing the log force can return as an error there, which isnt useful at that point anyway (we're in a kernel thread trying to free mem). > whatever the hell it's doing (that code gives me a headache), it looks Heh, likewise. I have voodoo dolls of one or two of the early XFS folks that I like to poke with needles occasionally.. :) > like this guy might sleep forever holding a lock that will prevent > others from freeing kernel memory. It will sleep until the previously initiated buffer write is done. AFAICT, we aren't seeing the I/O completion here for some reason... which points more to a possible device driver or h/ware issue (that is the usual root cause of this sort of hang, anyway). cheers. -- Nathan From owner-xfs@oss.sgi.com Wed May 31 04:21:46 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 31 May 2006 04:21:59 -0700 (PDT) Received: from dynamicweb.hu (ns.dynamicweb.hu [195.228.155.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k4VBLheZ003954 for ; Wed, 31 May 2006 04:21:45 -0700 Received: from dcccs (53d82c8b.adsl.enternet.hu [83.216.44.139]) by dynamicweb.hu (8.13.5/8.12.8) with SMTP id k4V7vFrQ031312; Wed, 31 May 2006 09:57:16 +0200 Message-ID: <00f501c68488$4d10c080$1800a8c0@dcccs> From: "Janos Haar" To: "Nathan Scott" Cc: , References: <01b701c6818d$4bcd37b0$1800a8c0@dcccs> <20060527234350.GA13881@voodoo.jdc.home> <004501c68225$00add170$1800a8c0@dcccs> <9a8748490605280917l73f5751cmf40674fc22726c43@mail.gmail.com> <01d801c6827c$fba04ca0$1800a8c0@dcccs> <01a801c683d2$e7a79c10$1800a8c0@dcccs> <200605301903.k4UJ3xQU008919@turing-police.cc.vt.edu> <1149038431.21827.20.camel@localhost.localdomain> <20060531143849.C478554@wobbly.melbourne.sgi.com> Subject: Re: XFS related hang (was Re: How to send a break? - dump from frozen 64bit linux) Date: Wed, 31 May 2006 10:00:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-archive-position: 7858 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: djani22@netcenter.hu Precedence: bulk X-list: xfs Content-Length: 3535 Lines: 97 ----- Original Message ----- From: "Nathan Scott" To: "Janos Haar" Cc: ; Sent: Wednesday, May 31, 2006 6:38 AM Subject: XFS related hang (was Re: How to send a break? - dump from frozen 64bit linux) > On Tue, May 30, 2006 at 09:20:31PM -0400, Steven Rostedt wrote: > > Added all those listed in the MAINTAINERS file for XFS. > > Thanks Steve. > > > On Tue, 2006-05-30 at 15:03 -0400, Valdis.Kletnieks@vt.edu wrote: > > > On Tue, 30 May 2006 12:22:01 +0200, Janos Haar said: > > > Half the processes on the box seem wedged at that same mutex_lock. I can't > > > seem to find an xfs_qm_shake in my source tree though. > > Its in fs/xfs/quota/xfs_qm.c. > > > kswapd0 D ffff81011fe03c38 0 297 1 1287 19 (L-TLB) > > ffff81011fe03c38 0000000000000004 000000000000000a ffff81011f92ba68 > > ffff81011f92b850 ffffffff805a23a0 0000149f99fa7d7c 000000000003bcde > > 000000002f2c46e0 ffff81008bc37180 > > Call Trace: {schedule_timeout+34} > > {xfs_qm_dqunpin_wait+220} {debug_mutex_free_waiter+141} > > So, we're waiting here on a synchronisation variable that'll > be released once the dquot metadata buffer write completes. > > > So it is now waiting to be woken up by something that calls: > > > > xfs_qm_dquot_logitem_unpin which seems to be the function to wake it > > up. > > Mhmm, that'd be called by the I/O completion handler on the buffer > containing that dquot. > > > And decyphering all the macro crap it seems that the function that wakes > > it up is xfs_trans_chunk_committed, or xfs_trans_uncommit. > > Right (the former, at this point in the code). > > > The above xfs_qm_dqunpin_wait still looks awfully racy, and the > > xfs_log_force, which I'm assuming wakes up whoever is suppose to wake up > > kswapd0, doesn't have a return code check. So if it failed to do > > The logforce isn't race-critical here - its ensuring writeout > of previously logged buffers is started before we go to sleep > waiting for the driver to wake us up when its done. > > An earlier I/O error on the journal is the only thing the log > force can return as an error there, which isnt useful at that > point anyway (we're in a kernel thread trying to free mem). > > > whatever the hell it's doing (that code gives me a headache), it looks > > Heh, likewise. I have voodoo dolls of one or two of the early > XFS folks that I like to poke with needles occasionally.. :) > > > like this guy might sleep forever holding a lock that will prevent > > others from freeing kernel memory. > > It will sleep until the previously initiated buffer write is done. > AFAICT, we aren't seeing the I/O completion here for some reason... > which points more to a possible device driver or h/ware issue (that > is the usual root cause of this sort of hang, anyway). > > cheers. Hey, i think i found something. My quota on my huge device is broken. (inferno -- 18014398504855404 0 0 18446744073709551519 0 0) I cant found a way to re-initialize it. But anyway, at this point i dont need it, trying to disable the quota usage. We will see.... Thanks a lot! Janos > > -- > Nathan > - > 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-xfs@oss.sgi.com Wed May 31 14:54:59 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 31 May 2006 14:55:15 -0700 (PDT) Received: from linux01.gwdg.de (linux01.gwdg.de [134.76.13.21]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k4VLsteZ020844 for ; Wed, 31 May 2006 14:54:59 -0700 Received: from linux01.gwdg.de (localhost [127.0.0.1]) by linux01.gwdg.de (8.13.3/8.13.3/SuSE Linux 0.7) with ESMTP id k4VLsllq030681; Wed, 31 May 2006 23:54:49 +0200 Received: from localhost (jengelh@localhost) by linux01.gwdg.de (8.13.3/8.13.3/Submit) with ESMTP id k4VLslNO030675; Wed, 31 May 2006 23:54:47 +0200 Date: Wed, 31 May 2006 23:54:45 +0200 (MEST) From: Jan Engelhardt To: Janos Haar cc: Nathan Scott , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS related hang (was Re: How to send a break? - dump from frozen 64bit linux) In-Reply-To: <00f501c68488$4d10c080$1800a8c0@dcccs> Message-ID: References: <01b701c6818d$4bcd37b0$1800a8c0@dcccs> <20060527234350.GA13881@voodoo.jdc.home> <004501c68225$00add170$1800a8c0@dcccs> <9a8748490605280917l73f5751cmf40674fc22726c43@mail.gmail.com> <01d801c6827c$fba04ca0$1800a8c0@dcccs> <01a801c683d2$e7a79c10$1800a8c0@dcccs> <200605301903.k4UJ3xQU008919@turing-police.cc.vt.edu> <1149038431.21827.20.camel@localhost.localdomain> <20060531143849.C478554@wobbly.melbourne.sgi.com> <00f501c68488$4d10c080$1800a8c0@dcccs> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 7860 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jengelh@linux01.gwdg.de Precedence: bulk X-list: xfs Content-Length: 479 Lines: 24 > >Hey, i think i found something. >My quota on my huge device is broken. That should not be a problem. I ran into that "problem" too but had no lockups back then (2.6.16-rc1). >(inferno -- 18014398504855404 0 0 18446744073709551519 >0 0) >I cant found a way to re-initialize it. Reinit: quotaoff /mntpt umount /mntpt mount /mntpt >But anyway, at this point i dont need it, trying to disable the quota usage. >We will see.... Jan Engelhardt --