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 RH disk. Yep, the old installer had code to say "the xfs disc" but I guess this was the quick-n-dirty spin, and it asks for "disc 6" (which really is what it is... just hard for you to know that) :) -Eric From owner-linux-xfs@oss.sgi.com Thu Feb 20 18:21:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Feb 2003 18:21:28 -0800 (PST) Received: from universe.chowhouse.com (IDENT:0@stumpy.chowhouse.com [209.180.91.165] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1L2LK3v001051 for ; Thu, 20 Feb 2003 18:21:22 -0800 Received: from universe.chowhouse.com (IDENT:1000@localhost [127.0.0.1]) by universe.chowhouse.com (8.12.6/8.12.6) with ESMTP id h1L2WuIQ008015 for ; Thu, 20 Feb 2003 19:32:56 -0700 Received: from localhost (james@localhost) by universe.chowhouse.com (8.12.6/8.12.6/Submit) with ESMTP id h1L2Wu05008012 for ; Thu, 20 Feb 2003 19:32:56 -0700 Date: Thu, 20 Feb 2003 19:32:56 -0700 (MST) From: James Rich To: XFS mailing list Subject: problem creating log Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2827 X-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@chowhouse.com Precedence: bulk X-list: linux-xfs Content-Length: 432 Lines: 15 When I create a log like this: mkfs.xfs -l logdev=/dev/sdb6,size=10000b /dev/sda2 I get an error that says the size 10000b specified for log subvolume is too large, maximum is 7 blocks. If I leave off the size=10000b then I get an error saying that 7 blocks is too small, minimum is 512. I get this error whether I use an external log or internal log. mkfs.xfs -V shows: mkfs.xfs version 2.0.3 what should I do? James Rich From owner-linux-xfs@oss.sgi.com Thu Feb 20 18:32:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Feb 2003 18:32: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 h1L2W13v001530 for ; Thu, 20 Feb 2003 18:32:02 -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 h1L2ekKp005867 for ; Thu, 20 Feb 2003 18:40:46 -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 SAA23057; Thu, 20 Feb 2003 18:40:14 -0800 (PST) Subject: Re: problem creating log From: Eric Sandeen To: James Rich Cc: XFS mailing list In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 20 Feb 2003 20:40:21 -0600 Message-Id: <1045795223.1235.1.camel@Liberator> Mime-Version: 1.0 X-archive-position: 2828 X-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: 243 Lines: 10 On Thu, 2003-02-20 at 20:32, James Rich wrote: > what should I do? Please try a newer xfsprogs version, for starters - 2.0.3 is pretty old by now. 2.3.9 is on the ftp site now, or grab a slightly older version from the 1.2 release. -Eric From owner-linux-xfs@oss.sgi.com Thu Feb 20 18:39:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Feb 2003 18:39:19 -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 h1L2dG3v002025 for ; Thu, 20 Feb 2003 18:39:16 -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 h1L2lxG8007110 for ; Thu, 20 Feb 2003 18:47:59 -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 NAA07922; Fri, 21 Feb 2003 13:46: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 NAA82613; Fri, 21 Feb 2003 13:46:32 +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 h1L2iUEh001799; Fri, 21 Feb 2003 13:44:30 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h1L2iLMC001797; Fri, 21 Feb 2003 13:44:21 +1100 Date: Fri, 21 Feb 2003 13:44:21 +1100 From: Nathan Scott To: James Rich Cc: linux-xfs@oss.sgi.com Subject: Re: problem creating log Message-ID: <20030221024421.GD804@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: 2829 X-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: 763 Lines: 23 On Thu, Feb 20, 2003 at 07:32:56PM -0700, James Rich wrote: > When I create a log like this: > > mkfs.xfs -l logdev=/dev/sdb6,size=10000b /dev/sda2 > I get an error that says the size 10000b specified for log subvolume is > too large, maximum is 7 blocks. If I leave off the size=10000b then I get > an error saying that 7 blocks is too small, minimum is 512. I get this > error whether I use an external log or internal log. mkfs.xfs -V shows: > > mkfs.xfs version 2.0.3 > What does /proc/partitions say for these devices? Possibly your device driver is incorrectly handling the BLKGETSIZE64 ioctl... put a printf in the libxfs code which calls this ioctl to see the returned size and see if that matches your perception of reality. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Feb 20 18:57:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Feb 2003 18:57:48 -0800 (PST) Received: from universe.chowhouse.com (IDENT:0@stumpy.chowhouse.com [209.180.91.165] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1L2vf3v002651 for ; Thu, 20 Feb 2003 18:57:42 -0800 Received: from universe.chowhouse.com (IDENT:1000@localhost [127.0.0.1]) by universe.chowhouse.com (8.12.6/8.12.6) with ESMTP id h1L39JIQ001110 for ; Thu, 20 Feb 2003 20:09:19 -0700 Received: from localhost (james@localhost) by universe.chowhouse.com (8.12.6/8.12.6/Submit) with ESMTP id h1L39JMJ001107 for ; Thu, 20 Feb 2003 20:09:19 -0700 Date: Thu, 20 Feb 2003 20:09:19 -0700 (MST) From: James Rich To: XFS mailing list Subject: Re: problem creating log In-Reply-To: <1045795223.1235.1.camel@Liberator> Message-ID: References: <1045795223.1235.1.camel@Liberator> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2830 X-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@chowhouse.com Precedence: bulk X-list: linux-xfs Content-Length: 389 Lines: 12 On Thu, 20 Feb 2003, Eric Sandeen wrote: > Please try a newer xfsprogs version, for starters - 2.0.3 is pretty old > by now. 2.3.9 is on the ftp site now, or grab a slightly older version > from the 1.2 release. I'm trying that now - but this is on a bootdisk and I need a statically linked version. Is there a flag I can set in the Makefile to build mkfs.xfs statically? James Rich From owner-linux-xfs@oss.sgi.com Thu Feb 20 19:39:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Feb 2003 19:39: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 h1L3dn3v008464 for ; Thu, 20 Feb 2003 19:39:49 -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 h1L3mSKp015888 for ; Thu, 20 Feb 2003 19:48:31 -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 OAA08478; Fri, 21 Feb 2003 14:47:11 +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 OAA82606; Fri, 21 Feb 2003 14:47:10 +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 h1L3j8Eh001983; Fri, 21 Feb 2003 14:45:08 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h1L3ix60001981; Fri, 21 Feb 2003 14:44:59 +1100 Date: Fri, 21 Feb 2003 14:44:59 +1100 From: Nathan Scott To: James Rich Cc: XFS mailing list Subject: Re: problem creating log Message-ID: <20030221034459.GF804@frodo> References: <1045795223.1235.1.camel@Liberator> 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: 2831 X-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: 695 Lines: 22 On Thu, Feb 20, 2003 at 08:09:19PM -0700, James Rich wrote: > On Thu, 20 Feb 2003, Eric Sandeen wrote: > > > Please try a newer xfsprogs version, for starters - 2.0.3 is pretty old > > by now. 2.3.9 is on the ftp site now, or grab a slightly older version > > from the 1.2 release. > > I'm trying that now - but this is on a bootdisk and I need a statically > linked version. Is there a flag I can set in the Makefile to build > mkfs.xfs statically? > I'm sure there's a macro we could use hidden away in the depths of libtool; but simplest way is to just do a mkfs build, unlink mkfs.xfs, append -static to its link line, then type make again in the mkfs directory. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Feb 20 19:50:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Feb 2003 19:50: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 h1L3oW3v010606 for ; Thu, 20 Feb 2003 19:50:33 -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 h1L3xHKp017826 for ; Thu, 20 Feb 2003 19:59:17 -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 TAA25522; Thu, 20 Feb 2003 19:58:45 -0800 (PST) Subject: Re: 1.2 rebuilt cmds and another installer iso. From: Eric Sandeen 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 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 20 Feb 2003 21:58:52 -0600 Message-Id: <1045799934.1235.69.camel@Liberator> Mime-Version: 1.0 X-archive-position: 2832 X-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: 1902 Lines: 65 Jason - here's a tree of the build environment, w/ some comments might possibly help... I'm realizing that a full writeup is a non-trivial task. :) . |-- anaconda -> anaconda-8.0 |-- anaconda-8.0 (stock RH anaconda, to diff against) | |-- balkan | |-- bootdisk |-- anaconda-8.0-xfs (xfs-modified anaconda) | |-- balkan | |-- bootdisk |-- anaconda-images-8.0 (images package - not certain this is used) | `-- rnotes | |-- de | |-- es | |-- fr | |-- it | `-- ja |-- anaconda-xfs -> anaconda-8.0-xfs |-- bootGen (used to build the actual installer - some is copied | |-- RedHat from the stock installer, I think - dosutils etc) | | |-- RPMS (here are symlinks to -all- rpms, the installer needs a subset) | | `-- base (need an updated comps.xml here, hdlist is built here) | |-- dosutils | | `-- autoboot | |-- images | | `-- pxeboot | `-- isolinux |-- genhdlist (used to make the hdlist - below are actual RPMS | |-- disc1 from the RH cds and the sgi-specific RPMS, with | | `-- RedHat any replaced RPMS (kernel for example) removed | | `-- RPMS from the RH dirs) | |-- disc2 | | `-- RedHat | | `-- RPMS | |-- disc3 | | `-- RedHat | | `-- RPMS | |-- disc4 | | `-- RedHat | | `-- RPMS | |-- disc5 | | `-- RedHat | | `-- RPMS | `-- sgi_disc | `-- RedHat | `-- RPMS (xfs-specific RPMS) |-- pixmaps | `-- sginotes |-- rnotes |-- sgiInstall (top of the tree that goes on the iso image) | |-- RedHat | | |-- RPMS -> ../../genhdlist/sgi_disc/RedHat/RPMS | | `-- base -> ../../bootGen/RedHat/base | |-- SRPMS -> ../sgiSRPMS/SRPMS | |-- dosutils -> ../bootGen/dosutils | |-- images -> ../bootGen/images | |-- isolinux -> ../bootGen/isolinux | `-- rebuildme `-- sgiSRPMS (SRPMS for sgi-specific RPMS) `-- SRPMS From owner-linux-xfs@oss.sgi.com Thu Feb 20 19:55:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Feb 2003 19:56:01 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1L3ts3v015251 for ; Thu, 20 Feb 2003 19:55:54 -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 h1L4ELkq029712 for ; Thu, 20 Feb 2003 22:14:22 -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 h1L43IBi015408 for ; Fri, 21 Feb 2003 15:03:18 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h1L43ITq015407 for linux-xfs@oss.sgi.com; Fri, 21 Feb 2003 15:03:18 +1100 (EST) Date: Fri, 21 Feb 2003 15:03:18 +1100 (EST) From: Nathan Scott Message-Id: <200302210403.h1L43ITq015407@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - pagebuf X-archive-position: 2833 X-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: 689 Lines: 18 Rework how IO completion is handled in pagebuf, particularly the case of blocksizes less than the pagesize. This makes more of an effort to set pages uptodate in this case, and removes the page_sync_t structure from the code entirely (previously we were allocating one of these per-page for small IOs). Some of the functions no longer need to return errors now, and some were doing bytes-written accounting unnecessarily - no more. Date: Thu Feb 20 20:02:00 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:140047a linux/fs/xfs/pagebuf/page_buf.c - 1.98 From owner-linux-xfs@oss.sgi.com Thu Feb 20 21:05:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Feb 2003 21:05:32 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1L55M3v018312 for ; Thu, 20 Feb 2003 21:05: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 h1L5Nokq001914 for ; Thu, 20 Feb 2003 23:23:52 -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 h1L5CmBi054639 for ; Fri, 21 Feb 2003 16:12:48 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h1L5CliW054596 for linux-xfs@oss.sgi.com; Fri, 21 Feb 2003 16:12:47 +1100 (EST) Date: Fri, 21 Feb 2003 16:12:47 +1100 (EST) From: Nathan Scott Message-Id: <200302210512.h1L5CliW054596@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - pagebuf X-archive-position: 2834 X-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: 567 Lines: 17 Revert the recent hashing change, performance seemed to go way down in certain benchmarks. This is reverted to how it was, except the number of hash buckets is larger than previously to attempt to account for the workload Steve was originally targetting with that change. Date: Thu Feb 20 21:12:00 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:140053a linux/fs/xfs/pagebuf/page_buf.c - 1.99 linux/fs/xfs/pagebuf/page_buf.h - 1.58 From owner-linux-xfs@oss.sgi.com Thu Feb 20 23:14:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Feb 2003 23:14:53 -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 h1L7Ei3v031042 for ; Thu, 20 Feb 2003 23:14:46 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 00ECB144D3; Fri, 21 Feb 2003 08:23:29 +0100 (MET) Date: Fri, 21 Feb 2003 08:23:26 +0100 From: Andi Kleen To: Chris Wedgwood Cc: Nathan Scott , Andi Kleen , linux-xfs@oss.sgi.com, agruen@suse.de Subject: Re: TAKE - acl_init Message-ID: <20030221072326.GC25144@wotan.suse.de> References: <200302182335.h1INZ7la8907219@snort.melbourne.sgi.com> <20030220075926.GA21973@wotan.suse.de> <20030220213327.GA804@frodo> <20030220214818.GB28461@f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030220214818.GB28461@f00f.org> X-archive-position: 2835 X-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: 488 Lines: 14 On Thu, Feb 20, 2003 at 01:48:18PM -0800, Chris Wedgwood wrote: > 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? When valgrind does not know the syscalls Purify very likely doesn't neither. -Andi From owner-linux-xfs@oss.sgi.com Thu Feb 20 23:45:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Feb 2003 23:45:47 -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 h1L7jg3v031720 for ; Thu, 20 Feb 2003 23:45:43 -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 h1L7sPPX036625; Fri, 21 Feb 2003 08:54:26 +0100 (CET) Message-Id: <4.3.2.7.2.20030221084703.03577f70@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Feb 2003 08:54:22 +0100 To: linux-xfs@oss.sgi.com From: Seth Mos Subject: Problem using appletalk with MacOS X to a scsi hd with XFS. Cc: scottl@promise.com.tw Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2836 X-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: 1612 Lines: 49 Hello, I have someone from promise who is having problems accessing files over Appletalk using MacOS X to a scsi disk. If anyone else out there is using this combination I would appreciate the help. I have access to the hardware but not the time to spare at the moment for setting up appletalk attaching scsi disks to my testbox etc. From: "Scott Liu" To: Subject: Mac X access to XFS filesystem on SCSI device problem? Date: Thu, 23 Jan 2003 11:31:22 +0800 Message-ID: <001001c2c28f$e7932fd0$a6cca8c0@Scott> MIME-Version: 1.0 Content-Type: text/plain; charset="big5" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by maildrop7.xs4all.nl id h0N3V4e45796 X-UIDL: 1043292665.maildrop7.45805 Dear, I create a partition with XFS on SCSI device, and copy a lot of files (about 500M bytes) from Mac X to this partition, sometimes it will fail with error message "-50". I test this with xfs 1.01, xfs 1.1 and xfs 1.2 pre-release#5, the problem also happen. But when the partition is ext2 on scsi device, XFS on IDE device or ext2 on IDE device, they are OK. It happens with XFS on SCSI device access from Mac X. Netatalk version is : netatalk-1.4b2+asun2.1.3 Mac version is : Mac X 10.1.4 Japanese version May you let me know how to solve this problem? Thanks. Best Regards, Scott Liu -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Fri Feb 21 01:42:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Feb 2003 01:42:33 -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 h1L9gP3v000784 for ; Fri, 21 Feb 2003 01:42:25 -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 h1L8knoT001310; Fri, 21 Feb 2003 00:46:53 -0800 From: "l.a walsh" To: "'Seth Mos'" , "'l.a walsh'" , Cc: "'Chris Wedgwood'" Subject: RE: been a while before i could get back to this.. Date: Fri, 21 Feb 2003 00:46:49 -0800 Message-ID: <000201c2d985$c8727fe0$1403a8c0@sc.tlinx.org> 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.4510 In-Reply-To: <4.3.2.7.2.20030220085856.0356e3a0@pop.xs4all.nl> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-archive-position: 2837 X-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: 3073 Lines: 86 > -----Original Message----- > From: Seth Mos [mailto:knuffie@xs4all.nl] > Sent: February 20, 2003 12:28a > To: l.a walsh; linux-xfs@oss.sgi.com > Cc: 'Chris Wedgwood' > Subject: RE: been a while before i could get back to this.. > > > 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. --- I don't have CVS setup. This problem has existed in its current form since last October. It's not a recent breakage. > if /var is seperate partition you might be able to find the > filesystem > shutdown message in the /var/log/messages log. --- Not if var is mounted on "/" or the socket to write to syslog is under "/"...I setup syslog to record to another system... These are the local window messages when I tried to dump: + xfsdump -b 1048576 -m -l 0 -o -L root - / + su -f -m backup -c 'nice -19 bzip2 >root/root-030220-0-2201.dump.bz2' xfsdump: using file dump (drive_simple) strategy xfsdump: version 2.2.6 (dump format 3.0) - Running single-threaded xfsdump: level 0 dump of ishtar:/ xfsdump: dump date: Thu Feb 20 22:01:40 2003 xfsdump: session id: 1dfb2395-0d6c-4132-9ba0-0b41bc30c3c0 xfsdump: session label: "root" xfsdump: ino map phase 1: skipping (no subtrees specified) xfsdump: ino map phase 2: constructing initial dump list xfsdump: WARNING: failed to get bulkstat information for inode 1590 xfsdump: syssgi( SGI_FS_BULKSTAT ) on fsroot failed: Input/output error xfsdump: Dump Status: ERROR + read fs dev DUMP ./dumplin: line 19: read: read error: 0: Input/output error ishtar:root/bin# ls bash: /bin/ls: Input/output error ========= These are the log messages I saw in the remote syslog: Feb 21 00:12:03 ishtar kernel: xfs_inotobp: xfs_imap() returned an error 22 on sd(8,3). Returning error. Feb 21 00:12:03 ishtar kernel: xfs_iunlink_remove: xfs_inotobp() returned an error 22 on sd(8,3). Returning error. Feb 21 00:12:03 ishtar kernel: xfs_inactive: xfs_ifree() returned an error = 22 on sd(8,3) Feb 21 00:12:03 ishtar kernel: xfs_force_shutdown(sd(8,3),0x1) called from line 1835 of file xfs_vnodeops.c. Return address = 0xc0213dca Feb 21 00:12:03 ishtar kernel: Filesystem "sd(8,3)": I/O Error Detected. Shutting down filesystem: sd(8,3) Feb 21 00:12:03 ishtar kernel: Please umount the filesystem, and rectify the problem(s) ------ I like that last line -- since 'umount' is unavailable...:-/ > 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. --- I could -- but they are all mounted under "/"....Had the output going to a file on /tmp, and another window watching that file with tail -f, nada...after reboot file has 0 len Hopefully the log above gives some cluese? From owner-linux-xfs@oss.sgi.com Fri Feb 21 02:28:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Feb 2003 02:28:44 -0800 (PST) Received: from hammail1.truenorth.com (h-213.61.138.102.host.de.colt.net [213.61.138.102]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1LASY3v002943 for ; Fri, 21 Feb 2003 02:28:35 -0800 Received: from hamburg.fcb.com ([170.200.66.61]) by hammail1.truenorth.com (Netscape Messaging Server 4.15) with ESMTP id HANN5V00.GKS for ; Fri, 21 Feb 2003 11:44:19 +0100 Date: Fri, 21 Feb 2003 11:37:19 +0100 Subject: Re: Corrupted file on iso installer image of XFS 1.2 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Harald Wagener To: linux-xfs@oss.sgi.com Content-Transfer-Encoding: 7bit In-Reply-To: <1045786663.10725.1.camel@Liberator> Message-Id: <73C2A403-4588-11D7-8601-003065DC18B8@hamburg.fcb.com> X-Mailer: Apple Mail (2.551) X-archive-position: 2838 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hwagener@hamburg.fcb.com Precedence: bulk X-list: linux-xfs Content-Length: 612 Lines: 20 Am Freitag, 21.02.03 um 01:17 Uhr schrieb Eric Sandeen: > 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... Maybe the labels are too long for lilo to handle again? ( I reported this earlier, but did not check on the 1.2 install disc yet). Regards, Harald -- Harald Wagener * FCB/Wilkens * An der Alster 42 * 20099 Hamburg From owner-linux-xfs@oss.sgi.com Fri Feb 21 02:34:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Feb 2003 02:34:10 -0800 (PST) Received: from hammail1.truenorth.com (h-213.61.138.102.host.de.colt.net [213.61.138.102]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1LAY63v003495 for ; Fri, 21 Feb 2003 02:34:07 -0800 Received: from hamburg.fcb.com ([170.200.66.61]) by hammail1.truenorth.com (Netscape Messaging Server 4.15) with ESMTP id HANNF300.OKG; Fri, 21 Feb 2003 11:49:51 +0100 Date: Fri, 21 Feb 2003 11:42:51 +0100 Subject: Re: Problem using appletalk with MacOS X to a scsi hd with XFS. Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: linux-xfs@oss.sgi.com, scottl@promise.com.tw, netatalk-admins@lists.sourceforge.net To: Seth Mos From: Harald Wagener In-Reply-To: <4.3.2.7.2.20030221084703.03577f70@pop.xs4all.nl> Message-Id: <3A1722E2-4589-11D7-8601-003065DC18B8@hamburg.fcb.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-archive-position: 2839 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hwagener@hamburg.fcb.com Precedence: bulk X-list: linux-xfs Content-Length: 1912 Lines: 54 Am Freitag, 21.02.03 um 08:54 Uhr schrieb Seth Mos: > Hello, > > I have someone from promise who is having problems accessing files > over Appletalk using MacOS X to a scsi disk. > If anyone else out there is using this combination I would appreciate > the help. > I have access to the hardware but not the time to spare at the moment > for setting up appletalk attaching scsi disks to my testbox etc. > > From: "Scott Liu" > To: > Subject: Mac X access to XFS filesystem on SCSI device problem? > [snip] > Dear, > > I create a partition with XFS on SCSI device, and copy a lot of files > (about 500M bytes) from Mac X to this partition, sometimes it will > fail with error message "-50". > I test this with xfs 1.01, xfs 1.1 and xfs 1.2 pre-release#5, the > problem also happen. > > But when the partition is ext2 on scsi device, XFS on IDE device or > ext2 on IDE device, they are OK. This is strange. '-50' normally indicates a problem with filenames. I don't known enough about multilanguage support to be able to comment on this. I succeeded by trying to copy smaller parts of a directory tree (like, the first level of subdirectories apart from each others), which helped alot (for OS 9 Clients). > It happens with XFS on SCSI device access from Mac X. > > Netatalk version is : netatalk-1.4b2+asun2.1.3 > Mac version is : Mac X 10.1.4 Japanese version > > May you let me know how to solve this problem? Thanks. netatalk-1.4b2 is ancient right now. To pipe up to the xfs motto, please try a more recent version if possible (like 1.6.0 or even 1.6.1pre2, which is to become 1.6.1 shortly). Also, Mac OS X is known to have problems with netatalk in earlier versions. Would an upgrade to the recently available 10.2.4 be possible for further testing? Regards, Harald -- Harald Wagener * FCB/Wilkens * An der Alster 42 * 20099 Hamburg From owner-linux-xfs@oss.sgi.com Fri Feb 21 04:29:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Feb 2003 04:29:36 -0800 (PST) Received: from poptart.bithose.com (ip-204-97-176-41.modem.logical.net [204.97.176.41]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1LCTU3v008051 for ; Fri, 21 Feb 2003 04:29:32 -0800 Received: from poptart.bithose.com (localhost [127.0.0.1]) by poptart.bithose.com (8.12.2/8.12.2) with ESMTP id h1LCc0US118600; Fri, 21 Feb 2003 07:38:00 -0500 (EST) Received: from localhost (jakari@localhost) by poptart.bithose.com (8.12.2/8.12.2/Submit) with ESMTP id h1LCc0uV117964; Fri, 21 Feb 2003 07:38:00 -0500 (EST) X-Authentication-Warning: poptart.bithose.com: jakari owned process doing -bs Date: Fri, 21 Feb 2003 07:38:00 -0500 (EST) From: Jameel Akari To: Harald Wagener cc: Seth Mos , , , Subject: Re: Problem using appletalk with MacOS X to a scsi hd with XFS. In-Reply-To: <3A1722E2-4589-11D7-8601-003065DC18B8@hamburg.fcb.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2840 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jakari@bithose.com Precedence: bulk X-list: linux-xfs Content-Length: 1492 Lines: 38 > Am Freitag, 21.02.03 um 08:54 Uhr schrieb Seth Mos: > > I have someone from promise who is having problems accessing files > > over Appletalk using MacOS X to a scsi disk. > > I create a partition with XFS on SCSI device, and copy a lot of files > > (about 500M bytes) from Mac X to this partition, sometimes it will > > fail with error message "-50". ... > > But when the partition is ext2 on scsi device, XFS on IDE device or > > ext2 on IDE device, they are OK. Now that's plain weird. I want to call it a red herring, but... On Fri, 21 Feb 2003, Harald Wagener wrote: > netatalk-1.4b2 is ancient right now. To pipe up to the xfs motto, > please try a more recent version if possible (like 1.6.0 or even > 1.6.1pre2, which is to become 1.6.1 shortly). Also, Mac OS X is known > to have problems with netatalk in earlier versions. Would an upgrade to > the recently available 10.2.4 be possible for further testing? Indeed. There have been a number of fixes in OS X 10.2 up to 10.2.4 for filesharing (Appletalk and otherwise) so it'd probably be a good thing to try, if possible. I only ever used 10.a.x as an Appletalk server, not a client, but I seem to recall there being a number of fixes there as well. Also, can you try connecting to the share via NFS or Samba, and seeing if that changes the outcome? Both work great for my OSX Macs connecting to an XFS fileserver. I don't use Netatalk at all anymore. -- #!/jameel/akari sleep 4800; make clean && make breakfast From owner-linux-xfs@oss.sgi.com Fri Feb 21 05:20:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Feb 2003 05:20:52 -0800 (PST) Received: from mail.belcaf.minsk.by (mail.sam-solutions.net [217.21.35.41]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1LDKa3v008874 for ; Fri, 21 Feb 2003 05:20:39 -0800 Received: from pc219.belcaf.minsk.by ([192.168.111.249]) by mail.belcaf.minsk.by (MTA 4.15) with ESMTP id HANUSW00.V66; Fri, 21 Feb 2003 15:29:20 +0200 Received: from pc219.belcaf.minsk.by (localhost.localdomain [127.0.0.1]) by pc219.belcaf.minsk.by (8.12.7/8.12.5) with ESMTP id h1LDS0Yo012205; Fri, 21 Feb 2003 15:28:01 +0200 Received: (from cat@localhost) by pc219.belcaf.minsk.by (8.12.7/8.12.5/Submit) id h1LDRwql012204; Fri, 21 Feb 2003 15:27:58 +0200 Date: Fri, 21 Feb 2003 15:27:58 +0200 From: Alexey Kotovich To: Seth Mos Cc: linux-xfs@oss.sgi.com Subject: Re: Problem using appletalk with MacOS X to a scsi hd with XFS. Message-ID: <20030221132758.GA8554@pc219.sam-solutions.net> Mail-Followup-To: Seth Mos , linux-xfs@oss.sgi.com References: <4.3.2.7.2.20030221084703.03577f70@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="dDRMvlgZJXvWKvBx" Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20030221084703.03577f70@pop.xs4all.nl> User-Agent: Mutt/1.4i X-Operating-System: ALT Linux GNU/Linux X-Kernel: Linux 2.4.18-alt6master-up X-archive-position: 2841 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: a.kotovich@sam-solutions.net Precedence: bulk X-list: linux-xfs Content-Length: 10122 Lines: 333 --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Hi there; I have the same experience some time ago. I wrote a patch for netatalk-1.5.0/3 that can help you to workaround problem. If my memory doesn't fail me the issue is as follows (as short as possible): AFP uses unique file number for internal needs which is two bytes of length. Netatalk does something like this ((st->st_dev << 16) | (st->st_ino & 0x0000ffff)) to get such a number. I'd like to mention that it must be unique per request only. As xfs has 64bits inode number and it has inconsequent order, sometimes we get the same file numbers in the same request that causes "error -50" on MacOS. kind regards, Alexey Kotovich ICQ:97715595 -- > Hello, > > I have someone from promise who is having problems accessing files over > Appletalk using MacOS X to a scsi disk. > If anyone else out there is using this combination I would appreciate the > help. > I have access to the hardware but not the time to spare at the moment for > setting up appletalk attaching scsi disks to my testbox etc. > > From: "Scott Liu" > To: > Subject: Mac X access to XFS filesystem on SCSI device problem? > Date: Thu, 23 Jan 2003 11:31:22 +0800 > Message-ID: <001001c2c28f$e7932fd0$a6cca8c0@Scott> > MIME-Version: 1.0 > Content-Type: text/plain; > charset="big5" > X-Priority: 3 (Normal) > X-MSMail-Priority: Normal > X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) > X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 > Importance: Normal > Content-Transfer-Encoding: 8bit > X-MIME-Autoconverted: from base64 to 8bit by maildrop7.xs4all.nl id > h0N3V4e45796 > X-UIDL: 1043292665.maildrop7.45805 > > Dear, > > I create a partition with XFS on SCSI device, and copy a lot of files > (about 500M bytes) from Mac X to this partition, sometimes it will fail > with error message "-50". > I test this with xfs 1.01, xfs 1.1 and xfs 1.2 pre-release#5, the problem > also happen. > > But when the partition is ext2 on scsi device, XFS on IDE device or ext2 on > IDE device, they are OK. > It happens with XFS on SCSI device access from Mac X. > > Netatalk version is : netatalk-1.4b2+asun2.1.3 > Mac version is : Mac X 10.1.4 Japanese version > > May you let me know how to solve this problem? Thanks. > > Best Regards, > Scott Liu > -- > Seth > It might just be your lucky day, if you only knew. > --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="netatalk-1.5.0-xfs.patch" diff -ruN netatalk-1.5.0/etc/afpd/file.c netatalk-1.5.0-new/etc/afpd/file.c --- netatalk-1.5.0/etc/afpd/file.c 2001-12-03 08:10:12 +0200 +++ netatalk-1.5.0-new/etc/afpd/file.c 2002-08-30 16:36:53 +0300 @@ -95,6 +95,40 @@ 0, 0, 0, 0, 0, 0, 0, 0 }; +static u_int32_t getinode(struct vol *vol, const char *path) +{ +#define MAXLEN 1024 + FILE *file; + u_int32_t ret = 1; + char *dpath = 0; + char *fpath = 0; + + if (!(dpath = calloc(1, MAXLEN))) { + return ret; + } + + if (!(fpath = calloc(1, MAXLEN))) { + ret = 0; + goto getinode_exit; + } + + getcwd(dpath, MAXLEN - 1); + snprintf(fpath, MAXLEN - 1, "%s/.AppleDouble/%s", dpath, path); + + if (!(file = fopen(fpath, "r"))) { + ret = 0; + } else { + fseek(file, ADEDOFF_COMMENT, SEEK_SET); + fread(&ret, 4, 1, file); + fclose(file); + } + +getinode_exit: + if (dpath) free(dpath); + if (fpath) free(fpath); + return ret; +} + int getfilparams(struct vol *vol, u_int16_t bitmap, char *path, struct dir *dir, struct stat *st, @@ -110,7 +144,7 @@ struct extmap *em; char *data, *nameoff = NULL, *upath; int bit = 0, isad = 1; - u_int32_t aint; + u_int32_t aint, inode = 0; u_int16_t ashort; u_char achar, fdType[4]; @@ -214,7 +248,24 @@ break; case FILPBIT_FNUM : - aint = 0; + aint = 0; + inode = getinode(vol, mtoupath(vol, path)); + + if (inode != 0) { + aint = htonl((st->st_dev << 16) | (inode & 0x0000ffff)); + memcpy(data, &aint, sizeof( aint )); + data += sizeof( aint ); +#if 0 + { + FILE *file = fopen("/tmp/XFS_inode.hash", "a"); + fprintf(file, "seq: %d: last: %d: path: %s\n", + aint, vol->v_lastinode, mtoupath(vol, path)); + fclose(file); + } +#endif + break; + } + #if AD_VERSION > AD_VERSION1 /* look in AD v2 header */ if (isad) @@ -264,9 +315,16 @@ #endif /* DID_MTAB */ #endif /* USE_LASTDID */ } - memcpy(data, &aint, sizeof( aint )); data += sizeof( aint ); +#if 0 + { + FILE *file = fopen("/tmp/XFS_inode.hash", "a"); + fprintf(file, "gen: %d: last: %d: path: %s\n", + aint, vol->v_lastinode, mtoupath(vol, path)); + fclose(file); + } +#endif break; case FILPBIT_DFLEN : @@ -482,6 +540,8 @@ ad_setentrylen( adp, ADEID_NAME, strlen( path )); memcpy(ad_entry( adp, ADEID_NAME ), path, ad_getentrylen( adp, ADEID_NAME )); + vol->v_lastinode > 65535 ? vol->v_lastinode = 1 : vol->v_lastinode ++; + memcpy(ad_entry(adp, ADEID_COMMENT), &vol->v_lastinode, 4); ad_flush( adp, ADFLAGS_DF|ADFLAGS_HF ); ad_close( adp, ADFLAGS_DF|ADFLAGS_HF ); diff -ruN netatalk-1.5.0/etc/afpd/volume.c netatalk-1.5.0-new/etc/afpd/volume.c --- netatalk-1.5.0/etc/afpd/volume.c 2002-08-30 16:17:49 +0300 +++ netatalk-1.5.0-new/etc/afpd/volume.c 2002-08-29 20:07:48 +0300 @@ -1149,6 +1149,8 @@ goto openvol_err; } + volume->v_lastinode = 0; + buflen = *rbuflen - sizeof( bitmap ); if (( ret = getvolparams( bitmap, volume, &st, rbuf + sizeof(bitmap), &buflen )) != AFP_OK ) { diff -ruN netatalk-1.5.0/etc/afpd/volume.h netatalk-1.5.0-new/etc/afpd/volume.h --- netatalk-1.5.0/etc/afpd/volume.h 2002-08-30 16:17:49 +0300 +++ netatalk-1.5.0-new/etc/afpd/volume.h 2002-08-29 20:07:48 +0300 @@ -60,6 +60,7 @@ char *v_forceuid; char *v_forcegid; #endif /* FORCE_UIDGID */ + u_int32_t v_lastinode; }; #ifdef NO_LARGE_VOL_SUPPORT --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="netatalk-1.5.3-xfs.patch" diff -ruN netatalk-1.5.3/etc/afpd/file.c netatalk-1.5.3-new/etc/afpd/file.c --- netatalk-1.5.3/etc/afpd/file.c 2002-05-25 15:28:19 +0300 +++ netatalk-1.5.3-new/etc/afpd/file.c 2002-08-30 17:55:44 +0300 @@ -95,6 +95,35 @@ 0, 0, 0, 0, 0, 0, 0, 0 }; +static u_int32_t getinode(struct vol *vol, const char *path) +{ +#define MAXLEN 1024 + FILE *file; + u_int32_t ret = 0; + char *dpath = 0; + char *fpath = 0; + + if (!(dpath = calloc(1, MAXLEN))) + return ret; + + if (!(fpath = calloc(1, MAXLEN))) + goto getinode_exit; + + getcwd(dpath, MAXLEN - 1); + snprintf(fpath, MAXLEN - 1, "%s/.AppleDouble/%s", dpath, path); + + if ((file = fopen(fpath, "r"))) { + fseek(file, ADEDOFF_COMMENT, SEEK_SET); + fread(&ret, 4, 1, file); + fclose(file); + } + +getinode_exit: + if (dpath) free(dpath); + if (fpath) free(fpath); + return ret; +} + int getmetadata(struct vol *vol, u_int16_t bitmap, char *path, struct dir *dir, struct stat *st, @@ -107,7 +136,7 @@ struct extmap *em; char *data, *nameoff = NULL, *upath; int bit = 0; - u_int32_t aint; + u_int32_t aint, inode = 0; u_int16_t ashort; u_char achar, fdType[4]; @@ -206,7 +235,24 @@ break; case FILPBIT_FNUM : - aint = 0; + aint = 0; + inode = getinode(vol, mtoupath(vol, path)); + + if (inode != 0) { + aint = htonl((st->st_dev << 16) | (inode & 0x0000ffff)); + memcpy(data, &aint, sizeof( aint )); + data += sizeof( aint ); +#if 0 + { + FILE *file = fopen("/tmp/XFS_inode.hash", "a"); + fprintf(file, "seq: %d: last: %d: path: %s\n", + aint, vol->v_lastinode, mtoupath(vol, path)); + fclose(file); + } +#endif + break; + } + #if AD_VERSION > AD_VERSION1 /* look in AD v2 header */ if (adp) @@ -272,6 +318,14 @@ memcpy(data, &aint, sizeof( aint )); data += sizeof( aint ); +#if 0 + { + FILE *file = fopen("/tmp/XFS_inode.hash", "a"); + fprintf(file, "gen: %d: last: %d: path: %s\n", + aint, vol->v_lastinode, mtoupath(vol, path)); + fclose(file); + } +#endif break; case FILPBIT_DFLEN : @@ -510,6 +564,8 @@ ad_setentrylen( adp, ADEID_NAME, strlen( path )); memcpy(ad_entry( adp, ADEID_NAME ), path, ad_getentrylen( adp, ADEID_NAME )); + vol->v_lastinode > 65535 ? vol->v_lastinode = 1 : vol->v_lastinode ++; + memcpy(ad_entry(adp, ADEID_COMMENT), &vol->v_lastinode, 4); ad_flush( adp, ADFLAGS_DF|ADFLAGS_HF ); ad_close( adp, ADFLAGS_DF|ADFLAGS_HF ); diff -ruN netatalk-1.5.3/etc/afpd/volume.c netatalk-1.5.3-new/etc/afpd/volume.c --- netatalk-1.5.3/etc/afpd/volume.c 2002-08-30 17:57:58 +0300 +++ netatalk-1.5.3-new/etc/afpd/volume.c 2002-08-30 17:27:09 +0300 @@ -1155,6 +1155,8 @@ goto openvol_err; } + volume->v_lastinode = 0; + buflen = *rbuflen - sizeof( bitmap ); if (( ret = getvolparams( bitmap, volume, &st, rbuf + sizeof(bitmap), &buflen )) != AFP_OK ) { diff -ruN netatalk-1.5.3/etc/afpd/volume.h netatalk-1.5.3-new/etc/afpd/volume.h --- netatalk-1.5.3/etc/afpd/volume.h 2002-08-30 17:57:58 +0300 +++ netatalk-1.5.3-new/etc/afpd/volume.h 2002-08-30 17:28:02 +0300 @@ -60,6 +60,7 @@ char *v_forceuid; char *v_forcegid; #endif /* FORCE_UIDGID */ + u_int32_t v_lastinode; }; #ifdef NO_LARGE_VOL_SUPPORT --dDRMvlgZJXvWKvBx-- From owner-linux-xfs@oss.sgi.com Fri Feb 21 06:18:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Feb 2003 06:18:37 -0800 (PST) Received: from deimos.frii.net (deimos.frii.com [216.17.128.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1LEIY3v010024 for ; Fri, 21 Feb 2003 06:18:34 -0800 Received: from frii.com ([216.17.224.222]) by deimos.frii.net (8.12.5/8.12.5) with ESMTP id h1LERP0W013908 for ; Fri, 21 Feb 2003 07:27:25 -0700 (MST) Message-ID: <3E5636FB.7030101@frii.com> Date: Fri, 21 Feb 2003 07:26:03 -0700 From: Jeff Means User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: problem with forRH-8.0-SGI-XFS-1.2.0-v3.iso Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2842 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: pico@frii.com Precedence: bulk X-list: linux-xfs Content-Length: 317 Lines: 9 in the ISO you have libattr-2.1.1-1.i386.rpm but the install script wants libattr-2.0.12-0.i386.rpm I don't know how to fix this myself and would appreaciate a quick response to this problem. I don't know if the same problem exists for libattr-devel-2.1.1-1.i386.rpm. Jeff Means CIO for MeansPC pico@frii.com From owner-linux-xfs@oss.sgi.com Fri Feb 21 06:44:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Feb 2003 06: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 h1LEiM3v010666 for ; Fri, 21 Feb 2003 06:44:22 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1LEiMH8010665 for linux-xfs@oss.sgi.com; Fri, 21 Feb 2003 06: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 h1LEiL3x010650 for ; Fri, 21 Feb 2003 06:44:21 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1LEQLIT010550; Fri, 21 Feb 2003 06:26:21 -0800 Date: Fri, 21 Feb 2003 06:26:21 -0800 Message-Id: <200302211426.h1LEQLIT010550@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 224] New: ISO for installer redhat 8.0 problem forRH-8.0-SGI-XFS-1.2.0-v3.iso X-Bugzilla-Reason: AssignedTo X-archive-position: 2843 X-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: 900 Lines: 34 http://oss.sgi.com/bugzilla/show_bug.cgi?id=224 Summary: ISO for installer redhat 8.0 problem forRH-8.0-SGI-XFS- 1.2.0-v3.iso Product: Linux XFS Version: 1.2.x Platform: IA32 OS/Version: Linux Status: NEW Severity: critical Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: pico@frii.com Steps to Reproduce: 1. Run Installer Actual Results: loops forever looking for libattr-2.0.12-0.i386.rpm when libattr-2.1.1-1.i386.rpm is packaged on disk Expected Results: installer runs normally and does not get hung up looking for files that are not there or there under a diffrent filename 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 Fri Feb 21 10:05:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Feb 2003 10:06:03 -0800 (PST) Received: from web41401.mail.yahoo.com (web41401.mail.yahoo.com [66.218.93.67]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1LI5s3v019562 for ; Fri, 21 Feb 2003 10:05:55 -0800 Message-ID: <20030221181441.50158.qmail@web41401.mail.yahoo.com> Received: from [216.18.124.226] by web41401.mail.yahoo.com via HTTP; Fri, 21 Feb 2003 10:14:41 PST Date: Fri, 21 Feb 2003 10:14:41 -0800 (PST) From: Rock Gordon Subject: xfs extended attributed/extents To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 2844 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rockgordon@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 200 Lines: 11 Hi, Does XFS journal EAs and extended attributes? TIA, __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ From owner-linux-xfs@oss.sgi.com Fri Feb 21 10:24:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Feb 2003 10:24:53 -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 h1LIOo3v020343 for ; Fri, 21 Feb 2003 10:24:50 -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 h1LIXYKp019094 for ; Fri, 21 Feb 2003 10:33:36 -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 FAA13997; Sat, 22 Feb 2003 05:32:18 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id FAA69251; Sat, 22 Feb 2003 05:32:16 +1100 (EST) Date: Sat, 22 Feb 2003 05:32:16 +1100 From: Nathan Scott To: Rock Gordon Cc: linux-xfs@oss.sgi.com Subject: Re: xfs extended attributed/extents Message-ID: <20030222053216.B882669@wobbly.melbourne.sgi.com> References: <20030221181441.50158.qmail@web41401.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030221181441.50158.qmail@web41401.mail.yahoo.com>; from rockgordon@yahoo.com on Fri, Feb 21, 2003 at 10:14:41AM -0800 X-archive-position: 2845 X-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: 234 Lines: 14 On Fri, Feb 21, 2003 at 10:14:41AM -0800, Rock Gordon wrote: > Hi, > > Does XFS journal EAs and extended attributes? Yes, extended attributes are considered metadata in XFS. (EAs == extended attributes, btw). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Feb 21 11:22:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Feb 2003 11:22:18 -0800 (PST) Received: from web41411.mail.yahoo.com (web41411.mail.yahoo.com [66.218.93.77]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1LJM83v022717 for ; Fri, 21 Feb 2003 11:22:09 -0800 Message-ID: <20030221193056.40587.qmail@web41411.mail.yahoo.com> Received: from [216.18.124.226] by web41411.mail.yahoo.com via HTTP; Fri, 21 Feb 2003 11:30:56 PST Date: Fri, 21 Feb 2003 11:30:56 -0800 (PST) From: Rock Gordon Subject: Re: xfs extended attributed/extents To: Nathan Scott Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030222053216.B882669@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 2846 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rockgordon@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 618 Lines: 31 Oh .. I'm sorry ... I meant "EAs and extents" ... (dunno what I was smoking :) ). On a side note, how frequently is the journal comitted to disk? Is it tunable? TIA, --- Nathan Scott wrote: > On Fri, Feb 21, 2003 at 10:14:41AM -0800, Rock > Gordon wrote: > > Hi, > > > > Does XFS journal EAs and extended attributes? > > Yes, extended attributes are considered metadata in > XFS. > > (EAs == extended attributes, btw). > > cheers. > > -- > Nathan __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ From owner-linux-xfs@oss.sgi.com Fri Feb 21 13:59:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Feb 2003 14:00:27 -0800 (PST) Received: from universe.chowhouse.com (IDENT:0@stumpy.chowhouse.com [209.180.91.165] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1LLxo3v025431 for ; Fri, 21 Feb 2003 13:59:51 -0800 Received: from universe.chowhouse.com (IDENT:1000@localhost [127.0.0.1]) by universe.chowhouse.com (8.12.6/8.12.6) with ESMTP id h1LMBO09005166 for ; Fri, 21 Feb 2003 15:11:24 -0700 Received: from localhost (james@localhost) by universe.chowhouse.com (8.12.6/8.12.6/Submit) with ESMTP id h1LMBOdF005163 for ; Fri, 21 Feb 2003 15:11:24 -0700 Date: Fri, 21 Feb 2003 15:11:24 -0700 (MST) From: James Rich To: XFS mailing list Subject: Re: problem creating log In-Reply-To: <1045795223.1235.1.camel@Liberator> Message-ID: References: <1045795223.1235.1.camel@Liberator> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2847 X-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@chowhouse.com Precedence: bulk X-list: linux-xfs Content-Length: 1166 Lines: 38 On Thu, 20 Feb 2003, Eric Sandeen wrote: > On Thu, 2003-02-20 at 20:32, James Rich wrote: > > > what should I do? > > Please try a newer xfsprogs version, for starters - 2.0.3 is pretty old > by now. 2.3.9 is on the ftp site now, or grab a slightly older version > from the 1.2 release. I did so and found that a problem exists when I specify the size as in: size=10000b. If I leave the size off it works. Here is the failing command: mkfs.xfs -f -l logdev=/dev/sdb6,size=10000b /dev/sda2 If I just leave the size parameter off it works. But how much of the /dev/sdb6 partition is used? /proc/partitions shows this for sdb6: 8 22 16033 sdb6 Is the partition big enough (I made it really small thinking that the log is small)? /proc/partitions for /dev/sda2 looks like: 8 2 208845 sda2 Does the log size depend on the partition being logged (i.e. if sda2 was 10 times bigger would the log need to be ten times bigger)? I know I could just use an internal log, but I have two disks and the itch to experiment :) Futher, by default mkfs.xfs creates logs with version 1. Shouldn't it default to version 2? Now using mkfs.xfs version 2.3.9 James Rich From owner-linux-xfs@oss.sgi.com Fri Feb 21 15:12:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Feb 2003 15:12: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 h1LNC03v026771 for ; Fri, 21 Feb 2003 15:12:00 -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 h1LNKmKp001774 for ; Fri, 21 Feb 2003 15:20:48 -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 RAA30530; Fri, 21 Feb 2003 17:20:47 -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 RAA51749; Fri, 21 Feb 2003 17:20:46 -0600 (CST) Date: Fri, 21 Feb 2003 17:18:59 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: James Rich cc: XFS mailing list Subject: Re: problem creating log In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2848 X-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: 1794 Lines: 57 Let's go with Nathan's hunch - what version of the kernel are you using? the BLKGETSIZE64 iocttl was broken for a while, and returned bad values. That could be causing your problem... THe default internal log grows with the size of the fs, to a point. But aside from some overall min/max log sizes (probably documented in the mkfs.xfs man page) you can have a wide range of log sizes for a given fs. Log v1 is still default, logv2 could probably use more testing before it becomes the default. -Eric On Fri, 21 Feb 2003, James Rich wrote: > On Thu, 20 Feb 2003, Eric Sandeen wrote: > > > On Thu, 2003-02-20 at 20:32, James Rich wrote: > > > > > what should I do? > > > > Please try a newer xfsprogs version, for starters - 2.0.3 is pretty old > > by now. 2.3.9 is on the ftp site now, or grab a slightly older version > > from the 1.2 release. > > I did so and found that a problem exists when I specify the size as in: > size=10000b. If I leave the size off it works. Here is the failing > command: > > mkfs.xfs -f -l logdev=/dev/sdb6,size=10000b /dev/sda2 > > If I just leave the size parameter off it works. But how much of the > /dev/sdb6 partition is used? /proc/partitions shows this for sdb6: > > 8 22 16033 sdb6 > > Is the partition big enough (I made it really small thinking that the log > is small)? /proc/partitions for /dev/sda2 looks like: > > 8 2 208845 sda2 > > Does the log size depend on the partition being logged (i.e. if sda2 was > 10 times bigger would the log need to be ten times bigger)? I know I > could just use an internal log, but I have two disks and the itch to > experiment :) > > Futher, by default mkfs.xfs creates logs with version 1. Shouldn't it > default to version 2? > > Now using mkfs.xfs version 2.3.9 > > James Rich > > From owner-linux-xfs@oss.sgi.com Fri Feb 21 15:26:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Feb 2003 15:27:05 -0800 (PST) Received: from universe.chowhouse.com (IDENT:0@stumpy.chowhouse.com [209.180.91.165] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1LNQu3v027269 for ; Fri, 21 Feb 2003 15:26:57 -0800 Received: from universe.chowhouse.com (IDENT:1000@localhost [127.0.0.1]) by universe.chowhouse.com (8.12.6/8.12.6) with ESMTP id h1LNcV09005329 for ; Fri, 21 Feb 2003 16:38:31 -0700 Received: from localhost (james@localhost) by universe.chowhouse.com (8.12.6/8.12.6/Submit) with ESMTP id h1LNcV0X005326 for ; Fri, 21 Feb 2003 16:38:31 -0700 Date: Fri, 21 Feb 2003 16:38:31 -0700 (MST) From: James Rich To: XFS mailing list Subject: Re: problem creating log In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2849 X-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@chowhouse.com Precedence: bulk X-list: linux-xfs Content-Length: 1062 Lines: 29 On Fri, 21 Feb 2003, Eric Sandeen wrote: > Let's go with Nathan's hunch - what version of the kernel are you using? 2.4.20 - though my cvs isn't as up to date as I thought it was. Was BLKGETSIZE64 broken anytime during 2.4.20? > the BLKGETSIZE64 iocttl was broken for a while, and returned bad values. > That could be causing your problem... > > THe default internal log grows with the size of the fs, to a point. But > aside from some overall min/max log sizes (probably documented in the > mkfs.xfs man page) you can have a wide range of log sizes for a given fs. I'm just wondering if my log partitions are big enough and if the size parameter is not specified does the log occupy the entire partition? > > If I just leave the size parameter off it works. But how much of the > > /dev/sdb6 partition is used? /proc/partitions shows this for sdb6: > > > > 8 22 16033 sdb6 > > > > Is the partition big enough (I made it really small thinking that the log > > is small)? /proc/partitions for /dev/sda2 looks like: > > > > 8 2 208845 sda2 James Rich From owner-linux-xfs@oss.sgi.com Fri Feb 21 15:46:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Feb 2003 15:46:18 -0800 (PST) Received: from universe.chowhouse.com (IDENT:0@stumpy.chowhouse.com [209.180.91.165] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1LNk93v027783 for ; Fri, 21 Feb 2003 15:46:09 -0800 Received: from universe.chowhouse.com (IDENT:1000@localhost [127.0.0.1]) by universe.chowhouse.com (8.12.6/8.12.6) with ESMTP id h1LNvh09005367 for ; Fri, 21 Feb 2003 16:57:43 -0700 Received: from localhost (james@localhost) by universe.chowhouse.com (8.12.6/8.12.6/Submit) with ESMTP id h1LNvhgO005364 for ; Fri, 21 Feb 2003 16:57:43 -0700 Date: Fri, 21 Feb 2003 16:57:43 -0700 (MST) From: James Rich To: XFS mailing list Subject: Re: problem creating log In-Reply-To: <200302211737.40492.joebacom@volstate.net> Message-ID: References: <200302211737.40492.joebacom@volstate.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2850 X-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@chowhouse.com Precedence: bulk X-list: linux-xfs Content-Length: 1109 Lines: 37 On Fri, 21 Feb 2003, Joe Bacom wrote: > What size did you make /dev/sdb6? fdisk /dev/sdb reports for sdb6: /dev/sdb6 354 355 16033 83 Linux which to me says around 16 MB. The trouble I have is that is 10,000 blocks for mkfs.xfs the same type of blocks as for fdisk? If so, then I have 16,033 - more than the 10,000 blocks I was trying to specify on the mkfs.xfs command. > Log size of 10,000 blocks it would need to be 40M > > Here is the formula that I use: > > 10000 blocks * 4 (4k blocks) / 1024 = size in meg. According to this my log partition is too small (if I want a log size of 10,000b). > Example: > for a log size of 128M you need to specify 32768b > > 32768 * 4 / 1024 = 128M Is there some advantage to a 128 MB log size versus a 10,000b log size? On another note - I created my / partition with an external log. How do I pass the logdev parameter to the kernel so it can be mounted? The lilo.conf man page didn't have anything to indicate how to pass mount parameters to the kernel. If I use a different partition for / that doesn't have an external log all is well. James Rich From owner-linux-xfs@oss.sgi.com Fri Feb 21 15:47:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Feb 2003 15:47: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 h1LNlO3v028095 for ; Fri, 21 Feb 2003 15:47:25 -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 h1LNuCKp006238 for ; Fri, 21 Feb 2003 15:56:13 -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 RAA56409; Fri, 21 Feb 2003 17:56:11 -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 RAA55119; Fri, 21 Feb 2003 17:56:11 -0600 (CST) Date: Fri, 21 Feb 2003 17:54:24 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: James Rich cc: XFS mailing list Subject: Re: problem creating log In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2851 X-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: 1266 Lines: 34 On Fri, 21 Feb 2003, James Rich wrote: > 2.4.20 - though my cvs isn't as up to date as I thought it was. Was > BLKGETSIZE64 broken anytime during 2.4.20? Nope, much earlier. > I'm just wondering if my log partitions are big enough and if the size > parameter is not specified does the log occupy the entire partition? That's right, the external log size defaults to the size of the log device you point at. If the device is smaller than what you request, you should get something like: mkfs.xfs -f -l logdev=/dev/sda2,size=10000b /dev/sda1 size 10000b specified for log subvolume is too large, maximum is 4016 blocks If my test device is large enough, then the command above succeeds for me. I thought that you had to specify a block size before you could use a "b" unit to specify any other size, but it looks like that's not causing an error... In any case, you were specifying 10000b, which is using (I guess) 4k blocks, or a 40960000-byte log. You said /proc/partitions showed 16033 512-byte blocks for sdb6, or 8208896 bytes - smaller than what you asked for. So that might be why it's failing, but I don't know why it's failing the way it is... I'd probably need to start gdb'ing or printf'ing my way through mkfs to see what's going on. -Eric From owner-linux-xfs@oss.sgi.com Fri Feb 21 16:00:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Feb 2003 16:00:27 -0800 (PST) Received: from universe.chowhouse.com (IDENT:0@stumpy.chowhouse.com [209.180.91.165] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1M00H3v028760 for ; Fri, 21 Feb 2003 16:00:18 -0800 Received: from universe.chowhouse.com (IDENT:1000@localhost [127.0.0.1]) by universe.chowhouse.com (8.12.6/8.12.6) with ESMTP id h1M0Bq09005388 for ; Fri, 21 Feb 2003 17:11:52 -0700 Received: from localhost (james@localhost) by universe.chowhouse.com (8.12.6/8.12.6/Submit) with ESMTP id h1M0Bqme005385 for ; Fri, 21 Feb 2003 17:11:52 -0700 Date: Fri, 21 Feb 2003 17:11:52 -0700 (MST) From: James Rich To: XFS mailing list Subject: Re: problem creating log In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2852 X-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@chowhouse.com Precedence: bulk X-list: linux-xfs Content-Length: 548 Lines: 15 On Fri, 21 Feb 2003, Eric Sandeen wrote: > So that might be why it's failing, but I don't know why it's failing the way > it is... I'd probably need to start gdb'ing or printf'ing my way through > mkfs to see what's going on. Okay, fantastic. Thanks for the guidance. Using a current mkfs.xfs fixed the original problem I reported about the weird minimum/maximum sizes. It now follows the behavior you describe exactly. Looks like I should make my log partitions bigger... Still wondering how to pass the logdev parm to lilo... James Rich From owner-linux-xfs@oss.sgi.com Fri Feb 21 17:38:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Feb 2003 17:38: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 h1M1cE3v030176 for ; Fri, 21 Feb 2003 17:38:14 -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 h1M1l2Kp021255 for ; Fri, 21 Feb 2003 17:47:03 -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 TAA84767; Fri, 21 Feb 2003 19:47:01 -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 TAA69276; Fri, 21 Feb 2003 19:47:01 -0600 (CST) Date: Fri, 21 Feb 2003 19:45:13 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: James Rich cc: XFS mailing list Subject: Re: problem creating log In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2853 X-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: 216 Lines: 13 On Fri, 21 Feb 2003, James Rich wrote: > Still wondering how to pass the logdev parm to lilo... In lilo.conf: append="rootflags=logdev=/dev/sdb6" (or some syntax close to that...) should do it, I think. -Eric From owner-linux-xfs@oss.sgi.com Fri Feb 21 22:12:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Feb 2003 22:13:20 -0800 (PST) Received: from web12308.mail.yahoo.com (web12308.mail.yahoo.com [216.136.173.106]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1M6Cg3v032478 for ; Fri, 21 Feb 2003 22:12:43 -0800 Message-ID: <20030222062137.53763.qmail@web12308.mail.yahoo.com> Received: from [12.254.129.114] by web12308.mail.yahoo.com via HTTP; Fri, 21 Feb 2003 22:21:37 PST Date: Fri, 21 Feb 2003 22:21:37 -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: 2854 X-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: 940 Lines: 27 Wahoo, I created an installer that worked, although it does have a problem. I think it asked for each cd 3 different times. I believe in anaconda there is a pkgorder that you can define, I might have to look into it. If anyone's desperate for a working/installing iso I have one I can upload. I had a sort of working build environment before, I don't know what was missing, but I remembered that this time all that was really needed was a re-generation of hdlist and hdlist2, I had everything set up for that, so I used the current v3 iso, and regenerated the hdlist, but used the same installer. As I said, it worked, but it was a bit anoying to put each cd in 3 times, let me know if anyone wants me to upload the iso anywhere, sorry I don't have a site to download it from. Jason Corbett __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ From owner-linux-xfs@oss.sgi.com Sat Feb 22 05:38:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 22 Feb 2003 05:38:17 -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 h1MDcD3v009178 for ; Sat, 22 Feb 2003 05:38:14 -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 h1MDl4G8008322 for ; Sat, 22 Feb 2003 05:47:04 -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 HAA03418; Sat, 22 Feb 2003 07:47: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 HAA75844; Sat, 22 Feb 2003 07:47:03 -0600 (CST) Date: Sat, 22 Feb 2003 07:45:10 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Jason Corbett cc: linux-xfs@oss.sgi.com Subject: Re: 1.2 rebuilt cmds and another installer iso. In-Reply-To: <20030222062137.53763.qmail@web12308.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2855 X-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: 491 Lines: 16 On Fri, 21 Feb 2003, Jason Corbett wrote: > Wahoo, I created an installer that worked, although it > does have a problem. I think it asked for each cd 3 > different times. I believe in anaconda there is a > pkgorder that you can define, I might have to look > into it. There is only so much you can do about this, due to dependencies. We were able to slightly change the pkgorder to make this better, but there will still be swaps. So, are you the new installer maintainer? :) -Eric From owner-linux-xfs@oss.sgi.com Sat Feb 22 09:28:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 22 Feb 2003 09:29:06 -0800 (PST) Received: from atlas.ace-hellas.gr (atlas.ace-hellas.gr [195.97.19.130]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1MHSv3v011268 for ; Sat, 22 Feb 2003 09:28:58 -0800 Received: from spyroshome (dhcp03.ace-hellas.gr [195.97.19.142] (may be forged)) by atlas.ace-hellas.gr (8.11.6/linuxconf) with SMTP id h1MHblt02228 for ; Sat, 22 Feb 2003 19:37:47 +0200 Message-ID: <000501c2da99$38cb6360$8e1361c3@spyroshome> From: "Spyros Ioakim" To: Subject: upgrade scenario for samba server Date: Sat, 22 Feb 2003 19:38:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-archive-position: 2856 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sioakim@ace-hellas.gr Precedence: bulk X-list: linux-xfs Content-Length: 2703 Lines: 63 Dear all, Recently I was asked to perform some Windows NT related file permissions on our samba file server. What was asked was for people to have access to give NTFS style permissions to specific files. e.g. The user who owned a file had to be able to give permissions to just another user. I found out that I couldn't do this and started looking around on the net and found out that this wasn't a samba limitation but a filesystem one. The solutions were two. Install kernel patches for acl support on my ext3 filesystem or "upgrade" it to xfs. I like the xfs solution better cause it seemed more stable and I'm also a big SGI fan... I need your comments on my solution to upgrade my file server to xfs. I understand that there isn't a tool to switch an ext3 fs to xfs (like ext2->ext3) I have the following scenerio and I need your comments on the following: My system right now has a RAID-5 controller (HP Netraid) that works with the megaraid driver. The system is running Redhat 7.2. I have set up my system like this: /dev/sda3 is / (133GB) /dev/sda1 is /boot (38MB) My files are on /samba (samba shares) and /home (user's home directories for windows) I go to / and do tar cvzfp homebackup.tar.gz home/* tar cvzfp sambabackup.tar.gz samba/* I also do: tar cvzfp etcbackup.tar.gz etc/* to get the configuration files, passwords etc.... I copy the tar.gzs to another disk which has free disk space to accomodate the above. I reboot the machine and install RH 8.0 using the xfs boot cd.I want your comments on the size of the partitions here. Right now I had everything under / cause I wanted a dynamic use of /home and /samba. 130GB to share between the two and redhat's files is much better for me than having: /home 50 GB /samba 50 GB / 30 GB Since the filesystem is journalized I don't have problems with fsck in case of power failure (very rare since the system is on a UPS) Even if I need to run fsck it takes about 15 minutes which is a good time (for me) so I don't see why i would break it down... So I'm thinking of having /boot 40MB ext3 and / 130 GB xfs. The bootloader will go to the MBR so there shouldn't be any problems booting (so I read....) After the system boots up with xfs I untar everything to /home and /samba. I also take the necessary files from /etc (I don't restore this don't worry) for the samba configuration, smbpasswd, passwd, shadow and whatever else I might need. Any comments/ideas would be appreciated... First of all will I get NT style permissions with samba or I'm just going to get a system with XFS and no gain :-? Is there anything special required for samba to use those acls? Thanks for reading the whole lot and waiting for comments :-) Spyros From owner-linux-xfs@oss.sgi.com Sat Feb 22 09:42:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 22 Feb 2003 09:42: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 h1MHg63v011825 for ; Sat, 22 Feb 2003 09:42:07 -0800 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.6/8.11.6) with ESMTP id h1MHp1804922; Sat, 22 Feb 2003 12:51:01 -0500 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Sat, 22 Feb 2003 12:51:01 -0500 (EST) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: Jason Corbett cc: linux-xfs@oss.sgi.com Subject: Re: 1.2 rebuilt cmds and another installer iso. In-Reply-To: <20030222062137.53763.qmail@web12308.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2857 X-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: 396 Lines: 15 On Fri, 21 Feb 2003 at 10:21pm, Jason Corbett wrote > Wahoo, I created an installer that worked, although it > does have a problem. I think it asked for each cd 3 > different times. I believe in anaconda there is a *snip* \begin{rimshot} Ah, trying to recreate the IRIX installation experience, huh? \end{rimshot} -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Sat Feb 22 09:52:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 22 Feb 2003 09:52:50 -0800 (PST) Received: from atlas.ace-hellas.gr (atlas.ace-hellas.gr [195.97.19.130]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1MHqg3v012396 for ; Sat, 22 Feb 2003 09:52:44 -0800 Received: from spyroshome (dhcp03.ace-hellas.gr [195.97.19.142] (may be forged)) by atlas.ace-hellas.gr (8.11.6/linuxconf) with SMTP id h1MI1Wt02765 for ; Sat, 22 Feb 2003 20:01:32 +0200 Message-ID: <005101c2da9c$8a91f5d0$8e1361c3@spyroshome> From: "Spyros Ioakim" To: Subject: upgrade scenario for samba server Date: Sat, 22 Feb 2003 20:02:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-archive-position: 2858 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sioakim@ace-hellas.gr Precedence: bulk X-list: linux-xfs Content-Length: 2703 Lines: 63 Dear all, Recently I was asked to perform some Windows NT related file permissions on our samba file server. What was asked was for people to have access to give NTFS style permissions to specific files. e.g. The user who owned a file had to be able to give permissions to just another user. I found out that I couldn't do this and started looking around on the net and found out that this wasn't a samba limitation but a filesystem one. The solutions were two. Install kernel patches for acl support on my ext3 filesystem or "upgrade" it to xfs. I like the xfs solution better cause it seemed more stable and I'm also a big SGI fan... I need your comments on my solution to upgrade my file server to xfs. I understand that there isn't a tool to switch an ext3 fs to xfs (like ext2->ext3) I have the following scenerio and I need your comments on the following: My system right now has a RAID-5 controller (HP Netraid) that works with the megaraid driver. The system is running Redhat 7.2. I have set up my system like this: /dev/sda3 is / (133GB) /dev/sda1 is /boot (38MB) My files are on /samba (samba shares) and /home (user's home directories for windows) I go to / and do tar cvzfp homebackup.tar.gz home/* tar cvzfp sambabackup.tar.gz samba/* I also do: tar cvzfp etcbackup.tar.gz etc/* to get the configuration files, passwords etc.... I copy the tar.gzs to another disk which has free disk space to accomodate the above. I reboot the machine and install RH 8.0 using the xfs boot cd.I want your comments on the size of the partitions here. Right now I had everything under / cause I wanted a dynamic use of /home and /samba. 130GB to share between the two and redhat's files is much better for me than having: /home 50 GB /samba 50 GB / 30 GB Since the filesystem is journalized I don't have problems with fsck in case of power failure (very rare since the system is on a UPS) Even if I need to run fsck it takes about 15 minutes which is a good time (for me) so I don't see why i would break it down... So I'm thinking of having /boot 40MB ext3 and / 130 GB xfs. The bootloader will go to the MBR so there shouldn't be any problems booting (so I read....) After the system boots up with xfs I untar everything to /home and /samba. I also take the necessary files from /etc (I don't restore this don't worry) for the samba configuration, smbpasswd, passwd, shadow and whatever else I might need. Any comments/ideas would be appreciated... First of all will I get NT style permissions with samba or I'm just going to get a system with XFS and no gain :-? Is there anything special required for samba to use those acls? Thanks for reading the whole lot and waiting for comments :-) Spyros From owner-linux-xfs@oss.sgi.com Sat Feb 22 10:22:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 22 Feb 2003 10:22:13 -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 h1MIM53v013057 for ; Sat, 22 Feb 2003 10:22:06 -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 h1MIV1cX086904 for ; Sat, 22 Feb 2003 12:31:02 -0600 (CST) (envelope-from cattelan@thebarn.com) Subject: Hopefully the last installer image. From: Russell Cattelan To: linux-xfs@oss.sgi.com Content-Type: text/plain Organization: Message-Id: <1045938661.1716.182.camel@lupo.thebarn.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Feb 2003 12:31:01 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 2859 X-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: 378 Lines: 12 The hdlist file has been rebuilt the installer has run through a install "everything" pass. I know not a a lot of testing but I should it in a "works for me" state at this point. ftp://oss.sgi.com/projects/xfs/Release-1.2/installer/forRH-8.0-SGI-XFS-1.2.0-v4.iso b1387ef5b9acd9def14a9f4eb298aaea forRH-8.0-SGI-XFS-1.2.0-v4.iso -- Russell Cattelan From owner-linux-xfs@oss.sgi.com Sat Feb 22 15:25:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 22 Feb 2003 15:25:32 -0800 (PST) Received: from atlas.ace-hellas.gr (atlas.ace-hellas.gr [195.97.19.130]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1MNPL3v016026 for ; Sat, 22 Feb 2003 15:25:23 -0800 Received: from spyroshome (dhcp05.ace-hellas.gr [195.97.19.144] (may be forged)) by atlas.ace-hellas.gr (8.11.6/linuxconf) with SMTP id h1MNXTt10000; Sun, 23 Feb 2003 01:33:30 +0200 Message-ID: <001701c2daca$ea4e8aa0$901361c3@spyroshome> From: "Spyros Ioakim" To: "Greg Freemyer" , References: <20030222194930.KBLJ3193.imf22bis.bellsouth.net@tiger2> Subject: Re: upgrade scenario for samba server Date: Sun, 23 Feb 2003 01:34:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-archive-position: 2860 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sioakim@ace-hellas.gr Precedence: bulk X-list: linux-xfs Content-Length: 5436 Lines: 148 Thanks for your quick reply, Unfortunately I don't have the time to install additional hardware to the server. I can take it down on a Sunday since nobody is working on it and an upgrade would also be nice... So I'm backing up everything and format/install clean RH 8.0... The FAQ says: Q: Can XFS be used for a root filesystem? Yes. A document describing how to convert your system to XFS is currently being worked on. The current state of this document you may find at http://www.linuxdoc.org/HOWTO/Linux+XFS-HOWTO/ The document describes on how to do the backup/restore similary to your way (with adding extra hardware to temporary backup the files). In the configuration of lilo.conf: /dev/hda2 / xfs defaults 1 1 So not only the FAQ mentions it but also the HOWTO shows that root partition can be XFS. For my case I don't want to get into LVM cause I have never used it before and it would be more trouble for my upgrade and don't have the time to check it out. So one / of 130GB will work for me (I guess)... And final question: Can you please be more specific on the limitation of samba and acls? What I want to do is for a file/folder the user that owns it to be able to give permissions to another user(s) or maybe another group. Access will normaly be Read, Write, Full Control. Please let me know if that's possible or if I will just waste my time with the upgrade. Regards, Spyros ----- Original Message ----- From: "Greg Freemyer" To: "Spyros Ioakim" ; Sent: Saturday, February 22, 2003 9:50 PM Subject: re: upgrade scenario for samba server > >> After the system boots up with xfs I untar everything to /home and /samba. > >> I also take the necessary files from /etc (I don't restore this don't > >> worry) > >> for the samba configuration, smbpasswd, passwd, shadow and whatever else I > >> might need. > > That should work. I personally have /home and /samba as standalone XFS filesytems. Then / is ext3 (without the kernel patch). This allows me to boot with a standard bootloader and also makes it easy to go into rescue mode from standard CDs. > > Having / as xfs may add to your work load, but I'm not sure. I assume the Redhat installer with xfs support has everything you need for / to be xfs?? > > Be aware that once you have ACLs (and/or EAs) that you need to back up, tar will no longer work for you. XFS comes with xfsdump and xfsrestore. There is also a modified version of tar called star that handles ACLs and EAs. I have never used star, so I can't say if it is any good or not. star is often used in conjunction with ext3 and the kernel patches you talked about. > > == And the "If I were you section" > > I would buy a 3ware 2-channel controller and a 200 GB IDE drive. Total cost $450. (Or get a 300 GB for a couple hundred more) > > The 3-ware card may be overkill, but I really like the way it makes an IDE drive perform like a SCSI drive and the 2-channel card is only a little over $100. > > (In reality, I would buy 2 drives and setup a mirror, but that is a different discussion.) > > Then add the new controller and disk to your existing environment. Compile up a kernel with XFS 1.2 support. (3ware and LVM are in the vanilla kernel). > > Then install the new kernel into /boot and reboot with it. > > The disk should show up as /dev/sda (or whatever is next in your setup.) > > Then add /dev/sda to a LVM PV and create a couple of good size LVs out of it. Be sure a leave some unused space on the PV for later expansion, and for snapshot usage. > > Build a xfs filesystem on one LV for /home and use another LV for /samba > > Make sure /samba and /home are quiescent. > > Mount the new filesystems and use tar to populate them. (ie. cd /mnt_new_home; tar cvf - /home | tar xvpf - ) > > mount the new FSes as /home and /samba. Restart samba (may not be needed) > > Now you have some volume expansion capability with LVM and you also have snapshot functionality. (I'm a big fan of snapshots). > > Also if you run out of diskspace, LVM will let put in another big drive and add it to the PV. Then use resize tools to extend the filesystems onto the extra drive. > > The good part is you did not have to do a full re-install of the OS. > > == End of "If I were you" > > >> Any comments/ideas would be appreciated... > >> First of all will I get NT style permissions with samba or I'm just going > >> to > >> get a system with XFS and no gain :-? > >> Is there anything special required for samba to use those acls? > > When you install XFS be sure and install all of the acl and attr related parts as well. > > >From my test server (I installed Samba last summer, so these are likely a little old): > > # rpm -qa | grep attr > attr-2.0.8-2 > attr-devel-2.0.8-2 > # rpm -qa | grep acl > acl-2.0.11-2 > acl-devel-2.0.11-2 > > Then you have to re-compile Samba to use ACLs. Something like ./configure --use_acls. Samba has a very complex ./configure line, so definitely try to get the ./configure line that was used to build your current installation and just add the --use_acls option. > > Also, you are aware that Samba only supports Posix ACLs (from a withdrawn draft standard). NTFS supports a superset of these so there are some NTFS ACLs that you will still not be able to support via Samba. > > HTH > Greg > -- > Greg Freemyer > From owner-linux-xfs@oss.sgi.com Sat Feb 22 15:48:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 22 Feb 2003 15:48:40 -0800 (PST) Received: from imf50bis.bellsouth.net (mail138.mail.bellsouth.net [205.152.58.98]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1MNmX3v016575 for ; Sat, 22 Feb 2003 15:48:33 -0800 Received: from tiger2 ([66.156.0.201]) by imf50bis.bellsouth.net (InterMail vM.5.01.04.25 201-253-122-122-125-20020815) with SMTP id <20030222235925.UXGP22060.imf50bis.bellsouth.net@tiger2>; Sat, 22 Feb 2003 18:59:25 -0500 Date: Sat, 22 Feb 2003 19:00:43 -0500 From: Greg Freemyer Subject: re[2]: upgrade scenario for samba server To: Spyros Ioakim , Mime-Version: 1.0 Organization: Norcross Group X-Mailer: GoldMine [6.00.21021] Content-Type: Text/plain Message-Id: <20030222235925.UXGP22060.imf50bis.bellsouth.net@tiger2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h1MNmY3v016583 X-archive-position: 2861 X-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-ml@NorcrossGroup.com Precedence: bulk X-list: linux-xfs Content-Length: 873 Lines: 23 >> And final question: >> Can you please be more specific on the limitation of samba and acls? >> What I want to do is for a file/folder the user that owns it to be able to >> give permissions to another user(s) or maybe another group. >> Access will normaly be Read, Write, Full Control. >> Please let me know if that's possible or if I will just waste my time with >> the upgrade. >> Regards, >> Spyros You can definitely give other users and groups unique privileges. Posix ACLs only allow each unique user/group to have 3 permissions read / write / execute. i.e. the normal UNIX permissions, but expanded to have the ability to define them for multiple users and groups. So what you describe should be possible. NTFS also has a delete ACL I think that is not supported, and I don't know how Modify and List Folder Contents are handled. Greg From owner-linux-xfs@oss.sgi.com Sun Feb 23 00:03:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 23 Feb 2003 00:04:04 -0800 (PST) Received: from curlew.cs.man.ac.uk (curlew.cs.man.ac.uk [130.88.13.7]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1N83v3v020821 for ; Sun, 23 Feb 2003 00:03:58 -0800 Received: from lithium.sta.man.ac.uk ([130.88.188.32] helo=doufu ident=mail) by curlew.cs.man.ac.uk with esmtp (Exim 4.12) id 18mrFn-0007q9-00 for linux-xfs@oss.sgi.com; Sun, 23 Feb 2003 08:12:55 +0000 Received: from rhowe by doufu with local (Exim 3.36 #1 (Debian)) id 18mrFn-0003fF-00 for ; Sun, 23 Feb 2003 08:12:55 +0000 Date: Sun, 23 Feb 2003 08:12:55 +0000 To: linux-xfs@oss.sgi.com Subject: xfs_repair unable to repair a corrupt filesystem Message-ID: <20030223081255.GA14077@lithium.sta.man.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i From: "Russell G. Howe" X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *18mrFn-0007q9-00*EaL5iqzPuy6* X-archive-position: 2862 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rhowe@wiss.co.uk Precedence: bulk X-list: linux-xfs Content-Length: 1490 Lines: 37 Hi, I'm having some problems with /var on my machine. The machine itself is rather unstable and hangs every few days, but I don't think that is XFS-related. What does concern XFS is the data corruption I experience after such a hard lockup (Alt+SysRq+B won't reboot the box, no HDD activity, etc). /var has had at least some corruption for the past week or so which I haven't had chance to fix. I took the opportunity just now after the latest hang (which has hosed /home). I'll post a seperate message about the /home problem singe it seems to be a seperate issue. xfs_repair on /var appeared to fix at least some things, but there were clearly still errors. I re-ran xfs_repair and got this output: http://rhowe.sfarc.net/xfs_repair_var.txt.gz The output appears identical no matter how many times I run xfs_repair. I'm using XFS from CVS, sometime around the 19th Dec (that is the date of compilation, and I update just before I compile). It's based on 2.4.20. Is this too old to be of use as a bug report? I am able and willing to build a more up to date release of XFS if need be. xfs_repair is from the Debian (unstable) package, and reports its version as 2.3.11 I can mount /var, but all those xfs_repair errors make me rather suspicious about using it. Most errors appear to be centred around one large (700Mbish) file, which I don't mind losing. -- Russell Howe | Why be just another cog in the machine, rhowe@wiss.co.uk | when you can be the spanner in the works? From owner-linux-xfs@oss.sgi.com Sun Feb 23 11:36:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 23 Feb 2003 11:36:24 -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 h1NJaH3v002620 for ; Sun, 23 Feb 2003 11:36:18 -0800 Received: (qmail 4828 invoked by uid 777); 23 Feb 2003 19:45:22 -0000 Date: Sun, 23 Feb 2003 20:45:22 +0100 From: Karol Kozimor To: linux-xfs@oss.sgi.com Subject: Re: buffer layer error Message-ID: <20030223194522.GA27423@hell.org.pl> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20030219100207.GA15374@hell.org.pl> <20030221000426.GA13165@hell.org.pl> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline In-Reply-To: <20030221000426.GA13165@hell.org.pl> User-Agent: Mutt/1.4i X-archive-position: 2863 X-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: 24767 Lines: 1173 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline I posted something like that a couple of days ago: > 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. Since I received no response, I assume nobody bothered to see the pictures :) Well, that was my fault anyway. So, here is the output: #v+ buffer layer error at fs/buffer.c:2697 Call Trace: [] drop_buffers+0xb3/0xb9 [] try_to_free_buffers+0x3c/0x96 [] linvfs_release_page+0x64/0x66 [] try_to_release_page+0x5c/0x6c [] block_invalidatepage+0xe3/0xf6 [] do_invalidate_page+0x27/0x2b [] truncate_complete_page+0x87/0x89 [] truncate_inode_pages+0xed/0x31d [] xfs_bmap_last_offset+0xc2/0x119 [] xfs_file_last_byte+0xea/0xf7 [] xfs_itruncate_start+0x9e/0xe2 [] xfs_setattr+0xb17/0xc2a [] linvfs_setattr+0x121/0x1db [] notify_change+0x150/0x182 [] do_truncate+0x4b/0x62 [] permission+0x35/0x37 [] may_open+0x165/0x1b6 [] filp_open+0x43/0x69 [] sys_open+0x5b/0x8b [] syscall_call+0x7/0xb #v- I also attached my .config file. Or perhaps I am thinking wrong, and the problem is not related to XFS at all? Best regards, -- Karol 'sziwan' Kozimor sziwan@hell.org.pl --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: attachment; filename=".config" # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_MMU=y CONFIG_SWAP=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # General setup # CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_LOG_BUF_SHIFT=14 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set CONFIG_MPENTIUM4=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MELAN is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_PREFETCH=y CONFIG_X86_SSE2=y # CONFIG_HUGETLB_PAGE is not set # CONFIG_SMP is not set # CONFIG_PREEMPT is not set # CONFIG_X86_UP_APIC is not set CONFIG_X86_MCE=y # CONFIG_X86_MCE_NONFATAL is not set # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_EDD=y CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # # Power management options (ACPI, APM) # CONFIG_PM=y CONFIG_SOFTWARE_SUSPEND=y # # ACPI Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y CONFIG_ACPI_AC=y CONFIG_ACPI_BATTERY=y CONFIG_ACPI_BUTTON=y CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_TOSHIBA is not set CONFIG_ACPI_DEBUG=y CONFIG_ACPI_BUS=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y # CONFIG_APM is not set CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_PROC_INTF=y # CONFIG_CPU_FREQ_24_API is not set CONFIG_X86_ACPI_CPUFREQ=y # CONFIG_X86_POWERNOW_K6 is not set # CONFIG_X86_POWERNOW_K7 is not set # CONFIG_X86_LONGHAUL is not set CONFIG_X86_SPEEDSTEP=m CONFIG_X86_P4_CLOCKMOD=m # CONFIG_X86_LONGRUN is not set # CONFIG_X86_GX_SUSPMOD is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y # CONFIG_SCx200 is not set CONFIG_PCI_LEGACY_PROC=y CONFIG_PCI_NAMES=y # CONFIG_ISA is not set # CONFIG_MCA is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # CONFIG_PCMCIA=m CONFIG_CARDBUS=y # CONFIG_I82092 is not set # CONFIG_I82365 is not set # CONFIG_TCIC is not set # # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set # # Executable file formats # CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_PC_CML1=m # CONFIG_PARPORT_SERIAL is not set CONFIG_PARPORT_PC_FIFO=y # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_PC_PCMCIA is not set # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play support # CONFIG_PNP=y CONFIG_PNP_NAMES=y # CONFIG_PNP_CARD is not set # CONFIG_PNP_DEBUG is not set # # Protocols # # CONFIG_PNPBIOS is not set # # Block devices # CONFIG_BLK_DEV_FD=m # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set CONFIG_BLK_DEV_LOOP=m # CONFIG_BLK_DEV_NBD is not set CONFIG_BLK_DEV_RAM=m CONFIG_BLK_DEV_RAM_SIZE=4096 # CONFIG_LBD is not set # # ATA/ATAPI/MFM/RLL device support # CONFIG_IDE=y # # IDE, ATA and ATAPI Block devices # CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_HD_IDE is not set # CONFIG_BLK_DEV_HD is not set CONFIG_BLK_DEV_IDEDISK=y # CONFIG_IDEDISK_MULTI_MODE is not set # CONFIG_IDEDISK_STROKE is not set # CONFIG_BLK_DEV_IDECS is not set CONFIG_BLK_DEV_IDECD=m # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set # CONFIG_IDE_TASK_IOCTL is not set # # IDE chipset support/bugfixes # # CONFIG_BLK_DEV_CMD640 is not set CONFIG_BLK_DEV_IDEPCI=y CONFIG_BLK_DEV_GENERIC=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_IDE_TCQ is not set # CONFIG_BLK_DEV_OFFBOARD is not set # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_PCI_WIP is not set CONFIG_BLK_DEV_ADMA=y # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_BLK_DEV_AMD74XX is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_TRIFLEX is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5520 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_BLK_DEV_HPT366 is not set # CONFIG_BLK_DEV_SC1200 is not set CONFIG_BLK_DEV_PIIX=y # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_PDC202XX_OLD is not set # CONFIG_BLK_DEV_PDC202XX_NEW is not set # CONFIG_BLK_DEV_RZ1000 is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIIMAGE is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set # CONFIG_BLK_DEV_VIA82CXXX is not set CONFIG_IDEDMA_AUTO=y # CONFIG_IDEDMA_IVB is not set CONFIG_BLK_DEV_IDE_MODES=y # # SCSI device support # CONFIG_SCSI=m # # SCSI support type (disk, tape, CD-ROM) # # CONFIG_BLK_DEV_SD is not set # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=m CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_CHR_DEV_SG=m # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_MULTI_LUN is not set # CONFIG_SCSI_REPORT_LUNS is not set # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # # SCSI low-level drivers # # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AACRAID is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_AIC79XX is not set # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_IN2000 is not set # CONFIG_SCSI_AM53C974 is not set # CONFIG_SCSI_MEGARAID is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_CPQFCTS is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_EATA_DMA is not set # CONFIG_SCSI_EATA_PIO is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_GENERIC_NCR5380 is not set # CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_PPA is not set # CONFIG_SCSI_IMM is not set # CONFIG_SCSI_NCR53C7xx is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_NCR53C8XX is not set # CONFIG_SCSI_SYM53C8XX is not set # CONFIG_SCSI_PCI2000 is not set # CONFIG_SCSI_PCI2220I is not set # CONFIG_SCSI_QLOGIC_ISP is not set # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_U14_34F is not set # CONFIG_SCSI_NSP32 is not set # CONFIG_SCSI_DEBUG is not set # # PCMCIA SCSI adapter support # # CONFIG_SCSI_PCMCIA is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # # Fusion MPT device support # # # IEEE 1394 (FireWire) support (EXPERIMENTAL) # CONFIG_IEEE1394=m # # Subsystem Options # # CONFIG_IEEE1394_VERBOSEDEBUG is not set # CONFIG_IEEE1394_OUI_DB is not set # # Device Drivers # # # Texas Instruments PCILynx requires I2C bit-banging # CONFIG_IEEE1394_OHCI1394=m # # Protocol Drivers # # CONFIG_IEEE1394_VIDEO1394 is not set # CONFIG_IEEE1394_SBP2 is not set # CONFIG_IEEE1394_ETH1394 is not set # CONFIG_IEEE1394_DV1394 is not set # CONFIG_IEEE1394_RAWIO is not set # CONFIG_IEEE1394_CMP is not set # # I2O device support # # CONFIG_I2O is not set # # Networking support # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y # CONFIG_NETLINK_DEV is not set # CONFIG_NETFILTER is not set # CONFIG_FILTER is not set CONFIG_UNIX=y # CONFIG_NET_KEY is not set CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_ARPD is not set # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set # CONFIG_INET_AH is not set # CONFIG_INET_ESP is not set # CONFIG_XFRM_USER is not set # CONFIG_IPV6 is not set # # SCTP Configuration (EXPERIMENTAL) # CONFIG_IPV6_SCTP__=y # CONFIG_IP_SCTP is not set # CONFIG_ATM is not set # CONFIG_VLAN_8021Q is not set # CONFIG_LLC is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Network testing # # CONFIG_NET_PKTGEN is not set CONFIG_NETDEVICES=y # # ARCnet devices # # CONFIG_ARCNET is not set CONFIG_DUMMY=m # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # CONFIG_ETHERTAP is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y # CONFIG_MII is not set # CONFIG_HAPPYMEAL is not set # CONFIG_SUNGEM is not set # CONFIG_NET_VENDOR_3COM is not set # # Tulip family network device support # # CONFIG_NET_TULIP is not set # CONFIG_HP100 is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_AMD8111_ETH is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_B44 is not set # CONFIG_DGRS is not set # CONFIG_EEPRO100 is not set # CONFIG_E100 is not set # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_8139CP is not set CONFIG_8139TOO=m CONFIG_8139TOO_PIO=y # CONFIG_8139TOO_TUNE_TWISTER is not set # CONFIG_8139TOO_8129 is not set # CONFIG_8139_OLD_RX_RESET is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_E1000 is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_R8169 is not set # CONFIG_SK98LIN is not set # CONFIG_TIGON3 is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PLIP is not set CONFIG_PPP=m # CONFIG_PPP_MULTILINK is not set CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m # CONFIG_PPPOE is not set # CONFIG_SLIP is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Token Ring devices (depends on LLC=y) # # CONFIG_NET_FC is not set # CONFIG_RCPCI is not set # CONFIG_SHAPER is not set # # Wan interfaces # # CONFIG_WAN is not set # # PCMCIA network device support # # CONFIG_NET_PCMCIA is not set # # Amateur Radio support # # CONFIG_HAMRADIO is not set # # IrDA (infrared) support # CONFIG_IRDA=m # # IrDA protocols # # CONFIG_IRLAN is not set # CONFIG_IRNET is not set CONFIG_IRCOMM=m # CONFIG_IRDA_ULTRA is not set # # IrDA options # CONFIG_IRDA_CACHE_LAST_LSAP=y CONFIG_IRDA_FAST_RR=y CONFIG_IRDA_DEBUG=y # # Infrared-port device drivers # # # SIR device drivers # CONFIG_IRTTY_SIR=m # # Dongle support # # CONFIG_DONGLE is not set # # Old SIR device drivers # # CONFIG_IRTTY_OLD is not set # CONFIG_IRPORT_SIR is not set # # Old Serial dongle support # # CONFIG_DONGLE_OLD is not set # # FIR device drivers # # CONFIG_USB_IRDA is not set # CONFIG_NSC_FIR is not set # CONFIG_WINBOND_FIR is not set # CONFIG_TOSHIBA_OLD is not set # CONFIG_TOSHIBA_FIR is not set # CONFIG_SMC_IRCC_FIR is not set # CONFIG_ALI_FIR is not set # CONFIG_VLSI_FIR is not set # # ISDN subsystem # # CONFIG_ISDN_BOOL is not set # # Telephony Support # # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_TSDEV is not set # CONFIG_INPUT_EVDEV is not set # CONFIG_INPUT_EVBUG is not set # # Input I/O drivers # # CONFIG_GAMEPORT is not set CONFIG_SOUND_GAMEPORT=y CONFIG_SERIO=y CONFIG_SERIO_I8042=y # CONFIG_SERIO_SERPORT is not set # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PARKBD is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=m # CONFIG_MOUSE_SERIAL is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TOUCHSCREEN is not set # CONFIG_INPUT_MISC is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # CONFIG_SERIAL_8250=m # CONFIG_SERIAL_8250_CS is not set # CONFIG_SERIAL_8250_EXTENDED is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=m CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 CONFIG_PRINTER=m # CONFIG_LP_CONSOLE is not set # CONFIG_PPDEV is not set # CONFIG_TIPAR is not set # # I2C support # # CONFIG_I2C is not set # # I2C Hardware Sensors Mainboard support # # # I2C Hardware Sensors Chip support # # # Mice # # CONFIG_BUSMOUSE is not set # CONFIG_QIC02_TAPE is not set # # IPMI # # CONFIG_IPMI_HANDLER is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set # CONFIG_INTEL_RNG is not set # CONFIG_AMD_RNG is not set # CONFIG_NVRAM is not set CONFIG_RTC=y # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set CONFIG_AGP=m # CONFIG_AGP3 is not set CONFIG_AGP_INTEL=m # CONFIG_AGP_VIA is not set # CONFIG_AGP_AMD is not set # CONFIG_AGP_SIS is not set # CONFIG_AGP_ALI is not set # CONFIG_AGP_SWORKS is not set # CONFIG_AGP_AMD_8151 is not set CONFIG_DRM=y # CONFIG_DRM_TDFX is not set # CONFIG_DRM_R128 is not set CONFIG_DRM_RADEON=m # CONFIG_DRM_I810 is not set # CONFIG_DRM_I830 is not set # CONFIG_DRM_MGA is not set # # PCMCIA character devices # # CONFIG_SYNCLINK_CS is not set # CONFIG_MWAVE is not set # CONFIG_RAW_DRIVER is not set # CONFIG_HANGCHECK_TIMER is not set # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # # File systems # # CONFIG_QUOTA is not set # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set # CONFIG_REISERFS_FS is not set # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set CONFIG_EXT3_FS=m CONFIG_EXT3_FS_XATTR=y # CONFIG_EXT3_FS_POSIX_ACL is not set CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set CONFIG_FAT_FS=m # CONFIG_MSDOS_FS is not set CONFIG_VFAT_FS=m # CONFIG_EFS_FS is not set # CONFIG_CRAMFS is not set CONFIG_TMPFS=y CONFIG_RAMFS=y CONFIG_ISO9660_FS=m CONFIG_JOLIET=y # CONFIG_ZISOFS is not set # CONFIG_JFS_FS is not set # CONFIG_MINIX_FS is not set # CONFIG_VXFS_FS is not set # CONFIG_NTFS_FS is not set # CONFIG_HPFS_FS is not set CONFIG_PROC_FS=y CONFIG_DEVFS_FS=y CONFIG_DEVFS_MOUNT=y # CONFIG_DEVFS_DEBUG is not set CONFIG_DEVPTS_FS=y # CONFIG_QNX4FS_FS is not set # CONFIG_ROMFS_FS is not set CONFIG_EXT2_FS=m CONFIG_EXT2_FS_XATTR=y # CONFIG_EXT2_FS_POSIX_ACL is not set # CONFIG_SYSV_FS is not set CONFIG_UDF_FS=m # CONFIG_UFS_FS is not set CONFIG_XFS_FS=y # CONFIG_XFS_RT is not set # CONFIG_XFS_QUOTA is not set # CONFIG_XFS_POSIX_ACL is not set # # Network File Systems # # CONFIG_CODA_FS is not set # CONFIG_INTERMEZZO_FS is not set # CONFIG_NFS_FS is not set # CONFIG_NFSD is not set # CONFIG_EXPORTFS is not set # CONFIG_CIFS is not set # CONFIG_SMB_FS is not set # CONFIG_NCP_FS is not set # CONFIG_AFS_FS is not set CONFIG_FS_MBCACHE=m # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y CONFIG_NLS=y # # Native Language Support # CONFIG_NLS_DEFAULT="iso8859-2" # CONFIG_NLS_CODEPAGE_437 is not set # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set # CONFIG_NLS_ISO8859_1 is not set CONFIG_NLS_ISO8859_2=y # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set # CONFIG_NLS_UTF8 is not set # # Graphics support # CONFIG_FB=y # CONFIG_FB_CLGEN is not set # CONFIG_FB_PM2 is not set # CONFIG_FB_CYBER2000 is not set # CONFIG_FB_IMSTT is not set # CONFIG_FB_VGA16 is not set # CONFIG_FB_VESA is not set CONFIG_VIDEO_SELECT=y # CONFIG_FB_HGA is not set # CONFIG_FB_RIVA is not set # CONFIG_FB_I810 is not set # CONFIG_FB_MATROX is not set CONFIG_FB_RADEON=m # CONFIG_FB_ATY128 is not set # CONFIG_FB_ATY is not set # CONFIG_FB_SIS is not set # CONFIG_FB_NEOMAGIC is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set # CONFIG_FB_TRIDENT is not set # CONFIG_FB_PM3 is not set # CONFIG_FB_VIRTUAL is not set # # Console display driver support # CONFIG_VGA_CONSOLE=y # CONFIG_MDA_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_PCI_CONSOLE=y # CONFIG_FBCON_ADVANCED is not set # CONFIG_FONTS is not set CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y # # Sound # CONFIG_SOUND=m # # Advanced Linux Sound Architecture # CONFIG_SND=m CONFIG_SND_SEQUENCER=m # CONFIG_SND_SEQ_DUMMY is not set CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_SEQUENCER_OSS=y # CONFIG_SND_RTCTIMER is not set # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set # # Generic devices # # CONFIG_SND_DUMMY is not set # CONFIG_SND_VIRMIDI is not set # CONFIG_SND_MTPAV is not set # CONFIG_SND_SERIAL_U16550 is not set # CONFIG_SND_MPU401 is not set # # PCI devices # # CONFIG_SND_ALI5451 is not set # CONFIG_SND_CS46XX is not set # CONFIG_SND_CS4281 is not set # CONFIG_SND_EMU10K1 is not set # CONFIG_SND_KORG1212 is not set # CONFIG_SND_NM256 is not set # CONFIG_SND_RME32 is not set # CONFIG_SND_RME96 is not set # CONFIG_SND_RME9652 is not set # CONFIG_SND_HDSP is not set # CONFIG_SND_TRIDENT is not set # CONFIG_SND_YMFPCI is not set # CONFIG_SND_ALS4000 is not set # CONFIG_SND_CMIPCI is not set # CONFIG_SND_ENS1370 is not set # CONFIG_SND_ENS1371 is not set # CONFIG_SND_ES1938 is not set # CONFIG_SND_ES1968 is not set # CONFIG_SND_MAESTRO3 is not set # CONFIG_SND_FM801 is not set # CONFIG_SND_ICE1712 is not set CONFIG_SND_INTEL8X0=m # CONFIG_SND_SONICVIBES is not set # CONFIG_SND_VIA82XX is not set # # ALSA USB devices # # CONFIG_SND_USB_AUDIO is not set # # Open Sound System # # CONFIG_SOUND_PRIME is not set # # USB support # CONFIG_USB=m # CONFIG_USB_DEBUG is not set # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y # CONFIG_USB_BANDWIDTH is not set # CONFIG_USB_DYNAMIC_MINORS is not set # # USB Host Controller Drivers # # CONFIG_USB_EHCI_HCD is not set # CONFIG_USB_OHCI_HCD is not set CONFIG_USB_UHCI_HCD=m # # USB Device Class drivers # # CONFIG_USB_AUDIO is not set # CONFIG_USB_BLUETOOTH_TTY is not set # CONFIG_USB_MIDI is not set # CONFIG_USB_ACM is not set # CONFIG_USB_PRINTER is not set # CONFIG_USB_STORAGE is not set # # USB Human Interface Devices (HID) # CONFIG_USB_HID=m CONFIG_USB_HIDINPUT=y # CONFIG_HID_FF is not set # CONFIG_USB_HIDDEV is not set # # USB HID Boot Protocol drivers # # CONFIG_USB_KBD is not set # CONFIG_USB_MOUSE is not set # CONFIG_USB_AIPTEK is not set # CONFIG_USB_WACOM is not set # CONFIG_USB_POWERMATE is not set # CONFIG_USB_XPAD is not set # # USB Imaging devices # # CONFIG_USB_MDC800 is not set # CONFIG_USB_SCANNER is not set # CONFIG_USB_MICROTEK is not set # CONFIG_USB_HPUSBSCSI is not set # # USB Multimedia devices # # CONFIG_USB_DABUSB is not set # # Video4Linux support is needed for USB Multimedia device support # # # USB Network adaptors # # CONFIG_USB_CATC is not set # CONFIG_USB_CDCETHER is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 is not set # CONFIG_USB_USBNET is not set # # USB port drivers # # CONFIG_USB_USS720 is not set # # USB Serial Converter support # # CONFIG_USB_SERIAL is not set # # USB Miscellaneous drivers # # CONFIG_USB_TIGL is not set # CONFIG_USB_AUERSWALD is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_BRLVGER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_TEST is not set # # Bluetooth support # # CONFIG_BT is not set # # Profiling support # # CONFIG_PROFILING is not set # # Kernel hacking # CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_DEBUG_SLAB is not set # CONFIG_DEBUG_IOVIRT is not set CONFIG_MAGIC_SYSRQ=y # CONFIG_DEBUG_SPINLOCK is not set CONFIG_KALLSYMS=y # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_FRAME_POINTER is not set # # Security options # # CONFIG_SECURITY is not set # # Cryptographic options # # CONFIG_CRYPTO is not set # # Library routines # # CONFIG_CRC32 is not set CONFIG_ZLIB_INFLATE=m CONFIG_ZLIB_DEFLATE=m CONFIG_X86_BIOS_REBOOT=y --CE+1k2dSO48ffgeK-- From owner-linux-xfs@oss.sgi.com Sun Feb 23 12:48:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 23 Feb 2003 12:48:23 -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 h1NKmH3v003710 for ; Sun, 23 Feb 2003 12:48:18 -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 h1NKvDoT015140; Sun, 23 Feb 2003 12:57:13 -0800 From: "l.a walsh" To: "'Russell G. Howe'" , Subject: RE: xfs_repair unable to repair a corrupt filesystem Date: Sun, 23 Feb 2003 12:57:13 -0800 Message-ID: <000501c2db7e$240eff00$1403a8c0@sc.tlinx.org> 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.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20030223081255.GA14077@lithium.sta.man.ac.uk> X-archive-position: 2864 X-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: 1943 Lines: 57 Seems that xfs_repair isn't very robust -- it doesn't even detect the problem on my disk that causes xfsdump to knock my rootfs offline. :-( -l > -----Original Message----- > From: linux-xfs-bounce@oss.sgi.com > [mailto:linux-xfs-bounce@oss.sgi.com] On Behalf Of Russell G. Howe > Sent: February 23, 2003 12:13a > To: linux-xfs@oss.sgi.com > Subject: xfs_repair unable to repair a corrupt filesystem > > > Hi, > > I'm having some problems with /var on my machine. The machine > itself is > rather unstable and hangs every few days, but I don't think that is > XFS-related. > > What does concern XFS is the data corruption I experience after such a > hard lockup (Alt+SysRq+B won't reboot the box, no HDD activity, etc). > /var has had at least some corruption for the past week or so which I > haven't had chance to fix. I took the opportunity just now after the > latest hang (which has hosed /home). I'll post a seperate > message about > the /home problem singe it seems to be a seperate issue. > > xfs_repair on /var appeared to fix at least some things, but > there were > clearly still errors. I re-ran xfs_repair and got this output: > http://rhowe.sfarc.net/xfs_repair_var.txt.gz The output appears identical no matter how many times I run xfs_repair. I'm using XFS from CVS, sometime around the 19th Dec (that is the date of compilation, and I update just before I compile). It's based on 2.4.20. Is this too old to be of use as a bug report? I am able and willing to build a more up to date release of XFS if need be. xfs_repair is from the Debian (unstable) package, and reports its version as 2.3.11 I can mount /var, but all those xfs_repair errors make me rather suspicious about using it. Most errors appear to be centred around one large (700Mbish) file, which I don't mind losing. -- Russell Howe | Why be just another cog in the machine, rhowe@wiss.co.uk | when you can be the spanner in the works? From owner-linux-xfs@oss.sgi.com Sun Feb 23 13:25:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 23 Feb 2003 13:25:18 -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 h1NLPF3v004467 for ; Sun, 23 Feb 2003 13:25:16 -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 h1NLYBG8025932 for ; Sun, 23 Feb 2003 13:34: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 PAA80749; Sun, 23 Feb 2003 15:34:11 -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 PAA36138; Sun, 23 Feb 2003 15:34:11 -0600 (CST) Date: Sun, 23 Feb 2003 15:32:05 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: "Russell G. Howe" cc: linux-xfs@oss.sgi.com Subject: Re: xfs_repair unable to repair a corrupt filesystem In-Reply-To: <20030223081255.GA14077@lithium.sta.man.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2865 X-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: 580 Lines: 18 On Sun, 23 Feb 2003, Russell G. Howe wrote: > xfs_repair on /var appeared to fix at least some things, but there were > clearly still errors. I re-ran xfs_repair and got this output: > > http://rhowe.sfarc.net/xfs_repair_var.txt.gz > > The output appears identical no matter how many times I run xfs_repair. Russell - try renaming the lost+found/ dir before you re-run repair. Otherswise, it will unlink it and then re-find all those "lost" inodes. I don't think this is the root of the problem (the 990 error is suspicious) but start with that and see what happens. -Eric From owner-linux-xfs@oss.sgi.com Sun Feb 23 13:28:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 23 Feb 2003 13:28:18 -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 h1NLSG3v004916 for ; Sun, 23 Feb 2003 13:28:16 -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 h1NLbCG8026304 for ; Sun, 23 Feb 2003 13:37: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 PAA90728; Sun, 23 Feb 2003 15:37:11 -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 PAA72556; Sun, 23 Feb 2003 15:37:11 -0600 (CST) Date: Sun, 23 Feb 2003 15:35:06 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com 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: <001c01c2d7d9$adaa7620$1403a8c0@sc.tlinx.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2866 X-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: 426 Lines: 16 Linda - I'm sorry, I'm not following this very well. What exactly did you try to do, and what happened? And what errors were reported both on the console and in the logs? -Eric On Tue, 18 Feb 2003, l.a walsh wrote: > 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... From owner-linux-xfs@oss.sgi.com Sun Feb 23 13:54:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 23 Feb 2003 13:54:08 -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 h1NLs03v005533 for ; Sun, 23 Feb 2003 13:54:02 -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 h1NM2tKp026196 for ; Sun, 23 Feb 2003 14:02:56 -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 JAA26434; Mon, 24 Feb 2003 09:01:39 +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 JAA00088; Mon, 24 Feb 2003 09:01:38 +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 h1NLxWLY000891; Mon, 24 Feb 2003 08:59:32 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h1NLxVnv000889; Mon, 24 Feb 2003 08:59:31 +1100 Date: Mon, 24 Feb 2003 08:59:31 +1100 From: Nathan Scott To: "Russell G. Howe" Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_repair unable to repair a corrupt filesystem Message-ID: <20030223215931.GA798@frodo> References: <20030223081255.GA14077@lithium.sta.man.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030223081255.GA14077@lithium.sta.man.ac.uk> User-Agent: Mutt/1.5.3i X-archive-position: 2867 X-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: 2035 Lines: 56 On Sun, Feb 23, 2003 at 08:12:55AM +0000, Russell G. Howe wrote: > Hi, > > I'm having some problems with /var on my machine. The machine itself is > rather unstable and hangs every few days, but I don't think that is > XFS-related. > ... > I'm using XFS from CVS, sometime around the 19th Dec (that is the date > of compilation, and I update just before I compile). It's based on There was an XFS problem in syncing when remounting read-only (which happens just before reboot), which was fixed earlier this year - it frequently affected /var because that is always very active during shutdown - this fix might help you if you upgrade. > xfs_repair on /var appeared to fix at least some things, but there were > clearly still errors. I re-ran xfs_repair and got this output: > > http://rhowe.sfarc.net/xfs_repair_var.txt.gz ... correcting nblocks for inode 2222, was 0 - counted 189764 ... correcting nblocks for inode 6296608, was 0 - counted 189764 ... Phase 7 - verify and correct link counts... corrupt dinode 2222, extent total = 2, nblocks = 0. Unmount and run xfs_repair.fatal error -- couldn't map inode 2222, err = 990 Basically, the reason you're getting this error is because somehow those two earlier statements (correcting nblocks) have become undone, somehow, by a later stage of repair; when phase7 comes along and expects this to be fixed, it ain't, so it coughs up a lung. Inodes 2222 and 6296608 are two unhappy looking files - can you send me the output of: # xfs_db -c 'inode 2222' -c p /dev/XXX You may find that forcing the nblocks value to be 189764 for these inodes gets xfs_repair past this hurdle (I can't see how it is getting "unfixed" though - some experiments on my machine suggest xfs_repair handles this case as I would expect). To force the block count for these inodes, do something like (fs must be unmounted): # xfs_db -x -c 'inode 2222' -c 'write core.nblocks 189764' /dev/XXX (repeat for inode 6296608) and then run repair again, to see if that's helped at all. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Feb 23 19:24:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 23 Feb 2003 19:24:21 -0800 (PST) Received: from gannet.scg.man.ac.uk (gannet.scg.man.ac.uk [130.88.94.110]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1O3OB3v010883 for ; Sun, 23 Feb 2003 19:24:13 -0800 Received: from lithium.sta.man.ac.uk ([130.88.188.32] helo=doufu ident=mail) by gannet.scg.man.ac.uk with esmtp (Exim 2.05 #6) id 18n9Mc-000IIN-00; Mon, 24 Feb 2003 03:33:10 +0000 Received: from rhowe by doufu with local (Exim 3.36 #1 (Debian)) id 18n9Mb-0005Gx-00; Mon, 24 Feb 2003 03:33:09 +0000 Date: Mon, 24 Feb 2003 03:33:09 +0000 To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_repair unable to repair a corrupt filesystem Message-ID: <20030224033309.GA20260@lithium.sta.man.ac.uk> References: <20030223081255.GA14077@lithium.sta.man.ac.uk> <20030223215931.GA798@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030223215931.GA798@frodo> User-Agent: Mutt/1.4i From: "Russell G. Howe" X-archive-position: 2868 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rhowe@wiss.co.uk Precedence: bulk X-list: linux-xfs Content-Length: 1832 Lines: 50 On Mon, Feb 24, 2003 at 08:59:31AM +1100, Nathan Scott wrote: > There was an XFS problem in syncing when remounting read-only > (which happens just before reboot), which was fixed earlier this > year - it frequently affected /var because that is always very > active during shutdown - this fix might help you if you upgrade. Hm, I didn't realise all filesystems were remounted ro, I thought all but / were unmounted and then only / was remounted ro. Oh well you learn something new every day! > > xfs_repair on /var appeared to fix at least some things, but there were > > clearly still errors. I re-ran xfs_repair and got this output: > > > > http://rhowe.sfarc.net/xfs_repair_var.txt.gz > > ... > correcting nblocks for inode 2222, was 0 - counted 189764 > ... > correcting nblocks for inode 6296608, was 0 - counted 189764 > ... > Phase 7 - verify and correct link counts... > corrupt dinode 2222, extent total = 2, nblocks = 0. Unmount and run xfs_repair.fatal error -- couldn't map inode 2222, err = 990 > > [snip] > > Inodes 2222 and 6296608 are two unhappy looking files - > can you send me the output of: > > # xfs_db -c 'inode 2222' -c p /dev/XXX See http://rhowe.sfarc.net/xfs_db_inode_2222.txt > To force the block count for these inodes, > do something like (fs must be unmounted): > > # xfs_db -x -c 'inode 2222' -c 'write core.nblocks 189764' /dev/XXX > (repeat for inode 6296608) I'm assuming doing this will alter the structure of the inode, as seen in the previous URL so I'll hold off running this in case you spot something in the output above. I don't need the file referenced by inode 2222, so losing it is of no consequence. I'd actually forgotten about its existence! -- Russell Howe | Why be just another cog in the machine, rhowe@wiss.co.uk | when you can be the spanner in the works? From owner-linux-xfs@oss.sgi.com Sun Feb 23 19:30:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 23 Feb 2003 19:30:45 -0800 (PST) Received: from iris.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1O3Uf3v011348 for ; Sun, 23 Feb 2003 19:30:42 -0800 Received: from erbenson.alaska.net (27-pm5.nwc.alaska.net [209.112.139.27]) by iris.acsalaska.net (8.12.7/8.12.7) with ESMTP id h1O3dgiS099961 for ; Sun, 23 Feb 2003 18:39:43 -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 DAA3D3A09 for ; Sun, 23 Feb 2003 18:39:41 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id C71754104E2; Sun, 23 Feb 2003 18:39:41 -0900 (AKST) Date: Sun, 23 Feb 2003 18:39:41 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: xfs_repair unable to repair a corrupt filesystem Message-ID: <20030224033941.GI707@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20030223081255.GA14077@lithium.sta.man.ac.uk> <20030223215931.GA798@frodo> <20030224033309.GA20260@lithium.sta.man.ac.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tctmm6wHVGT/P6vA" Content-Disposition: inline In-Reply-To: <20030224033309.GA20260@lithium.sta.man.ac.uk> 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-ACS-Spam-Status: no X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 2869 X-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: 1182 Lines: 39 --tctmm6wHVGT/P6vA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 24, 2003 at 03:33:09AM +0000, Russell G. Howe wrote: > On Mon, Feb 24, 2003 at 08:59:31AM +1100, Nathan Scott wrote: >=20 > > There was an XFS problem in syncing when remounting read-only > > (which happens just before reboot), which was fixed earlier this > > year - it frequently affected /var because that is always very > > active during shutdown - this fix might help you if you upgrade. >=20 > Hm, I didn't realise all filesystems were remounted ro, I thought all > but / were unmounted and then only / was remounted ro. Oh well you learn they are. perhaps the readonly fix could also affect a plain umount as well.=20=20 --=20 Ethan Benson http://www.alaska.net/~erbenson/ --tctmm6wHVGT/P6vA 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 iEYEARECAAYFAj5Zk/0ACgkQJKx7GixEevx4QwCfbzCuQQzJTw4l0ce6QXFwhwGV PtsAnifrHAHcK5bga8ljLR60+AgLF3cu =n9iE -----END PGP SIGNATURE----- --tctmm6wHVGT/P6vA-- From owner-linux-xfs@oss.sgi.com Sun Feb 23 19:42:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 23 Feb 2003 19:42:46 -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 h1O3gh3v011845 for ; Sun, 23 Feb 2003 19:42:44 -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 h1O3peKp001575 for ; Sun, 23 Feb 2003 19:51:40 -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 OAA29254; Mon, 24 Feb 2003 14:50:24 +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 OAA57460; Mon, 24 Feb 2003 14:50:23 +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 h1O3mGLY001829; Mon, 24 Feb 2003 14:48:16 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h1O3mFKi001827; Mon, 24 Feb 2003 14:48:15 +1100 Date: Mon, 24 Feb 2003 14:48:15 +1100 From: Nathan Scott To: "Russell G. Howe" Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_repair unable to repair a corrupt filesystem Message-ID: <20030224034815.GC798@frodo> References: <20030223081255.GA14077@lithium.sta.man.ac.uk> <20030223215931.GA798@frodo> <20030224033309.GA20260@lithium.sta.man.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030224033309.GA20260@lithium.sta.man.ac.uk> User-Agent: Mutt/1.5.3i X-archive-position: 2870 X-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: 2499 Lines: 70 On Mon, Feb 24, 2003 at 03:33:09AM +0000, Russell G. Howe wrote: > On Mon, Feb 24, 2003 at 08:59:31AM +1100, Nathan Scott wrote: > > > There was an XFS problem in syncing when remounting read-only > > (which happens just before reboot), which was fixed earlier this > > year - it frequently affected /var because that is always very > > active during shutdown - this fix might help you if you upgrade. > > Hm, I didn't realise all filesystems were remounted ro, I thought all > but / were unmounted and then only / was remounted ro. Oh well you learn > something new every day! No, you were right - I should have read your original mail more carefully. > > > xfs_repair on /var appeared to fix at least some things, but there were > > > clearly still errors. I re-ran xfs_repair and got this output: > > > > > > http://rhowe.sfarc.net/xfs_repair_var.txt.gz > > > > ... > > correcting nblocks for inode 2222, was 0 - counted 189764 > > ... > > correcting nblocks for inode 6296608, was 0 - counted 189764 > > ... > > Phase 7 - verify and correct link counts... > > corrupt dinode 2222, extent total = 2, nblocks = 0. Unmount and run xfs_repair.fatal error -- couldn't map inode 2222, err = 990 > > > > [snip] > > > > Inodes 2222 and 6296608 are two unhappy looking files - > > can you send me the output of: > > > > # xfs_db -c 'inode 2222' -c p /dev/XXX > > See http://rhowe.sfarc.net/xfs_db_inode_2222.txt Thanks. Its as it seemed & repair is saying - the inode has an incorrect nblocks field for some reason. I will have to do some more experiments with repair on a file like this (i.e. this large, and split into two extents like this), my previous little experiment where repair worked was on a small file. > > To force the block count for these inodes, > > do something like (fs must be unmounted): > > > > # xfs_db -x -c 'inode 2222' -c 'write core.nblocks 189764' /dev/XXX > > (repeat for inode 6296608) > > I'm assuming doing this will alter the structure of the inode, as seen Yep. > in the previous URL so I'll hold off running this in case you spot > something in the output above. Go ahead and try the write - I'll try creating an inode like yours locally, and running repair over it. > I don't need the file referenced by inode 2222, so losing it is of no > consequence. I'd actually forgotten about its existence! Is inode 6296608 a copy of this file? (seem to have the same size and both seem to be corrupted in the same way ...strange). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Feb 23 20:30:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 23 Feb 2003 20:30:40 -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 h1O4Ub3v013812 for ; Sun, 23 Feb 2003 20:30:37 -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 h1O4dVoT019885; Sun, 23 Feb 2003 20:39:31 -0800 From: "l.a walsh" To: "'Eric Sandeen'" Cc: Subject: RE: been a while before i could get back to this.. Date: Sun, 23 Feb 2003 20:39:31 -0800 Message-ID: <00c301c2dbbe$b929aaa0$1403a8c0@sc.tlinx.org> 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.4510 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-archive-position: 2871 X-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: 1991 Lines: 49 > > I'm sorry, I'm not following this very well. What exactly > did you try to do, > and what happened? And what errors were reported both on the console > and in the logs? --- xfsdump has been broken for me since last october. It still is with latest patch/kernel and utils: These are the local window messages when I tried to dump: + xfsdump -b 1048576 -m -l 0 -o -L root - / + su -f -m backup -c 'nice -19 bzip2 >root/root-030220-0-2201.dump.bz2' xfsdump: using file dump (drive_simple) strategy xfsdump: version 2.2.6 (dump format 3.0) - Running single-threaded xfsdump: level 0 dump of ishtar:/ xfsdump: dump date: Thu Feb 20 22:01:40 2003 xfsdump: session id: 1dfb2395-0d6c-4132-9ba0-0b41bc30c3c0 xfsdump: session label: "root" xfsdump: ino map phase 1: skipping (no subtrees specified) xfsdump: ino map phase 2: constructing initial dump list xfsdump: WARNING: failed to get bulkstat information for inode 1590 xfsdump: syssgi( SGI_FS_BULKSTAT ) on fsroot failed: Input/output error xfsdump: Dump Status: ERROR + read fs dev DUMP ./dumplin: line 19: read: read error: 0: Input/output error ishtar:root/bin# ls bash: /bin/ls: Input/output error ========= These are the log messages I saw in the remote syslog: Feb 21 00:12:03 ishtar kernel: xfs_inotobp: xfs_imap() returned an error 22 on sd(8,3). Returning error. Feb 21 00:12:03 ishtar kernel: xfs_iunlink_remove: xfs_inotobp() returned an error 22 on sd(8,3). Returning error. Feb 21 00:12:03 ishtar kernel: xfs_inactive: xfs_ifree() returned an error = 22 on sd(8,3) Feb 21 00:12:03 ishtar kernel: xfs_force_shutdown(sd(8,3),0x1) called from line 1835 of file xfs_vnodeops.c. Return address = 0xc0213dca Feb 21 00:12:03 ishtar kernel: Filesystem "sd(8,3)": I/O Error Detected. Shutting down filesystem: sd(8,3) Feb 21 00:12:03 ishtar kernel: Please umount the filesystem, and rectify the problem(s) ------ I like that last line -- since 'umount' is unavailable...:-/ Hopefully the log above gives some clues? From owner-linux-xfs@oss.sgi.com Sun Feb 23 21:22:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 23 Feb 2003 21:22:30 -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 h1O5MR3v015010 for ; Sun, 23 Feb 2003 21:22:28 -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 h1O5VOG8018160 for ; Sun, 23 Feb 2003 21:31:24 -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 QAA29910; Mon, 24 Feb 2003 16:30:08 +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 QAA99591; Mon, 24 Feb 2003 16:30:07 +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 h1O5S0LY002112; Mon, 24 Feb 2003 16:28:00 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h1O5RxIc002110; Mon, 24 Feb 2003 16:27:59 +1100 Date: Mon, 24 Feb 2003 16:27:59 +1100 From: Nathan Scott To: "Russell G. Howe" Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_repair unable to repair a corrupt filesystem Message-ID: <20030224052759.GD798@frodo> References: <20030223081255.GA14077@lithium.sta.man.ac.uk> <20030223215931.GA798@frodo> <20030224033309.GA20260@lithium.sta.man.ac.uk> <20030224034815.GC798@frodo> <20030224043829.GA20677@lithium.sta.man.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030224043829.GA20677@lithium.sta.man.ac.uk> User-Agent: Mutt/1.5.3i X-archive-position: 2872 X-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: 1914 Lines: 55 On Mon, Feb 24, 2003 at 04:38:29AM +0000, Russell G. Howe wrote: > On Mon, Feb 24, 2003 at 02:48:15PM +1100, Nathan Scott wrote: > > http://rhowe.sfarc.net/xfs_repair_after_nblocks_fiddle.txt.gz > > (and yes, I know xfs_repair says near the end that nblocks is 0, but > xfs_db definately reported setting it to 189764) > > As an example of how the filesystem behaves: > > [rhowe@gonzo] ~ $ > 5:31AM > Connection to gonzo.sfarc.net closed. > [root@xiao] ~ # cd /var > [root@xiao] /var # ls > [kernel message] > Filesystem "ide1(22,67)": corrupt dinode 2222, extent total = 2, nblocks > = 0, Unmount and run xfs_repair > [return to our regularly scheduled prompt] > ls: Scarface.avi: Unknown error 990 > account cache local log.nmbd mail run www > autofs games lock log.smbd oldlost+found spool > backups lib log lost+found rhowe tmp > [root@xiao] /var # ls rhowe > ls: rhowe/Scarface.avi: Unknown error 990 > (this is accompanied by a similar kernel error to the one above, but > with 6296608 as the dinode number.) > > I don't need the /var/rhowe directory at all, as soon as I can fix this > filesystem, I will be rm'ing it. > > > > I don't need the file referenced by inode 2222, so losing it is of no > > > consequence. I'd actually forgotten about its existence! > > > > Is inode 6296608 a copy of this file? (seem to have the same size > > and both seem to be corrupted in the same way ...strange). > > No idea. How could I find out? Can you run the same (first) xfs_db command I sent to print out the inode, except change the 2222 to 6296608? I wonder if these two inodes are pointing at the same extents... > Maybe I was playing with hard links or > something? (although I don't remember doing so...) No, a hard link would be two distinct directory entries with the same inode number - not quite the same as what we have here. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Feb 23 22:43:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 23 Feb 2003 22:43:45 -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 h1O6hf3v029231 for ; Sun, 23 Feb 2003 22:43:42 -0800 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id D42DDAC40; Mon, 24 Feb 2003 08:02:58 +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 D0493190CB; Mon, 24 Feb 2003 08:02:59 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id EC0B830881D; Mon, 24 Feb 2003 07:52:32 +0100 (CET) Message-ID: <3E59C130.D5269FC3@ch.sauter-bc.com> Date: Mon, 24 Feb 2003 07:52:32 +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: Spyros Ioakim Cc: linux-xfs@oss.sgi.com Subject: Re: upgrade scenario for samba server References: <000501c2da99$38cb6360$8e1361c3@spyroshome> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2873 X-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: 1872 Lines: 48 Spyros Ioakim schrieb: > > I reboot the machine and install RH 8.0 using the xfs boot cd.I want your > comments on the size of the partitions here. > Right now I had everything under / cause I wanted a dynamic use of /home and > /samba. > 130GB to share between the two and redhat's files is much better for me than > having: > /home 50 GB > /samba 50 GB > / 30 GB > Since the filesystem is journalized I don't have problems with fsck in case > of power failure (very rare since the system is on a UPS) > Even if I need to run fsck it takes about 15 minutes which is a good time > (for me) so I don't see why i would break it down... > > So I'm thinking of having /boot 40MB ext3 and / 130 GB xfs. > The bootloader will go to the MBR so there shouldn't be any problems booting > (so I read....) Hi, Another way was to put samba under /home as /home/samba. That way you could make / a smaller partition and have the 130GB mounted on /home. You could then create /boot and / as ext3 and only /home as XFS. If you ever need to upgrade you distribution and there is no XFS installer available, you could just use the RedHat disks to upgrade. After upgrade, you install/recompile a XFS kernel and work goes on. I have never installed like that but will maybe do so in future until RedHat includes XFS. Simon > > After the system boots up with xfs I untar everything to /home and /samba. > I also take the necessary files from /etc (I don't restore this don't worry) > for the samba configuration, smbpasswd, passwd, shadow and whatever else I > might need. > > Any comments/ideas would be appreciated... > First of all will I get NT style permissions with samba or I'm just going to > get a system with XFS and no gain :-? > Is there anything special required for samba to use those acls? > > Thanks for reading the whole lot and waiting for comments :-) > > Spyros From owner-linux-xfs@oss.sgi.com Sun Feb 23 23:07:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 23 Feb 2003 23:07:09 -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 h1O7763v031072 for ; Sun, 23 Feb 2003 23:07:07 -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 h1O7G3G8000612 for ; Sun, 23 Feb 2003 23:16:04 -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 SAA00563; Mon, 24 Feb 2003 18:14:47 +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 SAA13699; Mon, 24 Feb 2003 18:14:46 +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 h1O7CdLY002425; Mon, 24 Feb 2003 18:12:39 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h1O7CbiT002423; Mon, 24 Feb 2003 18:12:37 +1100 Date: Mon, 24 Feb 2003 18:12:37 +1100 From: Nathan Scott To: "Russell G. Howe" Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_repair unable to repair a corrupt filesystem Message-ID: <20030224071237.GF798@frodo> References: <20030223081255.GA14077@lithium.sta.man.ac.uk> <20030223215931.GA798@frodo> <20030224033309.GA20260@lithium.sta.man.ac.uk> <20030224034815.GC798@frodo> <20030224043829.GA20677@lithium.sta.man.ac.uk> <20030224052759.GD798@frodo> <20030224055532.GA21046@lithium.sta.man.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030224055532.GA21046@lithium.sta.man.ac.uk> User-Agent: Mutt/1.5.3i X-archive-position: 2874 X-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: 756 Lines: 23 On Mon, Feb 24, 2003 at 05:55:32AM +0000, Russell G. Howe wrote: > On Mon, Feb 24, 2003 at 04:27:59PM +1100, Nathan Scott wrote: > > Can you run the same (first) xfs_db command I sent to print > > out the inode, except change the 2222 to 6296608? I wonder > > if these two inodes are pointing at the same extents... > > Sure thing: > > http://rhowe.sfarc.net/xfs_db_inode_6296608.txt > Taa. Hmmm, they look like distinct files, with completely disjoint extents (which is good). I'll still try to revisit this locally, but if you don't need to keep them, you should be able to blow these files away by writing zeroes into the nextents and size fields (in a similar way to the way you did nblocks overwrite earlier with xfs_db). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Feb 23 23:18:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 23 Feb 2003 23:18:48 -0800 (PST) Received: from atlas.ace-hellas.gr (atlas.ace-hellas.gr [195.97.19.130]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1O7Ih3v031958 for ; Sun, 23 Feb 2003 23:18:45 -0800 Received: from spyros (spyros.ace-internal.gr [192.168.2.4]) by atlas.ace-hellas.gr (8.11.6/linuxconf) with ESMTP id h1O7Rbt13400; Mon, 24 Feb 2003 09:27:39 +0200 From: "Spyros Ioakim" To: "'Simon Matter'" Cc: Subject: RE: upgrade scenario for samba server Date: Mon, 24 Feb 2003 09:27:36 +0200 Message-ID: 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.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-reply-to: X-archive-position: 2875 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sioakim@ace-hellas.gr Precedence: bulk X-list: linux-xfs Content-Length: 2723 Lines: 86 That is actually a very good idea... During the weekend I was looking at Mandrake 9.0 that has builtin support for XFS. How do you guys feel about Mandrake? Does it seem less professional than Redhat? As I said the server is just samba with a couple of NFS exports... Do you reckon that RH8 with a XFS enabled kernel is a more stable solution? If I go with RH8 I will go with your implementation Simon. As far as I seen the XFS project releases updated kernels soon after Redhat does so there shouldn't be any problems to keep up with all the latest redhat patches.... Thank all, Spyros -----Original Message----- From: linux-xfs-bounce@oss.sgi.com [mailto:linux-xfs-bounce@oss.sgi.com] On Behalf Of Simon Matter Sent: Monday, February 24, 2003 8:53 AM To: Ioakim Spyros Cc: linux-xfs@oss.sgi.com Subject: Re: upgrade scenario for samba server Spyros Ioakim schrieb: > > I reboot the machine and install RH 8.0 using the xfs boot cd.I want your > comments on the size of the partitions here. > Right now I had everything under / cause I wanted a dynamic use of /home and > /samba. > 130GB to share between the two and redhat's files is much better for me than > having: > /home 50 GB > /samba 50 GB > / 30 GB > Since the filesystem is journalized I don't have problems with fsck in case > of power failure (very rare since the system is on a UPS) > Even if I need to run fsck it takes about 15 minutes which is a good time > (for me) so I don't see why i would break it down... > > So I'm thinking of having /boot 40MB ext3 and / 130 GB xfs. > The bootloader will go to the MBR so there shouldn't be any problems booting > (so I read....) Hi, Another way was to put samba under /home as /home/samba. That way you could make / a smaller partition and have the 130GB mounted on /home. You could then create /boot and / as ext3 and only /home as XFS. If you ever need to upgrade you distribution and there is no XFS installer available, you could just use the RedHat disks to upgrade. After upgrade, you install/recompile a XFS kernel and work goes on. I have never installed like that but will maybe do so in future until RedHat includes XFS. Simon > > After the system boots up with xfs I untar everything to /home and /samba. > I also take the necessary files from /etc (I don't restore this don't worry) > for the samba configuration, smbpasswd, passwd, shadow and whatever else I > might need. > > Any comments/ideas would be appreciated... > First of all will I get NT style permissions with samba or I'm just going to > get a system with XFS and no gain :-? > Is there anything special required for samba to use those acls? > > Thanks for reading the whole lot and waiting for comments :-) > > Spyros From owner-linux-xfs@oss.sgi.com Mon Feb 24 00:20:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Feb 2003 00:20:47 -0800 (PST) Received: from mail.microwarehouse.com.ph (microwarehouse.com.ph [203.87.129.5] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1O8Kb3v001324 for ; Mon, 24 Feb 2003 00:20:41 -0800 Received: from mail.microwarehouse.com.ph (mail.intra.microwarehouse.com.ph [192.168.12.6]) by mail.microwarehouse.com.ph (8.11.6/8.11.2) with ESMTP id h1OGREe27062; Mon, 24 Feb 2003 16:27:14 GMT Received: from ([192.168.12.113]) by mail.microwarehouse.com.ph (MailMonitor for SMTP v1.2.1 ) ; Mon, 24 Feb 2003 16:27:14 +0000 (UTC) Message-ID: <000d01c2dc65$64ae5730$710ca8c0@jay> From: "Jay" To: , Subject: Help Date: Mon, 24 Feb 2003 16:32:33 -0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 2876 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jay@microwarehouse.com.ph Precedence: bulk X-list: linux-xfs Content-Length: 623 Lines: 27 We had a power a failure at the office after that I tried to reboot the machine which runs on 7.1 redhat linux when it boot up i keep on getting Hit CTRL D or input root password to repair files system Hoew cani able to repair the linux file sysytem what command should i carry. I really need your reply on this. Thaks. ================================== Jay Gonzales MIS Programmer Microwarehouse Inc. Tel : +63 (2) 637-0474 ext. 120 Fax :+63 (2) 636-3720 Mobile : +63 917-4920349 E-mail: jay@microwarehouse.com.ph www.microwarehouse.com.ph ================================== [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Mon Feb 24 01:28:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Feb 2003 01:28: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 h1O9SL3v004939 for ; Mon, 24 Feb 2003 01:28:21 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id E4A8A186B148; Mon, 24 Feb 2003 01:37:24 -0800 (PST) Date: Mon, 24 Feb 2003 01:37:24 -0800 From: Chris Wedgwood To: "l.a walsh" Cc: "'Eric Sandeen'" , linux-xfs@oss.sgi.com Subject: Re: been a while before i could get back to this.. Message-ID: <20030224093724.GA13363@f00f.org> References: <00c301c2dbbe$b929aaa0$1403a8c0@sc.tlinx.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00c301c2dbbe$b929aaa0$1403a8c0@sc.tlinx.org> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2877 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 330 Lines: 13 On Sun, Feb 23, 2003 at 08:39:31PM -0800, l.a walsh wrote: > xfsdump: WARNING: failed to get bulkstat information for inode 1590 > xfsdump: syssgi( SGI_FS_BULKSTAT ) on fsroot failed: Input/output error > xfsdump: Dump Status: ERROR have you tried xfs_repair on / yet? --cw p.s. your MUA send garbage charactaers at times From owner-linux-xfs@oss.sgi.com Mon Feb 24 02:14:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Feb 2003 02:14:28 -0800 (PST) Received: from hammail1.truenorth.com (h-213.61.138.102.host.de.colt.net [213.61.138.102]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1OAEH3v006426 for ; Mon, 24 Feb 2003 02:14:19 -0800 Received: from hamburg.fcb.com ([170.200.66.61]) by hammail1.truenorth.com (Netscape Messaging Server 4.15) with ESMTP id HAT6IF00.ENA; Mon, 24 Feb 2003 11:30:15 +0100 Date: Mon, 24 Feb 2003 11:23:15 +0100 Subject: Re: Problem using appletalk with MacOS X to a scsi hd with XFS. Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Harald Wagener To: linux-xfs@oss.sgi.com, netatalk-devel@lists.sourceforge.net Content-Transfer-Encoding: 7bit In-Reply-To: <20030221132758.GA8554@pc219.sam-solutions.net> Message-Id: X-Mailer: Apple Mail (2.551) X-archive-position: 2878 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hwagener@hamburg.fcb.com Precedence: bulk X-list: linux-xfs Content-Length: 1019 Lines: 36 Am Freitag, 21.02.03 um 14:27 Uhr schrieb Alexey Kotovich: > Hi there; > > I have the same experience some time ago. > I wrote a patch for netatalk-1.5.0/3 that can help you to workaround > problem. > If my memory doesn't fail me the issue is as follows (as short as > possible): > > AFP uses unique file number for internal needs which is two bytes of > length. > Netatalk does something like this ((st->st_dev << 16) | (st->st_ino & > 0x0000ffff)) > to get such a number. I'd like to mention that it must be unique per > request only. > As xfs has 64bits inode number and it has inconsequent order, > sometimes we get > the same file numbers in the same request that causes "error -50" on > MacOS. > > kind regards, > Alexey Kotovich ICQ:97715595 Is this still true with cnid (netatalk 1.6.0)? Or does cnid decouple did from file inode information? If no, could it be made into doing so? Regards, Harald -- Harald Wagener * FCB/Wilkens * An der Alster 42 * 20099 Hamburg From owner-linux-xfs@oss.sgi.com Mon Feb 24 03:30:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Feb 2003 03:30:56 -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 h1OBUk3v010145 for ; Mon, 24 Feb 2003 03:30:47 -0800 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id h1OBdAUQ096150; Mon, 24 Feb 2003 12:39:16 +0100 (CET) Message-Id: <4.3.2.7.2.20030224115849.04902560@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Feb 2003 12:39:04 +0100 To: "Jay" , , From: Seth Mos Subject: Re: Help In-Reply-To: <000d01c2dc65$64ae5730$710ca8c0@jay> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2879 X-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: 839 Lines: 25 At 16:32 24-2-2003 -0800, Jay wrote: >We had a power a failure at the office >after that I tried to reboot the machine >which runs on 7.1 redhat linux when it boot up >i keep on getting >Hit CTRL D or input root password to repair files system Enter the root password and check with the mount command which filesystems are mounted and check which one you are missing. type dmesg to see what the kernel had to say about the unmountable filesystem. >Hoew cani able to repair the linux file sysytem what command should i carry. xfs_repair is what you need to repair your filesystem. Does this system have a IDE disk? If it does you will need to make certain that write caching is turned off using hdparm. This is often a cause of failure and filesystem corruption. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Mon Feb 24 04:39:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Feb 2003 04:39:36 -0800 (PST) Received: from down.physik.fu-berlin.de (down.physik.fu-berlin.de [160.45.34.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1OCdU3v014021 for ; Mon, 24 Feb 2003 04:39:31 -0800 Received: (from thimm@localhost) by down.physik.fu-berlin.de (8.9.3/8.9.1) id NAA1153175 for linux-xfs@oss.sgi.com; Mon, 24 Feb 2003 13:48:33 +0100 (CET) Resent-Message-Id: <200302241248.NAA1153175@down.physik.fu-berlin.de> Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by down.physik.fu-berlin.de (8.9.3/8.9.1) with ESMTP id JAA1129319 for ; Mon, 24 Feb 2003 09:24:02 +0100 (CET) Received: from fwd02.sul.t-online.de by mailout01.sul.t-online.com with smtp id 18nDu4-0000ul-00; Mon, 24 Feb 2003 09:24:00 +0100 Received: from puariko.homeip.net (520039812576-0001@[217.231.243.119]) by fmrl02.sul.t-online.com with esmtp id 18nDtx-0h8TfkC; Mon, 24 Feb 2003 09:23:53 +0100 Received: (from thimm@localhost) by puariko.nirvana (8.12.5/8.12.5/Submit) id h1O8NmIM013767; Mon, 24 Feb 2003 09:23:48 +0100 Date: Mon, 24 Feb 2003 09:23:48 +0100 From: Axel Thimm To: linux-xfs Subject: kernel-2.4.18-24.8.0at8: latest RHL 8.0 errata & XFS 1.2 Message-ID: <20030224082348.GA9582@puariko.nirvana> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gKMricLos+KVdGMg" Content-Disposition: inline User-Agent: Mutt/1.4i X-Sender: 520039812576-0001@t-dialin.net Resent-From: Axel.Thimm@physik.fu-berlin.de Resent-Date: Mon, 24 Feb 2003 13:48:32 +0100 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 2880 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs Content-Length: 1264 Lines: 38 --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I have adjusted the XFS patches from 1.2 to the latest release RedHat kernel for RedHat 8.0 (linux-2.4.19-kdb.patch and linux-2.4.19-quotabackport.patch had to be tweaked a litte for the recent redhat kernel releases). You can find them under http://atrpms.physik.fu-berlin.de/kernel/. Note that there are also some additional patches, which you can easily remove from the src.rpm. o base kernel sources: Taken from current redhat errata (2.4.18-24.8.0) o XFS: merged patches found in 1.2 o i2c-2.7.0 and lm_sensors-2.7.0. You should also get the updated userland tools. o 3ware 1.02.00.027 kernel driver for Escalade 7xxx series. Try to keep in sync with your firmware and userland tools. o v4l2-api (backported from http://bytesex.org/patches/2.4/11-v4l2-api-2.4.20-pre11.diff.gz) --=20 Axel.Thimm@physik.fu-berlin.de --gKMricLos+KVdGMg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+WdaUQBVS1GOamfERAhEXAJ9M/unvYYQRnm7+Gn6QA8OcpCV1EgCgmchW 56pzXtydkq0jGOyCjrcwkrw= =Wgvy -----END PGP SIGNATURE----- --gKMricLos+KVdGMg-- From owner-linux-xfs@oss.sgi.com Mon Feb 24 07:34:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Feb 2003 07:34:39 -0800 (PST) Received: from curlew.cs.man.ac.uk (curlew.cs.man.ac.uk [130.88.13.7]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1OFYR3v025797 for ; Mon, 24 Feb 2003 07:34:28 -0800 Received: from lithium.sta.man.ac.uk ([130.88.188.32] helo=doufu ident=mail) by curlew.cs.man.ac.uk with esmtp (Exim 4.12) id 18nJH4-000Mf5-00; Mon, 24 Feb 2003 14:08:06 +0000 Received: from rhowe by doufu with local (Exim 3.36 #1 (Debian)) id 18nJH4-00069E-00; Mon, 24 Feb 2003 14:08:06 +0000 Date: Mon, 24 Feb 2003 14:08:06 +0000 To: Nathan Scott Cc: "Russell G. Howe" , linux-xfs@oss.sgi.com Subject: Re: xfs_repair unable to repair a corrupt filesystem Message-ID: <20030224140806.GA23424@lithium.sta.man.ac.uk> References: <20030223081255.GA14077@lithium.sta.man.ac.uk> <20030223215931.GA798@frodo> <20030224033309.GA20260@lithium.sta.man.ac.uk> <20030224034815.GC798@frodo> <20030224043829.GA20677@lithium.sta.man.ac.uk> <20030224052759.GD798@frodo> <20030224055532.GA21046@lithium.sta.man.ac.uk> <20030224071237.GF798@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030224071237.GF798@frodo> User-Agent: Mutt/1.4i From: "Russell G. Howe" X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *18nJH4-000Mf5-00*pBggMgluOcs* X-archive-position: 2881 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rhowe@wiss.co.uk Precedence: bulk X-list: linux-xfs Content-Length: 932 Lines: 20 On Mon, Feb 24, 2003 at 06:12:37PM +1100, Nathan Scott wrote: > be able to blow these files away by writing zeroes into the > nextents and size fields (in a similar way to the way you did > nblocks overwrite earlier with xfs_db). Hm, OK. I'll try that then. I also have another problem with /home (log corruption causing mount failure), but the emails I sent to the list about that seem to have been caught in limbo for no good reason (I just got a Mailer-Daemon message saying there was an SMTP timeout talking to oss's mail server, yet it's odd that these messages don't get stuck). Eric Sandeen had a brief look at it on IRC before he went to bed, but not long enough to draw a conclusion. At least I have a rough idea of what data I can collect now, and I'll be posting a message about it shortly :) -- Russell Howe | Why be just another cog in the machine, rhowe@wiss.co.uk | when you can be the spanner in the works? From owner-linux-xfs@oss.sgi.com Mon Feb 24 07:52:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Feb 2003 07:52:30 -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 h1OFqM3v026530 for ; Mon, 24 Feb 2003 07:52:22 -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 h1OG1LKp012207 for ; Mon, 24 Feb 2003 08:01:21 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA24150; Mon, 24 Feb 2003 10:01:19 -0600 (CST) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 18nL2e-0000yf-00; Mon, 24 Feb 2003 10:01:20 -0600 Date: Mon, 24 Feb 2003 10:01:19 -0600 From: Nathan Straz To: "l.a walsh" Cc: linux-xfs@oss.sgi.com Subject: Re: been a while before i could get back to this.. Message-ID: <20030224160119.GA2145@sgi.com> Mail-Followup-To: "l.a walsh" , linux-xfs@oss.sgi.com References: <00c301c2dbbe$b929aaa0$1403a8c0@sc.tlinx.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00c301c2dbbe$b929aaa0$1403a8c0@sc.tlinx.org> User-Agent: Mutt/1.5.3i X-archive-position: 2882 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nstraz@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1132 Lines: 25 On Sun, Feb 23, 2003 at 08:39:31PM -0800, l.a walsh wrote: > xfsdump has been broken for me since last october. > It still is with latest patch/kernel and utils: > > These are the local window messages when I tried to dump: > + xfsdump -b 1048576 -m -l 0 -o -L root - / > + su -f -m backup -c 'nice -19 bzip2 >root/root-030220-0-2201.dump.bz2' > xfsdump: using file dump (drive_simple) strategy > xfsdump: version 2.2.6 (dump format 3.0) - Running single-threaded > xfsdump: level 0 dump of ishtar:/ > xfsdump: dump date: Thu Feb 20 22:01:40 2003 > xfsdump: session id: 1dfb2395-0d6c-4132-9ba0-0b41bc30c3c0 > xfsdump: session label: "root" > xfsdump: ino map phase 1: skipping (no subtrees specified) > xfsdump: ino map phase 2: constructing initial dump list > xfsdump: WARNING: failed to get bulkstat information for inode 1590 Is it always inode 1590? Could you print out the inode information with xfs_db? -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Mon Feb 24 09:53:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Feb 2003 09:53:56 -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 h1OHrj3v028056 for ; Mon, 24 Feb 2003 09:53:45 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1OHrjDM028055 for linux-xfs@oss.sgi.com; Mon, 24 Feb 2003 09:53:45 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1OHrR3v028043 for ; Mon, 24 Feb 2003 09:53:27 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1OHqS2g028031; Mon, 24 Feb 2003 09:52:28 -0800 Date: Mon, 24 Feb 2003 09:52:28 -0800 Message-Id: <200302241752.h1OHqS2g028031@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 225] New: thread deadlock on full fs. X-Bugzilla-Reason: AssignedTo X-archive-position: 2883 X-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: 29001 Lines: 491 http://oss.sgi.com/bugzilla/show_bug.cgi?id=225 Summary: thread deadlock on full fs. Product: Linux XFS Version: 1.2.x Platform: All OS/Version: Linux Status: NEW Severity: critical Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: stephy32@videotron.ca If this is a userspace bug, what version of the package are you using: What kernel are you using: 2.4.20 cvs from dec19 after fix from 256 ag... Where did the XFS code come from? (CVS, Linus, your distribution, etc): cvs tree download Description of Problem: A thread writing eventually deadlock waiting for some resouce when fs gets full. No SCSI error or other problem. Reproduceable also with raid 0 strip over 2 HW raid 5... How Reproducible: withing a day. Steps to Reproduce: 1. create a fs on an extra u160 SCSI 18 GB drive. 2. Start a few script that write to it, locally or over NFS. 3. Wait for system to go idle with load average going up, 10,50, 100 -> 300. Actual Results: system stop being usefull Expected Results: Geep going. Additional Information: Backtrace of D process, bdflush, kswapd... Stack traceback for pid 1 0xc1910000 1 0 0 0 D 0xc1910370 init EBP EIP Function (args) 0xc1911bc0 0xc01156f3 schedule+0x493 (0x0, 0xc1910000, 0x0, 0x0, 0x0) kernel .text 0xc0100000 0xc0115260 0xc01157b0 0xc1911bf0 0xc0212fc8 lock_wait+0x98 (0xeeb6ca70, 0xeeb6ca88, 0x0, 0x8) kernel .text 0xc0100000 0xc0212f30 0xc0213000 0xc1911c08 0xc0213088 mraccessf+0x48 (0xeeb6ca68, 0x0, 0xeeb6cadc, 0x9f8000) kernel .text 0xc0100000 0xc0213040 0xc02130b0 0xc1911c20 0xc01e905a xfs_ilock+0x6a (0xeeb6c9e0, 0xc8, 0xef927c40, 0x5b2, 0x0) kernel .text 0xc0100000 0xc01e8ff0 0xc01e9070 0xc1911c88 0xc020d644 xfs_iomap+0x104 (0xeeb6cadc, 0x9f8000, 0x0, 0x1000, 0x8000) kernel .text 0xc0100000 0xc020d540 0xc020d880 0xc1911cac 0xc02106a9 xfs_bmap+0x29 (0xeeb6c9f8, 0x9f8000, 0x0, 0x1000, 0x8000) kernel .text 0xc0100000 0xc0210680 0xc02106b0 0xc1911cec 0xc0209f2d map_blocks+0x8d (0xef015320, 0x9f8000, 0x0, 0x1000, 0xc1911d40) kernel .text 0xc0100000 0xc0209ea0 0xc0209fb0 0xc1911d8c 0xc020a607 delalloc_convert+0x137 (0xc1590210, 0x1, 0x0, 0x1, 0x1) kernel .text 0xc0100000 0xc020a4d0 0xc020a830 0xc1911db8 0xc020abff linvfs_writepage+0xaf (0xc1590210, 0x2173c, 0x0, 0x0, 0x2) kernel .text 0xc0100000 0xc020ab50 0xc020ac50 0xc1911e5c 0xc013bc4e write_some_buffers+0xae (0x0, 0xea31d680) kernel .text 0xc0100000 0xc013bba0 0xc013bd20 0xc1911e6c 0xc013cbec balance_dirty+0x2c (0xea31d680, 0x1000, 0x0, 0x5b1d00, 0x0) kernel .text 0xc0100000 0xc013cbc0 0xc013cc00 0xc1911e8c 0xc013d81f __block_commit_write+0xaf (0xd272d6a0, 0xc1306770, 0xb80, 0xd00, 0xd272d6a0) kernel .text 0xc0100000 0xc013d770 0xc013d840 0xc1911eb4 0xc013df9b generic_commit_write+0x3b (0xea02b880, 0xc1306770, 0xb80, 0xd00, 0xc1911ef8) kernel .text 0xc0100000 0xc013df60 0xc013e010 0xc1911f0c 0xc012dc75 generic_file_write_nolock+0x495 (0xea02b880, 0xbffffb00, 0x180, 0xc1911f84, 0x0) kernel .text 0xc0100000 0xc012d7e0 0xc012dec0 0xc1911f64 0xc021037f xfs_write+0x3bf (0xeef79228, 0xea02b880, 0xbffffb00, 0x180, 0xc1911f84) kernel .text 0xc0100000 0xc020ffc0 0xc0210640 0xc1911f98 0xc020b1d5 linvfs_write+0xa5 (0xea02b880, 0xbffffb00, 0x180, 0xea02b8a0, 0xc1910000) kernel .text 0xc0100000 0xc020b130 0xc020b210 0xc1911fbc 0xc013a9d8 sys_write+0x98 (0x1, 0xbffffb00, 0x180, 0x5b1b80, 0x0) kernel .text 0xc0100000 0xc013a940 0xc013aa50 0xc0107193 system_call+0x33 kernel .text 0xc0100000 0xc0107160 0xc0107198 Stack traceback for pid 6 0xefdd4000 6 1 0 0 D 0xefdd4370 bdflush EBP EIP Function (args) 0xefdd5d38 0xc01156f3 schedule+0x493 (0x0, 0xefdd4000, 0x0, 0x0, 0x0) kernel .text 0xc0100000 0xc0115260 0xc01157b0 0xefdd5d68 0xc0212fc8 lock_wait+0x98 (0xeeb6ca70, 0xeeb6ca88, 0x0, 0x8) kernel .text 0xc0100000 0xc0212f30 0xc0213000 0xefdd5d80 0xc0213088 mraccessf+0x48 (0xeeb6ca68, 0x0, 0xeeb6cadc, 0x9f5000) kernel .text 0xc0100000 0xc0213040 0xc02130b0 0xefdd5d98 0xc01e905a xfs_ilock+0x6a (0xeeb6c9e0, 0xc8, 0xefcedb80, 0xefdd5dd8, 0xc0254b06) kernel .text 0xc0100000 0xc01e8ff0 0xc01e9070 0xefdd5e00 0xc020d644 xfs_iomap+0x104 (0xeeb6cadc, 0x9f5000, 0x0, 0x1000, 0x8000) kernel .text 0xc0100000 0xc020d540 0xc020d880 0xefdd5e24 0xc02106a9 xfs_bmap+0x29 (0xeeb6c9f8, 0x9f5000, 0x0, 0x1000, 0x8000) kernel .text 0xc0100000 0xc0210680 0xc02106b0 0xefdd5e64 0xc0209f2d map_blocks+0x8d (0xef015320, 0x9f5000, 0x0, 0x1000, 0xefdd5eb8) kernel .text 0xc0100000 0xc0209ea0 0xc0209fb0 0xefdd5f04 0xc020a607 delalloc_convert+0x137 (0xefcf8e18, 0x1, 0xe826a480, 0x950a6, 0x8) kernel .text 0xc0100000 0xc020a4d0 0xc020a830 0xefdd5efc 0xc02553b9 generic_make_request+0x119 (0xc1063890, 0x131d9, 0x0, 0x0, 0xced77880) kernel .text 0xc0100000 0xc02552a0 0xc02553d0 0xefdd5fd4 0xc013bc4e write_some_buffers+0xae (0x0, 0x10f00, 0xc1911fa8, 0xc0105000) kernel .text 0xc0100000 0xc013bba0 0xc013bd20 0xefdd5fec 0xc013f42b bdflush+0xbb kernel .text 0xc0100000 0xc013f370 0xc013f450 0xc0105756 kernel_thread+0x26 kernel .text 0xc0100000 0xc0105730 0xc0105770 Stack traceback for pid 7 0xefdd2000 7 1 0 0 D 0xefdd2370 kupdated EBP EIP Function (args) 0xefdd38b0 0xc01156f3 schedule+0x493 (0x1, 0xefdd2000, 0xeb003c10, 0xe4cd638c, 0xe4cd6380) kernel .text 0xc0100000 0xc0115260 0xc01157b0 0xefdd38d0 0xc0105d28 __down+0x68 (0xe4cd6380, 0xe4cd63b4, 0x0) kernel .text 0xc0100000 0xc0105cc0 0xc0105d90 0xefdd38e4 0xc0105edb __down_failed+0xb (0xe4cd63b4, 0xefdd3920, 0xc0207a87, 0xe4cd6380, 0x5) kernel .text 0xc0100000 0xc0105ed0 0xc0105ee4 0xc0209b39 .text.lock.page_buf_locking+0xc kernel .text 0xc0100000 0xc0209b2d 0xc0209b50 0xefdd38f0 0xc0209c10 xfs_read_xfsstats+0xc0 (0x0, 0x7290a, 0x0, 0xfe0005, 0xd) kernel .text 0xc0100000 0xc0209b50 0xc0209c70 0xc0271887 scsi_dispatch_cmd+0x1a7 (0xeeb6c9e0, 0xef163800, 0x1, 0xefdd3dbc, 0xeeb6c9e0) kernel .text 0xc0100000 0xc02716e0 0xc0271a80 0xefdd3d70 0xc020d37f _xfs_imap_to_bmap+0x2f (0xeeb6c9e0, 0xefdd3dc0, 0xefdd3dbc, 0x1, 0x0) kernel .text 0xc0100000 0xc020d350 0xc020d540 0xefdd3dec 0xc020d816 xfs_iomap+0x2d6 (0xeeb6cadc, 0x9f4000, 0x0, 0x1000, 0x8000) kernel .text 0xc0100000 0xc020d540 0xc020d880 0xefdd3e10 0xc02106a9 xfs_bmap+0x29 (0xeeb6c9f8, 0x9f4000, 0x0, 0x1000, 0x8000) kernel .text 0xc0100000 0xc0210680 0xc02106b0 0xefdd3e50 0xc0209f2d map_blocks+0x8d (0xef015320, 0x9f4000, 0x0, 0x1000, 0xefdd3ea4) kernel .text 0xc0100000 0xc0209ea0 0xc0209fb0 0xefdd3ef0 0xc020a607 delalloc_convert+0x137 (0xc16b7dd0, 0x1, 0x0, 0x1, 0x1) kernel .text 0xc0100000 0xc020a4d0 0xc020a830 0xefdd3f1c 0xc020abff linvfs_writepage+0xaf (0xc16b7dd0, 0xc, 0x0, 0x0, 0x8) kernel .text 0xc0100000 0xc020ab50 0xc020ac50 0xefdd3fc0 0xc013bc4e write_some_buffers+0xae (0xef163800, 0x31, 0x0, 0xefdd3fc0, 0x0) kernel .text 0xc0100000 0xc013bba0 0xc013bd20 0xefdd3fb0 0xc0211c07 linvfs_write_super+0x27 kernel .text 0xc0100000 0xc0211be0 0xc0211c10 0xc0105756 kernel_thread+0x26 kernel .text 0xc0100000 0xc0105730 0xc0105770 Stack traceback for pid 687 0xef5f2000 687 1 0 1 D 0xef5f2370 syslogd EBP EIP Function (args) 0xef5f3b4c 0xc01156f3 schedule+0x493 (0x0, 0xef5f2000, 0x0, 0x0, 0x0) kernel .text 0xc0100000 0xc0115260 0xc01157b0 0xef5f3b7c 0xc0212fc8 lock_wait+0x98 (0xeeb6ca70, 0xeeb6ca88, 0x0, 0x8) kernel .text 0xc0100000 0xc0212f30 0xc0213000 0xef5f3b94 0xc0213088 mraccessf+0x48 (0xeeb6ca68, 0x0, 0xeeb6cadc, 0x9f7000) kernel .text 0xc0100000 0xc0213040 0xc02130b0 0xef5f3bac 0xc01e905a xfs_ilock+0x6a (0xeeb6c9e0, 0xc8, 0xee9fd650, 0xb, 0x0) kernel .text 0xc0100000 0xc01e8ff0 0xc01e9070 0xef5f3c14 0xc020d644 xfs_iomap+0x104 (0xeeb6cadc, 0x9f7000, 0x0, 0x1000, 0x8000) kernel .text 0xc0100000 0xc020d540 0xc020d880 0xef5f3c38 0xc02106a9 xfs_bmap+0x29 (0xeeb6c9f8, 0x9f7000, 0x0, 0x1000, 0x8000) kernel .text 0xc0100000 0xc0210680 0xc02106b0 0xef5f3c78 0xc0209f2d map_blocks+0x8d (0xef015320, 0x9f7000, 0x0, 0x1000, 0xef5f3ccc) kernel .text 0xc0100000 0xc0209ea0 0xc0209fb0 0xef5f3d18 0xc020a607 delalloc_convert+0x137 (0xc17b4970, 0x1, 0x0, 0x1, 0x1) kernel .text 0xc0100000 0xc020a4d0 0xc020a830 0xef5f3d44 0xc020abff linvfs_writepage+0xaf (0xc17b4970, 0x2173c, 0x0, 0x0, 0xef0f3780) kernel .text 0xc0100000 0xc020ab50 0xc020ac50 0xef5f3de8 0xc013bc4e write_some_buffers+0xae (0x286, 0x2, 0xef5f2000, 0xfffffc18, 0x1) kernel .text 0xc0100000 0xc013bba0 0xc013bd20 0xc025457d generic_unplug_device+0x2d (0xeebbf880, 0xc110af00, 0x9ad, 0x9bc, 0xef5f3e84) kernel .text 0xc0100000 0xc0254550 0xc0254590 0xef5f3e98 0xc012dc75 generic_file_write_nolock+0x495 (0xeebbf880, 0x8052da0, 0xf, 0xef5f3f10, 0x4a) kernel .text 0xc0100000 0xc012d7e0 0xc012dec0 0xef5f3ef0 0xc021037f xfs_write+0x3bf (0xef07c118, 0xeebbf880, 0x8052da0, 0xf, 0xef5f3f10) kernel .text 0xc0100000 0xc020ffc0 0xc0210640 0xef5f3f24 0xc020b1d5 linvfs_write+0xa5 (0xeebbf880, 0x8052da0, 0xf, 0xeebbf8a0, 0xa9ad) kernel .text 0xc0100000 0xc020b130 0xc020b210 0xef5f3f9c 0xc013ac0d do_readv_writev+0x1bd (0x0, 0xeebbf880, 0xbfffef80, 0x6, 0xef5f2000) kernel .text 0xc0100000 0xc013aa50 0xc013acd0 0xef5f3fbc 0xc013ad73 sys_writev+0x43 (0x4, 0xbfffef80, 0x6, 0x6, 0x4) kernel .text 0xc0100000 0xc013ad30 0xc013ad90 0xc0107193 system_call+0x33 kernel .text 0xc0100000 0xc0107160 0xc0107198 Stack traceback for pid 1128 0xed66c000 1128 1 0 0 D 0xed66c370 nmbd EBP EIP Function (args) 0xed66dbc0 0xc01156f3 schedule+0x493 (0x0, 0xed66c000, 0x0, 0x0, 0x0) kernel .text 0xc0100000 0xc0115260 0xc01157b0 0xed66dbf0 0xc0212fc8 lock_wait+0x98 (0xeeb6ca70, 0xeeb6ca88, 0x0, 0x8) kernel .text 0xc0100000 0xc0212f30 0xc0213000 0xed66dc08 0xc0213088 mraccessf+0x48 (0xeeb6ca68, 0x0, 0xeeb6cadc, 0x9f9000) kernel .text 0xc0100000 0xc0213040 0xc02130b0 0xed66dc20 0xc01e905a xfs_ilock+0x6a (0xeeb6c9e0, 0xc8, 0xed74bbd0, 0x3d, 0x0) kernel .text 0xc0100000 0xc01e8ff0 0xc01e9070 0xed66dc88 0xc020d644 xfs_iomap+0x104 (0xeeb6cadc, 0x9f9000, 0x0, 0x1000, 0x8000) kernel .text 0xc0100000 0xc020d540 0xc020d880 0xed66dcac 0xc02106a9 xfs_bmap+0x29 (0xeeb6c9f8, 0x9f9000, 0x0, 0x1000, 0x8000) kernel .text 0xc0100000 0xc0210680 0xc02106b0 0xed66dcec 0xc0209f2d map_blocks+0x8d (0xef015320, 0x9f9000, 0x0, 0x1000, 0xed66dd40) kernel .text 0xc0100000 0xc0209ea0 0xc0209fb0 0xed66dd8c 0xc020a607 delalloc_convert+0x137 (0xc183f210, 0x1, 0x0, 0x1, 0x1) kernel .text 0xc0100000 0xc020a4d0 0xc020a830 0xed66ddb8 0xc020abff linvfs_writepage+0xaf (0xc183f210, 0x2173c, 0x0, 0x0, 0xef147280) kernel .text 0xc0100000 0xc020ab50 0xc020ac50 0xed66de5c 0xc013bc4e write_some_buffers+0xae (0x286, 0xed66de00, 0xed66c000, 0xfffffc18, 0x0) kernel .text 0xc0100000 0xc013bba0 0xc013bd20 0xc025457d generic_unplug_device+0x2d (0xedc9f200, 0xc1791390, 0x17f, 0x1c7, 0xed66def8) kernel .text 0xc0100000 0xc0254550 0xc0254590 0xed66df0c 0xc012dc75 generic_file_write_nolock+0x495 (0xedc9f200, 0xbfffcca0, 0x48, 0xed66df84, 0x1000) kernel .text 0xc0100000 0xc012d7e0 0xc012dec0 0xed66df64 0xc021037f xfs_write+0x3bf (0xed74bb88, 0xedc9f200, 0xbfffcca0, 0x48, 0xed66df84) kernel .text 0xc0100000 0xc020ffc0 0xc0210640 0xed66df98 0xc020b1d5 linvfs_write+0xa5 (0xedc9f200, 0xbfffcca0, 0x48, 0xedc9f220, 0xed66c000) kernel .text 0xc0100000 0xc020b130 0xc020b210 0xed66dfbc 0xc013a9d8 sys_write+0x98 (0x3, 0xbfffcca0, 0x48, 0x48, 0xbfffcca0) kernel .text 0xc0100000 0xc013a940 0xc013aa50 0xc0107193 system_call+0x33 kernel .text 0xc0100000 0xc0107160 0xc0107198 Stack traceback for pid 26146 0xebce4000 26146 1454 0 0 D 0xebce4370 dd EBP EIP Function (args) 0xebce5b04 0xc01156f3 schedule+0x493 (0x1, 0xebce4000, 0xe4cd628c, 0xe4cd628c, 0xe4cd6280) kernel .text 0xc0100000 0xc0115260 0xc01157b0 0xebce5b24 0xc0105d28 __down+0x68 (0xe4cd6280, 0xe4cd62b4, 0x0) kernel .text 0xc0100000 0xc0105cc0 0xc0105d90 0xebce5b38 0xc0105edb __down_failed+0xb (0xe4cd62b4, 0xebce5b74, 0xc0207a87, 0xe4cd6280, 0x5) kernel .text 0xc0100000 0xc0105ed0 0xc0105ee4 0xc0209b39 .text.lock.page_buf_locking+0xc kernel .text 0xc0100000 0xc0209b2d 0xc0209b50 0xebce5b44 0xc0209c10 xfs_read_xfsstats+0xc0 (0xeeb6c098, 0xebce5e50, 0x0, 0x0, 0x0) kernel .text 0xc0100000 0xc0209b50 0xc0209c70 0xebce5ecc 0xc020f014 linvfs_setattr+0x164 (0xeec0ad00, 0xebce5efc, 0x48, 0xef015d8c, 0xef015d20) kernel .text 0xc0100000 0xc020eeb0 0xc020f070 0xebce5eec 0xc0151920 notify_change+0x80 (0xeec0ad00, 0xebce5efc, 0x48, 0xeeb6c080, 0x8) kernel .text 0xc0100000 0xc01518a0 0xc0151b45 0xebce5f38 0xc0138f16 do_truncate+0x46 (0xeec0ad00, 0x0, 0x0, 0x0, 0x2) kernel .text 0xc0100000 0xc0138ed0 0xc0138f30 0xebce5f64 0xc0146492 open_namei+0x4a2 (0xc1c33000, 0x8242, 0x1b6, 0xebce5f7c, 0xeec0ad00) kernel .text 0xc0100000 0xc0145ff0 0xc0146640 0xebce5fa0 0xc0139ee7 filp_open+0x37 (0xc1c33000, 0x8241, 0x1b6, 0xebce4000, 0xbffffc96) kernel .text 0xc0100000 0xc0139eb0 0xc0139f10 0xebce5fbc 0xc013a244 sys_open+0x34 (0xbffffc96, 0x8241, 0x1b6, 0xbffffc96, 0x1) kernel .text 0xc0100000 0xc013a210 0xc013a2b0 0xc0107193 system_call+0x33 kernel .text 0xc0100000 0xc0107160 0xc0107198 Stack traceback for pid 26240 0xeb002000 26240 25607 0 0 D 0xeb002370 rm EBP EIP Function (args) 0xeb003c00 0xc01156f3 schedule+0x493 (0x1, 0xeb002000, 0xe4cd638c, 0xefdd38c0, 0xe4cd6380) kernel .text 0xc0100000 0xc0115260 0xc01157b0 0xeb003c20 0xc0105d28 __down+0x68 (0xe4cd6380, 0xe4cd63b4, 0x0) kernel .text 0xc0100000 0xc0105cc0 0xc0105d90 0xeb003c34 0xc0105edb __down_failed+0xb (0xe4cd63b4, 0xeb003c70, 0xc0207a87, 0xe4cd6380, 0x5) kernel .text 0xc0100000 0xc0105ed0 0xc0105ee4 0xc0209b39 .text.lock.page_buf_locking+0xc kernel .text 0xc0100000 0xc0209b2d 0xc0209b50 0xeb003c40 0xc0209c10 xfs_read_xfsstats+0xc0 (0xecae3868, 0x0, 0xdb134880) kernel .text 0xc0100000 0xc0209b50 0xc0209c70 0xeb003f1c 0xc02124c8 vn_rele+0x38 (0xdb134880, 0xdb1348a0) kernel .text 0xc0100000 0xc0212490 0xc0212530 0xeb003f2c 0xc0211b62 linvfs_clear_inode+0x12 (0xdb1348a0, 0xdb1348a0) kernel .text 0xc0100000 0xc0211b50 0xc0211b80 0xeb003f3c 0xc01506da clear_inode+0xda (0xdb1348a0, 0xeebdc980, 0xdb1348a0, 0xed01b0a0) kernel .text 0xc0100000 0xc0150600 0xc0150720 0xeb003f54 0xc0151066 iput+0x176 (0xdb1348a0, 0xeb002000, 0x0) kernel .text 0xc0100000 0xc0150ef0 0xc0151170 0xeb003f68 0xc014f056 d_delete+0x66 (0xeebdc980, 0xeebdc980, 0xc5245000, 0xeebdc980) kernel .text 0xc0100000 0xc014eff0 0xc014f0b0 0xeb003f80 0xc014720c vfs_unlink+0x1ec (0xed01b0a0, 0xeebdc980, 0xdcadab80, 0xef534dc0, 0xc5245015) kernel .text 0xc0100000 0xc0147020 0xc0147250 0xeb003fbc 0xc01472d7 sys_unlink+0x87 (0xbffff8ae, 0x1, 0x0, 0xbffff8ae, 0x0) kernel .text 0xc0100000 0xc0147250 0xc0147340 0xc0107193 system_call+0x33 kernel .text 0xc0100000 0xc0107160 0xc0107198 Stack traceback for pid 26295 0xe4da8000 26295 1815 0 0 D 0xe4da8370 iotst64 EBP EIP Function (args) 0xe4da9bb8 0xc01156f3 schedule+0x493 (0x0, 0xe4da8000, 0x0, 0x0, 0x0) kernel .text 0xc0100000 0xc0115260 0xc01157b0 0xe4da9be8 0xc0212fc8 lock_wait+0x98 (0xeeb6ca70, 0xeeb6ca88, 0x0, 0x8) kernel .text 0xc0100000 0xc0212f30 0xc0213000 0xe4da9c00 0xc0213088 mraccessf+0x48 (0xeeb6ca68, 0x0, 0xeeb6cadc, 0x9f6000) kernel .text 0xc0100000 0xc0213040 0xc02130b0 0xe4da9c18 0xc01e905a xfs_ilock+0x6a (0xeeb6c9e0, 0xc8, 0xcd4d0720, 0x2173f, 0x0) kernel .text 0xc0100000 0xc01e8ff0 0xc01e9070 0xe4da9c80 0xc020d644 xfs_iomap+0x104 (0xeeb6cadc, 0x9f6000, 0x0, 0x1000, 0x8000) kernel .text 0xc0100000 0xc020d540 0xc020d880 0xe4da9ca4 0xc02106a9 xfs_bmap+0x29 (0xeeb6c9f8, 0x9f6000, 0x0, 0x1000, 0x8000) kernel .text 0xc0100000 0xc0210680 0xc02106b0 0xe4da9ce4 0xc0209f2d map_blocks+0x8d (0xef015320, 0x9f6000, 0x0, 0x1000, 0xe4da9d38) kernel .text 0xc0100000 0xc0209ea0 0xc0209fb0 0xe4da9d84 0xc020a607 delalloc_convert+0x137 (0xc12406e0, 0x1, 0x0, 0x1, 0x1) kernel .text 0xc0100000 0xc020a4d0 0xc020a830 0xe4da9db0 0xc020abff linvfs_writepage+0xaf (0xc12406e0, 0x2173c, 0x0, 0x0, 0xc01312a0) kernel .text 0xc0100000 0xc020ab50 0xc020ac50 0xe4da9e54 0xc013bc4e write_some_buffers+0xae (0x0, 0xc2d74d80) kernel .text 0xc0100000 0xc013bba0 0xc013bd20 0xe4da9e64 0xc013cbec balance_dirty+0x2c (0xc2d74d80, 0x1000, 0x0, 0x21730000, 0x0) kernel .text 0xc0100000 0xc013cbc0 0xc013cc00 0xe4da9e84 0xc013d81f __block_commit_write+0xaf (0xe8bcc9a0, 0xc12dce90, 0x0, 0x1000, 0xe8bcc9a0) kernel .text 0xc0100000 0xc013d770 0xc013d840 0xe4da9eac 0xc013df9b generic_commit_write+0x3b (0xc3154a00, 0xc12dce90, 0x0, 0x1000, 0xe4da9ef0) kernel .text 0xc0100000 0xc013df60 0xc013e010 0xe4da9f04 0xc012dc75 generic_file_write_nolock+0x495 (0xc3154a00, 0x8059a88, 0x1000, 0xe4da9f7c, 0xe4da8000) kernel .text 0xc0100000 0xc012d7e0 0xc012dec0 0xe4da9f5c 0xc021037f xfs_write+0x3bf (0xcd4d06d8, 0xc3154a00, 0x804aa88, 0x10000, 0xe4da9f7c) kernel .text 0xc0100000 0xc020ffc0 0xc0210640 0xe4da9f90 0xc020b1d5 linvfs_write+0xa5 (0xc3154a00, 0x804aa88, 0x10000, 0xe4da9fa8, 0x21720000) kernel .text 0xc0100000 0xc020b130 0xc020b210 0xe4da9fbc 0xc013af74 sys_pwrite+0xb4 (0x3, 0x804aa88, 0x10000, 0x21720000, 0x0) kernel .text 0xc0100000 0xc013aec0 0xc013afe8 0xc0107193 system_call+0x33 kernel .text 0xc0100000 0xc0107160 0xc0107198 Stack traceback for pid 26572 0xe347c000 26572 26571 0 1 D 0xe347c370 sadc EBP EIP Function (args) 0xe347dbc0 0xc01156f3 schedule+0x493 (0x0, 0xe347c000, 0x0, 0x0, 0x0) kernel .text 0xc0100000 0xc0115260 0xc01157b0 0xe347dbf0 0xc0212fc8 lock_wait+0x98 (0xeeb6ca70, 0xeeb6ca88, 0x0, 0x8) kernel .text 0xc0100000 0xc0212f30 0xc0213000 0xe347dc08 0xc0213088 mraccessf+0x48 (0xeeb6ca68, 0x0, 0xeeb6cadc, 0x9fa000) kernel .text 0xc0100000 0xc0213040 0xc02130b0 0xe347dc20 0xc01e905a xfs_ilock+0x6a (0xeeb6c9e0, 0xc8, 0xedbc6ac0, 0x1c, 0x0) kernel .text 0xc0100000 0xc01e8ff0 0xc01e9070 0xe347dc88 0xc020d644 xfs_iomap+0x104 (0xeeb6cadc, 0x9fa000, 0x0, 0x1000, 0x8000) kernel .text 0xc0100000 0xc020d540 0xc020d880 0xe347dcac 0xc02106a9 xfs_bmap+0x29 (0xeeb6c9f8, 0x9fa000, 0x0, 0x1000, 0x8000) kernel .text 0xc0100000 0xc0210680 0xc02106b0 0xe347dcec 0xc0209f2d map_blocks+0x8d (0xef015320, 0x9fa000, 0x0, 0x1000, 0xe347dd40) kernel .text 0xc0100000 0xc0209ea0 0xc0209fb0 0xe347dd8c 0xc020a607 delalloc_convert+0x137 (0xc17cfbb0, 0x1, 0x0, 0x1, 0x1) kernel .text 0xc0100000 0xc020a4d0 0xc020a830 0xe347ddb8 0xc020abff linvfs_writepage+0xaf (0xc17cfbb0, 0x2173c, 0x0, 0x0, 0xe8266b80) kernel .text 0xc0100000 0xc020ab50 0xc020ac50 0xe347de5c 0xc013bc4e write_some_buffers+0xae (0x286, 0xe347de00, 0xe347c000, 0xfffffc18, 0x1) kernel .text 0xc0100000 0xc013bba0 0xc013bd20 0xc025457d generic_unplug_device+0x2d (0xe46ef700, 0xc17c7780, 0x415, 0x51d, 0xe347def8) kernel .text 0xc0100000 0xc0254550 0xc0254590 0xe347df0c 0xc012dc75 generic_file_write_nolock+0x495 (0xe46ef700, 0x804f660, 0x108, 0xe347df84, 0xc0127848) kernel .text 0xc0100000 0xc012d7e0 0xc012dec0 0xe347df64 0xc021037f xfs_write+0x3bf (0xedbc6a78, 0xe46ef700, 0x804f660, 0x108, 0xe347df84) kernel .text 0xc0100000 0xc020ffc0 0xc0210640 0xe347df98 0xc020b1d5 linvfs_write+0xa5 (0xe46ef700, 0x804f660, 0x108, 0xe46ef720, 0xe347c000) kernel .text 0xc0100000 0xc020b130 0xc020b210 0xe347dfbc 0xc013a9d8 sys_write+0x98 (0x3, 0x804f660, 0x108, 0x3, 0xbffffbf8) kernel .text 0xc0100000 0xc013a940 0xc013aa50 0xc0107193 system_call+0x33 kernel .text 0xc0100000 0xc0107160 0xc0107198 Stack traceback for pid 26874 0xe0848000 26874 26873 0 1 D 0xe0848370 sadc EBP EIP Function (args) 0xe0849ef0 0xc01156f3 schedule+0x493 (0x0, 0xe0848000, 0x0, 0x0, 0x0) kernel .text 0xc0100000 0xc0115260 0xc01157b0 0xe0849f20 0xc0212fc8 lock_wait+0x98 (0xedbc6b14, 0xedbc6b2c, 0x0, 0x2) kernel .text 0xc0100000 0xc0212f30 0xc0213000 0xe0849f38 0xc0213088 mraccessf+0x48 (0xedbc6b0c, 0x0, 0x7ff, 0xe5) kernel .text 0xc0100000 0xc0213040 0xc02130b0 0xe0849f50 0xc01e902b xfs_ilock+0x3b (0xedbc6a60, 0x2, 0xeefd5400, 0xedbc6a60, 0xe0849fa0) kernel .text 0xc0100000 0xc01e8ff0 0xc01e9070 0xe0849f78 0xc020fb6b xfs_read+0xfb (0xedbc6a78, 0xea02b800, 0x804f780, 0xe5, 0xea02b820) kernel .text 0xc0100000 0xc020fa70 0xc020fc40 0xe0849f98 0xc020b125 linvfs_read+0x25 (0xea02b800, 0x804f780, 0xe5, 0xea02b820, 0xe0848000) kernel .text 0xc0100000 0xc020b100 0xc020b130 0xe0849fbc 0xc013a8c8 sys_read+0x98 (0x3, 0x804f780, 0xe5, 0xbffffbf8, 0xbffffbfc) kernel .text 0xc0100000 0xc013a830 0xc013a940 0xc0107193 system_call+0x33 kernel .text 0xc0100000 0xc0107160 0xc0107198 Stack traceback for pid 27175 0xc7f8e000 27175 27174 0 0 D 0xc7f8e370 sadc EBP EIP Function (args) 0xc7f8fef0 0xc01156f3 schedule+0x493 (0x0, 0xc7f8e000, 0x0, 0x0, 0x0) kernel .text 0xc0100000 0xc0115260 0xc01157b0 0xc7f8ff20 0xc0212fc8 lock_wait+0x98 (0xedbc6b14, 0xedbc6b2c, 0x0, 0x2) kernel .text 0xc0100000 0xc0212f30 0xc0213000 0xc7f8ff38 0xc0213088 mraccessf+0x48 (0xedbc6b0c, 0x0, 0x7ff, 0xe5) kernel .text 0xc0100000 0xc0213040 0xc02130b0 0xc7f8ff50 0xc01e902b xfs_ilock+0x3b (0xedbc6a60, 0x2, 0xeefd5400, 0xedbc6a60, 0xc7f8ffa0) kernel .text 0xc0100000 0xc01e8ff0 0xc01e9070 0xc7f8ff78 0xc020fb6b xfs_read+0xfb (0xedbc6a78, 0xd095e700, 0x804f780, 0xe5, 0xd095e720) kernel .text 0xc0100000 0xc020fa70 0xc020fc40 0xc7f8ff98 0xc020b125 linvfs_read+0x25 (0xd095e700, 0x804f780, 0xe5, 0xd095e720, 0xc7f8e000) kernel .text 0xc0100000 0xc020b100 0xc020b130 0xc7f8ffbc 0xc013a8c8 sys_read+0x98 (0x3, 0x804f780, 0xe5, 0xbffffbf8, 0xbffffbfc) kernel .text 0xc0100000 0xc013a830 0xc013a940 0xc0107193 system_call+0x33 kernel .text 0xc0100000 0xc0107160 0xc0107198 Stack traceback for pid 27236 0xc40cc000 27236 895 0 0 D 0xc40cc370 sshd EBP EIP Function (args) 0xc40cdf48 0xc01156f3 schedule+0x493 (0x1, 0xc40cc000, 0xd272d718, 0xddf07f58, 0xd272d6a0) kernel .text 0xc0100000 0xc0115260 0xc01157b0 0xc40cdf68 0xc0105d28 __down+0x68 (0xd272d70c, 0xc40cdf84, 0xe170b180) kernel .text 0xc0100000 0xc0105cc0 0xc0105d90 0xc40cdf7c 0xc0105edb __down_failed+0xb (0x5b1b80, 0x0, 0x180, 0xe170b180, 0xffffffea) kernel .text 0xc0100000 0xc0105ed0 0xc0105ee4 0xc020b5b8 .text.lock.xfs_file+0x5 kernel .text 0xc0100000 0xc020b5b3 0xc020b5e0 0xc40cdf98 0xc020b1bc linvfs_write+0x8c (0xe170b180, 0xbffff240, 0x180, 0xe170b1a0, 0xc40cc000) kernel .text 0xc0100000 0xc020b130 0xc020b210 0xc40cdfbc 0xc013a9d8 sys_write+0x98 (0x6, 0xbffff240, 0x180, 0x5b1b80, 0x0) kernel .text 0xc0100000 0xc013a940 0xc013aa50 0xc0107193 system_call+0x33 kernel .text 0xc0100000 0xc0107160 0xc0107198 Stack traceback for pid 27238 0xddf06000 27238 27236 0 1 D 0xddf06370 sshd EBP EIP Function (args) 0xddf07f48 0xc01156f3 schedule+0x493 (0x1, 0xddf06000, 0xc40cdf58, 0xd272d718, 0xd272d6a0) kernel .text 0xc0100000 0xc0115260 0xc01157b0 0xddf07f68 0xc0105d28 __down+0x68 (0xd272d70c, 0xddf07f84, 0xd0ad4f00) kernel .text 0xc0100000 0xc0105cc0 0xc0105d90 0xddf07f7c 0xc0105edb __down_failed+0xb (0x5b1b80, 0x0, 0x180, 0xd0ad4f00, 0xffffffea) kernel .text 0xc0100000 0xc0105ed0 0xc0105ee4 0xc020b5b8 .text.lock.xfs_file+0x5 kernel .text 0xc0100000 0xc020b5b3 0xc020b5e0 0xddf07f98 0xc020b1bc linvfs_write+0x8c (0xd0ad4f00, 0xbfffe070, 0x180, 0xd0ad4f20, 0xddf06000) kernel .text 0xc0100000 0xc020b130 0xc020b210 0xddf07fbc 0xc013a9d8 sys_write+0x98 (0x6, 0xbfffe070, 0x180, 0x5b1b80, 0x0) kernel .text 0xc0100000 0xc013a940 0xc013aa50 0xc0107193 system_call+0x33 kernel .text 0xc0100000 0xc0107160 0xc0107198 ------- 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 24 11:01:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Feb 2003 11:01:23 -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 h1OJ1H3v031535 for ; Mon, 24 Feb 2003 11:01:18 -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 h1OJ1BoT025390; Mon, 24 Feb 2003 11:01:11 -0800 From: "l.a walsh" To: "'Chris Wedgwood'" Cc: "'Eric Sandeen'" , Subject: RE: been a while before i could get back to this.. Date: Mon, 24 Feb 2003 11:01:11 -0800 Message-ID: <000101c2dc37$18c3eac0$1403a8c0@sc.tlinx.org> 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.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-reply-to: <20030224093724.GA13363@f00f.org> Importance: Normal X-archive-position: 2886 X-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: 2811 Lines: 82 > From: Chris Wedgwood [mailto:cw@f00f.org] > p.s. your MUA send garbage charactaers at times === MUA uses UTF-8 -- mostly ascii compat, but if your MUA is old, it might not grok UTF-8. > have you tried xfs_repair on / yet? You mean like this (or was there something different you wanted me to try?): > -----Original Message----- > From: linux-xfs-bounce@oss.sgi.com > [mailto:linux-xfs-bounce@oss.sgi.com] On Behalf Of l.a walsh > Sent: February 19, 2003 11:11a > To: 'Seth Mos'; linux-xfs@oss.sgi.com > Subject: RE: been a while before i could get back to this.. > > > 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 Mon Feb 24 11:23:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Feb 2003 11:23:35 -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 h1OJNT3v032251 for ; Mon, 24 Feb 2003 11:23:29 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1OJNTjf032250 for linux-xfs@oss.sgi.com; Mon, 24 Feb 2003 11:23:29 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1OJNS3v032239 for ; Mon, 24 Feb 2003 11:23:28 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1OJDhjk032137; Mon, 24 Feb 2003 11:13:43 -0800 Date: Mon, 24 Feb 2003 11:13:43 -0800 Message-Id: <200302241913.h1OJDhjk032137@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 225] thread deadlock on full fs. X-Bugzilla-Reason: AssignedTo X-archive-position: 2887 X-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: 367 Lines: 17 http://oss.sgi.com/bugzilla/show_bug.cgi?id=225 ------- Additional Comments From stephy32@videotron.ca 2003-02-24 11:13 ------- Created an attachment (id=65) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=65&action=view) .config used ------- 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 24 11:30:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Feb 2003 11:30:49 -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 h1OJUO3v000731 for ; Mon, 24 Feb 2003 11:30:25 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 7C08C186B158; Mon, 24 Feb 2003 11:30:24 -0800 (PST) Date: Mon, 24 Feb 2003 11:30:24 -0800 From: Chris Wedgwood To: "l.a walsh" Cc: "'Eric Sandeen'" , linux-xfs@oss.sgi.com Subject: Re: been a while before i could get back to this.. Message-ID: <20030224193024.GA15867@f00f.org> References: <20030224093724.GA13363@f00f.org> <000101c2dc37$18c3eac0$1403a8c0@sc.tlinx.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000101c2dc37$18c3eac0$1403a8c0@sc.tlinx.org> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2888 X-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: 376 Lines: 18 On Mon, Feb 24, 2003 at 11:01:11AM -0800, l.a walsh wrote: > MUA uses UTF-8 -- mostly ascii compat, but if your MUA is old, > it might not grok UTF-8. No, my MUA just doesn't spew forth garbage. > You mean like this (or was there something different you wanted > me to try?): > > No modify flag set, skipping filesystem flush and exiting. can you try it R/W ? --cw From owner-linux-xfs@oss.sgi.com Mon Feb 24 14:08:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Feb 2003 14:09:20 -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 h1OM8g3v007487 for ; Mon, 24 Feb 2003 14:08:43 -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 h1OM8bKp027509 for ; Mon, 24 Feb 2003 14:08:37 -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 QAA15645 for ; Mon, 24 Feb 2003 16:08:36 -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 QAA81893 for ; Mon, 24 Feb 2003 16:08:35 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h1P5OS609880 for linux-xfs@oss.sgi.com; Tue, 25 Feb 2003 00:24:28 -0500 Resent-Message-Id: <200302250524.h1P5OS609880@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 QAA93056 for ; Mon, 24 Feb 2003 16:00:43 -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 h1OM0fok14491920 for ; Mon, 24 Feb 2003 14:00:42 -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 h1OLvmET014301 for ; Mon, 24 Feb 2003 22:57:49 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id h1OLvmr9014300 for hch@sgi.com; Mon, 24 Feb 2003 22:57:48 +0100 Date: Mon, 24 Feb 2003 22:57:48 +0100 From: Christoph Hellwig Message-Id: <200302242157.h1OLvmr9014300@lab343.munich.sgi.com> Subject: TAKE - shut up gcc warnings about _lsn_cmp To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Tue, 25 Feb 2003 00:24:28 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 2889 X-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: 388 Lines: 14 We can't inline it when using 2.95 due to a possible miscompilation, but an __attribute__((unused)) at least keeps the compile silent. Date: Mon Feb 24 13:58:09 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:140187a linux/fs/xfs/xfs_log.h - 1.65 From owner-linux-xfs@oss.sgi.com Mon Feb 24 14:39:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Feb 2003 14:40:23 -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 h1OMdj3v008250 for ; Mon, 24 Feb 2003 14:39:46 -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 h1OIARG8015170 for ; Mon, 24 Feb 2003 10:10: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 MAA59654 for ; Mon, 24 Feb 2003 12:10: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 MAA81836 for ; Mon, 24 Feb 2003 12:10:26 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h1P1QJw06668 for linux-xfs@oss.sgi.com; Mon, 24 Feb 2003 20:26:19 -0500 Resent-Message-Id: <200302250126.h1P1QJw06668@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 LAA00970 for ; Mon, 24 Feb 2003 11:58:51 -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 h1OHwnok14401842 for ; Mon, 24 Feb 2003 09:58:50 -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 h1OHtal7023947 for ; Mon, 24 Feb 2003 18:55:36 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id h1OHtaV0023946 for hch@sgi.com; Mon, 24 Feb 2003 18:55:36 +0100 Date: Mon, 24 Feb 2003 18:55:36 +0100 From: Christoph Hellwig Message-Id: <200302241755.h1OHtaV0023946@lab343.munich.sgi.com> Subject: TAKE - flags must be unsigned long To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Mon, 24 Feb 2003 20:26:19 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 2890 X-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: 350 Lines: 13 spin_lock_irqsave must take an ulong, not int. Spotted by Anton Blanchard Date: Mon Feb 24 09:57:46 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:140135a linux/fs/xfs/support/debug.c - 1.17 From owner-linux-xfs@oss.sgi.com Mon Feb 24 15:11:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Feb 2003 15:12:00 -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 h1ONBH3v009167 for ; Mon, 24 Feb 2003 15:11:22 -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 h1ONBCoT027102; Mon, 24 Feb 2003 15:11:12 -0800 From: "l.a walsh" To: "'Chris Wedgwood'" Cc: "'Eric Sandeen'" , Subject: RE: been a while before i could get back to this.. Date: Mon, 24 Feb 2003 15:11:12 -0800 Message-ID: <000801c2dc5a$05f07fd0$1403a8c0@sc.tlinx.org> 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.4510 Importance: Normal In-Reply-To: <20030224193024.GA15867@f00f.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-archive-position: 2891 X-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: 391 Lines: 15 > > can you try it R/W ? --- Um...on the root filesystem?....you don't ask for much, do ya?... xfs_check also comes up 'blank'. But if there is a corruption in my file system but it has worked fine since October (except for xfsdump's), what are the chances that xfs_repair might cause a loss of functionality or data? Not that I have any worry or concerns, mind you...(<*gulp*>). -l From owner-linux-xfs@oss.sgi.com Mon Feb 24 15:15:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Feb 2003 15:15:58 -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 h1ONFP3v009722 for ; Mon, 24 Feb 2003 15:15:26 -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 h1ONFKoT027220; Mon, 24 Feb 2003 15:15:20 -0800 From: "l.a walsh" To: "'Nathan Straz'" Cc: Subject: RE: been a while before i could get back to this.. Date: Mon, 24 Feb 2003 15:15:20 -0800 Message-ID: <000901c2dc5a$99f14b10$1403a8c0@sc.tlinx.org> 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.4510 Importance: Normal In-Reply-To: <20030224160119.GA2145@sgi.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-archive-position: 2892 X-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: 927 Lines: 43 > From: Nathan Straz > Is it always inode 1590? --- Not sure -- first time have actually been able to record message. > Could you print out the inode > information with > xfs_db? --- Any particular commands I should give it? xfs_db: inode 1590 xfs_db: print core.magic = 0x494e core.mode = 0100755 core.version = 1 core.format = 2 (extents) core.nlinkv1 = 0 core.uid = 0 core.gid = 0 core.atime.sec = Sat Oct 19 21:13:21 2002 core.atime.nsec = 845366000 core.mtime.sec = Tue Sep 10 09:51:49 2002 core.mtime.nsec = 000000000 core.ctime.sec = Sat Oct 19 21:20:33 2002 core.ctime.nsec = 655340000 core.size = 15234 core.nblocks = 4 core.extsize = 0 core.nextents = 1 core.naextents = 0 core.forkoff = 0 core.aformat = 2 (extents) core.dmevmask = 0 core.dmstate = 0 core.newrtbm = 0 core.prealloc = 0 core.realtime = 0 core.gen = 1 next_unlinked = null u.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,3693,4,0] From owner-linux-xfs@oss.sgi.com Mon Feb 24 15:31:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Feb 2003 15:31:39 -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 h1ONV53v010309 for ; Mon, 24 Feb 2003 15:31:06 -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 h1ONevkq032199 for ; Mon, 24 Feb 2003 17:40:58 -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 KAA08867; Tue, 25 Feb 2003 10:29: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 KAA04576; Tue, 25 Feb 2003 10:29: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 h1ONRWRD005727; Tue, 25 Feb 2003 10:27:32 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h1ONRVXR005725; Tue, 25 Feb 2003 10:27:31 +1100 Date: Tue, 25 Feb 2003 10:27:31 +1100 From: Nathan Scott To: "l.a walsh" Cc: "'Eric Sandeen'" , linux-xfs@oss.sgi.com Subject: Re: been a while before i could get back to this.. Message-ID: <20030224232731.GC6057@frodo> References: <00c301c2dbbe$b929aaa0$1403a8c0@sc.tlinx.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00c301c2dbbe$b929aaa0$1403a8c0@sc.tlinx.org> User-Agent: Mutt/1.5.3i X-archive-position: 2893 X-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: 2012 Lines: 54 On Sun, Feb 23, 2003 at 08:39:31PM -0800, l.a walsh wrote: > > > > I'm sorry, I'm not following this very well. What exactly > > did you try to do, > > and what happened? And what errors were reported both on the console > > and in the logs? > --- > xfsdump has been broken for me since last october. > It still is with latest patch/kernel and utils: > > These are the local window messages when I tried to dump: > + xfsdump -b 1048576 -m -l 0 -o -L root - / > + su -f -m backup -c 'nice -19 bzip2 >root/root-030220-0-2201.dump.bz2' > xfsdump: using file dump (drive_simple) strategy > xfsdump: version 2.2.6 (dump format 3.0) - Running single-threaded > xfsdump: level 0 dump of ishtar:/ > xfsdump: dump date: Thu Feb 20 22:01:40 2003 > xfsdump: session id: 1dfb2395-0d6c-4132-9ba0-0b41bc30c3c0 > xfsdump: session label: "root" > xfsdump: ino map phase 1: skipping (no subtrees specified) > xfsdump: ino map phase 2: constructing initial dump list > xfsdump: WARNING: failed to get bulkstat information for inode 1590 > xfsdump: syssgi( SGI_FS_BULKSTAT ) on fsroot failed: Input/output error > xfsdump: Dump Status: ERROR > + read fs dev DUMP > ./dumplin: line 19: read: read error: 0: Input/output error > ishtar:root/bin# ls > bash: /bin/ls: Input/output error > > ========= > These are the log messages I saw in the remote syslog: > > Feb 21 00:12:03 ishtar kernel: xfs_inotobp: xfs_imap() returned an error 22 on > sd(8,3). Returning error. > Feb 21 00:12:03 ishtar kernel: xfs_iunlink_remove: xfs_inotobp() returned an > error 22 on sd(8,3). Returning error. > > Hopefully the log above gives some clues? Linda, Can you build a debug XFS kernel (i.e. CONFIG_XFS_DEBUG set) - this will give us more information from xfs_dilocate() -- which looks like the source of your error above (errno 22 == EINVAL, xfs_inotobp calls xfs_imap which can only get errors from xfs_dilocate, which returns EINVAL in several places). An xfs_db 'sb' printout would be useful as well. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Feb 24 15:59:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Feb 2003 16:00:08 -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 h1ONxU3v010941 for ; Mon, 24 Feb 2003 15:59:30 -0800 Received: from sydney.sydney.sgi.com (sydney.sydney.sgi.com [134.14.48.2]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h1P09Mkq002204 for ; Mon, 24 Feb 2003 18:09:23 -0600 Received: from sydney.sgi.com by sydney.sydney.sgi.com via ESMTP (950413.SGI.8.6.12/930416.SGI) for id KAA24844; Tue, 25 Feb 2003 10:58:07 +1100 Message-ID: <3E5AB1A5.1BA10AA9@sydney.sgi.com> Date: Tue, 25 Feb 2003 10:58:29 +1100 From: Mike Grayson Organization: Silicon Graphics X-Mailer: Mozilla 4.79C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS and RH8 failing install Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2894 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mikeg@sydney.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1177 Lines: 42 Hi Guys. Just a quick question. Just donwloaded the SGI XFS RH8 inst image. Copied to CD all OK. When I install all goes well until the end of the 1st RH CD. It then asks me to insert "cd6", no matter what I do or which type of install I do,i.e Server desktop etc. I dont have this CD and as from what I can tell there isn't really a cd6 ( apart from the Manuals ) can you shed any light on this. This is being installed on an SGI 1200. Which is giving me some other issues. After failing with the above. I tried to install RH8 standard ext3 and format the disk etc. That then only needed disk 1 and all went OK. But on reboot it fails at the SCSI controller. Many thanks for any help. Mike -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mike Grayson SGI Australia NSW Customer Support 85 Waterloo Road E-Mail mikeg@sgi.com North Ryde Sydney NSW 2113 Australia SGI VNET 527-9508 Tel +61 (0)2 8875 9500 Fax + 61 (0)2 8875 9481 Customer Support Center 1-800-818549 or austac@sgi.com Visit SGI Australia at - http://www.sgi.com.au ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-linux-xfs@oss.sgi.com Mon Feb 24 16:03:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Feb 2003 16:03:43 -0800 (PST) Received: from esds.vss.fsi.com (adsl-66-136-174-212.dsl.stlsmo.swbell.net [66.136.174.212]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1P0393v011433 for ; Mon, 24 Feb 2003 16:03:10 -0800 Received: from mosix (mosix [198.51.27.89]) by esds.vss.fsi.com (8.9.1a/8.9.1) with ESMTP id SAA12570; Mon, 24 Feb 2003 18:03:02 -0600 (CST) Subject: Re: XFS and RH8 failing install From: Matt Schillinger To: Mike Grayson Cc: linux-xfs@oss.sgi.com In-Reply-To: <3E5AB1A5.1BA10AA9@sydney.sgi.com> References: <3E5AB1A5.1BA10AA9@sydney.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 24 Feb 2003 18:05:14 -0600 Message-Id: <1046131515.21169.99.camel@mosix> Mime-Version: 1.0 X-archive-position: 2895 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mschilli@vss.fsi.com Precedence: bulk X-list: linux-xfs Content-Length: 1482 Lines: 56 Disc 6 is the XFS boot cd. Matt Schillinger mschilli@vss.fsi.com On Mon, 2003-02-24 at 17:58, Mike Grayson wrote: > Hi Guys. > > Just a quick question. > > Just donwloaded the SGI XFS RH8 inst image. > Copied to CD all OK. > > When I install all goes well until the end of the 1st RH CD. It then > asks me to insert "cd6", no matter what I do or which type of install I > do,i.e Server desktop etc. > > I dont have this CD and as from what I can tell there isn't really a cd6 > ( apart from the Manuals ) can you shed any light on this. > > This is being installed on an SGI 1200. > Which is giving me some other issues. > After failing with the above. > I tried to install RH8 standard ext3 and format the disk etc. > That then only needed disk 1 and all went OK. > But on reboot it fails at the SCSI controller. > > Many thanks for any help. > > Mike > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Mike Grayson > SGI Australia NSW Customer Support > 85 Waterloo Road E-Mail mikeg@sgi.com > North Ryde > Sydney NSW 2113 > Australia SGI VNET 527-9508 > Tel +61 (0)2 8875 9500 Fax + 61 (0)2 8875 9481 > Customer Support Center 1-800-818549 or austac@sgi.com > > Visit SGI Australia at - http://www.sgi.com.au > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > -- Matt Schillinger System Administrator FlightSafety International mschilli@vss.fsi.com 314-551-8403 From owner-linux-xfs@oss.sgi.com Mon Feb 24 16:06:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Feb 2003 16:07:11 -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 h1P06c3v012632 for ; Mon, 24 Feb 2003 16:06:38 -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 h1P06WG8017428 for ; Mon, 24 Feb 2003 16:06:33 -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 SAA19891; Mon, 24 Feb 2003 18:06:32 -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 SAA27008; Mon, 24 Feb 2003 18:06:32 -0600 (CST) Subject: Re: XFS and RH8 failing install From: Eric Sandeen To: Mike Grayson Cc: linux-xfs@oss.sgi.com In-Reply-To: <3E5AB1A5.1BA10AA9@sydney.sgi.com> References: <3E5AB1A5.1BA10AA9@sydney.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 24 Feb 2003 18:04:16 -0600 Message-Id: <1046131456.1607.10.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 2896 X-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: 467 Lines: 15 CD6 is the SGI install disc... we used to explicitly ask for it by that name, but I guess that code got dropped this time. Try that CD, and see what happens... -Eric > When I install all goes well until the end of the 1st RH CD. It then > asks me to insert "cd6", no matter what I do or which type of install I > do,i.e Server desktop etc. -- 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 24 16:12:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Feb 2003 16:12:44 -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 h1P0CA3v013913 for ; Mon, 24 Feb 2003 16:12:10 -0800 Received: from austin.mkp.net (rover.mkp.net [209.217.122.9]) by jaguar.mkp.net (Postfix) with ESMTP id 17B621781B; Mon, 24 Feb 2003 19:12:08 -0500 (EST) Received: by austin.mkp.net (Postfix, from userid 1654) id 13EF84448F; Mon, 24 Feb 2003 19:15:31 -0500 (EST) To: Mike Grayson Cc: linux-xfs@oss.sgi.com Subject: Re: XFS and RH8 failing install From: "Martin K. Petersen" Organization: mkp.net References: <3E5AB1A5.1BA10AA9@sydney.sgi.com> Date: 24 Feb 2003 19:15:30 -0500 In-Reply-To: <3E5AB1A5.1BA10AA9@sydney.sgi.com> 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: 2897 X-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: 715 Lines: 22 >>>>> "Mike" == Mike Grayson writes: Mike> I dont have this CD and as from what I can tell there isn't Mike> really a cd6 ( apart from the Manuals ) can you shed any light Mike> on this. Disc 6 is the XFS CD. Mike> This is being installed on an SGI 1200. Which is giving me some Mike> other issues. After failing with the above. I tried to install Mike> RH8 standard ext3 and format the disk etc. That then only Mike> needed disk 1 and all went OK. But on reboot it fails at the Mike> SCSI controller. Your BIOS interrupt routing table is broken and intel won't fix it. Try adding either "apic" or "noapic" to the kernel command line. -- Martin K. Petersen http://mkp.net/ From owner-linux-xfs@oss.sgi.com Mon Feb 24 16:26:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Feb 2003 16:27:09 -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 h1P0Qa3v014540 for ; Mon, 24 Feb 2003 16:26:36 -0800 Received: from sydney.sydney.sgi.com (sydney.sydney.sgi.com [134.14.48.2]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h1P0aRkq004645 for ; Mon, 24 Feb 2003 18:36:28 -0600 Received: from mario.sydney.sgi.com by sydney.sydney.sgi.com via ESMTP (950413.SGI.8.6.12/930416.SGI) id LAA26026; Tue, 25 Feb 2003 11:25:12 +1100 Received: from sgi.com (dhcp12.sydney.sgi.com [134.14.48.191]) by mario.sydney.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id LAA90019; Tue, 25 Feb 2003 11:25:12 +1100 (AEDT) Message-ID: <3E5AE31C.BF5B6A89@sgi.com> Date: Tue, 25 Feb 2003 11:29:32 +0800 From: Mike Grayson Organization: SGI X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: "Martin K. Petersen" CC: linux-xfs@oss.sgi.com Subject: Re: XFS and RH8 failing install References: <3E5AB1A5.1BA10AA9@sydney.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2898 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mikeg@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1297 Lines: 50 Hi All Thanks for getting back to me so quickly. I thought I had tried that one but will try it again. Martin. As for your suggestion could you please explaing a little more on how I do your suggestion. Many thanks Mike "Martin K. Petersen" wrote: > >>>>> "Mike" == Mike Grayson writes: > > Mike> I dont have this CD and as from what I can tell there isn't > Mike> really a cd6 ( apart from the Manuals ) can you shed any light > Mike> on this. > > Disc 6 is the XFS CD. > > Mike> This is being installed on an SGI 1200. Which is giving me some > Mike> other issues. After failing with the above. I tried to install > Mike> RH8 standard ext3 and format the disk etc. That then only > Mike> needed disk 1 and all went OK. But on reboot it fails at the > Mike> SCSI controller. > > Your BIOS interrupt routing table is broken and intel won't fix it. > > Try adding either "apic" or "noapic" to the kernel command line. > > -- > Martin K. Petersen http://mkp.net/ -- Mike Grayson SGI Sydney Australia NSW Customer Support 85 Waterloo Rd E-Mail mikeg@sydney.sgi.com Sydney Australia SGI Vnet 527-9508 2113 Tel +61 2 8875 9508 Fax +61 2 8875 9481 Customer Support Centre 1-800-818549 or austac@sgi.com Visit SGI Australia - http://www.sgi.com/global/anz From owner-linux-xfs@oss.sgi.com Mon Feb 24 16:37:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Feb 2003 16:38:27 -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 h1P0br3v015368 for ; Mon, 24 Feb 2003 16:37:53 -0800 Received: from austin.mkp.net (rover.mkp.net [209.217.122.9]) by jaguar.mkp.net (Postfix) with ESMTP id 4538A1781B; Mon, 24 Feb 2003 19:37:52 -0500 (EST) Received: by austin.mkp.net (Postfix, from userid 1654) id A209E4448F; Mon, 24 Feb 2003 19:41:14 -0500 (EST) To: Mike Grayson Cc: linux-xfs@oss.sgi.com Subject: Re: XFS and RH8 failing install From: "Martin K. Petersen" Organization: mkp.net References: <3E5AB1A5.1BA10AA9@sydney.sgi.com> <3E5AE31C.BF5B6A89@sgi.com> Date: 24 Feb 2003 19:41:14 -0500 In-Reply-To: <3E5AE31C.BF5B6A89@sgi.com> 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: 2899 X-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: 402 Lines: 15 >>>>> "Mike" == Mike Grayson writes: Mike> As for your suggestion could you please explaing a little more Mike> on how I do your suggestion. I don't know if you are using grub or lilo. If you are using lilo, just type "linux noapic" at the lilo: prompt. If you are using grub, there's an option to edit the parameters in the boot menu. -- Martin K. Petersen http://mkp.net/ From owner-linux-xfs@oss.sgi.com Mon Feb 24 16:49:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Feb 2003 16: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 h1P0n83v015853 for ; Mon, 24 Feb 2003 16:49:09 -0800 Received: from sydney.sydney.sgi.com (sydney.sydney.sgi.com [134.14.48.2]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h1P0n2Kp021048 for ; Mon, 24 Feb 2003 16:49:02 -0800 Received: from mario.sydney.sgi.com by sydney.sydney.sgi.com via ESMTP (950413.SGI.8.6.12/930416.SGI) id LAA26804; Tue, 25 Feb 2003 11:47:47 +1100 Received: from sgi.com (dhcp12.sydney.sgi.com [134.14.48.191]) by mario.sydney.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id LAA71448; Tue, 25 Feb 2003 11:47:46 +1100 (AEDT) Message-ID: <3E5AE866.2BCC0647@sgi.com> Date: Tue, 25 Feb 2003 11:52:06 +0800 From: Mike Grayson Organization: SGI X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: "Martin K. Petersen" CC: linux-xfs@oss.sgi.com Subject: Re: XFS and RH8 failing install References: <3E5AB1A5.1BA10AA9@sydney.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2900 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mikeg@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1333 Lines: 47 OK. Thought that I had tried that one. What happens is that all goes well until it asks for the "disc 6" I install the xfs install cd as suggested. press the OK button and NOTHING. The buttong stays greyed and no disk activity from either the CD or HD. Mike "Martin K. Petersen" wrote: > >>>>> "Mike" == Mike Grayson writes: > > Mike> I dont have this CD and as from what I can tell there isn't > Mike> really a cd6 ( apart from the Manuals ) can you shed any light > Mike> on this. > > Disc 6 is the XFS CD. > > Mike> This is being installed on an SGI 1200. Which is giving me some > Mike> other issues. After failing with the above. I tried to install > Mike> RH8 standard ext3 and format the disk etc. That then only > Mike> needed disk 1 and all went OK. But on reboot it fails at the > Mike> SCSI controller. > > Your BIOS interrupt routing table is broken and intel won't fix it. > > Try adding either "apic" or "noapic" to the kernel command line. > > -- > Martin K. Petersen http://mkp.net/ -- Mike Grayson SGI Sydney Australia NSW Customer Support 85 Waterloo Rd E-Mail mikeg@sydney.sgi.com Sydney Australia SGI Vnet 527-9508 2113 Tel +61 2 8875 9508 Fax +61 2 8875 9481 Customer Support Centre 1-800-818549 or austac@sgi.com Visit SGI Australia - http://www.sgi.com/global/anz From owner-linux-xfs@oss.sgi.com Mon Feb 24 17:15:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Feb 2003 17:16:19 -0800 (PST) Received: from hotmail.com (f54.sea2.hotmail.com [207.68.165.54]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1P1Fk3v016566 for ; Mon, 24 Feb 2003 17:15:47 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 24 Feb 2003 17:15:41 -0800 Received: from 208.244.233.175 by sea2fd.sea2.hotmail.msn.com with HTTP; Tue, 25 Feb 2003 01:15:41 GMT X-Originating-IP: [208.244.233.175] From: "Rick Smith" To: linux-xfs@oss.sgi.com Subject: Re: [Bug 225] thread deadlock on full fs. Date: Mon, 24 Feb 2003 17:15:41 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Feb 2003 01:15:41.0812 (UTC) FILETIME=[6A050340:01C2DC6B] X-archive-position: 2901 X-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: 8081 Lines: 207 I am experiencing the same problem with write/rm process hanging. I have included my earlier correspondence (including backtraces) and they look very similar to the bug 225 posted in bugzilla. My problem manifests itself as one write/rm thread hanging and blocking all others, even across two completely independent XFS filesystems. I am using software raid0 and the 2.4.20-xfs kernel. Rick Smith >From: "Richard Smith" >Reply-To: "Richard Smith" >To: "Russell Cattelan" ,"Rick Smith" > >CC: ,, >Subject: Re: rm hanging intermittently >Date: Fri, 17 Jan 2003 21:52:29 -0800 > >Russell, > Below are the bdflush, kswapd, kupdated and pagebufd backtraces from >the >lastest hanging process. They all seem to be paused in the same place. If I >kill the hung rm process, everyone wakes back up and the system continues >normally. > Where do I create a new bugzilla bug? Thanks for your help. > >Rick > >[2]kdb> btp 8 >0xf7cd0000 00000008 00000001 0 002 stop 0xf7cd0370 bdflush >ESP EIP Function (args) >0xf7cd1f84 0xc0116063 schedule+0x493 (0x0, 0xf7cd0000, 0xc040d538, >0xc040d538, 0x1f4) > kernel .text 0xc0100000 0xc0115bd0 >0xc0116120 >0xf7cd1fc4 0xc01164ca interruptible_sleep_on+0x4a (0x10f00, 0xf7ffbfb8) > kernel .text 0xc0100000 0xc0116480 >0xc0116500 >0xf7cd1fe4 0xc013e6b7 bdflush+0xc7 > kernel .text 0xc0100000 0xc013e5f0 >0xc013e6c0 >0xf7cd1ff4 0xc0107296 kernel_thread+0x26 > kernel .text 0xc0100000 0xc0107270 >0xc01072a0 >[2]kdb> go > >[0]kdb> btp 7 >0xf7cd4000 00000007 00000001 0 000 stop 0xf7cd4370 kswapd >ESP EIP Function (args) >0xf7cd5f94 0xc0116063 schedule+0x493 (0x0, 0xf7cd4000, 0xc040cad4, >0xc040cad4, 0x10f00) > kernel .text 0xc0100000 0xc0115bd0 >0xc0116120 >0xf7cd5fd4 0xc0132d66 kswapd+0x86 > kernel .text 0xc0100000 0xc0132ce0 >0xc0132d96 >0xf7cd5ff4 0xc0107296 kernel_thread+0x26 > kernel .text 0xc0100000 0xc0107270 >0xc01072a0 >[0]kdb> go > >[3]kdb> btp 9 >0xf7cce000 00000009 00000001 0 003 stop 0xf7cce370 kupdated >ESP EIP Function (args) >0xf7ccff68 0xc0116063 schedule+0x493 (0xf7ccffac, 0xc04abd04, 0xc044a7fc, >0x1bc3472, 0xf7cce000) > kernel .text 0xc0100000 0xc0115bd0 >0xc0116120 >0xf7ccffa8 0xc0115b1e schedule_timeout+0x7e (0x0, 0x10f00, 0xf7ffbfac, >0xc0105000) > kernel .text 0xc0100000 0xc0115aa0 >0xc0115b40 >0xf7ccffdc 0xc013e764 kupdate+0xa4 > kernel .text 0xc0100000 0xc013e6c0 >0xc013e800 >0xf7ccfff4 0xc0107296 kernel_thread+0x26 > kernel .text 0xc0100000 0xc0107270 >0xc01072a0 >[3]kdb> go > >[2]kdb> btp 10 >0xf7c98000 00000010 00000001 0 002 stop 0xf7c98370 pagebufd >ESP EIP Function (args) >0xf7c99f48 0xc0116063 schedule+0x493 (0x0, 0xf7c98000, 0xc04130e8, >0xc04130e8, 0xf7c99fc0) > kernel .text 0xc0100000 0xc0115bd0 >0xc0116120 >0xf7c99f88 0xc01164ca interruptible_sleep_on+0x4a (0xf7c99fc0, 0xf7c99fc0, >0xf7c99fc0, 0xf7c98000, 0xf7c99fb8) > kernel .text 0xc0100000 0xc0116480 >0xc0116500 >0xf7c99fa8 0xc02044a3 pagebuf_daemon+0xd3 > kernel .text 0xc0100000 0xc02043d0 >0xc0204640 >0xf7c99ff4 0xc0107296 kernel_thread+0x26 > kernel .text 0xc0100000 0xc0107270 >0xc01072a0 >[2]kdb> go > >----- Original Message ----- >From: "Russell Cattelan" >To: "Rick Smith" >Cc: ; ; ; > >Sent: Wednesday, January 15, 2003 1:46 PM >Subject: RE: rm hanging intermittently > > > > Before this gets lost can you open a bug in bugzilla and > > add this BT to it. > > > > And actually a bta (back trace all) would probably be more helpful > > since it usually informative to see what the kernel threads bdflush > > kswapd, kupdated, and the pagebuf daemons are doing. > > > > On Wed, 2003-01-15 at 14:14, Rick Smith wrote: > > > Eric, > > > I was able to successfully capture a backtrace of the hanging rm > > > problem today. It looks like it (and several other processes) are >stuck >in > > > the schedule() function. After searching the mailing list archive, >there > > > were several other similar problems concerning deadlock, but the >closest >was > > > posted by Matthew Wilcox at debian on 10-30-02 with the subject >"unlink > > > deadlock". The backtrace that he posted is quite similar to mine and >we >are > > > both using raid 0. I, however, am not using IA-64 architecture. > > > For me the problem seems to happen when there are multiple writes >(to > > > two different XFS partitions) very close to each other. Has this >deadlock > > > been addressed in kernels later than 2.4.20-rc1-xfs? Thanks for your >help. > > > The backtrace follows: > > > > > > [2]kdb> btp 18758 > > > 0xd5812000 00018758 00018739 0 002 stop 0xd5812370 rm > > > ESP EIP Function (args) > > > 0xd5813d38 0xc0116063 schedule+0x493 (0x1, 0xd5812000, 0xf7c3ad8c, > > > 0xf7c3ad8c, 0xf7580700) > > > kernel .text 0xc0100000 0xc0115bd0 >0xc0116120 > > > 0xd5813d78 0xc0107828 __down+0x68 > > > kernel .text 0xc0100000 0xc01077c0 >0xc0107890 > > > 0xd5813d94 0xc01079d4 __down_failed+0x8 (0x33c, 0xd5813df8, >0xf711f3cc, > > > 0xd5813dfc, 0xc01ec543) > > > kernel .text 0xc0100000 0xc01079cc >0xc01079d8 > > > 0xd5813da4 0xc01ee0eb .text.lock.xfs_log+0xdb > > > kernel .text 0xc0100000 0xc01ee010 >0xc01ee250 > > > 0xd5813da4 0xc01eccb2 xlog_state_get_iclog_space+0x62 (0xf7c3ad80, >0x33c, > > > 0xd5813df8, 0xf711f3cc, 0xd5813dfc) > > > kernel .text 0xc0100000 0xc01ecc50 >0xc01ecda0 > > > 0xd5813db8 0xc01ec543 xlog_write+0x153 (0xf6ff8c00, 0xd5813e68, 0xc, > > > 0xf711f3cc, 0xdf8b2c5c) > > > kernel .text 0xc0100000 0xc01ec3f0 >0xc01ec800 > > > 0xd5813e18 0xc01eb51c xfs_log_write+0x3c (0xf6ff8c00, 0xd5813e68, 0xc, > > > 0xf711f3cc, 0xdf8b2c5c) > > > kernel .text 0xc0100000 0xc01eb4e0 >0xc01eb550 > > > 0xd5813e3c 0xc01f7b24 xfs_trans_commit+0x184 (0xdf8b2c10, 0x4, 0x0, > > > 0xd5813f2c, 0x11) > > > kernel .text 0xc0100000 0xc01f79a0 >0xc01f7c50 > > > 0xd5813efc 0xc01fe6b8 xfs_remove+0x398 (0xd8c876d8, 0xd8c85580, 0x0) > > > kernel .text 0xc0100000 0xc01fe320 >0xc01fe790 > > > 0xd5813f54 0xc0209fbe linvfs_unlink+0x1e (0xd8c86da0, 0xd8c85580) > > > kernel .text 0xc0100000 0xc0209fa0 >0xc020a000 > > > 0xd5813f70 0xc0145d35 vfs_unlink+0x135 (0xd8c86da0, 0xd8c85580, >0xd8c8e180, > > > 0xf7cd2e40, 0xf2df9000) > > > kernel .text 0xc0100000 0xc0145c00 >0xc0145da0 > > > 0xd5813f8c 0xc0145e29 sys_unlink+0x89 (0x8053dab, 0x1, 0x0, 0x8053dab, >0x0) > > > kernel .text 0xc0100000 0xc0145da0 >0xc0145e90 > > > 0xd5813fc4 0xc0108c2b system_call+0x33 > > > kernel .text 0xc0100000 0xc0108bf8 >0xc0108c30 > > > [2]kdb> go > > > > > > Rick Smith > > > > > > _________________________________________________________________ > > > MSN 8 with e-mail virus protection service: 2 months FREE* > > > http://join.msn.com/?page=features/virus > > -- > > Russell Cattelan _________________________________________________________________ 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 Mon Feb 24 18:53:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Feb 2003 18:54:16 -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 h1P2rg3v018173 for ; Mon, 24 Feb 2003 18:53:42 -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 h1P205oB007060; Mon, 24 Feb 2003 18:00:05 -0800 From: "LA Walsh" To: "'Nathan Scott'" Cc: "'Eric Sandeen'" , Subject: RE: been a while before i could get back to this.. Date: Mon, 24 Feb 2003 17:58:27 -0800 Message-ID: <000001c2dc71$634bea90$1403a8c0@sc.tlinx.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_01C2DC2E.552A3130" 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 Importance: Normal In-Reply-To: <20030224232731.GC6057@frodo> X-archive-position: 2902 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: law@tlinx.org Precedence: bulk X-list: linux-xfs Content-Length: 20052 Lines: 408 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C2DC2E.552A3130 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Redid the mess w/debug and an 'strace' dumping off to a synchronous NFS mou= nted partition while "sync" was executing in 'forloop' on 2ndary console. this time instead of doing dismount on my root FS, it only dumped me into K= DB... such a deal!...too bad I don't have serial console setup....did a continue after it died though, and did get more output.... strace output is attached, ishtar (system under te^h^hstress) syslog says: Feb 24 17:37:05 ishtar su: (to backup) root on /dev/tty1 Feb 24 17:37:05 ishtar kernel: XFS assertion failed: INT_GET(agi->agi_unlinked[bucket_index], ARCH_CONVERT) !=3D NULLAGINO, file: xfs_inode.c, line: 1937 Feb 24 17:37:05 ishtar kernel: kernel BUG at debug.c:55! Feb 24 17:37:05 ishtar kernel: invalid operand: 0000 Feb 24 17:37:05 ishtar kernel: sg Feb 24 17:37:05 ishtar kernel: CPU: 0 Feb 24 17:37:05 ishtar kernel: EIP: 0010:[assfail+39/64] Not tainted Feb 24 17:37:05 ishtar kernel: EIP: 0010:[] Not tainted Feb 24 17:37:05 ishtar kernel: EFLAGS: 00010282 Feb 24 17:37:05 ishtar kernel: EIP is at assfail+0x27/0x40 [kernel] Feb 24 17:37:05 ishtar kernel: eax: 00000079 ebx: f7d48400 ecx: 00000000 edx: c0472c9c Feb 24 17:37:05 ishtar kernel: esi: f7d83800 edi: 00000001 ebp: f6115c00 esp: f6115bf0 Feb 24 17:37:05 ishtar kernel: ds: 0018 es: 0018 ss: 0018 Feb 24 17:37:05 ishtar kernel: Process xfsdump (pid: 3687, stackpage=3Df611= 5000) Feb 24 17:37:05 ishtar kernel: Stack: c03a5320 c039fb80 c0389101 00000791 f6115c64 c0216ee1 c039fb80 c0389101 Feb 24 17:37:05 ishtar kernel: 00000791 00000783 c0389101 00000064 00000000 f6115c54 000000f0 f6115c4c Feb 24 17:37:05 ishtar kernel: 00000027 00000627 00000000 f7d48400 f7c721bc f6115c64 c0238c93 f7c721bc Feb 24 17:37:05 ishtar kernel: Call Trace: Feb 24 17:37:05 ishtar kernel: [xfs_iunlink_remove+1649/1760] xfs_iunlink_remove+0x671/0x6e0 [kernel] Feb 24 17:37:05 ishtar kernel: [] xfs_iunlink_remove+0x671/0x6e0 [kernel] Feb 24 17:37:05 ishtar kernel: [xfs_trans_add_item+115/544] xfs_trans_add_item+0x73/0x220 [kernel] Feb 24 17:37:05 ishtar kernel: [] xfs_trans_add_item+0x73/0x220 [kernel] Feb 24 17:37:05 ishtar kernel: [xfs_ifree+47/640] xfs_ifree+0x2f/0x280 [ke= rnel] Feb 24 17:37:05 ishtar kernel: [] xfs_ifree+0x2f/0x280 [kernel] Feb 24 17:37:05 ishtar kernel: [xfs_inactive+869/1680] xfs_inactive+0x365/= 0x690 [kernel] Feb 24 17:37:05 ishtar kernel: [] xfs_inactive+0x365/0x690 [kern= el] Feb 24 17:37:05 ishtar kernel: [vn_rele+310/320] vn_rele+0x136/0x140 [kern= el] Feb 24 17:37:05 ishtar kernel: [] vn_rele+0x136/0x140 [kernel] Feb 24 17:37:05 ishtar kernel: [linvfs_clear_inode+25/48] linvfs_clear_inode+0x19/0x30 [kernel] Feb 24 17:37:05 ishtar kernel: [] linvfs_clear_inode+0x19/0x30 [kernel] Feb 24 17:37:05 ishtar kernel: [clear_inode+178/192] clear_inode+0xb2/0xc0 [kernel] Feb 24 17:37:05 ishtar kernel: [] clear_inode+0xb2/0xc0 [kernel] Feb 24 17:37:05 ishtar kernel: [iput+236/704] iput+0xec/0x2c0 [kernel] Feb 24 17:37:05 ishtar kernel: [] iput+0xec/0x2c0 [kernel] Feb 24 17:37:05 ishtar kernel: [xfs_iput+51/64] xfs_iput+0x33/0x40 [kernel] Feb 24 17:37:05 ishtar kernel: [] xfs_iput+0x33/0x40 [kernel] Feb 24 17:37:05 ishtar kernel: [xfs_bulkstat_one+833/1584] xfs_bulkstat_one+0x341/0x630 [kernel] Feb 24 17:37:05 ishtar kernel: [] xfs_bulkstat_one+0x341/0x630 [kernel] Feb 24 17:37:05 ishtar kernel: [xfs_bulkstat_single+85/320] xfs_bulkstat_single+0x55/0x140 [kernel] Feb 24 17:37:05 ishtar kernel: [] xfs_bulkstat_single+0x55/0x140 [kernel] Feb 24 17:37:05 ishtar kernel: [show_regs+70/336] show_regs+0x46/0x150 [ke= rnel] Feb 24 17:37:05 ishtar kernel: [] show_regs+0x46/0x150 [kernel] Feb 24 17:37:05 ishtar kernel: [xfs_ioc_bulkstat+450/528] xfs_ioc_bulkstat+0x1c2/0x210 [kernel] Feb 24 17:37:05 ishtar kernel: [] xfs_ioc_bulkstat+0x1c2/0x210 [kernel] Feb 24 17:37:05 ishtar kernel: [xfs_ioctl+1593/2016] xfs_ioctl+0x639/0x7e0 [kernel] Feb 24 17:37:05 ishtar kernel: [] xfs_ioctl+0x639/0x7e0 [kernel] Feb 24 17:37:05 ishtar kernel: [show_regs+70/336] show_regs+0x46/0x150 [ke= rnel] Feb 24 17:37:05 ishtar kernel: [] show_regs+0x46/0x150 [kernel] Feb 24 17:37:05 ishtar kernel: [wake_up_parent+37/64] wake_up_parent+0x25/= 0x40 [kernel] Feb 24 17:37:05 ishtar kernel: [] wake_up_parent+0x25/0x40 [kern= el] Feb 24 17:37:05 ishtar kernel: [do_notify_parent+138/192] do_notify_parent+0x8a/0xc0 [kernel] Feb 24 17:37:05 ishtar kernel: [] do_notify_parent+0x8a/0xc0 [ke= rnel] Feb 24 17:37:05 ishtar kernel: [linvfs_ioctl+73/224] linvfs_ioctl+0x49/0xe0 [kernel] Feb 24 17:37:05 ishtar kernel: [] linvfs_ioctl+0x49/0xe0 [kernel] Feb 24 17:37:05 ishtar kernel: [show_regs+70/336] show_regs+0x46/0x150 [ke= rnel] Feb 24 17:37:05 ishtar kernel: [] show_regs+0x46/0x150 [kernel] Feb 24 17:37:05 ishtar kernel: [show_regs+70/336] show_regs+0x46/0x150 [ke= rnel] Feb 24 17:37:05 ishtar kernel: [] show_regs+0x46/0x150 [kernel] Feb 24 17:37:05 ishtar kernel: [sys_ioctl+325/800] sys_ioctl+0x145/0x39c [kernel] Feb 24 17:37:05 ishtar kernel: [] sys_ioctl+0x145/0x39c [kernel] Feb 24 17:37:05 ishtar kernel: [show_regs+70/336] show_regs+0x46/0x150 [ke= rnel] Feb 24 17:37:05 ishtar kernel: [] show_regs+0x46/0x150 [kernel] Feb 24 17:37:05 ishtar kernel: [syscall_trace+82/118] syscall_trace+0x52/0= x76 [kernel] Feb 24 17:37:05 ishtar kernel: [] syscall_trace+0x52/0x76 [kerne= l] Feb 24 17:37:05 ishtar kernel: [tracesys+31/35] tracesys+0x1f/0x23 [kernel] Feb 24 17:37:05 ishtar kernel: [] tracesys+0x1f/0x23 [kernel] Feb 24 17:37:05 ishtar kernel: [show_regs+70/336] show_regs+0x46/0x150 [ke= rnel] Feb 24 17:37:05 ishtar kernel: [] show_regs+0x46/0x150 [kernel] Feb 24 17:37:05 ishtar kernel: Feb 24 17:37:05 ishtar kernel: Code: 0f 0b 37 00 0b ad 38 c0 89 ec 5d c3 90= 8d b6 00 00 00 00 8d ---- I take it that this isn't normal, expected, behavior in a modern file system? :-) ------=_NextPart_000_0001_01C2DC2E.552A3130 Content-Type: application/octet-stream; name="strace.log" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="strace.log" execve("/usr/sbin/xfsdump", ["xfsdump", "-b", "1048576", "-m", "-l", "0", "= -o", "-L", "root", "-", "/"], [/* 86 vars */]) =3D 0 uname({sys=3D"Linux", node=3D"ishtar", ...}) =3D 0 brk(0) =3D 0x808fde0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = =3D 0x40013000 open("/etc/ld.so.preload", O_RDONLY) =3D -1 ENOENT (No such file or dire= ctory) open("/etc/ld.so.cache", O_RDONLY) =3D 3 fstat64(3, {st_mode=3DS_IFREG|0644, st_size=3D102578, ...}) =3D 0 mmap2(NULL, 102578, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x40014000 close(3) =3D 0 open("/lib/libhandle.so.1", O_RDONLY) =3D 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\f\0"..., 1024)= =3D 1024 fstat64(3, {st_mode=3DS_IFREG|0644, st_size=3D100854, ...}) =3D 0 mmap2(NULL, 10084, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =3D 0x4002e000 mprotect(0x40030000, 1892, PROT_NONE) =3D 0 mmap2(0x40030000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1= ) =3D 0x40030000 close(3) =3D 0 open("/lib/libattr.so.1", O_RDONLY) =3D 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\n\0"..., 1024)= =3D 1024 fstat64(3, {st_mode=3DS_IFREG|0644, st_size=3D31047, ...}) =3D 0 mmap2(NULL, 10020, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =3D 0x40031000 mprotect(0x40033000, 1828, PROT_NONE) =3D 0 mmap2(0x40033000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1= ) =3D 0x40033000 close(3) =3D 0 open("/lib/libdm.so.0", O_RDONLY) =3D 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\26\0\000"..., 102= 4) =3D 1024 fstat64(3, {st_mode=3DS_IFREG|0644, st_size=3D169509, ...}) =3D 0 mmap2(NULL, 20868, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =3D 0x40034000 mprotect(0x40039000, 388, PROT_NONE) =3D 0 mmap2(0x40039000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x5= ) =3D 0x40039000 close(3) =3D 0 open("/lib/libc.so.6", O_RDONLY) =3D 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\205"..., 1024)= =3D 1024 fstat64(3, {st_mode=3DS_IFREG|0755, st_size=3D1312470, ...}) =3D 0 mmap2(NULL, 1169856, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =3D 0x4003a000 mprotect(0x4014e000, 39360, PROT_NONE) =3D 0 mmap2(0x4014e000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x= 113) =3D 0x4014e000 mmap2(0x40154000, 14784, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_AN= ONYMOUS, -1, 0) =3D 0x40154000 close(3) =3D 0 munmap(0x40014000, 102578) =3D 0 brk(0) =3D 0x808fde0 brk(0x808fe08) =3D 0x808fe08 brk(0x8090000) =3D 0x8090000 open("/usr/share/locale/locale.alias", O_RDONLY) =3D 3 fstat64(3, {st_mode=3DS_IFREG|0644, st_size=3D2601, ...}) =3D 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = =3D 0x40014000 read(3, "# Locale name alias data base.\n#"..., 4096) =3D 2601 brk(0x8091000) =3D 0x8091000 read(3, "", 4096) =3D 0 close(3) =3D 0 munmap(0x40014000, 4096) =3D 0 open("/usr/lib/locale/en_US/LC_IDENTIFICATION", O_RDONLY) =3D 3 fstat64(3, {st_mode=3DS_IFREG|0644, st_size=3D370, ...}) =3D 0 mmap2(NULL, 370, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x40014000 close(3) =3D 0 open("/usr/lib/locale/en_US/LC_MEASUREMENT", O_RDONLY) =3D 3 fstat64(3, {st_mode=3DS_IFREG|0644, st_size=3D28, ...}) =3D 0 mmap2(NULL, 28, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x40015000 close(3) =3D 0 open("/usr/lib/locale/en_US/LC_TELEPHONE", O_RDONLY) =3D 3 fstat64(3, {st_mode=3DS_IFREG|0644, st_size=3D64, ...}) =3D 0 mmap2(NULL, 64, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x40016000 close(3) =3D 0 open("/usr/lib/locale/en_US/LC_ADDRESS", O_RDONLY) =3D 3 fstat64(3, {st_mode=3DS_IFREG|0644, st_size=3D160, ...}) =3D 0 mmap2(NULL, 160, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x40017000 close(3) =3D 0 open("/usr/lib/locale/en_US/LC_NAME", O_RDONLY) =3D 3 fstat64(3, {st_mode=3DS_IFREG|0644, st_size=3D82, ...}) =3D 0 mmap2(NULL, 82, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x40018000 close(3) =3D 0 open("/usr/lib/locale/en_US/LC_PAPER", O_RDONLY) =3D 3 fstat64(3, {st_mode=3DS_IFREG|0644, st_size=3D39, ...}) =3D 0 mmap2(NULL, 39, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x40019000 close(3) =3D 0 open("/usr/lib/locale/en_US/LC_MESSAGES", O_RDONLY) =3D 3 fstat64(3, {st_mode=3DS_IFDIR|0755, st_size=3D28, ...}) =3D 0 close(3) =3D 0 open("/usr/lib/locale/en_US/LC_MESSAGES/SYS_LC_MESSAGES", O_RDONLY) =3D 3 fstat64(3, {st_mode=3DS_IFREG|0644, st_size=3D57, ...}) =3D 0 mmap2(NULL, 57, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x4001a000 close(3) =3D 0 brk(0x8092000) =3D 0x8092000 open("/usr/lib/locale/en_US/LC_MONETARY", O_RDONLY) =3D 3 fstat64(3, {st_mode=3DS_IFREG|0644, st_size=3D291, ...}) =3D 0 mmap2(NULL, 291, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x4001b000 close(3) =3D 0 open("/usr/lib/locale/en_US/LC_TIME", O_RDONLY) =3D 3 fstat64(3, {st_mode=3DS_IFREG|0644, st_size=3D2456, ...}) =3D 0 mmap2(NULL, 2456, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x4001c000 close(3) =3D 0 open("/usr/lib/locale/en_US/LC_NUMERIC", O_RDONLY) =3D 3 fstat64(3, {st_mode=3DS_IFREG|0644, st_size=3D59, ...}) =3D 0 mmap2(NULL, 59, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x4001d000 close(3) =3D 0 open("/usr/lib/locale/en_US.utf8/LC_CTYPE", O_RDONLY) =3D 3 fstat64(3, {st_mode=3DS_IFREG|0644, st_size=3D203336, ...}) =3D 0 mmap2(NULL, 203336, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x40158000 close(3) =3D 0 open("/usr/lib/gconv/gconv-modules.cache", O_RDONLY) =3D 3 fstat64(3, {st_mode=3DS_IFREG|0644, st_size=3D20338, ...}) =3D 0 mmap2(NULL, 20338, PROT_READ, MAP_SHARED, 3, 0) =3D 0x4001e000 close(3) =3D 0 getpid() =3D 3687 getrlimit(0x9, 0xbffff1e0) =3D 0 getrlimit(0x3, 0xbffff1e0) =3D 0 setrlimit(RLIMIT_STACK, {rlim_cur=3D131072*1024, rlim_max=3DRLIM_INFINITY})= =3D 0 getrlimit(0x3, 0xbffff1e0) =3D 0 getrlimit(0x2, 0xbffff1e0) =3D 0 getrlimit(0x1, 0xbffff1e0) =3D 0 setrlimit(RLIMIT_FSIZE, {rlim_cur=3DRLIM_INFINITY, rlim_max=3DRLIM_INFINITY= }) =3D 0 setrlimit(RLIMIT_FSIZE, {rlim_cur=3DRLIM_INFINITY, rlim_max=3DRLIM_INFINITY= }) =3D 0 getrlimit(0x1, 0xbffff1e0) =3D 0 getrlimit(0, 0xbffff1e0) =3D 0 setrlimit(RLIMIT_CPU, {rlim_cur=3DRLIM_INFINITY, rlim_max=3DRLIM_INFINITY})= =3D 0 getrlimit(0, 0xbffff1e0) =3D 0 brk(0x8094000) =3D 0x8094000 getcwd("/root/bin", 4096) =3D 10 stat64("/var/lib/xfsdump", 0xbffff1b0) =3D -1 ENOENT (No such file or dire= ctory) stat64("/var/xfsdump", {st_mode=3DS_IFDIR|0755, st_size=3D22, ...}) =3D 0 geteuid32() =3D 0 getpid() =3D 3687 open("/usr/share/locale/en_US/LC_MESSAGES/xfsdump.mo", O_RDONLY) =3D -1 ENO= ENT (No such file or directory) open("/usr/share/locale/en/LC_MESSAGES/xfsdump.mo", O_RDONLY) =3D -1 ENOENT= (No such file or directory) getpid() =3D 3687 write(2, "xfsdump: ", 9) =3D 9 write(2, "using file dump (drive_simple) s"..., 40) =3D 40 mmap2(NULL, 270336, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)= =3D 0x4018a000 getpid() =3D 3687 write(2, "xfsdump: ", 9) =3D 9 write(2, "version 2.2.6 (dump format 3.0)", 31) =3D 31 write(2, " - Running single-threaded\n", 27) =3D 27 time(NULL) =3D 1046137025 open("/etc/hostid", O_RDONLY|O_LARGEFILE) =3D -1 ENOENT (No such file or di= rectory) open("/etc/hostid", O_RDONLY|O_LARGEFILE) =3D -1 ENOENT (No such file or di= rectory) uname({sys=3D"Linux", node=3D"ishtar", ...}) =3D 0 gettimeofday({1046137025, 650839}, NULL) =3D 0 getpid() =3D 3687 open("/etc/resolv.conf", O_RDONLY) =3D 3 fstat64(3, {st_mode=3DS_IFREG|0644, st_size=3D1019, ...}) =3D 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = =3D 0x40023000 read(3, "#\n# /etc/resolv.conf\n#\n#\n# only "..., 4096) =3D 1019 read(3, "", 4096) =3D 0 close(3) =3D 0 munmap(0x40023000, 4096) =3D 0 socket(PF_UNIX, SOCK_STREAM, 0) =3D 3 connect(3, {sin_family=3DAF_UNIX, path=3D"/var/run/.nscd_socket"}, 110) =3D= 0 write(3, "\2\0\0\0\4\0\0\0\7\0\0\0", 12) =3D 12 write(3, "ishtar\0", 7) =3D 7 read(3, "\0\0\0\0\1\0\0\0\24\0\0\0\2\0\0\0\2\0\0\0\4\0\0\0\1\0\0"..., 32) = =3D 32 readv(3, [{"ishtar.sc.tlinx.org\0", 20}, {"\7\0\0\0\6\0\0\0", 8}, {"\300\25= 0\3\1", 4}], 3) =3D 32 read(3, "ishtar\0Bliss\0", 13) =3D 13 close(3) =3D 0 gettimeofday({1046137025, 652229}, NULL) =3D 0 open("/dev/urandom", O_RDONLY) =3D 3 getpid() =3D 3687 getuid32() =3D 0 gettimeofday({1046137025, 652428}, NULL) =3D 0 gettimeofday({1046137025, 652472}, NULL) =3D 0 read(3, "kQ\212\200\25\217b\346M3\344U\0\300\v\312", 16) =3D 16 uname({sys=3D"Linux", node=3D"ishtar", ...}) =3D 0 open("/etc/mtab", O_RDONLY) =3D 4 brk(0x8096000) =3D 0x8096000 fstat64(4, {st_mode=3DS_IFREG|0644, st_size=3D365, ...}) =3D 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = =3D 0x40023000 read(4, "/dev/sda3 / auto rw 0 0\nproc /pr"..., 4096) =3D 365 read(4, "", 4096) =3D 0 close(4) =3D 0 munmap(0x40023000, 4096) =3D 0 stat64("/", {st_mode=3DS_IFDIR|0755, st_size=3D4096, ...}) =3D 0 open("/", O_RDONLY|O_LARGEFILE) =3D 4 ioctl(4, 0x806c5864, 0xbfffed30) =3D 0 close(4) =3D 0 quotactl(0x5805 /* Q_??? */|USRQUOTA, "/dev/sda3", 0, {0, 0, 0, 0, 0, 0, 0,= 0}) =3D -1 ENOSYS (Function not implemented) quotactl(0x5805 /* Q_??? */|USRQUOTA, "/dev/sda3", 0, {0, 0, 0, 0, 0, 0, 0,= 0}) =3D -1 ENOSYS (Function not implemented) mkdir("/var", 0755) =3D -1 EEXIST (File exists) mkdir("/var/xfsdump", 0755) =3D -1 EEXIST (File exists) stat64("/var/xfsdump/inventory", {st_mode=3DS_IFDIR|0755, st_size=3D4096, .= ..}) =3D 0 open("/var/xfsdump/inventory/dc54b19e-71bd-4016-9e55-db2d54e430a1.InvIndex"= , O_RDONLY|O_LARGEFILE) =3D -1 ENOENT (No such file or directory) close(-2) =3D -1 EBADF (Bad file descriptor) getpid() =3D 3687 write(2, "xfsdump: ", 9) =3D 9 write(2, "level 0 dump of ishtar:/\n", 25) =3D 25 open("/etc/localtime", O_RDONLY) =3D 4 fstat64(4, {st_mode=3DS_IFREG|0644, st_size=3D1017, ...}) =3D 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = =3D 0x40023000 read(4, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0"..., 4096) = =3D 1017 close(4) =3D 0 munmap(0x40023000, 4096) =3D 0 getpid() =3D 3687 write(2, "xfsdump: ", 9) =3D 9 write(2, "dump date: Mon Feb 24 17:37:05 2"..., 36) =3D 36 getpid() =3D 3687 write(2, "xfsdump: ", 9) =3D 9 write(2, "session id: 6b518a80-158f-42e6-8"..., 49) =3D 49 getpid() =3D 3687 write(2, "xfsdump: ", 9) =3D 9 write(2, "session label: \"root\"\n", 22) =3D 22 open("/", O_RDONLY|O_LARGEFILE) =3D 4 fstat64(4, {st_mode=3DS_IFDIR|0755, st_size=3D4096, ...}) =3D 0 open("/", O_RDONLY|O_LARGEFILE) =3D 5 ioctl(5, 0xc01c5868, 0xbfffdda0) =3D 0 statfs("/", {f_type=3D0x58465342, f_bsize=3D4096, f_blocks=3D1440633, f_bfr= ee=3D371924, f_files=3D5767296, f_ffree=3D5580636, f_namelen=3D255}) =3D 0 stat64("/", {st_mode=3DS_IFDIR|0755, st_size=3D4096, ...}) =3D 0 open("/proc/mounts", O_RDONLY) =3D 6 fstat64(6, {st_mode=3DS_IFREG|0444, st_size=3D0, ...}) =3D 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = =3D 0x40023000 read(6, "rootfs / rootfs rw 0 0\n/dev/root"..., 4096) =3D 406 stat64("/", {st_mode=3DS_IFDIR|0755, st_size=3D4096, ...}) =3D 0 close(6) =3D 0 munmap(0x40023000, 4096) =3D 0 mmap2(NULL, 450560, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)= =3D 0x401cc000 brk(0x8099000) =3D 0x8099000 getpid() =3D 3687 write(2, "xfsdump: ", 9) =3D 9 write(2, "ino map phase 1: skipping (no su"..., 50) =3D 50 getpid() =3D 3687 write(2, "xfsdump: ", 9) =3D 9 write(2, "ino map phase 2: constructing in"..., 48) =3D 48 ioctl(4, 0xc0105865, 0xbfffedc0) =3D 0 brk(0x809e000) =3D 0x809e000 ioctl(4, 0xc0105866 +++ killed by SIGSEGV +++ ------=_NextPart_000_0001_01C2DC2E.552A3130-- From owner-linux-xfs@oss.sgi.com Mon Feb 24 20:50:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Feb 2003 20:51:23 -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 h1P4oj3v019434 for ; Mon, 24 Feb 2003 20:50:46 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id F0DB1186B15A; Mon, 24 Feb 2003 20:50:45 -0800 (PST) Date: Mon, 24 Feb 2003 20:50:45 -0800 From: Chris Wedgwood To: "L.A Walsh" Cc: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: been a while before i could get back to this.. Message-ID: <20030225045045.GA18191@f00f.org> References: <20030224193024.GA15867@f00f.org> <000801c2dc5a$05f07fd0$1403a8c0@sc.tlinx.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline In-Reply-To: <000801c2dc5a$05f07fd0$1403a8c0@sc.tlinx.org> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2903 X-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: 3138 Lines: 147 --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Feb 24, 2003 at 03:11:12PM -0800, l.a walsh wrote: > Um...on the root filesystem? yes > ....you don't ask for much, do ya?... nope > xfs_check also comes up 'blank'. sometimes it does, and xfs_repair still finds something todo i'm not sure if this is a past or present bug, but i've seen this on a couple of occasions > But if there is a corruption in my file system but it has worked > fine since October (except for xfsdump's), what are the chances that > xfs_repair might cause a loss of functionality or data? i've not seen xfsdump make things worse --- but i'm only one person with a few machines, so who knows... how about running (as root) the attached program then? it will bulkstat the rootfs and make sure it doesn't barf which i seem to recall xfsdump had problems with --cw --jI8keyz6grp/JLjh Content-Type: text/x-csrc; charset=us-ascii Content-Disposition: attachment; filename="linda-test.c" /* * linda-test.c * * quick hack mangled from other code to make sure this works all * happy for linda * * use this code as you will, no warranty, etc. --- if it breaks, you * get to keep all the peices * * cw@f00f.org * */ #define _GNU_SOURCE #include #include #include #include #include #include #include #include #include #include #include #include #define NINODE (256) int main() { struct timeval before, after; xfs_fsop_bulkreq_t brq; xfs_bstat_t buf[NINODE]; xfs_ino_t lastino = 0; size_t ocount, total = 0; int fd; int i; int ndir = 0, nfdir = 0; int nfile = 0, nffile = 0; if ((fd = open("/", O_RDONLY)) == -1) { perror("open"); exit(1); } printf("stating (please wait)....\n"); gettimeofday(&before, NULL); do { brq.lastip = &lastino; brq.icount = NINODE; brq.ubuffer = buf; brq.ocount = &ocount; if (-1 == ioctl(fd, XFS_IOC_FSBULKSTAT, &brq)) { perror("ioctl"); exit(1); } total += ocount; /* copy useful inodes out, we only care about fragemented files and directories. later, we can prune and directories that have no fragmented files and nlink==2 (ie. no sub directories) */ for (i=0; i 1) nfdir++; } if (S_ISREG(buf[i].bs_mode)) { nfile++; if (buf[i].bs_extents > 1) nffile++; } } } while(ocount); gettimeofday(&after, NULL); printf("\nbulkstat of %d total inodes took %0.3f seconds\n\n", total, ((double)(after.tv_sec - before.tv_sec) + (double)(after.tv_usec - before.tv_usec) / 1000000.0)); printf("Total files: %8d\n", nfile); printf("Total fragmented files: %8d\n", nffile); printf("Total directories: %8d\n", ndir); printf("Total fragmented directories: %8d\n", nfdir); close(fd); return 0; } --jI8keyz6grp/JLjh-- From owner-linux-xfs@oss.sgi.com Mon Feb 24 22:26:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Feb 2003 22:27:31 -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 h1P6Qw3v020660 for ; Mon, 24 Feb 2003 22:26:58 -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 h1P6QpKp006046 for ; Mon, 24 Feb 2003 22:26:52 -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 RAA13302; Tue, 25 Feb 2003 17:25:35 +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 RAA78354; Tue, 25 Feb 2003 17:25:25 +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 h1P6NERD011265; Tue, 25 Feb 2003 17:23:14 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h1P6NDQw011263; Tue, 25 Feb 2003 17:23:13 +1100 Date: Tue, 25 Feb 2003 17:23:13 +1100 From: Nathan Scott To: LA Walsh Cc: "'Eric Sandeen'" , linux-xfs@oss.sgi.com Subject: Re: been a while before i could get back to this.. Message-ID: <20030225062313.GG6057@frodo> References: <20030224232731.GC6057@frodo> <000001c2dc71$634bea90$1403a8c0@sc.tlinx.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000001c2dc71$634bea90$1403a8c0@sc.tlinx.org> User-Agent: Mutt/1.5.3i X-archive-position: 2904 X-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: 2310 Lines: 62 On Mon, Feb 24, 2003 at 05:58:27PM -0800, LA Walsh wrote: > Redid the mess w/debug and an 'strace' dumping off to a synchronous NFS mounted > partition while "sync" was executing in 'forloop' on 2ndary console. > > this time instead of doing dismount on my root FS, it only dumped me into KDB... > such a deal!... Hmmm -- that's the idea with debugging enabled. > too bad I don't have serial console setup....did a continue > after it died though, and did get more output.... > > strace output is attached, ishtar (system under te^h^hstress) syslog says: > > Feb 24 17:37:05 ishtar su: (to backup) root on /dev/tty1 > Feb 24 17:37:05 ishtar kernel: XFS assertion failed: > INT_GET(agi->agi_unlinked[bucket_index], ARCH_CONVERT) != NULLAGINO, file: > xfs_inode.c, line: 1937 OK, so this is in a completely different part of the code to where we were looking before... ugh, not useful. I think we will have to get you to run repair on this, so we can start at least with no known corruption problems. (to run repair on your root you need to boot off a CD, floppy, or some other alternate root). To answer the question Chris was asking, for this case at least, yes xfsdump is doing a bulkstat at this point... > ... > Feb 24 17:37:05 ishtar kernel: [xfs_bulkstat_one+833/1584] > xfs_bulkstat_one+0x341/0x630 [kernel] > Feb 24 17:37:05 ishtar kernel: [] xfs_bulkstat_one+0x341/0x630 > [kernel] > Feb 24 17:37:05 ishtar kernel: [xfs_bulkstat_single+85/320] > xfs_bulkstat_single+0x55/0x140 [kernel] > Feb 24 17:37:05 ishtar kernel: [] xfs_bulkstat_single+0x55/0x140 > [kernel] > Feb 24 17:37:05 ishtar kernel: [xfs_ioc_bulkstat+450/528] > xfs_ioc_bulkstat+0x1c2/0x210 [kernel] > Feb 24 17:37:05 ishtar kernel: [] xfs_ioc_bulkstat+0x1c2/0x210 > [kernel] > Feb 24 17:37:05 ishtar kernel: [xfs_ioctl+1593/2016] xfs_ioctl+0x639/0x7e0 > [kernel] > Feb 24 17:37:05 ishtar kernel: [] xfs_ioctl+0x639/0x7e0 [kernel] > ... > > ---- > I take it that this isn't normal, expected, behavior in a modern file > system? :-) > With debug enabled, basically all bets are off and we're actively trying to crash the system - since your fs had known corruption, this was always going to happen. Guess I should have spelled that out a bit more... ;) cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Feb 24 23:11:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Feb 2003 23:12:32 -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 h1P7Bu3v021348 for ; Mon, 24 Feb 2003 23:11:56 -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 h1P7Bpr5001427; Mon, 24 Feb 2003 23:11:51 -0800 From: "l.a walsh" To: "'Nathan Scott'" Cc: "'Eric Sandeen'" , Subject: RE: been a while before i could get back to this.. Date: Mon, 24 Feb 2003 23:11:46 -0800 Message-ID: <000101c2dc9d$28214380$1403a8c0@sc.tlinx.org> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <20030225062313.GG6057@frodo> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-archive-position: 2905 X-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: 1824 Lines: 48 Hmmm.... xfsdump seems to be running now .... went down to single user unmounted all FS's, but couldn't kill the test program running on /tmp, so to be safe, rebooted into single user...ran xfs_repair ...found about 15 disconnected inodes dating back to around the time I upgraded from SuSE 8.0 -> 8.1. Could be coincidental, but about 7 of the files were also bits of YAST2 output. Rebooted second time -- back up and doing level 0 dumps... So...one of those disconnected inodes was the one mentioned in death message -- that xfsdump died on -- #1590. So couple of questions/observations... Here I had a file system (all the recovered files were dated between 9-sep-2002 -> 12-sep-2002) that, except for being 'undumpable' (not a great thing, mind you) seemed to function just fine as a regular good 'ol file system. Recovered fine on unexpected crashes...etc. So 1) Maybe xfsdump or the 'getbulkstat' operation should be slightly more fault tolerant? Seems like shutting down the file system wasn't the most informative action to take. Perhaps more important (2): it would be REAL helpful if either xfs_repair or xfs_check would return an indication that there is a problem on a mounted filesystem (not necessarily correct the problem, though that would be ideal), but at least give me a way of determining that there is a problem so I can know that I should do a repair (hopefully before the system is taken down by an xfsdump). Mucho Bueno Thanks....though I'm still not sure how I got to where I was at... > With debug enabled, basically all bets are off and we're actively > trying to crash the system - since your fs had known corruption, > this was always going to happen. Guess I should have spelled that > out a bit more... ;) --- Not a prob....I always build with kdb enabled...:-) linda From owner-linux-xfs@oss.sgi.com Tue Feb 25 00:49:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Feb 2003 00:50:16 -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 h1P8nb3v023625 for ; Tue, 25 Feb 2003 00:49:38 -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 h1P8xTkq013341 for ; Tue, 25 Feb 2003 02:59:31 -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 TAA14221; Tue, 25 Feb 2003 19:48:12 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id TAA06130; Tue, 25 Feb 2003 19:48:10 +1100 (EST) Date: Tue, 25 Feb 2003 19:48:10 +1100 From: Nathan Scott To: "l.a walsh" Cc: "'Eric Sandeen'" , linux-xfs@oss.sgi.com Subject: Re: been a while before i could get back to this.. Message-ID: <20030225194810.A908040@wobbly.melbourne.sgi.com> References: <20030225062313.GG6057@frodo> <000101c2dc9d$28214380$1403a8c0@sc.tlinx.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000101c2dc9d$28214380$1403a8c0@sc.tlinx.org>; from xfs@tlinx.org on Mon, Feb 24, 2003 at 11:11:46PM -0800 X-archive-position: 2906 X-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: 886 Lines: 26 On Mon, Feb 24, 2003 at 11:11:46PM -0800, l.a walsh wrote: > Hmmm.... > xfsdump seems to be running now .... Thats good to hear. > So 1) Maybe xfsdump or the 'getbulkstat' operation should > be slightly more fault tolerant? Seems like shutting down > the file system wasn't the most informative action to take. *nod* ... this could possibly be made like some of the directory code which doesn't shutdown, but returns errors back out. > Perhaps more important (2): it would be REAL helpful if > either xfs_repair or xfs_check would return an indication > that there is a problem on a mounted filesystem > (not necessarily correct the problem, though that would be ideal), > but at least give me a way of determining that there is a > problem so I can know that I should do a repair (hopefully before > the system is taken down by an xfsdump). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Feb 25 01:13:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Feb 2003 01:13: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 h1P9D33v024279 for ; Tue, 25 Feb 2003 01:13:03 -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 h1P9CuKp030619 for ; Tue, 25 Feb 2003 01:12:57 -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 h1P9BdBi873996 for ; Tue, 25 Feb 2003 20:11:39 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h1P9BdOb874080 for linux-xfs@oss.sgi.com; Tue, 25 Feb 2003 20:11:39 +1100 (EST) Date: Tue, 25 Feb 2003 20:11:39 +1100 (EST) From: Nathan Scott Message-Id: <200302250911.h1P9BdOb874080@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - attr-2.3.0, add trusted namespace into XFS X-archive-position: 2907 X-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: 2643 Lines: 78 Transition from xfsroot attribute namespace to the more generic trusted namespace which other filesystems are also supporting. * Note: xfsdump and xfsrestore are affected by a change in libattr which deprecates the attribute name prefix "xfsroot", replacing it with the generic "trusted" name. The environment variable COMPAT_XFSROOT can be set in order to preserve the old behavior. Users of new kernels should use this new attr-2.3.0 package. cheers. Date: Tue Feb 25 00:56:46 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:140237a linux/fs/xfs/xfs_attr.h - 1.23 - Fix an incorrect comment regarding attribute error return code (patch from Andreas). linux/fs/xfs/linux/xfs_iops.c - 1.184 - Transition from xfsroot attribute namespace to the more generic trusted namespace which other filesystems are also supporting. Make the error return codes for an unrecognised attribute more consistent with those that other filesystems are using (patch from Andreas). Date: Tue Feb 25 01:06:10 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:140238a cmd/attr/include/libattr.h - 1.1 cmd/attr/examples/Makefile.examples - 1.1 cmd/attr/examples/Makefile - 1.1 cmd/attr/libattr/libattr.h - 1.1 cmd/attr/include/error_context.h - 1.1 cmd/attr/include/Makefile - 1.10 cmd/attr/debian/changelog - 1.30 cmd/attr/man/man2/setxattr.2 - 1.5 cmd/attr/man/man2/removexattr.2 - 1.3 cmd/attr/man/man2/listxattr.2 - 1.5 cmd/attr/man/man2/getxattr.2 - 1.3 cmd/attr/libattr/libattr.c - 1.6 cmd/attr/po/attr.pot - 1.2 cmd/attr/include/config.h.in - 1.3 cmd/attr/po/Makefile - 1.3 cmd/attr/po/de.po - 1.2 - New attr userspace package - transition to the trusted namespace for XFS (no more xfsroot names), add in the new attribute copying routines from Andreas, and also update the license info in the syscall man pages so that other folks can use em too. cmd/attr/libattr/attr_copy_fd.c - 1.1 - Library routine for copying extended attributes between files. cmd/attr/examples/copyattr.c - 1.1 - An example source file showing how to use the attribute copy routines. cmd/attr/libattr/attr_copy_file.c - 1.1 - Library routine for copying extended attributes between files. cmd/attr/configure.in - 1.13 cmd/attr/Makefile - 1.11 cmd/attr/VERSION - 1.28 cmd/attr/doc/CHANGES - 1.36 cmd/attr/libattr/Makefile - 1.10 - Update for extended attribute copying routines. From owner-linux-xfs@oss.sgi.com Tue Feb 25 01:15:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Feb 2003 01:15:38 -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 h1P9F53v024593 for ; Tue, 25 Feb 2003 01:15:05 -0800 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.55.176]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1P9EwKp030908 for ; Tue, 25 Feb 2003 01:14:59 -0800 Received: (from fsgqa@localhost) by bruce.melbourne.sgi.com (8.9.3/8.9.3) id UAA02017 for linux-xfs@oss.sgi.com; Tue, 25 Feb 2003 20:13:57 +1100 Date: Tue, 25 Feb 2003 20:13:57 +1100 From: FSG QA Message-Id: <200302250913.UAA02017@bruce.melbourne.sgi.com> Subject: TAKE - attr QA X-archive-position: 2908 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fsgqa@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 370 Lines: 15 Update QA tests to work with new attribute code (trusted namespace). Date: Tue Feb 25 01:13:13 PST 2003 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/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:140239a cmd/xfstests/062 - 1.17 cmd/xfstests/common.dump - 1.40 cmd/xfstests/062.out - 1.9 From owner-linux-xfs@oss.sgi.com Tue Feb 25 01:34:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Feb 2003 01:34:42 -0800 (PST) Received: from malik.acsalaska.net (malik.slb.nwc.acsalaska.net [209.112.155.41]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1P9YW3v025273 for ; Tue, 25 Feb 2003 01:34:33 -0800 Received: from erbenson.alaska.net (5-pm33.nwc.alaska.net [209.112.159.5]) by malik.acsalaska.net (8.12.7/8.12.7) with ESMTP id h1P9YV9k061363 for ; Tue, 25 Feb 2003 00:34:31 -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 064613A0C for ; Tue, 25 Feb 2003 00:34:29 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id D93844104E2; Tue, 25 Feb 2003 00:34:29 -0900 (AKST) Date: Tue, 25 Feb 2003 00:34:29 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: TAKE - attr-2.3.0, add trusted namespace into XFS Message-ID: <20030225093429.GB27906@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200302250911.h1P9BdOb874080@snort.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jy6Sn24JjFx/iggw" Content-Disposition: inline In-Reply-To: <200302250911.h1P9BdOb874080@snort.melbourne.sgi.com> 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-ACS-Spam-Status: no X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 2909 X-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: 1206 Lines: 38 --jy6Sn24JjFx/iggw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 25, 2003 at 08:11:39PM +1100, Nathan Scott wrote: > Transition from xfsroot attribute namespace to the more generic > trusted namespace which other filesystems are also supporting. >=20 > * Note: xfsdump and xfsrestore are affected by a change in libattr > which deprecates the attribute name prefix "xfsroot", replacing > it with the generic "trusted" name. The environment variable > COMPAT_XFSROOT can be set in order to preserve the old behavior. > Users of new kernels should use this new attr-2.3.0 package. hmm, so what happens when one upgrades the kernel and xfsroot attributes exist on the filesystems ? (they do when a ACL is present iirc). --=20 Ethan Benson http://www.alaska.net/~erbenson/ --jy6Sn24JjFx/iggw 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 iEYEARECAAYFAj5bOKUACgkQJKx7GixEevyAHwCgn4YLaE/HrPQfNUID4/knQ/3l LPgAnRE/OAK7TXG9q+DnjqcNsgzRx4Sc =K0kR -----END PGP SIGNATURE----- --jy6Sn24JjFx/iggw-- From owner-linux-xfs@oss.sgi.com Tue Feb 25 01:44:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Feb 2003 01:44:56 -0800 (PST) Received: from relay.dstl.gov.uk (relay.dera.gov.uk [192.5.29.49]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1P9ip3v025796 for ; Tue, 25 Feb 2003 01:44:52 -0800 Received: (qmail 20611 invoked from network); 25 Feb 2003 09:44:48 +0000 Received: from warlock.dstl.gov.uk (192.5.29.10) by relay.dera.gov.uk with SMTP; 25 Feb 2003 09:44:47 +0000 Subject: Re: [Bug 225] thread deadlock on full fs. From: Tony Gale To: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-CPLtt9JDasFTYZ5zv+T0" Organization: Message-Id: <1046166288.9976.1.camel@syntax.dstl.gov.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 25 Feb 2003 09:44:48 +0000 X-archive-position: 2910 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gale@syntax.dstl.gov.uk Precedence: bulk X-list: linux-xfs Content-Length: 1162 Lines: 39 --=-CPLtt9JDasFTYZ5zv+T0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2003-02-25 at 01:15, Rick Smith wrote: > I am experiencing the same problem with write/rm process hanging. I= =20 > have included my earlier correspondence (including backtraces) and they l= ook=20 > very similar to the bug 225 posted in bugzilla. > My problem manifests itself as one write/rm thread hanging and blocki= ng=20 > all others, even across two completely independent XFS filesystems. I am= =20 > using software raid0 and the 2.4.20-xfs kernel. >=20 This also looks similar to my bug #214 at=20 http://oss.sgi.com/bugzilla/show_bug.cgi?id=3D214 -tony --=-CPLtt9JDasFTYZ5zv+T0 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iQCVAwUAPls7Dx/0GZs/Z0FlAQL1nwQAqXEm4VWF/fCi0myTW0MM2Dy0tKXsGdTK 0evWyT/wTX3lCdvmRJOlPfCV8Osgrt2pLE3V2R8MRfiCTx0FMKS29FJUzMphIits t4yrA5BgAKT7tKaM5858NunyDDn2Nxv/AUUKOqB5w+h6/u1KHooctrF83LSzbqAZ HfEn2XXwCiA= =lMFu -----END PGP SIGNATURE----- --=-CPLtt9JDasFTYZ5zv+T0-- From owner-linux-xfs@oss.sgi.com Tue Feb 25 02:33:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Feb 2003 02:33:40 -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 h1PAXV3v029547 for ; Tue, 25 Feb 2003 02:33:32 -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 h1PAXPKp010673 for ; Tue, 25 Feb 2003 02:33:26 -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 EAA45790; Tue, 25 Feb 2003 04:33:25 -0600 (CST) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-16.corp.sgi.com [134.15.64.16]) by tulip-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id EAA87966; Tue, 25 Feb 2003 04:33:24 -0600 (CST) Subject: Re: TAKE - attr-2.3.0, add trusted namespace into XFS From: Stephen Lord To: Ethan Benson Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030225093429.GB27906@plato.local.lan> References: <200302250911.h1P9BdOb874080@snort.melbourne.sgi.com> <20030225093429.GB27906@plato.local.lan> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 25 Feb 2003 04:32:23 -0600 Message-Id: <1046169145.1367.1.camel@localhost.localdomain> Mime-Version: 1.0 X-archive-position: 2911 X-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: 939 Lines: 22 On Tue, 2003-02-25 at 03:34, Ethan Benson wrote: > On Tue, Feb 25, 2003 at 08:11:39PM +1100, Nathan Scott wrote: > > Transition from xfsroot attribute namespace to the more generic > > trusted namespace which other filesystems are also supporting. > > > > * Note: xfsdump and xfsrestore are affected by a change in libattr > > which deprecates the attribute name prefix "xfsroot", replacing > > it with the generic "trusted" name. The environment variable > > COMPAT_XFSROOT can be set in order to preserve the old behavior. > > Users of new kernels should use this new attr-2.3.0 package. > > hmm, so what happens when one upgrades the kernel and xfsroot > attributes exist on the filesystems ? (they do when a ACL is > present iirc). These name strings do not actually hit the disk at all, internally, xfs strips them off. So all this does is change the string prefix used by xfs to map to the different attribute domains. Steve From owner-linux-xfs@oss.sgi.com Tue Feb 25 02:48:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Feb 2003 02:48: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 h1PAm83v031370 for ; Tue, 25 Feb 2003 02:48:08 -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 h1PAm2Kp013582 for ; Tue, 25 Feb 2003 02:48:02 -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 EAA99709 for ; Tue, 25 Feb 2003 04:48:01 -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 EAA57271 for ; Tue, 25 Feb 2003 04:48:02 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h1PAm1F20177; Tue, 25 Feb 2003 04:48:01 -0600 Message-Id: <200302251048.h1PAm1F20177@jen.americas.sgi.com> Date: Tue, 25 Feb 2003 04:48:01 -0600 Subject: TAKE - initialize the iovec length in symlink cases To: linux-xfs@oss.sgi.com X-archive-position: 2912 X-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: 422 Lines: 16 Date: Tue Feb 25 02:47:27 PST 2003 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.4 Author: lord Merged by: lord Merged mods: 2.4.x-xfs-dev:slinx:134770a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:134770a linux/fs/xfs/linux/xfs_iops.c - 1.185 - Merge of 2.4.x-xfs-dev:slinx:134770a by lord. initialize the iovec length in symlink cases From owner-linux-xfs@oss.sgi.com Tue Feb 25 02:58:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Feb 2003 02:58:58 -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 h1PAwu3v032256 for ; Tue, 25 Feb 2003 02:58:56 -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 h1PAwoKp015664 for ; Tue, 25 Feb 2003 02:58:50 -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 EAA66696 for ; Tue, 25 Feb 2003 04:58:49 -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 EAA90559 for ; Tue, 25 Feb 2003 04:58:50 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h1PAwnG21834; Tue, 25 Feb 2003 04:58:49 -0600 Message-Id: <200302251058.h1PAwnG21834@jen.americas.sgi.com> Date: Tue, 25 Feb 2003 04:58:49 -0600 Subject: TAKE - merge some code from internal tree To: linux-xfs@oss.sgi.com X-archive-position: 2913 X-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: 1889 Lines: 68 If cmn_err is called with a CR character at the end of the input then do not add one. Date: Tue Feb 25 02:52:58 PST 2003 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.4 Author: lord Merged by: lord Merged mods: 2.4.x-xfs-dev:slinx:134299a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:134299a linux/fs/xfs/support/debug.c - 1.18 - Merge of 2.4.x-xfs-dev:slinx:134299a by lord. Avoid double new lines at end of messages Subject: TAKE - remove _KERNEL from the flags used to turn macros into functions Date: Tue Feb 25 02:55:14 PST 2003 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.4 Author: lord Merged by: lord Merged mods: 2.4.x-xfs-dev:slinx:134509a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:134509a linux/fs/xfs/xfs_macros.h - 1.19 - Merge of 2.4.x-xfs-dev:slinx:134509a by lord. remove _KERNEL from the flags used to turn macros into functions Subject: TAKE - rework readdir to be closer to the irix model internally, do all the filldir fixup at the linvfs layer. This is the V2 directory component, the V1 code still needs fixing up. We now return the same directory offsets as Irix does. Date: Tue Feb 25 02:57:48 PST 2003 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.4 Author: lord Merged by: lord Merged mods: 2.4.x-xfs-dev:slinx:134646a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:134646a linux/fs/xfs/xfs_dir2_block.c - 1.27 linux/fs/xfs/xfs_dir2_sf.c - 1.32 linux/fs/xfs/xfs_dir2_leaf.c - 1.29 - Merge of 2.4.x-xfs-dev:slinx:134646a by lord. remove linux specific d_off fixup. linux/fs/xfs/linux/xfs_file.c - 1.83 - Merge of 2.4.x-xfs-dev:slinx:134646a by lord. do directory offset fixup in linvfs_readdir From owner-linux-xfs@oss.sgi.com Tue Feb 25 06:52:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Feb 2003 06:52:40 -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 h1PEqU3v009359 for ; Tue, 25 Feb 2003 06:52:31 -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 h1PF2Pkq006120 for ; Tue, 25 Feb 2003 09:02: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 IAA79804 for ; Tue, 25 Feb 2003 08:52:23 -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 IAA31662 for ; Tue, 25 Feb 2003 08:52:21 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h1PM8EZ11971 for linux-xfs@oss.sgi.com; Tue, 25 Feb 2003 17:08:14 -0500 Resent-Message-Id: <200302252208.h1PM8EZ11971@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 IAA71053 for ; Tue, 25 Feb 2003 08:50:46 -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 h1PEoiok15019528 for ; Tue, 25 Feb 2003 06:50:45 -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 h1PEljET031883 for ; Tue, 25 Feb 2003 15:47:46 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id h1PElj1n031882 for hch@sgi.com; Tue, 25 Feb 2003 15:47:45 +0100 Date: Tue, 25 Feb 2003 15:47:45 +0100 From: Christoph Hellwig Message-Id: <200302251447.h1PElj1n031882@lab343.munich.sgi.com> Subject: TAKE - Merge up to 2.5.63 To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Tue, 25 Feb 2003 17:08:13 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 2914 X-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: 43332 Lines: 1113 Date: Tue Feb 25 06:45:07 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:140249a linux/arch/ppc64/boot/ppc32-types.h - 1.1 linux/sound/oss/sb_card.h - 1.1 linux/arch/m68knommu/platform/5307/vectors.c - 1.1 linux/drivers/net/wireless/arlan.c - 1.1 linux/include/asm-v850/flat.h - 1.1 linux/drivers/net/wireless/arlan-proc.c - 1.1 linux/drivers/net/wireless/arlan.h - 1.1 linux/drivers/net/wireless/ray_cs.c - 1.1 linux/drivers/bluetooth/btuart_cs.c - 1.1 linux/arch/m68knommu/mm/extable.c - 1.1 linux/include/asm-generic/ide_iops.h - 1.1 linux/arch/i386/kernel/doublefault.c - 1.1 linux/drivers/net/wireless/ray_cs.h - 1.1 linux/drivers/net/wireless/rayctl.h - 1.1 linux/drivers/net/wireless/strip.c - 1.1 linux/drivers/s390/net/Kconfig - 1.1 linux/arch/i386/mach-visws/reboot.c - 1.1 linux/arch/i386/kernel/cpu/cpufreq/Kconfig - 1.1 linux/lib/idr.c - 1.1 linux/kernel/posix-timers.c - 1.1 linux/include/asm-i386/mach-visws/cobalt.h - 1.1 linux/include/asm-i386/i8259.h - 1.1 linux/include/linux/posix-timers.h - 1.1 linux/drivers/pnp/manager.c - 1.1 linux/arch/alpha/oprofile/op_model_ev6.c - 1.1 linux/include/asm-i386/mach-visws/lithium.h - 1.1 linux/include/asm-i386/mach-visws/mach_apic.h - 1.1 linux/drivers/pnp/support.c - 1.1 linux/include/asm-i386/mach-visws/piix4.h - 1.1 linux/include/asm-m68knommu/flat.h - 1.1 linux/arch/ppc64/boot/string.S - 1.1 linux/arch/alpha/oprofile/op_model_ev67.c - 1.1 linux/arch/ppc64/boot/prom.c - 1.1 linux/arch/ppc64/boot/README - 1.1 linux/include/asm-v850/bug.h - 1.1 linux/arch/alpha/oprofile/op_impl.h - 1.1 linux/arch/alpha/oprofile/op_model_ev5.c - 1.1 linux/include/linux/idr.h - 1.1 linux/arch/alpha/oprofile/op_model_ev4.c - 1.1 linux/arch/m68knommu/platform/68VZ328/ucdimm/config.c - 1.1 linux/arch/alpha/oprofile/common.c - 1.1 linux/arch/alpha/oprofile/Kconfig - 1.1 linux/arch/alpha/oprofile/Makefile - 1.1 linux/scripts/header.tk - 1.9 linux/scripts/checkhelp.pl - 1.3 linux/scripts/Makefile - 1.16 linux/net/sunrpc/sysctl.c - 1.10 linux/net/sunrpc/svcsock.c - 1.28 linux/net/sunrpc/svcauth.c - 1.9 linux/net/sunrpc/sunrpc_syms.c - 1.21 linux/net/sunrpc/stats.c - 1.11 linux/net/sunrpc/auth_unix.c - 1.12 linux/net/sunrpc/auth_null.c - 1.12 linux/net/sunrpc/auth.c - 1.14 linux/net/rose/sysctl_net_rose.c - 1.5 linux/net/rose/rose_dev.c - 1.11 linux/net/netsyms.c - 1.61 linux/net/netrom/sysctl_net_netrom.c - 1.5 linux/net/netrom/nr_dev.c - 1.10 linux/net/netlink/af_netlink.c - 1.25 linux/net/irda/irproc.c - 1.12 linux/net/ipv6/tcp_ipv6.c - 1.46 linux/net/ipv6/sit.c - 1.27 linux/net/ipv6/route.c - 1.28 linux/net/ipv6/reassembly.c - 1.15 linux/net/ipv6/ndisc.c - 1.28 linux/net/ipv6/mcast.c - 1.23 linux/net/ipv6/ipv6_sockglue.c - 1.20 linux/net/ipv6/ip6_output.c - 1.17 linux/net/ipv6/ip6_input.c - 1.13 linux/net/ipv6/icmp.c - 1.24 linux/net/ipv6/exthdrs.c - 1.8 linux/net/ipv6/af_inet6.c - 1.30 linux/net/ipv6/addrconf.c - 1.31 linux/net/ipv6/Makefile - 1.12 linux/net/ipv4/route.c - 1.44 linux/net/ipv4/ipmr.c - 1.27 linux/net/ipv4/ipconfig.c - 1.35 linux/net/ipv4/ip_input.c - 1.21 linux/net/ipv4/ip_fragment.c - 1.19 linux/net/ipv4/igmp.c - 1.22 linux/net/ipv4/icmp.c - 1.37 linux/net/ipv4/af_inet.c - 1.48 linux/mm/slab.c - 1.51 linux/mm/filemap.c - 1.149 linux/lib/Makefile - 1.19 linux/kernel/signal.c - 1.50 linux/kernel/sched.c - 1.95 linux/kernel/resource.c - 1.20 linux/kernel/ksyms.c - 1.182 linux/kernel/kmod.c - 1.30 linux/kernel/fork.c - 1.84 linux/kernel/exit.c - 1.65 linux/kernel/Makefile - 1.43 linux/include/net/ip6_route.h - 1.8 linux/include/net/if_inet6.h - 1.8 linux/include/net/addrconf.h - 1.11 linux/include/linux/types.h - 1.13 linux/include/linux/tty_ldisc.h - 1.4 linux/include/linux/time.h - 1.11 linux/include/linux/sysctl.h - 1.70 linux/include/linux/sys.h - 1.4 linux/include/linux/swap.h - 1.72 linux/include/linux/sunrpc/svc.h - 1.14 linux/include/linux/sunrpc/auth.h - 1.10 linux/include/linux/socket.h - 1.12 linux/include/linux/skbuff.h - 1.31 linux/include/linux/signal.h - 1.13 linux/include/linux/sched.h - 1.99 linux/include/linux/rtnetlink.h - 1.16 linux/include/linux/nfsd/nfsfh.h - 1.18 linux/include/linux/module.h - 1.45 linux/include/linux/ioport.h - 1.15 linux/include/linux/init.h - 1.25 linux/include/linux/in6.h - 1.8 linux/include/linux/i2c.h - 1.19 linux/include/linux/genhd.h - 1.33 linux/include/linux/fs.h - 1.206 linux/include/linux/elf.h - 1.23 linux/include/linux/delay.h - 1.5 linux/include/linux/cdrom.h - 1.26 linux/include/linux/blkdev.h - 1.81 linux/include/linux/binfmts.h - 1.16 linux/include/asm-sparc64/psrcompat.h - 1.4 linux/include/asm-sparc64/posix_types.h - 1.9 linux/include/asm-sparc64/irq.h - 1.17 linux/include/asm-sparc64/ide.h - 1.20 linux/include/asm-sparc/posix_types.h - 1.4 linux/include/asm-ppc/unistd.h - 1.32 linux/include/asm-ppc/system.h - 1.28 linux/include/asm-ppc/posix_types.h - 1.10 linux/include/asm-ppc/ide.h - 1.23 linux/include/asm-ppc/delay.h - 1.8 linux/include/asm-i386/unistd.h - 1.35 linux/include/asm-i386/system.h - 1.32 linux/include/asm-i386/signal.h - 1.10 linux/include/asm-i386/segment.h - 1.5 linux/include/asm-i386/processor.h - 1.49 linux/include/asm-i386/posix_types.h - 1.5 linux/include/asm-i386/pgtable.h - 1.43 linux/include/asm-i386/mmu_context.h - 1.25 linux/include/asm-i386/lithium.h - 1.4 linux/include/asm-i386/ide.h - 1.15 linux/include/asm-i386/desc.h - 1.17 linux/include/asm-i386/delay.h - 1.4 linux/include/asm-i386/cobalt.h - 1.4 linux/include/asm-alpha/system.h - 1.27 linux/include/asm-alpha/posix_types.h - 1.7 linux/include/asm-alpha/machvec.h - 1.17 linux/include/asm-alpha/ide.h - 1.14 linux/include/asm-alpha/delay.h - 1.10 linux/include/asm-alpha/compiler.h - 1.10 linux/include/asm-alpha/byteorder.h - 1.5 linux/include/asm-alpha/bitops.h - 1.14 linux/fs/open.c - 1.47 linux/fs/nfsd/nfsxdr.c - 1.22 linux/fs/nfsd/nfssvc.c - 1.32 linux/fs/nfsd/nfs3xdr.c - 1.36 linux/fs/nfsd/nfs3proc.c - 1.21 linux/fs/nfsd/export.c - 1.48 linux/fs/file_table.c - 1.29 linux/fs/exec.c - 1.79 linux/fs/buffer.c - 1.149 linux/drivers/video/sgivwfb.c - 1.19 linux/drivers/video/q40fb.c - 1.17 linux/drivers/video/fm2fb.c - 1.19 linux/drivers/scsi/wd7000.h - 1.10 linux/drivers/scsi/wd7000.c - 1.23 linux/drivers/scsi/u14-34f.c - 1.31 linux/drivers/scsi/tmscsim.c - 1.22 linux/drivers/scsi/sym53c8xx_defs.h - 1.14 linux/drivers/scsi/sym53c8xx.c - 1.40 linux/drivers/scsi/sg.c - 1.49 linux/drivers/scsi/scsi_syms.c - 1.28 linux/drivers/scsi/scsi_proc.c - 1.15 linux/drivers/scsi/scsi_error.c - 1.40 linux/drivers/scsi/scsi.h - 1.44 linux/drivers/scsi/scsi.c - 1.70 linux/drivers/scsi/qlogicisp.c - 1.33 linux/drivers/scsi/qlogicfc.c - 1.34 linux/drivers/scsi/psi_chip.h - 1.3 linux/drivers/scsi/ppa.c - 1.23 linux/drivers/scsi/pluto.c - 1.19 linux/drivers/scsi/pci2220i.c - 1.28 linux/drivers/scsi/pci2000.c - 1.25 linux/drivers/scsi/megaraid.c - 1.43 linux/drivers/scsi/hosts.h - 1.36 linux/drivers/scsi/hosts.c - 1.41 linux/drivers/scsi/fdomain.c - 1.28 linux/drivers/scsi/eata_pio_proc.c - 1.5 linux/drivers/scsi/eata_pio.h - 1.6 linux/drivers/scsi/eata_pio.c - 1.20 linux/drivers/scsi/eata_dma_proc.h - 1.3 linux/drivers/scsi/eata_dma_proc.c - 1.9 linux/drivers/scsi/eata_dma.h - 1.6 linux/drivers/scsi/eata_dma.c - 1.22 linux/drivers/scsi/eata.c - 1.34 linux/drivers/scsi/aha152x.c - 1.36 linux/drivers/scsi/advansys.c - 1.33 linux/drivers/scsi/Makefile - 1.49 linux/drivers/scsi/AM53C974.c - 1.18 linux/drivers/scsi/53c7xx.c - 1.22 linux/drivers/pnp/Makefile - 1.19 linux/drivers/pci/Makefile - 1.30 linux/drivers/net/znet.c - 1.15 linux/drivers/net/strip.c - 1.20 linux/drivers/net/dgrs_plx9060.h - 1.3 linux/drivers/net/am79c961a.c - 1.17 linux/drivers/net/ac3200.c - 1.21 linux/drivers/net/Makefile - 1.69 linux/drivers/char/tty_io.c - 1.63 linux/drivers/char/tpqic02.c - 1.26 linux/drivers/char/sysrq.c - 1.35 linux/drivers/char/synclink.c - 1.34 linux/drivers/char/specialix.c - 1.18 linux/drivers/char/riscom8.c - 1.18 linux/drivers/char/isicom.c - 1.24 linux/drivers/char/ftape/zftape/zftape-vtbl.h - 1.4 linux/drivers/char/ftape/zftape/zftape-vtbl.c - 1.7 linux/drivers/char/ftape/zftape/zftape-eof.c - 1.4 linux/drivers/char/ftape/zftape/zftape-ctl.c - 1.7 linux/drivers/char/esp.c - 1.20 linux/drivers/char/epca.c - 1.25 linux/drivers/char/cyclades.c - 1.27 linux/drivers/block/floppy.c - 1.62 linux/drivers/acorn/block/fd1772.c - 1.32 linux/arch/sparc64/prom/Makefile - 1.14 linux/arch/sparc64/mm/ultra.S - 1.30 linux/arch/sparc64/mm/Makefile - 1.12 linux/arch/sparc64/lib/Makefile - 1.15 linux/arch/sparc64/kernel/time.c - 1.29 linux/arch/sparc64/kernel/systbls.S - 1.41 linux/arch/sparc64/kernel/sys_sunos32.c - 1.44 linux/arch/sparc64/kernel/sys_sparc32.c - 1.70 linux/arch/sparc64/kernel/sys32.S - 1.8 linux/arch/sparc64/kernel/sunos_ioctl32.c - 1.5 linux/arch/sparc64/kernel/sparc64_ksyms.c - 1.52 linux/arch/sparc64/kernel/smp.c - 1.52 linux/arch/sparc64/kernel/signal.c - 1.32 linux/arch/sparc64/kernel/ioctl32.c - 1.67 linux/arch/sparc64/kernel/Makefile - 1.30 linux/arch/sparc/kernel/time.c - 1.24 linux/arch/sparc/kernel/sparc_ksyms.c - 1.36 linux/arch/ppc/kernel/process.c - 1.48 linux/arch/ppc/kernel/misc.S - 1.55 linux/arch/ppc/8xx_io/uart.c - 1.25 linux/arch/mips/kernel/pci.c - 1.10 linux/arch/mips/kernel/irixsig.c - 1.13 linux/arch/m68k/kernel/head.S - 1.11 linux/arch/i386/lib/delay.c - 1.8 linux/arch/i386/kernel/traps.c - 1.73 linux/arch/i386/kernel/trampoline.S - 1.9 linux/arch/i386/kernel/time.c - 1.35 linux/arch/i386/kernel/setup.c - 1.88 linux/arch/i386/kernel/process.c - 1.67 linux/arch/i386/kernel/io_apic.c - 1.54 linux/arch/i386/kernel/i386_ksyms.c - 1.66 linux/arch/i386/kernel/head.S - 1.31 linux/arch/i386/kernel/entry.S - 1.74 linux/arch/i386/kernel/Makefile - 1.45 linux/arch/i386/Makefile - 1.48 linux/arch/alpha/mm/Makefile - 1.7 linux/arch/alpha/math-emu/Makefile - 1.11 linux/arch/alpha/lib/Makefile - 1.22 linux/arch/alpha/kernel/sys_sable.c - 1.13 linux/arch/alpha/kernel/ptrace.c - 1.19 linux/arch/alpha/kernel/entry.S - 1.35 linux/arch/alpha/kernel/alpha_ksyms.c - 1.42 linux/arch/alpha/kernel/Makefile - 1.31 linux/arch/alpha/Makefile - 1.29 linux/README - 1.14 linux/Makefile - 1.240 linux/MAINTAINERS - 1.133 linux/Documentation/sysrq.txt - 1.14 linux/Documentation/networking/ip-sysctl.txt - 1.17 linux/Documentation/networking/alias.txt - 1.4 linux/CREDITS - 1.97 linux/net/decnet/dn_route.c - 1.25 linux/net/decnet/dn_nsp_out.c - 1.12 linux/include/net/dn_route.h - 1.7 linux/include/linux/ide.h - 1.74 linux/drivers/sbus/char/aurora.c - 1.24 linux/arch/ppc/xmon/ansidecl.h - 1.4 linux/arch/i386/vmlinux.lds.S - 1.17 linux/arch/mips/baget/vacserial.c - 1.15 linux/drivers/net/arlan.h - 1.9 linux/drivers/net/arlan.c - 1.25 linux/drivers/net/arlan-proc.c - 1.10 linux/drivers/char/ppdev.c - 1.36 linux/drivers/parport/parport_pc.c - 1.53 linux/drivers/char/sx.c - 1.31 linux/include/asm-i386/hw_irq.h - 1.33 linux/fs/partitions/msdos.c - 1.27 linux/arch/i386/kernel/i8259.c - 1.36 linux/drivers/net/sis900.c - 1.41 linux/drivers/char/ip2main.c - 1.26 linux/drivers/char/ip2/i2ellis.h - 1.7 linux/net/sched/sch_atm.c - 1.10 linux/net/atm/lec.h - 1.7 linux/net/atm/lec.c - 1.17 linux/net/atm/common.c - 1.20 linux/include/linux/atmdev.h - 1.13 linux/arch/ppc/kernel/entry.S - 1.34 linux/drivers/scsi/ips.c - 1.37 linux/drivers/pcmcia/tcic.c - 1.21 linux/drivers/pcmcia/i82365.c - 1.33 linux/drivers/pcmcia/cs_internal.h - 1.13 linux/drivers/pcmcia/cs.c - 1.34 linux/drivers/pcmcia/cistpl.c - 1.16 linux/include/pcmcia/ss.h - 1.11 linux/drivers/pcmcia/cardbus.c - 1.26 linux/drivers/net/pcmcia/rayctl.h - 1.3 linux/drivers/net/pcmcia/ray_cs.h - 1.6 linux/drivers/net/pcmcia/ray_cs.c - 1.30 linux/drivers/net/pcmcia/Makefile - 1.25 linux/include/linux/pci_ids.h - 1.84 linux/drivers/scsi/sim710.c - 1.14 linux/fs/proc/proc_misc.c - 1.55 linux/drivers/net/setup.c - 1.22 linux/drivers/net/sk98lin/skgeinit.c - 1.7 linux/drivers/net/sk98lin/skge.c - 1.22 linux/arch/alpha/kernel/core_irongate.c - 1.14 linux/drivers/net/aironet4500_rid.c - 1.5 linux/drivers/net/aironet4500_proc.c - 1.17 linux/drivers/net/aironet4500_core.c - 1.22 linux/drivers/net/aironet4500_card.c - 1.22 linux/drivers/net/aironet4500.h - 1.13 linux/kernel/timer.c - 1.40 linux/drivers/scsi/scsi_lib.c - 1.59 linux/include/linux/i2c-algo-pcf.h - 1.4 linux/include/linux/i2c-algo-bit.h - 1.4 linux/include/linux/i2c-id.h - 1.15 linux/Documentation/i2c/summary - 1.4 linux/drivers/i2c/i2c-velleman.c - 1.9 linux/drivers/i2c/i2c-elv.c - 1.10 linux/drivers/i2c/i2c-philips-par.c - 1.10 linux/drivers/i2c/i2c-algo-pcf.c - 1.13 linux/drivers/i2c/i2c-dev.c - 1.24 linux/drivers/i2c/i2c-algo-bit.c - 1.15 linux/Documentation/i2c/i2c-protocol - 1.4 linux/Documentation/i2c/smbus-protocol - 1.4 linux/include/linux/i2c-dev.h - 1.11 linux/Documentation/i2c/writing-clients - 1.7 linux/drivers/pcmcia/pci_socket.h - 1.9 linux/drivers/pcmcia/pci_socket.c - 1.15 linux/drivers/pnp/quirks.c - 1.13 linux/drivers/ieee1394/raw1394.c - 1.24 linux/drivers/ieee1394/pcilynx.c - 1.27 linux/drivers/ieee1394/ohci1394.c - 1.28 linux/arch/i386/kernel/apic.c - 1.40 linux/drivers/ieee1394/hosts.h - 1.15 linux/drivers/ieee1394/hosts.c - 1.17 linux/arch/i386/kernel/mpparse.c - 1.34 linux/drivers/pci/setup-bus.c - 1.10 linux/drivers/scsi/scsi_scan.c - 1.40 linux/drivers/scsi/3w-xxxx.h - 1.17 linux/drivers/scsi/3w-xxxx.c - 1.27 linux/include/asm-sparc/ide.h - 1.17 linux/arch/ia64/ia32/sys_ia32.c - 1.40 linux/drivers/scsi/qla1280.c - 1.25 linux/kernel/pm.c - 1.13 linux/include/linux/raid/md_k.h - 1.31 linux/include/linux/raid/md.h - 1.21 linux/drivers/char/amiserial.c - 1.17 linux/drivers/scsi/pcmcia/aha152x_stub.c - 1.13 linux/drivers/net/skfp/pmf.c - 1.2 linux/Documentation/networking/8139too.txt - 1.20 linux/drivers/net/tulip/interrupt.c - 1.18 linux/arch/mips64/kernel/linux32.c - 1.16 linux/drivers/net/bonding.c - 1.18 linux/arch/alpha/kernel/irq_alpha.c - 1.13 linux/include/linux/usb.h - 1.55 linux/drivers/usb/serial/usb-serial.h - 1.28 linux/drivers/usb/serial/usb-serial.c - 1.14 linux/drivers/ide/ide.c - 1.81 linux/drivers/ide/ide-tape.c - 1.42 linux/drivers/ide/ide-proc.c - 1.26 linux/drivers/ide/ide-probe.c - 1.49 linux/drivers/ide/ide-pnp.c - 1.13 linux/drivers/ide/ide-floppy.c - 1.42 linux/drivers/ide/ide-dma.c - 1.35 linux/drivers/ide/ide-cd.c - 1.57 linux/drivers/ide/Makefile - 1.34 linux/Documentation/DocBook/videobook.tmpl - 1.8 linux/net/ipv4/netfilter/ip_nat_rule.c - 1.9 linux/net/ipv4/netfilter/ip_nat_core.c - 1.17 linux/net/ipv4/netfilter/ip_fw_compat.c - 1.14 linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c - 1.11 linux/net/ipv4/netfilter/ip_conntrack_core.c - 1.18 linux/drivers/scsi/dmx3191d.c - 1.12 linux/arch/ppc/8260_io/uart.c - 1.15 linux/drivers/char/rio/rio_linux.c - 1.18 linux/arch/s390/kernel/process.c - 1.17 linux/include/linux/raid/raid5.h - 1.11 linux/include/linux/raid/raid1.h - 1.13 linux/arch/s390/Makefile - 1.15 linux/include/asm-s390/unistd.h - 1.14 linux/include/asm-s390/uaccess.h - 1.9 linux/arch/s390/defconfig - 1.17 linux/include/asm-s390/system.h - 1.11 linux/include/asm-s390/dma.h - 1.3 linux/include/asm-s390/spinlock.h - 1.7 linux/include/asm-s390/signal.h - 1.6 linux/arch/s390/kernel/entry.S - 1.23 linux/arch/s390/kernel/init_task.c - 1.7 linux/drivers/s390/block/dasd_eckd.c - 1.14 linux/drivers/s390/block/dasd.c - 1.37 linux/Documentation/s390/cds.txt - 1.9 linux/include/asm-s390/bitops.h - 1.10 linux/arch/s390/kernel/traps.c - 1.15 linux/arch/s390/kernel/ptrace.c - 1.12 linux/arch/s390/kernel/setup.c - 1.12 linux/arch/s390/kernel/signal.c - 1.17 linux/arch/s390/mm/extable.c - 1.6 linux/arch/s390/mm/fault.c - 1.12 linux/Documentation/DocBook/kernel-hacking.tmpl - 1.13 linux/fs/xfs/xfsidbg.c - 1.220 linux/include/linux/profile.h - 1.5 linux/kernel/profile.c - 1.6 linux/drivers/usb/storage/transport.c - 1.39 linux/arch/alpha/kernel/sys_wildfire.c - 1.8 linux/drivers/acpi/tables/tbxface.c - 1.17 linux/drivers/acpi/tables/tbutils.c - 1.18 linux/drivers/acpi/tables/tbinstal.c - 1.19 linux/drivers/acpi/tables/tbget.c - 1.19 linux/drivers/acpi/resources/rsxface.c - 1.13 linux/drivers/acpi/resources/rsutils.c - 1.15 linux/drivers/acpi/resources/rsmisc.c - 1.12 linux/drivers/acpi/resources/rsmemory.c - 1.12 linux/drivers/acpi/resources/rslist.c - 1.14 linux/drivers/acpi/resources/rsirq.c - 1.15 linux/drivers/acpi/resources/rsio.c - 1.14 linux/drivers/acpi/resources/rsdump.c - 1.15 linux/drivers/acpi/resources/rscreate.c - 1.17 linux/drivers/acpi/resources/rscalc.c - 1.17 linux/drivers/acpi/resources/rsaddr.c - 1.13 linux/drivers/acpi/parser/psxface.c - 1.16 linux/drivers/acpi/parser/pswalk.c - 1.13 linux/drivers/acpi/parser/psutils.c - 1.16 linux/drivers/acpi/parser/pstree.c - 1.14 linux/drivers/acpi/parser/psscope.c - 1.12 linux/drivers/acpi/parser/psparse.c - 1.20 linux/drivers/acpi/parser/psopcode.c - 1.19 linux/drivers/acpi/parser/psargs.c - 1.18 linux/drivers/acpi/namespace/nsxfobj.c - 1.18 linux/drivers/acpi/namespace/nsxfname.c - 1.15 linux/drivers/acpi/namespace/nswalk.c - 1.12 linux/drivers/acpi/namespace/nsutils.c - 1.19 linux/drivers/acpi/namespace/nssearch.c - 1.19 linux/drivers/acpi/namespace/nsobject.c - 1.17 linux/drivers/acpi/namespace/nsnames.c - 1.17 linux/drivers/acpi/namespace/nsload.c - 1.19 linux/drivers/acpi/namespace/nseval.c - 1.19 linux/drivers/acpi/namespace/nsalloc.c - 1.17 linux/drivers/acpi/namespace/nsaccess.c - 1.19 linux/drivers/acpi/hardware/hwregs.c - 1.18 linux/drivers/acpi/hardware/hwgpe.c - 1.15 linux/drivers/acpi/hardware/hwacpi.c - 1.16 linux/drivers/acpi/events/evxfregn.c - 1.16 linux/drivers/acpi/events/evxfevnt.c - 1.15 linux/drivers/acpi/events/evxface.c - 1.18 linux/drivers/acpi/events/evsci.c - 1.13 linux/drivers/acpi/events/evrgnini.c - 1.16 linux/drivers/acpi/events/evregion.c - 1.18 linux/drivers/acpi/events/evmisc.c - 1.17 linux/drivers/acpi/events/evevent.c - 1.21 linux/drivers/acpi/dispatcher/dswstate.c - 1.19 linux/drivers/acpi/dispatcher/dswscope.c - 1.14 linux/drivers/acpi/dispatcher/dswload.c - 1.22 linux/drivers/acpi/dispatcher/dswexec.c - 1.17 linux/drivers/acpi/dispatcher/dsutils.c - 1.19 linux/drivers/acpi/dispatcher/dsopcode.c - 1.20 linux/drivers/acpi/dispatcher/dsobject.c - 1.23 linux/drivers/acpi/dispatcher/dsmthdat.c - 1.17 linux/drivers/acpi/dispatcher/dsmethod.c - 1.17 linux/drivers/acpi/dispatcher/dsfield.c - 1.17 linux/drivers/net/natsemi.c - 1.27 linux/drivers/media/radio/radio-cadet.c - 1.13 linux/drivers/isdn/eicon/divalog.h - 1.4 linux/drivers/md/raid1.c - 1.30 linux/drivers/md/raid5.c - 1.40 linux/drivers/acpi/namespace/nsdump.c - 1.18 linux/drivers/md/linear.c - 1.18 linux/drivers/md/md.c - 1.69 linux/drivers/scsi/cpqfcTSinit.c - 1.26 linux/drivers/scsi/cpqioctl.c - 1.2 linux/include/asm-arm/hardware/iomd.h - 1.4 linux/fs/xfs/support/qsort.c - 1.6 linux/include/asm-s390/module.h - 1.4 linux/arch/alpha/lib/ev6-memcpy.S - 1.3 linux/drivers/net/lasi_82596.c - 1.17 linux/include/asm-parisc/pdcpat.h - 1.2 linux/include/asm-parisc/pgtable.h - 1.9 linux/include/asm-parisc/irq.h - 1.4 linux/arch/parisc/kernel/time.c - 1.6 linux/arch/parisc/kernel/parisc_ksyms.c - 1.8 linux/arch/parisc/kernel/irq.c - 1.9 linux/arch/parisc/kernel/Makefile - 1.9 linux/drivers/acpi/tables/tbconvrt.c - 1.16 linux/drivers/acpi/tables/tbxfroot.c - 1.14 linux/drivers/acpi/namespace/nsinit.c - 1.16 linux/arch/m68k/ifpsp060/src/pfpsp.S - 1.5 linux/arch/m68k/ifpsp060/src/fpsp.S - 1.5 linux/arch/m68k/ifpsp060/src/isp.S - 1.4 linux/include/asm-ia64/sn/eeprom.h - 1.5 linux/arch/ia64/sn/io/l1.c - 1.6 linux/arch/ia64/sn/io/xbow.c - 1.5 linux/arch/ia64/sn/io/xtalk.c - 1.5 linux/include/asm-ia64/sn/pci/bridge.h - 1.5 linux/drivers/acpi/hardware/hwsleep.c - 1.15 linux/drivers/acpi/hardware/hwtimer.c - 1.13 linux/arch/s390x/kernel/traps.c - 1.11 linux/arch/s390x/kernel/sys_s390.c - 1.6 linux/include/asm-s390x/processor.h - 1.9 linux/arch/s390x/kernel/signal32.c - 1.12 linux/include/asm-s390x/pgtable.h - 1.14 linux/arch/s390x/kernel/signal.c - 1.14 linux/arch/s390x/kernel/setup.c - 1.11 linux/include/asm-s390x/module.h - 1.4 linux/include/asm-s390x/idals.h - 1.5 linux/include/asm-s390x/elf.h - 1.4 linux/include/asm-s390x/dma.h - 1.2 linux/include/asm-s390x/bitops.h - 1.6 linux/arch/s390x/kernel/ptrace.c - 1.11 linux/arch/s390x/kernel/process.c - 1.14 linux/arch/s390x/kernel/linux32.c - 1.25 linux/arch/s390x/kernel/init_task.c - 1.7 linux/include/asm-s390x/signal.h - 1.7 linux/drivers/s390/s390mach.c - 1.9 linux/arch/cris/boot/compressed/misc.c - 1.5 linux/arch/cris/drivers/serial.c - 1.12 linux/drivers/s390/net/netiucv.c - 1.15 linux/drivers/s390/net/ctcmain.c - 1.13 linux/arch/s390x/kernel/exec32.c - 1.5 linux/arch/s390x/kernel/entry.S - 1.21 linux/drivers/s390/char/tape.h - 1.6 linux/arch/s390x/kernel/binfmt_elf32.c - 1.7 linux/arch/s390x/defconfig - 1.16 linux/arch/s390x/mm/fault.c - 1.10 linux/arch/s390x/mm/extable.c - 1.5 linux/include/asm-s390x/spinlock.h - 1.7 linux/include/asm-s390x/system.h - 1.9 linux/drivers/s390/block/dasd_eckd.h - 1.8 linux/include/asm-s390x/uaccess.h - 1.6 linux/arch/s390x/kernel/wrapper32.S - 1.13 linux/drivers/s390/block/dasd_3990_erp.c - 1.11 linux/include/asm-s390x/unistd.h - 1.11 linux/drivers/pcmcia/hd64465_ss.c - 1.9 linux/include/asm-s390/idals.h - 1.5 linux/arch/s390x/Makefile - 1.16 linux/include/asm-arm/arch-integrator/platform.h - 1.2 linux/drivers/scsi/aic7xxx_old.c - 1.28 linux/Documentation/s390/Debugging390.txt - 1.8 linux/include/linux/compiler.h - 1.8 linux/drivers/net/wireless/Makefile - 1.9 linux/drivers/net/wireless/airport.c - 1.11 linux/drivers/net/wireless/orinoco.c - 1.15 linux/arch/alpha/mm/numa.c - 1.10 linux/arch/cris/drivers/eeprom.c - 1.9 linux/include/net/bluetooth/hci.h - 1.8 linux/include/net/bluetooth/hci_core.h - 1.9 linux/include/net/bluetooth/l2cap.h - 1.6 linux/drivers/bluetooth/hci_usb.c - 1.20 linux/drivers/bluetooth/Makefile - 1.10 linux/net/bluetooth/af_bluetooth.c - 1.11 linux/net/bluetooth/hci_core.c - 1.13 linux/net/bluetooth/hci_sock.c - 1.11 linux/net/bluetooth/syms.c - 1.7 linux/drivers/acpi/executer/exstore.c - 1.17 linux/drivers/acpi/utilities/utxface.c - 1.11 linux/drivers/acpi/utilities/utobject.c - 1.12 linux/drivers/acpi/utilities/utmisc.c - 1.15 linux/drivers/acpi/utilities/utinit.c - 1.12 linux/drivers/acpi/utilities/utglobal.c - 1.18 linux/drivers/acpi/utilities/uteval.c - 1.13 linux/drivers/acpi/utilities/utdelete.c - 1.13 linux/arch/alpha/lib/udelay.c - 1.2 linux/drivers/acpi/utilities/utdebug.c - 1.13 linux/drivers/acpi/utilities/utcopy.c - 1.16 linux/drivers/acpi/utilities/utalloc.c - 1.10 linux/drivers/net/wireless/airo.c - 1.25 linux/drivers/acpi/executer/exutils.c - 1.14 linux/drivers/acpi/executer/exsystem.c - 1.9 linux/drivers/acpi/executer/exstorob.c - 1.12 linux/drivers/acpi/executer/exstoren.c - 1.13 linux/drivers/acpi/executer/exconfig.c - 1.13 linux/drivers/acpi/executer/exconvrt.c - 1.15 linux/drivers/acpi/executer/excreate.c - 1.14 linux/drivers/acpi/executer/exdump.c - 1.17 linux/drivers/acpi/executer/exfield.c - 1.11 linux/drivers/acpi/executer/exfldio.c - 1.14 linux/drivers/acpi/executer/exmisc.c - 1.15 linux/drivers/acpi/executer/exmutex.c - 1.10 linux/drivers/acpi/executer/exnames.c - 1.10 linux/drivers/acpi/executer/exprep.c - 1.14 linux/drivers/acpi/executer/exregion.c - 1.12 linux/drivers/acpi/executer/exresnte.c - 1.17 linux/drivers/acpi/executer/exresolv.c - 1.15 linux/drivers/acpi/executer/exresop.c - 1.17 linux/drivers/scsi/pcmcia/nsp_cs.c - 1.15 linux/Documentation/sonypi.txt - 1.10 linux/Documentation/video4linux/meye.txt - 1.6 linux/include/linux/meye.h - 1.3 linux/drivers/char/sonypi.h - 1.12 linux/drivers/media/video/meye.h - 1.7 linux/drivers/media/video/meye.c - 1.13 linux/drivers/net/au1000_eth.c - 1.9 linux/include/linux/sonypi.h - 1.7 linux/drivers/char/sonypi.c - 1.12 linux/drivers/message/fusion/mptscsih.h - 1.11 linux/drivers/message/fusion/mptscsih.c - 1.16 linux/drivers/message/fusion/mptlan.h - 1.8 linux/drivers/message/fusion/mptlan.c - 1.9 linux/drivers/message/fusion/mptctl.c - 1.13 linux/drivers/message/fusion/mptbase.h - 1.10 linux/drivers/message/fusion/mptbase.c - 1.10 linux/drivers/message/fusion/isense.c - 1.7 linux/drivers/message/fusion/linux_compat.h - 1.8 linux/fs/ntfs/unistr.c - 1.8 linux/drivers/scsi/pcmcia/nsp_message.c - 1.6 linux/drivers/char/drm/drm_drv.h - 1.10 linux/drivers/net/irda/vlsi_ir.c - 1.14 linux/drivers/video/sstfb.c - 1.12 linux/drivers/bluetooth/hci_vhci.c - 1.9 linux/include/asm-ppc/ppcboot.h - 1.4 linux/arch/mips/au1000/common/serial.c - 1.7 linux/arch/mips/ddb5xxx/common/pci.c - 1.3 linux/arch/mips/philips/nino/int-handler.S - 1.2 linux/drivers/scsi/53c700.c - 1.16 linux/drivers/scsi/53c700.h - 1.9 linux/drivers/md/multipath.c - 1.17 linux/drivers/char/mwave/3780i.c - 1.3 linux/drivers/pcmcia/sa1100_generic.c - 1.13 linux/drivers/i2c/i2c-proc.c - 1.10 linux/include/linux/i2c-proc.h - 1.4 linux/drivers/message/i2o/i2o_config.c - 1.8 linux/drivers/acpi/executer/exoparg6.c - 1.7 linux/drivers/acpi/utilities/utmath.c - 1.7 linux/drivers/pcmcia/i82092.c - 1.10 linux/drivers/acpi/executer/exoparg3.c - 1.9 linux/drivers/acpi/executer/exoparg2.c - 1.14 linux/drivers/acpi/executer/exoparg1.c - 1.15 linux/Documentation/networking/bonding.txt - 1.7 linux/drivers/scsi/sym53c8xx_2/sym_glue.c - 1.12 linux/drivers/scsi/sym53c8xx_2/sym_glue.h - 1.9 linux/drivers/scsi/sym53c8xx_2/sym_hipd.c - 1.5 linux/drivers/scsi/sym53c8xx_2/sym_malloc.c - 1.2 linux/fs/bio.c - 1.26 linux/arch/arm/mm/alignment.c - 1.7 linux/include/asm-arm/arch-iop310/dma.h - 1.2 linux/drivers/block/cciss_scsi.c - 1.9 linux/drivers/usb/Makefile.lib - 1.3 linux/include/linux/init_task.h - 1.17 linux/net/ipv6/netfilter/ip6_queue.c - 1.7 linux/net/ipv4/netfilter/ipt_esp.c - 1.4 linux/net/ipv4/netfilter/ipt_ah.c - 1.4 linux/sound/pci/es1968.c - 1.13 linux/sound/pci/cs4281.c - 1.15 linux/sound/pci/als4000.c - 1.10 linux/sound/pci/ac97/ac97_codec.c - 1.13 linux/sound/oss/vwsnd.c - 1.6 linux/sound/oss/sb_card.c - 1.4 linux/sound/oss/rme96xx.c - 1.7 linux/sound/oss/maestro.c - 1.7 linux/sound/oss/mad16.c - 1.5 linux/arch/x86_64/boot/compressed/misc.c - 1.5 linux/arch/x86_64/ia32/ia32_ioctl.c - 1.14 linux/arch/x86_64/ia32/sys_ia32.c - 1.15 linux/arch/x86_64/kernel/Makefile - 1.15 linux/arch/x86_64/kernel/apic.c - 1.11 linux/arch/x86_64/kernel/entry.S - 1.10 linux/arch/x86_64/kernel/io_apic.c - 1.5 linux/arch/x86_64/kernel/ioport.c - 1.5 linux/arch/x86_64/kernel/mpparse.c - 1.7 linux/arch/x86_64/kernel/nmi.c - 1.8 linux/arch/x86_64/kernel/process.c - 1.15 linux/arch/x86_64/kernel/ptrace.c - 1.9 linux/arch/x86_64/kernel/setup.c - 1.9 linux/arch/x86_64/kernel/setup64.c - 1.10 linux/arch/x86_64/kernel/smp.c - 1.11 linux/arch/x86_64/kernel/smpboot.c - 1.12 linux/arch/x86_64/kernel/time.c - 1.9 linux/arch/x86_64/kernel/vsyscall.c - 1.9 linux/arch/x86_64/kernel/x8664_ksyms.c - 1.11 linux/arch/x86_64/lib/delay.c - 1.2 linux/arch/x86_64/mm/Makefile - 1.9 linux/sound/drivers/serial-u16550.c - 1.13 linux/include/asm-x86_64/processor.h - 1.11 linux/include/asm-x86_64/posix_types.h - 1.2 linux/include/asm-x86_64/pgtable.h - 1.12 linux/include/asm-x86_64/pda.h - 1.8 linux/include/asm-x86_64/mtrr.h - 1.5 linux/include/asm-x86_64/ide.h - 1.10 linux/include/asm-x86_64/i387.h - 1.7 linux/include/asm-x86_64/hw_irq.h - 1.5 linux/include/asm-x86_64/delay.h - 1.2 linux/include/asm-x86_64/bitops.h - 1.7 linux/include/asm-x86_64/system.h - 1.10 linux/include/asm-x86_64/signal.h - 1.7 linux/include/asm-x86_64/smp.h - 1.6 linux/include/asm-x86_64/unistd.h - 1.12 linux/include/asm-x86_64/thread_info.h - 1.7 linux/include/asm-ppc64/hardirq.h - 1.9 linux/arch/ppc64/mm/init.c - 1.14 linux/include/asm-ppc64/elf.h - 1.6 linux/arch/ppc64/Makefile - 1.16 linux/arch/ppc64/boot/Makefile - 1.9 linux/arch/ppc64/boot/addRamDisk.c - 1.2 linux/arch/ppc64/boot/addSystemMap.c - 1.2 linux/arch/ppc64/boot/crt0.S - 1.2 linux/arch/ppc64/boot/main.c - 1.4 linux/arch/ppc64/boot/zImage.lds - 1.3 linux/arch/ppc64/defconfig - 1.16 linux/arch/ppc64/kernel/Makefile - 1.15 linux/arch/ppc64/kernel/align.c - 1.6 linux/arch/ppc64/kernel/entry.S - 1.15 linux/arch/ppc64/kernel/head.S - 1.10 linux/arch/ppc64/kernel/htab.c - 1.10 linux/arch/ppc64/kernel/ioctl32.c - 1.16 linux/arch/ppc64/kernel/misc.S - 1.16 linux/arch/ppc64/kernel/open_pic.c - 1.8 linux/arch/ppc64/kernel/pSeries_lpar.c - 1.9 linux/arch/ppc64/kernel/ppc_ksyms.c - 1.10 linux/arch/ppc64/kernel/process.c - 1.14 linux/arch/ppc64/kernel/signal32.c - 1.15 linux/arch/ppc64/kernel/sys32.S - 1.8 linux/arch/ppc64/kernel/sys_ppc32.c - 1.17 linux/arch/ppc64/kernel/syscalls.c - 1.7 linux/arch/ppc64/kernel/time.c - 1.13 linux/arch/ppc64/kernel/xics.c - 1.10 linux/arch/ppc64/xmon/ansidecl.h - 1.2 linux/include/asm-ppc64/hw_irq.h - 1.7 linux/include/asm-ppc64/iSeries/ItLpNaca.h - 1.2 linux/include/asm-ppc64/unistd.h - 1.14 linux/include/asm-ppc64/system.h - 1.10 linux/include/asm-ppc64/semaphore.h - 1.5 linux/include/asm-ppc64/processor.h - 1.13 linux/include/asm-ppc64/posix_types.h - 1.4 linux/drivers/net/e1000/e1000_main.c - 1.16 linux/drivers/hotplug/ibmphp_pci.c - 1.4 linux/fs/jfs/jfs_metapage.c - 1.14 linux/fs/quota_v2.c - 1.9 linux/fs/quota_v1.c - 1.6 linux/drivers/net/tulip/dmfe.c - 1.5 linux/Documentation/sound/oss/PSS-updates - 1.2 linux/fs/jffs2/wbuf.c - 1.5 linux/include/asm-ia64/sn/sn2/shub_md.h - 1.3 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_rrb.c - 1.3 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_error.c - 1.3 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_dvr.c - 1.5 linux/fs/nfsctl.c - 1.6 linux/drivers/net/tc35815.c - 1.8 linux/drivers/usb/class/Makefile.lib - 1.2 linux/drivers/usb/class/cdc-acm.c - 1.15 linux/drivers/usb/core/usb.c - 1.28 linux/drivers/usb/host/ehci-hcd.c - 1.17 linux/drivers/usb/host/ehci.h - 1.10 linux/drivers/usb/input/usbkbd.c - 1.10 linux/drivers/usb/input/usbmouse.c - 1.9 linux/drivers/usb/media/ov511.c - 1.11 linux/drivers/usb/net/pegasus.h - 1.11 linux/drivers/usb/net/kaweth.c - 1.14 linux/arch/ia64/hp/sim/simeth.c - 1.4 linux/fs/ntfs/attrib.c - 1.9 linux/drivers/char/synclinkmp.c - 1.7 linux/fs/ntfs/mst.c - 1.3 linux/drivers/char/pcmcia/synclink_cs.c - 1.8 linux/drivers/bluetooth/bluecard_cs.c - 1.7 linux/arch/i386/pci/Makefile - 1.5 linux/arch/i386/pci/common.c - 1.7 linux/arch/i386/pci/direct.c - 1.6 linux/net/ipv6/ipv6_syms.c - 1.5 linux/arch/i386/pci/legacy.c - 1.4 linux/drivers/pci/hotplug.c - 1.9 linux/drivers/pci/probe.c - 1.12 linux/net/bluetooth/sco.c - 1.6 linux/net/bluetooth/l2cap.c - 1.7 linux/net/bluetooth/hci_conn.c - 1.6 linux/arch/i386/pci/visws.c - 1.4 linux/drivers/bluetooth/dtl1_cs.c - 1.6 linux/drivers/bluetooth/hci_ldisc.c - 1.6 linux/include/asm-generic/siginfo.h - 1.5 linux/drivers/video/pm3fb.c - 1.4 linux/drivers/usb/core/urb.c - 1.9 linux/drivers/usb/core/message.c - 1.14 linux/drivers/acpi/pci_link.c - 1.8 linux/drivers/acpi/pci_irq.c - 1.12 linux/drivers/acpi/osl.c - 1.14 linux/include/asm-s390/tlbflush.h - 1.4 linux/include/asm-s390x/qdio.h - 1.4 linux/include/asm-s390x/fsf.h - 1.2 linux/include/asm-s390x/thread_info.h - 1.4 linux/include/asm-s390x/tlbflush.h - 1.4 linux/drivers/s390/net/lcs.c - 1.10 linux/drivers/s390/cio/chsc.c - 1.6 linux/include/asm-s390/fsf.h - 1.2 linux/include/asm-s390/qdio.h - 1.4 linux/drivers/s390/cio/cio.c - 1.5 linux/arch/i386/kernel/cpu/cyrix.c - 1.6 linux/drivers/s390/cio/chsc.h - 1.4 linux/drivers/s390/block/dasd_ioctl.c - 1.9 linux/arch/i386/kernel/cpu/common.c - 1.11 linux/drivers/message/fusion/mptctl.h - 1.5 linux/sound/pci/rme9652/hammerfall_mem.c - 1.8 linux/drivers/input/serio/i8042.c - 1.10 linux/drivers/acpi/tables/tbrsdt.c - 1.9 linux/drivers/acpi/toshiba_acpi.c - 1.7 linux/drivers/acpi/tables/tbgetall.c - 1.8 linux/drivers/serial/clps711x.c - 1.6 linux/include/video/sgivw.h - 1.2 linux/drivers/serial/sa1100.c - 1.5 linux/drivers/input/joystick/grip_mp.c - 1.2 linux/drivers/serial/anakin.c - 1.6 linux/drivers/acpi/namespace/nsxfeval.c - 1.8 linux/drivers/serial/amba.c - 1.7 linux/drivers/acpi/namespace/nsdumpdv.c - 1.7 linux/drivers/serial/8250_pnp.c - 1.5 linux/drivers/serial/8250_pci.c - 1.6 linux/drivers/char/agp/via-agp.c - 1.7 linux/drivers/serial/21285.c - 1.6 linux/drivers/bluetooth/bt3c_cs.c - 1.8 linux/drivers/serial/sunzilog.c - 1.9 linux/drivers/serial/sunsu.c - 1.10 linux/drivers/usb/misc/atmsar.c - 1.4 linux/drivers/usb/misc/atmsar.h - 1.4 linux/drivers/usb/misc/speedtouch.c - 1.11 linux/drivers/i2c/i2c-rpx.c - 1.4 linux/drivers/i2c/i2c-frodo.c - 1.4 linux/drivers/char/genrtc.c - 1.4 linux/arch/i386/kernel/cpu/mtrr/if.c - 1.3 linux/drivers/acpi/numa.c - 1.5 linux/net/sctp/ipv6.c - 1.9 linux/include/net/sctp/ulpqueue.h - 1.3 linux/include/net/sctp/structs.h - 1.10 linux/net/sctp/ulpqueue.c - 1.4 linux/drivers/ide/setup-pci.c - 1.9 linux/drivers/ide/ppc/pmac.c - 1.4 linux/drivers/ide/ppc/mpc8xx.c - 1.2 linux/drivers/ide/pci/via82cxxx.c - 1.6 linux/drivers/ide/pci/trm290.c - 1.7 linux/drivers/ide/pci/slc90e66.c - 1.6 linux/drivers/ide/pci/sl82c105.c - 1.7 linux/drivers/ide/pci/sis5513.c - 1.8 linux/drivers/ide/pci/siimage.h - 1.5 linux/drivers/ide/pci/siimage.c - 1.7 linux/drivers/ide/pci/serverworks.c - 1.7 linux/drivers/ide/pci/rz1000.c - 1.5 linux/drivers/ide/pci/piix.c - 1.7 linux/drivers/ide/pci/pdcadma.c - 1.7 linux/drivers/ide/pci/pdc202xx_old.c - 1.8 linux/drivers/ide/pci/pdc202xx_new.c - 1.8 linux/drivers/ide/pci/opti621.c - 1.6 linux/drivers/ide/pci/ns87415.c - 1.6 linux/drivers/ide/pci/it8172.c - 1.6 linux/drivers/ide/pci/hpt366.c - 1.8 linux/drivers/ide/pci/hpt34x.c - 1.7 linux/drivers/ide/pci/generic.c - 1.6 linux/drivers/ide/pci/cy82c693.h - 1.6 linux/drivers/ide/pci/cy82c693.c - 1.8 linux/drivers/ide/pci/cs5530.c - 1.7 linux/drivers/ide/pci/cmd64x.c - 1.6 linux/drivers/ide/pci/cmd640.c - 1.3 linux/drivers/ide/pci/amd74xx.c - 1.10 linux/drivers/ide/pci/alim15x3.c - 1.6 linux/drivers/ide/pci/aec62xx.c - 1.7 linux/drivers/ide/pci/adma100.c - 1.3 linux/drivers/ide/legacy/umc8672.c - 1.3 linux/drivers/ide/legacy/qd65xx.h - 1.2 linux/drivers/ide/legacy/qd65xx.c - 1.2 linux/drivers/ide/legacy/q40ide.c - 1.2 linux/drivers/ide/legacy/pdc4030.h - 1.2 linux/drivers/ide/legacy/pdc4030.c - 1.4 linux/drivers/ide/legacy/macide.c - 1.2 linux/drivers/ide/legacy/ide-cs.c - 1.4 linux/drivers/ide/legacy/ht6560b.c - 1.2 linux/drivers/ide/legacy/gayle.c - 1.2 linux/drivers/ide/legacy/falconide.c - 1.3 linux/drivers/ide/legacy/dtc2278.c - 1.2 linux/drivers/ide/legacy/buddha.c - 1.2 linux/drivers/ide/legacy/ali14xx.c - 1.2 linux/drivers/ide/ide-iops.c - 1.4 linux/drivers/ide/arm/icside.c - 1.3 linux/drivers/ide/arm/rapide.c - 1.3 linux/arch/s390x/vmlinux.lds.S - 1.8 linux/arch/s390/vmlinux.lds.S - 1.8 linux/arch/i386/mm/hugetlbpage.c - 1.11 linux/arch/i386/mach-visws/traps.c - 1.2 linux/arch/i386/mach-visws/Makefile - 1.4 linux/arch/i386/mach-visws/mpparse.c - 1.2 linux/arch/i386/mach-visws/pci-visws.c - 1.2 linux/arch/i386/mach-visws/setup.c - 1.2 linux/arch/i386/mach-visws/visws_apic.c - 1.3 linux/Documentation/vm/hugetlbpage.txt - 1.3 linux/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c - 1.7 linux/arch/i386/kernel/cpu/cpufreq/speedstep.c - 1.8 linux/arch/i386/kernel/cpu/cpufreq/longrun.c - 1.6 linux/sound/pci/via82xx.c - 1.7 linux/include/asm-s390x/kmap_types.h - 1.2 linux/drivers/usb/serial/console.c - 1.2 linux/drivers/scsi/nsp32.c - 1.5 linux/drivers/scsi/aacraid/linit.c - 1.7 linux/net/bluetooth/rfcomm/tty.c - 1.6 linux/net/bluetooth/rfcomm/sock.c - 1.6 linux/net/bluetooth/rfcomm/core.c - 1.7 linux/net/bluetooth/bnep/sock.c - 1.4 linux/net/bluetooth/bnep/core.c - 1.6 linux/net/bluetooth/bnep/bnep.h - 1.3 linux/Documentation/rpc-cache.txt - 1.3 linux/fs/cifs/cifsfs.c - 1.6 linux/fs/nfsd/nfs4xdr.c - 1.7 linux/fs/cifs/cifsglob.h - 1.4 linux/fs/cifs/cifsproto.h - 1.6 linux/fs/cifs/cifssmb.c - 1.7 linux/fs/cifs/connect.c - 1.6 linux/fs/cifs/file.c - 1.6 linux/fs/cifs/inode.c - 1.6 linux/fs/cifs/misc.c - 1.4 linux/fs/nfsd/nfs4proc.c - 1.5 linux/fs/cifs/CHANGES - 1.5 linux/fs/cifs/transport.c - 1.4 linux/drivers/isdn/hardware/eicon/mi_pc.h - 1.3 linux/drivers/isdn/hardware/eicon/io.c - 1.2 linux/drivers/isdn/hardware/eicon/i4lididrv.c - 1.5 linux/include/linux/nfsd/xdr4.h - 1.6 linux/drivers/isdn/hardware/eicon/capimain.c - 1.3 linux/drivers/isdn/hardware/eicon/divasproc.c - 1.3 linux/drivers/isdn/hardware/eicon/divasmain.c - 1.5 linux/drivers/isdn/hardware/eicon/divasi.c - 1.3 linux/drivers/isdn/hardware/eicon/divamnt.c - 1.3 linux/net/rxrpc/sysctl.c - 1.2 linux/drivers/oprofile/buffer_sync.c - 1.7 linux/drivers/oprofile/oprofile_stats.c - 1.2 linux/drivers/char/tipar.c - 1.5 linux/arch/i386/kernel/profile.c - 1.2 linux/arch/x86_64/mm/pageattr.c - 1.2 linux/drivers/pnp/pnpbios/core.c - 1.7 linux/Documentation/pnp.txt - 1.2 linux/drivers/pnp/resource.c - 1.6 linux/arch/x86_64/kernel/profile.c - 1.3 linux/drivers/pnp/names.c - 1.4 linux/drivers/pnp/base.h - 1.4 linux/drivers/pnp/core.c - 1.6 linux/drivers/pnp/driver.c - 1.6 linux/drivers/pnp/system.c - 1.4 linux/drivers/pnp/isapnp/core.c - 1.7 linux/drivers/pnp/interface.c - 1.6 linux/include/linux/pnp.h - 1.7 linux/drivers/bluetooth/Kconfig - 1.3 linux/drivers/net/Kconfig - 1.9 linux/drivers/net/pcmcia/Kconfig - 1.3 linux/drivers/net/tokenring/Kconfig - 1.6 linux/arch/alpha/Kconfig - 1.8 linux/arch/i386/Kconfig - 1.12 linux/drivers/net/wireless/Kconfig - 1.4 linux/arch/i386/mach-voyager/voyager_smp.c - 1.5 linux/arch/parisc/kernel/ioctl32.c - 1.3 linux/drivers/media/dvb/av7110/saa7146_core.c - 1.3 linux/drivers/s390/Kconfig - 1.4 linux/net/bluetooth/rfcomm/Kconfig - 1.3 linux/drivers/scsi/Kconfig - 1.7 linux/arch/s390/Kconfig - 1.6 linux/arch/s390x/Kconfig - 1.7 linux/arch/sparc/Kconfig - 1.7 linux/drivers/ide/Kconfig - 1.6 linux/fs/befs/linuxvfs.c - 1.5 linux/arch/x86_64/Kconfig - 1.10 linux/fs/befs/ChangeLog - 1.4 linux/net/ipv4/xfrm_policy.c - 1.6 linux/net/bluetooth/bnep/Kconfig - 1.3 linux/drivers/video/Kconfig - 1.8 linux/drivers/usb/serial/Kconfig - 1.5 linux/drivers/usb/misc/Kconfig - 1.4 linux/net/ipv6/Kconfig - 1.2 linux/sound/oss/Kconfig - 1.5 linux/net/bluetooth/Kconfig - 1.3 linux/drivers/usb/input/Kconfig - 1.5 linux/include/asm-v850/page.h - 1.2 linux/net/bluetooth/hci_proc.c - 1.2 linux/include/asm-m68knommu/cacheflush.h - 1.2 linux/fs/binfmt_flat.c - 1.3 linux/include/asm-m68knommu/m68360_enet.h - 1.2 linux/include/asm-m68knommu/machdep.h - 1.2 linux/include/asm-m68knommu/mcfmbus.h - 1.2 linux/include/asm-m68knommu/mcfpci.h - 1.2 linux/drivers/parisc/power.c - 1.4 linux/drivers/parisc/lba_pci.c - 1.4 linux/drivers/parisc/dino.c - 1.5 linux/include/linux/flat.h - 1.3 linux/arch/v850/vmlinux.lds.S - 1.6 linux/arch/m68knommu/Kconfig - 1.6 linux/arch/m68knommu/kernel/init_task.c - 1.2 linux/arch/m68knommu/kernel/signal.c - 1.6 linux/arch/m68knommu/mm/Makefile - 1.3 linux/arch/m68knommu/platform/68328/entry.S - 1.3 linux/arch/m68knommu/platform/68328/pilot/crt0_rom.S - 1.2 linux/arch/m68knommu/platform/68360/commproc.c - 1.2 linux/arch/m68knommu/platform/68360/entry.S - 1.3 linux/arch/m68knommu/platform/68360/uCquicc/crt0_ram.S - 1.3 linux/arch/m68knommu/platform/68360/uCquicc/crt0_rom.S - 1.3 linux/arch/m68knommu/vmlinux.lds.S - 1.4 linux/arch/v850/kernel/signal.c - 1.6 linux/arch/v850/kernel/rte_cb_multi.c - 1.2 linux/arch/v850/kernel/process.c - 1.3 linux/arch/v850/kernel/init_task.c - 1.2 linux/arch/v850/kernel/irq.c - 1.4 linux/arch/v850/kernel/intv.S - 1.3 linux/include/asm-v850/entry.h - 1.2 linux/include/asm-v850/asm.h - 1.3 linux/arch/v850/kernel/entry.S - 1.4 linux/arch/v850/kernel/bug.c - 1.3 linux/arch/v850/Kconfig - 1.6 linux/drivers/serial/68360serial.c - 1.6 linux/drivers/serial/mcfserial.c - 1.3 linux/drivers/serial/nb85e_uart.c - 1.5 linux/net/key/af_key.c - 1.6 linux/drivers/s390/net/cu3088.c - 1.3 linux/drivers/scsi/scsi_sysfs.c - 1.5 linux/drivers/pnp/card.c - 1.5 linux/drivers/s390/char/tape_34xx.c - 1.2 linux/drivers/ide/pci/sc1200.c - 1.4 linux/Documentation/s390/driver-model.txt - 1.2 linux/drivers/acpi/namespace/nsparse.c - 1.5 linux/Documentation/scsi/ChangeLog.sym53c8xx_2 - 1.2 linux/Documentation/scsi/scsi_mid_low_api.txt - 1.2 linux/arch/sparc64/kernel/profile.c - 1.2 linux/drivers/s390/char/tape_core.c - 1.3 linux/arch/sparc64/oprofile/timer_int.c - 1.3 linux/drivers/acpi/events/evgpe.c - 1.5 linux/drivers/acpi/dispatcher/dsinit.c - 1.6 linux/drivers/ide/pci/cs5520.c - 1.4 linux/drivers/s390/cio/ccwgroup.c - 1.3 linux/drivers/s390/cio/device.c - 1.3 linux/net/ipv4/xfrm_user.c - 1.3 linux/drivers/s390/cio/device_id.c - 1.2 linux/include/asm-s390x/cio.h - 1.2 linux/include/asm-s390/cio.h - 1.2 linux/drivers/s390/cio/device_ops.c - 1.2 linux/drivers/s390/cio/device_pgid.c - 1.2 linux/drivers/s390/cio/device_status.c - 1.2 linux/drivers/s390/cio/ioasm.h - 1.2 linux/drivers/s390/cio/qdio.c - 1.2 linux/arch/s390x/kernel/module.c - 1.5 linux/arch/s390/kernel/module.c - 1.5 linux/arch/ppc64/oprofile/timer_int.c - 1.3 linux/drivers/s390/cio/qdio.h - 1.2 linux/arch/ppc64/kernel/profile.c - 1.2 linux/drivers/char/watchdog/w83877f_wdt.c - 1.5 linux/arch/x86_64/mm/hugetlbpage.c - 1.5 linux/drivers/i2c/chips/adm1021.c - 1.2 linux/drivers/i2c/chips/lm75.c - 1.2 linux/include/asm-s390x/compat.h - 1.4 linux/arch/um/include/sysdep-i386/checksum.h - 1.2 linux/drivers/scsi/aic7xxx/aic79xx.h - 1.2 linux/include/asm-i386/mach-visws/setup_arch_post.h - 1.2 linux/include/asm-i386/mach-visws/irq_vectors.h - 1.2 linux/include/asm-i386/mach-visws/do_timer.h - 1.2 linux/drivers/scsi/aic7xxx/aic79xx_osm.c - 1.5 linux/drivers/scsi/aic7xxx/aic79xx_pci.c - 1.4 linux/drivers/scsi/aic7xxx/aic7xxx_osm.c - 1.5 linux/drivers/char/watchdog/wafer5823wdt.c - 1.4 linux/drivers/char/watchdog/sc520_wdt.c - 1.4 linux/drivers/media/video/bt832.h - 1.2 linux/drivers/ide/pci/triflex.c - 1.2 linux/drivers/media/video/bt832.c - 1.2 linux/arch/parisc/kernel/profile.c - 1.2 linux/net/sunrpc/auth_gss/sunrpcgss_syms.c - 1.2 linux/net/sunrpc/auth_gss/auth_gss.c - 1.2 linux/drivers/char/ipmi/ipmi_kcs_intf.c - 1.2 linux/drivers/char/ipmi/ipmi_msghandler.c - 1.2 linux/include/linux/ipmi_smi.h - 1.2 linux/include/asm-alpha/core_marvel.h - 1.2 linux/fs/proc/task_nommu.c - 1.2 linux/include/acpi/platform/aclinux.h - 1.3 linux/include/acpi/platform/acgcc.h - 1.2 linux/include/acpi/acconfig.h - 1.2 linux/include/acpi/acdebug.h - 1.2 linux/include/acpi/acdispat.h - 1.2 linux/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl - 1.2 linux/include/acpi/platform/acenv.h - 1.3 linux/include/acpi/amlcode.h - 1.2 linux/include/acpi/acutils.h - 1.2 linux/include/acpi/actypes.h - 1.2 linux/include/acpi/actbl2.h - 1.2 linux/include/acpi/actbl1.h - 1.2 linux/include/acpi/actbl.h - 1.2 linux/include/acpi/actables.h - 1.2 linux/include/acpi/acstruct.h - 1.2 linux/include/acpi/acresrc.h - 1.2 linux/include/acpi/acpixf.h - 1.3 linux/include/acpi/acpiosxf.h - 1.3 linux/include/acpi/acpi.h - 1.3 linux/include/acpi/acparser.h - 1.2 linux/include/acpi/acoutput.h - 1.2 linux/include/acpi/acobject.h - 1.2 linux/include/acpi/acnamesp.h - 1.2 linux/include/acpi/acmacros.h - 1.2 linux/include/acpi/aclocal.h - 1.2 linux/include/acpi/acevents.h - 1.2 linux/include/acpi/acinterp.h - 1.2 linux/include/acpi/acexcep.h - 1.2 linux/include/acpi/acglobal.h - 1.2 linux/include/acpi/achware.h - 1.2 linux/scripts/modpost.c - 1.2 linux/net/ipv6/xfrm_policy.c - 1.2 From owner-linux-xfs@oss.sgi.com Tue Feb 25 07:40:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Feb 2003 07:41: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 h1PFep3v014435 for ; Tue, 25 Feb 2003 07:40:52 -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 h1PFekG8002853 for ; Tue, 25 Feb 2003 07:40: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 JAA74729 for ; Tue, 25 Feb 2003 09:40:45 -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 JAA60782 for ; Tue, 25 Feb 2003 09:40:45 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h1PFejN02192; Tue, 25 Feb 2003 09:40:45 -0600 Message-Id: <200302251540.h1PFejN02192@jen.americas.sgi.com> Date: Tue, 25 Feb 2003 09:40:45 -0600 Subject: TAKE - remove a couple more sync transactions from xfs To: linux-xfs@oss.sgi.com X-archive-position: 2915 X-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: 715 Lines: 25 This was a case left behind in the previous async transaction work. Only affects moving a file from a single block of extents to holding its extents in the inode. Date: Tue Feb 25 07:39:36 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:140254a linux/fs/xfs/xfs_bmap_btree.h - 1.56 - prototype changes linux/fs/xfs/xfs_bmap_btree.c - 1.133 - remove the sync transaction from xfs_bmbt_killroot linux/fs/xfs/xfs_bmap.c - 1.299 - take more advantage of the async transaction code, and do not mark transactions which move extents from a block to in inode format synchronous From owner-linux-xfs@oss.sgi.com Tue Feb 25 07:51:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Feb 2003 07:51:21 -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 h1PFpF3v017129 for ; Tue, 25 Feb 2003 07:51:15 -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 h1PFp9G8004802 for ; Tue, 25 Feb 2003 07:51:10 -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 JAA21477 for ; Tue, 25 Feb 2003 09:51:08 -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 JAA72643 for ; Tue, 25 Feb 2003 09:51:08 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h1PN70T12319 for linux-xfs@oss.sgi.com; Tue, 25 Feb 2003 18:07:00 -0500 Resent-Message-Id: <200302252307.h1PN70T12319@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 JAA02621 for ; Tue, 25 Feb 2003 09:50:48 -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 h1PFokok12415724 for ; Tue, 25 Feb 2003 07:50:47 -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 h1PFlrJI000992 for ; Tue, 25 Feb 2003 16:47:53 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id h1PFlrkA000991 for hch@sgi.com; Tue, 25 Feb 2003 16:47:53 +0100 Date: Tue, 25 Feb 2003 16:47:53 +0100 From: Christoph Hellwig Message-Id: <200302251547.h1PFlrkA000991@lab343.munich.sgi.com> Subject: TAKE - Remove flags argument from xattr inode operations again To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Tue, 25 Feb 2003 18:07:00 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 2916 X-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: 790 Lines: 29 Thanks go to Andreas Gruenbacher for lots of comments and the final tidbits. Date: Tue Feb 25 07:49:06 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:140255a linux/include/linux/fs.h - 1.207 linux/fs/ext2/acl.c - 1.10 linux/fs/xfs/linux/xfs_iops.c - 1.194 linux/fs/ext3/acl.c - 1.7 linux/fs/xattr.c - 1.13 linux/include/linux/xattr.h - 1.4 linux/fs/jfs/jfs_xattr.h - 1.5 linux/fs/jfs/xattr.c - 1.9 linux/fs/ext3/xattr_user.c - 1.4 linux/fs/ext3/xattr.h - 1.4 linux/fs/ext3/xattr.c - 1.4 linux/fs/ext2/xattr_user.c - 1.4 linux/fs/ext2/xattr.h - 1.4 linux/fs/ext2/xattr.c - 1.4 linux/fs/ext3/xattr_trusted.c - 1.2 linux/fs/ext2/xattr_trusted.c - 1.2 From owner-linux-xfs@oss.sgi.com Tue Feb 25 09:23:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Feb 2003 09:23:45 -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 h1PHNZ3v019260 for ; Tue, 25 Feb 2003 09:23:35 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1PHNYJG019259 for linux-xfs@oss.sgi.com; Tue, 25 Feb 2003 09:23:34 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1PHNW3v019246 for ; Tue, 25 Feb 2003 09:23:32 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1PGxv4g019008; Tue, 25 Feb 2003 08:59:57 -0800 Date: Tue, 25 Feb 2003 08:59:57 -0800 Message-Id: <200302251659.h1PGxv4g019008@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 225] thread deadlock on full fs. X-Bugzilla-Reason: AssignedTo X-archive-position: 2917 X-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: 616 Lines: 21 http://oss.sgi.com/bugzilla/show_bug.cgi?id=225 ------- Additional Comments From stephy32@videotron.ca 2003-02-25 08:59 ------- Created an attachment (id=66) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=66&action=view) kdb ps, dmesg, bta for feb24 xfs-cvs I checked out Feb 24 xfs-cvs tree and tried th etest again. Same result. Here's the bta for Feb 24 cvs tree, same .config as before build with gcc 2.96-113. Also tried compiling the kernel with 2.96-85 with similar results. ------- 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 25 09:57:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Feb 2003 09:57:19 -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 h1PHvA3v020625 for ; Tue, 25 Feb 2003 09:57:11 -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 h1PI76kq025132 for ; Tue, 25 Feb 2003 12:07:06 -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 LAA70202 for ; Tue, 25 Feb 2003 11:57:04 -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 LAA87814 for ; Tue, 25 Feb 2003 11:57:04 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h1PHv4306528; Tue, 25 Feb 2003 11:57:04 -0600 Message-Id: <200302251757.h1PHv4306528@jen.americas.sgi.com> Date: Tue, 25 Feb 2003 11:57:04 -0600 Subject: TAKE 882348 - remove incorrect debug check from log recovery To: linux-xfs@oss.sgi.com X-archive-position: 2918 X-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: 463 Lines: 20 Debug kernel issue only Date: Tue Feb 25 09:56:10 PST 2003 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.4 Inspected by: overby@sgi.com Author: lord Merged by: lord Merged mods: grove2:irix:140267a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:140267a linux/fs/xfs/xfs_log_recover.c - 1.255 - Merge of grove2:irix:140267a by lord. remove the xfs_inobp_check calls in recovery From owner-linux-xfs@oss.sgi.com Tue Feb 25 10:23:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Feb 2003 10:23:40 -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 h1PINY3v022931 for ; Tue, 25 Feb 2003 10:23:34 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1PINYWa022927 for linux-xfs@oss.sgi.com; Tue, 25 Feb 2003 10:23:34 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1PINW3x022908 for ; Tue, 25 Feb 2003 10:23:33 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1PI7CcZ021235; Tue, 25 Feb 2003 10:07:12 -0800 Date: Tue, 25 Feb 2003 10:07:12 -0800 Message-Id: <200302251807.h1PI7CcZ021235@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 225] thread deadlock on full fs. X-Bugzilla-Reason: AssignedTo X-archive-position: 2919 X-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: 15 http://oss.sgi.com/bugzilla/show_bug.cgi?id=225 cattelan@thebarn.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- 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 25 11:23:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Feb 2003 11:23: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 h1PJNZ3v025025 for ; Tue, 25 Feb 2003 11:23:35 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1PJNZNW025024 for linux-xfs@oss.sgi.com; Tue, 25 Feb 2003 11:23:35 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1PJNX3x025006 for ; Tue, 25 Feb 2003 11:23:33 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1PJI2LZ024311; Tue, 25 Feb 2003 11:18:02 -0800 Date: Tue, 25 Feb 2003 11:18:02 -0800 Message-Id: <200302251918.h1PJI2LZ024311@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: 2920 X-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: 673 Lines: 20 http://oss.sgi.com/bugzilla/show_bug.cgi?id=218 lord@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lord@sgi.com 2003-02-25 11:18 ------- This appears to have been a case of a filesystem setup while the mapcheck bug was present. Since running mapcheck on the machine there has been no-reoccurence. ------- 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 25 13:17:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Feb 2003 13:18:28 -0800 (PST) Received: from imf17bis.bellsouth.net (mail217.mail.bellsouth.net [205.152.58.157]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1PLHn3v027310 for ; Tue, 25 Feb 2003 13:17:50 -0800 Received: from tiger2 ([66.156.0.201]) by imf17bis.bellsouth.net (InterMail vM.5.01.04.25 201-253-122-122-125-20020815) with SMTP id <20030225211942.VGPJ12211.imf17bis.bellsouth.net@tiger2> for ; Tue, 25 Feb 2003 16:19:42 -0500 Date: Tue, 25 Feb 2003 16:21:07 -0500 From: Greg Freemyer Subject: xfsdump and SuSE 8.0 and curses To: xfs mailing list Mime-Version: 1.0 Organization: Norcross Group X-Mailer: GoldMine [6.00.21021] Content-Type: Text/plain Message-Id: <20030225211942.VGPJ12211.imf17bis.bellsouth.net@tiger2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h1PLHo3v027311 X-archive-position: 2921 X-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-ml@NorcrossGroup.com Precedence: bulk X-list: linux-xfs Content-Length: 777 Lines: 28 I have a SuSE 8.0 box I'm trying to update to xfs 1.2 I have everything updated but xfsdump. I downloaded the xfsdump-2.2.3-1.src.rpm, but when I try rpm --rebuild, I'm getting === checking for sed... /usr/bin/sed checking for echo... /bin/echo checking for libtool... /usr/bin/libtool checking how to run the C preprocessor... gcc -E checking for uuid/uuid.h... yes checking for uuid_generate in -luuid... yes checking for curses.h... yes checking for initscr in -lcurses... no FATAL ERROR: could not find a valid curses library. make: *** [include/builddefs] Error 1 Bad exit status from /var/tmp/rpm-tmp.14028 (%build) === In general I know the issue is that SuSE uses ncurses, not curses, but what do I have to do to get this to upgrade? TIA Greg -- Greg Freemyer From owner-linux-xfs@oss.sgi.com Tue Feb 25 13:25:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Feb 2003 13:26:29 -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 h1PLPt3v028526 for ; Tue, 25 Feb 2003 13:25:56 -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 h1PLPnG8004018 for ; Tue, 25 Feb 2003 13:25:49 -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 IAA20129; Wed, 26 Feb 2003 08:24:33 +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 IAA23720; Wed, 26 Feb 2003 08:24:32 +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 h1PLMLwL000850; Wed, 26 Feb 2003 08:22:21 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h1PLMDwM000848; Wed, 26 Feb 2003 08:22:13 +1100 Date: Wed, 26 Feb 2003 08:22:13 +1100 From: Nathan Scott To: Greg Freemyer Cc: xfs mailing list Subject: Re: xfsdump and SuSE 8.0 and curses Message-ID: <20030225212213.GB710@frodo> References: <20030225211942.VGPJ12211.imf17bis.bellsouth.net@tiger2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030225211942.VGPJ12211.imf17bis.bellsouth.net@tiger2> User-Agent: Mutt/1.5.3i X-archive-position: 2922 X-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: 1007 Lines: 33 On Tue, Feb 25, 2003 at 04:21:07PM -0500, Greg Freemyer wrote: > > I have a SuSE 8.0 box I'm trying to update to xfs 1.2 > > I have everything updated but xfsdump. > > I downloaded the xfsdump-2.2.3-1.src.rpm, but when I try rpm --rebuild, I'm getting > > === > checking for sed... /usr/bin/sed > checking for echo... /bin/echo > checking for libtool... /usr/bin/libtool > checking how to run the C preprocessor... gcc -E > checking for uuid/uuid.h... yes > checking for uuid_generate in -luuid... yes > checking for curses.h... yes > checking for initscr in -lcurses... no > FATAL ERROR: could not find a valid curses library. > make: *** [include/builddefs] Error 1 > Bad exit status from /var/tmp/rpm-tmp.14028 (%build) > === > > In general I know the issue is that SuSE uses ncurses, not curses, but what do I have to do to get this to upgrade? > Christoph fixed this up in xfsdump-2.2.4 (see xfsdump/doc/CHANGES). Let me guess, XFS 1.2 has xfsdump-2.2.3? If so, darn. ;) cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Feb 25 13:37:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Feb 2003 13:37:45 -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 h1PLbA3v001082 for ; Tue, 25 Feb 2003 13:37:12 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id C65DB1911266; Tue, 25 Feb 2003 13:37:10 -0800 (PST) Date: Tue, 25 Feb 2003 13:37:10 -0800 From: Chris Wedgwood To: Stephen Lord Cc: Ethan Benson , linux-xfs@oss.sgi.com Subject: Re: TAKE - attr-2.3.0, add trusted namespace into XFS Message-ID: <20030225213710.GA22042@f00f.org> References: <200302250911.h1P9BdOb874080@snort.melbourne.sgi.com> <20030225093429.GB27906@plato.local.lan> <1046169145.1367.1.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1046169145.1367.1.camel@localhost.localdomain> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2923 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 335 Lines: 11 On Tue, Feb 25, 2003 at 04:32:23AM -0600, Stephen Lord wrote: > These name strings do not actually hit the disk at all, internally, > xfs strips them off. So all this does is change the string prefix > used by xfs to map to the different attribute domains. So if I boot to an older kernel and have newer userspace I loose? --cw From owner-linux-xfs@oss.sgi.com Tue Feb 25 13:39:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Feb 2003 13:39:34 -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 h1PLd13v001412 for ; Tue, 25 Feb 2003 13:39:01 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1PLd1nM001411 for linux-xfs@oss.sgi.com; Tue, 25 Feb 2003 13:39: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 h1PLcx3v001400; Tue, 25 Feb 2003 13:38:59 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 648C31911266; Tue, 25 Feb 2003 13:38:59 -0800 (PST) Date: Tue, 25 Feb 2003 13:38:59 -0800 From: Chris Wedgwood To: bugzilla-daemon@oss.sgi.com Cc: xfs-master@oss.sgi.com Subject: Re: [Bug 218] Probable mmap() bug that breaks cpp-3.2 Message-ID: <20030225213859.GB22042@f00f.org> References: <200302251918.h1PJI2LZ024311@oss.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200302251918.h1PJI2LZ024311@oss.sgi.com> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2924 X-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: 354 Lines: 13 On Tue, Feb 25, 2003 at 11:18:02AM -0800, bugzilla-daemon@oss.sgi.com wrote: > This appears to have been a case of a filesystem setup while the > mapcheck bug was present. Since running mapcheck on the machine > there has been no-reoccurence. mapcheck is required to fix this? doesn't this mean a malicious user and cause this lockup still? --cw From owner-linux-xfs@oss.sgi.com Tue Feb 25 13:39:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Feb 2003 13:39:59 -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 h1PLdQ3v001459 for ; Tue, 25 Feb 2003 13:39:26 -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 h1PLnMkq020808 for ; Tue, 25 Feb 2003 15:49:23 -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 PAA72240; Tue, 25 Feb 2003 15:39:19 -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 PAA69456; Tue, 25 Feb 2003 15:39:20 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h1PLdJU13199; Tue, 25 Feb 2003 15:39:19 -0600 Subject: Re: TAKE - attr-2.3.0, add trusted namespace into XFS From: Steve Lord To: Chris Wedgwood Cc: Ethan Benson , linux-xfs@oss.sgi.com In-Reply-To: <20030225213710.GA22042@f00f.org> References: <200302250911.h1P9BdOb874080@snort.melbourne.sgi.com> <20030225093429.GB27906@plato.local.lan> <1046169145.1367.1.camel@localhost.localdomain> <20030225213710.GA22042@f00f.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1046209159.31695.1991.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 25 Feb 2003 15:39:19 -0600 X-archive-position: 2925 X-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: 741 Lines: 23 On Tue, 2003-02-25 at 15:37, Chris Wedgwood wrote: > On Tue, Feb 25, 2003 at 04:32:23AM -0600, Stephen Lord wrote: > > > These name strings do not actually hit the disk at all, internally, > > xfs strips them off. So all this does is change the string prefix > > used by xfs to map to the different attribute domains. > > So if I boot to an older kernel and have newer userspace I loose? Yep, unless you use the environment variable Nathan mentioned in his original message (I do not have it here, but I seem to remember him mentioning one for backwards compatibility). Steve > > > --cw -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Feb 25 13:45:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Feb 2003 13:45:55 -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 h1PLjM3v002723 for ; Tue, 25 Feb 2003 13:45:22 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1PLjM31002722 for linux-xfs@oss.sgi.com; Tue, 25 Feb 2003 13:45:22 -0800 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 h1PLjK3v002710; Tue, 25 Feb 2003 13:45:21 -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 h1PLtHkq021636; Tue, 25 Feb 2003 15:55:17 -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 PAA02739; Tue, 25 Feb 2003 15:45:15 -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 PAA77273; Tue, 25 Feb 2003 15:45:15 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h1PLjFJ13210; Tue, 25 Feb 2003 15:45:15 -0600 Subject: Re: [Bug 218] Probable mmap() bug that breaks cpp-3.2 From: Steve Lord To: Chris Wedgwood Cc: bugzilla-daemon@oss.sgi.com, xfs-master@oss.sgi.com In-Reply-To: <20030225213859.GB22042@f00f.org> References: <200302251918.h1PJI2LZ024311@oss.sgi.com> <20030225213859.GB22042@f00f.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1046209514.31698.2000.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 25 Feb 2003 15:45:14 -0600 X-archive-position: 2926 X-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: 809 Lines: 24 On Tue, 2003-02-25 at 15:38, Chris Wedgwood wrote: > On Tue, Feb 25, 2003 at 11:18:02AM -0800, bugzilla-daemon@oss.sgi.com wrote: > > > This appears to have been a case of a filesystem setup while the > > mapcheck bug was present. Since running mapcheck on the machine > > there has been no-reoccurence. > > mapcheck is required to fix this? > > doesn't this mean a malicious user and cause this lockup still? Nope, the problem was this filesystem was last running a kernel from the time period where that bug was present. So there were a bunch of files in this state. Running mapcheck cleaned up the filesystems, and a new kernel cleaned up the bug. 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 25 13:51:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Feb 2003 13:52:15 -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 h1PLph3v003346 for ; Tue, 25 Feb 2003 13:51:43 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1PLphD2003345 for linux-xfs@oss.sgi.com; Tue, 25 Feb 2003 13:51:43 -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 h1PLpf3v003333; Tue, 25 Feb 2003 13:51:42 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id C21101911266; Tue, 25 Feb 2003 13:51:41 -0800 (PST) Date: Tue, 25 Feb 2003 13:51:41 -0800 From: Chris Wedgwood To: Steve Lord Cc: bugzilla-daemon@oss.sgi.com, xfs-master@oss.sgi.com Subject: Re: [Bug 218] Probable mmap() bug that breaks cpp-3.2 Message-ID: <20030225215141.GA22195@f00f.org> References: <200302251918.h1PJI2LZ024311@oss.sgi.com> <20030225213859.GB22042@f00f.org> <1046209514.31698.2000.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1046209514.31698.2000.camel@jen.americas.sgi.com> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2927 X-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: 500 Lines: 16 On Tue, Feb 25, 2003 at 03:45:14PM -0600, Steve Lord wrote: > Nope, the problem was this filesystem was last running a kernel from > the time period where that bug was present. So there were a bunch of > files in this state. Running mapcheck cleaned up the filesystems, > and a new kernel cleaned up the bug. I'm confused.... i read it as, 'new kernel, will deadlock, mapcheck fixes this'. So I assumed I could store data past EOF and still confuse a new kernel. I was wrong I take it? --cw From owner-linux-xfs@oss.sgi.com Tue Feb 25 13:52:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Feb 2003 13:53:15 -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 h1PLqh3v003528 for ; Tue, 25 Feb 2003 13:52:44 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id E87B01911266; Tue, 25 Feb 2003 13:52:43 -0800 (PST) Date: Tue, 25 Feb 2003 13:52:43 -0800 From: Chris Wedgwood To: Steve Lord Cc: Ethan Benson , linux-xfs@oss.sgi.com Subject: Re: TAKE - attr-2.3.0, add trusted namespace into XFS Message-ID: <20030225215243.GB22195@f00f.org> References: <200302250911.h1P9BdOb874080@snort.melbourne.sgi.com> <20030225093429.GB27906@plato.local.lan> <1046169145.1367.1.camel@localhost.localdomain> <20030225213710.GA22042@f00f.org> <1046209159.31695.1991.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1046209159.31695.1991.camel@jen.americas.sgi.com> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2928 X-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: 436 Lines: 19 On Tue, Feb 25, 2003 at 03:39:19PM -0600, Steve Lord wrote: > Yep, unless you use the environment variable Nathan mentioned in his > original message (I do not have it here, but I seem to remember him > mentioning one for backwards compatibility). Yes. I saw that. IMO it sucks. I means I have to conciously check my kernel version and bugger about or else things break. Great. Imagine if tar or cp worked this way... --cw From owner-linux-xfs@oss.sgi.com Tue Feb 25 14:00:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Feb 2003 14:00:44 -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 h1PM0B3v004326 for ; Tue, 25 Feb 2003 14:00:11 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1PM0BqY004325 for linux-xfs@oss.sgi.com; Tue, 25 Feb 2003 14:00:11 -0800 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 h1PM093v004296; Tue, 25 Feb 2003 14:00:09 -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 h1PMA6kq024290; Tue, 25 Feb 2003 16:10:06 -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 QAA50564; Tue, 25 Feb 2003 16:00:03 -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 QAA65746; Tue, 25 Feb 2003 16:00:03 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h1PM03U10753; Tue, 25 Feb 2003 16:00:03 -0600 Subject: Re: [Bug 218] Probable mmap() bug that breaks cpp-3.2 From: Steve Lord To: Chris Wedgwood Cc: bugzilla-daemon@oss.sgi.com, xfs-master@oss.sgi.com In-Reply-To: <20030225215141.GA22195@f00f.org> References: <200302251918.h1PJI2LZ024311@oss.sgi.com> <20030225213859.GB22042@f00f.org> <1046209514.31698.2000.camel@jen.americas.sgi.com> <20030225215141.GA22195@f00f.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1046210402.31695.2021.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 25 Feb 2003 16:00:03 -0600 X-archive-position: 2929 X-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: 858 Lines: 27 On Tue, 2003-02-25 at 15:51, Chris Wedgwood wrote: > On Tue, Feb 25, 2003 at 03:45:14PM -0600, Steve Lord wrote: > > > Nope, the problem was this filesystem was last running a kernel from > > the time period where that bug was present. So there were a bunch of > > files in this state. Running mapcheck cleaned up the filesystems, > > and a new kernel cleaned up the bug. > > I'm confused.... i read it as, 'new kernel, will deadlock, mapcheck > fixes this'. Nope, old kernel created bad files, confused cpp in gcc 3.2, new kernel does not generate these files. mapcheck fixes up old files/ > > So I assumed I could store data past EOF and still confuse a new > kernel. I was wrong I take it? Yep. 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 25 14:00:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Feb 2003 14:01:06 -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 h1PM0X3v004335 for ; Tue, 25 Feb 2003 14:00: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 h1PMASkq024356 for ; Tue, 25 Feb 2003 16:10: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 IAA20674; Wed, 26 Feb 2003 08:59:10 +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 IAA80758; Wed, 26 Feb 2003 08:59:09 +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 h1PLuwwL001008; Wed, 26 Feb 2003 08:56:58 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h1PLuviL001006; Wed, 26 Feb 2003 08:56:57 +1100 Date: Wed, 26 Feb 2003 08:56:57 +1100 From: Nathan Scott To: Steve Lord Cc: Chris Wedgwood , Ethan Benson , linux-xfs@oss.sgi.com Subject: Re: TAKE - attr-2.3.0, add trusted namespace into XFS Message-ID: <20030225215657.GD710@frodo> References: <200302250911.h1P9BdOb874080@snort.melbourne.sgi.com> <20030225093429.GB27906@plato.local.lan> <1046169145.1367.1.camel@localhost.localdomain> <20030225213710.GA22042@f00f.org> <1046209159.31695.1991.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1046209159.31695.1991.camel@jen.americas.sgi.com> User-Agent: Mutt/1.5.3i X-archive-position: 2930 X-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: 724 Lines: 21 On Tue, Feb 25, 2003 at 03:39:19PM -0600, Steve Lord wrote: > On Tue, 2003-02-25 at 15:37, Chris Wedgwood wrote: > > On Tue, Feb 25, 2003 at 04:32:23AM -0600, Stephen Lord wrote: > > > > > These name strings do not actually hit the disk at all, internally, > > > xfs strips them off. So all this does is change the string prefix > > > used by xfs to map to the different attribute domains. > > > > So if I boot to an older kernel and have newer userspace I loose? Uh, what do you think you will loose? > Yep, unless you use the environment variable Nathan mentioned > in his original message (I do not have it here, but I seem to > remember him mentioning one for backwards compatibility). COMPAT_XFSROOT. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Feb 25 14:10:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Feb 2003 14:10: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 h1PMA23v005309 for ; Tue, 25 Feb 2003 14:10:02 -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 h1PM9uG8013534 for ; Tue, 25 Feb 2003 14:09:56 -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 JAA20882; Wed, 26 Feb 2003 09:08:40 +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 JAA04211; Wed, 26 Feb 2003 09:08: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 h1PM6TwL001039; Wed, 26 Feb 2003 09:06:29 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h1PM6SMM001037; Wed, 26 Feb 2003 09:06:28 +1100 Date: Wed, 26 Feb 2003 09:06:28 +1100 From: Nathan Scott To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - attr-2.3.0, add trusted namespace into XFS Message-ID: <20030225220628.GE710@frodo> References: <200302250911.h1P9BdOb874080@snort.melbourne.sgi.com> <20030225093429.GB27906@plato.local.lan> <1046169145.1367.1.camel@localhost.localdomain> <20030225213710.GA22042@f00f.org> <1046209159.31695.1991.camel@jen.americas.sgi.com> <20030225215243.GB22195@f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030225215243.GB22195@f00f.org> User-Agent: Mutt/1.5.3i X-archive-position: 2931 X-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: 862 Lines: 29 On Tue, Feb 25, 2003 at 01:52:43PM -0800, Chris Wedgwood wrote: > On Tue, Feb 25, 2003 at 03:39:19PM -0600, Steve Lord wrote: > > > Yep, unless you use the environment variable Nathan mentioned in his > > original message (I do not have it here, but I seem to remember him > > mentioning one for backwards compatibility). > > Yes. I saw that. IMO it sucks. > > I means I have to conciously check my kernel version and bugger about > or else things break. The only thing that could go "wrong" is in xfsdump/restore at the moment, and there are acceptable workarounds (IMO). > Great. > > Imagine if tar or cp worked this way... Fortunately, tar and cp don't grok extended attributes yet, so we're trying to make sure we use generic names that have meaning on other filesystem types too before this becomes a problem for those tools. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Feb 25 14:39:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Feb 2003 14:40:15 -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 h1PMdg3v006030 for ; Tue, 25 Feb 2003 14:39:42 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1PMdg2S006029 for linux-xfs@oss.sgi.com; Tue, 25 Feb 2003 14:39:42 -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 h1PMde3v006017; Tue, 25 Feb 2003 14:39:41 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 15E611911266; Tue, 25 Feb 2003 14:39:41 -0800 (PST) Date: Tue, 25 Feb 2003 14:39:41 -0800 From: Chris Wedgwood To: Steve Lord Cc: bugzilla-daemon@oss.sgi.com, xfs-master@oss.sgi.com Subject: Re: [Bug 218] Probable mmap() bug that breaks cpp-3.2 Message-ID: <20030225223941.GB22579@f00f.org> References: <200302251918.h1PJI2LZ024311@oss.sgi.com> <20030225213859.GB22042@f00f.org> <1046209514.31698.2000.camel@jen.americas.sgi.com> <20030225215141.GA22195@f00f.org> <1046210402.31695.2021.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1046210402.31695.2021.camel@jen.americas.sgi.com> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2932 X-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: 478 Lines: 16 On Tue, Feb 25, 2003 at 04:00:03PM -0600, Steve Lord wrote: > Nope, old kernel created bad files, confused cpp in gcc 3.2, new > kernel does not generate these files. mapcheck fixes up old files might xfs_check / xfs_repair not also be a candidate for trying to find such files? ie. check a few at random (maybe using ctime/mtime hints) or a command-line option to 'look harder' or would such code be unacceptable as it would be pointless for the IRIX codebase? --cw From owner-linux-xfs@oss.sgi.com Tue Feb 25 14:42:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Feb 2003 14:42: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 h1PMg23v006369 for ; Tue, 25 Feb 2003 14:42:02 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 47E981911266; Tue, 25 Feb 2003 14:42:02 -0800 (PST) Date: Tue, 25 Feb 2003 14:42:02 -0800 From: Chris Wedgwood To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - attr-2.3.0, add trusted namespace into XFS Message-ID: <20030225224202.GC22579@f00f.org> References: <200302250911.h1P9BdOb874080@snort.melbourne.sgi.com> <20030225093429.GB27906@plato.local.lan> <1046169145.1367.1.camel@localhost.localdomain> <20030225213710.GA22042@f00f.org> <1046209159.31695.1991.camel@jen.americas.sgi.com> <20030225215243.GB22195@f00f.org> <20030225220628.GE710@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030225220628.GE710@frodo> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2933 X-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: 705 Lines: 24 On Wed, Feb 26, 2003 at 09:06:28AM +1100, Nathan Scott wrote: > The only thing that could go "wrong" is in xfsdump/restore at the > moment, and there are acceptable workarounds (IMO). xfsdump/restore are pretty important IMO these are not applications i'd like to see trivially broken... is it not possible to have userspace deal with both cases? it on'y needs to determine which namespace prefix is in use once and cache this result (somewhat like what glibc does in places) > Fortunately, tar and cp don't grok extended attributes yet sorry, bad example on my part i was complaining that important userspace tools all-of-a-sudden work differently depending on what kernel you boot... --cw From owner-linux-xfs@oss.sgi.com Tue Feb 25 15:23:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Feb 2003 15:24:06 -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 h1PNNW3v007343 for ; Tue, 25 Feb 2003 15:23:32 -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 h1PNNPG8030281 for ; Tue, 25 Feb 2003 15:23:26 -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 KAA21820; Wed, 26 Feb 2003 10:22:09 +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 KAA11213; Wed, 26 Feb 2003 10:22:09 +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 h1PNJvwL001225; Wed, 26 Feb 2003 10:19:57 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h1PNJv4w001223; Wed, 26 Feb 2003 10:19:57 +1100 Date: Wed, 26 Feb 2003 10:19:57 +1100 From: Nathan Scott To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - attr-2.3.0, add trusted namespace into XFS Message-ID: <20030225231957.GF710@frodo> References: <200302250911.h1P9BdOb874080@snort.melbourne.sgi.com> <20030225093429.GB27906@plato.local.lan> <1046169145.1367.1.camel@localhost.localdomain> <20030225213710.GA22042@f00f.org> <1046209159.31695.1991.camel@jen.americas.sgi.com> <20030225215243.GB22195@f00f.org> <20030225220628.GE710@frodo> <20030225224202.GC22579@f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030225224202.GC22579@f00f.org> User-Agent: Mutt/1.5.3i X-archive-position: 2934 X-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: 1176 Lines: 36 On Tue, Feb 25, 2003 at 02:42:02PM -0800, Chris Wedgwood wrote: > On Wed, Feb 26, 2003 at 09:06:28AM +1100, Nathan Scott wrote: > > > The only thing that could go "wrong" is in xfsdump/restore at the > > moment, and there are acceptable workarounds (IMO). > > xfsdump/restore are pretty important IMO > > these are not applications i'd like to see trivially broken... Absolutely. They aren't "trivially broken", they just need to be told if you want to do things the old way (any attempt by restore to set an attribute on a non-existant namespace will fail & produce error messages of course). > is it not possible to have userspace deal with both cases? Userspace does handle both cases, it just can't do both at once, and it can't intuit which to use either (as you suggest below). > it on'y > needs to determine which namespace prefix is in use once and cache [there may also be no namespace prefix in use (yet) ... if no ROOT names are set at that point in time] > this result (somewhat like what glibc does in places) Yes, that would be good - I can't see a good reliable way to tell which namespaces a particular kernel supports though. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Feb 25 20:43:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Feb 2003 20:43:43 -0800 (PST) Received: from mail.dkp.com (mail.dkp.com [204.191.16.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1Q4hc3v010026 for ; Tue, 25 Feb 2003 20:43:39 -0800 Received: by mail.dkp.com (Postfix, from userid 20001) id 61CB92AD59; Tue, 25 Feb 2003 23:43:35 -0500 (EST) Received: from outsider.dkp.com (wallace.dkp.com [10.0.0.81]) by mail.dkp.com (Postfix) with SMTP id 864822AD52; Tue, 25 Feb 2003 23:43:31 -0500 (EST) Received: by outsider.dkp.com (sSMTP sendmail emulation); Tue, 25 Feb 2003 23:43:31 -0500 Date: Tue, 25 Feb 2003 23:43:30 -0500 From: Andrew Klaassen To: linux-list@ssc.com, ext3-users@redhat.com, linux-xfs@oss.sgi.com Subject: XFS vs. ext3 Message-ID: <20030226044329.GP2107@dkp.com> Mail-Followup-To: linux-list@ssc.com, ext3-users@redhat.com, linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: $Id: Sanitizer.pm,v 1.54 2002/02/15 16:59:07 bre Exp $ X-archive-position: 2935 X-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@dkp.com Precedence: bulk X-list: linux-xfs Content-Length: 2883 Lines: 64 (Sorry for cross-posting; I'm not on either ext3-users or linux-xfs, but I thought both lists might find this interesting. CC me with any replies or questions. Thanks.) (The last four paragraphs contain the interesting bits. Basically, XFS hath kick-ed the *ss of ext3 under conditions that are, for our company, critical.) Some listees might be interested in some testing I did the other day, XFS vs. ext3. In our last IMAX film project, right at crunch time, we were getting a whole bunch of dropped frames during compositing. Our compositing program would report "invalid file" partway through writing, and move on to the next frame. A year earlier we had done a very similar project, and stressed the system in very similar ways, but not seen the same problem at all. Difference? Last year we were using XFS, this year we were using ext3. Otherwise, as far as I could tell, the setups were identical. As far as I could tell; film projects differ in subtle ways, and that can have a big impact on how hard the filesystems are stressed. This Sunday I decided to test my hunch. We had to know for sure; if frames were also dropped with XFS under test, or if the test didn't show any dropped frames with either filesystem - in other words, if the problem was a Murphy's Law problem, refusing to show itself until the worst possible moment - we figured we'd be forced to spend a couple of hundred thousand dollars on servers and fabric for our next big IMAX project. The time needed to check for dropped frames and re-render frame-by-frame when a deadline is rushing up - to babysit - is simply too expensive. The test setup: 4 Shake compositing stations running on Win2k, communicating, via Samba, with a 1/2TB Linux server with an IDE software RAID5 setup, over GigE. Shake's job was simply to pump through 48MB Cineon frames from local drives to the server as fast as possible. I ran tests continuously for about 12 hours; I had to be able to guarantee my results. The results were clear and dramatic. Anywhere from 2 to 44 dropped frames out of 200 with ext3. (The worst ext3 numbers came while overwriting already existing files.) Zero dropped frames with XFS. Nadda. None. After the first few clear XFS tests I put extra load on the machine while the tests were running to see if that would make XFS hiccough - copying large files around internally, spawning CPU-eating programs. It didn't. Well... not until I threw a fork bomb at it, anyway. But even then, it kept on chuggin' till the load average was somewhere over 900. Conclusion, clear as a bell: XFS for high-bandwidth data transfer over Samba... when running IDE software RAID5, anyway. Oh yeah - another interesting note: There were also dropped frames under ext*2*, which I tried just as a comparison case. XFS truly does, in the patois of the time, r0x0r... Andrew Klaassen From owner-linux-xfs@oss.sgi.com Tue Feb 25 22:04:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Feb 2003 22:04:40 -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 h1Q64b3v011000 for ; Tue, 25 Feb 2003 22:04:38 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 1E3A71911266; Tue, 25 Feb 2003 22:04:38 -0800 (PST) Date: Tue, 25 Feb 2003 22:04:38 -0800 From: Chris Wedgwood To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - attr-2.3.0, add trusted namespace into XFS Message-ID: <20030226060438.GA24535@f00f.org> References: <200302250911.h1P9BdOb874080@snort.melbourne.sgi.com> <20030225093429.GB27906@plato.local.lan> <1046169145.1367.1.camel@localhost.localdomain> <20030225213710.GA22042@f00f.org> <1046209159.31695.1991.camel@jen.americas.sgi.com> <20030225215243.GB22195@f00f.org> <20030225220628.GE710@frodo> <20030225224202.GC22579@f00f.org> <20030225231957.GF710@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030225231957.GF710@frodo> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2936 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 330 Lines: 14 On Wed, Feb 26, 2003 at 10:19:57AM +1100, Nathan Scott wrote: > (any attempt by restore to set an attribute on a non-existant > namespace will fail & produce error messages of course) [...] > Yes, that would be good - I can't see a good reliable way to tell > which namespaces a particular kernel supports though. ? --cw From owner-linux-xfs@oss.sgi.com Tue Feb 25 22:04:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Feb 2003 22:05:00 -0800 (PST) Received: from barryg.mi.celestial.com (dagney.celestial.com [192.136.111.7]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1Q64u3v011094 for ; Tue, 25 Feb 2003 22:04:57 -0800 Received: by barryg.mi.celestial.com (Postfix, from userid 203) id 8B692639A6; Tue, 25 Feb 2003 22:04:55 -0800 (PST) Date: Tue, 25 Feb 2003 22:04:55 -0800 From: Bill Campbell To: linux-list@ssc.com Cc: ext3-users@redhat.com, linux-xfs@oss.sgi.com Subject: Re: [SLL] XFS vs. ext3 Message-ID: <20030225220455.A30650@barryg.mi.celestial.com> Reply-To: bill@celestial.com Mail-Followup-To: linux-list@ssc.com, ext3-users@redhat.com, linux-xfs@oss.sgi.com References: <20030226044329.GP2107@dkp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030226044329.GP2107@dkp.com>; from ak@dkp.com on Tue, Feb 25, 2003 at 11:43:30PM -0500 X-archive-position: 2937 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bill@celestial.com Precedence: bulk X-list: linux-xfs Content-Length: 771 Lines: 20 Veddy Inneresting. Got time to perform a similar test on reiserfs? On Tue, Feb 25, 2003 at 11:43:30PM -0500, Andrew Klaassen wrote: >(Sorry for cross-posting; I'm not on either ext3-users or >linux-xfs, but I thought both lists might find this interesting. >CC me with any replies or questions. Thanks.) .... Bill -- INTERNET: bill@Celestial.COM Bill Campbell; Celestial Software LLC UUCP: camco!bill PO Box 820; 6641 E. Mercer Way FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676 URL: http://www.celestial.com/ Cutting the space budget really restores my faith in humanity. It eliminates dreams, goals, and ideals and lets us get straight to the business of hate, debauchery, and self-annihilation. -- Johnny Hart From owner-linux-xfs@oss.sgi.com Tue Feb 25 22:10:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Feb 2003 22:10:54 -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 h1Q6Ao3v011988 for ; Tue, 25 Feb 2003 22:10:52 -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 h1Q6AiKp001295 for ; Tue, 25 Feb 2003 22:10:44 -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 RAA25393; Wed, 26 Feb 2003 17:09:28 +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 RAA75364; Wed, 26 Feb 2003 17:09:28 +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 h1Q67FwL002494; Wed, 26 Feb 2003 17:07:15 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h1Q67Eed002492; Wed, 26 Feb 2003 17:07:14 +1100 Date: Wed, 26 Feb 2003 17:07:14 +1100 From: Nathan Scott To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - attr-2.3.0, add trusted namespace into XFS Message-ID: <20030226060714.GN710@frodo> References: <200302250911.h1P9BdOb874080@snort.melbourne.sgi.com> <20030225093429.GB27906@plato.local.lan> <1046169145.1367.1.camel@localhost.localdomain> <20030225213710.GA22042@f00f.org> <1046209159.31695.1991.camel@jen.americas.sgi.com> <20030225215243.GB22195@f00f.org> <20030225220628.GE710@frodo> <20030225224202.GC22579@f00f.org> <20030225231957.GF710@frodo> <20030226060438.GA24535@f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030226060438.GA24535@f00f.org> User-Agent: Mutt/1.5.3i X-archive-position: 2938 X-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: 450 Lines: 19 On Tue, Feb 25, 2003 at 10:04:38PM -0800, Chris Wedgwood wrote: > On Wed, Feb 26, 2003 at 10:19:57AM +1100, Nathan Scott wrote: > > > (any attempt by restore to set an attribute on a non-existant > > namespace will fail & produce error messages of course) > > [...] > > > Yes, that would be good - I can't see a good reliable way to tell > > which namespaces a particular kernel supports though. > > ? > ENOSPC, EDQUOT, EROFS, ... -- Nathan From owner-linux-xfs@oss.sgi.com Tue Feb 25 22:32:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Feb 2003 22:32:17 -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 h1Q6WE3v012558 for ; Tue, 25 Feb 2003 22:32:15 -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 h1Q6gBkq015370 for ; Wed, 26 Feb 2003 00:42:12 -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 h1Q6UpBi1097093 for ; Wed, 26 Feb 2003 17:30:51 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h1Q6UoLr1095758 for linux-xfs@oss.sgi.com; Wed, 26 Feb 2003 17:30:50 +1100 (EST) Date: Wed, 26 Feb 2003 17:30:50 +1100 (EST) From: Nathan Scott Message-Id: <200302260630.h1Q6UoLr1095758@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - acl/attr updates X-archive-position: 2939 X-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: 1724 Lines: 62 Another extended attributes userspace patch from AndreasG - several small incremental fixes from last set, and addition of symbol versioning. Date: Tue Feb 25 22:27:13 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:140344a cmd/attr/libattr/attr_copy_check.c - 1.1 cmd/attr/exports - 1.1 cmd/attr/Makefile - 1.12 cmd/attr/VERSION - 1.29 cmd/attr/doc/CHANGES - 1.37 cmd/attr/libattr/Makefile - 1.11 cmd/attr/debian/changelog - 1.31 cmd/attr/include/libattr.h - 1.2 cmd/attr/libattr/libattr.h - 1.2 cmd/attr/include/error_context.h - 1.2 cmd/attr/libattr/attr_copy_fd.c - 1.2 cmd/attr/libattr/attr_copy_file.c - 1.2 An ACL userspace update from Andreas - adds in permissions copying routines and symbol versioning for libacl. Date: Tue Feb 25 22:29:15 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:140345a cmd/acl/libacl/perm_copy.h - 1.1 cmd/acl/examples/copyperm.c - 1.1 cmd/acl/exports - 1.1 cmd/acl/libacl/__apply_mask_to_mode.c - 1.1 cmd/acl/libacl/perm_copy_fd.c - 1.1 cmd/acl/libacl/perm_copy_file.c - 1.1 cmd/acl/configure.in - 1.24 cmd/acl/Makefile - 1.15 cmd/acl/VERSION - 1.45 cmd/acl/doc/CHANGES - 1.52 cmd/acl/include/Makefile - 1.11 cmd/acl/include/libacl.h - 1.10 cmd/acl/debian/control - 1.12 cmd/acl/debian/changelog - 1.39 cmd/acl/libacl/Makefile - 1.21 cmd/acl/po/de.po - 1.5 cmd/acl/po/acl.pot - 1.6 cmd/acl/libacl/libacl.h - 1.8 cmd/acl/include/config.h.in - 1.6 cmd/acl/po/Makefile - 1.7 cmd/acl/examples/Makefile.examples - 1.2 From owner-linux-xfs@oss.sgi.com Wed Feb 26 01:19:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Feb 2003 01:19:37 -0800 (PST) Received: from sweeney.demon.co.uk (213-152-33-154.dsl.eclipse.net.uk [213.152.33.154]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1Q9JN3v015665 for ; Wed, 26 Feb 2003 01:19:35 -0800 Received: from arequipa.sweeney.demon.co.uk (arequipa.sweeney.demon.co.uk [10.0.0.180]) by sweeney.demon.co.uk (Postfix) with SMTP id CFA111709F for ; Wed, 26 Feb 2003 09:19:06 +0000 (GMT) Date: Wed, 26 Feb 2003 09:20:34 +0000 From: Keith Matthews To: linux-xfs@oss.sgi.com Subject: Re: [SLL] XFS vs. ext3 Message-Id: <20030226092034.1cfc13d6.keith_m@sweeney.demon.co.uk> In-Reply-To: <20030225220455.A30650@barryg.mi.celestial.com> References: <20030226044329.GP2107@dkp.com> <20030225220455.A30650@barryg.mi.celestial.com> Organization: Frequentous Consultants Ltd X-Mailer: Sylpheed version 0.8.6 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2940 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: keith_m@sweeney.demon.co.uk Precedence: bulk X-list: linux-xfs Content-Length: 964 Lines: 29 On Tue, 25 Feb 2003 22:04:55 -0800 Bill Campbell wrote: > Veddy Inneresting. Got time to perform a similar test on reiserfs? > If you are going to that extent go the whole hog - try JFS as well. > On Tue, Feb 25, 2003 at 11:43:30PM -0500, Andrew Klaassen wrote: > >(Sorry for cross-posting; I'm not on either ext3-users or > >linux-xfs, but I thought both lists might find this interesting. > >CC me with any replies or questions. Thanks.) > .... > > Bill > -- > INTERNET: bill@Celestial.COM Bill Campbell; Celestial Software LLC > UUCP: camco!bill PO Box 820; 6641 E. Mercer Way > FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676 > URL: http://www.celestial.com/ > > Cutting the space budget really restores my faith in humanity. It > eliminates dreams, goals, and ideals and lets us get straight to the > business of hate, debauchery, and self-annihilation. > -- Johnny Hart > > From owner-linux-xfs@oss.sgi.com Wed Feb 26 07:05:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Feb 2003 07:05:35 -0800 (PST) Received: from thunker.thunk.org (thunk.org [140.239.227.29]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1QF5G3v006617 for ; Wed, 26 Feb 2003 07:05:17 -0800 Received: from [216.175.175.162] (helo=think.thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:DES-CBC3-SHA:168) (Exim 3.35 #1 (Debian)) id 18o36w-0003Bw-00; Wed, 26 Feb 2003 10:04:42 -0500 Received: from tytso by think.thunk.org with local (Exim 3.35 #1 (Debian)) id 18o36w-0006Gw-00; Wed, 26 Feb 2003 10:04:42 -0500 Date: Wed, 26 Feb 2003 10:04:42 -0500 From: "Theodore Ts'o" To: linux-list@ssc.com, ext3-users@redhat.com, linux-xfs@oss.sgi.com Subject: Re: XFS vs. ext3 Message-ID: <20030226150442.GC23962@think.thunk.org> References: <20030226044329.GP2107@dkp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030226044329.GP2107@dkp.com> User-Agent: Mutt/1.4i X-archive-position: 2941 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tytso@mit.edu Precedence: bulk X-list: linux-xfs Content-Length: 153 Lines: 5 Out of curiosity, what was the configuration of the Samba server? How much memory, CPU, disks, etc.? Specifically, was it an SMP machine? - Ted From owner-linux-xfs@oss.sgi.com Wed Feb 26 07:51:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Feb 2003 07:51:31 -0800 (PST) Received: from ubergeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1QFpJ3v007470 for ; Wed, 26 Feb 2003 07:51:20 -0800 Received: (qmail 5002 invoked by uid 500); 26 Feb 2003 15:48:46 -0000 Subject: Re: XFS vs. ext3 From: Austin Gonyou To: "Theodore Ts'o" Cc: linux-list@ssc.com, ext3-users@redhat.com, XFS List In-Reply-To: <20030226150442.GC23962@think.thunk.org> References: <20030226150442.GC23962@think.thunk.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1046274524.4822.21.camel@UberGeek> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 26 Feb 2003 09:48:46 -0600 X-archive-position: 2942 X-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: 580 Lines: 15 On Wed, 2003-02-26 at 09:04, Theodore Ts'o wrote: > Out of curiosity, what was the configuration of the Samba server? How > much memory, CPU, disks, etc.? Specifically, was it an SMP machine? > > - Ted Personally, I couldn't imagine a UP box, unless really fast with HT, handling a load like that, unless the RAID5 set is done in hardware, but even then, a fast bus would still be necessary, as well as a fast set of IO paths. To best support that, I'd guess at least DP. -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Wed Feb 26 08:16:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Feb 2003 08:16:32 -0800 (PST) Received: from mail.dkp.com (mail.dkp.com [204.191.16.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1QGGM3v008245 for ; Wed, 26 Feb 2003 08:16:23 -0800 Received: by mail.dkp.com (Postfix, from userid 20001) id D8FBC2AD66; Wed, 26 Feb 2003 11:16:21 -0500 (EST) Received: from wallace.dkp.com (wallace.dkp.com [10.0.0.81]) by mail.dkp.com (Postfix) with ESMTP id 56F232AD65; Wed, 26 Feb 2003 11:16:21 -0500 (EST) Received: by wallace.dkp.com (Postfix, from userid 168) id 2A6356F015; Wed, 26 Feb 2003 11:16:18 -0500 (EST) Date: Wed, 26 Feb 2003 11:16:18 -0500 From: Andrew Klaassen To: "Theodore Ts'o" Cc: linux-list@ssc.com, ext3-users@redhat.com, linux-xfs@oss.sgi.com Subject: Re: XFS vs. ext3 Message-ID: <20030226161618.GB11951@dkp.com> Mail-Followup-To: Theodore Ts'o , linux-list@ssc.com, ext3-users@redhat.com, linux-xfs@oss.sgi.com References: <20030226044329.GP2107@dkp.com> <20030226150442.GC23962@think.thunk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030226150442.GC23962@think.thunk.org> User-Agent: Mutt/1.4i X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: $Id: Sanitizer.pm,v 1.54 2002/02/15 16:59:07 bre Exp $ X-archive-position: 2943 X-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@dkp.com Precedence: bulk X-list: linux-xfs Content-Length: 920 Lines: 33 On Wed, Feb 26, 2003 at 10:04:42AM -0500, Theodore Ts'o wrote: > Out of curiosity, what was the configuration of the Samba > server? How much memory, CPU, disks, etc.? Specifically, was > it an SMP machine? Nope, it's not SMP. Specs: Single processor Pentium III 800MHz 768MB RAM ASUS CUBX rev 1.02 MB 6 Maxtor 120GB 5400rpm HDs 1 Onboard ATA66 CMD648 controller 2 Promise PCI ATA100 100TX/2 controllers (20268 chipset) Intel 1000BaseT server NIC Partitioned like so: md2 (data array I was writing to) : active raid5 hde4[0] hdg4[1] hdi4[2] hdk4[3] hdm4[4] hdo4[5] 592433920 blocks level 5, 64k chunk, algorithm 0 [6/6] [UUUUUU] md0 (root array) : active raid5 hde3[0] hdg3[1] hdi3[2] hdk3[3] hdm3[4] hdo3[5] 5243520 blocks level 5, 64k chunk, algorithm 0 [6/6] [UUUUUU] md1 (boot array) : active raid1 hde1[0] hdg1[1] 131392 blocks [2/2] [UU] Andrew Klaassen From owner-linux-xfs@oss.sgi.com Wed Feb 26 09:50:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Feb 2003 09:50: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 h1QHoN3v009782 for ; Wed, 26 Feb 2003 09:50:23 -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 h1QHoHKp025183 for ; Wed, 26 Feb 2003 09:50:17 -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 LAA62882 for ; Wed, 26 Feb 2003 11:50:16 -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 LAA20546 for ; Wed, 26 Feb 2003 11:50:16 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h1QHoG404653; Wed, 26 Feb 2003 11:50:16 -0600 Message-Id: <200302261750.h1QHoG404653@jen.americas.sgi.com> Date: Wed, 26 Feb 2003 11:50:16 -0600 Subject: TAKE - fix a bad merge from irix To: linux-xfs@oss.sgi.com X-archive-position: 2944 X-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: 434 Lines: 17 This went in yesterday, should have looked harder at what the merge tool did to the code, it replaced the wrong line in here. Date: Wed Feb 26 09:49:07 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:140375a linux/fs/xfs/xfs_log_recover.c - 1.256 - put back error=0 and remove the xfs_inobp_check() From owner-linux-xfs@oss.sgi.com Wed Feb 26 10:25:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Feb 2003 10:25:35 -0800 (PST) Received: from mail.dkp.com (mail.dkp.com [204.191.16.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1QIPM3v010605 for ; Wed, 26 Feb 2003 10:25:23 -0800 Received: by mail.dkp.com (Postfix, from userid 20001) id BF8B12ADDE; Wed, 26 Feb 2003 13:25:21 -0500 (EST) Received: from wallace.dkp.com (wallace.dkp.com [10.0.0.81]) by mail.dkp.com (Postfix) with ESMTP id 29A212AD66; Wed, 26 Feb 2003 13:25:21 -0500 (EST) Received: by wallace.dkp.com (Postfix, from userid 168) id 398FC6F015; Wed, 26 Feb 2003 13:25:20 -0500 (EST) Date: Wed, 26 Feb 2003 13:25:19 -0500 From: Andrew Klaassen To: Austin Gonyou Cc: "Theodore Ts'o" , linux-list@ssc.com, ext3-users@redhat.com, XFS List Subject: Re: XFS vs. ext3 Message-ID: <20030226182519.GB28064@dkp.com> Mail-Followup-To: Austin Gonyou , Theodore Ts'o , linux-list@ssc.com, ext3-users@redhat.com, XFS List References: <20030226150442.GC23962@think.thunk.org> <1046274524.4822.21.camel@UberGeek> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1046274524.4822.21.camel@UberGeek> User-Agent: Mutt/1.4i X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: $Id: Sanitizer.pm,v 1.54 2002/02/15 16:59:07 bre Exp $ X-archive-position: 2945 X-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@dkp.com Precedence: bulk X-list: linux-xfs Content-Length: 1628 Lines: 47 On Wed, Feb 26, 2003 at 09:48:46AM -0600, Austin Gonyou wrote: > On Wed, 2003-02-26 at 09:04, Theodore Ts'o wrote: > > Out of curiosity, what was the configuration of the Samba > > server? How much memory, CPU, disks, etc.? Specifically, > > was it an SMP machine? > > > > - Ted > > Personally, I couldn't imagine a UP box, unless really fast > with HT, handling a load like that, unless the RAID5 set is > done in hardware, but even then, a fast bus would still be > necessary, as well as a fast set of IO paths. To best support > that, I'd guess at least DP. Well, it did handle it - software RAID, 33MHz/32bit PCI bus and all... with XFS, anyway. It wasn't *fast*, but it handled it. Load averages would regularly climb to 12 using ext3, especially when overwriting old files; with XFS they stayed around 5 or 6. The dropped frame rate with ext3 was much higher with 2.4.9 than 2.4.18 kernels (consistently over 20 frames vs consistently under 10 frames), but there were still dropped frames with 2.4.18 (any dropped frames is unacceptable). I'd be willing to try a different kernel or two with ext3 if I get the chance... any suggestions/requests? (Of potential interest: The worst performance, 44 dropped frames, came with ext2, kernel 2.4.9, overwriting old files.) Back-of-the-envelope benchmarks: 2.4.9 - 50s/frame average (both ext2 and ext3) 2.4.18 - 20s/frame (ext3 and xfs) 48MB frames * 4 clients = 192MB 192MB/50s = 3.8MB/s 192MB/20s = 9.6MB/s Like I said... not fast, but on a limited budget fast isn't always the most important thing... Andrew Klaassen From owner-linux-xfs@oss.sgi.com Wed Feb 26 16:38:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Feb 2003 16:38:19 -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 h1R0c83v021326 for ; Wed, 26 Feb 2003 16:38:09 -0800 Received: from apps.cwi.nl (apps.cwi.nl [192.16.191.34]) by hera.cwi.nl with ESMTP id BAA11412 for ; Thu, 27 Feb 2003 01:37:59 +0100 (MET) From: Andries.Brouwer@cwi.nl Received: by apps.cwi.nl id h1R0bxr09281; Thu, 27 Feb 2003 01:37:59 +0100 (MET) Date: Thu, 27 Feb 2003 01:37:59 +0100 (MET) Message-Id: To: a.gruenbacher@computer.org, ag@bestbits.at, ak@suse.de, kaos@ocs.com.au, linux-xfs@oss.sgi.com, lord@sgi.com Subject: xattr manpages X-archive-position: 2946 X-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 Content-Length: 777 Lines: 20 Several new manpages have been contributed, so I was considering a new man-pages release for this weekend. Remains the question: what is the *xattr copyright situation today? Stephen Lord wrote: > 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. Andreas Gruenbacher wrote: > 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? Can anybody send me, or can I ftp somewhere, man pages with a copyright that allows redistribution? Andries From owner-linux-xfs@oss.sgi.com Wed Feb 26 16:44:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Feb 2003 16:44:46 -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 h1R0ig3v021826 for ; Wed, 26 Feb 2003 16:44:44 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18oC9w-0004d7-00; Thu, 27 Feb 2003 00:44:24 +0000 Date: Thu, 27 Feb 2003 00:44:24 +0000 From: Christoph Hellwig To: Andries.Brouwer@cwi.nl Cc: a.gruenbacher@computer.org, ag@bestbits.at, ak@suse.de, kaos@ocs.com.au, linux-xfs@oss.sgi.com, lord@sgi.com Subject: Re: xattr manpages Message-ID: <20030227004424.A17798@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 Andries.Brouwer@cwi.nl on Thu, Feb 27, 2003 at 01:37:59AM +0100 X-archive-position: 2947 X-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: 368 Lines: 9 On Thu, Feb 27, 2003 at 01:37:59AM +0100, Andries.Brouwer@cwi.nl wrote: > Several new manpages have been contributed, so I was > considering a new man-pages release for this weekend. > Remains the question: what is the *xattr copyright situation today? See http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/attr/man/man2/. The manpages now have a GPL header. From owner-linux-xfs@oss.sgi.com Wed Feb 26 16:48:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Feb 2003 16:48: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 h1R0mh3v022285 for ; Wed, 26 Feb 2003 16:48:44 -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 h1R0wekq013923 for ; Wed, 26 Feb 2003 18:58:41 -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 LAA04492; Thu, 27 Feb 2003 11:47: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 LAA87927; Thu, 27 Feb 2003 11:47:14 +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 h1R0iwUK001249; Thu, 27 Feb 2003 11:44:58 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h1R0iukJ001247; Thu, 27 Feb 2003 11:44:56 +1100 Date: Thu, 27 Feb 2003 11:44:56 +1100 From: Nathan Scott To: Andries.Brouwer@cwi.nl Cc: a.gruenbacher@computer.org, ag@bestbits.at, ak@suse.de, kaos@ocs.com.au, linux-xfs@oss.sgi.com, lord@sgi.com Subject: Re: xattr manpages Message-ID: <20030227004456.GA1235@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: 2948 X-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: 686 Lines: 25 hi Andries, On Thu, Feb 27, 2003 at 01:37:59AM +0100, Andries.Brouwer@cwi.nl wrote: > Several new manpages have been contributed, so I was > considering a new man-pages release for this weekend. > Remains the question: what is the *xattr copyright situation today? > ... > Can anybody send me, or can I ftp somewhere, man pages with > a copyright that allows redistribution? > The current attr package has what you want, from doc/CHANGES.. attr-2.3.0 (21 February 2003) - ... - Update licensing notice in system call man pages for aeb. I will mail you copies privately, but this is also available in the XFS CVS tree, or Andreas' website (acl.bestbits.at). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Feb 26 16:59:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Feb 2003 16:59:11 -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 h1R0x33v022807 for ; Wed, 26 Feb 2003 16:59:04 -0800 Received: from apps.cwi.nl (apps.cwi.nl [192.16.191.34]) by hera.cwi.nl with ESMTP id BAA13192 for ; Thu, 27 Feb 2003 01:58:55 +0100 (MET) From: Andries.Brouwer@cwi.nl Received: by apps.cwi.nl id h1R0wtA23040; Thu, 27 Feb 2003 01:58:55 +0100 (MET) Date: Thu, 27 Feb 2003 01:58:55 +0100 (MET) Message-Id: To: Andries.Brouwer@cwi.nl, hch@infradead.org, nathans@sgi.com Subject: Re: xattr manpages Cc: a.gruenbacher@computer.org, ag@bestbits.at, ak@suse.de, kaos@ocs.com.au, linux-xfs@oss.sgi.com, lord@sgi.com X-archive-position: 2949 X-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 Content-Length: 190 Lines: 10 > See http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/attr/man/man2/. > The manpages now have a GPL header. Thanks! > Current man pages attached. And thanks! once more - Andries From owner-linux-xfs@oss.sgi.com Wed Feb 26 18:43:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Feb 2003 18:43:29 -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 h1R2hL3v025522 for ; Wed, 26 Feb 2003 18:43:21 -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 h1R2hEG8001665 for ; Wed, 26 Feb 2003 18:43:15 -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 h1R2fv7L037071; Thu, 27 Feb 2003 13:41:57 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h1R2ftEw037200; Thu, 27 Feb 2003 13:41:55 +1100 (EST) Date: Thu, 27 Feb 2003 13:41:55 +1100 (EST) From: Nathan Scott Message-Id: <200302270241.h1R2ftEw037200@snort.melbourne.sgi.com> To: agruen@suse.de Cc: linux-xfs@oss.sgi.com Subject: TAKE - acl X-archive-position: 2950 X-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: 495 Lines: 17 Make libacl routines more robust in the presence of callers who don't check for failed function return codes and then call back into libacl. Patch from AndreasG. Date: Wed Feb 26 18:41:22 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:140454a cmd/acl/libacl/acl_get_permset.c - 1.3 cmd/acl/libacl/acl_get_entry.c - 1.3 cmd/acl/libacl/acl_create_entry.c - 1.4 From owner-linux-xfs@oss.sgi.com Thu Feb 27 00:51:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Feb 2003 00:51:50 -0800 (PST) Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1R8pi3v002210 for ; Thu, 27 Feb 2003 00:51:46 -0800 Received: from inf.ethz.ch (IDENT:khEMbxFNPeO/i7lOFvZa8NshPnYstpeV@ikarus.inf.ethz.ch [129.132.10.58]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id JAA27450 for ; Thu, 27 Feb 2003 09:51:43 +0100 (MET) Message-ID: <3E5DD19E.6030600@inf.ethz.ch> Date: Thu, 27 Feb 2003 09:51:42 +0100 From: Marc Schmitt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: logbufs=8,logbsize=32768 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2951 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: schmitt@inf.ethz.ch Precedence: bulk X-list: linux-xfs Content-Length: 565 Lines: 22 Hi all, I'm using the latest stable release 1.2.0 with kernel 2.4.19 under RedHat 7.3. As stated in the XFS FAQ, tuning the logbufs/logbsize values have a big impact on the delete performance. After running some bonnie++s, it's obvious that the impact is huge. The mount options given in the subject are memory greedy, the FAQ says, on a 128MB RAM system, it is likely to fail. What does the memory consumption depend on? Is there a formula to roughly calculate the memory consumed with those mount options per mounted file system? TIA Regards, Marc From owner-linux-xfs@oss.sgi.com Thu Feb 27 01:26:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Feb 2003 01:26:32 -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 h1R9QP3v003915 for ; Thu, 27 Feb 2003 01:26:26 -0800 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id h1R9QM8T033123; Thu, 27 Feb 2003 10:26:23 +0100 (CET) Message-Id: <4.3.2.7.2.20030227101340.03421930@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Feb 2003 10:26:11 +0100 To: Marc Schmitt , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: logbufs=8,logbsize=32768 In-Reply-To: <3E5DD19E.6030600@inf.ethz.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2952 X-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: 22319 Lines: 541 At 09:51 27-2-2003 +0100, Marc Schmitt wrote: >Hi all, > >I'm using the latest stable release 1.2.0 with kernel 2.4.19 under RedHat 7.3. > >As stated in the XFS FAQ, tuning the logbufs/logbsize values have a big >impact on the delete performance. After running some bonnie++s, it's >obvious that the impact is huge. > >The mount options given in the subject are memory greedy, the FAQ says, on >a 128MB RAM system, it is likely to fail. This is actually not quite correct anymore and comes from the pre 1.1 days. The amount of memory XFS allocates has been significantly reduced over time. >What does the memory consumption depend on? Is there a formula to roughly >calculate the memory consumed with those mount options per mounted file system? Well, I observed mount failing with 128MB on my testbox at that time and put a warning in the FAQ that just raising the value might result in failure. Cheers -- Seth It might just be your lucky day, if you only knew. rom owner-linux-xfs@oss.sgi.com Thu Feb 27 09:26:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Feb 2003 09:26:14 -0800 (PST) Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1RHQ7eA001445 for ; Thu, 27 Feb 2003 09:26:08 -0800 Received: from inf.ethz.ch (IDENT:WAAtjkoCiRiGs2oken+/doYdOUxHVBn0@ikarus.inf.ethz.ch [129.132.10.58]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id QAA17978; Thu, 27 Feb 2003 16:49:12 +0100 (MET) Message-ID: <3E5E3377.2060109@inf.ethz.ch> Date: Thu, 27 Feb 2003 16:49:11 +0100 From: Marc Schmitt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Lord CC: linux-xfs@oss.sgi.com, knuffie@xs4all.nl Subject: Re: logbufs=8,logbsize=32768 References: <3E5DD19E.6030600@inf.ethz.ch> <1046350347.2227.1.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2953 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: schmitt@inf.ethz.ch Precedence: bulk X-list: linux-xfs Stephen Lord wrote: > On Thu, 2003-02-27 at 02:51, Marc Schmitt wrote: > > Its really simple: > > 8 * 32K or 256K per filesystem that you use these options on. > > Usually no problem unless memory is tight at the time of mount. These > options do not make sense unless that filesystem is under constant > heavy metadata load. Thanks for the answers, Seth and Steve. I'm not sure what you mean by heavy metadata load, sorry. What produces such load? Databases? Home directories of a whole bunch of users on the same partition? In an earlier post (Re: Best Logfile size for XFS; 02/11/2002), Steve wrote: > There is no hard and fast rule for this, a larger log is only really useful if you > are doing metadata intensive operations over extended periods of time and > we have found that more iclogs are just as useful (the logbugs=8 mount option). > I cannot remember right now, but mkfs may automatically make the > log bigger on large devices, of course large may be past the 2 Tbyte limit > on linux. > > For write performance a larger log will not help, more iclogs might, but > not by much. > > The other thing to consider with larger logs is that recovery after a crash > can take longer. Logbufs are in memory only, right? If yes, the more I have, the more information gets lost on a crash, the higher the chance of heavy filesystem corruption, correct? Seth, judging by the number and content of your posts on this list, you must have XFS in production for ages. :) What mount options do you recommend or did you come up with for your different needs (I assume you're using XFS for different services)? TIA Regards, Marc rom owner-linux-xfs@oss.sgi.com Thu Feb 27 09:34:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Feb 2003 09:34: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 h1RHY5eA001980 for ; Thu, 27 Feb 2003 09:34: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 h1RCrRKp009383 for ; Thu, 27 Feb 2003 04:53:27 -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 GAA26749; Thu, 27 Feb 2003 06:53:26 -0600 (CST) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-52.corp.sgi.com [134.15.64.52]) by tulip-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id GAA75306; Thu, 27 Feb 2003 06:53:25 -0600 (CST) Subject: Re: logbufs=8,logbsize=32768 From: Stephen Lord To: Marc Schmitt Cc: linux-xfs@oss.sgi.com In-Reply-To: <3E5DD19E.6030600@inf.ethz.ch> References: <3E5DD19E.6030600@inf.ethz.ch> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 27 Feb 2003 06:52:26 -0600 Message-Id: <1046350347.2227.1.camel@localhost.localdomain> Mime-Version: 1.0 X-archive-position: 2954 X-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 On Thu, 2003-02-27 at 02:51, Marc Schmitt wrote: > Hi all, > > I'm using the latest stable release 1.2.0 with kernel 2.4.19 under > RedHat 7.3. > > As stated in the XFS FAQ, tuning the logbufs/logbsize values have a big > impact on the delete performance. After running some bonnie++s, it's > obvious that the impact is huge. > > The mount options given in the subject are memory greedy, the FAQ says, > on a 128MB RAM system, it is likely to fail. > > What does the memory consumption depend on? Is there a formula to > roughly calculate the memory consumed with those mount options per > mounted file system? Its really simple: 8 * 32K or 256K per filesystem that you use these options on. Usually no problem unless memory is tight at the time of mount. These options do not make sense unless that filesystem is under constant heavy metadata load. Steve rom owner-linux-xfs@oss.sgi.com Thu Feb 27 09:45:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Feb 2003 09:45:08 -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 h1RHj2eA006431 for ; Thu, 27 Feb 2003 09:45:03 -0800 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id h1RGQbME092979; Thu, 27 Feb 2003 17:26:38 +0100 (CET) Message-Id: <4.3.2.7.2.20030227170429.03759028@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Feb 2003 17:26:28 +0100 To: Marc Schmitt , Stephen Lord From: Seth Mos Subject: Re: logbufs=8,logbsize=32768 Cc: linux-xfs@oss.sgi.com In-Reply-To: <3E5E3377.2060109@inf.ethz.ch> References: <3E5DD19E.6030600@inf.ethz.ch> <1046350347.2227.1.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2955 X-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 At 16:49 27-2-2003 +0100, Marc Schmitt wrote: >Stephen Lord wrote: >Thanks for the answers, Seth and Steve. I'm not sure what you mean by >heavy metadata load, sorry. What produces such load? Databases? Home >directories of a whole bunch of users on the same partition? Heavy metadata load is the amount of changes that are done to the filesystem. So updating one 1GB file is a low metadata operation but updating 1 million files of 1KB is a high metadata load. The size of the file does not matter since metadata implies that the data it self is not journalled. >Logbufs are in memory only, right? If yes, the more I have, the more >information gets lost on a crash, the higher the chance of heavy >filesystem corruption, correct? Not corruption, but the amount of changes pending to be committed to disk might get lost resulting in missing files or a damaged file. Remember the filesystem stays in tact, but you will also need to have the database software (if you run it) to have transaction support or other crash recovery mechanisms to cope with the loss. >Seth, judging by the number and content of your posts on this list, you >must have XFS in production for ages. :) >What mount options do you recommend or did you come up with for your >different needs (I assume you're using XFS for different services)? I have one "large" database server which is running Red Hat Linux 7.3 with the XFS 1.2 release kernels I made myself. So far the machine has been in production for over a year. The machine is a dual 1.13Ghz PIII with 2GB ram and a 200GB hardware raid 10. The database software we use is Progres version 9.1C (pending 9.1D). The largest filesystem we have is the /users filesystem which also houses the home directories which are NFS exported. This filesystem is roughly 180GB large. We mount this filesystem with logbufs=8 to make the database response faster. Remember that the database must support the ability to perform crash recovery as well. XFS does the filesystem integrity and Progres performs the database integrity. We created this filesystem with a larger log (mkfs.xfs -l size=32768b /dev/foo). Although the filesystem is located on a hardware raid I did not perform stripunit and stripwidth tuning yet which should help performance even more. Cheers -- Seth It might just be your lucky day, if you only knew. rom owner-linux-xfs@oss.sgi.com Thu Feb 27 10:08:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Feb 2003 10:08: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 h1RI8TeA007159 for ; Thu, 27 Feb 2003 10:08: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 h1RFsJKp008788 for ; Thu, 27 Feb 2003 07:54:19 -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 JAA42449; Thu, 27 Feb 2003 09:54: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 JAA34282; Thu, 27 Feb 2003 09:54:18 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h1RFsIc20035; Thu, 27 Feb 2003 09:54:18 -0600 Subject: Re: logbufs=8,logbsize=32768 From: Steve Lord To: Marc Schmitt Cc: linux-xfs@oss.sgi.com, Seth Mos In-Reply-To: <3E5E3377.2060109@inf.ethz.ch> References: <3E5DD19E.6030600@inf.ethz.ch> <1046350347.2227.1.camel@localhost.localdomain> <3E5E3377.2060109@inf.ethz.ch> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1046361258.17393.221.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 27 Feb 2003 09:54:18 -0600 X-archive-position: 2956 X-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 On Thu, 2003-02-27 at 09:49, Marc Schmitt wrote: > Stephen Lord wrote: > > On Thu, 2003-02-27 at 02:51, Marc Schmitt wrote: > > > > Its really simple: > > > > 8 * 32K or 256K per filesystem that you use these options on. > > > > Usually no problem unless memory is tight at the time of mount. These > > options do not make sense unless that filesystem is under constant > > heavy metadata load. > > Thanks for the answers, Seth and Steve. I'm not sure what you mean by > heavy metadata load, sorry. What produces such load? Databases? Home > directories of a whole bunch of users on the same partition? A news or mail server would be a good one. A database does not usually once it is setup. > > In an earlier post (Re: Best Logfile size for XFS; 02/11/2002), Steve wrote: > > There is no hard and fast rule for this, a larger log is only really useful if you > > are doing metadata intensive operations over extended periods of time and > > we have found that more iclogs are just as useful (the logbugs=8 mount option). > > I cannot remember right now, but mkfs may automatically make the > > log bigger on large devices, of course large may be past the 2 Tbyte limit > > on linux. > > > > For write performance a larger log will not help, more iclogs might, but > > not by much. > > > > The other thing to consider with larger logs is that recovery after a crash > > can take longer. > > Logbufs are in memory only, right? If yes, the more I have, the more > information gets lost on a crash, the higher the chance of heavy > filesystem corruption, correct? Not of corruption, but if the amount time can roll backwards after recovery. Even at this size though, we probably have less data in flight than ext3 or reiserfs, not sure about jfs. What it does also mean is mounts after a crash will take longer. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com rom owner-linux-xfs@oss.sgi.com Thu Feb 27 10:47:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Feb 2003 10:47: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 h1RIlReA008833 for ; Thu, 27 Feb 2003 10:47:27 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1RIlR96008832 for linux-xfs@oss.sgi.com; Thu, 27 Feb 2003 10:47: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 h1RIlPeA008816 for ; Thu, 27 Feb 2003 10:47:25 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1RIbKtb008589; Thu, 27 Feb 2003 10:37:20 -0800 Date: Thu, 27 Feb 2003 10:37:20 -0800 Message-Id: <200302271837.h1RIbKtb008589@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 225] thread deadlock on full fs. X-Bugzilla-Reason: AssignedTo X-archive-position: 2957 X-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 http://oss.sgi.com/bugzilla/show_bug.cgi?id=225 stephy32@videotron.ca changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|critical |blocker ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. rom owner-linux-xfs@oss.sgi.com Thu Feb 27 10:47:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Feb 2003 10:47: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 h1RIlqeA008914 for ; Thu, 27 Feb 2003 10:47: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 h1RIvtkq013189 for ; Thu, 27 Feb 2003 12:57:55 -0600 Received: from thistle-e236.americas.sgi.com (thistle-e236.americas.sgi.com [128.162.236.204]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA75557 for ; Thu, 27 Feb 2003 12:47:45 -0600 (CST) Received: from clink.americas.sgi.com (clink.americas.sgi.com [128.162.236.153]) by thistle-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id MAA79590 for ; Thu, 27 Feb 2003 12:47:45 -0600 (CST) Received: from clink.americas.sgi.com (localhost [127.0.0.1]) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/erikj-IRIX6519-news) with ESMTP id h1RIlo0t5223509 for ; Thu, 27 Feb 2003 12:47:50 -0600 (CST) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/Submit) id h1RIln1N4595744 for linux-xfs@oss.sgi.com; Thu, 27 Feb 2003 12:47:49 -0600 (CST) Date: Thu, 27 Feb 2003 12:47:49 -0600 (CST) From: Dean Roehrich Message-Id: <200302271847.h1RIln1N4595744@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - POSTCREATE never fires X-archive-position: 2958 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@clink.americas.sgi.com Precedence: bulk X-list: linux-xfs fix dmapi POSTCREATE event in xfs_create/xfs_mkdir Date: Thu Feb 27 10:46:30 PST 2003 Workarea: clink.americas.sgi.com:/data/clink/a67/roehrich/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:140501a linux/fs/xfs/xfs_vnodeops.c - 1.583 - Add dm_event_sent to xfs_create/xfs_mkdir. Make POSTCREATE work the way it does in Irix. rom owner-linux-xfs@oss.sgi.com Thu Feb 27 11:13:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Feb 2003 11:14:03 -0800 (PST) Received: from dea.linux-mips.net (p508B7BED.dip.t-dialin.net [80.139.123.237]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1RJDueA011640 for ; Thu, 27 Feb 2003 11:13:57 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id h1RJDro16217 for linux-xfs@oss.sgi.com; Thu, 27 Feb 2003 20:13:53 +0100 Date: Thu, 27 Feb 2003 20:13:53 +0100 From: Ralf Baechle To: linux-xfs@oss.sgi.com Subject: ADMIN: Test, please ignore ... Message-ID: <20030227201353.A16049@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-archive-position: 2959 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-xfs Sorry, the list is acting up ... rom owner-linux-xfs@oss.sgi.com Thu Feb 27 11:17:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Feb 2003 11:17: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 h1RJHReA011833 for ; Thu, 27 Feb 2003 11:17:27 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1RJHRVd011829 for linux-xfs@oss.sgi.com; Thu, 27 Feb 2003 11:17: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 h1RJHPeC011813 for ; Thu, 27 Feb 2003 11:17:25 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h1RIo5qu009391; Thu, 27 Feb 2003 10:50:05 -0800 Date: Thu, 27 Feb 2003 10:50:05 -0800 Message-Id: <200302271850.h1RIo5qu009391@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 220] POSTCREATE never fires X-Bugzilla-Reason: AssignedTo X-archive-position: 2960 X-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 http://oss.sgi.com/bugzilla/show_bug.cgi?id=220 roehrich@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From roehrich@sgi.com 2003-02-27 10:50 ------- Modid: 2.4.x-xfs:slinx:140501a linux/fs/xfs/xfs_vnodeops.c - 1.583 - Add dm_event_sent to xfs_create/xfs_mkdir. Make POSTCREATE work the way it does in Irix. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. rom owner-linux-xfs@oss.sgi.com Thu Feb 27 11:25:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Feb 2003 11:25:55 -0800 (PST) Received: from ubergeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1RJPleA012270 for ; Thu, 27 Feb 2003 11:25:48 -0800 Received: (qmail 15548 invoked by uid 500); 27 Feb 2003 19:23:16 -0000 Subject: Re: xattr manpages From: Austin Gonyou To: Andries.Brouwer@cwi.nl Cc: a.gruenbacher@computer.org, ag@bestbits.at, ak@suse.de, kaos@ocs.com.au, XFS List , lord@sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1046373795.14894.19.camel@UberGeek> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 27 Feb 2003 13:23:16 -0600 X-archive-position: 2961 X-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 On Wed, 2003-02-26 at 18:37, Andries.Brouwer@cwi.nl wrote: > Several new manpages have been contributed, so I was > considering a new man-pages release for this weekend. > Remains the question: what is the *xattr copyright situation today? > XFS still does not support "immutable" right? > Andries -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Thu Feb 27 12:37:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Feb 2003 12:37:05 -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 h1RKaxeA021242 for ; Thu, 27 Feb 2003 12:37:00 -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 h1RKasOP031187 for ; Thu, 27 Feb 2003 12:36:54 -0800 Received: from localhost (localhost [127.0.0.1]) by oz.cnes.com (8.9.3/8.9.3) with ESMTP id MAA26551 for ; Thu, 27 Feb 2003 12:36:53 -0800 (PST) Date: Thu, 27 Feb 2003 12:36:53 -0800 From: Scott Jepson To: linux-xfs@oss.sgi.com Subject: Compile Error....kmem_zalloc Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2963 X-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: 1407 Lines: 34 Hi, I get this error on a 2.4.20 kernel with SCSI enabled for using a qlogin controller. It compiled fine before adding the latest xfs-patch (linux-2.4.20-xfs-2003-02-23.patch.bz2). ld -m elf_i386 -T /usr/src/linux-2.4.20/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.20/arch/i386/lib/lib.a /usr/src/linux-2.4.20/lib/lib.a /usr/src/linux-2.4.20/arch/i386/lib/lib.a --end-group -o vmlinux drivers/scsi/scsidrv.o: In function `kmem_zalloc': drivers/scsi/scsidrv.o(.text+0x217c0): multiple definition of `kmem_zalloc' fs/fs.o(.text+0xb3d50): first defined here make[1]: *** [kallsyms] Error 1 make[1]: Leaving directory `/usr/src/linux-2.4.20' make: *** [vmlinux] Error 2 Any ideas, Thanks, -Scott ---------------------------------------------------------------- Scott Jepson, Managing Partner Email: scott@cnes.com Creative Network Services, LLC http://www.cnes.com (310)470-6140 ---------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Thu Feb 27 12:39:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Feb 2003 12:39:32 -0800 (PST) Received: from mail02.securities.com (mail02.securities.com [57.69.15.72]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1RKdQeA021364 for ; Thu, 27 Feb 2003 12:39:27 -0800 Received: from mail02.securities.com (localhost [127.0.0.1]) by mail02.securities.com (8.12.5/8.12.5-DELIVERY) with ESMTP id h1RKdP5H005298 for ; Thu, 27 Feb 2003 15:39:25 -0500 Received: from mail02.securities.com (localhost [127.0.0.1]) by mail02.securities.com (8.12.5/8.12.5-SMTP) with ESMTP id h1RKdOxO005291 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 27 Feb 2003 15:39:25 -0500 Received: from localhost (venevene@localhost) by mail02.securities.com (8.12.5/8.12.5/Submit) with ESMTP id h1RKdNCQ005287; Thu, 27 Feb 2003 15:39:23 -0500 X-Authentication-Warning: mail02.securities.com: venevene owned process doing -bs Date: Thu, 27 Feb 2003 15:39:22 -0500 (EST) From: "Benito A. Venegas" X-X-Sender: Reply-To: "Benito A. Venegas" To: Eric Sandeen cc: Mihai RUSU , 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: 2964 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bvenegas@securities.com Precedence: bulk X-list: linux-xfs Content-Length: 1673 Lines: 56 Eric/Team: First.- Congratulations for release 1.2 to U and your partners in xfs-dev It's working very well in our "test" server, before to put in production. (yes, I couldn;t test pre-releases before, because I was in Chile with my family taking a 'reset' and doing junk job :/ ) Based in your answer to this Thread, so the only way for now it's rebuilding the whole partition with mkfs to obtain v2?. I don't have external log. I used only extended log in the same partition to create my FS before ( mkfs -t xfs -l size=32768b ...) Thanks vene.- 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 > > 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. > > > > > > -- Benito A. Venegas System Engineer, Technology 225 Park Ave. South (6th floor ISI) New York, NY 10003 A Euromoney Institutional Investor company. From owner-linux-xfs@oss.sgi.com Thu Feb 27 14:36:40 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Feb 2003 14:36:46 -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 h1RMadeA008885 for ; Thu, 27 Feb 2003 14:36:40 -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 h1RMaYOP032391 for ; Thu, 27 Feb 2003 14:36:34 -0800 Received: from localhost (localhost [127.0.0.1]) by oz.cnes.com (8.9.3/8.9.3) with ESMTP id OAA26651 for ; Thu, 27 Feb 2003 14:36:33 -0800 (PST) Date: Thu, 27 Feb 2003 14:36:33 -0800 From: Scott Jepson To: linux-xfs@oss.sgi.com Subject: Re: Compile Error....kmem_zalloc Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2965 X-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: 417 Lines: 12 Hmmm. It looks like Qlogics driver for the QLA2X00 cards also defines a kmem_zalloc. Any idea how to handle such a problem? Thanks, -Scott ---------------------------------------------------------------- Scott Jepson, Managing Partner Email: scott@cnes.com Creative Network Services, LLC http://www.cnes.com (310)470-6140 ---------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Thu Feb 27 15:21:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Feb 2003 15:21:12 -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 h1RNL9eA013260 for ; Thu, 27 Feb 2003 15:21:10 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id A344D1830660; Thu, 27 Feb 2003 15:21:09 -0800 (PST) Date: Thu, 27 Feb 2003 15:21:09 -0800 From: Chris Wedgwood To: "Benito A. Venegas" Cc: Eric Sandeen , Mihai RUSU , Linux XFS List Subject: Re: converting XFS log v1 -> v2 Message-ID: <20030227232109.GA2236@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: 2966 X-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: 469 Lines: 13 On Thu, Feb 27, 2003 at 03:39:22PM -0500, Benito A. Venegas wrote: > Based in your answer to this Thread, so the only way for now it's > rebuilding the whole partition with mkfs to obtain v2?. I don't have > external log. I used only extended log in the same partition to > create my FS before ( mkfs -t xfs -l size=32768b ...) I've used xfs_db to change the 'version' on a clean, unmounted fs then forces xfs_replair -L before remounting it with a v2 log. --cw From owner-linux-xfs@oss.sgi.com Thu Feb 27 15:27:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Feb 2003 15:27: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 h1RNRaeA013716 for ; Thu, 27 Feb 2003 15:27:36 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 36ABD1830660; Thu, 27 Feb 2003 15:27:36 -0800 (PST) Date: Thu, 27 Feb 2003 15:27:36 -0800 From: Chris Wedgwood To: Scott Jepson Cc: linux-xfs@oss.sgi.com Subject: Re: Compile Error....kmem_zalloc Message-ID: <20030227232736.GA2276@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: 2967 X-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: 700 Lines: 21 On Thu, Feb 27, 2003 at 12:36:53PM -0800, Scott Jepson wrote: > I get this error on a 2.4.20 kernel with SCSI enabled for using a > qlogin controller. It compiled fine before adding the latest > xfs-patch (linux-2.4.20-xfs-2003-02-23.patch.bz2). > drivers/scsi/scsidrv.o: In function `kmem_zalloc': > drivers/scsi/scsidrv.o(.text+0x217c0): multiple definition of > `kmem_zalloc' > fs/fs.o(.text+0xb3d50): first defined here defined in xfs/support/kmem.c ; used in lots of places to a pain to rename (nor desirable for IRIX compat.) where is the qlogic driver? i grepped the kernel and didn't see kmem_zalloc used by any scsi code; are you able to tweak that or is it a binary module? --cw From owner-linux-xfs@oss.sgi.com Thu Feb 27 15:57:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Feb 2003 15:57:50 -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 h1RNvieA021717 for ; Thu, 27 Feb 2003 15:57:45 -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 h1RNvdOP000768; Thu, 27 Feb 2003 15:57:39 -0800 Received: from localhost (localhost [127.0.0.1]) by oz.cnes.com (8.9.3/8.9.3) with ESMTP id PAA26758; Thu, 27 Feb 2003 15:57:39 -0800 (PST) Date: Thu, 27 Feb 2003 15:57:39 -0800 From: Scott Jepson To: Eric Sandeen cc: linux-xfs@oss.sgi.com Subject: Re: Compile Error....kmem_zalloc In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2968 X-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: 1415 Lines: 55 That works! Which SuSE patch were you referring to? Thanks, -Scott ---------------------------------------------------------------- Scott Jepson, Managing Partner Email: scott@cnes.com Creative Network Services, LLC http://www.cnes.com (310)470-6140 ---------------------------------------------------------------- On Thu, 27 Feb 2003, Eric Sandeen wrote: > Date: Thu, 27 Feb 2003 17:07:29 -0600 (CST) > From: Eric Sandeen > To: Scott Jepson > Subject: Re: Compile Error....kmem_zalloc > > Maybe try something like: > > -inline void * > +static inline void * > kmem_zalloc( int siz, int code, int id) > > in qla2x00.c, and > > - extern inline void *kmem_zalloc( int siz, int code, int id); > + static inline void *kmem_zalloc( int siz, int code, int id); > > in qla_gbl.h > > (lifted from the SuSE patch) > > -Eric > > On Thu, 27 Feb 2003, Scott Jepson wrote: > > > Hmmm. It looks like Qlogics driver for the QLA2X00 cards also defines > > a kmem_zalloc. Any idea how to handle such a problem? > > > > Thanks, > > -Scott > > > > ---------------------------------------------------------------- > > Scott Jepson, Managing Partner Email: scott@cnes.com > > Creative Network Services, LLC http://www.cnes.com > > (310)470-6140 > > ---------------------------------------------------------------- > > > > > > From owner-linux-xfs@oss.sgi.com Thu Feb 27 17:02:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Feb 2003 17:03:00 -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 h1S12veA024208 for ; Thu, 27 Feb 2003 17:02:57 -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 h1S12pOP001386; Thu, 27 Feb 2003 17:02:51 -0800 Received: from localhost (localhost [127.0.0.1]) by oz.cnes.com (8.9.3/8.9.3) with ESMTP id RAA26815; Thu, 27 Feb 2003 17:02:50 -0800 (PST) Date: Thu, 27 Feb 2003 17:02:50 -0800 From: Scott Jepson To: Chris Wedgwood cc: linux-xfs@oss.sgi.com Subject: Re: Compile Error....kmem_zalloc In-Reply-To: <20030227232736.GA2276@f00f.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2969 X-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: 1410 Lines: 44 The Qlogic driver code was downloaded from www.qlogic.com and installed via their install notes. I fixed the problem with the suggestion from Eric Sandeen. -Scott ---------------------------------------------------------------- Scott Jepson, Managing Partner Email: scott@cnes.com Creative Network Services, LLC http://www.cnes.com (310)470-6140 ---------------------------------------------------------------- On Thu, 27 Feb 2003, Chris Wedgwood wrote: > Date: Thu, 27 Feb 2003 15:27:36 -0800 > From: Chris Wedgwood > To: Scott Jepson > Cc: linux-xfs@oss.sgi.com > Subject: Re: Compile Error....kmem_zalloc > > On Thu, Feb 27, 2003 at 12:36:53PM -0800, Scott Jepson wrote: > > > I get this error on a 2.4.20 kernel with SCSI enabled for using a > > qlogin controller. It compiled fine before adding the latest > > xfs-patch (linux-2.4.20-xfs-2003-02-23.patch.bz2). > > > drivers/scsi/scsidrv.o: In function `kmem_zalloc': > > drivers/scsi/scsidrv.o(.text+0x217c0): multiple definition of > > `kmem_zalloc' > > fs/fs.o(.text+0xb3d50): first defined here > > defined in xfs/support/kmem.c ; used in lots of places to a pain to > rename (nor desirable for IRIX compat.) > > where is the qlogic driver? i grepped the kernel and didn't see > kmem_zalloc used by any scsi code; are you able to tweak that or is > it a binary module? > > > --cw > > From owner-linux-xfs@oss.sgi.com Thu Feb 27 17:48:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Feb 2003 17:48:54 -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 h1S1mpeA025364 for ; Thu, 27 Feb 2003 17:48: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 h1S1wukq030148 for ; Thu, 27 Feb 2003 19:58:56 -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 TAA20536; Thu, 27 Feb 2003 19:48:45 -0600 (CST) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-41.corp.sgi.com [134.15.64.41]) by tulip-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id TAA26401; Thu, 27 Feb 2003 19:48:43 -0600 (CST) Subject: Re: Compile Error....kmem_zalloc From: Stephen Lord To: Scott Jepson Cc: Chris Wedgwood , 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: 27 Feb 2003 19:47:35 -0600 Message-Id: <1046396857.1728.2.camel@localhost.localdomain> Mime-Version: 1.0 X-archive-position: 2970 X-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: 392 Lines: 17 On Thu, 2003-02-27 at 19:02, Scott Jepson wrote: > The Qlogic driver code was downloaded from www.qlogic.com and > installed via their install notes. > > I fixed the problem with the suggestion from Eric Sandeen. > > -Scott > I have been running exactly the same setup, but with the qlogic driver built as a module - no problems here. Possibly different driver versions though. Steve From owner-linux-xfs@oss.sgi.com Thu Feb 27 19:40:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Feb 2003 19:40:21 -0800 (PST) Received: from pop11.ucdavis.edu (pop11.ucdavis.edu [169.237.105.21]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1S3e4eA029222 for ; Thu, 27 Feb 2003 19:40:05 -0800 Received: from localhost (localhost [127.0.0.1]) by pop11.ucdavis.edu (8.11.6/8.11.0/IT4.6.2) with ESMTP id h1S3e4M12872 for ; Thu, 27 Feb 2003 19:40:04 -0800 (PST) Date: Thu, 27 Feb 2003 19:40:04 -0800 (PST) From: Christopher Pelton X-X-Sender: cjpelton@pop11.ucdavis.edu To: linux-xfs@oss.sgi.com Subject: XFS version 1 on linux Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2971 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cjpelton@ucdavis.edu Precedence: bulk X-list: linux-xfs Content-Length: 337 Lines: 10 Is there any plan to incorporate XFS version 1 into XFS for linux? We have 50+ DVD's burned on an SGI that would be very helpful to read on a linux box, but they are of course version 1. If not, are there any other development projects for XFS, or a known workaround for transferring files, other than over the network? Thanks, Chris From owner-linux-xfs@oss.sgi.com Thu Feb 27 19:47:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Feb 2003 19:47: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 h1S3l6eA029712 for ; Thu, 27 Feb 2003 19:47:07 -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 h1S3l1Kp025733 for ; Thu, 27 Feb 2003 19:47:01 -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 VAA98314; Thu, 27 Feb 2003 21:47:00 -0600 (CST) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-41.corp.sgi.com [134.15.64.41]) by tulip-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id VAA17250; Thu, 27 Feb 2003 21:46:59 -0600 (CST) Subject: Re: XFS version 1 on linux From: Stephen Lord To: Christopher Pelton 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: 27 Feb 2003 21:45:51 -0600 Message-Id: <1046403952.1926.1.camel@localhost.localdomain> Mime-Version: 1.0 X-archive-position: 2972 X-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: 731 Lines: 22 On Thu, 2003-02-27 at 21:40, Christopher Pelton wrote: > Is there any plan to incorporate XFS version 1 into XFS for linux? We have > 50+ DVD's burned on an SGI that would be very helpful to read on a linux > box, but they are of course version 1. > > If not, are there any other development projects for XFS, or a known > workaround for transferring files, other than over the network? > > Thanks, > Chris > Do you mean version 1 directories? Or something else, linux and Irix XFS are on disk compatible. There are some issues with version 1 directories on linux (I think cvs is current broken in this regard), but for the most part they will work just fine. Steve p.s. how did you manage to burn xfs based dvd's on Irix? From owner-linux-xfs@oss.sgi.com Fri Feb 28 00:28:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Feb 2003 00:28:53 -0800 (PST) Received: from mail.automatix.de ([62.67.57.175]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1S8SneA001061 for ; Fri, 28 Feb 2003 00:28:50 -0800 Received: from uucp by mail.automatix.de with local-bsmtp (Exim 3.35 #1) id 18ofsu-0005di-00 for linux-xfs@oss.sgi.com; Fri, 28 Feb 2003 09:28:48 +0100 Received: from pc2.s.automatix.de ([192.168.11.12]) by s.automatix.de with esmtp (Exim 3.36 #1) id 18ofX3-0007YD-00; Fri, 28 Feb 2003 09:06:13 +0100 From: Juergen Sauer Reply-To: juergen.sauer@automatix.de Organization: AutomatiX GmbH To: Christopher Pelton , linux-xfs@oss.sgi.com Subject: Re: XFS version 1 on linux Date: Fri, 28 Feb 2003 09:06:09 +0100 User-Agent: KMail/1.5 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: <200302280906.16457.juergen.sauer@automatix.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h1S8SpeA001062 X-archive-position: 2974 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juergen.sauer@automatix.de Precedence: bulk X-list: linux-xfs Content-Length: 1306 Lines: 41 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Freitag, 28. Februar 2003 04:40 schrieb Christopher Pelton: > Is there any plan to incorporate XFS version 1 into XFS for linux? We have > 50+ DVD's burned on an SGI that would be very helpful to read on a linux > box, but they are of course version 1. > If not, are there any other development projects for XFS, or a known > workaround for transferring files, other than over the network? Ok, all that should work, really. You shold be able to: - transfer the DVDs - transfer the Harddisks - Install Linux on the SGI machine (http://www.debian.org) First, you may Check it / Test is before you do the real work: You find at: http://www.knopper.net/knoppix/ an single iso-CD Linux, ready to run without installing anything, just burn it to CD. It has the current XFS included and you may test your datatransfer work without any risks. mfG Jürgen - -- Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de ** ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** ** http://www.automatix.de http://www.kranautomatisierung.de ** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+Xxh2W7UKI9EqarERApaPAJ9D3yV0pH18V8bSEwK52b2UA3o+RQCgqmTP iPINIF8ceZAywqKkswSeFi4= =NCkT -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Fri Feb 28 00:28:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Feb 2003 00:28:29 -0800 (PST) Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1S8SLeA001006 for ; Fri, 28 Feb 2003 00:28:23 -0800 Received: from inf.ethz.ch (IDENT:nQjsA7gIWjfHpP0Nn99PY24ZVb4TlG0+@ikarus.inf.ethz.ch [129.132.10.58]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id JAA13501; Fri, 28 Feb 2003 09:28:02 +0100 (MET) Message-ID: <3E5F1D92.3070404@inf.ethz.ch> Date: Fri, 28 Feb 2003 09:28:02 +0100 From: Marc Schmitt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Lord CC: Scott Jepson , Chris Wedgwood , linux-xfs@oss.sgi.com Subject: Re: Compile Error....kmem_zalloc References: <1046396857.1728.2.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2973 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: schmitt@inf.ethz.ch Precedence: bulk X-list: linux-xfs Content-Length: 563 Lines: 34 Same here, no problems. kernel: 2.4.19 XFS: 1.2.0 qla2xxx: v6.01.00-fo Using qla2300 driver as module. Greetz Marc Stephen Lord wrote: > On Thu, 2003-02-27 at 19:02, Scott Jepson wrote: > >>The Qlogic driver code was downloaded from www.qlogic.com and >>installed via their install notes. >> >>I fixed the problem with the suggestion from Eric Sandeen. >> >>-Scott >> > > > I have been running exactly the same setup, but with the qlogic > driver built as a module - no problems here. Possibly different > driver versions though. > > Steve > > > > From owner-linux-xfs@oss.sgi.com Fri Feb 28 00:34:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Feb 2003 00:34:53 -0800 (PST) Received: from mail.srz-berlin.de (ambrosius.srz-berlin.de [217.9.41.134]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1S8YneA001936 for ; Fri, 28 Feb 2003 00:34:50 -0800 Received: from [192.168.1.17] (helo=srz-berlin.de) by mail.srz-berlin.de with esmtp (Exim 6.66 #1) id 18ofyX-0008Nu-00 for linux-xfs@oss.sgi.com; Fri, 28 Feb 2003 09:34:37 +0100 Message-ID: <3E5F1E85.637C0E42@srz-berlin.de> Date: Fri, 28 Feb 2003 09:32:05 +0100 From: Axel Bringenberg Organization: Satz-Rechen-Zentrum Berlin - Systemgruppe (http://www.srz.de) X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.4.9-31SGI_XFS_1.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: XFS and RH8 failing install References: <3E5AB1A5.1BA10AA9@sydney.sgi.com> <3E5AE866.2BCC0647@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanner: exiscan *18ofyX-0008Nu-00*DZM5QGt/LTY* on Astaro Security Linux X-archive-position: 2975 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: A.Bringenberg@srz-berlin.de Precedence: bulk X-list: linux-xfs Content-Length: 464 Lines: 19 Hello, Mike Grayson schrieb: [...] > What happens is that all goes well until it asks for the "disc 6" > I install the xfs install cd as suggested. > press the OK button and NOTHING. I've tried yesterday an installation on a test pc and saw on console #3, that the installer tried to install the file lib-attr-2.0.19-0.i386.rpm - which isn't on disc 6. Could this be the problem? Cheers - bringi Axel Bringenberg -- Satz-Rechen-Zentrum Berlin - Systemgruppe From owner-linux-xfs@oss.sgi.com Fri Feb 28 01:27:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Feb 2003 01:28:05 -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 h1S9RueA002789 for ; Fri, 28 Feb 2003 01:27:59 -0800 Received: by sundancer.oche.de (Postfix, from userid 10) id 69D1429A5D; Fri, 28 Feb 2003 10:27:51 +0100 (CET) Received: (from news@localhost) by foehn.quickstep.oche.de (8.9.3/8.6.12) id KAA10493 for linux-xfs@oss.sgi.com; Fri, 28 Feb 2003 10:26:20 +0100 (CET) To: linux-xfs@oss.sgi.com Path: not-for-mail From: Martin Spott Newsgroups: list.linux-xfs Subject: Re: Compile Error....kmem_zalloc Date: 28 Feb 2003 09:26:20 GMT Organization: home Message-ID: References: NNTP-Posting-Host: tango.quickstep.oche.de X-Trace: foehn.quickstep.oche.de 1046424380 10360 192.168.48.11 (28 Feb 2003 09:26:20 GMT) X-Complaints-To: usenet@foehn.quickstep.oche.de NNTP-Posting-Date: 28 Feb 2003 09:26:20 GMT User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.20-xfs-evms (i686)) X-archive-position: 2976 X-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: 622 Lines: 15 Scott Jepson wrote: > Hmmm. It looks like Qlogics driver for the QLA2X00 cards also defines > a kmem_zalloc. Any idea how to handle such a problem? I took the QLA driver sources and built a patch from that against 2.4.20. Maybe you'd like to have a look at it - works great for me, although I never did test it as a module because I'm booting from that device: ftp://ftp.uni-duisburg.de:/Linux/kernel/patches/qla2x00src-v6.01.00.patch.gz Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Fri Feb 28 02:56:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Feb 2003 02:56:20 -0800 (PST) Received: from curlew.cs.man.ac.uk (curlew.cs.man.ac.uk [130.88.13.7]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1SAuBeA007585 for ; Fri, 28 Feb 2003 02:56:12 -0800 Received: from lithium.sta.man.ac.uk ([130.88.188.32] helo=doufu ident=mail) by curlew.cs.man.ac.uk with esmtp (Exim 4.12) id 18nKFI-0008j9-00 for linux-xfs@oss.sgi.com; Mon, 24 Feb 2003 15:10:20 +0000 Received: from rhowe by doufu with local (Exim 3.36 #1 (Debian)) id 18nKFH-0006EI-00 for ; Mon, 24 Feb 2003 15:10:19 +0000 Date: Mon, 24 Feb 2003 15:10:19 +0000 To: linux-xfs@oss.sgi.com Subject: Log corruption on /home. Message-ID: <20030224151019.GA23716@lithium.sta.man.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i From: "Russell G. Howe" X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *18nKFI-0008j9-00*Xw7xZeDVVTE* X-archive-position: 2977 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rhowe@wiss.co.uk Precedence: bulk X-list: linux-xfs Content-Length: 1132 Lines: 30 OK, now that /var is happy I have another problem :) /home was also corrupted by the crash, and fails to mount due to log corruption. Is it worth trying to find a way to avoid running xfs_repair -L on the partition? The log as dumped by xfs_logprint doesn't seem particularly interesting (although it doesn't seem to dump all of it). See: http://rhowe.sfarc.net/xfs_logprint_on_home.txt.gz http://rhowe.sfarc.net/kernel_log_on_mount.txt http://rhowe.sfarc.net/xfs_db_inode_6291870_on_home.txt http://rhowe.sfarc.net/file-analysis.txt The kernel log contains an error dumped whilst performing the actions in file-analysis.txt. I mounted the fs with the ro and norecovery options in order to do them. Eric Sandeen had a brief look at me with this last night (US time) but it was getting late so we didn't have time to do anything other than collect some error messages together. My other posts to the list about this don't seem to have made it to oss - hopefully this one will (and the others won't :) -- Russell Howe | Why be just another cog in the machine, rhowe@wiss.co.uk | when you can be the spanner in the works? From owner-linux-xfs@oss.sgi.com Fri Feb 28 03:16:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Feb 2003 03:16:11 -0800 (PST) Received: from relay.dstl.gov.uk (relay.dera.gov.uk [192.5.29.49]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1SBG5eA008280 for ; Fri, 28 Feb 2003 03:16:05 -0800 Received: (qmail 31558 invoked from network); 28 Feb 2003 11:16:01 +0000 Received: from warlock.dstl.gov.uk (192.5.29.10) by relay.dera.gov.uk with SMTP; 28 Feb 2003 11:16:01 +0000 Subject: cvs update trouble From: Tony Gale To: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-JWGVfM/osj7QE7mo/UgV" Organization: Message-Id: <1046430958.18089.28.camel@syntax.dstl.gov.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 28 Feb 2003 11:15:59 +0000 X-archive-position: 2978 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gale@syntax.dstl.gov.uk Precedence: bulk X-list: linux-xfs Content-Length: 786 Lines: 32 --=-JWGVfM/osj7QE7mo/UgV Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Updating 2.4 cvs stops here: cvs server: Updating linux/scripts/usb strace shows cvs waiting in read() from the network. AFAIK, there is no such directory as linux/scripts/usb in the source tree. -tony --=-JWGVfM/osj7QE7mo/UgV Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iQCVAwUAPl9E7h/0GZs/Z0FlAQL90AQA3YNrlcmFxpXxxOpixtn3A4t81gDlFhka J393aQLpO8zog2xJqZenqYZ93ORukhJBYpg035aQrUUBXdnZmoiRaLWwGtWq+Ni2 44BZ15BSKKUx/MqSfALAIMp95uxMyTSbDtHAI4P+Dt2TlEq20OjEaCw36wDJvwYr 8PNV0GKm+pg= =K/b9 -----END PGP SIGNATURE----- --=-JWGVfM/osj7QE7mo/UgV-- From owner-linux-xfs@oss.sgi.com Fri Feb 28 03:45:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Feb 2003 03:45:49 -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 h1SBjgeA009724 for ; Fri, 28 Feb 2003 03:45:43 -0800 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id h1SBjex3069019; Fri, 28 Feb 2003 12:45:40 +0100 (CET) Message-Id: <4.3.2.7.2.20030228124509.03296ac0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 28 Feb 2003 12:45:29 +0100 To: Tony Gale , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: cvs update trouble In-Reply-To: <1046430958.18089.28.camel@syntax.dstl.gov.uk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_12687153==_" X-archive-position: 2979 X-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: 4534 Lines: 100 --=====================_12687153==_ Content-Type: multipart/related; type="text/plain"; boundary="=====================_12687153==_.REL" --=====================_12687153==_.REL Content-Type: text/plain; charset="us-ascii"; format=flowed At 11:15 28-2-2003 +0000, Tony Gale wrote: >c113fc.jpg cvs update trouble.emstrouble.ems <0880.0002>> >*** PGP Signature Status: good >*** Signer: Tony Gale (Invalid) >*** Signed: 28-2-2003 12:15:58 >*** Verified: 28-2-2003 12:44:57 >*** BEGIN PGP VERIFIED MESSAGE *** > >Updating 2.4 cvs stops here: > >cvs server: Updating linux/scripts/usb > >strace shows cvs waiting in read() from the network. upgrade your cvs tools Cheers --=====================_12687153==_.REL Content-Type: image/jpeg; name="c113fc.jpg"; x-mac-type="4A504547"; x-mac-creator="4A565752" Content-ID: <4.3.2.7.2.20030228124509.03296ac0@pop.xs4all.nl.0> Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="c113fc.jpg" /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/ 2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAARCAAgACADASIAAhEBAxEB/8QA HwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUF BAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1 dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEB AQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAEC AxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRom JygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU 1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD+gCvlf9tW b4sW37Nvjq4+DFp4ov8AxfBrHwym1mw8DtrCeNL34TRfFfwO/wAfLTwg/ha5 svHieKLn4Fr8RodAb4W3lp8Yl1Z7Q/By5g+KI8Iypp3dx8fviH8dfjX4F+Hf xZ+HXwl8A/BD4Rfsh+MdRl1L9ij4+/tnfEPxf4t/as+M/wC0t8KLWHTvDPwK /aJ+EOt6B4T8Ht8EPD9/q+oL4R8VQ6dYeIPEHifxHrWgeHPDtxOn09Y/sP8A 7cmoWtneQftvfsqpDfW9pcwpcf8ABNj41W10sd5HYSxrNYzf8FO0vYrgLqEY a0a3+1PJ9khghmm13wwmufB8TeJ/AHBuNhl/FHFWV5NjalP2sKGLqVVJxtGT TdOlUhGpGFSlUlRlJVYUq+HqygqWIozqdVHBYrERcqFCdSKdm4penVp2vdJ7 NppO6aX8w3iD4Qa/+xd+0J+wr8S/D/hzwf8ABf47/tW6h8M9Z+P3gj4YfC79 nn4Y+BPhPquu/tM/sPfCb4ufs+fDTTfgD8O/B2k+Ifgfd6R+018QdAGg/FLX /jhc2ms+BPhL8TPCnja2+JXgq1+IGp/04V+Pnxn8OeHvhRL/AMFA9W/aj8N/ 8E+/2oPjD8Ef2rPgn4E8PfGD9o39jf8AZT13w34a+HPj39lf9ifxzZeAvB3h f9s//goJ4Fm+Hnw8t9V+InjrWNK8Nr+0v4Y8F618R/FHxU+J/gi/8eax468T 6D8Lvmr9qSw+HfgfWf8Agl148+B3wS/Zb+CXiX4j/tH/ALEfizxN49/ZZ/Zh /Zq+CHiDWfD3xVv/AIR+F/GmmWXxB/Z68O/E7U7f4L+PLfxh418Pal4b0H48 +J/g54rl1zX/AAwv7VHxouBd/s++Cfk868deDsoz/grh+GHzjNK3H3EGQcP5 BmWXUMDPKZz4iyHE8S4HMcRXr5hQxUMveU4SrLno4KvXliZ0KKw6o1KmJo7U 8sxFSliat6cFhaVSrVhNyVS1KtGhKCSg4uftJLRyS5U3e6UX+6X/AATi/YV/ YP8AFX7IH/BMzSvFn/BHT9n/AOK//C1/2AP2WfiL8Sf2vdT/AGav2Cdc8Cad 471z9n/R9e1yD4pS+OfGenftNeKviB4q1rTra61DxF4Z+Cnj7R9R1jx9oWoa z4uTy/G174V+Zf8Agn/4x/ac/YJ1n/gn1+xFq37D/wAePgr4I+M/g74d/s2+ PdG+N/jz4BT/AAT0X9q74Y/s0+KPiH8afjZ+zl4i+C3xU+P3jfT/AAx8Xr74 U/E7VfHnwy1T4Yp8LviB418VWn7Qa+Kfgn4x8Y/tB+Fv2neL/Zu/aZ/4JheL v2Vv+Cc+m/F79sj/AIIoGw8Of8E4P2FP2ev2oPhb+1R+zn4E/aD/AGh/EPhX 4e+Hvh18SvGfwOm+NNx+1N4C0PwJ4f0Xxnomh6po3w08b/BL4m6d8LPjr4Xu fiDrui+IdetIfC2iN/bA/bD+CvxZ0v8A4JO/BP8AY7+PP/BLv9tL9oD4KftE fE21tPhB8O9Nk+EX7K2l/DrSf2L/ANqjwz4Tih+Avhvx1+0/4x+H3gf4ceA2 0PQ9As7PV/G3hc+PtE8NpJbeFPDniGx8O6P9p4h8MZfxfwZxFkeYZLTz9YjK 8bUwWWSlQpVa2aUMNVqZb9UxOIxODpYPGfW1Tjh8VPG4OnSlN+2xNKhKrI58 JWnh8RRqwqOk4zjzT1aUHJc/NFKTlHlvePLJvpFux9zj9gjQP239Vb9qO6+N n7Zf7F/xI+KcPgXxv8Vvhd8AfEHiDw74G1P4oReDvg3YW3j6Oy/bf/YW8M/F W08ayeFPhP8AArwrqtz4Z8B+C9MuJfhN8MNe13wafjVp99e/Eb8tfi/+wD4a +GX/AAU4/Zh/Z88YftE/tG/tGfCjwL+zprv7bHhPw78dNR+Bt9JoHxz+C3xX +CHwq+GWraJrHwr+C/w31fQ9D0Lw7c6BfJp+h6hp0utWvhDwj4Q1LW/Fnwfj v/D/AIw+0NJ/aF/4K0eH9Z1PxF4f/Zb/AOCSmheINas7TTtW13Sfin+0rZaz qen6dYrpel2Op6nF+zsL3VLPTdMg0/TrS11Oe7gFjpy2kyTW+q+IY9Z4Pw54 c/bc+MP7bnhr9q/9q/w1+yz4LsfBf7LPxM/Z70bRv2e/iZ8YfHN3qt345+MP wq+J2n6pqmn/ABO+FXgyPT4dPj8GeJLXUtRtfEmoXWqXWoaRPPpD6g+t63e/ xn4YeCniHgPGXhXiviTw6yfJ+F8lw9P/AGnHVOBc5zbA1cu4Nq5LlVKGbYLF ZhxFjfqOZQwkMuxFWtzUcNhsNVlHC+wp0aX0ONzHCTy6tQpYupUr1JP3YrE0 6clPERqTfs5KNKPNHmc0lq21eV23/9k= --=====================_12687153==_.REL-- --=====================_12687153==_ Content-Type: text/plain; charset="us-ascii"; format=flowed -- Seth It might just be your lucky day, if you only knew. --=====================_12687153==_-- From owner-linux-xfs@oss.sgi.com Fri Feb 28 07:31:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Feb 2003 07:31:43 -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 h1SFVaeA020966 for ; Fri, 28 Feb 2003 07:31: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 h1SFVUG8000480 for ; Fri, 28 Feb 2003 07:31:30 -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 JAA95348; Fri, 28 Feb 2003 09:31:27 -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 JAA08773; Fri, 28 Feb 2003 09:31:29 -0600 (CST) Subject: Re: XFS and RH8 failing install From: Eric Sandeen To: Axel Bringenberg Cc: linux-xfs@oss.sgi.com In-Reply-To: <3E5F1E85.637C0E42@srz-berlin.de> References: <3E5AB1A5.1BA10AA9@sydney.sgi.com> <3E5AE866.2BCC0647@sgi.com> <3E5F1E85.637C0E42@srz-berlin.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 28 Feb 2003 09:28:39 -0600 Message-Id: <1046446119.22640.0.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 2980 X-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: 781 Lines: 29 I think that Russell fixed this on the latest iso, can you verify that you're using the latest? -Eric On Fri, 2003-02-28 at 02:32, Axel Bringenberg wrote: > Hello, > > Mike Grayson schrieb: > [...] > > What happens is that all goes well until it asks for the "disc 6" > > I install the xfs install cd as suggested. > > press the OK button and NOTHING. > > I've tried yesterday an installation on a test pc and saw on console #3, > that the installer tried to install the file lib-attr-2.0.19-0.i386.rpm > - which isn't on disc 6. Could this be the problem? > > Cheers > - bringi > > Axel Bringenberg > -- > Satz-Rechen-Zentrum Berlin - Systemgruppe > -- 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 Fri Feb 28 07:31:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Feb 2003 07:31:43 -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 h1SFVaeA020967 for ; Fri, 28 Feb 2003 07:31:37 -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 h1SFVUG8000484 for ; Fri, 28 Feb 2003 07:31:31 -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 JAA73074; Fri, 28 Feb 2003 09:31:27 -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 JAA97210; Fri, 28 Feb 2003 09:31:29 -0600 (CST) Subject: Re: XFS and RH8 failing install From: Eric Sandeen To: Axel Bringenberg Cc: linux-xfs@oss.sgi.com In-Reply-To: <3E5F1E85.637C0E42@srz-berlin.de> References: <3E5AB1A5.1BA10AA9@sydney.sgi.com> <3E5AE866.2BCC0647@sgi.com> <3E5F1E85.637C0E42@srz-berlin.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 28 Feb 2003 09:28:39 -0600 Message-Id: <1046446119.22655.1.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 2980 X-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: 781 Lines: 29 I think that Russell fixed this on the latest iso, can you verify that you're using the latest? -Eric On Fri, 2003-02-28 at 02:32, Axel Bringenberg wrote: > Hello, > > Mike Grayson schrieb: > [...] > > What happens is that all goes well until it asks for the "disc 6" > > I install the xfs install cd as suggested. > > press the OK button and NOTHING. > > I've tried yesterday an installation on a test pc and saw on console #3, > that the installer tried to install the file lib-attr-2.0.19-0.i386.rpm > - which isn't on disc 6. Could this be the problem? > > Cheers > - bringi > > Axel Bringenberg > -- > Satz-Rechen-Zentrum Berlin - Systemgruppe > -- 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 Fri Feb 28 09:05:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Feb 2003 09:05:12 -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 h1SH54eA022838 for ; Fri, 28 Feb 2003 09:05:05 -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 h1SH4jOP005598; Fri, 28 Feb 2003 09:04:45 -0800 Received: from localhost (localhost [127.0.0.1]) by oz.cnes.com (8.9.3/8.9.3) with ESMTP id JAA27445; Fri, 28 Feb 2003 09:04:45 -0800 (PST) Date: Fri, 28 Feb 2003 09:04:44 -0800 From: Scott Jepson To: Marc Schmitt cc: linux-xfs@oss.sgi.com Subject: Re: Compile Error....kmem_zalloc In-Reply-To: <3E5F1D92.3070404@inf.ethz.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2981 X-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: 1310 Lines: 59 Looks like I'm running a different qlogin driver: kernel: 2.4.20 XFS: 1.2.0 qla2xxx: qla2x00-v6.04.00b8 -Scott ---------------------------------------------------------------- Scott Jepson, Managing Partner Email: scott@cnes.com Creative Network Services, LLC http://www.cnes.com (310)470-6140 ---------------------------------------------------------------- On Fri, 28 Feb 2003, Marc Schmitt wrote: > Date: Fri, 28 Feb 2003 09:28:02 +0100 > From: Marc Schmitt > To: Stephen Lord > Cc: Scott Jepson , Chris Wedgwood , > linux-xfs@oss.sgi.com > Subject: Re: Compile Error....kmem_zalloc > > Same here, no problems. > > kernel: 2.4.19 > XFS: 1.2.0 > qla2xxx: v6.01.00-fo > > Using qla2300 driver as module. > > Greetz > Marc > > Stephen Lord wrote: > > On Thu, 2003-02-27 at 19:02, Scott Jepson wrote: > > > >>The Qlogic driver code was downloaded from www.qlogic.com and > >>installed via their install notes. > >> > >>I fixed the problem with the suggestion from Eric Sandeen. > >> > >>-Scott > >> > > > > > > I have been running exactly the same setup, but with the qlogic > > driver built as a module - no problems here. Possibly different > > driver versions though. > > > > Steve > > > > > > > > > > > From owner-linux-xfs@oss.sgi.com Fri Feb 28 09:32:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Feb 2003 09:33:05 -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 h1SHWveA023420 for ; Fri, 28 Feb 2003 09:32:58 -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 h1SHh4kq020125 for ; Fri, 28 Feb 2003 11:43: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 LAA09925 for ; Fri, 28 Feb 2003 11:32:51 -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 LAA75702 for ; Fri, 28 Feb 2003 11:32:49 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h210mbt28292 for linux-xfs@oss.sgi.com; Fri, 28 Feb 2003 19:48:37 -0500 Resent-Message-Id: <200303010048.h210mbt28292@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 KAA96564 for ; Fri, 28 Feb 2003 10:40:23 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h1SNuBA22006 for hch@sgi.com; Fri, 28 Feb 2003 18:56:11 -0500 Date: Fri, 28 Feb 2003 18:56:11 -0500 From: Christoph Hellwig Message-Id: <200302282356.h1SNuBA22006@taclab54.munich.sgi.com> Subject: TAKE - remove an unused variable Resent-From: hch@sgi.com Resent-Date: Fri, 28 Feb 2003 19:48:36 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 2982 X-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: 261 Lines: 11 Date: Fri Feb 28 08:39:31 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:140576a linux/fs/xfs/xfs_dir2_block.c - 1.28 From owner-linux-xfs@oss.sgi.com Fri Feb 28 22:19:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Feb 2003 22:19:44 -0800 (PST) Received: from ente.berdmann.de (frnk-d514e1d6.dsl.mediaWays.net [213.20.225.214]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h216JdeA032502 for ; Fri, 28 Feb 2003 22:19:40 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.35 #1) id 18p0LL-0004vf-00; Sat, 01 Mar 2003 07:19:31 +0100 Message-ID: <3E6050F2.3000908@berdmann.de> Date: Sat, 01 Mar 2003 07:19:30 +0100 From: Bernhard Erdmann User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.3b) Gecko/20030224 X-Accept-Language: de, en, fr MIME-Version: 1.0 To: juergen.sauer@automatix.de CC: Christopher Pelton , linux-xfs@oss.sgi.com Subject: Re: XFS version 1 on linux References: <200302280906.16457.juergen.sauer@automatix.de> In-Reply-To: <200302280906.16457.juergen.sauer@automatix.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2983 X-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: 591 Lines: 19 Juergen Sauer wrote: [...] > Ok, all that should work, really. > You shold be able to: > - transfer the DVDs > - transfer the Harddisks > - Install Linux on the SGI machine (http://www.debian.org) > > First, you may Check it / Test is before you do the real work: > You find at: http://www.knopper.net/knoppix/ > an single iso-CD Linux, ready to run without installing anything, just > burn it to CD. > It has the current XFS included and you may test your datatransfer > work without any risks. I guess this SGI box has one or more MIPS CPU - Knoppix is for the i386 architecture. From owner-linux-xfs@oss.sgi.com Fri Feb 28 23:20:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Feb 2003 23:20:45 -0800 (PST) Received: from ente.berdmann.de (frnk-d514e1d6.dsl.mediaWays.net [213.20.225.214]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h217KdeA000863 for ; Fri, 28 Feb 2003 23:20:41 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.35 #1) id 18p1IN-000510-00; Sat, 01 Mar 2003 08:20:31 +0100 Message-ID: <3E605F3F.7040908@berdmann.de> Date: Sat, 01 Mar 2003 08:20:31 +0100 From: Bernhard Erdmann User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.3b) Gecko/20030224 X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Russell Cattelan CC: linux-xfs@oss.sgi.com Subject: Re: Hopefully the last installer image. References: <1045938661.1716.182.camel@lupo.thebarn.com> In-Reply-To: <1045938661.1716.182.camel@lupo.thebarn.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2984 X-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: 402 Lines: 13 Russell Cattelan wrote: > The hdlist file has been rebuilt the installer has run through a > install "everything" pass. > I know not a a lot of testing but I should it in a "works for me" state > at this point. > > ftp://oss.sgi.com/projects/xfs/Release-1.2/installer/forRH-8.0-SGI-XFS-1.2.0-v4.iso > b1387ef5b9acd9def14a9f4eb298aaea forRH-8.0-SGI-XFS-1.2.0-v4.iso Thanks! Works for me too (TM) From owner-linux-xfs@oss.sgi.com Fri Feb 28 23:33:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Feb 2003 23:34:01 -0800 (PST) Received: from ente.berdmann.de (frnk-d514e1d6.dsl.mediaWays.net [213.20.225.214]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h217XueA001391 for ; Fri, 28 Feb 2003 23:33:57 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.35 #1) id 18p1VE-00052R-00; Sat, 01 Mar 2003 08:33:48 +0100 Message-ID: <3E60625B.9080408@berdmann.de> Date: Sat, 01 Mar 2003 08:33:47 +0100 From: Bernhard Erdmann User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.3b) Gecko/20030224 X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Matteo Centonza CC: linux-xfs@oss.sgi.com Subject: Re: nfsd crashes regularly (Oops) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2985 X-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: 700 Lines: 28 Matteo Centonza wrote: > Hi Bernhard, > > >>I have a box running kernel 2.4.18 (SGI XFS 1.1). Say twice a week the >>NFS server crashes with Oops, i.e. NFS service is blocked but the box is >>still running a mail server and you can log in. > > > if xfsdump was running, probably it's a known problem: > > http://marc.theaimsgroup.com/?l=linux-xfs&m=100339196420164&w=2 > > solved in the current CVS or 1.2 prereleases: > > http://marc.theaimsgroup.com/?l=linux-xfs&m=102036006319547&w=2 Hi, xfsdump was run by Amanda each night to backup. Upgrading to XFS 1.2 and kernel 2.4.19 seems to have solved the problem. This box hasn't crashed for two weeks now. Regards Bernie From owner-linux-xfs@oss.sgi.com Fri Feb 28 23:47:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Feb 2003 23:47:35 -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 h217lXeA001908 for ; Fri, 28 Feb 2003 23:47:33 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h217lXZK001907 for linux-xfs@oss.sgi.com; Fri, 28 Feb 2003 23:47:33 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h217lWeA001896 for ; Fri, 28 Feb 2003 23:47:32 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h217SXv5001347; Fri, 28 Feb 2003 23:28:33 -0800 Date: Fri, 28 Feb 2003 23:28:33 -0800 Message-Id: <200303010728.h217SXv5001347@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 223] mounting xfs on raid0 in linux-2.5.62 triggers BUG at ll_rw_blk.c:2000 X-Bugzilla-Reason: AssignedTo X-archive-position: 2986 X-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: 1757 Lines: 63 http://oss.sgi.com/bugzilla/show_bug.cgi?id=223 ------- Additional Comments From cw@f00f.org 2003-02-20 02:45 ------- Subject: Re: New: mounting xfs on raid0 in linux-2.5.62 triggers BUG at ll_rw_blk.c:2000 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 ------- Additional Comments From msokalski@atsi.krakow.pl 2003-02-20 02:48 ------- Subject: Re: New: mounting xfs on raid0 in linux-2.5.62 triggers BUG at ll_rw_blk.c:2000 > 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 ------- Additional Comments From vapier@gentoo.org 2003-02-28 23:28 ------- i reported it as an xfs bug because i have a raid0 setup that uses reiserfs in the same box with the same setup, but it does not cause a BUG() ... ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.