From owner-linux-xfs@oss.sgi.com Sat Feb 1 04:45:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 01 Feb 2003 04:45:37 -0800 (PST) Received: from hotmail.com (oe45.law9.hotmail.com [64.4.8.17]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h11CjQ3v013494 for ; Sat, 1 Feb 2003 04:45:26 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 1 Feb 2003 04:52:45 -0800 X-Originating-IP: [213.23.7.198] From: "Kai Leibrandt" To: Subject: Another mkfs.xfs RAID Question Date: Sat, 1 Feb 2003 13:52:41 +0100 Message-ID: <000001c2c9f0$ced5d750$0500a8c0@Bilbo> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2605 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-OriginalArrivalTime: 01 Feb 2003 12:52:45.0846 (UTC) FILETIME=[D12C2360:01C2C9F0] X-archive-position: 2488 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: k_leibrandt@hotmail.com Precedence: bulk X-list: linux-xfs Hi all, Dragos' question about the su,sw options led me to have another look at my Mylex RAID setup, and I now am confused too... My RAID controller tells me that the primary RAID volume (a 3-disk RAID 5) has a Stripe Size of 64k and a Segment Size of 8k. So for this setup should the sunit be set to 64k or to 8k (the segment size)??? The manual fo the DAC says that the segment size is the preferred io size for caching, but xfs has a preferred io size equal to the stripe size - which to choose? Many thanks, Kai. From owner-linux-xfs@oss.sgi.com Sat Feb 1 04:57:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 01 Feb 2003 04:57:09 -0800 (PST) Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h11Cv33v014036 for ; Sat, 1 Feb 2003 04:57:05 -0800 Received: from pc9391.physik.uni-regensburg.de (pc9391.physik.uni-regensburg.de [132.199.98.219]) by rrzs2.rz.uni-regensburg.de (8.11.6+Sun/8.11.6) with ESMTP id h11D4Re24224 for ; Sat, 1 Feb 2003 14:04:27 +0100 (MET) Received: from guc28561 by pc9391.physik.uni-regensburg.de with local (Exim 3.35 #1 (Debian)) id 18exJr-0002A1-00 for ; Sat, 01 Feb 2003 14:04:27 +0100 Date: Sat, 1 Feb 2003 14:04:27 +0100 From: Christian Guggenberger To: linux-xfs@oss.sgi.com Subject: Yet Another mkfs.xfs RAID Question Message-ID: <20030201130427.GA8128@pc9391.physik.uni-regensburg.de> Reply-To: Christian.Guggenberger@physik.uni-regensburg.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-archive-position: 2489 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Christian.Guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Hi, I'm going to set up a new 1.7 TB HW Raid 5 next week. RAID 5 contains 11 disks, Stripe Unit should be (according to the manual) 128k. so my mkfs.xfs options will be sunit=256, swidth=2560 for the data section, won't they? I will definitly use internal log, so I'd like to ask, if I should use logversion 2, and what sunit and swidth values I should use here? I guess the same as for the data section??? Would I gain something from logversion 2? thx Christian From owner-linux-xfs@oss.sgi.com Sat Feb 1 08:38:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 01 Feb 2003 08:38:18 -0800 (PST) Received: from hera.cwi.nl (hera.cwi.nl [192.16.191.8]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h11GcA3v019761 for ; Sat, 1 Feb 2003 08:38:11 -0800 Received: from apps.cwi.nl (apps.cwi.nl [192.16.191.34]) by hera.cwi.nl with ESMTP id RAA11002 for ; Sat, 1 Feb 2003 17:45:29 +0100 (MET) From: Andries.Brouwer@cwi.nl Received: by apps.cwi.nl id h11GjTX02579; Sat, 1 Feb 2003 17:45:29 +0100 (MET) Date: Sat, 1 Feb 2003 17:45:29 +0100 (MET) Message-Id: To: Andries.Brouwer@cwi.nl, kaos@ocs.com.au Subject: Re: system call documentation Cc: a.gruenbacher@computer.org, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com X-archive-position: 2490 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: Andries.Brouwer@cwi.nl Precedence: bulk X-list: linux-xfs From kaos@ocs.com.au Sat Feb 1 14:22:31 2003 >Preparing the next man page release, I compared the list of >system calls for i386 in 2.4.20 with the list of documented >system calls. It looks like > >fgetxattr, > ... >are undocumented so far. *xattr* man pages are in the XFS tree and Andreas Gruenbacher's site, contents forwarded under separate copy. getxattr.2: getxattr, lgetxattr, fgetxattr2 listxattr.2: listxattr, llistxattr, flistxattr removexattr.2: removexattr, lremovexattr, fremovexattr setxattr.2: setxattr, lsetxattr, fsetxattr Good. Thanks! However, .\" (C) Andreas Gruenbacher, February 2001 .\" (C) Silicon Graphics Inc, September 2001 there is no indication that redistribution (of possibly modified copies) is permitted. Andries From owner-linux-xfs@oss.sgi.com Sat Feb 1 08:59:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 01 Feb 2003 08:59:51 -0800 (PST) Received: from waltsathlon.localhost.net (12-229-130-237.client.attbi.com [12.229.130.237]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h11Gxi3v020394 for ; Sat, 1 Feb 2003 08:59:44 -0800 Received: from comcast.net (localhost.localhost.net [127.0.0.1]) by waltsathlon.localhost.net (Postfix) with ESMTP id 407021C318FF; Sat, 1 Feb 2003 09:07:04 -0800 (PST) Message-ID: <3E3BFEB7.7050407@comcast.net> Date: Sat, 01 Feb 2003 09:07:03 -0800 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian.Guggenberger@physik.uni-regensburg.de Cc: linux-xfs@oss.sgi.com Subject: Re: Yet Another mkfs.xfs RAID Question References: <20030201130427.GA8128@pc9391.physik.uni-regensburg.de> In-Reply-To: <20030201130427.GA8128@pc9391.physik.uni-regensburg.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2491 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: waltabbyh@comcast.net Precedence: bulk X-list: linux-xfs Christian Guggenberger wrote: > Hi, > > I'm going to set up a new 1.7 TB HW Raid 5 next week. > RAID 5 contains 11 disks, Stripe Unit should be (according to the manual) > 128k. > so my mkfs.xfs options will be sunit=256, swidth=2560 for the data section, won't they? > > I will definitly use internal log, so I'd like to ask, if I should use > logversion 2, and what sunit and swidth values I should use here? > I guess the same as for the data section??? > > Would I gain something from logversion 2? > > thx > Christian > > Are you using software md raid or hardware raid? If it's hardware raid 5, the logversion argument shouldn't matter. Software raid is another story. I recently setup a file/database server with a six disk software raid 5 setup. I had time to try different raid chunksizes as well as experiment with version 1 vs. version 2 logs. What I found, for my case, version 2 logs for xfs really helped out in create/delete operations. Particularly deletes. Sequential read/writes were unaffected by the version differences. I ran many Bonnie++ runs as well as created a script that created 2000 directories with 10000 files in each directory and then proceeded to delete the whole lot. Each result was timed, although I don't have any numbers for you. I remember version 2 logs as performing much better for these types of uses. HTH, -Walt From owner-linux-xfs@oss.sgi.com Sat Feb 1 12:55:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 01 Feb 2003 12:55:35 -0800 (PST) Received: from jaguar.mkp.net (jaguar.mkp.net [66.11.169.42]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h11KtV3v022988 for ; Sat, 1 Feb 2003 12:55:32 -0800 Received: from austin.mkp.net (rover.mkp.net [209.217.122.9]) by jaguar.mkp.net (Postfix) with ESMTP id 4C1AF177F4; Sat, 1 Feb 2003 16:02:56 -0500 (EST) Received: by austin.mkp.net (Postfix, from userid 1654) id 9B6DE4448D; Sat, 1 Feb 2003 16:03:01 -0500 (EST) To: "Kai Leibrandt" Cc: Subject: Re: Another mkfs.xfs RAID Question From: "Martin K. Petersen" Organization: mkp.net References: <000001c2c9f0$ced5d750$0500a8c0@Bilbo> Date: 01 Feb 2003 16:03:01 -0500 In-Reply-To: <000001c2c9f0$ced5d750$0500a8c0@Bilbo> Message-ID: Lines: 22 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 2492 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: mkp@mkp.net Precedence: bulk X-list: linux-xfs >>>>> "Kai" == Kai Leibrandt writes: Kai> Dragos' question about the su,sw options led me to have another Kai> look at my Mylex RAID setup, and I now am confused too... My Kai> RAID controller tells me that the primary RAID volume (a 3-disk Kai> RAID 5) has a Stripe Size of 64k and a Segment Size of 8k. So for Kai> this setup should the sunit be set to 64k or to 8k (the segment Kai> size)??? The manual fo the DAC says that the segment size is the Kai> preferred io size for caching, but xfs has a preferred io size Kai> equal to the stripe size - which to choose? Hmmm. My guess would be that the Mylex uses 8k hardware sectors internally and does read/modify/write on those. Whether the 64K is stripe width or stripe unit, I don't know. The real answer is the same as always: Try both settings with your anticipated I/O load and see which one performs better. -- Martin K. Petersen http://mkp.net/ From owner-linux-xfs@oss.sgi.com Sat Feb 1 13:13:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 01 Feb 2003 13:13:19 -0800 (PST) Received: from jaguar.mkp.net (jaguar.mkp.net [66.11.169.42]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h11LDF3v023922 for ; Sat, 1 Feb 2003 13:13:16 -0800 Received: from austin.mkp.net (rover.mkp.net [209.217.122.9]) by jaguar.mkp.net (Postfix) with ESMTP id 22A0B177F4; Sat, 1 Feb 2003 16:20:41 -0500 (EST) Received: by austin.mkp.net (Postfix, from userid 1654) id 0BE5F4448D; Sat, 1 Feb 2003 16:20:47 -0500 (EST) To: Christian.Guggenberger@physik.uni-regensburg.de Cc: linux-xfs@oss.sgi.com Subject: Re: Yet Another mkfs.xfs RAID Question From: "Martin K. Petersen" Organization: mkp.net References: <20030201130427.GA8128@pc9391.physik.uni-regensburg.de> Date: 01 Feb 2003 16:20:46 -0500 In-Reply-To: <20030201130427.GA8128@pc9391.physik.uni-regensburg.de> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 2494 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: mkp@mkp.net Precedence: bulk X-list: linux-xfs Content-Length: 908 Lines: 26 >>>>> "Christian" == Christian Guggenberger writes: Christian> I'm going to set up a new 1.7 TB HW Raid 5 next week. RAID Christian> 5 contains 11 disks, Stripe Unit should be (according to Christian> the manual) 128k. so my mkfs.xfs options will be Christian> sunit=256, swidth=2560 for the data section, won't they? Yup. Christian> I will definitly use internal log, so I'd like to ask, if I Christian> should use logversion 2, and what sunit and swidth values I Christian> should use here? I guess the same as for the data Christian> section??? 128KB log alignment seems a bit of an overkill. Does your controller state which chunk size it uses internally? Most controllers use 4-16KB blocks for RAID5. So try aligning your log to values in that neighbourhood. There's no swidth for the log, btw. -- Martin K. Petersen http://mkp.net/ From owner-linux-xfs@oss.sgi.com Sun Feb 2 06:19:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 02 Feb 2003 06:19:31 -0800 (PST) Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h12EJK3v006207 for ; Sun, 2 Feb 2003 06:19:21 -0800 Received: from pc9391.physik.uni-regensburg.de (pc9391.physik.uni-regensburg.de [132.199.98.219]) by rrzs2.rz.uni-regensburg.de (8.11.6+Sun/8.11.6) with ESMTP id h12EQme12060 for ; Sun, 2 Feb 2003 15:26:48 +0100 (MET) Received: from guc28561 by pc9391.physik.uni-regensburg.de with local (Exim 3.35 #1 (Debian)) id 18fL56-0003Oy-00 for ; Sun, 02 Feb 2003 15:26:48 +0100 Date: Sun, 2 Feb 2003 15:26:48 +0100 From: Christian Guggenberger To: linux-xfs@oss.sgi.com Subject: Re: Yet Another mkfs.xfs RAID Question] Message-ID: <20030202142648.GB12810@pc9391.physik.uni-regensburg.de> Reply-To: Christian.Guggenberger@physik.uni-regensburg.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-archive-position: 2495 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Christian.Guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Content-Length: 1363 Lines: 36 On Sat, Feb 01, 2003 at 04:20:46PM -0500, Martin K. Petersen wrote: > >>>>> "Christian" == Christian Guggenberger writes: > > Christian> I'm going to set up a new 1.7 TB HW Raid 5 next week. RAID > Christian> 5 contains 11 disks, Stripe Unit should be (according to > Christian> the manual) 128k. so my mkfs.xfs options will be > Christian> sunit=256, swidth=2560 for the data section, won't they? > > Yup. > > > Christian> I will definitly use internal log, so I'd like to ask, if I > Christian> should use logversion 2, and what sunit and swidth values I > Christian> should use here? I guess the same as for the data > Christian> section??? > > 128KB log alignment seems a bit of an overkill. > > Does your controller state which chunk size it uses internally? Most > controllers use 4-16KB blocks for RAID5. So try aligning your log to > values in that neighbourhood. > thanks for your quick answer! The only Documentation about stripe or chunk size I got from the vendor is, to use 32k chunk size for random read/write optimaziation or 128k chunk for sequentiell read/write optimaziation... No mention about what the contoller does internally! so I will stay with logversion 1 and sunit, switdh arguments for data section as mentioned above. @Walt, yes its an hardware Raid5 thanks Christian From owner-linux-xfs@oss.sgi.com Sun Feb 2 06:58:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 02 Feb 2003 06:58:57 -0800 (PST) Received: from waltsathlon.localhost.net (12-229-130-237.client.attbi.com [12.229.130.237]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h12Ewp3v006943 for ; Sun, 2 Feb 2003 06:58:52 -0800 Received: from comcast.net (localhost.localhost.net [127.0.0.1]) by waltsathlon.localhost.net (Postfix) with ESMTP id 8BE0F1C31C5D; Sun, 2 Feb 2003 07:06:15 -0800 (PST) Message-ID: <3E3D33E7.4040301@comcast.net> Date: Sun, 02 Feb 2003 07:06:15 -0800 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian.Guggenberger@physik.uni-regensburg.de Cc: linux-xfs@oss.sgi.com Subject: Re: Yet Another mkfs.xfs RAID Question] References: <20030202142648.GB12810@pc9391.physik.uni-regensburg.de> In-Reply-To: <20030202142648.GB12810@pc9391.physik.uni-regensburg.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2496 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: waltabbyh@comcast.net Precedence: bulk X-list: linux-xfs Content-Length: 1515 Lines: 44 Christian Guggenberger wrote: > On Sat, Feb 01, 2003 at 04:20:46PM -0500, Martin K. Petersen wrote: > >>>>>>>"Christian" == Christian Guggenberger writes: >> >>Christian> I'm going to set up a new 1.7 TB HW Raid 5 next week. RAID >>Christian> 5 contains 11 disks, Stripe Unit should be (according to >>Christian> the manual) 128k. so my mkfs.xfs options will be >>Christian> sunit=256, swidth=2560 for the data section, won't they? >> >>Yup. >> >> >>Christian> I will definitly use internal log, so I'd like to ask, if I >>Christian> should use logversion 2, and what sunit and swidth values I >>Christian> should use here? I guess the same as for the data >>Christian> section??? >> >>128KB log alignment seems a bit of an overkill. >> >>Does your controller state which chunk size it uses internally? Most >>controllers use 4-16KB blocks for RAID5. So try aligning your log to >>values in that neighbourhood. >> > > thanks for your quick answer! > The only Documentation about stripe or chunk size I got from the vendor is, > to use 32k chunk size for random read/write optimaziation or 128k chunk for > sequentiell read/write optimaziation... No mention about what the contoller > does internally! > > so I will stay with logversion 1 and sunit, switdh arguments for data > section as mentioned above. > > @Walt, yes its an hardware Raid5 > > thanks > Christian > > Sorry 'bout that. That's what I get for trying to reply without my coffee yet :) From owner-linux-xfs@oss.sgi.com Sun Feb 2 07:05:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 02 Feb 2003 07:05:02 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h12F4x3v007444 for ; Sun, 2 Feb 2003 07:04:59 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h12FL1kq016537 for ; Sun, 2 Feb 2003 09:21:01 -0600 Received: from tulip-e236.americas.sgi.com (tulip-e236.americas.sgi.com [128.162.236.208]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA80429; Sun, 2 Feb 2003 09:12:21 -0600 (CST) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-47.corp.sgi.com [134.15.64.47]) by tulip-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id JAA17263; Sun, 2 Feb 2003 09:12:22 -0600 (CST) Subject: Re: Yet Another mkfs.xfs RAID Question From: Stephen Lord To: "Martin K. Petersen" Cc: Christian.Guggenberger@physik.uni-regensburg.de, linux-xfs@oss.sgi.com In-Reply-To: References: <20030201130427.GA8128@pc9391.physik.uni-regensburg.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 02 Feb 2003 09:11:55 -0600 Message-Id: <1044198718.1372.0.camel@localhost.localdomain> Mime-Version: 1.0 X-archive-position: 2497 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1031 Lines: 29 On Sat, 2003-02-01 at 15:20, Martin K. Petersen wrote: > >>>>> "Christian" == Christian Guggenberger writes: > > Christian> I'm going to set up a new 1.7 TB HW Raid 5 next week. RAID > Christian> 5 contains 11 disks, Stripe Unit should be (according to > Christian> the manual) 128k. so my mkfs.xfs options will be > Christian> sunit=256, swidth=2560 for the data section, won't they? > > Yup. > > > Christian> I will definitly use internal log, so I'd like to ask, if I > Christian> should use logversion 2, and what sunit and swidth values I > Christian> should use here? I guess the same as for the data > Christian> section??? > > 128KB log alignment seems a bit of an overkill. > > Does your controller state which chunk size it uses internally? Most > controllers use 4-16KB blocks for RAID5. So try aligning your log to > values in that neighbourhood. 4K is usually enough to fix performance issues, but it may be dependent on the underlying raid too. Steve From owner-linux-xfs@oss.sgi.com Sun Feb 2 07:18:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 02 Feb 2003 07:18:32 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h12FIS3v008006 for ; Sun, 2 Feb 2003 07:18:28 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h12FYUkq016654 for ; Sun, 2 Feb 2003 09:34:30 -0600 Received: from tulip-e236.americas.sgi.com (tulip-e236.americas.sgi.com [128.162.236.208]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA81342; Sun, 2 Feb 2003 09:25:51 -0600 (CST) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-47.corp.sgi.com [134.15.64.47]) by tulip-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id JAA13016; Sun, 2 Feb 2003 09:25:47 -0600 (CST) Subject: Re: system call documentation From: Stephen Lord To: Andries.Brouwer@cwi.nl Cc: kaos@ocs.com.au, a.gruenbacher@computer.org, Linux Kernel Mailing List , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 02 Feb 2003 09:25:21 -0600 Message-Id: <1044199525.1372.8.camel@localhost.localdomain> Mime-Version: 1.0 X-archive-position: 2498 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1255 Lines: 46 On Sat, 2003-02-01 at 10:45, Andries.Brouwer@cwi.nl wrote: > From kaos@ocs.com.au Sat Feb 1 14:22:31 2003 > > >Preparing the next man page release, I compared the list of > >system calls for i386 in 2.4.20 with the list of documented > >system calls. It looks like > > > >fgetxattr, > > ... > >are undocumented so far. > > *xattr* man pages are in the XFS tree and Andreas Gruenbacher's site, > contents forwarded under separate copy. > > getxattr.2: getxattr, lgetxattr, fgetxattr2 > listxattr.2: listxattr, llistxattr, flistxattr > removexattr.2: removexattr, lremovexattr, fremovexattr > setxattr.2: setxattr, lsetxattr, fsetxattr > > Good. Thanks! > > However, > > .\" (C) Andreas Gruenbacher, February 2001 > .\" (C) Silicon Graphics Inc, September 2001 > > there is no indication that redistribution (of possibly modified > copies) is permitted. > > Andries > > There should be no problem with redistribution, I can probably get someone to update them soon. I presume Andreas will also have no problems with this. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Sun Feb 2 07:19:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 02 Feb 2003 07:19:48 -0800 (PST) Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h12FJj3v008217 for ; Sun, 2 Feb 2003 07:19:46 -0800 Received: from pc9391.physik.uni-regensburg.de (pc9391.physik.uni-regensburg.de [132.199.98.219]) by rrzs2.rz.uni-regensburg.de (8.11.6+Sun/8.11.6) with ESMTP id h12FRBe19361; Sun, 2 Feb 2003 16:27:11 +0100 (MET) Received: from guc28561 by pc9391.physik.uni-regensburg.de with local (Exim 3.35 #1 (Debian)) id 18fM1X-0003nZ-00; Sun, 02 Feb 2003 16:27:11 +0100 Date: Sun, 2 Feb 2003 16:27:11 +0100 From: Christian Guggenberger To: Stephen Lord Cc: linux-xfs@oss.sgi.com, waltabbyh@comcast.net, mkp@mkp.net Subject: Re: Yet Another mkfs.xfs RAID Question Message-ID: <20030202152711.GA14360@pc9391.physik.uni-regensburg.de> Reply-To: Christian.Guggenberger@physik.uni-regensburg.de References: <20030201130427.GA8128@pc9391.physik.uni-regensburg.de> <1044198718.1372.0.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1044198718.1372.0.camel@localhost.localdomain> User-Agent: Mutt/1.3.28i X-archive-position: 2499 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Christian.Guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Content-Length: 1293 Lines: 34 On Sun, Feb 02, 2003 at 09:11:55AM -0600, Stephen Lord wrote: > On Sat, 2003-02-01 at 15:20, Martin K. Petersen wrote: > > >>>>> "Christian" == Christian Guggenberger writes: > > > > Christian> I'm going to set up a new 1.7 TB HW Raid 5 next week. RAID > > Christian> 5 contains 11 disks, Stripe Unit should be (according to > > Christian> the manual) 128k. so my mkfs.xfs options will be > > Christian> sunit=256, swidth=2560 for the data section, won't they? > > > > Yup. > > > > > > Christian> I will definitly use internal log, so I'd like to ask, if I > > Christian> should use logversion 2, and what sunit and swidth values I > > Christian> should use here? I guess the same as for the data > > Christian> section??? > > > > 128KB log alignment seems a bit of an overkill. > > > > Does your controller state which chunk size it uses internally? Most > > controllers use 4-16KB blocks for RAID5. So try aligning your log to > > values in that neighbourhood. > > 4K is usually enough to fix performance issues, but it may be dependent > on the underlying raid too. > I could give it try, anyway... This sunit options for the logsection can be overruled at mount time, could'n't they?? I'll check out the manpage. Christian From owner-linux-xfs@oss.sgi.com Sun Feb 2 07:33:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 02 Feb 2003 07:33:45 -0800 (PST) Received: from muriel.parsec.at (muriel.parsec.at [80.120.166.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h12FXe3v008923 for ; Sun, 2 Feb 2003 07:33:42 -0800 Received: from localhost (ag@localhost) by muriel.parsec.at (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id h12Fedm01902; Sun, 2 Feb 2003 16:40:39 +0100 Date: Sun, 2 Feb 2003 16:40:39 +0100 (CET) From: Andreas Gruenbacher X-X-Sender: To: Stephen Lord cc: , , Linux Kernel Mailing List , Subject: Re: system call documentation [license question] In-Reply-To: <1044199525.1372.8.camel@localhost.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2500 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: ag@bestbits.at Precedence: bulk X-list: linux-xfs Content-Length: 1191 Lines: 38 On 2 Feb 2003, Stephen Lord wrote: > On Sat, 2003-02-01 at 10:45, Andries.Brouwer@cwi.nl wrote: > > [...] > > > > *xattr* man pages are in the XFS tree and Andreas Gruenbacher's site, > > contents forwarded under separate copy. > > > > getxattr.2: getxattr, lgetxattr, fgetxattr2 > > listxattr.2: listxattr, llistxattr, flistxattr > > removexattr.2: removexattr, lremovexattr, fremovexattr > > setxattr.2: setxattr, lsetxattr, fsetxattr > > > > Good. Thanks! > > > > However, > > > > .\" (C) Andreas Gruenbacher, February 2001 > > .\" (C) Silicon Graphics Inc, September 2001 > > > > there is no indication that redistribution (of possibly modified > > copies) is permitted. > > > > Andries > > There should be no problem with redistribution, I can probably get > someone to update them soon. I presume Andreas will also have no > problems with this. The man pages are intended to be GPL licensed, while libacl (and libattr) was originally intended to be under LGPL. I have been quite lazy on putting that right into the package. I assume that nobody has any objections. Maybe someone wants to add that information to the CVS? Regards, Andreas. From owner-linux-xfs@oss.sgi.com Sun Feb 2 07:42:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 02 Feb 2003 07:43:00 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h12Fgu3v009424 for ; Sun, 2 Feb 2003 07:42:57 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 922F714DC1; Sun, 2 Feb 2003 16:50:20 +0100 (MET) Date: Sun, 2 Feb 2003 16:50:17 +0100 From: Andi Kleen To: Andreas Gruenbacher Cc: Stephen Lord , Andries.Brouwer@cwi.nl, kaos@ocs.com.au, linux-xfs@oss.sgi.com Subject: Re: system call documentation [license question] Message-ID: <20030202155017.GA13373@wotan.suse.de> References: <1044199525.1372.8.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-archive-position: 2501 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: ak@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 802 Lines: 20 [l-k dropped from cc because there are already too many off-topic threads there] > The man pages are intended to be GPL licensed, while libacl (and libattr) > was originally intended to be under LGPL. I have been quite lazy on IMHO GPL or LGPL doesn't make much sense for documentation. For example if someone printed them out and sold them as book would you really want to force them to include a CD with the roff format ("prefered format for modification")? When I wrote man pages I put them onto the same license as most of the other man pages are, which roughly says "do what you want, but add a changelog for changes and don't remove my name" Another alternative would be the new FDL from the FSF (http://www.fsf.org/licenses/fdl.html) but it seems to be a bit too complicated for me. -Andi From owner-linux-xfs@oss.sgi.com Sun Feb 2 10:48:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 02 Feb 2003 10:48:17 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h12Im73v011168 for ; Sun, 2 Feb 2003 10:48:08 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18fPH5-0000QI-00; Sun, 02 Feb 2003 18:55:27 +0000 Date: Sun, 2 Feb 2003 18:55:27 +0000 From: Christoph Hellwig To: Andi Kleen Cc: Andreas Gruenbacher , Stephen Lord , Andries.Brouwer@cwi.nl, kaos@ocs.com.au, linux-xfs@oss.sgi.com Subject: Re: system call documentation [license question] Message-ID: <20030202185526.A1558@infradead.org> References: <1044199525.1372.8.camel@localhost.localdomain> <20030202155017.GA13373@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030202155017.GA13373@wotan.suse.de>; from ak@suse.de on Sun, Feb 02, 2003 at 04:50:17PM +0100 X-archive-position: 2502 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 485 Lines: 12 On Sun, Feb 02, 2003 at 04:50:17PM +0100, Andi Kleen wrote: > Another alternative would be the new FDL from the FSF > (http://www.fsf.org/licenses/fdl.html) > but it seems to be a bit too complicated for me. At least the Debian folks considere this license non-free (and I fully agree with tham, not that it matters..), so there's a singnificant part of the Linux userbase that won't easily get them. I'd be happy if we wouldn't get any FDL-pollution into linux-specific packages.. From owner-linux-xfs@oss.sgi.com Sun Feb 2 10:56:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 02 Feb 2003 10:56:08 -0800 (PST) Received: from phoenix.infradead.org (phoenix.mvhi.com [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h12Iu43v011650 for ; Sun, 2 Feb 2003 10:56:05 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18fPOm-0000Rz-00; Sun, 02 Feb 2003 19:03:24 +0000 Date: Sun, 2 Feb 2003 19:03:24 +0000 From: Christoph Hellwig To: Andi Kleen Cc: Andreas Gruenbacher , Stephen Lord , Andries.Brouwer@cwi.nl, kaos@ocs.com.au, linux-xfs@oss.sgi.com Subject: Re: system call documentation [license question] Message-ID: <20030202190324.A1723@infradead.org> References: <1044199525.1372.8.camel@localhost.localdomain> <20030202155017.GA13373@wotan.suse.de> <20030202185526.A1558@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030202185526.A1558@infradead.org>; from hch@infradead.org on Sun, Feb 02, 2003 at 06:55:27PM +0000 X-archive-position: 2503 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 642 Lines: 14 On Sun, Feb 02, 2003 at 06:55:27PM +0000, Christoph Hellwig wrote: > At least the Debian folks considere this license non-free (and I fully > agree with tham, not that it matters..), so there's a singnificant > part of the Linux userbase that won't easily get them. (Small addition before I get flamed heavily) The FSF-advocacy of the FDL is optional, but even this part beeing written down in the FDL makes it hard to find out whether something FDL-licensed actually is free or not and makes the license a rather bad choice. IMHO a BSD-style license is a very good choice for documentation, but other people may have other preferences.. From owner-linux-xfs@oss.sgi.com Sun Feb 2 11:09:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 02 Feb 2003 11:09:17 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h12J993v012196 for ; Sun, 2 Feb 2003 11:09:10 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id E7484189371D; Sun, 2 Feb 2003 11:16:39 -0800 (PST) Date: Sun, 2 Feb 2003 11:16:39 -0800 From: Chris Wedgwood To: Andi Kleen Cc: Andreas Gruenbacher , Stephen Lord , Andries.Brouwer@cwi.nl, kaos@ocs.com.au, linux-xfs@oss.sgi.com Subject: Re: system call documentation [license question] Message-ID: <20030202191639.GA8222@f00f.org> References: <1044199525.1372.8.camel@localhost.localdomain> <20030202155017.GA13373@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030202155017.GA13373@wotan.suse.de> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2504 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: 410 Lines: 14 On Sun, Feb 02, 2003 at 04:50:17PM +0100, Andi Kleen wrote: > When I wrote man pages I put them onto the same license as most of > the other man pages are, which roughly says "do what you want, but > add a changelog for changes and don't remove my name" what about "do what you want; but don't blame, sue or call me if stuff breaks" ? does retention of a name really matter than much to ones ego? --cw From owner-linux-xfs@oss.sgi.com Sun Feb 2 16:41:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 02 Feb 2003 16:41:20 -0800 (PST) Received: from ente.berdmann.de (frnk-d514e1a2.dsl.mediaWays.net [213.20.225.162]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h130fA3v015004 for ; Sun, 2 Feb 2003 16:41:12 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.35 #1) id 18fUDQ-0002vc-00; Mon, 03 Feb 2003 01:12:00 +0100 Message-ID: <3E3DB3D0.5090300@berdmann.de> Date: Mon, 03 Feb 2003 01:12:00 +0100 From: Bernhard Erdmann User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Eric Sandeen CC: Kwon SoonSon , linux-xfs@oss.sgi.com Subject: Re: some XFS questions References: <20030127083818.84351.qmail@web7306.mail.yahoo.co.kr> <1043706127.11527.162.camel@stout.americas.sgi.com> In-Reply-To: <1043706127.11527.162.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2505 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: be@berdmann.de Precedence: bulk X-list: linux-xfs Content-Length: 693 Lines: 24 Eric Sandeen wrote: [...] >>3. in xfs_dinode_core, there is di_projid. >>What is this for? > > > Irix has the concepts of user, group, and project, I believe. Probably > not used on Linux, but retained for on-disk compat. [...] http://techpubs.sgi.com/library/manuals/2000/007-2859-020/pdf/007-2859-020.pdf states on p. 105: "A project ID is similar to a group ID, with two major exceptions: * The current project ID is associated within an entire array session, not an individual process. * The project ID does not affect access permissions; it is intended mainly for accounting purposes, and is in fact reported in extended accounting information (see extacct(5) for details)." From owner-linux-xfs@oss.sgi.com Mon Feb 3 05:45:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Feb 2003 05:45:27 -0800 (PST) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h13DjH3v001623 for ; Mon, 3 Feb 2003 05:45:18 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h13CxdKp006922 for ; Mon, 3 Feb 2003 04:59:39 -0800 Received: from tulip-e236.americas.sgi.com (tulip-e236.americas.sgi.com [128.162.236.208]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA00155; Mon, 3 Feb 2003 07:52:41 -0600 (CST) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-72.corp.sgi.com [134.15.64.72]) by tulip-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id HAA96809; Mon, 3 Feb 2003 07:52:39 -0600 (CST) Subject: Re: Yet Another mkfs.xfs RAID Question From: Stephen Lord To: Christian.Guggenberger@physik.uni-regensburg.de Cc: linux-xfs@oss.sgi.com, waltabbyh@comcast.net, mkp@mkp.net In-Reply-To: <20030202152711.GA14360@pc9391.physik.uni-regensburg.de> References: <20030201130427.GA8128@pc9391.physik.uni-regensburg.de> <1044198718.1372.0.camel@localhost.localdomain> <20030202152711.GA14360@pc9391.physik.uni-regensburg.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 03 Feb 2003 07:52:09 -0600 Message-Id: <1044280332.1726.24.camel@localhost.localdomain> Mime-Version: 1.0 X-archive-position: 2506 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 331 Lines: 16 On Sun, 2003-02-02 at 09:27, Christian Guggenberger wrote: > > > I could give it try, anyway... > This sunit options for the logsection can be overruled at mount time, > could'n't they?? > > I'll check out the manpage. > > Christian I don't think you can override log stripe alignment, just the data stripe alignment. Steve From owner-linux-xfs@oss.sgi.com Mon Feb 3 11:45:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Feb 2003 11:45:21 -0800 (PST) Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h13JjC3v028173 for ; Mon, 3 Feb 2003 11:45:14 -0800 Received: from pc9391.physik.uni-regensburg.de (pc9391.physik.uni-regensburg.de [132.199.98.219]) by rrzs2.rz.uni-regensburg.de (8.11.6+Sun/8.11.6) with ESMTP id h13Jqkx13358 for ; Mon, 3 Feb 2003 20:52:46 +0100 (MET) Received: from guc28561 by pc9391.physik.uni-regensburg.de with local (Exim 3.35 #1 (Debian)) id 18fme6-0006nn-00 for ; Mon, 03 Feb 2003 20:52:46 +0100 Date: Mon, 3 Feb 2003 20:52:46 +0100 From: Christian Guggenberger To: linux-xfs@oss.sgi.com Subject: Re: Yet Another mkfs.xfs RAID Question Message-ID: <20030203195246.GB25508@pc9391.physik.uni-regensburg.de> Reply-To: Christian.Guggenberger@physik.uni-regensburg.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-archive-position: 2507 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Christian.Guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Content-Length: 851 Lines: 27 On Mon, Feb 03, 2003 at 07:52:09AM -0600, Stephen Lord wrote: > On Sun, 2003-02-02 at 09:27, Christian Guggenberger wrote: > > > > > I could give it try, anyway... > > This sunit options for the logsection can be overruled at mount time, > > could'n't they?? > > > > I'll check out the manpage. > > > > Christian > > I don't think you can override log stripe alignment, just the data > stripe alignment. > okay. Any other problems with log v2, sunit=8 I could run into?? Another (little) Question: My machine has 2 GB Ram, and from tomorrow on, 4.3 TB will be exported via kernel-nfsd. Till now, I mount all big xfs partitions with logbufs=8. Could this cause any trouble, as my mounted xfs-filesystem size grows that way? I read in the man pages that too high logbufs values may cause problems when main memory is too little... thx Christian From owner-linux-xfs@oss.sgi.com Mon Feb 3 12:05:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Feb 2003 12:05:58 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h13K5r3v028761 for ; Mon, 3 Feb 2003 12:05:54 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h13IDWG8028272 for ; Mon, 3 Feb 2003 10:13:32 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA02818 for ; Mon, 3 Feb 2003 14:13:21 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA51395 for ; Mon, 3 Feb 2003 14:13:21 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h13KDLX25989; Mon, 3 Feb 2003 14:13:21 -0600 Message-Id: <200302032013.h13KDLX25989@jen.americas.sgi.com> Date: Mon, 3 Feb 2003 14:13:21 -0600 Subject: TAKE - XFS I/O path tweaks To: linux-xfs@oss.sgi.com X-archive-position: 2508 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 590 Lines: 21 cleanup delayed allocate write path a little and fix some small bugs in there. Date: Mon Feb 3 12:10:40 PST 2003 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:138445a linux/fs/xfs/linux/xfs_aops.c - 1.17 - Improve documentation, fix the handling of buffer heads on the dirty list, and the vnode modified state when converting delalloc space to real space. linux/fs/xfs/linux/xfs_iomap.c - 1.5 - Add support for a trylock case in the release page path. From owner-linux-xfs@oss.sgi.com Mon Feb 3 12:14:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Feb 2003 12:14:17 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h13KEF3v029246 for ; Mon, 3 Feb 2003 12:14:15 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h13KEF8u029245 for linux-xfs@oss.sgi.com; Mon, 3 Feb 2003 12:14:15 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h13KED3x029231 for ; Mon, 3 Feb 2003 12:14:14 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h13JrHQo028683; Mon, 3 Feb 2003 11:53:17 -0800 Date: Mon, 3 Feb 2003 11:53:17 -0800 Message-Id: <200302031953.h13JrHQo028683@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 213] New: XFS kernel patch breaks kdemultimedia X-Bugzilla-Reason: AssignedTo X-archive-position: 2509 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1212 Lines: 52 http://oss.sgi.com/bugzilla/show_bug.cgi?id=213 Summary: XFS kernel patch breaks kdemultimedia Product: Linux XFS Version: Current Platform: IA32 OS/Version: Linux Status: NEW Severity: normal Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: garethclay@ntlworld.com What kernel are you using: 2.4.20 Where did the XFS code come from? (CVS, Linus, your distribution, etc): Your patch, xfs-2.4.20-all-i386.bz2 Description of Problem: When the kernel is patched with the XFS patch, the kdemultimedia package of the KDE desktop (www.kde.org) can't be compiled. I submitted this as a bug in KDE, but they claim it's not a KDE problem - they say it's XFS. You can find all the information including the compiler output at http://bugs.kde.org/show_bug.cgi?id=52669. Thanks for your attention :) How Reproducible: Steps to Reproduce: 1. 2. 3. Actual Results: Expected Results: Additional Information: ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Feb 3 22:12:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Feb 2003 22:12:26 -0800 (PST) Received: from lindy.SoftHome.net (ip212.CamelotCourt.com [66.54.152.212] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h146CH3v007574 for ; Mon, 3 Feb 2003 22:12:17 -0800 Received: from localhost (localhost [127.0.0.1]) (uid 422) by lindy.SoftHome.net with local; Mon, 03 Feb 2003 23:20:14 -0700 To: linux-xfs@oss.sgi.com Subject: xfs oops Organization: SoftHome X-URL: http://SoftHome.net/ Date: Mon, 03 Feb 2003 23:20:14 -0700 From: Brian Grossman Message-ID: X-archive-position: 2510 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: brian@SoftHome.net Precedence: bulk X-list: linux-xfs Content-Length: 3147 Lines: 75 This oops is with kernel 2.4.20 + preemptable patch + xfs + v4l2. The cpu is an athlon. Streamer records tv to disk from bttv. The recording is going to an xfs partition. There are also ext3 and reiserfs partitions on this system. The taint is a geforce4 video card. From: kern.log: Unable to handle kernel paging request at virtual address 28252227 printing eip: c012f83d *pde = 00000000 Oops: 0002 CPU: 0 EIP: 0010:[kmem_cache_free+125/176] Tainted: P EFLAGS: 00010046 eax: dab8e000 ebx: 00000000 ecx: c8eda000 edx: 28252223 esi: c184be50 edi: 00000202 ebp: 000001d2 esp: c2611dd0 ds: 0018 es: 0018 ss: 0018 Process streamer (pid: 28823, stackpage=c2611000) Stack: c8eda0c0 c8eda0c0 c8eda0c0 000001d2 c013a49a c184be50 c8eda0c0 c013c371 c8eda0c0 c8eda0c0 c107f4a8 000001d2 c2610000 c107f4a8 c107f4a8 c013a7e9 c2610000 c107f4c4 c0130824 c107f4a8 000001d2 00000020 000001d2 00000020 Call Trace: [__put_unused_buffer_head+42/96] [try_to_free_buffers+129/368] [try_to_release_page+73/80] [shrink_cache+612/1040] [shrink_caches+86/128] [try_to_free_pages_zone+60/96] [balance_classzone+93/464] [__alloc_pages+274/352] [generic_file_write_nolock+977/1760] [_alloc_pages+22/32] [generic_file_write_nolock+1005/1760] [xfs:pagebuf_offset_R2a780972+32860/48288] [xfs:pagebuf_offset_R2a780972+10643/48288] [sys_write+150/304] [system_call+51/56] Code: 89 42 04 89 10 c7 01 00 00 00 00 c7 41 04 00 00 00 00 8b 46 <6>note: streamer[28823] exited with preempt_count 3 And after ksymoops: Unable to handle kernel paging request at virtual address 28252227 c012f83d *pde = 00000000 Oops: 0002 CPU: 0 EIP: 0010:[kmem_cache_free+125/176] Tainted: P EFLAGS: 00010046 eax: dab8e000 ebx: 00000000 ecx: c8eda000 edx: 28252223 esi: c184be50 edi: 00000202 ebp: 000001d2 esp: c2611dd0 ds: 0018 es: 0018 ss: 0018 Process streamer (pid: 28823, stackpage=c2611000) Stack: c8eda0c0 c8eda0c0 c8eda0c0 000001d2 c013a49a c184be50 c8eda0c0 c013c371 c8eda0c0 c8eda0c0 c107f4a8 000001d2 c2610000 c107f4a8 c107f4a8 c013a7e9 c2610000 c107f4c4 c0130824 c107f4a8 000001d2 00000020 000001d2 00000020 Call Trace: [__put_unused_buffer_head+42/96] [try_to_free_buffers+129/368] [try_to_release_page+73/80] [shrink_cache+612/1040] [shrink_caches+86/128] Code: 89 42 04 89 10 c7 01 00 00 00 00 c7 41 04 00 00 00 00 8b 46 Using defaults from ksymoops -t elf32-i386 -a i386 >>eax; dab8e000 <_end+1a8a5894/3060d894> >>ecx; c8eda000 <_end+8bf1894/3060d894> >>edx; 28252223 Before first symbol >>esi; c184be50 <_end+15636e4/3060d894> >>esp; c2611dd0 <_end+2329664/3060d894> Code; 00000000 Before first symbol 00000000 <_EIP>: Code; 00000000 Before first symbol 0: 89 42 04 mov %eax,0x4(%edx) Code; 00000003 Before first symbol 3: 89 10 mov %edx,(%eax) Code; 00000005 Before first symbol 5: c7 01 00 00 00 00 movl $0x0,(%ecx) Code; 0000000b Before first symbol b: c7 41 04 00 00 00 00 movl $0x0,0x4(%ecx) Code; 00000012 Before first symbol 12: 8b 46 00 mov 0x0(%esi),%eax From owner-linux-xfs@oss.sgi.com Tue Feb 4 01:08:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Feb 2003 01:08:12 -0800 (PST) Received: from phoenix.infradead.org (phoenix.mvhi.com [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h149833v025666 for ; Tue, 4 Feb 2003 01:08:04 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18fzB4-0007aj-00; Tue, 04 Feb 2003 09:15:38 +0000 Date: Tue, 4 Feb 2003 09:15:38 +0000 From: Christoph Hellwig To: Brian Grossman Cc: linux-xfs@oss.sgi.com Subject: Re: xfs oops Message-ID: <20030204091538.A29171@infradead.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from brian@SoftHome.net on Mon, Feb 03, 2003 at 11:20:14PM -0700 X-archive-position: 2511 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 403 Lines: 11 On Mon, Feb 03, 2003 at 11:20:14PM -0700, Brian Grossman wrote: > > This oops is with kernel 2.4.20 + preemptable patch + xfs + v4l2. > The cpu is an athlon. > Streamer records tv to disk from bttv. The recording is going > to an xfs partition. > There are also ext3 and reiserfs partitions on this system. > The taint is a geforce4 video card. Please try to reproduce it without the preempt patch. From owner-linux-xfs@oss.sgi.com Tue Feb 4 01:44:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Feb 2003 01:44:24 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h149iG3v030900 for ; Tue, 4 Feb 2003 01:44:16 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h149iGGH030899 for linux-xfs@oss.sgi.com; Tue, 4 Feb 2003 01:44:16 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h149iE3x030885 for ; Tue, 4 Feb 2003 01:44:14 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h149ec8b030848; Tue, 4 Feb 2003 01:40:38 -0800 Date: Tue, 4 Feb 2003 01:40:38 -0800 Message-Id: <200302040940.h149ec8b030848@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 213] XFS kernel patch breaks kdemultimedia X-Bugzilla-Reason: AssignedTo X-archive-position: 2512 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 458 Lines: 16 http://oss.sgi.com/bugzilla/show_bug.cgi?id=213 ------- Additional Comments From gale@dstl.gov.uk 2003-02-04 01:40 ------- Userspace programs must not be compiled with arbitrary kernel headers (but with the headers that gcc was complied with) - thats the Linus policy. If your distribution still does this it is completely broken. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Feb 4 02:20:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Feb 2003 02:20:31 -0800 (PST) Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h14AKP3v000351 for ; Tue, 4 Feb 2003 02:20:26 -0800 Received: from auto-nb1.xs4all.nl (host-4.coltex.demon.nl [212.238.252.68]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id h14AS1QR067283; Tue, 4 Feb 2003 11:28:01 +0100 (CET) Message-Id: <4.3.2.7.2.20030204112723.042b5668@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 04 Feb 2003 11:27:58 +0100 To: Brian Grossman From: Seth Mos Subject: Re: xfs oops Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030204091538.A29171@infradead.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2513 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: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 597 Lines: 20 At 09:15 4-2-2003 +0000, Christoph Hellwig wrote: >On Mon, Feb 03, 2003 at 11:20:14PM -0700, Brian Grossman wrote: > > > > This oops is with kernel 2.4.20 + preemptable patch + xfs + v4l2. > > The cpu is an athlon. > > Streamer records tv to disk from bttv. The recording is going > > to an xfs partition. > > There are also ext3 and reiserfs partitions on this system. > > The taint is a geforce4 video card. > >Please try to reproduce it without the preempt patch. And it that doesn't help try without the binary NV driver. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Tue Feb 4 11:35:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Feb 2003 11:35:06 -0800 (PST) Received: from exchange.ccur.com (mail.ccur.com [208.248.32.212]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h14JYw3v009339 for ; Tue, 4 Feb 2003 11:35:00 -0800 Received: by exchange.ccur.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Feb 2003 14:42:31 -0500 Message-ID: From: "Miro, Felix" To: "'linux-xfs@oss.sgi.com'" Subject: Need patch for 2.4.21 Date: Tue, 4 Feb 2003 14:42:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 2515 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: felix.miro@ccur.com Precedence: bulk X-list: linux-xfs Content-Length: 386 Lines: 9 I'm having difficulty applying the 2.4.19 patch against 2.4.21 source. Our product offering is going to be based on 2.4.21. We would like to include XFS in our linux offering. Can you supply an XFS patch based on 2.4.21? The problem I'm having is with files that have significant changes in 2.4.21 vs 2.4.19. The 2.4.19 patch doesn't relate at all in those cases. Regards, Felix Miro From owner-linux-xfs@oss.sgi.com Tue Feb 4 11:45:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Feb 2003 11:45:34 -0800 (PST) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h14JjU3v009868 for ; Tue, 4 Feb 2003 11:45:31 -0800 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id h14Jqq5t012300; Tue, 4 Feb 2003 20:52:53 +0100 (CET) Message-Id: <4.3.2.7.2.20030204204843.034c5678@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 04 Feb 2003 20:52:51 +0100 To: "Miro, Felix" , "'linux-xfs@oss.sgi.com'" From: Seth Mos Subject: Re: Need patch for 2.4.21 In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2516 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: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 900 Lines: 24 At 14:42 4-2-2003 -0500, Miro, Felix wrote: >I'm having difficulty applying the 2.4.19 patch against 2.4.21 source. Our >product offering is going to be based on 2.4.21. We would like to include >XFS in our linux offering. Can you supply an XFS patch based on 2.4.21? >The problem I'm having is with files that have significant changes in 2.4.21 >vs 2.4.19. The 2.4.19 patch doesn't relate at all in those cases. Fetch the current CVS tree. Recerse apply the kdb patch. Diff this tree against the vanilla 2.4.21 and you basically got about the same result. The thing is though. 2.4.21 is not out yet (according to kernel.org) and I don't remember seeing anything related to security holes either which would force a new release. It is not based on a XFS release like 1.1 or the 1.2pre snapshots and thus not as well tested. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Tue Feb 4 11:51:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Feb 2003 11:51:09 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h14Jp63v010320 for ; Tue, 4 Feb 2003 11:51:06 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h14K7Qkq002997 for ; Tue, 4 Feb 2003 14:07:26 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA65310; Tue, 4 Feb 2003 13:58:38 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA80002; Tue, 4 Feb 2003 13:58:38 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h14Jwcl01325; Tue, 4 Feb 2003 13:58:38 -0600 Subject: Re: Need patch for 2.4.21 From: Steve Lord To: Seth Mos Cc: "Miro, Felix" , "'linux-xfs@oss.sgi.com'" In-Reply-To: <4.3.2.7.2.20030204204843.034c5678@pop.xs4all.nl> References: <4.3.2.7.2.20030204204843.034c5678@pop.xs4all.nl> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1044388718.670.108.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 04 Feb 2003 13:58:38 -0600 X-archive-position: 2517 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1425 Lines: 36 On Tue, 2003-02-04 at 13:52, Seth Mos wrote: > At 14:42 4-2-2003 -0500, Miro, Felix wrote: > >I'm having difficulty applying the 2.4.19 patch against 2.4.21 source. Our > >product offering is going to be based on 2.4.21. We would like to include > >XFS in our linux offering. Can you supply an XFS patch based on 2.4.21? > >The problem I'm having is with files that have significant changes in 2.4.21 > >vs 2.4.19. The 2.4.19 patch doesn't relate at all in those cases. > > Fetch the current CVS tree. Recerse apply the kdb patch. > Diff this tree against the vanilla 2.4.21 and you basically got about the > same result. > > The thing is though. 2.4.21 is not out yet (according to kernel.org) and I > don't remember seeing anything related to security holes either which would > force a new release. > > It is not based on a XFS release like 1.1 or the 1.2pre snapshots and thus > not as well tested. cvs is the internal development tree, the 1.2pre code is actually a few months behind it now for the most part. Of course that few months may represent bugs being fixed, or bugs being introduced - it should be the former. There is also a patch here: ftp://oss.sgi.com/projects/xfs/download/patches/weekly-snapshot-patch/linux-2.4.20-xfs-2003-01-26.patch.bz2 Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Feb 4 13:40:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Feb 2003 13:41:00 -0800 (PST) Received: from hotmail.com (f46.sea2.hotmail.com [207.68.165.46]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h14Lep3v013742 for ; Tue, 4 Feb 2003 13:40:52 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 4 Feb 2003 13:48:25 -0800 Received: from 208.244.233.175 by sea2fd.sea2.hotmail.msn.com with HTTP; Tue, 04 Feb 2003 21:48:25 GMT X-Originating-IP: [208.244.233.175] From: "Rick Smith" To: linux-xfs@oss.sgi.com Subject: CVS checkout hanging Date: Tue, 04 Feb 2003 13:48:25 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 04 Feb 2003 21:48:25.0569 (UTC) FILETIME=[252DED10:01C2CC97] X-archive-position: 2518 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: rgsmith72@hotmail.com Precedence: bulk X-list: linux-xfs Content-Length: 888 Lines: 21 I am trying to checkout the latest source tree using the CVS instructions from oss.sgi.com, but the checkout seems to hang everytime at the same place. I have tried to perform the checkout on multiple platforms and from different locations, but I get the same results. I have waited several hours for the process to complete, but it never gets beyond the line below. Anyone else able to grab the full source tree out of CVS? cvs -z3 checkout linux-2.4-xfs hangs after the line: cvs server: Updating linux-2.4-xfs/linux/scripts/usb cvs -z3 checkout linux-2.5-xfs hangs after the line: cvs server: Updating linux-2.5-xfs/linux/usr/initramfs_data.scr Any help appreciated. Thanks. Rick Smith _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 From owner-linux-xfs@oss.sgi.com Tue Feb 4 13:49:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Feb 2003 13:49:06 -0800 (PST) Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h14Lmx3v014279 for ; Tue, 4 Feb 2003 13:49:01 -0800 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.6/8.11.6) with ESMTP id h14LubB20887; Tue, 4 Feb 2003 16:56:37 -0500 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Tue, 4 Feb 2003 16:56:37 -0500 (EST) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: Rick Smith cc: linux-xfs@oss.sgi.com Subject: Re: CVS checkout hanging In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2519 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jlb17@duke.edu Precedence: bulk X-list: linux-xfs Content-Length: 896 Lines: 23 On Tue, 4 Feb 2003 at 1:48pm, Rick Smith wrote > I am trying to checkout the latest source tree using the CVS > instructions from oss.sgi.com, but the checkout seems to hang everytime at > the same place. I have tried to perform the checkout on multiple platforms > and from different locations, but I get the same results. I have waited > several hours for the process to complete, but it never gets beyond the line > below. Anyone else able to grab the full source tree out of CVS? > > cvs -z3 checkout linux-2.4-xfs hangs after the line: > cvs server: Updating linux-2.4-xfs/linux/scripts/usb > > cvs -z3 checkout linux-2.5-xfs hangs after the line: > cvs server: Updating linux-2.5-xfs/linux/usr/initramfs_data.scr I believe (search the archives) the CVS access is currently off. Try CVSup. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Tue Feb 4 14:02:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Feb 2003 14:02:09 -0800 (PST) Received: from hotmail.com (f50.sea2.hotmail.com [207.68.165.50]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h14M263v014822 for ; Tue, 4 Feb 2003 14:02:07 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 4 Feb 2003 14:09:40 -0800 Received: from 208.244.233.175 by sea2fd.sea2.hotmail.msn.com with HTTP; Tue, 04 Feb 2003 22:09:40 GMT X-Originating-IP: [208.244.233.175] From: "Rick Smith" To: linux-xfs@oss.sgi.com Subject: U320 Large Array Performance Date: Tue, 04 Feb 2003 14:09:40 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 04 Feb 2003 22:09:40.0931 (UTC) FILETIME=[1D5AB930:01C2CC9A] X-archive-position: 2520 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: rgsmith72@hotmail.com Precedence: bulk X-list: linux-xfs Content-Length: 1471 Lines: 33 I am constructing a large, high performance U320 raid0 array with XFS using the 2.4.20-rc1-xfs kernel and linux software raid. I am pleased with the performance, but it seems that when I exceed 14 disks total in the single raid0 array, performance becomes erratic. With 14 disks and under, the extents are laid out nicely in incrementing order very close to each other (according to xfs_bmap) and I can get very large MB/s numbers using 4 U320 SCSI channels and 73GB disks. However, with 15+ disks, I am seeing large, erratic gaps in the extents, which is seriously affecting read/write performance. I don't exceed 5 drives per channel, and the problem seems to exist no matter what SCSI configuration that I use. I have tried various numbers of channels and disks per channel, but the problem remains when I exceed 14 disks. Currently the read performance for 15 disks is about half the read performance for 14 disks in the array. Other filesystems tested (reiserfs and ext2/3) do not seem to suffer from this problem, but they also don't produce the awesome speed that the XFS filesystem does. I plan on experimenting with the latest 2.4 and 2.5 versions of the XFS kernel as soon as I can get a good copy from CVS. Any help is appreciated. Thanks. Rick Smith _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail From owner-linux-xfs@oss.sgi.com Tue Feb 4 14:08:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Feb 2003 14:08:37 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h14M8W3v015305 for ; Tue, 4 Feb 2003 14:08:33 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h14MOrkq006687 for ; Tue, 4 Feb 2003 16:24:53 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA27850; Tue, 4 Feb 2003 16:16:06 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id QAA10058; Tue, 4 Feb 2003 16:16:06 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h14MG6N11742; Tue, 4 Feb 2003 16:16:06 -0600 Subject: Re: U320 Large Array Performance From: Steve Lord To: Rick Smith Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1044396965.5272.1.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 04 Feb 2003 16:16:05 -0600 X-archive-position: 2521 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1656 Lines: 32 On Tue, 2003-02-04 at 16:09, Rick Smith wrote: > I am constructing a large, high performance U320 raid0 array with XFS > using the 2.4.20-rc1-xfs kernel and linux software raid. I am pleased with > the performance, but it seems that when I exceed 14 disks total in the > single raid0 array, performance becomes erratic. With 14 disks and under, > the extents are laid out nicely in incrementing order very close to each > other (according to xfs_bmap) and I can get very large MB/s numbers using 4 > U320 SCSI channels and 73GB disks. However, with 15+ disks, I am seeing > large, erratic gaps in the extents, which is seriously affecting read/write > performance. I don't exceed 5 drives per channel, and the problem seems to > exist no matter what SCSI configuration that I use. I have tried various > numbers of channels and disks per channel, but the problem remains when I > exceed 14 disks. Currently the read performance for 15 disks is about half > the read performance for 14 disks in the array. > Other filesystems tested (reiserfs and ext2/3) do not seem to suffer > from this problem, but they also don't produce the awesome speed that the > XFS filesystem does. > I plan on experimenting with the latest 2.4 and 2.5 versions of the XFS > kernel as soon as I can get a good copy from CVS. > Any help is appreciated. Thanks. Sounds like you need to play with mkfs options on XFS. Can you send the output of xfs_info /mnt where /mnt is the mounted filesystem. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Feb 4 14:40:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Feb 2003 14:40:05 -0800 (PST) Received: from hotmail.com (f69.sea2.hotmail.com [207.68.165.69]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h14Mdx3v015948 for ; Tue, 4 Feb 2003 14:40:00 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 4 Feb 2003 14:47:34 -0800 Received: from 208.244.233.175 by sea2fd.sea2.hotmail.msn.com with HTTP; Tue, 04 Feb 2003 22:47:34 GMT X-Originating-IP: [208.244.233.175] From: "Rick Smith" To: lord@sgi.com Cc: linux-xfs@oss.sgi.com Subject: Re: U320 Large Array Performance Date: Tue, 04 Feb 2003 14:47:34 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 04 Feb 2003 22:47:34.0399 (UTC) FILETIME=[687268F0:01C2CC9F] X-archive-position: 2522 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: rgsmith72@hotmail.com Precedence: bulk X-list: linux-xfs Content-Length: 3309 Lines: 82 Steve, Here is the output from xfs_info, please excuse the formatting. I am using a chunk size of 4K in the raid. Larger sizes seem to degrade performance. Thanks for your help. With 14 disks in the array: meta-data=/test isize=256 agcount=240, agsize=1048576 blks data = bsize=4096 blocks=251392736, imaxpct=25 = sunit=1 swidth=14 blks, unwritten=1 naming =version 2 bsize=4096 log =external bsize=4096 blocks=32768 version=1 = sunit=0 blks realtime =none extsz=57344 blocks=0, rtextents=0 With 15 disks in the array meta-data=/test isize=256 agcount=257, agsize=1048576 blks data = bsize=4096 blocks=269349360, imaxpct=25 = sunit=1 swidth=15 blks, unwritten=1 naming =version 2 bsize=4096 log =external bsize=4096 blocks=32768 version=1 = sunit=0 blks realtime =none extsz=61440 blocks=0, rtextents=0 >From: Steve Lord >To: Rick Smith >CC: linux-xfs@oss.sgi.com >Subject: Re: U320 Large Array Performance >Date: 04 Feb 2003 16:16:05 -0600 > >On Tue, 2003-02-04 at 16:09, Rick Smith wrote: > > I am constructing a large, high performance U320 raid0 array with >XFS > > using the 2.4.20-rc1-xfs kernel and linux software raid. I am pleased >with > > the performance, but it seems that when I exceed 14 disks total in the > > single raid0 array, performance becomes erratic. With 14 disks and >under, > > the extents are laid out nicely in incrementing order very close to each > > other (according to xfs_bmap) and I can get very large MB/s numbers >using 4 > > U320 SCSI channels and 73GB disks. However, with 15+ disks, I am seeing > > large, erratic gaps in the extents, which is seriously affecting >read/write > > performance. I don't exceed 5 drives per channel, and the problem seems >to > > exist no matter what SCSI configuration that I use. I have tried various > > numbers of channels and disks per channel, but the problem remains when >I > > exceed 14 disks. Currently the read performance for 15 disks is about >half > > the read performance for 14 disks in the array. > > Other filesystems tested (reiserfs and ext2/3) do not seem to suffer > > from this problem, but they also don't produce the awesome speed that >the > > XFS filesystem does. > > I plan on experimenting with the latest 2.4 and 2.5 versions of the >XFS > > kernel as soon as I can get a good copy from CVS. > > Any help is appreciated. Thanks. > >Sounds like you need to play with mkfs options on XFS. Can you send >the output of xfs_info /mnt where /mnt is the mounted filesystem. > >Steve > > >-- > >Steve Lord voice: +1-651-683-3511 >Principal Engineer, Filesystem Software email: lord@sgi.com _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail From owner-linux-xfs@oss.sgi.com Tue Feb 4 15:37:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Feb 2003 15:37:54 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h14Nbj3v016792 for ; Tue, 4 Feb 2003 15:37:45 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h14LjTG8029622 for ; Tue, 4 Feb 2003 13:45:29 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA21197; Tue, 4 Feb 2003 17:45:18 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id RAA34943; Tue, 4 Feb 2003 17:45:18 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h14NjI611879; Tue, 4 Feb 2003 17:45:18 -0600 Subject: Re: U320 Large Array Performance From: Steve Lord To: Rick Smith Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1044402317.5272.34.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 04 Feb 2003 17:45:18 -0600 X-archive-position: 2523 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 4778 Lines: 114 On Tue, 2003-02-04 at 16:47, Rick Smith wrote: > Steve, > Here is the output from xfs_info, please excuse the formatting. I am using > a chunk size of 4K in the raid. Larger sizes seem to degrade performance. > Thanks for your help. I was going to have a chat with someone about this, but they are gone for the day, so stripe suggestions will have to wait a while. Do you have any way of measuring the I/O going on to each drive? There are ways of making a filesystem where the allocation headers for each allocation group land on the same device and it cripples us. Not sure which version of the mkfs code is in linux right now to be honest. If you can monitor it then you would see this happening. Messing with -d agsize=xxx can be used to fix this up. Try adding -b size=4096 -d agsize=1048559b to the 15 disk case, this should make the allocation groups a multiple of your stripe width - 1. This will cause the allocation group headers to round robin through the drives. This is a bit of a shot in the dark. Note the math here is to make agsize+1 a multiple of the number of drives you have which is a bit less than 4Gbytes. This is a little bit of a shot in the dark, but it may help. Also, you have -d unwritten=1, this will not be doing you any good, and can in fact cause problems with some forms of mmaped I/O. More tomorrow. Steve > > With 14 disks in the array: > meta-data=/test isize=256 agcount=240, agsize=1048576 > blks > data = bsize=4096 blocks=251392736, > imaxpct=25 > = sunit=1 swidth=14 blks, > unwritten=1 > naming =version 2 bsize=4096 > log =external bsize=4096 blocks=32768 version=1 > = sunit=0 blks > realtime =none extsz=57344 blocks=0, rtextents=0 > > With 15 disks in the array > meta-data=/test isize=256 agcount=257, agsize=1048576 > blks > data = bsize=4096 blocks=269349360, > imaxpct=25 > = sunit=1 swidth=15 blks, > unwritten=1 > naming =version 2 bsize=4096 > log =external bsize=4096 blocks=32768 version=1 > = sunit=0 blks > realtime =none extsz=61440 blocks=0, rtextents=0 > > >From: Steve Lord > >To: Rick Smith > >CC: linux-xfs@oss.sgi.com > >Subject: Re: U320 Large Array Performance > >Date: 04 Feb 2003 16:16:05 -0600 > > > >On Tue, 2003-02-04 at 16:09, Rick Smith wrote: > > > I am constructing a large, high performance U320 raid0 array with > >XFS > > > using the 2.4.20-rc1-xfs kernel and linux software raid. I am pleased > >with > > > the performance, but it seems that when I exceed 14 disks total in the > > > single raid0 array, performance becomes erratic. With 14 disks and > >under, > > > the extents are laid out nicely in incrementing order very close to each > > > other (according to xfs_bmap) and I can get very large MB/s numbers > >using 4 > > > U320 SCSI channels and 73GB disks. However, with 15+ disks, I am seeing > > > large, erratic gaps in the extents, which is seriously affecting > >read/write > > > performance. I don't exceed 5 drives per channel, and the problem seems > >to > > > exist no matter what SCSI configuration that I use. I have tried various > > > numbers of channels and disks per channel, but the problem remains when > >I > > > exceed 14 disks. Currently the read performance for 15 disks is about > >half > > > the read performance for 14 disks in the array. > > > Other filesystems tested (reiserfs and ext2/3) do not seem to suffer > > > from this problem, but they also don't produce the awesome speed that > >the > > > XFS filesystem does. > > > I plan on experimenting with the latest 2.4 and 2.5 versions of the > >XFS > > > kernel as soon as I can get a good copy from CVS. > > > Any help is appreciated. Thanks. > > > >Sounds like you need to play with mkfs options on XFS. Can you send > >the output of xfs_info /mnt where /mnt is the mounted filesystem. > > > >Steve > > > > > >-- > > > >Steve Lord voice: +1-651-683-3511 > >Principal Engineer, Filesystem Software email: lord@sgi.com > > > _________________________________________________________________ > Help STOP SPAM with the new MSN 8 and get 2 months FREE* > http://join.msn.com/?page=features/junkmail -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Feb 4 22:09:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Feb 2003 22:09:13 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h156953v024212 for ; Tue, 4 Feb 2003 22:09:06 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h156PQkq014378 for ; Wed, 5 Feb 2003 00:25:27 -0600 Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id h156FbS31185; Wed, 5 Feb 2003 17:15:37 +1100 Date: Wed, 5 Feb 2003 17:15:37 +1100 From: Keith Owens Message-Id: <200302050615.h156FbS31185@sherman.melbourne.sgi.com> Subject: TAKE - Upgrade common code to kdb v3.0 X-archive-position: 2525 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 783 Lines: 28 Upgrade common code to kdb v3.0 Date: Tue Feb 4 22:14:05 PST 2003 Workarea: sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:138640a linux/kernel/module.c - 1.26 linux/include/linux/module.h - 1.34 linux/kdb/kdb_bt.c - 1.14 linux/kdb/kdb_bp.c - 1.15 linux/kdb/Makefile - 1.16 linux/include/linux/kdbprivate.h - 1.22 linux/include/linux/kdb.h - 1.28 linux/kdb/modules/Makefile - 1.16 linux/kdb/kdbsupport.c - 1.16 linux/kdb/kdbmain.c - 1.34 linux/kdb/kdb_io.c - 1.17 linux/Documentation/kdb/kdb.mm - 1.17 linux/Documentation/kdb/kdb_bt.man - 1.9 linux/kdb/kdb_id.c - 1.16 linux/kernel/kallsyms.c - 1.13 linux/include/linux/kallsyms.h - 1.10 linux/kdb/ChangeLog - 1.27 From owner-linux-xfs@oss.sgi.com Tue Feb 4 22:15:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Feb 2003 22:16:01 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h156Fr3v024656 for ; Tue, 4 Feb 2003 22:15:54 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h155UQKp002023 for ; Tue, 4 Feb 2003 21:30:27 -0800 Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id h156MRl31452; Wed, 5 Feb 2003 17:22:27 +1100 Date: Wed, 5 Feb 2003 17:22:27 +1100 From: Keith Owens Message-Id: <200302050622.h156MRl31452@sherman.melbourne.sgi.com> Subject: TAKE - Upgrade i386 code to kdb v3.0 X-archive-position: 2526 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 661 Lines: 22 Upgrade i386 code to kdb v3.0 Date: Tue Feb 4 22:21:36 PST 2003 Workarea: sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:138643a linux/arch/i386/vmlinux.lds - 1.15 linux/arch/i386/kernel/traps.c - 1.49 linux/include/asm-i386/kdb.h - 1.15 linux/include/asm-i386/kdbprivate.h - 1.18 linux/arch/i386/kdb/kdba_id.c - 1.14 linux/arch/i386/kdb/kdbasupport.c - 1.24 linux/arch/i386/kdb/kdba_io.c - 1.19 linux/arch/i386/kdb/Makefile - 1.12 linux/arch/i386/kdb/kdba_bt.c - 1.18 linux/arch/i386/kdb/kdba_bp.c - 1.17 linux/arch/i386/kdb/ChangeLog - 1.16 From owner-linux-xfs@oss.sgi.com Tue Feb 4 22:19:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Feb 2003 22:19:50 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h156Jd3v025118 for ; Tue, 4 Feb 2003 22:19:39 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h154RNG8025499 for ; Tue, 4 Feb 2003 20:27:24 -0800 Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id h156QDm31546; Wed, 5 Feb 2003 17:26:13 +1100 Date: Wed, 5 Feb 2003 17:26:13 +1100 From: Keith Owens Message-Id: <200302050626.h156QDm31546@sherman.melbourne.sgi.com> Subject: TAKE - Upgrade modules to kdb v3.0 X-archive-position: 2527 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 315 Lines: 13 Upgrade modules to kdb v3.0 Date: Tue Feb 4 22:24:50 PST 2003 Workarea: sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:138644a linux/kdb/modules/kdbm_vm.c - 1.21 linux/kdb/modules/kdbm_pg.c - 1.61 From owner-linux-xfs@oss.sgi.com Tue Feb 4 23:43:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Feb 2003 23:44:05 -0800 (PST) Received: from mail.blazebox.homeip.net (pool-141-155-24-162.ny5030.east.verizon.net [141.155.24.162]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h157hu3v029017 for ; Tue, 4 Feb 2003 23:43:57 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.blazebox.homeip.net (Postfix) with ESMTP id E22E6A287; Wed, 5 Feb 2003 02:52:33 -0500 (EST) Received: from mail.blazebox.homeip.net (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.1.10) id 34835-6B72E990; Wed, 05 Feb 2003 02:52:33 -0500 Received: from blaze (blaze [192.168.0.43]) by mail.blazebox.homeip.net (Postfix) with ESMTP id 9667EA1C2; Wed, 5 Feb 2003 02:52:32 -0500 (EST) Subject: Re: Need patch for 2.4.21 From: Paul Blazejowski To: "Miro, Felix" Cc: linux-xfs In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-GahSoEfaBacYe2olmfwo" Organization: Message-Id: <1044431496.1261.11.camel@blaze> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 05 Feb 2003 02:51:36 -0500 X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.10; AVE: 6.18.0.1; VDF: 6.18.0.5; host: blazebox.homeip.net) X-archive-position: 2528 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: paulb@blazebox.homeip.net Precedence: bulk X-list: linux-xfs Content-Length: 1238 Lines: 43 --=-GahSoEfaBacYe2olmfwo Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2003-02-04 at 14:42, Miro, Felix wrote: > I'm having difficulty applying the 2.4.19 patch against 2.4.21 source. Our > product offering is going to be based on 2.4.21. We would like to include > XFS in our linux offering. Can you supply an XFS patch based on 2.4.21? > The problem I'm having is with files that have significant changes in 2.4= .21 > vs 2.4.19. The 2.4.19 patch doesn't relate at all in those cases. >=20 > Regards, > Felix Miro >=20 You mean the latest preXX? because there is no 2.4.21 just yet... I have made a diff against the 2.4.21-pre4 source from kernel.org. It's from today's CVS but without the kdb v3.0 commits Keith Ownes just made...to xfs/linux-2.4 cvs tree. The patch is on http://www.blazebox.homeip.net/~paul/linux/ Regards, Paul --=-GahSoEfaBacYe2olmfwo Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+QMKHIymMQsXoRDARAny8AJ9uNVX9RRpGi4RcQONEb6yXB7lIJACfWDcU aTRdlGy5CTpbNRaE2uDvY84= =FiKs -----END PGP SIGNATURE----- --=-GahSoEfaBacYe2olmfwo-- From owner-linux-xfs@oss.sgi.com Tue Feb 4 23:48:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Feb 2003 23:48:49 -0800 (PST) Received: from mail.blazebox.homeip.net (pool-141-155-24-162.ny5030.east.verizon.net [141.155.24.162]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h157mk3v029484 for ; Tue, 4 Feb 2003 23:48:46 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.blazebox.homeip.net (Postfix) with ESMTP id DA653A288; Wed, 5 Feb 2003 02:57:23 -0500 (EST) Received: from mail.blazebox.homeip.net (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.1.10) id 34894-3C25491B; Wed, 05 Feb 2003 02:57:23 -0500 Received: from blaze (blaze [192.168.0.43]) by mail.blazebox.homeip.net (Postfix) with ESMTP id 915CBA1C2; Wed, 5 Feb 2003 02:57:23 -0500 (EST) Subject: Re: Need patch for 2.4.21 From: Paul Blazejowski To: "Miro, Felix" Cc: linux-xfs In-Reply-To: <1044431496.1261.11.camel@blaze> References: <1044431496.1261.11.camel@blaze> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-1sk978J1qk4t6fuK8tBn" Organization: Message-Id: <1044431787.1263.18.camel@blaze> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 05 Feb 2003 02:56:27 -0500 X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.10; AVE: 6.18.0.1; VDF: 6.18.0.5; host: blazebox.homeip.net) X-archive-position: 2529 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: paulb@blazebox.homeip.net Precedence: bulk X-list: linux-xfs Content-Length: 1481 Lines: 54 --=-1sk978J1qk4t6fuK8tBn Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2003-02-05 at 02:51, Paul Blazejowski wrote: > On Tue, 2003-02-04 at 14:42, Miro, Felix wrote: >=20 > > I'm having difficulty applying the 2.4.19 patch against 2.4.21 source. = Our > > product offering is going to be based on 2.4.21. We would like to inclu= de > > XFS in our linux offering. Can you supply an XFS patch based on 2.4.21? > > The problem I'm having is with files that have significant changes in 2= .4.21 > > vs 2.4.19. The 2.4.19 patch doesn't relate at all in those cases. > >=20 > > Regards, > > Felix Miro > >=20 >=20 > You mean the latest preXX? because there is no 2.4.21 just yet... >=20 > I have made a diff against the 2.4.21-pre4 source from kernel.org. > It's from today's CVS but without the kdb v3.0 commits Keith Ownes just > made...to xfs/linux-2.4 cvs tree. >=20 > The patch is on http://www.blazebox.homeip.net/~paul/linux/ >=20 > Regards, >=20 > Paul Sorry, the correct url should be http://www.blazebox.homeip.net:81/~paul/linux/ (damn isp is blocking port 80) Regards, Paul --=-1sk978J1qk4t6fuK8tBn Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+QMOrIymMQsXoRDARAlx2AJ9LWs0HspTF1nUACCyzUM/MEJqr7ACeKrqh QU03DyhY7Wj+kFBiitglMx4= =Ynbb -----END PGP SIGNATURE----- --=-1sk978J1qk4t6fuK8tBn-- From owner-linux-xfs@oss.sgi.com Wed Feb 5 01:30:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Feb 2003 01:30:43 -0800 (PST) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h159UH3v031547 for ; Wed, 5 Feb 2003 01:30:19 -0800 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id h159bsJJ079737; Wed, 5 Feb 2003 10:37:54 +0100 (CET) Message-Id: <4.3.2.7.2.20030205103624.03506b40@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 05 Feb 2003 10:37:52 +0100 To: Joshua Baker-LePain , Rick Smith From: Seth Mos Subject: Re: CVS checkout hanging Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2530 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: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 1122 Lines: 31 At 16:56 4-2-2003 -0500, Joshua Baker-LePain wrote: >On Tue, 4 Feb 2003 at 1:48pm, Rick Smith wrote > > > I am trying to checkout the latest source tree using the CVS > > instructions from oss.sgi.com, but the checkout seems to hang everytime at > > the same place. I have tried to perform the checkout on multiple platforms > > and from different locations, but I get the same results. I have waited > > several hours for the process to complete, but it never gets beyond the > line > > below. Anyone else able to grab the full source tree out of CVS? > > > > cvs -z3 checkout linux-2.4-xfs hangs after the line: > > cvs server: Updating linux-2.4-xfs/linux/scripts/usb > > > > cvs -z3 checkout linux-2.5-xfs hangs after the line: > > cvs server: Updating linux-2.5-xfs/linux/usr/initramfs_data.scr > >I believe (search the archives) the CVS access is currently off. Try >CVSup. No, CVS is working fine but you need the new cvs toolkt which fixed the (remote) root hole. Older versions hang. Your tree did check out alright by the way. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Feb 5 03:52:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Feb 2003 03:52:53 -0800 (PST) Received: from mail.kailee.net (dsl-213-023-028-078.arcor-ip.net [213.23.28.78]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h15Bqh3v003659 for ; Wed, 5 Feb 2003 03:52:44 -0800 Received: from Bilbo (unknown [192.168.0.12]) by mail.kailee.net (Postfix) with ESMTP id E48473023AF3 for ; Wed, 5 Feb 2003 07:09:52 -0500 (EST) From: "Kai Leibrandt" To: Subject: Re: Another mkfs.xfs RAID Question Date: Wed, 5 Feb 2003 13:00:03 +0100 Message-ID: <000201c2cd0e$20b90db0$0c00a8c0@Bilbo> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2605 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-archive-position: 2531 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: kai@kailee.net Precedence: bulk X-list: linux-xfs Content-Length: 5310 Lines: 130 Ok, I had some time over the weekend to put some spare disks in the machine and see what the effect of different mkfs options would be with bonnie. This is all on a 700MHz Athlon, 512Mb RAM, a Mylex DAC960PD with 32Mb Cache, and the 3 18Gb IBM DPSS are on a separate channel each. First, hardware set to 64k stripe, 8k segment, write-through caching; mkfs.xfs with sunit=2,swidth=16: -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU sunit=2, 4096 4419 7.9 4420 2.3 2808 2.3 8292 19.9 9915 5.7 177.8 1.5 mkfs.xfs with sunit=16,swidth=128: -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU sunit=16 4096 4431 7.6 4439 2.2 2837 2.2 8593 20.2 10280 5.8 190.2 1.4 So there's really no difference to speak of in real terms... Next, set the hardware to 64k stripe, 64k segment, write-through caching; mkfs.xfs with sunit=16,swidth=128: -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU sunit=16 4096 5014 8.7 5013 2.5 3408 2.6 11876 28.3 14653 8.2 190.6 1.3 And now that last setup (64k stripe,64k segment, sunit=16,swidth=128) with write-back caching enabled: -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU u16w48s6 4096 6153 10.8 6165 3.1 3968 3.0 12149 29.0 14533 8.6 165.5 1.2 So the 64k segment seems to really help (in Bonnie at least). To a lesser degree switching on write-back also helps, so in case there's a UPS sitting in the same rack (or a battery backup on the DAC960) it's probably a good idea to use it. However, I was surprised to see how relatively little the performance impact of different mkfs options were assuming the same hardware parameters. Of course, this is nowhere near a scientific study. It's also interesting to see how badly the DAC does in comparison to an ata md raid 5, even though there's only one disk per scsi channel in active use. Oh and _do_ remember this is mostly focussing on sequential i/o! Hope this is interesting to anyone, Kai. > -----Original Message----- > From: Murthy Kambhampaty [mailto:murthy.kambhampaty@goeci.com] > Sent: 03 February 2003 21:45 > To: Murthy Kambhampaty; 'Kai Leibrandt'; 'linux-xfs@oss.sgi.com' > Subject: RE: Another mkfs.xfs RAID Question > > > Try sunit=8k, swidth=64k, for the Mylex raid controller with > default settings > (http://oss.sgi.com/projects/xfs/mail_archive/200205/msg00152.html) > > Note: With recent firmware, both segment size (8k, 64k) and > stripe size (up to 1024k in several steps) are user > selectable. However, we had problems with a 64k SEGMENT size, > so we now just use 8k segment size and a stripe size of 64k. > Also, for the postgresql data volume, we use a 64m external > v2 log on md1 on a separate controller, and mount with > logbufs=8,logbsize=256k (the server -- Supermicro Super8050 > -- has 2+1 hot pluggable power supplies, runs on a ups with > apcusd to shut the machine down on power failure, and is > backed up every night; if that motherboard fails we will > likely be doing bare-metal recovery given that it is a busy > server and the aggressive log settings). It was difficult to > test the effects of tweaking the segment size and stripe size > (if you are able to set up Mylex GAM server, you might find > it easy enough); the log settings gave the lowest `time dd > if=/dev/zero of=/mnt/testdisk/testfile bs=4096 count=1310720` > in repeated testing with unmount/mount between reps; the > mount options are at their maximums, increasing the logdev's > size to 128m (which is the max, IIRC) gave a small decline > rather than an improvement. (I'll admit the testing wasn't > too formal, but we didn't think the differences would be so > dramatic as to formalize the "protocol" and record the results.) > > PS: sorry if you see multiple messages; I seem to have been > having problems posting > > > -----Original Message----- > From: Kai Leibrandt [mailto:k_leibrandt@hotmail.com] > Sent: Saturday, February 01, 2003 07:53 > To: linux-xfs@oss.sgi.com > Subject: Another mkfs.xfs RAID Question > > > Hi all, > > Dragos' question about the su,sw options led me to have > another look at my Mylex RAID setup, and I now am confused > too... My RAID controller tells me that the primary RAID > volume (a 3-disk RAID > 5) has a Stripe Size of 64k and a Segment Size of 8k. So for > this setup should the sunit be set to 64k or to 8k (the > segment size)??? The manual fo the DAC says that the segment > size is the preferred io size for caching, but xfs has a > preferred io size equal to the stripe size - which to choose? > > Many thanks, > > Kai. > From owner-linux-xfs@oss.sgi.com Wed Feb 5 04:43:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Feb 2003 04:43:46 -0800 (PST) Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h15Cha3v004773 for ; Wed, 5 Feb 2003 04:43:38 -0800 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id h15CpGkW078140; Wed, 5 Feb 2003 13:51:16 +0100 (CET) Message-Id: <4.3.2.7.2.20030205133321.032b2840@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 05 Feb 2003 13:51:13 +0100 To: "Kai Leibrandt" , From: Seth Mos Subject: Re: Another mkfs.xfs RAID Question In-Reply-To: <000201c2cd0e$20b90db0$0c00a8c0@Bilbo> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2532 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: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 2186 Lines: 61 At 13:00 5-2-2003 +0100, Kai Leibrandt wrote: >Of course, this is nowhere near a scientific study. It's also >interesting to see how badly the DAC does in comparison to an ata md >raid 5, even though there's only one disk per scsi channel in active >use. Oh and _do_ remember this is mostly focussing on sequential i/o! >Hope this is interesting to anyone, 3 disk software raid 5 over 2 promise ultra ata 100 controllers. 1 Disk per channel. kernel 2.4.18-19-1.2pre5 , XFS with version 2 logs. PIII 450 with 256MB ram, 1 Seagate Barracuda IV 80GB, 2 IBM Deathstar 60GXP 80GB. No extra mount options given. I can probably get better scores using sunit and swidth options. [root@lsautom raid]# xfs_info /raid meta-data=/raid isize=256 agcount=37, agsize=1048568 blks data = bsize=4096 blocks=38399936, imaxpct=25 = sunit=8 swidth=16 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768 version=2 = sunit=8 blks realtime =none extsz=65536 blocks=0, rtextents=0 [seth@lsautom seth]$ cat /etc/raidtab raiddev /dev/md0 raid-level 5 nr-raid-disks 3 nr-spare-disks 0 persistent-superblock 1 parity-algorithm left-symmetric chunk-size 32 device /dev/hdg1 raid-disk 0 device /dev/hdk1 raid-disk 1 device /dev/hdi2 raid-disk 2 -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 512 5466 89.9 29453 30.2 14302 23.9 5681 94.7 89181 89.1 216.4 5.0 1024 5479 90.0 25155 27.5 16346 27.4 5834 97.7 83500 92.5 192.6 4.2 This is by no means a extremely fast array, but it should give you a pointer what to expect from yours. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Feb 5 06:26:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Feb 2003 06:26:17 -0800 (PST) Received: from exchange.ccur.com (mail.ccur.com [208.248.32.212]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h15EQA3v025844 for ; Wed, 5 Feb 2003 06:26:11 -0800 Received: by exchange.ccur.com with Internet Mail Service (5.5.2653.19) id <1J848DWJ>; Wed, 5 Feb 2003 09:33:45 -0500 Message-ID: From: "Miro, Felix" To: "'Paul Blazejowski'" Cc: linux-xfs Subject: RE: Need patch for 2.4.21 Date: Wed, 5 Feb 2003 09:33:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-archive-position: 2533 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: felix.miro@ccur.com Precedence: bulk X-list: linux-xfs Content-Length: 1288 Lines: 49 Thanks. What is the patch marked preempt about? Should I be using that one? Regards, Felix -----Original Message----- From: Paul Blazejowski [mailto:paulb@blazebox.homeip.net] Sent: Wednesday, February 05, 2003 2:56 AM To: Miro, Felix Cc: linux-xfs Subject: Re: Need patch for 2.4.21 On Wed, 2003-02-05 at 02:51, Paul Blazejowski wrote: > On Tue, 2003-02-04 at 14:42, Miro, Felix wrote: > > > I'm having difficulty applying the 2.4.19 patch against 2.4.21 source. Our > > product offering is going to be based on 2.4.21. We would like to include > > XFS in our linux offering. Can you supply an XFS patch based on 2.4.21? > > The problem I'm having is with files that have significant changes in 2.4.21 > > vs 2.4.19. The 2.4.19 patch doesn't relate at all in those cases. > > > > Regards, > > Felix Miro > > > > You mean the latest preXX? because there is no 2.4.21 just yet... > > I have made a diff against the 2.4.21-pre4 source from kernel.org. > It's from today's CVS but without the kdb v3.0 commits Keith Ownes just > made...to xfs/linux-2.4 cvs tree. > > The patch is on http://www.blazebox.homeip.net/~paul/linux/ > > Regards, > > Paul Sorry, the correct url should be http://www.blazebox.homeip.net:81/~paul/linux/ (damn isp is blocking port 80) Regards, Paul From owner-linux-xfs@oss.sgi.com Wed Feb 5 06:44:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Feb 2003 06:44:20 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h15EiG3v026401 for ; Wed, 5 Feb 2003 06:44:16 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h15EiGRf026400 for linux-xfs@oss.sgi.com; Wed, 5 Feb 2003 06:44:16 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h15EiF3x026386 for ; Wed, 5 Feb 2003 06:44:15 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h15EhX0r026370; Wed, 5 Feb 2003 06:43:33 -0800 Date: Wed, 5 Feb 2003 06:43:33 -0800 Message-Id: <200302051443.h15EhX0r026370@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 214] New: filesystem lockup X-Bugzilla-Reason: AssignedTo X-archive-position: 2534 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 802 Lines: 31 http://oss.sgi.com/bugzilla/show_bug.cgi?id=214 Summary: filesystem lockup Product: Linux XFS Version: unspecified Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: gale@dstl.gov.uk What kernel are you using: 2.4 CVS Jan 16 2003 Description of Problem: Filesystem lockup. This is on a News server, which gets a continuous disk hammering. I've had this happen occasionally from lots of different 2.4 CVS kernels over the past 18 months. KDB backtrace on it's way.... ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Feb 5 06:44:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Feb 2003 06:45:03 -0800 (PST) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h15Eis3v026650 for ; Wed, 5 Feb 2003 06:44:55 -0800 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id h15EqWTu011573; Wed, 5 Feb 2003 15:52:32 +0100 (CET) Message-Id: <4.3.2.7.2.20030205155127.03006e30@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 05 Feb 2003 15:52:31 +0100 To: "Miro, Felix" , "'Paul Blazejowski'" From: Seth Mos Subject: RE: Need patch for 2.4.21 Cc: linux-xfs In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2535 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: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 309 Lines: 14 At 09:33 5-2-2003 -0500, Miro, Felix wrote: >Thanks. What is the patch marked preempt about? Should I be using that one? AFAIK preempt still don't always like XFS and for production environments with XFS I suggest you don't use it. YMMV Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Feb 5 06:50:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Feb 2003 06:50:25 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h15EoN3v027319 for ; Wed, 5 Feb 2003 06:50:23 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h15EoNxH027318 for linux-xfs@oss.sgi.com; Wed, 5 Feb 2003 06:50:23 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h15EoM3x027304 for ; Wed, 5 Feb 2003 06:50:22 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h15EiZoZ026556; Wed, 5 Feb 2003 06:44:35 -0800 Date: Wed, 5 Feb 2003 06:44:35 -0800 Message-Id: <200302051444.h15EiZoZ026556@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 214] filesystem lockup X-Bugzilla-Reason: AssignedTo X-archive-position: 2536 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 411 Lines: 18 http://oss.sgi.com/bugzilla/show_bug.cgi?id=214 ------- Additional Comments From gale@dstl.gov.uk 2003-02-05 06:44 ------- Created an attachment (id=61) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=61&action=view) KDB backtrace from hung system KDB backtrace from hung system ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Feb 5 07:00:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Feb 2003 07:00:59 -0800 (PST) Received: from exchange.ccur.com (mail.ccur.com [208.248.32.212]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h15F0o3v027959 for ; Wed, 5 Feb 2003 07:00:51 -0800 Received: by exchange.ccur.com with Internet Mail Service (5.5.2653.19) id <1J8481B9>; Wed, 5 Feb 2003 10:08:26 -0500 Message-ID: From: "Miro, Felix" To: "'Seth Mos'" , "'Paul Blazejowski'" Cc: linux-xfs Subject: RE: Need patch for 2.4.21 Date: Wed, 5 Feb 2003 10:08:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-archive-position: 2537 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: felix.miro@ccur.com Precedence: bulk X-list: linux-xfs Content-Length: 550 Lines: 27 What is the .sig patch? Regards, Felix -----Original Message----- From: Seth Mos [mailto:knuffie@xs4all.nl] Sent: Wednesday, February 05, 2003 9:53 AM To: Miro, Felix; 'Paul Blazejowski' Cc: linux-xfs Subject: RE: Need patch for 2.4.21 At 09:33 5-2-2003 -0500, Miro, Felix wrote: >Thanks. What is the patch marked preempt about? Should I be using that one? AFAIK preempt still don't always like XFS and for production environments with XFS I suggest you don't use it. YMMV Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Feb 5 07:42:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Feb 2003 07:42:18 -0800 (PST) Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h15FgB3v029040 for ; Wed, 5 Feb 2003 07:42:12 -0800 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id h15FnmHO018163; Wed, 5 Feb 2003 16:49:48 +0100 (CET) Message-Id: <4.3.2.7.2.20030205164842.030164b0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 05 Feb 2003 16:49:47 +0100 To: "Miro, Felix" , "'Paul Blazejowski'" From: Seth Mos Subject: RE: Need patch for 2.4.21 Cc: linux-xfs In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2538 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: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 281 Lines: 13 At 10:08 5-2-2003 -0500, Miro, Felix wrote: >What is the .sig patch? the signature so you can check if the file is not tampered with or different from the server (corruption). I presume it is a md5sum, I'm not sure. -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Feb 5 09:54:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Feb 2003 09:54:41 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h15HsV3v030805 for ; Wed, 5 Feb 2003 09:54:32 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h15IAwkq027450 for ; Wed, 5 Feb 2003 12:10:58 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA08504; Wed, 5 Feb 2003 12:02:08 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id MAA03931; Wed, 5 Feb 2003 12:02:08 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h15I28x24372; Wed, 5 Feb 2003 12:02:08 -0600 Subject: Re: U320 Large Array Performance From: Steve Lord To: Rick Smith Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1044468127.18872.16.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 05 Feb 2003 12:02:08 -0600 X-archive-position: 2539 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 524 Lines: 19 On Tue, 2003-02-04 at 16:47, Rick Smith wrote: > Steve, > Here is the output from xfs_info, please excuse the formatting. I am using > a chunk size of 4K in the raid. Larger sizes seem to degrade performance. > Thanks for your help. > Can you do one more thing for me, with these configurations send me the xfs_bmap -v output for a file on each filesystem. Thanks, Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Feb 5 10:46:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Feb 2003 10:46:38 -0800 (PST) Received: from mail.blazebox.homeip.net (pool-141-155-24-162.ny5030.east.verizon.net [141.155.24.162]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h15IkW3v032247 for ; Wed, 5 Feb 2003 10:46:33 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.blazebox.homeip.net (Postfix) with ESMTP id D658FA1C7; Wed, 5 Feb 2003 13:55:12 -0500 (EST) Received: from mail.blazebox.homeip.net (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.1.10) id 37920-68A60A39; Wed, 05 Feb 2003 13:55:12 -0500 Received: from blaze (blaze [192.168.0.43]) by mail.blazebox.homeip.net (Postfix) with ESMTP id 55DDCA101; Wed, 5 Feb 2003 13:55:12 -0500 (EST) Subject: RE: Need patch for 2.4.21 From: Paul Blazejowski To: "Miro, Felix" Cc: linux-xfs In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-DNVpUdxQgk/lU59P5dJJ" Organization: Message-Id: <1044471252.653.5.camel@blaze> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 05 Feb 2003 13:54:12 -0500 X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.10; AVE: 6.18.0.1; VDF: 6.18.0.5; host: blazebox.homeip.net) X-archive-position: 2540 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: paulb@blazebox.homeip.net Precedence: bulk X-list: linux-xfs Content-Length: 2036 Lines: 78 --=-DNVpUdxQgk/lU59P5dJJ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2003-02-05 at 09:33, Miro, Felix wrote: > Thanks. What is the patch marked preempt about? Should I be using that on= e? >=20 > Regards, > Felix=20 >=20 > -----Original Message----- > From: Paul Blazejowski [mailto:paulb@blazebox.homeip.net] > Sent: Wednesday, February 05, 2003 2:56 AM > To: Miro, Felix > Cc: linux-xfs > Subject: Re: Need patch for 2.4.21 >=20 >=20 > On Wed, 2003-02-05 at 02:51, Paul Blazejowski wrote: > > On Tue, 2003-02-04 at 14:42, Miro, Felix wrote: > >=20 > > > I'm having difficulty applying the 2.4.19 patch against 2.4.21 source. > Our > > > product offering is going to be based on 2.4.21. We would like to > include > > > XFS in our linux offering. Can you supply an XFS patch based on 2.4.2= 1? > > > The problem I'm having is with files that have significant changes in > 2.4.21 > > > vs 2.4.19. The 2.4.19 patch doesn't relate at all in those cases. > > >=20 > > > Regards, > > > Felix Miro > > >=20 > >=20 > > You mean the latest preXX? because there is no 2.4.21 just yet... > >=20 > > I have made a diff against the 2.4.21-pre4 source from kernel.org. > > It's from today's CVS but without the kdb v3.0 commits Keith Ownes just > > made...to xfs/linux-2.4 cvs tree. > >=20 > > The patch is on http://www.blazebox.homeip.net/~paul/linux/ > >=20 > > Regards, > >=20 > > Paul >=20 > Sorry, the correct url should be > http://www.blazebox.homeip.net:81/~paul/linux/ > (damn isp is blocking port 80) >=20 > Regards, >=20 > Paul >=20 For preempt info try here=20 http://www.kernel.org/pub/linux/kernel/people/rml/README Regards, Paul --=-DNVpUdxQgk/lU59P5dJJ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+QV3UIymMQsXoRDARAoxjAJ9s0TcDs1ZFFl25gx4OptNd02StaACffll/ 4xcsTKhtQCPVwHQkjJpFbt8= =l6pw -----END PGP SIGNATURE----- --=-DNVpUdxQgk/lU59P5dJJ-- From owner-linux-xfs@oss.sgi.com Wed Feb 5 10:49:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Feb 2003 10:49:35 -0800 (PST) Received: from mail.blazebox.homeip.net (pool-141-155-24-162.ny5030.east.verizon.net [141.155.24.162]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h15InV3v032697 for ; Wed, 5 Feb 2003 10:49:32 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.blazebox.homeip.net (Postfix) with ESMTP id 7EE60A1D1; Wed, 5 Feb 2003 13:58:14 -0500 (EST) Received: from mail.blazebox.homeip.net (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.1.10) id 37945-503D1797; Wed, 05 Feb 2003 13:58:14 -0500 Received: from blaze (blaze [192.168.0.43]) by mail.blazebox.homeip.net (Postfix) with ESMTP id 1C86CA101; Wed, 5 Feb 2003 13:58:14 -0500 (EST) Subject: RE: Need patch for 2.4.21 From: Paul Blazejowski To: Seth Mos Cc: "Miro, Felix" , linux-xfs In-Reply-To: <4.3.2.7.2.20030205164842.030164b0@pop.xs4all.nl> References: <4.3.2.7.2.20030205164842.030164b0@pop.xs4all.nl> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-WbWwql+ZTDvJiS5dutYo" Organization: Message-Id: <1044471434.653.9.camel@blaze> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 05 Feb 2003 13:57:14 -0500 X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.10; AVE: 6.18.0.1; VDF: 6.18.0.5; host: blazebox.homeip.net) X-archive-position: 2541 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: paulb@blazebox.homeip.net Precedence: bulk X-list: linux-xfs Content-Length: 1011 Lines: 42 --=-WbWwql+ZTDvJiS5dutYo Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2003-02-05 at 10:49, Seth Mos wrote: > At 10:08 5-2-2003 -0500, Miro, Felix wrote: > >What is the .sig patch? >=20 > the signature so you can check if the file is not tampered with or=20 > different from the server (corruption). >=20 > I presume it is a md5sum, I'm not sure. >=20 >=20 > -- > Seth > It might just be your lucky day, if you only knew. >=20 >=20 The .sig (signature) file it's like md5sum but made with GPG in this case GnuPG and can also verify authenticity,curruption of the file just like Seth pointed out. Regards, Paul --=-WbWwql+ZTDvJiS5dutYo Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+QV6KIymMQsXoRDARAoaQAJ90FghSYeyVxJ6DNmDSrXXmm6o65ACfWRZx LNX6rBX6Xg9UaSdd7AGFero= =1lGO -----END PGP SIGNATURE----- --=-WbWwql+ZTDvJiS5dutYo-- From owner-linux-xfs@oss.sgi.com Wed Feb 5 12:26:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Feb 2003 12:26:07 -0800 (PST) Received: from hotmail.com (f20.sea2.hotmail.com [207.68.165.20]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h15KQ23v004315 for ; Wed, 5 Feb 2003 12:26:02 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 5 Feb 2003 12:33:40 -0800 Received: from 208.244.233.175 by sea2fd.sea2.hotmail.msn.com with HTTP; Wed, 05 Feb 2003 20:33:40 GMT X-Originating-IP: [208.244.233.175] From: "Rick Smith" To: lord@sgi.com Cc: linux-xfs@oss.sgi.com Subject: Re: U320 Large Array Performance Date: Wed, 05 Feb 2003 12:33:40 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 05 Feb 2003 20:33:40.0546 (UTC) FILETIME=[DE4F7A20:01C2CD55] X-archive-position: 2542 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: rgsmith72@hotmail.com Precedence: bulk X-list: linux-xfs Content-Length: 1309 Lines: 42 Steve, After examining the output of the xfs_bmap that I sent you it looks like each file has a different allocation group for the 15 disk case. With 14 disks (73GB each) there are 240 allocation groups when I build the filesystem and I get 257 allocation groups when I use 15 disks. Could there be an issue when exceeding 256 allocation groups that affects the mapping of files to allocation groups? Rick >From: Steve Lord >To: Rick Smith >CC: linux-xfs@oss.sgi.com >Subject: Re: U320 Large Array Performance >Date: 05 Feb 2003 12:02:08 -0600 > >On Tue, 2003-02-04 at 16:47, Rick Smith wrote: > > Steve, > > Here is the output from xfs_info, please excuse the formatting. I am >using > > a chunk size of 4K in the raid. Larger sizes seem to degrade >performance. > > Thanks for your help. > > > >Can you do one more thing for me, with these configurations send me the >xfs_bmap -v output for a file on each filesystem. > >Thanks, > >Steve > >-- > >Steve Lord voice: +1-651-683-3511 >Principal Engineer, Filesystem Software email: lord@sgi.com _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus From owner-linux-xfs@oss.sgi.com Wed Feb 5 12:51:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Feb 2003 12:51:23 -0800 (PST) Received: from hotmail.com (f10.sea2.hotmail.com [207.68.165.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h15KpK3v004939 for ; Wed, 5 Feb 2003 12:51:20 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 5 Feb 2003 11:53:23 -0800 Received: from 208.244.233.175 by sea2fd.sea2.hotmail.msn.com with HTTP; Wed, 05 Feb 2003 19:53:23 GMT X-Originating-IP: [208.244.233.175] From: "Rick Smith" To: lord@sgi.com Cc: linux-xfs@oss.sgi.com Subject: Re: U320 Large Array Performance Date: Wed, 05 Feb 2003 11:53:23 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 05 Feb 2003 19:53:23.0786 (UTC) FILETIME=[3DCF2AA0:01C2CD50] X-archive-position: 2543 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: rgsmith72@hotmail.com Precedence: bulk X-list: linux-xfs Content-Length: 2566 Lines: 72 Steve, Here is the data you requested. By the way, I experimented with agsize as you suggested and it didn't have any affect. In fact (as you probably know), the tool mkfs.xfs produces a warning when agsize is a multiple of stripe size. Output sampling of 4 files written in succession with 14 disks (excellent performance): test.459.data: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..16199]: 7436152..7452351 0 (7436152..7452351) 16200 test.460.data: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..16199]: 7452352..7468551 0 (7452352..7468551) 16200 test.461.data: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..16199]: 7468552..7484751 0 (7468552..7484751) 16200 test.462.data: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..16199]: 7484752..7500951 0 (7484752..7500951) 16200 Output sampling of 4 files written in succession with 15 disks (performance drops significantly): test.459.data: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..16199]: 58720320..58736519 7 (64..16263) 16200 test.460.data: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..16199]: 67108928..67125127 8 (64..16263) 16200 test.461.data: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..16199]: 75497536..75513735 9 (64..16263) 16200 test.462.data: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..16199]: 83886144..83902343 10 (64..16263) Thanks for your help. Rick >From: Steve Lord >To: Rick Smith >CC: linux-xfs@oss.sgi.com >Subject: Re: U320 Large Array Performance >Date: 05 Feb 2003 12:02:08 -0600 > >On Tue, 2003-02-04 at 16:47, Rick Smith wrote: > > Steve, > > Here is the output from xfs_info, please excuse the formatting. I am >using > > a chunk size of 4K in the raid. Larger sizes seem to degrade >performance. > > Thanks for your help. > > > >Can you do one more thing for me, with these configurations send me the >xfs_bmap -v output for a file on each filesystem. > >Thanks, > >Steve > >-- > >Steve Lord voice: +1-651-683-3511 >Principal Engineer, Filesystem Software email: lord@sgi.com _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail From owner-linux-xfs@oss.sgi.com Wed Feb 5 13:14:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Feb 2003 13:14:58 -0800 (PST) Received: from hotmail.com (f58.sea2.hotmail.com [207.68.165.58]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h15LEr3v006011 for ; Wed, 5 Feb 2003 13:14:54 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 5 Feb 2003 12:48:07 -0800 Received: from 208.244.233.175 by sea2fd.sea2.hotmail.msn.com with HTTP; Wed, 05 Feb 2003 20:48:06 GMT X-Originating-IP: [208.244.233.175] From: "Rick Smith" To: lord@sgi.com Cc: linux-xfs@oss.sgi.com Subject: Re: U320 Large Array Performance Date: Wed, 05 Feb 2003 12:48:06 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 05 Feb 2003 20:48:07.0180 (UTC) FILETIME=[E2DD54C0:01C2CD57] X-archive-position: 2544 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: rgsmith72@hotmail.com Precedence: bulk X-list: linux-xfs Content-Length: 1555 Lines: 46 Steve, As a test, I shortened the size of one of the 15 disks in the array (using fdisk) in order to create a slightly smaller filesystem and thus requiring a smaller number of allocation groups. The resultant filesystem only required 256 allocation groups and I was able to improve performance over 14 disks for the first time. The results from xfs_bmap for this 15 disk array was very similar to the output that I sent you for the 14 disk array. There were no extent gaps between files written in succession and each group of files seem to have the same AG. I feel the problem is the result of >256 allocation groups. Any thoughts on this? Rick >From: Steve Lord >To: Rick Smith >CC: linux-xfs@oss.sgi.com >Subject: Re: U320 Large Array Performance >Date: 05 Feb 2003 12:02:08 -0600 > >On Tue, 2003-02-04 at 16:47, Rick Smith wrote: > > Steve, > > Here is the output from xfs_info, please excuse the formatting. I am >using > > a chunk size of 4K in the raid. Larger sizes seem to degrade >performance. > > Thanks for your help. > > > >Can you do one more thing for me, with these configurations send me the >xfs_bmap -v output for a file on each filesystem. > >Thanks, > >Steve > >-- > >Steve Lord voice: +1-651-683-3511 >Principal Engineer, Filesystem Software email: lord@sgi.com _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail From owner-linux-xfs@oss.sgi.com Wed Feb 5 13:16:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Feb 2003 13:16:28 -0800 (PST) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h15LGL3v006371 for ; Wed, 5 Feb 2003 13:16:23 -0800 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id h15LO3Qk042140 for ; Wed, 5 Feb 2003 22:24:04 +0100 (CET) Message-Id: <4.3.2.7.2.20030205221803.04022970@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 05 Feb 2003 22:24:01 +0100 To: linux-xfs@oss.sgi.com From: Seth Mos Subject: Red Hat Linux errata kernel 2.4.18-24 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2545 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: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 381 Lines: 18 Hello, Here is another another one from seth' remarkebly unreliable kernels. This is the 2.4.18-24 Red Hat Linux errata with the 1.2Pre5 patch applied. Disclaimer: It compiles but I have not boot tested these kernels yet by lack of hardware access. Good luck with them. http://iserv.nl/files/xfs/2.4.18-24/ Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Feb 5 13:44:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Feb 2003 13:44:21 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h15LiH3v007080 for ; Wed, 5 Feb 2003 13:44:17 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h15LiHQm007079 for linux-xfs@oss.sgi.com; Wed, 5 Feb 2003 13:44:17 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h15LiF3x007061 for ; Wed, 5 Feb 2003 13:44:15 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h15LUxEN006953; Wed, 5 Feb 2003 13:30:59 -0800 Date: Wed, 5 Feb 2003 13:30:59 -0800 Message-Id: <200302052130.h15LUxEN006953@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 214] filesystem lockup X-Bugzilla-Reason: AssignedTo X-archive-position: 2546 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2339 Lines: 51 http://oss.sgi.com/bugzilla/show_bug.cgi?id=214 ------- Additional Comments From cattelan@thebarn.com 2003-02-05 13:30 ------- Hmm everybody is waiting for IO even your ext3 FS's I would look at your scsi system first as these back traces seem to suggest errors in that area. ^M0xf7cedf64 0xc0116a83 schedule+0x493 (0x0, 0x1, 0xf7cec000, 0xf7cedfd0, 0xf7cedfd0) kernel .text 0xc0100000 0xc01165f0 0xc0116b40 ^M0xf7cedf8c 0xc0105de5 __down_interruptible+0x75 (0xf7cedfc4, 0xf7cedfc4) kernel .text 0xc0100000 0xc0105d70 0xc0105e60 ^M0xf7cedf9c 0xc0105ece __down_failed_interruptible+0xa (0x0, 0x0, 0x1, 0xf7cedfd0, 0xf7cedfd0) kernel .text 0xc0100000 0xc0105ec4 0xc0105ed4 ^M 0xc0222d65 .text.lock.scsi_error+0x109 kernel .text 0xc0100000 0xc0222c5c 0xc0222d80 ^M0xf7cedfec 0xc0222b6a scsi_error_handler+0x10a kernel .text 0xc0100000 0xc0222a60 0xc0222c00 ^M 0xc0105736 kernel_thread+0x26 kernel .text 0xc0100000 0xc0105710 0xc0105750 ^MEnter to end, to continue: Stack traceback for pid 13 ^M0xf7cea000 13 1 0 000 stop 0xf7cea370 scsi_eh_1 EBP EIP Function (args) ^M0xf7cebf64 0xc0116a83 schedule+0x493 (0x0, 0x1, 0xf7cea000, 0xf7cebfd0, 0xf7cebfd0) kernel .text 0xc0100000 0xc01165f0 0xc0116b40 ^M0xf7cebf8c 0xc0105de5 __down_interruptible+0x75 (0xf7cebfc4, 0xf7cebfc4) kernel .text 0xc0100000 0xc0105d70 0xc0105e60 ^M0xf7cebf9c 0xc0105ece __down_failed_interruptible+0xa (0x0, 0x0, 0x1, 0xf7cebfd0, 0xf7cebfd0) kernel .text 0xc0100000 0xc0105ec4 0xc0105ed4 ^M 0xc0222d65 .text.lock.scsi_error+0x109 kernel .text 0xc0100000 0xc0222c5c 0xc0222d80 ^M0xf7cebfec 0xc0222b6a scsi_error_handler+0x10a kernel .text 0xc0100000 0xc0222a60 0xc0222c00 ^M 0xc0105736 kernel_thread+0x26 kernel .text 0xc0100000 0xc0105710 0xc0105750 ^MEnter to end, to continue: ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Feb 5 15:42:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Feb 2003 15:42:57 -0800 (PST) Received: from hotmail.com (f13.sea2.hotmail.com [207.68.165.13]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h15Ngr3v008383 for ; Wed, 5 Feb 2003 15:42:53 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 5 Feb 2003 11:53:23 -0800 Received: from 208.244.233.175 by sea2fd.sea2.hotmail.msn.com with HTTP; Wed, 05 Feb 2003 19:53:23 GMT X-Originating-IP: [208.244.233.175] From: "Rick Smith" To: lord@sgi.com Cc: linux-xfs@oss.sgi.com Subject: Re: U320 Large Array Performance Date: Wed, 05 Feb 2003 11:53:23 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 05 Feb 2003 19:53:23.0758 (UTC) FILETIME=[3DCAE4E0:01C2CD50] X-archive-position: 2547 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: rgsmith72@hotmail.com Precedence: bulk X-list: linux-xfs Content-Length: 2566 Lines: 72 Steve, Here is the data you requested. By the way, I experimented with agsize as you suggested and it didn't have any affect. In fact (as you probably know), the tool mkfs.xfs produces a warning when agsize is a multiple of stripe size. Output sampling of 4 files written in succession with 14 disks (excellent performance): test.459.data: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..16199]: 7436152..7452351 0 (7436152..7452351) 16200 test.460.data: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..16199]: 7452352..7468551 0 (7452352..7468551) 16200 test.461.data: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..16199]: 7468552..7484751 0 (7468552..7484751) 16200 test.462.data: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..16199]: 7484752..7500951 0 (7484752..7500951) 16200 Output sampling of 4 files written in succession with 15 disks (performance drops significantly): test.459.data: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..16199]: 58720320..58736519 7 (64..16263) 16200 test.460.data: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..16199]: 67108928..67125127 8 (64..16263) 16200 test.461.data: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..16199]: 75497536..75513735 9 (64..16263) 16200 test.462.data: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..16199]: 83886144..83902343 10 (64..16263) Thanks for your help. Rick >From: Steve Lord >To: Rick Smith >CC: linux-xfs@oss.sgi.com >Subject: Re: U320 Large Array Performance >Date: 05 Feb 2003 12:02:08 -0600 > >On Tue, 2003-02-04 at 16:47, Rick Smith wrote: > > Steve, > > Here is the output from xfs_info, please excuse the formatting. I am >using > > a chunk size of 4K in the raid. Larger sizes seem to degrade >performance. > > Thanks for your help. > > > >Can you do one more thing for me, with these configurations send me the >xfs_bmap -v output for a file on each filesystem. > >Thanks, > >Steve > >-- > >Steve Lord voice: +1-651-683-3511 >Principal Engineer, Filesystem Software email: lord@sgi.com _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail From owner-linux-xfs@oss.sgi.com Wed Feb 5 15:43:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Feb 2003 15:43:03 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h15Nh13v008411 for ; Wed, 5 Feb 2003 15:43:01 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h15LomG8009726 for ; Wed, 5 Feb 2003 13:50:49 -0800 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA10727; Thu, 6 Feb 2003 10:49:22 +1100 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 78AB23000B8; Thu, 6 Feb 2003 10:49:19 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 947428F; Thu, 6 Feb 2003 10:49:19 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: linux-xfs@oss.sgi.com Cc: linux-kernel@vger.kernel.org Subject: Announce: XFS split patches for 2.4.20 - respin Date: Thu, 06 Feb 2003 10:49:13 +1100 Message-ID: <9354.1044488953@kao2.melbourne.sgi.com> X-archive-position: 2548 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 988 Lines: 29 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-Type: text/plain; charset=us-ascii ftp://oss.sgi.com/projects/xfs/download/patches/2.4.20. The xfs patches for 2.4.20 have been respun as of 2003-02-05 23:39 UTC, including kdb v3.0. For some time the XFS group have been producing split patches for XFS, separating the core XFS changes from additional patches such as kdb, xattr, acl, dmapi. The split patches are released to the world with the hope that developers and distributors will find them useful. Read the README in each directory very carefully, the split patch format has changed over a few kernel releases. Any questions that are covered by the README will be ignored. There is even a 2.4.21/README for the terminally impatient :). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Exmh version 2.1.1 10/15/1999 iD8DBQE+QaL3i4UHNye0ZOoRAl+qAKDL/6PxFSFfGk3k79Oj6PETJbX2kwCfZ8R7 N+AHlUOzIi9XP/APq/6SXZM= =fXnA -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Wed Feb 5 17:44:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Feb 2003 17:44:57 -0800 (PST) Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h161iJ3v026245; Wed, 5 Feb 2003 17:44:20 -0800 Received: from [10.0.0.10] (c-24-245-56-70.mn.client2.attbi.com [24.245.56.70]) by lips.thebarn.com (8.12.6/8.12.6) with ESMTP id h161q3cX042943; Wed, 5 Feb 2003 19:52:03 -0600 (CST) (envelope-from cattelan@thebarn.com) Subject: Re: [Bug 214] filesystem lockup From: Russell Cattelan To: linux-xfs@oss.sgi.com Cc: bugzilla-daemon@oss.sgi.com In-Reply-To: <200302052130.h15LUxEN006953@oss.sgi.com> References: <200302052130.h15LUxEN006953@oss.sgi.com> Content-Type: text/plain Organization: Message-Id: <1044496320.51364.9.camel@lupo.thebarn.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 05 Feb 2003 19:52:01 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 2549 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: 2648 Lines: 58 Ok never mind... I looked at a running system and this is the correct backtrace for those threads. On Wed, 2003-02-05 at 15:30, bugzilla-daemon@oss.sgi.com wrote: > http://oss.sgi.com/bugzilla/show_bug.cgi?id=214 > > > > > > ------- Additional Comments From cattelan@thebarn.com 2003-02-05 13:30 ------- > Hmm everybody is waiting for IO even your ext3 FS's > I would look at your scsi system first as these back traces > seem to suggest errors in that area. > > ^M0xf7cedf64 0xc0116a83 schedule+0x493 (0x0, 0x1, 0xf7cec000, 0xf7cedfd0, > 0xf7cedfd0) > kernel .text 0xc0100000 0xc01165f0 0xc0116b40 > ^M0xf7cedf8c 0xc0105de5 __down_interruptible+0x75 (0xf7cedfc4, 0xf7cedfc4) > kernel .text 0xc0100000 0xc0105d70 0xc0105e60 > ^M0xf7cedf9c 0xc0105ece __down_failed_interruptible+0xa (0x0, 0x0, 0x1, > 0xf7cedfd0, 0xf7cedfd0) > kernel .text 0xc0100000 0xc0105ec4 0xc0105ed4 > ^M 0xc0222d65 .text.lock.scsi_error+0x109 > kernel .text 0xc0100000 0xc0222c5c 0xc0222d80 > ^M0xf7cedfec 0xc0222b6a scsi_error_handler+0x10a > kernel .text 0xc0100000 0xc0222a60 0xc0222c00 > ^M 0xc0105736 kernel_thread+0x26 > kernel .text 0xc0100000 0xc0105710 0xc0105750 > ^MEnter to end, to continue: > Stack traceback for pid 13 > ^M0xf7cea000 13 1 0 000 stop 0xf7cea370 scsi_eh_1 > EBP EIP Function (args) > ^M0xf7cebf64 0xc0116a83 schedule+0x493 (0x0, 0x1, 0xf7cea000, 0xf7cebfd0, > 0xf7cebfd0) > kernel .text 0xc0100000 0xc01165f0 0xc0116b40 > ^M0xf7cebf8c 0xc0105de5 __down_interruptible+0x75 (0xf7cebfc4, 0xf7cebfc4) > kernel .text 0xc0100000 0xc0105d70 0xc0105e60 > ^M0xf7cebf9c 0xc0105ece __down_failed_interruptible+0xa (0x0, 0x0, 0x1, > 0xf7cebfd0, 0xf7cebfd0) > kernel .text 0xc0100000 0xc0105ec4 0xc0105ed4 > ^M 0xc0222d65 .text.lock.scsi_error+0x109 > kernel .text 0xc0100000 0xc0222c5c 0xc0222d80 > ^M0xf7cebfec 0xc0222b6a scsi_error_handler+0x10a > kernel .text 0xc0100000 0xc0222a60 0xc0222c00 > ^M 0xc0105736 kernel_thread+0x26 > kernel .text 0xc0100000 0xc0105710 0xc0105750 > ^MEnter to end, to continue: > > > > > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. -- Russell Cattelan From owner-linux-xfs@oss.sgi.com Wed Feb 5 18:20:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Feb 2003 18:20:31 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h162KO3v030827 for ; Wed, 5 Feb 2003 18:20:24 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h162KOA2030826 for linux-xfs@oss.sgi.com; Wed, 5 Feb 2003 18:20:24 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h162KM3x030812 for ; Wed, 5 Feb 2003 18:20:22 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h162KBc0030809; Wed, 5 Feb 2003 18:20:11 -0800 Date: Wed, 5 Feb 2003 18:20:11 -0800 Message-Id: <200302060220.h162KBc0030809@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 212] Problem compiling acl-2.0.9: undefined reference to `getxattr' X-Bugzilla-Reason: AssignedTo X-archive-position: 2550 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 604 Lines: 21 http://oss.sgi.com/bugzilla/show_bug.cgi?id=212 nathans@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From nathans@sgi.com 2003-02-05 18:20 ------- This is fixed in acl-2.2.3 (in CVS shortly) -- thanks for the report Mario. cheers. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Feb 5 18:23:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Feb 2003 18:23:32 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h162NT3v031268 for ; Wed, 5 Feb 2003 18:23:30 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h161c8Kp028671 for ; Wed, 5 Feb 2003 17:38:09 -0800 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 h162To3s4865237; Thu, 6 Feb 2003 13:29:51 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h162TmWj4863710; Thu, 6 Feb 2003 13:29:48 +1100 (EST) Date: Thu, 6 Feb 2003 13:29:48 +1100 (EST) From: Nathan Scott Message-Id: <200302060229.h162TmWj4863710@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Cc: agruen@suse.de Subject: TAKE - acl X-archive-position: 2551 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@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 459 Lines: 18 Fix link order for acl binaries when linking with static libattr.a. Date: Wed Feb 5 18:28:53 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:138746a cmd/acl/VERSION - 1.42 cmd/acl/doc/CHANGES - 1.49 cmd/acl/chacl/Makefile - 1.10 cmd/acl/debian/changelog - 1.36 cmd/acl/setfacl/Makefile - 1.9 cmd/acl/getfacl/Makefile - 1.9 From owner-linux-xfs@oss.sgi.com Thu Feb 6 02:10:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Feb 2003 02:11:02 -0800 (PST) Received: from ente.berdmann.de (frnk-d514e1d8.dsl.mediaWays.net [213.20.225.216]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h16AAv3v013379 for ; Thu, 6 Feb 2003 02:10:58 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=localhost) by ente.berdmann.de with esmtp (Exim 3.35 #1) id 18gj73-0003J5-00; Thu, 06 Feb 2003 11:18:33 +0100 Received: from 192.168.1.1 ( [192.168.1.1]) as user be@ente.berdmann.de by apollo.berdmann.de with HTTP; Thu, 6 Feb 2003 11:18:33 +0100 Message-ID: <1044526713.3e42367950301@apollo.berdmann.de> Date: Thu, 6 Feb 2003 11:18:33 +0100 From: Bernhard Erdmann To: Eric Sandeen Cc: Axel Thimm , Russell Cattelan , linux-xfs@oss.sgi.com Subject: Re: 1.2 PreRelease avaliable References: <1033780525.2804.41.camel@funky> <20021010192226.GA10689@bonzo.nirvana> <1034370452.14692.30.camel@stout.americas.sgi.com> In-Reply-To: <1034370452.14692.30.camel@stout.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 192.168.1.1 X-archive-position: 2552 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: be@berdmann.de Precedence: bulk X-list: linux-xfs Content-Length: 515 Lines: 25 Zitat von Eric Sandeen : > On Thu, 2002-10-10 at 14:22, Axel Thimm wrote: > > > Bugs: > > - The installer will not work if you try to install > "custom->everything". > > After having completed 268 of 1468 packages (754MB of 4691MB) the > installer > > chokes on anaconda: > > Hi Axel - thanks for the report. I can duplicate this, but so far > I > have no idea what the problem might be... > > -Eric Hi Eric, did you get an idea in the meanwhile? I hit this bug today. Regards Bernie From owner-linux-xfs@oss.sgi.com Thu Feb 6 02:41:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Feb 2003 02:41:33 -0800 (PST) Received: from K-7.stesmi.com (as4-1-7.has.s.bonet.se [217.215.31.238]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h16AfM3v016678 for ; Thu, 6 Feb 2003 02:41:25 -0800 Received: from stesmi.com (as4-1-7.has.s.bonet.se [217.215.31.238]) by K-7.stesmi.com (8.12.5/8.12.4) with ESMTP id h16An6xF005163; Thu, 6 Feb 2003 11:49:06 +0100 Message-ID: <3E423DA2.90704@stesmi.com> Date: Thu, 06 Feb 2003 11:49:06 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernhard Erdmann CC: Eric Sandeen , Axel Thimm , Russell Cattelan , linux-xfs@oss.sgi.com Subject: Re: 1.2 PreRelease avaliable References: <1033780525.2804.41.camel@funky> <20021010192226.GA10689@bonzo.nirvana> <1034370452.14692.30.camel@stout.americas.sgi.com> <1044526713.3e42367950301@apollo.berdmann.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2553 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: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 648 Lines: 37 Bernhard Erdmann wrote: > Zitat von Eric Sandeen : > > >>On Thu, 2002-10-10 at 14:22, Axel Thimm wrote: >> >> >>>Bugs: >>>- The installer will not work if you try to install >> >>"custom->everything". >> >>> After having completed 268 of 1468 packages (754MB of 4691MB) the >> >>installer >> >>> chokes on anaconda: >> >>Hi Axel - thanks for the report. I can duplicate this, but so far >>I >>have no idea what the problem might be... >> >>-Eric > > > > Hi Eric, > > did you get an idea in the meanwhile? I hit this bug today. Couldn't it have something to do with an overflow ? 4691MB is more than 2**32.. // Stefan From owner-linux-xfs@oss.sgi.com Thu Feb 6 03:26:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Feb 2003 03:26:41 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h16BQY3v018025 for ; Thu, 6 Feb 2003 03:26:36 -0800 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 0BB6BAC37; Thu, 6 Feb 2003 12:42:33 +0100 (CET) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id D3D6619004; Thu, 6 Feb 2003 12:42:32 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id C392C30881D; Thu, 6 Feb 2003 12:34:17 +0100 (CET) Message-ID: <3E424839.A1334265@ch.sauter-bc.com> Date: Thu, 06 Feb 2003 12:34:17 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.22-6.2.3 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Seth Mos Cc: linux-xfs@oss.sgi.com Subject: Re: Red Hat Linux errata kernel 2.4.18-24 References: <4.3.2.7.2.20030205221803.04022970@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2554 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: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Content-Length: 501 Lines: 27 Seth Mos schrieb: > > Hello, > > Here is another another one from seth' remarkebly unreliable kernels. > > This is the 2.4.18-24 Red Hat Linux errata with the 1.2Pre5 patch applied. Thank you very much! On which RH release did you build? Simon > > Disclaimer: It compiles but I have not boot tested these kernels yet by > lack of hardware access. > > Good luck with them. > > http://iserv.nl/files/xfs/2.4.18-24/ > > Cheers > -- > Seth > It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Thu Feb 6 03:42:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Feb 2003 03:42:44 -0800 (PST) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h16Bge3v019249 for ; Thu, 6 Feb 2003 03:42:41 -0800 Received: from auto-nb1.xs4all.nl (host-4.coltex.demon.nl [212.238.252.68]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id h16BoPMA047078; Thu, 6 Feb 2003 12:50:25 +0100 (CET) Message-Id: <4.3.2.7.2.20030206124434.03f806e8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 06 Feb 2003 12:50:07 +0100 To: Simon Matter From: Seth Mos Subject: Re: Red Hat Linux errata kernel 2.4.18-24 Cc: linux-xfs@oss.sgi.com In-Reply-To: <3E424839.A1334265@ch.sauter-bc.com> References: <4.3.2.7.2.20030205221803.04022970@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2555 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: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 884 Lines: 31 At 12:34 6-2-2003 +0100, Simon Matter wrote: >Seth Mos schrieb: > > > > Hello, > > > > Here is another another one from seth' remarkebly unreliable kernels. > > > > This is the 2.4.18-24 Red Hat Linux errata with the 1.2Pre5 patch applied. > >Thank you very much! > >On which RH release did you build? Red Hat 7.1, since that is the only fast box I have access to. All the others that are 7.3 would take me about a day to rebuild for all architectures. The fast box does this in about 4 hours. If there is anything special about a 7.3 build I can do it but it would take a while. The kernel seems to work for me, it stalls every now and then but that might be caused by my home dir residing on a NFS mount. Local IO seems to do fine, the Bonnie score I got was decent enough for the hardware on my testbox. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Thu Feb 6 05:30:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Feb 2003 05:31:01 -0800 (PST) Received: from web7305.mail.yahoo.co.kr (web7305.mail.yahoo.co.kr [211.119.129.206]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h16DUq3v021922 for ; Thu, 6 Feb 2003 05:30:53 -0800 Message-ID: <20030206133833.63799.qmail@web7305.mail.yahoo.co.kr> Received: from [165.213.1.1] by web7305.mail.kr.yahoo.com via HTTP; Thu, 06 Feb 2003 22:38:32 JST Date: Thu, 6 Feb 2003 22:38:32 +0900 (JST) From: =?euc-kr?q?Kwon=20SoonSon?= Subject: question on log option To: xfs MIME-Version: 1.0 Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: 8bit X-archive-position: 2556 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: ksoonson@yahoo.co.kr Precedence: bulk X-list: linux-xfs Content-Length: 790 Lines: 26 Hello XFS folks: I would like to know some of detailed design of XFS implementations. 1. Could anyone please let me know why the log is distributed among the ag if the log is set to "internal"? If I am wrong, please let me know how the log is generated. (superblock-log-ag-ag-ag... or superblock-ag(sb...log)-ag(sb..log)-ag(sb...log)...) which is correct? 2. Regarding the source code,(line 1771: xfs_mkfs.c) logagno = (xfs_agnumber_t)(agcount / 2); Could anyone please let me know what the "logagno" is for? Doesn't this mean log is generated per each ag? Thanks very much.... _____________________________________________________________________ µðÁöÅ» Ä«¸Þ¶ó¿Í Âû¶± ±ÃÇÕ- ¾ßÈÄ! »çÁø http://kr.photos.yahoo.com/ µ·µÇ´Â Áß°íÂ÷ ¼îÇθô - ¾ßÈÄ! ÀÚµ¿Â÷ http://autos.yahoo.co.kr/autos/ From owner-linux-xfs@oss.sgi.com Thu Feb 6 05:44:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Feb 2003 05:44:21 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h16DiH3v022523 for ; Thu, 6 Feb 2003 05:44:17 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h16DiHFv022522 for linux-xfs@oss.sgi.com; Thu, 6 Feb 2003 05:44:17 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h16DiF3x022507 for ; Thu, 6 Feb 2003 05:44:15 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h16DheW5022489; Thu, 6 Feb 2003 05:43:40 -0800 Date: Thu, 6 Feb 2003 05:43:40 -0800 Message-Id: <200302061343.h16DheW5022489@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 214] filesystem lockup X-Bugzilla-Reason: AssignedTo X-archive-position: 2557 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 564 Lines: 22 http://oss.sgi.com/bugzilla/show_bug.cgi?id=214 ------- Additional Comments From gale@dstl.gov.uk 2003-02-06 05:43 ------- For the record: On Thu, 2003-02-06 at 01:52, Russell Cattelan wrote: > Ok never mind... I looked at a running system and this is the correct > backtrace for those threads. The XFS and EXT[23] filesystems are running off of different SCSI controllers (and no scsi errors are logged), and both seem to be locked. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Feb 6 07:04:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Feb 2003 07:04:38 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h16F4Y3v025129 for ; Thu, 6 Feb 2003 07:04:35 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h16FL8kq018442 for ; Thu, 6 Feb 2003 09:21:08 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA26065; Thu, 6 Feb 2003 09:12:15 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id JAA90108; Thu, 6 Feb 2003 09:12:15 -0600 (CST) Date: Thu, 6 Feb 2003 09:06:55 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: =?euc-kr?q?Kwon=20SoonSon?= cc: xfs Subject: Re: question on log option In-Reply-To: <20030206133833.63799.qmail@web7305.mail.yahoo.co.kr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by tolkor.sgi.com id h16FL8kq018442 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h16F4Z3v025130 X-archive-position: 2558 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1087 Lines: 41 Hi - THe log is not in each ag, it is in an ag close to the middle of the filesystem. The "logagno" is the ag that holds the log. Hence logagno = (xfs_agnumber_t)(agcount / 2); -Eric On Thu, 6 Feb 2003, [euc-kr] Kwon SoonSon wrote: > Hello XFS folks: > > I would like to know some of detailed design of XFS > implementations. > > 1. Could anyone please let me know why the log > is distributed among the ag if the log is set to > "internal"? > If I am wrong, please let me know how the log is > generated. (superblock-log-ag-ag-ag... or > superblock-ag(sb...log)-ag(sb..log)-ag(sb...log)...) > which is correct? > > 2. Regarding the source code,(line 1771: xfs_mkfs.c) > logagno = (xfs_agnumber_t)(agcount / 2); > Could anyone please let me know what the "logagno" is > for? Doesn't this mean log is generated per each ag? > > Thanks very much.... > > _____________________________________________________________________ > µðÁöÅ» Ä«¸Þ¶ó¿Í Âû¶± ±ÃÇÕ- ¾ßÈÄ! »çÁø > http://kr.photos.yahoo.com/ > µ·µÇ´Â Áß°íÂ÷ ¼îÇθô - ¾ßÈÄ! ÀÚµ¿Â÷ > http://autos.yahoo.co.kr/autos/ > > From owner-linux-xfs@oss.sgi.com Thu Feb 6 07:32:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Feb 2003 07:32:58 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h16FWp3v028271 for ; Thu, 6 Feb 2003 07:32:52 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h16FnPkq019202 for ; Thu, 6 Feb 2003 09:49:25 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA49499 for ; Thu, 6 Feb 2003 09:40:33 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA66766 for ; Thu, 6 Feb 2003 09:40:32 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h16FeWD13207; Thu, 6 Feb 2003 09:40:32 -0600 Message-Id: <200302061540.h16FeWD13207@jen.americas.sgi.com> Date: Thu, 6 Feb 2003 09:40:32 -0600 Subject: TAKE - command rpm build fix X-archive-position: 2559 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 387 Lines: 16 fix rpm build for more versions of bash Date: Thu Feb 6 07:40:16 PST 2003 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:138783a cmd/xfsprogs/include/buildmacros - 1.6 - fix internationalization part of build macros to work with more versions of the shell. From owner-linux-xfs@oss.sgi.com Thu Feb 6 07:57:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Feb 2003 07:58:00 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h16Fvr3v001366 for ; Thu, 6 Feb 2003 07:57:54 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h16E5jG8010111 for ; Thu, 6 Feb 2003 06:05:45 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA57809; Thu, 6 Feb 2003 10:05:34 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id KAA02649; Thu, 6 Feb 2003 10:05:33 -0600 (CST) Subject: Re: 1.2 PreRelease avaliable From: Eric Sandeen To: Bernhard Erdmann Cc: Axel Thimm , Russell Cattelan , linux-xfs@oss.sgi.com In-Reply-To: <1044526713.3e42367950301@apollo.berdmann.de> References: <1033780525.2804.41.camel@funky> <20021010192226.GA10689@bonzo.nirvana> <1034370452.14692.30.camel@stout.americas.sgi.com> <1044526713.3e42367950301@apollo.berdmann.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 06 Feb 2003 10:00:13 -0600 Message-Id: <1044547214.22687.0.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 2560 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 990 Lines: 38 We have not looked at the installer at all, recently, focus has been on the code itself. In fact, there may not be an updated installer with the "final" 1.2 release; the installer has always been a "bonus" and we'll fix things as we have time. -Eric On Thu, 2003-02-06 at 04:18, Bernhard Erdmann wrote: > Zitat von Eric Sandeen : > > > On Thu, 2002-10-10 at 14:22, Axel Thimm wrote: > > > > > Bugs: > > > - The installer will not work if you try to install > > "custom->everything". > > > After having completed 268 of 1468 packages (754MB of 4691MB) the > > installer > > > chokes on anaconda: > > > > Hi Axel - thanks for the report. I can duplicate this, but so far > > I > > have no idea what the problem might be... > > > > -Eric > > > Hi Eric, > > did you get an idea in the meanwhile? I hit this bug today. > > Regards > Bernie -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Thu Feb 6 10:05:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Feb 2003 10:06:02 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h16I5t3v009596 for ; Thu, 6 Feb 2003 10:05:55 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h16GDlG8021716 for ; Thu, 6 Feb 2003 08:13:47 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA64863 for ; Thu, 6 Feb 2003 12:13:35 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id MAA42785 for ; Thu, 6 Feb 2003 12:13:36 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h16IDat04254; Thu, 6 Feb 2003 12:13:36 -0600 Message-Id: <200302061813.h16IDat04254@jen.americas.sgi.com> Date: Thu, 6 Feb 2003 12:13:36 -0600 Subject: TAKE - fix memory leaks To: linux-xfs@oss.sgi.com X-archive-position: 2561 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 568 Lines: 20 fix a couple of memory leaks found by stanford checker Date: Thu Feb 6 10:13:04 PST 2003 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:138812a linux/fs/xfs/xfs_log_recover.c - 1.254 - during log recovery, delay allocating a chunk of memory until we know we are actually going to need it. Removes a leak in xlog_recover_add_to_trans(). linux/fs/xfs/xfs_dir_leaf.c - 1.108 - always free allocated memory in xfs_dir_leaf_to_shortform From owner-linux-xfs@oss.sgi.com Thu Feb 6 14:27:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Feb 2003 14:27:29 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h16MRK3v013706 for ; Thu, 6 Feb 2003 14:27:21 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h16Mhtkq000899 for ; Thu, 6 Feb 2003 16:43:56 -0600 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 h16MXj3s4963160 for ; Fri, 7 Feb 2003 09:33:45 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h16MXimK5070019 for linux-xfs@oss.sgi.com; Fri, 7 Feb 2003 09:33:44 +1100 (EST) Date: Fri, 7 Feb 2003 09:33:44 +1100 (EST) From: Nathan Scott Message-Id: <200302062233.h16MXimK5070019@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - spread buildmacros fix around X-archive-position: 2562 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@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 524 Lines: 18 Push Steve's INSTALL_LINGUAS shell macro fix to other buildmacros files, and make a similar fixup for the INSTALL_MAN macro. Date: Thu Feb 6 14:31:59 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:138878a cmd/dmapi/include/buildmacros - 1.6 cmd/xfsprogs/include/buildmacros - 1.7 cmd/acl/include/buildmacros - 1.7 cmd/attr/include/buildmacros - 1.6 cmd/xfsdump/include/buildmacros - 1.6 From owner-linux-xfs@oss.sgi.com Thu Feb 6 23:00:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Feb 2003 23:00:29 -0800 (PST) Received: from mail.lbsd.net (mail.lbsd.net [196.25.111.97]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1770K3v023028 for ; Thu, 6 Feb 2003 23:00:21 -0800 Received: from localhost (nkukard@localhost) by mail.lbsd.net (8.12.1/8.12.1) with ESMTP id h1777jIQ005424; Fri, 7 Feb 2003 09:07:46 +0200 Date: Fri, 7 Feb 2003 09:07:45 +0200 (SAST) From: Nigel Kukard To: IDMS Linux Mailing List cc: Linux XFS Mailing List Subject: [PATCH] 2.4.20 + xfs-20030207 + grsecurity 1.9.8 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2563 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: nkukard@lbsd.net Precedence: bulk X-list: linux-xfs Content-Length: 1512 Lines: 45 Hi Guys, After alot of testing I'm glad to release the 2.4.20+xfs+grsec kernel patch. Patch can be found at http://www.lbsd.net under Development Status. Enjoy! -- Nigel Kukard (Chief Executive Officer) Lando Technologies Africa (Pty) Ltd nigel@lando.co.za www.lando.co.za Tel: 083 399 5822 Fax: 086 1100036 Hoheisen Park Bellville, Cape Town National Internet Service Provider The best language to use is the language that was designed for what you want to use it for - 1997 ===================================================================== Disclaimer ---------- The contents of this message and any attachments are intended solely for the addressee's use and may be legally privileged and/or confidential information. This message may not be retained, distributed, copied or used if you are not he addressee of this message. If this message was sent to you in error, please notify the sender immediately by reply e-mail and then destroy the message and any copies thereof. Opinions, conclusions and other information in this message may be personal to the sender and is not that of Lando Technologies Africa or any of it's subsideries, associated companies or principals and is therefore not endorsed by any of the Lando groups of companies. Due to e-maill communication being insecure, Lando groups of companies do not guarantee confidentiality, security, accuracy or performance of the e-mail. Any liability for viruses is excluded to the fullest extent. From owner-linux-xfs@oss.sgi.com Fri Feb 7 01:39:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Feb 2003 01:39:22 -0800 (PST) Received: from kerberos.suse.cz (kerberos.suse.cz [195.47.106.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h179dC3v024583 for ; Fri, 7 Feb 2003 01:39:14 -0800 Received: from chimera.suse.cz (chimera.suse.cz [10.20.0.2]) by kerberos.suse.cz (SuSE SMTP server) with ESMTP id 16CAF59D368 for ; Fri, 7 Feb 2003 10:46:57 +0100 (CET) Received: from alienAngel.upjs.sk (test12.suse.cz [10.20.3.140]) by chimera.suse.cz (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h179kv415465 for ; Fri, 7 Feb 2003 10:46:57 +0100 X-Authentication-Warning: chimera.suse.cz: Host test12.suse.cz [10.20.3.140] claimed to be alienAngel.upjs.sk Received: from localhost (ja@localhost) by alienAngel.upjs.sk (8.12.6/8.12.6/Submit) with ESMTP id h179kiSO002036 for ; Fri, 7 Feb 2003 10:46:44 +0100 X-Authentication-Warning: alienAngel.home.sk: ja owned process doing -bs Date: Fri, 7 Feb 2003 10:46:44 +0100 (CET) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: linux-xfs@oss.sgi.com Subject: can't seek in filesystem at bb 8207728640 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2564 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: 1579 Lines: 47 Hi all. # xfs_db -r /dev/hda8 xfs_db: freesp can't seek in filesystem at bb 8207728640 can't read btree block 0/1025966080 can't seek in filesystem at bb 29141501952 can't read btree block 0/3642687744 from to extents blocks pct 1 1 55 55 0.02 2 3 141 338 0.10 4 7 166 947 0.27 8 15 477 5803 1.67 16 31 50 1148 0.33 32 63 20 929 0.27 64 127 25 2439 0.70 128 255 11 1691 0.49 256 511 1 423 0.12 512 1023 1 664 0.19 4096 8191 3 19129 5.49 8192 16383 3 36191 10.39 16384 32767 1 32228 9.25 32768 65535 3 148128 42.53 65536 131071 1 98208 28.19 xfs_db: I found this message on one of my xfs partions. Please can anybody explain me that? How dangerous is that for my data? The FS seems to work normaly, I can write to disk, delete and read (I tried to read all data on partition.). After founding this messages I checked all my computers with xfs filesystem but messages appears only on this one partition. I'm using always the latest CVS snap-patch but I don't know if bug happend with last one or previous one (I don't use xfs_db regularly). If you need any additional information, please let me know. Kernel is vanilla 2.4.20 with SGI XFS Snap-Patch-2003-01-26 with ACLs, quota, no debug enabled Partition is mounted without quota. xfs_db is from xfsprogs-2.3.6 Thanks. Jan Derfinak From owner-linux-xfs@oss.sgi.com Fri Feb 7 05:48:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Feb 2003 05:48:12 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h17Dm53v011648 for ; Fri, 7 Feb 2003 05:48:06 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h17D2tKp015174 for ; Fri, 7 Feb 2003 05:02:55 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA04653; Fri, 7 Feb 2003 07:55:50 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id HAA58703; Fri, 7 Feb 2003 07:55:50 -0600 (CST) Date: Fri, 7 Feb 2003 07:50:21 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Jan Derfinak cc: linux-xfs@oss.sgi.com Subject: Re: can't seek in filesystem at bb 8207728640 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2565 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2034 Lines: 60 How big is your filesystem? 8207728640*512 is >2T, I doubt that your 8th partition on your IDE drive is that big... :) Can you try an xfs_repair -n on /dev/hda8 when it's unmounted, see if it finds any errors? (-n tells it to not really make any changes, do it without -n if you really want it to repair). -Eric On Fri, 7 Feb 2003, Jan Derfinak wrote: > Hi all. > > # xfs_db -r /dev/hda8 > xfs_db: freesp > can't seek in filesystem at bb 8207728640 > can't read btree block 0/1025966080 > can't seek in filesystem at bb 29141501952 > can't read btree block 0/3642687744 > from to extents blocks pct > 1 1 55 55 0.02 > 2 3 141 338 0.10 > 4 7 166 947 0.27 > 8 15 477 5803 1.67 > 16 31 50 1148 0.33 > 32 63 20 929 0.27 > 64 127 25 2439 0.70 > 128 255 11 1691 0.49 > 256 511 1 423 0.12 > 512 1023 1 664 0.19 > 4096 8191 3 19129 5.49 > 8192 16383 3 36191 10.39 > 16384 32767 1 32228 9.25 > 32768 65535 3 148128 42.53 > 65536 131071 1 98208 28.19 > xfs_db: > > I found this message on one of my xfs partions. Please can anybody explain > me that? How dangerous is that for my data? The FS seems to work normaly, I > can write to disk, delete and read (I tried to read all data on partition.). > After founding this messages I checked all my computers with xfs filesystem > but messages appears only on this one partition. I'm using always the latest > CVS snap-patch but I don't know if bug happend with last one or previous one > (I don't use xfs_db regularly). If you need any additional information, > please let me know. > > Kernel is vanilla 2.4.20 with > SGI XFS Snap-Patch-2003-01-26 with ACLs, quota, no debug enabled > Partition is mounted without quota. > > xfs_db is from xfsprogs-2.3.6 > > Thanks. > > Jan Derfinak > > > > From owner-linux-xfs@oss.sgi.com Fri Feb 7 07:06:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Feb 2003 07:06:16 -0800 (PST) Received: from mail.upjs.sk (mail.upjs.sk [158.197.16.41]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h17F6B3v013122 for ; Fri, 7 Feb 2003 07:06:12 -0800 Received: from localhost (ja@localhost) by mail.upjs.sk (8.11.6/8.11.6) with ESMTP id h17FDJg09758; Fri, 7 Feb 2003 16:13:19 +0100 Date: Fri, 7 Feb 2003 16:13:19 +0100 (CET) From: Jan Derfinak To: Eric Sandeen cc: linux-xfs@oss.sgi.com Subject: Re: can't seek in filesystem at bb 8207728640 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2566 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: 570 Lines: 19 On Fri, 7 Feb 2003, Eric Sandeen wrote: > How big is your filesystem? 8207728640*512 is >2T, I doubt > that your 8th partition on your IDE drive is that big... :) Of course no. The partition is about 16GB. > > Can you try an xfs_repair -n on /dev/hda8 when it's unmounted, > see if it finds any errors? (-n tells it to not really make any changes, > do it without -n if you really want it to repair). Oh yes. I forgot write that I ran xfs_repair -n. It doesn't detect any error. After that I ran xfs_repair without -n but problem doesn't disappear. jano From owner-linux-xfs@oss.sgi.com Fri Feb 7 07:42:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Feb 2003 07:42:53 -0800 (PST) Received: from w1301.hostcentric.net (w1301.hostcentric.net [209.25.197.254]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h17Fgn3v013789 for ; Fri, 7 Feb 2003 07:42:50 -0800 Received: (qmail 25496 invoked by alias); 7 Feb 2003 15:50:38 -0000 Received: from unknown (HELO avalanche) (195.228.226.66) by 0 with SMTP; 7 Feb 2003 15:50:38 -0000 Message-ID: <004001c2cec0$a40997d0$0a00a8c0@avalanche> Reply-To: "Gabor Forgacs" From: "Gabor Forgacs" To: Subject: maxiosz value Date: Fri, 7 Feb 2003 16:50:28 +0100 Organization: Colorfront MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 2567 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: gabor@colorfront.com Precedence: bulk X-list: linux-xfs Content-Length: 271 Lines: 13 Hi all i just recognized some performance problem on xfs which probably related to the low value of the maxiosz value it reports about 512kb (by heart) value. Could i just set this value higher some way ? thank you Gabor Forgacs [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Fri Feb 7 13:00:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Feb 2003 13:00:35 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h17L0Q3v018482 for ; Fri, 7 Feb 2003 13:00:27 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h17J8MG8017588 for ; Fri, 7 Feb 2003 11:08:23 -0800 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 IAA02194; Sat, 8 Feb 2003 08:06:56 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id IAA18612; Sat, 8 Feb 2003 08:06:55 +1100 (EST) Date: Sat, 8 Feb 2003 08:06:55 +1100 From: Nathan Scott To: Jan Derfinak Cc: linux-xfs@oss.sgi.com Subject: Re: can't seek in filesystem at bb 8207728640 Message-ID: <20030208080654.A819435@wobbly.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ja@mail.upjs.sk on Fri, Feb 07, 2003 at 10:46:44AM +0100 X-archive-position: 2568 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: 811 Lines: 34 On Fri, Feb 07, 2003 at 10:46:44AM +0100, Jan Derfinak wrote: > Hi all. hi there, > # xfs_db -r /dev/hda8 > xfs_db: freesp > can't seek in filesystem at bb 8207728640 > can't read btree block 0/1025966080 > can't seek in filesystem at bb 29141501952 > can't read btree block 0/3642687744 > ... > I found this message on one of my xfs partions. Please can anybody explain > me that? It is almost certainly an xfs_db bug that was fixed recently. > How dangerous is that for my data? Not dangerous, its likely to be a problem in xfs_db, so not on-disk. > xfs_db is from xfsprogs-2.3.6 Try xfsprogs-2.3.7, from xfsprogs/doc/CHANGES... xfsprogs-2.3.7 (14 November 2002) - Fix an endian bug in xfs_db freesp command when descending into multi-level agf cnt/bno btrees. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Feb 7 16:44:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Feb 2003 16:44:25 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h180iH3v022758 for ; Fri, 7 Feb 2003 16:44:17 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h180iHTt022757 for linux-xfs@oss.sgi.com; Fri, 7 Feb 2003 16:44:17 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h180iG3x022743 for ; Fri, 7 Feb 2003 16:44:16 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h180V9ga022679; Fri, 7 Feb 2003 16:31:09 -0800 Date: Fri, 7 Feb 2003 16:31:09 -0800 Message-Id: <200302080031.h180V9ga022679@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 206] XFS filesysem corruption while umounting sw raid 1 X-Bugzilla-Reason: AssignedTo X-archive-position: 2569 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1178 Lines: 31 http://oss.sgi.com/bugzilla/show_bug.cgi?id=206 hmh@debian.org changed: What |Removed |Added ---------------------------------------------------------------------------- Version|Current |1.1.x ------- Additional Comments From hmh@debian.org 2003-02-07 16:31 ------- I've duplicated the problem as well. Linux 2.4.18, xfs 1.1 patches from SGI, SMP. userspace is Debian 3.0r1. Upon remount ro of /dev/md0 (root filesystem, RAID1 array) followed by a reboot, the xfs fs would be corrupted. xfs_repair fixes the problem, which among other things causes the primary xfs superblock to be trashed. I am not 100% sure the corruption happens at umount (well, I suppose a mount ro,remount since it happened on the root partition at reboot time), raid1 shutdown (maybe xfs doesn't flush state right at raid1 read-only remount for root fs shutdown?), or raid1 resync. The problem was very easy to duplicate: wait for the raid to resync, reboot, and there would it go. xfs_repair time, again. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sat Feb 8 10:14:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 08 Feb 2003 10:14:26 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h18IEI3v001914 for ; Sat, 8 Feb 2003 10:14:18 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h18IEILT001913 for linux-xfs@oss.sgi.com; Sat, 8 Feb 2003 10:14:18 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h18IEG3x001899 for ; Sat, 8 Feb 2003 10:14:16 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h18HppOP001753; Sat, 8 Feb 2003 09:51:51 -0800 Date: Sat, 8 Feb 2003 09:51:51 -0800 Message-Id: <200302081751.h18HppOP001753@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 217] New: Kernel compilation error X-Bugzilla-Reason: AssignedTo X-archive-position: 2570 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2099 Lines: 75 http://oss.sgi.com/bugzilla/show_bug.cgi?id=217 Summary: Kernel compilation error Product: Linux XFS Version: unspecified Platform: IA32 OS/Version: Linux Status: NEW Severity: normal Priority: Medium Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: nemeczek@drq.pl If this is a userspace bug, what version of the package are you using: What kernel are you using: 2.4.20 without loadable modules Where did the XFS code come from? (CVS, Linus, your distribution, etc): ftp://oss.sgi.com/projects/xfs/patches/2.4.20/xfs-2.4.20-all-i386.bz2 Description of Problem: Undeclared symbol ESRCH in module.h (see below) _________________________________________________________ gcc -D__KERNEL__ -I/usr/src/linux-2.4.20-bugreport/include -Wall -Wstrict- prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame- pointer -pipe -march=i686 -nostdinc -iwithprefix include - DKBUILD_BASENAME=sys -c -o sys.o sys.c /usr/src/linux-2.4.20-bugreport/include/linux/module.h: In function `print_symbol': In file included from sys.c:7: /usr/src/linux-2.4.20-bugreport/include/linux/module.h:434: `ESRCH' undeclared (first use in this function) /usr/src/linux-2.4.20-bugreport/include/linux/module.h:434: (Each undeclared identifier is reported only once /usr/src/linux-2.4.20-bugreport/include/linux/module.h:434: for each function it appears in.) /usr/src/linux-2.4.20-bugreport/include/linux/module.h:435: warning: control reaches end of non-void function make[2]: *** [sys.o] Error 1 How Reproducible: Steps to Reproduce: 1. Patch kernel 2.4.20 2. Disable loadable module support 3. make bzImage Actual Results: Expected Results: Additional Information: My workaround: ---- line 10 #include #include #include #include #ifdef __GENKSYMS__ ---- ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sat Feb 8 11:51:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 08 Feb 2003 11:51:17 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h18Jp83v002910 for ; Sat, 8 Feb 2003 11:51:08 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h18Jp8Ok002909 for linux-xfs@oss.sgi.com; Sat, 8 Feb 2003 11:51:08 -0800 Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h18Jp43v002895; Sat, 8 Feb 2003 11:51:05 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 1B2DD18B0A9A; Sat, 8 Feb 2003 11:59:01 -0800 (PST) Date: Sat, 8 Feb 2003 11:59:01 -0800 From: Chris Wedgwood To: bugzilla-daemon@oss.sgi.com, nemeczek@drq.pl Cc: xfs-master@oss.sgi.com Subject: Re: [Bug 217] New: Kernel compilation error Message-ID: <20030208195901.GA8013@f00f.org> References: <200302081751.h18HppOP001753@oss.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200302081751.h18HppOP001753@oss.sgi.com> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2571 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: 284 Lines: 13 On Sat, Feb 08, 2003 at 09:51:51AM -0800, bugzilla-daemon@oss.sgi.com wrote: > /usr/src/linux-2.4.20-bugreport/include/linux/module.h:434: `ESRCH' > undeclared (first use in this function) I've seen this too. Make sure you have #include in linux/module.h. --cw From owner-linux-xfs@oss.sgi.com Sat Feb 8 14:34:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 08 Feb 2003 14:34:58 -0800 (PST) Received: from lindy.SoftHome.net (lindy.SoftHome.net [66.54.152.212]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h18MYl3v004175 for ; Sat, 8 Feb 2003 14:34:48 -0800 Received: from localhost (localhost [127.0.0.1]) (uid 422) by lindy.SoftHome.net with local; Sat, 08 Feb 2003 15:42:49 -0700 To: Christoph Hellwig cc: linux-xfs@oss.sgi.com Subject: Re: xfs oops In-Reply-To: Message from Christoph Hellwig of "Tue, 04 Feb 2003 09:15:38 GMT." <20030204091538.A29171@infradead.org> References: <20030204091538.A29171@infradead.org> Date: Sat, 08 Feb 2003 15:42:49 -0700 From: Brian Grossman Message-ID: X-archive-position: 2572 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: brian@SoftHome.net Precedence: bulk X-list: linux-xfs Content-Length: 615 Lines: 20 > On Mon, Feb 03, 2003 at 11:20:14PM -0700, Brian Grossman wrote: > > > > This oops is with kernel 2.4.20 + preemptable patch + xfs + v4l2. > > The cpu is an athlon. > > Streamer records tv to disk from bttv. The recording is going > > to an xfs partition. > > There are also ext3 and reiserfs partitions on this system. > > The taint is a geforce4 video card. > > Please try to reproduce it without the preempt patch. It still gets oopses. Most recently in kswapd. I'll try factoring out nvidia next. Are there any known issues combining xfs with v4l2, nvidia or preempt? Or with ext3 or reiserfs? Brian From owner-linux-xfs@oss.sgi.com Sat Feb 8 14:41:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 08 Feb 2003 14:41:59 -0800 (PST) Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h18Mfq3v004649 for ; Sat, 8 Feb 2003 14:41:53 -0800 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id h18Mnluk023885 for ; Sat, 8 Feb 2003 23:49:48 +0100 (CET) Message-Id: <4.3.2.7.2.20030208234122.02eb5018@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 08 Feb 2003 23:49:32 +0100 To: linux-xfs@oss.sgi.com From: Seth Mos Subject: Contributed 2.4.18-24 XFS 1.2 pre5 kernels Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2573 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: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 1048 Lines: 28 Hi, So far the kernels I made have been downloaded a number of times and I was wondering if anyone is having problems with them. I myself don't have the hardware or time to thoroughly test the kernels, and yes I run the kernels I made on a number of test boxen and some semi production ones with good succes. These errata kernels are rather important for people who have broadcom network cards and are experiencing crashes or hangs. And since I have a few non production systems using these cards I sort of needed these errata as well. I might do more errata kernels in the future as time permits and the amount of core changes in the errata don't creat unresolvable conflicts. So if anyone has comments, suggestions or problems with these kernels I would like to now them. In case people forgot where they are, go here http://iserv.nl/files/xfs/ If you file a bugreport in bugzilla, make sure to mention that they are contributed kernels. Not the official SGI kit. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Sat Feb 8 15:14:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 08 Feb 2003 15:14:25 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h18NEI3v005343 for ; Sat, 8 Feb 2003 15:14:18 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h18NEIIH005342 for linux-xfs@oss.sgi.com; Sat, 8 Feb 2003 15:14:18 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h18NEG41005326 for ; Sat, 8 Feb 2003 15:14:17 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h18N00ZH005221; Sat, 8 Feb 2003 15:00:00 -0800 Date: Sat, 8 Feb 2003 15:00:00 -0800 Message-Id: <200302082300.h18N00ZH005221@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 217] Kernel compilation error X-Bugzilla-Reason: AssignedTo X-archive-position: 2574 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1284 Lines: 49 http://oss.sgi.com/bugzilla/show_bug.cgi?id=217 kaos@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|xfs-master@oss.sgi.com |kaos@sgi.com ------- Additional Comments From cw@f00f.org 2003-02-08 11:51 ------- Subject: Re: New: Kernel compilation error On Sat, Feb 08, 2003 at 09:51:51AM -0800, bugzilla-daemon@oss.sgi.com wrote: > /usr/src/linux-2.4.20-bugreport/include/linux/module.h:434: `ESRCH' > undeclared (first use in this function) I've seen this too. Make sure you have #include in linux/module.h. --cw ------- Additional Comments From kaos@sgi.com 2003-02-08 14:59 ------- The backport of kksymoops from 2.5 to 2.4 and included in kdb v3.0 did not cater for kernels with no modules at all. Quick patch until I can upgrade kdb. --- linux/include/linux/module.h Sun Feb 9 09:58:57 2003 +++ linux/include/linux/module.h Sun Feb 9 09:58:33 2003 @@ -428,6 +428,7 @@ #else +#include static inline int print_symbol(const char *fmt, unsigned long address) { ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sat Feb 8 15:33:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 08 Feb 2003 15:33:50 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h18NXg3v005843 for ; Sat, 8 Feb 2003 15:33:43 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 4615918B0AA3; Sat, 8 Feb 2003 15:41:39 -0800 (PST) Date: Sat, 8 Feb 2003 15:41:39 -0800 From: Chris Wedgwood To: Brian Grossman Cc: Christoph Hellwig , linux-xfs@oss.sgi.com Subject: Re: xfs oops Message-ID: <20030208234139.GB23898@f00f.org> References: <20030204091538.A29171@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2575 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: 741 Lines: 25 On Sat, Feb 08, 2003 at 03:42:49PM -0700, Brian Grossman wrote: > It still gets oopses. Most recently in kswapd. I'll try factoring > out nvidia next. I've seen this too... I'm actually trying to reproduce this now but so far it's been pretty good other than some lock contention issues. > Are there any known issues combining xfs with v4l2, nvidia or > preempt? Or with ext3 or reiserfs? I'm trying with preemtp and without the nv driver... previously when I got this the nv driver has been loaded although wasn't active at the time. Sadly, 2.5.x and the nv driver don't play well together right now in terms of locking. I'd love to know if you can reproduce this *without* the nv driver as so far I've been unable to. --cw From owner-linux-xfs@oss.sgi.com Sat Feb 8 16:28:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 08 Feb 2003 16:28:43 -0800 (PST) Received: from lindy.SoftHome.net (ip212.CamelotCourt.com [66.54.152.212] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h190Sa3v006777 for ; Sat, 8 Feb 2003 16:28:37 -0800 Received: from localhost (localhost [127.0.0.1]) (uid 422) by lindy.SoftHome.net with local; Sat, 08 Feb 2003 17:36:39 -0700 To: Chris Wedgwood cc: Christoph Hellwig , linux-xfs@oss.sgi.com Subject: Re: xfs oops In-Reply-To: Message from Chris Wedgwood of "Sat, 08 Feb 2003 15:41:39 PST." <20030208234139.GB23898@f00f.org> References: <20030204091538.A29171@infradead.org> <20030208234139.GB23898@f00f.org> Date: Sat, 08 Feb 2003 17:36:39 -0700 From: Brian Grossman Message-ID: X-archive-position: 2576 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: brian@SoftHome.net Precedence: bulk X-list: linux-xfs Content-Length: 612 Lines: 20 > > It still gets oopses. Most recently in kswapd. I'll try factoring > > out nvidia next. > > I've seen this too... I'm actually trying to reproduce this now but so > far it's been pretty good other than some lock contention issues. My most recent problem was deleting three ~1.5GB files. Oops in kswapd. RM in diskwait. Any further access to the filesystem diskwaited, too. After reboot, I discovered that the third file remained. > Sadly, 2.5.x and the nv driver don't play well together right now in > terms of locking. My problems are with 2.4.20. I'll factor out nvidia in a couple days. Brian From owner-linux-xfs@oss.sgi.com Sat Feb 8 16:46:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 08 Feb 2003 16:46:06 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h190k33v007422 for ; Sat, 8 Feb 2003 16:46:04 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id DB3F118B0AA3; Sat, 8 Feb 2003 16:54:00 -0800 (PST) Date: Sat, 8 Feb 2003 16:54:00 -0800 From: Chris Wedgwood To: Brian Grossman Cc: Christoph Hellwig , linux-xfs@oss.sgi.com Subject: Re: xfs oops Message-ID: <20030209005400.GA24125@f00f.org> References: <20030204091538.A29171@infradead.org> <20030208234139.GB23898@f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2577 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: 834 Lines: 29 On Sat, Feb 08, 2003 at 05:36:39PM -0700, Brian Grossman wrote: > My most recent problem was deleting three ~1.5GB files. Oops in > kswapd. I'm not sure it's rm (or the fs delete path) to blame... I create and delete 10GB+ files all the time under 2.4.x without problems. > RM in diskwait. Any further access to the filesystem diskwaited, > too. After reboot, I discovered that the third file remained. Yeah, if kswapd barfs, disk IO is pretty much hosed from there out out. > My problems are with 2.4.20. I noticed that after sending it. For me 2.4.20+ has been rock solid even when given lots of abuse. > I'll factor out nvidia in a couple days. Please try. It would be interesting to know if that helps... I use the nv module under 2.4.x and don't have problems, but that might be luck more than anything. --cw From owner-linux-xfs@oss.sgi.com Sun Feb 9 03:53:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 09 Feb 2003 03:53:34 -0800 (PST) Received: from ks406.kasserver.com (ks406.kasserver.com [62.141.48.110]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h19BrQ3v019828 for ; Sun, 9 Feb 2003 03:53:27 -0800 Received: from altmann.li (Aff08.pppool.de [213.6.255.8]) (authenticated) by ks406.kasserver.com (8.11.6/8.11.6) with ESMTP id h19C1Cr30128 for ; Sun, 9 Feb 2003 13:01:12 +0100 Message-ID: <3E464526.7000500@altmann.li> Date: Sun, 09 Feb 2003 13:10:14 +0100 From: achim altmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; QXW03301) Gecko/20010726 Netscape6/6.1 X-Accept-Language: de-DE MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: RedHat 8.0 anf XFS Image or Kernel-Update ? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2578 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: achim@altmann.li Precedence: bulk X-list: linux-xfs Content-Length: 579 Lines: 24 hello, i would like install a redhat-system 8.0 with XFS-Filesystem support. A image redhat-7.3-xfs is avalaible but some programms on my other machine run's under redhat8.0 and i would like work with redhat > 8.0 Please could an tell me what is better Redhat 8.0 and a kernel-update or redhat-7.3-xfs-image or redhat-8.1-xfs-beta(if is avalaible) ? And may i become many problems when i compile the kernel with XFS-Support self? Please could any her say what is the best way to install and the best stable XFS now? Thank's a lot for any helps Best reagards Achim From owner-linux-xfs@oss.sgi.com Sun Feb 9 10:16:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 09 Feb 2003 10:16:57 -0800 (PST) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h19IGm3v027907 for ; Sun, 9 Feb 2003 10:16:49 -0800 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id h19IOk0v014971; Sun, 9 Feb 2003 19:24:46 +0100 (CET) Message-Id: <4.3.2.7.2.20030209191826.032d8b38@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 09 Feb 2003 19:24:37 +0100 To: achim altmann , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: RedHat 8.0 anf XFS Image or Kernel-Update ? In-Reply-To: <3E464526.7000500@altmann.li> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2579 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: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 1433 Lines: 44 At 13:10 9-2-2003 +0100, achim altmann wrote: >hello, > >i would like install a redhat-system 8.0 with XFS-Filesystem support. That is possible. There is a XFS Red Hat 8.0 installer on the FTP site. ftp://oss.sgi.com/projects/xfs/ Don't forget to update the kernel on it after installing. If you want a dvd you can also find a link in the archives to a complete Red Hat 8.0 with XFS support installer. >A image redhat-7.3-xfs is avalaible but some programms on my other machine >run's under redhat8.0 and i would like work with redhat > 8.0 > >Please could an tell me what is better If your program needs gcc-3.2 or glibc 2.3 you will need Red Hat 8. >Redhat 8.0 and a kernel-update or redhat-7.3-xfs-image or >redhat-8.1-xfs-beta(if is avalaible) ? We only have a Red Hat 8.0 installer, there is not enough manpower to make installers for the beta products. >And may i become many problems when i compile the kernel with XFS-Support >self? There should be no problems in installing or compiling another XFS enabled kernel. The on-disk format is the same. >Please could any her say what is the best way to install and the best >stable XFS now? If you need a Red Hat 8.0 box and you already have the Red Hat 8.0 CD's I suggest fetching just the 8.0 XFS installer from the FTP site and upgrade the kernel to the 1.2pre5 version which is available. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Sun Feb 9 20:14:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 09 Feb 2003 20:14:26 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1A4EI3v032712 for ; Sun, 9 Feb 2003 20:14:18 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1A4EIuW032711 for linux-xfs@oss.sgi.com; Sun, 9 Feb 2003 20:14:18 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1A4EG3x032697 for ; Sun, 9 Feb 2003 20:14:17 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1A3wSQ8032574; Sun, 9 Feb 2003 19:58:28 -0800 Date: Sun, 9 Feb 2003 19:58:28 -0800 Message-Id: <200302100358.h1A3wSQ8032574@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 206] XFS filesysem corruption while umounting sw raid 1 X-Bugzilla-Reason: AssignedTo X-archive-position: 2581 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 384 Lines: 17 http://oss.sgi.com/bugzilla/show_bug.cgi?id=206 ------- Additional Comments From sandeen@sgi.com 2003-02-09 19:58 ------- Can you try either the latest 1.2 prerelease (pre5) or CVS? We fixed a remount, ro flushing bug recently, it might be related. -Eric ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sun Feb 9 22:15:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 09 Feb 2003 22:15:33 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1A6FQ3v001368 for ; Sun, 9 Feb 2003 22:15:26 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1A4NWG8005365 for ; Sun, 9 Feb 2003 20:23:33 -0800 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 h1A6M43s6565748; Mon, 10 Feb 2003 17:22:04 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h1A6M3Hh6636582; Mon, 10 Feb 2003 17:22:03 +1100 (EST) Date: Mon, 10 Feb 2003 17:22:03 +1100 (EST) From: Nathan Scott Message-Id: <200302100622.h1A6M3Hh6636582@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, agruen@suse.de Subject: TAKE - merge ACL userspace patches X-archive-position: 2582 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@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 3771 Lines: 151 Sync up with a bunch of outstanding patches from Andreas from while I've been away. Still a few more to come, but these are the ones that looked fine on first pass. cheers. ps: Steve, that test 033 failure should now be rectified. Fix qa test 033 - if we have to retry mkfs with a different inode size, make sure that second output is not also in the result. Date: Sat Feb 8 14:59:28 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:139152a cmd/xfstests/033 - 1.10 Subject: TAKE - Merge ACL userspace patches from Andreas. Date: Sun Feb 9 20:53:07 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:139179a cmd/acl/man/man5/acl.5 - 1.18 - Fix from Andreas - minor man pages update. cmd/acl/libacl/acl_init.c - 1.3 - Fix from Andreas - libacl memory leak. Subject: TAKE - Merge several ACL userspace patches from Andreas. Date: Sun Feb 9 21:24:16 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:139180a cmd/acl/libacl/Makefile - 1.20 - increment version number for ACL entry preallocation and moved ACL entry reordering outside of loops. cmd/acl/libacl/libobj.h - 1.6 cmd/acl/libacl/libacl.h - 1.6 cmd/acl/libacl/acl_set_tag_type.c - 1.3 cmd/acl/libacl/acl_set_qualifier.c - 1.3 cmd/acl/libacl/acl_init.c - 1.4 cmd/acl/libacl/acl_from_text.c - 1.4 cmd/acl/libacl/acl_from_mode.c - 1.3 cmd/acl/libacl/acl_free.c - 1.3 cmd/acl/libacl/acl_dup.c - 1.3 cmd/acl/libacl/acl_create_entry.c - 1.3 cmd/acl/libacl/acl_copy_int.c - 1.3 cmd/acl/libacl/acl_copy_entry.c - 1.3 cmd/acl/libacl/acl_calc_mask.c - 1.3 cmd/acl/libacl/__libobj.c - 1.3 cmd/acl/libacl/__acl_reorder_obj_p.c - 1.3 cmd/acl/libacl/__acl_from_xattr.c - 1.3 - ACL entry preallocation and moved ACL entry reordering outside of loops. cmd/acl/getfacl/getfacl.c - 1.9 - Fix an error handling case. Subject: TAKE - Revert INSTALL_MAN buildmacro change - dopey, was causing install hangs. Date: Sun Feb 9 21:34:38 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:139181a cmd/dmapi/include/buildmacros - 1.7 cmd/xfsprogs/include/buildmacros - 1.8 cmd/acl/include/buildmacros - 1.8 cmd/attr/include/buildmacros - 1.7 cmd/xfsdump/include/buildmacros - 1.7 Subject: TAKE - Merge libacl bug fix from Andreas - acl_get_file mishandled default ACL when initial ACE count guess was incorrect. Date: Sun Feb 9 21:37:09 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:139182a cmd/acl/libacl/acl_get_file.c - 1.6 Subject: TAKE - Fix from AG - Correct a signedness issue in getfacl's handling of uid/gid. Date: Sun Feb 9 21:41:42 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:139183a cmd/acl/getfacl/user_group.c - 1.4 Subject: TAKE - Sync up with Andreas - package version/doc updates. Date: Sun Feb 9 22:14:44 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:139186a cmd/acl/VERSION - 1.43 cmd/acl/doc/CHANGES - 1.50 cmd/acl/debian/changelog - 1.37 From owner-linux-xfs@oss.sgi.com Sun Feb 9 22:53:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 09 Feb 2003 22:53:09 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1A6r13v008316 for ; Sun, 9 Feb 2003 22:53:02 -0800 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 90C53AC49; Mon, 10 Feb 2003 08:09:42 +0100 (CET) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id BBC43190CB; Mon, 10 Feb 2003 08:09:42 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id C2FED30881D; Mon, 10 Feb 2003 08:01:01 +0100 (CET) Message-ID: <3E474E2D.36AA229A@ch.sauter-bc.com> Date: Mon, 10 Feb 2003 08:01:01 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.22-6.2.3 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Seth Mos Cc: linux-xfs@oss.sgi.com Subject: Re: Contributed 2.4.18-24 XFS 1.2 pre5 kernels References: <4.3.2.7.2.20030208234122.02eb5018@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2583 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: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Content-Length: 1474 Lines: 42 Seth Mos schrieb: > > Hi, > > So far the kernels I made have been downloaded a number of times and I was > wondering if anyone is having problems with them. Seth, I have rebuilt your source rpm on RedHat 7.3, which went without any problem. I'm using the resulting kernels on several RedHat 7.2 boxes now without any problem. Your work is much appreciated!! My only problem is that I still don't know how we can get RedHat to do this for us. I'm sure as we start using 2.6 (or 3.0), we will get it anyway. Simon > > I myself don't have the hardware or time to thoroughly test the kernels, > and yes I run the kernels I made on a number of test boxen and some semi > production ones with good succes. > > These errata kernels are rather important for people who have broadcom > network cards and are experiencing crashes or hangs. And since I have a few > non production systems using these cards I sort of needed these errata as well. > > I might do more errata kernels in the future as time permits and the amount > of core changes in the errata don't creat unresolvable conflicts. > > So if anyone has comments, suggestions or problems with these kernels I > would like to now them. > In case people forgot where they are, go here http://iserv.nl/files/xfs/ > > If you file a bugreport in bugzilla, make sure to mention that they are > contributed kernels. Not the official SGI kit. > > Cheers > -- > Seth > It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Sun Feb 9 23:14:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 09 Feb 2003 23:14:20 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1A7EI3v008918 for ; Sun, 9 Feb 2003 23:14:18 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1A7EI43008917 for linux-xfs@oss.sgi.com; Sun, 9 Feb 2003 23:14:18 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1A7EG3x008903 for ; Sun, 9 Feb 2003 23:14:16 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1A6x6eY008785; Sun, 9 Feb 2003 22:59:06 -0800 Date: Sun, 9 Feb 2003 22:59:06 -0800 Message-Id: <200302100659.h1A6x6eY008785@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 218] New: Probable mmap() bug that breaks cpp-3.2 X-Bugzilla-Reason: AssignedTo X-archive-position: 2584 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2716 Lines: 86 http://oss.sgi.com/bugzilla/show_bug.cgi?id=218 Summary: Probable mmap() bug that breaks cpp-3.2 Product: Linux XFS Version: Current Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: erayo@cs.bilkent.edu.tr If this is a userspace bug, what version of the package are you using: The problem occurs in the user space, but I am not certain where it comes from (it's not a crash) What kernel are you using: orion:qmake$ uname -a Linux orion 2.4.20-xfs #4 Sun Feb 9 18:07:50 EET 2003 i686 unknown Where did the XFS code come from? (CVS, Linus, your distribution, etc): I'm using CVS HEAD from SGI. Description of Problem: Problem is that cpp-3.2 will malfunct when using XFS. It has been suggested that there might be a problem with mmap() in XFS, not properly null-padding mmap() and that might indeed be the case.... Here is a typical manifestation of the problem: /home-aux/exa/code/kde/qt-copy/include/qcstring.h:394: parse error before `/' token In that source code 394 is the last line and there is no such character as '/' So if I inspect closely and run just the preprocessor: g++-3.2 -E .... g++-3.2: Internal error: Segmentation fault (program cpp0) Please submit a full bug report Now, it might seem that this is a GCC bug, but that isn't the case. When I try to compile the same code on tmpfs or ext2 everything works fine. How Reproducible: You will hate me for this :) It's very reproducible but it might be hard for you to find a test system. The bug pertains to version 2:2.95.4-17 of gcc packages in debian (other versions might not manifest this bug) I have been able to spot the problem only in compilation of Qt from qt-copy in KDE CVS. I think trying to compile Qt 3.1 will be a good start. I've tried other sources I have to reproduce the bug in a minimal setting but so far I have failed. If I can find an easier test case I will send the details. Of course, I would like to hear from you what else I can do to locate the bug or reproduce it in alternative ways. Additional Information: Here is my qt configuration if needed: export YACC='byacc -d' make -f Makefile.cvs ./configure -system-zlib -qt-gif -system-libpng -system-libjpeg \ -plugin-imgfmt-mng -thread -no-stl -no-xinerama -no-g++-exceptions \ -fast -platform linux-g++-i686 Here linux-g++-i686 is standard g++ configuration with some optimization flags and using g++-3.2.... ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Feb 10 00:53:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Feb 2003 00:53:11 -0800 (PST) Received: from mailhost.uni-koblenz.de (rz@mailhost.uni-koblenz.de [141.26.64.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1A8r23v027147 for ; Mon, 10 Feb 2003 00:53:03 -0800 Received: from bliss.uni-koblenz.de (bliss.uni-koblenz.de [141.26.64.65]) by mailhost.uni-koblenz.de (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id h1A90MhB020654 for ; Mon, 10 Feb 2003 10:01:03 +0100 Received: from localhost (localhost [127.0.0.1]) by bliss.uni-koblenz.de (8.12.6/8.12.3) with ESMTP id h1A90MHI010074 for ; Mon, 10 Feb 2003 10:00:22 +0100 From: Rainer Krienke Organization: Uni Koblenz To: linux-xfs@oss.sgi.com Subject: What is needed for a stable 2.4 based system? Date: Mon, 10 Feb 2003 10:00:21 +0100 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200302101000.22190.krienke@uni-koblenz.de> X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h1A8r43v027149 X-archive-position: 2585 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: krienke@uni-koblenz.de Precedence: bulk X-list: linux-xfs Content-Length: 1192 Lines: 32 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I want to set up a nfs file server using xfs as the filesystem (~1TBytes). The server should of course run as stable as possible. So what I would like to know is what patches I need to get a stable system. Here is what I downloaded: - - kernel 2.4.20 (from kernel.org) - - the xfs patch for 2.4.20 (xfs-2.4.20-all-i386) from ftp://oss.sgi.com/projects/xfs/download/patches/2.4.20/ Are there any futher patches needed. Is anyone using xfs in a production environment with a similar configuration? Thanks Rainer - -- - --------------------------------------------------------------------------- Rainer Krienke, Universitaet Koblenz, Rechenzentrum Universitaetsstrasse 1, 56070 Koblenz, Tel: +49 261287 -1312, Fax: -1001312 Mail: krienke@uni-koblenz.de, Web: http://www.uni-koblenz.de/~krienke Get my public PGP key: http://www.uni-koblenz.de/~krienke/mypgp.html - --------------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+R2omaldtjc/KDEoRAi7LAJ9yRKfbubjtcXwBVX6yLu0ztd5YaACeLA8Q hj8It40atjV3KMXr2HjnmZs= =Kv/Y -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Mon Feb 10 04:14:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Feb 2003 04:14:26 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1ACEJ3v001600 for ; Mon, 10 Feb 2003 04:14:19 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1ACEJjd001599 for linux-xfs@oss.sgi.com; Mon, 10 Feb 2003 04:14:19 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1ACEG43001578 for ; Mon, 10 Feb 2003 04:14:17 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1ABxnNf032014; Mon, 10 Feb 2003 03:59:49 -0800 Date: Mon, 10 Feb 2003 03:59:49 -0800 Message-Id: <200302101159.h1ABxnNf032014@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 218] Probable mmap() bug that breaks cpp-3.2 X-Bugzilla-Reason: AssignedTo X-archive-position: 2586 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 536 Lines: 18 http://oss.sgi.com/bugzilla/show_bug.cgi?id=218 ------- Additional Comments From lord@sgi.com 2003-02-10 03:59 ------- Ugh, almost certainly this is my fault. There was just some reworking of this path. I must have missed something - I did run some tests cases of load which used to break CC. Can you run the mapcheck program (sent seperately) on the filesystem where this happens and let me know the result? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Feb 10 04:17:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Feb 2003 04:17:54 -0800 (PST) Received: from kerberos.suse.cz (kerberos.suse.cz [195.47.106.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1ACHp3v002046 for ; Mon, 10 Feb 2003 04:17:52 -0800 Received: from chimera.suse.cz (chimera.suse.cz [10.20.0.2]) by kerberos.suse.cz (SuSE SMTP server) with ESMTP id 5881E59D347; Mon, 10 Feb 2003 13:25:48 +0100 (CET) Received: from alienAngel.upjs.sk (test12.suse.cz [10.20.3.140]) by chimera.suse.cz (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h1ACPm410744; Mon, 10 Feb 2003 13:25:48 +0100 X-Authentication-Warning: chimera.suse.cz: Host test12.suse.cz [10.20.3.140] claimed to be alienAngel.upjs.sk Received: from localhost (ja@localhost) by alienAngel.upjs.sk (8.12.6/8.12.6/Submit) with ESMTP id h1ACOfgo025091; Mon, 10 Feb 2003 13:24:41 +0100 X-Authentication-Warning: alienAngel.home.sk: ja owned process doing -bs Date: Mon, 10 Feb 2003 13:24:41 +0100 (CET) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: can't seek in filesystem at bb 8207728640 In-Reply-To: <20030208080654.A819435@wobbly.melbourne.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2587 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: 672 Lines: 28 On Sat, 8 Feb 2003, Nathan Scott wrote: Hi. > > How dangerous is that for my data? > > Not dangerous, its likely to be a problem in xfs_db, so not on-disk. > > > xfs_db is from xfsprogs-2.3.6 > > Try xfsprogs-2.3.7, from xfsprogs/doc/CHANGES... > > xfsprogs-2.3.7 (14 November 2002) > - Fix an endian bug in xfs_db freesp command when descending > into multi-level agf cnt/bno btrees. Thanks. Where I can find this version? Only in CVS? There is only 2.3.6 version in ftp://oss.sgi.com/projects/xfs/download/cmd_tars/. jano -- I like work, it fascinates me. I can sit and look at it for hours. Jerome Klapka Jerome (Three men in a boat) From owner-linux-xfs@oss.sgi.com Mon Feb 10 05:06:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Feb 2003 05:06:45 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1AD6W3v003226 for ; Mon, 10 Feb 2003 05:06:33 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1ACLgKp009514 for ; Mon, 10 Feb 2003 04:21:43 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA98691; Mon, 10 Feb 2003 07:14:30 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id HAA57653; Mon, 10 Feb 2003 07:14:29 -0600 (CST) Date: Mon, 10 Feb 2003 07:08:32 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Rainer Krienke cc: linux-xfs@oss.sgi.com Subject: Re: What is needed for a stable 2.4 based system? In-Reply-To: <200302101000.22190.krienke@uni-koblenz.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2588 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1643 Lines: 45 For starters, the patch you downloaded is a development snapshot, so if it's stable, you're just lucky - it has not undergone extensive testing. If you want patches that have been internally tested at SGI, get one of the Release 1.2pre5 patches from SGI - it is expected that this is the code which will be released as 1.2-final. -Eric On Mon, 10 Feb 2003, Rainer Krienke wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > > I want to set up a nfs file server using xfs as the filesystem (~1TBytes). The server should of course run as stable as > possible. So what I would like to know is what patches I need to get a stable system. Here is what I downloaded: > > - - kernel 2.4.20 (from kernel.org) > - - the xfs patch for 2.4.20 (xfs-2.4.20-all-i386) from ftp://oss.sgi.com/projects/xfs/download/patches/2.4.20/ > > Are there any futher patches needed. > Is anyone using xfs in a production environment with a similar configuration? > > Thanks > Rainer > - -- > - --------------------------------------------------------------------------- > Rainer Krienke, Universitaet Koblenz, Rechenzentrum > Universitaetsstrasse 1, 56070 Koblenz, Tel: +49 261287 -1312, Fax: -1001312 > Mail: krienke@uni-koblenz.de, Web: http://www.uni-koblenz.de/~krienke > Get my public PGP key: http://www.uni-koblenz.de/~krienke/mypgp.html > - --------------------------------------------------------------------------- > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.7 (GNU/Linux) > > iD8DBQE+R2omaldtjc/KDEoRAi7LAJ9yRKfbubjtcXwBVX6yLu0ztd5YaACeLA8Q > hj8It40atjV3KMXr2HjnmZs= > =Kv/Y > -----END PGP SIGNATURE----- > > > From owner-linux-xfs@oss.sgi.com Mon Feb 10 05:08:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Feb 2003 05:08:09 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1AD863v003658 for ; Mon, 10 Feb 2003 05:08:06 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1ACNGKp009643 for ; Mon, 10 Feb 2003 04:23:16 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA29719; Mon, 10 Feb 2003 07:16:03 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id HAA59573; Mon, 10 Feb 2003 07:16:03 -0600 (CST) Date: Mon, 10 Feb 2003 07:10:06 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Jan Derfinak cc: Nathan Scott , Subject: Re: can't seek in filesystem at bb 8207728640 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2589 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 878 Lines: 37 Hm, we've been bad about keeping those up to date - I'll put new versions out today, from cvs. -Eric On Mon, 10 Feb 2003, Jan Derfinak wrote: > On Sat, 8 Feb 2003, Nathan Scott wrote: > > Hi. > > > > How dangerous is that for my data? > > > > Not dangerous, its likely to be a problem in xfs_db, so not on-disk. > > > > > xfs_db is from xfsprogs-2.3.6 > > > > Try xfsprogs-2.3.7, from xfsprogs/doc/CHANGES... > > > > xfsprogs-2.3.7 (14 November 2002) > > - Fix an endian bug in xfs_db freesp command when descending > > into multi-level agf cnt/bno btrees. > > Thanks. > > Where I can find this version? Only in CVS? There is only 2.3.6 version in > ftp://oss.sgi.com/projects/xfs/download/cmd_tars/. > > > jano > > -- > I like work, it fascinates me. I can sit and look at it for hours. > Jerome Klapka Jerome (Three men in a boat) > > From owner-linux-xfs@oss.sgi.com Mon Feb 10 05:56:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Feb 2003 05:56:59 -0800 (PST) Received: from mailhost.uni-koblenz.de (root@mailhost.uni-koblenz.de [141.26.64.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1ADut3v004471 for ; Mon, 10 Feb 2003 05:56:56 -0800 Received: from bliss.uni-koblenz.de (bliss.uni-koblenz.de [141.26.64.65]) by mailhost.uni-koblenz.de (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id h1AE4vCX013444; Mon, 10 Feb 2003 15:04:57 +0100 Received: from localhost (localhost [127.0.0.1]) by bliss.uni-koblenz.de (8.12.6/8.12.3) with ESMTP id h1AE4uHI006027; Mon, 10 Feb 2003 15:04:56 +0100 From: Rainer Krienke Organization: Uni Koblenz To: Eric Sandeen Subject: Re: What is needed for a stable 2.4 based system? Date: Mon, 10 Feb 2003 15:04:55 +0100 User-Agent: KMail/1.5 Cc: linux-xfs@oss.sgi.com References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200302101504.56067.krienke@uni-koblenz.de> X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h1ADuv3v004472 X-archive-position: 2590 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: krienke@uni-koblenz.de Precedence: bulk X-list: linux-xfs Content-Length: 1988 Lines: 58 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Montag, 10. Februar 2003 14:08, Eric Sandeen wrote: > > On Mon, 10 Feb 2003, Rainer Krienke wrote: > > Hello, > > > > I want to set up a nfs file server using xfs as the filesystem > > (~1TBytes). The server should of course run as stable as possible. So > > what I would like to know is what patches I need to get a stable system. > > Here is what I downloaded: > > > > - - kernel 2.4.20 (from kernel.org) > > - - the xfs patch for 2.4.20 (xfs-2.4.20-all-i386) from > > ftp://oss.sgi.com/projects/xfs/download/patches/2.4.20/ > > > > Are there any futher patches needed. > > Is anyone using xfs in a production environment with a similar > > configuration? > > > > Thanks > > Rainer > > - -- > > - - -- > For starters, the patch you downloaded is a development snapshot, so if > it's stable, you're just lucky - it has not undergone extensive testing. > > If you want patches that have been internally tested at SGI, get one > of the Release 1.2pre5 patches from SGI - it is expected that this is the > code which will be released as 1.2-final. > I looked in ftp://oss.sgi.com/projects/xfs/download/Release-1.2pre5/kernel_patches/ but there is no patch for 2.4.20 only for 2.4.19. Am I looking in the wrong place or will it simply take somewhat more time until there is a stable patch for 2.4.20? Thanks Rainer - -- - --------------------------------------------------------------------------- Rainer Krienke, Universitaet Koblenz, Rechenzentrum Universitaetsstrasse 1, 56070 Koblenz, Tel: +49 261287 -1312, Fax: -1001312 Mail: krienke@uni-koblenz.de, Web: http://www.uni-koblenz.de/~krienke Get my public PGP key: http://www.uni-koblenz.de/~krienke/mypgp.html - --------------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+R7GIaldtjc/KDEoRAmPUAKDiR80dMLSTWtQsNyxkveMH8ubKvgCggQhF LHezFelyzblwkYsOyCyLZQ4= =44h9 -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Mon Feb 10 06:03:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Feb 2003 06:04:01 -0800 (PST) Received: from omta02.mta.everyone.net (sitemail3.everyone.net [216.200.145.37]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1AE3j3v005394 for ; Mon, 10 Feb 2003 06:03:56 -0800 Received: from sitemail.everyone.net (dsnat [216.200.145.62]) by omta02.mta.everyone.net (Postfix) with ESMTP id 7501C1C43C5 for ; Mon, 10 Feb 2003 06:11:38 -0800 (PST) Received: by sitemail.everyone.net (Postfix, from userid 99) id 56D1A4542; Mon, 10 Feb 2003 06:11:38 -0800 (PST) Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Date: Mon, 10 Feb 2003 06:11:38 -0800 (PST) From: marc baier To: linux-xfs@oss.sgi.com Subject: data recovery Reply-To: flyingbrain@23a.de X-Originating-Ip: [217.227.108.177] Message-Id: <20030210141138.56D1A4542@sitemail.everyone.net> X-archive-position: 2591 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: flyingbrain@23a.de Precedence: bulk X-list: linux-xfs Content-Length: 602 Lines: 27 hi there, i have a little question...... i accidentaly deleted "some" files ... first i moved them to trash and then deleted them.... :-(( i've looked at your faq and it says there is nearly no chance to restore them..... is there any chance to bring back my data???????????????? greetings and thanks marc _____________________________________________________________ 23a mail _____________________________________________________________ Select your own custom email address for FREE! Get you@yourchoice.com w/No Ads, 6MB, POP & more! http://www.everyone.net/selectmail?campaign=tag From owner-linux-xfs@oss.sgi.com Mon Feb 10 06:28:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Feb 2003 06:28:33 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1AESU3v006098 for ; Mon, 10 Feb 2003 06:28:31 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id D71A018B3B1B; Mon, 10 Feb 2003 06:36:34 -0800 (PST) Date: Mon, 10 Feb 2003 06:36:34 -0800 From: Chris Wedgwood To: marc baier Cc: linux-xfs@oss.sgi.com Subject: Re: data recovery Message-ID: <20030210143634.GA31463@f00f.org> References: <20030210141138.56D1A4542@sitemail.everyone.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030210141138.56D1A4542@sitemail.everyone.net> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2592 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: 423 Lines: 16 On Mon, Feb 10, 2003 at 06:11:38AM -0800, marc baier wrote: > first i moved them to trash and then deleted them.... :-(( > is there any chance to bring back my data???????????????? there is a slim chance to recover the data in part of the disk hasn't been used much since file deletion by groveling over the disk looking for it how well this works depends on the data and how much writing has occurred since --cw From owner-linux-xfs@oss.sgi.com Mon Feb 10 06:48:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Feb 2003 06:48:27 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1AEmO3v006805 for ; Mon, 10 Feb 2003 06:48:24 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1AE3YKp018049 for ; Mon, 10 Feb 2003 06:03:35 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA07695; Mon, 10 Feb 2003 08:56:21 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id IAA62021; Mon, 10 Feb 2003 08:56:21 -0600 (CST) Subject: Re: What is needed for a stable 2.4 based system? From: Eric Sandeen To: Rainer Krienke Cc: linux-xfs@oss.sgi.com In-Reply-To: <200302101504.56067.krienke@uni-koblenz.de> References: <200302101504.56067.krienke@uni-koblenz.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 10 Feb 2003 08:56:20 -0600 Message-Id: <1044888981.21802.3.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 2593 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2489 Lines: 69 Rainer - At this time, 1.2 will be released for 2.4.19. It may be trivial to merge the patch up to 2.4.20, but all of the testing we have done has been on 2.4.19, so that will be our release kernel version. -Eric On Mon, 2003-02-10 at 08:04, Rainer Krienke wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Montag, 10. Februar 2003 14:08, Eric Sandeen wrote: > > > > On Mon, 10 Feb 2003, Rainer Krienke wrote: > > > Hello, > > > > > > I want to set up a nfs file server using xfs as the filesystem > > > (~1TBytes). The server should of course run as stable as possible. So > > > what I would like to know is what patches I need to get a stable system. > > > Here is what I downloaded: > > > > > > - - kernel 2.4.20 (from kernel.org) > > > - - the xfs patch for 2.4.20 (xfs-2.4.20-all-i386) from > > > ftp://oss.sgi.com/projects/xfs/download/patches/2.4.20/ > > > > > > Are there any futher patches needed. > > > Is anyone using xfs in a production environment with a similar > > > configuration? > > > > > > Thanks > > > Rainer > > > - -- > > > - > - -- > For starters, the patch you downloaded is a development snapshot, so if > > it's stable, you're just lucky - it has not undergone extensive testing. > > > > If you want patches that have been internally tested at SGI, get one > > of the Release 1.2pre5 patches from SGI - it is expected that this is the > > code which will be released as 1.2-final. > > > > I looked in > > ftp://oss.sgi.com/projects/xfs/download/Release-1.2pre5/kernel_patches/ > > but there is no patch for 2.4.20 only for 2.4.19. Am I looking in the wrong > place or will it simply take somewhat more time until there is a stable patch > for 2.4.20? > > Thanks Rainer > - -- > - --------------------------------------------------------------------------- > Rainer Krienke, Universitaet Koblenz, Rechenzentrum > Universitaetsstrasse 1, 56070 Koblenz, Tel: +49 261287 -1312, Fax: -1001312 > Mail: krienke@uni-koblenz.de, Web: http://www.uni-koblenz.de/~krienke > Get my public PGP key: http://www.uni-koblenz.de/~krienke/mypgp.html > - --------------------------------------------------------------------------- > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.7 (GNU/Linux) > > iD8DBQE+R7GIaldtjc/KDEoRAmPUAKDiR80dMLSTWtQsNyxkveMH8ubKvgCggQhF > LHezFelyzblwkYsOyCyLZQ4= > =44h9 > -----END PGP SIGNATURE----- -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Mon Feb 10 07:36:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Feb 2003 07:36:13 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1AFa53v007599 for ; Mon, 10 Feb 2003 07:36:05 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1AEpGKp022999 for ; Mon, 10 Feb 2003 06:51:16 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA73730 for ; Mon, 10 Feb 2003 09:44:02 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA65802 for ; Mon, 10 Feb 2003 09:44:01 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h1AMvgV07258 for linux-xfs@oss.sgi.com; Mon, 10 Feb 2003 17:57:42 -0500 Resent-Message-Id: <200302102257.h1AMvgV07258@taclab54.munich.sgi.com> Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA25424 for ; Mon, 10 Feb 2003 09:42:07 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h1AMtmC07249 for hch@sgi.com; Mon, 10 Feb 2003 17:55:48 -0500 Date: Mon, 10 Feb 2003 17:55:48 -0500 From: Christoph Hellwig Message-Id: <200302102255.h1AMtmC07249@taclab54.munich.sgi.com> Subject: TAKE - Handle kmalloc failures in _pagebuf_page_io() properly Resent-From: hch@sgi.com Resent-Date: Mon, 10 Feb 2003 17:57:42 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 2594 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 423 Lines: 15 Contributed fix from Andreas Gruenbacher , handle out of memory situations in _pagebuf_page_io() properly. Date: Mon Feb 10 07:40:50 PST 2003 Workarea: taclab54.munich.sgi.com:/home/hch/repo/slinx/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:139202a linux/fs/xfs/pagebuf/page_buf.c - 1.92 - Handle kmalloc failures properly From owner-linux-xfs@oss.sgi.com Mon Feb 10 07:56:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Feb 2003 07:56:30 -0800 (PST) Received: from intranet.mtp.eprocess.fr (imap.eprocess.fr [62.23.135.13]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1AFuJ3v008180 for ; Mon, 10 Feb 2003 07:56:21 -0800 Received: from eprocess.fr (fcombernous.mtp.eprocess.fr [192.168.2.14]) by intranet.mtp.eprocess.fr (8.9.3/8.9.3) with ESMTP id RAA31155 for ; Mon, 10 Feb 2003 17:04:17 +0100 Message-ID: <3E47CD81.4070802@eprocess.fr> Date: Mon, 10 Feb 2003 17:04:17 +0100 From: Fabien Combernous User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: online resizing ? X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by intranet.mtp.eprocess.fr id RAA31155 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h1AFuM3v008183 X-archive-position: 2595 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: fcombernous@eprocess.fr Precedence: bulk X-list: linux-xfs Content-Length: 292 Lines: 15 Lo, I would like to know if exist a patch to permit online resizing a xfs filesystem. Thanks Fabien. -- Fabien COMBERNOUS - IT Engineer e'process - Parc Club du Millénaire Batiment n° 6 1025 rue Henri Becquerel - 34000 Montpellier FRANCE http://www.eprocess.tv - +33 (0)4 67 13 84 50 From owner-linux-xfs@oss.sgi.com Mon Feb 10 08:01:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Feb 2003 08:01:16 -0800 (PST) Received: from silver.digirati.com.br (silver.digirati.com.br [200.185.109.126]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1AG1A3v008667 for ; Mon, 10 Feb 2003 08:01:11 -0800 Received: from wsmichel (RJ227195.user.veloxzone.com.br [200.165.227.195]) (authenticated (0 bits)) by silver.digirati.com.br (8.11.6/8.11.6) with ESMTP id h1AG7xC05544; Mon, 10 Feb 2003 14:08:00 -0200 Message-ID: <008101c2d11e$9c1f8290$1601070a@mz.digirati.com.br> From: "Michel Machado" To: "Fabien Combernous" , References: <3E47CD81.4070802@eprocess.fr> Subject: Re: online resizing ? Date: Mon, 10 Feb 2003 13:08:06 -0300 Organization: Digirati MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-MIME-Autoconverted: from 8bit to quoted-printable by silver.digirati.com.br id h1AG7xC05544 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h1AG1C3v008668 X-archive-position: 2596 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: michel@digirati.com.br Precedence: bulk X-list: linux-xfs Content-Length: 514 Lines: 27 "man xfs_growfs" ----- Original Message ----- From: "Fabien Combernous" To: Sent: Monday, February 10, 2003 1:04 PM Subject: online resizing ? | Lo, | | I would like to know if exist a patch to permit online resizing a xfs | filesystem. | | Thanks Fabien. | | -- | | Fabien COMBERNOUS - IT Engineer | e'process - Parc Club du Millénaire Batiment n° 6 | 1025 rue Henri Becquerel - 34000 Montpellier FRANCE | http://www.eprocess.tv - +33 (0)4 67 13 84 50 | | | From owner-linux-xfs@oss.sgi.com Mon Feb 10 08:02:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Feb 2003 08:02:14 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1AG2B3v009075 for ; Mon, 10 Feb 2003 08:02:11 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1AFHMKp026698 for ; Mon, 10 Feb 2003 07:17:22 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA49367; Mon, 10 Feb 2003 10:10:09 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id KAA67147; Mon, 10 Feb 2003 10:10:09 -0600 (CST) Subject: Re: online resizing ? From: Eric Sandeen To: Fabien Combernous Cc: linux-xfs@oss.sgi.com In-Reply-To: <3E47CD81.4070802@eprocess.fr> References: <3E47CD81.4070802@eprocess.fr> Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 10 Feb 2003 10:10:08 -0600 Message-Id: <1044893408.21788.5.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h1AG2C3v009089 X-archive-position: 2597 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 588 Lines: 28 You can grow online, you cannot shrink on- or off-line. See "man xfs_growfs" -Eric. On Mon, 2003-02-10 at 10:04, Fabien Combernous wrote: > Lo, > > I would like to know if exist a patch to permit online resizing a xfs > filesystem. > > Thanks Fabien. > > -- > > Fabien COMBERNOUS - IT Engineer > e'process - Parc Club du Millénaire Batiment n° 6 > 1025 rue Henri Becquerel - 34000 Montpellier FRANCE > http://www.eprocess.tv - +33 (0)4 67 13 84 50 > > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Mon Feb 10 08:05:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Feb 2003 08:05:30 -0800 (PST) Received: from intranet.mtp.eprocess.fr (smtp.eprocess.fr [62.23.135.13]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1AG5P3v009579 for ; Mon, 10 Feb 2003 08:05:26 -0800 Received: from eprocess.fr (fcombernous.mtp.eprocess.fr [192.168.2.14]) by intranet.mtp.eprocess.fr (8.9.3/8.9.3) with ESMTP id RAA31270; Mon, 10 Feb 2003 17:13:15 +0100 Message-ID: <3E47CF9A.8040701@eprocess.fr> Date: Mon, 10 Feb 2003 17:13:14 +0100 From: Fabien Combernous User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michel Machado CC: linux-xfs@oss.sgi.com Subject: Re: online resizing ? References: <3E47CD81.4070802@eprocess.fr> <008101c2d11e$9c1f8290$1601070a@mz.digirati.com.br> In-Reply-To: <008101c2d11e$9c1f8290$1601070a@mz.digirati.com.br> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by intranet.mtp.eprocess.fr id RAA31270 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h1AG5R3v009581 X-archive-position: 2598 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: fcombernous@eprocess.fr Precedence: bulk X-list: linux-xfs Content-Length: 1029 Lines: 43 Many Thanks. This command look to permit an expand, realy usefull. But is it possible to reduce also ? I'm writting a document about volume managers and some features depends with file system. And i don't use all file systems available with Linux. Michel Machado wrote: > "man xfs_growfs" > > ----- Original Message ----- > From: "Fabien Combernous" > To: > Sent: Monday, February 10, 2003 1:04 PM > Subject: online resizing ? > > > | Lo, > | > | I would like to know if exist a patch to permit online resizing a xfs > | filesystem. > | > | Thanks Fabien. > | > | -- > | > | Fabien COMBERNOUS - IT Engineer > | e'process - Parc Club du Millénaire Batiment n° 6 > | 1025 rue Henri Becquerel - 34000 Montpellier FRANCE > | http://www.eprocess.tv - +33 (0)4 67 13 84 50 > | > | > | > > -- Fabien COMBERNOUS - IT Engineer e'process - Parc Club du Millénaire Batiment n° 6 1025 rue Henri Becquerel - 34000 Montpellier FRANCE http://www.eprocess.tv - +33 (0)4 67 13 84 50 From owner-linux-xfs@oss.sgi.com Mon Feb 10 08:45:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Feb 2003 08:46:02 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1AGjr3v010396 for ; Mon, 10 Feb 2003 08:45:54 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1AG15Kp032234 for ; Mon, 10 Feb 2003 08:01:05 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA80506; Mon, 10 Feb 2003 10:53:52 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id KAA74959; Mon, 10 Feb 2003 10:53:51 -0600 (CST) Subject: Re: can't seek in filesystem at bb 8207728640 From: Eric Sandeen To: Eric Sandeen Cc: Jan Derfinak , Nathan Scott , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 10 Feb 2003 10:53:50 -0600 Message-Id: <1044896030.21788.10.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 2599 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 316 Lines: 13 On Mon, 2003-02-10 at 07:10, Eric Sandeen wrote: > Hm, we've been bad about keeping those up to date - I'll put new versions > out today, from cvs. > Ok, new userspace is on oss now. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Mon Feb 10 11:14:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Feb 2003 11:14:27 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1AJEI3v012252 for ; Mon, 10 Feb 2003 11:14:18 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1AJEIXo012251 for linux-xfs@oss.sgi.com; Mon, 10 Feb 2003 11:14:18 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1AJEG3x012237 for ; Mon, 10 Feb 2003 11:14:16 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1AJ4H8c012168; Mon, 10 Feb 2003 11:04:17 -0800 Date: Mon, 10 Feb 2003 11:04:17 -0800 Message-Id: <200302101904.h1AJ4H8c012168@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 218] Probable mmap() bug that breaks cpp-3.2 X-Bugzilla-Reason: AssignedTo X-archive-position: 2600 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 680 Lines: 18 http://oss.sgi.com/bugzilla/show_bug.cgi?id=218 ------- Additional Comments From erayo@cs.bilkent.edu.tr 2003-02-10 11:04 ------- Since I trust you guys, I just ran mapcheck --all after I saw that it detected some errors. It fixed in excess of 20000 errors. Maybe you should be including the tool and documenting this bug in the distro. I guess I'm not the only one with this obscure problem. My file system now seems to work properly. Although it reported 37 errors as well, there doesn't seem to be any major failure. What are those errors anyway? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Feb 10 13:28:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Feb 2003 13:28:15 -0800 (PST) Received: from localhost.localdomain (stube.nsstc.nasa.gov [198.122.193.142]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1ALS53v013596 for ; Mon, 10 Feb 2003 13:28:06 -0800 Received: (from hargrjb@localhost) by localhost.localdomain (8.11.6/8.11.6) id h1ALEKL01679; Mon, 10 Feb 2003 15:14:20 -0600 X-Authentication-Warning: localhost.localdomain: hargrjb set sender to brian.hargrave@nsstc.nasa.gov using -f Subject: compatibility with Promise RM8000 From: Brian Hargrave To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 10 Feb 2003 15:14:20 -0600 Message-Id: <1044911660.1212.37.camel@stube> Mime-Version: 1.0 X-archive-position: 2601 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: brian.hargrave@nsstc.nasa.gov Precedence: bulk X-list: linux-xfs Content-Length: 4853 Lines: 119 We are having trouble with reliability using xfs under linux with a Promise RM8000 device. Anybody else reported related problems with this device? We have been using xfs on scsi arrays for months with no problems on a system configured exactly the same (as far as xfs, redhat, and scsi hardware). We are also having the same issue on a Mandrake9 system with a Adaptec 2940U2W scsi card. Here is a sample error message: Feb 10 13:26:48 hostname kernel: xfs_force_shutdown(sd(8,2),0x8) called from line 4068 of file xfs_bmap.c. Return address = 0xc018caf2 Feb 10 13:26:48 hostname kernel: Corruption of in-memory data detected. Shutting down filesystem: sd(8,2) Feb 10 13:26:48 hostname kernel: Please umount the filesystem, and rectify the problem(s) Here are some system details: % cat /proc/pci snip--- Bus 0, device 20, function 0: SCSI storage controller: Adaptec AIC-7881U (rev 0). IRQ 10. Master Capable. Latency=64. Min Gnt=8.Max Lat=8. I/O at 0xe800 [0xe8ff]. Non-prefetchable 32 bit memory at 0xfebff000 [0xfebfffff]. Bus 1, device 0, function 0: ---snip $ df -k Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda2 3612272 2329996 1098736 68% / none 127504 0 127504 0% /dev/shm /dev/sda2 481393216 141041656 340351560 30% /archive $ cat /etc/fstab LABEL=/ / ext3 defaults 1 1 none /dev/pts devpts gid=5,mode=620 0 0 none /proc proc defaults 0 0 none /dev/shm tmpfs defaults 0 0 /dev/sda1 swap swap defaults 0 0 /dev/sda2 /archive xfs defaults 1 2 $ uname -a Linux hostname 2.4.18-SGI_XFS_1.1smp #1 SMP Wed Apr 17 09:05:28 CDT 2002 i686 unknown $ dmesg snip--- SCSI subsystem driver Revision: 1.00 scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.4 aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs Vendor: Promise Model: 5 Disk RAID5 Rev: 1.10 Type: Direct-Access ANSI SCSI revision: 03 scsi0:A:0:0: Tagged Queuing enabled. Depth 253 Attached scsi disk sda at scsi0, channel 0, id 0, lun 0 (scsi0:A:0): 40.000MB/s transfers (20.000MHz, offset 8, 16bit) SCSI device sda: 965018624 512-byte hdwr sectors (494090 MB) sda: sda1 sda2 ---snip $ rpm -qa | grep -i xfs kernel-smp-2.4.18-SGI_XFS_1.1 xfsprogs-devel-2.0.3-0 kernel-2.4.18-SGI_XFS_1.1 xfsprogs-2.0.3-0 $ cat /proc/scsi/aic7xxx/0 Adaptec AIC7xxx driver version: 6.2.4 aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs Channel A Target 0 Negotiation Settings User: 40.000MB/s transfers (20.000MHz, offset 255, 16bit) Goal: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) Curr: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) Channel A Target 0 Lun 0 Settings Commands Queued 6085 Commands Active 0 Command Openings 32 Max Tagged Openings 253 Device Queue Frozen Count 0 Channel A Target 1 Negotiation Settings User: 40.000MB/s transfers (20.000MHz, offset 255, 16bit) Channel A Target 2 Negotiation Settings User: 40.000MB/s transfers (20.000MHz, offset 255, 16bit) Channel A Target 3 Negotiation Settings User: 40.000MB/s transfers (20.000MHz, offset 255, 16bit) Channel A Target 4 Negotiation Settings User: 40.000MB/s transfers (20.000MHz, offset 255, 16bit) Channel A Target 5 Negotiation Settings User: 40.000MB/s transfers (20.000MHz, offset 255, 16bit) Channel A Target 6 Negotiation Settings User: 40.000MB/s transfers (20.000MHz, offset 255, 16bit) Channel A Target 7 Negotiation Settings User: 40.000MB/s transfers (20.000MHz, offset 255, 16bit) Channel A Target 8 Negotiation Settings User: 40.000MB/s transfers (20.000MHz, offset 255, 16bit) Channel A Target 9 Negotiation Settings User: 40.000MB/s transfers (20.000MHz, offset 255, 16bit) Channel A Target 10 Negotiation Settings User: 40.000MB/s transfers (20.000MHz, offset 255, 16bit) Channel A Target 11 Negotiation Settings User: 40.000MB/s transfers (20.000MHz, offset 255, 16bit) Channel A Target 12 Negotiation Settings User: 40.000MB/s transfers (20.000MHz, offset 255, 16bit) Channel A Target 13 Negotiation Settings User: 40.000MB/s transfers (20.000MHz, offset 255, 16bit) Channel A Target 14 Negotiation Settings User: 40.000MB/s transfers (20.000MHz, offset 255, 16bit) Channel A Target 15 Negotiation Settings User: 40.000MB/s transfers (20.000MHz, offset 255, 16bit) From owner-linux-xfs@oss.sgi.com Mon Feb 10 16:06:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Feb 2003 16:06:47 -0800 (PST) Received: from uwast.astro.wisc.edu (uwast.astro.wisc.edu [144.92.179.130]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1B06f3v015238 for ; Mon, 10 Feb 2003 16:06:42 -0800 Received: from astro.wisc.edu (pigseye.astro.wisc.edu [128.104.136.111]) (authenticated bits=0) by uwast.astro.wisc.edu (8.12.7/8.12.7) with ESMTP id h1ANqXDZ2463028; Mon, 10 Feb 2003 17:52:33 -0600 (CST) Date: Mon, 10 Feb 2003 17:52:40 -0600 Subject: Re: compatibility with Promise RM8000 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: linux-xfs@oss.sgi.com To: Brian Hargrave From: Stephan L Jansen In-Reply-To: <1044911660.1212.37.camel@stube> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-archive-position: 2602 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: jansen@astro.wisc.edu Precedence: bulk X-list: linux-xfs Content-Length: 5470 Lines: 135 Hi, We have four of those devices and have had some problems but at this point I'm fairly sure it is not XFS related. It appears that the problems have been fixed with the latest version of the firmware (1.1.0.13) which is not yet on their web site. The problems we saw only happened under heavy load and were accompanied by numerous SCSI errors. On Monday, February 10, 2003, at 03:14 PM, Brian Hargrave wrote: > We are having trouble with reliability using xfs under linux with a > Promise RM8000 device. Anybody else reported related problems with > this > device? We have been using xfs on scsi arrays for months with no > problems on a system configured exactly the same (as far as xfs, > redhat, > and scsi hardware). We are also having the same issue on a Mandrake9 > system with a Adaptec 2940U2W scsi card. > > Here is a sample error message: > > Feb 10 13:26:48 hostname kernel: xfs_force_shutdown(sd(8,2),0x8) called > from line 4068 of file xfs_bmap.c. Return address = 0xc018caf2 > Feb 10 13:26:48 hostname kernel: Corruption of in-memory data detected. > Shutting down filesystem: sd(8,2) > Feb 10 13:26:48 hostname kernel: Please umount the filesystem, and > rectify the problem(s) > > Here are some system details: > > % cat /proc/pci > snip--- > Bus 0, device 20, function 0: > SCSI storage controller: Adaptec AIC-7881U (rev 0). > IRQ 10. > Master Capable. Latency=64. Min Gnt=8.Max Lat=8. > I/O at 0xe800 [0xe8ff]. > Non-prefetchable 32 bit memory at 0xfebff000 [0xfebfffff]. > Bus 1, device 0, function 0: > ---snip > > $ df -k > Filesystem 1k-blocks Used Available Use% Mounted on > /dev/hda2 3612272 2329996 1098736 68% / > none 127504 0 127504 0% /dev/shm > /dev/sda2 481393216 141041656 340351560 30% /archive > > $ cat /etc/fstab > LABEL=/ / ext3 defaults > 1 1 > none /dev/pts devpts gid=5,mode=620 > 0 0 > none /proc proc defaults > 0 0 > none /dev/shm tmpfs defaults > 0 0 > /dev/sda1 swap swap defaults > 0 0 > /dev/sda2 /archive xfs defaults > 1 2 > > $ uname -a > Linux hostname 2.4.18-SGI_XFS_1.1smp #1 SMP Wed Apr 17 09:05:28 CDT > 2002 > i686 unknown > > $ dmesg > snip--- > SCSI subsystem driver Revision: 1.00 > scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.4 > > aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs > > Vendor: Promise Model: 5 Disk RAID5 Rev: 1.10 > Type: Direct-Access ANSI SCSI revision: 03 > scsi0:A:0:0: Tagged Queuing enabled. Depth 253 > Attached scsi disk sda at scsi0, channel 0, id 0, lun 0 > (scsi0:A:0): 40.000MB/s transfers (20.000MHz, offset 8, 16bit) > SCSI device sda: 965018624 512-byte hdwr sectors (494090 MB) > sda: sda1 sda2 > ---snip > > $ rpm -qa | grep -i xfs > kernel-smp-2.4.18-SGI_XFS_1.1 > xfsprogs-devel-2.0.3-0 > kernel-2.4.18-SGI_XFS_1.1 > xfsprogs-2.0.3-0 > > $ cat /proc/scsi/aic7xxx/0 > Adaptec AIC7xxx driver version: 6.2.4 > aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs > Channel A Target 0 Negotiation Settings > User: 40.000MB/s transfers (20.000MHz, offset 255, 16bit) > Goal: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) > Curr: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) > Channel A Target 0 Lun 0 Settings > Commands Queued 6085 > Commands Active 0 > Command Openings 32 > Max Tagged Openings 253 > Device Queue Frozen Count 0 > Channel A Target 1 Negotiation Settings > User: 40.000MB/s transfers (20.000MHz, offset 255, 16bit) > Channel A Target 2 Negotiation Settings > User: 40.000MB/s transfers (20.000MHz, offset 255, 16bit) > Channel A Target 3 Negotiation Settings > User: 40.000MB/s transfers (20.000MHz, offset 255, 16bit) > Channel A Target 4 Negotiation Settings > User: 40.000MB/s transfers (20.000MHz, offset 255, 16bit) > Channel A Target 5 Negotiation Settings > User: 40.000MB/s transfers (20.000MHz, offset 255, 16bit) > Channel A Target 6 Negotiation Settings > User: 40.000MB/s transfers (20.000MHz, offset 255, 16bit) > Channel A Target 7 Negotiation Settings > User: 40.000MB/s transfers (20.000MHz, offset 255, 16bit) > Channel A Target 8 Negotiation Settings > User: 40.000MB/s transfers (20.000MHz, offset 255, 16bit) > Channel A Target 9 Negotiation Settings > User: 40.000MB/s transfers (20.000MHz, offset 255, 16bit) > Channel A Target 10 Negotiation Settings > User: 40.000MB/s transfers (20.000MHz, offset 255, 16bit) > Channel A Target 11 Negotiation Settings > User: 40.000MB/s transfers (20.000MHz, offset 255, 16bit) > Channel A Target 12 Negotiation Settings > User: 40.000MB/s transfers (20.000MHz, offset 255, 16bit) > Channel A Target 13 Negotiation Settings > User: 40.000MB/s transfers (20.000MHz, offset 255, 16bit) > Channel A Target 14 Negotiation Settings > User: 40.000MB/s transfers (20.000MHz, offset 255, 16bit) > Channel A Target 15 Negotiation Settings > User: 40.000MB/s transfers (20.000MHz, offset 255, 16bit) > From owner-linux-xfs@oss.sgi.com Mon Feb 10 19:24:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Feb 2003 19:24:18 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1B3OC3v024090 for ; Mon, 10 Feb 2003 19:24:13 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1B3fKkq018762 for ; Mon, 10 Feb 2003 21:41:21 -0600 Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id h1B3VB609196; Tue, 11 Feb 2003 14:31:11 +1100 Date: Tue, 11 Feb 2003 14:31:11 +1100 From: Keith Owens Message-Id: <200302110331.h1B3VB609196@sherman.melbourne.sgi.com> Subject: TAKE - Minor kdb v3.0 fixes X-archive-position: 2603 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 372 Lines: 14 Build with kdb and CONFIG_MODULES=n. Export kdb_initial_cpu so modules can use KDB_ENTER(); Date: Mon Feb 10 19:29:18 PST 2003 Workarea: sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:139319a linux/include/linux/module.h - 1.35 linux/kdb/kdbmain.c - 1.35 From owner-linux-xfs@oss.sgi.com Mon Feb 10 23:09:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Feb 2003 23:10:03 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1B79t3v004320 for ; Mon, 10 Feb 2003 23:09:56 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1B5I6G8005152 for ; Mon, 10 Feb 2003 21:18:07 -0800 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 h1B7Gd3s6713721 for ; Tue, 11 Feb 2003 18:16:39 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h1B7GcxM6900231 for linux-xfs@oss.sgi.com; Tue, 11 Feb 2003 18:16:38 +1100 (EST) Date: Tue, 11 Feb 2003 18:16:38 +1100 (EST) From: Nathan Scott Message-Id: <200302110716.h1B7GcxM6900231@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - extra mount check X-archive-position: 2604 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@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 464 Lines: 15 Extra check on the mount path - ensure we don't attempt to mount XFS fs's with sector sizes smaller than those the device supports. Tripped a BUG in pagebuf, should now be resolved (let me know Keith -- thanks). Date: Mon Feb 10 23:15:51 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:139328a linux/fs/xfs/xfs_mount.c - 1.316 From owner-linux-xfs@oss.sgi.com Tue Feb 11 02:17:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Feb 2003 02:17:15 -0800 (PST) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1BAH83v007018 for ; Tue, 11 Feb 2003 02:17:08 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1B9WNKp028029 for ; Tue, 11 Feb 2003 01:32:24 -0800 Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id h1BAO8R30992; Tue, 11 Feb 2003 21:24:08 +1100 Date: Tue, 11 Feb 2003 21:24:08 +1100 From: Keith Owens Message-Id: <200302111024.h1BAO8R30992@sherman.melbourne.sgi.com> Subject: TAKE - XFS patches from 2.5.60-mm1 X-archive-position: 2605 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 395 Lines: 14 Andrew Morton found some warnings in the XFS code in the 2.5.60 kernel, apply his patches against 2.5.59-xfs. Date: Tue Feb 11 02:22:06 PST 2003 Workarea: sherman.melbourne.sgi.com:/build/kaos/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:139330a linux/fs/xfs/xfs_error.h - 1.29 linux/fs/xfs/support/debug.c - 1.16 From owner-linux-xfs@oss.sgi.com Tue Feb 11 02:19:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Feb 2003 02:19:07 -0800 (PST) Received: from mailhost.uni-koblenz.de (root@mailhost.uni-koblenz.de [141.26.64.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1BAJ33v007359 for ; Tue, 11 Feb 2003 02:19:05 -0800 Received: from bliss.uni-koblenz.de (bliss.uni-koblenz.de [141.26.64.65]) by mailhost.uni-koblenz.de (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id h1BAR9wN016143; Tue, 11 Feb 2003 11:27:09 +0100 Received: from localhost (localhost [127.0.0.1]) by bliss.uni-koblenz.de (8.12.6/8.12.3) with ESMTP id h1BAR8HI021510; Tue, 11 Feb 2003 11:27:08 +0100 From: Rainer Krienke Organization: Uni Koblenz To: Eric Sandeen Subject: Re: What is needed for a stable 2.4 based system? Date: Tue, 11 Feb 2003 11:27:08 +0100 User-Agent: KMail/1.5 Cc: linux-xfs@oss.sgi.com References: <200302101504.56067.krienke@uni-koblenz.de> <1044888981.21802.3.camel@stout.americas.sgi.com> In-Reply-To: <1044888981.21802.3.camel@stout.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200302111127.08514.krienke@uni-koblenz.de> X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) X-archive-position: 2606 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: krienke@uni-koblenz.de Precedence: bulk X-list: linux-xfs Content-Length: 898 Lines: 22 On Montag, 10. Februar 2003 15:56, Eric Sandeen wrote: > Rainer - > > At this time, 1.2 will be released for 2.4.19. It may be trivial to > merge the patch up to 2.4.20, but all of the testing we have done has > been on 2.4.19, so that will be our release kernel version. > Ist there a kind of filesystem stress-test software that would help to find bugs in a particular version of xfs if I should decide not to go with 2.4.19+xfs but perhaps 2.4.20+xfs? Thanks Rainer -- --------------------------------------------------------------------------- Rainer Krienke, Universitaet Koblenz, Rechenzentrum Universitaetsstrasse 1, 56070 Koblenz, Tel: +49 261287 -1312, Fax: -1001312 Mail: krienke@uni-koblenz.de, Web: http://www.uni-koblenz.de/~krienke Get my public PGP key: http://www.uni-koblenz.de/~krienke/mypgp.html --------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Tue Feb 11 07:52:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Feb 2003 07:52:31 -0800 (PST) Received: from mail.slb.com (eurmta02.montrouge.eur.slb.com [163.187.152.23]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1BFok3v016739 for ; Tue, 11 Feb 2003 07:52:28 -0800 Received: from conversion-daemon.eurmta02.montrouge.eur.slb.com by eurmta02.montrouge.eur.slb.com (iPlanet Messaging Server 5.2 HotFix 1.02 (built Sep 16 2002)) id <0HA500I01G74FC@eurmta02.montrouge.eur.slb.com> for linux-xfs@oss.sgi.com; Tue, 11 Feb 2003 15:15:26 +0000 (GMT) Received: from wgmail1.houston.nam.slb.com (wgmail1.houston.nam.slb.com [137.144.106.50]) by eurmta02.montrouge.eur.slb.com (iPlanet Messaging Server 5.2 HotFix 1.02 (built Sep 16 2002)) with ESMTP id <0HA500I7CFWCYB@eurmta02.montrouge.eur.slb.com> for linux-xfs@oss.sgi.com; Tue, 11 Feb 2003 14:50:36 +0000 (GMT) Received: from BOJAVAN1.houston.westerngeco.slb.com (localhost [127.0.0.1]) by wgmail1.houston.nam.slb.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h1BEkfk02508; Tue, 11 Feb 2003 08:46:46 -0600 (CST) Date: Tue, 11 Feb 2003 08:47:10 -0600 From: Vangel Bojaxhi Subject: XFS patch for 2.4.9-e.10.10summit X-Sender: VBojaxhi@wgmail1.houston.nam.slb.com To: linux-xfs@oss.sgi.com Cc: al Richings Message-id: <5.1.0.14.2.20030211083929.00ae8830@wgmail1.houston.nam.slb.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 2608 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: vbojaxhi@houston.westerngeco.slb.com Precedence: bulk X-list: linux-xfs Content-Length: 460 Lines: 24 To whom it may concern: I am investigating if the XFS can be implemented in a IBM i386 8 way SMP machine, running Red Hat Advanced Serever Kernel Version 2.4.9-e.10.10summit. Unfortunately the latest patch I could find in your site http://oss.sgi.com/projects/xfs/.. is the "xfs-1.1-PR2-2.4.18-all.patch.bz2" , which is for 2.4.18 kernel. Please advice. Regards / Vangel WesternGeco Houston (713)-689-2509 [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Tue Feb 11 07:52:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Feb 2003 07:52:17 -0800 (PST) Received: from ahriman.bucharest.roedu.net (ahriman.bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1BFq53v016766 for ; Tue, 11 Feb 2003 07:52:08 -0800 Received: (qmail 27021 invoked by uid 1000); 11 Feb 2003 16:21:03 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 11 Feb 2003 16:21:03 -0000 Date: Tue, 11 Feb 2003 18:21:03 +0200 (EET) From: Mihai RUSU X-X-Sender: To: Rainer Krienke cc: Linux XFS List Subject: Re: What is needed for a stable 2.4 based system? In-Reply-To: <200302111127.08514.krienke@uni-koblenz.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2607 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: dizzy@roedu.net Precedence: bulk X-list: linux-xfs Content-Length: 1437 Lines: 40 Hi Try to checkout linux-2.4-xfs CVS module and you will get the xfstests which are used for testing XFS (among other things probably). Also a very used tool to stress test FS on Linux is dbench and I also used bonnie++. On Tue, 11 Feb 2003, Rainer Krienke wrote: > On Montag, 10. Februar 2003 15:56, Eric Sandeen wrote: > > Rainer - > > > > At this time, 1.2 will be released for 2.4.19. It may be trivial to > > merge the patch up to 2.4.20, but all of the testing we have done has > > been on 2.4.19, so that will be our release kernel version. > > > > Ist there a kind of filesystem stress-test software that would help to find > bugs in a particular version of xfs if I should decide not to go with > 2.4.19+xfs but perhaps 2.4.20+xfs? > > Thanks > Rainer > -- > --------------------------------------------------------------------------- > Rainer Krienke, Universitaet Koblenz, Rechenzentrum > Universitaetsstrasse 1, 56070 Koblenz, Tel: +49 261287 -1312, Fax: -1001312 > Mail: krienke@uni-koblenz.de, Web: http://www.uni-koblenz.de/~krienke > Get my public PGP key: http://www.uni-koblenz.de/~krienke/mypgp.html > --------------------------------------------------------------------------- > > > ---------------------------- Mihai RUSU Disclaimer: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of any company, unless otherwise specifically stated. From owner-linux-xfs@oss.sgi.com Tue Feb 11 07:56:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Feb 2003 07:56:07 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1BFu03v017592 for ; Tue, 11 Feb 2003 07:56:02 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18ictD-0003oc-00; Tue, 11 Feb 2003 16:04:07 +0000 Date: Tue, 11 Feb 2003 16:04:07 +0000 From: Christoph Hellwig To: Vangel Bojaxhi Cc: linux-xfs@oss.sgi.com, al Richings Subject: Re: XFS patch for 2.4.9-e.10.10summit Message-ID: <20030211160407.A14637@infradead.org> References: <5.1.0.14.2.20030211083929.00ae8830@wgmail1.houston.nam.slb.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <5.1.0.14.2.20030211083929.00ae8830@wgmail1.houston.nam.slb.com>; from vbojaxhi@houston.westerngeco.slb.com on Tue, Feb 11, 2003 at 08:47:10AM -0600 X-archive-position: 2609 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 652 Lines: 14 On Tue, Feb 11, 2003 at 08:47:10AM -0600, Vangel Bojaxhi wrote: > To whom it may concern: > > I am investigating if the XFS can be implemented in a IBM i386 8 way SMP > machine, running Red Hat Advanced Serever Kernel > Version 2.4.9-e.10.10summit. Unfortunately the latest patch I could find > in your site http://oss.sgi.com/projects/xfs/.. is the > "xfs-1.1-PR2-2.4.18-all.patch.bz2" , which is for 2.4.18 kernel. It's basically not possible to backport the current XFS code to a pre-2.4.11 kernel, I'd suggest you use a newer kernel anyway. Anyway, where is that kernel rpm downloadable? The newest kernel on RH's ftp site is 2.4.9-10. From owner-linux-xfs@oss.sgi.com Tue Feb 11 08:03:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Feb 2003 08:03:36 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1BG3X3v018133 for ; Tue, 11 Feb 2003 08:03:33 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1BEBkG8012835 for ; Tue, 11 Feb 2003 06:11:46 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA01634 for ; Tue, 11 Feb 2003 10:11:35 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA90206 for ; Tue, 11 Feb 2003 10:11:34 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h1BNRlu06189 for linux-xfs@oss.sgi.com; Tue, 11 Feb 2003 18:27:47 -0500 Resent-Message-Id: <200302112327.h1BNRlu06189@taclab54.munich.sgi.com> Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA32274 for ; Tue, 11 Feb 2003 10:08:59 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h1BNPBs06173 for hch@sgi.com; Tue, 11 Feb 2003 18:25:11 -0500 Date: Tue, 11 Feb 2003 18:25:11 -0500 From: Christoph Hellwig Message-Id: <200302112325.h1BNPBs06173@taclab54.munich.sgi.com> Subject: TAKE - missing includes Resent-From: hch@sgi.com Resent-Date: Tue, 11 Feb 2003 18:27:47 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 2610 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 441 Lines: 15 On i386 many kernel headers are included implicitly, on some other architectures not. Add missing includes to fs/xfs/support/move.c Date: Tue Feb 11 08:07:35 PST 2003 Workarea: taclab54.munich.sgi.com:/home/hch/repo/slinx/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:139338a linux/fs/xfs/support/move.c - 1.10 - Include and From owner-linux-xfs@oss.sgi.com Tue Feb 11 08:14:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Feb 2003 08:14:32 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1BGER3v018648 for ; Tue, 11 Feb 2003 08:14:29 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1BEMfG8013834 for ; Tue, 11 Feb 2003 06:22:41 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA30430 for ; Tue, 11 Feb 2003 10:22:29 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA91014 for ; Tue, 11 Feb 2003 10:22:28 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h1BNceX06602 for linux-xfs@oss.sgi.com; Tue, 11 Feb 2003 18:38:40 -0500 Resent-Message-Id: <200302112338.h1BNceX06602@taclab54.munich.sgi.com> Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA54903 for ; Tue, 11 Feb 2003 10:20:05 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h1BNaI606500 for hch@sgi.com; Tue, 11 Feb 2003 18:36:18 -0500 Date: Tue, 11 Feb 2003 18:36:18 -0500 From: Christoph Hellwig Message-Id: <200302112336.h1BNaI606500@taclab54.munich.sgi.com> Subject: TAKE - fix a comment typo Resent-From: hch@sgi.com Resent-Date: Tue, 11 Feb 2003 18:38:40 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 2611 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 346 Lines: 14 Contrinuted fix from elenstev@mesatop.com, fix a comment typo. Date: Tue Feb 11 08:19:00 PST 2003 Workarea: taclab54.munich.sgi.com:/home/hch/repo/slinx/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:139343a linux/fs/xfs/xfs_bmap.c - 1.298 - spell separately right From owner-linux-xfs@oss.sgi.com Tue Feb 11 08:27:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Feb 2003 08:27:51 -0800 (PST) Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1BGRh3v032552 for ; Tue, 11 Feb 2003 08:27:44 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-163-13.quicknet.nl [212.58.163.13]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id h1BGZP8V068611; Tue, 11 Feb 2003 17:35:26 +0100 (CET) Message-Id: <4.3.2.7.2.20030211173109.03020a28@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 11 Feb 2003 17:35:24 +0100 To: Christoph Hellwig , Vangel Bojaxhi From: Seth Mos Subject: Re: XFS patch for 2.4.9-e.10.10summit Cc: linux-xfs@oss.sgi.com, al Richings In-Reply-To: <20030211160407.A14637@infradead.org> References: <5.1.0.14.2.20030211083929.00ae8830@wgmail1.houston.nam.slb.com> <5.1.0.14.2.20030211083929.00ae8830@wgmail1.houston.nam.slb.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2612 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: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 1168 Lines: 31 At 16:04 11-2-2003 +0000, Christoph Hellwig wrote: >On Tue, Feb 11, 2003 at 08:47:10AM -0600, Vangel Bojaxhi wrote: > > To whom it may concern: > > > > I am investigating if the XFS can be implemented in a IBM i386 8 way SMP > > machine, running Red Hat Advanced Serever Kernel > > Version 2.4.9-e.10.10summit. Unfortunately the latest patch I could find > > in your site http://oss.sgi.com/projects/xfs/.. is the > > "xfs-1.1-PR2-2.4.18-all.patch.bz2" , which is for 2.4.18 kernel. > >It's basically not possible to backport the current XFS code to a pre-2.4.11 >kernel, I'd suggest you use a newer kernel anyway. Anyway, where is >that kernel rpm downloadable? The newest kernel on RH's ftp site >is 2.4.9-10. The Advanced server product still uses a 2.4.9 based kernel which is heavily modified. I don't think it is worth the trouble to make it patch and work. The sources for AS are available on the ftp site somewhere IIRC but you have to pay $800 anually for the product itself. So I am afraid that XFS in RHAS is a no-go and it would also void any support that you just paid for. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Tue Feb 11 08:41:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Feb 2003 08:41:19 -0800 (PST) Received: from mail.aem.umn.edu (mail.aem.umn.edu [128.101.142.239]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1BGfF3v016641 for ; Tue, 11 Feb 2003 08:41:16 -0800 Received: from lightning.aem.umn.edu (lightning.aem.umn.edu [128.101.143.49]) by mail.aem.umn.edu (8.11.3/8.11.3) with ESMTP id h1BGlmO71560; Tue, 11 Feb 2003 10:47:48 -0600 (CST) (envelope-from muno@aem.umn.edu) Received: (from muno@localhost) by lightning.aem.umn.edu (8.11.6/8.9.1) id h1BGlnA27197; Tue, 11 Feb 2003 10:47:49 -0600 Date: Tue, 11 Feb 2003 10:47:49 -0600 From: Ray Muno To: Seth Mos Cc: Christoph Hellwig , Vangel Bojaxhi , linux-xfs@oss.sgi.com, al Richings Subject: Re: XFS patch for 2.4.9-e.10.10summit Message-ID: <20030211164747.GA26434@aem.umn.edu> References: <5.1.0.14.2.20030211083929.00ae8830@wgmail1.houston.nam.slb.com> <5.1.0.14.2.20030211083929.00ae8830@wgmail1.houston.nam.slb.com> <4.3.2.7.2.20030211173109.03020a28@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20030211173109.03020a28@pop.xs4all.nl> User-Agent: Mutt/1.5.1i X-archive-position: 2613 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: muno@aem.umn.edu Precedence: bulk X-list: linux-xfs Content-Length: 1919 Lines: 48 I went to a presentation by SGI about their new Altix Itanium Linux machines. They claimed that they are running Red Hat Advanced Server with XFS. On Tue, Feb 11, 2003 at 05:35:24PM +0100, Seth Mos wrote: > At 16:04 11-2-2003 +0000, Christoph Hellwig wrote: > >On Tue, Feb 11, 2003 at 08:47:10AM -0600, Vangel Bojaxhi wrote: > >> To whom it may concern: > >> > >> I am investigating if the XFS can be implemented in a IBM i386 8 way SMP > >> machine, running Red Hat Advanced Serever Kernel > >> Version 2.4.9-e.10.10summit. Unfortunately the latest patch I could find > >> in your site http://oss.sgi.com/projects/xfs/.. is the > >> "xfs-1.1-PR2-2.4.18-all.patch.bz2" , which is for 2.4.18 kernel. > > > >It's basically not possible to backport the current XFS code to a > >pre-2.4.11 > >kernel, I'd suggest you use a newer kernel anyway. Anyway, where is > >that kernel rpm downloadable? The newest kernel on RH's ftp site > >is 2.4.9-10. > > The Advanced server product still uses a 2.4.9 based kernel which is > heavily modified. I don't think it is worth the trouble to make it patch > and work. > > The sources for AS are available on the ftp site somewhere IIRC but you > have to pay $800 anually for the product itself. > > So I am afraid that XFS in RHAS is a no-go and it would also void any > support that you just paid for. > > Cheers > > -- > Seth > It might just be your lucky day, if you only knew. > ============================================================================= Ray Muno http://www.aem.umn.edu/people/staff/muno University of Minnesota e-mail: muno@aem.umn.edu Aerospace Engineering and Mechanics Phone: (612) 625-9531 110 Union St. S.E. FAX: (612) 626-1558 Minneapolis, Mn 55455 ============================================================================= From owner-linux-xfs@oss.sgi.com Tue Feb 11 08:44:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Feb 2003 08:44:21 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1BGiJ3v018476 for ; Tue, 11 Feb 2003 08:44:19 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1BGiJ2x018475 for linux-xfs@oss.sgi.com; Tue, 11 Feb 2003 08:44:19 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1BGiH3x018460 for ; Tue, 11 Feb 2003 08:44:17 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1BGZf2e016602; Tue, 11 Feb 2003 08:35:41 -0800 Date: Tue, 11 Feb 2003 08:35:41 -0800 Message-Id: <200302111635.h1BGZf2e016602@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 209] Kernel 2.4.20-xfs memory leaks X-Bugzilla-Reason: AssignedTo X-archive-position: 2614 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 474 Lines: 17 http://oss.sgi.com/bugzilla/show_bug.cgi?id=209 ------- Additional Comments From gale@dstl.gov.uk 2003-02-11 08:35 ------- Sounds to me like the memory isn't being lost but being used as cache. When you say your server needs to be rebooted daily, what happens if you don't reboot it? output of some entries of 'vmstat 1' would help clear this up ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Feb 11 08:44:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Feb 2003 08:44:22 -0800 (PST) Received: from phoenix.infradead.org (carisma.slowglass.com [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1BGiJ3v018473 for ; Tue, 11 Feb 2003 08:44:20 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18iddx-00045t-00; Tue, 11 Feb 2003 16:52:25 +0000 Date: Tue, 11 Feb 2003 16:52:25 +0000 From: Christoph Hellwig To: Ray Muno Cc: Seth Mos , Christoph Hellwig , Vangel Bojaxhi , linux-xfs@oss.sgi.com, al Richings Subject: Re: XFS patch for 2.4.9-e.10.10summit Message-ID: <20030211165225.A15730@infradead.org> References: <5.1.0.14.2.20030211083929.00ae8830@wgmail1.houston.nam.slb.com> <5.1.0.14.2.20030211083929.00ae8830@wgmail1.houston.nam.slb.com> <4.3.2.7.2.20030211173109.03020a28@pop.xs4all.nl> <20030211164747.GA26434@aem.umn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030211164747.GA26434@aem.umn.edu>; from muno@aem.umn.edu on Tue, Feb 11, 2003 at 10:47:49AM -0600 X-archive-position: 2615 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 409 Lines: 10 On Tue, Feb 11, 2003 at 10:47:49AM -0600, Ray Muno wrote: > I went to a presentation by SGI about their new Altix Itanium Linux > machines. They claimed that they are running Red Hat Advanced Server > with XFS. That's wrong. Do you now the name of that marketing person? p.s. and even if it was running RH AS, the IA64 version of RH AS is based on linux 2.4.18 which makes patching in XFS a lot easier. From owner-linux-xfs@oss.sgi.com Tue Feb 11 10:12:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Feb 2003 10:12:30 -0800 (PST) Received: from exchange.ccur.com (mail.ccur.com [208.248.32.212]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1BICQ3v024132 for ; Tue, 11 Feb 2003 10:12:28 -0800 Received: by exchange.ccur.com with Internet Mail Service (5.5.2653.19) id <1J840APW>; Tue, 11 Feb 2003 13:20:30 -0500 Message-ID: From: "Miro, Felix" To: "'linux-xfs@oss.sgi.com'" Subject: pagebuf problems Date: Tue, 11 Feb 2003 13:20:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 2616 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: felix.miro@ccur.com Precedence: bulk X-list: linux-xfs Content-Length: 353 Lines: 16 I haven't had any luck getting the 2.4.21pre4 patch you sent to work. The system won't boot. I get bad EIP. The problem appears to be related to pagebuf. What little trace info I have shows: ksoftirqd timer_bh pagebuf_daemon_wakeup timer_softirq __do_softirq ksoftirqd If I configure XFS out of the build the system boots fine. Regards, Felix From owner-linux-xfs@oss.sgi.com Tue Feb 11 10:23:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Feb 2003 10:23:47 -0800 (PST) Received: from mercury.drw.net (mercury.drw.net [66.48.89.4]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1BINh3v024633 for ; Tue, 11 Feb 2003 10:23:44 -0800 Received: from debian01 (adsl-63-193-189-58.dsl.bkfd14.pacbell.net [63.193.189.58]) by mercury.drw.net (8.11.6/8.11.6) with SMTP id h1BIY7A23492 for ; Tue, 11 Feb 2003 13:34:08 -0500 Date: Tue, 11 Feb 2003 10:32:24 -0800 From: George App To: linux-xfs@oss.sgi.com Subject: Support for XFS File systems Message-Id: <20030211103224.3d2786d7.george@georgeapp.com> X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2617 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: george@georgeapp.com Precedence: bulk X-list: linux-xfs Content-Length: 171 Lines: 8 I have been using the XFS file system for some time now. I am very happy with it. Are there any tools available for defraging the XFS file system? Thanks, George App From owner-linux-xfs@oss.sgi.com Tue Feb 11 10:31:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Feb 2003 10:31:28 -0800 (PST) Received: from ncbdc.bbs.com ([208.0.185.14]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1BIVO3v025099 for ; Tue, 11 Feb 2003 10:31:25 -0800 Received: by NCBDC with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Feb 2003 10:39:31 -0800 Message-ID: <057889C7F1E5D61193620002A537E869467EE2@NCBDC> From: Marc Kaplan To: "'George App'" , linux-xfs@oss.sgi.com Subject: RE: Support for XFS File systems Date: Tue, 11 Feb 2003 10:39:30 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 2618 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: MKaplan@snapappliance.com Precedence: bulk X-list: linux-xfs Content-Length: 419 Lines: 20 Yea, you can use xfs_fsr to defragment the file system -Marc -----Original Message----- From: George App [mailto:george@georgeapp.com] Sent: Tuesday, February 11, 2003 10:32 AM To: linux-xfs@oss.sgi.com Subject: Support for XFS File systems I have been using the XFS file system for some time now. I am very happy with it. Are there any tools available for defraging the XFS file system? Thanks, George App From owner-linux-xfs@oss.sgi.com Tue Feb 11 11:42:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Feb 2003 11:42:07 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1BJfw3v026006 for ; Tue, 11 Feb 2003 11:41:58 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1BHoCG8010302 for ; Tue, 11 Feb 2003 09:50:12 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA50653; Tue, 11 Feb 2003 13:50:00 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id NAA52913; Tue, 11 Feb 2003 13:49:59 -0600 (CST) Subject: Re: What is needed for a stable 2.4 based system? From: Eric Sandeen To: Jan-Frode Myklebust Cc: Rainer Krienke , linux-xfs@oss.sgi.com In-Reply-To: <20030211201605.A16099@ii.uib.no> References: <200302101000.22190.krienke@uni-koblenz.de> <20030211201605.A16099@ii.uib.no> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 11 Feb 2003 13:49:47 -0600 Message-Id: <1044992988.9274.3.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 2619 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 762 Lines: 22 On Tue, 2003-02-11 at 13:16, Jan-Frode Myklebust wrote: > Is it really that bad? I'm in the process of setting up a server with > ~2.5 TB of XFS storage, and was just about to go for the linux-2.4-xfs > cvs-tree. I'm not saying it's bad! I'm also not saying it's good. I'm saying that CVS snapshots are just that; and that they have not been rigorously tested by anyone at SGI. > I've had the impression that the cvs-tree was purely a bugfix only > tree, and that it should be as safe as the kernel.org tree. Is that not true? the cvs tree is a development tree, warts and all. It usually -is- pretty good, but no guarantees. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Tue Feb 11 11:55:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Feb 2003 11:55:27 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1BJtG3v026603 for ; Tue, 11 Feb 2003 11:55:17 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1BI3UG8011765 for ; Tue, 11 Feb 2003 10:03:31 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA82548 for ; Tue, 11 Feb 2003 14:03:19 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA60225 for ; Tue, 11 Feb 2003 14:03:17 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h1C3JTA07698 for linux-xfs@oss.sgi.com; Tue, 11 Feb 2003 22:19:29 -0500 Resent-Message-Id: <200302120319.h1C3JTA07698@taclab54.munich.sgi.com> Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA25668 for ; Tue, 11 Feb 2003 13:59:05 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id h1BJx2Zu8376930 for ; Tue, 11 Feb 2003 11:59:03 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id h1BJuKg3020766 for ; Tue, 11 Feb 2003 20:56:20 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id h1BJuKax020765 for hch@sgi.com; Tue, 11 Feb 2003 20:56:20 +0100 Date: Tue, 11 Feb 2003 20:56:20 +0100 From: Christoph Hellwig Message-Id: <200302111956.h1BJuKax020765@lab343.munich.sgi.com> Subject: TAKE - Merge up to 2.5.60 To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Tue, 11 Feb 2003 22:19:29 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 2620 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 62744 Lines: 1646 Passed the testsuite and stress testing fine, but I had one unreproducible oops in driver code, so handle it with care. Date: Tue Feb 11 11:51:18 PST 2003 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:139388a linux/arch/um/vmlinux.lds.S - 1.1 linux/arch/arm/common/Makefile - 1.1 linux/include/asm-arm/arch-sa1100/mftb2.h - 1.1 linux/include/asm-arm/arch-sa1100/trizeps.h - 1.1 linux/include/asm-um/common.lds.S - 1.1 linux/arch/um/sys-i386/extable.c - 1.1 linux/drivers/pci/pci-sysfs.c - 1.1 linux/drivers/usb/net/Makefile.mii - 1.1 linux/Documentation/ia64/fsys.txt - 1.1 linux/drivers/char/hangcheck-timer.c - 1.1 linux/mm/fadvise.c - 1.1 linux/arch/um/include/uml_uaccess.h - 1.1 linux/include/acpi/processor.h - 1.1 linux/include/acpi/platform/aclinux.h - 1.1 linux/include/acpi/platform/acgcc.h - 1.1 linux/arch/ia64/scripts/check-gas - 1.1 linux/include/asm-um/bug.h - 1.1 linux/arch/ia64/scripts/check-gas-asm.S - 1.1 linux/arch/um/include/skas_ptrace.h - 1.1 linux/arch/um/kernel/tt/unmap.c - 1.1 linux/include/acpi/acconfig.h - 1.1 linux/include/asm-um/ucontext.h - 1.1 linux/include/asm-x86_64/dma-mapping.h - 1.1 linux/include/acpi/acdebug.h - 1.1 linux/include/acpi/acdispat.h - 1.1 linux/Documentation/sound/alsa/DocBook/alsa-driver-api.tmpl - 1.1 linux/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl - 1.1 linux/Documentation/sound/alsa/OSS-Emulation.txt - 1.1 linux/arch/ia64/scripts/unwcheck.sh - 1.1 linux/include/acpi/platform/acenv.h - 1.1 linux/arch/arm/mach-sa1100/trizeps.c - 1.1 linux/include/acpi/amlcode.h - 1.1 linux/arch/i386/kernel/cpu/cpufreq/acpi.c - 1.1 linux/include/acpi/acutils.h - 1.1 linux/include/acpi/actypes.h - 1.1 linux/arch/um/Makefile-skas - 1.1 linux/include/acpi/actbl71.h - 1.1 linux/include/acpi/actbl2.h - 1.1 linux/include/acpi/actbl1.h - 1.1 linux/arch/um/dyn.lds.S - 1.1 linux/arch/um/Makefile-tt - 1.1 linux/include/acpi/actbl.h - 1.1 linux/include/acpi/actables.h - 1.1 linux/include/acpi/acstruct.h - 1.1 linux/include/acpi/acresrc.h - 1.1 linux/include/acpi/acpixf.h - 1.1 linux/include/acpi/acpiosxf.h - 1.1 linux/include/acpi/acpi_drivers.h - 1.1 linux/include/acpi/acpi_bus.h - 1.1 linux/arch/ia64/kernel/fsys.S - 1.1 linux/arch/alpha/kernel/srmcons.c - 1.1 linux/include/linux/fadvise.h - 1.1 linux/include/acpi/acpi.h - 1.1 linux/arch/arm/mach-sa1100/leds-hackkit.c - 1.1 linux/include/acpi/acparser.h - 1.1 linux/arch/arm/mach-sa1100/hackkit.c - 1.1 linux/include/linux/seqlock.h - 1.1 linux/arch/arm/common/plx90x0.c - 1.1 linux/arch/arm/common/sa1111-pcibuf.c - 1.1 linux/arch/arm/common/sa1111-pcipool.c - 1.1 linux/arch/arm/common/sa1111.c - 1.1 linux/arch/arm/common/via82c505.c - 1.1 linux/arch/arm/def-configs/hackkit - 1.1 linux/arch/arm/def-configs/trizeps - 1.1 linux/include/acpi/acoutput.h - 1.1 linux/include/acpi/acobject.h - 1.1 linux/include/acpi/acnamesp.h - 1.1 linux/include/acpi/acmacros.h - 1.1 linux/include/acpi/aclocal.h - 1.1 linux/include/acpi/acevents.h - 1.1 linux/include/acpi/acinterp.h - 1.1 linux/arch/um/kernel/tt/mem_user.c - 1.1 linux/include/acpi/acexcep.h - 1.1 linux/include/acpi/acglobal.h - 1.1 linux/include/acpi/achware.h - 1.1 linux/scripts/ver_linux - 1.12 linux/net/wanrouter/Makefile - 1.8 linux/net/unix/af_unix.c - 1.52 linux/net/sunrpc/svc.c - 1.21 linux/net/sunrpc/sched.c - 1.35 linux/net/sunrpc/clnt.c - 1.27 linux/net/sunrpc/Makefile - 1.11 linux/net/socket.c - 1.50 linux/net/netsyms.c - 1.59 linux/net/netlink/af_netlink.c - 1.24 linux/net/lapb/Makefile - 1.7 linux/net/irda/irlmp.c - 1.23 linux/net/irda/iriap.c - 1.20 linux/net/irda/ircomm/Makefile - 1.11 linux/net/irda/Makefile - 1.13 linux/net/ipv6/tcp_ipv6.c - 1.45 linux/net/ipv6/route.c - 1.27 linux/net/ipv6/Makefile - 1.10 linux/net/ipv4/tcp_output.c - 1.34 linux/net/ipv4/tcp_ipv4.c - 1.58 linux/net/ipv4/sysctl_net_ipv4.c - 1.16 linux/net/ipv4/route.c - 1.43 linux/net/ipv4/ip_output.c - 1.42 linux/net/ipv4/fib_hash.c - 1.11 linux/net/ipv4/devinet.c - 1.20 linux/net/core/rtnetlink.c - 1.14 linux/net/bridge/br.c - 1.26 linux/net/bridge/Makefile - 1.9 linux/net/ax25/Makefile - 1.8 linux/net/appletalk/Makefile - 1.9 linux/net/Makefile - 1.30 linux/net/802/Makefile - 1.12 linux/mm/vmscan.c - 1.123 linux/mm/slab.c - 1.49 linux/mm/page_alloc.c - 1.104 linux/mm/mremap.c - 1.41 linux/mm/mmap.c - 1.70 linux/mm/memory.c - 1.100 linux/mm/filemap.c - 1.147 linux/mm/Makefile - 1.23 linux/lib/Makefile - 1.18 linux/kernel/time.c - 1.14 linux/kernel/sys.c - 1.46 linux/kernel/signal.c - 1.48 linux/kernel/sched.c - 1.93 linux/kernel/printk.c - 1.29 linux/kernel/module.c - 1.37 linux/kernel/ksyms.c - 1.180 linux/kernel/kmod.c - 1.28 linux/kernel/fork.c - 1.82 linux/kernel/exit.c - 1.63 linux/kernel/acct.c - 1.24 linux/kernel/Makefile - 1.42 linux/include/scsi/scsi.h - 1.10 linux/include/net/tcp.h - 1.41 linux/include/net/sock.h - 1.42 linux/include/net/ip.h - 1.23 linux/include/linux/types.h - 1.12 linux/include/linux/times.h - 1.4 linux/include/linux/time.h - 1.10 linux/include/linux/sysctl.h - 1.69 linux/include/linux/slab.h - 1.28 linux/include/linux/signal.h - 1.11 linux/include/linux/sdla_x25.h - 1.4 linux/include/linux/sched.h - 1.97 linux/include/linux/quota.h - 1.23 linux/include/linux/ptrace.h - 1.6 linux/include/linux/pci.h - 1.71 linux/include/linux/module.h - 1.43 linux/include/linux/mm.h - 1.113 linux/include/linux/isdnif.h - 1.18 linux/include/linux/fs.h - 1.204 linux/include/linux/elf.h - 1.22 linux/include/linux/blkdev.h - 1.80 linux/include/linux/apm_bios.h - 1.13 linux/include/asm-sparc64/unistd.h - 1.30 linux/include/asm-sparc64/signal.h - 1.7 linux/include/asm-sparc64/mman.h - 1.6 linux/include/asm-sparc64/ide.h - 1.19 linux/include/asm-sparc64/elf.h - 1.17 linux/include/asm-sparc64/delay.h - 1.10 linux/include/asm-sparc/smp.h - 1.12 linux/include/asm-sparc/signal.h - 1.5 linux/include/asm-sparc/mman.h - 1.6 linux/include/asm-sparc/delay.h - 1.4 linux/include/asm-ppc/system.h - 1.27 linux/include/asm-ppc/signal.h - 1.8 linux/include/asm-ppc/io.h - 1.21 linux/include/asm-mips/signal.h - 1.6 linux/include/asm-m68k/signal.h - 1.6 linux/include/asm-m68k/mac_psc.h - 1.5 linux/include/asm-i386/unistd.h - 1.34 linux/include/asm-i386/signal.h - 1.8 linux/include/asm-i386/pgtable.h - 1.41 linux/include/asm-arm/signal.h - 1.7 linux/include/asm-arm/proc-armv/processor.h - 1.12 linux/include/asm-arm/io.h - 1.25 linux/include/asm-arm/ecard.h - 1.7 linux/include/asm-arm/arch-rpc/io.h - 1.10 linux/include/asm-arm/arch-rpc/hardware.h - 1.10 linux/include/asm-arm/arch-ebsa110/time.h - 1.11 linux/include/asm-arm/arch-ebsa110/param.h - 1.5 linux/include/asm-alpha/signal.h - 1.6 linux/include/asm-alpha/pci.h - 1.17 linux/include/asm-alpha/elf.h - 1.7 linux/fs/vfat/Makefile - 1.6 linux/fs/super.c - 1.96 linux/fs/stat.c - 1.31 linux/fs/read_write.c - 1.32 linux/fs/proc/array.c - 1.56 linux/fs/proc/Makefile - 1.14 linux/fs/nls/Makefile - 1.12 linux/fs/nfsd/nfssvc.c - 1.30 linux/fs/nfs/write.c - 1.49 linux/fs/nfs/read.c - 1.40 linux/fs/nfs/mount_clnt.c - 1.11 linux/fs/ncpfs/sock.c - 1.17 linux/fs/namei.c - 1.65 linux/fs/msdos/Makefile - 1.6 linux/fs/lockd/svc.c - 1.24 linux/fs/lockd/clntproc.c - 1.19 linux/fs/lockd/Makefile - 1.7 linux/fs/ioctl.c - 1.18 linux/fs/inode.c - 1.90 linux/fs/fat/Makefile - 1.9 linux/fs/ext2/super.c - 1.42 linux/fs/ext2/inode.c - 1.64 linux/fs/ext2/balloc.c - 1.26 linux/fs/ext2/Makefile - 1.9 linux/fs/exec.c - 1.77 linux/fs/dquot.c - 1.66 linux/fs/dcache.c - 1.45 linux/fs/buffer.c - 1.146 linux/fs/binfmt_elf.c - 1.51 linux/fs/autofs/waitq.c - 1.8 linux/fs/Makefile - 1.76 linux/drivers/zorro/Makefile - 1.14 linux/drivers/video/vesafb.c - 1.27 linux/drivers/video/skeletonfb.c - 1.16 linux/drivers/video/acornfb.c - 1.29 linux/drivers/video/Makefile - 1.50 linux/drivers/sgi/char/Makefile - 1.8 linux/drivers/scsi/u14-34f.c - 1.29 linux/drivers/scsi/tmscsim.c - 1.21 linux/drivers/scsi/sym53c8xx.c - 1.39 linux/drivers/scsi/sr_ioctl.c - 1.33 linux/drivers/scsi/sg.c - 1.48 linux/drivers/scsi/scsiiom.c - 1.6 linux/drivers/scsi/scsi_syms.c - 1.27 linux/drivers/scsi/scsi_proc.c - 1.14 linux/drivers/scsi/scsi_error.c - 1.38 linux/drivers/scsi/scsi_debug.c - 1.30 linux/drivers/scsi/scsi.h - 1.43 linux/drivers/scsi/scsi.c - 1.69 linux/drivers/scsi/qlogicpti.c - 1.25 linux/drivers/scsi/qlogicisp.c - 1.32 linux/drivers/scsi/qlogicfc.c - 1.33 linux/drivers/scsi/qlogicfas.c - 1.20 linux/drivers/scsi/pluto.c - 1.18 linux/drivers/scsi/pci2220i.c - 1.27 linux/drivers/scsi/pci2000.h - 1.10 linux/drivers/scsi/pci2000.c - 1.24 linux/drivers/scsi/ncr53c8xx.c - 1.31 linux/drivers/scsi/megaraid.c - 1.42 linux/drivers/scsi/inia100.c - 1.25 linux/drivers/scsi/ini9100u.c - 1.22 linux/drivers/scsi/in2000.c - 1.16 linux/drivers/scsi/ide-scsi.c - 1.52 linux/drivers/scsi/hosts.h - 1.35 linux/drivers/scsi/hosts.c - 1.40 linux/drivers/scsi/gdth_proc.c - 1.15 linux/drivers/scsi/gdth.c - 1.25 linux/drivers/scsi/g_NCR5380.c - 1.20 linux/drivers/scsi/fdomain.c - 1.27 linux/drivers/scsi/fcal.c - 1.14 linux/drivers/scsi/esp.c - 1.31 linux/drivers/scsi/eata_pio.c - 1.19 linux/drivers/scsi/eata_generic.h - 1.5 linux/drivers/scsi/eata_dma.c - 1.21 linux/drivers/scsi/eata.c - 1.32 linux/drivers/scsi/constants.c - 1.15 linux/drivers/scsi/atp870u.c - 1.25 linux/drivers/scsi/aic7xxx/aic7xxx.seq - 1.13 linux/drivers/scsi/advansys.c - 1.32 linux/drivers/scsi/NCR5380.c - 1.17 linux/drivers/scsi/Makefile - 1.48 linux/drivers/scsi/BusLogic.c - 1.22 linux/drivers/scsi/AM53C974.c - 1.17 linux/drivers/scsi/53c7,8xx.scr - 1.3 linux/drivers/scsi/53c7,8xx.h - 1.8 linux/drivers/scsi/53c7,8xx.c - 1.23 linux/drivers/sbus/char/Makefile - 1.16 linux/drivers/pnp/Makefile - 1.18 linux/drivers/pci/proc.c - 1.33 linux/drivers/pci/Makefile - 1.29 linux/drivers/nubus/Makefile - 1.7 linux/drivers/net/sgiseeq.c - 1.20 linux/drivers/net/rrunner.c - 1.24 linux/drivers/net/irda/irport.c - 1.27 linux/drivers/net/irda/Makefile - 1.23 linux/drivers/net/hamradio/scc.c - 1.29 linux/drivers/net/hamradio/Makefile - 1.12 linux/drivers/net/hamradio/6pack.c - 1.16 linux/drivers/net/acenic.c - 1.43 linux/drivers/net/Space.c - 1.40 linux/drivers/net/Makefile - 1.67 linux/drivers/net/3c509.c - 1.41 linux/drivers/macintosh/adb.c - 1.22 linux/drivers/macintosh/Makefile - 1.18 linux/drivers/isdn/hisax/l3dss1.c - 1.18 linux/drivers/isdn/hisax/isdnl2.c - 1.18 linux/drivers/isdn/hisax/Makefile - 1.25 linux/drivers/fc4/fc.c - 1.15 linux/drivers/fc4/Makefile - 1.10 linux/drivers/char/tty_io.c - 1.61 linux/drivers/char/synclink.c - 1.33 linux/drivers/char/rtc.c - 1.36 linux/drivers/char/nvram.c - 1.26 linux/drivers/char/n_tty.c - 1.17 linux/drivers/char/n_hdlc.c - 1.18 linux/drivers/char/keyboard.c - 1.32 linux/drivers/char/ftape/zftape/zftape-init.c - 1.17 linux/drivers/char/ftape/zftape/Makefile - 1.6 linux/drivers/char/ftape/lowlevel/ftape-init.c - 1.7 linux/drivers/char/ftape/lowlevel/fdc-io.c - 1.9 linux/drivers/char/ftape/lowlevel/Makefile - 1.8 linux/drivers/char/ftape/compressor/zftape-compress.c - 1.9 linux/drivers/char/Makefile - 1.81 linux/drivers/cdrom/Makefile - 1.8 linux/drivers/block/paride/Makefile - 1.12 linux/drivers/block/nbd.c - 1.50 linux/drivers/block/loop.c - 1.77 linux/drivers/block/ll_rw_blk.c - 1.126 linux/drivers/block/floppy.c - 1.61 linux/drivers/block/Makefile - 1.32 linux/drivers/acorn/scsi/powertec.c - 1.21 linux/drivers/acorn/scsi/oak.c - 1.15 linux/drivers/acorn/scsi/fas216.h - 1.8 linux/drivers/acorn/scsi/fas216.c - 1.17 linux/drivers/acorn/scsi/eesox.c - 1.21 linux/drivers/acorn/scsi/cumana_2.c - 1.21 linux/drivers/acorn/scsi/cumana_1.c - 1.14 linux/drivers/acorn/scsi/acornscsi.c - 1.23 linux/drivers/acorn/scsi/Makefile - 1.11 linux/arch/sparc64/solaris/signal.c - 1.7 linux/arch/sparc64/math-emu/math.c - 1.10 linux/arch/sparc64/kernel/winfixup.S - 1.7 linux/arch/sparc64/kernel/time.c - 1.28 linux/arch/sparc64/kernel/systbls.S - 1.39 linux/arch/sparc64/kernel/sys_sunos32.c - 1.43 linux/arch/sparc64/kernel/sys_sparc32.c - 1.68 linux/arch/sparc64/kernel/signal32.c - 1.32 linux/arch/sparc64/kernel/signal.c - 1.30 linux/arch/sparc64/kernel/Makefile - 1.29 linux/arch/sparc64/Makefile - 1.27 linux/arch/sparc/mm/sun4c.c - 1.41 linux/arch/sparc/math-emu/math.c - 1.5 linux/arch/sparc/kernel/time.c - 1.23 linux/arch/sparc/kernel/sys_sunos.c - 1.40 linux/arch/sparc/kernel/sys_sparc.c - 1.17 linux/arch/sparc/kernel/sparc_ksyms.c - 1.35 linux/arch/sparc/kernel/signal.c - 1.33 linux/arch/sparc/kernel/pcic.c - 1.26 linux/arch/sparc/kernel/entry.S - 1.17 linux/arch/sparc/kernel/Makefile - 1.22 linux/arch/sparc/Makefile - 1.23 linux/arch/ppc/lib/Makefile - 1.14 linux/arch/ppc/kernel/time.c - 1.24 linux/arch/ppc/kernel/signal.c - 1.22 linux/arch/ppc/kernel/pci.c - 1.32 linux/arch/ppc/kernel/Makefile - 1.37 linux/arch/ppc/amiga/Makefile - 1.12 linux/arch/ppc/Makefile - 1.37 linux/arch/ppc/8xx_io/Makefile - 1.12 linux/arch/mips/mm/Makefile - 1.10 linux/arch/mips/kernel/time.c - 1.15 linux/arch/mips/kernel/sysirix.c - 1.21 linux/arch/mips/kernel/Makefile - 1.14 linux/arch/mips/Makefile - 1.16 linux/arch/m68k/sun3x/Makefile - 1.8 linux/arch/m68k/mvme16x/Makefile - 1.7 linux/arch/m68k/mac/macints.c - 1.12 linux/arch/m68k/mac/Makefile - 1.8 linux/arch/m68k/kernel/time.c - 1.8 linux/arch/m68k/kernel/Makefile - 1.14 linux/arch/m68k/atari/Makefile - 1.9 linux/arch/m68k/amiga/Makefile - 1.6 linux/arch/m68k/Makefile - 1.13 linux/arch/i386/mm/init.c - 1.52 linux/arch/i386/mm/Makefile - 1.13 linux/arch/i386/kernel/vm86.c - 1.24 linux/arch/i386/kernel/traps.c - 1.71 linux/arch/i386/kernel/time.c - 1.34 linux/arch/i386/kernel/signal.c - 1.33 linux/arch/i386/kernel/setup.c - 1.87 linux/arch/i386/kernel/process.c - 1.65 linux/arch/i386/kernel/irq.c - 1.53 linux/arch/i386/kernel/io_apic.c - 1.52 linux/arch/i386/kernel/init_task.c - 1.11 linux/arch/i386/kernel/i386_ksyms.c - 1.65 linux/arch/i386/kernel/entry.S - 1.73 linux/arch/i386/kernel/apm.c - 1.57 linux/arch/i386/kernel/Makefile - 1.43 linux/arch/i386/Makefile - 1.46 linux/arch/arm/mm/Makefile - 1.24 linux/arch/arm/kernel/traps.c - 1.33 linux/arch/arm/kernel/time.c - 1.22 linux/arch/arm/kernel/signal.c - 1.29 linux/arch/arm/kernel/setup.c - 1.40 linux/arch/arm/kernel/irq.c - 1.27 linux/arch/arm/kernel/ecard.c - 1.26 linux/arch/arm/kernel/Makefile - 1.25 linux/arch/arm/boot/compressed/head.S - 1.24 linux/arch/arm/Makefile - 1.42 linux/arch/alpha/kernel/time.c - 1.27 linux/arch/alpha/kernel/smp.c - 1.42 linux/arch/alpha/kernel/signal.c - 1.22 linux/arch/alpha/kernel/setup.c - 1.35 linux/arch/alpha/kernel/ptrace.c - 1.18 linux/arch/alpha/kernel/proto.h - 1.22 linux/arch/alpha/kernel/process.c - 1.33 linux/arch/alpha/kernel/irq.c - 1.29 linux/arch/alpha/kernel/alpha_ksyms.c - 1.41 linux/arch/alpha/kernel/Makefile - 1.30 linux/arch/alpha/Makefile - 1.28 linux/Makefile - 1.238 linux/MAINTAINERS - 1.131 linux/Documentation/sysctl/kernel.txt - 1.8 linux/Documentation/networking/ip-sysctl.txt - 1.16 linux/Documentation/modules.txt - 1.8 linux/Documentation/md.txt - 1.5 linux/Documentation/kbuild/bug-list.txt - 1.3 linux/Documentation/kbuild/00-INDEX - 1.5 linux/Documentation/Changes - 1.63 linux/net/decnet/dn_nsp_in.c - 1.18 linux/drivers/sbus/char/aurora.c - 1.23 linux/drivers/isdn/eicon/eicon.h - 1.15 linux/drivers/isdn/eicon/Makefile - 1.9 linux/drivers/acorn/scsi/arxescsi.c - 1.17 linux/Documentation/kernel-parameters.txt - 1.21 linux/Documentation/isdn/HiSax.cert - 1.5 linux/include/asm-mips/ng1hw.h - 1.4 linux/drivers/tc/Makefile - 1.7 linux/drivers/net/declance.c - 1.18 linux/arch/mips/dec/time.c - 1.8 linux/arch/mips/dec/Makefile - 1.9 linux/arch/mips/baget/time.c - 1.6 linux/arch/mips/baget/Makefile - 1.9 linux/drivers/net/arlan.h - 1.8 linux/drivers/net/arlan.c - 1.23 linux/drivers/block/cpqarray.c - 1.64 linux/kernel/ptrace.c - 1.30 linux/drivers/parport/parport_pc.c - 1.52 linux/drivers/parport/Makefile - 1.12 linux/drivers/net/ppp_generic.c - 1.34 linux/drivers/net/hamradio/yam.c - 1.21 linux/fs/partitions/sun.c - 1.8 linux/fs/partitions/Makefile - 1.13 linux/arch/m68k/math-emu/fp_scan.S - 1.3 linux/arch/m68k/math-emu/fp_decode.h - 1.3 linux/drivers/net/sis900.c - 1.39 linux/drivers/char/ip2main.c - 1.25 linux/drivers/char/ip2/i2os.h - 1.3 linux/drivers/char/ip2/i2ellis.c - 1.6 linux/drivers/atm/Makefile - 1.24 linux/net/atm/Makefile - 1.13 linux/arch/alpha/kernel/pci_impl.h - 1.13 linux/drivers/block/DAC960.h - 1.22 linux/drivers/block/DAC960.c - 1.64 linux/arch/sparc64/kernel/power.c - 1.13 linux/arch/sh/kernel/time.c - 1.18 linux/arch/sh/kernel/Makefile - 1.18 linux/arch/sh/Makefile - 1.15 linux/drivers/scsi/ips.h - 1.21 linux/drivers/scsi/ips.c - 1.35 linux/include/asm-sh/signal.h - 1.5 linux/include/asm-i386/kmap_types.h - 1.13 linux/drivers/pcmcia/Makefile - 1.22 linux/arch/m68k/sun3/Makefile - 1.11 linux/arch/m68k/mac/via.c - 1.6 linux/include/linux/spinlock.h - 1.23 linux/drivers/net/pcmcia/ray_cs.c - 1.29 linux/drivers/net/pcmcia/Makefile - 1.24 linux/drivers/net/pcmcia/3c589_cs.c - 1.25 linux/include/linux/acpi.h - 1.34 linux/Documentation/filesystems/proc.txt - 1.17 linux/drivers/net/wan/Makefile - 1.21 linux/drivers/net/tokenring/Makefile - 1.13 linux/include/linux/pci_ids.h - 1.82 linux/drivers/scsi/sim710.scr - 1.3 linux/drivers/scsi/sim710.c - 1.13 linux/drivers/scsi/sim710.h - 1.9 linux/drivers/net/pcmcia/xirc2ps_cs.c - 1.21 linux/drivers/net/pcmcia/3c574_cs.c - 1.23 linux/drivers/net/pcmcia/nmclan_cs.c - 1.17 linux/mm/highmem.c - 1.49 linux/include/asm-i386/pgtable-3level.h - 1.12 linux/fs/proc/proc_misc.c - 1.53 linux/drivers/net/sk98lin/skxmac2.c - 1.6 linux/drivers/net/sk98lin/skvpd.c - 1.6 linux/drivers/net/sk98lin/skgeinit.c - 1.6 linux/include/asm-i386/pgalloc.h - 1.23 linux/arch/alpha/kernel/sys_nautilus.c - 1.12 linux/arch/alpha/kernel/core_irongate.c - 1.13 linux/include/linux/mmzone.h - 1.36 linux/include/asm-alpha/core_irongate.h - 1.8 linux/include/linux/agp_backend.h - 1.25 linux/drivers/net/pcmcia/aironet4500_cs.c - 1.17 linux/drivers/char/agp/Makefile - 1.13 linux/kernel/timer.c - 1.39 linux/drivers/scsi/scsi_lib.c - 1.58 linux/drivers/char/agp/agp.h - 1.33 linux/drivers/i2c/i2c-core.c - 1.20 linux/drivers/i2c/Makefile - 1.11 linux/arch/sparc64/kernel/sbus.c - 1.18 linux/arch/i386/kernel/acpi.c - 1.33 linux/drivers/telephony/Makefile - 1.7 linux/drivers/net/pcmcia/com20020_cs.c - 1.10 linux/drivers/net/arcnet/Makefile - 1.6 linux/drivers/net/tokenring/smctr_firmware.h - 1.3 linux/drivers/ieee1394/Makefile - 1.18 linux/include/asm-i386/apicdef.h - 1.11 linux/include/asm-arm/arch-sa1100/ide.h - 1.9 linux/drivers/scsi/scsi_scan.c - 1.39 linux/drivers/scsi/3w-xxxx.c - 1.26 linux/drivers/net/tokenring/tmspci.c - 1.10 linux/drivers/net/tokenring/madgemc.c - 1.7 linux/arch/m68k/atari/hades-pci.c - 1.5 linux/include/asm-sparc/ide.h - 1.16 linux/fs/autofs4/waitq.c - 1.9 linux/arch/ia64/kernel/head.S - 1.13 linux/arch/ia64/kernel/gate.S - 1.13 linux/arch/ia64/kernel/entry.h - 1.6 linux/arch/ia64/kernel/entry.S - 1.34 linux/arch/ia64/kernel/efi.c - 1.21 linux/arch/ia64/kernel/acpi.c - 1.19 linux/arch/ia64/kernel/Makefile - 1.18 linux/drivers/acorn/char/pcf8583.c - 1.8 linux/arch/ia64/ia32/sys_ia32.c - 1.39 linux/arch/ia64/ia32/ia32_support.c - 1.8 linux/arch/ia64/ia32/ia32_signal.c - 1.12 linux/arch/ia64/ia32/ia32_entry.S - 1.20 linux/arch/ia64/ia32/binfmt_elf32.c - 1.17 linux/arch/ia64/dig/setup.c - 1.10 linux/arch/ia64/vmlinux.lds.S - 1.22 linux/arch/ia64/tools/print_offsets.c - 1.15 linux/arch/ia64/Makefile - 1.24 linux/Documentation/ia64/README - 1.4 linux/arch/ia64/kernel/irq.c - 1.25 linux/arch/ia64/tools/Makefile - 1.13 linux/arch/ia64/kernel/setup.c - 1.23 linux/arch/ia64/kernel/signal.c - 1.21 linux/arch/ia64/kernel/sys_ia64.c - 1.18 linux/arch/ia64/kernel/time.c - 1.18 linux/arch/ia64/kernel/traps.c - 1.18 linux/arch/ia64/kernel/unaligned.c - 1.13 linux/arch/ia64/kernel/unwind.c - 1.12 linux/arch/ia64/lib/Makefile - 1.18 linux/arch/ia64/kernel/ivt.S - 1.20 linux/arch/ia64/kernel/machvec.c - 1.5 linux/arch/ia64/kernel/sal.c - 1.9 linux/arch/ia64/kernel/ptrace.c - 1.21 linux/arch/ia64/kernel/process.c - 1.25 linux/arch/ia64/kernel/perfmon.c - 1.20 linux/arch/ia64/kernel/mca.c - 1.17 linux/arch/ia64/mm/init.c - 1.25 linux/arch/ia64/mm/fault.c - 1.13 linux/arch/ia64/lib/memset.S - 1.7 linux/arch/ia64/mm/extable.c - 1.5 linux/arch/ia64/kernel/pal.S - 1.10 linux/drivers/scsi/qla1280.c - 1.24 linux/include/asm-ia64/ia32.h - 1.16 linux/include/asm-ia64/elf.h - 1.8 linux/include/asm-ia64/bugs.h - 1.2 linux/include/asm-ia64/bitops.h - 1.12 linux/include/asm-ia64/processor.h - 1.30 linux/include/asm-ia64/ptrace.h - 1.11 linux/include/asm-ia64/mmu_context.h - 1.13 linux/include/asm-ia64/spinlock.h - 1.11 linux/include/asm-ia64/unistd.h - 1.29 linux/include/asm-ia64/signal.h - 1.8 linux/include/asm-ia64/uaccess.h - 1.10 linux/include/asm-ia64/system.h - 1.23 linux/drivers/net/8139too.c - 1.48 linux/drivers/scsi/pcmcia/qlogic_stub.c - 1.11 linux/drivers/scsi/pcmcia/fdomain_stub.c - 1.11 linux/drivers/scsi/pcmcia/aha152x_stub.c - 1.12 linux/fs/devfs/Makefile - 1.7 linux/drivers/isdn/hysdn/hysdn_boot.c - 1.7 linux/drivers/net/skfp/smtdef.c - 1.2 linux/drivers/net/skfp/smt.c - 1.3 linux/drivers/net/skfp/pcmplc.c - 1.3 linux/drivers/net/skfp/skfddi.c - 1.15 linux/drivers/net/skfp/rmt.c - 1.2 linux/drivers/net/skfp/cfm.c - 1.2 linux/drivers/net/skfp/ecm.c - 1.3 linux/drivers/net/skfp/h/supern_2.h - 1.2 linux/drivers/net/skfp/h/osdef1st.h - 1.3 linux/net/bridge/br_if.c - 1.10 linux/drivers/video/matrox/Makefile - 1.9 linux/include/asm-mips/isadep.h - 1.4 linux/include/asm-mips64/signal.h - 1.4 linux/include/asm-mips64/r10kcache.h - 1.4 linux/arch/mips64/mm/Makefile - 1.7 linux/arch/mips64/sgi-ip27/ip27-timer.c - 1.11 linux/arch/mips64/sgi-ip22/ip22-timer.c - 1.8 linux/arch/mips64/Makefile - 1.16 linux/arch/mips64/kernel/Makefile - 1.9 linux/drivers/video/riva/fbdev.c - 1.22 linux/drivers/net/appletalk/Makefile - 1.6 linux/include/linux/usb.h - 1.53 linux/drivers/usb/serial/usb-serial.c - 1.13 linux/drivers/usb/serial/ftdi_sio.h - 1.7 linux/drivers/usb/serial/Makefile - 1.24 linux/arch/ia64/kernel/irq_ia64.c - 1.14 linux/drivers/ide/Makefile - 1.33 linux/net/ipv4/netfilter/ip_queue.c - 1.16 linux/net/ipv4/netfilter/Makefile - 1.20 linux/drivers/net/pcmcia/ibmtr_cs.c - 1.12 linux/drivers/video/sa1100fb.c - 1.20 linux/drivers/usb/serial/ftdi_sio.c - 1.46 linux/arch/ia64/kernel/smpboot.c - 1.18 linux/arch/ia64/kernel/minstate.h - 1.9 linux/drivers/net/wan/lmc/lmc_ver.h - 1.3 linux/drivers/net/wan/lmc/lmc_main.c - 1.13 linux/drivers/net/wan/lmc/lmc_ioctl.h - 1.3 linux/drivers/char/rio/cmdpkt.h - 1.2 linux/drivers/char/rio/riotty.c - 1.6 linux/arch/s390/Makefile - 1.14 linux/arch/s390/kernel/Makefile - 1.12 linux/include/asm-s390/signal.h - 1.4 linux/drivers/s390/net/Makefile - 1.9 linux/drivers/s390/char/Makefile - 1.10 linux/drivers/s390/block/Makefile - 1.10 linux/arch/s390/kernel/time.c - 1.10 linux/arch/s390/kernel/signal.c - 1.15 linux/net/ipv6/netfilter/Makefile - 1.13 linux/fs/xfs/xfsidbg.c - 1.219 linux/fs/xfs/xfs_log.h - 1.64 linux/fs/xfs/xfs_log.c - 1.264 linux/fs/xfs/xfs_extfree_item.c - 1.52 linux/fs/xfs/xfs_buf_item.c - 1.137 linux/fs/xfs/xfs_inode_item.c - 1.109 linux/fs/xfs/Makefile - 1.165 linux/fs/xfs/xfs_dquot_item.c - 1.32 linux/fs/xfs/xfs_vfsops.c - 1.402 linux/fs/xfs/xfs_trans.c - 1.138 linux/fs/xfs/xfs_trans.h - 1.117 linux/fs/xfs/xfs_trans_buf.c - 1.111 linux/kdb/Makefile - 1.19 linux/drivers/usb/storage/usb.h - 1.21 linux/drivers/usb/storage/usb.c - 1.35 linux/drivers/usb/storage/transport.h - 1.16 linux/drivers/usb/storage/transport.c - 1.38 linux/arch/alpha/kernel/core_titan.c - 1.9 linux/drivers/usb/storage/scsiglue.h - 1.4 linux/drivers/usb/storage/scsiglue.c - 1.30 linux/drivers/usb/storage/protocol.h - 1.5 linux/include/asm-ia64/asmmacro.h - 1.5 linux/drivers/acpi/tables/tbinstal.c - 1.17 linux/drivers/acpi/tables.c - 1.9 linux/drivers/acpi/resources/rscalc.c - 1.15 linux/drivers/acpi/namespace/nsload.c - 1.17 linux/fs/jffs/intrep.c - 1.20 linux/drivers/acpi/include/amlcode.h - 1.16 linux/drivers/acpi/include/actypes.h - 1.19 linux/drivers/acpi/include/actables.h - 1.15 linux/drivers/acpi/include/acpixf.h - 1.17 linux/drivers/acpi/include/acpiosxf.h - 1.16 linux/drivers/acpi/include/acpi.h - 1.8 linux/drivers/acpi/include/acobject.h - 1.17 linux/drivers/acpi/include/acexcep.h - 1.14 linux/drivers/acpi/ec.c - 1.16 linux/arch/ia64/ia32/ia32_ioctl.c - 1.7 linux/arch/ia64/kernel/brl_emu.c - 1.5 linux/arch/ia64/kernel/ia64_ksyms.c - 1.18 linux/drivers/acpi/Makefile - 1.23 linux/arch/ia64/kernel/palinfo.c - 1.11 linux/drivers/mtd/Makefile - 1.13 linux/drivers/mtd/ftl.c - 1.31 linux/drivers/mtd/mtdblock.c - 1.29 linux/net/ipv4/tcp_minisocks.c - 1.22 linux/Documentation/arm/SA1100/CERF - 1.2 linux/include/asm-sparc/kmap_types.h - 1.11 linux/drivers/usb/storage/freecom.c - 1.20 linux/drivers/usb/storage/dpcm.c - 1.4 linux/drivers/media/video/zr36120.c - 1.16 linux/drivers/media/video/stradis.c - 1.11 linux/drivers/media/video/saa7185.c - 1.9 linux/drivers/media/video/saa5249.c - 1.12 linux/drivers/media/video/bttv-driver.c - 1.27 linux/drivers/media/video/Makefile - 1.14 linux/drivers/media/radio/radio-zoltrix.c - 1.12 linux/Documentation/sparc/sbus_drivers.txt - 1.2 linux/drivers/media/radio/Makefile - 1.12 linux/drivers/isdn/hisax/l3ni1.c - 1.11 linux/drivers/input/Makefile - 1.10 linux/arch/sh/kernel/io.c - 1.4 linux/arch/arm/mach-footbridge/Makefile - 1.10 linux/Documentation/SubmittingDrivers - 1.8 linux/Documentation/kbuild/makefiles.txt - 1.8 linux/arch/arm/kernel/plx90x0.c - 1.5 linux/arch/arm/kernel/via82c505.c - 1.9 linux/arch/arm/mach-sa1100/Makefile - 1.18 linux/arch/arm/mach-sa1100/leds.c - 1.10 linux/arch/arm/mach-shark/Makefile - 1.8 linux/arch/arm/mm/proc-arm920.S - 1.15 linux/drivers/acpi/include/acconfig.h - 1.24 linux/drivers/acpi/include/acdebug.h - 1.17 linux/drivers/acpi/include/acdispat.h - 1.13 linux/drivers/acpi/include/acevents.h - 1.14 linux/drivers/acpi/include/acglobal.h - 1.18 linux/drivers/acpi/include/achware.h - 1.11 linux/drivers/acpi/include/acinterp.h - 1.17 linux/drivers/acpi/include/aclocal.h - 1.20 linux/drivers/acpi/include/acmacros.h - 1.17 linux/drivers/acpi/include/acnamesp.h - 1.17 linux/drivers/acpi/include/acoutput.h - 1.13 linux/drivers/acpi/include/acparser.h - 1.15 linux/drivers/acpi/include/acresrc.h - 1.10 linux/drivers/acpi/include/actbl.h - 1.12 linux/drivers/md/Makefile - 1.13 linux/drivers/md/md.c - 1.67 linux/drivers/net/hamachi.c - 1.21 linux/drivers/scsi/cpqfcTSinit.c - 1.25 linux/include/asm-ppc/kmap_types.h - 1.14 linux/mm/oom_kill.c - 1.20 linux/drivers/video/sis/Makefile - 1.7 linux/net/irda/irnet/irnet.h - 1.13 linux/include/asm-arm/module.h - 1.4 linux/arch/parisc/kernel/entry.S - 1.7 linux/drivers/parport/parport_gsc.c - 1.9 linux/drivers/net/lasi_82596.c - 1.16 linux/arch/parisc/kernel/traps.c - 1.7 linux/arch/parisc/kernel/time.c - 1.5 linux/arch/parisc/kernel/syscall.S - 1.6 linux/arch/parisc/kernel/signal.c - 1.7 linux/arch/i386/kernel/dmi_scan.c - 1.24 linux/arch/parisc/kernel/parisc_ksyms.c - 1.7 linux/include/asm-parisc/bitops.h - 1.3 linux/include/asm-parisc/signal.h - 1.2 linux/include/asm-parisc/smp.h - 1.3 linux/arch/parisc/kernel/irq.c - 1.8 linux/arch/parisc/kernel/Makefile - 1.8 linux/arch/parisc/Makefile - 1.12 linux/drivers/acpi/include/actbl71.h - 1.9 linux/drivers/acpi/include/actbl2.h - 1.12 linux/drivers/acpi/include/actbl1.h - 1.9 linux/drivers/acpi/power.c - 1.12 linux/drivers/scsi/osst.c - 1.23 linux/arch/ia64/kernel/iosapic.c - 1.14 linux/arch/ia64/lib/swiotlb.c - 1.10 linux/arch/ia64/sn/io/Makefile - 1.9 linux/drivers/acpi/acpi_ksyms.c - 1.15 linux/drivers/acpi/hardware/hwtimer.c - 1.11 linux/fs/reiserfs/inode.c - 1.37 linux/drivers/usb/storage/unusual_devs.h - 1.16 linux/arch/s390x/kernel/time.c - 1.9 linux/arch/s390x/kernel/signal32.c - 1.10 linux/arch/s390x/kernel/signal.c - 1.12 linux/arch/s390x/kernel/linux32.c - 1.23 linux/include/asm-s390x/signal.h - 1.5 linux/arch/cris/drivers/serial.c - 1.11 linux/arch/cris/kernel/Makefile - 1.14 linux/arch/cris/kernel/ptrace.c - 1.10 linux/arch/cris/lib/old_checksum.c - 1.4 linux/arch/s390x/kernel/Makefile - 1.12 linux/include/asm-cris/signal.h - 1.2 linux/drivers/net/tokenring/tmsisa.c - 1.6 linux/include/asm-arm/mach/irq.h - 1.6 linux/include/asm-cris/io.h - 1.7 linux/arch/s390x/Makefile - 1.15 linux/drivers/scsi/aic7xxx_old/aic7xxx_proc.c - 1.7 linux/drivers/scsi/aic7xxx_old.c - 1.27 linux/drivers/scsi/aic7xxx/aic7xxx_pci.c - 1.7 linux/drivers/scsi/aic7xxx/aic7xxx_osm.h - 1.12 linux/drivers/scsi/aic7xxx/aic7xxx_inline.h - 1.6 linux/arch/arm/mach-integrator/pci_v3.c - 1.13 linux/drivers/scsi/aic7xxx/aic7xxx.h - 1.7 linux/drivers/net/wan/dscc4.c - 1.16 linux/drivers/sbus/char/bbc_envctrl.c - 1.3 linux/Documentation/s390/s390dbf.txt - 1.3 linux/arch/arm/mach-ebsa110/Makefile - 1.6 linux/arch/arm/mach-ebsa110/time.c - 1.3 linux/include/asm-ia64/perfmon.h - 1.8 linux/include/asm-ia64/sn/sv.h - 1.3 linux/arch/mips/mips-boards/generic/time.c - 1.5 linux/net/ipv4/netfilter/ip_nat_helper.c - 1.8 linux/arch/mips/ite-boards/generic/time.c - 1.4 linux/drivers/net/fealnx.c - 1.18 linux/drivers/net/wireless/Makefile - 1.8 linux/fs/freevxfs/vxfs_fshead.c - 1.7 linux/drivers/net/wireless/orinoco.h - 1.11 linux/drivers/net/wireless/orinoco_cs.c - 1.14 linux/drivers/media/video/bt856.c - 1.8 linux/drivers/media/video/bt819.c - 1.7 linux/fs/char_dev.c - 1.6 linux/net/bluetooth/Makefile - 1.10 linux/drivers/mtd/nand/Makefile - 1.6 linux/drivers/mtd/maps/sa1100-flash.c - 1.5 linux/drivers/mtd/maps/elan-104nc.c - 1.4 linux/drivers/mtd/chips/jedec.c - 1.5 linux/drivers/mtd/chips/Makefile - 1.7 linux/drivers/acpi/utilities/utcopy.c - 1.14 linux/drivers/acpi/include/acstruct.h - 1.11 linux/drivers/net/wireless/airo_cs.c - 1.5 linux/drivers/usb/serial/pl2303.h - 1.7 linux/drivers/acpi/include/acutils.h - 1.15 linux/drivers/net/wireless/airo.c - 1.24 linux/drivers/acpi/include/platform/acenv.h - 1.12 linux/drivers/acpi/include/platform/acgcc.h - 1.12 linux/drivers/acpi/include/platform/aclinux.h - 1.12 linux/drivers/usb/serial/pl2303.c - 1.27 linux/drivers/message/fusion/mptscsih.c - 1.15 linux/drivers/message/fusion/Makefile - 1.11 linux/drivers/ieee1394/sbp2.c - 1.18 linux/fs/partitions/ldm.c - 1.10 linux/drivers/usb/storage/isd200.c - 1.13 linux/drivers/usb/storage/datafab.h - 1.3 linux/drivers/video/aty/atyfb_base.c - 1.17 linux/arch/arm/mach-sa1100/sa1111.c - 1.14 linux/arch/arm/mach-sa1100/sa1111-pcibuf.c - 1.8 linux/arch/arm/mach-sa1100/pcipool.c - 1.5 linux/arch/arm/mach-sa1100/leds.h - 1.7 linux/arch/arm/mach-anakin/Makefile - 1.5 linux/drivers/telephony/ixj_pcmcia.c - 1.3 linux/drivers/scsi/dpt_i2o.c - 1.19 linux/arch/mips/au1000/common/Makefile - 1.7 linux/arch/mips/au1000/common/time.c - 1.3 linux/arch/mips64/mips-boards/generic/time.c - 1.4 linux/arch/mips/philips/nino/time.c - 1.2 linux/drivers/scsi/53c700.c - 1.15 linux/drivers/parport/parport_cs.c - 1.5 linux/Documentation/usb/hiddev.txt - 1.4 linux/include/asm-ia64/tlb.h - 1.9 linux/drivers/mtd/devices/blkmtd.c - 1.19 linux/fs/namespace.c - 1.25 linux/fs/quota.c - 1.19 linux/drivers/i2c/i2c-proc.c - 1.9 linux/drivers/message/i2o/Makefile - 1.5 linux/drivers/atm/lanai.c - 1.6 linux/arch/arm/mach-epxa10db/Makefile - 1.5 linux/net/8021q/vlan.h - 1.3 linux/Documentation/networking/bonding.txt - 1.6 linux/fs/jbd/journal.c - 1.18 linux/drivers/scsi/sym53c8xx_2/sym_glue.c - 1.11 linux/drivers/scsi/sym53c8xx_2/sym_glue.h - 1.8 linux/arch/arm/mm/proc-arm926.S - 1.11 linux/fs/ext3/inode.c - 1.32 linux/drivers/hotplug/pci_hotplug_util.c - 1.6 linux/drivers/hotplug/pci_hotplug_core.c - 1.17 linux/drivers/hotplug/pci_hotplug.h - 1.5 linux/drivers/hotplug/cpqphp_proc.c - 1.6 linux/drivers/hotplug/cpqphp_pci.c - 1.8 linux/drivers/hotplug/cpqphp_nvram.c - 1.6 linux/drivers/hotplug/cpqphp_ctrl.c - 1.6 linux/drivers/hotplug/cpqphp_core.c - 1.11 linux/drivers/hotplug/Makefile - 1.8 linux/include/linux/jbd.h - 1.13 linux/fs/jbd/recovery.c - 1.6 linux/include/linux/ext3_jbd.h - 1.8 linux/fs/jbd/transaction.c - 1.15 linux/fs/seq_file.c - 1.6 linux/fs/ext3/Makefile - 1.7 linux/fs/jbd/Makefile - 1.4 linux/drivers/net/pcmcia/axnet_cs.c - 1.7 linux/init/do_mounts.c - 1.24 linux/include/linux/gfp.h - 1.9 linux/drivers/usb/serial/ipaq.c - 1.19 linux/drivers/usb/serial/ipaq.h - 1.6 linux/arch/arm/mm/proc-arm922.S - 1.10 linux/arch/arm/mach-tbox/Makefile - 1.5 linux/arch/arm/mach-adifcc/Makefile - 1.5 linux/arch/arm/mach-arc/Makefile - 1.5 linux/arch/arm/mach-clps7500/Makefile - 1.5 linux/arch/arm/mach-ftvpci/Makefile - 1.5 linux/arch/arm/mach-iop310/Makefile - 1.5 linux/arch/arm/mach-l7200/Makefile - 1.5 linux/arch/arm/mach-rpc/Makefile - 1.5 linux/fs/xfs/pagebuf/page_buf.c - 1.94 linux/include/linux/init_task.h - 1.16 linux/drivers/net/wireless/netwave_cs.c - 1.6 linux/net/ipv6/netfilter/ip6_queue.c - 1.5 linux/drivers/base/Makefile - 1.11 linux/lib/zlib_inflate/Makefile - 1.4 linux/lib/zlib_deflate/Makefile - 1.4 linux/drivers/input/gameport/Makefile - 1.5 linux/drivers/input/serio/Makefile - 1.7 linux/sound/synth/emux/soundfont.c - 1.4 linux/sound/synth/emux/emux_seq.c - 1.5 linux/sound/synth/emux/emux_oss.c - 1.4 linux/sound/synth/emux/Makefile - 1.7 linux/sound/synth/Makefile - 1.9 linux/sound/sound_firmware.c - 1.3 linux/sound/ppc/tumbler.c - 1.6 linux/sound/ppc/powermac.c - 1.7 linux/sound/ppc/pmac.c - 1.7 linux/sound/ppc/keywest.c - 1.6 linux/sound/pci/ymfpci/ymfpci_main.c - 1.10 linux/sound/pci/trident/trident_synth.c - 1.4 linux/sound/pci/trident/trident_memory.c - 1.5 linux/sound/pci/trident/trident_main.c - 1.9 linux/sound/pci/trident/Makefile - 1.5 linux/sound/pci/sonicvibes.c - 1.10 linux/sound/pci/rme9652/rme9652.c - 1.14 linux/sound/pci/rme9652/Makefile - 1.6 linux/sound/pci/rme96.c - 1.13 linux/sound/pci/nm256/nm256.c - 1.11 linux/sound/pci/maestro3.c - 1.11 linux/sound/pci/korg1212/korg1212.c - 1.15 linux/sound/pci/intel8x0.c - 1.13 linux/sound/pci/fm801.c - 1.11 linux/sound/pci/es1968.c - 1.12 linux/sound/pci/es1938.c - 1.11 linux/sound/pci/ens1370.c - 1.15 linux/sound/pci/emu10k1/memory.c - 1.6 linux/sound/pci/emu10k1/emuproc.c - 1.7 linux/sound/pci/emu10k1/emupcm.c - 1.8 linux/sound/pci/emu10k1/emufx.c - 1.11 linux/sound/pci/emu10k1/emu10k1_main.c - 1.8 linux/sound/pci/emu10k1/emu10k1.c - 1.9 linux/sound/pci/emu10k1/Makefile - 1.6 linux/sound/pci/cs46xx/cs46xx_lib.c - 1.11 linux/sound/pci/cs4281.c - 1.14 linux/sound/pci/cmipci.c - 1.13 linux/sound/pci/ali5451/ali5451.c - 1.14 linux/sound/pci/ac97/ak4531_codec.c - 1.4 linux/sound/pci/ac97/ac97_codec.c - 1.11 linux/sound/pci/ac97/Makefile - 1.10 linux/arch/ppc/boot/simple/Makefile - 1.12 linux/sound/oss/trident.c - 1.9 linux/sound/oss/maestro.c - 1.6 linux/sound/oss/i810_audio.c - 1.9 linux/sound/oss/dmasound/Makefile - 1.5 linux/arch/ppc/platforms/Makefile - 1.11 linux/arch/ppc/platforms/pmac_time.c - 1.4 linux/arch/x86_64/Makefile - 1.14 linux/arch/x86_64/ia32/Makefile - 1.10 linux/arch/x86_64/ia32/ia32_signal.c - 1.9 linux/arch/x86_64/kernel/Makefile - 1.13 linux/arch/x86_64/kernel/apic.c - 1.9 linux/arch/x86_64/kernel/signal.c - 1.10 linux/arch/x86_64/kernel/time.c - 1.7 linux/arch/x86_64/lib/Makefile - 1.10 linux/arch/x86_64/mm/Makefile - 1.7 linux/sound/oss/ac97_codec.c - 1.5 linux/sound/oss/Makefile - 1.10 linux/sound/isa/wavefront/wavefront_synth.c - 1.8 linux/sound/isa/wavefront/wavefront_fx.c - 1.6 linux/sound/isa/sgalaxy.c - 1.8 linux/sound/isa/sb/sb_mixer.c - 1.6 linux/sound/isa/sb/sb_common.c - 1.9 linux/sound/isa/sb/sb8_main.c - 1.4 linux/sound/isa/sb/sb16_main.c - 1.8 linux/sound/isa/sb/sb16_csp.c - 1.6 linux/sound/isa/sb/sb16.c - 1.9 linux/sound/isa/sb/emu8000.c - 1.8 linux/sound/isa/sb/Makefile - 1.10 linux/sound/isa/opti9xx/opti92x-ad1848.c - 1.9 linux/sound/isa/gus/interwave.c - 1.9 linux/sound/isa/gus/gus_synth.c - 1.5 linux/sound/isa/gus/gus_reset.c - 1.4 linux/sound/isa/gus/gus_pcm.c - 1.6 linux/sound/isa/gus/gus_mixer.c - 1.4 linux/sound/isa/gus/gus_mem_proc.c - 1.5 linux/sound/isa/gus/gus_mem.c - 1.4 linux/sound/isa/gus/gus_main.c - 1.7 linux/sound/isa/gus/gus_irq.c - 1.3 linux/sound/isa/gus/Makefile - 1.7 linux/sound/isa/es18xx.c - 1.12 linux/sound/isa/es1688/es1688_lib.c - 1.6 linux/sound/isa/es1688/Makefile - 1.5 linux/sound/isa/cs423x/cs4236_lib.c - 1.4 linux/sound/isa/cs423x/cs4236.c - 1.12 linux/sound/isa/cs423x/cs4231_lib.c - 1.10 linux/sound/isa/cs423x/Makefile - 1.7 linux/sound/isa/cmi8330.c - 1.9 linux/sound/isa/ad1848/ad1848_lib.c - 1.9 linux/sound/isa/ad1848/Makefile - 1.7 linux/sound/isa/ad1816a/ad1816a_lib.c - 1.7 linux/sound/isa/ad1816a/Makefile - 1.5 linux/sound/i2c/tea6330t.c - 1.4 linux/sound/i2c/cs8427.c - 1.5 linux/sound/i2c/Makefile - 1.9 linux/sound/drivers/serial-u16550.c - 1.12 linux/sound/drivers/opl3/opl3_seq.c - 1.7 linux/sound/drivers/opl3/opl3_oss.c - 1.4 linux/sound/drivers/opl3/Makefile - 1.10 linux/sound/drivers/mtpav.c - 1.11 linux/sound/drivers/mpu401/mpu401_uart.c - 1.10 linux/sound/drivers/mpu401/mpu401.c - 1.7 linux/sound/drivers/mpu401/Makefile - 1.10 linux/sound/drivers/dummy.c - 1.11 linux/sound/core/timer.c - 1.11 linux/sound/core/sound.c - 1.13 linux/sound/core/seq/seq_timer.h - 1.4 linux/sound/core/seq/seq_timer.c - 1.7 linux/sound/core/seq/seq_queue.h - 1.9 linux/sound/core/seq/seq_queue.c - 1.9 linux/sound/core/seq/seq_ports.c - 1.7 linux/sound/core/seq/seq_midi_event.c - 1.8 linux/sound/core/seq/seq_midi_emul.c - 1.4 linux/sound/core/seq/seq_midi.c - 1.8 linux/sound/core/seq/seq_instr.c - 1.4 linux/sound/core/seq/seq_clientmgr.c - 1.11 linux/sound/core/seq/oss/seq_oss_midi.c - 1.6 linux/sound/core/seq/oss/seq_oss_init.c - 1.5 linux/sound/core/seq/oss/Makefile - 1.8 linux/sound/core/seq/instr/ainstr_simple.c - 1.3 linux/sound/core/seq/instr/ainstr_iw.c - 1.3 linux/sound/core/seq/instr/ainstr_gf1.c - 1.3 linux/sound/core/seq/instr/ainstr_fm.c - 1.3 linux/sound/core/seq/instr/Makefile - 1.11 linux/sound/core/seq/Makefile - 1.17 linux/sound/core/rtctimer.c - 1.12 linux/sound/core/rawmidi.c - 1.13 linux/sound/core/pcm_native.c - 1.13 linux/sound/core/pcm_misc.c - 1.5 linux/sound/core/pcm_memory.c - 1.6 linux/sound/core/pcm_lib.c - 1.10 linux/sound/core/pcm.c - 1.8 linux/sound/core/oss/pcm_plugin.c - 1.5 linux/sound/core/oss/pcm_oss.c - 1.14 linux/sound/core/oss/mixer_oss.c - 1.7 linux/sound/core/oss/Makefile - 1.6 linux/sound/core/memory.c - 1.12 linux/sound/core/isadma.c - 1.4 linux/sound/core/init.c - 1.9 linux/sound/core/info.c - 1.12 linux/sound/core/hwdep.c - 1.5 linux/sound/core/device.c - 1.9 linux/sound/core/control.c - 1.9 linux/sound/core/Makefile - 1.16 linux/sound/Makefile - 1.13 linux/include/asm-x86_64/kmap_types.h - 1.6 linux/include/sound/version.h - 1.15 linux/include/sound/trident.h - 1.5 linux/include/sound/timer.h - 1.3 linux/include/sound/sndmagic.h - 1.6 linux/include/sound/seq_kernel.h - 1.4 linux/include/sound/sb16_csp.h - 1.2 linux/include/sound/sb.h - 1.5 linux/include/sound/pcm_params.h - 1.6 linux/include/sound/pcm.h - 1.9 linux/include/sound/mixer_oss.h - 1.5 linux/include/sound/info.h - 1.6 linux/include/sound/gus.h - 1.3 linux/include/sound/emu10k1.h - 1.8 linux/include/sound/cs46xx.h - 1.8 linux/include/sound/core.h - 1.16 linux/include/sound/ak4531_codec.h - 1.2 linux/include/sound/ad1848.h - 1.3 linux/include/sound/ac97_codec.h - 1.10 linux/include/asm-x86_64/signal.h - 1.5 linux/include/asm-ppc64/elf.h - 1.5 linux/arch/ppc64/Makefile - 1.15 linux/arch/ppc64/defconfig - 1.14 linux/arch/ppc64/kernel/Makefile - 1.13 linux/arch/ppc64/kernel/entry.S - 1.13 linux/arch/ppc64/kernel/head.S - 1.9 linux/arch/ppc64/kernel/htab.c - 1.9 linux/arch/ppc64/kernel/init_task.c - 1.4 linux/arch/ppc64/kernel/misc.S - 1.14 linux/arch/ppc64/kernel/pci.c - 1.10 linux/arch/ppc64/kernel/process.c - 1.12 linux/arch/ppc64/kernel/rtas-proc.c - 1.4 linux/arch/ppc64/kernel/rtasd.c - 1.6 linux/arch/ppc64/kernel/signal.c - 1.13 linux/arch/ppc64/kernel/signal32.c - 1.13 linux/arch/ppc64/kernel/smp.c - 1.14 linux/arch/ppc64/kernel/sys_ppc32.c - 1.15 linux/arch/ppc64/kernel/time.c - 1.11 linux/arch/ppc64/kernel/traps.c - 1.10 linux/arch/ppc64/lib/Makefile - 1.8 linux/include/asm-ppc64/unistd.h - 1.12 linux/include/asm-ppc64/thread_info.h - 1.7 linux/include/asm-ppc64/uaccess.h - 1.5 linux/include/asm-ppc64/system.h - 1.9 linux/include/asm-ppc64/signal.h - 1.3 linux/include/asm-ppc64/ppc32.h - 1.5 linux/include/asm-ppc64/processor.h - 1.12 linux/drivers/net/e1000/e1000_main.c - 1.15 linux/drivers/net/e1000/Makefile - 1.7 linux/drivers/net/e1000/e1000_osdep.h - 1.8 linux/drivers/net/e1000/e1000.h - 1.10 linux/drivers/net/e1000/e1000_ethtool.c - 1.8 linux/drivers/net/e1000/e1000_proc.c - 1.6 linux/drivers/hotplug/ibmphp_pci.c - 1.3 linux/Documentation/filesystems/jfs.txt - 1.4 linux/drivers/hotplug/ibmphp_ebda.c - 1.6 linux/drivers/hotplug/ibmphp_core.c - 1.10 linux/fs/jfs/inode.c - 1.21 linux/fs/jfs/jfs_btree.h - 1.4 linux/fs/jfs/jfs_debug.h - 1.5 linux/fs/jfs/jfs_dmap.c - 1.11 linux/fs/jfs/jfs_dtree.c - 1.12 linux/fs/jfs/jfs_inode.c - 1.6 linux/fs/jfs/jfs_imap.c - 1.12 linux/fs/jfs/namei.c - 1.15 linux/arch/arm/mach-sa1100/stork.c - 1.6 linux/fs/jfs/jfs_xtree.c - 1.8 linux/fs/jfs/jfs_logmgr.c - 1.23 linux/fs/jfs/super.c - 1.21 linux/fs/jfs/jfs_mount.c - 1.12 linux/fs/jfs/jfs_txnmgr.c - 1.22 linux/fs/jfs/jfs_umount.c - 1.8 linux/fs/jfs/jfs_unicode.c - 1.4 linux/fs/jfs/jfs_metapage.c - 1.13 linux/fs/quota_v2.c - 1.8 linux/drivers/net/tg3.h - 1.13 linux/sound/core/ioctl32/timer32.c - 1.6 linux/drivers/net/tg3.c - 1.15 linux/sound/core/ioctl32/rawmidi32.c - 1.6 linux/drivers/net/tulip/de4x5.c - 1.9 linux/drivers/net/tulip/de4x5.h - 1.2 linux/sound/core/ioctl32/pcm32.c - 1.6 linux/sound/core/ioctl32/ioctl32.h - 1.5 linux/sound/core/ioctl32/ioctl32.c - 1.9 linux/drivers/net/e100/e100_proc.c - 1.8 linux/drivers/net/e100/Makefile - 1.5 linux/drivers/net/e100/e100.h - 1.12 linux/Documentation/sound/alsa/CMIPCI.txt - 1.2 linux/drivers/net/e100/e100_main.c - 1.14 linux/fs/jffs2/os-linux.h - 1.7 linux/arch/ia64/sn/kernel/Makefile - 1.7 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_dvr.c - 1.4 linux/arch/ia64/sn/io/sn1/pcibr.c - 1.5 linux/drivers/acpi/acpi_bus.h - 1.8 linux/arch/i386/kernel/acpi_wakeup.S - 1.7 linux/drivers/acpi/acpi_drivers.h - 1.9 linux/sound/core/ioctl32/seq32.c - 1.5 linux/drivers/usb/image/microtek.c - 1.8 linux/Documentation/usb/silverlink.txt - 1.2 linux/drivers/usb/class/cdc-acm.c - 1.14 linux/drivers/usb/core/Makefile - 1.11 linux/drivers/usb/core/devices.c - 1.6 linux/drivers/usb/core/hcd.c - 1.18 linux/drivers/usb/core/hcd.h - 1.13 linux/drivers/usb/input/hid-core.c - 1.13 linux/drivers/usb/core/usb.c - 1.27 linux/drivers/usb/host/ehci-dbg.c - 1.12 linux/arch/arm/mach-pxa/Makefile - 1.6 linux/drivers/usb/host/ehci-hcd.c - 1.16 linux/drivers/usb/host/ehci-mem.c - 1.6 linux/drivers/usb/host/ehci-q.c - 1.16 linux/drivers/usb/host/ehci.h - 1.9 linux/drivers/usb/host/ohci-hcd.c - 1.17 linux/drivers/usb/host/ohci-mem.c - 1.10 linux/drivers/usb/host/ohci-q.c - 1.19 linux/drivers/usb/media/usbvideo.c - 1.12 linux/drivers/usb/image/hpusbscsi.c - 1.10 linux/drivers/usb/image/scanner.c - 1.16 linux/drivers/usb/image/scanner.h - 1.11 linux/drivers/usb/media/Makefile - 1.7 linux/drivers/usb/serial/safe_serial.c - 1.10 linux/drivers/usb/media/vicam.c - 1.10 linux/mm/readahead.c - 1.16 linux/mm/pdflush.c - 1.10 linux/fs/exportfs/Makefile - 1.4 linux/drivers/isdn/i4l/Makefile - 1.8 linux/arch/ia64/hp/zx1/hpzx1_misc.c - 1.8 linux/drivers/pcmcia/sa1100_trizeps.c - 1.3 linux/arch/ia64/hp/sim/simserial.c - 1.8 linux/arch/ia64/hp/sim/simscsi.c - 1.8 linux/arch/ia64/hp/sim/simeth.c - 1.3 linux/include/asm-ia64/tlbflush.h - 1.4 linux/arch/ia64/hp/common/Makefile - 1.5 linux/arch/ia64/hp/common/sba_iommu.c - 1.7 linux/drivers/isdn/capi/Makefile - 1.5 linux/drivers/isdn/hardware/avm/Makefile - 1.4 linux/drivers/scsi/aic7xxx/aic7xxx_core.c - 1.6 linux/sound/i2c/l3/Makefile - 1.4 linux/sound/pci/rme32.c - 1.9 linux/sound/i2c/l3/uda1341.c - 1.4 linux/drivers/usb/host/uhci-hcd.c - 1.16 linux/drivers/pci/hotplug.c - 1.8 linux/fs/fs-writeback.c - 1.13 linux/include/linux/page-flags.h - 1.17 linux/mm/page-writeback.c - 1.18 linux/include/linux/buffer_head.h - 1.17 linux/include/linux/jiffies.h - 1.2 linux/kernel/suspend.c - 1.20 linux/drivers/char/drm/i830_dma.c - 1.6 linux/drivers/usb/host/hc_simple.c - 1.6 linux/fs/mpage.c - 1.17 linux/drivers/acorn/scsi/scsi.h - 1.3 linux/drivers/usb/core/message.c - 1.13 linux/drivers/acpi/ac.c - 1.8 linux/drivers/acpi/battery.c - 1.10 linux/drivers/acpi/fan.c - 1.7 linux/drivers/acpi/button.c - 1.9 linux/drivers/acpi/thermal.c - 1.11 linux/drivers/acpi/processor.c - 1.15 linux/drivers/acpi/osl.c - 1.12 linux/drivers/s390/cio/Makefile - 1.5 linux/drivers/s390/net/lcs.c - 1.8 linux/net/llc/Makefile - 1.7 linux/drivers/scsi/53c8xx_d.h_shipped - 1.2 linux/drivers/scsi/53c8xx_u.h_shipped - 1.2 linux/drivers/scsi/aic7xxx/aic7xxx_reg.h_shipped - 1.4 linux/sound/pci/rme9652/hdsp.c - 1.8 linux/drivers/scsi/aic7xxx/aic7xxx_seq.h_shipped - 1.4 linux/drivers/scsi/sim710_d.h_shipped - 1.3 linux/sound/pci/rme9652/hammerfall_mem.c - 1.7 linux/sound/isa/sb/emu8000_pcm.c - 1.4 linux/drivers/input/power.c - 1.4 linux/drivers/input/mouse/rpcmouse.c - 1.7 linux/drivers/acpi/toshiba_acpi.c - 1.5 linux/drivers/acpi/include/amlresrc.h - 1.6 linux/fs/direct-io.c - 1.15 linux/drivers/usb/input/pid.c - 1.5 linux/fs/smbfs/smbiod.c - 1.5 linux/security/dummy.c - 1.8 linux/security/capability.c - 1.6 linux/security/Makefile - 1.3 linux/drivers/serial/uart00.c - 1.7 linux/drivers/serial/Makefile - 1.8 linux/include/asm-generic/rmap.h - 1.3 linux/arch/i386/mm/pgtable.c - 1.5 linux/include/linux/security.h - 1.7 linux/drivers/bluetooth/bt3c_cs.c - 1.6 linux/drivers/base/fs/Makefile - 1.6 linux/net/sched/sch_htb.c - 1.5 linux/drivers/usb/misc/atmsar.c - 1.3 linux/drivers/usb/misc/atmsar.h - 1.3 linux/drivers/usb/misc/speedtouch.c - 1.10 linux/arch/ia64/kernel/perfmon_itanium.h - 1.3 linux/arch/ia64/kernel/perfmon_mckinley.h - 1.3 linux/arch/i386/kernel/cpu/mtrr/Makefile - 1.3 linux/arch/ia64/lib/memcpy_mck.S - 1.2 linux/include/asm-generic/rtc.h - 1.3 linux/net/sctp/input.c - 1.8 linux/include/asm-ia64/kmap_types.h - 1.3 linux/include/asm-sparc64/kmap_types.h - 1.3 linux/fs/xfs/linux/xfs_aops.c - 1.27 linux/include/asm-alpha/kmap_types.h - 1.3 linux/include/asm-i386/mmzone.h - 1.5 linux/drivers/ide/pci/sis5513.c - 1.7 linux/drivers/ide/pci/pdc202xx_old.c - 1.7 linux/drivers/ide/pci/pdc202xx_new.c - 1.7 linux/include/asm-ppc64/kmap_types.h - 1.3 linux/drivers/ide/pci/amd74xx.c - 1.8 linux/include/asm-um/archparam-i386.h - 1.2 linux/arch/um/Makefile - 1.9 linux/arch/um/defconfig - 1.5 linux/arch/um/drivers/Makefile - 1.6 linux/arch/um/drivers/chan_kern.c - 1.4 linux/arch/um/drivers/chan_user.c - 1.4 linux/arch/um/drivers/daemon_kern.c - 1.3 linux/arch/um/drivers/daemon_user.c - 1.2 linux/arch/um/drivers/fd.c - 1.3 linux/arch/um/drivers/harddog_kern.c - 1.3 linux/arch/um/drivers/harddog_user.c - 1.2 linux/arch/um/drivers/hostaudio_kern.c - 1.3 linux/arch/um/drivers/line.c - 1.5 linux/arch/um/drivers/mcast_kern.c - 1.4 linux/arch/um/drivers/mcast_user.c - 1.2 linux/arch/um/drivers/mconsole_kern.c - 1.6 linux/arch/um/drivers/mmapper_kern.c - 1.3 linux/arch/um/drivers/net_kern.c - 1.5 linux/arch/um/drivers/null.c - 1.3 linux/arch/um/drivers/port_kern.c - 1.6 linux/arch/um/drivers/port_user.c - 1.4 linux/arch/um/drivers/pty.c - 1.3 linux/arch/um/drivers/slip_kern.c - 1.4 linux/arch/um/drivers/slip_user.c - 1.3 linux/arch/um/drivers/ssl.c - 1.5 linux/arch/um/drivers/stdio_console.c - 1.5 linux/arch/um/drivers/tty.c - 1.3 linux/arch/um/drivers/ubd_kern.c - 1.9 linux/arch/um/drivers/xterm.c - 1.5 linux/arch/um/include/frame.h - 1.3 linux/arch/um/include/irq_user.h - 1.3 linux/arch/um/include/kern_util.h - 1.5 linux/arch/um/include/mconsole.h - 1.3 linux/arch/um/include/os.h - 1.3 linux/arch/um/include/signal_kern.h - 1.2 linux/arch/um/include/sysdep-i386/frame.h - 1.2 linux/arch/um/include/sysdep-i386/frame_kern.h - 1.3 linux/arch/um/include/sysdep-i386/frame_user.h - 1.2 linux/arch/um/include/sysdep-i386/ptrace.h - 1.3 linux/arch/um/include/sysdep-i386/sigcontext.h - 1.3 linux/arch/um/include/sysdep-i386/syscalls.h - 1.2 linux/arch/um/include/umid.h - 1.2 linux/arch/um/include/user_util.h - 1.6 linux/arch/um/kernel/Makefile - 1.8 linux/arch/um/kernel/frame.c - 1.4 linux/arch/um/kernel/frame_kern.c - 1.3 linux/arch/um/kernel/init_task.c - 1.3 linux/arch/um/kernel/irq.c - 1.5 linux/arch/um/kernel/irq_user.c - 1.6 linux/arch/um/kernel/ksyms.c - 1.5 linux/arch/um/kernel/mem.c - 1.7 linux/arch/um/kernel/process.c - 1.5 linux/arch/um/kernel/process_kern.c - 1.7 linux/arch/um/kernel/ptrace.c - 1.4 linux/arch/um/kernel/sigio_user.c - 1.4 linux/arch/um/kernel/signal_kern.c - 1.4 linux/arch/um/kernel/smp.c - 1.5 linux/arch/um/kernel/sys_call_table.c - 1.5 linux/arch/um/kernel/time.c - 1.5 linux/arch/um/kernel/time_kern.c - 1.5 linux/arch/um/kernel/tlb.c - 1.5 linux/arch/um/kernel/trap_kern.c - 1.5 linux/arch/um/kernel/trap_user.c - 1.5 linux/arch/um/kernel/uaccess_user.c - 1.3 linux/arch/um/kernel/um_arch.c - 1.5 linux/arch/um/kernel/umid.c - 1.4 linux/arch/um/kernel/unmap.c - 1.2 linux/arch/um/kernel/user_syms.c - 1.2 linux/arch/um/kernel/user_util.c - 1.3 linux/arch/um/main.c - 1.4 linux/arch/um/os-Linux/drivers/ethertap_kern.c - 1.3 linux/arch/um/os-Linux/drivers/ethertap_user.c - 1.2 linux/arch/um/os-Linux/drivers/tuntap_kern.c - 1.3 linux/arch/um/os-Linux/drivers/tuntap_user.c - 1.2 linux/arch/um/os-Linux/file.c - 1.5 linux/arch/um/os-Linux/process.c - 1.3 linux/arch/um/sys-i386/Makefile - 1.6 linux/arch/um/sys-i386/bugs.c - 1.3 linux/arch/um/sys-i386/fault.c - 1.2 linux/include/asm-um/pgtable.h - 1.5 linux/arch/um/sys-i386/sigcontext.c - 1.3 linux/arch/um/sys-i386/util/mk_thread_kern.c - 1.3 linux/arch/um/util/mk_task_kern.c - 1.2 linux/include/asm-um/ptrace-i386.h - 1.2 linux/include/asm-um/ptrace-generic.h - 1.3 linux/include/asm-um/processor-i386.h - 1.2 linux/include/asm-um/processor-generic.h - 1.4 linux/include/asm-um/page.h - 1.4 linux/include/asm-um/current.h - 1.2 linux/include/asm-um/module.h - 1.2 linux/arch/i386/mm/hugetlbpage.c - 1.9 linux/arch/sparc64/mm/hugetlbpage.c - 1.4 linux/net/bridge/netfilter/Makefile - 1.3 linux/drivers/acpi/scan.c - 1.5 linux/arch/ia64/mm/hugetlbpage.c - 1.4 linux/drivers/pci/pci.h - 1.2 linux/drivers/base/cpu.c - 1.4 linux/include/asm-alpha/topology.h - 1.4 linux/include/asm-generic/topology.h - 1.3 linux/sound/pci/cs46xx/dsp_spos_scb_lib.c - 1.5 linux/include/asm-i386/topology.h - 1.4 linux/include/asm-ia64/topology.h - 1.5 linux/sound/pci/cs46xx/dsp_spos.c - 1.5 linux/include/asm-mips64/topology.h - 1.2 linux/include/asm-ppc64/topology.h - 1.4 linux/sound/pci/ac97/ac97_patch.c - 1.5 linux/sound/core/pcm_sgbuf.c - 1.5 linux/include/sound/pcm_sgbuf.h - 1.4 linux/include/sound/cs46xx_dsp_spos.h - 1.5 linux/include/sound/cs46xx_dsp_scb_types.h - 1.2 linux/arch/um/uml.lds.S - 1.6 linux/arch/i386/kernel/cpu/cpufreq/Makefile - 1.4 linux/sound/usb/usbquirks.h - 1.5 linux/sound/usb/usbmixer.c - 1.4 linux/sound/usb/usbmidi.c - 1.6 linux/sound/usb/usbaudio.h - 1.5 linux/Documentation/filesystems/ext3.txt - 1.2 linux/sound/usb/usbaudio.c - 1.7 linux/sound/pci/via82xx.c - 1.5 linux/sound/pci/ice1712/ice1712.h - 1.5 linux/sound/pci/ice1712/ice1712.c - 1.5 linux/sound/pci/ice1712/ews.c - 1.5 linux/sound/pci/ice1712/ak4524.c - 1.5 linux/sound/pci/ice1712/Makefile - 1.4 linux/mm/truncate.c - 1.4 linux/include/asm-s390/kmap_types.h - 1.3 linux/drivers/scsi/nsp32.c - 1.4 linux/drivers/scsi/aacraid/linit.c - 1.6 linux/drivers/scsi/aacraid/aacraid.h - 1.4 linux/drivers/scsi/aacraid/aachba.c - 1.6 linux/kernel/workqueue.c - 1.2 linux/Documentation/DocBook/journal-api.tmpl - 1.5 linux/arch/i386/kernel/timers/timer_pit.c - 1.5 linux/drivers/isdn/hardware/eicon/Makefile - 1.3 linux/drivers/isdn/hardware/eicon/io.h - 1.2 linux/arch/ppc/platforms/4xx/Makefile - 1.4 linux/arch/um/include/time_user.h - 1.4 linux/arch/um/drivers/pcap_user.c - 1.2 linux/arch/um/drivers/pcap_kern.c - 1.2 linux/drivers/isdn/hardware/eicon/diva_didd.c - 1.3 linux/net/rxrpc/krxtimod.c - 1.3 linux/net/rxrpc/krxsecd.c - 1.4 linux/net/rxrpc/krxiod.c - 1.3 linux/net/rxrpc/internal.h - 1.3 linux/net/rxrpc/Makefile - 1.4 linux/fs/afs/cmservice.c - 1.3 linux/include/asm-x86_64/proto.h - 1.6 linux/fs/afs/internal.h - 1.3 linux/fs/afs/kafsasyncd.c - 1.3 linux/fs/afs/kafstimod.c - 1.3 linux/arch/um/kernel/tempfile.c - 1.3 linux/fs/nfs/nfs4proc.c - 1.6 linux/arch/ppc/boot/simple/misc.c - 1.5 linux/include/asm-i386/edd.h - 1.4 linux/Documentation/tipar.txt - 1.2 linux/fs/sysfs/Makefile - 1.3 linux/drivers/pnp/pnpbios/Makefile - 1.3 linux/fs/sysfs/inode.c - 1.6 linux/arch/i386/kernel/edd.c - 1.6 linux/include/linux/sysfs.h - 1.6 linux/drivers/pnp/isapnp/Makefile - 1.5 linux/drivers/bluetooth/Kconfig - 1.2 linux/drivers/mtd/maps/Kconfig - 1.3 linux/drivers/net/Kconfig - 1.7 linux/drivers/net/appletalk/Kconfig - 1.3 linux/drivers/net/arcnet/Kconfig - 1.3 linux/drivers/net/hamradio/Kconfig - 1.3 linux/drivers/net/irda/Kconfig - 1.3 linux/drivers/message/i2o/Kconfig - 1.2 linux/drivers/net/pcmcia/Kconfig - 1.2 linux/drivers/net/tokenring/Kconfig - 1.4 linux/arch/alpha/Kconfig - 1.7 linux/drivers/message/fusion/Kconfig - 1.2 linux/arch/arm/Kconfig - 1.6 linux/drivers/net/tulip/Kconfig - 1.2 linux/security/Kconfig - 1.4 linux/arch/arm/mach-sa1100/Kconfig - 1.2 linux/drivers/md/Kconfig - 1.2 linux/arch/cris/Kconfig - 1.5 linux/arch/cris/drivers/Kconfig - 1.2 linux/arch/i386/Kconfig - 1.10 linux/drivers/net/wan/Kconfig - 1.3 linux/net/irda/irlan/Kconfig - 1.2 linux/drivers/media/video/Kconfig - 1.3 linux/drivers/net/wireless/Kconfig - 1.3 linux/drivers/media/radio/Kconfig - 1.2 linux/drivers/parport/Kconfig - 1.3 linux/arch/i386/mach-voyager/Makefile - 1.3 linux/drivers/media/dvb/frontends/Kconfig - 1.3 linux/include/linux/crypto.h - 1.4 linux/arch/ia64/Kconfig - 1.6 linux/scripts/Makefile.modver - 1.3 linux/scripts/Makefile.lib - 1.4 linux/arch/ia64/kernel/perfmon_generic.h - 1.2 linux/scripts/Makefile.build - 1.6 linux/include/asm-parisc/module.h - 1.3 linux/arch/ia64/mm/discontig.c - 1.2 linux/drivers/char/Kconfig - 1.5 linux/arch/m68k/Kconfig - 1.8 linux/arch/mips/Kconfig - 1.6 linux/arch/mips64/Kconfig - 1.6 linux/arch/parisc/Kconfig - 1.7 linux/drivers/media/dvb/dvb-core/Makefile - 1.3 linux/drivers/pcmcia/Kconfig - 1.2 linux/drivers/pnp/Kconfig - 1.3 linux/drivers/media/Kconfig - 1.3 linux/arch/parisc/kernel/signal32.c - 1.3 linux/drivers/s390/Kconfig - 1.3 linux/arch/parisc/kernel/sys_parisc32.c - 1.6 linux/net/bluetooth/rfcomm/Kconfig - 1.2 linux/drivers/fc4/Kconfig - 1.2 linux/drivers/cdrom/Kconfig - 1.2 linux/drivers/scsi/Kconfig - 1.6 linux/drivers/isdn/sc/Kconfig - 1.2 linux/net/irda/ircomm/Kconfig - 1.2 linux/drivers/char/agp/Kconfig - 1.5 linux/arch/ppc/Kconfig - 1.6 linux/drivers/block/paride/Kconfig - 1.2 linux/drivers/char/drm/Kconfig - 1.2 linux/arch/ppc64/Kconfig - 1.6 linux/drivers/isdn/hysdn/Kconfig - 1.2 linux/arch/s390/Kconfig - 1.5 linux/net/ipv4/ah.c - 1.5 linux/drivers/hotplug/Kconfig - 1.3 linux/arch/s390x/Kconfig - 1.6 linux/drivers/hotplug/acpiphp.h - 1.3 linux/arch/sh/Kconfig - 1.6 linux/drivers/hotplug/acpiphp_glue.c - 1.5 linux/arch/sparc/Kconfig - 1.6 linux/net/ipv4/netfilter/Kconfig - 1.2 linux/drivers/scsi/pcmcia/Kconfig - 1.3 linux/drivers/i2c/Kconfig - 1.3 linux/drivers/input/joystick/Kconfig - 1.2 linux/arch/sparc64/Kconfig - 1.6 linux/drivers/ide/Kconfig - 1.5 linux/drivers/block/Kconfig - 1.2 linux/drivers/input/joystick/iforce/Kconfig - 1.2 linux/drivers/input/gameport/Kconfig - 1.2 linux/arch/um/Kconfig - 1.4 linux/drivers/usb/host/Kconfig - 1.3 linux/arch/x86_64/Kconfig - 1.8 linux/fs/befs/ChangeLog - 1.2 linux/sound/pci/Kconfig - 1.3 linux/fs/Kconfig - 1.9 linux/drivers/input/Kconfig - 1.3 linux/drivers/input/keyboard/Kconfig - 1.3 linux/drivers/ieee1394/Kconfig - 1.3 linux/net/sctp/Kconfig - 1.2 linux/crypto/Makefile - 1.6 linux/crypto/cipher.c - 1.4 linux/crypto/digest.c - 1.4 linux/crypto/internal.h - 1.4 linux/crypto/tcrypt.c - 1.6 linux/drivers/usb/image/Kconfig - 1.3 linux/net/Kconfig - 1.5 linux/drivers/input/misc/Kconfig - 1.3 linux/net/irda/Kconfig - 1.2 linux/net/irda/irnet/Kconfig - 1.2 linux/drivers/input/mouse/Kconfig - 1.4 linux/net/bluetooth/bnep/Kconfig - 1.2 linux/drivers/serial/Kconfig - 1.4 linux/drivers/telephony/Kconfig - 1.2 linux/drivers/acpi/Kconfig - 1.3 linux/drivers/video/Kconfig - 1.6 linux/net/sched/Kconfig - 1.2 linux/drivers/usb/storage/Kconfig - 1.2 linux/drivers/atm/Kconfig - 1.2 linux/drivers/usb/serial/Kconfig - 1.4 linux/drivers/usb/misc/Kconfig - 1.3 linux/drivers/usb/Kconfig - 1.2 linux/sound/oss/Kconfig - 1.4 linux/drivers/usb/net/Kconfig - 1.3 linux/net/bluetooth/Kconfig - 1.2 linux/drivers/usb/class/Kconfig - 1.5 linux/drivers/char/pcmcia/Kconfig - 1.2 linux/net/ax25/Kconfig - 1.2 linux/drivers/char/ftape/Kconfig - 1.2 linux/drivers/usb/input/Kconfig - 1.3 linux/include/net/xfrm.h - 1.5 linux/drivers/input/serio/Kconfig - 1.5 linux/init/Kconfig - 1.6 linux/drivers/usb/media/Kconfig - 1.3 linux/drivers/input/touchscreen/Kconfig - 1.2 linux/fs/hugetlbfs/inode.c - 1.7 linux/fs/eventpoll.c - 1.4 linux/fs/binfmt_som.c - 1.3 linux/fs/binfmt_flat.c - 1.2 linux/mm/fremap.c - 1.3 linux/drivers/serial/8250_gsc.c - 1.3 linux/drivers/parisc/sba_iommu.c - 1.4 linux/drivers/parisc/ccio-rm-dma.c - 1.4 linux/drivers/parisc/ccio-dma.c - 1.5 linux/include/linux/hugetlb.h - 1.4 linux/drivers/parisc/Makefile - 1.3 linux/drivers/net/mac8390.c - 1.4 linux/include/asm-i386/node.h - 1.2 linux/include/asm-i386/memblk.h - 1.2 linux/include/asm-i386/cpu.h - 1.2 linux/include/asm-v850/signal.h - 1.2 linux/drivers/base/node.c - 1.5 linux/drivers/base/memblk.c - 1.3 linux/include/asm-m68knommu/signal.h - 1.2 linux/arch/v850/kernel/time.c - 1.3 linux/arch/m68knommu/Kconfig - 1.5 linux/arch/m68knommu/Makefile - 1.3 linux/arch/m68knommu/kernel/Makefile - 1.4 linux/arch/m68knommu/kernel/signal.c - 1.4 linux/arch/m68knommu/kernel/time.c - 1.2 linux/arch/m68knommu/platform/68360/uCquicc/crt0_ram.S - 1.2 linux/arch/m68knommu/platform/68360/uCquicc/crt0_rom.S - 1.2 linux/arch/v850/kernel/signal.c - 1.4 linux/arch/v850/kernel/rte_mb_a_pci.c - 1.3 linux/include/asm-v850/pci.h - 1.2 linux/arch/v850/kernel/mach.h - 1.2 linux/arch/v850/kernel/Makefile - 1.3 linux/arch/v850/Kconfig - 1.5 linux/arch/v850/Makefile - 1.4 linux/drivers/net/irda/sir_kthread.c - 1.3 linux/drivers/hotplug/cpci_hotplug_pci.c - 1.3 linux/drivers/hotplug/cpci_hotplug_core.c - 1.3 linux/arch/ppc/syslib/Makefile - 1.4 linux/net/ipv4/esp.c - 1.3 linux/drivers/scsi/scsi_sysfs.c - 1.4 linux/scripts/per-cpu-check.awk - 1.3 linux/drivers/serial/mux.c - 1.3 linux/drivers/mca/Makefile - 1.2 linux/drivers/s390/char/sclp_tty.c - 1.2 linux/drivers/s390/char/sclp_tty.h - 1.2 linux/Documentation/scsi/ChangeLog.sym53c8xx - 1.2 linux/Documentation/scsi/aic7xxx.txt - 1.3 linux/Documentation/scsi/ibmmca.txt - 1.2 linux/drivers/s390/char/tape_char.c - 1.2 linux/include/asm-sparc64/compat.h - 1.4 linux/drivers/video/console/Kconfig - 1.4 linux/drivers/video/console/Makefile - 1.3 linux/drivers/acpi/dispatcher/dsinit.c - 1.4 linux/net/ipv4/xfrm_user.c - 1.2 linux/include/asm-ppc64/compat.h - 1.3 linux/drivers/char/watchdog/Kconfig - 1.3 linux/arch/um/drivers/xterm_kern.c - 1.3 linux/kernel/params.c - 1.3 linux/include/linux/xfrm.h - 1.2 linux/arch/x86_64/kernel/mtrr/Makefile - 1.2 linux/arch/x86_64/mm/hugetlbpage.c - 1.3 linux/Documentation/scsi/aic79xx.txt - 1.2 linux/Documentation/sound/alsa/ALSA-Configuration.txt - 1.2 linux/arch/um/kernel/tt/uaccess_user.c - 1.2 linux/arch/um/kernel/tt/trap_user.c - 1.2 linux/arch/um/kernel/tt/tracer.c - 1.2 linux/arch/um/kernel/tt/tlb.c - 1.2 linux/arch/um/kernel/tt/syscall_user.c - 1.2 linux/arch/um/kernel/tt/syscall_kern.c - 1.2 linux/arch/um/kernel/tt/sys-i386/sigcontext.c - 1.2 linux/arch/um/kernel/tt/ptproxy/proxy.c - 1.2 linux/arch/um/kernel/tt/process_kern.c - 1.2 linux/arch/um/kernel/tt/mem.c - 1.2 linux/arch/um/kernel/tt/include/uaccess.h - 1.2 linux/arch/um/kernel/tt/include/tt.h - 1.2 linux/arch/um/kernel/tt/include/ptrace-tt.h - 1.2 linux/include/asm-x86_64/compat.h - 1.4 linux/arch/um/kernel/tt/include/mode_kern.h - 1.2 linux/arch/um/kernel/tt/include/mode.h - 1.2 linux/arch/um/kernel/tt/gdb_kern.c - 1.2 linux/arch/um/kernel/tt/gdb.c - 1.2 linux/arch/um/kernel/tt/Makefile - 1.2 linux/drivers/i2c/busses/Kconfig - 1.2 linux/drivers/i2c/chips/Kconfig - 1.2 linux/arch/um/kernel/skas/trap_user.c - 1.2 linux/arch/um/kernel/skas/tlb.c - 1.2 linux/arch/um/kernel/skas/syscall_user.c - 1.2 linux/arch/um/kernel/skas/syscall_kern.c - 1.2 linux/arch/um/kernel/skas/sys-i386/sigcontext.c - 1.2 linux/arch/um/kernel/skas/process_kern.c - 1.2 linux/arch/um/kernel/skas/process.c - 1.2 linux/arch/um/kernel/skas/mem_user.c - 1.2 linux/arch/um/kernel/skas/mem.c - 1.2 linux/arch/um/kernel/skas/include/uaccess.h - 1.2 linux/arch/um/kernel/skas/include/skas_ptrace.h - 1.2 linux/arch/um/kernel/skas/include/skas.h - 1.2 linux/arch/um/kernel/skas/include/ptrace-skas.h - 1.2 linux/arch/um/kernel/skas/include/mode_kern.h - 1.2 linux/arch/um/kernel/skas/include/mode.h - 1.2 linux/arch/um/include/mode.h - 1.2 linux/include/asm-ia64/intrinsics.h - 1.2 linux/sound/pci/ice1712/amp.c - 1.2 linux/include/asm-ia64/compat.h - 1.3 linux/arch/um/include/choose-mode.h - 1.2 linux/drivers/scsi/aic7xxx/Kconfig.aic7xxx - 1.2 linux/arch/um/drivers/slirp_user.c - 1.2 linux/arch/um/drivers/slirp_kern.c - 1.2 linux/drivers/scsi/aic7xxx/aic79xx.reg - 1.2 linux/drivers/scsi/aic7xxx/aic79xx.seq - 1.2 linux/drivers/scsi/aic7xxx/aic79xx_core.c - 1.3 linux/drivers/scsi/aic7xxx/aic79xx_inline.h - 1.2 linux/drivers/scsi/aic7xxx/aic79xx_osm.c - 1.3 linux/drivers/scsi/aic7xxx/aic79xx_osm.h - 1.3 linux/drivers/scsi/aic7xxx/aic79xx_reg.h_shipped - 1.2 linux/drivers/scsi/aic7xxx/aic79xx_reg_print.c_shipped - 1.2 linux/drivers/scsi/aic7xxx/aic79xx_seq.h_shipped - 1.2 linux/drivers/scsi/aic7xxx/aic7xxx_osm.c - 1.3 linux/drivers/scsi/aic7xxx/aic7xxx_reg_print.c_shipped - 1.3 linux/drivers/scsi/aic7xxx/aiclib.c - 1.2 linux/drivers/scsi/aic7xxx/aiclib.h - 1.2 linux/drivers/scsi/aic7xxx/scsi_iu.h - 1.2 linux/include/asm-parisc/compat.h - 1.2 linux/include/asm-parisc/dma-mapping.h - 1.2 linux/drivers/char/ipmi/Makefile - 1.2 linux/net/sunrpc/auth_gss/gss_krb5_crypto.c - 1.2 linux/net/sunrpc/auth_gss/Makefile - 1.2 linux/arch/parisc/kernel/module.c - 1.2 linux/include/asm-arm/bug.h - 1.2 linux/arch/ppc/ocp/Makefile - 1.2 linux/arch/ppc64/kernel/module.c - 1.2 linux/arch/alpha/kernel/core_marvel.c - 1.2 linux/include/asm-generic/vmlinux.lds.h - 1.2 linux/drivers/eisa/Makefile - 1.2 From owner-linux-xfs@oss.sgi.com Tue Feb 11 12:09:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Feb 2003 12:09:36 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1BK9Q3v027149 for ; Tue, 11 Feb 2003 12:09:27 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 6186518AE93F; Tue, 11 Feb 2003 12:17:35 -0800 (PST) Date: Tue, 11 Feb 2003 12:17:35 -0800 From: Chris Wedgwood To: George App Cc: linux-xfs@oss.sgi.com Subject: Re: Support for XFS File systems Message-ID: <20030211201735.GA6124@f00f.org> References: <20030211103224.3d2786d7.george@georgeapp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030211103224.3d2786d7.george@georgeapp.com> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2621 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: 371 Lines: 13 On Tue, Feb 11, 2003 at 10:32:24AM -0800, George App wrote: > Are there any tools available for defraging the XFS file system? As someone else said, xfs_fsr will do this for you. I will point out though that unless your filesystem is really badly fragmented (in which case it would be good to know why) then xfs_fsr can actually make some workloads *worse*. --cw From owner-linux-xfs@oss.sgi.com Tue Feb 11 15:01:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Feb 2003 15:01:54 -0800 (PST) Received: from exchange.ccur.com (mail.ccur.com [208.248.32.212]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1BN1m3v030052 for ; Tue, 11 Feb 2003 15:01:50 -0800 Received: by exchange.ccur.com with Internet Mail Service (5.5.2653.19) id <1J840DPK>; Tue, 11 Feb 2003 18:09:53 -0500 Message-ID: From: "Miro, Felix" To: "'linux-xfs@oss.sgi.com'" Subject: RE: pagebuf problems Date: Tue, 11 Feb 2003 18:09:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 2622 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: felix.miro@ccur.com Precedence: bulk X-list: linux-xfs Content-Length: 924 Lines: 41 call trace: timer_bh + 0x254/0x3b0 pagebuf_daemon_wakeup + 0x0/0x40 timer_softirq + 0x2c/0x40 _do_softirq + 0x2c/x40 ksoftirqd + 0xf5/0x120 kernel_thread + 0x3d/0xb0 register_proc_table + 0xe0/0x100 The boot hang occurs while bringing up filesystem devices: cdrom,... Any clue? Can you point me to the latest 2.4.21pre4 patch for XFS? I have the 1/26/03 version. Regards, Felix > -----Original Message----- > From: Miro, Felix > Sent: Tuesday, February 11, 2003 1:21 PM > To: 'linux-xfs@oss.sgi.com' > Subject: pagebuf problems > > I haven't had any luck getting the 2.4.21pre4 patch you sent to work. The > system won't boot. I get bad EIP. The problem appears to be related to > pagebuf. What little trace info I have shows: > > ksoftirqd > timer_bh > pagebuf_daemon_wakeup > timer_softirq > __do_softirq > ksoftirqd > > If I configure XFS out of the build the system boots fine. > > Regards, > Felix From owner-linux-xfs@oss.sgi.com Tue Feb 11 15:22:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Feb 2003 15:22:24 -0800 (PST) Received: from tautology.org (evrtwa1-ar13-4-33-070-190.evrtwa1.dsl-verizon.net [4.33.70.190]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1BNMD3v030898 for ; Tue, 11 Feb 2003 15:22:16 -0800 Received: from tautology.org (evrtwa1-ar13-4-33-070-190.evrtwa1.dsl-verizon.net [4.33.70.190]) by tautology.org (8.12.6/8.12.6) with ESMTP id h1BNUMhs037996 for ; Tue, 11 Feb 2003 15:30:23 -0800 (PST) (envelope-from seth@tautology.org) Received: from localhost (seth@localhost) by tautology.org (8.12.6/8.12.6/Submit) with ESMTP id h1BNUMxh037992 for ; Tue, 11 Feb 2003 15:30:22 -0800 (PST) (envelope-from seth@tautology.org) Date: Tue, 11 Feb 2003 15:30:18 -0800 (PST) From: Seth Woolley To: linux-xfs@oss.sgi.com Subject: dmapi-2.0.5 sources autoconf dancing. Message-ID: <20030211150343.C22819-100000@tautology.org> Mail-Followup-To: Seth Woolley MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2623 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: seth@tautology.org Precedence: bulk X-list: linux-xfs Content-Length: 1335 Lines: 38 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi XFSers, I'm Security Team Leader at sourcemage.org, a source-based GNU/Linux distribution, and we have something similar to a ports system that downloads sources from author's websites and compiles them. We use MD5s to verify the downloaded sources. dmapi-2.0.5 source changed twice on your server. Once to autoconf 2.53 (on 2002-11-08). Second back to 2.13 (on 2003-02-10). When it happened the first time, I just checked the diff looking for trojans and noticed it was just an autoconf change for the most part and updated our MD5. Now it switched back to 2.13, and the MD5 has to be moved back. If this happens too many times, I start to lobby the authors to have a policy of changing the version number (say 2.0.5-2) on the file if they change a released source file. I was just wondering if anybody else noticed this and what the problem was with the newer autoconf. Seth - -- Seth Alan Woolley , SPAM/UCE is unauthorized Key id 7BEACC7D = 2978 0BD1 BA48 B671 C1EB 93F7 EDF4 3CDF 7BEA CC7D Full Key at seth.tautology.org, see www.gnupg.org www.keyserver.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQE+SYeO7fQ833vqzH0RAhYHAKDC1uPeK96+jJJJEXXfWWbl8mQjCwCgvnOp v4AFc5MbZ25WgAGjLYNn6dE= =UsWV -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Tue Feb 11 17:08:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Feb 2003 17:08:45 -0800 (PST) Received: from wideangle.nameip.net (IDENT:ZY5PRvKp0G+mh/S0BP+cOiK6SRTMqqV9@[211.49.2.185]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1C18Z3v002310 for ; Tue, 11 Feb 2003 17:08:36 -0800 Received: (qmail 15309 invoked by uid 500); 12 Feb 2003 01:16:44 -0000 Subject: xfsprogs build for XFS 1.2 on RedHat 7.x From: Seung-yeong Oh To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1045012603.4171.6.camel@wideangle.nameip.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 12 Feb 2003 10:16:43 +0900 X-archive-position: 2624 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: so1713@orgio.net Precedence: bulk X-list: linux-xfs Content-Length: 293 Lines: 8 Hello, Somehow I couldn't rebuild xfsprogs-2.3.5-0.src.rpm for XFS 1.2 on RedHat 7.x. I didn't have any problem with the util rebuilding for XFS 1.2pre5.. Did anything happen to the spec file? I'd appreciate any input. Thank you. The error message I got was Files not found for the man dirs. From owner-linux-xfs@oss.sgi.com Tue Feb 11 17:29:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Feb 2003 17:29:29 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1C1TM3v002951 for ; Tue, 11 Feb 2003 17:29:22 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 8D3E418BCC15; Tue, 11 Feb 2003 17:37:32 -0800 (PST) Date: Tue, 11 Feb 2003 17:37:32 -0800 From: Chris Wedgwood To: Seung-yeong Oh Cc: linux-xfs@oss.sgi.com Subject: Re: xfsprogs build for XFS 1.2 on RedHat 7.x Message-ID: <20030212013732.GA7782@f00f.org> References: <1045012603.4171.6.camel@wideangle.nameip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1045012603.4171.6.camel@wideangle.nameip.net> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2625 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: 263 Lines: 18 On Wed, Feb 12, 2003 at 10:16:43AM +0900, Seung-yeong Oh wrote: > Did anything happen to the spec file? no > I'd appreciate any input. what fails and how? > The error message I got was Files not found for the man dirs. a little more info please --cw From owner-linux-xfs@oss.sgi.com Tue Feb 11 17:49:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Feb 2003 17:49:41 -0800 (PST) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1C1nY3v004179 for ; Tue, 11 Feb 2003 17:49:35 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1C14tKp032097 for ; Tue, 11 Feb 2003 17:04:55 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id TAA46238; Tue, 11 Feb 2003 19:57:38 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id TAA84141; Tue, 11 Feb 2003 19:57:39 -0600 (CST) Date: Tue, 11 Feb 2003 19:57:24 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Seung-yeong Oh cc: linux-xfs@oss.sgi.com Subject: Re: xfsprogs build for XFS 1.2 on RedHat 7.x In-Reply-To: <1045012603.4171.6.camel@wideangle.nameip.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2626 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 596 Lines: 21 We'll have to ask Russell - my guess is it's the difference between gzipped and not-gzipped man pages, the box that built those srpms is an 8.0 box. If you have an old srpm around, can you see what the build host was for that package? -Eric On 12 Feb 2003, Seung-yeong Oh wrote: > Hello, > Somehow I couldn't rebuild xfsprogs-2.3.5-0.src.rpm for XFS 1.2 on > RedHat 7.x. > I didn't have any problem with the util rebuilding for XFS 1.2pre5.. > Did anything happen to the spec file? > I'd appreciate any input. Thank you. > The error message I got was Files not found for the man dirs. > > From owner-linux-xfs@oss.sgi.com Tue Feb 11 22:20:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Feb 2003 22:20:32 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1C6KQ3v009142 for ; Tue, 11 Feb 2003 22:20:26 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1C6KQNP009141 for linux-xfs@oss.sgi.com; Tue, 11 Feb 2003 22:20:26 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1C6KO3x009127 for ; Tue, 11 Feb 2003 22:20:24 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1C6FgJn008747; Tue, 11 Feb 2003 22:15:42 -0800 Date: Tue, 11 Feb 2003 22:15:42 -0800 Message-Id: <200302120615.h1C6FgJn008747@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 209] Kernel 2.4.20-xfs memory leaks X-Bugzilla-Reason: AssignedTo X-archive-position: 2627 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1815 Lines: 36 http://oss.sgi.com/bugzilla/show_bug.cgi?id=209 ------- Additional Comments From crypope@gmx.net 2003-02-11 22:15 ------- Please see the vmstat 1 results. # vmstat 1 procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 0 0 0 0 436564 56 173732 0 0 0 0 105 61 0 0 100 0 0 0 0 436564 56 173732 0 0 0 0 106 56 0 1 99 0 0 0 0 436564 56 173732 0 0 0 0 111 71 1 0 99 0 0 0 0 436564 56 173732 0 0 0 0 105 60 0 1 99 0 0 0 0 436464 56 173732 0 0 0 0 151 108 1 1 98 0 0 0 0 436456 56 173740 0 0 0 0 167 174 2 1 97 0 0 0 0 436452 56 173744 0 0 0 0 162 183 3 2 95 0 0 0 0 436452 56 173744 0 0 0 0 144 119 2 0 98 0 0 0 0 436444 56 173752 0 0 0 0 175 214 2 1 97 0 0 0 0 436444 56 173752 0 0 0 0 281 93 1 0 99 0 0 0 0 436316 56 173756 0 0 0 0 233 200 2 2 96 0 0 0 0 436312 56 173760 0 0 0 0 119 72 0 1 99 0 0 0 0 436312 56 173760 0 0 0 0 244 170 0 2 98 0 0 0 0 436308 56 173764 0 0 0 0 149 144 1 0 99 0 0 0 0 436276 56 173768 0 0 12 0 147 160 3 0 97 0 0 0 0 436264 56 173780 0 0 0 0 157 113 1 0 99 0 0 0 0 436280 56 173780 0 0 0 0 105 70 1 0 99 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Feb 11 23:05:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Feb 2003 23:06:06 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1C75w3v010100 for ; Tue, 11 Feb 2003 23:05:59 -0800 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id B9BCDAC37; Wed, 12 Feb 2003 08:23:01 +0100 (CET) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id A1E92190CF; Wed, 12 Feb 2003 08:23:01 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id 755B430881D; Wed, 12 Feb 2003 08:14:02 +0100 (CET) Message-ID: <3E49F43A.F8A5E1E7@ch.sauter-bc.com> Date: Wed, 12 Feb 2003 08:14:02 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.22-6.2.3 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Eric Sandeen Cc: Seung-yeong Oh , linux-xfs@oss.sgi.com Subject: Re: xfsprogs build for XFS 1.2 on RedHat 7.x References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2628 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: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Content-Length: 832 Lines: 29 I have rebuilt on RedHat 7.2. The only problem is that I first had to rebuild xfsprogrs, then upgrade the resulting binary rpms and then rebuild all other packages. Simon Eric Sandeen schrieb: > > We'll have to ask Russell - my guess is it's the difference between > gzipped and not-gzipped man pages, the box that built those srpms > is an 8.0 box. > > If you have an old srpm around, can you see what the build host > was for that package? > > -Eric > > On 12 Feb 2003, Seung-yeong Oh wrote: > > > Hello, > > Somehow I couldn't rebuild xfsprogs-2.3.5-0.src.rpm for XFS 1.2 on > > RedHat 7.x. > > I didn't have any problem with the util rebuilding for XFS 1.2pre5.. > > Did anything happen to the spec file? > > I'd appreciate any input. Thank you. > > The error message I got was Files not found for the man dirs. > > > > From owner-linux-xfs@oss.sgi.com Wed Feb 12 01:56:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Feb 2003 01:57:05 -0800 (PST) Received: from wideangle.nameip.net (IDENT:tUVCtxEndc4vj6dwW0erZQtUYnwredWa@[211.49.2.185]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1C9uv3v017238 for ; Wed, 12 Feb 2003 01:56:58 -0800 Received: (qmail 26071 invoked by uid 500); 12 Feb 2003 10:05:07 -0000 Subject: xfsprogs build for XFS 1.2 on RedHat 7.x problem solved From: Seung-yeong Oh To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1045044307.1778.12.camel@wideangle.nameip.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 12 Feb 2003 19:05:07 +0900 X-archive-position: 2629 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: so1713@orgio.net Precedence: bulk X-list: linux-xfs Content-Length: 1375 Lines: 37 Hello, I don't know what happened, but apparently there was a change in the spec file only for the xfsprogs SRPM. Reversing the change solved the problem as follows; # diff -Nur xfsprogs.spec.orig xfsprogs.spec --- xfsprogs.spec.orig Tue Feb 11 02:31:11 2003 +++ xfsprogs.spec Wed Feb 12 18:47:49 2003 @@ -67,15 +67,15 @@ { sort | uniq | awk ' $1 == "d" { printf ("%%%%dir %%%%attr(%s,%s,%s) %s\n", $2, $3, $4, $5); } -$1 == "f" { if (match ($6, "/usr/local/man") || match ($6, "/usr/local/share/doc/xfsprogs")) +$1 == "f" { if (match ($6, "/usr/share/man") || match ($6, "/usr/share/doc/xfsprogs")) printf ("%%%%doc "); - if (match ($6, "/usr/local/man")) + if (match ($6, "/usr/share/man")) printf ("%%%%attr(%s,%s,%s) %s*\n", $2, $3, $4, $6); else printf ("%%%%attr(%s,%s,%s) %s\n", $2, $3, $4, $6); } -$1 == "l" { if (match ($3, "/usr/local/man") || match ($3, "/usr/local/share/doc/xfsprogs")) +$1 == "l" { if (match ($3, "/usr/share/man") || match ($3, "/usr/share/doc/xfsprogs")) printf ("%%%%doc "); - if (match ($3, "/usr/local/man")) + if (match ($3, "/usr/share/man")) printf ("%attr(0777,root,root) %s*\n", $3); else printf ("%attr(0777,root,root) %s\n", $3); }' Have a nice day. From owner-linux-xfs@oss.sgi.com Wed Feb 12 02:46:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Feb 2003 02:46:07 -0800 (PST) Received: from mail.iwr.uni-heidelberg.de (mail.iwr.uni-heidelberg.de [129.206.104.30]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1CAk23v021657 for ; Wed, 12 Feb 2003 02:46:04 -0800 Received: from kenzo.iwr.uni-heidelberg.de (kenzo.iwr.uni-heidelberg.de [129.206.120.29]) by mail.iwr.uni-heidelberg.de (8.11.1/8.11.1) with ESMTP id h1CAsDb18423; Wed, 12 Feb 2003 11:54:13 +0100 (MET) Received: from localhost (bogdan@localhost) by kenzo.iwr.uni-heidelberg.de (8.11.6/8.11.6) with ESMTP id h1CAsCr04969; Wed, 12 Feb 2003 11:54:13 +0100 Date: Wed, 12 Feb 2003 11:54:12 +0100 (CET) From: Bogdan Costescu To: Chris Wedgwood cc: linux-xfs@oss.sgi.com Subject: Defrag pitfals (was Re: Support for XFS File systems) In-Reply-To: <20030211201735.GA6124@f00f.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2630 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: bogdan.costescu@iwr.uni-heidelberg.de Precedence: bulk X-list: linux-xfs Content-Length: 939 Lines: 25 On Tue, 11 Feb 2003, Chris Wedgwood wrote: > I will point out though that unless your filesystem is really badly > fragmented (in which case it would be good to know why) then xfs_fsr > can actually make some workloads *worse*. Could you (or somebody else) please elaborate on this ? I've switched several file systems to XFS exactly because of the feature of defragmenting while the FS was still mounted. I've tried to find this kind of information prior to switching to XFS, but I failed... empirical evidence suggests that defragmentation helps a lot in my case, but I would really like to be aware of situations when this feature would become detrimental. Thanks in advance! -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From owner-linux-xfs@oss.sgi.com Wed Feb 12 07:55:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Feb 2003 07:55:40 -0800 (PST) Received: from pop015.verizon.net (pop015pub.verizon.net [206.46.170.172]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1CFtT3v009801 for ; Wed, 12 Feb 2003 07:55:30 -0800 Received: from [192.168.0.6] ([138.88.29.179]) by pop015.verizon.net (InterMail vM.5.01.05.20 201-253-122-126-120-20021101) with ESMTP id <20030212160336.VMUL7113.pop015.verizon.net@[192.168.0.6]> for ; Wed, 12 Feb 2003 10:03:36 -0600 Subject: official patch won't patch kernel From: Bart Himel <31himel@cua.edu> To: linux-xfs@oss.sgi.com Content-Type: text/plain Organization: Message-Id: <1045065597.680.8.camel@ockham> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 12 Feb 2003 10:59:58 -0500 Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at pop015.verizon.net from [138.88.29.179] at Wed, 12 Feb 2003 10:03:35 -0600 X-archive-position: 2631 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: 31himel@cua.edu Precedence: bulk X-list: linux-xfs Content-Length: 19367 Lines: 525 I just downloaded the new official xfs 1.2.0 patches for linux kernel 2.4.19, and I'm having trouble with the linux-2.4.19-core-xfs-1.2.0.patch. When I run "patch -p1 < linux-2.4.19-core-xfs-1.2.0.patch" I get the following messages "The next patch would create the file Documentation/Changes, which already exists! Assume -R? [n]" Whether I tell it yes or no, it still fails to patch the kernel. Any ideas? Below is a complete listing of what it complains of. Again, it doesn't matter whether I answer yes or no to all/any of these, it still fails to patch the kernel. The next patch would create the file Documentation/Changes, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file Documentation/Changes.rej The next patch would create the file Documentation/Configure.help, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file Documentation/Configure.help.rej The next patch would create the file Documentation/filesystems/00-INDEX, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file Documentation/filesystems/00-INDEX.rej The next patch would create the file Documentation/filesystems/Locking, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file Documentation/filesystems/Locking.rej The next patch would create the file MAINTAINERS, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file MAINTAINERS.rej The next patch would create the file Makefile, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file Makefile.rej The next patch would create the file arch/alpha/defconfig, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/alpha/defconfig.rej The next patch would create the file arch/arm/defconfig, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/arm/defconfig.rej The next patch would create the file arch/cris/defconfig, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/cris/defconfig.rej The next patch would create the file arch/i386/defconfig, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/i386/defconfig.rej The next patch would create the file arch/i386/kernel/entry.S, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/i386/kernel/entry.S.rej The next patch would create the file arch/ia64/defconfig, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/ia64/defconfig.rej The next patch would create the file arch/ia64/ia32/sys_ia32.c, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/ia64/ia32/sys_ia32.c.rej The next patch would create the file arch/ia64/kernel/entry.S, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/ia64/kernel/entry.S.rej The next patch would create the file arch/m68k/defconfig, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/m68k/defconfig.rej The next patch would create the file arch/mips/defconfig, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/mips/defconfig.rej The next patch would create the file arch/mips64/defconfig, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/mips64/defconfig.rej The next patch would create the file arch/parisc/defconfig, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/parisc/defconfig.rej The next patch would create the file arch/ppc/configs/IVMS8_defconfig, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/ppc/configs/IVMS8_defconfig.rej The next patch would create the file arch/ppc/configs/SM850_defconfig, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/ppc/configs/SM850_defconfig.rej The next patch would create the file arch/ppc/configs/SPD823TS_defconfig, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/ppc/configs/SPD823TS_defconfig.rej The next patch would create the file arch/ppc/configs/TQM823L_defconfig, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/ppc/configs/TQM823L_defconfig.rej The next patch would create the file arch/ppc/configs/TQM850L_defconfig, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/ppc/configs/TQM850L_defconfig.rej The next patch would create the file arch/ppc/configs/TQM860L_defconfig, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/ppc/configs/TQM860L_defconfig.rej The next patch would create the file arch/ppc/configs/apus_defconfig, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/ppc/configs/apus_defconfig.rej The next patch would create the file arch/ppc/configs/bseip_defconfig, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/ppc/configs/bseip_defconfig.rej The next patch would create the file arch/ppc/configs/common_defconfig, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/ppc/configs/common_defconfig.rej The next patch would create the file arch/ppc/configs/est8260_defconfig, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/ppc/configs/est8260_defconfig.rej The next patch would create the file arch/ppc/configs/gemini_defconfig, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/ppc/configs/gemini_defconfig.rej The next patch would create the file arch/ppc/configs/ibmchrp_defconfig, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/ppc/configs/ibmchrp_defconfig.rej The next patch would create the file arch/ppc/configs/mbx_defconfig, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/ppc/configs/mbx_defconfig.rej The next patch would create the file arch/ppc/configs/oak_defconfig, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/ppc/configs/oak_defconfig.rej The next patch would create the file arch/ppc/configs/power3_defconfig, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/ppc/configs/power3_defconfig.rej The next patch would create the file arch/ppc/configs/rpxcllf_defconfig, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/ppc/configs/rpxcllf_defconfig.rej The next patch would create the file arch/ppc/configs/rpxlite_defconfig, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/ppc/configs/rpxlite_defconfig.rej The next patch would create the file arch/ppc/configs/walnut_defconfig, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/ppc/configs/walnut_defconfig.rej The next patch would create the file arch/ppc/defconfig, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/ppc/defconfig.rej The next patch would create the file arch/s390/defconfig, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/s390/defconfig.rej The next patch would create the file arch/s390x/defconfig, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/s390x/defconfig.rej The next patch would create the file arch/s390x/kernel/linux32.c, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/s390x/kernel/linux32.c.rej The next patch would create the file arch/sh/defconfig, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/sh/defconfig.rej The next patch would create the file arch/sparc/defconfig, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/sparc/defconfig.rej The next patch would create the file arch/sparc64/defconfig, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/sparc64/defconfig.rej The next patch would create the file arch/sparc64/kernel/sys_sparc32.c, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/sparc64/kernel/sys_sparc32.c.rej The next patch would create the file arch/sparc64/kernel/systbls.S, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file arch/sparc64/kernel/systbls.S.rej The next patch would create the file drivers/block/ll_rw_blk.c, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file drivers/block/ll_rw_blk.c.rej The next patch would create the file drivers/md/raid5.c, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file drivers/md/raid5.c.rej The next patch would create the file fs/Config.in, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file fs/Config.in.rej The next patch would create the file fs/Makefile, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file fs/Makefile.rej The next patch would create the file fs/buffer.c, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file fs/buffer.c.rej The next patch would create the file fs/dquot.c, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file fs/dquot.c.rej The next patch would create the file fs/inode.c, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file fs/inode.c.rej The next patch would create the file fs/intermezzo/journal_xfs.c, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file fs/intermezzo/journal_xfs.c.rej The next patch would create the file fs/intermezzo/vfs.c, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file fs/intermezzo/vfs.c.rej The next patch would create the file fs/ioctl.c, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file fs/ioctl.c.rej The next patch would create the file fs/namei.c, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file fs/namei.c.rej The next patch would create the file fs/super.c, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file fs/super.c.rej The next patch would create the file include/asm-alpha/ioctls.h, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file include/asm-alpha/ioctls.h.rej The next patch would create the file include/asm-cris/ioctls.h, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file include/asm-cris/ioctls.h.rej The next patch would create the file include/asm-i386/bitops.h, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file include/asm-i386/bitops.h.rej The next patch would create the file include/asm-i386/ioctls.h, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file include/asm-i386/ioctls.h.rej The next patch would create the file include/asm-i386/spinlock.h, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file include/asm-i386/spinlock.h.rej The next patch would create the file include/asm-ia64/ioctls.h, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file include/asm-ia64/ioctls.h.rej The next patch would create the file include/asm-ia64/unistd.h, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file include/asm-ia64/unistd.h.rej The next patch would create the file include/asm-m68k/ioctls.h, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file include/asm-m68k/ioctls.h.rej The next patch would create the file include/asm-parisc/ioctls.h, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file include/asm-parisc/ioctls.h.rej The next patch would create the file include/asm-sh/ioctl.h, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file include/asm-sh/ioctl.h.rej The next patch would create the file include/asm-sh/ioctls.h, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file include/asm-sh/ioctls.h.rej The next patch would create the file include/asm-sparc/ioctls.h, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file include/asm-sparc/ioctls.h.rej The next patch would create the file include/asm-sparc64/ioctls.h, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file include/asm-sparc64/ioctls.h.rej The next patch would create the file include/linux/fs.h, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file include/linux/fs.h.rej The next patch would create the file include/linux/limits.h, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file include/linux/limits.h.rej The next patch would create the file include/linux/miscdevice.h, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file include/linux/miscdevice.h.rej The next patch would create the file include/linux/mm.h, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file include/linux/mm.h.rej The next patch would create the file include/linux/quota.h, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file include/linux/quota.h.rej The next patch would create the file include/linux/quotaops.h, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file include/linux/quotaops.h.rej The next patch would create the file include/linux/sched.h, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file include/linux/sched.h.rej The next patch would create the file include/linux/slab.h, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file include/linux/slab.h.rej The next patch would create the file include/linux/sysctl.h, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file include/linux/sysctl.h.rej The next patch would create the file include/linux/vmalloc.h, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file include/linux/vmalloc.h.rej The next patch would create the file kernel/ksyms.c, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file kernel/ksyms.c.rej The next patch would create the file kernel/sysctl.c, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file kernel/sysctl.c.rej The next patch would create the file mm/filemap.c, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file mm/filemap.c.rej The next patch would create the file mm/mprotect.c, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file mm/mprotect.c.rej The next patch would create the file mm/page_alloc.c, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file mm/page_alloc.c.rej The next patch would create the file mm/slab.c, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file mm/slab.c.rej The next patch would create the file mm/vmalloc.c, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file mm/vmalloc.c.rej The next patch would create the file net/socket.c, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file net/socket.c.rej From owner-linux-xfs@oss.sgi.com Wed Feb 12 09:13:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Feb 2003 09:13:56 -0800 (PST) Received: from bbnmg1.net.external.hp.com (bbnmg1.net.external.hp.com [192.6.76.73]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1CHDn3v011578 for ; Wed, 12 Feb 2003 09:13:50 -0800 Received: from aare.GVA.HP.COM (aare.gva.hp.com [15.152.18.77]) by bbnmg1.net.external.hp.com (Postfix) with ESMTP id B6A5E79 for ; Wed, 12 Feb 2003 18:22:01 +0100 (MET) Received: by aare.gva.hp.com with Internet Mail Service (5.5.2655.55) id <1YAR09K2>; Wed, 12 Feb 2003 18:22:01 +0100 Message-ID: From: "BARANYAI,PAL (HP-Hungary,ex1)" To: "'linux-xfs@oss.sgi.com'" Subject: FW: XFS (Filesystem) Date: Wed, 12 Feb 2003 18:22:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C2D2BB.412423C0" X-archive-position: 2632 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: pal.baranyai@hp.com Precedence: bulk X-list: linux-xfs Content-Length: 46977 Lines: 789 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C2D2BB.412423C0 Content-Type: text/plain; charset="iso-8859-1" Hi, I downloaded the kernel patches from ftp://oss.sgi.com/projects/xfs/download/Release-1.2/kernel_patches/ When I tried to installed core patch I got errors. Looking into this file I found that it is not a patch but an archive of the patched files in patch format. It simply contains the files in whole, not just the changes. I attached a new core patch file which works for me. Best wishes, Pal Baranyai HP Hungary ------_=_NextPart_000_01C2D2BB.412423C0 Content-Type: application/octet-stream; name="linux-2.4.19-core-xfs-1.2.0-WORKING-patch.bz2" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="linux-2.4.19-core-xfs-1.2.0-WORKING-patch.bz2" QlpoOTFBWSZTWRgMlzcASjP/gH/7xA1//////////7////9gtVzr1q5tQAVe imQgRNMQM3aw7dyz23LYqtPQLAadu97j16rhOnffPh5G2q7nXe+K8H2y9d89 5HbHeyBRPXuzXLe2leqJAAbZVGgeg2z167NV7AGhsxIiS9DkOq5O+g6Xe232 6vd7z1qvVAGIKAFSVXcPWia4AdHq7YCxc9O4GHve3j76scXu7r6Pdr2ocu7H e9rqOtD0zYNaMb21p1T0FGg774dwNFfLes9tPdfdmx4nFgxNW160H20J9m6y O9tt1Vtusk7u53r717SV3udXk+322d7mY0+n3t733e3n2999j4rVuset933v Wtt2fXreNKWt2pew9z3ISqdVJdr6eXD6zrAPlVB3X3RafcAFNUejWTZ69710 8NyN7x3LveOaut7L3z7n189dd6+nvNKz7aAX2ecPs0E73r3vr7QOnr2nvbzX St2fe6+7ePpWj6R9fc32pvVrfdCz2fTkuRvCyaO6aCWs92+9h2N4728urKkf W+F2Nzmz5ejqTa7fdAAO2Lq2N7YmTQtYfZtVuZeByA7YZZBazN14nU9zunri 4cfRo5tS0Nrru2+vr3mV2EpoggBAJpoAmgATINJgmJk1NNGqf5ApB4aJNGnq MTCU0CCETQgKeIp6aamp4aU9E9RkNGEBk0aAADQAABI0pEkaUjzVP1T9Jqae gnlND1NAAA0Bo0A0NPUAAD1DQAk0khBAQAEaaAFPICNT9JpNqJ4UyepoZpHp Mj1HlA9QaegRJECaCaaJgIBNT00aNAk9MjTU2kxpBPCnpMBqA00GhoIkSAgC NCJiZTU8TFI0BtQGgHqGg/VDQPUAGgAD/d9PWRYHoAR/jwxDIhEIURIgsiIr IiRQjBhWFWIRFILJ9AyWyBbGQJIg/C0pYf6mbkfhMGNaNaWiwolBWN/vzFTK 2fp+rMjBjepSQqgoa+ZD1l/7v8/+ch8liyFv6P2/p1c5qxgUjSLIkO+FoYVs YIrUKFLRlRIUVFliKNiFK1Cg2K2MBKRjEKJS1FGIWpRr4g5S01NstxLaWFv6 YbcEiTrqn1z14OfaQq1JQaI1Q4vlI4qs7xKHIRQ+UnLmow6KWpO6HRWBv3/w HBtzLafl+Lw35csLlLH+AZgTVAKI7Q15dS8kpd8qOYUiMBDMSoRCKiDnAtJL oyyzCZUxYUthbs5iY2YZKGDMImKRRxSKi0tiUpjHwY2OTZ2pj5XnJxczbW6U 8s3CVslLLThrbrVwV/vnNuYWg5tsF1KKxSttKJbtNKaWXGmaustG4womNnFm go3GlVCyWqqmyGqiDqIVlaNpRBldsGxvonvlLeHL0p1sg51NC660YZa1IlLT JSFlGKbZliJoOddmnZxOHHWialWtrpQ1QoXBZYxottyYpSZC2bGZdLcf+8rw 4snCmBjLCkpGNnybl5yzVy0bVKWl1GuQrN6kOG/sE3BhKWe7632l3EnYf+sS 14Sc9iXMQQUnQowFaMLbM3Z+t9a32m+dPIj387dPLL4sch1uj4Hr/x7O5Ho4 xIqcKNSctuMroLlnO6U0y9H6/6Zi2BzaDMu5/IxqOGYdziw/t/xwTvX4cffF Jfw/dH0efaT1euv9nkDD+wmxNskCoilPfn3OPzvnvShgfi5nqqI+otE0GiwE xhf7v78hmyqqqqh9jB19W/xy4XYfn/w13Iu9pIVGv+CGtmModmXGt5Us6p+9 2m5eM3vhGWIX66G6RDTJpFnWiqiMQXtpUYw5NQePOHmD/h2g+QvhZQvhBYeT MaUyCMKlGFsLQElhMZKlYw1hSkgmEgYpKWlpSMRkFTTJI1UJjUg4CJFHCpRX HICEzVhgZqpk6w+8fApQzTsWhWoVBLVgNLvcZSriIFbllrYsv5UqKCOmOrEM q6Ya1mtDc8y6Js4Ytg1dskR1BKVtBDRwiMKKS6up9kultmDkUSww02yFMIlK UhNQOqeLbuunRztabCtMy4WpnW4sZNa12GORy0zlRpjSk1LRstK0aDElsiBW zMaa7JaXBLri0pNTI3CijLSrq00K4rjXUVo7BRscysKnNwERXCi0qFSy2i2x VWg1mmLiotaqoKCuUERVWNVAwQEQRlQbKjFtGgxlq0VURoJTOq17KDKcBKtk 4mg4NcYt5wOchRKcjbc7E/nkppHTe2NFznCiGbtkY02KoaMuyTA9KrQplbcM +ZZz1LLwZZ1jEMLCYASGMBqQ1FmpdMFTMZrtgTKFYWy4iSzGyoB0f4kxJpFW bCUqg4RZRM7rmkbqUcQUtQy2qrTEmAYUCqMLVxmYyYuYYpFZaWTWtFpJgqLb WXbI3GjTbymia2t5ma1uLSkKM1KxNZrWS0jpcKaYc8T0SddHRbSo8jLVGnqh 0BzW9D1YFax0MGsCsWtg0bLNZjWEZWhaMYYpSoMW0Kb4vH0L8nVHX+Tc5H19 efE/C8+tuD2p5YQaYUc1MJTUMQiZZnFh5Ukv/Jx/GU1oq2duYHZB/KqTJL9m WiiJmath2IZUqTSSOWmni4CobbjYldrrW+UUFSasott1tiKVTtV3Yogqg3cO nbpXIVsn/liPkLZNNtyyDMdrgc92h54gdHKHLSFSgRCoiBN6v2m4Zynd6H+L 3fCpJWCZr0ZCM00008IEQUhySeHcfD9upmqm1jduRouUmlSiYIjFK2OzRqZo 1EZy1jI53b6FON+MBRFzg1ms1hrRVcRpcYbDo2ds4527fDDFYqIbNa1UrVFt hwnvmihm+2Q4ZXTUOspr15d9dejxHe7L3KQNKSVQHmu2+rgIEQmeTkc0urm2 KhUcntcszp5P51+M9OFlUrU7JUTQbPxc6xj5KPKYQ/yehGq2WnQKZUoJQljM P1J8s+lNv6+Rsch/FKAoiiiB66U1ve41c/K7O236szOzjOeptPCwsdIFSLFi yImSMwnuf4O9R81hGEe+alVFLcJ+0ET5o/IEPSTpzpf/r/n6/BSS4r/5P7c8 dXe/o9Ni76n9e//rBMBJiz0+KcpYdMRCxxLIt3J2QkfsTX9FrwafMzWWFy/5 XPADpYlI1LVJLUrZdg+6goPhytY/Lb7b/Ha/nvj7MxfuVtCda/YmVL/lThAL QQ4JOg1JrnUYwOnTrCPJ4vOJLlImmrgvid4Kjv6oO9S8rg/o5+Ebm53sraoF Q5OIGac9W9I+uNfldMmeIHe2MFkVZFJzScrl+Vz93rzb3+y5vyb08fx/7zcp UcZ0kwkCq4ROCXPOeUyce//D/aNnCCl973iX2+6Ik1DdLpBEOFOkSoTp1cRD 7i38/+viebH+bleZeubXsJUCYyCwAyVixZPghNIFYRZDdmmFUrfzs/a+xwDl PsynxErB1FhT/E4z7eN+1n648hJz6rgYTE7W5RKiHZUiBIkTrRRGaekPTj/0 4iK/NxISGCo2XncDwQ6RjNrB1S1K2nuQoqq043JT+ldiDcOH6lZBUOQhOM6K Z1xMSziE2cQ5PPRZoHu3vJmiLlvFOxhrSVBBJ4RFUwSXG9mM7Lzjzv69e0u7 NNGZIVujk2Z8QxlwBSGDAGICkFPDWsA9MPwQ9n8egnn8jYToxTuTmzqwF26y j23E4a27be28uuT9zrxursGV9pxiPjz5Nbu9LagpWsx7mrHhOqBlKH1OODAU CtEKqqIi7vFLmklYpunJ0nZs776NZcYVMc/DRrOWxp1HuTnyopXhDZGPO3Eq 5aUUatGRLWm2EMSCMSgpLDTAFUWKLyac/Mfe9fV9/Gr15ckm0gKKCjsAekD7 lEUjBR+oduEnqPBWoz9D5nWOuozs9EaB9WnnO++kVsqNGSBxysBVg01a64nz 3a2MBbfg8f6+V+b/GJnC925Cr/s/y3Ye6FK63s8OtbI6/2Uj9ldln1dlr+Tv nL0Tix1SmE8Ef/srTlh2UlS6/OV1Hr6ayn/pT/8w07LMdWGeFbB+j14RBxR8 fif4pvXaLD1OxLSmWG2yRwepP2y6mANjAFGZoYA+dgD7PSU7AdOgTsfQHr+i Obwq/1Sj2RKn1vWhX5byE3tBv+g02bcm6aWX/446sMf8M6fO92mKHccSHDW/ Wv2t8x61MUM/plwp8g3lti49zWxYKfupJj/tsOZMhDbkJEhWQVRVK+m56dEq CgfMdevmpf5qVwTeDKFE1F3jLO5gD0+FpJ/A+S5xgglgSgGJMAJMzPRtzBtW KIydv3QS+LOH+WUeROjJBOA7Jk2JT8T5i/G033G+qu8LKH07O7qHD9H6d3Np 3fphl432f4+tMR343ZUPusscaxFtKolpxBd5csvOZMLb71H580+Lx314JvHD lTXPi5Z4ihdR5RCT64GhJ8fyNhi4gV0lpr9TH2fHgbc7/dHbbsx+RBGbZQF8 OQlNnGgdCI0k1K0K+GibRLmJ3+Ho2dE5CoG6+WnJRimmCMDsYbdKN6q6dQVX by9t1qHFOerwzWc5gaR1LpnOIXhqnGXeinEZmyMsO3LEVCUDb9DfXhaBo6zz wDlS46IQOnOpRHH2Afn89+vW3LnlccZiePQsLt2KadTem7E85xDt5ojEOrNT NNrb40xLeXdM/lbNlZCsN+LURmDONFDHSE0Yt3WrZ42LchywxdWk7sS1Rlgl loUqowd0L5DnkDdn8D5nOVH02ZEkWQvZL7IYviYXiALkbPo5cubmml8IaEAk 0EWVenkoenUXfTyvHkYN8aY0vkhKkcDWOLe7OmPgvdBOHQt/PvgSZeumJ4p4 hap9ngHsGBNcifRutnLy9cEqXRo+E+/wUkS2aiyu1TFDq/sc6VhvqwqufrUz 46ZNvGh3s3nJKbHktXG/hx7dpdtiTEDgEMUqWFPhhnOB79yGmaPyK+nMxusL b2/Dyc9rwXjlfrk1ibR61aaEvw4+kj4pz3yQXw/Ujxw5k4EUadHrmjv1Vd7s 5taWlG073vQ669LvvsFeVunhlZm1y0D500zsT9CVzkXjnsmuFXq5bSL+XvuL wssgAf0AABQoepBqIkgCgSAC9YmkAC4b+n39sCCXxoNsUePpoVThANkhBOUS oLFQCRkPFFQCvRKQfgtO1Jo/rp7wCAH5liPzaD8zU7BJNRjV9P4fwymr2+En YK/ylz+P4n6qg4fBxl6f2Qes+b/0jRlsYOznMaAbpS2PUDat6S43OmXN0MDj MAsApxDTZdwys8y/gvr/6OBvk/8hFV5RgDX6SP+2s5HpNFPxx5PGfcKQY0pC ZO4yTOyZ3cNcNVZoZqI1qCqww/9jJiMDTD6Q3z46PblJNDC/I1Qxm7nGsDfT CleN6wQySaEzTR6f1/b9B/P3eIX/AYEe2VPSV4xwTcxS1YNgIonElwP+PuWs +B4TOk/m35qASb5kUWKoiPic7W9bMzBq9gOMwBvOb6g9/s9+Pt/PYSvOs5db 5+lZcthuPuoPKafnLGvp7fRMQyIiV9lmjgUBdKqrRlXsya7qtLIVbQ/hRQL7 E5J6Ozf6eRtqg36KUOKmZc9ryeMy0xxHaefUjJMwkg1swEMwoiCJAXyNEM9C vNKIdwQD9X/Hr/lnU/DCVVgODoPMnPP4enQaZlSwbA+Nxnadqto2LUktUPMs VYgIz5rYKAdfX8h361uPP3eP+Bt040QeK/59XM2+3bOcdvxwb+Bp8zsUG5lw thAD00Qp6YP5k0Qq49IUAemDxkI7TfQPYxjFjAHdBNSHi1Sso8MKD0QDdyHG y0MLxEukxgzK48DdE9eG2wwubM0sh8Yav20p+RnRmCUsrebArBkdReJaED3+ YLqaGDgtwxpOYPdjPy+2m05Pcdnjnrn6/ZVFGNtUForQ7b3mi8PtnnDhW0vw 6OTOumzkpRXFEsP8IeYHnYPRIop6fN0S1RNxaILLqaKZxFoLeNU0yTWEO0PT iegejLxQ5aBCVZIaTEG/flS33gNI3zKeXtx0hCh/TEJ/OuHXeU3NrZnhTyIO JiPkNKUPJuoyzszhA7kFgmigkdMJJVIb/n/91efXOv7WibTXMn4YWQ2b3bFO uke2VemUWWpd11urb6pUNJH6r/dft07LWLph9WYcPRryq9Y3LlDtwkXyLTXt tlcc9N2dlxtvfYWTuuvSOZQWO9jxCRp7nnnN1sCn1R1+d5oswRW+W7brlRvH aYw1ltI2XTjW+xU1PjkPRmNrmfRlz5GELEK0Trf8muupX91WLGdp/98n/vPm 2UlVFygknbXuJbcJTfP8dfy/Xw/Tx3vtejhKPXCFBl4TjIRjYg/lgFxMyasj ZJGwCAA1koiSnhpThBhj80TRIsAGiIZmokULCGtiw0/S3CDvIHQU8Aw9ITmN JIFJsy70/xwSP8f3vjJxEkQSJavonBJ4UNjH9v6XdpFEuxUyoC3enpQS46Fl 3FI7ic2pxHjK7WhU5ob5rnaGtriqYNq6SJdmMWOkXTWiYJgU1EW8W80ne3mb ijKnatCzBJfbm95InSPZ7Fb4ofpJXoHCtiPw30xN/u+xwek6wjP6VRHcOsfp l9fVlPZEKGEWSRJDw+zL8Nr+97QFMNJwQPdIQMAkgoPE4QJ4f9FDQ/ft+BLz AMwrD2BiTQU1RALy38hjSyMfwteYMpBkVE+n6JAB+jrNEPiy+3gPOJ2qAJ1Y YMhkBICITr+75RztX0iA86Jppn78SyXZ494YkyhzPw6pDOhpWzUMfcaUjrTV 7gGYl8w0gaK/ed6zKvz+r2AMx16c9mXrs9BZ6qliQJAluP/G6Oa/bH6uD27s 31/F4LVceGvtrs88rNNtdQ0g+gJtANK1iNwMgNpttGMVVVEFERREViMWEZGI giSC6bFoh8W1wJjnY6OBu9/0yGAN2Sf433L++REN8qaDg7nH/AePt7fVFZxm BFlG954znu9RlUOyVPGpeDB/yE8IEgdSIAQ25/FE75K+pBL2mE2PmH2FsKfs 5y4L+nA53Te/j3ET7S/4ctEbYn6zhTVxqF+bELAkhAhJc8ZIx+5AY9w7z1HO 5Kl3Qjt2PEri+RkeOkE3exWW2ooYIbmF6/4vndSMgjVUqj+n63zzQxaWD5ah wnqMamudFOIfyycezWzKs2xDjSIb7keeuB4cP/NxtvVuuScJxcDjwnEhOOOg NIytkEltMke8XUoTSs+7H498GiwMHTfLTdKTbYGQg+MOIy8s6IbOINHjB3WV yvNd5NcM91HkmlsMXU8sI8CZpFhGLv0nQ2KOiZGnHDJMvpGAsZIEHd3ulAk6 RlM2Bv8FnbJzkk+vA/0Lr2qtg0vaJIdoXwZKnQm6ZRMHcOrt9/t97e94zn76 S9z0EQoUz3Sj3qipWcE6kCdFShJW0YM0ae6fERh5VPEGUkYLcZ4SlKCliMKC qi5NK8GUwzuh00M1IhAsj0physZi9VlhKS00xohqtzUvKIRZqHnefhivj2S4 9nu7FUp7lbafZH7EMAfGS+f3/JJ0fZp8dorPx/Mw/YwkayEUQQIaSMu71zZg khgmDJVT0WyN1tizFYLhSsxClUtP2scwPAU8Nxs9km00bGKzLC13HdxZihx7 HFDkHeJCk4pTb/S3E2UeKClgaFnEQ3yhkl68z7syQ3xS7XAKTtctKmgPJmBq /dae1/qgYOpz+v8UAMwnYfKxmxvSnBijMlc/z4ExiqNINYEzI+LGbWWWwlcl sdPB/dI0y2zJM1TFyh2kyOVxsbp2DRUU8oyoLHx0GkNTV7+tznrbusvsjf0r P5dDlErN2u5857htOBwV2m7sYHolG2G0EJN82Hm5Gvb049sj9VV0U4UvMqKG oSW3aFhX7Dq8sjog51JIyEJImeneO7ykp75H7G02Om5etjs3v+yn8cz64w3p jq+54iNeKZlTAKw+KImkqpC7bba1otV+7svRngcNJYkAYkWEin6H+DH2MaY0 63Jv39GdePExbE2RPvM6MObOqKd3ctIt87ks9Atj0d4zNQi5xZDd+7KDFxnR GJ6M+HyH+fs6iEnm2OnRnKJZWFUaSjFqWN507Cx7+18br97hYzGrbFZK7H90 7F31DNJVZM7o02qRS9N52AJFVDP5XekGL4sNqvKUNbZfR7OeS5/GU7O7xeid DMNaAPYO/ceXyfeoqqoqKqErNgt9brK2HG7ho71+kjD7pjwWxbEYp3JH3U23 SIQ/Bn3W+8bz/N73CkMDto2Td/Hr+Jvn9N5/Ny/cRvbwe9gDBshM3I4PpEAh 8J4yxhnB2dio1119vMEv048v5xzeYkh4aSuRnKl5bwXH11/Usn1+Xi1dSFTe rq6RZR6ju9CwUYTHJyE6ofD0ef8a/ZWt+ULrw7bCppwfnKD6W0z7J0lFsuMQ Y4ze/nvpXny3ysFnqmStmzzyi89z6Kl3NOTX0cqpQ9BMPqDkdl2spXHKfjp5 xHTyEjmXPwofT9dSa5ryXiQ9JOaOTZvP70PbeBuSeKj/D9eOyboL6aMxJ2mB qZ0O4nah2czfNs8EqSxYiFLJhKQi3hCl9XgXU9fsxi1Mllyzj3rGlHhuenfr OXvbNqWWuLE5dMXq7FKqtN47UZGeYz+VNYeUrGtZ3NYpcPHaG1NyWia5c4eW 9uaDm2lk/LPGWbDTq2qFuFj1u6s+bnuiynde3zqnh3UH28Z9JWlqB0SN+cY5 zM+GOGBZyW1ZrI1pgTIZJvInHHBnZEDiRu1MsazKBRebp3RKxV1os1nMxMqw 3Ug9DBKQDsEAHy7+YoLpidt0+6VAjTwZtGjVZOB03J/0At492Vq1sDZlC3Lp xxx8/DRpqWo6trvA6jDxigTYZuyMJQAs7+ltGqcbxsLWTW4q/Z0TeWjV3de8 LNKvqoW56TuRvy6Lp2vEWPP8MJgE2ojXy1Y23WtZjnaXgc/GVqW03fJlboID doWl1mlWqJsbZWYZ2y0vbmLKSmbXgpdbWnoqkFmPm8rjoSTuVC+5DnVVsJNL dTd79dA6EJtUW8rGsMelMJDwY73QupN5mb0qApRJUkUtCkUBSjUCyQ0jDX7O /wNjZvKdPw5bUIXQm9/RrZh4dmrv5N6yzMzU6Yuuqr40i8wU+WGDenijTSBf vUNJpQ7O/pOhptkUoiHolVR4hxDtQgv2YmrZNwjxZoWpoQFMnd2gQLwj4odF +2ika/WTv7Q3n3ouqiiy3HgYLozpZx/oWCaWq1mxoZWStQbA6c58ZSPFSmlk 0wZHTGIdB0cTlc3n6J9uEdT5Pnz2ZqDfPonqo+bMzSy1EolThBhZqw0rkt5V 7dGZ0M1YaKv33+vC/uH43yWoxdha9mDZLCLrzbPz7JNBqsWF3CH35jQ82ge9 JPOXjRtngCShnnZUOEGzw1WbOZPcvuQblbPwOX3sM28uUM7OL7dWYKMHzWbv n0NhxjZRFJnJG275KaKdj+a/fqdmnqlAWIbGzqrjLhEDxodE0aYwP/nZpfMi 3qjjZfGgrVK32yPbc8mZ9keXVILcnHcF7cJFck1Fat19r2Dxue+4Eja2oEqf BTIQhME0kzpdeEMXNsoZIBMJXxLI/HHlHQi0KF8rSfbDA7XScqbN/92r0TBC 1CxLMspPf5mpLRBd3DKmwvbuLvlPqZi1Rz5cSEXXcsR21jnjybBMuWVt3NPc 8d6r+yLgC3fOFv/w1vJHCJBIU7fCJx/tv8ldeRKVuwfNSJA1uVcHT8e94Oe6 0XXqPSiBMVdxTw0x6KQ9GyVaj0jnj8RES2d8umx2ofttc35u2y7E+W1aYbbP jViJZGPolPVgUwXIATCYYhMxMMARlKJjmjjMx4IBgWov+GA4yrYR33Vkzmro rVbFVkFEJ7VhAlA7UcNWGA2fd0aqlhe+3Ea/V/FgPMcg9xZeRabGTDONnY2H YtIwSCRTLFlSwbgWYDLLLAGSrlVSCmCAbIQcC7RoxlwODuiE1ZsX9G3Sc9xj kFJX0ct3x8o9aVKvC6kfd2ZlJ30ax3H5TpxxnkvPTVAd92NtP1/f+n+rDCfs /ML65aJ+wWvrhnl91utD8iAQejr48jrYboI5tcC8jjsqfR9tsWeHwi25+tCM b8OyUc/TiVpFaKJGC73+TfV63r6x73X88Tq9cR0uB9WT5059jn17g7/dbmud yx/Lxc2G3Z57fJUndRtdfRw1Ty6Dj55XxsjLBINtFOm38Nb+J5GuoyZFUUGI dLeOdOlGJfeik5JoIcReh7Kk8p7GR+TBIvHMDHNpxvTDEiZjCBmHYpxizidD /0ljjqlntl+u0RnXoTQL8HT1PDRZd7dnVnO+ML9mjjGvBGl3qkbjerdTapiL vfd2ciTFgvb3zidYJn5dV6+NuYide57vnvHjt6a9hrlD4mPuhtlxWlm/ei0d 3smbIZ9uptpJrlm1mp9Iy1l76Orz5iN8/fqDVMq6nsPxN28q8fDlyWAZseT+ WvTe/guRuDoBGBEvGVPTyw43OCy7Kv8gxOJTKVCHLPFYB0g3SY3lX3EYnBna WelZtVUUSoo9sR8TlKBWaeOmHIXQjRGEr2ptw919OvNzatS3cxlimzmzzNb2 X3Rz1/Ws7O9oayuE9iV09kinJ89KNOSch98pRMtsuvQ6rESpWTs7T6dbXnPP Y1c+uQF3gK817sNOeyLdTP13EtZlnzYWyMOk2AwkMkHCksih2G6JBkzGcX1O CU8tax5o2GV1wcLd/kM7Z5a5Zys3ksSNmwShisiuq47v8JXaFtpqs9a0Axpz K0XoyzkleQVkfLPde+O2tsp78tGvDJkfudnMhEq43F8yGZElUZJhj8MpHF3x 6cOftkZXi7enpvwzJpVlKUnpsiU7K5Nu3XTN33o6P1q0/BSI7TxmVWmA9Tbg xRD3REJI5F5AUwtPK7ZyFktciUosRK/HXhvkW8GIdGUspN3PL0djz2XPutJw pPGNONJolsjdXOxHT3+aV5f2WA4IsuenNr280WWB0JIPvRquLHtM2ROXHPK9 pEgHEybmbjO4UvLfWOVCkaLpDOsyet2iuKz4wT2uBfyD7bz8vsm7FJ+SqzSc zyhSppko2V76Z4Gu4p9ddpf2odm1dUT15FYW2EeBFgDN3xLZFgR/L1nXbfUG OPp7pptK8HNNlga39b/a79FGfybmdWrO40bh73rZMXfdP7o12pBsHB2KIpxk cBMFzsOMEv3jskzX9NHt6sn11iJqkSe2SxKciuuN1hxJlUW46NZg0io4Dj4t 4ryg1N7PUrOuBOYcgZn5x78nrROu+vqOm6flBkRLRLwQOwxATQU4O0QSC5dn Km5CRCd+w0x2Nse3Xsg3YcO0Y3lRMkmRNmAJobTnvw/VhfjYfH2yvmJC88pf Kt+/eucXoxliVxueyzdrvyfYbq86nuOjK+oP5+BzQcBA/FfYxVMynaNVgeoq UEK9O+pYL962ZONbvfbhntZ64x+dc+1BeTtTiyvpDn03nGY46w8k7SX1kd67 +nL4Hy+p3zvDTb1+V3rEKYxOLFLy8S2scTzm4+HgduwlOevh01crfT93OCVx 65muMnD1+a63o9L4zMt0EV9xHdGNtl5EdL690i/K812/TukUufmukXSmi7KK yx4Y0KuVu3fhA9b8FpqDdGUrM+mkFlW2ZW6drkziZ68cVxb5WZb8O/FaRtYE U8SOYqjw8KR/TjGCrEF5kpdS4lT5Tft+UTNj5c1+Nc8t+/+Xba7+b9JuteIM uO5e6ZflhzXH25tzS4hNhkhgcDvEzOCBEGMCRkilvgJzen9J6seGZ0eHYYX9 Gl+VtfGmK9iZgwQw1ewaxGDXndNjw5VpYjonI5zEuui660kPRU1TeB/a5NsD cWUMi51zO6EJXP1aQQDu+SO0Vg85jy2f4u0hmZYKfC7q0PhZXK/K26c/Wxss BIIkJWS3v552avnIt5XdmkbCYhNQR56lMOM2Z6/JB2G+xuaSUZ+6B1+ENCLD pMwUsYmNY0ZazEphVFEMZc+W8/Mck8emn5YiLuT7cCtg0itr21jXVdmkZnUJ 71W607Ii4d7LOkVkzIdvoj0HTmXahaUP3UeL5088modWlmosfGV0bN+4xtws p3b7jx3ljgPGPM8OyIvlFZ+8pe2FHOeNej0fSdYnOd8+2VuONlO+njivPN54 KhTTCtt+zqi1L36fu79Fpltt9XF9nP2YmHg9mh1hz5LDU5mvfBiXbrA7GN70 PL5/PxxPf7vatUudmAnm54jr4OaIDRABNmIQwJDGE6+FsYzLB5GcQ3EUVDK8 YwwCTNgKcctDMRMeQkKRUBJQeU+8/qel2UrQBN91H+vdx+S/uhzzoDJ56Ifq 51UP6F66B758nTJIpCQgeY08v7ghA19NlWySBzkSmJ+aVCMVkEI/gDuwCTKo q+7VHZ2+fxnDwz9p1ftL8PCh25Nqb/c0GPajv+fbYB7+O3dKLB0duJxEGSfn chCQJMYJFFlEKyH7SADIEQCMIMAKfLZfl/3f+H9IDsnZS1SpSg1YCQtBBQUo hWAsEJS0hKoqqKNLGSSxawokUSq1KUtsFkWiiiQYka1ih8zmRowaApFLZLGK jFRBV/niYToz7f1H07Q/2DFA+VA+0ciAiaGQ/8PtAJQYMQSBIKwBTlB1foKA agOorEoZIQqMLIVKSKRkEARkkRBBBYMRAEYqCKelNhYmvu1aVsY3x+4JcwXI H6q8hRcr5DvUcTFEygA/hZD7f21Y3HY53MvLfDveIE7Z+MqISd5TbIVn0Xho 1oIQwhGWvKUkQk41fvIbTTzqLMW3PH8Qf52Bf6oT/becerxYEhcinrI83+mB jcTBjGDGMYMIH9sQ2rihW6EQIutmRrgTh/HmBpCHTBCYRodp9HpNux2hFWo1 0SfRB/AmZjoTE6cU5UXC41d84WRfSdAYGYfwuI3AjxgvUrAG3J2RoA7dYiqo CJH5/XBNGGd8rmsKY7NGwxhI7+/U7nWjZ0GRUDONQM/v8OvKZs3QW5xkojlO Opyl7lUkTGvP9smcGyTFUwXppclfLZEsZ0pAgs4vGf/L/zf5yFb623LV64YP okXv6lP5slDjwnHb3DtuzBDyBoHL7PdbarDgXkGH3wyIGCJ652TcNkSvWgOb JB6CEjQhtAU7WQLGZPYe0fsIZd39pkonFGp6ruy1eOtpe6FZa/1TaMbjdSbA qjlCG2NuB2bcpsgg8eBu7p0Tfvz/abE05jafre5kNGOIaDu6Q1n1SScS/S9T u8WMkiZwNgwKKPYde57iYbLtgaESH7xRrSXIGUUzzrYw0tdbRMJ3HDqMTp/K RufThzJrMOXK5dvPIdqPmJUfaNttwfWcTAJN14PSxJURx1uNqo6xFjMHYkKK jODlibZHUCKt8poP5f8yUTsQH57xxih2gcPCgfgjLP7TWpZpvr3VP5ovRWlv Myt3nkfWzFgLw9Hng400gvEdz8SI2n0DPJnt9E92wB5IsnrCURKjN/Nmt4d+ EPPTc8IlgQ/Sfi5/vMRaD3l7zdOKME65Xo50tezM7GKF7fr3OxOzXzfUqqq5 o57z6zYZBIJonsNAy2XjsXFgjIttyYEifXKq7kTv57qW86NtQXKw7CeKtRPe rgnklM4A2jJkNgG1hm0XPIbQlb0J3wm2GRNQ8RzpQrZ9OLOF7uSLCIsFC2qS +pUDhSGgvKRxnJFr+41FNRTm6EXBKZ4hNLx3Du/FY/viyR94u3/SgTr50idw /QJmJFhc11LxT+qy1b+JEK6sQJ38cbUEz2uw/yPyESSr0U4mRS1Otezo3UPH Qc6VtrL8Py06rsbbWwQ4ZXRAbvl4SMuvVM2Wa+hzI75+EEhDUxV9AdMyDyxN mtq5+jyVUlN/NA9GuiDV6NTnvTbCg+tXJunquiyvZvk2Krk57jECK7XaEb+x Gfipw+W+c78W7BDSr957+vUrj0fnXzolZYzSWyThK/ljESfpXlxhoGoXy+N/ H58WNoocTNeXHXUu1NleWWx5y1nzT3lq+Zm3bWIF3u4YN0tre2Thu575YFXr U+Rb7nbBNN92Pp5r7Zd9ttaY7llZuNHLJV7fZPmW5IxCCN48WQfRKm2b7Gwt 8s+clDSB1/eI1gytEDms2E88Il823X4gkjOXo/rp/bZ5vNcZ3Bzms2SRcONj qsIYsay9KjWMhrP7SKnYfEf1t+nIOjHd6jPVK4Jny3E47KUuk2MG6Gy79G+j Lp3vljFrev6NWvgI8/5ly3jg4bDYxUcV9kYlOEgi00p8j0vIcyfuOL7rfZ7p OrVJYLJGBmKTW1nNUUJnqQZc9IobqN56yLPiwsN1+yQ9vIBsxkf2j0b3JE/I hvEYdUdHD28Sp6CxkkKVX1GkcOaZwaHYvg0vkePn5sMPRS1sT+xKUmn4RFB+ iH2rkowFr0+MieDsO/drgkgd05iN7H8Eb/DNtfHYOhU66xGT4i+5Vm8O+pSU 7OHr1nbO08G2CG3ubvXJtUHh5LOjV1r/V3lxR4v2Si6+JXSaUme8RQhgWssj NlA/ZZwnaA3JrWCxgyO8du8lWfzXH4T9Xi6/V4muoJO76EZRAhXDyNrtKvks OZHd+26crE9LYtssrI4b3LBVmq+Fsp2Ds4/FvLJpc2mryNHlUmp6QrpBO8Nh tsmkmdeG6SRBYP0+iR2b7bwxk5SM7k8oeVl4Ol5ruS67Y8pRXa/VFN7V4UZH FkxHpj9VuP3UMYzfhxmTrOSwmYofTXFXd1OtzxYrJ8MrfXYYkdD4cg41zHv8 7nLZs47TXWW7YK8z8vUHBrmMZefc2zv1MD0ke3v9I1y98QtOpjSpQmye/5/q bdF7brtg8MyNlA6i3MNSvzWr5x9WVix5t5lzbms2fJde3tXRnfjpeJHBivOI QmQ3Khzcam7dv3kridYkpT54yfJUGuCHIMS5z+mtZdzte0crV+X7Xb1+WL3u f0/d4MYPleCCpHAta2JijVhDatWmai2wlaQF+2JYh1K/ow0fI0fVveePKdcZ dZ9p3vxn6m45mL5Lv0+rw5vBSa6WzXzzz1q3LlOd3PATzWvKqvNNsXIqsLe+ 3drpSVe7ZJhPKdmdX4yuqsvFv258tbZPPhrqGCRSQfxiH8ZJBRZFFFhFUUa0 FQSKIHozCYwFIqKCREWIJAVQBSKoKpFikVVAWAqChFYiQFIgjFIoLIxFVRix gxYRJBCKQSLEjEIQjCLCIn5y2yqRgqGMoIgjWgq7jJAl+5oLt6AAN3PSCBhE VP4/T+M7DzH09v2GbptnbgVQZBiKTGBAoyRZGCoqRJUJS0FkokJEYosUmSso aQxBiMjqDAJYHTjJAwQ0AyoY/wBQUKYon5AFKQSkRQoUHk+aMh4o3AU5+2eN kT4vVjaXpqdtUFqz8lcN27iC+LAA+MVXzgCmSrDMhIDCEKxBVJEPBgFQANIL UVQdh68Dr5tfj5uM/q6Hk/RJeY4HT/7tH1+b39PQ3Lz626t0dUVgeV+rZt26 tm2xtOvy5ZSnuGM81sTKG9RsOMhUpujmvuSuR57beOWrZux/8JsWsOj14fq+ yPjETQaGgjaYhsIPxnueN/39zjV0uQG/53sXcYHKNxuqgbv8WNlwCBlA4ycw ga+XuPjFswtVa2pXnO5B+swuk9gFD6B3Lnut9wlY/0ERyOgldd1n+gNj8R9m EjgZ0MRp85tdHpYbnPK3t5JF1s23s6Eku/A85hLr/V5umVqaiO8j6Dq6G0l2 rxW2jCbU7/K3NFPWbO9Lx9sfbU2AXF7Ia4kDZYEyyJkIRa1Bwypb5JkBOrx6 nI8nU2d986RtHj3CZ0hCu6yAtyxjNbW6G63Z2oa0JBOl++QbubGTVoYOBcQ5 DKEw2poXuTRavXKGnHohnLj9IfpCliSSQgSApRQYt+TmrafJkOIk1qaxj3hd 9N5P1lnmpYzDI1ucapEuwlsSFIuOTHbElAzjggZCBZlgjB9cilOSAgk5wqSd GUQSUO7QPpkYbUxLB6DdUwUvLnTTVF59/hrA/LdQHLMxZpDtITOIQjo4fX3E qFpglA7FifJa5Uzd/IlFQ4hyXiHclOL0uIEUb9stYvW/JNuH143MR2FQizcG aHj3Fr38tUGjT1fNkWyds2PbQnrf0bvKofvIHe+Xr8cvEpw9JEJRRzwnZFsI m7ym85cqvkZ1b6WKzN6iS0oWszmbFMzWdTN1GFdvjFXYsxepl9afKMY0lOiC qzWFmMxL1okH0qxpnu4fGdKcXrMY1FtTwLOMaHeXziaisOqxi8y8Zw+byJ5v Txq9PeKebU6aZeozCxcOVidZxcWZl4itVrIiHxqNZjTIijE4xN4rVxM5M1Fa hRmpV4UmIHfOcZS1FZwa1U6zExOrxFTMvmoMPejFSlMDqXidZqawkqV1MXkv RWJKyVlYtnFLIKQ7zoWFXnK2stwZ7+LnKRp+YfBmBAkART6oqLQClC/VEIVC kLCp/sdxCOCKl4lwFPfLPX2msohCzgDENk/qh9XzFAd0QXOqRairCAKaqIYQ u0O87xtd6AHxMi3y7fA2ISEgZI7yw35SAB0YAHqxksCT7v5FRYs2I2y2ylEV RVFig2BbYwjE+piIGENOBEORCWJUnIxVj1SxQNWCrCJAO4KaigkYmFOw7Zxg jA083etldEOYgePsd+8JFh0VKgVUkUhmGRoGA84XNCFjD15KP2RTteJ1Hnv8 0cJ4ig7Pk43zNCRTUhgSkMZDs30c04mPwiiTJpCw9lJAkGyd2LsMxZxL42Xd MN+GNH72kA12H7PiwiRpltFlMpD6TR0/ktuFytsO2yePfPXnv0lZZnpiflI/ CKqNVanxx4Vu8ez9I0e3UsLpRatLXJEtQ5ltJzVtqqlo8tuGNnsc8kV03vVZ sxov7q5mDvd/lDXLLVefVIfC7LdE5uYbpSo9uda3m0jhbwoVIEM0112XdxWD A3PbS5S/bakIVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV VVVVVVVVf4v4j7r9mH3J/Dkw2+suxo/hXj5P+XwOyS8vzQx9voy7/Dlvl63r P5pfX6L19r1rbY1rV5ji9NuzhV1ZxN3GLtxbt8VyKeREkkbGMaqEQhFIRJJG hjGvcDmmTGLjtKdY45U2vqeN3GVyoRb4jCt84zTBhsuZVrSKy+58ruqsrouS 33VWHYoM6IqUa/GR8QzNRp2bfRBsm5V8owRlxfCm59lXE3ydg+MrCLEbtrwH CllHmWq+uFNW8MJ/Qh+92F2c8HDScGKPx4gOdgvpYAYO/l4hni92fkUBPzSW aGKFjaGyOSH86llMyLCyghZLbF/4ofyDiTd2iAqMxYN/6Y0Kaj/2iFhiz7VB 64YLYWikgsj/usKkDEhUUgpE/ACQpP9ANDm+72LzeafXv6vGSEfEA7CEhf5h /u4xny+MgoMzA51jDeQkzeJHeDBM9L+yJU2ut2FY1vrspS2ZSyxWWwT5rPbV 2RmHnCIM3LzaDlBgmjW56ifAdCGksZmJcCB/KvKvLynD2pqoVX95nuL8nbeR bOSyRxD4EcAMx7AYgvo8uxiQcHY0MeH66MGCz73MebU2haogZg9Qj4UDlJqj 3oKjSJ3wOQFSANRG0BmFU1ByNQSbZRRseRvAU6DS5gUe3i02nWiZcqNOFXgP syX6e/5HA3qHpN6BxuRNv0ObU5qSQciZWlPD0i8JbYzUhP9fEfi/fYuAdkyF sR/qTNwCxU0DqY7y9DjQkmZjB8vx+rEn5JyjGpNqPfZWpcyn4LPJlAmGKEZq NSa0+9uwjDWkewkUvPXa4sDWi/EkJAmLBqAIVAFOUF4Ziq28O9Q5NySAwK5a K5q2YAkBmOSrpOFR+PtNrqrZjgx2mW0O4SY6WqdTnrOoVX2Dh8HGepeUBIDM XpL/WO4u4fkZqR+Vz/WH90+OBghAIELRf8o7zxd/ut9xmc1lLPw25rW+7br4 OUJxyFvGGI6Cyo1yLpsRDlnXbBVmq5RNCYEmZ0zP7+3y7P18H7zqJ7PUPb68 5xecfPOVq8FtZSrof91kL9vcXS2nczM+Tfa5q+Dn/Po7yLJ0su2Okkortlx+ jUh38vp83I58zmqrhbyzMfa25mCJL3tuzYDMIYaN7z70rzpvpCiHSdGnupSB VBw2WhbQaUNZwavM4m5204ZDoX7/jm+d2JIgcy7wltHMOo5sf8XUMdHBe962 LeYseBMZ+OcYEjyTunQskwaIyzGtfgOMn6+9sty5vVEzE7N83Po/R5b3N7YG YWzy8nbv4WO+tqN7WWSao6vMv2d0leYgyBx9RrbSxaDAkke08iPedRG9f4mh 3dPTiZmHLCTdZBDbhcUKEUv1qQrlDSAFiLgKB7oLlPOay3C4oGo+CnHv9+56 yddoiiB/wY75mc1qsxBN5fSnKlE5FklF/auK/2UhtRRzFuRM5J2sOdX8OijH Whm4ZJIG/B1rS3IHPp7eM21xOHKyLHiaZm68hMWhpRcOQXfnMlCH9fQMfUTt eMcGkpw3SpjeFX8yT6LRrv5byx2LsjDkNi/J7Dkq0RY7wJSiJkPdT1QmrBr3 2F26cWgwewYA3MTU/F4A7nrIjHwPmO3XYAprr1c4myA4wLkQnIQCZgsD0iyB ONfLKvlr44eE2ucSWGMTswQqPyq6qiJ0nKJPMiV54cvR5efM2Mv/vPDkUwcu 4yvhJJu9B+FQPm+M/tBOwCCsAiF0PGgbLmSz5lf8O7B07mc83zWbM3w2UY59 z7zLlfILh3rK8o1esRDqSWx8pgzSslL3mDJN/NXAlZYT2rC6mH2sxYDMxdaO JsrjQaQwBjGQfAu7kT78e71M6rHXpkjzcvbsJXTM2/wBa2WfrVlhr02Vfior n0fFYewxsqX6PWNw94yY9lzh2x9bcODGfVmZjV9bi8enRX840zDFmNaumYnr tM+SBm6tGZlrJlc8t+yk1006KaCFGxwyb5q5Cb05xKVPRU0TxRXXjWy/7WRL OeulOeiDHqM4B+33PTDRaYBoSd8onBpZqGCrGsoWKqB4szlulaX3Fvhd56nq bNvBcc2rh3PPecYIsRLm461cez4nkQdnxyloI053GmkJSHdRFnsnS8re5aIX XyYB6HGfRnBWF4tnPDdis5XIrxSesSRzzfZ5jEmfGU92IjDv1eMXgwhCBAq8 iulwzN2OD0Tjud3t7yiCySCh2sC+JroQ77rYK0Z4eCVux49+Y9X4C91vtUSt zG8FVLu0TiD++TSGLY5b8wPeNN5+nRs2dGuDZW8p7V9Vszp8KSvQadtmPcM1 9yuvuOy/tTumSSECInjqHf+RMZvSUnfR9MiJzdphHCRiiNaH+cK13ClqqSK8 832kKk0gCknZniYHDA9DFhjAhwizPj4PjWtBshJ+3bt0pvqMS/B5S2Iw9E4u zHi4RnGOw87msw+Y4hO0reXlLRFPE8O91uXSnum5zzkc4Jy3GNEQwMxR/Q8e nlnUY3z1CZlt+6iYdd5qHlJEISdN6jM3DefIPefPoS4niSOfOy8WaxnpzF08 4vOVh6uIWMRmXx5+cbL8fQC+uMx5+fNNjf/gfyO8t1q9KsZ67p3Ngk+EsAsL iZ9t85yJ8ZjFESkkhb9eVEss+s8pKqWmvLsDMfiNB16TbveZeHFyejMjvSuk rLjoh1meN4Hty44R2dtDxx2M2uVriZjVP2IzeFb41owbxZpA8rd5V6L6eeOd GUO9Yq4yisBaBE1110aqDh9YfJMuomHd41P7MRy9VbuhuRHYZgdAzLpuc8vw /hsS72Jfz/ocCXrdfr/Z6/JKVsirh1v5X+4h6o8zf3YM47JonN2P3aVpWY5L +n6fw/ymwrGq1kkI1wDn9sOIaMhTMT9P63DlCcePXFVtcHXyjknT1/X4yRwn 6u8+AG/z/d9j30tab7ao/e6+osPt0BIJkgBoVKgiRTOAtoi4GbWNsq4Dvdyf b1HcWeT69m7h+jHsJIqSKlYp6bbIes+icBYTJ+EFsFKNH5qH/D8C82pfvu/0 ejA7UOiCigx7tWc/7Kf0QeUENNJNPSyOJER6RMcJu0pnq1GmZ43vsswH7CZx 2kD3+vW3PF3RTkesrbtKM+2k4MeeK7oH4bI02zkVNWGXj/M9lmunYrpVw7J/ 5KbDXvOi5pyW8tcmmeUsg9ESnvKJxxZI40cdUELRDtvnzw60MU6ZMfD2TMyt 25Ig47vS8fM881jt9mTZp3QSg4xujMuoQ0J/anlc9UzMzYO+knbLU5Yh3WqD 2dMxNOLMRwP6/oiZZJrTiwjMNO0PLuyTWiNSg+qclDHg43FobZYOcEYJr0xL vc+9pvLRz4WDpr8zKVYHdkIw54YrD5prkcKM7buy3bm8qYkf5O9i9Lu9SLf8 mZbd8g7Zk+d9J0mkV2NgI6AwjDjukw6QsvUdJ01N3NW1FqRaUpMcu0dx32cB /Kt7uMcEVtcwUnfJLHXvgkEhEsn6UUmaoamzSGLkwFpGyRIteZahIlHLXilJ kt21yomkLcmbRMxI60PLlfCZLsLMYpMdqyj6+dwJtRO89oL20ppTybrWts6r N0+SYSyWWWEGdZRvfGTyRs6sZbV9h0TnZYw9qam0pPGlCyH8E0gyaxy3xoNS n4tWUSLxblrXVQZ+bCvJ+FLnrtldhLxV6SC9hV7fDnqeHMOWWDbtDxdHjmeJ ezra0IA0dn8eAJIeGzaUp7aHFGqx0tj0WEvURm0MT0ulpOSpj6YCCFszaRsZ vnMknHd1afPm/wMjjEy4d1SIUHtVQaXRiIabmN5Hmd5jWeLvsnOh6YfykgxW DIOKoutMPhXU9rWD6vStTQ6mt+fHClO2GCuLuybwSweOD9tmpR1089nKbyco aiBnEP5dd9J4lkep7IogilsAkGejnKklClOUrDzc8Qsqa4sU47t3TP1IxTVU Z0pKauXQigu+bq15UXcLGH2a2DqYIZnOIsoojYYW39fm/EA/AxgMSIwgDwIq P50/loE/iSQ0gw1kMgyQsncLAxggGNUk/jrZ9gzf82g4ZD/5ESCckDdlJpGK MbZEowgpSUdTFKgGMNx3tbSaf6GBdtskgcCgwqYkBTohAuw0UNMgDOEaWwYU ikZrRhAFUhSpYxCGLRg8msnt04L69dZCJiItBmbarNuHqLjoP0PL/p/4HdOH zBUh6Z8fzq4CH/QsIbRCK2V/cIesf/UAJP0wSeB4jyRZMKRpG0DqgfWY4nhU PxZ4gPq0AER9nxeOe7FP4/s1r/2KiN1RH+Coj8nxnD+rd9H4n7/gDtiCco7S KFiAp3w84kWh9Z/PCCQnlGKxf0OH8/7hdhSUgFfPVe+In2ssQmmVvUWRcEWX 2vyn81jA/U7wMIfzgdZOqKiKqu9qKqKitnxBy5+SgRMMs9t3RLLOGx5ogSIn INOL+Q2c5sw4rWORSOntxfdshF1ExenfnboimqVMN6UbTOvt4kM12HVrJJqr YxdugiQDIcQPAVP9SQA83cLJP0JKiCdPED/0ob8vIjCRJLHWEB0OyCb9C7ru p5xiGKRXWpNlQga7QUHqWZp4ghFqBOQVcU/g2TqkhmmPl1fSDy50G5YdTDr/ s4PUgvQm0BeWXGIYF3quXRC0FYqPA/k30WPw9wGOEg97JA7zwGA/3B+0yKRg AkFioLMoQmzSBdWqqhlnta60t5GFrTSoAyBSscwgFQBhCbHkgnIMy3OXeEDf vrL/DsM2wNwDNjmU0AaIulOB9BsrWf13ClexMgxDy620uFX772121bz1kiYx ok6KQQ5ZKTcd7zo3QRQEggNt+tjxN4MwIGuwbwp4oHgwPUMNET4q2DzKdfH2 fJo3DwoVoTfJDbFeyqEJmb3Rs/4wZDBDPySQPQkbqHggKbQYUZEYFYsKiiqC Ios8qYCnEQoVGjLCjiJcsDmx3gzgOu97p1vLeHXdOcT7OBSn1AL7hJBzCPIb Y/5sc2CFvhjqcZ0OEEhdJOcBUCHSgtdZ8tHGPUxZhCCvzPiYswemLN8Io96k N5OOTuVm2aWfZCkQ77Mt7wPmA0UKJWfagGj0M8ZtIGxtQ6uwd2cs6xFbo4aC mqvmUHz64Qvq95JCoJt06t7lZcshOMNkPmZidTQHGv6daeBxamylj1FO/EEj sYwMIx1jreYmR4eBF/vAdhwPMDuazrlG6yEZFWMYxgIMEFQSSeg6SG8HYidw e8nQPeMixZF6oNosGMEVUUURg1zR3E9JPOB49xA9JO/w9BvsZme/NXC5g0Bn dejkZcwfSR6jp7QpahBDuR5wPNs3K7svKJP7L9iAKX8/NPJwQ9AQTLcOPK/X zanrQjlA6cfEF1TGbopAQ54ToKARLDD0p+l1PJsB8uagByafZ5SyAWiqqqqu HTlsFYeRgBdzteEU6XlJIbgjiiY2Q2CD1SCbEfiQbCIQKJS1uID/DBdSPfRk JPlBPQ6sMHr9ihuVnAxHv1PaAsgWqcAsOZ9VJhF+6cctz7aEdcg5ws26mwUV hJFIoAoQWBEkkBUMEdgfTVGskNMOSegmPcGI7QHaaeEboXCj3jLI9rjtJEzi VEwA5OPmoAsQhIkEO3VzvDFPJEW3OFTy8yOT2oZ9fRhJGLBihc4Yu8RAqKiO odEWg4Qwe0E1FdRIUpY4HT0EORiYJ19fRCxuO5U52afKh4r7g4nsYHfqdS+a 89tOgXkGR8uQjz808gbpKEzQ1iZb0eweQVSKSPSmzhVEeajX9g9Bw21dQ77a kO46B06GRmZvN9aKJCFUF1TF8DDLQIAJqm2L6KrjA/QcviLKvbCQ9sCiLz00 Hb27aXm40+KDjg0QT5rwGUdrxzhwP3DA9IHEKGvEliAyBxmjQbExRNhAZkGn pKQu5E2VS1Fh2yuV5EKkIsARkBpqJqg1GTstQM9ayiEJIhCBJmgGy92jb6e5 gWb7y4l556ru81Vho+dUq+MqqlKPCWTeaCJIki3QCcYnLm4zHxEKH1gUAEMI hrHLjjZlTVPWQGTMynsnywwtGWgzM7f0/cJFfZoUjvR+9f0Op6DvF/a9czpf nZ7BRpRxxNVw99Hki7Sg9Koeu4VjRUF8hsU/1UgWkwPcKDfa4B9HkHeKwVgG 8fV2oHB0GBjbMzQzU1hytX3Q/BQ68r8zgtbUqHQMzihsZ9qQ2+86GjtVHx+3 wHB4RS0Id9SRAlOt9yWBPILhScVNRXkZ1gOgPHagNK2Ky2Flmi0gClC5UY+h rWSj9cs31YNibN+F4AFIT0vJZ1InJolSRMGPSBeJ1yUAYlzNMIYmQkUgv6v7 cOktSr+iCVE30ErdN75pUOBxMXhMz560qZJ3PASn4Yek6KLUh0NlYKvdW2A2 QKgJ2q4EiPdVCLDbxIEhjsNAx8ZME5k8wCFb6FbueoqTYbnaLCqSg+YwQBTe WAomUSyZds1IaaYiZIRDgfTwQQp+ovvLgLtp6qikCtqS0DtFQOi5dyZctOfB Ov4kPIPIf17C+o/bH2g/lLnocvPsB5dSgPMy767ZKN9MANP6FCIDAzwijJ9w x9mPbbNwAxrNTK6wjY36AIUe2Ijbhh2BcA/5R6TbjwJN9Zr6+wx4GqY2BuZ2 LKOAXPxnyn3HT1bVkOEeAchWrGex+IJaNukJEZJEwCWwegnR70wkk4ISk8X2 LgCndgylmTlM1dDVUMLHEANHUgUvoAyk1ABioQGAEAYMIAx6CUAw+Ck3dVct j2bjclkdGh2GFIXqT0HbQe8OzqNTtm01I5HvPBx9DQ8iUBw8OCoegBDkiasr 6TuDDY24lRTU7j0DGFgwWcKA75hy8m78soh0ENoIWCdgeFPPvSnR7wqIB0nS puilAMHjBZnN5KMHgbliGZxUhJIm5ANtuTfOi8QcEWNUq+ijH3gkZ7wl0uky h2KGoRPM9NMemaqeUfIiGCJMuVVV1ZtCp6Sthrdp43VSI57DueXrRLB9+PvT PKd+mB3rumAMiabcy1XnBwrICn83GhMEKYgnpCleBbCYE61QJuJrn6XRcHII dzMjJVGXPUTiAvuQwQkAxRn4/o8NHmmv4DLDl8GUnOIYKOJObZh9EXuD16ON DlOx2hNeXkaCOiHTWjgUAhQr3BQawZANsRd0Cynb27jPXcIsAhGA9IoH34cT x9vX1JWi76TSqlVac6uEsgOkVrUoENtqdp5AQNFP3kAoiQdqZ03W9I82HBjj 0rcEsXjgW82y2dEwBDxYcbFcbUGxlVawraESjFNwJcr5bWahFEdCLeFwape2 qR3nXlZS6xb2JqbTaGAUXpgk9tdrPbDfO+hmehQ6Tu8MWPyMNPPhzUriQ9Bx KTQxICeMaKQHsOO71N7GpxXEcGidIpJIQhOdhl+6YA7mATt2NBQ2IvDNA8+R 9gWtwUwAw5KlUibroAhQm8GWYmIwJqJ2xUO1j46Cg46THzOolzYWOsE/Bm9L YQ9vhysJ4YTvy9PQKPYrMzmeF6nRVAKr1MRs+AMzdye4ZFkWFzsTtktJ1MvM 5nM9DQ0+caW4fuPqvLIDERaAqBsv5NJifkk+BYuEMPAdCF3AShaxM9GfZHcO OoHOGEy294OukuxBAjgR7dMtkHLsEgRBSAX4akTVLnbQ099zZDTfgiE+FKWC AYihsIJQDE+G+W6qZD9CbGOr0KBpQJVHwkh9d5gYQBPfl4SHpJq1nJsGYbQ9 Y2oahyP3fefel/L2Epe/7HKtJylCsTFLhwy01FpaIpgpL+fRh0dtx3yNE0KU pEFoexH1/8Ok31Tr8fq/Jfjliqwk1n8dZcGYm+ot+akyfj73aYgTSIxGIiPw kWp7qZC5Avzl4dz5o3iBeI/J+ux6lUwfR5w3ZG9AyDzT8T781MPx+c/TERNT lP0mIoosRZCWEUM8H31Y2qH4lb4/F4h/LvqbyStOP5X/hCQOHPMjmdcOb5LS SElBgCH7+I0cE5DQvghp5nQfg3qeCEJOe3VNjIkgRk6BRuB5tOuDB03QzgHf RHhOUQDLU7DEEubHF/K0bUIxiGqLR0mJkGgwqgwL62cnAZ1h84vQX0ZA5OQd FwDrNcGwJidOR3niOCpM/RegQhxC0Xlrxh7TXIzyduKe8078c6weKabhdePH Xox39QrlbcOKbntYQgQSDw57nQWOGABrwydk3QxOoqGrIw5DjBQteu6hrIYh OgDx2eqyBpeUH2bNpaGF1hmSewepg4VZjpoUX2lKB5eRwPDl733tdUIFttFo QLbatCB2eB6bDPIoas5GW6QlSokYEsa7q5wENjyoKCDki7Q5XLgw03L1eG/H I7GbW/C0+PN4XGScQZUkoHfhZ4ju0cnpxytmaFjIUQ47c3rdwj8XK58/cBO8 pkIHv/rHWoJqHx/ZSE+UNE2gfuEiaoZVsDBkRiMiJESIkhQxRK9n6ofaOxbD 8PwWbxusHPZQY/uT2hbnf+A5xCgoy+9wNfsJ+YKQsf9dWEJJBcbMYSTm0BMg /5GRqBgOSApxCEoE7yAYHO2wiAlIdSBrrBIirGMkURWRUSCqzMVLg+I1PFo7 jvfkDzt9upKz+ZiBcVDASd3eCvMBTSgZrumHGsx3b4FnkwbRt3OUZBk3MnGb sggKDFVGKirCcMgUYbZaX/+xafTYwf5/N4u1qZ8J4xy3/f8M8ZKyksLJYFmL 3zvxxwNrMYFS5g3G6GSEWAhGlYhiLJlklyFUxmKHRhgsMgya7ge+g2KjntHt ElG4gSDIGJBeIrRXVDi89A1WTMPcg8jp11Ox544a1ajt4AkBm0ORDlGBxxSy UalSKeAMl7qMtWpUWphO3ZSdwIQcB22QNXuUgzftuk2EJJJJQ/KbTT4NDQ1d 2jlCSh54Bj2Q3eM3ac4xSDEOikKEm6VpZDlMzNwcPMMBfNCQhBTZ2cFUUQj4 I31AoOJHjxMAZbgZIdRikDrnTNIduOORzN2GYcMq1iSSZD4XgNPTaSW2hjyE PkbGRYYKKcMP1duGjlBRZPBshe7CEkiNhqdOpoBl1UySyMMzHZoyHLIIGChg js0d9diSZlemO5lVXhs9wu6TlRvbb2ZZw915zq3SQV8vUBgbLkHGyyHT9eRn OqcPHAOPHk59kgwkkYxGQkhFkhAkWRU6hgBONCO5y88GXPVo6rwQxPd0GaEj 2T2YtnZMundxeaEvfI4F4fSFpwNGstXbtwJHr7M3BOd3Knkypeoe3t5Z5h0S /L0NTxxA9+lHPbCGuTjVNNoHp5i7K9BNoICdAnq7dYB1gXW5bzZRESlkwjNv cOvL1MSNRoe/b7Fp6RjT07hR3HfeQwc2Ewui7WI1FXNcPYayIswHZDWHNz3u 731fI17moc3hrYcODyUzMYo76FHJM1ss1JxG69MAIyMYScCiTE028N1k7MaJ OAarEJCQkMIbcHNLXWoTlbBrLdN41TFJJlQGWJNmUkEIjfWePmht6H0W2No0 bTtphl567YdjLmhincm46nXz6FwFEZE9BTZKKcccccdxJQFse32+p6attgY2 GQZzRNYWloaNvWAXqpTeEZKQ+lFaCQ2TDNlU7wa70Qjch4lGKo10Ld8lMktj xf9KF7HAOzMMVPNbIFDk5QPd3LZxBDykqloImNJay3CCGYytQ6tt4wIX5GCh 4wbKXnYdZg8Icw7nn5+uAYFVTpRRUU6vogh6enPPYTV5p9XMa7ZHJ8JEgcTb xxkeTqBJJway4ug6YCnovHzzOZ4ajgMdaDUo57hga+OKqn1W4k525taIxFZp hVFBiEEYAijGIxdUKHPYzDZlUcslSNshWTZYiPjsNwKGxk8jB0CwWhXKCAZD dIv+b96OQBYQIE0idnMYImZSonPwSudZ6A0BqDBkwiJROTgJ4PL9PW6MYhtI wkJrYKJYtbFSSIMMVBVQEy5O06snsAJWDfn2svX+bpcgRc9027YHK/k/bz8L u4VMhw9+XKr8bu2iqK6zRBPlDmRSoCHiqVO8QOB3POE80tDlCAnmzzsaCk/g mgog1oSii/aiTwI4KzJrAbiFTmcd3jEOnJcU8TCx0rEgmce5WrWkKie6JIi3 g0kBhA51igYm16dAQfAC0L6Jr1npGUEc6Y/CVQQ6/p24+96H9UkEhFTPoFPE OQxYF0T19vO75t2lZmqbUmJwEpOOUQDpmDGWxvbCidk5YoJLuABtTAW4w7qG hD0Yv8yLzx7GQWdG6u6lwqyCfAyYfv0fIyPrUMlCh00HEjluUQUqfFMx9uUz sHB9QFeSwT7pyg0KneeA42gmSoxtY3ljACF4pTJXdef7Zys0rBJN0sT02Hfx qoelm8xg+1FY7MNO7QQwIJpBWE67Be9EDKL6TZZRnkrTn56bEiSbDDC0lo8g 00tDOPLhi0C6WOg8w8rCLzQJDfDcUNQ+xxODMdKF2vMkgU6v6+3p8F73wwkI 5zJFC2yC+PvtPzlD47AlQ1zMy76+Y5dXVmVyDqBLdBOYfRFDg/Dv9nV05JwC KxPb23M8803xHElpTVb2Fgg5opkdmarJ5ISFiPRFwnNWLA4wohJIAX4B1TOI M5hH+9OnsDyG9lFOrizfsl7tNANaZr2ypddCB4fzEfIDAKBAlItilS82TMBt VRDYYIqbrS4q4H0b62rRYA/kKJJJ2u5D0DC+2+turOM8rkQdChjQxZbTBLkQ 1OWGn5tSm+nbUNQR0IWGZkyTbvu9qHAHKLBVd7OWummVAQhAzuXRd4xLxZRg WgkxLy+/j9nu98E+bl1Dr0WLIAooicj6gI/GRCU9udLYAgk3OcKCHumhz6hD j2POmSHUATdE8m5JAnb3B3EQhIRb2jjstahbcSVlH6wL/RxNBtQqlGrFPluh Xyp79rF4X9soD5oBIq3gJhEBuxEGmHfoAlmHRPs1y4or0jKyxNhhkJCxFMAy PdYEZgoFKEIiBGmOFCywmrkPhA62GgFBXdFE3wHoFGemBhA4H5IfwaSh8uWQ P97BRYpskuRCJ/rhdB0DC3PD1wwBhPgO+h8UjcoTzx5KZ87AkTlKYhIi7YKX YYBOgECiIkEOQvbfJ46naJoARkCMtrJKhVvcIe32Wnl7vJ2ZBnj0WDwQQcbU vORNkZ4tkjFFiuKVUWkDxO2eE888Dg8UfZQ4gTaiT3od/OfLRuRDI8VakFHt zxux7HvPYmRqVlnJlL/8GabKcSg8Fte6yVdsjKTwyiab6zYNAuFIj1kCyUZP OHbPMtA6E3Mx++FhBYEhPeImv4duBDBCg1JNJEYED5ECexJDbQisRBEF2koK MtUpNtjCZ7fuhAdhrRgSGAxQmdGkwqVAbEpWpFaPm/qaLTAwhh1hCbDmDizg csyZE5uwRqcBLnTEcwqyVjRFsspz6C+GySJ5CySwDTCT0iYhzIH+CQVYoVBO N1FJO+yjBggKKmHkn/ST3h7H3d52HLpsWIIypRkCosGI20GFLQWCJESCxrQr RAj7xUzGkpUMmNH4yeoLPOHvDLSdhIlQDUkIXQcTAqFHPjAO7BGRerAZEJFw AMX6yWYqSivl48ZdPPWmpyKgQHfaEvO3ILB0eQqFlXniGfSVIQUkJ0SYxBct pYQDEFIZEwBAEiSEQQqFYEooMGS2AJIIFIVzvEz7iUMTpLnHagJb6fJinSBB YhOyVA0pSkIpHzsVfvBT4npsJvEjvJmdlcIGpC7BTo48d5+/cIBmCGQvZDAY p/v2UgWAiUkiEHzqQLL3xK0pO8Vdj32GQR2aVs8LDy95Q1Bgok9szwVVRURz RGYe0O87zXsGnlOU9sOnxgbPvI0MYACOkRQqCpIQJD4NGGJyZXgk04Q7EknO qqsWkOsywhjcYkUMJSTECoGXtxQN4i4aH9hA/rJ6DbZIHX3TAlOws65Tq1R0 01rNa1RWXLCeVkljNCoKKLDWBlqNMoCQYUMD8h9Hhug6KCNqaWzFiYwE3CwP 36ISGmKrk+wTIb6qxGTmFDm9BgjbpTNLj6TO7MeGQ1k0BN6AGMgxODJd3GBp jBE2sCbOS2RF5evAkgHO73TFtjrbiC9bmA7hilxqViktOnjDTcnWNrZywvCP AprHTDjDd2dCRTTN4ZNuCmabTomyPK3Ys2hqmN4kZSLFBHoCAWasJ1silsnM +hT0H4gESm7D6XHg3yOXnXRlXlkm2GiGVObQOBwkzLbtyIRsSTQwJhkiG3LI V32AvERdZSCib4anItl1QVDha9R7sGP35SaaG16bFp/eM6MoZTWE2Gk3BFEp 1XbodE0CJnuNGhM1CRDSwWbI4KD5KkSUuCECEn6uRkcEK1tTAPiuSTOjsYU7 CsuL355kAhAkIE5VhSUptDcfFn9lAZ2pTN2W+E3AkgEiohidcRQO5AIIbSKX IVFVBsKkRU1fpFdUIceSd6dTa22p1BYhmcg/BOgHQgIAyCxRiv/7AkhskhFB nX66p82xeH68kLFe7gcAPXufXKm5onPymIzSH+Of70z8/2cvd889X4k0ngHx EHPieTcJEQAzqeou3kr2WGz4tPL/L6FuQNg2tigMoOmc5lRBjJ+tgecOzUVh DoU1mWHUaZ4hQ7VVVVVeoF1nIhPA5V+T5+w7Fh0nn25nIDn3vOPjUysPqhQL 9VXEsPcUPKP5QkEwQHpyeU9RRr5vg8ddanOFMJJdVCXTTN9fd7C4mCcxCjOq oqsu2hKB5FKb0AmC3lZczfnkeR7iFeA2CqUkB4k3gMLpSRArKiwWCIAosFhR PRrA7lVhqAskikUUg7UKi1kFArA8iVJJWSsAV4khPRMFwUjaMKKLRSNokKsB CyxIlZSjFiSoiWpG0SUVtQbEWqRtGFFUqkbRIVYDZYowssaWA5xSgIkYKIsk 2ELIONSAxjGMYxiMYkYkSITunMzIqGwwTjgclRktttRHKXJVB5ALENEtiCnI HIEpPAeR4Ar0xbcaaktMKMgie6woKyZrBRRyqViqrZ2XhZJJwexEWIYgcIHs vQRKByBg1WBBpTUyxkErs1RLYdWlbTancQGU4iUKKJeIzxM0pTmhyUVBiYoi Zg6NGjYuw5EFLsgoTaAmh0WN1qa0iasNNLWnuzWDvGBmO8ZXTRJ/BIah0wOk 7S2QRnWoMtk5lVI5sJyUR01FF53bQhrBKFKiIphhQcqoqYIUyWTkNCMsQqJA hCMYkETkiLoFJoQyTLbk0d/cbfClL8R868YSBg+C5kVriAbPt64QIwp0jj6Y aNtp5PVqGabiPgW8GfXWcqfRH7Ud74gygi0Z/czxi2yQ7ZpOMoWM4zE1cHP9 tb5uua7BrOARDChqk5dZ8XX3i7GcEc0+GYdNCAIHbaHaGSYaqjGJpjOOPdnU 7ejsRqWgRChE02a0sgyZnGYC1QRKy9BzcPwp1se2KQM0A2nHDwbqCzKl00AJ pOKcYIYaImts3RZhsFImGhoibuYDMApKwqjXSaKO+jeUW4xAwZW4pMSJDtYc DJiSG8SMSMSMQYKIoqiCIKCJSwe6mb2ElDVRiVrDCxt8NWEnwa56/bBpN8LN WE2nGcWyuy0grGGyNc7PzXmy46fGe+eFdsgRhO48Ftwkbfxoy2jGdOPrmgmq xibXbnGIONkRcEstwaRd7OqnTJCW+YDuadI8ayXEUelNejbhGsA/eTWjrtMB AVzBxomN+DcU3Ah9t3ExooGyAjd1DCps5SveE0dOZ3zvvh2wtbCiPOmcWHSH Ra10zc57xXNvxjx3nmsV24HY4w6j00Rtkbfu3deI7NolXz0a7483879b4k8u JXo4Q+7fiaK7v1wyxjsYoheSHxHBEcIWrqJFgB8IL9I5M0YXda62EDqcEgb2 3bLms7SSEgTzpBjKefNY467z1nrV54K5q75cfRkiBx+erzjQ/Y7Tydi+ZL4T idx70aZBOEdaz1bAz4xpM9jy4hFju6O2LLTXYyRo5LLCwrrLJEaYmEs5O2RI MnZiL6IcNbdjnLU8BW9wPA/GjJSGTT20ad0PcoSY1iDl25UvJwlsdqTuyRoc EcwF1i3XCqQ7tLaCnDBZerUYTEqjOd3btrEhwex4oVuxdPZYlY7sSLW8S0vT jotK5jFmIc8umayZSwN+3YNcbbWLTjHaZw7hTuaJeE7yktvFvcFmXeqnEtVP lVNEXmSCVh2eHFUzILA5EGN5ilnKlS1hosH2jDGmka21UGPMfkTTxo6xnttz IYeOJbTc8NnPNyGwd4GMqdSKuWbQBegFJhmIIKnE82OzdqMmCHOqGYGIHcKj dTtb3qstScWSx6cqB3bIOW0inp1mHjVjkjMxaDfs3U2lzsYltWdFudmzl5ib Ud5JvvSxFZWCG/KTjNWYRFGIcdlCmb7pypkDhImHpQihxU5D5va1OtNwujDI OEMmYaMDDNxz5hZwdwSJjaN65aDg3M7qLs65PfAQLQsIrY0UzNNwyMngkTia EMkssB3CWaxvICiWTJZLeIY4c4JHbJdpnaZt2Mt1ntN5Z0JJHhjQ0hnZZpjD QI7Juc0sRTiWFtkhQSVCJQC79QvlhW2AM+ggd33je5iKMID+ucrW4FkYwgQg JBSERwQFLJx1AhEOwR2nLBoCURT2n7UAeRwXVT7pJIQyRPqge58b/4TkZAJ2 EduncpTQ6kZYVCqCqzhMkM/yBP75bwbCk+KSTJ7B3E6cteILuYgZCD5gMxTK nwVR+7BRRgNPZwpUCCvO3JNC+43vu0d2WyGpm6GCKc7cShxsb6QMmOYIYGWU fRHn1ixmA1FbzsQucVXDsQyvnrq4kp9YFXnDdnDHE2uOeCB2bdI8YnFi2pHI SZoF2d6McQZqMSZRIa3L5hOcF7I7Q7NkwXJt/wDgcsHJczR6GSkyYNJoTMCV tZBaIJDsMGdduECAhEAiiE75IJIh18Aq6Kr2yYtZmzA9n9NIXG55LHEOJWBx N9ld+AdnFSQGR3ERWoI0rwY5nUmbsDlDYYtbdE2cU2NvX85AgwflhsSEOM7j tHhB2gSIShCQPW6jx8rGhIYUnLYaBqb+3ZUNrULTUP5hAzzpAL4/weqdj3fi rgWrSWqPcHqQO1WBzk7++F9IZ9cHwhUv6qDGVBlEOtGB4hySLETCfdFfuhrk HiZkG00OXqGIicx/MIgcgxnWnUOENo4JjxMn4XhtyCIUG1l2g7QmFgihtSKB 8YR04ynI+XzqpsvXhsLlEkAkwVJZIgW44MbuRQJkFkHiQEHXdDXwUvJr0eUJ oEeyDxrqzxi9g2HvRrMhoTi9j1PBBvA76NI0NpGMgZIQzsI2NyikxJDsyTEC YnFvXFIxSpKHHUV+Eh7AzUtYDBEChWKnGW22NjIpZBsvY03jmKG0HZFMTTRQ pEzMXRX2UUroqectjrhSWYqhy+mEIsWCqdPeL5XuGohvO3GHBH+VVLV1/0iY E3TuQ5ctz0MsrxF88/MLjMDiZMExMBriaDQRxYuLnA8tOLz5XV34N8eR38jf OfobMUnAiJ+a0iiM6pxlZv2gcTN3GcHP4fJ1qfi+d2Pzqa3eOvBf0w3FuOt6 sk4G6kkYQgRAzs43MQjsgLTKiZp8kqLOXq61JtHktpueNIBFodU5u2wyZCY4 JqGIncOP1wWRuceLQG48YGyWCUwYyBA4n1618CGAMUUuArqWG2oL3QFueXzU yQEQj8Q9IeUK7YaxU3Bl2bONqXBYhpKQ00OjhTGSyMgSGZdgRiKooioqQEjE jBIqKKxhElaYA4Qy4txgIV4eVDUqSnuatxWbE9Q46Ymgh50kJFgTXb9u28QR URVEUjO4P7vjr0RDciyKMeIVe+IH2b3gMntAkWQcR7uah3kEM+bq0O9WDp7K fND1Awt9VOgDEmvJZgGxsIiJT40LjWxG2DKNRVRtFpbUG0LEPVD2/SnsfaHW dHSvlizu+tstvT81sb2bl0UAspFMcKWkpp/K4/ge7sBljKHIYcCUYJcVJ2Ca HVdzNswnVIbojGhbA6kUsKgDanX9ITdacKkKJAolSRCJSpQrvlNk8G14lMdE CYwUpnzNVrJ9CLeax3NylXSF7Xn59p50OAMyZlKSJF0BDJ8wJ4zFdvdANp00 IBRyJtBcS9cxqlopQfRSVESAREikG0SKTGV9wM4KPIAS3yZXftiGuppPHquk Lj1KC6BQrtimRnXiWJ+Xw2x+b/RLzYHlTYQXoWUBODKouCnM9RP2n69ghyDk Fs37cQVQf0t1dSlgJ6Dmmps7zAABOe8z07uk8wsggsA1bCqITlEn6MPvTelD SgovuN/EZ2fOOsLvTBpRJ5lP3jQi+kAcspAyWOiB/7tgSDgWuvGX5e2WG6AI RUdrYByUqsoGNy6Xi+0Bo6rA9nsfXo1GVQPrh4kbE3BlY1mXKZMQpiSKlesg cRjN5u7okpSCiSAyCQA5vM/o5VvwQwD8VDmYuMk4XVu5Bj7b6GnzgX1mfcp7 ql6qxkmZtlliktkQSMpLQOiBeDeBQ6E867o8o5l5/AxOjRKL8ukOoIghw9BR z+ePDq3lpsivgnekZAQkUYvKD7CAXQgEgDW9CFwBxAJ2pPW1HcpFhOabmWfE 2NrCUxAmhkCp81LCAoFYSVk8C9nYidyLVSj1Wphn5MSB2dxZ2BIq5BjE/AvA 7Yp0dpPa1HcYzBh2oDc1s7E07MoOQSKIfZwuWuXR9e/w+PKYJJ/Q+uSd8Oyq wPaTL2Ho54yD2IWul+VxuCDeLegnZTzz7ej34sBQgobAfTyPAfxFeRaKqo7H y9mPb9hh6pr8pM61yHuAMi9oVCqoQogSKUbisg0BjyM3CmQeAB/V8WA8dAvo R4Go8qdInGMo1vGLSbDZ1kLBkwQgWMRUS0tZSbDANAYJBCCrKbQCkKsxcY7J sjjDpxxhP75AvpLIAU59iioqqqqr74NiwYKqonU2m0NgiKyfMwLPMPu/z0mk 7j8UAUnGAFk/eJOY1UIUS42ERJBZBSKRVFFILBYGBIebh2lJVST4HXQJkqaF RKZIymg1NpANzY8w0MT951jaCiMESeXvA2CaA8ybcFLRZVZLTTO3JQu5NaIH n36p6tEnKbiKcWyHJBVIqqyRggim4lkG70S9sZxMiOy2oH839HONgagaUT+l Za1jiFaNE6+bsQYtZ4UNwm7ToMOYOQic0zsDPgrFRQ+U29J4EfNy+w9QiJZ6 Rk9B9cBC+aklGNoH/wkxhOwQhsRjFVGKQgRIhC0PdFqI+EUqKuXWUrbJFrJM KG8K9jynUbTeO8hDMXMOkxinKkWpVERwhzI+h49+UIE3NAsUns0qskPa0tBK 9rAKJANv5GR+ID41ldz7oCZiGWM7xVnHy/SS0evA3RZEvK6MjKEyF+yKpOen wwCFG9bQIdYa7GCGeBPwIjbZQCTZQM5sJlRPAj4lS7H0phjv3TYHcxkn4/gD kvZpy6Pe6bSF2NENuiJ6NTxnykUKip+WKDUEfFEZBQLQFkVPbF9sTNMypp+V UJ9UXEBsFnPsPTWu9UWWIB18ij6GZDWgqp0HVDLyEQ/HcEHd9AaOnYhnqqlA OpxxxoqmvNoeRDTyOweDBSH5pz2HxxKg3tV1kgo1lClR+HgGT0e+e1Qlj68l Wg0DakergN4RUD2wQS0eq6IhOkJPnT2mdj2waiwiyB+aFELRB+AsdXf4lTpO Wb2lvI+YAb/tipDAHoaIlvwI/dD8DCCj5seIRKUJILAIEAZCoI9bXw1fYdT7 xgJPxPj1DFDUEc+JYM1ovc5oVGZkQoEMLqYOzdhuXpjgx4+o8S5rKWl21y9i k97lk8z90Y3wY5Hdt2cutTxLE3f54fCjf9V5U6zvUZsGFydlfnSaZ2NADo+d jg0NtW7gOQg5hEQHa4aHQbzdCpIRXFXyxUNBHmTvCiz98WiSLDcpBXinIkal FA4ADCH0yHDGjBltKWVKQKx5RUGmQQYEClCKsBLhUXJQr86GoTFHZiCIDBJg iZkDIiJuCmkKGrS2GkpokbuBaYxwRLBwGKM9YmwDwgLF3g7g6hH5PoUs1qXk b01gawF1Gk8CjJNkCmESI0JdGHbGuO1sUxIkWQPzMDWAS+6lRTISyUSMbSgi h4/hTAN6eKGAzf81n/J/60mw7MCUVUJzZUxLll5zFsmTHMpIaYBoFFTEDrqE pBYIkDt7fo7g2wFOQQbZcsxbt0fMrRgBOcjD9g9iKBh2sD3kPhxrReyFiQOZ 8FVCKsAUGIjEYoHwErIDEkBSKQNgxG6rdR1NJIl1g4X7Lypt7WAuuBnAEReQ dp+e/+YwCde5CIiRIxBREWICJCMiJBFZCAEFj1oSuXMIfZiiO7TIqFAWhQw8 egB8lhMqDe9MMgQyQ5eCE2PYQ90UQ4j4Ov3oV63+5oaFVUZUV1DhuUAEIifl TI7E7jgKTHS3LBvEtIYDoJoM7YHKM1C8TPHlJ6KEhzqUkEuBAiQL0/Juo5A8 NkBkHcRXoi4VPOqAzVrtm9xRuzskyZ0OYS+gUp1pL4OJBHBKucpwm/S20143 ZTuRgpO+YCWBweqwDkh+pKMEGIwiJISKiRiAyOq/S7vMHs3/j415SGYRPjyh rOqNbQZAq8enF0RRCE7zYtphGeOtNWUOYxLywS0KGQ5PWRgFAoWTKDYpKbiF mwlP9hlmAoCqJNkxVQFQygq2Qa6eMqAMP9oIgSd0Q9E8WIsLVZGmSB3MI9Iw YREQGBDSQrsJNOpBbJL19R3J4j7b5Bn6ywmRIxMRk9T0u4+sibRWByyEOQCR npuAUI3mZkWk32vzYh23qoC792mnc8kt7jKiixg9nSk68STOcnehAUOoxiat gQyMUikQZvwc+sDYNIEcicY9ZYj7PjAWTX1cwQihk1GSeVMOUD6rihpPKpDv mLcrT2Plwg07s6PKhcqZ5OeZ11wIkVzILADGutJpAHIquddy99yFzLAMW7qo 4lnCGJxDkgUVlDQZON+flMgZm8rIBioRSmF+wrvH3C9KYLRo7FvwwE8WNZLv /AIPXqUKpYB/EMQ0h886UrS5JByHpWUDL95zSbxYMtrIqDsVLJQRUSUQ3rmY 1MYWIwSCDMQKyHgEOw4Ocoh5mO8i70iltlhCxTbQhh5obTlupFRYjID4JAXP LNi/FaGhfM4mE45IOdIJzWcLJy2UR+nwVRiCiiICimrVVVWIJZLRWDIUpRUR gyJGCQhJIQIUhl3m4BbQRz1x0tc1OxXvNAJD5wEToyigggoIIxFnfm6cGSTQ 1E1GbM1wdwPj5BCkDgfUvZk9ud1bbjmfA9v2nmngoB4kgMVAhFkIyiiQYCjF FF/nsskF9TKeJ3n5Pu2hskPcXuPB0ECf1MN4oMwQOgMBhcPBn3EEhvQpzwRQ 9plERgRL2Ip+VsXCoc2Iyf5DKMMYSxZqWiVB5oYNsmGTASIrBkSMEi0xy9Es HpS195m3BU3ggVEXSn7ItQqNGl2EJsRdBWA8ybRNCJUG6oX5+lKHWC4h+WrT 79vDd+UkapD3lnoMgDuBuUS94bZmiRVWqJJxNGw7RgoAEE7S1SuGMgO5sSSE EtIfmc1UPkQwm7o6P39Rzo+V915eS7H2uEohOcQ4hFy8RVzRPxmJHL0RTt8M y8GdCZovz3UWKIoLoLD82EzAqW/TZuaAl34JJ9RCaDdNCw+/CnJC8rCWRh1P iaLkuWa2AkhG80oLLAoaHr66oPJgaWcetiOr4X9cCzqUEIHSYluy52TTJ37B u/Vb8n1/OUzQjatsESX53zsJJACBfcIvPBDpw8+VftchzFHMN/vDivoPkPgb Rh8AVkYgRNCXu+SkD3nRxgJFGQJWXqUMGTAEGctXIKSAsF4uRLT5fAUs5DFh K6+Tb5RMoFrw9pBAXcsYdjGCEwySbnIMmStEaByt5cjTKwdytc1KdumDLBxO F34GzRBA6pAcask+v61blKxkCGLWMAgQAjoN3hw5pmtJYlvYhwh7Q0lEHOtI OWFRE8Cf3ebIeaSN/tvsnIY1FCSGA7tzASYN0nGN4f3pwEQ+846F1eOgCfSQ nvidZbAIEW56faqahyTzO9pp39uH2Rxl89uClL6WywlhIeqw6ccvaVJXTbM1 sAbDE1szITPx1HfJo1DbG2iSpZguxAucbMonCpTBaG5wdzBzMkTlxzM1brh4 ZNzgzCQMcijx5OflWMXoJznRmKRlmOLRkmXXOnJwJrIXctty2Nxls5a85za1 wkmpi5ED/GAO7Pg1nnEZvUyhyHUKYW9HKYmVFXkXWxldEDOIWYaR1jmsgTga bljWrAYZOpYuqIf6s81wZ3UaSVVHo6x5nM9FnxmEK7MOwyH0dns3c+Hdg3iL B14czRaR7wUpWKA7agENkCwsk822jaTR5JoKIiYAViwoyHDBST+XoKY+8Hs+ zzqHDBczZO2GJYhiUQOMnZhsoHO0TVAwYBCLCAwVhBUEJFEqUhLLth9b6LJJ BQpKYSHviUgLkkgey7KOZbjy8zQzCKa84VCHjpeOmSWfMIGwWVwFF4qKeI9Z aRCRjCJJEjIIwQGRBBiijIrFUQiCwRjCJGDJFUEgyTxJKKGsQTJFyO3szsNj kiGcQNCItpFRtBHI03w/WHIwMgIz0QQOJvRpuEbC0ZLAdsahD1UiiaxFSQQF O0QJigVsPsLSp5zsM3FwBQAB0Ie6enOjjIGcxwMD+P4UK7DESPX2sqXKY+xy eKg7QQnek9YDcCqQgjVTAgM7BkCY8U0QdTZpEQgKzItT7oCW0CmLBKDgheIO WlpJAKIMDUgbJbGkLpBABlCc5ECjaCiwnBNrypZogO0aSkNIqZghjDLpLJ9M o0MFsE5CayELWBowmuFKENbz17bJpFNkgCZJEpJo00y0IoBhM8WlUDsAWXau 31cjKBaL3gJkIansRPrLUEOUQhCSHFDR1IH9Xvh9Cvkir8T6cMiMcO372R+Q zg4p7sgFeD35zBNCO+5rW1umQczBmDSp9iXFL2jYco0LfDEDXmm968Prrzs9 zRydNtbXJTpz3N5JHVJvlEYMQ3SswQiZvkDc9dh+7cKHF43jA60nNVZN2VUZ On9JrU5VLs/6wS7pt2aoiAwnFqwRz0DGFvEJTTYiH5et8D5W+b4jxE88h6i7 sLnEb3BYEVIjAFgRFDyYKBxIAVCoCtEEKipQUUoLuwEY/ajM/OO5ApaGECCp AgKEgMh1Qq2IwQSoACMUGIREhFIRRAJFFSoI0QQCRACD98EOYxTcHoUgAEBD moPGT5K9B9zAOyNLxRfe9Rf8BoPOeJqKIZdQBzFHo9wiBz73337CFgcw80n5 4IUBskzNoHMPEKdpHjwDt8wfUTu7x3m5km5zN7okRIkAOY6fSGA+GF1Mf3pA okLGSfDxRVCKB3ExmTIoj2DUGAiIqgoT38wsyDGEUGHCG73BE80DydK45EyF LR5qNCEstJhu+ec5vsZIS1amEQOpAUhPkApvBAyR5ahogERHvyGQQDNZIyQm PQdRop1QMDwM7vXNu0VYePR5iF9F1C2gkMAZJWp0MDl+idk2LT3PYzUUARN2 Q7UK8OzjezaSc8VFyXU1MxMiff4mD7GYGNmRASEWTmid+I9PlXH5RE15qNIV AkDLFEMYLJWFZFkn10sgYhR2N4fhQOuhpMI6QNlW4NznW4Vgq7p0ZMb3iF5y CwPFzBtRxy9pQAnTnzSeAm+AxYAQBgEIpBTbu2YiiCgpkhm1ORJ7jxjn0gw2 /yHplydTsZzA5fmqQIK1L42owVFcSwCRBbaAHDEYLDGjBSQWBFiMBGCIEAKg QWEAEKBSIIXCdEkLHX5nlcDINQE0BOcAHD0Kn97AH0Wy3PTCR5LeEnMCdEjA kEkEIQCISESwGe4h19ydes46sZAjlIeeHsIg+2NQNRniHw4CF4H4vJSthnp7 nspV5UoI4JfWZkOhr0AUfPek+q3Qb4RwCK4/dPj8j7xDOTFs6v7bJqvd7Vlr lyktxE9x2ZsR2UQnZx3xb6QhppqgqIKNyQUh1CkaUSDQ5w47MxZ9nfXxqQFp fjzEbZMjB06SZIWToqaLmY4kF1DBYcEAOQB36oxIGzkxVJafUrkBAJhCr7LS 2ZJDrvHc8YXDSpZCApvG5LmhIZH5H55GsfsM2z5kg5m836N9ydooVOPOPmTq gJCKAEIKEvvN6AHZZMEPrriOJNgaCVvoASkCxCBAOxLGfrfxqts3w34MP4Ee cCRCY/s0ZN/P3p5oaO54TzVOiBExxJ2Fg5eKKR4gNgHVh1WhCNuH7XBgGIQy YQyQHA9HpCyGmIa2FyTffnDDnjACZcPEBeQqc4ZyfbP29zQ7daDvO+/A/LDr gHHJDiGQMoDoBoPPZX4ANq0OcnIHkcqSQkk66oGggFRJBGJ6lCIROukO/jqY xMb40AeGg/WQjHUPouq82815j018vp8tKSqNkONUUx65khEkkI9bW0+0Oz+2 xQ8bjDFAglMUBqCLY/16UHaIiDupB5KH3l4HVJAlxBssVEM9bKE3DTdUJ2Lw 5xm9vqbQhHIEVd8RULh57lHpJaKnkiO2JaQisIGPsMj0nWYSqsgxA5ud+hQJ vY9UetzkbnYeS2cecBKfrpJGkYyEXNiahEhCRmJqB+EgsiicVex5+VoS2SNQ ClC0sjAghYVCSCUlECfNr6nY98lh61QUjHkJUSMHVX4MvIoFRtKrFBGZSgxg sWpCrMthWrIIRUFxCsTCtCqOYYTD1jUEMSVYCZcZ0dK/sNqHOK5UZBYNuDbY xizANlQuJikL1nCWkYylMET5pwOZIMEZBG2jwqWIzASsE53fw1kFk2KaspzT QtnEDYNQnBdZKjqntAkExYZY66HDoGVGlqTI5ZjrA4IyQD3kQ0yFxANhsaoC AaQcGSYLAaGJkaIkiUiYZkOADra9jErydB3FjIzMvo6tijd/f82d75Gd+kCN 4AF8OLe6YInKwQBSCcDMhIIF7WzzZIRKcg93FziylNTVBafdF5uI7cdrDlG5 bNG0xTkLcGC4SDZ6wqBGvAOSZCBxfSAfDc9NUlrs8L132q1oyBWBCBH47eLz Fz4X5VTgtk5b3TwW0b8RPFErn6LmddF7H0eAHfAkFEv2MMFxamBwRkz2EdYl w4QYVc5ILO52Oshzcrdo9yBCCEOgnv0E7vERHOe3TkU1swcATr4l8tQ650cL enpwUMzzgMgxKc4G3Br160HSPlBYv4YYZCWgHcYGkGJCH+pAC8CEUSRAiTCs 3kVzTUBK5MhxlnvKpXvCKmPRWUu1J8mDR8rMsYY6WqeVbIhtQP5Jjhi94Fgo f6fXIKGzCg0sGenaFnQEiG0rl9t2QQT48lqboIQGMCBCKkIsUhG9CFAxGKsG iKRqkkCCC+1WneqAMe45HKIp8+SHzV9IA48+pqSPZE5Kh5OaLvocj5fgRNxz XkF5n6A9/kc6AcNXosdAJagX7iIF4YkqN2ElEU3ES0MYoRCRC3r6snHJSoJT FyGAUFpSAVFiRYUlBErwWFMEiA/anfqoqBvOzT5puifX0Gs9wgqR6spkZiYf v1YYyChRhCxJjDC0THlZ3PKmCXa3INJV55FMq0r8VjAHOVmWU2TtnlMp8Jx2 rrrtOVVoafrt0ir0ooGjg8o4o3tljiaNcdXRSlOkE8xPx3ZOFzGXdCVyVKSt 4J0OpduDlPJzI5cUiM0S1Yi8Yd3R+b9p0byaZA6fk4HNV8N8SVkcd08QRIOO o5Af8VyZTXvstDQ2UjwnSTeXQzsD2eNevnd+o6Zx3Y4Q97eCn8vMuLc6/fxl pnXty/nqxyB9z5Xrw9p+PFASvVUmP0HO40mEkyo7JmzsJSdN5R+7eMLQ+Y1D YkltDJk3YqqpPFPTSVWe+DMTUePfYzSmJFsjUJdRzDO3I7X2vxzJUqFpMwMz mUqMp2RO0DeSON7iVlN6lagMm6hq44INrKnCxp6h6QJKJrBSeoZ1WnSKV7xH I72+ENxlxcv6xUOvQdv6Pb078lZK9KXLGiClyAXBKWvbvz74xIKCQIaF5p3d zT04nop2CiWJd4EIKCB4h3R1uY9zjtY3Mwyg+SyEje7zqGnuw4WJcG9eXRFn T4RC0O3Yt8nfShqFm2Ti0JspnPLmtNt/CI2Z57cR7DDRnr27Y73xrNNLJPmT u5q7pU6XbvMHb3hlSpyCn1TteipgXnnR7B2qNAr87ltR4Q9+ERqq6EvfGM21 v37HKHXmi08EhoWGdtW5hkDK78mvF8Yao09BEtbCHJHHkTc+CCBwboQ5y57u UpaCUDgSQZksocEmES5LTJLM33DSYN/9P+jrTVU9o+OxXVPdnwPt88TTDsYM OR6vSi72+vi4LxveNGGzXVXds6jHW2ilG3hpeCGUe5KkCQiQhj3mOX0+4Q98 2TqatoZBAPb430wPQWa2wERDpVh2prVOEOGBjTINMK762BeSvDPUsS9FwuSJ GAiZxts0Fg/wYcptdPBeBOILz790tHr27sCctWEPpPkqXpfFuSftQwRNjUNY jNAyJGLFMYDaAI6SGSEYRIO220IbTNVYOBPlMUzDR+gcHVTDMm+/6+OIzWFZ tBpDONhG4uUXSGfDRt37wK6ItPjMt2uPO5hmuZ5XWBIjA6pAUhhT9VkuDNJF PUYb6d9h1BbsIiT0OkJ0kSR1CJZHKWxPOGIOXkGpVnXqn4mZkHt4yUwQA7jk vC6XZXiQU6RQIrYPCNh6odgC9e3WszAgdYqhw8mk1qhq33EIaYw0oh3aYg5R V8LmDdxKE02/s9lM3paqDz5LbctzR/Ftt+HgQno7/dqG54yeKIcj8QUtmR3F C4VOJCJEQpn132G2dlGONCA9FJoniqK5Ekzx3dXMYt4yOfah5tuuf40wfApT XjYfDQU4ZaFrA97Av0HGGbPPDfQQvk7YU/ofyyCQO28YBoGtg9LPiLGL8JII e0HP76OZp6wjFhEIyKkbtAL7IahqSQujuw924wViiciw4O64nIQ9XNUQYqiI iqqMYiIqjFEiCiiU9QYUnNORq7YX2NsOTObqLqAUpKJ1KZiSnQ9JSlENw4if mOvVvYiQkGhJDWnWLjR7QL9qQp3dK8gOgbXuAU78gFPTmIeEVyiNJAPKpVPf 7JaHbmHM+hK1yzXUnKBDnjwoFhgpbFrmLrDUmb7ZtsaiAs3YbDRWYMJgkkoy PT9nHR37WpKYeZp1ZUOZGfOOBzsP3CE8yaFmjwiIiXwuMylGpasSqqJbbSKi jVRW0sFbhkzbhpktddjCJS2qonwQ6LPviItwzrHLzOJ0t7YQHAOZDDmW0wrx VWFUurRO0jCC/nCy15Wo3TQ1zmJaQLKSChEJQRima1JoQSaiyBqhU5gSZTgE Qsoc48DhAjaWMqjEtAoozHGVh8ujRhXdNmY6guGTR7004nGsjLTECtsSANgK WspAwiTMiygl1wYdrIdTogqw5LFfLNMg31KS5oHzoWxOZwtUDtHBHKVFQ2xI h6g5eju0ExN5mUHmcSJTxukJ8kCoZXZCQjbt0Lnd4QkTl/PyDB54D1RVUUcL VVVAGSCrGjReyEjkKzfBYKqoKJhZKj87QPN6g2+X5LXhgoF4QkiWvSr2W3HG XVx6I0IQ+f3sbChn4txskus2DNUszWCGY3DM63D0LQWyENnD6TLLjobGaZFO yLd1kWcGQGa0OwhPElufsQwZy5VlpggQgKTjaBtDOEO6PTEEk2JpddUH3sCs RkB2wCZr+KZgCoYBAbi3lrXTMQxMBSVWbXM1KWjGJiI7FEba27z3TilyUcwm Dh2ngM4SZAtLgjkSM4zhG46PJNGnhWeW4BkBem2+ZlMSqi5oDYxBCGCkp5Ou emAJwLZrQMhNKKy2ZYxJAxl5LWs5JJS1AzsNRBnUhorlpOKN7AmGGNiHgGxy dcm+OmMAMzbE11+rSNudhZfTc7qh33Lap8/I5ZLtgYM7xpzimYwxw8CrBgK2 a4gGkAQ1aiQ3iLA3gRWSg2zE1rWba04GzWJadGanDDAmQIxVYktBhDJaray8 7WwNADM7iyZ1CkkjCICQHdgYIB2YyPs3l8KZodc80nJ5VNIPSt2cm+iwiSIC iwIEjN9r2JvN5rg3Fd4BpktLCtHSXpfNYEZzW8RF8NozdF0xV/wmWbgo2yEI QhCK04NiZNSG4tMgQhJHcBNRBY8IeQBMTJVwRFsXNhQ5fDu2X6BOwIGTKGR5 +bjOhJTIZRLQnsIbbzGOB7J1i2wSZvsoDlWkjpgVDhqatnOnC8+fTjjcEFBF HQnMcDRZSlLeV5u/Pk9vGuEy2ynhJZVjOwaTHCmBOITacjximZGqLjtVWcnc xCbaed4Y66pQxgaOAstxRRpNcwwNZm9k0zTMwiqwCoJwoaEhqOwLliDHJjJ0 5OHXHRCjMTibPS6ew5hO6tAVmoacCNQzzMRhu7dgB2Yo550doXbVdUw5ZzIk 6ZJm5Og1Lm6KKw7Q3LvzhEJkbcgNYcBoQLneTl9US9dQVfNPjljh2y+2TMlC 2Otp+pBKgIfi7yTvnbXgfh2dlo0w1DIFogBJN7OBRqYWO7khe+xtpDEd4yb7 FsDDRmQHaMWCyGh4KFiDJLwkIGmeSsSZJrCwzStdBMwSCShge8GxQBQIYo0E ZJa6Y0pHTU7CQNQNTLbBISCKaQGkkcHgkSC4YkJvCY3bYNzehqGyRFSCJFAU kUVYjBZAWAICMGMAFiBEkRhDnlxH+PALh/FN8xU1KofSw37kb3rFxXuMNL/e RkBwVL9u+6Ipm4RGhU1AjZGncGZUWWPRcKY86KiVExdYKgwaW3uCOZINnRYz pNk1mpBpr9Ms5MMt7NRdAQstgqJ4Tvoj167bDoo09FgqCZA2YPs1uJNOU8E1 oD7+7XoO80m5pnoZEqqgaLJBSQNdEUKkSiPFXSR1oQnKUSEvpOn4W56mQlN4 HahiVAoGx3JAIZTc2WaBGTYKoRO5mh8bdfcYVpOkFVqVv2wGzkcZuIeT0bio om3dmMYxiiKIiMiqgI06w6wdRdKrGMFFSLGIIR031jeAcApuOBs7XQPPnB1x ABUJCGPuVgrLYWccWYddZdYIsJolGYtgXZgW3M2dcWBXac9wL1MVJPNpUogj Ir66+iCFiHbKoe3Xswe0Z+R5JyBHIHCSB5kASSJUlREiNQGghy7/qoGoEiPj zAJub91IajoeZQcpl1TYnv0WiyYCHfykJHe1DcLAU95ubw3HK1b1kQytN1f1 6BTyuFaEfXtwQwBVA7QytQjBU+HCr1rvmeDkeWSVeJWLobIZEMUSvn17/c6n Z3Za1WWhi99neOXq93Fk0BKipG9U1MbhguDlCUs1J2HQ8pTgqqDadJE3vIxg b5o4BU/R8jc33rlsYQ0h6wqwBcEFSQKnZJZwE9RQxIxWKKsUUFYkfaTn3RDv iNLKkIss86XGIIJARMPHyJ2DIPWT1UwQ1KURDSSCkFxQZIoWZYCyFiAVRGL/ 1QEWKSBA6i0Gcr8xDpeliB4EFfaF0EMjs28yby+82vBrl7exzpeVwd87yB5z FRUDioJynX9QRNgEsbVJAoLWqhfKij74gCYDAW6fBd2Utu+TxPf22s1mXUx1 mIx7wG2zmxbgdGkQnSQ7MiyRMO8aQ/mhGKh1O9A6OXDX+88bu47uL+WLI8gf bc5BMsmuR0HoPMXTmAl2SoqUcat+f489HnFzM81qFEpfTC0skJVRjVBiMlQl T9SWOAwLEh4EhCOshvPMioJ/lACRBhEZIQhEFA7HFMTJcmEJvnwWwudhUFxH eADCvsisg2eyKEiBIGGI8UyzGMunrA70SuXUdoSEhUoCqyYacNBQsAX7oqmq QbQP32KHwLw6aln4FocYr8yJ8UpuAvcCBoRN4MJYgCfs/qNGGg3AZJEICEIP MsSeMBTz+M+tqUzHw9RxZzV+eSrkpjKzGlrJBIiEEnYISgJEiSAalw5f2G9+ bl2W0HROlrPVQQr4A/IUlC5QUPHScSJxoobiGg+HUSXMEZA6G8QDMidqfWTl FQ6pVlS3m4GWEjDYHCtJsmAyKAkssKvro8JwYEOFWf03gU5HOSfPNcvYWXe6 VMGqr+56ZR/dQ3kncMLzJlvq6cpoPxBDqCYaBqY2ovLoEuV+7KISHgzEFqeL DEgVlywKrGIageycYPZ2tgipGRGLPzzCU2BhG4a2nMRzPmoTz72iGRRSROBZ X4enqdzCZhsJQNwzgiZcSpyaQZETeSCuhdN+QN1WwDA+gDnp0gzdQHRvYmzj RYimaeqoQIR7MCjGrIba2LRxD5TcmWYBToRBT/IgsIgEVOyigAwxTsKKOR5p BBFBVBQURWAiHbbNUPmI6bZnGHDs16YMi2roK2TVNj9ZQJqc4cSxkUjBFLw3 dh/KieFSFKi4lCyLO4vW5DERmfceSkjobCcVt5y4Ke+8d2E2YhP+s0wjIs04 WnSVCIcwVgVXacM5c0jtt9GpR5wVLttmwm3HrnQsXeKRWQ4FgW1b8Sd8I0vE zVz1wYahC0Wv37FDOTfmLKjosmk6IHIDYs9wiMcJC8IUZ8mPzRgHs5m4B1io Z4A+EQTNBPawUE2YhjABD1RRkBOQCbNxJ0HF6kFHbE/qDtC3AnonIlVeU28/ AKCAHyoCKikTZlisYgsiwFEWCyQqEPbEisYMYEpIsf7JBWAxCRIAf1n8/7Kv /uMBXEB9+NaQAqCWqFP6EgYwxkixFITowwggyGsIo1IGpLIqjAyB65D1H+Eb pPwIMwRqJkFIP/8XckU4UJAYDJc3 ------_=_NextPart_000_01C2D2BB.412423C0-- From owner-linux-xfs@oss.sgi.com Wed Feb 12 10:16:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Feb 2003 10:16:52 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1CIGl3v012955 for ; Wed, 12 Feb 2003 10:16:47 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id AF87418BCC33; Wed, 12 Feb 2003 10:25:00 -0800 (PST) Date: Wed, 12 Feb 2003 10:25:00 -0800 From: Chris Wedgwood To: Bogdan Costescu Cc: linux-xfs@oss.sgi.com Subject: Re: Defrag pitfals (was Re: Support for XFS File systems) Message-ID: <20030212182500.GA11383@f00f.org> References: <20030211201735.GA6124@f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2633 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: 2587 Lines: 66 On Wed, Feb 12, 2003 at 11:54:12AM +0100, Bogdan Costescu wrote: > Could you (or somebody else) please elaborate on this ? Short answer: xfs_fsr can (and usually does) destroy locality of files. Longer answer: xfs_fsr, when run without a filename (or list of filenames), does a bulkstat of the filesystem and finds candidate inodes to defragment. bulkstat avoid having to do a tree-traversal and it's pretty fast for the most part. xfs_fsr defragments the files by creating a new (temporary) file, copying the data from the fragmented file to the new file swapping the extents before releasing the temporary file. The problem with this is that it can destroy locality of files: consider a directory of source code for example, most of the files are *near* each other (xfs_bmap -v will show this) as XFS tries to group files in same directory into the same AG as the parent directory[1]. Now, because xfs_fsr doesn't actually create the new file in the directory of the file it's going to replace, the filesystem can't try to place the new (temporary) file near the others and it may end up being located somewhere very different. Since XFS does a pretty good job at preventing fragmentation, for things like large trees of source code it appears better to have the odd file (slightly) fragmented that the odd file scattered elsewhere on disk. Now, if you have a small number of directories with fragmented files and want to defragment the fragmented files and *NOT* ruin file locality, you can try "xfs_fsr /path/to/dir/*" and see how that fares. > I've switched several file systems to XFS exactly because of the > feature of defragmenting while the FS was still mounted. I've tried > to find this kind of information prior to switching to XFS, but I > failed... empirical evidence suggests that defragmentation helps a > lot in my case, but I would really like to be aware of situations > when this feature would become detrimental. I'm curious as to why it helps so much in your case... what are you doing that causes lots of fragmentation? Does your disk ever get really full? Do you do lots of synchronous/or direct writes? Do lots of NFS clients access your filesystem? As a general rule, XFS doesn't fragment all that badly. On my desktop for /home, which is pretty active (thousand of files created and deleted every day), I have about 240 fragmented files from over almost 800,000 files. Thanks, --cw [1] Actually, I'm a bit vague on this and too lazy to check the source right now, so maybe I'm wrong in which case someone can correct me... From owner-linux-xfs@oss.sgi.com Wed Feb 12 11:19:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Feb 2003 11:20:00 -0800 (PST) Received: from mail.iwr.uni-heidelberg.de (mail.iwr.uni-heidelberg.de [129.206.104.30]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1CJJt3v014138 for ; Wed, 12 Feb 2003 11:19:56 -0800 Received: from kenzo.iwr.uni-heidelberg.de (kenzo.iwr.uni-heidelberg.de [129.206.120.29]) by mail.iwr.uni-heidelberg.de (8.11.1/8.11.1) with ESMTP id h1CJS6b03562; Wed, 12 Feb 2003 20:28:07 +0100 (MET) Received: from localhost (bogdan@localhost) by kenzo.iwr.uni-heidelberg.de (8.11.6/8.11.6) with ESMTP id h1CJS6N08741; Wed, 12 Feb 2003 20:28:06 +0100 Date: Wed, 12 Feb 2003 20:28:06 +0100 (CET) From: Bogdan Costescu To: Chris Wedgwood cc: linux-xfs@oss.sgi.com Subject: Re: Defrag pitfals (was Re: Support for XFS File systems) In-Reply-To: <20030212182500.GA11383@f00f.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2634 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: bogdan.costescu@iwr.uni-heidelberg.de Precedence: bulk X-list: linux-xfs Content-Length: 2972 Lines: 67 On Wed, 12 Feb 2003, Chris Wedgwood wrote: > Short answer: > xfs_fsr can (and usually does) destroy locality of files. Thank you for the answer ! > I'm curious as to why it helps so much in your case... what are you > doing that causes lots of fragmentation? Scientific simulations that produce large amounts of data over a long time. Of course, "large amounts" and "long time" is relative, in our case being "several hundreds megabytes" and "days". The file is created at the beginning of the simulation and data is appended to it for the whole simulation duration; data is never rewritten during the simulation. Depending on data size, simulations can finish sooner or later and produce files that are of different sizes, however in order to ease later backup, we limit the size of one file to approximately 650 MB. Writting to disk is not a problem, as the rate at which data is produced is very low. However, reading the data becomes a problem and we need to do it to either analize the data or transfer it from there to other computer or CD. When using ext2, by writting a several hundreds megabytes file with 'dd if=/dev/zero' would produce a file for which reading speed was about 20 MiB/s, independent of the state of the FS (newly formatted or nearly full), which was what we expected from this disk; however, reading one of the simulation files is done at 2-3 MiB/s, leading to problems f.e. when trying to write to CD with a piped "mkisofs | cdrecord". After switching to XFS and (mea culpa!) forgetting to set up xfs_fsr to be run by cron, the read speed would be similar after several days-weeks. However, by using xfs_fsr we go back to reading with around 20 MiB/s even for a pretty full FS. > Does your disk ever get really full? Sometimes; not everybody is careful about taking data away after it was produced... But >75% full is normal. > Do you do lots of synchronous/or direct writes? Probably not, most of the code is written in Fortran... > Do lots of NFS clients access your filesystem? Most often, we run this simulations as parallel jobs; however only one process does the I/O. The behaviour is about the same when using either: - NFS clients (<10 at one time) write to this FS - there is one parallel job running on several nodes with one process on the node with the disk which is the only process writting to the file; no NFS access in this case > As a general rule, XFS doesn't fragment all that badly. Well, given the conditions, I think that any filesystem would have problems. But the nice thing about XFS, which made me switch, is that defragmentation occurs without unmounting the FS which lets us run simulations _and_ read data at hight speeds. -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From owner-linux-xfs@oss.sgi.com Wed Feb 12 11:27:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Feb 2003 11:27:24 -0800 (PST) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1CJRH3v014612 for ; Wed, 12 Feb 2003 11:27:17 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1CIghKp006473 for ; Wed, 12 Feb 2003 10:42:43 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA67490; Wed, 12 Feb 2003 13:35:23 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA04708; Wed, 12 Feb 2003 13:35:23 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h1CJZNL25347; Wed, 12 Feb 2003 13:35:23 -0600 Subject: Re: Defrag pitfals (was Re: Support for XFS File systems) From: Steve Lord To: Bogdan Costescu Cc: Chris Wedgwood , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1045078522.1850.50.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 12 Feb 2003 13:35:23 -0600 X-archive-position: 2635 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 553 Lines: 18 On Wed, 2003-02-12 at 13:28, Bogdan Costescu wrote: > After switching to XFS and (mea culpa!) forgetting to set up xfs_fsr to be > run by cron, the read speed would be similar after several days-weeks. > However, by using xfs_fsr we go back to reading with around 20 MiB/s even > for a pretty full FS. > You can always tell fsr to just defragment these files, rather than the whole filesystem. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Feb 12 11:28:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Feb 2003 11:28:51 -0800 (PST) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1CJSk3v014752 for ; Wed, 12 Feb 2003 11:28:46 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1CGxvKp027847 for ; Wed, 12 Feb 2003 08:59:57 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA32968 for ; Wed, 12 Feb 2003 11:52:38 -0600 (CST) Received: from rose.americas.sgi.com (rose.americas.sgi.com [128.162.232.98]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA31492 for ; Wed, 12 Feb 2003 11:52:39 -0600 (CST) Subject: XFS 1.2 available From: Rusell Cattelan To: linux-xfs@oss.sgi.com Content-Type: text/plain Organization: Message-Id: <1045072349.4899.21.camel@rose.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-1) Date: 12 Feb 2003 11:52:29 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 2636 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@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 525 Lines: 17 Ok so this announcement it a bit late but XFS 1.2.0 has finally been released. Please refer to the web page. http://oss.sgi.com/projects/xfs/ For the full announcement. Note the original "core" patch was incorrectly generated the first time around. Please check your md5sums to make sure are the correct patches before trying to patch your kernel. 9fc8546a7466f1d5ceb772b9e04d58af linux-2.4.19-core-xfs-1.2.0.patch.gz e0b76f53bc82d721614b6b63284b2c54 linux-2.4.19-xfs-1.2.0.patch.gz -Russell Cattelan cattelan@xfs.org From owner-linux-xfs@oss.sgi.com Wed Feb 12 11:59:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Feb 2003 11:59:19 -0800 (PST) Received: from mail.iwr.uni-heidelberg.de (mail.iwr.uni-heidelberg.de [129.206.104.30]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1CJx93v015681 for ; Wed, 12 Feb 2003 11:59:10 -0800 Received: from kenzo.iwr.uni-heidelberg.de (kenzo.iwr.uni-heidelberg.de [129.206.120.29]) by mail.iwr.uni-heidelberg.de (8.11.1/8.11.1) with ESMTP id h1CK7Lb04455; Wed, 12 Feb 2003 21:07:21 +0100 (MET) Received: from localhost (bogdan@localhost) by kenzo.iwr.uni-heidelberg.de (8.11.6/8.11.6) with ESMTP id h1CK7Lg08982; Wed, 12 Feb 2003 21:07:22 +0100 Date: Wed, 12 Feb 2003 21:07:21 +0100 (CET) From: Bogdan Costescu To: Steve Lord cc: Chris Wedgwood , Subject: Re: Defrag pitfals (was Re: Support for XFS File systems) In-Reply-To: <1045078522.1850.50.camel@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2637 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: bogdan.costescu@iwr.uni-heidelberg.de Precedence: bulk X-list: linux-xfs Content-Length: 1560 Lines: 34 On 12 Feb 2003, Steve Lord wrote: > You can always tell fsr to just defragment these files, rather than > the whole filesystem. Sure, but there's not much else on the FS. And it would mean to find a reliable way of identifying them... Too complicated :-) But either at file or FS level the important feature for us (OK, I'll say it just one more time :-)) is that it can be done with a mounted FS; I'm not aware of any other Linux FS where this is possible. Thank you for your work ! [Maybe OT] Inbetween these messages, I talked to a friend about a networking problem that he has as part of a P2P network. Then made the connection that the way files are stored when downloaded from such network is very similar to our situation (talking here only about large stuff like ISO images, movies and whatnot) - files are written to disk over several hours, days or weeks, depending on Internet link speed and availability. The difference might be in appended vs. random writting mode; for the networks that support chunked file transfer they are probably written as sparse files. Then the files have to be read for writting to CD (ISO images), played (movies) etc., so they have the same problem. Heh, that could make XFS the FS of choice for all Linux P2P users (outlaws or not) around the globe :-))) -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From owner-linux-xfs@oss.sgi.com Wed Feb 12 12:08:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Feb 2003 12:08:07 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1CK833v016185 for ; Wed, 12 Feb 2003 12:08:04 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 79171186F7B7; Wed, 12 Feb 2003 12:16:17 -0800 (PST) Date: Wed, 12 Feb 2003 12:16:17 -0800 From: Chris Wedgwood To: Bogdan Costescu Cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: Defrag pitfals (was Re: Support for XFS File systems) Message-ID: <20030212201617.GA12161@f00f.org> References: <1045078522.1850.50.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2638 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: 1778 Lines: 43 On Wed, Feb 12, 2003 at 09:07:21PM +0100, Bogdan Costescu wrote: > [Maybe OT] Inbetween these messages, I talked to a friend about a > networking problem that he has as part of a P2P network. Applications which write to multiple 'parts' of the file simultaneously (ie. reading different parts of the file from different foreign hosts) tend to cause bad fragmentation. I'm not sure if this is better or worse with other filesystems. > Then made the connection that the way files are stored when > downloaded from such network is very similar to our situation > (talking here only about large stuff like ISO images, movies and > whatnot) - files are written to disk over several hours, days or > weeks, depending on Internet link speed and availability. Slowly writing to disk over a long period of time whilst there is other disk activity increases the likely hood of fragmentation. A good example here is log files. It's even worse if you write pattern means you open and close the file between writes. If this isn't the case you could in theory tune the preallocation on the filesystem to make it greater and see if that helps (I tried it here with positive results). > The difference might be in appended vs. random writting mode; for > the networks that support chunked file transfer they are probably > written as sparse files. Writing to sparse files randomly bites. Without application level changes this is pretty hard to do much about. > Then the files have to be read for writting to CD (ISO images), > played (movies) etc., so they have the same problem. A small mount of fragmentation isn't really that bad... I guess it depends on the average extent size and their physical layout on disk and to how hard the drive works to access this data. --cw From owner-linux-xfs@oss.sgi.com Wed Feb 12 13:35:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Feb 2003 13:35:10 -0800 (PST) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1CLZ63v017455 for ; Wed, 12 Feb 2003 13:35:06 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1CKoWKp019533 for ; Wed, 12 Feb 2003 12:50:32 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA57062; Wed, 12 Feb 2003 15:43:13 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA68172; Wed, 12 Feb 2003 15:43:13 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h1CLhDp30384; Wed, 12 Feb 2003 15:43:13 -0600 Subject: Re: Defrag pitfals (was Re: Support for XFS File systems) From: Steve Lord To: Chris Wedgwood Cc: Bogdan Costescu , linux-xfs@oss.sgi.com In-Reply-To: <20030212201617.GA12161@f00f.org> References: <1045078522.1850.50.camel@jen.americas.sgi.com> <20030212201617.GA12161@f00f.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1045086193.30216.23.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 12 Feb 2003 15:43:13 -0600 X-archive-position: 2639 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 3342 Lines: 82 On Wed, 2003-02-12 at 14:16, Chris Wedgwood wrote: > On Wed, Feb 12, 2003 at 09:07:21PM +0100, Bogdan Costescu wrote: > > > [Maybe OT] Inbetween these messages, I talked to a friend about a > > networking problem that he has as part of a P2P network. > > Applications which write to multiple 'parts' of the file > simultaneously (ie. reading different parts of the file from different > foreign hosts) tend to cause bad fragmentation. I'm not sure if this > is better or worse with other filesystems. > > > Then made the connection that the way files are stored when > > downloaded from such network is very similar to our situation > > (talking here only about large stuff like ISO images, movies and > > whatnot) - files are written to disk over several hours, days or > > weeks, depending on Internet link speed and availability. > > Slowly writing to disk over a long period of time whilst there is > other disk activity increases the likely hood of fragmentation. A > good example here is log files. > > It's even worse if you write pattern means you open and close the file > between writes. If this isn't the case you could in theory tune the > preallocation on the filesystem to make it greater and see if that > helps (I tried it here with positive results). > > > The difference might be in appended vs. random writting mode; for > > the networks that support chunked file transfer they are probably > > written as sparse files. > > Writing to sparse files randomly bites. Without application level > changes this is pretty hard to do much about. > > > Then the files have to be read for writting to CD (ISO images), > > played (movies) etc., so they have the same problem. > > A small mount of fragmentation isn't really that bad... I guess it > depends on the average extent size and their physical layout on disk > and to how hard the drive works to access this data. > A thought occurrs to me here, xfs will not drop space out beyond eof if XFS_DIFLAG_PREALLOC is set in the inode flags. Right now the only way to get this is to use the preallocate call. If you look in xfs_setattr you can see some code like this: if (mask & XFS_AT_XFLAGS) { ip->i_d.di_flags = 0; if (vap->va_xflags & XFS_XFLAG_REALTIME) { ip->i_d.di_flags |= XFS_DIFLAG_REALTIME; /* This is replicated in the io core for * CXFS use */ ip->i_iocore.io_flags |= XFS_IOCORE_RT; } /* can't set PREALLOC this way, just ignore it */ } It would not be too hard to extend this to allow setting the prealloc flag. There is an XFS_IOC_FSSETXATTR which would allow setting it. We could extend the ioctl interface for xfs to take the EXT2_IOC_SETFLAGS ioctl which is used by ext2,ext3 and reiserfs, and use one of its bits. We could then have files which would have less tendency to get fragmented as you extended them over time. They still would get chopped up, just less so than before. Just a thought. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Feb 12 13:56:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Feb 2003 13:56:47 -0800 (PST) Received: from myphorum.de (h-217.110.117.254.host.de.colt.net [217.110.117.254] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1CLud3v018228 for ; Wed, 12 Feb 2003 13:56:40 -0800 Received: from localhost.localdomain (user4@pD9E8304E.dip.t-dialin.net [217.232.48.78]) (authenticated) by myphorum.de (8.11.6/8.11.2) with ESMTP id h1CM4pC19922 for ; Wed, 12 Feb 2003 23:04:51 +0100 Date: Wed, 12 Feb 2003 23:05:57 +0100 From: Thomas Seifert To: linux-xfs@oss.sgi.com Subject: Release 1.2 for Kernel 2.4.20? Message-Id: <20030212230557.3ece54af.thomas.seifert@myphorum.de> Organization: MyPhorum.de X-Mailer: Sylpheed version 0.8.8 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavis-milter (http://amavis.org/) X-archive-position: 2640 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: thomas.seifert@myphorum.de Precedence: bulk X-list: linux-xfs Content-Length: 355 Lines: 16 Hi folks, thanks for that great filesystem. I use it in production on many system and never had any problems with it :-). For the current release, is there a chance to get official 1.2-patches for the 2.4.20-kernel or maybe the upcoming 2.4.21? Or do we have to live with snapshots from CVS for it? Just curious about the policy on it. TIA, Thomas From owner-linux-xfs@oss.sgi.com Wed Feb 12 15:44:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Feb 2003 15:44:29 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1CNiK3v021223 for ; Wed, 12 Feb 2003 15:44:20 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1CNiKMV021222 for linux-xfs@oss.sgi.com; Wed, 12 Feb 2003 15:44:20 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1CNiH3x021208 for ; Wed, 12 Feb 2003 15:44:17 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1CNe1GT021157; Wed, 12 Feb 2003 15:40:01 -0800 Date: Wed, 12 Feb 2003 15:40:01 -0800 Message-Id: <200302122340.h1CNe1GT021157@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 219] New: O_DIRECT io no longer works when the available data size is less than the underlying block-device size? X-Bugzilla-Reason: AssignedTo X-archive-position: 2641 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1971 Lines: 87 http://oss.sgi.com/bugzilla/show_bug.cgi?id=219 Summary: O_DIRECT io no longer works when the available data size is less than the underlying block-device size? Product: Linux XFS Version: unspecified Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: Medium Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: cw@f00f.org this occurs linux-2.5.60; 2.4.x (from oss' CVS) works as expected under 2.4.x i am able to read a 1 byte file O_DIRECT; 2.5.60 fails when doing this testing fs-block-sized (well, == page size, really) reads with a 5k file under 2.4.x shows i can read the first block then a partial for the second block (as expected) under 2.5.60 the first block read correctly, the second barfs --------- snip snip --------- source code --------- #define _GNU_SOURCE #include #include #include #include #include #include int main() { int h; int ps; char *buf; ssize_t n; ps = getpagesize(); if (!(buf = valloc(ps))) return 1; if ((h = open("od.c", O_RDONLY|O_DIRECT)) < 0) return 1; do { n = read(h, buf, ps); if (n == -1) { perror("read"); break; } printf("read %d bytes\n", n); } while(n); close(h); return 0; } -------------- snip snip -------- scissor party ---------- results (not a 5k file as mentioned above, s/od.c/a.out/ for that): cw:0@tapu(cw)$ uname -r 2.4.20-cw2 cw:0@tapu(cw)$ gcc -Wall od.c cw:0@tapu(cw)$ ./a.out read 503 bytes read 0 bytes cw:0@tapu(cw)$ and charon:~% uname -r 2.5.60 charon:~% gcc -Wall od.c charon:~% ./a.out read: Invalid argument ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Feb 12 16:01:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Feb 2003 16:01:52 -0800 (PST) Received: from smtp.ii.uib.no (eik.ii.uib.no [129.177.16.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1D01l3v021801 for ; Wed, 12 Feb 2003 16:01:49 -0800 Received: from apal-192.ii.uib.no ([129.177.192.27] helo=apal.ii.uib.no) by smtp.ii.uib.no with esmtp (Exim 4.10) id 18ift4-0001Tu-00; Tue, 11 Feb 2003 20:16:10 +0100 Received: (from janfrode@localhost) by apal.ii.uib.no (8.11.6+Sun/8.11.6) id h1BJGAB16210; Tue, 11 Feb 2003 20:16:10 +0100 (MET) Date: Tue, 11 Feb 2003 20:16:05 +0100 From: Jan-Frode Myklebust To: Eric Sandeen Cc: Rainer Krienke , linux-xfs@oss.sgi.com Message-ID: <20030211201605.A16099@ii.uib.no> References: <200302101000.22190.krienke@uni-koblenz.de> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: ; from sandeen@sgi.com on Mon, Feb 10, 2003 at 07:08:32AM -0600 Subject: Re: What is needed for a stable 2.4 based system? Content-Type: text/plain; charset=us-ascii X-Scanner: exiscan *18ift4-0001Tu-00*We6nWYu0CDg* (ii.uib.no) X-Scanner: exiscan *18ift4-0001Tu-00*We6nWYu0CDg* (ii.uib.no) X-archive-position: 2642 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: janfrode@parallab.no Precedence: bulk X-list: linux-xfs Content-Length: 775 Lines: 20 On Mon, Feb 10, 2003 at 07:08:32AM -0600, Eric Sandeen wrote: > For starters, the patch you downloaded is a development snapshot, so if > it's stable, you're just lucky - it has not undergone extensive testing. Is it really that bad? I'm in the process of setting up a server with ~2.5 TB of XFS storage, and was just about to go for the linux-2.4-xfs cvs-tree. Plain 2.4.19 woun't do for me, since there's a hard lockup bug in the tg3 driver that wasn't fixed before 2.4.20rc3: http://www.uwsg.iu.edu/hypermail/linux/kernel/0211.3/0167.html and this is exactly the hardware I'm planning on running my storage from. I've had the impression that the cvs-tree was purely a bugfix only tree, and that it should be as safe as the kernel.org tree. Is that not true? -jf From owner-linux-xfs@oss.sgi.com Wed Feb 12 16:31:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Feb 2003 16:31:40 -0800 (PST) Received: from ks406.kasserver.com (ks406.kasserver.com [62.141.48.110]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1D0VT3v022449 for ; Wed, 12 Feb 2003 16:31:30 -0800 Received: from anubis (Aff0c.pppool.de [213.6.255.12]) by ks406.kasserver.com (8.11.6/8.11.6) with SMTP id h1D0ddm00669 for ; Thu, 13 Feb 2003 01:39:39 +0100 Message-ID: <042b01c2d2f9$9ad51260$5a02640a@terragon.de> From: "Achim Altmann" To: "xfs mailinglist" Subject: Please need help RH and RH-8.0-XFS-iso-image break? Date: Thu, 13 Feb 2003 01:48:19 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-archive-position: 2643 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: achim@altmann.li Precedence: bulk X-list: linux-xfs Content-Length: 429 Lines: 20 Hello, i had downloaded the new RedHat-8.0-xfs-iso.image and after if i have selec= t my pakets an=B4d like start the installation then on the first paket (gli= bc-common-...) say the system please insert the CD1 I pushed in the same CD and start again , the system say, "that isn't a SGI= -XFS-CDROM" Please could any tell me what is wrong? Thank's a lot for any helps Reagards Achim [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Wed Feb 12 16:38:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Feb 2003 16:38:49 -0800 (PST) Received: from nyx (h24-70-202-183.gv.shawcable.net [24.70.202.183]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1D0ch3v022940 for ; Wed, 12 Feb 2003 16:38:44 -0800 Received: from sshack by nyx with local (Exim 3.35 #1 (Debian)) id 18j7TD-0004LK-00 for ; Wed, 12 Feb 2003 16:43:19 -0800 Date: Wed, 12 Feb 2003 16:43:19 -0800 To: linux-xfs@oss.sgi.com Subject: xfsdump doesn't seem to respect -d option. Message-ID: <20030213004319.GF26472@nox.steveshack.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="h56sxpGKRmy85csR" Content-Disposition: inline User-Agent: Mutt/1.3.28i From: "Steve P. Shack" X-archive-position: 2644 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: sshack@steveshack.org Precedence: bulk X-list: linux-xfs Content-Length: 1197 Lines: 42 --h56sxpGKRmy85csR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I'm attempting to use xfsdump to generate a dump images of a certain size (for backup onto cd). xfsdump claims i'm giving too many options. "too many -? arguments: maximum is 1 when running in miniroot". My command line looks something like this. xfsdump -d 750 -f backup1 -f backup2 /=20 This seems to work on irix, or at least it doesn't bail out right away. irix seems to just ignore -d (but then I was testing with -d 10 there). any ideas? I'm hoping to have xfsdump a bunch of files which I can write to cdr as a backup. --=20 -- Steve Paul Shack sshack at steveshack dot org GPG Fingerprint: 22C5 195E 0060 9EAF 0DFC D933 93DC 4BC9 C429 = 53F6 http://www.steveshack.org --h56sxpGKRmy85csR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+Suonk9xLycQpU/YRArIoAJ99WaqZOg7GQruRpV/3jFmBUNaPlACeNXWe wJxt5Z+R85+gaCWz5nNEnQ8= =DW/i -----END PGP SIGNATURE----- --h56sxpGKRmy85csR-- From owner-linux-xfs@oss.sgi.com Wed Feb 12 17:01:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Feb 2003 17:01:35 -0800 (PST) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1D11W3v023627 for ; Wed, 12 Feb 2003 17:01:32 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h1D0GwKp004730 for ; Wed, 12 Feb 2003 16:16:59 -0800 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA21802; Thu, 13 Feb 2003 12:08:23 +1100 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 88792300087; Thu, 13 Feb 2003 12:08:22 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 277428F; Thu, 13 Feb 2003 12:08:22 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Jan-Frode Myklebust Cc: linux-xfs@oss.sgi.com Subject: Re: What is needed for a stable 2.4 based system? In-reply-to: Your message of "Tue, 11 Feb 2003 20:16:05 BST." <20030211201605.A16099@ii.uib.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Feb 2003 12:08:16 +1100 Message-ID: <29832.1045098496@kao2.melbourne.sgi.com> X-archive-position: 2645 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 626 Lines: 13 On Tue, 11 Feb 2003 20:16:05 +0100, Jan-Frode Myklebust wrote: >I've had the impression that the cvs-tree was purely a bugfix only >tree, and that it should be as safe as the kernel.org tree. Is that not true? The CVS trees are reflections (delayed a few hours) of the SGI internal development tree. Their stability depends on what SGI are doing to XFS. ATM it is mainly bug fixes, but large chunks could go in, for example, 2.4 XFS was upgraded to kdb v3.0 last week. SGI run nightly QA tests on the development trees, so "it works for us". Like any other leading edge code, run your own tests. From owner-linux-xfs@oss.sgi.com Wed Feb 12 17:33:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Feb 2003 17:33:46 -0800 (PST) Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1D1Xb3v024364 for ; Wed, 12 Feb 2003 17:33:39 -0800 Received: from rss1.rz.uni-regensburg.de (rss1.rz.uni-regensburg.de [132.199.1.200]) by rrzs2.rz.uni-regensburg.de (8.11.6+Sun/8.11.6) with SMTP id h1D1fpQ24560 for ; Thu, 13 Feb 2003 02:41:51 +0100 (MET) Received: (qmail 8162 invoked from network); 13 Feb 2003 02:41:51 +0100 Received: from pc9391.physik.uni-regensburg.de (HELO pc9391) (guc28561@132.199.98.219) by rss1.rz.uni-regensburg.de with SMTP; 13 Feb 2003 02:41:51 +0100 Date: Thu, 13 Feb 2003 02:41:51 +0100 From: Christian Guggenberger To: Jan-Frode Myklebust Cc: linux-xfs@oss.sgi.com Subject: Re: What is needed for a stable 2.4 based system? Message-ID: <20030213024151.C17795@pc9391.uni-regensburg.de> References: <200302101000.22190.krienke@uni-koblenz.de> <20030211201605.A16099@ii.uib.no> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <20030211201605.A16099@ii.uib.no>; from janfrode@parallab.no on Tue, Feb 11, 2003 at 20:16:05 +0100 X-Mailer: Balsa 1.2.4 X-archive-position: 2646 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Christian.Guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Content-Length: 1155 Lines: 22 Hi, On 11.02.2003 20:16 Jan-Frode Myklebust wrote: > On Mon, Feb 10, 2003 at 07:08:32AM -0600, Eric Sandeen wrote: > > For starters, the patch you downloaded is a development snapshot, so if > > it's stable, you're just lucky - it has not undergone extensive testing. > > Is it really that bad? I'm in the process of setting up a server with > ~2.5 TB of XFS storage, and was just about to go for the linux-2.4-xfs > cvs-tree. Plain 2.4.19 woun't do for me, since there's a hard lockup > bug in the tg3 driver that wasn't fixed before 2.4.20rc3: > > I'm using xfs-cvs since last August on an NFS Server with 4.3 TB with almost no problems at all. We had some NFS server problems, but these got fixed only some days after that bug got public (Bug #186, I think). Other problems were related to Intel's e1000 driver, which got better with 2.4.20. For our use, xfs-cvs _is_ very stable. But, of course, it's always good to test with your Envrionment, before leaving for production use... Besides this, you always could ask for patches for the tg3 (Jeff Garzik, I think, is the man who cares about that drivers on lkml) against 2.4.19! Christian From owner-linux-xfs@oss.sgi.com Wed Feb 12 17:42:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Feb 2003 17:42:12 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1D1g93v024858 for ; Wed, 12 Feb 2003 17:42:09 -0800 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1D0vZKp007858 for ; Wed, 12 Feb 2003 16:57:36 -0800 Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA06510; Thu, 13 Feb 2003 12:48:59 +1100 (AEDT) Date: Thu, 13 Feb 2003 12:48:59 +1100 From: Tim Shimmin To: "Steve P. Shack" Cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump doesn't seem to respect -d option. Message-ID: <20030213124858.X3669870@boing.melbourne.sgi.com> References: <20030213004319.GF26472@nox.steveshack.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <20030213004319.GF26472@nox.steveshack.org>; from sshack@steveshack.org on Wed, Feb 12, 2003 at 04:43:19PM -0800 X-archive-position: 2647 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2064 Lines: 49 Hi Steve, On Wed, Feb 12, 2003 at 04:43:19PM -0800, Steve P. Shack wrote: > Hi, > I'm attempting to use xfsdump to generate a dump images of a > certain size (for backup onto cd). xfsdump claims i'm giving too many > options. "too many -? arguments: maximum is 1 when running in > miniroot". My command line looks something like this. > > xfsdump -d 750 -f backup1 -f backup2 / > > This seems to work on irix, or at least it doesn't bail out right > away. irix seems to just ignore -d (but then I was testing with -d 10 > there). > > any ideas? I'm hoping to have xfsdump a bunch of files which I can > write to cdr as a backup. > 1. You can't split up a dump to multiple files (using multiple -f's) on Linux as we never ported this code (requires multiple threads - needed to convert the sproc code). I don't think anyone has done this port yet (but I noticed the xfs_copy port was done recently which used sprocs I believe). Since we do not allow multiple files/threads we set xfsdump to run single threaded, which it calls "miniroot" mode - an undocumented "-z" option used for the miniroot. That is why you got a strange error message which was meant to be telling you that you can have only one "-f" option. 2. I don't think you understand the "-d" option. It refers to the size of a "dump _media_ file". From xfsdump(8): "The media object records the dump stream as one or more media files. A media file is a self-contained partial dump. The portion of a dump stream contained on a media object can be split into several media files. This minimizes the impact of media dropouts on the entire dump stream, and speeds subtree restores." And in a tape dump, there are normally multiple media files per tape. Each media file contains at the start of it a repeat of the inode map, directory data, etc... so that the media file within the tape can be restored independently. Checkout cmd/xfsdump/doc/xfsdump.html for some explanation and diagrams. In the case of a file dump, it always uses just 1 media file. --Tim From owner-linux-xfs@oss.sgi.com Wed Feb 12 18:09:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Feb 2003 18:09:13 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1D2953v025626 for ; Wed, 12 Feb 2003 18:09:05 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1D2QUkq021964 for ; Wed, 12 Feb 2003 20:26:30 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id UAA75197; Wed, 12 Feb 2003 20:17:14 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id UAA34118; Wed, 12 Feb 2003 20:17:13 -0600 (CST) Date: Wed, 12 Feb 2003 20:16:49 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Achim Altmann cc: xfs mailinglist Subject: Re: Please need help RH and RH-8.0-XFS-iso-image break? In-Reply-To: <042b01c2d2f9$9ad51260$5a02640a@terragon.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by tolkor.sgi.com id h1D2QUkq021964 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h1D2963v025628 X-archive-position: 2648 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 455 Lines: 15 On Thu, 13 Feb 2003, Achim Altmann wrote: > Hello, > > i had downloaded the new RedHat-8.0-xfs-iso.image and after if i have select my pakets an´d like start the installation then on the first paket (glibc-common-...) say the system please insert the CD1 > > I pushed in the same CD and start again , the system say, "that isn't a SGI-XFS-CDROM" You should insert the first CD from Red Hat Linux 8.0, not the SGI cd. Does that work for you? -Eric From owner-linux-xfs@oss.sgi.com Wed Feb 12 18:41:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Feb 2003 18:41:26 -0800 (PST) Received: from ia2020.localdomain (adsl-66-124-158-132.dsl.sntc01.pacbell.net [66.124.158.132]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1D2fK3v026257 for ; Wed, 12 Feb 2003 18:41:21 -0800 Received: from echen ([192.168.0.3]) by ia2020.localdomain (8.9.3/8.9.3) with SMTP id SAA11175 for ; Wed, 12 Feb 2003 18:46:12 -0800 From: "Eric Chen" To: Subject: getfattr and setfattr Date: Wed, 12 Feb 2003 18:50:55 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-archive-position: 2649 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: echen@ateonix.com Precedence: bulk X-list: linux-xfs Content-Length: 1234 Lines: 29 Hello SGI XFS development team member, I wanted to be able to integrate file copying with preserving extended attributes when copying to/from an XFS filesystem. I looked up different resources and tried out copying over the network in different ways, such as rcp, rsync, scp, smbfs, nfs. However, none of them support extended attributes, and extended attributes are lost when the file is copied over to the destination. I came across 'getfattr' and 'setfattr' and those 2 commands seem to preserve the EA if I first 'getfattr -Rd * > save_attr' then copy the files over then 'setfattr --restore=save_attr' This *seems* to work fine, but since you were listed as the author in the man pages, I thought you might know more about this. Ideally, I want to integrate file copying and preserving extended attributes, so I am attempting to modify the source code so that will be handled. I was hoping you could give me some more information, such as where I can find the code for 'getfattr' and 'setfattr' so I could take a look at it and get some idea from that. I'm not really sure where to get started, so if you have any suggestions or references to resources that might help me on my way, I would be very grateful. Thanks, Eric From owner-linux-xfs@oss.sgi.com Wed Feb 12 18:46:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Feb 2003 18:46:43 -0800 (PST) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1D2ka3v026759 for ; Wed, 12 Feb 2003 18:46:37 -0800 Received: from attbi.com (12-253-73-46.client.attbi.com[12.253.73.46]) by sccrmhc02.attbi.com (sccrmhc02) with SMTP id <200302122145590020032ng7e>; Wed, 12 Feb 2003 21:46:00 +0000 Message-ID: <3E4AC117.9080005@attbi.com> Date: Wed, 12 Feb 2003 14:48:07 -0700 From: "D. Stimits" Reply-To: stimits@attbi.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021018 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: Defrag pitfals (was Re: Support for XFS File systems) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2650 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: stimits@attbi.com Precedence: bulk X-list: linux-xfs Content-Length: 1557 Lines: 33 Bogdan Costescu wrote: > On Wed, 12 Feb 2003, Chris Wedgwood wrote: > ... > Scientific simulations that produce large amounts of data over a long > time. Of course, "large amounts" and "long time" is relative, in our case > being "several hundreds megabytes" and "days". The file is created at the > beginning of the simulation and data is appended to it for the whole > simulation duration; data is never rewritten during the simulation. > Depending on data size, simulations can finish sooner or later and > produce > files that are of different sizes, however in order to ease later backup, > we limit the size of one file to approximately 650 MB. Writting to > disk is > not a problem, as the rate at which data is produced is very low. > However, > reading the data becomes a problem and we need to do it to either analize > the data or transfer it from there to other computer or CD. > ... I am curious if the data is binary, or if it is in such a form that SQL storage could be used? That would solve a lot of problems (or perhaps alter them) for replication, and especially for fragmentation choices and questions. Postgresql might be a good choice, network enabling it and having nodes write to postgresql either via sockets or a daemon running on your master node. If you need to sort or view non-binary data in more than one way, SQL would be a blessing. I am also curious what kind of Postgresql or MySQL performance differences people have found under XFS, compared to any other file system? D. Stimits, stimits AT attbi DOT com From owner-linux-xfs@oss.sgi.com Wed Feb 12 18:58:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Feb 2003 18:58:13 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1D2w93v027313 for ; Wed, 12 Feb 2003 18:58:09 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1D16TG8002088 for ; Wed, 12 Feb 2003 17:06:29 -0800 Received: from tulip-e236.americas.sgi.com (tulip-e236.americas.sgi.com [128.162.236.208]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id VAA96628; Wed, 12 Feb 2003 21:06:17 -0600 (CST) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-100.corp.sgi.com [134.15.64.100]) by tulip-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id VAA40412; Wed, 12 Feb 2003 21:06:14 -0600 (CST) Subject: Re: What is needed for a stable 2.4 based system? From: Stephen Lord To: Jan-Frode Myklebust Cc: Eric Sandeen , Rainer Krienke , linux-xfs@oss.sgi.com In-Reply-To: <20030211201605.A16099@ii.uib.no> References: <200302101000.22190.krienke@uni-koblenz.de> <20030211201605.A16099@ii.uib.no> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 12 Feb 2003 21:05:15 -0600 Message-Id: <1045105518.1546.2.camel@localhost.localdomain> Mime-Version: 1.0 X-archive-position: 2651 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1238 Lines: 31 On Tue, 2003-02-11 at 13:16, Jan-Frode Myklebust wrote: > On Mon, Feb 10, 2003 at 07:08:32AM -0600, Eric Sandeen wrote: > > For starters, the patch you downloaded is a development snapshot, so if > > it's stable, you're just lucky - it has not undergone extensive testing. > > Is it really that bad? I'm in the process of setting up a server with > ~2.5 TB of XFS storage, and was just about to go for the linux-2.4-xfs > cvs-tree. Plain 2.4.19 woun't do for me, since there's a hard lockup > bug in the tg3 driver that wasn't fixed before 2.4.20rc3: > > http://www.uwsg.iu.edu/hypermail/linux/kernel/0211.3/0167.html > > and this is exactly the hardware I'm planning on running my storage > from. > > I've had the impression that the cvs-tree was purely a bugfix only > tree, and that it should be as safe as the kernel.org tree. Is that not true? > In general my workstation is running CVS within a few days of the current tree. If I change something major I subject myself to it first. But my workload and your workload are not going to be the same, so your mileage may vary. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Feb 12 19:14:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Feb 2003 19:14:21 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1D3EJ3v029000 for ; Wed, 12 Feb 2003 19:14:19 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1D3EJwL028999 for linux-xfs@oss.sgi.com; Wed, 12 Feb 2003 19:14:19 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1D3EH3x028985 for ; Wed, 12 Feb 2003 19:14:17 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1D34ITJ027782; Wed, 12 Feb 2003 19:04:18 -0800 Date: Wed, 12 Feb 2003 19:04:18 -0800 Message-Id: <200302130304.h1D34ITJ027782@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 219] O_DIRECT io no longer works when the available data size is less than the underlying block-device size? X-Bugzilla-Reason: AssignedTo X-archive-position: 2652 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 449 Lines: 17 http://oss.sgi.com/bugzilla/show_bug.cgi?id=219 ------- Additional Comments From lord@sgi.com 2003-02-12 19:04 ------- In general, this is discussion which needs to be had with Andrew Morton. In 2.5 we are using the generic direct I/O path, which is working on different ground rules than the code in 2.4. Yep its a pain. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Feb 12 19:36:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Feb 2003 19:36:55 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1D3ap3v030608 for ; Wed, 12 Feb 2003 19:36:51 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h1D2qIKp016480 for ; Wed, 12 Feb 2003 18:52:19 -0800 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 OAA23438; Thu, 13 Feb 2003 14:43:41 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id OAA33902; Thu, 13 Feb 2003 14:43:40 +1100 (AEDT) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) with ESMTP id h1D3fuSK003067; Thu, 13 Feb 2003 14:41:56 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h1D3ftCS003061; Thu, 13 Feb 2003 14:41:55 +1100 Date: Thu, 13 Feb 2003 14:41:55 +1100 From: Nathan Scott To: Eric Chen Cc: linux-xfs@oss.sgi.com, agruen@suse.de Subject: Re: getfattr and setfattr Message-ID: <20030213034155.GB11065@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: 2653 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: 2000 Lines: 50 On Wed, Feb 12, 2003 at 06:50:55PM -0800, Eric Chen wrote: > Hello SGI XFS development team member, hi there, > I wanted to be able to integrate file copying with preserving extended > attributes when copying to/from an XFS filesystem. I looked up different > resources and tried out copying over the network in different ways, such as > rcp, rsync, scp, smbfs, nfs. However, none of them support extended > attributes, and extended attributes are lost when the file is copied over to > the destination. > > I came across 'getfattr' and 'setfattr' and those 2 commands seem to > preserve the EA if I first > > 'getfattr -Rd * > save_attr' > then copy the files over > then 'setfattr --restore=save_attr' > > This *seems* to work fine, but since you were listed as the author in the > man pages, I thought you might know more about this. Ideally, I want to These programs were originally written by Andreas Gruenbacher (CC'd), with relatively minor changes from us, so you may want to discuss this in detail with him. > integrate file copying and preserving extended attributes, so I am > attempting to modify the source code so that will be handled. I was hoping > you could give me some more information, such as where I can find the code > for 'getfattr' and 'setfattr' so I could take a look at it and get some idea The code is in the "attr" package, and the XFS CVS tree below cmd/attr/getfattr/ and cmd/attr/setfattr/. > from that. I'm not really sure where to get started, so if you have any > suggestions or references to resources that might help me on my way, I would > be very grateful. Andreas has a modified version of the fileutils package on his website which preserved ACLs across cp, mv, etc. I believe he has recently been working on extending this to EAs in general - I have a patch from Andreas in my queue somewhere adding generic EA copying routines into libattr; so you could contact him to see where he's up to and where/how you can help out. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Feb 12 20:10:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Feb 2003 20:10:36 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1D4AQ3v031313 for ; Wed, 12 Feb 2003 20:10:27 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1D4Rokq024728 for ; Wed, 12 Feb 2003 22:27:51 -0600 Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id h1D4HX000929; Thu, 13 Feb 2003 15:17:33 +1100 Date: Thu, 13 Feb 2003 15:17:33 +1100 From: Keith Owens Message-Id: <200302130417.h1D4HX000929@sherman.melbourne.sgi.com> Subject: TAKE - Remove warning from kdbm_vm.c X-archive-position: 2654 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 282 Lines: 12 Remove warning from kdbm_vm.c Date: Wed Feb 12 20:16:47 PST 2003 Workarea: sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:139629a linux/kdb/modules/kdbm_vm.c - 1.22 From owner-linux-xfs@oss.sgi.com Wed Feb 12 21:04:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Feb 2003 21:04:44 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1D54a3v001025 for ; Wed, 12 Feb 2003 21:04:36 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1D1S0G8003457 for ; Wed, 12 Feb 2003 17:28:00 -0800 Received: from tulip-e236.americas.sgi.com (tulip-e236.americas.sgi.com [128.162.236.208]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id VAA14495; Wed, 12 Feb 2003 21:27:48 -0600 (CST) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-100.corp.sgi.com [134.15.64.100]) by tulip-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id VAA77710; Wed, 12 Feb 2003 21:27:47 -0600 (CST) Subject: Re: getfattr and setfattr From: Stephen Lord To: Eric Chen Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 12 Feb 2003 21:26:47 -0600 Message-Id: <1045106809.1545.11.camel@localhost.localdomain> Mime-Version: 1.0 X-archive-position: 2655 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1703 Lines: 41 On Wed, 2003-02-12 at 20:50, Eric Chen wrote: > Hello SGI XFS development team member, > > I wanted to be able to integrate file copying with preserving extended > attributes when copying to/from an XFS filesystem. I looked up different > resources and tried out copying over the network in different ways, such as > rcp, rsync, scp, smbfs, nfs. However, none of them support extended > attributes, and extended attributes are lost when the file is copied over to > the destination. > > I came across 'getfattr' and 'setfattr' and those 2 commands seem to > preserve the EA if I first > > 'getfattr -Rd * > save_attr' > then copy the files over > then 'setfattr --restore=save_attr' > > This *seems* to work fine, but since you were listed as the author in the > man pages, I thought you might know more about this. Ideally, I want to > integrate file copying and preserving extended attributes, so I am > attempting to modify the source code so that will be handled. I was hoping > you could give me some more information, such as where I can find the code > for 'getfattr' and 'setfattr' so I could take a look at it and get some idea > from that. I'm not really sure where to get started, so if you have any > suggestions or references to resources that might help me on my way, I would > be very grateful. > > Thanks, > Eric > I think xfsdump/xfsrestore is the only pre-existing mechanism which will preserve them. The cp command on Irix has been extended to copy attributes if the -a option is specified. However, that code is not something we can distribute, Irix cp almost certainly originated in an AT&T code base, plus the attribute calls are different between irix and linux. Steve From owner-linux-xfs@oss.sgi.com Wed Feb 12 22:01:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Feb 2003 22:02:04 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1D61t3v002449 for ; Wed, 12 Feb 2003 22:01:56 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 3C1E018CA19F; Wed, 12 Feb 2003 22:10:11 -0800 (PST) Date: Wed, 12 Feb 2003 22:10:11 -0800 From: Chris Wedgwood To: Stephen Lord Cc: Eric Chen , linux-xfs@oss.sgi.com Subject: Re: getfattr and setfattr Message-ID: <20030213061011.GA15247@f00f.org> References: <1045106809.1545.11.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1045106809.1545.11.camel@localhost.localdomain> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2656 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: 457 Lines: 16 On Wed, Feb 12, 2003 at 09:26:47PM -0600, Stephen Lord wrote: > I think xfsdump/xfsrestore is the only pre-existing mechanism which > will preserve them. 'star' supports ACLs, not sure about EA as a whole though, and as mention Andreas Gruenbacher (sp?) has modified the gnu tools for this too hopefully the update GNU tools will get merged back into the GNU code base at some point (with perhaps the dependency of a vendor/OS specific libacl) --cw From owner-linux-xfs@oss.sgi.com Wed Feb 12 22:15:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Feb 2003 22:15:48 -0800 (PST) Received: from bnbtv.com (httpd.isaiah.com [68.15.9.23] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1D6Fi3v005621 for ; Wed, 12 Feb 2003 22:15:45 -0800 Received: from system2.bnbtv.com [68.50.146.189] by bnbtv.com with ESMTP (SMTPD32-7.07) id AA4E630086; Wed, 12 Feb 2003 22:25:18 -0800 Message-Id: <5.1.1.6.0.20030213012316.026bc548@mail.jcntv.com> X-Sender: errol.neal@bnbtv.com@mail.jcntv.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 13 Feb 2003 01:26:11 -0500 To: linux-xfs@oss.sgi.com From: Errol Neal Subject: Cannot find XFS option in kernel config Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2657 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: errol.neal@bnbtv.com Precedence: bulk X-list: linux-xfs Content-Length: 282 Lines: 8 I have been using the 1.1 release. I am trying to configure a kernel for 1.2 release. I have already patched the kernel, but I cannot seem to find the option to configure the kernel for XFS. It was under the Filesystems tree in 1.1 release. Can someone help me please? Errol From owner-linux-xfs@oss.sgi.com Thu Feb 13 02:54:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Feb 2003 02:54:41 -0800 (PST) Received: from shade.globe.cz (ondrej.sury.org [81.95.99.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1DAsW3v026895 for ; Thu, 13 Feb 2003 02:54:33 -0800 Received: (qmail 19267 invoked by uid 1000); 13 Feb 2003 11:01:08 -0000 To: Thomas Seifert Cc: linux-xfs@oss.sgi.com Subject: Re: Release 1.2 for Kernel 2.4.20? From: Ondrej Sury In-Reply-To: <20030212230557.3ece54af.thomas.seifert@myphorum.de> (Thomas Seifert's message of "Wed, 12 Feb 2003 23:05:57 +0100") References: <20030212230557.3ece54af.thomas.seifert@myphorum.de> Date: Thu, 13 Feb 2003 12:01:08 +0100 Message-ID: <87y94k78cr.fsf@globe.cz> User-Agent: Gnus/5.090011 (Oort Gnus v0.11) Emacs/21.3.50 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 2658 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: sury.ondrej@globe.cz Precedence: bulk X-list: linux-xfs Content-Length: 788 Lines: 22 Thomas Seifert writes: > Hi folks, > > thanks for that great filesystem. > I use it in production on many system and never had any problems with it :-). > > For the current release, is there a chance to get official 1.2-patches for the 2.4.20-kernel > or maybe the upcoming 2.4.21? > > Or do we have to live with snapshots from CVS for it? > Just curious about the policy on it. Fixing rejected patches after patching 2.4.19 with xfs 1.2 and then with linux 2.4.20 patch is trivial (at least for ia32 arch), but it may or may not work. I just did it, but I am not courageous enough to try it ;-) O. -- Ondrej Sury - CIO Globe Internet s.r.o. http://globe.cz/ Tel: +420(2)35365000 Fax: +420(2)35365009 Planickova 1, 162 00 Praha 6 From owner-linux-xfs@oss.sgi.com Thu Feb 13 02:57:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Feb 2003 02:57:53 -0800 (PST) Received: from federazione.fmbcc.fm ([195.223.139.226]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1DAvk3v027324 for ; Thu, 13 Feb 2003 02:57:48 -0800 Received: from Qmail-Mail-Server ([10.113.160.207]) by federazione.fmbcc.fm (Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) with SMTP id 41256CCC.003D13E5; Thu, 13 Feb 2003 12:07:07 +0100 Received: (qmail 31223 invoked from network); 13 Feb 2003 10:54:11 -0000 Received: from unknown (HELO FI0P38) (10.113.160.38) by 0 with SMTP; 13 Feb 2003 10:54:11 -0000 Message-ID: <001801c2d34f$f65e7da0$26a0710a@FI0P38> From: "Fabio Baiocco" To: Subject: Error rebuilding xfsprogs-2.3.5-0.src.rpm Date: Thu, 13 Feb 2003 12:06:30 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 2659 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: baiocco.f@filottrano.bcc.it Precedence: bulk X-list: linux-xfs Content-Length: 3382 Lines: 108 The command rpm --rebuild xfsprogs-2.3.5-0.src.rpm on a RedHat 7.2 displays those errors: error: File not found: /tmp/12496/usr/share/man/man5/xfs.5 error: File not found: /tmp/12496/usr/share/man/man8/fsck.xfs.8 error: File not found: /tmp/12496/usr/share/man/man8/mkfs.xfs.8 error: File not found: /tmp/12496/usr/share/man/man8/xfs_admin.8 error: File not found: /tmp/12496/usr/share/man/man8/xfs_bmap.8 error: File not found: /tmp/12496/usr/share/man/man8/xfs_check.8 error: File not found: /tmp/12496/usr/share/man/man8/xfs_db.8 error: File not found: /tmp/12496/usr/share/man/man8/xfs_freeze.8 error: File not found: /tmp/12496/usr/share/man/man8/xfs_growfs.8 error: File not found: /tmp/12496/usr/share/man/man8/xfs_logprint.8 error: File not found: /tmp/12496/usr/share/man/man8/xfs_mkfile.8 error: File not found: /tmp/12496/usr/share/man/man8/xfs_ncheck.8 error: File not found: /tmp/12496/usr/share/man/man8/xfs_repair.8 error: File not found: /tmp/12496/usr/share/man/man8/xfs_rtcp.8 error: File not found: /tmp/12496/usr/share/man/man8/xfs_info.8 error: File not found: /tmp/12496/usr/share/man/man3/path_to_handle.3 error: File not found: /tmp/12496/usr/share/man/man3/attr_list_by_handle.3 error: File not found: /tmp/12496/usr/share/man/man3/attr_multi_by_handle.3 error: File not found: /tmp/12496/usr/share/man/man3/fd_to_handle.3 error: File not found: /tmp/12496/usr/share/man/man3/free_handle.3 error: File not found: /tmp/12496/usr/share/man/man3/fssetdm_by_handle.3 error: File not found: /tmp/12496/usr/share/man/man3/handle_to_fshandle.3 error: File not found: /tmp/12496/usr/share/man/man3/open_by_handle.3 error: File not found: /tmp/12496/usr/share/man/man3/path_to_fshandle.3 error: File not found: /tmp/12496/usr/share/man/man3/readlink_by_handle.3 File not found: /tmp/12496/usr/share/man/man5/xfs.5 File not found: /tmp/12496/usr/share/man/man8/fsck.xfs.8 File not found: /tmp/12496/usr/share/man/man8/mkfs.xfs.8 File not found: /tmp/12496/usr/share/man/man8/xfs_admin.8 File not found: /tmp/12496/usr/share/man/man8/xfs_bmap.8 File not found: /tmp/12496/usr/share/man/man8/xfs_check.8 File not found: /tmp/12496/usr/share/man/man8/xfs_db.8 File not found: /tmp/12496/usr/share/man/man8/xfs_freeze.8 File not found: /tmp/12496/usr/share/man/man8/xfs_growfs.8 File not found: /tmp/12496/usr/share/man/man8/xfs_logprint.8 File not found: /tmp/12496/usr/share/man/man8/xfs_mkfile.8 File not found: /tmp/12496/usr/share/man/man8/xfs_ncheck.8 File not found: /tmp/12496/usr/share/man/man8/xfs_repair.8 File not found: /tmp/12496/usr/share/man/man8/xfs_rtcp.8 File not found: /tmp/12496/usr/share/man/man8/xfs_info.8 File not found: /tmp/12496/usr/share/man/man3/path_to_handle.3 File not found: /tmp/12496/usr/share/man/man3/attr_list_by_handle.3 File not found: /tmp/12496/usr/share/man/man3/attr_multi_by_handle.3 File not found: /tmp/12496/usr/share/man/man3/fd_to_handle.3 File not found: /tmp/12496/usr/share/man/man3/free_handle.3 File not found: /tmp/12496/usr/share/man/man3/fssetdm_by_handle.3 File not found: /tmp/12496/usr/share/man/man3/handle_to_fshandle.3 File not found: /tmp/12496/usr/share/man/man3/open_by_handle.3 File not found: /tmp/12496/usr/share/man/man3/path_to_fshandle.3 File not found: /tmp/12496/usr/share/man/man3/readlink_by_handle.3 [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Thu Feb 13 03:07:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Feb 2003 03:07:26 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1DB7L3v028325 for ; Thu, 13 Feb 2003 03:07:21 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id BDF7014547; Thu, 13 Feb 2003 12:15:31 +0100 (MET) Content-Type: text/plain; charset="iso-8859-1" From: Andreas Gruenbacher Organization: SuSE Labs, SuSE Linux AG To: Eric Chen Subject: Re: getfattr and setfattr Date: Thu, 13 Feb 2003 12:15:24 +0100 User-Agent: KMail/1.4.3 Cc: linux-xfs@oss.sgi.com, Nathan Scott References: <20030213034155.GB11065@frodo> In-Reply-To: <20030213034155.GB11065@frodo> MIME-Version: 1.0 Message-Id: <200302131215.26070.agruen@suse.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h1DB7M3v028326 X-archive-position: 2660 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: agruen@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 2743 Lines: 67 Hello, I was indeed planning on adding support for copying EAs to the fileutils patch this week. It's probably easiest for you to stay tuned on the acl-devel@bestbits.at mailing list. Meanwhile the fileutils have also been merged into coreutils (containing fileutils, textutils, sh-utils), so this is what I will be focusing on. On Thursday 13 February 2003 04:41, Nathan Scott wrote: > On Wed, Feb 12, 2003 at 06:50:55PM -0800, Eric Chen wrote: > > Hello SGI XFS development team member, > > hi there, > > > I wanted to be able to integrate file copying with preserving > > extended attributes when copying to/from an XFS filesystem. I > > looked up different resources and tried out copying over the > > network in different ways, such as rcp, rsync, scp, smbfs, nfs. > > However, none of them support extended attributes, and extended > > attributes are lost when the file is copied over to the > > destination. > > > > I came across 'getfattr' and 'setfattr' and those 2 commands seem > > to preserve the EA if I first > > > > 'getfattr -Rd * > save_attr' > > then copy the files over > > then 'setfattr --restore=save_attr' > > > > This *seems* to work fine, but since you were listed as the author > > in the man pages, I thought you might know more about this. > > Ideally, I want to > > These programs were originally written by Andreas Gruenbacher > (CC'd), with relatively minor changes from us, so you may want > to discuss this in detail with him. > > > integrate file copying and preserving extended attributes, so I am > > attempting to modify the source code so that will be handled. I was > > hoping you could give me some more information, such as where I can > > find the code for 'getfattr' and 'setfattr' so I could take a look > > at it and get some idea > > The code is in the "attr" package, and the XFS CVS tree below > cmd/attr/getfattr/ and cmd/attr/setfattr/. > > > from that. I'm not really sure where to get started, so if you > > have any suggestions or references to resources that might help me > > on my way, I would be very grateful. > > Andreas has a modified version of the fileutils package on his > website which preserved ACLs across cp, mv, etc. I believe he > has recently been working on extending this to EAs in general - > I have a patch from Andreas in my queue somewhere adding generic > EA copying routines into libattr; so you could contact him to > see where he's up to and where/how you can help out. > > cheers. -- ------------------------------------------------------------------ Andreas Gruenbacher SuSE Linux AG mailto:agruen@suse.de Deutschherrnstr. 15-19 http://www.suse.de/ D-90429 Nuernberg, Germany From owner-linux-xfs@oss.sgi.com Thu Feb 13 03:54:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Feb 2003 03:54:05 -0800 (PST) Received: from hermod.slb.nwc.acsalaska.net (hermod.slb.nwc.acsalaska.net [209.112.155.45]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1DBrx3v032110 for ; Thu, 13 Feb 2003 03:53:59 -0800 Received: from erbenson.alaska.net (203-pm32.nwc.alaska.net [209.112.158.203]) by hermod.slb.nwc.acsalaska.net (8.12.7/8.12.7) with ESMTP id h1DC2DMg067412; Thu, 13 Feb 2003 03:02:13 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id D8F0C3A0B; Thu, 13 Feb 2003 03:02:09 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id D2ECF4104E2; Thu, 13 Feb 2003 03:02:09 -0900 (AKST) Date: Thu, 13 Feb 2003 03:02:09 -0900 From: Ethan Benson To: Andreas Gruenbacher Cc: linux-xfs@oss.sgi.com Subject: Re: getfattr and setfattr Message-ID: <20030213120209.GA13226@plato.local.lan> Mail-Followup-To: Andreas Gruenbacher , linux-xfs@oss.sgi.com References: <20030213034155.GB11065@frodo> <200302131215.26070.agruen@suse.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline In-Reply-To: <200302131215.26070.agruen@suse.de> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-archive-position: 2661 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: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 1060 Lines: 39 --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 13, 2003 at 12:15:24PM +0100, Andreas Gruenbacher wrote: > Hello, >=20 > I was indeed planning on adding support for copying EAs to the fileutils= =20 > patch this week. It's probably easiest for you to stay tuned on the=20 > acl-devel@bestbits.at mailing list. >=20 > Meanwhile the fileutils have also been merged into coreutils (containing= =20 > fileutils, textutils, sh-utils), so this is what I will be focusing on. has there been any further progress on getting GNU upstream to merge the acl support? --=20 Ethan Benson http://www.alaska.net/~erbenson/ --9jxsPFA5p3P2qPhR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj5LiUEACgkQJKx7GixEevzqhwCglL2OJNpmDAQyrV3ZSSwYgJXv ZUUAmwYKKjpeng9vfti3omFq2J2/ijL1 =z/VB -----END PGP SIGNATURE----- --9jxsPFA5p3P2qPhR-- From owner-linux-xfs@oss.sgi.com Thu Feb 13 03:54:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Feb 2003 03:54:51 -0800 (PST) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1DBsh3v032329 for ; Thu, 13 Feb 2003 03:54:44 -0800 Received: (qmail 28347 invoked from network); 13 Feb 2003 12:02:58 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 13 Feb 2003 12:02:58 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 511D4300087; Thu, 13 Feb 2003 23:02:56 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 291A08F; Thu, 13 Feb 2003 23:02:56 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: "Fabio Baiocco" Cc: linux-xfs@oss.sgi.com Subject: Re: Error rebuilding xfsprogs-2.3.5-0.src.rpm In-reply-to: Your message of "Thu, 13 Feb 2003 12:06:30 BST." <001801c2d34f$f65e7da0$26a0710a@FI0P38> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Feb 2003 23:02:50 +1100 Message-ID: <5105.1045137770@ocs3.intra.ocs.com.au> X-archive-position: 2662 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1520 Lines: 43 On Thu, 13 Feb 2003 12:06:30 +0100, "Fabio Baiocco" wrote: >The command rpm --rebuild xfsprogs-2.3.5-0.src.rpm on a RedHat 7.2 displays those errors: > >error: File not found: /tmp/12496/usr/share/man/man5/xfs.5 For some reason, the spec file in xfsprogs is incorrect. It has /usr/local/man/man5/xfs.5 when it should be /usr/local/man/man5/xfs.5* the trailing '*' is to cope with gzipped man pages, which RH 7.2 does by default. It looks like a failure in the awk code that builds the spec filelist from the manifest. Until the xfs release team can correct the build process, here is an untested patch to workaround the problem. --- xfsprogs.spec.orig Thu Feb 13 22:57:44 2003 +++ xfsprogs.spec Thu Feb 13 22:58:36 2003 @@ -72,13 +72,13 @@ if (match ($6, "/usr/local/man")) printf ("%%%%attr(%s,%s,%s) %s*\n", $2, $3, $4, $6); else - printf ("%%%%attr(%s,%s,%s) %s\n", $2, $3, $4, $6); } + printf ("%%%%attr(%s,%s,%s) %s*\n", $2, $3, $4, $6); } $1 == "l" { if (match ($3, "/usr/local/man") || match ($3, "/usr/local/share/doc/xfsprogs")) printf ("%%%%doc "); if (match ($3, "/usr/local/man")) printf ("%attr(0777,root,root) %s*\n", $3); else - printf ("%attr(0777,root,root) %s\n", $3); }' + printf ("%attr(0777,root,root) %s*\n", $3); }' } set +x files < "$DIST_INSTALL" > files.rpm Use as:- rpm -i xfsprogs-2.3.5-0.src.rpm cd /usr/src/redhat/SPECS (or wherever you unpack your rpms) patch -p0 < patch_above rpmbuild -ba xfsprogs.spec From owner-linux-xfs@oss.sgi.com Thu Feb 13 04:00:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Feb 2003 04:00:39 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1DC0a3v000539 for ; Thu, 13 Feb 2003 04:00:37 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 59DFA14570; Thu, 13 Feb 2003 13:08:47 +0100 (MET) Content-Type: text/plain; charset="iso-8859-1" From: Andreas Gruenbacher Organization: SuSE Labs, SuSE Linux AG To: Ethan Benson Subject: Re: getfattr and setfattr Date: Thu, 13 Feb 2003 13:08:44 +0100 User-Agent: KMail/1.4.3 Cc: linux-xfs@oss.sgi.com References: <200302131215.26070.agruen@suse.de> <20030213120209.GA13226@plato.local.lan> In-Reply-To: <20030213120209.GA13226@plato.local.lan> MIME-Version: 1.0 Message-Id: <200302131308.44225.agruen@suse.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h1DC0b3v000541 X-archive-position: 2663 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: agruen@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 614 Lines: 19 On Thursday 13 February 2003 13:02, Ethan Benson wrote: > On Thu, Feb 13, 2003 at 12:15:24PM +0100, Andreas Gruenbacher wrote: > > Hello, > > > > I was indeed planning on adding support for copying EAs to the > > fileutils patch this week. It's probably easiest for you to stay > > tuned on the acl-devel@bestbits.at mailing list. > > > > Meanwhile the fileutils have also been merged into coreutils > > (containing fileutils, textutils, sh-utils), so this is what I will > > be focusing on. > > has there been any further progress on getting GNU upstream to merge > the acl support? I'm afraid not. --Andreas. From owner-linux-xfs@oss.sgi.com Thu Feb 13 05:18:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Feb 2003 05:18:21 -0800 (PST) Received: from ks406.kasserver.com (ks406.kasserver.com [62.141.48.110]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1DDI53v006890 for ; Thu, 13 Feb 2003 05:18:06 -0800 Received: from anubis (Af4af.pppool.de [213.6.244.175]) by ks406.kasserver.com (8.11.6/8.11.6) with SMTP id h1DDQ6f09958 for ; Thu, 13 Feb 2003 14:26:08 +0100 Message-ID: <002701c2d364$b3c57dd0$5a02640a@terragon.de> From: "Achim Altmann" To: "xfs mailinglist" Subject: Can't pagebuffer in kernelmenu ? Date: Thu, 13 Feb 2003 14:34:46 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-archive-position: 2664 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: achim@altmann.li Precedence: bulk X-list: linux-xfs Content-Length: 8114 Lines: 183 hello, now i have downloaded the kernel-2.4.19 from kernel.org in step two i have downloaded the two patches for xfs-kernel-support for kernel-2.4.19 in step 3 i had patch the kernel under /usr/src with taht two patch-files the new kernel-2.4.19 was a symlink to /usr/src/linux in step 4 i had "make manuconfig" I found the option under "filesystem" [*] POSIX Access Control Lists = x x x x [*] Quota support = = x x x x < > Old quota format suppo= rt = x x x x < > VFS v0 quota format su= pport = x x x x [*] Compatible quota inter= faces = x x x x (Original) Compatible qu= ota interfaces = x x x x < > Kernel automounter suppo= rt = x x x x < > Kernel automounter versi= on 4 support (also supports v3) = x x x x Reiserfs support = = x x x x [ ] Have reiserfs do extra= internal checking = x x x x [ ] Stats in /proc/fs/reis= erfs = x x x x < > Ext3 journalling file sy= stem support = x x x x < > DOS FAT fs support = = x x x x < > Compressed ROM file syst= em support = x x x x [*] Virtual memory file syst= em support (former shm fs) = x x x x ISO 9660 CDROM file syst= em support = x x x x [*] Microsoft Joliet CDROM= extensions = x x x x [*] Transparent decompress= ion extension = x x x x < > Minix fs support = = x x x x < > FreeVxFS file system sup= port (VERITAS VxFS(TM) compatible) = x x x x < > NTFS file system support= (read only) = x x x x < > OS/2 HPFS file system su= pport = x x x x [*] /proc file system suppor= t = x x x x < > QNX4 file system support= (read only) = x x x x ROM file system support = = x x x x <*> Second extended fs suppo= rt = x x x x < > System V/Xenix/V7/Cohere= nt file system support = x x x x < > UDF file system support = (read only) = x x x x < > UFS file system support = (read only) = x x x x <*> XFS filesystem support = = x x x x [*] Quota support = = x x x x [ ] DMAPI support = = x x x x Network File Systems ---> = = x x x x Partition Types ---> = = x x x x Native Language Support ---> but you can see self above i can't find "pagebuffer" in step 5 i had run=20 make dep and then coms the following message fomit-frame-pointer -pipe -mpreferred-stack-boundary=3D2 -march=3Dathlon = -nostdinc -I /usr/lib/gcc-lib/i386-redhat-linux/3.2/include -- dir.c emd.c = inode.c ioctl .c mangle.c namei.c rdir.c > .depend make[4]: Verlassen des Verzeichnisses Verzeichnis =C2=BB/usr/src/linux-2.4.= 19/fs/umsdos=C2=AB make -C vfat fastdep make[4]: Wechsel in das Verzeichnis Verzeichnis =C2=BB/usr/src/linux-2.4.19= /fs/vfat=C2=AB /usr/src/linux-2.4.19/scripts/mkdep -D__KERNEL__ -I/usr/src/linux-2.4.19/in= clude -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -f= no-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=3D2 -march=3Dathlon = -nostdinc -I /usr/lib/gcc-lib/i386-redhat-linux/3.2/include -- namei.c vfa= tfs_syms.c > . depend make[4]: Verlassen des Verzeichnisses Verzeichnis =C2=BB/usr/src/linux-2.4.= 19/fs/vfat=C2=AB make -C xfs fastdep make: Wechsel in das Verzeichnis ein unbekanntes Verzeichnis make: *** xfs: Datei oder Verzeichnis nicht gefunden. Schluss. make: Verlassen des Verzeichnisses ein unbekanntes Verzeichnis make[3]: *** [_sfdep_xfs] Fehler 2 make[3]: Verlassen des Verzeichnisses Verzeichnis =C2=BB/usr/src/linux-2.4.= 19/fs=C2=AB make[2]: *** [fastdep] Fehler 2 make[2]: Verlassen des Verzeichnisses Verzeichnis =C2=BB/usr/src/linux-2.4.= 19/fs=C2=AB make[1]: *** [_sfdep_fs] Fehler 2 make[1]: Verlassen des Verzeichnisses Verzeichnis =C2=BB/usr/src/linux-2.4.= 19=C2=AB make: *** [dep-files] Fehler 2 [root@alpha1 linux-2.4.19]# Verlassen =3D=3D> leaf Verzeichnis =3D=3D=3D> tree Fehler =3D=3D=3D=3D> error Could any say what is wrong? Now i download the new kernel from cvs like in your web-documentation (FAQ) I hope that is better, please telle me when if is possible, which problems = coms with this sorry but a had download the new redhat 8.0-xfs-image and during the instal= lation=20 (he would like installed the kernel) comes a error an break the installtion My System is a tyan-dual-amd board with 3WARE-4p controller and 3WARE-Hot-S= WAP-IDE-BOX Please help Thank's a lot Best reagards Achim [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Thu Feb 13 05:38:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Feb 2003 05:38:58 -0800 (PST) Received: from federazione.fmbcc.fm ([195.223.139.226]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1DDcl3v011773 for ; Thu, 13 Feb 2003 05:38:49 -0800 Received: from Qmail-Mail-Server ([10.113.160.207]) by federazione.fmbcc.fm (Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) with SMTP id 41256CCC.004BD227; Thu, 13 Feb 2003 14:48:10 +0100 Received: (qmail 30301 invoked from network); 13 Feb 2003 13:35:13 -0000 Received: from unknown (HELO FI0P38) (10.113.160.38) by 0 with SMTP; 13 Feb 2003 13:35:13 -0000 Message-ID: <002101c2d366$7578ef60$26a0710a@FI0P38> From: "Fabio Baiocco" To: Subject: xfsprogs-2.3.5-0.src.rpm shipped with pre5 Date: Thu, 13 Feb 2003 14:47:33 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 2665 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: baiocco.f@filottrano.bcc.it Precedence: bulk X-list: linux-xfs Content-Length: 255 Lines: 5 I try to rebuild the xfsprogs-2.3.5-0.src.rpm on RH 7.2 shipped with pre5 version and it doesn't return an error code creating the relative rpm but this package is different from the one shipped with Xfs version 1.2? [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Thu Feb 13 05:50:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Feb 2003 05:50:16 -0800 (PST) Received: from hbcse.tifr.res.in (hbcse.tifr.res.in [158.144.44.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1DDoA3v012704 for ; Thu, 13 Feb 2003 05:50:13 -0800 Received: from linto (helo=localhost) by hbcse.tifr.res.in with local-esmtp (Exim 3.35 #1 (Debian)) id 18jJqx-00008y-00 for ; Thu, 13 Feb 2003 19:26:39 +0530 Date: Thu, 13 Feb 2003 19:26:39 +0530 (IST) From: "'Linto Joseph Mathew" To: linux-xfs@oss.sgi.com Subject: Disk formatting Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2666 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: linto@hbcse.tifr.res.in Precedence: bulk X-list: linux-xfs Content-Length: 80 Lines: 4 How the inode block size is calculated? Please give the formatting details? From owner-linux-xfs@oss.sgi.com Thu Feb 13 06:40:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Feb 2003 06:40:46 -0800 (PST) Received: from mail.iwr.uni-heidelberg.de (mail.iwr.uni-heidelberg.de [129.206.104.30]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1DEea3v016059 for ; Thu, 13 Feb 2003 06:40:38 -0800 Received: from kenzo.iwr.uni-heidelberg.de (kenzo.iwr.uni-heidelberg.de [129.206.120.29]) by mail.iwr.uni-heidelberg.de (8.11.1/8.11.1) with ESMTP id h1DEmqb05024; Thu, 13 Feb 2003 15:48:52 +0100 (MET) Received: from localhost (bogdan@localhost) by kenzo.iwr.uni-heidelberg.de (8.11.6/8.11.6) with ESMTP id h1DEmqd23176; Thu, 13 Feb 2003 15:48:52 +0100 Date: Thu, 13 Feb 2003 15:48:52 +0100 (CET) From: Bogdan Costescu To: "D. Stimits" cc: linux-xfs@oss.sgi.com Subject: Re: Defrag pitfals (was Re: Support for XFS File systems) In-Reply-To: <3E4AC117.9080005@attbi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2667 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: bogdan.costescu@iwr.uni-heidelberg.de Precedence: bulk X-list: linux-xfs Content-Length: 836 Lines: 22 On Wed, 12 Feb 2003, D. Stimits wrote: > I am curious if the data is binary, or if it is in such a form that SQL > storage could be used? Yes, the data is binary, lots of Fortran INTEGER*4 and REAL*8. At least in some cases, data could be split for putting it into some database. But that would require very many changes in all aspects of our work as not only the producer has to be made SQL-aware, but also all consumers of this data. Another aspect is that data is usually consumed in the same sequence that it was produced, so none of the fancy sorting could be involved. -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From owner-linux-xfs@oss.sgi.com Thu Feb 13 07:05:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Feb 2003 07:05:38 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1DF5R3v017249 for ; Thu, 13 Feb 2003 07:05:27 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1DFMukq007060 for ; Thu, 13 Feb 2003 09:22:56 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA36178; Thu, 13 Feb 2003 09:13:37 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id JAA27044; Thu, 13 Feb 2003 09:13:38 -0600 (CST) Date: Thu, 13 Feb 2003 09:13:09 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Errol Neal cc: linux-xfs@oss.sgi.com Subject: Re: Cannot find XFS option in kernel config In-Reply-To: <5.1.1.6.0.20030213012316.026bc548@mail.jcntv.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2668 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 585 Lines: 22 Did you apply both patches in ftp://oss.sgi.com/projects/xfs/Release-1.2/kernel_patches/ ? One is changes to the core kernel, the other is xfs-specific files. That directory could use a README... but you need to apply both patches. -Eric On Thu, 13 Feb 2003, Errol Neal wrote: > I have been using the 1.1 release. I am trying to configure a kernel for > 1.2 release. I have already patched the kernel, but I cannot seem to find > the option to configure the kernel for XFS. It was under the Filesystems > tree in 1.1 release. Can someone help me please? > > > Errol > > From owner-linux-xfs@oss.sgi.com Thu Feb 13 07:18:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Feb 2003 07:18:16 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1DFI93v017936 for ; Thu, 13 Feb 2003 07:18:10 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1DFZdkq007443 for ; Thu, 13 Feb 2003 09:35:39 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA04474; Thu, 13 Feb 2003 09:26:20 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id JAA17940; Thu, 13 Feb 2003 09:26:20 -0600 (CST) Date: Thu, 13 Feb 2003 09:25:51 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Achim Altmann cc: xfs mailinglist Subject: Re: Can't pagebuffer in kernelmenu ? In-Reply-To: <002701c2d364$b3c57dd0$5a02640a@terragon.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by tolkor.sgi.com id h1DFZdkq007443 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h1DFIA3v017937 X-archive-position: 2669 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 8370 Lines: 116 Hello Achim - There is no pagebuf option now, you get pagebuf automatically with xfs, so that is not the problem. Do you have the "fs/xfs" directory in your kernel tree? It looks like perhaps the larger patch was not applied correctly. -Eric On Thu, 13 Feb 2003, Achim Altman wrote: > hello, > > now i have downloaded the kernel-2.4.19 from kernel.org > in step two i have downloaded the > two patches for xfs-kernel-support for kernel-2.4.19 > in step 3 i had patch the kernel under /usr/src with taht two patch-files > the new kernel-2.4.19 was a symlink to /usr/src/linux > > in step 4 i had "make manuconfig" > > I found the option under "filesystem" > > [*] POSIX Access Control Lists x x > x x [*] Quota support x x > x x < > Old quota format support x x > x x < > VFS v0 quota format support x x > x x [*] Compatible quota interfaces x x > x x (Original) Compatible quota interfaces x x > x x < > Kernel automounter support x x > x x < > Kernel automounter version 4 support (also supports v3) x x > x x Reiserfs support x x > x x [ ] Have reiserfs do extra internal checking x x > x x [ ] Stats in /proc/fs/reiserfs x x > x x < > Ext3 journalling file system support x x > x x < > DOS FAT fs support x x > x x < > Compressed ROM file system support x x > x x [*] Virtual memory file system support (former shm fs) x x > x x ISO 9660 CDROM file system support x x > x x [*] Microsoft Joliet CDROM extensions x x > x x [*] Transparent decompression extension x x > x x < > Minix fs support x x > x x < > FreeVxFS file system support (VERITAS VxFS(TM) compatible) x x > x x < > NTFS file system support (read only) x x > x x < > OS/2 HPFS file system support x x > x x [*] /proc file system support x x > x x < > QNX4 file system support (read only) x x > x x ROM file system support x x > x x <*> Second extended fs support x x > x x < > System V/Xenix/V7/Coherent file system support x x > x x < > UDF file system support (read only) x x > x x < > UFS file system support (read only) x x > x x <*> XFS filesystem support x x > x x [*] Quota support x x > x x [ ] DMAPI support x x > x x Network File Systems ---> x x > x x Partition Types ---> x x > x x Native Language Support ---> > > but you can see self above > > i can't find "pagebuffer" > > in step 5 i had run > make dep > and then coms the following message > fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=athlon -nostdinc -I /usr/lib/gcc-lib/i386-redhat-linux/3.2/include -- dir.c emd.c inode.c ioctl > .c mangle.c namei.c rdir.c > .depend > make[4]: Verlassen des Verzeichnisses Verzeichnis »/usr/src/linux-2.4.19/fs/umsdos« > make -C vfat fastdep > make[4]: Wechsel in das Verzeichnis Verzeichnis »/usr/src/linux-2.4.19/fs/vfat« > /usr/src/linux-2.4.19/scripts/mkdep -D__KERNEL__ -I/usr/src/linux-2.4.19/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common > -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=athlon -nostdinc -I /usr/lib/gcc-lib/i386-redhat-linux/3.2/include -- namei.c vfatfs_syms.c > . > depend > make[4]: Verlassen des Verzeichnisses Verzeichnis »/usr/src/linux-2.4.19/fs/vfat« > make -C xfs fastdep > make: Wechsel in das Verzeichnis ein unbekanntes Verzeichnis > make: *** xfs: Datei oder Verzeichnis nicht gefunden. Schluss. > make: Verlassen des Verzeichnisses ein unbekanntes Verzeichnis > make[3]: *** [_sfdep_xfs] Fehler 2 > make[3]: Verlassen des Verzeichnisses Verzeichnis »/usr/src/linux-2.4.19/fs« > make[2]: *** [fastdep] Fehler 2 > make[2]: Verlassen des Verzeichnisses Verzeichnis »/usr/src/linux-2.4.19/fs« > make[1]: *** [_sfdep_fs] Fehler 2 > make[1]: Verlassen des Verzeichnisses Verzeichnis »/usr/src/linux-2.4.19« > make: *** [dep-files] Fehler 2 > [root@alpha1 linux-2.4.19]# > > Verlassen ==> leaf > Verzeichnis ===> tree > Fehler ====> error > > Could any say what is wrong? > > Now i download the new kernel from cvs like in your web-documentation (FAQ) > > I hope that is better, please telle me when if is possible, which problems coms with this > sorry but a had download the new redhat 8.0-xfs-image and during the installation > (he would like installed the kernel) comes a error an break the installtion > > My System is a tyan-dual-amd board with 3WARE-4p controller and 3WARE-Hot-SWAP-IDE-BOX > > Please help > > Thank's a lot > > Best reagards > Achim > > > [[HTML alternate version deleted]] > > From owner-linux-xfs@oss.sgi.com Thu Feb 13 07:19:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Feb 2003 07:20:01 -0800 (PST) Received: from ks406.kasserver.com (ks406.kasserver.com [62.141.48.110]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1DFJu3v018378 for ; Thu, 13 Feb 2003 07:19:57 -0800 Received: from anubis (Af4af.pppool.de [213.6.244.175]) by ks406.kasserver.com (8.11.6/8.11.6) with SMTP id h1DFSCv22477 for ; Thu, 13 Feb 2003 16:28:12 +0100 Message-ID: <004101c2d375$bf6cfb20$5a02640a@terragon.de> From: "Achim Altmann" To: "xfs mailinglist" Subject: Sorry but can't find pagebuff in kernel only pagebuff debug? Date: Thu, 13 Feb 2003 16:36:59 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 2670 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: achim@altmann.li Precedence: bulk X-list: linux-xfs Content-Length: 416 Lines: 24 Hello, now i have doenloaded the kernel from xfs-cvs-tree But i saw only under file system in kernel-config the entry pagebuffer debugging support Is this correct? Or have i to select another section befor an than i can see the select-box pagebuffering (only this ) O what i have to do? I would like run XFS not as a module!!! Thank's a lot for any help Reagards Achim [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Thu Feb 13 07:24:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Feb 2003 07:24:56 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1DFOr3v018881 for ; Thu, 13 Feb 2003 07:24:53 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1DFgNkq007619 for ; Thu, 13 Feb 2003 09:42:23 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA41668; Thu, 13 Feb 2003 09:33:04 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id JAA27822; Thu, 13 Feb 2003 09:33:04 -0600 (CST) Date: Thu, 13 Feb 2003 09:32:35 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: "'Linto Joseph Mathew" cc: linux-xfs@oss.sgi.com Subject: Re: Disk formatting In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2671 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 407 Lines: 18 the mkfs.xfs man page has a detailed section on inode options, this might answer your question. "man 5 xfs" will also give you some information on the layout of an xfs filesystem. If you have specific questions after reading those documents, let us know. -Eric On Thu, 13 Feb 2003, 'Linto Joseph Mathew wrote: > How the inode block size is calculated? > Please give the formatting details? > > > From owner-linux-xfs@oss.sgi.com Thu Feb 13 07:56:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Feb 2003 07:56:10 -0800 (PST) Received: from mailout1.echostar.com (mailout1.echostar.com [204.76.128.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1DFtx3v031484 for ; Thu, 13 Feb 2003 07:56:00 -0800 Received: from riv-exchcon.echostar.com ([10.1.200.73]) by 10.0.221.101 with InterScan Messaging Security Suite; Thu, 13 Feb 2003 09:04:29 -0700 Received: by riv-exchcon.echostar.com with Internet Mail Service (5.5.2653.19) id <1XY9R0KH>; Thu, 13 Feb 2003 09:04:10 -0700 Received: from echostar.com (linux1.echostar.com [10.79.98.101]) by riv-exchcon.echostar.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1XY9R0J4; Thu, 13 Feb 2003 09:03:58 -0700 From: "Buzbee, James" To: linux-xfs@oss.sgi.com Message-ID: <3E4BC1ED.3060201@echostar.com> Date: Thu, 13 Feb 2003 09:03:57 -0700 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Write Verify and XFS X-Enigmail-Version: 0.62.4.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2672 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: James.Buzbee@echostar.com Precedence: bulk X-list: linux-xfs Content-Length: 2414 Lines: 54 Sorry for the long post, but I'm wrestling with several issues related to manufacturing flaws that are (evidently) commonly found with IDE drives. What we are finding is that there are bad sectors on new drives that are not recognized until we try to read previously written data. We've been told by the drive manufacturer that this is "normal". You write data to the drive, the write succeeds. Sometime later you go to read your data and you get an error such as : hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdc: dma_intr: error=0x40 { UncorrectableError }, LBAsect=24093, sector=23984 end_request: I/O error, dev 16:01 (hdc), sector 23984 Obviously by this time your data is lost. We're told that if we write to that bad sector again, the sector will be remapped away. First question, is this -really- normal? I have a hard time believing that it is OK for a brand new drive to silently fail on some writes. Can this error be detected at write time, and if so, what would Linux/XFS do with the error? Researching a bit, I find that some drives are shipped from the manufacturer with "Write Verify" turned on for the first "N" power cycles. Based on my limited understanding of Write Verify this implies to me that the manufacturer wants the consumer to use the drive for a while, and the "bad" sectors will turn up and get remapped. Obviously, this will have a impact on drive performance during this period. Is this because the drive manufacturers don't want to spend the time/money to verify the platter themselves? Second question, when Write Verify is turned on and a bad sector is detected, will the drive firmware transparently take care of remapping and re-writing the data or does an error get passed up the chain for higher level software to take care of? If the error gets passed up the chain, what will Linux/XFS do with the error? Last question, if this -really- is normal, and it is something that has to be dealt with, what is the proper solution? I know that leaving Write Verify turned on is not the solution. It cuts drive performance in half. One proposed solution (for us at least) is to turn Write Verify on for "critical" data and off for "non-critical" data. This seems like a hack. If I write the data to the drive, and the drive says "OK" shouldn't the data be there? Thanks for any and all feedback! Jim From owner-linux-xfs@oss.sgi.com Thu Feb 13 08:18:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Feb 2003 08:18:08 -0800 (PST) Received: from mail.tvol.net (pr-66-150-46-254.wgate.com [66.150.46.254]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1DGI03v032122 for ; Thu, 13 Feb 2003 08:18:01 -0800 Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.tvol.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZBLDHPYG; Thu, 13 Feb 2003 11:26:38 -0500 Received: from wgate.com (localhost.localdomain [127.0.0.1]) by sinz.eng.tvol.net (8.12.5/8.12.5) with ESMTP id h1DGOrCj000924; Thu, 13 Feb 2003 11:24:54 -0500 Message-ID: <3E4BC6D5.4090807@wgate.com> Date: Thu, 13 Feb 2003 11:24:53 -0500 From: Michael Sinz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021118 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Buzbee, James" CC: linux-xfs@oss.sgi.com Subject: Re: Write Verify and XFS References: <3E4BC1ED.3060201@echostar.com> In-Reply-To: <3E4BC1ED.3060201@echostar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2673 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: msinz@wgate.com Precedence: bulk X-list: linux-xfs Content-Length: 1967 Lines: 42 Buzbee, James wrote: > > Sorry for the long post, but I'm wrestling with several issues related > to manufacturing flaws that are (evidently) commonly found with IDE drives. [...] > Last question, if this -really- is normal, and it is something that has > to be dealt with, what is the proper solution? I know that leaving > Write Verify turned on is not the solution. It cuts drive performance > in half. One proposed solution (for us at least) is to turn Write Verify > on for "critical" data and off for "non-critical" data. This seems like > a hack. If I write the data to the drive, and the drive says > "OK" shouldn't the data be there? ; Thu, 13 Feb 2003 08:32:25 -0800 Received: from tiger2 ([66.156.0.142]) by imf14bis.bellsouth.net (InterMail vM.5.01.04.25 201-253-122-122-125-20020815) with SMTP id <20030213164235.NFRT15990.imf14bis.bellsouth.net@tiger2>; Thu, 13 Feb 2003 11:42:35 -0500 Date: Thu, 13 Feb 2003 11:43:31 -0500 From: Greg Freemyer Subject: re: Write Verify and XFS To: "Buzbee, James" , Mime-Version: 1.0 Organization: Norcross Group X-Mailer: GoldMine [6.00.21021] Content-Type: Text/plain Message-Id: <20030213164235.NFRT15990.imf14bis.bellsouth.net@tiger2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h1DGWQ3v032681 X-archive-position: 2674 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: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs Content-Length: 4129 Lines: 73 James, That is an interesting post, but it definitely all takes place below the XFS level. Filesystems in general assume that the underlying disks/raid systems are reliable. And just so you know, even write verify is not enough to truly ensure you won't have problems. During the 80's it was common to have disk areas with weak magnetic characteristics. The end result was that you had sectors that could hold data for long enough to pass write/read tests, but if you wrote something to disk, then tried to read it 6 months later, you got read errors. At that time I used to do a read only diskscan on all new drives. That way any weak magnetic areas could be detected immediately and remapped. After that, I would partition and mkfs. (You do know every sector has a CRC, so the drive can tell if even one bit has changed from when it was written.) I have not seen that behavior recently, but I always use RAID now if I care about the data. If I were experiencing this problem today, I would at least do a "dd if=/dev/hdb of=/dev/null" on all new drives and let all the read errors occur and have automatic remapping take place. (I've been told that IDE bad block remapping is automatic, but I am not a definitive source on that.) I guess you could also write out a data pattern that stresses the magnetic fields, leave the drive alone for a day/week/month, then try to read it back off with the above dd command. Unfortunately, I don't know what data pattern would stress a drive. HTH Greg Freemyer >> Sorry for the long post, but I'm wrestling with several issues related >> to manufacturing flaws that are (evidently) commonly found with IDE >> drives. >> What we are finding is that there are bad sectors on new drives that are >> not recognized until we try to read previously written data. We've been >> told by the drive manufacturer that this is "normal". You write data to >> the drive, the write succeeds. Sometime later you go to read your data >> and you get an error such as : >> hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } >> hdc: dma_intr: error=0x40 { UncorrectableError }, LBAsect=24093, >> sector=23984 >> end_request: I/O error, dev 16:01 (hdc), sector 23984 >> Obviously by this time your data is lost. We're told that if we write to >> that bad sector again, the sector will be remapped away. >> First question, is this -really- normal? I have a hard time believing >> that it is OK for a brand new drive to silently fail on some writes. Can >> this error be detected at write time, and if so, what would Linux/XFS do >> with the error? >> Researching a bit, I find that some drives are shipped from the >> manufacturer with "Write Verify" turned on for the first "N" power >> cycles. Based on my limited understanding of Write Verify this implies >> to me that the manufacturer wants the consumer to use the drive for a >> while, and the "bad" sectors will turn up and get remapped. Obviously, >> this will have a impact on drive performance during this period. Is this >> because the drive manufacturers don't want to spend the time/money to >> verify the platter themselves? >> Second question, when Write Verify is turned on and a bad sector is >> detected, will the drive firmware transparently take care of remapping >> and re-writing the data or does an error get passed up the chain for >> higher level software to take care of? If the error gets passed up the >> chain, what will Linux/XFS do with the error? >> Last question, if this -really- is normal, and it is something that has >> to be dealt with, what is the proper solution? I know that leaving >> Write Verify turned on is not the solution. It cuts drive performance >> in half. One proposed solution (for us at least) is to turn Write Verify >> on for "critical" data and off for "non-critical" data. This seems like >> a hack. If I write the data to the drive, and the drive says >> "OK" shouldn't the data be there? >> Thanks for any and all feedback! >> Jim From owner-linux-xfs@oss.sgi.com Thu Feb 13 08:41:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Feb 2003 08:41:16 -0800 (PST) Received: from homer.nks.net (homer.nks.net [66.152.21.172]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1DGf83v001120 for ; Thu, 13 Feb 2003 08:41:09 -0800 Received: from hoju.nks.net (hoju.nks.net [192.168.1.17]) by homer.nks.net (8.9.3/8.9.3) with ESMTP id LAA19547 for ; Thu, 13 Feb 2003 11:49:21 -0500 Received: from localhost.localdomain (two.nks.net [192.168.1.22]) by hoju.nks.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id LAA12781 for ; Thu, 13 Feb 2003 11:49:19 -0500 Subject: Re: Write Verify and XFS From: Derek Glidden To: linux-xfs@oss.sgi.com In-Reply-To: <3E4BC6D5.4090807@wgate.com> References: <3E4BC1ED.3060201@echostar.com> <3E4BC6D5.4090807@wgate.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 13 Feb 2003 11:49:19 -0500 Message-Id: <1045154959.29851.23.camel@two.nks.net> Mime-Version: 1.0 X-archive-position: 2675 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: dglidden@illusionary.com Precedence: bulk X-list: linux-xfs Content-Length: 2617 Lines: 55 On Thu, 2003-02-13 at 11:24, Michael Sinz wrote: > > Last question, if this -really- is normal, and it is something that has > > to be dealt with, what is the proper solution? I know that leaving > > Write Verify turned on is not the solution. It cuts drive performance > > in half. One proposed solution (for us at least) is to turn Write Verify > > on for "critical" data and off for "non-critical" data. This seems like > > a hack. If I write the data to the drive, and the drive says > > "OK" shouldn't the data be there? > I agree with your rant - and I also know that the trick the drive > makers use works for Windows systems because the "format" operation > (well older Windows) would write to every sector of the drive. Agreed here also. > What I have done is to take new drives and put them on-line (powered) > and set the write verify on and then use a simple tool that wrote > random data over the whole disk (or just /dev/zero using something We typically run new systems through the "Cerberus" test, originally made by VA. One of the test processes does something similar to what you're describing above, only doing multiple parallel non-destructive reads against the whole block device, which also seriously stresses the drive. We've had great luck with Cerberus catching out marginal equipment before we deploy new systems. http://sourceforge.net/projects/va-ctcs/ We actually do use IDE drives for all our systems, but important systems get pounded for some time with Cerberus, and at the very least get mirrored drives if not RAID5. I still agree that SCSI is "better" but as long as we've gone through full QA, we've had great luck with IDE, and IDE is just so much cheaper and considering the state of the industry today.... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- #!/usr/bin/perl -w $_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map {$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110; $t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z) [$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join "",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d= unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d >>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q* 8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]} print+x"C*",@a}';s/x/pack+/g;eval usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \ | extract_mpeg2 | mpeg2dec - http://www.cs.cmu.edu/~dst/DeCSS/Gallery/ http://www.eff.org/ http://www.anti-dmca.org/ From owner-linux-xfs@oss.sgi.com Thu Feb 13 08:41:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Feb 2003 08:41:53 -0800 (PST) Received: from relay.utk.ru (relay.utk.ru [81.91.37.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1DGfk3v001316 for ; Thu, 13 Feb 2003 08:41:48 -0800 Received: from localhost.localdomain (IDENT:sinkam@vc196.utk.ru [81.91.32.196]) by relay.utk.ru (8.12.7/8.12.7) with SMTP id h1DGnZDq021228 for ; Thu, 13 Feb 2003 21:49:59 +0500 (YEKT) From: sinkam Date: Thu, 13 Feb 2003 19:42:50 +0500 X-Mailer: KMail [version 1.1.99] Content-Type: text/plain; charset="us-ascii" To: linux-xfs@oss.sgi.com Subject: n.p. division MIME-Version: 1.0 Message-Id: <03021319425001.00664@localhost.localdomain> Content-Transfer-Encoding: 8bit X-archive-position: 2676 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: sinkam@mail.utk.ru Precedence: bulk X-list: linux-xfs Content-Length: 118 Lines: 7 Dear sirs, could you inform me on your company's division which considers new products SGI to produce. Yuri Linder From owner-linux-xfs@oss.sgi.com Thu Feb 13 09:20:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Feb 2003 09:20:17 -0800 (PST) Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1DHK93v002549 for ; Thu, 13 Feb 2003 09:20:10 -0800 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.6/8.11.6) with ESMTP id h1DHSLt15228; Thu, 13 Feb 2003 12:28:21 -0500 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Thu, 13 Feb 2003 12:28:21 -0500 (EST) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: Keith Owens cc: Fabio Baiocco , Subject: Re: Error rebuilding xfsprogs-2.3.5-0.src.rpm In-Reply-To: <5105.1045137770@ocs3.intra.ocs.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2677 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jlb17@duke.edu Precedence: bulk X-list: linux-xfs Content-Length: 709 Lines: 21 On Thu, 13 Feb 2003 at 11:02pm, Keith Owens wrote > For some reason, the spec file in xfsprogs is incorrect. It has > /usr/local/man/man5/xfs.5 > when it should be > /usr/local/man/man5/xfs.5* > the trailing '*' is to cope with gzipped man pages, which RH 7.2 does > by default. > > It looks like a failure in the awk code that builds the spec filelist > from the manifest. Until the xfs release team can correct the build > process, here is an untested patch to workaround the problem. Thanks! The patch works for me, i.e. xfsprogs rpmbuilds and the affected man pages are in place after installing the rpms produced. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Thu Feb 13 09:35:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Feb 2003 09:35:23 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1DHZJ3v003591 for ; Thu, 13 Feb 2003 09:35:20 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1DGopKp021507 for ; Thu, 13 Feb 2003 08:50:52 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA01898 for ; Thu, 13 Feb 2003 11:43:29 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA46653 for ; Thu, 13 Feb 2003 11:43:31 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h1DHhV630457; Thu, 13 Feb 2003 11:43:31 -0600 Message-Id: <200302131743.h1DHhV630457@jen.americas.sgi.com> Date: Thu, 13 Feb 2003 11:43:31 -0600 Subject: TAKE 880764 - fix another transaction ordering problem To: linux-xfs@oss.sgi.com X-archive-position: 2678 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1303 Lines: 36 fix one more set of transaction callback ordering issues, this was always there, but exposed by the last change in this area and made much more likely. Date: Thu Feb 13 09:41:15 PST 2003 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 Inspected by: lord@sgi.com Author: overby Merged by: lord Merged mods: irix6.5f:irix:139655a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:139655a linux/fs/xfs/xfs_log.h - 1.64 - Merge of irix6.5f:irix:139655a by lord. Add a prototype for xfs_log_release_iclog. linux/fs/xfs/xfs_log.c - 1.264 - Merge of irix6.5f:irix:139655a by lord. Remove the releasing of the iclog from xfs_log_notify (except when aborting). The release will be done later by xfs_trans_commit. xfs_log_release_iclog is called by xfs_trans_commit to release iclogs. This is so that log-private types don't need to be included outside of xfs_log. linux/fs/xfs/xfs_trans.c - 1.140 - Merge of irix6.5f:irix:139655a by lord. in xfs_trans_commit, eliminate a race betweeen unlocking items and adding the transaction to the iclog's callback by adding the callbacks before unlocking the items. The reference to the iclog acquired in xfs_log_done is held until after the unlocks are done. From owner-linux-xfs@oss.sgi.com Thu Feb 13 10:31:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Feb 2003 10:31:58 -0800 (PST) Received: from andrei.myip.org (12-234-116-173.client.attbi.com [12.234.116.173]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1DIVr3v004621 for ; Thu, 13 Feb 2003 10:31:54 -0800 Received: from spampd.localdomain (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7D3DB2FA71 for ; Thu, 13 Feb 2003 10:40:11 -0800 (PST) Received: from stantz.corp.sgi.com (unknown [130.62.4.42]) by andrei.myip.org (Postfix) with ESMTP id DFAEC2FA71 for ; Thu, 13 Feb 2003 10:40:10 -0800 (PST) Received: from localhost.localdomain (localhost [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 800671967B for ; Thu, 13 Feb 2003 10:40:00 -0800 (PST) Subject: Re: Defrag pitfals (was Re: Support for XFS File systems) From: Florin Andrei Reply-To: linux-xfs@oss.sgi.com To: linux-xfs In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 13 Feb 2003 10:40:00 -0800 Message-Id: <1045161600.30606.4.camel@stantz.corp.sgi.com> Mime-Version: 1.0 X-archive-position: 2679 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: florin@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 824 Lines: 21 On Wed, 2003-02-12 at 11:28, Bogdan Costescu wrote: > After switching to XFS and (mea culpa!) forgetting to set up xfs_fsr to be > run by cron, the read speed would be similar after several days-weeks. > However, by using xfs_fsr we go back to reading with around 20 MiB/s even > for a pretty full FS. There were many helpful answers posted to the list, surely you can pick a few good ones and try. A generic method that seems to work pretty much everywhere and provides good results is to avoid the disk usage to grow too much. A filesystem that's at 95% usage will usually be quite fragmented. Stay away from that. By doing some tests you may be able to determine which is - in your case - the disk usage limit which triggers the fragmentation problems. -- Florin Andrei A cloned dog doesn't know the old tricks. From owner-linux-xfs@oss.sgi.com Thu Feb 13 10:57:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Feb 2003 10:57:25 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1DIvF3v005228 for ; Thu, 13 Feb 2003 10:57:15 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1DIClKp029893 for ; Thu, 13 Feb 2003 10:12:47 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA94911 for ; Thu, 13 Feb 2003 13:05:26 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA20101 for ; Thu, 13 Feb 2003 13:05:25 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h1E2LZd16001 for linux-xfs@oss.sgi.com; Thu, 13 Feb 2003 21:21:35 -0500 Resent-Message-Id: <200302140221.h1E2LZd16001@taclab54.munich.sgi.com> Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA90723 for ; Thu, 13 Feb 2003 13:05:09 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id h1DJ58Zu9175472 for ; Thu, 13 Feb 2003 11:05:08 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id h1DJ2Ocg011607 for ; Thu, 13 Feb 2003 20:02:24 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id h1DJ2OZc011604 for hch@sgi.com; Thu, 13 Feb 2003 20:02:24 +0100 Date: Thu, 13 Feb 2003 20:02:24 +0100 From: Christoph Hellwig Message-Id: <200302131902.h1DJ2OZc011604@lab343.munich.sgi.com> Subject: TAKE - fix dirty buffer leak (in error path) To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Thu, 13 Feb 2003 21:21:35 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 2680 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 409 Lines: 13 Date: Thu Feb 13 11:03:00 PST 2003 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:139678a linux/fs/xfs/pagebuf/page_buf.c - 1.93 - Nathan pointed out that the kmalloc failure handling in _pagebuf_page_io still isn't correct - we could leak dirty buffer heads in this case. From owner-linux-xfs@oss.sgi.com Thu Feb 13 12:16:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Feb 2003 12:16:47 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1DKGe3v006462 for ; Thu, 13 Feb 2003 12:16:41 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1DIP3G8023727 for ; Thu, 13 Feb 2003 10:25:03 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA99376 for ; Thu, 13 Feb 2003 14:24:52 -0600 (CST) Received: from rose.americas.sgi.com (rose.americas.sgi.com [128.162.232.98]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA20502 for ; Thu, 13 Feb 2003 14:24:52 -0600 (CST) Subject: Re: Error rebuilding xfsprogs-2.3.5-0.src.rpm From: Rusell Cattelan Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: Message-Id: <1045167898.1476.27.camel@rose.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-1) Date: 13 Feb 2003 14:24:58 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 2681 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@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 941 Lines: 24 Just as a side note for everybody. All the rpm builds and testing for 1.2 was done on RH 8.0 boxes. So while we are more than willing to accept patches for earlier version of RH we simply and not tested anything but 8.0. On Thu, 2003-02-13 at 11:28, Joshua Baker-LePain wrote: > On Thu, 13 Feb 2003 at 11:02pm, Keith Owens wrote > > > For some reason, the spec file in xfsprogs is incorrect. It has > > /usr/local/man/man5/xfs.5 > > when it should be > > /usr/local/man/man5/xfs.5* > > the trailing '*' is to cope with gzipped man pages, which RH 7.2 does > > by default. > > > > It looks like a failure in the awk code that builds the spec filelist > > from the manifest. Until the xfs release team can correct the build > > process, here is an untested patch to workaround the problem. > > Thanks! The patch works for me, i.e. xfsprogs rpmbuilds and the affected > man pages are in place after installing the rpms produced. From owner-linux-xfs@oss.sgi.com Thu Feb 13 16:14:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Feb 2003 16:14:26 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1E0EK3v018922 for ; Thu, 13 Feb 2003 16:14:20 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1E0EKuv018921 for linux-xfs@oss.sgi.com; Thu, 13 Feb 2003 16:14:20 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1E0EI3v018897 for ; Thu, 13 Feb 2003 16:14:18 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1DNpWfr018417; Thu, 13 Feb 2003 15:51:32 -0800 Date: Thu, 13 Feb 2003 15:51:32 -0800 Message-Id: <200302132351.h1DNpWfr018417@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 220] New: POSTCREATE never fires X-Bugzilla-Reason: AssignedTo X-archive-position: 2682 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1413 Lines: 59 http://oss.sgi.com/bugzilla/show_bug.cgi?id=220 Summary: POSTCREATE never fires Product: Linux XFS Version: 1.2.x Platform: IA32 OS/Version: Linux Status: NEW Severity: normal Priority: Low Component: dmapi AssignedTo: xfs-master@oss.sgi.com ReportedBy: joshhelmer@cox.net If this is a userspace bug, what version of the package are you using: What kernel are you using: 2.4.20-xfs Where did the XFS code come from? (CVS, Linus, your distribution, etc): CVS (last update 2/12/2003) Description of Problem: The test for determining if a POSTCREATE event needs to fire contains a minor bug. How Reproducible: Steps to Reproduce: 1. 2. 3. Actual Results: Expected Results: Additional Information: --- xfs_vnodeops.c Thu Feb 13 16:32:44 2003 +++ xfs_vnodeops.c.new Thu Feb 13 16:32:23 2003 @@ -2115,7 +2115,7 @@ /* Fallthrough to std_return with error = 0 */ std_return: - if ((error != 0) && + if ((error == 0) && DM_EVENT_ENABLED(dir_vp->v_vfsp, XFS_BHVTOI(dir_bdp), DM_EVENT_POSTCREATE)) { (void) dm_send_namesp_event(DM_EVENT_POSTCREATE, ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Feb 13 16:14:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Feb 2003 16:14:33 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1E0EK3v018923 for ; Thu, 13 Feb 2003 16:14:20 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1E0EK5t018920 for linux-xfs@oss.sgi.com; Thu, 13 Feb 2003 16:14:20 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1E0EI3x018897 for ; Thu, 13 Feb 2003 16:14:18 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1E0CCe4018589; Thu, 13 Feb 2003 16:12:12 -0800 Date: Thu, 13 Feb 2003 16:12:12 -0800 Message-Id: <200302140012.h1E0CCe4018589@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 221] New: reload xfs module crash X-Bugzilla-Reason: AssignedTo X-archive-position: 2683 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1645 Lines: 57 http://oss.sgi.com/bugzilla/show_bug.cgi?id=221 Summary: reload xfs module crash Product: Linux XFS Version: 1.2.x Platform: IA32 OS/Version: Linux Status: NEW Severity: normal Priority: Low Component: dmapi AssignedTo: xfs-master@oss.sgi.com ReportedBy: joshhelmer@cox.net If this is a userspace bug, what version of the package are you using: What kernel are you using: 2.4.20-xfs Where did the XFS code come from? (CVS, Linus, your distribution, etc): cvs (last update 2/12/2003) Description of Problem: Removing and re-inserting the xfs modules will crash when dmapi is enabled. How Reproducible: Every time. Steps to Reproduce: 1. Mount a filesystem with dmapi (will load the xfs module) mount -t xfs /dev/hdb1 /xfs -o dmapi,mtpt=/xfs 2. Unmount the filesystem 3. Remove the xfs module. When I do this I get the following error: kmem_cache_destroy: Can't free all objects c7a57b84 4. Try to insmod the xfs module. Actual Results: The module fails to load. Expected Results: Additional Information: It appears that the problem is caused because the "dm_tokdata" cache never goes away. When you try to free the cache it fails because the slabs_partial list still has an outstanding entry in it. From that point on, you are unable to load the xfs module because a "dm_tokdata" cache is still hanging out in memory and the cache manager will not allow you to create a new one with that same name. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Feb 13 19:15:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Feb 2003 19:16:04 -0800 (PST) Received: from imsmq06.netvigator.com (imsmq06.netvigator.com [218.102.48.42]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1E3Fu3v007197 for ; Thu, 13 Feb 2003 19:15:57 -0800 Received: (qmail 5983 invoked from network); 14 Feb 2003 03:24:09 -0000 Received: from pcd270142.netvigator.com (HELO grifdale) (203.218.60.142) by imsmq06.netvigator.com with SMTP; 14 Feb 2003 03:24:09 -0000 Received: from snowman by grifdale with local (Exim 3.36 #1 (Debian)) id 18jWSP-0001iM-00; Fri, 14 Feb 2003 11:24:09 +0800 To: Thomas Seifert Subject: Re: Release 1.2 for Kernel 2.4.20? From: Frank Chung Cc: linux-xfs@oss.sgi.com In-reply-to: <20030212230557.3ece54af.thomas.seifert@myphorum.de> References: <20030212230557.3ece54af.thomas.seifert@myphorum.de> Message-Id: Date: Fri, 14 Feb 2003 11:24:09 +0800 X-archive-position: 2684 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: chungf@myrealbox.com Precedence: bulk X-list: linux-xfs Content-Length: 1302 Lines: 35 Thomas Seifert wrote: > > Hi folks, > > thanks for that great filesystem. > I use it in production on many system and never had any problems with it > :-). > > For the current release, is there a chance to get official 1.2-patches for > the 2.4.20-kernel or maybe the upcoming 2.4.21? > > Or do we have to live with snapshots from CVS for it? > Just curious about the policy on it. Being the _official_ patch, SGI developers naturally have certain requirements on its reliability. They have been working on version 1.2 since before 2.4.20 was out, so they can only guarantee reliability of the patch when applied to the kernel they developed for, i.e. 2.4.19. I have my own question though. For 2.4.20, you can apply the xfs patch in one of 3 ways: - Apply the cvs snapshot from: ftp://oss.sgi.com/projects/xfs/patches/2.4.20/ - Apply the weekly snapshot from: ftp://oss.sgi.com/projects/xfs/patches/weekly-snapshot-patch/ - Manually fixing the rejects in the official 1.2 patch and applying Provided one can actually "fix" the rejects and still end up with a usable kernel and fs (I routinely do this for applying xfs patches after Andrew Morton's low latency patch), which of these 3 methods yield a "more" stable (and yet up-to-date) xfs kernel? Regards, Frank From owner-linux-xfs@oss.sgi.com Thu Feb 13 20:07:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Feb 2003 20:07:16 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1E47A3v008080 for ; Thu, 13 Feb 2003 20:07:10 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1E2FYG8029639 for ; Thu, 13 Feb 2003 18:15:34 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id WAA46399; Thu, 13 Feb 2003 22:15:23 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id WAA89298; Thu, 13 Feb 2003 22:15:23 -0600 (CST) Date: Thu, 13 Feb 2003 22:14:49 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Frank Chung cc: Thomas Seifert , Subject: Re: Release 1.2 for Kernel 2.4.20? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2685 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1015 Lines: 28 On Fri, 14 Feb 2003, Frank Chung wrote: > I have my own question though. For 2.4.20, you can apply the xfs patch in > one of 3 ways: > - Apply the cvs snapshot from: > ftp://oss.sgi.com/projects/xfs/patches/2.4.20/ This is a snapshot that is taken when things "seem" stable, and it's massaged into many sub-patches for system integrators. But it's still not rigorously tested. > - Apply the weekly snapshot from: > ftp://oss.sgi.com/projects/xfs/patches/weekly-snapshot-patch/ This one is cron-generated, runs the risk of being completely broken. > - Manually fixing the rejects in the official 1.2 patch and applying > > Provided one can actually "fix" the rejects and still end up with a usable > kernel and fs (I routinely do this for applying xfs patches after Andrew > Morton's low latency patch), which of these 3 methods yield a "more" stable > (and yet up-to-date) xfs kernel? Stable - the 1.2 patch. uptodate - the weekly snapshot. Somewhere in between, the patches/2.4.20 patch. :) -Eric From owner-linux-xfs@oss.sgi.com Thu Feb 13 22:58:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Feb 2003 22:58:25 -0800 (PST) Received: from server3.thinmail.com (IDENT:root@server3.thinmail.com [64.39.29.150]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1E6wG3v010066 for ; Thu, 13 Feb 2003 22:58:17 -0800 Received: (from root@localhost) by server3.thinmail.com (8.9.3/8.9.3) id BAA20098 for linux-xfs@oss.sgi.com; Fri, 14 Feb 2003 01:08:52 -0600 Received: from mail.speakeasy.net (mail14.speakeasy.net [216.254.0.214]) by server3.thinmail.com (8.9.3/8.9.3) with ESMTP id BAA20061 for ; Fri, 14 Feb 2003 01:08:30 -0600 Received: (qmail 13325 invoked from network); 14 Feb 2003 07:05:32 -0000 Received: from unknown (HELO [192.168.0.22]) ([66.92.66.165]) (envelope-sender ) by mail14.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 14 Feb 2003 07:05:32 -0000 Mime-Version: 1.0 X-Sender: aaronm@mail.cs.brandeis.edu (Unverified) Message-Id: Date: Fri, 14 Feb 2003 01:55:47 -0500 Subject: data recovery from a single stripe X-Thinmail: Processed by Thinmail build 0055, Revision: 1.150 , id 20073 X-Thinmail-Loop: fa750-827cfd80d6215eec To: linux-xfs@oss.sgi.com From: Aaron Macks X-archive-position: 2686 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: aaronm@cs.brandeis.edu.ml.to Precedence: bulk X-list: linux-xfs Content-Length: 569 Lines: 14 A hypothetical: Say I have 2 identical drives configured as a striped array, but only with 1 stripe, i.e. a contiguous data stripe from one drive to the next), and a single XFS partition on the pair. If the first drive is lost, would the data on the second be recoverable, say by backup superblocks? just trying to figure some things out thanks Aaron -- _______________________________________________________ Aaron Macks(aaronm@cs.brandeis.edu) [http://wiglaf.cs-i.brandeis.edu/~aaronm] My sheep has seven gall bladders, that makes me the King of the Universe! From owner-linux-xfs@oss.sgi.com Fri Feb 14 02:37:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Feb 2003 02:37:44 -0800 (PST) Received: from sundancer.oche.de (sundancer.oche.de [194.94.252.29]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1EAbX3v016832 for ; Fri, 14 Feb 2003 02:37:37 -0800 Received: by sundancer.oche.de (Postfix, from userid 10) id D16B32826D; Fri, 14 Feb 2003 11:45:46 +0100 (CET) Received: (from martin@localhost) by foehn.quickstep.oche.de (8.9.3/8.6.12) id LAA02947; Fri, 14 Feb 2003 11:45:22 +0100 (CET) Date: Fri, 14 Feb 2003 11:45:22 +0100 (CET) Message-Id: <200302141045.LAA02947@foehn.quickstep.oche.de> From: Martin Spott To: linux-xfs@oss.sgi.com Subject: Re: data recovery from a single stripe In-Reply-To: Organization: home User-Agent: tin/1.4.5-20010409 ("One More Nightmare") (UNIX) (SunOS/5.8 (sun4m)) X-archive-position: 2687 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Martin.Spott@uni-duisburg.de Precedence: bulk X-list: linux-xfs Content-Length: 382 Lines: 12 > A hypothetical: > Say I have 2 identical drives configured as a striped array, but only > with 1 stripe, i.e. a contiguous data stripe from one drive to the > next), [...] Isn't this called "concatenated disks" ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Fri Feb 14 08:14:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Feb 2003 08:14:24 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1EGEK3v025390 for ; Fri, 14 Feb 2003 08:14:20 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1EGEK4h025389 for linux-xfs@oss.sgi.com; Fri, 14 Feb 2003 08:14:20 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1EGEI3x025375 for ; Fri, 14 Feb 2003 08:14:18 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1EG3gfj024956; Fri, 14 Feb 2003 08:03:42 -0800 Date: Fri, 14 Feb 2003 08:03:42 -0800 Message-Id: <200302141603.h1EG3gfj024956@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 221] reload xfs/dmapi module crash X-Bugzilla-Reason: AssignedTo X-archive-position: 2688 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 949 Lines: 26 http://oss.sgi.com/bugzilla/show_bug.cgi?id=221 roehrich@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|reload xfs module crash |reload xfs/dmapi module | |crash ------- Additional Comments From roehrich@sgi.com 2003-02-14 08:03 ------- Is the tokdata cache the only one that had stuff remaining in it? If there's something in it, then I'm betting there's something in the other caches as well. Look over the files under /proc/xfs_dmapi_d just prior to your unmount and unload and see if there are any clues about what's going to happen. It's possible (likely) that we're missing a few opportunities to mark the filesystem and the module as busy. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Feb 14 09:20:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Feb 2003 09:20:36 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1EHKS3v026634 for ; Fri, 14 Feb 2003 09:20:28 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1EHKRcV026633 for linux-xfs@oss.sgi.com; Fri, 14 Feb 2003 09:20:27 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1EHKQ3v026621 for ; Fri, 14 Feb 2003 09:20:26 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1EHFu9R026568; Fri, 14 Feb 2003 09:15:56 -0800 Date: Fri, 14 Feb 2003 09:15:56 -0800 Message-Id: <200302141715.h1EHFu9R026568@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 221] reload xfs/dmapi module crash X-Bugzilla-Reason: AssignedTo X-archive-position: 2689 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2395 Lines: 62 http://oss.sgi.com/bugzilla/show_bug.cgi?id=221 ------- Additional Comments From joshhelmer@cox.net 2003-02-14 09:15 ------- Yes, I am pretty sure that the dm_tokdata cache is the only one with data left in it. I added some debugging code to mm/slab.c to dump the contents of the cache in the case where it does not clean up properly and the only one that ever has issues is the "dm_tokdata" cache. After doing some more testing I think that I MIGHT have found the problem. In dm_send_namesp_event(), token data is being allocated - even if the PREUNMOUNT event is not being handled. When the check against DM_FLAGS_UNWANTED occurs a return is called without ever freeing up that memory... I applied the following patch: --------------------------------------------------------------------------- --- dmapi_event.c.orig Fri Feb 14 09:23:08 2003 +++ dmapi_event.c Fri Feb 14 09:24:56 2003 @@ -654,6 +654,10 @@ * vp1_right is the filesystem right. * vp2_right is the root inode right. */ + if (flags & DM_FLAGS_UNWANTED) { + dm_change_fsys_entry(sidvfsp, DM_STATE_UNMOUNTING); + return(0); + } tdp1 = dm_vfs_data(sidvfsp, vp1, vp1_right); if (tdp1 == NULL) @@ -664,10 +668,6 @@ return ENOMEM; } - if (flags & DM_FLAGS_UNWANTED) { - dm_change_fsys_entry(sidvfsp, DM_STATE_UNMOUNTING); - return(0); - } break; case DM_EVENT_NOSPACE: ----------------------------------------------------------------------------- to my local machine and all issues seem to have cleared up. I can't guarantee that this is 100% correct though because if, instead of moving the check against DM_FLAGS_UNWANTED up, I just release tdp1 and tdp2 a whole slew of other problems show up. I am also a little uncomfortable with this solution because when I dump out the dm_tokdata cache I only see a single entry in the slabs_partial list. This solution skips the allocation of 2 entries. So, while it seems to work locally, I suspect that I am overlooking something still. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Feb 14 10:51:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Feb 2003 10:52:02 -0800 (PST) Received: from ks406.kasserver.com (ks406.kasserver.com [62.141.48.110]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1EIpr3v032470 for ; Fri, 14 Feb 2003 10:51:54 -0800 Received: from anubis (A7b41.pppool.de [213.6.123.65]) by ks406.kasserver.com (8.11.6/8.11.6) with SMTP id h1EJ0D317856 for ; Fri, 14 Feb 2003 20:00:13 +0100 Message-ID: <001a01c2d45c$8e2f9d00$5a02640a@terragon.de> From: "Achim Altmann" To: "xfs mailinglist" Subject: Question about images need help? Date: Fri, 14 Feb 2003 20:09:10 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 2690 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: achim@altmann.li Precedence: bulk X-list: linux-xfs Content-Length: 525 Lines: 23 Hello now i try to install xfs on redhat 8.0 i have some some problems with this once is the kernel not ok, next is this the is the break the iso-rh-xfs-80-image when this like installed the kernel and so far Plese could any tell me which redhat 8.0 image is ok. for Boards with dual-amd and 3Ware ide-raid-system If is the DVD-iso that is now no problem i have now on DVD-brener but i can not test this image and then this Please could any help thank's a lot Best wishes Achim [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Fri Feb 14 11:55:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Feb 2003 11:55:14 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1EJt53v001010 for ; Fri, 14 Feb 2003 11:55:06 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 8274118FB83F; Fri, 14 Feb 2003 12:03:27 -0800 (PST) Date: Fri, 14 Feb 2003 12:03:27 -0800 From: Chris Wedgwood To: Aaron Macks Cc: linux-xfs@oss.sgi.com Subject: Re: data recovery from a single stripe Message-ID: <20030214200327.GA24944@f00f.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2691 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: 670 Lines: 23 On Fri, Feb 14, 2003 at 01:55:47AM -0500, Aaron Macks wrote: > Say I have 2 identical drives configured as a striped array, but > only with 1 stripe, i.e. a contiguous data stripe from one drive to > the next), and a single XFS partition on the pair. Concatenated? > If the first drive is lost, would the data on the second be > recoverable, say by backup superblocks? just trying to figure some > things out thanks Aaron Yes... the filesystem is a series of AGs, each with their own SB (a copy of the main SB). An AG contains enough information to recover the data for that AG although you will almost certainly loose directory names and/or structure. --cw From owner-linux-xfs@oss.sgi.com Fri Feb 14 12:02:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Feb 2003 12:02:42 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1EK2b3v001630 for ; Fri, 14 Feb 2003 12:02:37 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id CEE8318FB83F; Fri, 14 Feb 2003 12:10:59 -0800 (PST) Date: Fri, 14 Feb 2003 12:10:59 -0800 From: Chris Wedgwood To: linux-xfs@oss.sgi.com Subject: linux/fs/xfs/xfs_log.h:_lsn_cmp not declared __inline__ with gcc 2.95 Message-ID: <20030214201059.GA25006@f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2692 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: 835 Lines: 34 linux/fs/xfs/xfs_log.h seems to want to declare _lsn_cmp() only for GCC versions != 2.95. Why is this? It means with gcc-2.95 we get lots of copies of this function declared and never used. The following patch prevents this and seems to work perfect with 2.95... ===== fs/xfs/xfs_log.h 1.2 vs edited ===== --- 1.2/fs/xfs/xfs_log.h Mon Feb 3 10:19:33 2003 +++ edited/fs/xfs/xfs_log.h Fri Feb 14 00:18:21 2003 @@ -52,12 +52,7 @@ * By comparing each compnent, we don't have to worry about extra * endian issues in treating two 32 bit numbers as one 64 bit number */ -static -#ifdef __GNUC__ -# if !((__GNUC__ == 2) && (__GNUC_MINOR__ == 95)) -__inline__ -#endif -#endif +static __inline__ xfs_lsn_t _lsn_cmp(xfs_lsn_t lsn1, xfs_lsn_t lsn2, xfs_arch_t arch) { if (CYCLE_LSN(lsn1, arch) != CYCLE_LSN(lsn2, arch)) --cw From owner-linux-xfs@oss.sgi.com Fri Feb 14 12:09:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Feb 2003 12:10:03 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1EK9u3v004314 for ; Fri, 14 Feb 2003 12:09:58 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1EIIOG8001595 for ; Fri, 14 Feb 2003 10:18:24 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA79062; Fri, 14 Feb 2003 14:18:10 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA74363; Fri, 14 Feb 2003 14:18:12 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h1EKICp12461; Fri, 14 Feb 2003 14:18:12 -0600 Subject: Re: linux/fs/xfs/xfs_log.h:_lsn_cmp not declared __inline__ with gcc 2.95 From: Steve Lord To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030214201059.GA25006@f00f.org> References: <20030214201059.GA25006@f00f.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1045253892.463.1183.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 14 Feb 2003 14:18:12 -0600 X-archive-position: 2693 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2038 Lines: 69 On Fri, 2003-02-14 at 14:10, Chris Wedgwood wrote: > linux/fs/xfs/xfs_log.h seems to want to declare _lsn_cmp() only for > GCC versions != 2.95. > > Why is this? The way I remember it - 2.95 generated bad code here. We made a number of changes: date: 2001/02/13 00:33:03; author: cattelan; state: Exp; lines: +7 -1 modid: 2.4.x-xfs:slinx:87361a This removes the "inline" from the lsn_cmp function. This function appears to be incorrectly compiled by the gcc 2.95.x compiler. This does produce a warning messages when compiling with the 2.95 compiler fixing this would require code restructuring which would be incompatible with the irix source. Hopefully the compiler will be fixed in the future and the inline can be restored. date: 2001/04/18 16:19:03; author: lord; state: Exp; lines: +1 -1 modid: 2.4.x-xfs:slinx:92837a This particular compiler workaround appears to only be needed on one rev of gcc, make it go away for the others. date: 2002/05/24 14:37:11; author: lord; state: Exp; lines: +7 -7 modid: 2.4.x-xfs:slinx:120154a Fix lsn_cmp warnings with gcc 2.95 compiler Steve > > It means with gcc-2.95 we get lots of copies of this function declared > and never used. > > The following patch prevents this and seems to work perfect with > 2.95... > > > ===== fs/xfs/xfs_log.h 1.2 vs edited ===== > --- 1.2/fs/xfs/xfs_log.h Mon Feb 3 10:19:33 2003 > +++ edited/fs/xfs/xfs_log.h Fri Feb 14 00:18:21 2003 > @@ -52,12 +52,7 @@ > * By comparing each compnent, we don't have to worry about extra > * endian issues in treating two 32 bit numbers as one 64 bit number > */ > -static > -#ifdef __GNUC__ > -# if !((__GNUC__ == 2) && (__GNUC_MINOR__ == 95)) > -__inline__ > -#endif > -#endif > +static __inline__ > xfs_lsn_t _lsn_cmp(xfs_lsn_t lsn1, xfs_lsn_t lsn2, xfs_arch_t arch) > { > if (CYCLE_LSN(lsn1, arch) != CYCLE_LSN(lsn2, arch)) > > > > --cw -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Feb 14 12:18:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Feb 2003 12:19:00 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1EKHq3v004811 for ; Fri, 14 Feb 2003 12:18:27 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 112E818FB83F; Fri, 14 Feb 2003 12:26:15 -0800 (PST) Date: Fri, 14 Feb 2003 12:26:15 -0800 From: Chris Wedgwood To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: linux/fs/xfs/xfs_log.h:_lsn_cmp not declared __inline__ with gcc 2.95 Message-ID: <20030214202615.GB25088@f00f.org> References: <20030214201059.GA25006@f00f.org> <1045253892.463.1183.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1045253892.463.1183.camel@jen.americas.sgi.com> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2694 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: 394 Lines: 17 On Fri, Feb 14, 2003 at 02:18:12PM -0600, Steve Lord wrote: > The way I remember it - 2.95 generated bad code here. Which gcc-2.95? For me, it *seems* to work... if it's not working, what can I expect to see? Am I silently experincing corruption as I type this? :( > Hopefully the compiler will be fixed in the future and the inline > can be restored. Anyone else tested this? --cw From owner-linux-xfs@oss.sgi.com Fri Feb 14 12:21:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Feb 2003 12:21:39 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1EKKO3v004859 for ; Fri, 14 Feb 2003 12:21:05 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1EJZvKp017562 for ; Fri, 14 Feb 2003 11:35:57 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA00005; Fri, 14 Feb 2003 14:28:33 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA19780; Fri, 14 Feb 2003 14:28:33 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h1EKSXd12506; Fri, 14 Feb 2003 14:28:33 -0600 Subject: Re: linux/fs/xfs/xfs_log.h:_lsn_cmp not declared __inline__ with gcc 2.95 From: Steve Lord To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030214202615.GB25088@f00f.org> References: <20030214201059.GA25006@f00f.org> <1045253892.463.1183.camel@jen.americas.sgi.com> <20030214202615.GB25088@f00f.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1045254513.466.1185.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 14 Feb 2003 14:28:33 -0600 X-archive-position: 2695 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 857 Lines: 30 On Fri, 2003-02-14 at 14:26, Chris Wedgwood wrote: > On Fri, Feb 14, 2003 at 02:18:12PM -0600, Steve Lord wrote: > > > The way I remember it - 2.95 generated bad code here. > > Which gcc-2.95? Well, thats the problem, there is no way to divine more about the compiler than 2.95, so the code cannot tell. I think the problem came out as recovery failures, or maybe a cpu loop somewhere, I really cannot remember anymore. Steve > > For me, it *seems* to work... if it's not working, what can I expect > to see? Am I silently experincing corruption as I type this? :( > > > Hopefully the compiler will be fixed in the future and the inline > > can be restored. > > Anyone else tested this? > > > --cw -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Feb 14 13:30:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Feb 2003 13:30:51 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1ELUO3v022498 for ; Fri, 14 Feb 2003 13:30:24 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1ELm4kq019076 for ; Fri, 14 Feb 2003 15:48:04 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA15985 for ; Fri, 14 Feb 2003 15:38:40 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA04164 for ; Fri, 14 Feb 2003 15:38:41 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h1ELc0l08462; Fri, 14 Feb 2003 15:38:00 -0600 Message-Id: <200302142138.h1ELc0l08462@stout.americas.sgi.com> Date: Fri, 14 Feb 2003 15:38:00 -0600 Subject: TAKE - Remove unused init_spinlock #define X-archive-position: 2696 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 318 Lines: 13 Remove unused init_spinlock #define Date: Fri Feb 14 13:38:23 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:139854a linux/fs/xfs/support/spin.h - 1.10 From owner-linux-xfs@oss.sgi.com Fri Feb 14 14:17:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Feb 2003 14:17:27 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1EMHH3v023468 for ; Fri, 14 Feb 2003 14:17:17 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1EMYvkq020759 for ; Fri, 14 Feb 2003 16:34:57 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA40367 for ; Fri, 14 Feb 2003 16:25:33 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id QAA99874 for ; Fri, 14 Feb 2003 16:25:20 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h1EMPKo22498; Fri, 14 Feb 2003 16:25:20 -0600 Message-Id: <200302142225.h1EMPKo22498@jen.americas.sgi.com> Date: Fri, 14 Feb 2003 16:25:20 -0600 Subject: TAKE - improve xfs metadata hashing To: linux-xfs@oss.sgi.com X-archive-position: 2697 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 766 Lines: 25 Under heavy load, there are not enough hash buckets to deal with the number of metadata buffers. Use the same techniques as the regular linux buffer cache here. use more hash buckets for holding xfs metadata, and use the same hash algorithm as the regular buffer cache. Date: Fri Feb 14 14:23:40 PST 2003 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:139864a linux/fs/xfs/linux/xfs_super.c - 1.238 - initialize xfs_physmem before pagebuf linux/fs/xfs/pagebuf/page_buf.c - 1.94 - base the number of hash buckets for xfs metadata on the amount of memory in the system, and use the same hash algorithm as the regular buffer cache. From owner-linux-xfs@oss.sgi.com Fri Feb 14 14:34:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Feb 2003 14:34:49 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1EMYi3v024014 for ; Fri, 14 Feb 2003 14:34:45 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id E144A14621; Fri, 14 Feb 2003 23:43:01 +0100 (MET) Date: Fri, 14 Feb 2003 23:43:01 +0100 From: Andi Kleen To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - improve xfs metadata hashing Message-ID: <20030214224301.GA10746@wotan.suse.de> References: <200302142225.h1EMPKo22498@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200302142225.h1EMPKo22498@jen.americas.sgi.com> X-archive-position: 2698 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: ak@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 931 Lines: 27 > linux/fs/xfs/pagebuf/page_buf.c - 1.94 > - base the number of hash buckets for xfs metadata on the amount of > memory in the system, and use the same hash algorithm as the > regular buffer cache. Hi, I cannot review the change because it hasn't reached the public CVS server yet. But in general I would be very careful with existing hash functions in Linux. Lots of them are suffering from the "i don't use a prime modulo, but some cheap binary modulo" problem, causing bad hashing, which is normally papered around with making the cache size resizing overly aggressive, guaranteeing slow cache misses when the hash table is accessed. e.g. Buffer-cache hash table entries: 65536 (order: 6, 262144 bytes) That's far too big, definitely guaranteeing cache misses for most bucket accesses even on an Itanium 2 ;) Probably you're better off with a much smaller table and a better hash function using primes. -Andi From owner-linux-xfs@oss.sgi.com Fri Feb 14 14:40:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Feb 2003 14:41:01 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1EMew3v024466 for ; Fri, 14 Feb 2003 14:40:59 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1EKnQG8002496 for ; Fri, 14 Feb 2003 12:49:26 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA29025; Fri, 14 Feb 2003 16:49:14 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id QAA36027; Fri, 14 Feb 2003 16:49:15 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h1EMnFl04262; Fri, 14 Feb 2003 16:49:15 -0600 Subject: Re: TAKE - improve xfs metadata hashing From: Steve Lord To: Andi Kleen Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030214224301.GA10746@wotan.suse.de> References: <200302142225.h1EMPKo22498@jen.americas.sgi.com> <20030214224301.GA10746@wotan.suse.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1045262954.15864.18.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 14 Feb 2003 16:49:14 -0600 X-archive-position: 2699 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1527 Lines: 42 On Fri, 2003-02-14 at 16:43, Andi Kleen wrote: > > linux/fs/xfs/pagebuf/page_buf.c - 1.94 > > - base the number of hash buckets for xfs metadata on the amount of > > memory in the system, and use the same hash algorithm as the > > regular buffer cache. > > Hi, > > I cannot review the change because it hasn't reached the public > CVS server yet. But in general I would be very careful with existing > hash functions in Linux. Lots of them are suffering from the > "i don't use a prime modulo, but some cheap binary modulo" problem, > causing bad hashing, which is normally papered around with making the > cache size resizing overly aggressive, guaranteeing slow cache misses > when the hash table is accessed. > > e.g. > > Buffer-cache hash table entries: 65536 (order: 6, 262144 bytes) > > That's far too big, definitely guaranteeing cache misses for most > bucket accesses even on an Itanium 2 ;) > > Probably you're better off with a much smaller table and a better hash function > using primes. Well, this one was actually better than the existing one - as measured by a profiler while running spec. But yes, it definitely needs to be capped. I did put an upper ceiling on the size, probably still too aggressive though. As for hash algorithm, its the one from fs/buffer.c Thanks though. Steve p.s. there will be very little coverage from SGI next week. -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Feb 14 15:07:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Feb 2003 15:07:22 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1EN7E3v025067 for ; Fri, 14 Feb 2003 15:07:15 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 38F3614653; Sat, 15 Feb 2003 00:15:32 +0100 (MET) Date: Sat, 15 Feb 2003 00:15:28 +0100 From: Andi Kleen To: Steve Lord Cc: Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: TAKE - improve xfs metadata hashing Message-ID: <20030214231528.GA16411@wotan.suse.de> References: <200302142225.h1EMPKo22498@jen.americas.sgi.com> <20030214224301.GA10746@wotan.suse.de> <1045262954.15864.18.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1045262954.15864.18.camel@jen.americas.sgi.com> X-archive-position: 2700 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: ak@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 1640 Lines: 41 On Fri, Feb 14, 2003 at 04:49:14PM -0600, Steve Lord wrote: > On Fri, 2003-02-14 at 16:43, Andi Kleen wrote: > > > linux/fs/xfs/pagebuf/page_buf.c - 1.94 > > > - base the number of hash buckets for xfs metadata on the amount of > > > memory in the system, and use the same hash algorithm as the > > > regular buffer cache. > > > > Hi, > > > > I cannot review the change because it hasn't reached the public > > CVS server yet. But in general I would be very careful with existing > > hash functions in Linux. Lots of them are suffering from the > > "i don't use a prime modulo, but some cheap binary modulo" problem, > > causing bad hashing, which is normally papered around with making the > > cache size resizing overly aggressive, guaranteeing slow cache misses > > when the hash table is accessed. > > > > e.g. > > > > Buffer-cache hash table entries: 65536 (order: 6, 262144 bytes) > > > > That's far too big, definitely guaranteeing cache misses for most > > bucket accesses even on an Itanium 2 ;) > > > > Probably you're better off with a much smaller table and a better hash function > > using primes. > > Well, this one was actually better than the existing one - as measured > by a profiler while running spec. But yes, it definitely needs to be > capped. I did put an upper ceiling on the size, probably still too > aggressive though. As for hash algorithm, its the one from fs/buffer.c See http://www.citi.umich.edu/projects/linux-scalability/reports/hash.html for more details. It also gives some suggestions on how to improve it. I think Linux still uses the hash functions criticized in there. -Andi From owner-linux-xfs@oss.sgi.com Fri Feb 14 18:40:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Feb 2003 18:40:33 -0800 (PST) Received: from ks406.kasserver.com (ks406.kasserver.com [62.141.48.110]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1F2eS3v032329 for ; Fri, 14 Feb 2003 18:40:29 -0800 Received: from anubis (B0271.pppool.de [213.7.2.113]) by ks406.kasserver.com (8.11.6/8.11.6) with SMTP id h1F2mob12556 for ; Sat, 15 Feb 2003 03:48:50 +0100 Message-ID: <005401c2d49e$06b5e360$5a02640a@terragon.de> From: "Achim Altmann" To: "xfs mailinglist" Subject: kernel pan. no init ...? Date: Sat, 15 Feb 2003 03:57:49 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 2701 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: achim@altmann.li Precedence: bulk X-list: linux-xfs Content-Length: 1751 Lines: 58 Hello, now i gave installed new kernel with xfs--support and i have changed my old ext3-filesystem to XFS my old filesystem is now on /dev/sda9 (is only the backup but bootable ) and the new on the /dev/sda1-8 I use lilo and i have two bootoptions 1) boot /dev/sda2 (that is / ) ==> /boot is on /dev/sda1 2) boot /devb/sda9 (in sda9 is all / and /boot and all other mountpoints) The kernel and the init-file is in both /boot-directorys the same and this kernels are both supported XFS I can boot /dev/sda9 but this filesystem is ext3 but i can mount under that system all XFS-devices from /dev/sda1-8 If i boot /dev/sda2 then comes the following message VFS: Can't find ext3 filesystem on dev sd(8,2) mount error 22 mounting ext3 pivotroot: pivot_root(sysroot, sysroot/initrd) failed 2 umount unused kernel memory 124K freed kernel panic: No init found Try passing init= option to Kernel Sorry i don't understod this message I have set the runlevel All Files are the same like under /dev/sda9 /dev/sda9 was the file-system /dev/sda1-8 i have this installtion-form from linux-XFS-HOWTO "Migration" i have only edit the /etc/fstab and lilo.conf i have tested to install lilo from Booted /dev/sda9 ==> installing was ok. and i have boot (with an xfs-kernel) the rescue-system /dev/sda2 and under this rescue-system i have also installed lilo ==> was also ok.! Yes i would also like installed grub but grub makes problems he stay after boot on stage2 and the is finish Maybe he has problems with may raid-system (yes that is a crazy-idea) or i have problems with installing grub Please could any help I have now all tested, changed, installed sorry i don't see the problem reagards Achim [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Fri Feb 14 21:08:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Feb 2003 21:08:22 -0800 (PST) Received: from web12301.mail.yahoo.com (web12301.mail.yahoo.com [216.136.173.99]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1F58J3v001176 for ; Fri, 14 Feb 2003 21:08:19 -0800 Message-ID: <20030215051643.72993.qmail@web12301.mail.yahoo.com> Received: from [12.254.129.114] by web12301.mail.yahoo.com via HTTP; Fri, 14 Feb 2003 21:16:43 PST Date: Fri, 14 Feb 2003 21:16:43 -0800 (PST) From: Jason Corbett Subject: Problem installing SGI-RH 8.0 XFS customized cd To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 2702 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: jasoncorbett01@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 1546 Lines: 45 Hello, I looked on the mailing list and couldn't find anyone else reporting this, but if someone has please forgive me. I tried installing the RH 8.0 XFS installer with the cd on SGI site. Everything went fine untill it tried to install the kernel. It said it couldn't install the kernel rpm and this was a fatal error. The only option was to reboot. I verified the media, and everything checked out. Then I looked at the kernel rpms, ran a rpm --checksig and sha1 and md5 sums were ok on the kernel rpms. However I was installing on an athlon, and I didn't see any athlon rpms on the cd. I know that RH has athlon rpms on it's cd and that's what get's installed. Then I thought that maybe I should put the athlon rpms from the site in the directory with the other cd's. I tried cutting a new cd with those rpms in the directory, but the same thing happens. So is there some other file I should have altered? I don't know much about modifying the anaconda installer, but I would think it has some type of file somewhere where it lists all the rpms. I looked at comps.xml, but it just lists packages, not their architectures. Has anyone successfully installed this on an athlon, unfortunately I was going to try it on an intel machine, but didn't have time before I went home. My home machine is the similar to the one at work, and it fails also. Please help, Jason Corbett __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com From owner-linux-xfs@oss.sgi.com Sat Feb 15 07:09:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 15 Feb 2003 07:09:35 -0800 (PST) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1FF9O3v010630 for ; Sat, 15 Feb 2003 07:09:27 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1FFHjKp014641 for ; Sat, 15 Feb 2003 07:17:45 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA38626; Sat, 15 Feb 2003 09:17:44 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id JAA82361; Sat, 15 Feb 2003 09:17:44 -0600 (CST) Date: Sat, 15 Feb 2003 09:16:56 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Jason Corbett cc: linux-xfs@oss.sgi.com Subject: Re: Problem installing SGI-RH 8.0 XFS customized cd In-Reply-To: <20030215051643.72993.qmail@web12301.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2703 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 511 Lines: 18 On Fri, 14 Feb 2003, Jason Corbett wrote: > Hello, > > I looked on the mailing list and couldn't find > anyone else reporting this, but if someone has please > forgive me. > > I tried installing the RH 8.0 XFS installer with the > cd on SGI site. Everything went fine untill it tried > to install the kernel. It said it couldn't install > the kernel rpm and this was a fatal error. The only > option was to reboot. Do you have the text of the error? that would help us know what went wrong. -Eric From owner-linux-xfs@oss.sgi.com Sat Feb 15 08:25:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 15 Feb 2003 08:25:32 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1FGPO3v011472 for ; Sat, 15 Feb 2003 08:25:24 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1FGhAkq010327 for ; Sat, 15 Feb 2003 10:43:10 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA79151; Sat, 15 Feb 2003 10:33:44 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id KAA76932; Sat, 15 Feb 2003 10:33:44 -0600 (CST) Date: Sat, 15 Feb 2003 10:32:55 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Achim Altmann cc: linux-xfs@oss.sgi.com Subject: Re: Problem installing SGI-RH 8.0 XFS customized cd In-Reply-To: <00a401c2d50d$48f54580$5a02640a@terragon.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2704 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 526 Lines: 17 On Sat, 15 Feb 2003, Achim Altmann wrote: > hello, > i had the same problem, now on two different machines > i thought that was maybe my download corrupt but now i'm shure that image is > total buggy. Well, it's not totally buggy, but the athlon RPMs are missing from the iso. We can probably get this fixed sometime this week - we're out of the office this week, so things will go more slowly. I don't remember how the installer works, perhaps you can choose to install the x86 RPMs and then update them by hand? -Eric From owner-linux-xfs@oss.sgi.com Sat Feb 15 10:17:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 15 Feb 2003 10:17:33 -0800 (PST) Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1FIHQ3v012587 for ; Sat, 15 Feb 2003 10:17:27 -0800 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id h1FIPmIY010124; Sat, 15 Feb 2003 19:25:48 +0100 (CET) Message-Id: <4.3.2.7.2.20030215192415.03a259e8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 15 Feb 2003 19:25:43 +0100 To: Steve Lord , Chris Wedgwood From: Seth Mos Subject: Re: linux/fs/xfs/xfs_log.h:_lsn_cmp not declared __inline__ with gcc 2.95 Cc: linux-xfs@oss.sgi.com In-Reply-To: <1045254513.466.1185.camel@jen.americas.sgi.com> References: <20030214202615.GB25088@f00f.org> <20030214201059.GA25006@f00f.org> <1045253892.463.1183.camel@jen.americas.sgi.com> <20030214202615.GB25088@f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2705 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: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 723 Lines: 24 At 14:28 14-2-2003 -0600, Steve Lord wrote: >On Fri, 2003-02-14 at 14:26, Chris Wedgwood wrote: > > On Fri, Feb 14, 2003 at 02:18:12PM -0600, Steve Lord wrote: > > > > > The way I remember it - 2.95 generated bad code here. > > > > Which gcc-2.95? > >Well, thats the problem, there is no way to divine more about >the compiler than 2.95, so the code cannot tell. I think the >problem came out as recovery failures, or maybe a cpu loop >somewhere, I really cannot remember anymore. Zombie proccesses. Mainly loopdiloops. Process stuck in D state. A very early version of 2.96 also had this IIRC. 2.95.2 was the main crulpit. 2.95.3 and above are safe. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Sat Feb 15 10:29:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 15 Feb 2003 10:29:27 -0800 (PST) Received: from web12305.mail.yahoo.com (web12305.mail.yahoo.com [216.136.173.103]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1FITO3v013084 for ; Sat, 15 Feb 2003 10:29:24 -0800 Message-ID: <20030215183750.65818.qmail@web12305.mail.yahoo.com> Received: from [12.254.129.114] by web12305.mail.yahoo.com via HTTP; Sat, 15 Feb 2003 10:37:50 PST Date: Sat, 15 Feb 2003 10:37:50 -0800 (PST) From: Jason Corbett Subject: Re: Problem installing SGI-RH 8.0 XFS customized cd To: Eric Sandeen Cc: linux-xfs@oss.sgi.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 2706 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: jasoncorbett01@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 1317 Lines: 55 Sorry about not including it at first. Here you go: There was an error installing kernel-2.4.18-18SGI_XFS_1.2.0. This can indicate media failure, lack of disk space, and/or hardware problems. This is a fatal error and your install will be aborted. Please verify your media and try your install again. Press the OK button to reboot your system. That's it. I also looked at /mnt/sysimage/root/install.log for clues: Installing xfsdump-2.2.1-0. Installing kernel-2.4.18-18SGI_XFS_1.2.0. I did try verifying the media, and everything checked out. Jason Corbett --- Eric Sandeen wrote: > On Fri, 14 Feb 2003, Jason Corbett wrote: > > > Hello, > > > > I looked on the mailing list and couldn't find > > anyone else reporting this, but if someone has > please > > forgive me. > > > > I tried installing the RH 8.0 XFS installer with > the > > cd on SGI site. Everything went fine untill it > tried > > to install the kernel. It said it couldn't > install > > the kernel rpm and this was a fatal error. The > only > > option was to reboot. > > Do you have the text of the error? that would help > us know what went wrong. > > -Eric > __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com From owner-linux-xfs@oss.sgi.com Sat Feb 15 13:08:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 15 Feb 2003 13:08:34 -0800 (PST) Received: from hotmail.com (f92.law10.hotmail.com [64.4.15.92]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1FL8Q3v020948 for ; Sat, 15 Feb 2003 13:08:27 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 15 Feb 2003 13:16:48 -0800 Received: from 80.182.255.55 by lw10fd.law10.hotmail.msn.com with HTTP; Sat, 15 Feb 2003 21:16:48 GMT X-Originating-IP: [80.182.255.55] From: "Stefano Rossi" To: linux-xfs@oss.sgi.com Subject: spec file incorrect for xfsprogs-2.3.5-0.src.rpm (solved) Date: Sat, 15 Feb 2003 21:16:48 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Message-ID: X-OriginalArrivalTime: 15 Feb 2003 21:16:48.0685 (UTC) FILETIME=[8D17A5D0:01C2D537] X-archive-position: 2707 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: linux_rh@hotmail.com Precedence: bulk X-list: linux-xfs Content-Length: 638 Lines: 37 That's the reason for which the xfsprogs-2.3.5-0.src.rpm package doesn't rebuild on Red Hat 7.x. The spec file contain some incorrect paths they are: /usr/local/share ^^^^^ /usr/local/share/man ^^^^^ /usr/local/share/doc ^^^^^ It is necessary to change those paths in the spec file: /usr/share /usr/share/man /usr/share/doc and than give the command: rpm -ta xfsprog.spec That's all. PS: in xfsprogs-2.3.5-0.src.rpm shipped with pre5 the spec file was correct!! _________________________________________________________________ Vinci la nuova Nissan Micra con MSN Messenger! http://www.msn.it/messenger/ From owner-linux-xfs@oss.sgi.com Sat Feb 15 13:51:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 15 Feb 2003 13:51:33 -0800 (PST) Received: from web12303.mail.yahoo.com (web12303.mail.yahoo.com [216.136.173.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1FLpR3v021644 for ; Sat, 15 Feb 2003 13:51:27 -0800 Message-ID: <20030215215954.94883.qmail@web12303.mail.yahoo.com> Received: from [12.254.129.114] by web12303.mail.yahoo.com via HTTP; Sat, 15 Feb 2003 13:59:54 PST Date: Sat, 15 Feb 2003 13:59:54 -0800 (PST) From: Jason Corbett Subject: Re: Problem installing SGI-RH 8.0 XFS customized cd To: Eric Sandeen Cc: linux-xfs@oss.sgi.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 2708 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: jasoncorbett01@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 1165 Lines: 47 If anyone knows how to tell anaconda to use the i386 kernel, or if you know what files need to be modified, let me know, I can probably do it myself. Thanks for all the help. Jason Corbett --- Eric Sandeen wrote: > On Fri, 14 Feb 2003, Jason Corbett wrote: > > > Hello, > > > > I looked on the mailing list and couldn't find > > anyone else reporting this, but if someone has > please > > forgive me. > > > > I tried installing the RH 8.0 XFS installer with > the > > cd on SGI site. Everything went fine untill it > tried > > to install the kernel. It said it couldn't > install > > the kernel rpm and this was a fatal error. The > only > > option was to reboot. > > Do you have the text of the error? that would help > us know what went wrong. > > -Eric > ===== . _____ ___ / __/____/ / (_)__ __ ____ __ / /_/ __ / /__/ / _ \/ // /\ \/ / /_____//_/ /____/_/_//_/\_,_/ /_/\_\ ==== /_____/ =================================== Caldera OpenLinux __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com From owner-linux-xfs@oss.sgi.com Sun Feb 16 10:03:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 16 Feb 2003 10:03:43 -0800 (PST) Received: from rrzd2.rz.uni-regensburg.de (root@rrzd2.rz.uni-regensburg.de [132.199.1.12]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1GI3Z3v005007 for ; Sun, 16 Feb 2003 10:03:37 -0800 Received: from rrzd2 (root@rrzd2 [127.0.0.1]) by rrzd2.rz.uni-regensburg.de (8.12.3/8.12.3/Debian -4) with ESMTP id h1GIC5H8015654 for ; Sun, 16 Feb 2003 19:12:05 +0100 Received: from rss1.rz.uni-regensburg.de ([132.199.1.200]) by rrzd2 (MailMonitor for SMTP v1.2.1 ) ; Sun, 16 Feb 2003 19:12:02 +0100 (CET) Received: (qmail 8466 invoked from network); 16 Feb 2003 19:12:01 +0100 Received: from pc9391.physik.uni-regensburg.de (HELO pc9391) (guc28561@132.199.98.219) by rss1.rz.uni-regensburg.de with SMTP; 16 Feb 2003 19:12:01 +0100 Date: Sun, 16 Feb 2003 19:12:01 +0100 From: Christian Guggenberger To: linux-xfs@oss.sgi.com Subject: prcesses stuck in D state (lock_p) Message-ID: <20030216191201.A29247@pc9391.uni-regensburg.de> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Balsa 1.2.4 X-archive-position: 2709 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Christian.Guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Content-Length: 624 Lines: 19 Hi all, with recent cvs Kernels (namely with SGI XFS snapshot 2.4.20-2003-01-14_00:43_UTC with ACLs, quota, no debug enabled ) I see, after a week of heavy load, one or often more processes stuck in D state. All that processes are acessing nfs-mounts, such as : (Output of ps -efl) 000 D abc12345 921 1 0 69 0 - 404 lock_p Feb14 ? 00:00:00 md5sum -v -c sums I have also machines accessing the same nfs-share (running 2.4.19-xfs-cvs of October) with no problems at all. I don't want to blame xfs here directly, but I like to know if someone of you guys is seeing a similiar behavour... Thanks Christian From owner-linux-xfs@oss.sgi.com Sun Feb 16 14:50:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 16 Feb 2003 14:50:37 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1GMoY3v008378 for ; Sun, 16 Feb 2003 14:50:34 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h1GN8Skq022385 for ; Sun, 16 Feb 2003 17:08:29 -0600 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 JAA26329; Mon, 17 Feb 2003 09:57:42 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id JAA65005; Mon, 17 Feb 2003 09:57:41 +1100 (AEDT) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) with ESMTP id h1GMtrp4030822; Mon, 17 Feb 2003 09:55:53 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h1GMtqQI030813; Mon, 17 Feb 2003 09:55:52 +1100 Date: Mon, 17 Feb 2003 09:55:52 +1100 From: Nathan Scott To: Christian Guggenberger Cc: linux-xfs@oss.sgi.com Subject: Re: prcesses stuck in D state (lock_p) Message-ID: <20030216225552.GD9521@frodo> References: <20030216191201.A29247@pc9391.uni-regensburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030216191201.A29247@pc9391.uni-regensburg.de> User-Agent: Mutt/1.5.3i X-archive-position: 2710 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: 1035 Lines: 30 On Sun, Feb 16, 2003 at 07:12:01PM +0100, Christian Guggenberger wrote: > Hi all, > > with recent cvs Kernels (namely with > SGI XFS snapshot 2.4.20-2003-01-14_00:43_UTC with ACLs, quota, no debug > enabled ) > I see, after a week of heavy load, one or often more processes stuck in D > state. > All that processes are acessing nfs-mounts, such as : (Output of ps -efl) > > 000 D abc12345 921 1 0 69 0 - 404 lock_p Feb14 ? 00:00:00 > md5sum -v -c sums > > I have also machines accessing the same nfs-share (running 2.4.19-xfs-cvs > of October) with no problems at all. > I don't want to blame xfs here directly, but I like to know if someone of > you guys is seeing a similiar behavour... > I have been seeing a similar issue in a couple of the QA tests. I've traced my issue back to a recent regression on the XFS IO path - I expect to have a fix for that checked in later today; hopefully this will be the fix for the problem you're hitting as well (I'm not using NFS at all here though). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Feb 16 19:16:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 16 Feb 2003 19:16:31 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1H3GM3v010216 for ; Sun, 16 Feb 2003 19:16:23 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1H3YHkq027671 for ; Sun, 16 Feb 2003 21:34:19 -0600 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 h1H3NT3s8103830 for ; Mon, 17 Feb 2003 14:23:29 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h1H3NTgc8183784 for linux-xfs@oss.sgi.com; Mon, 17 Feb 2003 14:23:29 +1100 (EST) Date: Mon, 17 Feb 2003 14:23:29 +1100 (EST) From: Nathan Scott Message-Id: <200302170323.h1H3NTgc8183784@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - fix pagebuf compiler warning X-archive-position: 2711 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@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 299 Lines: 13 Fix compiler warning in call to free_pages. Date: Sun Feb 16 19:23:04 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:139913a linux/fs/xfs/pagebuf/page_buf.c - 1.95 From owner-linux-xfs@oss.sgi.com Sun Feb 16 19:26:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 16 Feb 2003 19:26:15 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1H3Q83v020348 for ; Sun, 16 Feb 2003 19:26:09 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1H3YYG8020790 for ; Sun, 16 Feb 2003 19:34:35 -0800 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 h1H3XI3s8237307 for ; Mon, 17 Feb 2003 14:33:18 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h1H3XIJQ8229580 for linux-xfs@oss.sgi.com; Mon, 17 Feb 2003 14:33:18 +1100 (EST) Date: Mon, 17 Feb 2003 14:33:18 +1100 (EST) From: Nathan Scott Message-Id: <200302170333.h1H3XIJQ8229580@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - fix writepage deadlock X-archive-position: 2712 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@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 395 Lines: 14 Fix buffer_head deadlock on the IO path on small blocksize filesystems. Fixes fsstress hangs on these, observed using QA test 013 and others. Date: Sun Feb 16 19:32:02 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:139914a linux/fs/xfs/linux/xfs_aops.c - 1.18 From owner-linux-xfs@oss.sgi.com Sun Feb 16 20:05:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 16 Feb 2003 20:05:24 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1H45D3v021188 for ; Sun, 16 Feb 2003 20:05:14 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1H4N9kq028614 for ; Sun, 16 Feb 2003 22:23:11 -0600 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 h1H4CC3s8246909 for ; Mon, 17 Feb 2003 15:12:22 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h1H4CB898243645 for linux-xfs@oss.sgi.com; Mon, 17 Feb 2003 15:12:11 +1100 (EST) Date: Mon, 17 Feb 2003 15:12:11 +1100 (EST) From: Nathan Scott Message-Id: <200302170412.h1H4CB898243645@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - minor xfsprogs updates X-archive-position: 2713 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@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 905 Lines: 37 Date: Thu Feb 13 15:23:31 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:139743a cmd/xfsprogs/man/man5/xfs.5 - 1.7 - fix a man page typo. Date: Sun Feb 16 20:11:09 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:139915a cmd/xfsprogs/VERSION - 1.65 cmd/xfsprogs/doc/CHANGES - 1.90 cmd/xfsprogs/debian/changelog - 1.58 - minor xfsprogs updates cmd/xfsprogs/mkfs/xfs_mkfs.c - 1.39 - fix a divide-by-zero error with some sunit/swidth values. cmd/xfsprogs/include/xfs_log.h - 1.12 cmd/xfsprogs/include/xfs_trans.h - 1.11 - sync with kernel changes, noop for userspace. cmd/xfsprogs/libxfs/xfs_dir_leaf.c - 1.12 - fix a memory leak. From owner-linux-xfs@oss.sgi.com Mon Feb 17 01:14:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Feb 2003 01:15:04 -0800 (PST) Received: from kerberos.suse.cz (kerberos.suse.cz [195.47.106.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1H9Es3v002768 for ; Mon, 17 Feb 2003 01:14:55 -0800 Received: from chimera.suse.cz (chimera.suse.cz [10.20.0.2]) by kerberos.suse.cz (SuSE SMTP server) with ESMTP id 8B63859D307; Mon, 17 Feb 2003 10:23:21 +0100 (CET) Received: from alienAngel.upjs.sk (test12.suse.cz [10.20.3.140]) by chimera.suse.cz (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h1H9NL432699; Mon, 17 Feb 2003 10:23:21 +0100 X-Authentication-Warning: chimera.suse.cz: Host test12.suse.cz [10.20.3.140] claimed to be alienAngel.upjs.sk Received: from localhost (ja@localhost) by alienAngel.upjs.sk (8.12.6/8.12.6/Submit) with ESMTP id h1H9N9IG006176; Mon, 17 Feb 2003 10:23:09 +0100 X-Authentication-Warning: alienAngel.home.sk: ja owned process doing -bs Date: Mon, 17 Feb 2003 10:23:09 +0100 (CET) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: Achim Altmann Cc: xfs mailinglist Subject: Re: kernel pan. no init ...? In-Reply-To: <005401c2d49e$06b5e360$5a02640a@terragon.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2714 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: 522 Lines: 19 On Sat, 15 Feb 2003, Achim Altmann wrote: Hi. > VFS: Can't find ext3 filesystem on dev sd(8,2) > mount error 22 mounting ext3 > pivotroot: pivot_root(sysroot, sysroot/initrd) failed 2 > umount unused kernel memory 124K freed > kernel panic: No init found Try passing init= option to Kernel Do you have xfs compiled in kernel or as module? Do you have changed filesystem type in /etc/fstab? jan -- I like work, it fascinates me. I can sit and look at it for hours. Jerome Klapka Jerome (Three men in a boat) From owner-linux-xfs@oss.sgi.com Mon Feb 17 01:33:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Feb 2003 01:33:25 -0800 (PST) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1H9XF3v003326 for ; Mon, 17 Feb 2003 01:33:16 -0800 Received: from auto-nb1.xs4all.nl (host-4.coltex.demon.nl [212.238.252.68]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id h1H9fgNl034321; Mon, 17 Feb 2003 10:41:42 +0100 (CET) Message-Id: <4.3.2.7.2.20030217104001.03229b90@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Feb 2003 10:41:31 +0100 To: "Achim Altmann" , "xfs mailinglist" From: Seth Mos Subject: Re: kernel pan. no init ...? In-Reply-To: <005401c2d49e$06b5e360$5a02640a@terragon.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2715 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: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 1061 Lines: 35 At 03:57 15-2-2003 +0100, Achim Altmann wrote: >Hello, > >now i gave installed new kernel with xfs--support and i have changed my >old ext3-filesystem to XFS > >my old filesystem is now on /dev/sda9 (is only the backup but bootable ) >and the new on the /dev/sda1-8 > >I use lilo and i have two bootoptions > >1) boot /dev/sda2 (that is / ) ==> /boot is on /dev/sda1 > >2) boot /devb/sda9 (in sda9 is all / and /boot and all other mountpoints) > >The kernel and the init-file is in both /boot-directorys the same and this >kernels are both supported XFS > >I can boot /dev/sda9 but this filesystem is ext3 but i can mount under >that system all XFS-devices from /dev/sda1-8 > >If i boot /dev/sda2 then comes the following message You can not install the bootloader in a xfs partition. Lilo or grub will overwrite sector 0 which is where the XFS superblock lives. You can install the bootloader either in the mbr or on a partition which does not contain a XFS filesystem (like swap). Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Mon Feb 17 01:51:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Feb 2003 01:51:50 -0800 (PST) Received: from ente.berdmann.de (frnk-d514e12f.dsl.mediaWays.net [213.20.225.47]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1H9pk3v003914 for ; Mon, 17 Feb 2003 01:51:47 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=localhost) by ente.berdmann.de with esmtp (Exim 3.35 #1) id 18ki4L-0006tA-00; Mon, 17 Feb 2003 11:00:13 +0100 Received: from 192.168.1.1 ( [192.168.1.1]) as user be@ente.berdmann.de by apollo.berdmann.de with HTTP; Mon, 17 Feb 2003 11:00:13 +0100 Message-ID: <1045476013.3e50b2ad5749b@apollo.berdmann.de> Date: Mon, 17 Feb 2003 11:00:13 +0100 From: Bernhard Erdmann To: Jason Corbett Cc: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: Problem installing SGI-RH 8.0 XFS customized cd References: <20030215183750.65818.qmail@web12305.mail.yahoo.com> In-Reply-To: <20030215183750.65818.qmail@web12305.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 192.168.1.1 X-archive-position: 2716 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: be@berdmann.de Precedence: bulk X-list: linux-xfs Content-Length: 747 Lines: 28 Zitat von Jason Corbett : > Sorry about not including it at first. Here you go: > > There was an error installing > kernel-2.4.18-18SGI_XFS_1.2.0. This can > indicate media failure, lack of disk > space, and/or hardware problems. This is > a fatal error and your install will be > aborted. Please verify your media and try > your install again. Hi, the same error happens to me when doing an HTTP install. The Apache logs indicate the RPM being delivered correctly and of the same size as on the SGI XFS 1.2 CD: 172.30.26.69 - - [17/Feb/2003:10:50:28 +0100] "GET /redhat/8.0/i386/RedHat/RPMS/ kernel-2.4.18-18SGI_XFS_1.2.0.i686.rpm HTTP/1.0" 200 14228158 "- " "Python-urllib /1.15" CPU was a Celeron 466. From owner-linux-xfs@oss.sgi.com Mon Feb 17 04:14:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Feb 2003 04:14:28 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1HCEL3v008529 for ; Mon, 17 Feb 2003 04:14:21 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1HCELlS008528 for linux-xfs@oss.sgi.com; Mon, 17 Feb 2003 04:14:21 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1HCEJ3x008514 for ; Mon, 17 Feb 2003 04:14:20 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1HBpVPi007585; Mon, 17 Feb 2003 03:51:31 -0800 Date: Mon, 17 Feb 2003 03:51:31 -0800 Message-Id: <200302171151.h1HBpVPi007585@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 222] New: file truncation after fsync() and following reset. X-Bugzilla-Reason: AssignedTo X-archive-position: 2717 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1959 Lines: 56 http://oss.sgi.com/bugzilla/show_bug.cgi?id=222 Summary: file truncation after fsync() and following reset. Product: Linux XFS Version: 1.2.x Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: razuwaev@relex.ru CC: razuwaev@relex.ru Description of Problem: Under x86 linux 2.4.18 (kernel from www.kernel.org) with XFS 1.2 (http://oss.sgi.com/projects/xfs/patchlist.html) found bug: after fsync() and following reset file may be spontaneously truncated. How Reproduce: 1. open some files for RW (1-5 files). 2. seek to the EOF 3. write whole block 4Kb. 4. seek to the middle of the file at offset n*4096 (n is any positive integer). 5. write whole block 4Kb. 6. #2-#5 repeates some times (usually 10-20 times). 7. fsync() for all files. 8. get size of the all files (for compare with next results). 8. From another process makes reboot -f -n (reboot w/o sync and w/o shutdown process). This step simulates RESET action. Actual Results: Sometimes after reset one or more files has size lesser then after fsync (may be lost 1-4 blocks). I.e. loses last added blocks. Updates in the middle blocks of the file _never_ lose. Expected Results: All files must have the same sizes as before reset the system. Additional Information: XFS configured w/o real-time section and with log on the same device as data section. Mount string (in /etc/mtab) is:/dev/hda6 /mnt/xfs xfs rw 0 0 I tried understand difference fsync after writes to the EOF and to the middle of the file. Seems fsync after write to the EOF causes the pagebuf_write_full_page(). fsync after write to the middle of the file causes ll_rw_block(). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Feb 17 05:39:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Feb 2003 05:39:16 -0800 (PST) Received: from ahriman.bucharest.roedu.net (ahriman.bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1HDd53v011775 for ; Mon, 17 Feb 2003 05:39:07 -0800 Received: (qmail 10438 invoked by uid 1000); 17 Feb 2003 14:08:45 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 17 Feb 2003 14:08:45 -0000 Date: Mon, 17 Feb 2003 16:08:45 +0200 (EET) From: Mihai RUSU X-X-Sender: To: Linux XFS List Subject: converting XFS log v1 -> v2 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2718 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: dizzy@roedu.net Precedence: bulk X-list: linux-xfs Content-Length: 384 Lines: 14 Hi I have a running XFS filesystem with external log v1. I would like to convert it to v2 using the current 1.2 release. Is that possible ? How? Thanks ---------------------------- Mihai RUSU Disclaimer: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of any company, unless otherwise specifically stated. From owner-linux-xfs@oss.sgi.com Mon Feb 17 06:48:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Feb 2003 06:48:51 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1HEmi3v013624 for ; Mon, 17 Feb 2003 06:48:45 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1HEvDKp014401 for ; Mon, 17 Feb 2003 06:57:13 -0800 Received: from tulip-e236.americas.sgi.com (tulip-e236.americas.sgi.com [128.162.236.208]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA34611; Mon, 17 Feb 2003 08:57:12 -0600 (CST) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-63.corp.sgi.com [134.15.64.63]) by tulip-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id IAA70742; Mon, 17 Feb 2003 08:57:11 -0600 (CST) Subject: Re: TAKE - improve xfs metadata hashing From: Stephen Lord To: Steve Lord Cc: Andi Kleen , linux-xfs@oss.sgi.com In-Reply-To: <1045262954.15864.18.camel@jen.americas.sgi.com> References: <200302142225.h1EMPKo22498@jen.americas.sgi.com> <20030214224301.GA10746@wotan.suse.de> <1045262954.15864.18.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 17 Feb 2003 08:56:06 -0600 Message-Id: <1045493768.1369.31.camel@localhost.localdomain> Mime-Version: 1.0 X-archive-position: 2719 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 361 Lines: 15 On Fri, 2003-02-14 at 16:49, Steve Lord wrote: ... It turns out there is a bug in this code, and it will trash your filesystem. Fix coming shortly, if you are following cvs, please make sure you update again before using the filesystem. Nothing wrong with the hash code, just when you have more than 256 buckets, it does not fit in a char anymore. Steve From owner-linux-xfs@oss.sgi.com Mon Feb 17 06:53:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Feb 2003 06:53:11 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1HEr93v014539 for ; Mon, 17 Feb 2003 06:53:09 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1HF1cKp014794 for ; Mon, 17 Feb 2003 07:01:38 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA47875 for ; Mon, 17 Feb 2003 09:01:38 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA36233 for ; Mon, 17 Feb 2003 09:01:37 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h1HF1bC32095; Mon, 17 Feb 2003 09:01:37 -0600 Message-Id: <200302171501.h1HF1bC32095@jen.americas.sgi.com> Date: Mon, 17 Feb 2003 09:01:37 -0600 Subject: TAKE - fix stupid bug in hashing change To: linux-xfs@oss.sgi.com X-archive-position: 2720 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 510 Lines: 19 fix the new hashing code, cap buckets more aggressively, and expand pb_hash_index to fit the new hash range. CVS was broken on Friday, this fixes it. Date: Mon Feb 17 07:00:26 PST 2003 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:139926a linux/fs/xfs/pagebuf/page_buf.c - 1.96 - cap hash buckets at 2K linux/fs/xfs/pagebuf/page_buf.h - 1.56 - make pb_hash_index and unsigned char From owner-linux-xfs@oss.sgi.com Mon Feb 17 07:44:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Feb 2003 07:44:31 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1HFiM3v018068 for ; Mon, 17 Feb 2003 07:44:22 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1HFiMtB018067 for linux-xfs@oss.sgi.com; Mon, 17 Feb 2003 07:44:22 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1HFiK3x018053 for ; Mon, 17 Feb 2003 07:44:20 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1HFcIhd018007; Mon, 17 Feb 2003 07:38:18 -0800 Date: Mon, 17 Feb 2003 07:38:18 -0800 Message-Id: <200302171538.h1HFcIhd018007@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 222] file truncation after fsync() and following reset. X-Bugzilla-Reason: AssignedTo X-archive-position: 2721 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 628 Lines: 22 http://oss.sgi.com/bugzilla/show_bug.cgi?id=222 cattelan@thebarn.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From cattelan@thebarn.com 2003-02-17 07:38 ------- Please include the script/program used. Also if possible try the code in the cvs tree. Some changes were reciently made to the write/release page logic. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Feb 17 08:24:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Feb 2003 08:24:36 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1HGOT3v020813 for ; Mon, 17 Feb 2003 08:24:29 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1HGWwKp023085 for ; Mon, 17 Feb 2003 08:32:58 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA61744; Mon, 17 Feb 2003 10:32:57 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id KAA04799; Mon, 17 Feb 2003 10:32:57 -0600 (CST) Date: Mon, 17 Feb 2003 10:31:50 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Mihai RUSU cc: Linux XFS List Subject: Re: converting XFS log v1 -> v2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2722 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 857 Lines: 28 There is an "xfs_chver" script under Irix that uses xfs_db to do some conversions like this - I was working on making it work with v2 logs at one point, but I did not get it to a releaseable state. It involved setting flags in the "version" field of the superblock and setting the logsunit field as well. I'll have to bug Steve and Glen to remember if there are any pitfalls to this method. -Eric On Mon, 17 Feb 2003, Mihai RUSU wrote: > Hi > > I have a running XFS filesystem with external log v1. I would like to > convert it to v2 using the current 1.2 release. Is that possible ? How? > > Thanks > > ---------------------------- > Mihai RUSU > > Disclaimer: Any views or opinions presented within this e-mail are solely > those of the author and do not necessarily represent those of any company, > unless otherwise specifically stated. > > From owner-linux-xfs@oss.sgi.com Mon Feb 17 08:59:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Feb 2003 08:59:59 -0800 (PST) Received: from ahriman.bucharest.roedu.net (ahriman.bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1HGxq3v021912 for ; Mon, 17 Feb 2003 08:59:53 -0800 Received: (qmail 26928 invoked by uid 1000); 17 Feb 2003 17:29:34 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 17 Feb 2003 17:29:34 -0000 Date: Mon, 17 Feb 2003 19:29:34 +0200 (EET) From: Mihai RUSU X-X-Sender: To: Eric Sandeen cc: Linux XFS List Subject: Re: converting XFS log v1 -> v2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2723 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: dizzy@roedu.net Precedence: bulk X-list: linux-xfs Content-Length: 984 Lines: 27 On Mon, 17 Feb 2003, Eric Sandeen wrote: > There is an "xfs_chver" script under Irix that uses xfs_db to do some > conversions like this - I was working on making it work with v2 > logs at one point, but I did not get it to a releaseable state. > > It involved setting flags in the "version" field of the superblock > and setting the logsunit field as well. I'll have to bug Steve and > Glen to remember if there are any pitfalls to this method. > > -Eric > Hmm, Im wondering, xfs_repair -L doesnt actually rebuild a complete log ? I mean what info from the log does it use ? Like if it uses only the version field and the UUID, we can "convert" the log by setting only the version field and then xfs_repair -L on it to make the rest. Just a hint :) ---------------------------- Mihai RUSU Disclaimer: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of any company, unless otherwise specifically stated. From owner-linux-xfs@oss.sgi.com Mon Feb 17 09:02:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Feb 2003 09:02:39 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1HH2Z3v022339 for ; Mon, 17 Feb 2003 09:02:36 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 98358186B12E; Mon, 17 Feb 2003 09:11:10 -0800 (PST) Date: Mon, 17 Feb 2003 09:11:10 -0800 From: Chris Wedgwood To: Mihai RUSU Cc: Eric Sandeen , Linux XFS List Subject: Re: converting XFS log v1 -> v2 Message-ID: <20030217171110.GA5436@f00f.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2724 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: 479 Lines: 23 On Mon, Feb 17, 2003 at 07:29:34PM +0200, Mihai RUSU wrote: > Hmm, Im wondering, xfs_repair -L doesnt actually rebuild a complete > log ? -L zeros the log > I mean what info from the log does it use? Like if it uses only the > version field and the UUID, we can "convert" the log by setting only > the version field and then xfs_repair -L on it to make the rest. I wondered this myself... umount frob bits to make v2 xfs_repair -L mount does it work? --cw From owner-linux-xfs@oss.sgi.com Mon Feb 17 09:58:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Feb 2003 09:58:05 -0800 (PST) Received: from ubergeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1HHw13v023274 for ; Mon, 17 Feb 2003 09:58:01 -0800 Received: (qmail 5133 invoked by uid 500); 17 Feb 2003 18:04:03 -0000 Subject: Kernel BUG at ll_rw_blk.c:1194 From: Austin Gonyou To: XFS List Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1045505043.4835.12.camel@UberGeek> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 17 Feb 2003 12:04:03 -0600 X-archive-position: 2725 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: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Content-Length: 3733 Lines: 107 This happened when a filesystem got full and was still trying to be written to by Oracle. This is 2.4.20 + snapshot-xfs-2.4.20-2002-12-18+rl2+rmap15b Here's the oops.. ------------------- kernel BUG at ll_rw_blk.c:1194! invalid operand: 0000 CPU: 0 EIP: 0010:[] Not tainted EFLAGS: 00010206 eax: 00000410 ebx: 00000008 ecx: cc17c680 edx: cc17c680 esi: 00000001 edi: 00000002 ebp: 00000007 esp: c8869f0c ds: 0018 es: 0018 ss: 0018 Process kswapd (pid: 11, stackpage=c8869000) Stack: cc17c680 00000001 c014404d 00000001 cc17c680 00000100 ffffffff c1017c90 000001d0 c02f2760 cc17c680 cc17c680 c1017c90 c014418b cc17c680 00000001 00000000 c1017c90 c014221f c02f2760 c1017c90 000001d0 c02f2760 c0134b85 Call Trace: [] [] [] [] [] [] [] [] [] [] Code: 0f 0b aa 04 fa 60 2c c0 b8 03 00 00 00 f0 0f ab 42 18 b8 08 Ksymoops output below. ------------------- ksymoops 2.4.1 on i686 2.4.20-ag3. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.20-ag3/ (default) -m /boot/System.map-2.4.20-ag3 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Reading Oops report from the terminal kernel BUG at ll_rw_blk.c:1194! invalid operand: 0000 CPU: 0 EIP: 0010:[] Not tainted EFLAGS: 00010206 eax: 00000410 ebx: 00000008 ecx: cc17c680 edx: cc17c680 esi: 00000001 edi: 00000002 ebp: 00000007 esp: c8869f0c ds: 0018 es: 0018 ss: 0018 Process kswapd (pid: 11, stackpage=c8869000) Stack: cc17c680 00000001 c014404d 00000001 cc17c680 00000100 ffffffff c1017c90 000001d0 c02f2760 cc17c680 cc17c680 c1017c90 c014418b cc17c680 00000001 00000000 c1017c90 c014221f c02f2760 c1017c90 000001d0 c02f2760 c0134b85 Call Trace: [] [] [] [] [] [] [] [] [] [] Code: 0f 0b aa 04 fa 60 2c c0 b8 03 00 00 00 f0 0f ab 42 18 b8 08kernel BUG at ll_rw_blk.c:1194! invalid operand: 0000 EFLAGS: 00010206 eax: 00000410 ebx: 00000008 ecx: cc17c680 edx: cc17c680 esi: 00000001 edi: 00000002 ebp: 00000007 esp: c8869f0c ds: 0018 es: 0018 ss: 0018 Process kswapd (pid: 11, stackpage=c8869000) Stack: cc17c680 00000001 c014404d 00000001 cc17c680 00000100 ffffffff c1017c90 Code: 0f 0b aa 04 fa 60 2c c0 b8 03 00 00 00 f0 0f ab 42 18 b8 08 Using defaults from ksymoops -t elf32-i386 -a i386 Code; 00000000 Before first symbol 00000000 <_EIP>: Code; 00000000 Before first symbol 0: 0f 0b ud2a Code; 00000002 Before first symbol 2: aa stos %al,%es:(%edi) Code; 00000003 Before first symbol 3: 04 fa add $0xfa,%al Code; 00000005 Before first symbol 5: 60 pusha Code; 00000006 Before first symbol 6: 2c c0 sub $0xc0,%al Code; 00000008 Before first symbol 8: b8 03 00 00 00 mov $0x3,%eax Code; 0000000d Before first symbol d: f0 0f ab 42 18 lock bts %eax,0x18(%edx) Code; 00000012 Before first symbol 12: b8 08 00 00 00 mov $0x8,%eax -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Mon Feb 17 10:40:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Feb 2003 10:40:29 -0800 (PST) Received: from rrzd2.rz.uni-regensburg.de (root@rrzd2.rz.uni-regensburg.de [132.199.1.12]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1HIeJ3v024085 for ; Mon, 17 Feb 2003 10:40:21 -0800 Received: from rrzd2 (root@rrzd2 [127.0.0.1]) by rrzd2.rz.uni-regensburg.de (8.12.3/8.12.3/Debian -4) with ESMTP id h1HImrMF032256 for ; Mon, 17 Feb 2003 19:48:53 +0100 Received: from rss1.rz.uni-regensburg.de ([132.199.1.200]) by rrzd2 (MailMonitor for SMTP v1.2.1 ) ; Mon, 17 Feb 2003 19:48:52 +0100 (CET) Received: (qmail 9670 invoked from network); 17 Feb 2003 19:48:52 +0100 Received: from pc9391.physik.uni-regensburg.de (HELO pc9391) (guc28561@132.199.98.219) by rss1.rz.uni-regensburg.de with SMTP; 17 Feb 2003 19:48:52 +0100 Date: Mon, 17 Feb 2003 19:48:52 +0100 From: Christian Guggenberger To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: prcesses stuck in D state (lock_p) Message-ID: <20030217194852.C31771@pc9391.uni-regensburg.de> References: <20030216191201.A29247@pc9391.uni-regensburg.de> <20030216225552.GD9521@frodo> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <20030216225552.GD9521@frodo>; from nathans@sgi.com on Sun, Feb 16, 2003 at 23:55:52 +0100 X-Mailer: Balsa 1.2.4 X-archive-position: 2726 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Christian.Guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Content-Length: 1299 Lines: 32 On 16.02.2003 23:55 Nathan Scott wrote: > On Sun, Feb 16, 2003 at 07:12:01PM +0100, Christian Guggenberger wrote: > > Hi all, > > > > with recent cvs Kernels (namely with > > SGI XFS snapshot 2.4.20-2003-01-14_00:43_UTC with ACLs, quota, no debug > > enabled ) > > I see, after a week of heavy load, one or often more processes stuck in D > > state. > > All that processes are acessing nfs-mounts, such as : (Output of ps -efl) > > > > 000 D abc12345 921 1 0 69 0 - 404 lock_p Feb14 ? 00:00:00 > > md5sum -v -c sums > > > > I have also machines accessing the same nfs-share (running 2.4.19-xfs-cvs > > of October) with no problems at all. > > I don't want to blame xfs here directly, but I like to know if someone of > > you guys is seeing a similiar behavour... > > > > I have been seeing a similar issue in a couple of the QA tests. > I've traced my issue back to a recent regression on the XFS IO > path - I expect to have a fix for that checked in later today; > hopefully this will be the fix for the problem you're hitting > as well (I'm not using NFS at all here though). > well, actually I really don't know how to reproduce this bug I'm hitting. I'll try to hit it on another machine with the same kernel running. Maybe I'll find some more info this week! thx Christian From owner-linux-xfs@oss.sgi.com Mon Feb 17 12:14:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Feb 2003 12:14:18 -0800 (PST) Received: from K-7.stesmi.com (as4-1-7.has.s.bonet.se [217.215.31.238]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1HKEB3v025828 for ; Mon, 17 Feb 2003 12:14:13 -0800 Received: from stesmi.com (as4-1-7.has.s.bonet.se [217.215.31.238]) by K-7.stesmi.com (8.12.5/8.12.5) with ESMTP id h1HKMoVb003316 for ; Mon, 17 Feb 2003 21:22:51 +0100 Message-ID: <3E51449A.5000502@stesmi.com> Date: Mon, 17 Feb 2003 21:22:50 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: A few questions regarding XFS 1.2 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (K-7.stesmi.com) X-archive-position: 2727 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: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 409 Lines: 12 Can someone please inform me about something.. The installer ISO contains acl-2.0.19, acl-devel-2.0.19 and libacl-2.0.19 whereas the RPMS directory on the ftp site contains acl-2.0.19, libacl-2.0.19 and libacl-devel-2.0.19. Why? Also, The attr package version is 2.0.11-0 in the installer image but 2.0.12-0 on the ftp site. Again, why? Same name issue exists (attr-devel vs libattr-devel). // Stefan From owner-linux-xfs@oss.sgi.com Mon Feb 17 12:41:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Feb 2003 12:41:58 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1HKfs3v027352 for ; Mon, 17 Feb 2003 12:41:55 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 94446186B12E; Mon, 17 Feb 2003 12:50:30 -0800 (PST) Date: Mon, 17 Feb 2003 12:50:30 -0800 From: Chris Wedgwood To: Stefan Smietanowski Cc: linux-xfs@oss.sgi.com Subject: Re: A few questions regarding XFS 1.2 Message-ID: <20030217205030.GA6294@f00f.org> References: <3E51449A.5000502@stesmi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E51449A.5000502@stesmi.com> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2728 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: 379 Lines: 12 On Mon, Feb 17, 2003 at 09:22:50PM +0100, Stefan Smietanowski wrote: > The installer ISO contains acl-2.0.19, acl-devel-2.0.19 and > libacl-2.0.19 whereas the RPMS directory on the ftp site contains > acl-2.0.19, libacl-2.0.19 and libacl-devel-2.0.19. Why? The SGI people have abundant time on their hands but wish to deprive you of the latest code in the installer. --cw From owner-linux-xfs@oss.sgi.com Mon Feb 17 12:47:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Feb 2003 12:48:03 -0800 (PST) Received: from K-7.stesmi.com (as4-1-7.has.s.bonet.se [217.215.31.238]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1HKlu3v027809 for ; Mon, 17 Feb 2003 12:47:57 -0800 Received: from stesmi.com (as4-1-7.has.s.bonet.se [217.215.31.238]) by K-7.stesmi.com (8.12.5/8.12.5) with ESMTP id h1HKuZVb003739; Mon, 17 Feb 2003 21:56:35 +0100 Message-ID: <3E514C83.6020706@stesmi.com> Date: Mon, 17 Feb 2003 21:56:35 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Wedgwood CC: linux-xfs@oss.sgi.com Subject: Re: A few questions regarding XFS 1.2 References: <3E51449A.5000502@stesmi.com> <20030217205030.GA6294@f00f.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (K-7.stesmi.com) X-archive-position: 2729 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: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 681 Lines: 31 Chris Wedgwood wrote: > On Mon, Feb 17, 2003 at 09:22:50PM +0100, Stefan Smietanowski wrote: > > >>The installer ISO contains acl-2.0.19, acl-devel-2.0.19 and >>libacl-2.0.19 whereas the RPMS directory on the ftp site contains >>acl-2.0.19, libacl-2.0.19 and libacl-devel-2.0.19. Why? > > > The SGI people have abundant time on their hands but wish to deprive > you of the latest code in the installer. Excellent quoting. If you really mean to quote this part.. look at the filenames. acl-2.0.19 acl-devel-2.0.19 libacl-2.0.19 vs acl-2.0.19 libacl-2.0.19 libacl-devel-2.0.19 Has absolutely nothing to do with versions. The lower part of my mail did however. // Stefan From owner-linux-xfs@oss.sgi.com Mon Feb 17 12:50:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Feb 2003 12:50:44 -0800 (PST) Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1HKof3v029088 for ; Mon, 17 Feb 2003 12:50:42 -0800 Received: from [10.0.0.10] (c-24-245-56-70.mn.client2.attbi.com [24.245.56.70]) by lips.thebarn.com (8.12.6/8.12.6) with ESMTP id h1HKxGcX091729; Mon, 17 Feb 2003 14:59:16 -0600 (CST) (envelope-from cattelan@thebarn.com) Subject: Re: A few questions regarding XFS 1.2 From: Russell Cattelan To: Stefan Smietanowski Cc: linux-xfs@oss.sgi.com In-Reply-To: <3E51449A.5000502@stesmi.com> References: <3E51449A.5000502@stesmi.com> Content-Type: text/plain Organization: Message-Id: <1045515555.98641.15.camel@lupo.thebarn.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 17 Feb 2003 14:59:16 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 2730 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: 723 Lines: 20 On Mon, 2003-02-17 at 14:22, Stefan Smietanowski wrote: > Can someone please inform me about something.. > > The installer ISO contains acl-2.0.19, acl-devel-2.0.19 and > libacl-2.0.19 whereas the RPMS directory on the ftp site contains > acl-2.0.19, libacl-2.0.19 and libacl-devel-2.0.19. Why? > > Also, The attr package version is 2.0.11-0 in the installer image but > 2.0.12-0 on the ftp site. Again, why? Same name issue exists (attr-devel > vs libattr-devel). > > // Stefan The re-spin of the installer was done in about an hour. I probably missed updating my build scripts with the new names/versions. If I find some time I'll look at fixing that but no promises. -- Russell Cattelan From owner-linux-xfs@oss.sgi.com Mon Feb 17 12:55:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Feb 2003 12:55:57 -0800 (PST) Received: from K-7.stesmi.com (as4-1-7.has.s.bonet.se [217.215.31.238]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1HKto3v000917 for ; Mon, 17 Feb 2003 12:55:51 -0800 Received: from stesmi.com (as4-1-7.has.s.bonet.se [217.215.31.238]) by K-7.stesmi.com (8.12.5/8.12.5) with ESMTP id h1HL4WVb003907; Mon, 17 Feb 2003 22:04:32 +0100 Message-ID: <3E514E60.4050501@stesmi.com> Date: Mon, 17 Feb 2003 22:04:32 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Russell Cattelan CC: linux-xfs@oss.sgi.com Subject: Re: A few questions regarding XFS 1.2 References: <3E51449A.5000502@stesmi.com> <1045515555.98641.15.camel@lupo.thebarn.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (K-7.stesmi.com) X-archive-position: 2731 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: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 850 Lines: 26 Russell Cattelan wrote: > On Mon, 2003-02-17 at 14:22, Stefan Smietanowski wrote: > >>Can someone please inform me about something.. >> >>The installer ISO contains acl-2.0.19, acl-devel-2.0.19 and >>libacl-2.0.19 whereas the RPMS directory on the ftp site contains >>acl-2.0.19, libacl-2.0.19 and libacl-devel-2.0.19. Why? >> >>Also, The attr package version is 2.0.11-0 in the installer image but >>2.0.12-0 on the ftp site. Again, why? Same name issue exists (attr-devel >>vs libattr-devel). >> >>// Stefan > > The re-spin of the installer was done in about an hour. > I probably missed updating my build scripts with the > new names/versions. > If I find some time I'll look at fixing that but no promises. > Thanx. Why I asked was that maybe it was done on purpose for some reason. I'm just finalizing my DVD based on 1.2.. // Stefan From owner-linux-xfs@oss.sgi.com Mon Feb 17 12:58:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Feb 2003 12:58:03 -0800 (PST) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1HKvx3v010880 for ; Mon, 17 Feb 2003 12:58:00 -0800 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id h1HL6XFS049547; Mon, 17 Feb 2003 22:06:33 +0100 (CET) Message-Id: <4.3.2.7.2.20030217220303.03419008@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Feb 2003 22:06:19 +0100 To: Stefan Smietanowski , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: A few questions regarding XFS 1.2 In-Reply-To: <3E51449A.5000502@stesmi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2732 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: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 909 Lines: 27 At 21:22 17-2-2003 +0100, Stefan Smietanowski wrote: >Can someone please inform me about something.. > >The installer ISO contains acl-2.0.19, acl-devel-2.0.19 and libacl-2.0.19 >whereas the RPMS directory on the ftp site contains acl-2.0.19, >libacl-2.0.19 and libacl-devel-2.0.19. Why? > >Also, The attr package version is 2.0.11-0 in the installer image but >2.0.12-0 on the ftp site. Again, why? Same name issue exists (attr-devel >vs libattr-devel). I believe that the names of the packages were changed on purpose to make them align with the names of the acl packages that have merged from the acl project. Apart from the naming they are identical. There have been a few months in between the first 1.2pre1 and the 1.2 release. I can't think of anything else right now. Maybe searching the archives will turn something up. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Mon Feb 17 13:24:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Feb 2003 13:24:52 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1HLOl3v013314 for ; Mon, 17 Feb 2003 13:24:48 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 877AA186B12E; Mon, 17 Feb 2003 13:33:23 -0800 (PST) Date: Mon, 17 Feb 2003 13:33:23 -0800 From: Chris Wedgwood To: Seth Mos Cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: linux/fs/xfs/xfs_log.h:_lsn_cmp not declared __inline__ with gcc 2.95 Message-ID: <20030217213323.GA6541@f00f.org> References: <20030214202615.GB25088@f00f.org> <20030214201059.GA25006@f00f.org> <1045253892.463.1183.camel@jen.americas.sgi.com> <20030214202615.GB25088@f00f.org> <4.3.2.7.2.20030215192415.03a259e8@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20030215192415.03a259e8@pop.xs4all.nl> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2733 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: 1112 Lines: 38 On Sat, Feb 15, 2003 at 07:25:43PM +0100, Seth Mos wrote: > Zombie proccesses. Mainly loopdiloops. Process stuck in D state. A > very early version of 2.96 also had this IIRC. 2.95.2 was the main > crulpit. 2.95.3 and above are safe. I did manage to get problems with 2.95.4 but they are different to what you describe (processed stuck in IO wait, but would come unstuck if I remounted RO underneath them). Perhaps we can have a comment in the source as to *why* the __inline__ is omitted for certain gcc versions, perhaps something like: diff -u -r1.64 xfs_log.h --- xfs_log.h 13 Feb 2003 17:41:15 -0000 1.64 +++ xfs_log.h 17 Feb 2003 21:24:05 -0000 @@ -53,8 +53,11 @@ * endian issues in treating two 32 bit numbers as one 64 bit number */ static +/* Some versions of gcc (2.95.x for example) will miscompile if + * this is declared __inline__, later versions of gcc (3.2+) appear to + * work correctly. */ #ifdef __GNUC__ -# if !((__GNUC__ == 2) && (__GNUC_MINOR__ == 95)) +#if !((__GNUC__ == 2) && ((__GNUC_MINOR__ == 95) || __GNUC_MINOR__ == 96)) __inline__ #endif #endif Thanks, --cw From owner-linux-xfs@oss.sgi.com Mon Feb 17 14:03:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Feb 2003 14:03:33 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1HM3R3v004708 for ; Mon, 17 Feb 2003 14:03:28 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1HMBvKp022142 for ; Mon, 17 Feb 2003 14:11:58 -0800 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 h1HMAe3s8454173 for ; Tue, 18 Feb 2003 09:10:40 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h1HMAd0s8434931 for linux-xfs@oss.sgi.com; Tue, 18 Feb 2003 09:10:39 +1100 (EST) Date: Tue, 18 Feb 2003 09:10:39 +1100 (EST) From: Nathan Scott Message-Id: <200302172210.h1HMAd0s8434931@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsprogs X-archive-position: 2734 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@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 453 Lines: 17 Add a missing build dependency for building Debian packages (thanks to Ryan Murray for reporting this). Date: Mon Feb 17 14:06:05 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:139931a cmd/xfsprogs/VERSION - 1.66 cmd/xfsprogs/doc/CHANGES - 1.91 cmd/xfsprogs/debian/control - 1.12 cmd/xfsprogs/debian/changelog - 1.59 From owner-linux-xfs@oss.sgi.com Mon Feb 17 14:41:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Feb 2003 14:41:35 -0800 (PST) Received: from mail.osdl.org (air-2.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1HMfR3v006210; Mon, 17 Feb 2003 14:41:28 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id h1HMnvw04624; Mon, 17 Feb 2003 14:49:57 -0800 Subject: [PATCH] Fix warnings for XFS on 2.5.61 From: Stephen Hemminger To: owner-xfs@oss.sgi.com Cc: Linux Kernel Mailing List , linux-xfs@oss.sgi.com Content-Type: text/plain Organization: Open Source Devlopment Lab Message-Id: <1045522194.12947.92.camel@dell_ss3.pdx.osdl.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 17 Feb 2003 14:49:57 -0800 Content-Transfer-Encoding: 7bit X-archive-position: 2735 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: shemminger@osdl.org Precedence: bulk X-list: linux-xfs Content-Length: 675 Lines: 20 This patch gets rid of the following warnings. fs/xfs/support/qsort.c: In function `qsort': fs/xfs/support/qsort.c:202: warning: duplicate `const' diff -Nru a/fs/xfs/support/qsort.c b/fs/xfs/support/qsort.c --- a/fs/xfs/support/qsort.c Mon Feb 17 14:16:15 2003 +++ b/fs/xfs/support/qsort.c Mon Feb 17 14:16:15 2003 @@ -199,7 +199,7 @@ { char *const end_ptr = &base_ptr[size * (total_elems - 1)]; char *tmp_ptr = base_ptr; - char *thresh = min(end_ptr, base_ptr + max_thresh); + char *const thresh = min_t(char *const, end_ptr, base_ptr + max_thresh); register char *run_ptr; /* Find smallest element in first threshold and place it at the From owner-linux-xfs@oss.sgi.com Mon Feb 17 15:51:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Feb 2003 15:51:31 -0800 (PST) Received: from ente.berdmann.de (frnk-d514e12f.dsl.mediaWays.net [213.20.225.47]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1HNpJ3v007251 for ; Mon, 17 Feb 2003 15:51:21 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.35 #1) id 18kvAp-0008Am-00; Tue, 18 Feb 2003 00:59:47 +0100 Message-ID: <3E517773.2010700@berdmann.de> Date: Tue, 18 Feb 2003 00:59:47 +0100 From: Bernhard Erdmann User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Mihai RUSU CC: Linux XFS List Subject: Re: converting XFS log v1 -> v2 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2736 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: be@berdmann.de Precedence: bulk X-list: linux-xfs Content-Length: 275 Lines: 17 Mihai RUSU wrote: > Hi > > I have a running XFS filesystem with external log v1. I would like to > convert it to v2 using the current 1.2 release. Is that possible ? How? Hi, I don't know your circumstances, but I'd probably do xfsdump umount mkfs.xfs mount xfsrestore From owner-linux-xfs@oss.sgi.com Mon Feb 17 16:36:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Feb 2003 16:36:35 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1I0aV3v007919 for ; Mon, 17 Feb 2003 16:36:31 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 7A2B3186B12E; Mon, 17 Feb 2003 16:45:07 -0800 (PST) Date: Mon, 17 Feb 2003 16:45:07 -0800 From: Chris Wedgwood To: Mihai RUSU Cc: Linux XFS List Subject: Re: converting XFS log v1 -> v2 Message-ID: <20030218004507.GA7549@f00f.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2737 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: 503 Lines: 22 On Mon, Feb 17, 2003 at 04:08:45PM +0200, Mihai RUSU wrote: > I have a running XFS filesystem with external log v1. I would like > to convert it to v2 using the current 1.2 release. Is that possible? > How? I just tested this with an *internal* log. But it *might* work for you all the same... (in fact, an external log is probably a better way to do this perhaps?) umount the fs xfs_db -x /dev/blem --- fiddle versionnum xfs_repair -L mount Backup data, etc. first though :) --cw From owner-linux-xfs@oss.sgi.com Mon Feb 17 16:49:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Feb 2003 16:49:40 -0800 (PST) Received: from phoenix.infradead.org (phoenix.mvhi.com [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1I0na3v008388; Mon, 17 Feb 2003 16:49:38 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18kw5L-0000ye-00; Tue, 18 Feb 2003 00:58:11 +0000 Date: Tue, 18 Feb 2003 00:58:11 +0000 From: Christoph Hellwig To: Stephen Hemminger Cc: owner-xfs@oss.sgi.com, Linux Kernel Mailing List , linux-xfs@oss.sgi.com Subject: Re: [PATCH] Fix warnings for XFS on 2.5.61 Message-ID: <20030218005811.A3709@infradead.org> Mail-Followup-To: Christoph Hellwig , Stephen Hemminger , owner-xfs@oss.sgi.com, Linux Kernel Mailing List , linux-xfs@oss.sgi.com References: <1045522194.12947.92.camel@dell_ss3.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1045522194.12947.92.camel@dell_ss3.pdx.osdl.net>; from shemminger@osdl.org on Mon, Feb 17, 2003 at 02:49:57PM -0800 X-archive-position: 2738 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 294 Lines: 8 On Mon, Feb 17, 2003 at 02:49:57PM -0800, Stephen Hemminger wrote: > This patch gets rid of the following warnings. > > fs/xfs/support/qsort.c: In function `qsort': > fs/xfs/support/qsort.c:202: warning: duplicate `const' This is a bug in recent gcc versions, submit a patch to gcc instead. From owner-linux-xfs@oss.sgi.com Mon Feb 17 18:00:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Feb 2003 18:01:06 -0800 (PST) Received: from hotmail.com (bay1-f55.bay1.hotmail.com [65.54.245.55]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1I20w3v009198 for ; Mon, 17 Feb 2003 18:00:59 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 17 Feb 2003 18:09:30 -0800 Received: from 12.236.29.248 by by1fd.bay1.hotmail.msn.com with HTTP; Tue, 18 Feb 2003 02:09:29 GMT X-Originating-IP: [12.236.29.248] From: "John Haverty" To: linux-xfs@oss.sgi.com Subject: Please pay attention to RedHat 7.x, other stable linux kernels (2.4) please ;p Date: Mon, 17 Feb 2003 18:09:29 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 18 Feb 2003 02:09:30.0151 (UTC) FILETIME=[C55E3370:01C2D6F2] X-archive-position: 2739 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: zeio@hotmail.com Precedence: bulk X-list: linux-xfs Content-Length: 634 Lines: 16 Thanks for the release of 1.2 and all your work, but I would like to request that because of RedHat 8's near un-useable broken state, that 1.2-release patches be made for the 7.x kernel series which is conveniently unified. RedHat 8 is a desktop candy coated OS and XFS is a serious filesystem for serious users and big iron machines. Also, I feel that FreeBSD is more than deserving of at least an experimental port of XFS. Good Luck - John Haverty _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From owner-linux-xfs@oss.sgi.com Mon Feb 17 18:48:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Feb 2003 18:48:07 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1I2m03v010219 for ; Mon, 17 Feb 2003 18:48:01 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1I2uWG8002687 for ; Mon, 17 Feb 2003 18:56:32 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id UAA62820; Mon, 17 Feb 2003 20:56:30 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id UAA80676; Mon, 17 Feb 2003 20:56:31 -0600 (CST) Date: Mon, 17 Feb 2003 20:55:20 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: John Haverty cc: linux-xfs@oss.sgi.com Subject: Re: Please pay attention to RedHat 7.x, other stable linux kernels (2.4) please ;p In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2740 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1589 Lines: 36 On Mon, 17 Feb 2003, John Haverty wrote: > Thanks for the release of 1.2 and all your work, but I would like to request > that because of RedHat 8's near un-useable broken state, that 1.2-release > patches be made for the 7.x kernel series which is conveniently unified. If we had pointed our limited resources towards Red Hat 7.3, we would be reading a similar plea for 8.0 support this evening. :) There are two problems here; we cannot support every Red Hat (or other vendor) release, and Red Hat has chosen not to support XFS at all. Our choice in the past has been to support the most recent Red Hat kernel, if possible, because we know that we do have a lot of Red Hat users. I imagine that a backport to a Red Hat 7.3 kernel would not be too bad, perhaps if you or someone in the Linux community can do this, it would be well received. Encouraging Red Hat to support XFS would also be a good thing. > RedHat 8 is a desktop candy coated OS and XFS is a serious filesystem for > serious users and big iron machines. Also, I feel that FreeBSD is more than > deserving of at least an experimental port of XFS. There are some licensing issues here, and also some time == money issues. SGI is highly unlikely to release XFS under a BSD license, because our competitors could quickly integrate it into their products. Even a GPL'd stand-alone product for BSD is unlikely to be produced by SGI, because frankly there is not much incentive to spend the time doing this. SGI has Linux products, but not BSD. Those are my opinions, not an official SGI stance, btw. :) -Eric From owner-linux-xfs@oss.sgi.com Mon Feb 17 21:20:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Feb 2003 21:20:35 -0800 (PST) Received: from imsmq10.netvigator.com (imsmq10.netvigator.com [218.102.48.123]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1I5KQ3v012257 for ; Mon, 17 Feb 2003 21:20:28 -0800 Received: (qmail 26049 invoked from network); 18 Feb 2003 05:28:58 -0000 Received: from pcd270142.netvigator.com (HELO grifdale) (203.218.60.142) by imsmq10.netvigator.com with SMTP; 18 Feb 2003 05:28:58 -0000 Received: from snowman by grifdale with local (Exim 3.36 #1 (Debian)) id 18l0JN-0004J1-00; Tue, 18 Feb 2003 13:28:57 +0800 To: John Haverty Subject: Re: Please pay attention to RedHat 7.x, other stable linux kernels(2.4) please ;p From: Frank Chung Cc: linux-xfs@oss.sgi.com In-reply-to: Message-Id: Date: Tue, 18 Feb 2003 13:28:57 +0800 X-archive-position: 2741 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: chungf@myrealbox.com Precedence: bulk X-list: linux-xfs Content-Length: 464 Lines: 15 On Mon, 17 Feb 2003, John Haverty wrote: > Also, I feel that FreeBSD is more than deserving of at least an > experimental port of XFS. If you want asynchronous I/O with protection from filesystem corruption in FreeBSD, try Soft Updates [1]. If you'd like to try a journalling filesystem, somebody's porting JFS to FreeBSD [2]. [1] http://www.defcon1.org/html/Software_Articles/Soft-Updates/soft-updates.html [2] http://jfs4bsd.sourceforge.net/ Regards, Frank From owner-linux-xfs@oss.sgi.com Tue Feb 18 00:09:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Feb 2003 00:09:16 -0800 (PST) Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1I8983v018112 for ; Tue, 18 Feb 2003 00:09:09 -0800 Received: from auto-nb1.xs4all.nl (host-4.coltex.demon.nl [212.238.252.68]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id h1I8HgXq090456; Tue, 18 Feb 2003 09:17:42 +0100 (CET) Message-Id: <4.3.2.7.2.20030218091120.04996ef0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 18 Feb 2003 09:17:24 +0100 To: Eric Sandeen , John Haverty From: Seth Mos Subject: Re: Please pay attention to RedHat 7.x, other stable linux kernels (2.4) please ;p Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2742 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: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 1123 Lines: 32 At 20:55 17-2-2003 -0600, Eric Sandeen wrote: >On Mon, 17 Feb 2003, John Haverty wrote: > >I imagine that a backport to a Red Hat 7.3 kernel would not be too bad, >perhaps if you or someone in the Linux community can do this, it would >be well received. The kernels from my site are built under Red Hat 7.1 and also reflect the latest errata kernel. They are based on the 2.4.18-24 errata from Red Hat and also include the XFS 1.2pre5 patches. Although the name still says pre5 it is ofcourse the 1.2 code. http://iserv.nl/files/xfs/2.4.18-24/ So if you need the Red Hat 7.x variant this would be your best bet. I am rebuilding this kernel with the proper 1.2 name on a Red Hat 7.3 box at the moment. But this could take a while (half a day). There might also be a new errata kernel coming soon which *should* fix numerous network problems related to gigabit ethernet. Keep in mind however that the last 4 errata release from Red Hat which should have fixed this still have not solved the problem to date. There was -17, -18, -19 and now -24. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Tue Feb 18 00:19:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Feb 2003 00:19:25 -0800 (PST) Received: from phoenix.infradead.org (phoenix.mvhi.com [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1I8JI3v018630 for ; Tue, 18 Feb 2003 00:19:19 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18l36Y-0002Mb-00; Tue, 18 Feb 2003 08:27:54 +0000 Date: Tue, 18 Feb 2003 08:27:54 +0000 From: Christoph Hellwig To: John Haverty Cc: linux-xfs@oss.sgi.com Subject: Re: Please pay attention to RedHat 7.x, other stable linux kernels (2.4) please ;p Message-ID: <20030218082754.A8994@infradead.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from zeio@hotmail.com on Mon, Feb 17, 2003 at 06:09:29PM -0800 X-archive-position: 2743 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 940 Lines: 18 On Mon, Feb 17, 2003 at 06:09:29PM -0800, John Haverty wrote: > Thanks for the release of 1.2 and all your work, but I would like to request > that because of RedHat 8's near un-useable broken state, that 1.2-release > patches be made for the 7.x kernel series which is conveniently unified. Given your detailed analysis of different Red Hat versions you might have noticed that the 7.x and 8.0 errata kernels differ only the version string and the conmpiler usded for building.. > RedHat 8 is a desktop candy coated OS and XFS is a serious filesystem for > serious users and big iron machines. Also, I feel that FreeBSD is more than > deserving of at least an experimental port of XFS. The XFS code is freely available - port it to FreeBSD if you think it's wort the effort. I doubt my employer (SGI) is interested in wasting it's time for something like that (note that this is not an official statement, just an educated guess) From owner-linux-xfs@oss.sgi.com Tue Feb 18 01:49:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Feb 2003 01:49:34 -0800 (PST) Received: from hotmail.com (bay1-f184.bay1.hotmail.com [65.54.245.184]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1I9nQ3v020395 for ; Tue, 18 Feb 2003 01:49:26 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 18 Feb 2003 01:57:59 -0800 Received: from 12.236.29.248 by by1fd.bay1.hotmail.msn.com with HTTP; Tue, 18 Feb 2003 09:57:58 GMT X-Originating-IP: [12.236.29.248] From: "John Haverty" To: linux-xfs@oss.sgi.com Subject: Re: Please pay attention to RedHat 7.x, other stable linux kernels (2.4) please ;p Date: Tue, 18 Feb 2003 01:57:58 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 18 Feb 2003 09:57:59.0111 (UTC) FILETIME=[379D1D70:01C2D734] X-archive-position: 2744 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: zeio@hotmail.com Precedence: bulk X-list: linux-xfs Content-Length: 2417 Lines: 48 Christoph Hellwig wrote: >Given your detailed analysis of different Red Hat versions you might >have noticed that the 7.x and 8.0 errata kernels differ only the >version string and the conmpiler usded for building.. I was referring to broken c libraries and broken compilers, and a strange fetish by the vendor to up versions of things that should be upped conservatively and never revving some important things. I have run into a few applications, including 'our own' that do not run properly on RedHat 8. >The XFS code is freely available - port it to FreeBSD if you think it's >worth the effort. I doubt my employer (SGI) is interested in wasting it's >time for something like that >(note that this is not an official statement, >just an educated guess) FreeBSD, waste of time? Hardly. FreeBSD is, for example, the basis for JunOS, a military grade piece of iron that runs the best routers on earth, so I hardly think of FreeBSD as a waste. Plus, FreeBSD is a meritocracy, well documented, coherent. One who works for a real unix vendor, such as SGI->Irix, should have an appreciation of FreeBSD. It's fine wine in the sour world of Linux. ;p I think I'll pay attention to Seth Moss' efforts @ http://iserv.nl/files/xfs/2.4.18-24/ It looks to be just what I need. I hope he continues with the effort. It's much appreciated. I also think it's sad that RedHat hasn't chosen excellence for its customers. XFS is the best filesystem for Linux, and they keep pushing other inferior alternatives. Thanks for working against them on this :) I would also like to point out that RedHat 8 is officially a desktop OS, and the vendor, who I deal with (and am seeking alternatives to because of this) is basically telling me, a paying customer this: You will no longer be able to get free "server" renditions of RedHat. You have to buy Advanced Server. Also note that Advanced Server has no publicly available RPMS in binary form. It's all very frustrating and needless to say I am an upset RedHat user and hearken back to the days of really die hard support for RedHat. (RedHat 7.0 and below "die" in March this year, and 7.1-7.3 die in December.) Thanks again anyone working on XFS for Linux, its great ;p _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus From owner-linux-xfs@oss.sgi.com Tue Feb 18 04:47:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Feb 2003 04:47:11 -0800 (PST) Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1ICl23v026346 for ; Tue, 18 Feb 2003 04:47:03 -0800 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.6/8.11.6) with ESMTP id h1ICtdl14322; Tue, 18 Feb 2003 07:55:39 -0500 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Tue, 18 Feb 2003 07:55:39 -0500 (EST) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: John Haverty cc: linux-xfs@oss.sgi.com Subject: Re: Please pay attention to RedHat 7.x, other stable linux kernels (2.4) please ;p In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2745 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jlb17@duke.edu Precedence: bulk X-list: linux-xfs Content-Length: 1329 Lines: 31 On Tue, 18 Feb 2003 at 1:57am, John Haverty wrote > Christoph Hellwig wrote: > > >The XFS code is freely available - port it to FreeBSD if you think it's > >worth the effort. I doubt my employer (SGI) is interested in wasting it's > >time for something like that > >(note that this is not an official statement, > >just an educated guess) > > FreeBSD, waste of time? Hardly. FreeBSD is, for example, the basis for > JunOS, a military grade piece of iron that runs the best routers on earth, > so I hardly think of FreeBSD as a waste. Plus, FreeBSD is a meritocracy, > well documented, coherent. One who works for a real unix vendor, such as > SGI->Irix, should have an appreciation of FreeBSD. It's fine wine in the > sour world of Linux. ;p I think you misunderstand the original sentiment. SGI would probably consider it a waste of their time (= money) to port XFS to an OS in which they have no financial interest. They have products based on Linux, and thus XFS on Linux can make them money. XFS on FreeBSD won't, thus no port. They *are* a profit seeking company, after all. Regarding your initial question, it's easy enough to rpmbuild the official 1.2 SRPMs on a 7.x box. That's what I'm doing here. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Tue Feb 18 05:40:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Feb 2003 05:40:07 -0800 (PST) Received: from rrzd2.rz.uni-regensburg.de (root@rrzd2.rz.uni-regensburg.de [132.199.1.12]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1IDe23v001466 for ; Tue, 18 Feb 2003 05:40:03 -0800 Received: from rrzd2 (root@rrzd2 [127.0.0.1]) by rrzd2.rz.uni-regensburg.de (8.12.3/8.12.3/Debian -4) with ESMTP id h1IDmdeG012862 for ; Tue, 18 Feb 2003 14:48:39 +0100 Received: from rss1.rz.uni-regensburg.de ([132.199.1.200]) by rrzd2 (MailMonitor for SMTP v1.2.1 ) ; Tue, 18 Feb 2003 14:48:38 +0100 (CET) Received: (qmail 535 invoked from network); 18 Feb 2003 14:48:38 +0100 Received: from pc9391.physik.uni-regensburg.de (HELO pc9391) (guc28561@132.199.98.219) by rss1.rz.uni-regensburg.de with SMTP; 18 Feb 2003 14:48:38 +0100 Date: Tue, 18 Feb 2003 14:48:37 +0100 From: Christian Guggenberger To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - fix writepage deadlock Message-ID: <20030218144837.A988@pc9391.uni-regensburg.de> References: <200302170333.h1H3XIJQ8229580@snort.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <200302170333.h1H3XIJQ8229580@snort.melbourne.sgi.com>; from nathans@snort.melbourne.sgi.com on Mon, Feb 17, 2003 at 04:33:18 +0100 X-Mailer: Balsa 1.2.4 X-archive-position: 2746 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Christian.Guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Content-Length: 539 Lines: 14 On 17.02.2003 04:33 Nathan Scott wrote: > Fix buffer_head deadlock on the IO path on small blocksize filesystems. > Fixes fsstress hangs on these, observed using QA test 013 and others. > Hi Nathan, your fix seems to work for me. I've been able to reproduce (with January patches) these Stuck D processes when md5summing a 1GB+ File over NFS, while the NFS Server(XFS 1.2-pre1)is under heavy load (about 10). Latest cvs on client cide seems to do fine for me, but I will do some further tests and see what'll happen... Christian From owner-linux-xfs@oss.sgi.com Tue Feb 18 05:54:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Feb 2003 05:54:31 -0800 (PST) Received: from kauri.itee.uq.edu.au (kauri.itee.uq.edu.au [130.102.66.24]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1IDsR3v002111 for ; Tue, 18 Feb 2003 05:54:28 -0800 Received: from luma.itee.uq.edu.au (luma.itee.uq.edu.au [130.102.66.14]) by kauri.itee.uq.edu.au (8.12.6/8.12.6) with ESMTP id h1IE2wmP019706; Wed, 19 Feb 2003 00:02:58 +1000 (EST) Received: from mango.itee.uq.edu.au (chrisp@mango.itee.uq.edu.au [130.102.66.4]) by luma.itee.uq.edu.au (8.12.6/8.12.6) with ESMTP id h1IE2wDe027308; Wed, 19 Feb 2003 00:02:58 +1000 (EST) Date: Wed, 19 Feb 2003 00:02:58 +1000 (EST) From: Chris Pascoe To: Chris Wedgwood cc: linux-xfs@oss.sgi.com Subject: Re: linux/fs/xfs/xfs_log.h:_lsn_cmp not declared __inline__ with gcc 2.95 In-Reply-To: <20030217213323.GA6541@f00f.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checked: This message probably not SPAM X-Spam-Score: -1 X-Spam-Tests: DATE_IN_PAST_06_12,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01,USER_AGENT_PINE X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-archive-position: 2747 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: c.pascoe@itee.uq.edu.au Precedence: bulk X-list: linux-xfs Content-Length: 713 Lines: 19 > > Zombie proccesses. Mainly loopdiloops. Process stuck in D state. A > > very early version of 2.96 also had this IIRC. 2.95.2 was the main > > crulpit. 2.95.3 and above are safe. > > I did manage to get problems with 2.95.4 but they are different to > what you describe (processed stuck in IO wait, but would come unstuck > if I remounted RO underneath them). That sounds like the behaviour that was initially seen that prompted the fix. I don't think that 2.95.3/4 were safe when I tested back then, contrary to Seth's experiences. See http://marc.theaimsgroup.com/?l=linux-xfs&m=99535721111774&w=2 for a description as to what the compiler's doing wrong and why it had to be un-inlined. Regards, Chris From owner-linux-xfs@oss.sgi.com Tue Feb 18 07:20:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Feb 2003 07:20:43 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1IFKW3v003593 for ; Tue, 18 Feb 2003 07:20:32 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1IFKV3D003589 for linux-xfs@oss.sgi.com; Tue, 18 Feb 2003 07:20:31 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1IFKT43003549 for ; Tue, 18 Feb 2003 07:20:29 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1IFH7wA003498; Tue, 18 Feb 2003 07:17:07 -0800 Date: Tue, 18 Feb 2003 07:17:07 -0800 Message-Id: <200302181517.h1IFH7wA003498@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 222] file truncation after fsync() and following reset. X-Bugzilla-Reason: AssignedTo X-archive-position: 2749 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 585 Lines: 22 http://oss.sgi.com/bugzilla/show_bug.cgi?id=222 ------- Additional Comments From razuwaev@relex.ru 2003-02-18 07:17 ------- Created an attachment (id=62) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=62&action=view) test for reproduce the situation. Part 1/3 I tried developer branch (2.4.20+XFS). Situation is the same as on 2.4.18 + XFS 1.2. I composed test for reproduce the situation. Please uncompress the archive. Readme says what need to do. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Feb 18 07:20:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Feb 2003 07:20:41 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1IFKW3v003594 for ; Tue, 18 Feb 2003 07:20:32 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1IFKW5H003591 for linux-xfs@oss.sgi.com; Tue, 18 Feb 2003 07:20:32 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1IFKT47003549 for ; Tue, 18 Feb 2003 07:20:30 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1IFIWtD003519; Tue, 18 Feb 2003 07:18:32 -0800 Date: Tue, 18 Feb 2003 07:18:32 -0800 Message-Id: <200302181518.h1IFIWtD003519@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 222] file truncation after fsync() and following reset. X-Bugzilla-Reason: AssignedTo X-archive-position: 2748 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 393 Lines: 17 http://oss.sgi.com/bugzilla/show_bug.cgi?id=222 ------- Additional Comments From razuwaev@relex.ru 2003-02-18 07:18 ------- Created an attachment (id=64) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=64&action=view) test for reproduce the situation. Part 3/3 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Feb 18 07:20:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Feb 2003 07:20:52 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1IFKW3v003592 for ; Tue, 18 Feb 2003 07:20:32 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1IFKVar003590 for linux-xfs@oss.sgi.com; Tue, 18 Feb 2003 07:20:31 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1IFKT45003549 for ; Tue, 18 Feb 2003 07:20:29 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1IFI4C8003509; Tue, 18 Feb 2003 07:18:04 -0800 Date: Tue, 18 Feb 2003 07:18:04 -0800 Message-Id: <200302181518.h1IFI4C8003509@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 222] file truncation after fsync() and following reset. X-Bugzilla-Reason: AssignedTo X-archive-position: 2750 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 393 Lines: 17 http://oss.sgi.com/bugzilla/show_bug.cgi?id=222 ------- Additional Comments From razuwaev@relex.ru 2003-02-18 07:18 ------- Created an attachment (id=63) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=63&action=view) test for reproduce the situation. Part 2/3 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Feb 18 07:44:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Feb 2003 07:44:28 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1IFiL3v005005 for ; Tue, 18 Feb 2003 07:44:21 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1IFiLAk005004 for linux-xfs@oss.sgi.com; Tue, 18 Feb 2003 07:44:21 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1IFiK3x004990 for ; Tue, 18 Feb 2003 07:44:20 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1IFMLpe004828; Tue, 18 Feb 2003 07:22:21 -0800 Date: Tue, 18 Feb 2003 07:22:21 -0800 Message-Id: <200302181522.h1IFMLpe004828@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 222] file truncation after fsync() and following reset. X-Bugzilla-Reason: AssignedTo X-archive-position: 2751 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 340 Lines: 18 http://oss.sgi.com/bugzilla/show_bug.cgi?id=222 ------- Additional Comments From razuwaev@relex.ru 2003-02-18 07:22 ------- (From update of attachment 62) download #62->xaa, #63->xab,#64->xac cat x* >test.tar.gz ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Feb 18 07:49:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Feb 2003 07:49:06 -0800 (PST) Received: from smtp.unc.edu (smtpsrv12.isis.unc.edu [152.2.1.243]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1IFn13v005842 for ; Tue, 18 Feb 2003 07:49:02 -0800 Received: from jennyw.unc.edu (dhcp8358.dhcp.unc.edu [152.2.213.230]) by smtp.unc.edu (8.12.2/8.12.2) with ESMTP id h1IFvUAh008408 for ; Tue, 18 Feb 2003 10:57:30 -0500 (EST) Date: Tue, 18 Feb 2003 10:57:30 -0500 From: Jenny Williams To: linux-xfs@oss.sgi.com Subject: Corrupted file on iso installer image of XFS 1.2 Message-ID: <2115652.1045565850@jennyw> X-Mailer: Mulberry/3.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 2752 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: jenny_williams@unc.edu Precedence: bulk X-list: linux-xfs Content-Length: 1260 Lines: 37 I have downloaded the following file ftp://oss.sgi.com/projects/xfs/download/Release-1.2/installer/forRH8.0-SGI- XFS-1.2.0.iso Twice, burned two separate CD's, verified the media and have tried to run an upgrade to an existing Redhat 7.3 with XFS 1.1 on a Tyan Thunder K7 Athlon 1.4Ghz system . I used this same mechanism when upgrading these same systems from 7.1 and it worked like a charm (Thanks!) Both times the installation attempt has failed with an error leading me to believe that the following file might be corrupt on that iso image: kernel-2.4.18-18SGI_XFS-1.2.0 Could someone verify that they have successfully upgraded a Redhat 7.3 Athlon system with that iso disk? (I tried finding an external list but the one on the XFS page at SGI is a dead link) At this point I am going to proceed by backing out XFS from that existing 7.3 install, upgrading to 8.0 and then trying the following Redhat RPM's. ftp://oss.sgi.com/projects/xfs/download/Release-1.2/kernel_rpms/2.4.18-18- RH/ Should I anticipate that the RPM would have the same issue? Thank you for any assistance. Virginia Williams Systems Administrator Research Applications Support University of North Carolina - Chapel Hill jenny_williams@unc.edu (919) 843-7194 From owner-linux-xfs@oss.sgi.com Tue Feb 18 08:00:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Feb 2003 08:00:11 -0800 (PST) Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1IG053v006405 for ; Tue, 18 Feb 2003 08:00:06 -0800 Received: from auto-nb1.xs4all.nl (host-4.coltex.demon.nl [212.238.252.68]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id h1IG8hMZ003926; Tue, 18 Feb 2003 17:08:43 +0100 (CET) Message-Id: <4.3.2.7.2.20030218170511.03a9be00@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 18 Feb 2003 17:08:41 +0100 To: Jenny Williams , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Corrupted file on iso installer image of XFS 1.2 In-Reply-To: <2115652.1045565850@jennyw> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2753 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: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 335 Lines: 16 At 10:57 18-2-2003 -0500, Jenny Williams wrote: >I have downloaded the following file > > kernel-2.4.18-18SGI_XFS-1.2.0 This sounds familiar. So far one other person with an athlon has seen the same issue when upgrading. I don't know how to fix this yes. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Tue Feb 18 08:31:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Feb 2003 08:31:23 -0800 (PST) Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1IGVI3v007473 for ; Tue, 18 Feb 2003 08:31:19 -0800 Received: from [10.0.0.10] (c-24-245-56-70.mn.client2.attbi.com [24.245.56.70]) by lips.thebarn.com (8.12.6/8.12.6) with ESMTP id h1IGducX003780; Tue, 18 Feb 2003 10:39:56 -0600 (CST) (envelope-from cattelan@thebarn.com) Subject: Re: Please pay attention to RedHat 7.x, other stable linux kernels (2.4) please ;p From: Russell Cattelan To: John Haverty Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: Message-Id: <1045586395.1716.49.camel@lupo.thebarn.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 18 Feb 2003 10:39:55 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 2754 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: 2891 Lines: 61 So maybe you want to spend a little less time ranting. You can help out cvs -d :pserver:cvs@xfs.org:/export/burn/cvsFBSDXFS login password: cvs cvs -d :pserver:cvs@xfs.org:/export/burn/cvsFBSDXFS co XFS (note this port is not sponsored by SGI) which is why it going very very slowly. On Tue, 2003-02-18 at 03:57, John Haverty wrote: > Christoph Hellwig wrote: > >Given your detailed analysis of different Red Hat versions you might > >have noticed that the 7.x and 8.0 errata kernels differ only the > >version string and the conmpiler usded for building.. > > I was referring to broken c libraries and broken compilers, and a strange > fetish by the vendor to up versions of things that should be upped > conservatively and never revving some important things. I have run into a > few applications, including 'our own' that do not run properly on RedHat 8. > > >The XFS code is freely available - port it to FreeBSD if you think it's > >worth the effort. I doubt my employer (SGI) is interested in wasting it's > >time for something like that > >(note that this is not an official statement, > >just an educated guess) > > FreeBSD, waste of time? Hardly. FreeBSD is, for example, the basis for > JunOS, a military grade piece of iron that runs the best routers on earth, > so I hardly think of FreeBSD as a waste. Plus, FreeBSD is a meritocracy, > well documented, coherent. One who works for a real unix vendor, such as > SGI->Irix, should have an appreciation of FreeBSD. It's fine wine in the > sour world of Linux. ;p > > I think I'll pay attention to Seth Moss' efforts @ > http://iserv.nl/files/xfs/2.4.18-24/ > It looks to be just what I need. I hope he continues with the effort. It's > much appreciated. > > I also think it's sad that RedHat hasn't chosen excellence for its > customers. XFS is the best filesystem for Linux, and they keep pushing other > inferior alternatives. Thanks for working against them on this :) > > I would also like to point out that RedHat 8 is officially a desktop OS, and > the vendor, who I deal with (and am seeking alternatives to because of this) > is basically telling me, a paying customer this: > You will no longer be able to get free "server" renditions of RedHat. You > have to buy Advanced Server. Also note that Advanced Server has no publicly > available RPMS in binary form. It's all very frustrating and needless to > say I am an upset RedHat user and hearken back to the days of really die > hard support for RedHat. (RedHat 7.0 and below "die" in March this year, and > 7.1-7.3 die in December.) > > Thanks again anyone working on XFS for Linux, its great ;p > > _________________________________________________________________ > MSN 8 with e-mail virus protection service: 2 months FREE* > http://join.msn.com/?page=features/virus -- Russell Cattelan From owner-linux-xfs@oss.sgi.com Tue Feb 18 08:38:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Feb 2003 08:38:31 -0800 (PST) Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1IGcR3v008393 for ; Tue, 18 Feb 2003 08:38:28 -0800 Received: from [10.0.0.10] (c-24-245-56-70.mn.client2.attbi.com [24.245.56.70]) by lips.thebarn.com (8.12.6/8.12.6) with ESMTP id h1IGl5cX003872; Tue, 18 Feb 2003 10:47:05 -0600 (CST) (envelope-from cattelan@thebarn.com) Subject: Re: Please pay attention to RedHat 7.x, other stable linux kernels (2.4) please ;p From: Russell Cattelan Cc: John Haverty , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: Message-Id: <1045586825.1716.57.camel@lupo.thebarn.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 18 Feb 2003 10:47:05 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 2755 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: 861 Lines: 19 On Mon, 2003-02-17 at 20:55, Eric Sandeen wrote: > There are some licensing issues here, and also some time == money issues. > > SGI is highly unlikely to release XFS under a BSD license, because our > competitors could quickly integrate it into their products. Even a > GPL'd stand-alone product for BSD is unlikely to be produced by SGI, because > frankly there is not much incentive to spend the time doing this. SGI > has Linux products, but not BSD. Just to make sure people don't get the wrong idea, the GPL does not prevent XFS from being ported to BSD. The only thing it really prevents is any group doing non open source releases of a BSD product that includes XFS. The BSD kernels do have GPL'd code include as a part of their releases, it is just very carefully sand boxed and turned OFF by default. -- Russell Cattelan From owner-linux-xfs@oss.sgi.com Tue Feb 18 09:17:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Feb 2003 09:17:55 -0800 (PST) Received: from jupiter.ucsd.edu (jupiter.ucsd.edu [132.239.126.151]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1IHHl3v009227 for ; Tue, 18 Feb 2003 09:17:47 -0800 Received: from localhost (vly@localhost) by jupiter.ucsd.edu (SGI-8.9.3/8.9.3) with ESMTP id JAA17320; Tue, 18 Feb 2003 09:39:05 -0800 (PST) Date: Tue, 18 Feb 2003 09:39:05 -0800 From: Vinh Ly To: linux-xfs@oss.sgi.com Subject: Re: Problem installing SGI-RH 8.0 XFS customized cd Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2756 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: vly@ucsd.edu Precedence: bulk X-list: linux-xfs Content-Length: 716 Lines: 28 I want to relate my experience with the RH80 installer dated 2/11/03 with an md5 of cee4c68af10836902645b4d0b89020a4. I'm getting the same error that Jason Crobett reported last week, "There was an error installing kernel-2.4.18-18SGI_XFS_1.2.0." Machine 1: P4, 845G chipset, 512 DDR RAM Machine 2: dual P3, Serverworks chipset, 512 ECC REG SDRAM I was getting the same error on both of these machines using the following installation methods: Fresh install GUI or text mode makes no difference Upgrading from a brand new 7.3 installation Upgrading from the previous 8.0 ISO install Thank you, vl P.S. Cosmetics: The welcome screen says it's version 1.2pre1, and it's still asking for disc 6. :) From owner-linux-xfs@oss.sgi.com Tue Feb 18 09:24:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Feb 2003 09:24:04 -0800 (PST) Received: from relay-3m.club-internet.fr (relay-3m.club-internet.fr [194.158.104.42]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1IHO03v009676 for ; Tue, 18 Feb 2003 09:24:01 -0800 Received: from agnes (f07v-5-202.d1.club-internet.fr [212.194.136.202]) by relay-3m.club-internet.fr (Postfix) with ESMTP id 94195E1C1; Tue, 18 Feb 2003 18:33:30 +0100 (CET) Subject: Re: Please pay attention to RedHat 7.x, other stable linux kernels (2.4) please ;p From: Jean Francois Martinez To: Joshua Baker-LePain Cc: John Haverty , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 18 Feb 2003 18:17:31 +0100 Message-Id: <1045588652.19058.4.camel@agnes.fremen.dune> Mime-Version: 1.0 X-archive-position: 2757 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: jfm2@club-internet.fr Precedence: bulk X-list: linux-xfs Content-Length: 1646 Lines: 36 On Tue, 2003-02-18 at 13:55, Joshua Baker-LePain wrote: > On Tue, 18 Feb 2003 at 1:57am, John Haverty wrote > > > Christoph Hellwig wrote: > > > > >The XFS code is freely available - port it to FreeBSD if you think it's > > >worth the effort. I doubt my employer (SGI) is interested in wasting it's > > >time for something like that > > >(note that this is not an official statement, > > >just an educated guess) > > > > FreeBSD, waste of time? Hardly. FreeBSD is, for example, the basis for > > JunOS, a military grade piece of iron that runs the best routers on earth, > > so I hardly think of FreeBSD as a waste. Plus, FreeBSD is a meritocracy, > > well documented, coherent. One who works for a real unix vendor, such as > > SGI->Irix, should have an appreciation of FreeBSD. It's fine wine in the > > sour world of Linux. ;p > > I think you misunderstand the original sentiment. SGI would probably > consider it a waste of their time (= money) to port XFS to an OS in which > they have no financial interest. They have products based on Linux, and > thus XFS on Linux can make them money. XFS on FreeBSD won't, thus no > port. They *are* a profit seeking company, after all. > > Regarding your initial question, it's easy enough to rpmbuild the official > 1.2 SRPMs on a 7.x box. That's what I'm doing here. > And there is another point: since AFAIK they would have to change the licence in order to get XFS into *BSD that would mean it would allow their competitors to include it in their OSses. With GPL Sun and others cannot take it unless they are willing to GPLed their own OS. JFM From owner-linux-xfs@oss.sgi.com Tue Feb 18 11:09:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Feb 2003 11:09:34 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1IJ9P3v011366 for ; Tue, 18 Feb 2003 11:09:25 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1IJHxG8028333 for ; Tue, 18 Feb 2003 11:17:59 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA95165; Tue, 18 Feb 2003 13:17:53 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id NAA54553; Tue, 18 Feb 2003 13:17:52 -0600 (CST) Date: Tue, 18 Feb 2003 13:16:35 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Jenny Williams cc: linux-xfs@oss.sgi.com Subject: Re: Corrupted file on iso installer image of XFS 1.2 In-Reply-To: <2115652.1045565850@jennyw> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2758 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1579 Lines: 48 I think the athlon rpms are completely missing from the installer, but perhaps not missing from the list of files it wants to install. It will take a re-spin of the installer to fix this. -Eric On Tue, 18 Feb 2003, Jenny Williams wrote: > I have downloaded the following file > > ftp://oss.sgi.com/projects/xfs/download/Release-1.2/installer/forRH8.0-SGI- > XFS-1.2.0.iso > > Twice, burned two separate CD's, verified the media and have tried to run > an upgrade to an existing Redhat 7.3 with XFS 1.1 on a Tyan Thunder K7 > Athlon 1.4Ghz system . I used this same mechanism when upgrading these same > systems from 7.1 and it worked like a charm (Thanks!) > > Both times the installation attempt has failed with an error leading me to > believe that the following file might be corrupt on that iso image: > > kernel-2.4.18-18SGI_XFS-1.2.0 > > > > Could someone verify that they have successfully upgraded a Redhat 7.3 > Athlon system with that iso disk? (I tried finding an external list but > the one on the XFS page at SGI is a dead link) > > At this point I am going to proceed by backing out XFS from that existing > 7.3 install, upgrading to 8.0 and then trying the following Redhat RPM's. > > ftp://oss.sgi.com/projects/xfs/download/Release-1.2/kernel_rpms/2.4.18-18- > RH/ > > Should I anticipate that the RPM would have the same issue? > > Thank you for any assistance. > > Virginia Williams > Systems Administrator > Research Applications Support > University of North Carolina - Chapel Hill > jenny_williams@unc.edu (919) 843-7194 > > From owner-linux-xfs@oss.sgi.com Tue Feb 18 11:24:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Feb 2003 11:24:30 -0800 (PST) Received: from smtp.unc.edu (smtpsrv12.isis.unc.edu [152.2.1.243]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1IJOM3v011892 for ; Tue, 18 Feb 2003 11:24:22 -0800 Received: from jennyw.unc.edu (dhcp8358.dhcp.unc.edu [152.2.213.230]) by smtp.unc.edu (8.12.2/8.12.2) with ESMTP id h1IJW7Ah005882; Tue, 18 Feb 2003 14:32:08 -0500 (EST) Date: Tue, 18 Feb 2003 14:32:06 -0500 From: Jenny Williams To: Eric Sandeen cc: linux-xfs@oss.sgi.com Subject: Re: Corrupted file on iso installer image of XFS 1.2 Message-ID: <14991957.1045578726@jennyw> In-Reply-To: References: X-Mailer: Mulberry/3.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 2759 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: jenny_williams@unc.edu Precedence: bulk X-list: linux-xfs Content-Length: 2046 Lines: 65 Might that re-spin be undertaken, or are you guys going to let it be the way it is? I figure that if the functionality changed from one iso image to the next it might be an issue for people. Please know I ask this with the full understanding that you guys spin these RedHat specific files above and beyond the call. --On Tuesday, February 18, 2003 1:16 PM -0600 Eric Sandeen wrote: > I think the athlon rpms are completely missing from the installer, > but perhaps not missing from the list of files it wants to install. > > It will take a re-spin of the installer to fix this. > > -Eric > > On Tue, 18 Feb 2003, Jenny Williams wrote: > >> I have downloaded the following file >> >> ftp://oss.sgi.com/projects/xfs/download/Release-1.2/installer/forRH8.0-S >> GI- XFS-1.2.0.iso >> >> Twice, burned two separate CD's, verified the media and have tried to >> run an upgrade to an existing Redhat 7.3 with XFS 1.1 on a Tyan Thunder >> K7 Athlon 1.4Ghz system . I used this same mechanism when upgrading >> these same systems from 7.1 and it worked like a charm (Thanks!) >> >> Both times the installation attempt has failed with an error leading me >> to believe that the following file might be corrupt on that iso image: >> >> kernel-2.4.18-18SGI_XFS-1.2.0 >> >> >> >> Could someone verify that they have successfully upgraded a Redhat 7.3 >> Athlon system with that iso disk? (I tried finding an external list but >> the one on the XFS page at SGI is a dead link) >> >> At this point I am going to proceed by backing out XFS from that >> existing 7.3 install, upgrading to 8.0 and then trying the following >> Redhat RPM's. >> >> ftp://oss.sgi.com/projects/xfs/download/Release-1.2/kernel_rpms/2.4.18- >> 18- RH/ >> >> Should I anticipate that the RPM would have the same issue? >> >> Thank you for any assistance. >> >> Virginia Williams >> Systems Administrator >> Research Applications Support >> University of North Carolina - Chapel Hill >> jenny_williams@unc.edu (919) 843-7194 >> >> > Jenny From owner-linux-xfs@oss.sgi.com Tue Feb 18 11:36:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Feb 2003 11:36:38 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1IJaY3v012388 for ; Tue, 18 Feb 2003 11:36:34 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1IJj8G8030691 for ; Tue, 18 Feb 2003 11:45:08 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA06255; Tue, 18 Feb 2003 13:45:07 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id NAA67082; Tue, 18 Feb 2003 13:45:07 -0600 (CST) Date: Tue, 18 Feb 2003 13:43:49 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Jenny Williams cc: linux-xfs@oss.sgi.com Subject: Re: Corrupted file on iso installer image of XFS 1.2 In-Reply-To: <14991957.1045578726@jennyw> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2760 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 699 Lines: 20 Oh, we'll probably get it worked out. I swore last time that I would not do another RH installer, but Russell was nice enough to step in and do it this time. :) It's just a matter of priorities and time. But there's no point in leaving a non-functional installer out there, so it'll probably get fixed up. -Eric On Tue, 18 Feb 2003, Jenny Williams wrote: > > Might that re-spin be undertaken, or are you guys going to let it be the > way it is? I figure that if the functionality changed from one iso image > to the next it might be an issue for people. Please know I ask this with > the full understanding that you guys spin these RedHat specific files above > and beyond the call. From owner-linux-xfs@oss.sgi.com Tue Feb 18 11:50:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Feb 2003 11:50:47 -0800 (PST) Received: from smtp.unc.edu (smtpsrv12.isis.unc.edu [152.2.1.243]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1IJoe3v012934 for ; Tue, 18 Feb 2003 11:50:41 -0800 Received: from jennyw.unc.edu (dhcp8358.dhcp.unc.edu [152.2.213.230]) by smtp.unc.edu (8.12.2/8.12.2) with ESMTP id h1IJwYAh012751; Tue, 18 Feb 2003 14:58:34 -0500 (EST) Date: Tue, 18 Feb 2003 14:58:36 -0500 From: Jenny Williams To: Eric Sandeen cc: linux-xfs@oss.sgi.com Subject: Re: Corrupted file on iso installer image of XFS 1.2 Message-ID: <16578208.1045580316@jennyw> In-Reply-To: References: X-Mailer: Mulberry/3.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 2761 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: jenny_williams@unc.edu Precedence: bulk X-list: linux-xfs Content-Length: 880 Lines: 30 Thank you for the information. I'll keep my eyes peeled. --On Tuesday, February 18, 2003 1:43 PM -0600 Eric Sandeen wrote: > Oh, we'll probably get it worked out. I swore last time that I would > not do another RH installer, but Russell was nice enough to step > in and do it this time. :) It's just a matter of priorities and > time. > > But there's no point in leaving a non-functional installer out there, > so it'll probably get fixed up. > > -Eric > > > On Tue, 18 Feb 2003, Jenny Williams wrote: > >> >> Might that re-spin be undertaken, or are you guys going to let it be the >> way it is? I figure that if the functionality changed from one iso >> image to the next it might be an issue for people. Please know I ask >> this with the full understanding that you guys spin these RedHat >> specific files above and beyond the call. > Jenny From owner-linux-xfs@oss.sgi.com Tue Feb 18 11:52:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Feb 2003 11:52:15 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1IJqC3v013264 for ; Tue, 18 Feb 2003 11:52:12 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1IKANkq031727 for ; Tue, 18 Feb 2003 14:10:23 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA15266; Tue, 18 Feb 2003 14:00:41 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id OAA61048; Tue, 18 Feb 2003 14:00:41 -0600 (CST) Date: Tue, 18 Feb 2003 13:59:23 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Jenny Williams cc: linux-xfs@oss.sgi.com Subject: Re: Corrupted file on iso installer image of XFS 1.2 In-Reply-To: <2115652.1045565850@jennyw> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2762 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 673 Lines: 21 On Tue, 18 Feb 2003, Jenny Williams wrote: > Both times the installation attempt has failed with an error leading me to > believe that the following file might be corrupt on that iso image: > > kernel-2.4.18-18SGI_XFS-1.2.0 Oh, the other helpful thing would be to look at the other terminals (alt-f1,f2, etc) for any other error messages. > At this point I am going to proceed by backing out XFS from that existing > 7.3 install, upgrading to 8.0 and then trying the following Redhat RPM's. > > ftp://oss.sgi.com/projects/xfs/download/Release-1.2/kernel_rpms/2.4.18-18- > RH/ > I think that should work fine, as long as your system root is not on xfs. -Eric From owner-linux-xfs@oss.sgi.com Tue Feb 18 13:15:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Feb 2003 13:15:36 -0800 (PST) Received: from ubergeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1ILFT3v014570 for ; Tue, 18 Feb 2003 13:15:29 -0800 Received: (qmail 11524 invoked by uid 500); 18 Feb 2003 21:21:33 -0000 Subject: Back trace of fs lock behavior. From: Austin Gonyou To: XFS List Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1045603292.8516.79.camel@UberGeek> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 18 Feb 2003 15:21:33 -0600 X-archive-position: 2763 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: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Content-Length: 1354 Lines: 46 This happened just after an FS was full, oracle stopped processing, programs which rely on oracle's return were stopped, then I attempted to tail one of their log files. This is from that tail. 0kdb>btp 11925 0xcefe2000 11925 2389 0 002 stop 0xcefe2360 tail ESP EIP Function(args) 0xcefe3ecc 0xc01156b3 schedule+0x493(0x0, 0xcefe2000, 0x0, 0x0, 0x0) Kernel .text 0xc0100000 0xc0115220 0xc0115770 0xcefe3f0c 0xc01c9ff6 lock_wait+0xa6(0xebf49c3c, 0x0) Kernel .text 0xc0100000 0xc01c9f50 0xc01ca030 0xcefe3f38 0xc01ca0b8 mraccessf+0x48(0xebf49c1c, 0x0) Kernel .text 0xc0100000 0xc01ca070 0xc01ca0e0 0xcefe3f4c 0xc01a149a xfs_ilock+0x3a(0xebf49b70, 0x2, 0xf7320400, 0xebf49b70) Kernel .text 0xc0100000 0xc01a1460 0xc01a14d0 0xcefe3f60 0xc01c6ef3 xfs_read+0xf3(0xebf49b88, 0xdab7c200, 0xbfffceb0, 0x1000, 0dab7c220) Kernel .text 0xc0100000 0xc0106e00 0xc01c6f50 0xcefe3f84 0xc01c25fb linvfs_read+0x26(0xdab7c200, 0xbfffce60, 0x1000, 0xdab7c220, 0xcefe2000) Kernel .text 0xc0100000 0xnnnnnnnn 0xnnnnnnnn 0xnnnnnnnn 0xcefe3fa0 0xc0140036 sys_read+0x96(0x3, 0xbfffce60, 0x1000, 0x40016b4c, 0xbffff094) Kernel .text 0xc0100000 0xc013ffa0 0xc01400be 0xcefe3fc4 0xc0108c33 system_call+0x33 Kernel .text 0xc0100000 0xc0108c00 0xc0108c38 -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Tue Feb 18 13:24:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Feb 2003 13:24:18 -0800 (PST) Received: from ente.berdmann.de (frnk-d514e1df.dsl.mediaWays.net [213.20.225.223]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1ILO93v015056 for ; Tue, 18 Feb 2003 13:24:11 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.35 #1) id 18lFM1-0002MO-00; Tue, 18 Feb 2003 22:32:41 +0100 Message-ID: <3E52A679.5010205@berdmann.de> Date: Tue, 18 Feb 2003 22:32:41 +0100 From: Bernhard Erdmann User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Jenny Williams CC: linux-xfs@oss.sgi.com Subject: Re: Corrupted file on iso installer image of XFS 1.2 References: <2115652.1045565850@jennyw> In-Reply-To: <2115652.1045565850@jennyw> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2764 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: be@berdmann.de Precedence: bulk X-list: linux-xfs Content-Length: 827 Lines: 23 Jenny Williams wrote: > I have downloaded the following file > > ftp://oss.sgi.com/projects/xfs/download/Release-1.2/installer/forRH8.0-SGI- > XFS-1.2.0.iso > > Twice, burned two separate CD's, verified the media and have tried to > run an upgrade to an existing Redhat 7.3 with XFS 1.1 on a Tyan Thunder > K7 Athlon 1.4Ghz system . I used this same mechanism when upgrading > these same systems from 7.1 and it worked like a charm (Thanks!) > > Both times the installation attempt has failed with an error leading me > to believe that the following file might be corrupt on that iso image: > > kernel-2.4.18-18SGI_XFS-1.2.0 This installer bug hit me today when I tried to install SGI XFS 1.2.0 from CD to an IBM Thinkpad A31. I went back to the 1.2pre1 ISO and upgraded later kernel and userspace tools. From owner-linux-xfs@oss.sgi.com Tue Feb 18 13:25:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Feb 2003 13:25:38 -0800 (PST) Received: from ente.berdmann.de (frnk-d514e1df.dsl.mediaWays.net [213.20.225.223]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1ILPX3v015319 for ; Tue, 18 Feb 2003 13:25:34 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.35 #1) id 18lFNP-0002MS-00; Tue, 18 Feb 2003 22:34:07 +0100 Message-ID: <3E52A6CF.9020403@berdmann.de> Date: Tue, 18 Feb 2003 22:34:07 +0100 From: Bernhard Erdmann User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Eric Sandeen CC: Jenny Williams , linux-xfs@oss.sgi.com Subject: Re: Corrupted file on iso installer image of XFS 1.2 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2765 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: be@berdmann.de Precedence: bulk X-list: linux-xfs Content-Length: 213 Lines: 8 Eric Sandeen wrote: [...] > But there's no point in leaving a non-functional installer out there, > so it'll probably get fixed up. The 1.2.0 installer has another bug: it prints a welcome message for 1.2pre1. From owner-linux-xfs@oss.sgi.com Tue Feb 18 13:31:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Feb 2003 13:31:16 -0800 (PST) Received: from ente.berdmann.de (frnk-d514e1df.dsl.mediaWays.net [213.20.225.223]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1ILVC3v015945 for ; Tue, 18 Feb 2003 13:31:13 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.35 #1) id 18lFSq-0002Ms-00; Tue, 18 Feb 2003 22:39:44 +0100 Message-ID: <3E52A820.2030201@berdmann.de> Date: Tue, 18 Feb 2003 22:39:44 +0100 From: Bernhard Erdmann User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Eric Sandeen CC: Jenny Williams , linux-xfs@oss.sgi.com Subject: Re: Corrupted file on iso installer image of XFS 1.2 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2766 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: be@berdmann.de Precedence: bulk X-list: linux-xfs Content-Length: 329 Lines: 10 Eric Sandeen wrote: > Oh, we'll probably get it worked out. I swore last time that I would > not do another RH installer, but Russell was nice enough to step > in and do it this time. :) It's just a matter of priorities and > time. Is it that complicated? Do you have a Howto or a script how to "roll your own installer"? From owner-linux-xfs@oss.sgi.com Tue Feb 18 13:50:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Feb 2003 13:50:54 -0800 (PST) Received: from ubergeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1ILoj3v016592 for ; Tue, 18 Feb 2003 13:50:46 -0800 Received: (qmail 11833 invoked by uid 500); 18 Feb 2003 21:56:50 -0000 Subject: Mount oops from 2.4.20 + xfs-Dec182002 From: Austin Gonyou To: XFS List Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1045605409.8516.91.camel@UberGeek> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 18 Feb 2003 15:56:50 -0600 X-archive-position: 2767 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: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Content-Length: 4023 Lines: 103 After having to reboot the system from a bad state,(i.e. poweroff), and then attempting to mount the FC connected disks again, mount caused an Oops. I've seen this with many different kernel rev's though, then the conditions are just right. ksymoops 2.4.1 on i686 2.4.20-ag3-p4-debug. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.20-ag3-p4-debug/ (default) -m /boot/System.map (specified) Warning (compare_maps): mismatch on symbol md_size , md says f8a6ee80, /lib/modules/2.4.20-ag3-p4-debug/kernel/drivers/md/md.o says f8a6eca0. Ignoring /lib/modules/2.4.20-ag3-p4-debug/kernel/drivers/md/md.o entry Warning (compare_maps): mismatch on symbol mddev_map , md says f8a6e680, /lib/modules/2.4.20-ag3-p4-debug/kernel/drivers/md/md.o says f8a6e4a0. Ignoring /lib/modules/2.4.20-ag3-p4-debug/kernel/drivers/md/md.o entry Unable to handle kernel NULL pointer dereference at virtual address 00000058 c01bdd7e *pde = 36538001 Oops: 0000 CPU: 2 EIP: 0010:[xfs_ioerror_alert+14/96] Not tainted EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010206 eax: 00000000 ebx: 00000000 ecx: f6e0ce80 edx: 01fb8950 esi: f6274800 edi: 01fb8950 ebp: 00000000 esp: f686db70 ds: 0018 es: 0018 ss: 0018 Process mount (pid: 1153, stackpage=f686d000) Stack: 00000000 0000000c c01acd80 c02d3a97 f6274800 00000000 01fb8950 00000000 00000000 f6274800 00000000 f61a45c0 f6e0ce80 00000002 c01ad782 f6e0ce80 f61a45c0 00000002 f61a4480 f6c8f400 00000004 ed1e2090 f6219274 c01ad8c6 Call Trace: [xlog_recover_do_buffer_trans+304/592] [xlog_recover_do_trans+82/256] [xlog_recover_commit_trans+38/64] [xlog_recover_process_data+298/464] [xlog_do_recovery_pass+852/2048] Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 58 58 85 c0 8b 4c 24 1c 53 bb 0c 00 00 00 74 07 0f b7 98 >>EIP; c01bdd7e <===== Trace; c01acd80 Trace; c01ad782 Trace; c01ad8c6 Trace; c01ada2a Trace; c01ae704 Trace; c01aec34 Trace; c01aec81 Trace; c01aee02 Trace; c01a7f20 Trace; c01b05cc Trace; c01af738 Trace; c01b751f Trace; c01c8add Trace; c0131c46 Trace; c0132163 Trace; c0145cc1 Trace; c0145ec4 Trace; c0158185 Trace; c015843b Trace; c015829c Trace; c0158864 Trace; c0108c33 Code; c01bdd7e 00000000 <_EIP>: Code; c01bdd7e <===== 0: 8b 58 58 mov 0x58(%eax),%ebx <===== Code; c01bdd81 3: 85 c0 test %eax,%eax Code; c01bdd83 5: 8b 4c 24 1c mov 0x1c(%esp,1),%ecx Code; c01bdd87 9: 53 push %ebx Code; c01bdd88 a: bb 0c 00 00 00 mov $0xc,%ebx Code; c01bdd8d f: 74 07 je 18 <_EIP+0x18> c01bdd96 Code; c01bdd8f 11: 0f b7 98 00 00 00 00 movzwl 0x0(%eax),%ebx 2 warnings issued. Results may not be reliable. -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Tue Feb 18 13:58:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Feb 2003 13:58:30 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1ILwJ3v017104 for ; Tue, 18 Feb 2003 13:58:20 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id D2DF5186B138; Tue, 18 Feb 2003 14:06:59 -0800 (PST) Date: Tue, 18 Feb 2003 14:06:59 -0800 From: Chris Wedgwood To: Austin Gonyou Cc: XFS List Subject: Re: Mount oops from 2.4.20 + xfs-Dec182002 Message-ID: <20030218220659.GB15178@f00f.org> References: <1045605409.8516.91.camel@UberGeek> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1045605409.8516.91.camel@UberGeek> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2768 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: 413 Lines: 14 On Tue, Feb 18, 2003 at 03:56:50PM -0600, Austin Gonyou wrote: > >>EIP; c01bdd7e <===== Did anything get printed before this oops? xfs_ioerror_alert should print out details of an IO error that looks like it occurred during log replay... I wonder if it was passed a bogus non-zero mp? Maybe dumping the log transactions would show if one of the transactions is trashed? --cw From owner-linux-xfs@oss.sgi.com Tue Feb 18 14:20:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Feb 2003 14:20:50 -0800 (PST) Received: from hell.org.pl (qmailr@hell.org.pl [212.244.218.42]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1IMK73v017862 for ; Tue, 18 Feb 2003 14:20:13 -0800 Received: (qmail 7046 invoked by uid 777); 18 Feb 2003 22:28:54 -0000 Date: Tue, 18 Feb 2003 23:28:54 +0100 From: Karol Kozimor To: linux-xfs@oss.sgi.com Subject: XFS and ACPI sleep states compat in 2.5 Message-ID: <20030218222854.GA8829@hell.org.pl> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 2769 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sziwan@hell.org.pl Precedence: bulk X-list: linux-xfs Content-Length: 11540 Lines: 261 --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Hi, It seems that the XFS code (probably page_buf.c) doesn't have any support for ACPI sleep states (S3 a.k.a. Suspend-To-RAM, and S4 a.k.a. Suspend-To-Disk, or software suspend - swsusp). The problem seems to concentrate on pagebufd (and pagebuf/0) not beeing able to enter refrigerator (suspend) properly. Upon entering the S4 state, 2.5.59-61 (as well as 2.4.x-xfs) suspend subsystem fails to stop those kernel threads, and refuses to suspend. After such a trial, pagebufd seems to start sucking up the CPU power greatly, but otherwise works correctly (at least I think so, I failed to notice any filesystem corruption). The S3 state (only supported in 2.5) actually disregards the warnings of not being able to stop pagebufd (part of dmesg attached) and works smoothly, but after resume the pagebufd still uses up the processor. I wouldn't bother the list, if the swsusp and ACPI sleep code wasn't integrated into the official kernel. Anyway, there exist some patches for 2.4.20 kernels and a recent version of XFS that deal with that issue perfectly (at least for me, I haven't ecountered any XFS-related problems so far using those). One I'm currently using is here: http://www.sfo.jp/debian/patch/swsusp/swsusp18.xfs-1.2pre4.patch The patch seems trivial (as most patches for swsusp + journalled filesystems are), but alas, I'm no kernel hacker and the structure of page_buf.c in 2.5 has changed substantially, so I'm not able to patch it by myself. Thanks in advance for any help or hints, Best regards, -- Karol 'sziwan' Kozimor sziwan@hell.org.pl --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: attachment; filename="dmesg-2.5.61" Linux version 2.5.61 (sziwan@nadir) (gcc version 3.2.2) #3 Tue Feb 18 21:49:46 CET 2003 Video mode to be used for restore is f00 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000000fff9000 (usable) BIOS-e820: 000000000fff9000 - 000000000ffff000 (ACPI data) BIOS-e820: 000000000ffff000 - 0000000010000000 (ACPI NVS) BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved) 255MB LOWMEM available. ACPI: have wakeup address 0xc0001000 On node 0 totalpages: 65529 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 61433 pages, LIFO batch:14 HighMem zone: 0 pages, LIFO batch:1 ACPI: RSDP (v000 ASUS ) @ 0x000f6870 ACPI: RSDT (v001 ASUS P4_L3CS 16944.11825) @ 0x0fff9000 ACPI: FADT (v001 ASUS P4_L3CS 16944.11825) @ 0x0fff9080 ACPI: BOOT (v001 ASUS P4_L3CS 16944.11825) @ 0x0fff9040 ACPI: DSDT (v001 ASUS P4_L3CS 00000.04096) @ 0x00000000 ACPI: BIOS passes blacklist Building zonelist for node : 0 Kernel command line: BOOT_IMAGE=NEW ro root=305 resume=/dev/hda1 apci_sleep=s3_bios single Initializing CPU#0 PID hash table entries: 1024 (order 10: 8192 bytes) Detected 1699.585 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 3350.52 BogoMIPS Memory: 256092k/262116k available (1745k kernel code, 5316k reserved, 677k data, 104k init, 0k highmem) Dentry cache hash table entries: 32768 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) -> /dev -> /dev/console -> /root CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 512K CPU: After generic, caps: 3febf9ff 00000000 00000000 00000000 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU#0: Intel P4/Xeon Extended MCE MSRs (12) available CPU: Intel(R) Pentium(R) 4 Mobile CPU 1.70GHz stepping 04 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket mtrr: v2.0 (20020519) PCI: PCI BIOS revision 2.10 entry at 0xf0e40, last bus=2 PCI: Using configuration type 1 BIO: pool of 256 setup, 14Kb (56 bytes/bio) biovec pool[0]: 1 bvecs: 256 entries (12 bytes) biovec pool[1]: 4 bvecs: 256 entries (48 bytes) biovec pool[2]: 16 bvecs: 256 entries (192 bytes) biovec pool[3]: 64 bvecs: 256 entries (768 bytes) biovec pool[4]: 128 bvecs: 256 entries (1536 bytes) biovec pool[5]: 256 bvecs: 256 entries (3072 bytes) ACPI: Subsystem revision 20030122 tbxface-0098 [03] acpi_load_tables : ACPI Tables successfully acquired Parsing all Control Methods:.............................................................................................................................................................................................................................................................. Table [DSDT] - 769 Objects with 60 Devices 254 Methods 26 Regions ACPI Namespace successfully loaded at root c0385a7c evxfevnt-0073 [04] acpi_enable : Transition to ACPI mode successful evgpe-0262: *** Info: GPE Block0 defined as GPE0 to GPE15 evgpe-0262: *** Info: GPE Block1 defined as GPE16 to GPE31 Executing all Device _STA and_INI methods:............................................................ 60 Devices found containing: 60 _STA, 5 _INI methods Completing Region/Field/Buffer/Package initialization:.......................................................................... Initialized 18/26 Regions 0/0 Fields 23/23 Buffers 33/33 Packages (769 nodes) ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: PCI Interrupt Link [LNKA] (IRQs *5) ACPI: PCI Interrupt Link [LNKB] (IRQs 7 *11) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 11, enabled at IRQ 9) ACPI: PCI Interrupt Link [LNKD] (IRQs 5 7 11, enabled at IRQ 9) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15, disabled) ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 11 12 14 15, disabled) ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 11 12 14 15, disabled) ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 10 11 12 14 15, disabled) ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) Transparent bridge - Intel Corp. 82801BAM/CAM PCI Bri ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI2._PRT] ACPI: Embedded Controller [ECD0] (gpe 28) ACPI: Power Resource [PRCF] (on) Linux Plug and Play Support v0.94 (c) Adam Belay block request queues: 128 requests per read queue 128 requests per write queue 8 requests per batch enter congestion at 15 exit congestion at 17 ACPI: PCI Interrupt Link [LNKE] enabled at IRQ 10 ACPI: PCI Interrupt Link [LNKF] enabled at IRQ 11 ACPI: PCI Interrupt Link [LNKG] enabled at IRQ 10 ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 5 PCI: Using ACPI for IRQ routing PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off' SBF: Simple Boot Flag extension found and enabled. SBF: Setting boot flags 0x1 Enabling SEP on CPU 0 aio_setup: sizeof(struct page) = 40 Journalled Block Device driver loaded devfs: v1.22 (20021013) Richard Gooch (rgooch@atnf.csiro.au) devfs: boot_options: 0x1 SGI XFS for Linux 2.5.61 with no debug enabled ACPI: AC Adapter [ACAD] (on-line) ACPI: Battery Slot [BAT0] (battery present) ACPI: Power Button (FF) [PWRF] ACPI: Sleep Button (CM) [SLPB] ACPI: Lid Switch [LIDD] ACPI: Fan [CFAN] (on) ACPI: Processor [CPU0] (supports C1 C2, 8 throttling states) ACPI: Thermal Zone [THRM] (58 C) pty: 256 Unix98 ptys configured Real Time Clock Driver v1.11 Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx ICH3M: IDE controller at PCI slot 00:1f.1 ICH3M: chipset revision 2 ICH3M: not 100% native mode: will probe irqs later ide0: BM-DMA at 0x8400-0x8407, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0x8408-0x840f, BIOS settings: hdc:DMA, hdd:pio hda: IC25N040ATCS04-0, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hdc: TOSHIBA DVD-ROM SD-R2212, ATAPI CD/DVD-ROM drive ide1 at 0x170-0x177,0x376 on irq 15 hda: host protected area => 1 hda: 78140160 sectors (40008 MB) w/1768KiB Cache, CHS=77520/16/63, UDMA(100) /dev/ide/host0/bus0/target0/lun0: p1 p2 p3 < p5 p6 p7 > p4 mice: PS/2 mouse device common for all mice i8042.c: Detected active multiplexing controller, rev 1.1. serio: i8042 AUX0 port at 0x60,0x64 irq 12 serio: i8042 AUX1 port at 0x60,0x64 irq 12 serio: i8042 AUX2 port at 0x60,0x64 irq 12 input: PS/2 Synaptics TouchPad on isa0060/serio4 serio: i8042 AUX3 port at 0x60,0x64 irq 12 input: AT Set 2 keyboard on isa0060/serio0 serio: i8042 KBD port at 0x60,0x64 irq 1 NET4: Linux TCP/IP 1.0 for NET4.0 IP: routing cache hash table of 2048 buckets, 16Kbytes TCP: Hash tables configured (established 16384 bind 32768) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. BIOS EDD facility v0.09 2003-Jan-22, 1 devices found ACPI: (supports S0 S1 S3 S4 S5) Resume Machine: resuming from /dev/hda1 Resuming from device ide0(3,1) Resume Machine: This is normal swap space XFS mounting filesystem ide0(3,5) Starting XFS recovery on filesystem: ide0(3,5) (dev: 3/5) Ending XFS recovery on filesystem: ide0(3,5) (dev: 3/5) VFS: Mounted root (xfs filesystem) readonly. Mounted devfs on /dev Freeing unused kernel memory: 104k freed Adding 393552k swap on /dev/hda1. Priority:-1 extents:1 XFS mounting filesystem ide0(3,6) Ending clean XFS mount for filesystem: ide0(3,6) serio: kseriod exiting 8139too Fast Ethernet driver 0.9.26 eth0: RealTek RTL8139 Fast Ethernet at 0xa800, 00:e0:18:dc:6d:bc, IRQ 9 eth0: Identified 8139 chip type 'RTL-8139B' eth0: Setting 100mbps full-duplex based on auto-negotiated partner ability 45e1. hda: DMA disabled Stopping tasks: init entered refrigerator =pdflush: bogus wakeup! pdflush entered refrigerator =pdflush: bogus wakeup! pdflush entered refrigerator =kswapd0 entered refrigerator =agetty entered refrigerator =agetty entered refrigerator =agetty entered refrigerator =agetty entered refrigerator =agetty entered refrigerator =dhcpcd entered refrigerator =sshd entered refrigerator = stopping tasks failed (2 tasks remaining) Suspending devices Suspending device c038d2ec Suspending devices Suspending device c038d2ec suspending: hda <0>Suspending devices Suspending device c038d2ec hwsleep-0238 [12] acpi_enter_sleep_state: Entering sleep state [S3] Enabling SEP on CPU 0 Devices Resumed eth0: Setting 100mbps full-duplex based on auto-negotiated partner ability 45e1. Devices Resumed Restarting tasks...<6> Strange, pagebufd not stopped Strange, eth0 not stopped done init left refrigerator pdflush left refrigerator kswapd0 left refrigerator agetty left refrigerator agetty left refrigerator agetty left refrigerator agetty left refrigerator agetty left refrigerator dhcpcd left refrigerator sshd left refrigerator pdflush left refrigerator hda: status timeout: status=0x80 { Busy } hda: drive not ready for command ide0: reset: success NETDEV WATCHDOG: eth0: transmit timed out eth0: Tx queue start entry 6 dirty entry 2. eth0: Tx descriptor 0 is 00002000. eth0: Tx descriptor 1 is 00002000. eth0: Tx descriptor 2 is 00002000. (queue head) eth0: Tx descriptor 3 is 00002000. eth0: Setting 100mbps full-duplex based on auto-negotiated partner ability 45e1. --r5Pyd7+fXNt84Ff3-- From owner-linux-xfs@oss.sgi.com Tue Feb 18 14:28:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Feb 2003 14:28:50 -0800 (PST) Received: from ubergeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1IMSi3v018338 for ; Tue, 18 Feb 2003 14:28:47 -0800 Received: (qmail 12180 invoked by uid 500); 18 Feb 2003 22:34:37 -0000 Subject: Re: Mount oops from 2.4.20 + xfs-Dec182002 From: Austin Gonyou To: Chris Wedgwood Cc: XFS List In-Reply-To: <20030218220659.GB15178@f00f.org> References: <20030218220659.GB15178@f00f.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1045607677.8523.96.camel@UberGeek> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 18 Feb 2003 16:34:37 -0600 X-archive-position: 2770 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: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Content-Length: 1107 Lines: 32 On Tue, 2003-02-18 at 16:06, Chris Wedgwood wrote: > On Tue, Feb 18, 2003 at 03:56:50PM -0600, Austin Gonyou wrote: > > > >>EIP; c01bdd7e <===== > > Did anything get printed before this oops? xfs_ioerror_alert should > print out details of an IO error that looks like it occurred during > log replay... I wonder if it was passed a bogus non-zero mp? > > Maybe dumping the log transactions would show if one of the > transactions is trashed? Nothing major before this, but the log info looks like this: Feb 18 14:52:48 Phoenix kernel: XFS mounting filesystem sd(8,128) Feb 18 14:52:49 Phoenix kernel: Starting XFS recovery on filesystem: sd(8,128) (dev: 8/128) Feb 18 14:52:49 Phoenix kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000058 Feb 18 14:52:49 Phoenix kernel: printing eip: Feb 18 14:52:49 Phoenix kernel: c01bdd7e Feb 18 14:52:49 Phoenix kernel: *pde = 36538001 Feb 18 14:52:49 Phoenix kernel: *pte = 00000000 Feb 18 14:52:49 Phoenix kernel: Oops: 0000 > > --cw -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Tue Feb 18 14:48:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Feb 2003 14:49:06 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1IMmx3v018881 for ; Tue, 18 Feb 2003 14:48:59 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id B4B98186B138; Tue, 18 Feb 2003 14:57:39 -0800 (PST) Date: Tue, 18 Feb 2003 14:57:39 -0800 From: Chris Wedgwood To: Austin Gonyou Cc: XFS List Subject: Re: Mount oops from 2.4.20 + xfs-Dec182002 Message-ID: <20030218225739.GB15618@f00f.org> References: <20030218220659.GB15178@f00f.org> <1045607677.8523.96.camel@UberGeek> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1045607677.8523.96.camel@UberGeek> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2771 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: 364 Lines: 15 On Tue, Feb 18, 2003 at 04:34:37PM -0600, Austin Gonyou wrote: > Nothing major before this, but the log info looks like this: if it's still oopsing in xfs_ioerror_alert, can you print out the values of mp, bp & func (as pointers) in xfs_ioerror_alert, something like printk("xfs_ioerror_alert %p %p %p\n", mp, bp, func); or whatever will suffice. --cw From owner-linux-xfs@oss.sgi.com Tue Feb 18 15:27:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Feb 2003 15:28:01 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1INRt3v019543 for ; Tue, 18 Feb 2003 15:27:55 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1INaRKp011092 for ; Tue, 18 Feb 2003 15:36:29 -0800 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 h1INZ93s8152082; Wed, 19 Feb 2003 10:35:09 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h1INZ7la8907219; Wed, 19 Feb 2003 10:35:07 +1100 (EST) Date: Wed, 19 Feb 2003 10:35:07 +1100 (EST) From: Nathan Scott Message-Id: <200302182335.h1INZ7la8907219@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, agruen@suse.de Subject: TAKE - acl_init X-archive-position: 2772 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@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 363 Lines: 14 Fix a zero-length malloc in acl_init - causing QA failures when libacl is linked with the electric fence library. Date: Tue Feb 18 15:34:40 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:139974a cmd/acl/libacl/acl_init.c - 1.5 From owner-linux-xfs@oss.sgi.com Tue Feb 18 17:20:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Feb 2003 17:20:22 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1J1KH3v021476 for ; Tue, 18 Feb 2003 17:20:17 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1J1SqG8014958 for ; Tue, 18 Feb 2003 17:28:52 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id TAA57012; Tue, 18 Feb 2003 19:28:51 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id TAA57770; Tue, 18 Feb 2003 19:28:51 -0600 (CST) Date: Tue, 18 Feb 2003 19:27:31 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Bernhard Erdmann cc: Jenny Williams , Subject: Re: Corrupted file on iso installer image of XFS 1.2 In-Reply-To: <3E52A820.2030201@berdmann.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2773 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1128 Lines: 26 On Tue, 18 Feb 2003, Bernhard Erdmann wrote: > Is it that complicated? Do you have a Howto or a script how to "roll > your own installer"? It's not that hard, once you've taken the time to figure things out. There were two bits of it, Anaconda modifications to support xfs, and creating the right build environment for the installer. You can look at the patch in the Anaconda SRPM to see what we did to the installer itself (actually lots of xfs support is there already from Red Hat, thanks to Martin!). To see how we set up the build environment, it would probably be best to post a Makefile that Russell wrote to do most of the hard stuff. We essentially have every RPM from 8.0 + our RPMs in a tree, and symlink them around. One set of symlinks is for all the RPMs needed to build the anaconda environment, the other set of symlinks "teaches" the installer which RPMs are on which CD. Scripts that come with Anaconda do the rest (build the hdlist and build the installer). I'll talk to Russell about publishing the Makefile - I think we'd both be ecstatic if someone else wanted to pick up this work. :) -Eric From owner-linux-xfs@oss.sgi.com Tue Feb 18 17:34:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Feb 2003 17:34:36 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1J1YW3v021947 for ; Tue, 18 Feb 2003 17:34:32 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1J1h7G8018536 for ; Tue, 18 Feb 2003 17:43:07 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id TAA82064; Tue, 18 Feb 2003 19:43:06 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id TAA77732; Tue, 18 Feb 2003 19:43:06 -0600 (CST) Date: Tue, 18 Feb 2003 19:41:46 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Austin Gonyou cc: XFS List Subject: Re: Mount oops from 2.4.20 + xfs-Dec182002 In-Reply-To: <1045605409.8516.91.camel@UberGeek> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2774 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 4717 Lines: 120 xfs_ioerror_alert isn't supposed to be oopsing (i.e. there's no BUG() call in there...) In general, a kdb backtrace will be more interesting than ksymoops output - we get to see function args that way. Better yet, grab us on irc while it's in kdb. You can also type something like "kdb> dmesg n" where "n" is the number of lines from the end of dmesg to print - sometimes a printk has not made it out yet, but it is in the log buffer. -Eric On 18 Feb 2003, Austin Gonyou wrote: > After having to reboot the system from a bad state,(i.e. poweroff), and > then attempting to mount the FC connected disks again, mount caused an > Oops. I've seen this with many different kernel rev's though, then the > conditions are just right. > > > ksymoops 2.4.1 on i686 2.4.20-ag3-p4-debug. Options used > -V (default) > -k /proc/ksyms (default) > -l /proc/modules (default) > -o /lib/modules/2.4.20-ag3-p4-debug/ (default) > -m /boot/System.map (specified) > > Warning (compare_maps): mismatch on symbol md_size , md says f8a6ee80, > /lib/modules/2.4.20-ag3-p4-debug/kernel/drivers/md/md.o says f8a6eca0. > Ignoring /lib/modules/2.4.20-ag3-p4-debug/kernel/drivers/md/md.o entry > Warning (compare_maps): mismatch on symbol mddev_map , md says > f8a6e680, /lib/modules/2.4.20-ag3-p4-debug/kernel/drivers/md/md.o says > f8a6e4a0. Ignoring > /lib/modules/2.4.20-ag3-p4-debug/kernel/drivers/md/md.o entry > Unable to handle kernel NULL pointer dereference at virtual address > 00000058 > c01bdd7e > *pde = 36538001 > Oops: 0000 > CPU: 2 > EIP: 0010:[xfs_ioerror_alert+14/96] Not tainted > EIP: 0010:[] Not tainted > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010206 > eax: 00000000 ebx: 00000000 ecx: f6e0ce80 edx: 01fb8950 > esi: f6274800 edi: 01fb8950 ebp: 00000000 esp: f686db70 > ds: 0018 es: 0018 ss: 0018 > Process mount (pid: 1153, stackpage=f686d000) > Stack: 00000000 0000000c c01acd80 c02d3a97 f6274800 00000000 01fb8950 > 00000000 > 00000000 f6274800 00000000 f61a45c0 f6e0ce80 00000002 c01ad782 f6e0ce80 > f61a45c0 00000002 f61a4480 f6c8f400 00000004 ed1e2090 f6219274 c01ad8c6 > Call Trace: [xlog_recover_do_buffer_trans+304/592] > [xlog_recover_do_trans+82/256] [xlog_recover_commit_trans+38/64] > [xlog_recover_process_data+298/464] [xlog_do_recovery_pass+852/2048] > Call Trace: [] [] [] [] > [] > [] [] [] [] [] > [] > [] [] [] [] [] > [] > [] [] [] [] [] > Code: 8b 58 58 85 c0 8b 4c 24 1c 53 bb 0c 00 00 00 74 07 0f b7 98 > > >>EIP; c01bdd7e <===== > Trace; c01acd80 > Trace; c01ad782 > Trace; c01ad8c6 > Trace; c01ada2a > Trace; c01ae704 > Trace; c01aec34 > Trace; c01aec81 > Trace; c01aee02 > Trace; c01a7f20 > Trace; c01b05cc > Trace; c01af738 > Trace; c01b751f > Trace; c01c8add > Trace; c0131c46 > Trace; c0132163 > Trace; c0145cc1 > Trace; c0145ec4 > Trace; c0158185 > Trace; c015843b > Trace; c015829c > Trace; c0158864 > Trace; c0108c33 > Code; c01bdd7e > 00000000 <_EIP>: > Code; c01bdd7e <===== > 0: 8b 58 58 mov 0x58(%eax),%ebx <===== > Code; c01bdd81 > 3: 85 c0 test %eax,%eax > Code; c01bdd83 > 5: 8b 4c 24 1c mov 0x1c(%esp,1),%ecx > Code; c01bdd87 > 9: 53 push %ebx > Code; c01bdd88 > a: bb 0c 00 00 00 mov $0xc,%ebx > Code; c01bdd8d > f: 74 07 je 18 <_EIP+0x18> c01bdd96 > > Code; c01bdd8f > 11: 0f b7 98 00 00 00 00 movzwl 0x0(%eax),%ebx > > > 2 warnings issued. Results may not be reliable. > > > > > > > -- > Austin Gonyou > Coremetrics, Inc. > > From owner-linux-xfs@oss.sgi.com Tue Feb 18 18:35:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Feb 2003 18:35:50 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1J2Zl3v023451 for ; Tue, 18 Feb 2003 18:35:48 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1J2s0kq016038 for ; Tue, 18 Feb 2003 20:54:00 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id UAA54443; Tue, 18 Feb 2003 20:44:22 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id UAA78343; Tue, 18 Feb 2003 20:44:22 -0600 (CST) Date: Tue, 18 Feb 2003 20:43:02 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Karol Kozimor cc: linux-xfs@oss.sgi.com Subject: Re: XFS and ACPI sleep states compat in 2.5 In-Reply-To: <20030218222854.GA8829@hell.org.pl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2775 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2441 Lines: 64 Hi Karol - I have actually never looked at this, but just doing some hacking-by-pattern-matching looks like maybe this is all that is needed in 2.5, assuming the patch for 2.4 works correctly: --- /usr/tmp/TmpDir.23920-0/linux/fs/xfs/pagebuf/page_buf.c_1.94 Tue Feb 18 20:43:38 2003 +++ linux/fs/xfs/pagebuf/page_buf.c Tue Feb 18 20:34:50 2003 @@ -57,6 +57,7 @@ #include #include #include +#include #include #include @@ -1591,6 +1592,9 @@ INIT_LIST_HEAD(&tmp); do { + if (current->flags & PF_FREEZE) + refrigerator(PF_IOTHREAD); + if (pbd_active == 1) { del_timer(&pb_daemon_timer); pb_daemon_timer.expires = jiffies + -Eric On Tue, 18 Feb 2003, Karol Kozimor wrote: > Hi, > It seems that the XFS code (probably page_buf.c) doesn't have any support > for ACPI sleep states (S3 a.k.a. Suspend-To-RAM, and S4 a.k.a. > Suspend-To-Disk, or software suspend - swsusp). > > The problem seems to concentrate on pagebufd (and pagebuf/0) not beeing > able to enter refrigerator (suspend) properly. Upon entering the S4 state, > 2.5.59-61 (as well as 2.4.x-xfs) suspend subsystem fails to stop those > kernel threads, and refuses to suspend. After such a trial, pagebufd seems > to start sucking up the CPU power greatly, but otherwise works correctly > (at least I think so, I failed to notice any filesystem corruption). The S3 > state (only supported in 2.5) actually disregards the warnings of not being > able to stop pagebufd (part of dmesg attached) and works smoothly, but > after resume the pagebufd still uses up the processor. > > I wouldn't bother the list, if the swsusp and ACPI sleep code wasn't > integrated into the official kernel. Anyway, there exist some patches for > 2.4.20 kernels and a recent version of XFS that deal with that issue > perfectly (at least for me, I haven't ecountered any XFS-related problems > so far using those). One I'm currently using is here: > http://www.sfo.jp/debian/patch/swsusp/swsusp18.xfs-1.2pre4.patch > The patch seems trivial (as most patches for swsusp + journalled > filesystems are), but alas, I'm no kernel hacker and the structure of > page_buf.c in 2.5 has changed substantially, so I'm not able to patch it by > myself. Thanks in advance for any help or hints, > Best regards, > > -- > Karol 'sziwan' Kozimor > sziwan@hell.org.pl > From owner-linux-xfs@oss.sgi.com Tue Feb 18 21:16:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Feb 2003 21:16:56 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1J5Gr3v029150 for ; Tue, 18 Feb 2003 21:16:54 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 195AB186B130; Tue, 18 Feb 2003 21:25:35 -0800 (PST) Date: Tue, 18 Feb 2003 21:25:35 -0800 From: Chris Wedgwood To: Chris Pascoe Cc: linux-xfs@oss.sgi.com Subject: Re: linux/fs/xfs/xfs_log.h:_lsn_cmp not declared __inline__ with gcc 2.95 Message-ID: <20030219052535.GA17685@f00f.org> References: <20030217213323.GA6541@f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2776 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: 557 Lines: 18 On Wed, Feb 19, 2003 at 12:02:58AM +1000, Chris Pascoe wrote: > That sounds like the behaviour that was initially seen that prompted > the fix. I don't think that 2.95.3/4 were safe when I tested back > then, contrary to Seth's experiences. I'm 100% certain that 2.95.4 (Debian something) does NOT to compile this correctly when inlined. > See http://marc.theaimsgroup.com/?l=linux-xfs&m=99535721111774&w=2 for a > description as to what the compiler's doing wrong and why it had to be > un-inlined. Thanks, this is exactly what I was after. --cw From owner-linux-xfs@oss.sgi.com Tue Feb 18 21:33:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Feb 2003 21:33:50 -0800 (PST) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.58.33]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1J5Xl3v030201 for ; Tue, 18 Feb 2003 21:33:47 -0800 Received: from Shiva (shiva [192.168.3.20]) by ishtar.tlinx.org (8.12.6/8.12.2/SuSE Linux 0.6) with ESMTP id h1J5gNLf013084 for ; Tue, 18 Feb 2003 21:42:23 -0800 From: "l.a walsh" To: Subject: been a while before i could get back to this.. Date: Tue, 18 Feb 2003 21:42:24 -0800 Message-ID: <001c01c2d7d9$adaa7620$1403a8c0@sc.tlinx.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h1J5Xm3v030202 X-archive-position: 2777 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: xfs@tlinx.org Precedence: bulk X-list: linux-xfs Content-Length: 2524 Lines: 59 But I did pick up the latest 'all' patch as of 02-05-03. Patched against vanilla 2.4.20. more hwdets@end. I still had an older xfsdump/utils (223+225)...but they really shouldn't do this... I mean xfs shouldn't be soo easily crashable by a user-space program that might send it garbage. I know parameter checking isn't in vogue these days and defensive programming is passe (as well as unprofitable and considered a waste of company resources) but I'm iconclastic on the defensive programing thing in the kernel. the kernel should not trust input from user space programs and should validate parameters to see that they make sense. It's a simple thing...just a simple level 0 dump... OUCH!...I'd be happy to show you the script/command, but it's filled full of binary zeros...AGGG...corruption from trying to do a backup...talking about kickin a girl when she's down...bummer. My backups are getting cobwebbed. Gonna have to break down and setup amanda or tar or something... Fire corruption by trying to do xfsdump level 0...ug Hmmm..that's special...last backup where the file was stored 'bin dir', xfs restore claims it isn't a directory -- just a large 25 meg file. that’s not nice. Next in line is to try new xfsdump/restore, but even if they work, its still bad that xfs dies so easily -- I have no debug output -- it just says found fatal error in file system and must shutdown the fs. After that, nada...zilch... no programs can run...not even sync. (ok, so maybe i should copy my entire root to another disk...but still....*whine whine whine*... -linda relevent hinv: Main memory size: 1048568KiB (1023 MiB) 2 GenuineIntel Pentium III (Coppermine) processors 4 IDE devices: /dev/hda: 195371568 sectors (100030 MB) w/8192KiB Cache, CHS=12161/255/63, UDMA(33) /dev/hdb: ATAPI 40X DVD-ROM drive, 512kB Cache, UDMA(33) /dev/hdc: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=155061/16/63, UDMA(33) /dev/hdd: 117266688 sectors (60041 MB) w/1902KiB Cache, CHS=116336/16/63, UDMA(33) PCI bus devices: Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 3). PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 3). ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 2). IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 1). PCI bridge: Intel Corp. 80960RP [i960 RP Microprocessor/Bridge] (rev 3). SCSI storage controller: Adaptec AHA-2940U2/U2W / 7890/7891 (rev 0). SCSI storage controller: Adaptec AIC-7880U (rev 1). From owner-linux-xfs@oss.sgi.com Wed Feb 19 01:34:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Feb 2003 01:34:30 -0800 (PST) Received: from centauri.artland.com.pl (centauri.artland.com.pl [62.233.164.19]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1J9YI3v005480 for ; Wed, 19 Feb 2003 01:34:21 -0800 Received: (qmail 16526 invoked from network); 19 Feb 2003 09:50:48 -0000 Received: from unknown (HELO ubik) (149.156.124.19) by centauri.artland.com.pl with DES-CBC3-SHA encrypted SMTP; 19 Feb 2003 09:50:48 -0000 Received: from pokryfka by ubik with local (Exim 3.35 #1 (Debian)) id 18lQlN-00035G-00 for ; Wed, 19 Feb 2003 10:43:37 +0100 Date: Wed, 19 Feb 2003 10:43:37 +0100 To: linux-xfs@oss.sgi.com Subject: link problem Message-ID: <20030219094337.GA11835@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.3i From: Michal Adamczak X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) X-archive-position: 2778 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: pokryfka@druid.if.uj.edu.pl Precedence: bulk X-list: linux-xfs Content-Length: 308 Lines: 15 hi do hard links work properly on xfs? when createing one a get a copy instead of a link... please answer on prive as i am not subscribed regards -- Michal Adamczak pokryfka@druid.if.uj.edu.pl nobody knows what happens when you die live as you want - it doesnt mean you'r right that is on facts of life From owner-linux-xfs@oss.sgi.com Wed Feb 19 01:49:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Feb 2003 01:49:25 -0800 (PST) Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1J9nI3v005989 for ; Wed, 19 Feb 2003 01:49:19 -0800 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id h1J9vr2F018199; Wed, 19 Feb 2003 10:57:59 +0100 (CET) Message-Id: <4.3.2.7.2.20030219105030.036d3090@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 19 Feb 2003 10:57:49 +0100 To: "l.a walsh" , From: Seth Mos Subject: Re: been a while before i could get back to this.. In-Reply-To: <001c01c2d7d9$adaa7620$1403a8c0@sc.tlinx.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h1J9nK3v005990 X-archive-position: 2779 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: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 1859 Lines: 50 At 21:42 18-2-2003 -0800, l.a walsh wrote: >Gonna have to break down and setup amanda or tar or something... >Fire corruption by trying to do xfsdump level 0...ug >Hmmm..that's special...last backup where the file was stored 'bin dir', >xfs restore claims it isn't a directory -- just a large 25 meg file. > >that’s not nice. > >Next in line is to try new xfsdump/restore, but even if they work, its >still bad that xfs dies so easily -- > >I have no debug output -- it just says found fatal error in file >system and must shutdown the fs. After that, nada...zilch... >no programs can run...not even sync. (ok, so maybe i should copy >my entire root to another disk...but still....*whine whine whine*... It sounds to me like your filesystem is indeed damaged. I suggest repairing it with xfs_repair. You will probably get the filesystem shutdown when using tar as well. The problem crops up because the moment it tries to read the file it immediatly triggers a filesystem corruption error state. So it (probably) won't matter if you would use tar or xfsdump, it would barf anyhow. Umount the disk, run xfs_repair -n to see what it wants to correct. If it does not say it wants to put your entire filesystem in lost and found, you can run xfs_repair normally and it will attempt to fix the problems. If you are not sure and if the block device is not too large I suggest dumping it with dd to a file so you have some sort of backup just in case xfs_repair would turn it into swiss cheese. dd if=/dev/hda? of=/backup/damaged_fs.bin bs=4096 You can always try running the xfs_repair on this binary file before running it on your real disk. Once the filesystem has been repaired you will probably also be able to normally dump and restoer with xfsdump and or tar. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Feb 19 02:08:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Feb 2003 02:08:44 -0800 (PST) Received: from ente.berdmann.de (frnk-d514e117.dsl.mediaWays.net [213.20.225.23]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1JA8e3v006607 for ; Wed, 19 Feb 2003 02:08:41 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=localhost) by ente.berdmann.de with esmtp (Exim 3.35 #1) id 18lRHw-0004DP-00 for linux-xfs@oss.sgi.com; Wed, 19 Feb 2003 11:17:16 +0100 Received: from 192.168.1.1 ( [192.168.1.1]) as user be@ente.berdmann.de by apollo.berdmann.de with HTTP; Wed, 19 Feb 2003 11:17:16 +0100 Message-ID: <1045649836.3e5359ac6779c@apollo.berdmann.de> Date: Wed, 19 Feb 2003 11:17:16 +0100 From: Bernhard Erdmann To: linux-xfs@oss.sgi.com Subject: xfsprogs RPM of 1.2.0 with files on prefix /usr/local MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 192.168.1.1 X-archive-position: 2780 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: be@berdmann.de Precedence: bulk X-list: linux-xfs Content-Length: 550 Lines: 16 Hi, xfsprogs of SGI XFS 1.2.0 installs with prefix /usr/local instead of /usr. A freshly installed RHL 8.0 with SGI XFS 1.2pre1 and upgraded to XFS 1.2.0 can't execute xfsdump: # xfsdump -J -F -f /dev/null / xfsdump: error while loading shared libraries: libhandle.so.1: cannot open shared object file: No such file or directory libhandle.so.1 is in /usr/local/lib instead of /usr/lib. /usr/local/lib is not by default in /etc/ld.so.conf, so ld can't find libhandle.so.1. Workaround: add /usr/local/lib to /etc/ld.so.conf and execute ldconfig. From owner-linux-xfs@oss.sgi.com Wed Feb 19 02:09:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Feb 2003 02:09:45 -0800 (PST) Received: from ente.berdmann.de (frnk-d514e117.dsl.mediaWays.net [213.20.225.23]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1JA9g3v006954 for ; Wed, 19 Feb 2003 02:09:43 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=localhost) by ente.berdmann.de with esmtp (Exim 3.35 #1) id 18lRIu-0004Db-00; Wed, 19 Feb 2003 11:18:16 +0100 Received: from 192.168.1.1 ( [192.168.1.1]) as user be@ente.berdmann.de by apollo.berdmann.de with HTTP; Wed, 19 Feb 2003 11:18:16 +0100 Message-ID: <1045649896.3e5359e8903cb@apollo.berdmann.de> Date: Wed, 19 Feb 2003 11:18:16 +0100 From: Bernhard Erdmann To: Michal Adamczak Cc: linux-xfs@oss.sgi.com Subject: Re: link problem References: <20030219094337.GA11835@localhost> In-Reply-To: <20030219094337.GA11835@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 192.168.1.1 X-archive-position: 2781 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: be@berdmann.de Precedence: bulk X-list: linux-xfs Content-Length: 200 Lines: 12 Zitat von Michal Adamczak : > hi > do hard links work properly on xfs? > > when createing one a get a copy instead of a link... It does work. Just do ln file1 file2 From owner-linux-xfs@oss.sgi.com Wed Feb 19 03:22:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Feb 2003 03:22:54 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1JBMk3v010539 for ; Wed, 19 Feb 2003 03:22:47 -0800 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id A9AB9AC4D; Wed, 19 Feb 2003 12:41:07 +0100 (CET) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id 18A56190D8; Wed, 19 Feb 2003 12:41:08 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id B6E1C30881D; Wed, 19 Feb 2003 12:31:23 +0100 (CET) Message-ID: <3E536B0B.CA3336DF@ch.sauter-bc.com> Date: Wed, 19 Feb 2003 12:31:23 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.22-6.2.3 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Seth Mos Cc: Eric Sandeen , John Haverty , linux-xfs@oss.sgi.com Subject: Re: Please pay attention to RedHat 7.x, other stable linuxkernels (2.4) please ;p References: <4.3.2.7.2.20030218091120.04996ef0@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2782 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: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Content-Length: 1422 Lines: 43 Seth, Thanks for your effort building updated RedHat kernel. I found the new ones on http://iserv.nl/files/xfs/2.4.18-24/ but coudn't find the source RPM. Is it really exactly 1.2pre5 only with the name changed? Simon Seth Mos schrieb: > > At 20:55 17-2-2003 -0600, Eric Sandeen wrote: > >On Mon, 17 Feb 2003, John Haverty wrote: > > > >I imagine that a backport to a Red Hat 7.3 kernel would not be too bad, > >perhaps if you or someone in the Linux community can do this, it would > >be well received. > > The kernels from my site are built under Red Hat 7.1 and also reflect the > latest errata kernel. > They are based on the 2.4.18-24 errata from Red Hat and also include the > XFS 1.2pre5 patches. > > Although the name still says pre5 it is ofcourse the 1.2 code. > http://iserv.nl/files/xfs/2.4.18-24/ > > So if you need the Red Hat 7.x variant this would be your best bet. > > I am rebuilding this kernel with the proper 1.2 name on a Red Hat 7.3 box > at the moment. But this could take a while (half a day). > > There might also be a new errata kernel coming soon which *should* fix > numerous network problems related to gigabit ethernet. Keep in mind however > that the last 4 errata release from Red Hat which should have fixed this > still have not solved the problem to date. > There was -17, -18, -19 and now -24. > > Cheers > > -- > Seth > It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Feb 19 06:38:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Feb 2003 06:38:59 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1JEcs3v023021 for ; Wed, 19 Feb 2003 06:38:55 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1JElWKp017666 for ; Wed, 19 Feb 2003 06:47:32 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA70217; Wed, 19 Feb 2003 08:47:31 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id IAA11863; Wed, 19 Feb 2003 08:47:31 -0600 (CST) Date: Wed, 19 Feb 2003 08:46:06 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Karol Kozimor cc: linux-xfs@oss.sgi.com Subject: Re: XFS and ACPI sleep states compat in 2.5 In-Reply-To: <20030219100207.GA15374@hell.org.pl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2783 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 878 Lines: 25 On Wed, 19 Feb 2003, Karol Kozimor wrote: > There seems, however, to be an issue loosely connected with suspend. Does this behave differently with the patch vs. without? > Suspending and resuming almost universally seems to trigger the strange > ,,Unknown error 990'' problems upon any file access. Are there any messages in the system logs before/after this? 990 is "EFSCORRUPTED" out of xfs, perhaps the filesystem has shut down. There should be some error messages in the logs, if EFSCORRUPTED is being generated. I can try to take a look at this, but my problem with ACPI in the past has always been finding a machine which implements ACPI well enough in the bios that it has -any- hope of working correctly.... If the patch I posted doesn't make this any -worse- then I'll go ahead and check it in; if it is causing this problem, perhaps I should hold off. -Eric From owner-linux-xfs@oss.sgi.com Wed Feb 19 07:08:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Feb 2003 07:09:01 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1JF8p3v024918 for ; Wed, 19 Feb 2003 07:08:51 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1JFHSKp022113 for ; Wed, 19 Feb 2003 07:17:28 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA54608 for ; Wed, 19 Feb 2003 09:17:27 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA43585 for ; Wed, 19 Feb 2003 09:17:25 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h1JMXRN02697 for linux-xfs@oss.sgi.com; Wed, 19 Feb 2003 17:33:27 -0500 Resent-Message-Id: <200302192233.h1JMXRN02697@taclab54.munich.sgi.com> Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA46869 for ; Wed, 19 Feb 2003 09:14:09 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id h1JFE7ok11437583 for ; Wed, 19 Feb 2003 07:14:07 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id h1JFBIw0001107 for ; Wed, 19 Feb 2003 16:11:18 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id h1JFBIa7001106 for hch@sgi.com; Wed, 19 Feb 2003 16:11:18 +0100 Date: Wed, 19 Feb 2003 16:11:18 +0100 From: Christoph Hellwig Message-Id: <200302191511.h1JFBIa7001106@lab343.munich.sgi.com> Subject: TAKE - Merge up to Linux 2.5.62 To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Wed, 19 Feb 2003 17:33:27 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 2784 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 47452 Lines: 1222 Date: Wed Feb 19 07:07:52 PST 2003 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:139991a linux/drivers/input/misc/98spkr.c - 1.1 linux/scripts/modpost.h - 1.1 linux/drivers/cpufreq/proc_intf.c - 1.1 linux/arch/i386/oprofile/op_model_p4.c - 1.1 linux/Documentation/sound/rme96xx - 1.1 linux/drivers/cpufreq/freq_table.c - 1.1 linux/drivers/cpufreq/Makefile - 1.1 linux/scripts/modpost.c - 1.1 linux/scripts/mk_elfconfig.c - 1.1 linux/scripts/file2alias.c - 1.1 linux/drivers/cpufreq/Kconfig - 1.1 linux/fs/ext3/xattr_trusted.c - 1.1 linux/scripts/empty.c - 1.1 linux/scripts/Makefile.modpost - 1.1 linux/drivers/char/agp/alpha-agp.c - 1.1 linux/fs/ext2/xattr_trusted.c - 1.1 linux/arch/i386/kernel/cpu/cpufreq/powernow-k7.c - 1.1 linux/drivers/ieee1394/raw1394-private.h - 1.1 linux/net/sctp/ssnmap.c - 1.1 linux/arch/ppc64/kernel/scanlog.c - 1.1 linux/include/asm-x86_64/mmsegment.h - 1.1 linux/include/asm-x86_64/mmzone.h - 1.1 linux/include/asm-x86_64/numa.h - 1.1 linux/include/asm-x86_64/numnodes.h - 1.1 linux/arch/x86_64/boot/mtools.conf.in - 1.1 linux/drivers/acpi/sleep/sleep.h - 1.1 linux/drivers/acpi/sleep/proc.c - 1.1 linux/drivers/acpi/sleep/poweroff.c - 1.1 linux/drivers/acpi/sleep/main.c - 1.1 linux/drivers/acpi/sleep/Makefile - 1.1 linux/net/ipv6/xfrm_policy.c - 1.1 linux/arch/x86_64/kernel/wakeup.S - 1.1 linux/drivers/ieee1394/ieee1394-ioctl.h - 1.1 linux/drivers/usb/input/hid-tmff.c - 1.1 linux/drivers/char/watchdog/cpu5wdt.c - 1.1 linux/arch/i386/kernel/cpu/cpufreq/powernow-k7.h - 1.1 linux/include/linux/vermagic.h - 1.1 linux/arch/x86_64/mm/k8topology.c - 1.1 linux/include/linux/mod_devicetable.h - 1.1 linux/drivers/net/tokenring/proteon.c - 1.1 linux/drivers/eisa/pci_eisa.c - 1.1 linux/drivers/net/typhoon-firmware.h - 1.1 linux/drivers/net/tokenring/skisa.c - 1.1 linux/drivers/eisa/virtual_root.c - 1.1 linux/drivers/net/typhoon.c - 1.1 linux/arch/i386/kernel/acpi/wakeup.S - 1.1 linux/drivers/net/typhoon.h - 1.1 linux/arch/x86_64/mm/numa.c - 1.1 linux/arch/i386/kernel/acpi/boot.c - 1.1 linux/arch/i386/kernel/acpi/Makefile - 1.1 linux/arch/i386/kernel/acpi/sleep.c - 1.1 linux/scripts/Makefile - 1.15 linux/net/x25/x25_link.c - 1.13 linux/net/unix/sysctl_net_unix.c - 1.7 linux/net/sunrpc/xprt.c - 1.39 linux/net/sunrpc/sysctl.c - 1.9 linux/net/sunrpc/sched.c - 1.36 linux/net/sunrpc/clnt.c - 1.28 linux/net/sched/sch_cbq.c - 1.15 linux/net/netsyms.c - 1.60 linux/net/irda/wrapper.c - 1.13 linux/net/irda/qos.c - 1.19 linux/net/irda/irsysctl.c - 1.12 linux/net/irda/irlap_event.c - 1.26 linux/net/ipv6/sysctl_net_ipv6.c - 1.5 linux/net/ipv6/Makefile - 1.11 linux/net/ipv4/tcp_output.c - 1.35 linux/net/ipv4/sysctl_net_ipv4.c - 1.17 linux/net/ipv4/proc.c - 1.17 linux/net/ipv4/ipip.c - 1.28 linux/net/ipv4/ip_gre.c - 1.27 linux/net/core/sysctl_net_core.c - 1.6 linux/net/core/rtnetlink.c - 1.15 linux/net/core/dev.c - 1.68 linux/net/ax25/sysctl_net_ax25.c - 1.6 linux/mm/vmscan.c - 1.124 linux/mm/swap_state.c - 1.58 linux/mm/slab.c - 1.50 linux/mm/mmap.c - 1.71 linux/mm/filemap.c - 1.148 linux/lib/vsprintf.c - 1.21 linux/kernel/time.c - 1.15 linux/kernel/sys.c - 1.47 linux/kernel/softirq.c - 1.33 linux/kernel/signal.c - 1.49 linux/kernel/sched.c - 1.94 linux/kernel/module.c - 1.38 linux/kernel/ksyms.c - 1.181 linux/kernel/kmod.c - 1.29 linux/kernel/fork.c - 1.83 linux/kernel/exit.c - 1.64 linux/kernel/dma.c - 1.9 linux/include/net/irda/wrapper.h - 1.8 linux/include/net/irda/irda_device.h - 1.15 linux/include/net/af_unix.h - 1.6 linux/include/linux/wireless.h - 1.11 linux/include/linux/sunrpc/clnt.h - 1.15 linux/include/linux/signal.h - 1.12 linux/include/linux/sched.h - 1.98 linux/include/linux/ptrace.h - 1.7 linux/include/linux/pci.h - 1.72 linux/include/linux/pagemap.h - 1.52 linux/include/linux/module.h - 1.44 linux/include/linux/kmod.h - 1.11 linux/include/linux/keyboard.h - 1.5 linux/include/linux/kbd_kern.h - 1.11 linux/include/linux/hfs_sysdep.h - 1.13 linux/include/linux/fs.h - 1.205 linux/include/linux/dcache.h - 1.33 linux/include/asm-sparc64/system.h - 1.27 linux/include/asm-sparc64/signal.h - 1.8 linux/include/asm-sparc64/ptrace.h - 1.4 linux/include/asm-sparc/system.h - 1.19 linux/include/asm-sparc/signal.h - 1.6 linux/include/asm-sparc/page.h - 1.20 linux/include/asm-ppc/unistd.h - 1.31 linux/include/asm-ppc/signal.h - 1.9 linux/include/asm-mips/signal.h - 1.7 linux/include/asm-i386/signal.h - 1.9 linux/include/asm-i386/semaphore.h - 1.18 linux/include/asm-i386/processor.h - 1.48 linux/include/asm-i386/pgtable.h - 1.42 linux/include/asm-i386/page.h - 1.34 linux/include/asm-i386/msr.h - 1.18 linux/include/asm-i386/fixmap.h - 1.15 linux/include/asm-arm/signal.h - 1.8 linux/include/asm-arm/proc-armv/system.h - 1.17 linux/include/asm-arm/proc-armv/processor.h - 1.13 linux/include/asm-alpha/unistd.h - 1.28 linux/include/asm-alpha/signal.h - 1.7 linux/include/asm-alpha/io.h - 1.21 linux/fs/ufs/truncate.c - 1.22 linux/fs/ufs/inode.c - 1.29 linux/fs/ufs/ialloc.c - 1.18 linux/fs/ufs/dir.c - 1.22 linux/fs/ufs/balloc.c - 1.18 linux/fs/sysv/inode.c - 1.37 linux/fs/qnx4/inode.c - 1.42 linux/fs/proc/generic.c - 1.35 linux/fs/proc/base.c - 1.48 linux/fs/proc/array.c - 1.57 linux/fs/ntfs/super.c - 1.23 linux/fs/nfsd/nfssvc.c - 1.31 linux/fs/nfsd/export.c - 1.47 linux/fs/nfs/nfs3xdr.c - 1.21 linux/fs/nfs/inode.c - 1.63 linux/fs/ncpfs/sock.c - 1.18 linux/fs/namei.c - 1.66 linux/fs/minix/inode.c - 1.40 linux/fs/locks.c - 1.37 linux/fs/lockd/svc.c - 1.25 linux/fs/lockd/clntlock.c - 1.14 linux/fs/ext2/super.c - 1.43 linux/fs/ext2/inode.c - 1.65 linux/fs/ext2/ialloc.c - 1.34 linux/fs/ext2/balloc.c - 1.27 linux/fs/ext2/acl.c - 1.9 linux/fs/ext2/Makefile - 1.10 linux/fs/exec.c - 1.78 linux/fs/dcache.c - 1.46 linux/fs/buffer.c - 1.147 linux/fs/binfmt_aout.c - 1.30 linux/drivers/scsi/wd7000.c - 1.22 linux/drivers/scsi/ultrastor.c - 1.18 linux/drivers/scsi/u14-34f.c - 1.30 linux/drivers/scsi/sym53c416.c - 1.16 linux/drivers/scsi/st.c - 1.62 linux/drivers/scsi/seagate.c - 1.23 linux/drivers/scsi/scsi_error.c - 1.39 linux/drivers/scsi/ppa.c - 1.22 linux/drivers/scsi/mca_53c9x.c - 1.13 linux/drivers/scsi/imm.c - 1.22 linux/drivers/scsi/ibmmca.c - 1.22 linux/drivers/scsi/fd_mcs.c - 1.12 linux/drivers/scsi/eata.c - 1.33 linux/drivers/scsi/aha1740.c - 1.15 linux/drivers/scsi/aha1542.c - 1.32 linux/drivers/scsi/NCR53c406a.c - 1.18 linux/drivers/scsi/NCR53C9x.c - 1.22 linux/drivers/sbus/char/envctrl.c - 1.19 linux/drivers/pci/quirks.c - 1.35 linux/drivers/pci/pci.c - 1.65 linux/drivers/net/via-rhine.c - 1.40 linux/drivers/net/sunqe.c - 1.24 linux/drivers/net/sunbmac.c - 1.25 linux/drivers/net/shaper.c - 1.23 linux/drivers/net/rrunner.c - 1.25 linux/drivers/net/pcnet32.c - 1.40 linux/drivers/net/hamradio/scc.c - 1.30 linux/drivers/net/hamradio/baycom_epp.c - 1.26 linux/drivers/net/eexpress.c - 1.23 linux/drivers/net/eepro100.c - 1.55 linux/drivers/net/depca.c - 1.25 linux/drivers/net/bmac.c - 1.23 linux/drivers/net/Space.c - 1.41 linux/drivers/net/Makefile - 1.68 linux/drivers/net/3c59x.c - 1.45 linux/drivers/net/3c509.c - 1.42 linux/drivers/macintosh/adb.c - 1.23 linux/drivers/char/vt.c - 1.32 linux/drivers/char/tty_io.c - 1.62 linux/drivers/char/specialix.c - 1.17 linux/drivers/char/rtc.c - 1.37 linux/drivers/char/riscom8.c - 1.17 linux/drivers/char/random.c - 1.38 linux/drivers/char/nvram.c - 1.27 linux/drivers/char/n_tty.c - 1.18 linux/drivers/char/misc.c - 1.33 linux/drivers/char/keyboard.c - 1.33 linux/drivers/char/ftape/lowlevel/ftape-read.c - 1.4 linux/drivers/cdrom/cdrom.c - 1.52 linux/drivers/block/nbd.c - 1.51 linux/drivers/block/loop.c - 1.78 linux/drivers/block/ll_rw_blk.c - 1.127 linux/drivers/block/genhd.c - 1.47 linux/drivers/acorn/scsi/queue.c - 1.9 linux/drivers/acorn/scsi/fas216.c - 1.18 linux/drivers/acorn/scsi/acornscsi.c - 1.24 linux/drivers/acorn/block/fd1772.c - 1.31 linux/drivers/Makefile - 1.42 linux/arch/sparc64/kernel/systbls.S - 1.40 linux/arch/sparc64/kernel/sys_sparc32.c - 1.69 linux/arch/sparc64/kernel/signal32.c - 1.33 linux/arch/sparc64/kernel/signal.c - 1.31 linux/arch/sparc64/kernel/irq.c - 1.31 linux/arch/sparc64/kernel/ioctl32.c - 1.66 linux/arch/sparc64/kernel/init_task.c - 1.10 linux/arch/sparc/mm/init.c - 1.35 linux/arch/sparc/kernel/signal.c - 1.34 linux/arch/sparc/kernel/init_task.c - 1.9 linux/arch/sparc/boot/Makefile - 1.13 linux/arch/sparc/Makefile - 1.24 linux/arch/ppc/kernel/signal.c - 1.23 linux/arch/ppc/kernel/setup.c - 1.54 linux/arch/ppc/kernel/ptrace.c - 1.19 linux/arch/ppc/kernel/process.c - 1.47 linux/arch/ppc/kernel/ppc_ksyms.c - 1.54 linux/arch/ppc/kernel/misc.S - 1.54 linux/arch/ppc/kernel/irq.c - 1.43 linux/arch/ppc/kernel/head.S - 1.41 linux/arch/mips/kernel/sysmips.c - 1.9 linux/arch/mips/kernel/signal.c - 1.19 linux/arch/mips/kernel/irixsig.c - 1.12 linux/arch/m68k/kernel/traps.c - 1.18 linux/arch/m68k/kernel/signal.c - 1.21 linux/arch/i386/math-emu/fpu_entry.c - 1.7 linux/arch/i386/kernel/vm86.c - 1.25 linux/arch/i386/kernel/traps.c - 1.72 linux/arch/i386/kernel/smp.c - 1.54 linux/arch/i386/kernel/signal.c - 1.34 linux/arch/i386/kernel/ptrace.c - 1.28 linux/arch/i386/kernel/process.c - 1.66 linux/arch/i386/kernel/io_apic.c - 1.53 linux/arch/i386/kernel/apm.c - 1.58 linux/arch/i386/kernel/Makefile - 1.44 linux/arch/i386/Makefile - 1.47 linux/arch/arm/lib/backtrace.S - 1.11 linux/arch/arm/kernel/traps.c - 1.34 linux/arch/arm/kernel/signal.c - 1.30 linux/arch/arm/kernel/ptrace.c - 1.25 linux/arch/arm/kernel/irq.c - 1.28 linux/arch/arm/kernel/init_task.c - 1.12 linux/arch/arm/kernel/ecard.c - 1.27 linux/arch/alpha/lib/csum_ipv6_magic.S - 1.5 linux/arch/alpha/kernel/signal.c - 1.23 linux/Makefile - 1.239 linux/MAINTAINERS - 1.132 linux/Documentation/CodingStyle - 1.5 linux/drivers/net/irda/smc-ircc.c - 1.28 linux/drivers/acorn/char/keyb_arc.c - 1.11 linux/arch/mips/baget/vacserial.c - 1.14 linux/drivers/net/arlan.c - 1.24 linux/drivers/net/arlan-proc.c - 1.9 linux/kernel/ptrace.c - 1.31 linux/drivers/net/hamradio/yam.c - 1.22 linux/drivers/char/sx.c - 1.30 linux/fs/partitions/check.c - 1.64 linux/drivers/net/sis900.c - 1.40 linux/drivers/net/fc/iph5526.c - 1.23 linux/drivers/atm/nicstar.c - 1.21 linux/arch/arm/vmlinux-armv.lds.in - 1.25 linux/arch/alpha/kernel/pci.c - 1.29 linux/drivers/block/DAC960.c - 1.65 linux/arch/sparc64/kernel/power.c - 1.14 linux/arch/sh/kernel/signal.c - 1.17 linux/arch/sh/kernel/process.c - 1.23 linux/drivers/scsi/ips.h - 1.22 linux/drivers/scsi/ips.c - 1.36 linux/net/irda/ircomm/ircomm_tty.c - 1.26 linux/net/irda/ircomm/ircomm_param.c - 1.14 linux/include/asm-sh/signal.h - 1.6 linux/drivers/pcmcia/tcic.c - 1.20 linux/drivers/pcmcia/i82365.c - 1.32 linux/drivers/pcmcia/cs.c - 1.33 linux/include/pcmcia/ss.h - 1.10 linux/fs/udf/inode.c - 1.36 linux/include/linux/spinlock.h - 1.24 linux/drivers/net/starfire.c - 1.30 linux/drivers/net/tokenring/Makefile - 1.14 linux/arch/i386/kernel/smpboot.c - 1.57 linux/include/linux/pci_ids.h - 1.83 linux/include/linux/pc_keyb.h - 1.2 linux/drivers/net/tokenring/tms380tr.h - 1.6 linux/drivers/net/tokenring/tms380tr.c - 1.19 linux/drivers/net/pcmcia/xirc2ps_cs.c - 1.22 linux/fs/proc/proc_misc.c - 1.54 linux/arch/ppc/kernel/head_4xx.S - 1.13 linux/include/linux/agp_backend.h - 1.26 linux/drivers/net/aironet4500_proc.c - 1.16 linux/drivers/char/agp/Makefile - 1.14 linux/drivers/char/agp/agp.h - 1.34 linux/drivers/i2c/i2c-core.c - 1.21 linux/drivers/pcmcia/yenta.c - 1.38 linux/drivers/pcmcia/pci_socket.h - 1.8 linux/drivers/pcmcia/pci_socket.c - 1.14 linux/arch/i386/kernel/acpi.c - 1.34 linux/include/linux/input.h - 1.24 linux/include/linux/com20020.h - 1.4 linux/drivers/net/arcnet/com20020.c - 1.6 linux/drivers/net/arcnet/com20020-pci.c - 1.15 linux/drivers/net/tokenring/smctr.c - 1.18 linux/net/sched/sch_gred.c - 1.12 linux/drivers/ieee1394/raw1394.h - 1.7 linux/drivers/ieee1394/raw1394.c - 1.23 linux/drivers/ieee1394/pcilynx.h - 1.11 linux/drivers/ieee1394/pcilynx.c - 1.26 linux/drivers/ieee1394/ieee1394_core.c - 1.27 linux/drivers/ieee1394/ohci1394.h - 1.18 linux/drivers/ieee1394/ohci1394.c - 1.27 linux/arch/i386/kernel/apic.c - 1.39 linux/drivers/ieee1394/hosts.h - 1.14 linux/drivers/ieee1394/hosts.c - 1.16 linux/drivers/ieee1394/highlevel.h - 1.6 linux/arch/i386/kernel/mpparse.c - 1.33 linux/drivers/char/moxa.c - 1.16 linux/drivers/char/mxser.c - 1.22 linux/drivers/ieee1394/Makefile - 1.19 linux/drivers/ieee1394/highlevel.c - 1.11 linux/drivers/net/tokenring/madgemc.c - 1.8 linux/arch/ia64/kernel/signal.c - 1.22 linux/kernel/pm.c - 1.12 linux/include/linux/rtc.h - 1.8 linux/include/asm-ia64/signal.h - 1.9 linux/drivers/net/8139too.c - 1.49 linux/arch/arm/mm/consistent.c - 1.14 linux/fs/devfs/base.c - 1.51 linux/drivers/char/nwflash.c - 1.16 linux/include/asm-mips64/signal.h - 1.5 linux/arch/mips64/kernel/signal32.c - 1.14 linux/arch/mips64/kernel/signal.c - 1.12 linux/net/econet/af_econet.c - 1.17 linux/include/linux/usb.h - 1.54 linux/drivers/block/elevator.c - 1.30 linux/drivers/net/wan/comx-hw-mixcom.c - 1.11 linux/drivers/net/wan/comx-hw-comx.c - 1.10 linux/net/ipv4/netfilter/iptable_mangle.c - 1.11 linux/net/ipv4/netfilter/iptable_filter.c - 1.6 linux/net/ipv4/netfilter/ip_queue.c - 1.17 linux/net/ipv4/netfilter/ip_nat_rule.c - 1.8 linux/net/ipv4/netfilter/ip_nat_ftp.c - 1.11 linux/net/ipv4/netfilter/ip_conntrack_core.c - 1.17 linux/fs/nfs/nfs3proc.c - 1.21 linux/drivers/char/rio/rioroute.c - 1.5 linux/drivers/char/rio/rioboot.c - 1.7 linux/include/asm-s390/signal.h - 1.5 linux/drivers/s390/block/dasd_eckd.c - 1.13 linux/include/asm-arm/arch-sa1100/time.h - 1.7 linux/arch/s390/kernel/signal.c - 1.16 linux/net/ipv6/netfilter/ip6table_filter.c - 1.5 linux/include/asm-mips64/sn/nmi.h - 1.3 linux/include/asm-mips64/sn/launch.h - 1.3 linux/fs/xfs/linux/xfs_iops.c - 1.192 linux/Documentation/filesystems/Locking - 1.21 linux/drivers/usb/storage/usb.c - 1.36 linux/drivers/acpi/tables/tbxface.c - 1.16 linux/drivers/acpi/tables/tbutils.c - 1.17 linux/drivers/acpi/tables/tbinstal.c - 1.18 linux/drivers/acpi/tables/tbget.c - 1.18 linux/drivers/acpi/resources/rsxface.c - 1.12 linux/drivers/acpi/resources/rsutils.c - 1.14 linux/drivers/acpi/resources/rsmisc.c - 1.11 linux/drivers/acpi/resources/rsmemory.c - 1.11 linux/drivers/acpi/resources/rslist.c - 1.13 linux/drivers/acpi/resources/rsirq.c - 1.14 linux/drivers/acpi/resources/rsio.c - 1.13 linux/drivers/acpi/resources/rsdump.c - 1.14 linux/drivers/acpi/resources/rscreate.c - 1.16 linux/drivers/acpi/resources/rscalc.c - 1.16 linux/drivers/acpi/resources/rsaddr.c - 1.12 linux/drivers/acpi/parser/psxface.c - 1.15 linux/drivers/acpi/parser/pswalk.c - 1.12 linux/drivers/acpi/parser/psutils.c - 1.15 linux/drivers/acpi/parser/pstree.c - 1.13 linux/drivers/acpi/parser/psscope.c - 1.11 linux/drivers/acpi/parser/psparse.c - 1.19 linux/drivers/acpi/parser/psopcode.c - 1.18 linux/drivers/acpi/parser/psargs.c - 1.17 linux/drivers/acpi/namespace/nsxfobj.c - 1.17 linux/drivers/acpi/namespace/nsxfname.c - 1.14 linux/drivers/acpi/namespace/nswalk.c - 1.11 linux/drivers/acpi/namespace/nsutils.c - 1.18 linux/arch/arm/kernel/ptrace.h - 1.5 linux/drivers/acpi/namespace/nssearch.c - 1.18 linux/drivers/acpi/namespace/nsobject.c - 1.16 linux/drivers/acpi/namespace/nsnames.c - 1.16 linux/drivers/acpi/namespace/nsload.c - 1.18 linux/drivers/acpi/namespace/nseval.c - 1.18 linux/drivers/acpi/namespace/nsalloc.c - 1.16 linux/drivers/acpi/namespace/nsaccess.c - 1.18 linux/fs/jffs/intrep.c - 1.21 linux/drivers/acpi/hardware/hwregs.c - 1.17 linux/drivers/acpi/hardware/hwgpe.c - 1.14 linux/drivers/acpi/hardware/hwacpi.c - 1.15 linux/drivers/acpi/events/evxfregn.c - 1.15 linux/drivers/acpi/events/evxfevnt.c - 1.14 linux/drivers/acpi/events/evxface.c - 1.17 linux/drivers/acpi/events/evsci.c - 1.12 linux/drivers/acpi/events/evrgnini.c - 1.15 linux/drivers/acpi/events/evregion.c - 1.17 linux/drivers/acpi/events/evmisc.c - 1.16 linux/drivers/acpi/events/evevent.c - 1.20 linux/drivers/acpi/ec.c - 1.17 linux/drivers/acpi/dispatcher/dswstate.c - 1.18 linux/drivers/acpi/dispatcher/dswscope.c - 1.13 linux/drivers/acpi/dispatcher/dswload.c - 1.21 linux/drivers/acpi/dispatcher/dswexec.c - 1.16 linux/drivers/acpi/dispatcher/dsutils.c - 1.18 linux/drivers/acpi/dispatcher/dsopcode.c - 1.19 linux/drivers/acpi/dispatcher/dsobject.c - 1.22 linux/drivers/acpi/dispatcher/dsmthdat.c - 1.16 linux/drivers/acpi/dispatcher/dsmethod.c - 1.16 linux/drivers/acpi/dispatcher/dsfield.c - 1.16 linux/drivers/acpi/Makefile - 1.24 linux/drivers/ieee1394/video1394.c - 1.25 linux/drivers/ieee1394/video1394.h - 1.7 linux/drivers/mtd/mtdblock.c - 1.30 linux/include/linux/serio.h - 1.9 linux/kernel/user.c - 1.7 linux/drivers/media/video/tuner-3036.c - 1.5 linux/drivers/media/video/saa7110.c - 1.8 linux/drivers/media/video/saa5249.c - 1.13 linux/drivers/media/video/msp3400.c - 1.15 linux/drivers/media/video/bttv-cards.c - 1.17 linux/drivers/input/mousedev.c - 1.17 linux/drivers/input/joydev.c - 1.15 linux/drivers/input/input.c - 1.16 linux/drivers/acpi/namespace/nsdump.c - 1.17 linux/drivers/block/cciss.c - 1.51 linux/drivers/macintosh/adbhid.c - 1.10 linux/drivers/md/md.c - 1.68 linux/drivers/scsi/cpqfcTSworker.c - 1.14 linux/drivers/media/video/tvaudio.c - 1.14 linux/net/irda/irsyms.c - 1.11 linux/include/asm-i386/module.h - 1.5 linux/arch/parisc/kernel/syscall.S - 1.7 linux/arch/parisc/kernel/signal.c - 1.8 linux/arch/parisc/hpux/fs.c - 1.6 linux/drivers/acpi/tables/tbconvrt.c - 1.15 linux/drivers/acpi/tables/tbxfroot.c - 1.13 linux/drivers/acpi/namespace/nsinit.c - 1.15 linux/drivers/acpi/power.c - 1.13 linux/include/asm-ia64/sn/ioerror.h - 1.5 linux/arch/ia64/sn/io/io.c - 1.5 linux/include/asm-ia64/sn/router.h - 1.4 linux/drivers/acpi/acpi_ksyms.c - 1.16 linux/fs/reiserfs/resize.c - 1.10 linux/drivers/acpi/hardware/hwsleep.c - 1.14 linux/drivers/acpi/hardware/hwtimer.c - 1.12 linux/fs/reiserfs/journal.c - 1.38 linux/fs/reiserfs/hashes.c - 1.6 linux/net/ipv6/netfilter/ip6table_mangle.c - 1.5 linux/arch/s390x/kernel/signal32.c - 1.11 linux/arch/s390x/kernel/signal.c - 1.13 linux/arch/s390x/kernel/linux32.c - 1.24 linux/include/asm-s390x/signal.h - 1.6 linux/arch/cris/kernel/signal.c - 1.10 linux/arch/s390x/kernel/entry.S - 1.20 linux/arch/s390x/kernel/wrapper32.S - 1.12 linux/include/asm-cris/signal.h - 1.3 linux/drivers/pcmcia/hd64465_ss.c - 1.8 linux/drivers/net/tokenring/tmsisa.c - 1.7 linux/include/asm-arm/mach/irq.h - 1.7 linux/drivers/net/sungem.c - 1.24 linux/drivers/sbus/char/bbc_envctrl.c - 1.4 linux/Documentation/s390/Debugging390.txt - 1.7 linux/drivers/char/ec3104_keyb.c - 1.3 linux/arch/arm/mach-footbridge/irq.c - 1.5 linux/arch/cris/drivers/usb-host.c - 1.13 linux/drivers/net/wireless/orinoco.c - 1.14 linux/arch/ppc/boot/utils/mknote.c - 1.3 linux/arch/alpha/mm/numa.c - 1.9 linux/arch/ppc/boot/utils/hack-coff.c - 1.3 linux/arch/ppc/boot/utils/addnote.c - 1.3 linux/arch/cris/drivers/eeprom.c - 1.8 linux/arch/ppc/boot/common/misc-common.c - 1.9 linux/net/bluetooth/af_bluetooth.c - 1.10 linux/net/bluetooth/hci_core.c - 1.12 linux/drivers/mtd/maps/sa1100-flash.c - 1.6 linux/drivers/mtd/chips/jedec.c - 1.6 linux/drivers/acpi/executer/exstore.c - 1.16 linux/drivers/acpi/utilities/utxface.c - 1.10 linux/drivers/acpi/utilities/utobject.c - 1.11 linux/drivers/acpi/utilities/utmisc.c - 1.14 linux/drivers/acpi/utilities/utinit.c - 1.11 linux/drivers/acpi/utilities/utglobal.c - 1.17 linux/drivers/acpi/utilities/uteval.c - 1.12 linux/drivers/acpi/utilities/utdelete.c - 1.12 linux/drivers/acpi/utilities/utdebug.c - 1.12 linux/drivers/acpi/utilities/utcopy.c - 1.15 linux/drivers/acpi/utilities/utalloc.c - 1.9 linux/drivers/acpi/executer/exutils.c - 1.13 linux/drivers/acpi/executer/exsystem.c - 1.8 linux/drivers/acpi/executer/exstorob.c - 1.11 linux/drivers/acpi/executer/exstoren.c - 1.12 linux/drivers/acpi/executer/exconfig.c - 1.12 linux/drivers/acpi/executer/exconvrt.c - 1.14 linux/drivers/acpi/executer/excreate.c - 1.13 linux/drivers/acpi/executer/exdump.c - 1.16 linux/drivers/acpi/executer/exfield.c - 1.10 linux/drivers/acpi/executer/exfldio.c - 1.13 linux/drivers/acpi/executer/exmisc.c - 1.14 linux/drivers/acpi/executer/exmutex.c - 1.9 linux/drivers/acpi/executer/exnames.c - 1.9 linux/drivers/acpi/executer/exprep.c - 1.13 linux/drivers/acpi/executer/exregion.c - 1.11 linux/drivers/acpi/executer/exresnte.c - 1.16 linux/drivers/acpi/executer/exresolv.c - 1.14 linux/drivers/acpi/executer/exresop.c - 1.16 linux/fs/sysv/itree.c - 1.11 linux/drivers/ieee1394/sbp2.c - 1.19 linux/drivers/ieee1394/nodemgr.c - 1.14 linux/arch/arm/mach-sa1100/xp860.c - 1.10 linux/arch/arm/mach-sa1100/irq.c - 1.10 linux/drivers/scsi/dpt_i2o.c - 1.20 linux/arch/mips/ddb5xxx/common/nile4.c - 1.2 linux/drivers/net/ns83820.c - 1.18 linux/drivers/i2c/i2c-adap-ite.c - 1.7 linux/include/linux/hiddev.h - 1.6 linux/fs/jffs2/background.c - 1.16 linux/arch/i386/kernel/nmi.c - 1.12 linux/drivers/mtd/devices/blkmtd.c - 1.20 linux/fs/namespace.c - 1.26 linux/drivers/message/i2o/i2o_scsi.c - 1.12 linux/drivers/message/i2o/i2o_lan.c - 1.6 linux/drivers/message/i2o/i2o_core.c - 1.9 linux/drivers/message/i2o/i2o_block.c - 1.29 linux/drivers/message/i2o/Makefile - 1.6 linux/drivers/acpi/executer/exoparg6.c - 1.6 linux/drivers/acpi/utilities/utmath.c - 1.6 linux/drivers/pcmcia/i82092.c - 1.9 linux/arch/arm/def-configs/epxa10db - 1.8 linux/arch/arm/mach-epxa10db/irq.c - 1.4 linux/drivers/acpi/executer/exoparg3.c - 1.8 linux/drivers/acpi/executer/exoparg2.c - 1.13 linux/drivers/acpi/executer/exoparg1.c - 1.14 linux/fs/jbd/journal.c - 1.19 linux/fs/ext3/ialloc.c - 1.22 linux/fs/ext3/inode.c - 1.33 linux/fs/ext3/super.c - 1.30 linux/drivers/hotplug/cpqphp_ctrl.c - 1.7 linux/include/linux/jbd.h - 1.14 linux/fs/jbd/recovery.c - 1.7 linux/include/linux/ext3_jbd.h - 1.9 linux/fs/jbd/transaction.c - 1.16 linux/fs/ext3/balloc.c - 1.11 linux/fs/jbd/commit.c - 1.10 linux/fs/ext3/Makefile - 1.8 linux/fs/ext3/acl.c - 1.6 linux/arch/arm/mm/proc-xscale.S - 1.12 linux/include/asm-arm/arch-iop310/serial.h - 1.3 linux/arch/arm/mach-iop310/iop310-irq.c - 1.6 linux/arch/arm/mach-iop310/iop310-pci.c - 1.8 linux/arch/arm/mach-iop310/iq80310-irq.c - 1.6 linux/arch/arm/mach-iop310/xs80200-irq.c - 1.6 linux/arch/arm/mach-rpc/irq.c - 1.4 linux/fs/xfs/pagebuf/page_buf.c - 1.95 linux/drivers/block/cciss_scsi.c - 1.8 linux/drivers/net/Makefile.lib - 1.5 linux/lib/crc32.c - 1.6 linux/drivers/ieee1394/dv1394.c - 1.11 linux/drivers/ieee1394/dv1394.h - 1.3 linux/net/ipv6/netfilter/ip6_queue.c - 1.6 linux/fs/xattr.c - 1.12 linux/include/linux/xattr.h - 1.3 linux/drivers/input/joystick/amijoy.c - 1.6 linux/drivers/input/gameport/ns558.c - 1.7 linux/drivers/input/joystick/magellan.c - 1.6 linux/drivers/input/joystick/spaceball.c - 1.5 linux/drivers/input/joystick/spaceorb.c - 1.5 linux/drivers/input/joystick/stinger.c - 1.5 linux/drivers/input/joystick/warrior.c - 1.5 linux/drivers/input/serio/serio.c - 1.8 linux/drivers/input/serio/serport.c - 1.6 linux/arch/alpha/kernel/init_task.c - 1.3 linux/sound/pci/trident/trident_main.c - 1.10 linux/sound/pci/nm256/nm256.c - 1.12 linux/sound/pci/maestro3.c - 1.12 linux/sound/pci/korg1212/korg1212.c - 1.16 linux/sound/pci/intel8x0.c - 1.14 linux/sound/pci/ens1370.c - 1.16 linux/sound/pci/emu10k1/memory.c - 1.7 linux/sound/pci/emu10k1/emupcm.c - 1.9 linux/sound/pci/emu10k1/emufx.c - 1.12 linux/sound/pci/cs46xx/cs46xx_lib.c - 1.12 linux/arch/ppc/boot/common/util.S - 1.4 linux/sound/pci/ali5451/ali5451.c - 1.15 linux/sound/pci/ac97/ac97_codec.c - 1.12 linux/sound/oss/vwsnd.c - 1.5 linux/arch/ppc/boot/simple/Makefile - 1.13 linux/arch/ppc/boot/simple/gt64260_tty.c - 1.4 linux/arch/ppc/boot/simple/head.S - 1.4 linux/arch/ppc/boot/simple/misc-ev64260.S - 1.3 linux/arch/ppc/boot/simple/misc-spruce.c - 1.5 linux/arch/ppc/boot/simple/rw4/ppc_40x.h - 1.2 linux/arch/ppc/boot/utils/mkbugboot.c - 1.3 linux/sound/oss/trident.c - 1.10 linux/sound/oss/rme96xx.h - 1.2 linux/sound/oss/rme96xx.c - 1.6 linux/sound/oss/nec_vrc5477.c - 1.4 linux/sound/oss/es1371.c - 1.8 linux/sound/oss/es1370.c - 1.8 linux/arch/ppc/platforms/ev64260.h - 1.3 linux/arch/ppc/platforms/ev64260_setup.c - 1.5 linux/arch/ppc/platforms/k2.h - 1.3 linux/arch/ppc/platforms/k2_pci.c - 1.5 linux/arch/ppc/platforms/k2_setup.c - 1.7 linux/arch/ppc/platforms/lopec_pci.c - 1.4 linux/arch/ppc/platforms/lopec_serial.h - 1.3 linux/arch/ppc/platforms/lopec_setup.c - 1.11 linux/arch/ppc/platforms/mcpn765.h - 1.3 linux/arch/ppc/platforms/mcpn765_pci.c - 1.3 linux/arch/ppc/platforms/mcpn765_serial.h - 1.3 linux/arch/ppc/platforms/mcpn765_setup.c - 1.8 linux/arch/ppc/platforms/menf1.h - 1.3 linux/arch/ppc/platforms/menf1_pci.c - 1.3 linux/arch/ppc/platforms/menf1_setup.c - 1.7 linux/arch/ppc/platforms/mvme5100.h - 1.3 linux/arch/ppc/platforms/mvme5100_pci.c - 1.3 linux/arch/ppc/platforms/mvme5100_serial.h - 1.3 linux/arch/ppc/platforms/mvme5100_setup.c - 1.5 linux/arch/ppc/platforms/pcore.h - 1.3 linux/arch/ppc/platforms/pcore_pci.c - 1.3 linux/arch/ppc/platforms/pcore_setup.c - 1.6 linux/arch/ppc/platforms/powerpmc250.c - 1.6 linux/arch/ppc/platforms/powerpmc250.h - 1.3 linux/arch/ppc/platforms/powerpmc250_serial.h - 1.3 linux/arch/ppc/platforms/pplus_pci.c - 1.3 linux/arch/ppc/platforms/pplus_setup.c - 1.11 linux/arch/ppc/platforms/prpmc750_pci.c - 1.3 linux/arch/ppc/platforms/prpmc750_serial.h - 1.3 linux/arch/ppc/platforms/prpmc750_setup.c - 1.6 linux/arch/ppc/platforms/prpmc800.h - 1.3 linux/arch/ppc/platforms/prpmc800_pci.c - 1.3 linux/arch/ppc/platforms/prpmc800_serial.h - 1.3 linux/arch/ppc/platforms/prpmc800_setup.c - 1.6 linux/arch/ppc/platforms/sandpoint.h - 1.3 linux/arch/ppc/platforms/sandpoint_pci.c - 1.3 linux/arch/ppc/platforms/sandpoint_serial.h - 1.3 linux/arch/ppc/platforms/sandpoint_setup.c - 1.9 linux/arch/ppc/platforms/spruce.h - 1.4 linux/arch/ppc/platforms/spruce_pci.c - 1.4 linux/arch/ppc/platforms/spruce_serial.h - 1.3 linux/arch/ppc/platforms/spruce_setup.c - 1.9 linux/arch/ppc/platforms/zx4500.h - 1.3 linux/arch/ppc/platforms/zx4500_pci.c - 1.3 linux/arch/ppc/platforms/zx4500_serial.h - 1.3 linux/arch/ppc/platforms/zx4500_setup.c - 1.5 linux/arch/x86_64/Makefile - 1.15 linux/arch/x86_64/boot/Makefile - 1.12 linux/arch/x86_64/boot/bootsect.S - 1.2 linux/arch/x86_64/boot/tools/build.c - 1.2 linux/arch/x86_64/defconfig - 1.15 linux/arch/x86_64/ia32/ia32_signal.c - 1.10 linux/arch/x86_64/ia32/ia32entry.S - 1.9 linux/arch/x86_64/ia32/sys_ia32.c - 1.14 linux/arch/x86_64/kernel/Makefile - 1.14 linux/arch/x86_64/kernel/apic.c - 1.10 linux/arch/x86_64/kernel/bluesmoke.c - 1.6 linux/arch/x86_64/kernel/early_printk.c - 1.6 linux/arch/x86_64/kernel/entry.S - 1.9 linux/arch/x86_64/kernel/head.S - 1.9 linux/arch/x86_64/kernel/head64.c - 1.5 linux/arch/x86_64/kernel/init_task.c - 1.4 linux/arch/x86_64/kernel/irq.c - 1.7 linux/arch/x86_64/kernel/mpparse.c - 1.6 linux/arch/x86_64/kernel/msr.c - 1.6 linux/arch/x86_64/kernel/nmi.c - 1.7 linux/arch/x86_64/kernel/process.c - 1.14 linux/arch/x86_64/kernel/setup.c - 1.8 linux/arch/x86_64/kernel/setup64.c - 1.9 linux/arch/x86_64/kernel/signal.c - 1.11 linux/arch/x86_64/kernel/smp.c - 1.10 linux/arch/x86_64/kernel/smpboot.c - 1.11 linux/arch/x86_64/kernel/sys_x86_64.c - 1.7 linux/arch/x86_64/kernel/time.c - 1.8 linux/arch/x86_64/kernel/traps.c - 1.13 linux/arch/x86_64/kernel/vsyscall.c - 1.8 linux/arch/x86_64/mm/Makefile - 1.8 linux/arch/x86_64/mm/fault.c - 1.9 linux/arch/x86_64/mm/init.c - 1.13 linux/arch/x86_64/mm/ioremap.c - 1.7 linux/sound/oss/ad1848.c - 1.9 linux/sound/isa/gus/interwave.c - 1.10 linux/sound/isa/cs423x/cs4236_lib.c - 1.5 linux/sound/isa/cs423x/cs4236.c - 1.13 linux/sound/isa/cs423x/cs4231_lib.c - 1.11 linux/sound/drivers/mtpav.c - 1.12 linux/sound/core/timer.c - 1.12 linux/sound/core/seq/seq_midi_emul.c - 1.5 linux/sound/core/seq/seq_device.c - 1.7 linux/sound/core/pcm_native.c - 1.14 linux/sound/core/pcm_memory.c - 1.7 linux/sound/core/pcm_lib.c - 1.11 linux/sound/core/oss/pcm_oss.c - 1.15 linux/sound/core/isadma.c - 1.5 linux/sound/core/hwdep.c - 1.6 linux/include/asm-x86_64/segment.h - 1.6 linux/include/asm-x86_64/processor.h - 1.10 linux/include/asm-x86_64/pgtable.h - 1.11 linux/include/asm-x86_64/pgalloc.h - 1.6 linux/include/asm-x86_64/pda.h - 1.7 linux/include/asm-x86_64/page.h - 1.8 linux/include/asm-x86_64/msr.h - 1.4 linux/include/asm-x86_64/mpspec.h - 1.4 linux/include/asm-x86_64/io.h - 1.6 linux/include/asm-x86_64/ia32.h - 1.8 linux/include/asm-x86_64/i387.h - 1.6 linux/include/asm-x86_64/e820.h - 1.4 linux/include/asm-x86_64/desc.h - 1.6 linux/include/asm-x86_64/current.h - 1.3 linux/include/sound/version.h - 1.16 linux/include/sound/pcm.h - 1.10 linux/include/asm-x86_64/system.h - 1.9 linux/include/sound/ac97_codec.h - 1.11 linux/include/asm-x86_64/signal.h - 1.6 linux/include/asm-ppc/todc.h - 1.4 linux/include/asm-x86_64/smp.h - 1.5 linux/include/asm-ppc/pplus.h - 1.3 linux/include/asm-x86_64/spinlock.h - 1.7 linux/include/asm-ppc/ppc405_dma.h - 1.3 linux/include/asm-ppc/mpc10x.h - 1.5 linux/include/asm-ppc/ibm403.h - 1.4 linux/include/asm-x86_64/vsyscall.h - 1.4 linux/include/asm-x86_64/unistd.h - 1.11 linux/include/asm-ppc/gt64260.h - 1.3 linux/include/asm-ppc/gt64260_defs.h - 1.3 linux/include/asm-ppc/harrier.h - 1.3 linux/include/asm-x86_64/timex.h - 1.6 linux/include/asm-x86_64/thread_info.h - 1.6 linux/arch/ppc64/defconfig - 1.15 linux/arch/ppc64/kernel/Makefile - 1.14 linux/arch/ppc64/kernel/align.c - 1.5 linux/arch/ppc64/kernel/binfmt_elf32.c - 1.4 linux/arch/ppc64/kernel/entry.S - 1.14 linux/arch/ppc64/kernel/i8259.c - 1.3 linux/arch/ppc64/kernel/ioctl32.c - 1.15 linux/arch/ppc64/kernel/misc.S - 1.15 linux/arch/ppc64/kernel/process.c - 1.13 linux/arch/ppc64/kernel/ptrace.c - 1.7 linux/arch/ppc64/kernel/rtas.c - 1.6 linux/arch/ppc64/kernel/rtasd.c - 1.7 linux/arch/ppc64/kernel/signal.c - 1.14 linux/arch/ppc64/kernel/signal32.c - 1.14 linux/arch/ppc64/kernel/smp.c - 1.15 linux/arch/ppc64/kernel/sys32.S - 1.7 linux/arch/ppc64/kernel/sys_ppc32.c - 1.16 linux/arch/ppc64/kernel/time.c - 1.12 linux/arch/ppc64/kernel/traps.c - 1.11 linux/arch/ppc64/xmon/start.c - 1.6 linux/arch/ppc64/xmon/xmon.c - 1.9 linux/include/asm-ppc64/unistd.h - 1.13 linux/include/asm-ppc64/signal.h - 1.4 linux/include/asm-ppc64/rtas.h - 1.5 linux/fs/jfs/jfs_logmgr.h - 1.10 linux/drivers/hotplug/ibmphp_hpc.c - 1.6 linux/fs/jfs/jfs_debug.h - 1.6 linux/fs/jfs/jfs_imap.c - 1.13 linux/fs/jfs/namei.c - 1.16 linux/arch/arm/mach-footbridge/isa-irq.c - 1.5 linux/fs/jfs/jfs_logmgr.c - 1.24 linux/fs/jfs/jfs_mount.c - 1.13 linux/fs/jfs/jfs_txnmgr.c - 1.23 linux/fs/jfs/jfs_umount.c - 1.9 linux/drivers/net/tg3.c - 1.16 linux/drivers/net/tulip/de4x5.c - 1.10 linux/include/linux/futex.h - 1.6 linux/kernel/futex.c - 1.14 linux/net/ipv4/netfilter/arptable_filter.c - 1.2 linux/arch/i386/kernel/acpi_wakeup.S - 1.8 linux/lib/radix-tree.c - 1.11 linux/drivers/ieee1394/eth1394.c - 1.5 linux/drivers/usb/core/hub.c - 1.19 linux/include/asm-arm/arch-pxa/time.h - 1.2 linux/drivers/usb/input/hid-core.c - 1.14 linux/arch/arm/mach-pxa/irq.c - 1.4 linux/drivers/usb/image/scanner.c - 1.17 linux/drivers/ieee1394/amdtp.h - 1.3 linux/drivers/usb/input/Makefile - 1.8 linux/drivers/ieee1394/amdtp.c - 1.6 linux/drivers/usb/input/hid-input.c - 1.7 linux/drivers/usb/input/hid.h - 1.7 linux/drivers/usb/input/hiddev.c - 1.12 linux/drivers/usb/input/usbkbd.c - 1.9 linux/drivers/usb/input/usbmouse.c - 1.8 linux/drivers/usb/input/wacom.c - 1.10 linux/mm/pdflush.c - 1.11 linux/arch/x86_64/ia32/fpu32.c - 1.4 linux/drivers/scsi/aic7xxx/aic7xxx_core.c - 1.7 linux/sound/arm/sa11xx-uda1341.c - 1.9 linux/sound/i2c/l3/uda1341.c - 1.5 linux/net/ipv6/ipv6_syms.c - 1.4 linux/mm/page-writeback.c - 1.19 linux/include/linux/buffer_head.h - 1.18 linux/init/Makefile - 1.14 linux/include/linux/jiffies.h - 1.3 linux/include/linux/namei.h - 1.3 linux/drivers/acorn/scsi/scsi.h - 1.4 linux/drivers/char/hvc_console.c - 1.8 linux/drivers/acpi/pci_bind.c - 1.6 linux/drivers/acpi/ac.c - 1.9 linux/drivers/acpi/battery.c - 1.11 linux/drivers/acpi/bus.c - 1.12 linux/drivers/acpi/pci_root.c - 1.8 linux/drivers/acpi/fan.c - 1.8 linux/drivers/acpi/pci_link.c - 1.7 linux/drivers/acpi/button.c - 1.10 linux/drivers/acpi/pci_irq.c - 1.11 linux/drivers/acpi/thermal.c - 1.12 linux/drivers/acpi/system.c - 1.11 linux/drivers/acpi/processor.c - 1.16 linux/drivers/acpi/osl.c - 1.13 linux/drivers/acpi/utils.c - 1.6 linux/drivers/isdn/hisax/amd7930_fn.c - 1.8 linux/scripts/fixdep.c - 1.7 linux/drivers/s390/net/lcs.c - 1.9 linux/arch/i386/kernel/suspend.c - 1.9 linux/arch/i386/kernel/cpu/centaur.c - 1.4 linux/drivers/usb/input/aiptek.c - 1.10 linux/arch/alpha/kernel/asm-offsets.c - 1.4 linux/arch/x86_64/ia32/ipc32.c - 1.6 linux/sound/pci/rme9652/hdsp.c - 1.9 linux/sound/isa/sb/emu8000_pcm.c - 1.5 linux/drivers/input/joystick/iforce/iforce.h - 1.3 linux/drivers/input/keyboard/atkbd.c - 1.9 linux/drivers/input/touchscreen/gunze.c - 1.4 linux/drivers/input/serio/rpckbd.c - 1.6 linux/drivers/input/serio/parkbd.c - 1.4 linux/drivers/input/serio/i8042.c - 1.9 linux/drivers/input/serio/ct82c710.c - 1.5 linux/drivers/input/mouse/sermouse.c - 1.4 linux/drivers/input/mouse/rpcmouse.c - 1.8 linux/drivers/input/mouse/psmouse.c - 1.10 linux/drivers/input/mouse/pc110pad.c - 1.4 linux/drivers/input/mouse/logibm.c - 1.5 linux/drivers/input/mouse/inport.c - 1.5 linux/drivers/input/mouse/amimouse.c - 1.6 linux/drivers/input/keyboard/xtkbd.c - 1.5 linux/drivers/input/keyboard/sunkbd.c - 1.7 linux/drivers/input/joystick/iforce/iforce-packets.c - 1.4 linux/drivers/input/joystick/iforce/iforce-serio.c - 1.3 linux/drivers/input/keyboard/amikbd.c - 1.8 linux/drivers/input/joystick/twidjoy.c - 1.4 linux/drivers/input/joystick/iforce/iforce-usb.c - 1.7 linux/drivers/acpi/tables/tbrsdt.c - 1.8 linux/drivers/acpi/toshiba_acpi.c - 1.6 linux/drivers/acpi/tables/tbgetall.c - 1.7 linux/drivers/input/keyboard/newtonkbd.c - 1.5 linux/drivers/input/serio/q40kbd.c - 1.6 linux/fs/direct-io.c - 1.16 linux/drivers/input/touchscreen/h3600_ts_input.c - 1.4 linux/drivers/usb/input/powermate.c - 1.9 linux/drivers/usb/input/xpad.c - 1.9 linux/drivers/usb/input/hid-ff.c - 1.3 linux/drivers/usb/input/fixp-arith.h - 1.3 linux/fs/smbfs/smbiod.c - 1.6 linux/drivers/input/serio/sa1111ps2.c - 1.5 linux/security/capability.c - 1.7 linux/Documentation/cli-sti-removal.txt - 1.2 linux/drivers/input/serio/ambakmi.c - 1.3 linux/drivers/char/agp/ali-agp.c - 1.6 linux/drivers/char/agp/sis-agp.c - 1.6 linux/drivers/char/agp/frontend.c - 1.6 linux/drivers/char/agp/hp-agp.c - 1.6 linux/drivers/char/agp/i460-agp.c - 1.6 linux/drivers/acpi/namespace/nsxfeval.c - 1.7 linux/drivers/acpi/namespace/nsdumpdv.c - 1.6 linux/drivers/char/agp/sworks-agp.c - 1.6 linux/drivers/char/agp/via-agp.c - 1.6 linux/drivers/bluetooth/bt3c_cs.c - 1.7 linux/fs/jfs/resize.c - 1.6 linux/include/asm-sparc/cacheflush.h - 1.2 linux/drivers/serial/sunzilog.c - 1.8 linux/drivers/serial/sunsu.c - 1.9 linux/drivers/input/misc/Makefile - 1.5 linux/arch/i386/kernel/cpu/mtrr/generic.c - 1.5 linux/drivers/i2c/i2c-algo-ibm_ocp.c - 1.3 linux/include/asm-ppc/rtc.h - 1.3 linux/net/sctp/sysctl.c - 1.3 linux/fs/jfs/jfs_xattr.h - 1.4 linux/include/net/sctp/user.h - 1.2 linux/net/sctp/ulpevent.c - 1.4 linux/fs/jfs/xattr.c - 1.8 linux/drivers/acpi/numa.c - 1.4 linux/net/sctp/protocol.c - 1.12 linux/net/sctp/Makefile - 1.4 linux/include/net/sctp/sctp.h - 1.9 linux/net/sctp/adler32.c - 1.3 linux/net/sctp/associola.c - 1.8 linux/net/sctp/command.c - 1.3 linux/net/sctp/crc32c.c - 1.2 linux/net/sctp/debug.c - 1.4 linux/net/sctp/endpointola.c - 1.5 linux/net/sctp/input.c - 1.9 linux/net/sctp/ipv6.c - 1.8 linux/net/sctp/objcnt.c - 1.2 linux/net/sctp/output.c - 1.6 linux/include/net/sctp/ulpqueue.h - 1.2 linux/net/sctp/outqueue.c - 1.8 linux/net/sctp/primitive.c - 1.4 linux/include/net/sctp/constants.h - 1.3 linux/include/net/sctp/sm.h - 1.8 linux/net/sctp/sm_make_chunk.c - 1.9 linux/include/net/sctp/command.h - 1.3 linux/net/sctp/sm_sideeffect.c - 1.10 linux/net/sctp/sm_statefuns.c - 1.9 linux/include/net/sctp/structs.h - 1.9 linux/net/sctp/sm_statetable.c - 1.7 linux/net/sctp/socket.c - 1.10 linux/net/sctp/transport.c - 1.6 linux/net/sctp/ulpqueue.c - 1.3 linux/drivers/ide/pci/amd74xx.h - 1.6 linux/drivers/ide/pci/amd74xx.c - 1.9 linux/arch/um/kernel/exec_kern.c - 1.4 linux/arch/um/kernel/signal_kern.c - 1.5 linux/arch/x86_64/vmlinux.lds.S - 1.7 linux/arch/i386/mm/hugetlbpage.c - 1.10 linux/arch/ppc/boot/include/mpc10x.h - 1.4 linux/arch/ppc/boot/common/mpc10x_memory.c - 1.3 linux/drivers/acpi/blacklist.c - 1.4 linux/arch/sparc64/mm/hugetlbpage.c - 1.5 linux/arch/ppc/boot/common/cpc700_memory.c - 1.3 linux/drivers/acpi/sleep.c - 1.5 linux/drivers/acpi/debug.c - 1.2 linux/drivers/acpi/event.c - 1.2 linux/drivers/acpi/scan.c - 1.6 linux/arch/ia64/mm/hugetlbpage.c - 1.5 linux/drivers/block/deadline-iosched.c - 1.6 linux/drivers/base/hotplug.c - 1.7 linux/sound/pci/cs46xx/dsp_spos_scb_lib.c - 1.6 linux/sound/core/pcm_sgbuf.c - 1.6 linux/kernel/cpufreq.c - 1.8 linux/include/asm-x86_64/topology.h - 1.2 linux/include/sound/pcm_sgbuf.h - 1.5 linux/include/linux/cpufreq.h - 1.9 linux/arch/i386/kernel/cpu/cpufreq/powernow-k6.c - 1.6 linux/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c - 1.6 linux/arch/i386/kernel/cpu/cpufreq/speedstep.c - 1.7 linux/arch/i386/kernel/cpu/cpufreq/elanfreq.c - 1.6 linux/arch/i386/kernel/cpu/cpufreq/Makefile - 1.5 linux/arch/i386/kernel/cpu/cpufreq/longrun.c - 1.5 linux/arch/i386/kernel/cpu/cpufreq/longhaul.c - 1.6 linux/sound/usb/usbquirks.h - 1.6 linux/sound/usb/usbaudio.h - 1.6 linux/sound/usb/usbaudio.c - 1.8 linux/sound/pci/via82xx.c - 1.6 linux/drivers/scsi/aacraid/commsup.c - 1.2 linux/drivers/scsi/aacraid/aachba.c - 1.7 linux/net/bluetooth/rfcomm/core.c - 1.6 linux/net/bluetooth/bnep/core.c - 1.5 linux/kernel/workqueue.c - 1.3 linux/arch/ppc/platforms/4xx/walnut.h - 1.5 linux/fs/cifs/TODO - 1.3 linux/fs/cifs/asn1.c - 1.3 linux/fs/cifs/cifs_debug.c - 1.5 linux/fs/cifs/cifs_debug.h - 1.3 linux/fs/cifs/cifs_unicode.c - 1.2 linux/fs/cifs/cifsfs.c - 1.5 linux/fs/cifs/cifsfs.h - 1.3 linux/fs/cifs/cifsglob.h - 1.3 linux/fs/cifs/cifspdu.h - 1.3 linux/fs/cifs/cifsproto.h - 1.5 linux/fs/cifs/cifssmb.c - 1.6 linux/fs/cifs/connect.c - 1.5 linux/fs/cifs/dir.c - 1.3 linux/fs/cifs/file.c - 1.5 linux/fs/cifs/inode.c - 1.5 linux/arch/alpha/kernel/systbls.S - 1.4 linux/fs/cifs/link.c - 1.3 linux/fs/cifs/misc.c - 1.3 linux/fs/cifs/netmisc.c - 1.5 linux/fs/cifs/CHANGES - 1.4 linux/fs/cifs/transport.c - 1.3 linux/fs/cifs/smbencrypt.c - 1.3 linux/include/asm-ppc/ibm405.h - 1.4 linux/arch/i386/kernel/timers/Makefile - 1.5 linux/arch/i386/kernel/timers/timer.c - 1.3 linux/arch/i386/kernel/timers/timer_cyclone.c - 1.3 linux/arch/i386/kernel/timers/timer_tsc.c - 1.8 linux/drivers/isdn/hardware/eicon/i4lididrv.c - 1.4 linux/drivers/isdn/hardware/eicon/i4l_idi.c - 1.2 linux/arch/ppc/platforms/4xx/ash.c - 1.4 linux/arch/ppc/platforms/4xx/ash.h - 1.5 linux/arch/ppc/platforms/4xx/cedar.c - 1.4 linux/arch/ppc/platforms/4xx/cedar.h - 1.5 linux/arch/ppc/platforms/4xx/ep405.c - 1.5 linux/arch/ppc/platforms/4xx/ep405.h - 1.5 linux/arch/ppc/platforms/4xx/ibm405gp.c - 1.5 linux/arch/ppc/platforms/4xx/ibm405gp.h - 1.5 linux/arch/ppc/platforms/4xx/ibmnp405h.c - 1.5 linux/arch/ppc/platforms/4xx/ibmnp405h.h - 1.5 linux/arch/ppc/platforms/4xx/ibmnp405l.c - 1.5 linux/arch/ppc/platforms/4xx/ibmnp405l.h - 1.5 linux/arch/ppc/platforms/4xx/ibmstb3.c - 1.5 linux/arch/ppc/platforms/4xx/ibmstb3.h - 1.5 linux/arch/ppc/platforms/4xx/ibmstb4.c - 1.5 linux/arch/ppc/platforms/4xx/ibmstb4.h - 1.5 linux/arch/ppc/platforms/4xx/redwood.c - 1.4 linux/arch/ppc/platforms/4xx/redwood.h - 1.5 linux/arch/ppc/platforms/4xx/redwood5.c - 1.4 linux/arch/ppc/platforms/4xx/redwood5.h - 1.4 linux/arch/ppc/platforms/4xx/walnut.c - 1.5 linux/drivers/isdn/hardware/eicon/divasmain.c - 1.4 linux/drivers/isdn/hardware/eicon/diva.c - 1.3 linux/fs/nfs/nfs4xdr.c - 1.6 linux/drivers/oprofile/buffer_sync.c - 1.6 linux/drivers/oprofile/cpu_buffer.c - 1.4 linux/drivers/oprofile/cpu_buffer.h - 1.3 linux/drivers/oprofile/event_buffer.h - 1.3 linux/drivers/oprofile/oprof.c - 1.3 linux/drivers/oprofile/oprof.h - 1.3 linux/drivers/oprofile/oprofile_files.c - 1.3 linux/drivers/oprofile/oprofilefs.c - 1.3 linux/net/rxrpc/krxtimod.c - 1.4 linux/net/rxrpc/krxsecd.c - 1.5 linux/net/rxrpc/krxiod.c - 1.4 linux/net/rxrpc/internal.h - 1.4 linux/fs/afs/cmservice.c - 1.4 linux/include/asm-x86_64/proto.h - 1.7 linux/include/asm-x86_64/acpi.h - 1.2 linux/fs/afs/internal.h - 1.4 linux/fs/afs/kafsasyncd.c - 1.4 linux/fs/afs/kafstimod.c - 1.4 linux/arch/i386/oprofile/op_counter.h - 1.2 linux/include/linux/oprofile.h - 1.3 linux/arch/i386/oprofile/Makefile - 1.4 linux/arch/i386/oprofile/init.c - 1.3 linux/arch/i386/oprofile/nmi_int.c - 1.5 linux/arch/i386/oprofile/op_model_athlon.c - 1.4 linux/arch/i386/oprofile/op_model_ppro.c - 1.4 linux/arch/i386/oprofile/op_x86_model.h - 1.2 linux/arch/i386/oprofile/timer_int.c - 1.3 linux/arch/x86_64/kernel/e820.c - 1.3 linux/arch/x86_64/kernel/aperture.c - 1.2 linux/arch/x86_64/kernel/acpi.c - 1.4 linux/arch/ppc/boot/simple/misc.c - 1.6 linux/drivers/pnp/pnpbios/core.c - 1.6 linux/arch/ppc/boot/simple/relocate.S - 1.3 linux/fs/sysfs/inode.c - 1.7 linux/arch/ppc/platforms/pal4.h - 1.3 linux/arch/ppc/platforms/pal4_pci.c - 1.4 linux/arch/ppc/platforms/pal4_serial.h - 1.3 linux/arch/ppc/platforms/pal4_setup.c - 1.4 linux/drivers/media/dvb/av7110/av7110.c - 1.4 linux/drivers/net/Kconfig - 1.8 linux/drivers/message/i2o/Kconfig - 1.3 linux/drivers/net/tokenring/Kconfig - 1.5 linux/arch/arm/Kconfig - 1.7 linux/include/linux/eventpoll.h - 1.5 linux/arch/i386/Kconfig - 1.11 linux/arch/i386/mach-voyager/voyager_smp.c - 1.4 linux/arch/i386/mach-voyager/voyager_thread.c - 1.2 linux/scripts/Makefile.modver - 1.4 linux/scripts/Makefile.modinst - 1.3 linux/scripts/Makefile.lib - 1.5 linux/drivers/media/dvb/dvb-core/dvb_frontend.c - 1.3 linux/scripts/Makefile.build - 1.7 linux/arch/parisc/kernel/binfmt_elf32.c - 1.3 linux/drivers/media/dvb/av7110/av7110.h - 1.3 linux/arch/parisc/kernel/signal32.c - 1.4 linux/arch/parisc/kernel/sys32.h - 1.3 linux/arch/parisc/kernel/sys_parisc32.c - 1.7 linux/drivers/char/agp/Kconfig - 1.6 linux/arch/ppc64/Kconfig - 1.7 linux/arch/sparc64/Kconfig - 1.7 linux/arch/x86_64/Kconfig - 1.9 linux/fs/befs/datastream.c - 1.3 linux/fs/befs/btree.c - 1.3 linux/fs/befs/ChangeLog - 1.3 linux/net/sctp/Kconfig - 1.3 linux/drivers/input/misc/Kconfig - 1.4 linux/drivers/acpi/Kconfig - 1.4 linux/drivers/video/Kconfig - 1.7 linux/net/ipv4/xfrm_state.c - 1.4 linux/drivers/usb/input/Kconfig - 1.4 linux/include/net/xfrm.h - 1.6 linux/fs/hugetlbfs/inode.c - 1.8 linux/fs/ext3/xattr_user.c - 1.3 linux/fs/ext3/xattr.h - 1.3 linux/fs/ext3/xattr.c - 1.3 linux/fs/ext2/xattr_user.c - 1.3 linux/fs/ext2/xattr.h - 1.3 linux/fs/ext2/xattr.c - 1.3 linux/fs/eventpoll.c - 1.5 linux/include/asm-m68knommu/mcfne.h - 1.2 linux/drivers/parisc/eisa.c - 1.5 linux/include/linux/hugetlb.h - 1.5 linux/include/asm-v850/signal.h - 1.3 linux/drivers/media/video/saa7134/saa7134-tvaudio.c - 1.4 linux/include/asm-m68knommu/signal.h - 1.3 linux/arch/m68knommu/kernel/asm-offsets.c - 1.3 linux/arch/m68knommu/kernel/signal.c - 1.5 linux/arch/m68knommu/kernel/traps.c - 1.2 linux/arch/v850/kernel/signal.c - 1.5 linux/arch/v850/kernel/asm-consts.c - 1.2 linux/arch/ppc/syslib/pplus_common.c - 1.3 linux/drivers/net/irda/sir_kthread.c - 1.4 linux/drivers/hotplug/cpci_hotplug_core.c - 1.4 linux/arch/ppc/syslib/todc_time.c - 1.5 linux/arch/ppc/syslib/ppc4xx_serial.c - 1.3 linux/net/key/af_key.c - 1.5 linux/arch/ppc/syslib/ppc4xx_pm.c - 1.3 linux/arch/ppc/syslib/ppc405_pci.c - 1.4 linux/arch/ppc/syslib/pci_auto.c - 1.3 linux/arch/ppc/syslib/mpc10x_common.c - 1.4 linux/arch/ppc/syslib/harrier.c - 1.3 linux/arch/ppc/syslib/gt64260_pic.c - 1.3 linux/arch/ppc/syslib/gt64260_common.c - 1.3 linux/arch/ppc/syslib/cpc710.h - 1.4 linux/arch/ppc/syslib/cpc700_pic.c - 1.3 linux/arch/ppc/syslib/cpc700.h - 1.3 linux/drivers/acpi/namespace/nsparse.c - 1.4 linux/drivers/ieee1394/dma.c - 1.2 linux/drivers/ieee1394/dma.h - 1.2 linux/arch/sparc64/oprofile/init.c - 1.2 linux/arch/sparc64/oprofile/timer_int.c - 1.2 linux/drivers/acpi/events/evgpe.c - 1.4 linux/drivers/acpi/dispatcher/dsinit.c - 1.5 linux/drivers/char/agp/amd-k7-agp.c - 1.5 linux/drivers/char/agp/amd-k8-agp.c - 1.5 linux/drivers/char/agp/backend.c - 1.5 linux/drivers/char/agp/generic.c - 1.5 linux/include/linux/mca-legacy.h - 1.2 linux/drivers/char/agp/intel-agp.c - 1.5 linux/arch/ppc64/oprofile/timer_int.c - 1.2 linux/arch/ppc64/oprofile/init.c - 1.2 linux/drivers/char/watchdog/Kconfig - 1.4 linux/drivers/char/watchdog/Makefile - 1.3 linux/drivers/ieee1394/iso.c - 1.2 linux/drivers/ieee1394/iso.h - 1.2 linux/drivers/char/watchdog/acquirewdt.c - 1.4 linux/kernel/compat.c - 1.4 linux/drivers/input/misc/gsc_ps2.c - 1.2 linux/drivers/char/watchdog/machzwd.c - 1.4 linux/drivers/char/watchdog/pcwd.c - 1.4 linux/drivers/char/watchdog/sbc60xxwdt.c - 1.4 linux/drivers/char/watchdog/wdt977.c - 1.4 linux/drivers/char/watchdog/wdt285.c - 1.3 linux/drivers/char/watchdog/wdt.c - 1.4 linux/drivers/char/watchdog/w83877f_wdt.c - 1.4 linux/arch/x86_64/kernel/module.c - 1.5 linux/arch/x86_64/mm/hugetlbpage.c - 1.4 linux/drivers/char/agp/generic-3.0.c - 1.3 linux/drivers/char/agp/i7x05-agp.c - 1.4 linux/arch/um/kernel/tt/syscall_kern.c - 1.3 linux/arch/um/kernel/tt/process_kern.c - 1.3 linux/arch/um/kernel/skas/process_kern.c - 1.3 linux/arch/i386/kernel/sysenter.c - 1.3 linux/drivers/scsi/aic7xxx/aic79xx.reg - 1.3 linux/include/asm-i386/mach-summit/mach_mpparse.h - 1.3 linux/include/asm-i386/mach-summit/mach_apic.h - 1.4 linux/drivers/scsi/aic7xxx/aic79xx_osm.c - 1.4 linux/drivers/scsi/aic7xxx/aic79xx_pci.c - 1.3 linux/drivers/scsi/aic7xxx/aic7xxx_osm.c - 1.4 linux/include/asm-ppc/ibm_ocp_pci.h - 1.3 linux/drivers/char/watchdog/alim7101_wdt.c - 1.3 linux/arch/ppc/platforms/4xx/ibm405gpr.c - 1.3 linux/arch/ppc/platforms/4xx/ibm405gpr.h - 1.3 linux/drivers/char/agp/via-kt400.c - 1.3 linux/drivers/char/watchdog/wafer5823wdt.c - 1.3 linux/arch/ppc/platforms/4xx/ibmnp4gs.c - 1.3 linux/drivers/char/watchdog/sc1200wdt.c - 1.3 linux/drivers/char/watchdog/sc520_wdt.c - 1.3 linux/arch/ppc/platforms/4xx/ibmnp4gs.h - 1.3 linux/arch/ppc/syslib/ppc4xx_dma.c - 1.3 linux/arch/ppc/platforms/4xx/ibmstbx25.c - 1.3 linux/arch/ppc/platforms/4xx/ibmstbx25.h - 1.3 linux/drivers/net/amd8111e.c - 1.2 linux/arch/ppc/platforms/4xx/sycamore.c - 1.3 linux/arch/ppc/platforms/4xx/sycamore.h - 1.3 linux/arch/ppc/platforms/4xx/redwood6.h - 1.3 linux/arch/ppc/platforms/4xx/redwood6.c - 1.3 linux/arch/parisc/oprofile/timer_int.c - 1.2 linux/net/sunrpc/rpc_pipe.c - 1.3 linux/arch/parisc/oprofile/init.c - 1.2 linux/arch/i386/kernel/cpu/cpufreq/gx-suspmod.c - 1.3 linux/init/vermagic.c - 1.2 linux/include/linux/eisa.h - 1.2 linux/arch/alpha/kernel/core_marvel.c - 1.3 linux/drivers/eisa/eisa-bus.c - 1.2 linux/drivers/eisa/Makefile - 1.3 linux/drivers/eisa/Kconfig - 1.2 linux/arch/alpha/kernel/sys_marvel.c - 1.2 linux/mm/fadvise.c - 1.2 linux/include/acpi/platform/aclinux.h - 1.2 linux/include/asm-x86_64/dma-mapping.h - 1.2 linux/include/acpi/platform/acenv.h - 1.2 linux/include/acpi/acpixf.h - 1.2 linux/include/acpi/acpiosxf.h - 1.2 linux/include/acpi/acpi_drivers.h - 1.2 linux/include/acpi/acpi.h - 1.2 linux/arch/arm/common/sa1111-pcibuf.c - 1.2 linux/arch/arm/common/sa1111.c - 1.2 From owner-linux-xfs@oss.sgi.com Wed Feb 19 07:29:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Feb 2003 07:30:16 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1JFTs3v025828 for ; Wed, 19 Feb 2003 07:29:54 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1JFmBkq008665 for ; Wed, 19 Feb 2003 09:48:11 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA95048 for ; Wed, 19 Feb 2003 09:38:31 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA74921 for ; Wed, 19 Feb 2003 09:38:30 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h1JMsV204882 for linux-xfs@oss.sgi.com; Wed, 19 Feb 2003 17:54:31 -0500 Resent-Message-Id: <200302192254.h1JMsV204882@taclab54.munich.sgi.com> Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA38474 for ; Wed, 19 Feb 2003 09:38:01 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id h1JFbxok11440165 for ; Wed, 19 Feb 2003 07:38:00 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id h1JFZBdG001532 for ; Wed, 19 Feb 2003 16:35:11 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id h1JFZBp5001531 for hch@sgi.com; Wed, 19 Feb 2003 16:35:11 +0100 Date: Wed, 19 Feb 2003 16:35:11 +0100 From: Christoph Hellwig Message-Id: <200302191535.h1JFZBp5001531@lab343.munich.sgi.com> Subject: TAKE - insert dirty buffers at the tail of the inode queue To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Wed, 19 Feb 2003 17:54:31 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 2785 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 413 Lines: 14 Date: Wed Feb 19 07:32:57 PST 2003 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:139992a linux/fs/buffer.c - 1.115 - insert dirty buffer at the tail of the inode queue to avoid submitting I/O in reverse order in fsync_inode_list and getting in the way of write clustering. From owner-linux-xfs@oss.sgi.com Wed Feb 19 07:55:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Feb 2003 07:55:26 -0800 (PST) Received: from hell.org.pl (qmailr@hell.org.pl [212.244.218.42]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1JFtH3v026508 for ; Wed, 19 Feb 2003 07:55:21 -0800 Received: (qmail 32617 invoked by uid 777); 19 Feb 2003 16:04:04 -0000 Date: Wed, 19 Feb 2003 17:04:04 +0100 From: Karol Kozimor To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: XFS and ACPI sleep states compat in 2.5 Message-ID: <20030219160404.GA5225@hell.org.pl> Mail-Followup-To: Eric Sandeen , linux-xfs@oss.sgi.com References: <20030219100207.GA15374@hell.org.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-archive-position: 2786 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sziwan@hell.org.pl Precedence: bulk X-list: linux-xfs Content-Length: 2348 Lines: 51 Thus wrote Eric Sandeen: > > There seems, however, to be an issue loosely connected with suspend. > Does this behave differently with the patch vs. without? No. As I stated earlier, the issue was present with 2.5.59 and 2.5.60, so without your patch applied. > > Suspending and resuming almost universally seems to trigger the strange > > ,,Unknown error 990'' problems upon any file access. > Are there any messages in the system logs before/after this? 990 > is "EFSCORRUPTED" out of xfs, perhaps the filesystem has shut down. > There should be some error messages in the logs, if EFSCORRUPTED > is being generated. Well, nothing here. The logs are silent. Is it possible for the filesystem to shut down selectively? I.e. I have two XFS filesystems mounted at / and /home. When the problem occurs (at random circumstances, also before any suspends), I am able to access one part of the filesystem (e.g. /bin, /usr/local/bin), while on the same time it is impossible to access the other (/usr/bin). > I can try to take a look at this, but my problem with ACPI in the past > has always been finding a machine which implements ACPI well enough > in the bios that it has -any- hope of working correctly.... ACPI development has been quite active over the last months. ACPI included in vanilla 2.4.x is about a year (or more) old, and is buggy. The new code for 2.4.x is on acpi.sf.net and is synchronized with recent 2.5.x releases. Anyway, either you've seen a very old (pre-2002) version of ACPI code, or you must have been extremely unlucky. > If the patch I posted doesn't make this any -worse- then I'll go ahead > and check it in; if it is causing this problem, perhaps I should hold > off. As I said, the problem is not dependent. This filesystem shutdown (?) is trigerred by the suspend / resume event, but it also exists independently. Oh, I nearly forgot: there is a strange issue involved with the filesystem: during the normal shutdown process, the kernel spits out the traceback of something connected with fs/buffer.c. Alas, it happens either when my keyboard doesn't work (after a S3 resume... well, it isn't perfect), or I'm not paying attention, so I'm not able to press scroll-lock in time. I'll try to catch this message and see if it will be of any meaning. Best regards, -- Karol 'sziwan' Kozimor sziwan@hell.org.pl From owner-linux-xfs@oss.sgi.com Wed Feb 19 11:02:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Feb 2003 11:02:57 -0800 (PST) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.58.33]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1JJ2m3v030963 for ; Wed, 19 Feb 2003 11:02:49 -0800 Received: from Shiva (shiva [192.168.3.20]) by ishtar.tlinx.org (8.12.6/8.12.2/SuSE Linux 0.6) with ESMTP id h1JJBRLf018527; Wed, 19 Feb 2003 11:11:27 -0800 From: "l.a walsh" To: "'Seth Mos'" , Subject: RE: been a while before i could get back to this.. Date: Wed, 19 Feb 2003 11:11:27 -0800 Message-ID: <001401c2d84a$b39cc350$1403a8c0@sc.tlinx.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <4.3.2.7.2.20030219105030.036d3090@pop.xs4all.nl> Importance: Normal X-archive-position: 2787 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: xfs@tlinx.org Precedence: bulk X-list: linux-xfs Content-Length: 2106 Lines: 59 > It sounds to me like your filesystem is indeed damaged. I > suggest repairing > it with xfs_repair. --- It's my root file system, it's a bit hard to unmount, but xfs_check has no output and xfs_repair seems to just show progress: # xfs_repair -nf /dev/sda1 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 - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. --- > You will probably get the filesystem shutdown when using tar as well. > The problem crops up because the moment it tries to read the file it > immediatly triggers a filesystem corruption error state. So it (probably) > won't matter > if you would use tar or xfsdump, it would barf anyhow. --- File system seems fine...It's been used without noticable problems since problem appeared in _October_. Wasn't real concerned since rootfs mostly contains stuff that doesn't change much (distro and config files, configs backed up). It's just xfs_dump that dumps...(or doesn't). Wish it wasn't so rude as to just assume my FS is bad and unmount it -- as everything else seems fine. Approx 187,000 names ("find / -xdev|wc") with over 10,000 dirs, /dev/sda3 tot=5.5G used=4.1G avail=1.5G 75% / -l From owner-linux-xfs@oss.sgi.com Wed Feb 19 12:11:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Feb 2003 12:12:02 -0800 (PST) Received: from webcube3.volstate.net (webcube2.volstate.net [66.129.16.201]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1JKBq3v004987 for ; Wed, 19 Feb 2003 12:11:53 -0800 Received: from jupiter.solar.com (host2-33-153-216.martek.net [216.153.33.2] (may be forged)) by webcube3.volstate.net (8.11.6/8.11.6) with ESMTP id h1JKKZL13171 for ; Wed, 19 Feb 2003 15:20:35 -0500 Content-Type: text/plain; charset="us-ascii" From: Joe Bacom Reply-To: joebacom@volstate.net To: linux-xfs@oss.sgi.com Subject: Seg Fault in libattr Date: Wed, 19 Feb 2003 14:19:50 -0600 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Message-Id: <200302191419.50007.joebacom@volstate.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h1JKBs3v004988 X-archive-position: 2788 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: joebacom@volstate.net Precedence: bulk X-list: linux-xfs Content-Length: 357 Lines: 10 Anybody know why libattr.so.1.0.1 would cause a signal 11 segmentation fault in libncurses.so.5? I am building a php extension for accessing extended attributes using the libattr shared library. When executed, it core dumps with the above seg fault. Looking at the source for libattr, I can't see a reason for libncurses to be involved at all. Joe From owner-linux-xfs@oss.sgi.com Wed Feb 19 12:28:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Feb 2003 12:28:45 -0800 (PST) Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1JKSW3v005557 for ; Wed, 19 Feb 2003 12:28:35 -0800 Received: from [10.0.0.10] (c-24-245-56-70.mn.client2.attbi.com [24.245.56.70]) by lips.thebarn.com (8.12.6/8.12.6) with ESMTP id h1JKbCcX026222; Wed, 19 Feb 2003 14:37:14 -0600 (CST) (envelope-from cattelan@thebarn.com) Subject: Re: Corrupted file on iso installer image of XFS 1.2 From: Russell Cattelan Cc: Bernhard Erdmann , Jenny Williams , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: multipart/mixed; boundary="=-nPDbv5RaDMnFKy3PxN89" Organization: Message-Id: <1045687031.1716.99.camel@lupo.thebarn.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 19 Feb 2003 14:37:12 -0600 X-archive-position: 2789 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: 7688 Lines: 208 --=-nPDbv5RaDMnFKy3PxN89 Content-Type: text/plain Content-Transfer-Encoding: 7bit Ok the installer iso has been respun the iso the athlon kernels. The acl-devel and attr-devel packages have also been updated to libacl-devel and libattr-devel. I have not tested this iso but hopefully nothing in the build process has gone a muck so it should work no worse than the old one. The Makefile that I use to do all the setup and building of the various pieces has been included on the iso. rebuildme/Makefile No howto at this time but is anybody is feeling really brave they can give play with it. On Tue, 2003-02-18 at 19:27, Eric Sandeen wrote: > On Tue, 18 Feb 2003, Bernhard Erdmann wrote: > > > Is it that complicated? Do you have a Howto or a script how to "roll > > your own installer"? > > It's not that hard, once you've taken the time to figure things out. > > There were two bits of it, Anaconda modifications to support xfs, > and creating the right build environment for the installer. You can look > at the patch in the Anaconda SRPM to see what we did to the installer > itself (actually lots of xfs support is there already from Red Hat, thanks > to Martin!). To see how we set up the build environment, it would > probably be best to post a Makefile that Russell wrote to do most of > the hard stuff. > > We essentially have every RPM from 8.0 + our RPMs in a tree, and symlink > them around. One set of symlinks is for all the RPMs needed to build > the anaconda environment, the other set of symlinks "teaches" the installer > which RPMs are on which CD. Scripts that come with Anaconda do the > rest (build the hdlist and build the installer). > > I'll talk to Russell about publishing the Makefile - I think we'd both > be ecstatic if someone else wanted to pick up this work. :) > > -Eric -- Russell Cattelan --=-nPDbv5RaDMnFKy3PxN89 Content-Disposition: attachment; filename=XFSinstMake Content-Type: text/plain; name=XFSinstMake; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit BUILDINSTDIR= $(shell $(CONFIG_SHELL) ) BUILDINSTALL = buildinstall #KERNSOURCE = /misc/pbuild/SGI_RH KERNSOURCE = /misc/build1/SGI2 ANACONDA_SOURCE = /misc/build1/SGI RH_ISO_SOURCE = /misc/xfs2/psyche #RH_ISO_SOURCE = ../psyche BOOTGEN = /misc/xfs2/PSYCHEinst/bootGen CMD_SOURCE = /misc/xfs2/XFS/xfs-cmds_2.4.x-xfs-r1.2 KERNVERSION = 2.4.18-18SGI_XFS_1.2.0 CDVERS = "1031690066.345824\nPsyche 8.0\ni386\n6\nRedHat/base\nRedHat/RPMS\nRedHat/pixmaps\n" MKISOFS = mkisofs IMPLANTISOMD5 = /usr/lib/anaconda-runtime/implantisomd5 ISO = xfs-`date "+%b%d-%H"`.iso UPDATEIMG = updates-`date "+%b%d-%H"`.img LOOPDEV = /dev/loop5 COMMANDS = xfsprogs xfsdump acl dmapi attr COMMANDRPMS = attr libattr-devel libattr \ xfsprogs xfsprogs-devel xfsdump \ acl libacl-devel libacl \ dmapi dmapi-devel up_kernel: -rm -f genhdlist/sgi_disc/RedHat/RPMS/kernel-*2.4.18* -rm -f genhdlist/disc?/RedHat/RPMS/kernel-*2.4.18* -rm -f bootGen/RedHat/RPMS/kernel-*2.4.18* rsync -v ${KERNSOURCE}/RPMS/i?86/kernel-*${KERNVERSION}* genhdlist/sgi_disc/RedHat/RPMS/ rsync -v ${KERNSOURCE}/RPMS/athlon/kernel-*${KERNVERSION}* genhdlist/sgi_disc/RedHat/RPMS/ (cd bootGen/RedHat/RPMS; ln -s ../../../genhdlist/sgi_disc/RedHat/RPMS/kernel-BOOT-${KERNVERSION}* .) ls -l genhdlist/sgi_disc/RedHat/RPMS/ -rm -f sgiSRPMS/SRPMS/kernel-*2.4.18* rsync -v ${KERNSOURCE}/SRPMS/kernel-${KERNVERSION}* sgiSRPMS/SRPMS/ ls -l sgiSRPMS/SRPMS/ up_cmds: -for d in $(COMMANDRPMS); do \ rm -f genhdlist/sgi_disc/RedHat/RPMS/*$$d-*.i?86.rpm; \ rm -f genhdlist/disc?/RedHat/RPMS/*$$d-*i?86.rpm; \ rm -f bootGen/RedHat/RPMS/*$$d-*i?86.rpm; \ rm -f sgiSRPMS/SRPMS/*$$d-*.src.rpm; \ done for d in $(COMMANDS); do \ rsync -v ${CMD_SOURCE}/$$d/build/rpm/*$$d-*.i?86.rpm genhdlist/sgi_disc/RedHat/RPMS/; \ rsync -v ${CMD_SOURCE}/$$d/build/rpm/*$$d-*.src.rpm sgiSRPMS/SRPMS/; \ (cd bootGen/RedHat/RPMS; ln -s ../../../genhdlist/sgi_disc/RedHat/RPMS/*$$d-*.i?86.rpm .); \ ls -l bootGen/RedHat/RPMS/*$$d-*i?86.rpm; \ done # -rm sgiSRPMS/SRPMS/quota-*.src.rpm # -rm genhdlist/sgi_disc/RedHat/RPMS/quota-*.i?86.rpm # rsync -v ${CMD_SOURCE}/../../x2.4-xfs-r1.0/RPMS/*/quota-*.i?86.rpm genhdlist/sgi_disc/RedHat/RPMS/ # rsync -v ${CMD_SOURCE}/../../x2.4-xfs-r1.0/SRPMS/quota-*.src.rpm sgiSRPMS/SRPMS/ ls -l genhdlist/sgi_disc/RedHat/RPMS/ sgiSRPMS/SRPMS/ up_genhdlist: anaconda-xfs/utils/genhdlist --withnumbers \ --hdlist bootGen/RedHat/base/hdlist \ `pwd`/genhdlist/disc1 \ `pwd`/genhdlist/disc2 \ `pwd`/genhdlist/disc3 \ `pwd`/genhdlist/disc4 \ `pwd`/genhdlist/disc5 \ `pwd`/genhdlist/sgi_disc up_genhdlist-neworder: anaconda-xfs/utils/genhdlist --withnumbers \ --hdlist bootGen/RedHat/base/hdlist \ --fileorder anaconda-xfs/scripts/pkgorder-modified \ `pwd`/genhdlist/disc1 \ `pwd`/genhdlist/disc2 \ `pwd`/genhdlist/disc3 \ `pwd`/genhdlist/disc4 \ `pwd`/genhdlist/disc5 \ `pwd`/genhdlist/sgi_disc #pkgorder-default: # anaconda/anaconda-xfs/scripts/pkgorderHERE \ # `pwd`/bootGen i386 > anaconda/anaconda-xfs/scripts/pkgorder-default # implantisomd5: isofs $(IMPLANTISOMD5) -f ./$(ISO) isofs: $(MKISOFS) -V "SGI XFS 1.2" \ -P SGI -p "xfs-masters@oss.sgi.com" \ -A "SGI Linux XFS 1.2 Installer" \ -boot-load-size 4 \ -boot-info-table \ -no-emul-boot \ -b isolinux/isolinux.bin \ -c isolinux/boot.cat \ -l -f -r -R -J -V -T \ -o ./$(ISO) sgiInstall up_anaconda: -rm -f genhdlist/sgi_disc/RedHat/RPMS/anaconda-* -rm -f sgiSRPMS/SRPMS/anaconda-* -rm -f bootGen/RedHat/RPMS/anaconda-*.rpm -rm -f genhdlist/disc?/RedHat/RPMS/anaconda-*.rpm rsync -v ${ANACONDA_SOURCE}/RPMS/*/anaconda-*XFS* genhdlist/sgi_disc/RedHat/RPMS/ rsync -v ${ANACONDA_SOURCE}/SRPMS/anaconda-*XFS* sgiSRPMS/SRPMS/ (cd bootGen/RedHat/RPMS; ln -s ../../../genhdlist/sgi_disc/RedHat/RPMS/anaconda-* .) buildimg: (cd anaconda-xfs/scripts; ./buildinstall --comp i386 --release SGI-XFS ${BOOTGEN} ) cdlinks: -mkdir -p sgiInstall/RedHat -(cd sgiInstall; ln -s ../sgiSRPMS/SRPMS .; ln -s ../bootGen/dosutils . ; \ ln -s ../bootGen/images . ; ln -s ../bootGen/isolinux . ) -(cd sgiInstall/RedHat; ln -s ../../genhdlist/sgi_disc/RedHat/RPMS . ; \ ln -s ../../bootGen/RedHat/base . ) (cd sgiInstall; printf ${CDVERS} > .discinfo) updatedisk: /sbin/modprobe loop dd if=/dev/zero of=anaconda/updates/$(UPDATEIMG) bs=1k count=1440 /sbin/losetup $(LOOPDEV) anaconda/updates/$(UPDATEIMG) /sbin/mke2fs $(LOOPDEV) 1440 mkdir anaconda/updates/foo mount -t ext2 -o loop anaconda/updates/$(UPDATEIMG) anaconda/updates/foo cp anaconda/updates/*.py anaconda/updates/foo umount anaconda/updates/foo rmdir anaconda/updates/foo /sbin/losetup -d $(LOOPDEV) mkdirs: -mkdir -p genhdlist/sgi_disc/RedHat/RPMS -mkdir -p genhdlist/disc1/RedHat/RPMS -mkdir -p genhdlist/disc2/RedHat/RPMS -mkdir -p genhdlist/disc3/RedHat/RPMS -mkdir -p genhdlist/disc4/RedHat/RPMS -mkdir -p genhdlist/disc5/RedHat/RPMS -mkdir -p sgiSRPMS/SRPMS/ seedbootgen: -mkdir -p bootGen/RedHat/RPMS -mkdir -p bootGen/images -mkdir -p bootGen/RedHat/base -mkdir -p bootGen/dosutils (cd bootGen/RedHat/RPMS;rm -f *.rpm; ln -s ${RH_ISO_SOURCE}/disc?/RedHat/RPMS/*.rpm .) (cd genhdlist/disc1/RedHat/RPMS;rm -f *.rpm; ln -s ${RH_ISO_SOURCE}/disc1/RedHat/RPMS/*.rpm .) (cd genhdlist/disc2/RedHat/RPMS;rm -f *.rpm; ln -s ${RH_ISO_SOURCE}/disc2/RedHat/RPMS/*.rpm .) (cd genhdlist/disc3/RedHat/RPMS;rm -f *.rpm; ln -s ${RH_ISO_SOURCE}/disc3/RedHat/RPMS/*.rpm .) cp ${RH_ISO_SOURCE}/disc1/RedHat/base/comps.rpm bootGen/RedHat/base/ (cd bootGen/RedHat/base; ln -s ../../../compsXFS.xml comps.xml) --=-nPDbv5RaDMnFKy3PxN89-- From owner-linux-xfs@oss.sgi.com Wed Feb 19 13:28:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Feb 2003 13:29:04 -0800 (PST) Received: from mxzilla3.xs4all.nl (mxzilla3.xs4all.nl [194.109.6.49]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1JLSu3v006622 for ; Wed, 19 Feb 2003 13:28:57 -0800 Received: from xs1.xs4all.nl (xs1.xs4all.nl [194.109.3.11]) by mxzilla3.xs4all.nl (8.12.3/8.12.3) with ESMTP id h1JLbdW7078448; Wed, 19 Feb 2003 22:37:39 +0100 (CET) Received: from localhost (knuffie@localhost) by xs1.xs4all.nl (8.11.6/8.11.6) with ESMTP id h1JLbdK16692; Wed, 19 Feb 2003 22:37:39 +0100 (CET) (envelope-from knuffie@xs1.xs4all.nl) Date: Wed, 19 Feb 2003 22:37:39 +0100 (CET) From: Seth Mos To: "l.a walsh" cc: linux-xfs@oss.sgi.com Subject: RE: been a while before i could get back to this.. In-Reply-To: <001401c2d84a$b39cc350$1403a8c0@sc.tlinx.org> Message-ID: <20030219223422.A16357-100000@xs1.xs4all.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2790 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: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 852 Lines: 24 On Wed, 19 Feb 2003, l.a walsh wrote: > File system seems fine...It's been used without noticable > problems since problem appeared in _October_. Wasn't real concerned > since rootfs mostly contains stuff that doesn't change much (distro > and config files, configs backed up). Can you tell me what kernel you were running again? Was is the 1.2 based release with a bit older dump and restore? > It's just xfs_dump that dumps...(or doesn't). Wish it wasn't > so rude as to just assume my FS is bad and unmount it -- as everything > else seems fine. Just reducing the options. Did you try using the newer userspace utilities, dump, restore, repair etc. Do you get a kernel panic/oops during the dump or is is xfsdump that bails out? You say it's the rootfs that you are trying to dump. It isn't shared out over NFS perhaps is it? Cheers Seth From owner-linux-xfs@oss.sgi.com Wed Feb 19 14:04:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Feb 2003 14:04:57 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1JM4s3v008623 for ; Wed, 19 Feb 2003 14:04:54 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h1JMDVKp016191 for ; Wed, 19 Feb 2003 14:13:32 -0800 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 JAA25779; Thu, 20 Feb 2003 09:12:14 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id JAA76254; Thu, 20 Feb 2003 09:12:12 +1100 (AEDT) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) with ESMTP id h1JMAGL5001475; Thu, 20 Feb 2003 09:10:16 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h1JMADxQ001464; Thu, 20 Feb 2003 09:10:13 +1100 Date: Thu, 20 Feb 2003 09:10:13 +1100 From: Nathan Scott To: Joe Bacom Cc: linux-xfs@oss.sgi.com Subject: Re: Seg Fault in libattr Message-ID: <20030219221013.GC1053@frodo> References: <200302191419.50007.joebacom@volstate.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200302191419.50007.joebacom@volstate.net> User-Agent: Mutt/1.5.3i X-archive-position: 2791 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: 616 Lines: 20 hi Joe, On Wed, Feb 19, 2003 at 02:19:50PM -0600, Joe Bacom wrote: > Anybody know why libattr.so.1.0.1 would cause a signal 11 segmentation fault > in libncurses.so.5? > > I am building a php extension for accessing extended attributes using the > libattr shared library. When executed, it core dumps with the above seg > fault. Looking at the source for libattr, I can't see a reason for > libncurses to be involved at all. Indeed, libattr does not link with libncurses. What is your actual gdb stacktrace? (and what makes you say that libattr is causing a segfault in libncurses?) cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Feb 19 15:11:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Feb 2003 15:11:58 -0800 (PST) Received: from web12305.mail.yahoo.com (web12305.mail.yahoo.com [216.136.173.103]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1JNBt3v010060 for ; Wed, 19 Feb 2003 15:11:56 -0800 Message-ID: <20030219232040.15751.qmail@web12305.mail.yahoo.com> Received: from [192.41.88.6] by web12305.mail.yahoo.com via HTTP; Wed, 19 Feb 2003 15:20:40 PST Date: Wed, 19 Feb 2003 15:20:40 -0800 (PST) From: Jason Corbett Subject: Re: Corrupted file on iso installer image of XFS 1.2 To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 2792 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: jasoncorbett01@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 505 Lines: 17 I've tried and it errored out when creating the filesystem citing a runtime error that /sbin/mkfs.xfs could not be used, I looked and there was no /sbin/mkfs.xfs. I'm looking at the Makefile now to try and build my own, but who knows if I'll get that working. Thanks for trying to address this, even though you're doing it on your own time. Jason Corbett __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com From owner-linux-xfs@oss.sgi.com Wed Feb 19 16:03:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Feb 2003 16:03:37 -0800 (PST) Received: from mail15.messagelabs.com (mail15.messagelabs.com [63.210.62.243]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1K03S3v011187 for ; Wed, 19 Feb 2003 16:03:29 -0800 X-VirusChecked: Checked X-Env-Sender: jli@Brocade.COM X-Msg-Ref: server-10.tower-15.messagelabs.com!1045699921!38279 Received: (qmail 26223 invoked from network); 20 Feb 2003 00:12:01 -0000 Received: from sj6-b.brocade.com (HELO discus.brocade.com) (63.121.140.220) by server-10.tower-15.messagelabs.com with SMTP; 20 Feb 2003 00:12:01 -0000 Received: from hq-ex-c2.brocade.com (hq-ex-c2.brocade.com [192.168.126.35]) by discus.brocade.com (Postfix) with ESMTP id 7C94C4F605 for ; Wed, 19 Feb 2003 16:11:03 -0800 (PST) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Feb 2003 16:12:06 -0800 Message-ID: <7CBD7127AB037F439CB8146275AE261E37CEB9@hq-ex-6> From: Jason Li To: "'linux-xfs@oss.sgi.com'" Subject: sync doesn't do the job Date: Wed, 19 Feb 2003 16:12:05 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 2793 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: jli@Brocade.COM Precedence: bulk X-list: linux-xfs Content-Length: 335 Lines: 16 Hi, We are running xfs1.1 on linux 2.4.19 with a CF. But sync command doesn't seem to flush all the CF, a remount -ro doesn't sync the buffers either. I heard the xfs uses a different buffer system, is this the cause? Thanks so much for your input. Please cc me on your reply. Regards, Jason [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Wed Feb 19 16:50:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Feb 2003 16:50:36 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1K0oX3v014033 for ; Wed, 19 Feb 2003 16:50:34 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1K0xDKp011381 for ; Wed, 19 Feb 2003 16:59:13 -0800 Received: from Liberator (sshgate.corp.sgi.com [169.238.216.146]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id QAA95761; Wed, 19 Feb 2003 16:58:41 -0800 (PST) Subject: Re: sync doesn't do the job From: Eric Sandeen To: Jason Li Cc: "'linux-xfs@oss.sgi.com'" In-Reply-To: <7CBD7127AB037F439CB8146275AE261E37CEB9@hq-ex-6> References: <7CBD7127AB037F439CB8146275AE261E37CEB9@hq-ex-6> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 19 Feb 2003 18:58:53 -0600 Message-Id: <1045702735.23242.3.camel@Liberator> Mime-Version: 1.0 X-archive-position: 2794 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 950 Lines: 35 Hi Jason - What symptoms are you seeing? Also, any chance you can try the 1.2 code? (although I understand that 1.1 may be in production now). We did fix a last-minute problem in 1.2 which involved remount, readonly not flushing everything to disk. XFS does use it's own "pagebuf" system for metadata, and it also uses delayed allocation on normal buffers, these are both a bit different from other Linux filesystems. However, sync and remount should work as expected. Send us a box and we'll do some testing here. ;-) -Eric On Wed, 2003-02-19 at 18:12, Jason Li wrote: > > Hi, > > We are running xfs1.1 on linux 2.4.19 with a CF. But sync command doesn't > seem to flush all the CF, a remount -ro doesn't sync the buffers either. > > I heard the xfs uses a different buffer system, is this the cause? > > Thanks so much for your input. Please cc me on your reply. > > Regards, > Jason > > > [[HTML alternate version deleted]] > From owner-linux-xfs@oss.sgi.com Wed Feb 19 16:52:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Feb 2003 16:52:06 -0800 (PST) Received: from mail.cnes.com (mail.cnes.com [208.179.92.38]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1K0q33v014494 for ; Wed, 19 Feb 2003 16:52:04 -0800 Received: from oz.cnes.com (wall.cnes.com [208.179.92.60]) by mail.cnes.com (8.12.5/8.12.5) with ESMTP id h1K10hOP011620 for ; Wed, 19 Feb 2003 17:00:43 -0800 Received: from localhost (localhost [127.0.0.1]) by oz.cnes.com (8.9.3/8.9.3) with ESMTP id RAA19148 for ; Wed, 19 Feb 2003 17:00:43 -0800 (PST) Date: Wed, 19 Feb 2003 17:00:43 -0800 From: Scott Jepson To: linux-xfs@oss.sgi.com Subject: Compile problem...undefined reference to `xfs_params' Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2795 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: scott@cnes.com Precedence: bulk X-list: linux-xfs Content-Length: 1547 Lines: 36 Has anyone seen or fixed this problem?: make[1]: Entering directory `/usr/src/linux-2.4-xfs/linux' ld -m elf_i386 -T /usr/src/linux-2.4-xfs/linux/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o init/do_mounts.o --start-group arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o drivers/char/char.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/ide/idedriver.o drivers/scsi/scsidrv.o drivers/cdrom/driver.o drivers/pci/driver.o drivers/video/video.o net/network.o /usr/src/linux-2.4-xfs/linux/arch/i386/lib/lib.a /usr/src/linux-2.4-xfs/linux/lib/lib.a /usr/src/linux-2.4-xfs/linux/arch/i386/lib/lib.a --end-group -o vmlinux fs/fs.o: In function `xfs_cmn_err': fs/fs.o(.text+0x6a172): undefined reference to `xfs_params' fs/fs.o(.text+0x6a188): undefined reference to `xfs_params' fs/fs.o: In function `xfs_ialloc': fs/fs.o(.text+0x717d6): undefined reference to `xfs_params' fs/fs.o: In function `xfs_init': fs/fs.o(.text+0x8528c): undefined reference to `xfs_params' fs/fs.o: In function `xfs_setattr': fs/fs.o(.text+0x8726f): undefined reference to `xfs_params' fs/fs.o(.text+0x8d584): more undefined references to `xfs_params' follow make[1]: *** [kallsyms] Error 1 make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux' make: *** [vmlinux] Error 2 I have tried the 2.4.19 with xfs 1.2 patches and 2.4.20 with the 2.4.20 patches on 2 different machines and got the same results. Thanks, -Scott From owner-linux-xfs@oss.sgi.com Wed Feb 19 17:05:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Feb 2003 17:05:14 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1K15B3v015021 for ; Wed, 19 Feb 2003 17:05:12 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id C7A04186B132; Wed, 19 Feb 2003 17:13:56 -0800 (PST) Date: Wed, 19 Feb 2003 17:13:56 -0800 From: Chris Wedgwood To: "l.a walsh" Cc: "'Seth Mos'" , linux-xfs@oss.sgi.com Subject: Re: been a while before i could get back to this.. Message-ID: <20030220011356.GB22921@f00f.org> References: <4.3.2.7.2.20030219105030.036d3090@pop.xs4all.nl> <001401c2d84a$b39cc350$1403a8c0@sc.tlinx.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001401c2d84a$b39cc350$1403a8c0@sc.tlinx.org> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2796 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: 421 Lines: 16 On Wed, Feb 19, 2003 at 11:11:27AM -0800, l.a walsh wrote: > It's just xfs_dump that dumps...(or doesn't). Wish it wasn't so > rude as to just assume my FS is bad and unmount it -- as everything > else seems fine. i may have missed some details here does xfsdump puke because it gets an error from the kernel, or does it barf internally? either way, are you able to see where this happens? (strace or gdb) --cw From owner-linux-xfs@oss.sgi.com Wed Feb 19 17:09:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Feb 2003 17:09:58 -0800 (PST) Received: from mail15.messagelabs.com (mail15.messagelabs.com [63.210.62.243]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1K19n3v015501 for ; Wed, 19 Feb 2003 17:09:50 -0800 X-VirusChecked: Checked X-Env-Sender: jli@brocade.com X-Msg-Ref: server-26.tower-15.messagelabs.com!1045703413!61086 Received: (qmail 22035 invoked from network); 20 Feb 2003 01:10:14 -0000 Received: from sj6-b.brocade.com (HELO hammer.brocade.com) (63.121.140.220) by server-26.tower-15.messagelabs.com with SMTP; 20 Feb 2003 01:10:14 -0000 Received: from hq-ex-c3.brocade.com (hq-ex-c3.brocade.com [192.168.126.211]) by hammer.brocade.com (8.11.3/8.11.3) with ESMTP id h1K1IPW16488; Wed, 19 Feb 2003 17:18:25 -0800 (PST) Received: by hq-ex-c3.brocade.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Feb 2003 17:18:26 -0800 Message-ID: <7CBD7127AB037F439CB8146275AE261E37CEBA@hq-ex-6> From: Jason Li To: "'Eric Sandeen'" Cc: "'linux-xfs@oss.sgi.com'" Subject: RE: sync doesn't do the job Date: Wed, 19 Feb 2003 17:18:24 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 2797 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: jli@brocade.com Precedence: bulk X-list: linux-xfs Content-Length: 1561 Lines: 69 Hi Eric, Thanks for replying. I tried the following script: for i in `seq 1 100` do echo $i>>myfile done; sync (show dirty buffers) reboot -f and for i in `seq 1 100` do echo $i>>myfile done; sync (show dirty buffers) mount -ro / reboot Both failed to get the 100 numbers in the file. Another thing I tried is to show dirty buffers (with a hack) -- both showed no dirty buffer from the linux side. We can try 1.2, but for now we need to understand where the problem is. Best regards, Jason > What symptoms are you seeing? Also, any chance you can try the 1.2 > code? (although I understand that 1.1 may be in production now). We > did fix a last-minute problem in 1.2 which involved remount, readonly > not flushing everything to disk. > > XFS does use it's own "pagebuf" system for metadata, and it also uses > delayed allocation on normal buffers, these are both a bit different > from other Linux filesystems. However, sync and remount > should work as > expected. > > Send us a box and we'll do some testing here. ;-) > > -Eric > > On Wed, 2003-02-19 at 18:12, Jason Li wrote: > > > > Hi, > > > > We are running xfs1.1 on linux 2.4.19 with a CF. But sync > command doesn't > > seem to flush all the CF, a remount -ro doesn't sync the > buffers either. > > > > I heard the xfs uses a different buffer system, is this the cause? > > > > Thanks so much for your input. Please cc me on your reply. > > > > Regards, > > Jason > > > > > > [[HTML alternate version deleted]] > > > > > [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Wed Feb 19 17:29:40 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Feb 2003 17:29:42 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1K1Te3v016088 for ; Wed, 19 Feb 2003 17:29:40 -0800 Received: from relay1.corp.sgi.com (ether-spindle.corp.sgi.com [192.26.51.29]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1K1cKG8020768 for ; Wed, 19 Feb 2003 17:38:20 -0800 Received: from Liberator (sshgate.corp.sgi.com [169.238.216.146]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id RAA52139; Wed, 19 Feb 2003 17:37:48 -0800 (PST) Subject: RE: sync doesn't do the job From: Eric Sandeen To: Jason Li Cc: "'linux-xfs@oss.sgi.com'" In-Reply-To: <7CBD7127AB037F439CB8146275AE261E37CEBA@hq-ex-6> References: <7CBD7127AB037F439CB8146275AE261E37CEBA@hq-ex-6> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 19 Feb 2003 19:38:00 -0600 Message-Id: <1045705082.23242.21.camel@Liberator> Mime-Version: 1.0 X-archive-position: 2798 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1251 Lines: 47 Jason - one other thing that occurred to me... does the CF system do write-caching? Might be interesting to test this on a spinning disk, if you can. (and if it's IDE, explicitly turn off write caching). I tried the reboot -f test on essentially top of tree devel code, on a scsi drive, and it worked fine. I also tested it on 1.1 code (which we released for vanilla kernel 2.4.18, and Red Hat 2.4.9-based - I tested the Red Hat kernel), and it also worked fine. (I left out the "(show dirty buffers)" part, not sure what you're doing there.) You said it's 1.1 on linux 2.4.19 - I wonder if the forward port may have caused problems? -Eric On Wed, 2003-02-19 at 19:18, Jason Li wrote: > > Hi Eric, > > Thanks for replying. > > I tried the following script: > for i in `seq 1 100` do echo $i>>myfile done; > sync > (show dirty buffers) > reboot -f > and > for i in `seq 1 100` do echo $i>>myfile done; > sync > (show dirty buffers) > mount -ro / > reboot > Both failed to get the 100 numbers in the file. > > Another thing I tried is to show dirty buffers (with a hack) -- both showed > no dirty buffer from the linux side. > > We can try 1.2, but for now we need to understand where the problem is. > > Best regards, > Jason From owner-linux-xfs@oss.sgi.com Wed Feb 19 17:40:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Feb 2003 17:40:21 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1K1eI3v016579 for ; Wed, 19 Feb 2003 17:40:19 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h1K1mvKp018055 for ; Wed, 19 Feb 2003 17:48:58 -0800 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA27589; Thu, 20 Feb 2003 12:47:34 +1100 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 511013000B8; Thu, 20 Feb 2003 12:47:32 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id C2B348F; Thu, 20 Feb 2003 12:47:32 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Scott Jepson Cc: linux-xfs@oss.sgi.com Subject: Re: Compile problem...undefined reference to `xfs_params' In-reply-to: Your message of "Wed, 19 Feb 2003 17:00:43 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 20 Feb 2003 12:47:27 +1100 Message-ID: <25200.1045705647@kao2.melbourne.sgi.com> X-archive-position: 2799 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2091 Lines: 91 On Wed, 19 Feb 2003 17:00:43 -0800, Scott Jepson wrote: >Has anyone seen or fixed this problem?: >fs/fs.o: In function `xfs_cmn_err': >fs/fs.o(.text+0x6a172): undefined reference to `xfs_params' XFS did not build with CONFIG_SYSCTL=n. diff fs/xfs/linux/Makefile --- fs/xfs/linux/Makefile +++ fs/xfs/linux/Makefile @@ -49,9 +49,9 @@ export-objs := xfs_globals.o obj-$(CONFIG_PROC_FS) += xfs_stats.o -obj-$(CONFIG_SYSCTL) += xfs_sysctl.o -obj-y += xfs_aops.o \ +obj-y += xfs_sysctl.o \ + xfs_aops.o \ xfs_behavior.o \ xfs_file.o \ xfs_fs_subr.o \ diff fs/xfs/linux/xfs_sysctl.c --- fs/xfs/linux/xfs_sysctl.c +++ fs/xfs/linux/xfs_sysctl.c @@ -35,9 +35,13 @@ #include /* - * Tunable XFS parameters + * Tunable XFS parameters. xfs_params is required even when CONFIG_SYSCTL=n, + * other XFS code uses these values. */ +xfs_param_t xfs_params = { 128, 32, 0, 1, 0, 0, 0 }; + +#ifdef CONFIG_SYSCTL extern struct xfsstats xfsstats; STATIC ulong xfs_min[XFS_PARAM] = { \ @@ -45,8 +49,6 @@ STATIC ulong xfs_max[XFS_PARAM] = { \ XFS_REFCACHE_SIZE_MAX, XFS_REFCACHE_SIZE_MAX, 1, 1, 1, 1, 127 }; -xfs_param_t xfs_params = { 128, 32, 0, 1, 0, 0, 0 }; - static struct ctl_table_header *xfs_table_header; @@ -143,16 +145,21 @@ {CTL_FS, "fs", NULL, 0, 0555, xfs_dir_table}, {0} }; +#endif /* CONFIG_SYSCTL */ void xfs_sysctl_register(void) { +#ifdef CONFIG_SYSCTL xfs_table_header = register_sysctl_table(xfs_root_table, 1); +#endif } void xfs_sysctl_unregister(void) { +#ifdef CONFIG_SYSCTL if (xfs_table_header) unregister_sysctl_table(xfs_table_header); +#endif } diff fs/xfs/linux/xfs_sysctl.h --- fs/xfs/linux/xfs_sysctl.h +++ fs/xfs/linux/xfs_sysctl.h @@ -64,12 +64,7 @@ extern xfs_param_t xfs_params; -#ifdef CONFIG_SYSCTL extern void xfs_sysctl_register(void); extern void xfs_sysctl_unregister(void); -#else -static __inline void xfs_sysctl_register(void) { }; -static __inline void xfs_sysctl_unregister(void) { }; -#endif #endif /* __XFS_SYSCTL_H__ */ From owner-linux-xfs@oss.sgi.com Wed Feb 19 17:43:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Feb 2003 17:43:03 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1K1gx3v017025 for ; Wed, 19 Feb 2003 17:43:00 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1K21Gkq017892 for ; Wed, 19 Feb 2003 20:01:18 -0600 Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id h1K1oY511078; Thu, 20 Feb 2003 12:50:34 +1100 Date: Thu, 20 Feb 2003 12:50:34 +1100 From: Keith Owens Message-Id: <200302200150.h1K1oY511078@sherman.melbourne.sgi.com> Subject: TAKE - XFS did not build with CONFIG_SYSCTL=n X-archive-position: 2800 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 368 Lines: 14 XFS did not build with CONFIG_SYSCTL=n Date: Wed Feb 19 17:49:13 PST 2003 Workarea: sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:140011a linux/fs/xfs/linux/Makefile - 1.67 linux/fs/xfs/linux/xfs_sysctl.h - 1.8 linux/fs/xfs/linux/xfs_sysctl.c - 1.13 From owner-linux-xfs@oss.sgi.com Wed Feb 19 17:44:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Feb 2003 17:44:06 -0800 (PST) Received: from phoenix.infradead.org (phoenix.mvhi.com [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1K1i03v017315 for ; Wed, 19 Feb 2003 17:44:02 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18lft0-0005VG-00; Thu, 20 Feb 2003 01:52:30 +0000 Date: Thu, 20 Feb 2003 01:52:30 +0000 From: Christoph Hellwig To: Scott Jepson Cc: linux-xfs@oss.sgi.com Subject: Re: Compile problem...undefined reference to `xfs_params' Message-ID: <20030220015229.A21115@infradead.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from scott@cnes.com on Wed, Feb 19, 2003 at 05:00:43PM -0800 X-archive-position: 2801 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 1657 Lines: 32 On Wed, Feb 19, 2003 at 05:00:43PM -0800, Scott Jepson wrote: > > Has anyone seen or fixed this problem?: > make[1]: Entering directory `/usr/src/linux-2.4-xfs/linux' > ld -m elf_i386 -T /usr/src/linux-2.4-xfs/linux/arch/i386/vmlinux.lds -e > stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o > init/version.o init/do_mounts.o --start-group arch/i386/kernel/kernel.o > arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o > drivers/char/char.o drivers/block/block.o drivers/misc/misc.o > drivers/net/net.o drivers/media/media.o drivers/ide/idedriver.o > drivers/scsi/scsidrv.o drivers/cdrom/driver.o drivers/pci/driver.o > drivers/video/video.o net/network.o > /usr/src/linux-2.4-xfs/linux/arch/i386/lib/lib.a > /usr/src/linux-2.4-xfs/linux/lib/lib.a > /usr/src/linux-2.4-xfs/linux/arch/i386/lib/lib.a --end-group -o vmlinux > fs/fs.o: In function `xfs_cmn_err': > fs/fs.o(.text+0x6a172): undefined reference to `xfs_params' > fs/fs.o(.text+0x6a188): undefined reference to `xfs_params' > fs/fs.o: In function `xfs_ialloc': > fs/fs.o(.text+0x717d6): undefined reference to `xfs_params' > fs/fs.o: In function `xfs_init': > fs/fs.o(.text+0x8528c): undefined reference to `xfs_params' > fs/fs.o: In function `xfs_setattr': > fs/fs.o(.text+0x8726f): undefined reference to `xfs_params' > fs/fs.o(.text+0x8d584): more undefined references to `xfs_params' follow > make[1]: *** [kallsyms] Error 1 > make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux' > make: *** [vmlinux] Error 2 It looks like you build without CONFIG_SYSTCL, is that intended? Anyway, I think xfs_params should be moved from xfs_sysctl.c to xfs_globals.c From owner-linux-xfs@oss.sgi.com Wed Feb 19 17:50:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Feb 2003 17:50:30 -0800 (PST) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.58.33]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1K1oR3v017931 for ; Wed, 19 Feb 2003 17:50:27 -0800 Received: from Shiva (shiva [192.168.3.20]) by ishtar.tlinx.org (8.12.6/8.12.2/SuSE Linux 0.6) with ESMTP id h1K1x2Lf023250; Wed, 19 Feb 2003 17:59:02 -0800 From: "l.a walsh" To: Cc: "'Chris Wedgwood'" , "'Seth Mos'" Subject: RE: been a while before i could get back to this.. Date: Wed, 19 Feb 2003 17:59:02 -0800 Message-ID: <000001c2d883$a454a000$1403a8c0@sc.tlinx.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20030219223422.A16357-100000@xs1.xs4all.nl> Importance: Normal X-archive-position: 2802 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: xfs@tlinx.org Precedence: bulk X-list: linux-xfs Content-Length: 2304 Lines: 63 > Can you tell me what kernel you were running again? Was is > the 1.2 based > release with a bit older dump and restore? linux-2.4.20 (vanilla) with feb 04,04 xfs-all patch xfsdump 2.2.3. > Just reducing the options. Did you try using the newer userspace > utilities, dump, restore, repair etc. ---- will try 2.2.6 later...does it build on SuSE w/o errors yet? There was some bit about it requiring 'curses' -- I just went through and changed all the refs to 'ncurses'.... > > Do you get a kernel panic/oops during the dump or is is > xfsdump that bails > out? You say it's the rootfs that you are trying to dump. It > isn't shared > out over NFS perhaps is it? ...checking...nope, but I do have it shared via SMB, though normally it's not 'mounted' on any workstations it serves (only 1 active workstation client right now, and I'm on it. No kernel panic or oops but it flies by awfully fast. It's just so darn unfriendly...since I can't really do anything other than press reset at that point....Am in process of creating tbz2 archives for the other partitions right now...dang bzip2 is ..slow...I only have 6G of data, and its still cranking (backup ~3G so far) > From: Chris Wedgwood [mailto:cw@f00f.org] > does xfsdump puke because it gets an error from the kernel, or does it > barf internally? --- Hmm....it appears that something in the kernel driver thinks that the disk is corrupt so it unmounts the root drive. xfs just sorta exits... it flies by on the screen so fast and wasn't being cooperative when I wanted to scroll back. I wish there was a "pipe" mode where I could say, no, don't buffer, and flush it every character. Inefficient as *bleep*, but in some situations.... Actually, now that I think about it, if I pipe the output to /tmp the pipe would already be open and its on a different partition, so theoretically, the output should be saved, no? > either way, are you able to see where this happens? (strace or gdb) --- Haven't tried strace...was hoping this bug would tickle someone's "aha" button and it was already 'solved'.... I'll try to get more info ...but first need to rebuild the utils. Darn redhat RPM's aren't compatible with SuSE. Maybe you could link it using the downrev of GLIBC and cover both RH and SuSE? Just a thought. -linda From owner-linux-xfs@oss.sgi.com Wed Feb 19 19:24:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Feb 2003 19:25:04 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1K3Ot3v018975 for ; Wed, 19 Feb 2003 19:24:56 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1K3XYKp004061 for ; Wed, 19 Feb 2003 19:33:35 -0800 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 h1K3WGNt9266382; Thu, 20 Feb 2003 14:32:17 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h1K3WELK9265640; Thu, 20 Feb 2003 14:32:14 +1100 (EST) Date: Thu, 20 Feb 2003 14:32:14 +1100 (EST) From: Nathan Scott Message-Id: <200302200332.h1K3WELK9265640@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, agruen@suse.de Subject: TAKE - acl X-archive-position: 2803 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@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 702 Lines: 25 Merge symbol visibility patch from Andreas for hiding symbols in libacl which we don't want exported, provided the compiler supports that (adds a configure check too). Date: Wed Feb 19 19:31:38 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:140014a cmd/acl/m4/visibility_hidden.m4 - 1.1 cmd/acl/m4/Makefile - 1.1 cmd/acl/aclocal.m4 - 1.1 cmd/acl/configure.in - 1.23 cmd/acl/Makefile - 1.14 cmd/acl/VERSION - 1.44 cmd/acl/doc/CHANGES - 1.51 cmd/acl/debian/changelog - 1.38 cmd/acl/libacl/libobj.h - 1.7 cmd/acl/libacl/libacl.h - 1.7 cmd/acl/include/config.h.in - 1.5 From owner-linux-xfs@oss.sgi.com Wed Feb 19 19:47:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Feb 2003 19:47:45 -0800 (PST) Received: from mail.cnes.com (mail.cnes.com [208.179.92.38]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1K3lb3v019546 for ; Wed, 19 Feb 2003 19:47:38 -0800 Received: from oz.cnes.com (wall.cnes.com [208.179.92.60]) by mail.cnes.com (8.12.5/8.12.5) with ESMTP id h1K3tiOP012553; Wed, 19 Feb 2003 19:55:44 -0800 Received: from localhost (localhost [127.0.0.1]) by oz.cnes.com (8.9.3/8.9.3) with ESMTP id TAA19278; Wed, 19 Feb 2003 19:55:43 -0800 (PST) Date: Wed, 19 Feb 2003 19:55:43 -0800 From: Scott Jepson To: Christoph Hellwig cc: linux-xfs@oss.sgi.com Subject: Re: Compile problem...undefined reference to `xfs_params' In-Reply-To: <20030220015229.A21115@infradead.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2804 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: scott@cnes.com Precedence: bulk X-list: linux-xfs Content-Length: 1806 Lines: 44 > > > > Has anyone seen or fixed this problem?: > > make[1]: Entering directory `/usr/src/linux-2.4-xfs/linux' > > ld -m elf_i386 -T /usr/src/linux-2.4-xfs/linux/arch/i386/vmlinux.lds -e > > stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o > > init/version.o init/do_mounts.o --start-group arch/i386/kernel/kernel.o > > arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o > > drivers/char/char.o drivers/block/block.o drivers/misc/misc.o > > drivers/net/net.o drivers/media/media.o drivers/ide/idedriver.o > > drivers/scsi/scsidrv.o drivers/cdrom/driver.o drivers/pci/driver.o > > drivers/video/video.o net/network.o > > /usr/src/linux-2.4-xfs/linux/arch/i386/lib/lib.a > > /usr/src/linux-2.4-xfs/linux/lib/lib.a > > /usr/src/linux-2.4-xfs/linux/arch/i386/lib/lib.a --end-group -o vmlinux > > fs/fs.o: In function `xfs_cmn_err': > > fs/fs.o(.text+0x6a172): undefined reference to `xfs_params' > > fs/fs.o(.text+0x6a188): undefined reference to `xfs_params' > > fs/fs.o: In function `xfs_ialloc': > > fs/fs.o(.text+0x717d6): undefined reference to `xfs_params' > > fs/fs.o: In function `xfs_init': > > fs/fs.o(.text+0x8528c): undefined reference to `xfs_params' > > fs/fs.o: In function `xfs_setattr': > > fs/fs.o(.text+0x8726f): undefined reference to `xfs_params' > > fs/fs.o(.text+0x8d584): more undefined references to `xfs_params' follow > > make[1]: *** [kallsyms] Error 1 > > make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux' > > make: *** [vmlinux] Error 2 > > It looks like you build without CONFIG_SYSTCL, is that intended? > Anyway, I think xfs_params should be moved from xfs_sysctl.c to xfs_globals.c > > Yes, I'm running a stripped down kernel for resource reasons. Thanks to everyone for their prompt reply, keep up the good work! Thanks, -Scott From owner-linux-xfs@oss.sgi.com Wed Feb 19 20:43:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Feb 2003 20:43:48 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1K4he3v020254 for ; Wed, 19 Feb 2003 20:43:41 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1K4qKG8019305 for ; Wed, 19 Feb 2003 20:52:21 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id WAA52807 for ; Wed, 19 Feb 2003 22:52:19 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id WAA46271 for ; Wed, 19 Feb 2003 22:52:20 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h1K4onU10409; Wed, 19 Feb 2003 22:50:49 -0600 Message-Id: <200302200450.h1K4onU10409@stout.americas.sgi.com> Date: Wed, 19 Feb 2003 22:50:49 -0600 Subject: TAKE - Allow the pagebuf daemon to suspend in 2.5.x X-archive-position: 2805 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 438 Lines: 15 Apparently suspend may still have problems, but it looks like this is the right way to hook into the ACPI suspend code in 2.5. Allow the pagebuf daemon to suspend. Date: Wed Feb 19 20:50:22 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.5.x-xfs/workarea The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:140015a linux/fs/xfs/pagebuf/page_buf.c - 1.97 From owner-linux-xfs@oss.sgi.com Wed Feb 19 23:50:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Feb 2003 23:50:56 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1K7ok3v023285 for ; Wed, 19 Feb 2003 23:50:47 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 4B904149F6; Thu, 20 Feb 2003 08:59:27 +0100 (MET) Date: Thu, 20 Feb 2003 08:59:26 +0100 From: Andi Kleen To: Nathan Scott Cc: linux-xfs@oss.sgi.com, agruen@suse.de Subject: Re: TAKE - acl_init Message-ID: <20030220075926.GA21973@wotan.suse.de> References: <200302182335.h1INZ7la8907219@snort.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200302182335.h1INZ7la8907219@snort.melbourne.sgi.com> X-archive-position: 2806 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: ak@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 286 Lines: 11 On Wed, Feb 19, 2003 at 10:35:07AM +1100, Nathan Scott wrote: > Fix a zero-length malloc in acl_init - causing QA failures > when libacl is linked with the electric fence library. Still using ElectricFence and not valgrind for testing ? @) valgrind will find much more bugs. -Andi From owner-linux-xfs@oss.sgi.com Thu Feb 20 00:19:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Feb 2003 00:19:44 -0800 (PST) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1K8Ja3v024034 for ; Thu, 20 Feb 2003 00:19:37 -0800 Received: from auto-nb1.xs4all.nl (host-4.coltex.demon.nl [212.238.252.68]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id h1K8SInb069206; Thu, 20 Feb 2003 09:28:19 +0100 (CET) Message-Id: <4.3.2.7.2.20030220085856.0356e3a0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Feb 2003 09:28:11 +0100 To: "l.a walsh" , From: Seth Mos Subject: RE: been a while before i could get back to this.. Cc: "'Chris Wedgwood'" In-Reply-To: <000001c2d883$a454a000$1403a8c0@sc.tlinx.org> References: <20030219223422.A16357-100000@xs1.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2807 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: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 2565 Lines: 71 At 17:59 19-2-2003 -0800, l.a walsh wrote: > > Can you tell me what kernel you were running again? Was is > > the 1.2 based > > release with a bit older dump and restore? > >linux-2.4.20 (vanilla) with feb 04,04 xfs-all patch > >xfsdump 2.2.3. Can you try a newer CVS perhaps. There has been some CVS breakage this month. You might be affected. >No kernel panic or oops but it flies by awfully fast. It's just >so darn unfriendly...since I can't really do anything other than >press reset at that point....Am in process of creating tbz2 archives >for the other partitions right now...dang bzip2 is ..slow...I only >have 6G of data, and its still cranking (backup ~3G so far) if /var is seperate partition you might be able to find the filesystem shutdown message in the /var/log/messages log. That might prove usefull. > > From: Chris Wedgwood [mailto:cw@f00f.org] > > does xfsdump puke because it gets an error from the kernel, or does it > > barf internally? >--- > Hmm....it appears that something in the kernel driver thinks >that the disk is corrupt so it unmounts the root drive. xfs just >sorta exits... it flies by on the screen so fast and wasn't being >cooperative when I wanted to scroll back. As soon as XFS detects a corruption error it shuts down the partition to prevent worse. There must be something wedged that only gets triggered by xfsdump. > I wish there was a "pipe" mode where I could say, no, don't >buffer, and flush it every character. Inefficient as *bleep*, but >in some situations.... > > Actually, now that I think about it, if I pipe the output >to /tmp the pipe would already be open and its on a different partition, >so theoretically, the output should be saved, no? cd /tmp nohup xfsdump -yada yada & this should save at least the xfsdump output. Even if the root fs shutdown you should still be able to read and write other partitions. > Haven't tried strace...was hoping this bug would tickle someone's >"aha" button and it was already 'solved'.... Nay. > I'll try to get more info ...but first need to rebuild the utils. >Darn redhat RPM's aren't compatible with SuSE. Maybe you could link it >using the downrev of GLIBC and cover both RH and SuSE? Just a thought. You can rebuild the rpms safely on a SuSE machine. You can try the following (not sure if it works) rpm --rebuild --nodeps xfsprogs-2.??.src.rpm This should write some rpms to the rpm build directory, wherever that is on SuSE. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Thu Feb 20 01:14:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Feb 2003 01:14:30 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1K9EM3v025194 for ; Thu, 20 Feb 2003 01:14:22 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1K9EMNp025193 for linux-xfs@oss.sgi.com; Thu, 20 Feb 2003 01:14:22 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1K9EK3x025179 for ; Thu, 20 Feb 2003 01:14:20 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1K9CYYV025153; Thu, 20 Feb 2003 01:12:34 -0800 Date: Thu, 20 Feb 2003 01:12:34 -0800 Message-Id: <200302200912.h1K9CYYV025153@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 223] New: mounting xfs on raid0 in linux-2.5.62 triggers BUG at ll_rw_blk.c:2000 X-Bugzilla-Reason: AssignedTo X-archive-position: 2808 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 3062 Lines: 79 http://oss.sgi.com/bugzilla/show_bug.cgi?id=223 Summary: mounting xfs on raid0 in linux-2.5.62 triggers BUG at ll_rw_blk.c:2000 Product: Linux XFS Version: unspecified Platform: IA32 OS/Version: Linux Status: NEW Severity: major Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: vapier@gentoo.org i'm using 2.5.62 from bitkeeper (after a bunch of xfs patches ... basically synced up around 04:00 EST) the bug existed before the series of XFS patches and after ... i was hoping that this patch in particular would have fixed my problem: http://linux.bkbits.net:8080/linux-2.5/cset@1.990.2.5?nav=index.html|ChangeSet@-1d but alas, no change in behavior (still trigger BUG() in ll_rw_blk.c) Hardware is a Pentium 3 using a Triones Technologies, Inc. HPT366/368/370/370A/372 (rev 02) PCI IDE card to run 4 IDE hard drives in RAID0 from `dmesg`: XFS mounting filesystem md(9,0) ------------[ cut here ]------------ kernel BUG at drivers/block/ll_rw_blk.c:2000! invalid operand: 0000 CPU: 0 EIP: 0060:[] Not tainted (c02cfb06 ) EFLAGS: 00010246 EIP is at submit_bio+0x16/0x64 eax: 00000000 ebx: 00000000 ecx: f7fd5824 edx: 00000000 esi: f7fd5824 edi: 00000020 ebp: f2511b80 esp: f2511b7c ds: 007b es: 007b ss: 0068 Process mount (pid: 1842, threadinfo=f2510000 task=f3baecc0) Stack: 00001000 f2511bdc c027841a 00000000 f7fd5824 f252e7e4 0000bb9e f3320e00 00000000 1280bbbe 00020000 00000000 00000020 00000000 f252e7e4 f2511be0 c0277822 f252e7e4 00000020 00000000 f252e7e4 f2740000 00020000 00000000 Call Trace: [] pagebuf_iorequest+0x2da/0x30c [] pagebuf_associate_memory+0x6a/0x174 [] xfsbdstrat+0x22/0x28 [] xlog_bread+0x4a/0x88 [] xlog_find_verify_cycle+0xdc/0x1b4 [] xlog_find_cycle_start+0x1c/0x84 [] xlog_find_head+0x246/0x3c0 [] xlog_find_tail+0x18/0x38c [] xlog_alloc_log+0x2dd/0x3c0 [] xlog_recover+0x1e/0xa0 [] xfs_log_mount+0x58/0xc0 [] xfs_log_mount+0x83/0xc0 [] xfs_mountfs+0x9d7/0xddc [] xfs_setsize_buftarg+0x2e/0x50 [] xfs_mount+0x216/0x280 [] linvfs_fill_super+0x144/0x2ac [] vsprintf+0x16/0x1c [] sprintf+0x14/0x18 [] sb_set_blocksize+0x18/0x48 [] get_sb_bdev+0xe8/0x12c [] linvfs_get_sb+0x1e/0x28 [] linvfs_fill_super+0x0/0x2ac [] do_kern_mount+0x48/0xa8 [] do_add_mount+0x62/0x150 [] do_mount+0x139/0x150 [] sys_mount+0x136/0x224 [] syscall_call+0x7/0xb Code: 0f 0b d0 07 c8 3a 43 c0 89 f6 83 79 24 00 75 0a 0f 0b d1 07 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Feb 20 01:56:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Feb 2003 01:56:13 -0800 (PST) Received: from ente.berdmann.de (frnk-d514e1ad.dsl.mediaWays.net [213.20.225.173]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1K9u53v026395 for ; Thu, 20 Feb 2003 01:56:07 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=localhost) by ente.berdmann.de with esmtp (Exim 3.35 #1) id 18lnZA-0006jj-00; Thu, 20 Feb 2003 11:04:32 +0100 Received: from 192.168.1.1 ( [192.168.1.1]) as user be@ente.berdmann.de by apollo.berdmann.de with HTTP; Thu, 20 Feb 2003 11:04:32 +0100 Message-ID: <1045735472.3e54a83029546@apollo.berdmann.de> Date: Thu, 20 Feb 2003 11:04:32 +0100 From: Bernhard Erdmann To: Russell Cattelan Cc: Jenny Williams , linux-xfs@oss.sgi.com Subject: Re: Corrupted file on iso installer image of XFS 1.2 References: <1045687031.1716.99.camel@lupo.thebarn.com> In-Reply-To: <1045687031.1716.99.camel@lupo.thebarn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 192.168.1.1 X-archive-position: 2809 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: be@berdmann.de Precedence: bulk X-list: linux-xfs Content-Length: 593 Lines: 21 Zitat von Russell Cattelan : > Ok the installer iso has been respun the iso the athlon kernels. > The acl-devel and attr-devel packages have also been updated > to libacl-devel and libattr-devel. > I have not tested this iso but hopefully nothing in the > build process has gone a muck so it should work no worse than > the old one. Hi Russel, I just tried this new installer: it fails making the filesystems, both in kickstart mode as well as in manual mode. anacdump.txt reads: RuntimeError: /usr/sbin/mkfs.xfs can not be run (shouldn't mkfs.xfs be in /sbin?) From owner-linux-xfs@oss.sgi.com Thu Feb 20 02:45:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Feb 2003 02:45:06 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1KAj13v030142 for ; Thu, 20 Feb 2003 02:45:01 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1KAj1s9030141 for linux-xfs@oss.sgi.com; Thu, 20 Feb 2003 02:45:01 -0800 Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1KAiw3v030125; Thu, 20 Feb 2003 02:44:59 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id AC1EC186B132; Thu, 20 Feb 2003 02:53:45 -0800 (PST) Date: Thu, 20 Feb 2003 02:53:45 -0800 From: Chris Wedgwood To: bugzilla-daemon@oss.sgi.com Cc: xfs-master@oss.sgi.com, Andi Kleen Subject: Re: [Bug 223] New: mounting xfs on raid0 in linux-2.5.62 triggers BUG at ll_rw_blk.c:2000 Message-ID: <20030220105345.GA25064@f00f.org> References: <200302200912.h1K9CYYV025153@oss.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200302200912.h1K9CYYV025153@oss.sgi.com> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2810 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: 741 Lines: 26 On Thu, Feb 20, 2003 at 01:12:34AM -0800, bugzilla-daemon@oss.sgi.com wrote: > http://oss.sgi.com/bugzilla/show_bug.cgi?id=223 > > Summary: mounting xfs on raid0 in linux-2.5.62 triggers BUG at > ll_rw_blk.c:2000 > Product: Linux XFS > Version: unspecified > Platform: IA32 > OS/Version: Linux > Status: NEW > Severity: major > Priority: High > Component: XFS kernel code > AssignedTo: xfs-master@oss.sgi.com > ReportedBy: vapier@gentoo.org I think Andi Kleen already reported this and it was decided the raid layers were passing bogons to ll_rw_block. Andi, can you please comment on this perhaps? --cw From owner-linux-xfs@oss.sgi.com Thu Feb 20 02:48:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Feb 2003 02:48:33 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1KAmS3v030618 for ; Thu, 20 Feb 2003 02:48:28 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1KAmSWU030617 for linux-xfs@oss.sgi.com; Thu, 20 Feb 2003 02:48:28 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1KAmQ3v030603; Thu, 20 Feb 2003 02:48:27 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id BDE1114448; Thu, 20 Feb 2003 11:57:07 +0100 (MET) Date: Thu, 20 Feb 2003 11:57:04 +0100 From: Andi Kleen To: Chris Wedgwood Cc: bugzilla-daemon@oss.sgi.com, xfs-master@oss.sgi.com, Andi Kleen Subject: Re: [Bug 223] New: mounting xfs on raid0 in linux-2.5.62 triggers BUG at ll_rw_blk.c:2000 Message-ID: <20030220105704.GE10374@wotan.suse.de> References: <200302200912.h1K9CYYV025153@oss.sgi.com> <20030220105345.GA25064@f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030220105345.GA25064@f00f.org> X-archive-position: 2811 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: ak@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 275 Lines: 12 > I think Andi Kleen already reported this and it was decided the raid > layers were passing bogons to ll_rw_block. It does not split requests correctly in all cases. > > Andi, can you please comment on this perhaps? See http://bugme.osdl.org/show_bug.cgi?id=349 -Andi From owner-linux-xfs@oss.sgi.com Thu Feb 20 08:01:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Feb 2003 08:02:03 -0800 (PST) Received: from mail.epost.de (mail.epost.de [193.28.100.165] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1KG1q3v008754 for ; Thu, 20 Feb 2003 08:01:53 -0800 Received: from epost.de (217.110.232.6) by mail.epost.de (6.7.015) (authenticated as rainer.traut@epost.de) id 3E426BBE001C6EE3 for linux-xfs@oss.sgi.com; Thu, 20 Feb 2003 16:42:01 +0100 Message-ID: <3E54F749.4050209@epost.de> Date: Thu, 20 Feb 2003 16:42:01 +0100 From: Rainer Traut User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030216 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: HD broken? (mkfs.xfs) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2812 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: rainer.traut@epost.de Precedence: bulk X-list: linux-xfs Content-Length: 2547 Lines: 54 Hi, when making a new xfs fs I get this output. [root@pc0797 src]# mkfs.xfs /dev/sdb1 -f RET 0 writing 69632bytes at blkno=0(0), 0x8086c90 RET 0 writing 512bytes at blkno=0(0), 0x8086c90 meta-data=/dev/sdb1 isize=256 agcount=9, agsize=262144 blks data = bsize=4096 blocks=2220978, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200, version=1 = sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 RET 9097061376 writing 65536bytes at blkno=9097061376(17767698), 0x8086c90 RET 4294983680 writing 512bytes at blkno=4294983680(8388640), 0x8086c90 RET 4294984192 writing 512bytes at blkno=4294984192(8388641), 0x8086c90 RET 0 writing 512bytes at blkno=0(0), 0x8086db8 RET 512 writing 512bytes at blkno=512(1), 0x8086db8 RET 1024 writing 512bytes at blkno=1024(2), 0x8086db8 RET 4096 writing 4096bytes at blkno=4096(8), 0x8086db8 RET 8192 writing 4096bytes at blkno=8192(16), 0x8086db8 RET 12288 writing 4096bytes at blkno=12288(24), 0x8086db8 RET 1073741824 writing 512bytes at blkno=1073741824(2097152), 0x8086db8 RET 1073742336 writing 512bytes at blkno=1073742336(2097153), 0x8086db8 RET 1073742848 writing 512bytes at blkno=1073742848(2097154), 0x8086db8 RET 1073745920 writing 4096bytes at blkno=1073745920(2097160), 0x8086db8 RET 1073750016 writing 4096bytes at blkno=1073750016(2097168), 0x8086db8 RET 1073754112 writing 4096bytes at blkno=1073754112(2097176), 0x8086db8 RET 2147483648 writing 512bytes at blkno=2147483648(4194304), 0x8086db8 RET 2147484160 writing 512bytes at blkno=2147484160(4194305), 0x8086db8 RET 2147484672 writing 512bytes at blkno=2147484672(4194306), 0x8086db8 RET 2147487744 writing 4096bytes at blkno=2147487744(4194312), 0x8086db8 RET 2147491840 writing 4096bytes at blkno=2147491840(4194320), 0x8086db8 RET 2147495936 writing 4096bytes at blkno=2147495936(4194328), 0x8086db8 RET 3221225472 writing 512bytes at blkno=3221225472(6291456), 0x8086db8 RET 3221225984 writing 512bytes at blkno=3221225984(6291457), 0x8086db8 ... [root@pc0797 src]# uname -a Linux pc0797.bgs-ing.de 2.4.18-24SGI_XFS_1.2 #1 Tue Feb 18 12:47:10 CET 2003 i686 unknown [root@pc0797 src]# rpm -qa|grep xfs XFree86-xfs-4.2.0-8 xfsprogs-2.3.5-0 [root@pc0797 src]# cat /etc/redhat-release Red Hat Linux release 7.3 (Valhalla) [root@pc0797 src]# Might this tell me my hd is broken? Thank you Rainer From owner-linux-xfs@oss.sgi.com Thu Feb 20 08:11:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Feb 2003 08:11:10 -0800 (PST) Received: from cideweb.com (dns3.cideweb.com [217.11.125.67]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1KGAv3v010086 for ; Thu, 20 Feb 2003 08:10:59 -0800 Received: (qmail 5729 invoked by uid 1023); 20 Feb 2003 16:19:39 -0000 Received: from unknown (HELO oceane) (192.168.0.250) by luna.cideweb.com with SMTP; 20 Feb 2003 16:19:37 -0000 Content-Type: text/plain; charset="iso-8859-15" From: Eduardo To: linux-xfs@oss.sgi.com Subject: CXFS Clustering on linux Date: Thu, 20 Feb 2003 17:19:35 +0100 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200302201719.35854.htb@cideweb.com> X-archive-position: 2813 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: htb@cideweb.com Precedence: bulk X-list: linux-xfs Content-Length: 60 Lines: 4 Hi is CXFS available for linux? where? is it free? Regards From owner-linux-xfs@oss.sgi.com Thu Feb 20 08:17:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Feb 2003 08:17:18 -0800 (PST) Received: from smtp.unc.edu (smtpsrv11.isis.unc.edu [152.2.1.242]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1KGHD3v010588 for ; Thu, 20 Feb 2003 08:17:14 -0800 Received: from jennyw (dhcp01762.wireless.unc.edu [152.19.251.24]) by smtp.unc.edu (8.12.2/8.12.2) with ESMTP id h1KGOoLX011735; Thu, 20 Feb 2003 11:24:51 -0500 (EST) Date: Thu, 20 Feb 2003 11:24:52 -0500 From: Jenny Williams To: Russell Cattelan cc: Bernhard Erdmann , linux-xfs@oss.sgi.com Subject: Re: Corrupted file on iso installer image of XFS 1.2 Message-ID: <12488998.1045740292@jennyw> In-Reply-To: <1045687031.1716.99.camel@lupo.thebarn.com> References: <1045687031.1716.99.camel@lupo.thebarn.com> X-Mailer: Mulberry/3.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 2814 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: jenny_williams@unc.edu Precedence: bulk X-list: linux-xfs Content-Length: 2715 Lines: 66 I've tried the following: Upgrade 7.3/xfs 1.1 to 8.0/xfs 1.2 with the v.2 ISO image. Except for the question of whether I was building a new system or upgraded I chose all the default settings. This scenario worked just fine with only one exception - lilo did not run as part of the installation so the machine rebooted however it was using the prior 7.3/xfs 1.1 kernel and none of the modules loaded. Easy enough to fix, however something that might be frustrating. I have one cosmetic note - the installer I know on the v.1 disk, not sure about the v.2 disk - prompts for Disk 6 - I was tired and grumpy by this point so it took some time for it to sink in that this means the SGI XFS 1.2 for RH disk. Thanks so much for putting the effort into this. LOVE xfs. --On Wednesday, February 19, 2003 2:37 PM -0600 Russell Cattelan wrote: > Ok the installer iso has been respun the iso the athlon kernels. > The acl-devel and attr-devel packages have also been updated > to libacl-devel and libattr-devel. > I have not tested this iso but hopefully nothing in the > build process has gone a muck so it should work no worse than > the old one. > > The Makefile that I use to do all the setup and building of the various > pieces has been included on the iso. > rebuildme/Makefile > No howto at this time but is anybody is feeling really brave they > can give play with it. > > On Tue, 2003-02-18 at 19:27, Eric Sandeen wrote: >> On Tue, 18 Feb 2003, Bernhard Erdmann wrote: >> >> > Is it that complicated? Do you have a Howto or a script how to "roll >> > your own installer"? >> >> It's not that hard, once you've taken the time to figure things out. >> >> There were two bits of it, Anaconda modifications to support xfs, >> and creating the right build environment for the installer. You can look >> at the patch in the Anaconda SRPM to see what we did to the installer >> itself (actually lots of xfs support is there already from Red Hat, >> thanks to Martin!). To see how we set up the build environment, it would >> probably be best to post a Makefile that Russell wrote to do most of the >> hard stuff. >> >> We essentially have every RPM from 8.0 + our RPMs in a tree, and symlink >> them around. One set of symlinks is for all the RPMs needed to build >> the anaconda environment, the other set of symlinks "teaches" the >> installer which RPMs are on which CD. Scripts that come with Anaconda >> do the rest (build the hdlist and build the installer). >> >> I'll talk to Russell about publishing the Makefile - I think we'd both >> be ecstatic if someone else wanted to pick up this work. :) >> >> -Eric > -- > Russell Cattelan Jenny From owner-linux-xfs@oss.sgi.com Thu Feb 20 08:24:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Feb 2003 08:24:42 -0800 (PST) Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1KGOT3v011063 for ; Thu, 20 Feb 2003 08:24:31 -0800 Received: from [10.0.0.10] (c-24-245-56-70.mn.client2.attbi.com [24.245.56.70]) by lips.thebarn.com (8.12.6/8.12.6) with ESMTP id h1KGXDcX043352; Thu, 20 Feb 2003 10:33:13 -0600 (CST) (envelope-from cattelan@thebarn.com) Subject: Re: CXFS Clustering on linux From: Russell Cattelan To: Eduardo Cc: linux-xfs@oss.sgi.com In-Reply-To: <200302201719.35854.htb@cideweb.com> References: <200302201719.35854.htb@cideweb.com> Content-Type: text/plain Organization: Message-Id: <1045758792.1716.118.camel@lupo.thebarn.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 20 Feb 2003 10:33:13 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 2815 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: 305 Lines: 14 On Thu, 2003-02-20 at 10:19, Eduardo wrote: > Hi > is CXFS available for linux? close but not yet. > where? >From SGI when it's ready. > is it free? Sorry no... SGI has to make money somewhere us simple programs do like to keep eating after all. > Regards -- Russell Cattelan From owner-linux-xfs@oss.sgi.com Thu Feb 20 08:30:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Feb 2003 08:30:56 -0800 (PST) Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1KGUk3v011547 for ; Thu, 20 Feb 2003 08:30:47 -0800 Received: from [10.0.0.10] (c-24-245-56-70.mn.client2.attbi.com [24.245.56.70]) by lips.thebarn.com (8.12.6/8.12.6) with ESMTP id h1KGdVcX043489; Thu, 20 Feb 2003 10:39:31 -0600 (CST) (envelope-from cattelan@thebarn.com) Subject: Re: HD broken? (mkfs.xfs) From: Russell Cattelan To: Rainer Traut Cc: linux-xfs@oss.sgi.com In-Reply-To: <3E54F749.4050209@epost.de> References: <3E54F749.4050209@epost.de> Content-Type: text/plain Organization: Message-Id: <1045759170.1716.126.camel@lupo.thebarn.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 20 Feb 2003 10:39:31 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 2816 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: 2974 Lines: 64 This this might tell me a piece a debugging code slipped out. Your mkfs should have worked just fine.... just rather chatty. I'll be putting out new cmd rpms shortly as the build somehow got /usr/local defined as the prefix. On Thu, 2003-02-20 at 09:42, Rainer Traut wrote: > Hi, > when making a new xfs fs > I get this output. > > [root@pc0797 src]# mkfs.xfs /dev/sdb1 -f > RET 0 writing 69632bytes at blkno=0(0), 0x8086c90 > RET 0 writing 512bytes at blkno=0(0), 0x8086c90 > meta-data=/dev/sdb1 isize=256 agcount=9, agsize=262144 blks > data = bsize=4096 blocks=2220978, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=0 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=1200, version=1 > = sunit=0 blks > realtime =none extsz=65536 blocks=0, rtextents=0 > RET 9097061376 writing 65536bytes at blkno=9097061376(17767698), 0x8086c90 > RET 4294983680 writing 512bytes at blkno=4294983680(8388640), 0x8086c90 > RET 4294984192 writing 512bytes at blkno=4294984192(8388641), 0x8086c90 > RET 0 writing 512bytes at blkno=0(0), 0x8086db8 > RET 512 writing 512bytes at blkno=512(1), 0x8086db8 > RET 1024 writing 512bytes at blkno=1024(2), 0x8086db8 > RET 4096 writing 4096bytes at blkno=4096(8), 0x8086db8 > RET 8192 writing 4096bytes at blkno=8192(16), 0x8086db8 > RET 12288 writing 4096bytes at blkno=12288(24), 0x8086db8 > RET 1073741824 writing 512bytes at blkno=1073741824(2097152), 0x8086db8 > RET 1073742336 writing 512bytes at blkno=1073742336(2097153), 0x8086db8 > RET 1073742848 writing 512bytes at blkno=1073742848(2097154), 0x8086db8 > RET 1073745920 writing 4096bytes at blkno=1073745920(2097160), 0x8086db8 > RET 1073750016 writing 4096bytes at blkno=1073750016(2097168), 0x8086db8 > RET 1073754112 writing 4096bytes at blkno=1073754112(2097176), 0x8086db8 > RET 2147483648 writing 512bytes at blkno=2147483648(4194304), 0x8086db8 > RET 2147484160 writing 512bytes at blkno=2147484160(4194305), 0x8086db8 > RET 2147484672 writing 512bytes at blkno=2147484672(4194306), 0x8086db8 > RET 2147487744 writing 4096bytes at blkno=2147487744(4194312), 0x8086db8 > RET 2147491840 writing 4096bytes at blkno=2147491840(4194320), 0x8086db8 > RET 2147495936 writing 4096bytes at blkno=2147495936(4194328), 0x8086db8 > RET 3221225472 writing 512bytes at blkno=3221225472(6291456), 0x8086db8 > RET 3221225984 writing 512bytes at blkno=3221225984(6291457), 0x8086db8 > ... > > [root@pc0797 src]# uname -a > Linux pc0797.bgs-ing.de 2.4.18-24SGI_XFS_1.2 #1 Tue Feb 18 12:47:10 CET > 2003 i686 unknown > [root@pc0797 src]# rpm -qa|grep xfs > XFree86-xfs-4.2.0-8 > xfsprogs-2.3.5-0 > [root@pc0797 src]# cat /etc/redhat-release > Red Hat Linux release 7.3 (Valhalla) > [root@pc0797 src]# > > Might this tell me my hd is broken? > > Thank you > Rainer -- Russell Cattelan From owner-linux-xfs@oss.sgi.com Thu Feb 20 08:37:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Feb 2003 08:37:22 -0800 (PST) Received: from azrael.blades.cxm (ua8d10hel.dial.kolumbus.fi [62.248.137.8]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1KGaq3v012041 for ; Thu, 20 Feb 2003 08:37:02 -0800 Received: (from blades@localhost) by azrael.blades.cxm (SGI-8.9.3/8.9.3) id SAA14376; Thu, 20 Feb 2003 18:44:05 +0200 (EET) X-Authentication-Warning: azrael.blades.cxm: blades set sender to harri.haataja@kolumbus.fi using -f Date: Thu, 20 Feb 2003 18:44:04 +0200 From: Harri Haataja To: Russell Cattelan Cc: Eduardo , linux-xfs@oss.sgi.com Subject: Re: CXFS Clustering on linux Message-ID: <20030220184404.A114479@azrael.blades.cxm> Mail-Followup-To: Russell Cattelan , Eduardo , linux-xfs@oss.sgi.com References: <200302201719.35854.htb@cideweb.com> <1045758792.1716.118.camel@lupo.thebarn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1045758792.1716.118.camel@lupo.thebarn.com>; from cattelan@thebarn.com on Thu, Feb 20, 2003 at 10:33:13AM -0600 X-archive-position: 2817 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: harri.haataja@kolumbus.fi Precedence: bulk X-list: linux-xfs Content-Length: 487 Lines: 22 On Thu, Feb 20, 2003 at 10:33:13AM -0600, Russell Cattelan wrote: > On Thu, 2003-02-20 at 10:19, Eduardo wrote: > > is CXFS available for linux? > close but not yet. Oh, nice. > > where? > From SGI when it's ready. > > is it free? > Sorry no... SGI has to make money somewhere > us simple programs do like to keep eating after all. ^^^^^^^^ They have A.I.! Run! -- All programs evolve until they can send email. -- Richard Letts Except Microsoft Exchange. -- Art From owner-linux-xfs@oss.sgi.com Thu Feb 20 10:26:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Feb 2003 10:26:52 -0800 (PST) Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1KIQf3v013589 for ; Thu, 20 Feb 2003 10:26:41 -0800 Received: from [10.0.0.10] (c-24-245-56-70.mn.client2.attbi.com [24.245.56.70]) by lips.thebarn.com (8.12.6/8.12.6) with ESMTP id h1KIZScX045695 for ; Thu, 20 Feb 2003 12:35:28 -0600 (CST) (envelope-from cattelan@thebarn.com) Subject: 1.2 rebuilt cmds and another installer iso. From: Russell Cattelan To: linux-xfs@oss.sgi.com Content-Type: text/plain Organization: Message-Id: <1045766128.1716.155.camel@lupo.thebarn.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 20 Feb 2003 12:35:28 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 2818 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: 601 Lines: 17 Somehow the prefix /usr/local got set when building the cmds for the 1.2 release. New freshly build cmds from a freshly checkout tree are now on oss. The build number has been bumped so they should install over the the older rpms. The installer iso has been rebuilt yet again since the bad prefix caused the xfs cmds to not be included in the stage2 image. (which makes it rather hard to make an XFS file system) da0b2054ef0439d70322fdc856ec6a81 forRH-8.0-SGI-XFS-1.2.0-v3.iso Again I have not tested this iso so please report back success/failures. -- Russell Cattelan From owner-linux-xfs@oss.sgi.com Thu Feb 20 12:08:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Feb 2003 12:08:56 -0800 (PST) Received: from web12301.mail.yahoo.com (web12301.mail.yahoo.com [216.136.173.99]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1KK8k3v017469 for ; Thu, 20 Feb 2003 12:08:47 -0800 Message-ID: <20030220201734.34712.qmail@web12301.mail.yahoo.com> Received: from [192.41.88.6] by web12301.mail.yahoo.com via HTTP; Thu, 20 Feb 2003 12:17:34 PST Date: Thu, 20 Feb 2003 12:17:34 -0800 (PST) From: Jason Corbett Subject: Re: 1.2 rebuilt cmds and another installer iso. To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 2819 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: jasoncorbett01@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 566 Lines: 17 Sorry about this, but this one didn't install either. It freezes when loading the xfs cd back in (after cd1) and virtual terminal 3 says that it is getting an IOError it can't find libattr-2.0.12-0.i386.rpm. I am still trying to reproduce the build environment, but still don't understand which targets to run in which order, I don't quite understand what all the Variables mean, I'm working on it though. Jason Corbett __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ From owner-linux-xfs@oss.sgi.com Thu Feb 20 12:53:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Feb 2003 12:53:10 -0800 (PST) Received: from ente.berdmann.de (frnk-d514e1ad.dsl.mediaWays.net [213.20.225.173]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1KKr53v019248 for ; Thu, 20 Feb 2003 12:53:06 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.35 #1) id 18lxpB-0007oB-00; Thu, 20 Feb 2003 22:01:45 +0100 Message-ID: <3E554238.5090908@berdmann.de> Date: Thu, 20 Feb 2003 22:01:44 +0100 From: Bernhard Erdmann User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Russell Cattelan CC: linux-xfs@oss.sgi.com Subject: Re: 1.2 rebuilt cmds and another installer iso. References: <1045766128.1716.155.camel@lupo.thebarn.com> In-Reply-To: <1045766128.1716.155.camel@lupo.thebarn.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2820 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: be@berdmann.de Precedence: bulk X-list: linux-xfs Content-Length: 259 Lines: 9 Russell Cattelan wrote: [...] > The installer iso has been rebuilt yet again since the bad prefix caused > the xfs cmds to not be included in the stage2 image. (which makes it > rather hard to make an XFS file system) [...] Thanks for your ongoing efforts! From owner-linux-xfs@oss.sgi.com Thu Feb 20 13:08:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Feb 2003 13:08:30 -0800 (PST) Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1KL8N3v019947 for ; Thu, 20 Feb 2003 13:08:24 -0800 Received: from [10.0.0.10] (c-24-245-56-70.mn.client2.attbi.com [24.245.56.70]) by lips.thebarn.com (8.12.6/8.12.6) with ESMTP id h1KLH9cX048825; Thu, 20 Feb 2003 15:17:09 -0600 (CST) (envelope-from cattelan@thebarn.com) Subject: Re: 1.2 rebuilt cmds and another installer iso. From: Russell Cattelan To: Jason Corbett Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030220201734.34712.qmail@web12301.mail.yahoo.com> References: <20030220201734.34712.qmail@web12301.mail.yahoo.com> Content-Type: text/plain Organization: Message-Id: <1045775826.1716.162.camel@lupo.thebarn.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 20 Feb 2003 15:17:06 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 2821 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: 886 Lines: 26 On Thu, 2003-02-20 at 14:17, Jason Corbett wrote: > Sorry about this, but this one didn't install either. > It freezes when loading the xfs cd back in (after cd1) > and virtual terminal 3 says that it is getting an > IOError it can't find libattr-2.0.12-0.i386.rpm. ohh crap I forgot to update the hdlist file. The version number on the cmd's changed... > > I am still trying to reproduce the build environment, > but still don't understand which targets to run in > which order, I don't quite understand what all the > Variables mean, I'm working on it though. Ya sorry is that intuitive. Franky RH installer build process is a bit clumsy, and is very error prone. > > Jason Corbett > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, more > http://taxes.yahoo.com/ -- Russell Cattelan From owner-linux-xfs@oss.sgi.com Thu Feb 20 13:28:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Feb 2003 13:28:11 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1KLS73v021667 for ; Thu, 20 Feb 2003 13:28:07 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h1KLanKp020473 for ; Thu, 20 Feb 2003 13:36:50 -0800 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 IAA05463; Fri, 21 Feb 2003 08:35:30 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id IAA75058; Fri, 21 Feb 2003 08:35:29 +1100 (AEDT) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) with ESMTP id h1KLXSEh000939; Fri, 21 Feb 2003 08:33:28 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h1KLXS6Y000937; Fri, 21 Feb 2003 08:33:28 +1100 Date: Fri, 21 Feb 2003 08:33:27 +1100 From: Nathan Scott To: Andi Kleen Cc: linux-xfs@oss.sgi.com, agruen@suse.de Subject: Re: TAKE - acl_init Message-ID: <20030220213327.GA804@frodo> References: <200302182335.h1INZ7la8907219@snort.melbourne.sgi.com> <20030220075926.GA21973@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030220075926.GA21973@wotan.suse.de> User-Agent: Mutt/1.5.3i X-archive-position: 2822 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: 995 Lines: 30 hi Andi, On Thu, Feb 20, 2003 at 08:59:26AM +0100, Andi Kleen wrote: > On Wed, Feb 19, 2003 at 10:35:07AM +1100, Nathan Scott wrote: > > Fix a zero-length malloc in acl_init - causing QA failures > > when libacl is linked with the electric fence library. > > Still using ElectricFence and not valgrind for testing ? @) > > valgrind will find much more bugs. Hmmm... just tried running valgrind on xfs_repair and looks like its going to take a bit of work to get valgrind to work on any of our tools - we use ustat in libxfs for example, & valgrind barfs on that as an unrecognised syscall. The acl and attr tools make extensive use of all the xattr syscalls, which are still relatively new, so those are likely to have similar problems I guess. I don't have time to hack on valgrind right now - maybe some community-minded person out there wants to give this a go? There's detailed instructions in the valgrind source on how to modify the code to fix these issues... cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Feb 20 13:39:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Feb 2003 13:39:32 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1KLdT3v022226 for ; Thu, 20 Feb 2003 13:39:30 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 3E18B186B132; Thu, 20 Feb 2003 13:48:18 -0800 (PST) Date: Thu, 20 Feb 2003 13:48:18 -0800 From: Chris Wedgwood To: Nathan Scott Cc: Andi Kleen , linux-xfs@oss.sgi.com, agruen@suse.de Subject: Re: TAKE - acl_init Message-ID: <20030220214818.GB28461@f00f.org> References: <200302182335.h1INZ7la8907219@snort.melbourne.sgi.com> <20030220075926.GA21973@wotan.suse.de> <20030220213327.GA804@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030220213327.GA804@frodo> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2823 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: 332 Lines: 12 On Fri, Feb 21, 2003 at 08:33:27AM +1100, Nathan Scott wrote: > Hmmm... just tried running valgrind on xfs_repair and looks like its > going to take a bit of work to get valgrind to work on any of our > tools - we use ustat in libxfs for example, & valgrind barfs on that > as an unrecognised syscall. Does purify work? --cw From owner-linux-xfs@oss.sgi.com Thu Feb 20 14:15:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Feb 2003 14:15:25 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1KMFH3v024749 for ; Thu, 20 Feb 2003 14:15:18 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1KMO0G8031122 for ; Thu, 20 Feb 2003 14:24:01 -0800 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 h1KMMhNt9389811 for ; Fri, 21 Feb 2003 09:22:43 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h1KMMgZE9371706 for linux-xfs@oss.sgi.com; Fri, 21 Feb 2003 09:22:42 +1100 (EST) Date: Fri, 21 Feb 2003 09:22:42 +1100 (EST) From: Nathan Scott Message-Id: <200302202222.h1KMMgZE9371706@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - pagebuf X-archive-position: 2824 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@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 421 Lines: 16 Remove some off_t abuse in pagebuf_offset and the page_io routine, after some careful analysis. Date: Thu Feb 20 14:21:58 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:140039a linux/fs/xfs/xfs_buf.h - 1.103 linux/fs/xfs/pagebuf/page_buf.c - 1.97 linux/fs/xfs/pagebuf/page_buf.h - 1.57 From owner-linux-xfs@oss.sgi.com Thu Feb 20 15:55:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Feb 2003 15:55:40 -0800 (PST) Received: from hell.org.pl (qmailr@hell.org.pl [212.244.218.42]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1KNtV3v026749 for ; Thu, 20 Feb 2003 15:55:32 -0800 Received: (qmail 23265 invoked by uid 777); 21 Feb 2003 00:04:26 -0000 Date: Fri, 21 Feb 2003 01:04:26 +0100 From: Karol Kozimor To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: buffer layer error (was: XFS and ACPI sleep states compat in 2.5) Message-ID: <20030221000426.GA13165@hell.org.pl> Mail-Followup-To: Eric Sandeen , linux-xfs@oss.sgi.com References: <20030219100207.GA15374@hell.org.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-archive-position: 2825 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sziwan@hell.org.pl Precedence: bulk X-list: linux-xfs Content-Length: 975 Lines: 23 Hi, As promised, I post the details of that strange error I experience during shutdown. However, since I am now extremely tired, and apart from that, extremely lazy, I had only enough energy to make some photos of the call trace, which I placed here: http://hell.org.pl/~sziwan/calltrace1.jpg and calltrace2.jpg. Please excuse me for that, if you find it uncomfortable, I will type it in after a couple of hours sleep. :/ Anyway, what I do is start a 2.5.61 kernel (with ACPI compiled in and that little fix you wrote), then immediately trigger shutdown -r now by pressing ctrl+alt+del just when the gettys appear. No ACPI-specific operations are performed. The shutdown scripts go just as far as here: if [ -d /var/lock/subsys ]; then rm -f /var/lock/subsys/* fi and then the kernel dumps the call trace (before the next command). The system reboots after that and so far no integrity loss has been observed. Best regards, -- Karol 'sziwan' Kozimor sziwan@hell.org.pl From owner-linux-xfs@oss.sgi.com Thu Feb 20 16:09:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Feb 2003 16:09:32 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1L09O3v027285 for ; Thu, 20 Feb 2003 16:09:25 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1L0I8Kp018501 for ; Thu, 20 Feb 2003 16:18:08 -0800 Received: from Liberator (sshgate.corp.sgi.com [169.238.216.146]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id QAA11950; Thu, 20 Feb 2003 16:17:33 -0800 (PST) Subject: Re: Corrupted file on iso installer image of XFS 1.2 From: Eric Sandeen To: Jenny Williams Cc: Russell Cattelan , Bernhard Erdmann , linux-xfs@oss.sgi.com In-Reply-To: <12488998.1045740292@jennyw> References: <1045687031.1716.99.camel@lupo.thebarn.com> <12488998.1045740292@jennyw> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 20 Feb 2003 18:17:40 -0600 Message-Id: <1045786663.10725.1.camel@Liberator> Mime-Version: 1.0 X-archive-position: 2826 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 767 Lines: 19 On Thu, 2003-02-20 at 10:24, Jenny Williams wrote: > lilo did not run as part of the installation so the machine rebooted > however it was using the prior 7.3/xfs 1.1 kernel and none of the modules > loaded. Easy enough to fix, however something that might be frustrating. Not sure what to say about that one... > I have one cosmetic note - the installer I know on the v.1 disk, not sure > about the v.2 disk - prompts for Disk 6 - I was tired and grumpy by this > point so it took some time for it to sink in that this means the SGI XFS > 1.2 for R