From owner-linux-xfs@oss.sgi.com Mon Oct 1 00:33:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f917Xvv10377 for linux-xfs-outgoing; Mon, 1 Oct 2001 00:33:57 -0700 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f917XrD10358 for ; Mon, 1 Oct 2001 00:33:53 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f917XjK08472 for ; Mon, 1 Oct 2001 00:33:45 -0700 Received: (from fsgqa@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA70639 for linux-xfs@oss.sgi.com; Mon, 1 Oct 2001 17:32:27 +1000 (EST) Date: Mon, 1 Oct 2001 17:32:27 +1000 (EST) From: FSG QA Message-Id: <200110010732.RAA70639@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsdump/xfsrestore cleanup Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Remove stkchk references. --Tim Date: Mon Oct 1 00:31:33 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/fsgqa/isms/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:103645a cmd/xfsdump/dump/Makefile - 1.7 - get rid of stkchk cmd/xfsdump/common/main.c - 1.12 - get rid of useless stkchk related calls and code cmd/xfsdump/common/cldmgr.c - 1.5 - get rid of stkchk related calls cmd/xfsdump/restore/Makefile - 1.7 cmd/xfsdump/common/Makefile - 1.6 - get rid of stkchk cmd/xfsdump/VERSION - 1.19 - bump revision for removal of stkchk abstraction cmd/xfsdump/doc/CHANGES - 1.22 - note removal of stkchk stuff From owner-linux-xfs@oss.sgi.com Mon Oct 1 00:37:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f917bJf10530 for linux-xfs-outgoing; Mon, 1 Oct 2001 00:37:19 -0700 Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f917bDD10511 for ; Mon, 1 Oct 2001 00:37:13 -0700 Received: from mailgate4.nec.co.jp ([10.7.69.197]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id f917b3a08435 for ; Mon, 1 Oct 2001 16:37:03 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id f917b2V20098 for ; Mon, 1 Oct 2001 16:37:02 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (THKTNES98740.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id f917aaX29684 for ; Mon, 1 Oct 2001 16:36:56 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA98 for ; Mon, 1 Oct 2001 16:36:34 +0900 Received: FROM mailsv.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Mon Oct 01 16:36:33 2001 +0900 Received: from rifu.bsd.tnes.nec.co.jp (IDENT:root@rifu.bsd.tnes.nec.co.jp [10.1.101.142]) by mailsv.tnes.nec.co.jp (8.9.3/3.7W01031510) with ESMTP id QAA84179; Mon, 1 Oct 2001 16:36:34 +0900 (JST) Received: from tagajo.bsd.tnes.nec.co.jp (tagajo.bsd.tnes.nec.co.jp [10.1.101.146]) by rifu.bsd.tnes.nec.co.jp (8.10.2+3.3W/3.7W/BSD-TNES-MX01) with ESMTP id f917aYi29106; Mon, 1 Oct 2001 16:36:34 +0900 Received: (from sasaki@localhost) by tagajo.bsd.tnes.nec.co.jp (8.8.5+2.7Wbeta5/3.5Wpl1-97090809) id QAA26557; Mon, 1 Oct 2001 16:36:34 +0900 (JST) Message-Id: <200110010736.QAA26557@tagajo.bsd.tnes.nec.co.jp> To: Timothy Shimmin cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - xfsdump/restore changes for ia64 In-reply-to: Your message of Mon, 01 Oct 2001 17:03:29 +1000. <20011001170329.A1372@boing.melbourne.sgi.com> Date: Mon, 01 Oct 2001 16:36:34 +0900 From: Takayuki Sasaki Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Timothy, Thank you for your time. Timothy Shimmin wrote: > Hi Takayuki, > > On Mon, Oct 01, 2001 at 03:06:20PM +0900, Takayuki Sasaki wrote: > > > > FSG QA wrote: > > > Date: Fri Sep 28 02:49:27 PDT 2001 > > > Workarea: snort.melbourne.sgi.com:/diskb/build4/fsgqa/isms/2.4.x-xfs > > (snip) > > > cmd/xfsdump/common/stkchk.c - 1.2 > > > - make a size long so comparison works for ia32/ia64 with ptr > > > > I have a question. > > > > The type of sc_sz in struct stkchk is changed to long from int, > > but get_stacksz() is left declared to return int. > > > > stkchk.c line 90: > > stkchkp->sc_sz = get_stacksz( ); > > > > Further more, I'm wondering because it seems that rlim_cur is > > defined as unsigned long. > > > > [My box is RedHat 7.1] > > $ grep rlim_cur /usr/include/*/*.h > > /usr/include/bits/resource.h: rlim_t rlim_cur; > > /usr/include/bits/resource.h: rlim64_t rlim_cur; > > (snip) > > /usr/include/linux/resource.h: unsigned long rlim_cur; > > $ grep rlim_t /usr/include/*/*.h > > /usr/include/bits/resource.h:typedef __rlim_t rlim_t; > > /usr/include/bits/resource.h:typedef __rlim64_t rlim_t; > > /usr/include/bits/resource.h: rlim_t rlim_cur; > > /usr/include/bits/resource.h: rlim_t rlim_max; > > /usr/include/bits/types.h:typedef __u_long __rlim_t; /* Type of resource counts. */ > > > > Which is correct? > > > Well, from this it seems it should be declared as : unsigned long. > But I have a better solution forthcoming. > > This abstraction (one of too many in xfsdump) has a stack checking function > stkchk() which is only called in main.c in a function "stkplay" > (it calls itself recursively until it gets stack overflow and outputs > at what address this happens at...unsure how useful this is) > which is NEVER compiled in (#ifdef NEVER). Yes, shkchk() is nerver compiled, however, this is in stkchk_register()... Could I disregard for this? Thanks in advance, Takayuki From owner-linux-xfs@oss.sgi.com Mon Oct 1 00:54:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f917s3J10995 for linux-xfs-outgoing; Mon, 1 Oct 2001 00:54:03 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f917rtD10976 for ; Mon, 1 Oct 2001 00:53:55 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id AAA03594 for ; Mon, 1 Oct 2001 00:52:46 -0700 (PDT) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA02002; Mon, 1 Oct 2001 17:52:30 +1000 (AEST) Date: Mon, 1 Oct 2001 17:52:30 +1000 From: Timothy Shimmin To: Takayuki Sasaki Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - xfsdump/restore changes for ia64 Message-ID: <20011001175230.D1372@boing.melbourne.sgi.com> References: <20011001170329.A1372@boing.melbourne.sgi.com> <200110010736.QAA26557@tagajo.bsd.tnes.nec.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <200110010736.QAA26557@tagajo.bsd.tnes.nec.co.jp>; from sasaki@bsd.tnes.nec.co.jp on Mon, Oct 01, 2001 at 04:36:34PM +0900 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Takayuki, On Mon, Oct 01, 2001 at 04:36:34PM +0900, Takayuki Sasaki wrote: > > Thank you for your time. You're welcome. > > This abstraction (one of too many in xfsdump) has a stack checking function > > stkchk() which is only called in main.c in a function "stkplay" > > (it calls itself recursively until it gets stack overflow and outputs > > at what address this happens at...unsure how useful this is) > > which is NEVER compiled in (#ifdef NEVER). > > Yes, shkchk() is nerver compiled, however, this is in > stkchk_register()... > Could I disregard this? Yes. stkchk_register() just sets up some values so that stkchk() can use them later - but it never happens. The only thing that will be evident is that a debug message will no longer be printed for "-v debug=proc" debug level. But who cares :) Cheers, Tim. From owner-linux-xfs@oss.sgi.com Mon Oct 1 06:44:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f91Di7d17194 for linux-xfs-outgoing; Mon, 1 Oct 2001 06:44:07 -0700 Received: from smtp3.163.com ([202.108.44.203]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f91DhvD17169 for ; Mon, 1 Oct 2001 06:43:58 -0700 Received: from epyz.net (todd.jbic.com [205.133.156.45]) by smtp3.163.com (Postfix) with SMTP id 930EA1CA5847A; Mon, 1 Oct 2001 21:42:21 +0800 (CST) From: To: Subject: $0.00/min Long Distance MIME-Version: 1.0 Content-Type: multipart/mixed;boundary= "----=_NextPart_000_00A3_D9D587B1.C3962768" 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 Message-Id: <20011001134221.930EA1CA5847A@smtp3.163.com> Date: Mon, 1 Oct 2001 21:42:21 +0800 (CST) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk ------=_NextPart_000_00A3_D9D587B1.C3962768 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMC8vRU4iPg0KPCEt LSBzYXZlZCBmcm9tIHVybD0oMDAyMilodHRwOi8vaW50ZXJuZXQuZS1tYWlsIC0tPg0KPGh0 bWw+DQo8aGVhZD4NCjx0aXRsZT5GbGF0IFJhdGUgTG9uZyBEaXN0YW5jZTwvdGl0bGU+DQo8 bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD1pc28tODg1OS0xIj4NCjxNRVRBIG5hbWU9IkdFTkVSQVRPUiIgY29udGVudD0iSUJN IE5ldE9iamVjdHMgVG9wUGFnZSBWNC4wLjMgIGZvciBXaW5kb3dzIj4NCjwvaGVhZD4NCjxC T0RZIGJnY29sb3I9IiMwMDAwMDAiIHRleHQ9IiNmZmZmZmYiPg0KPFRBQkxFIHdpZHRoPSI1 MDAiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiBhbGlnbj0i bGVmdCIgYmdjb2xvcj0iI2ZmZmZmZiI+DQogIA0KICAgIDxUUiBiZ2NvbG9yPSIjZmZmZjgw Ij4NCiAgICAgIDxURCBoZWlnaHQ9IjEyMyIgd2lkdGg9IjUwMSI+PGRpdiBhbGlnbj0iY2Vu dGVyIj48Rk9OVCBzaXplPSIzIiBmYWNlPSJBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlm IiBjb2xvcj0iIzAwMDAwMCI+PEI+PEZPTlQgc2l6ZT0iNSI+VW5saW1pdGVkIExvbmcgRGlz dGFuY2U8YnI+DQogICAgICA8L0ZPTlQ+PEZPTlQgc2l6ZT0iNCI+DQogICAgICAkMzkuOTUg cGVyIG1vbnRoPC9mb250PjxGT05UIHNpemU9IjUiPjxCUj4NCiAgICAgIDwvRk9OVD48L0I+ PEZPTlQgY29sb3I9IiNmZjAwMDAiPjxCPjxGT05UIHNpemU9IjUiPg0KICAgICAgPEZPTlQg c2l6ZT0iMyI+T05FIEZFRSwgT05DRSBBIE1PTlRIPGJyPg0KICAgICAgTk8gTU9SRSBPVVRS QUdFT1VTIFBIT05FIEJJTExTPC9mb250PjwvRk9OVD48L0I+PC9GT05UPjwvRk9OVD48QlI+ DQogICAgICA8Rk9OVCBjb2xvcj0iIzAwMDAwMCI+PEI+PEJSPg0KICAgICAgPEZPTlQgZmFj ZT0iQXJpYWwiPg0KICAgICAgSXQncyB5b3VyIE1vbmV5IFlvdSBDaG9vc2UhPC9GT05UPjwv Qj48L0ZPTlQ+PC9kaXY+DQogICAgPC90ZD4NCiAgICA8L3RyPg0KICAgIDx0cj4gDQogICAg PHRkIGhlaWdodD0iMjIiPg0KICAgICAgPERJViBhbGlnbj0iY2VudGVyIiBzdHlsZT0idG9w IDogMTM5cHg7bGVmdCA6IDEwcHg7Ij4gPGZvbnQgY29sb3I9IiMwMDAwOTkiIGZhY2U9IkFy aWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPjxicj4NCiAgICAgICAgUmVzaWRlbnRpYWwg YW5kIEJ1c2luZXNzIEZsYXQgUmF0ZSBMb25nIERpc3RhbmNlIC08Yj4gPGZvbnQgY29sb3I9 IiM5OTAwMDAiPk9ORSANCiAgICAgICAgTU9OVEhMWSBGRUU8L2ZvbnQ+PC9iPjxCPiA8L0I+ c3RhcnRpbmcgYXQ8Qj4gPGZvbnQgY29sb3I9IiM5OTAwMDAiPiQzOS45NTwvZm9udD48L0I+ PC9mb250PiANCiAgICAgICAgPEJSPg0KICAgICAgPHA+PEZPTlQgZmFjZT0iQXJpYWwsIEhl bHZldGljYSwgc2Fucy1zZXJpZiIgc2l6ZT0iMiIgY29sb3I9IiMwMDAwMDAiPjxCPklmIHdv dWxkIGxpa2UgbW9yZSBpbmZvcm1hdGlvbiwgcGxlYXNlIGZpbGwNCiAgICAgIG91dCB0aGUg Zm9sbG93aW5nIGZvcm0gYW5kIGEgcmVwcmVzZW50YXRpdmUNCiAgICAgIHdpbGwgdGVsbCB5 b3UgYWxsIGFib3V0IGl0LjwvQj48L0ZPTlQ+PC9wPg0KICAgICAgICA8cD48Rk9OVCBmYWNl PSJBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSIyIiBjb2xvcj0iIzAwMDAw MCI+PGI+Tm8gaGFzc2xlcy4gTm8gDQogICAgICAgICAgaGFyZCBzZWxsIHRhY3RpY3MuIEp1 c3QgdGhlIGZhY3RzITwvYj48L2ZvbnQ+PC9wPg0KICAgICAgPC9kaXY+DQogICAgICA8L3Rk Pg0KICA8L3RyPg0KICA8dHI+IA0KICAgIDx0ZD4gDQogICAgICA8Zm9ybSBtZXRob2Q9InBv c3QiIGVuY1R5cGU9dGV4dC9wbGFpbg0KYWN0aW9uPSJtYWlsdG86am9pbl9pbkBleGNpdGUu Y29tP3N1YmplY3Q9RmxhdCBSYXRlIExvbmcgRGlzdGFuY2UgSW5xdWlyeSI+DQogICAgICAg IDx0YWJsZSB3aWR0aD0iNTAwIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFk ZGluZz0iMyI+DQogICAgICAgICAgPHRyPiANCiAgICAgICAgICAgIDx0ZCB3aWR0aD0iNTAl Ij48Rk9OVCBmYWNlPSJBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSIyIiBj b2xvcj0iIzAwMDAwMCI+TmFtZTo8L2ZvbnQ+PC90ZD4NCiAgICAgICAgICAgIDx0ZD48Rk9O VCBmYWNlPSJBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSIyIiBjb2xvcj0i IzAwMDAwMCI+IA0KICAgICAgICAgICAgICA8aW5wdXQgdHlwZT0idGV4dCIgbmFtZT0ibmFt ZSI+DQogICAgICAgICAgICAgIDwvZm9udD48L3RkPg0KICAgICAgICAgIDwvdHI+DQogICAg ICAgICAgPHRyPiANCiAgICAgICAgICAgIDx0ZCB3aWR0aD0iNTAlIj48Rk9OVCBmYWNlPSJB cmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSIyIiBjb2xvcj0iIzAwMDAwMCI+ UGhvbmUgDQogICAgICAgICAgICAgIE51bWJlcjo8L2ZvbnQ+PC90ZD4NCiAgICAgICAgICAg IDx0ZD48Rk9OVCBmYWNlPSJBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSIy IiBjb2xvcj0iIzAwMDAwMCI+DQogICAgICAgICAgICAgIDxpbnB1dCB0eXBlPSJ0ZXh0IiBu YW1lPSJwaG9uZSI+DQogICAgICAgICAgICAgIDwvZm9udD48L3RkPg0KICAgICAgICAgIDwv dHI+DQogICAgICAgICAgPHRyPiANCiAgICAgICAgICAgIDx0ZCB3aWR0aD0iNTAlIj48Rk9O VCBmYWNlPSJBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSIyIiBjb2xvcj0i IzAwMDAwMCI+RW1haWwgDQogICAgICAgICAgICAgIEFkZHJlc3M6PC9mb250PjwvdGQ+DQog ICAgICAgICAgICA8dGQ+PEZPTlQgZmFjZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJp ZiIgc2l6ZT0iMiIgY29sb3I9IiMwMDAwMDAiPg0KICAgICAgICAgICAgICA8aW5wdXQgdHlw ZT0idGV4dCIgbmFtZT0iZW1haWwiPg0KICAgICAgICAgICAgICA8L2ZvbnQ+PC90ZD4NCiAg ICAgICAgICA8L3RyPg0KICAgICAgICAgIDx0cj4gDQogICAgICAgICAgICA8dGQgd2lkdGg9 IjUwJSI+PEZPTlQgZmFjZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiIgc2l6ZT0i MiIgY29sb3I9IiMwMDAwMDAiPkJlc3QgDQogICAgICAgICAgICAgIFRpbWUgdG8gQ29udGFj dDo8L2ZvbnQ+PC90ZD4NCiAgICAgICAgICAgIDx0ZD48Rk9OVCBmYWNlPSJBcmlhbCwgSGVs dmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSIyIiBjb2xvcj0iIzAwMDAwMCI+DQogICAgICAg ICAgICAgIDxpbnB1dCB0eXBlPSJ0ZXh0IiBuYW1lPSJiZXN0dGltZSI+DQogICAgICAgICAg ICAgIDwvZm9udD48L3RkPg0KICAgICAgICAgIDwvdHI+DQogICAgICAgICAgPHRyPg0KICAg ICAgICAgICAgPFREIGNvbHNwYW49IjIiIGhlaWdodD0iNDUiIGFsaWduPSJjZW50ZXIiPiAN CiAgICAgICAgICAgICAgPGRpdiBhbGlnbj0iY2VudGVyIj48Rk9OVCBmYWNlPSJBcmlhbCwg SGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSIyIiBjb2xvcj0iIzAwMDAwMCI+DQogICAg ICAgICAgICAgICAgPGlucHV0IHR5cGU9InN1Ym1pdCIgbmFtZT0iU3VibWl0IiB2YWx1ZT0i U3VibWl0Ij4NCiAgICAgICAgICAgICAgICA8L2ZvbnQ+PC9kaXY+DQogICAgICAgICAgICA8 QlI+DQogICAgICAgICAgICA8Rk9OVCBmYWNlPSJBcmlhbCIgY29sb3I9IiMwMDAwMDAiPg0K ICAgICAgICAgICAgWW91IHdpbGwgc2F2ZSBodW5kcmVkcyBvciBldmVuDQogICAgICAgICAg ICB0aG91c2FuZHMNCiAgICAgICAgICAgIG9mIGRvbGxhcnMgZWFjaCB5ZWFyISBIb21lIGFu ZA0KICAgICAgICAgICAgc21hbGwgYnVzaW5lc3MNCiAgICAgICAgICAgIHBsYW5zIGFyZSBo ZXJlITwvRk9OVD48QlI+DQogICAgICAgICAgICA8QlI+DQogICAgICAgICAgICA8Rk9OVCBj b2xvcj0iI2ZmMDAwMCIgZmFjZT0iQXJpYWwiPkhhdmUgYSBjb21wYW55IHdpdGggYSBsYXJn ZSBwaG9uZSBiaWxsPyBJZg0KICAgICAgICAgICAgdGhlIGFuc3dlciBpcyB5ZXMsIHdlIGFz ayBXaHk/PC9GT05UPjwvdGQ+DQogICAgICAgICAgPC90cj4NCiAgICAgICAgPC90YWJsZT4N CiAgICAgIDwvZm9ybT4NCiAgICA8L3RkPg0KICA8L3RyPg0KICA8dHI+DQogICAgICA8VEQg d2lkdGg9IjUwMCIgaGVpZ2h0PSI4OCI+DQogICAgICA8ZGl2IGFsaWduPSJjZW50ZXIiPg0K ICAgICAgICA8cD48Rk9OVCBjb2xvcj0iIzAwMDAwMCI+Jm5ic3A7PC9GT05UPjwvcD4NCiAg ICAgICAgPHA+PEZPTlQgZmFjZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiIgc2l6 ZT0iMiIgY29sb3I9IiMwMDAwMDAiPklmIHlvdSB3b3VsZCBsaWtlIA0KICAgICAgICAgIHRv IGJlIHJlbW92ZWQgZnJvbSBvdXIgbGlzdCwgcGxlYXNlIHNlbmQgYW4gZW1haWwgdG8gPGEg aHJlZj0ibWFpbHRvOmNlYXNlZmlyZTAyMUBtYWlsLmNvbSAiPnJwZmxhdHJhdGVsb25nZGlz dG5vd0BleGNpdGUuY29tLjwvYT4gDQogICAgICAgICAgPC9mb250PjwvcD4NCiAgICAgIDwv ZGl2Pg0KICAgIDwvdGQ+DQogICAgPC90cj4NCjwvdGFibGU+DQo8L2JvZHk+DQo8L2h0bWw+ DQogICAgDQogICAg ------=_NextPart_000_00A3_D9D587B1.C3962768-- From owner-linux-xfs@oss.sgi.com Mon Oct 1 06:54:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f91DsWb17735 for linux-xfs-outgoing; Mon, 1 Oct 2001 06:54:32 -0700 Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f91DsSD17716 for ; Mon, 1 Oct 2001 06:54:28 -0700 Received: from mailgate4.nec.co.jp ([10.7.69.197]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id f91DrYa10236 for ; Mon, 1 Oct 2001 22:53:34 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id f91DrXV19432 for ; Mon, 1 Oct 2001 22:53:33 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (THKTNES98740.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id f91DrXX08304 for ; Mon, 1 Oct 2001 22:53:33 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA291 for ; Mon, 1 Oct 2001 22:53:31 +0900 Received: FROM noshiro.bsd.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Mon Oct 01 22:53:30 2001 +0900 Received: from localhost (localhost [127.0.0.1]) by noshiro.bsd.tnes.nec.co.jp (Postfix) with ESMTP id 67F00660C for ; Mon, 1 Oct 2001 22:53:31 +0900 (JST) To: linux-xfs@oss.sgi.com Subject: execute lvchange while mounting XFS filesystem X-Mailer: Mew version 1.94.2 on XEmacs 21.4 (Artificial Intelligence) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20011001225331N.masano@tnes.nec.co.jp> Date: Mon, 01 Oct 2001 22:53:31 +0900 (JST) From: ASANO Masahiro X-Dispatcher: imput version 20000228(IM140) Lines: 22 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I encountered an oops and you can reproduce it with the following operations: # lvcreate -L 32m -n masano1 /dev/vg0 # mkfs.xfs /dev/vg0/masano1 # mount /dev/vg0/masano1 /mnt/masano1 # lvchange -p r /dev/vg0/masano1 # touch /mnt/masano1/dummy # sync I think that these operations may have no special meaning, however, it seems that there is an issue in the error handling of writing log operation. I looked into XFS kernel sources but I could not find what led to this oops. Thanks in advance, -- masano From owner-linux-xfs@oss.sgi.com Mon Oct 1 07:05:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f91E5me18098 for linux-xfs-outgoing; Mon, 1 Oct 2001 07:05:48 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f91E5kD18077 for ; Mon, 1 Oct 2001 07:05:46 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f91E43L22893 for ; Mon, 1 Oct 2001 07:04:03 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA3047355; Mon, 1 Oct 2001 09:02:47 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA90926; Mon, 1 Oct 2001 09:02:47 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f91E25O06650; Mon, 1 Oct 2001 09:02:05 -0500 Message-Id: <200110011402.f91E25O06650@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Sean Elble cc: linux-xfs@oss.sgi.com Subject: Re: IRIX 6.5.6m/XFS CVS: Any problems? In-Reply-To: Message from Sean Elble of "Sun, 30 Sep 2001 13:14:08 PDT." <20010930201408.26924.qmail@web11706.mail.yahoo.com> Date: Mon, 01 Oct 2001 09:02:05 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hello, > > I have a Silicon Graphics Indigo2 here with IRIX > 6.5.6m installed (love it, BTW), and a Linux server > that is about to have the latest CVS version of the > XFS kernel installed, along with the kernel-level NFS > server. > > Are there any known problems, or catches, using NFS on > IRIX with a Linux 2.4.10 server? I would like to use > NFS3, if possible, but I would appreciate any comments > any users may have. Thanks, in advance! > You may want to upgrade to the latest Irix release, there were some problems with NFS V3 between Linux and Irix. The Irix implementation expected the NFS file handles to be of a specific size, and Linux used a different size. I think this is fixed in 6.5.13. This only affected V3 NFS I think. Steve From owner-linux-xfs@oss.sgi.com Mon Oct 1 07:35:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f91EZna18701 for linux-xfs-outgoing; Mon, 1 Oct 2001 07:35:49 -0700 Received: from dmz.tecosim.de ([194.24.222.241]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f91EZeD18681 for ; Mon, 1 Oct 2001 07:35:41 -0700 Received: (from uucp@localhost) by dmz.tecosim.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) id f91EVO128259; Mon, 1 Oct 2001 16:31:24 +0200 Received: from ns.tecosim.de(194.24.222.9) via SMTP by dmz.tecosim.de, id smtpd4pkXQU; Mon Oct 1 16:31:23 2001 Received: from donner.tecosim.de (donner.tecosim.de [194.24.222.109]) by ns.tecosim.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id f91EXCL03546; Mon, 1 Oct 2001 16:33:12 +0200 Received: (from leh@localhost) by donner.tecosim.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) id f91EVLh23773; Mon, 1 Oct 2001 16:31:21 +0200 Date: Mon, 1 Oct 2001 16:31:21 +0200 From: Utz Lehmann To: Steve Lord Cc: Sean Elble , linux-xfs@oss.sgi.com Subject: Re: IRIX 6.5.6m/XFS CVS: Any problems? Message-ID: <20011001163121.D15188@de.tecosim.com> References: <200110011402.f91E25O06650@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="IiVenqGWf+H9Y6IX" Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <200110011402.f91E25O06650@jen.americas.sgi.com>; from lord@sgi.com on Mon, Oct 01, 2001 at 09:02:05AM -0500 X-Scanned-By: MIMEDefang 1.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --IiVenqGWf+H9Y6IX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Steve Lord [lord@sgi.com] wrote: > > Hello, > > > > I have a Silicon Graphics Indigo2 here with IRIX > > 6.5.6m installed (love it, BTW), and a Linux server > > that is about to have the latest CVS version of the > > XFS kernel installed, along with the kernel-level NFS > > server. > > > > Are there any known problems, or catches, using NFS on > > IRIX with a Linux 2.4.10 server? I would like to use > > NFS3, if possible, but I would appreciate any comments > > any users may have. Thanks, in advance! > > > > You may want to upgrade to the latest Irix release, there were some > problems with NFS V3 between Linux and Irix. The Irix implementation > expected the NFS file handles to be of a specific size, and Linux used > a different size. I think this is fixed in 6.5.13. This only affected > V3 NFS I think. > > Steve I had grabed a small patch for the linux nfs server on lkml. It's set the file handle size on the linux nfs server to a value (older) IRIX Versions (and HP-UX 10.20) can understand. I have used this patch till 2.4.9. Maybe it works with 2.4.10 too. It works for me, but use it at your own risk. Or use NFS v2. utz --IiVenqGWf+H9Y6IX Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="nfsfh-broken-clients.patch" --- linux-2.4-xfs-20010723/linux/fs/nfsd/nfsfh.c Thu Jul 12 18:33:21 2001 +++ linux/fs/nfsd/nfsfh.c Tue Jul 24 19:03:33 2001 @@ -818,6 +818,11 @@ nfsd_nr_verified++; if (fhp->fh_handle.fh_fileid_type == 255) return nfserr_opnotsupp; + +/* fix for broken nfs clients */ +if (inode && fhp->fh_handle.fh_size < NFS_FHSIZE) +fhp->fh_handle.fh_size = NFS_FHSIZE; + return 0; } @@ -849,6 +854,11 @@ fhp->fh_handle.fh_size = (datap-fhp->fh_handle.fh_auth+1)*4; } out: + +/* fix for broken nfs clients */ +if (fhp->fh_handle.fh_size < NFS_FHSIZE) +fhp->fh_handle.fh_size = NFS_FHSIZE; + return 0; out_bad: --IiVenqGWf+H9Y6IX-- From owner-linux-xfs@oss.sgi.com Mon Oct 1 08:50:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f91FoaL20454 for linux-xfs-outgoing; Mon, 1 Oct 2001 08:50:36 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f91FoWD20434 for ; Mon, 1 Oct 2001 08:50:32 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f91FmJL02197 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Mon, 1 Oct 2001 08:48:19 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id RAA1525448 for ; Mon, 1 Oct 2001 17:48:10 +0200 (CEST) mail_from (roehrich@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA3099100; Mon, 1 Oct 2001 10:46:48 -0500 (CDT) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.187.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA59909; Mon, 1 Oct 2001 10:46:47 -0500 (CDT) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id KAA27923; Mon, 1 Oct 2001 10:46:47 -0500 (CDT) Message-Id: <200110011546.KAA27923@slobber.americas.sgi.com> To: Takayuki Sasaki cc: linux-xfs@oss.sgi.com Subject: Re: wbee (sample_hsm) dumped core Date: Mon, 01 Oct 2001 10:46:47 -0500 From: Dean Roehrich Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From: Takayuki Sasaki >> me what you think: should we just remove sample_hsm/print_event and rely on >> the other print_event? > >I think so because sample_hsm/print_eventry was not compiled >here by make :) then I made it by hand and run it. It seemed >work successfully, however, there is no document of >sample_hsm/print_event except itself, so I'm not sure about it. > >Could you tell me what are you using or should I use to evaluate >dmapi of XFS filesystem? Is there any good tools / documents >besides cvs tree? I use the print_event in src/suite1/cmd/print_event.c. It looks like the print_event in suite1 has a few extra pieces, and some changes in the formatting. I guess I'm inclined to remove the one in sample_hsm. Most of the stuff I use is in src/simple, src/common/cmd, and src/suite1, and I do like to use sample_hsm/mls. I named suite1 and suite2 in that way because, as far as I could see, suite2 appeared to be a descendant of suite1. The things that are now in src/common were found in both suite1 and suite2--hence, "common". Suite2 has some baggage with it, as you may have noticed, and it's possible that it has something to do with automation (maybe src/suite2/menu_test). Let's see...the only piece I haven't explained is src/simple. That's the stuff I made back when I needed some simple tests, and the rest of this jumble of test suites was making me dizzy. If you're looking for more info on DMAPI you should dig around on: http://www.opengroup.org/onlinepubs/9657099/toc.htm Dean From owner-linux-xfs@oss.sgi.com Mon Oct 1 09:24:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f91GOu921114 for linux-xfs-outgoing; Mon, 1 Oct 2001 09:24:56 -0700 Received: from mail.aem.umn.edu (mail.aem.umn.edu [128.101.142.239]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f91GOoD21095 for ; Mon, 1 Oct 2001 09:24:50 -0700 Received: from lightning.aem.umn.edu (lightning.aem.umn.edu [128.101.143.49]) by mail.aem.umn.edu (8.9.3/8.9.3) with ESMTP id LAA48741 for ; Mon, 1 Oct 2001 11:23:15 -0500 (CDT) (envelope-from muno@aem.umn.edu) Received: (from muno@localhost) by lightning.aem.umn.edu (8.11.2/8.9.1) id f91GMrC24727 for linux-xfs@oss.sgi.com; Mon, 1 Oct 2001 11:22:53 -0500 Date: Mon, 1 Oct 2001 11:22:53 -0500 From: Ray Muno To: linux-xfs@oss.sgi.com Subject: Bad permissions with SGI XFS 1.01 Redhat 7.1 install Message-ID: <20011001112251.A21559@aem.umn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.19-current-20010622i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk We are installing Redhat 7.1 SGI XFS 1.01 on various machines. We have noticed that there are quite a few system files with wide open permissions. [root@lightning muno]# find / -mount -perm 666 -exec ls -l {} \; | grep -v games | grep -v dev -rw-rw-rw- 1 root root 68 Aug 30 13:39 /var/lib/pgsql/.bash_profile -rw-rw-rw- 1 root root 670 Sep 26 10:06 /var/lib/texmf/ls-R -rw-rw-rw- 1 root root 21815 Aug 30 13:46 /var/log/XFree86.9.log -rw-rw-rw- 1 root root 0 Aug 30 13:39 /var/ftp/etc/ld.so.conf srw-rw-rw- 1 root root 0 Sep 26 16:27 /tmp/.gdm_socket -rw-rw-rw- 1 root root 53 Aug 30 13:45 /etc/sysconfig/i18n -rw-rw-rw- 1 root root 89 Aug 30 13:45 /etc/sysconfig/mouse -rw-rw-rw- 1 root root 32 Aug 30 13:45 /etc/sysconfig/keyboard -rw-rw-rw- 1 root root 66 Aug 30 13:45 /etc/sysconfig/network -rw-rw-rw- 1 root root 42 Aug 30 13:45 /etc/sysconfig/clock -rw-rw-rw- 1 root root 11 Aug 30 13:45 /etc/sysconfig/desktop -rw-rw-rw- 1 root root 2724 Aug 30 13:45 /etc/sysconfig/hwconf -rw-rw-rw- 1 root root 14559 Aug 30 13:46 /etc/X11/XF86Config -rw-rw-rw- 1 root root 1842 Aug 30 13:46 /etc/X11/XF86Config-4 -rw-rw-rw- 1 root root 16351 Aug 30 13:45 /etc/X11/XF86Config.old -rw-rw-rw- 1 root root 3740 Aug 30 13:45 /etc/X11/XF86Config-4.old -rw-rw-rw- 1 root root 114 Aug 30 13:43 /etc/ld.so.conf -rw-rw-rw- 1 root root 84 Aug 30 13:45 /etc/shells -rw-rw-rw- 1 root root 984 Aug 30 13:39 /etc/syslog.conf -rw-rw-rw- 1 root root 1756 Aug 30 13:46 /etc/inittab -rw-rw-rw- 1 root root 1199 Aug 30 13:39 /etc/rndc.conf -rw-rw-rw- 1 root root 81 Sep 26 16:23 /etc/resolv.conf -rw-rw-rw- 1 root root 221 Aug 30 13:39 /etc/sgml/sgml-docbook-3.0.cat -rw-rw-rw- 1 root root 194 Aug 30 13:41 /etc/sgml/catalog -rw-rw-rw- 1 root root 221 Aug 30 13:39 /etc/sgml/sgml-docbook-3.1.cat -rw-rw-rw- 1 root root 221 Aug 30 13:39 /etc/sgml/sgml-docbook-4.0.cat -rw-rw-rw- 1 root root 221 Aug 30 13:39 /etc/sgml/sgml-docbook-4.1.cat -rw-rw-rw- 1 root root 220 Aug 30 13:41 /etc/sgml/xml-docbook-4.1.cat -rw-rw-rw- 1 root root 2564 Aug 30 13:43 /etc/pango/pango.modules-rw-rw-rw- 1 root root 104 Aug 30 13:45 /etc/modules.conf~ -rw-rw-rw- 1 root root 543 Sep 17 12:43 /etc/fstab -rw-rw-rw- 1 root root 148 Sep 27 14:40 /etc/hosts -rw-rw-rw- 1 root root 380 Aug 30 13:40 /usr/share/doc/libtool-1.3.5/demo/config.h.in -rw-rw-rw- 1 root root 2 Aug 30 13:44 /usr/share/fonts/default/TrueType/fonts.dir -rw-rw-rw- 1 root root 1436 Aug 30 13:44 /usr/share/fonts/default/TrueType/fonts.scale -rw-rw-rw- 1 root root 21853 Aug 30 13:38 /usr/share/fonts/fontmap-rw-rw-rw- 1 root root 10638 Aug 30 13:40 /usr/share/texmf/web2c/jadetex.log -rw-rw-rw- 1 root root 10599 Aug 30 13:40 /usr/share/texmf/web2c/pdfjadetex.log -rw-rw-rw- 1 root root 1806912 Aug 30 13:40 /usr/share/texmf/web2c/jadetex.fmt -rw-rw-rw- 1 root root 1849935 Aug 30 13:40 /usr/share/texmf/web2c/pdfjadetex.fmt - This is not an issue with Redhat 7.1 directly. It does not exhibit this behavior. I opened a bug report with Redhat and they said it is an issue with the SGI installer. ============================================================================= 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 Mon Oct 1 09:35:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f91GZ6R21419 for linux-xfs-outgoing; Mon, 1 Oct 2001 09:35:06 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f91GZ4D21400 for ; Mon, 1 Oct 2001 09:35:04 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f91GXCL07723 for ; Mon, 1 Oct 2001 09:33:12 -0700 Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA3113969; Mon, 1 Oct 2001 11:31:56 -0500 (CDT) Received: from sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id LAA35289; Mon, 1 Oct 2001 11:31:55 -0500 (CDT) Message-ID: <3BB899DC.B8620DA8@sgi.com> Date: Mon, 01 Oct 2001 11:29:16 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.8-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Ray Muno CC: linux-xfs@oss.sgi.com Subject: Re: Bad permissions with SGI XFS 1.01 Redhat 7.1 install References: <20011001112251.A21559@aem.umn.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ray Muno wrote: > > We are installing Redhat 7.1 SGI XFS 1.01 on various machines. We have > noticed that there are quite a few system files with wide open permissions. > This is not an issue with Redhat 7.1 directly. It does not exhibit this > behavior. I opened a bug report with Redhat and they said it is an issue > with the SGI installer. This is a known issue with an available work-around, please see ftp://oss.sgi.com/projects/xfs/download/Release-1.0.1/installer/00-SECURITY-WARNING-README Thanks, -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Oct 1 09:35:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f91GZTG21535 for linux-xfs-outgoing; Mon, 1 Oct 2001 09:35:29 -0700 Received: from roujin.gargoylecc.com (mail@roujin.gargoylecc.com [65.100.85.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f91GZRD21516 for ; Mon, 1 Oct 2001 09:35:27 -0700 Received: from ringram by roujin.gargoylecc.com with local (Exim 3.32 #1) id 15o60j-00046K-00 for linux-xfs@oss.sgi.com; Mon, 01 Oct 2001 10:33:41 -0600 Date: Mon, 1 Oct 2001 10:33:41 -0600 To: linux-xfs@oss.sgi.com Subject: back-port patches for xfs to pre 2.4 kernels Message-ID: <20011001103341.A15757@roujin.gargoylecc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.22i From: Russel Ingram Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I think I probably already know the answer to this question but I figure it doesn't hurt to ask anyway. Is there any possibility that a patch could be made to add support to a 2.2.19 kernel? The only reason I would want this is due to the fact that the Debian woody i386 kernel is still at 2.2.19 and the tools for building custom boot disks don't quite work right if I try to supply them with a 2.4 kernel for xfs. Thanx, Russ -- Russel H. Ingram Gargoyle Computer Consulting (307)742-1361 or (307)760-1317 www.gargoylecc.com From owner-linux-xfs@oss.sgi.com Mon Oct 1 09:36:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f91GajW21670 for linux-xfs-outgoing; Mon, 1 Oct 2001 09:36:45 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f91GahD21650 for ; Mon, 1 Oct 2001 09:36:43 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f91GYoL07871 for ; Mon, 1 Oct 2001 09:34:50 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA3109938; Mon, 1 Oct 2001 11:33:34 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA62774; Mon, 1 Oct 2001 11:33:34 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f91GWpm06991; Mon, 1 Oct 2001 11:32:51 -0500 Message-Id: <200110011632.f91GWpm06991@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Ray Muno cc: linux-xfs@oss.sgi.com Subject: Re: Bad permissions with SGI XFS 1.01 Redhat 7.1 install In-Reply-To: Message from Ray Muno of "Mon, 01 Oct 2001 11:22:53 CDT." <20011001112251.A21559@aem.umn.edu> Date: Mon, 01 Oct 2001 11:32:51 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > - > > This is not an issue with Redhat 7.1 directly. It does not exhibit this > behavior. I opened a bug report with Redhat and they said it is an issue > with the SGI installer. It is actually the version of the kernel used during the install which has the problem. Take a look here for some updates and a script to fix permissions: ftp://oss.sgi.com/projects/xfs/download/Release-1.0.1/installer/ Steve From owner-linux-xfs@oss.sgi.com Mon Oct 1 10:39:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f91HdFR22933 for linux-xfs-outgoing; Mon, 1 Oct 2001 10:39:15 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f91HdCD22914 for ; Mon, 1 Oct 2001 10:39:12 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA05614 for ; Mon, 1 Oct 2001 10:36:24 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA3104233; Mon, 1 Oct 2001 12:36:15 -0500 (CDT) Received: from sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id MAA38865; Mon, 1 Oct 2001 12:36:15 -0500 (CDT) Message-ID: <3BB8A8EE.9A9CDC2C@sgi.com> Date: Mon, 01 Oct 2001 12:33:34 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.8-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Russel Ingram CC: linux-xfs@oss.sgi.com Subject: Re: back-port patches for xfs to pre 2.4 kernels References: <20011001103341.A15757@roujin.gargoylecc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Russel Ingram wrote: > > I think I probably already know the answer to this question but I > figure it doesn't hurt to ask anyway. Is there any possibility that > a patch could be made to add support to a 2.2.19 kernel? The only > reason I would want this is due to the fact that the Debian woody i386 > kernel is still at 2.2.19 and the tools for building custom boot disks > don't quite work right if I try to supply them with a 2.4 kernel for xfs. SGI has no plans to backport XFS to 2.2, I think you will find it much easier to fix the boot disk creation tools than to backport XFS. :) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Oct 1 10:50:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f91HoGn23210 for linux-xfs-outgoing; Mon, 1 Oct 2001 10:50:16 -0700 Received: from roujin.gargoylecc.com (mail@roujin.gargoylecc.com [65.100.85.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f91HoCD23191 for ; Mon, 1 Oct 2001 10:50:12 -0700 Received: from ringram by roujin.gargoylecc.com with local (Exim 3.32 #1) id 15o7Bf-00048I-00 for linux-xfs@oss.sgi.com; Mon, 01 Oct 2001 11:49:03 -0600 Date: Mon, 1 Oct 2001 11:49:03 -0600 To: linux-xfs@oss.sgi.com Subject: Re: back-port patches for xfs to pre 2.4 kernels Message-ID: <20011001114903.A15883@roujin.gargoylecc.com> References: <20011001103341.A15757@roujin.gargoylecc.com> <3BB8A8EE.9A9CDC2C@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3BB8A8EE.9A9CDC2C@sgi.com> User-Agent: Mutt/1.3.22i From: Russel Ingram Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Oct 01, 2001 at 12:33:34PM -0500, Eric Sandeen wrote: > Russel Ingram wrote: > > > > I think I probably already know the answer to this question but I > > figure it doesn't hurt to ask anyway. Is there any possibility that > > a patch could be made to add support to a 2.2.19 kernel? The only > > reason I would want this is due to the fact that the Debian woody i386 > > kernel is still at 2.2.19 and the tools for building custom boot disks > > don't quite work right if I try to supply them with a 2.4 kernel for xfs. > > SGI has no plans to backport XFS to 2.2, I think you will find it much easier to > fix the boot disk creation tools than to backport XFS. :) > > -Eric > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. That's what I figured but since I haven't had any success in making the boot disk tools work so far I thought I'd check. Thanx, Russ -- Russel H. Ingram Gargoyle Computer Consulting (307)742-1361 or (307)760-1317 www.gargoylecc.com From owner-linux-xfs@oss.sgi.com Mon Oct 1 11:23:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f91INv523912 for linux-xfs-outgoing; Mon, 1 Oct 2001 11:23:57 -0700 Received: from mail.aem.umn.edu (mail.aem.umn.edu [128.101.142.239]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f91INqD23893 for ; Mon, 1 Oct 2001 11:23:53 -0700 Received: from lightning.aem.umn.edu (lightning.aem.umn.edu [128.101.143.49]) by mail.aem.umn.edu (8.9.3/8.9.3) with ESMTP id NAA50385 for ; Mon, 1 Oct 2001 13:23:47 -0500 (CDT) (envelope-from muno@aem.umn.edu) Received: (from muno@localhost) by lightning.aem.umn.edu (8.11.2/8.9.1) id f91INPG25214 for linux-xfs@oss.sgi.com; Mon, 1 Oct 2001 13:23:25 -0500 Date: Mon, 1 Oct 2001 13:23:25 -0500 From: Ray Muno To: linux-xfs@oss.sgi.com Subject: Re: Bad permissions with SGI XFS 1.01 Redhat 7.1 install Message-ID: <20011001132323.E24742@aem.umn.edu> References: <20011001112251.A21559@aem.umn.edu> <20011001113717.P10348@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011001113717.P10348@sgi.com> User-Agent: Mutt/1.3.19-current-20010622i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks, three replies in very short order. I ran the fix-perms script and that is fine. I am a little confused about the updates disk. I am using kickstart to do the installs. How do I incorporate the update floppy in to that procedure? I boot from the SGI XFS 1.01 install CD and do a "linux ks". If this is truly a problem with the underlying kernel, will it cause problems beyond install time? I see that Redhat explicitly sets umask to 022 in /etc/rc.d/init.d/functions and calls that in the init scripts. Is there a danger of other things running as root creating files that are mode 666? Is there a kernel patch to fix the problem for the running machines. On Mon, Oct 01, 2001 at 11:37:17AM -0500, Nathan Straz wrote: > On Mon, Oct 01, 2001 at 11:22:53AM -0500, Ray Muno wrote: > > We are installing Redhat 7.1 SGI XFS 1.01 on various machines. We have > > noticed that there are quite a few system files with wide open permissions. > > This was caught a while ago. There is an update disk available to fix > this for you. See the original post at: > > http://marc.theaimsgroup.com/?l=linux-xfs&m=99685493904396&w=2 > > -- > Nate Straz nstraz@sgi.com > sgi, inc http://www.sgi.com/ > Linux Test Project http://ltp.sf.net/ ============================================================================= 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 Mon Oct 1 11:34:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f91IYmi24232 for linux-xfs-outgoing; Mon, 1 Oct 2001 11:34:48 -0700 Received: from mail.teatime.com.tw (mail.teatime.com.tw [210.241.226.252]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f91IYhD24212 for ; Mon, 1 Oct 2001 11:34:43 -0700 Received: from localhost ([127.0.0.1] helo=mail.teatime.com.tw ident=root) by mail.teatime.com.tw with smtp (Exim 3.32 #1 (Debian)) id 15o7tl-0004bU-00 for ; Tue, 02 Oct 2001 02:34:37 +0800 Received: from p176.inside ([192.168.0.176]) by mail.teatime.com.tw (TeaTime Mail Server 0.6.4) with SMTP id spool/smaOoNcS9 for ; Tue, 2 Oct 01 02:34:31 +0800 Date: Tue, 02 Oct 2001 02:36:34 +0800 From: Tommy Wu To: linux-xfs@oss.sgi.com Subject: xfs_force_shutdown problem ? Reply-To: tommy@teatime.com.tw Organization: TeaTime Development Message-Id: <20011002021047.4A8E.NEWSLETTER@teatime.com.tw> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.07 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! I got some message in my log. Maybe runnig 1 hour, 1 day or 1 week.... :-( I've got it serval times.... Sep 30 00:23:54 hisdb kernel: xfs_force_shutdown(sd(8,17),0x8) called from line \ 4072 of file xfs_bmap.c. Return address = 0xc018c5c4 Sep 30 00:23:54 hisdb kernel: Corruption of in-memory data detected. Shutting \ down filesystem: sd(8,17) Sep 30 00:23:54 hisdb kernel: Please umount the filesystem, and rectify the problem(s) I also found some message for xfs_force_shutdown in XFS faq. In the faq said, this maybe a hardware error for disk... but I got the message is different with faq... In faq, the message is 'I/O Error detect'... in my system, it show 'Corruption of in-memory...' But I've ran the memtest86 to test my ram... it is ok. Is there any suggestion for this problem ? My hardware is PIII * 2, 2G ram, with 9G scsi hdd *1 and a 560G external scsi raid. All partition use XFS, but this message only show in the external 560G scsi raid. I'm running in 2.4.9-xfs with HIMEM, SMP enabled. I also try 2.4.10-xfs, but there is some VM problem with HIMEM and SMP.... it will freeze my linux box (something deadlock...), so I don't got the same message like 2.4.9-xfs. Should I try some early kernel verion ? And... this message seem not a heavy loading problem... because I found every time it occured, the system loading is almost idle... -- Tommy Wu mailto:tommy@teatime.com.tw http://www.teatime.com.tw/~tommy ICQ: 22766091 Mobile Phone: +886 936 909490 TeaTime BBS +886 2 31515964 24Hrs V.Everything From owner-linux-xfs@oss.sgi.com Mon Oct 1 11:45:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f91Ijnb24505 for linux-xfs-outgoing; Mon, 1 Oct 2001 11:45:49 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f91IjjD24486 for ; Mon, 1 Oct 2001 11:45:45 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA09051 for ; Mon, 1 Oct 2001 11:44:37 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA3116315; Mon, 1 Oct 2001 13:44:28 -0500 (CDT) Received: from sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA25275; Mon, 1 Oct 2001 13:44:27 -0500 (CDT) Message-ID: <3BB8B8E9.1CD4A095@sgi.com> Date: Mon, 01 Oct 2001 13:41:46 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.8-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Ray Muno CC: linux-xfs@oss.sgi.com Subject: Re: Bad permissions with SGI XFS 1.01 Redhat 7.1 install References: <20011001112251.A21559@aem.umn.edu> <20011001113717.P10348@sgi.com> <20011001132323.E24742@aem.umn.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ray Muno wrote: > > Thanks, three replies in very short order. > > I ran the fix-perms script and that is fine. > > I am a little confused about the updates disk. I am using kickstart to > do the installs. How do I incorporate the update floppy in to that > procedure? I boot from the SGI XFS 1.01 install CD and do a "linux ks". I think you can add the fix-perms script to run in the post-install section of the kickstart? > If this is truly a problem with the underlying kernel, will it cause > problems beyond install time? I see that Redhat explicitly sets umask > to 022 in /etc/rc.d/init.d/functions and calls that in the init scripts. > Is there a danger of other things running as root creating files that > are mode 666? Is there a kernel patch to fix the problem for the running > machines. Since the umask is explicitly set on a normal bootup, you shouldn't run into problems down the line. The installer was not doing this, so files created during the install had the wrong perms. The bug was fixed in 2.4.7-pre7, I'm not sure where the fix was or where a patch might be. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Oct 1 12:02:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f91J2W725150 for linux-xfs-outgoing; Mon, 1 Oct 2001 12:02:32 -0700 Received: from ned.crphq.org (fwuser@host194.crp.org [64.242.225.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f91J2UD25130 for ; Mon, 1 Oct 2001 12:02:30 -0700 Received: from W30-GX150 (64.242.225.217) by ned.crphq.org (Worldmail 1.3.167); 1 Oct 2001 15:02:26 -0400 Message-Id: <4.2.0.58.20011001145958.020c4028@mail> X-Sender: X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 01 Oct 2001 15:02:13 -0400 To: Ray Muno From: Ryan Casey Subject: Re: Bad permissions with SGI XFS 1.01 Redhat 7.1 install Cc: linux-xfs@oss.sgi.com In-Reply-To: <20011001132323.E24742@aem.umn.edu> References: <20011001113717.P10348@sgi.com> <20011001112251.A21559@aem.umn.edu> <20011001113717.P10348@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 01:23 PM 10/1/2001 -0500, Ray Muno wrote: >I am a little confused about the updates disk. I am using kickstart to >do the installs. How do I incorporate the update floppy in to that >procedure? I boot from the SGI XFS 1.01 install CD and do a "linux ks". I believe "linux updates ks" or "linux ks updates" will work, you should be prompted to enter the updates disk at the beginning of the process. I know I've done kickstart with the update disk, and I think that was the command I used... -Ryan Casey From owner-linux-xfs@oss.sgi.com Mon Oct 1 12:03:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f91J3C025305 for linux-xfs-outgoing; Mon, 1 Oct 2001 12:03:12 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f91J39D25285 for ; Mon, 1 Oct 2001 12:03:09 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f91J33L25867 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Mon, 1 Oct 2001 12:03:03 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA09669 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Mon, 1 Oct 2001 12:03:02 -0700 (PDT) Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id VAA1540673 for ; Mon, 1 Oct 2001 21:03:09 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA2903612 for ; Mon, 1 Oct 2001 14:01:44 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA96115 for ; Mon, 1 Oct 2001 14:01:44 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id f91J10907325; Mon, 1 Oct 2001 14:01:00 -0500 Message-Id: <200110011901.f91J10907325@jen.americas.sgi.com> Date: Mon, 1 Oct 2001 14:01:00 -0500 Subject: TAKE - fix a hang in parallel copies & dbench Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk A massively parallel copy, and some users of dbench reported a hung machine with xfs. Tracked this down to a memory allocation causing reentry to xfs - from within a transaction which will eventually deadlock. Fixing this required some core kernel changes, but they are minor and do not affect the code executed for other filesystems at all. Date: Mon Oct 1 11:59:24 PDT 2001 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:103688a linux/kernel/ksyms.c - 1.111 - export icreate instead of icreate4 linux/include/linux/fs.h - 1.121 - Remove icreate4, change prototype for icreate to include a gfp_mask linux/fs/inode.c - 1.54 - Allow allocate_inode to take a gfp_mask so XFS can tell it not to call back into the filesystem. Fold icreate4 and icreate into one function - we never use the extra arguments. Add the grp_mask to the icreate call, and use GFP_KERNEL from the iget call. linux/fs/xfs/xfs_iget.c - 1.148 - Pass SLAB_KERNEL or SLAB_NOFS into icreate depending on being in a transaction or not. linux/fs/xfs/linux/xfs_vnode.c - 1.67 - Call icreate with a gfp_mask argument From owner-linux-xfs@oss.sgi.com Mon Oct 1 12:21:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f91JLr926545 for linux-xfs-outgoing; Mon, 1 Oct 2001 12:21:53 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f91JLoD26524 for ; Mon, 1 Oct 2001 12:21:50 -0700 Received: from crom.corp.sgi.com (crom.corp.sgi.com [130.62.63.32]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA08805 for ; Mon, 1 Oct 2001 12:20:42 -0700 (PDT) mail_from (florin@sgi.com) Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.175.86]) by crom.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA28498 for ; Mon, 1 Oct 2001 12:27:20 -0700 (PDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id ADE5415A218 for ; Mon, 1 Oct 2001 12:19:04 -0700 (PDT) Subject: 2.4.9 is bad From: Florin Andrei To: linux-xfs Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.14 (Preview Release) Date: 01 Oct 2001 12:19:04 -0700 Message-Id: <1001963944.21818.32.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Looks like there are some serious problems with 2.4.9 This is what i get from a system running XFS-1.0.1 on linux-2.4.9, RAID hardware (DAC960): xfs_force_shutdown(dac960(48,4),0x8) called from line 4072 of file xfs_bmap.c. Return address = 0xc01b8b9c Corruption of in-memory data detected. Shutting down filesystem: dac960(48,4) Please umount the filesystem, and rectify the problem(s) I saw this at least twice on this system. Anyone knows if 2.4.10 fixes these problems? -- Florin Andrei "This is a Klingon." "Where did it came from?" "Oklahoma." (from Star Trek Enterprise series premiere) From owner-linux-xfs@oss.sgi.com Mon Oct 1 12:22:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f91JMvq26729 for linux-xfs-outgoing; Mon, 1 Oct 2001 12:22:57 -0700 Received: from mail.aem.umn.edu (mail.aem.umn.edu [128.101.142.239]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f91JMqD26707 for ; Mon, 1 Oct 2001 12:22:52 -0700 Received: from lightning.aem.umn.edu (lightning.aem.umn.edu [128.101.143.49]) by mail.aem.umn.edu (8.9.3/8.9.3) with ESMTP id OAA51300 for ; Mon, 1 Oct 2001 14:22:47 -0500 (CDT) (envelope-from muno@aem.umn.edu) Received: (from muno@localhost) by lightning.aem.umn.edu (8.11.2/8.9.1) id f91JMOK25358 for linux-xfs@oss.sgi.com; Mon, 1 Oct 2001 14:22:24 -0500 Date: Mon, 1 Oct 2001 14:22:24 -0500 From: Ray Muno To: linux-xfs@oss.sgi.com Subject: Re: Bad permissions with SGI XFS 1.01 Redhat 7.1 install Message-ID: <20011001142223.G24742@aem.umn.edu> References: <20011001112251.A21559@aem.umn.edu> <20011001113717.P10348@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011001113717.P10348@sgi.com> User-Agent: Mutt/1.3.19-current-20010622i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ray Muno wrote: > > Thanks, three replies in very short order. > > I ran the fix-perms script and that is fine. > > I am a little confused about the updates disk. I am using kickstart to > do the installs. How do I incorporate the update floppy in to that > procedure? I boot from the SGI XFS 1.01 install CD and do a "linux ks". I think you can add the fix-perms script to run in the post-install section of the kickstart? > If this is truly a problem with the underlying kernel, will it cause > problems beyond install time? I see that Redhat explicitly sets umask > to 022 in /etc/rc.d/init.d/functions and calls that in the init scripts. > Is there a danger of other things running as root creating files that > are mode 666? Is there a kernel patch to fix the problem for the running > machines. Since the umask is explicitly set on a normal bootup, you shouldn't run into problems down the line. The installer was not doing this, so files created during the install had the wrong perms. The bug was fixed in 2.4.7-pre7, I'm not sure where the fix was or where a patch might be. -Eric ---- We ran a test program out of xinetd that just touched a file in /tmp. The file that was created was mode 666. We tested this on an Debian 2.2 machine, 2.2.17 kernel, and the file was 644. It seems clear that this is a big issue for things that are not explicitly run from init.d. ============================================================================= 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 Mon Oct 1 12:29:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f91JTwV27053 for linux-xfs-outgoing; Mon, 1 Oct 2001 12:29:58 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f91JTuD27033 for ; Mon, 1 Oct 2001 12:29:56 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f91JToL28623 for ; Mon, 1 Oct 2001 12:29:50 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA3116755; Mon, 1 Oct 2001 14:28:34 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA45814; Mon, 1 Oct 2001 14:28:34 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f91JRor07404; Mon, 1 Oct 2001 14:27:50 -0500 Message-Id: <200110011927.f91JRor07404@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Ray Muno cc: linux-xfs@oss.sgi.com Subject: Re: Bad permissions with SGI XFS 1.01 Redhat 7.1 install In-Reply-To: Message from Ray Muno of "Mon, 01 Oct 2001 14:22:24 CDT." <20011001142223.G24742@aem.umn.edu> Date: Mon, 01 Oct 2001 14:27:50 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > We ran a test program out of xinetd that just touched a file in /tmp. > The file that was created was mode 666. We tested this on an Debian 2.2 > machine, 2.2.17 kernel, and the file was 644. It seems clear that this is > a big issue for things that are not explicitly run from init.d. Really the only answer for to this is to upgrade to a later kernel than the one packaged. We do not really have the bandwidth to repackage with a different kernel. Steve > > ============================================================================= > > 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 Mon Oct 1 12:48:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f91Jm9P27842 for linux-xfs-outgoing; Mon, 1 Oct 2001 12:48:09 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f91Jm6D27822 for ; Mon, 1 Oct 2001 12:48:06 -0700 Received: from crom.corp.sgi.com (crom.corp.sgi.com [130.62.63.32]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA01200 for ; Mon, 1 Oct 2001 12:46:59 -0700 (PDT) mail_from (florin@sgi.com) Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.175.86]) by crom.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA04083 for ; Mon, 1 Oct 2001 12:53:37 -0700 (PDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 7101915A218 for ; Mon, 1 Oct 2001 12:46:50 -0700 (PDT) Subject: Re: 2.4.9 is bad From: Florin Andrei To: linux-xfs In-Reply-To: <1001963944.21818.32.camel@stantz.corp.sgi.com> References: <1001963944.21818.32.camel@stantz.corp.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.14 (Preview Release) Date: 01 Oct 2001 12:46:50 -0700 Message-Id: <1001965610.21903.44.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2001-10-01 at 12:19, Florin Andrei wrote: > > I saw this at least twice on this system. > Anyone knows if 2.4.10 fixes these problems? Apparently, a friend of mine gets all kind of "attempting to kill init" stuff with 2.4.10 (and reiserfs, but that's ok). Looks like it's time to go back to older kernels for production machines. :o) -- Florin Andrei "This is a Klingon." "Where did it came from?" "Oklahoma." (from Star Trek Enterprise series premiere) From owner-linux-xfs@oss.sgi.com Mon Oct 1 13:01:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f91K1ER28657 for linux-xfs-outgoing; Mon, 1 Oct 2001 13:01:14 -0700 Received: from homer.mkintl.com (cloven-ext.nks.net [216.139.204.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f91K1AD28635 for ; Mon, 1 Oct 2001 13:01:10 -0700 Received: from illusionary.com (two.nks.net [192.168.1.22]) by homer.mkintl.com (8.9.3/8.9.3) with ESMTP id QAA29168 for ; Mon, 1 Oct 2001 16:01:04 -0400 Message-ID: <3BB8CB80.EA37C769@illusionary.com> Date: Mon, 01 Oct 2001 16:01:04 -0400 From: Derek Glidden X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.10-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: 2.4.9 is bad References: <1001963944.21818.32.camel@stantz.corp.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Florin Andrei wrote: > > Looks like there are some serious problems with 2.4.9 > This is what i get from a system running XFS-1.0.1 on linux-2.4.9, RAID > hardware (DAC960): > > xfs_force_shutdown(dac960(48,4),0x8) called from line 4072 of file > xfs_bmap.c. Return address = 0xc01b8b9c > Corruption of in-memory data detected. Shutting down filesystem: > dac960(48,4) > Please umount the filesystem, and rectify the problem(s) > > I saw this at least twice on this system. > Anyone knows if 2.4.10 fixes these problems? We've seen this same error a couple of times on an Athlon box using several big IDE hard drives with software RAID0 during heavy activity. The box has some other problems, though, so we haven't redeployed it yet with 2.4.10 on it, but that's the next step for us. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- #!/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/ http://www.sciencemag.org/cgi/content/full/293/5537/2028 From owner-linux-xfs@oss.sgi.com Mon Oct 1 14:25:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f91LPmS30555 for linux-xfs-outgoing; Mon, 1 Oct 2001 14:25:48 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f91LPkD30536 for ; Mon, 1 Oct 2001 14:25:46 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f91LPeL07877 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Mon, 1 Oct 2001 14:25:40 -0700 Received: from clink-eth.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id XAA1544677 for ; Mon, 1 Oct 2001 23:24:31 +0200 (CEST) mail_from (roehrich@clink-eth.americas.sgi.com) Received: (from roehrich@localhost) by clink-eth.americas.sgi.com (SGI-8.9.3/8.9.3) id QAA32435 for linux-xfs@oss.sgi.com; Mon, 1 Oct 2001 16:24:16 -0500 (CDT) Date: Mon, 1 Oct 2001 16:24:16 -0500 (CDT) From: Dean Roehrich Message-Id: <200110012124.QAA32435@clink-eth.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - Allow dmapi mounts to work again Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Oct 1 14:23:03 PDT 2001 Workarea: clink-eth.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:103709a linux/fs/super.c - 1.57 - Allow dmapi mounts to work again. From owner-linux-xfs@oss.sgi.com Mon Oct 1 14:42:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f91LgrI31094 for linux-xfs-outgoing; Mon, 1 Oct 2001 14:42:53 -0700 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f91LgpD31075 for ; Mon, 1 Oct 2001 14:42:51 -0700 Received: from clink-eth.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f91LgjK09891 for ; Mon, 1 Oct 2001 14:42:45 -0700 Received: (from roehrich@localhost) by clink-eth.americas.sgi.com (SGI-8.9.3/8.9.3) id QAA37459 for linux-xfs@oss.sgi.com; Mon, 1 Oct 2001 16:41:26 -0500 (CDT) Date: Mon, 1 Oct 2001 16:41:26 -0500 (CDT) From: Dean Roehrich Message-Id: <200110012141.QAA37459@clink-eth.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - Fix some dmapi tests Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Add fixes from Takayuki Sasaki Date: Mon Oct 1 14:39:50 PDT 2001 Workarea: clink-eth.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:103715a cmd/xfstests/dmapi/src/sample_hsm/migout.c - 1.3 - use atohan properly cmd/xfstests/dmapi/src/sample_hsm/wbee.c - 1.3 - fix region handling cmd/xfstests/dmapi/src/sample_hsm/print_event.c - 1.3 - remove--superceded by suite1/cmd/print_event.c cmd/xfstests/dmapi/src/sample_hsm/migin.c - 1.3 - call mk_daemon from a different place so we don't close the dmapi device. From owner-linux-xfs@oss.sgi.com Mon Oct 1 16:04:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f91N4LG32712 for linux-xfs-outgoing; Mon, 1 Oct 2001 16:04:21 -0700 Received: from thor.goeci.com (thor.goeci.com [216.181.40.16]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f91N4ID32693 for ; Mon, 1 Oct 2001 16:04:18 -0700 Received: by THOR with Internet Mail Service (5.5.2650.21) id <4BW5Q3CD>; Mon, 1 Oct 2001 19:04:13 -0400 Message-ID: From: Murthy Kambhampaty To: "'Florin Andrei'" , linux-xfs Subject: RE: 2.4.9 is bad Date: Mon, 1 Oct 2001 19:04:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Monday, October 01, 2001 15:47, Florin Andrei wrote: > Apparently, a friend of mine gets all kind of "attempting to > kill init" > stuff with 2.4.10 (and reiserfs, but that's ok). > Looks like it's time to go back to older kernels for production > machines. :o) > I've been running the 2.4.10 kernel with XFS 1.0.1 patches on a test system for a couple of days, and no messages of any kind. Admittedly, it really just sits around as I have been busy with other stuff ... Also, it is a vanilla box - Dell Precision 210 with a single 9 GB SCSI disk on the internal adapter. Murthy From owner-linux-xfs@oss.sgi.com Mon Oct 1 17:38:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f920ctl01925 for linux-xfs-outgoing; Mon, 1 Oct 2001 17:38:55 -0700 Received: from a.mx.spoiled.org (babel.spoiled.org [217.13.197.48]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f920cZD01905 for ; Mon, 1 Oct 2001 17:38:35 -0700 Received: by a.mx.spoiled.org (Postfix, from userid 8) id 1C3D11195E; Tue, 2 Oct 2001 02:38:34 +0200 (CEST) From: thomas graichen Reply-To: thomas graichen X-Newsgroups: spoiled.linux.sgi.xfs Subject: Re: [uml-devel] uml with xfs support Date: Tue, 2 Oct 2001 02:30:02 +0200 Organization: spoiled dot org Lines: 252 Distribution: local Message-ID: References: <200110010354.WAA04600@ccure.karaya.com> Reply-To: thomas graichen X-Complaints-To: newsmaster@spoiled.org User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.10-xfs (i686)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk just because i also asked around here and it has something to do with xfs too i put it here too if someone is interested to run user-mode- linux with the xfs kernel (maybe useful for debugging too?) ... t thomas graichen wrote: > Jeff Dike wrote: >> So, it looks like gdb is sane and the value of physmem isn't. > that one brought me to the right direction: physmem really was wrong > due to my own change - i assumed that the physmem in uml and the one > from xfs are the same and thus declared one of them as external to > avoid the conflicting symbols while linking the kernel - but that > assumption was wrong - the physmem in xfs has nothing directly to do > with the physmem in uml - so we have some real namecollision between > those two projects here which have to be resolved somehow ... even > more: the eicon isdn driver in the kernel also seems to use physmem > for itself - i'll mail this posting to the three maintainers of the > respective projects to coordinate how to solve this in a clean way > (cc'ed to alan cox - maybe it would be a good idea to put this some- > where central into the kernel so that anyone who needs it may use it > if all those physmems are meaning the same - did not look very close > at it - because i think the name really calles for further trouble :-) > my solution so far was to rename the physmem of uml to uml_physmem > and a kernel build that way booted without any problems ... > # cat /proc/version > Linux version 2.4.9-xfs-8um (root@carbon.example.com) (gcc version > egcs-2.91.66 > 19990314/Linux (egcs-1.1.2 release / Linux-Mandrake 8.0)) #16 Mon Oct 1 > 22:02:24 CEST 2001 > # cat /proc/filesystems > nodev proc > nodev sockfs > nodev tmpfs > nodev pipefs > ext2 > nodev devfs > nodev devpts > xfs > # > ... and i assume it to work without problems now too - it's too late > now to try it out > ok here are the patches which made xfs and uml coexisting happy to- > gether - maybe someone else likes to have them and it would be nice > if they might in some way go into further uml releases (at least the > __clear_user addition to uaccess.h which is required for xfs) and > the conflicts regarding physmem will be solved ... > t > --- ./arch/um/include/user_util.h.physmem Mon Oct 1 21:06:01 2001 > +++ ./arch/um/include/user_util.h Mon Oct 1 21:06:36 2001 > @@ -32,7 +32,7 @@ > > extern unsigned long low_physmem; > extern unsigned long high_physmem; > -extern unsigned long physmem; > +extern unsigned long uml_physmem; > extern unsigned long end_vm; > extern unsigned long start_vm; > > --- ./arch/um/kernel/mem.c.physmem Mon Oct 1 21:12:39 2001 > +++ ./arch/um/kernel/mem.c Mon Oct 1 21:12:53 2001 > @@ -66,7 +66,7 @@ > for(i=0;i zones_size[i] = 0; > zones_size[1] = (high_physmem >> PAGE_SHIFT) - > - (physmem >> PAGE_SHIFT) - zones_size[0]; > + (uml_physmem >> PAGE_SHIFT) - zones_size[0]; > free_area_init(zones_size); > } > > --- ./arch/um/kernel/exec_kern.c.physmem Mon Oct 1 21:11:49 2001 > +++ ./arch/um/kernel/exec_kern.c Mon Oct 1 21:55:42 2001 > @@ -59,7 +59,7 @@ > > current->thread.extern_pid = new_pid; > free_page(stack); > - protect(physmem, high_physmem - physmem, 1, 1, 0); > + protect(uml_physmem, high_physmem - uml_physmem, 1, 1, 0); > task_protections((unsigned long) current); > force_flush_all(); > unblock_signals(); > --- ./arch/um/kernel/um_arch.c.physmem Mon Oct 1 21:15:13 2001 > +++ ./arch/um/kernel/um_arch.c Mon Oct 1 21:15:35 2001 > @@ -115,7 +115,7 @@ > #define START 0xa0000000 > #endif > > -unsigned long physmem; > +unsigned long uml_physmem; > > unsigned long start_vm; > unsigned long end_vm; > @@ -234,7 +234,7 @@ > remap_data(ROUND_DOWN(&__bss_start), ROUND_UP(brk_start)); > > /* Start physical memory at least 4M after the current brk */ > - physmem = ROUND_4M(brk_start) + (1 << 22); > + uml_physmem = ROUND_4M(brk_start) + (1 << 22); > > /* Create fake command line from argv[]. */ > have_root = 0; > @@ -299,7 +299,7 @@ > * of physical memory or the remaining space left in the kernel > * area of the address space, whichever is smaller. > */ > - start_vm = physmem + physmem_size + VMALLOC_OFFSET; > + start_vm = uml_physmem + physmem_size + VMALLOC_OFFSET; > if(start_vm >= get_kmem_end()) > panic("Physical memory too large to allow any kernel " > "virtual memory"); > @@ -313,16 +313,16 @@ > printk(KERN_INFO "Kernel virtual memory size shrunk to %ld " > "bytes\n", virtmem_size); > > - setup_range(-1, NULL, physmem, physmem_size, > + setup_range(-1, NULL, uml_physmem, physmem_size, > physmem_size + VMALLOC_OFFSET + virtmem_size); > setup_memory(); > - high_physmem = physmem + physmem_size; > + high_physmem = uml_physmem + physmem_size; > > - start_pfn = PFN_UP(__pa(physmem)); > + start_pfn = PFN_UP(__pa(uml_physmem)); > end_pfn = PFN_DOWN(__pa(high_physmem)); > bootmap_size = init_bootmem(start_pfn, end_pfn - start_pfn); > - free_bootmem(__pa(physmem) + bootmap_size, > - high_physmem - physmem - bootmap_size); > + free_bootmem(__pa(uml_physmem) + bootmap_size, > + high_physmem - uml_physmem - bootmap_size); > #ifdef CONFIG_BLK_DEV_INITRD > if(initrd != NULL) read_initrd(initrd); > #endif > --- ./arch/um/kernel/ksyms.c.physmem Mon Oct 1 21:12:09 2001 > +++ ./arch/um/kernel/ksyms.c Mon Oct 1 21:12:18 2001 > @@ -10,7 +10,7 @@ > > EXPORT_SYMBOL(stop); > EXPORT_SYMBOL(strtok); > -EXPORT_SYMBOL(physmem); > +EXPORT_SYMBOL(uml_physmem); > EXPORT_SYMBOL(current_task); > EXPORT_SYMBOL(set_signals); > EXPORT_SYMBOL(kernel_thread); > --- ./arch/um/kernel/process_kern.c.physmem Mon Oct 1 21:14:10 2001 > +++ ./arch/um/kernel/process_kern.c Mon Oct 1 21:14:14 2001 > @@ -521,7 +521,7 @@ > { > force_flush_all(); > if(current->mm != current->p_pptr->mm) > - protect(physmem, high_physmem - physmem, 1, 1, 0); > + protect(uml_physmem, high_physmem - uml_physmem, 1, 1, 0); > task_protections((unsigned long) current); > if(current->thread.request.u.fork_finish.from) > schedule_tail(current->thread.request.u.fork_finish.from); > @@ -748,7 +748,7 @@ > > start_stack = (unsigned long) current; > end_stack = start_stack + PAGE_SIZE * 4; > - protect(physmem, start_stack - physmem, 1, 1, 1); > + protect(uml_physmem, start_stack - uml_physmem, 1, 1, 1); > protect(end_stack, high_physmem - end_stack, 1, 1, 1); > } > > @@ -758,7 +758,7 @@ > > start_stack = (unsigned long) current; > end_stack = start_stack + PAGE_SIZE * 4; > - protect(physmem, start_stack - physmem, 1, 1, 1); > + protect(uml_physmem, start_stack - uml_physmem, 1, 1, 1); > protect(end_stack, high_physmem - end_stack, 1, 1, 1); > } > > --- ./include/asm-um/dma.h.physmem Mon Oct 1 21:07:05 2001 > +++ ./include/asm-um/dma.h Mon Oct 1 21:30:45 2001 > @@ -5,6 +5,6 @@ > > #undef MAX_DMA_ADDRESS > > -#define MAX_DMA_ADDRESS (physmem) > +#define MAX_DMA_ADDRESS (uml_physmem) > > #endif > --- ./include/asm-um/page.h.physmem Mon Oct 1 21:08:01 2001 > +++ ./include/asm-um/page.h Mon Oct 1 21:08:37 2001 > @@ -28,14 +28,14 @@ > > #endif /* __ASSEMBLY__ */ > > -extern unsigned long physmem; > +extern unsigned long uml_physmem; > > -#define PAGE_OFFSET (physmem) > +#define PAGE_OFFSET (uml_physmem) > > #define __va_space (8*1024*1024) > > -#define __pa(x) ((unsigned long) (x) - (physmem)) > -#define __va(x) ((void *) ((unsigned long) (x) + (physmem))) > +#define __pa(x) ((unsigned long) (x) - (uml_physmem)) > +#define __va(x) ((void *) ((unsigned long) (x) + (uml_physmem))) > > #define virt_to_page(kaddr) (mem_map + (__pa(kaddr) >> PAGE_SHIFT)) > #define VALID_PAGE(page) ((page - mem_map) < max_mapnr) > --- ./include/asm-um/uaccess.h.physmem Tue Oct 2 01:15:50 2001 > +++ ./include/asm-um/uaccess.h Mon Oct 1 21:30:43 2001 > @@ -35,7 +35,7 @@ > #define set_fs(x) (current->addr_limit = (x)) > > extern unsigned long end_vm; > -extern unsigned long physmem; > +extern unsigned long uml_physmem; > > #define under_task_size(addr, size) \ > (((unsigned long) (addr) < TASK_SIZE) && \ > @@ -146,6 +146,14 @@ > void **fault_catcher); > > static inline int clear_user(void *mem, int len) > +{ > + return(access_ok(VERIFY_WRITE, mem, len) ? > + __do_clear_user(mem, len, > + ¤t->thread.fault_addr, > + ¤t->thread.fault_catcher) : len); > +} > + > +static inline int __clear_user(void *mem, int len) > { > return(access_ok(VERIFY_WRITE, mem, len) ? > __do_clear_user(mem, len, > -- > thomas graichen ... perfection is reached, not > when there is no longer anything to add, but when there is no > longer anything to take away. --- antoine de saint-exupery > _______________________________________________ > User-mode-linux-devel mailing list > User-mode-linux-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel -- thomas graichen ... perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. --- antoine de saint-exupery From owner-linux-xfs@oss.sgi.com Mon Oct 1 19:51:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f922p6O04323 for linux-xfs-outgoing; Mon, 1 Oct 2001 19:51:06 -0700 Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.121.49]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f922p2D04301 for ; Mon, 1 Oct 2001 19:51:02 -0700 Received: from dhcp10 (static031-81-151-24.nm01-c3.cpe.charter-ne.com [24.151.81.31]) by scaup.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id TAA26221; Mon, 1 Oct 2001 19:50:39 -0700 (PDT) Message-ID: <013301c14aec$d7573b00$0a00a8c0@intranet.mp3s.com> Reply-To: "Sean Elble" From: "Sean Elble" To: "Steve Lord" Cc: References: <200110011402.f91E25O06650@jen.americas.sgi.com> Subject: Re: IRIX 6.5.6m/XFS CVS: Any problems? Date: Mon, 1 Oct 2001 22:49:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve, Can I upgrade from the SGI web site? I know I can download the 6.5.13 files (900 or so MB), but, will this work OK? I am already in the maintaince stream, so I won't have that damn "stream switch" problem. Now if I could only get some IRIX media from SGI without paying $600.00! No offense to you guys, or SGI, as they have done a _lot_ for the Linux community, but $600? Come on! Anyway, thanks for the reply; I'll certainly take your advice into consideration? BTW - Are there any major disadvantages to using NFS v2? ----- Original Message ----- From: "Steve Lord" To: "Sean Elble" Cc: Sent: Monday, October 01, 2001 10:02 AM Subject: Re: IRIX 6.5.6m/XFS CVS: Any problems? > > Hello, > > > > I have a Silicon Graphics Indigo2 here with IRIX > > 6.5.6m installed (love it, BTW), and a Linux server > > that is about to have the latest CVS version of the > > XFS kernel installed, along with the kernel-level NFS > > server. > > > > Are there any known problems, or catches, using NFS on > > IRIX with a Linux 2.4.10 server? I would like to use > > NFS3, if possible, but I would appreciate any comments > > any users may have. Thanks, in advance! > > > > You may want to upgrade to the latest Irix release, there were some > problems with NFS V3 between Linux and Irix. The Irix implementation > expected the NFS file handles to be of a specific size, and Linux used > a different size. I think this is fixed in 6.5.13. This only affected > V3 NFS I think. > > Steve > From owner-linux-xfs@oss.sgi.com Mon Oct 1 19:53:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f922rON04420 for linux-xfs-outgoing; Mon, 1 Oct 2001 19:53:24 -0700 Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.121.49]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f922rJD04399 for ; Mon, 1 Oct 2001 19:53:20 -0700 Received: from dhcp10 (static031-81-151-24.nm01-c3.cpe.charter-ne.com [24.151.81.31]) by scaup.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id TAA08591; Mon, 1 Oct 2001 19:53:16 -0700 (PDT) Message-ID: <014601c14aed$34616ff0$0a00a8c0@intranet.mp3s.com> Reply-To: "Sean Elble" From: "Sean Elble" To: "Utz Lehmann" Cc: References: <200110011402.f91E25O06650@jen.americas.sgi.com> <20011001163121.D15188@de.tecosim.com> Subject: Re: IRIX 6.5.6m/XFS CVS: Any problems? Date: Mon, 1 Oct 2001 22:51:57 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Utz, Thanks for the information; do you know if this patch needs to be applied for NFS v3 to work from IRIX to Linux? It looks really easy to apply manually if it doesn't apply automatically . . . I've been wrong before though. :-) Thanks again! -Sean ----- Original Message ----- From: "Utz Lehmann" To: "Steve Lord" Cc: "Sean Elble" ; Sent: Monday, October 01, 2001 10:31 AM Subject: Re: IRIX 6.5.6m/XFS CVS: Any problems? > Hi > > Steve Lord [lord@sgi.com] wrote: > > > Hello, > > > > > > I have a Silicon Graphics Indigo2 here with IRIX > > > 6.5.6m installed (love it, BTW), and a Linux server > > > that is about to have the latest CVS version of the > > > XFS kernel installed, along with the kernel-level NFS > > > server. > > > > > > Are there any known problems, or catches, using NFS on > > > IRIX with a Linux 2.4.10 server? I would like to use > > > NFS3, if possible, but I would appreciate any comments > > > any users may have. Thanks, in advance! > > > > > > > You may want to upgrade to the latest Irix release, there were some > > problems with NFS V3 between Linux and Irix. The Irix implementation > > expected the NFS file handles to be of a specific size, and Linux used > > a different size. I think this is fixed in 6.5.13. This only affected > > V3 NFS I think. > > > > Steve > > I had grabed a small patch for the linux nfs server on lkml. It's set the > file handle size on the linux nfs server to a value (older) IRIX Versions > (and HP-UX 10.20) can understand. I have used this patch till 2.4.9. Maybe > it works with 2.4.10 too. > It works for me, but use it at your own risk. > > Or use NFS v2. > > > utz > From owner-linux-xfs@oss.sgi.com Mon Oct 1 20:07:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9237NG04807 for linux-xfs-outgoing; Mon, 1 Oct 2001 20:07:23 -0700 Received: from mail.tahsda.org.tw (c252.h203149202.is.net.tw [203.149.202.252]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9237ID04779 for ; Mon, 1 Oct 2001 20:07:18 -0700 Received: from mail.teatime.com.tw (localhost [127.0.0.1]) by mail.tahsda.org.tw (8.8.8+Sun/8.8.8) with SMTP id LAA25056; Tue, 2 Oct 2001 11:06:29 +0800 (CST) Received: from local_139.168.120.8 ([139.168.120.8]) by mail (TeaTime Mail Server 0.6.1) with SMTP id spool/smaIIaW4W for ; Tue, 2 Oct 01 11:06:17 +0800 Date: Tue, 02 Oct 2001 11:06:17 +0800 From: Tommy Wu To: Florin Andrei Subject: Re: 2.4.9 is bad Cc: linux-xfs Reply-To: tommy@teatime.com.tw Organization: TeaTime Development In-Reply-To: <1001965610.21903.44.camel@stantz.corp.sgi.com> References: <1001963944.21818.32.camel@stantz.corp.sgi.com> <1001965610.21903.44.camel@stantz.corp.sgi.com> Message-Id: <20011002110216.26DF.NEWSLETTER@teatime.com.tw> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.07 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Florin Andrei wrote: > > I saw this at least twice on this system. > > Anyone knows if 2.4.10 fixes these problems? I also got the same message in here.... 3 times in yesterday night :-( 2.4.10 has some other problem in VM.... it will freeze my linux (deadlock). I've tried the vm-tweak patch and linus's deadlock patch... but it seem no work here (for SMP, HIGHMEM linux). > Looks like it's time to go back to older kernels for production > machines. :o) So... do you know which version of kernel is stable with XFS now ? -- Tommy Wu mailto:tommy@teatime.com.tw http://www.teatime.com.tw/~tommy ICQ: 22766091 Mobile Phone: +886 936 909490 TeaTime BBS +886 2 31515964 24Hrs V.Everything From owner-linux-xfs@oss.sgi.com Mon Oct 1 22:57:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f925vX307153 for linux-xfs-outgoing; Mon, 1 Oct 2001 22:57:33 -0700 Received: from porgy.srv.nld.sonera.net (mbox-01.soneraplaza.nl [195.66.15.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f925vVD07134 for ; Mon, 1 Oct 2001 22:57:31 -0700 Received: from qn-213-73-192-55.quicknet.nl ([213.73.192.55]:62506 "EHLO et.schoenmakerstraat.org") by soneramail.nl with ESMTP id ; Tue, 2 Oct 2001 07:57:21 +0200 Received: from localhost ([127.0.0.1] helo=dds.nl) by et.schoenmakerstraat.org with esmtp (Exim 3.12 #1 (Debian)) id 15oIa2-0000La-00 for ; Tue, 02 Oct 2001 07:58:58 +0200 Message-ID: <3BB957A2.E1DB930E@dds.nl> Date: Tue, 02 Oct 2001 07:58:58 +0200 From: Ries van twisk Reply-To: rvt@dds.nl X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9 i586) X-Accept-Language: en MIME-Version: 1.0 CC: linux-xfs Subject: Re: 2.4.9 is bad References: Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have 2.4.9 installaed on a vaniella Linux kernel with XFS and it works perfectly. I must say that the machine is my internet gateway and fileserver but is not to buzy. Ries From owner-linux-xfs@oss.sgi.com Tue Oct 2 00:02:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9272Er08206 for linux-xfs-outgoing; Tue, 2 Oct 2001 00:02:14 -0700 Received: from mail.tahsda.org.tw (c252.h203149202.is.net.tw [203.149.202.252]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f92728D08182 for ; Tue, 2 Oct 2001 00:02:09 -0700 Received: from mail.teatime.com.tw (localhost [127.0.0.1]) by mail.tahsda.org.tw (8.8.8+Sun/8.8.8) with SMTP id OAA06348; Tue, 2 Oct 2001 14:58:18 +0800 (CST) Received: from local_139.168.120.8 ([139.168.120.8]) by mail (TeaTime Mail Server 0.6.1) with SMTP id spool/smaLoaiwm for ; Tue, 2 Oct 01 14:58:05 +0800 Date: Tue, 02 Oct 2001 14:58:05 +0800 From: Tommy Wu To: rvt@dds.nl Subject: Re: 2.4.9 is bad Cc: linux-xfs Reply-To: tommy@teatime.com.tw Organization: TeaTime Development In-Reply-To: <3BB957A2.E1DB930E@dds.nl> References: <3BB957A2.E1DB930E@dds.nl> Message-Id: <20011002145755.26E7.NEWSLETTER@teatime.com.tw> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.07 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ries van twisk wrote: > I have 2.4.9 installaed on a vaniella Linux kernel with XFS and it works > perfectly. I must say that the machine is my internet gateway and > fileserver but is not to buzy. Here are 6 machine running 2.4.9-xfs..., 5 in my office, 1 in my home.. in office: 1 for firewall, 1 p2-233 cpu, 192m ram.... 1 for samba server, 1 p2-300 cpu 192m ram... 1 for samba server, 1 p-75 cpu 128m ram... and 2 for oracle server, 2 p3-1G cpu, 2g ram... in my home: 1 for firewall, samba server. , 2 p-233 cpu, 256m ram.... Only in the 2 machine with 2 * p3-1g cpu and 2g ram have such problem... So I think this problem should be some VM problem with SMP and HIGHMEM enabled. -- Tommy Wu mailto:tommy@teatime.com.tw http://www.teatime.com.tw/~tommy ICQ: 22766091 Mobile Phone: +886 936 909490 TeaTime BBS +886 2 31515964 24Hrs V.Everything From owner-linux-xfs@oss.sgi.com Tue Oct 2 01:26:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f928QxH09748 for linux-xfs-outgoing; Tue, 2 Oct 2001 01:26:59 -0700 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f928QuD09729 for ; Tue, 2 Oct 2001 01:26:56 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f928QoK23159 for ; Tue, 2 Oct 2001 01:26:51 -0700 Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id SAA30507; Tue, 2 Oct 2001 18:26:40 +1000 Date: Tue, 2 Oct 2001 18:26:40 +1000 From: Keith Owens Message-Id: <200110020826.SAA30507@sherman.melbourne.sgi.com> Subject: TAKE - Sync with current kdb, correct xfs warnings Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sync with current kdb, correct xfs warnings Date: Tue Oct 2 01:24:32 PDT 2001 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:103752a linux/include/linux/sysctl.h - 1.39 linux/fs/super.c - 1.58 linux/fs/xfs/xfs_log_recover.c - 1.213 linux/kdb/modules/kdbm_vm.c - 1.14 linux/include/linux/kdbprivate.h - 1.13 linux/kdb/kdbmain.c - 1.22 linux/kdb/kdb_io.c - 1.10 linux/include/asm-i386/kdbprivate.h - 1.12 linux/arch/i386/kdb/kdbasupport.c - 1.17 linux/include/asm-ia64/kdb.h - 1.4 linux/kdb/ChangeLog - 1.8 linux/include/asm-ia64/kdbprivate.h - 1.2 From owner-linux-xfs@oss.sgi.com Tue Oct 2 05:41:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f92CfAO14111 for linux-xfs-outgoing; Tue, 2 Oct 2001 05:41:10 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f92Cf4D14089 for ; Tue, 2 Oct 2001 05:41:04 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id FAA03021 for ; Tue, 2 Oct 2001 05:39:57 -0700 (PDT) mail_from (tbd@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id HAA3119694; Tue, 2 Oct 2001 07:39:47 -0500 (CDT) Received: from fsgi158.americas.sgi.com (fsgi158.americas.sgi.com [128.162.191.39]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id HAA71593; Tue, 2 Oct 2001 07:39:46 -0500 (CDT) From: Tad Dolphay Received: by fsgi158.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) id HAA17289; Tue, 2 Oct 2001 07:39:46 -0500 (CDT) Message-Id: <200110021239.HAA17289@fsgi158.americas.sgi.com> Subject: Re: IRIX 6.5.6m/XFS CVS: Any problems? To: S_Elble@yahoo.com Date: Tue, 2 Oct 2001 07:39:45 -0500 (CDT) Cc: ulehmann@de.tecosim.com (Utz Lehmann), linux-xfs@oss.sgi.com In-Reply-To: <014601c14aed$34616ff0$0a00a8c0@intranet.mp3s.com> from "Sean Elble" at Oct 01, 2001 10:51:57 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > Utz, > > Thanks for the information; do you know if this patch needs to be applied > for NFS v3 to work from IRIX to Linux? It looks really easy to apply For the most part NFS V3 will still work using a pre 6.5.13 IRIX client and 2.4 linux server. The problem is that sometimes when doing a pwd on a NFS mounted directory you won't see the entire path name. Tad > manually if it doesn't apply automatically . . . I've been wrong before > though. :-) Thanks again! > > -Sean > ----- Original Message ----- > From: "Utz Lehmann" > To: "Steve Lord" > Cc: "Sean Elble" ; > Sent: Monday, October 01, 2001 10:31 AM > Subject: Re: IRIX 6.5.6m/XFS CVS: Any problems? > > > > Hi > > > > Steve Lord [lord@sgi.com] wrote: > > > > Hello, > > > > > > > > I have a Silicon Graphics Indigo2 here with IRIX > > > > 6.5.6m installed (love it, BTW), and a Linux server > > > > that is about to have the latest CVS version of the > > > > XFS kernel installed, along with the kernel-level NFS > > > > server. > > > > > > > > Are there any known problems, or catches, using NFS on > > > > IRIX with a Linux 2.4.10 server? I would like to use > > > > NFS3, if possible, but I would appreciate any comments > > > > any users may have. Thanks, in advance! > > > > > > > > > > You may want to upgrade to the latest Irix release, there were some > > > problems with NFS V3 between Linux and Irix. The Irix implementation > > > expected the NFS file handles to be of a specific size, and Linux used > > > a different size. I think this is fixed in 6.5.13. This only affected > > > V3 NFS I think. > > > > > > Steve > > > > I had grabed a small patch for the linux nfs server on lkml. It's set the > > file handle size on the linux nfs server to a value (older) IRIX Versions > > (and HP-UX 10.20) can understand. I have used this patch till 2.4.9. Maybe > > it works with 2.4.10 too. > > It works for me, but use it at your own risk. > > > > Or use NFS v2. > > > > > > utz > > > From owner-linux-xfs@oss.sgi.com Tue Oct 2 05:51:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f92CpG414408 for linux-xfs-outgoing; Tue, 2 Oct 2001 05:51:16 -0700 Received: from TYO202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.247.6.41]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f92CpBD14367 for ; Tue, 2 Oct 2001 05:51:12 -0700 Received: from mailgate4.nec.co.jp ([10.7.69.193]) by TYO202.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id f92CpAQ09677 for ; Tue, 2 Oct 2001 21:51:10 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id f92CpAw04361 for ; Tue, 2 Oct 2001 21:51:10 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (THKTNES98740.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id f92Cp9X15221 for ; Tue, 2 Oct 2001 21:51:09 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA424 for ; Tue, 2 Oct 2001 21:51:08 +0900 Received: FROM mailsv.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Tue Oct 02 21:51:06 2001 +0900 Received: from rifu.bsd.tnes.nec.co.jp (IDENT:root@rifu.bsd.tnes.nec.co.jp [10.1.101.142]) by mailsv.tnes.nec.co.jp (8.9.3/3.7W01031510) with ESMTP id VAA93574; Tue, 2 Oct 2001 21:51:07 +0900 (JST) Received: from tagajo.bsd.tnes.nec.co.jp (tagajo.bsd.tnes.nec.co.jp [10.1.101.146]) by rifu.bsd.tnes.nec.co.jp (8.10.2+3.3W/3.7W/BSD-TNES-MX01) with ESMTP id f92Cp7i30022; Tue, 2 Oct 2001 21:51:07 +0900 Received: (from sasaki@localhost) by tagajo.bsd.tnes.nec.co.jp (8.8.5+2.7Wbeta5/3.5Wpl1-97090809) id VAA08726; Tue, 2 Oct 2001 21:51:06 +0900 (JST) Message-Id: <200110021251.VAA08726@tagajo.bsd.tnes.nec.co.jp> To: Dean Roehrich cc: linux-xfs@oss.sgi.com Subject: Re: wbee (sample_hsm) dumped core In-reply-to: Your message of Mon, 01 Oct 2001 10:46:47 -0500. <200110011546.KAA27923@slobber.americas.sgi.com> Date: Tue, 02 Oct 2001 21:51:06 +0900 From: Takayuki Sasaki Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Dean, Dean Roehrich wrote: > I use the print_event in src/suite1/cmd/print_event.c. It looks like the > print_event in suite1 has a few extra pieces, and some changes in the > formatting. I guess I'm inclined to remove the one in sample_hsm. Most of > the stuff I use is in src/simple, src/common/cmd, and src/suite1, and I do > like to use sample_hsm/mls. I used a little src/common/cmd, sample_hsm, simple and suite2. suite1 had not been used yet because they have a lot of programs, and I have another job ;-/ It seems that the programs in suite2 such as test_dmattr, test_efault and test_fileattr were something wrong on my box, but it were tested several weeks ago and I forgot what was wrong... Therefore, I have to confirm them on the latest kernel when I can find the time. (snip) > and the rest of this jumble of test suites was making me dizzy. me too :) > If you're looking for more info on DMAPI you should dig around on: > http://www.opengroup.org/onlinepubs/9657099/toc.htm Thanks for the information and your work. Cheers, Takayuki From owner-linux-xfs@oss.sgi.com Tue Oct 2 05:51:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f92CpKB14425 for linux-xfs-outgoing; Tue, 2 Oct 2001 05:51:20 -0700 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f92CpAD14365 for ; Tue, 2 Oct 2001 05:51:10 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f92Cp5L27364 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Tue, 2 Oct 2001 05:51:05 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id FAA27686 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Tue, 2 Oct 2001 05:51:04 -0700 (PDT) Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id OAA1581773 for ; Tue, 2 Oct 2001 14:50:03 +0200 (CEST) mail_from (tbd@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id HAA3114213; Tue, 2 Oct 2001 07:49:45 -0500 (CDT) Received: from fsgi158.americas.sgi.com (fsgi158.americas.sgi.com [128.162.191.39]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id HAA63040; Tue, 2 Oct 2001 07:49:45 -0500 (CDT) From: Tad Dolphay Received: by fsgi158.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) id HAA17179; Tue, 2 Oct 2001 07:49:44 -0500 (CDT) Message-Id: <200110021249.HAA17179@fsgi158.americas.sgi.com> Subject: Re: IRIX 6.5.6m/XFS CVS: Any problems? To: S_Elble@yahoo.com Date: Tue, 2 Oct 2001 07:49:44 -0500 (CDT) Cc: lord@sgi.com (Steve Lord), linux-xfs@oss.sgi.com In-Reply-To: <013301c14aec$d7573b00$0a00a8c0@intranet.mp3s.com> from "Sean Elble" at Oct 01, 2001 10:49:16 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > Steve, > > Can I upgrade from the SGI web site? I know I can download the 6.5.13 files > (900 or so MB), but, will this work OK? I am already in the maintaince > stream, so I won't have that damn "stream switch" problem. > > Now if I could only get some IRIX media from SGI without paying $600.00! No > offense to you guys, or SGI, as they have done a _lot_ for the Linux > community, but $600? Come on! > > Anyway, thanks for the reply; I'll certainly take your advice into > consideration? > > BTW - Are there any major disadvantages to using NFS v2? Here's some of the the improvements to NFS V3: - 64 bit file offsets - safe asynchronous writes - readdirplus for faster directory lookups - larger default read/write sizes Tad > ----- Original Message ----- > From: "Steve Lord" > To: "Sean Elble" > Cc: > Sent: Monday, October 01, 2001 10:02 AM > Subject: Re: IRIX 6.5.6m/XFS CVS: Any problems? > > > > > Hello, > > > > > > I have a Silicon Graphics Indigo2 here with IRIX > > > 6.5.6m installed (love it, BTW), and a Linux server > > > that is about to have the latest CVS version of the > > > XFS kernel installed, along with the kernel-level NFS > > > server. > > > > > > Are there any known problems, or catches, using NFS on > > > IRIX with a Linux 2.4.10 server? I would like to use > > > NFS3, if possible, but I would appreciate any comments > > > any users may have. Thanks, in advance! > > > > > > > You may want to upgrade to the latest Irix release, there were some > > problems with NFS V3 between Linux and Irix. The Irix implementation > > expected the NFS file handles to be of a specific size, and Linux used > > a different size. I think this is fixed in 6.5.13. This only affected > > V3 NFS I think. > > > > Steve > > > From owner-linux-xfs@oss.sgi.com Tue Oct 2 06:18:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f92DIAd15047 for linux-xfs-outgoing; Tue, 2 Oct 2001 06:18:10 -0700 Received: from dmz.tecosim.de ([194.24.222.241]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f92DI5D15028 for ; Tue, 2 Oct 2001 06:18:06 -0700 Received: (from uucp@localhost) by dmz.tecosim.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) id f92DF6v32396; Tue, 2 Oct 2001 15:15:06 +0200 Received: from ns.tecosim.de(194.24.222.9) via SMTP by dmz.tecosim.de, id smtpdVOAzSV; Tue Oct 2 15:15:01 2001 Received: from donner.tecosim.de (donner.tecosim.de [194.24.222.109]) by ns.tecosim.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id f92DExb08342; Tue, 2 Oct 2001 15:14:59 +0200 Received: (from leh@localhost) by donner.tecosim.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) id f92DEx631302; Tue, 2 Oct 2001 15:14:59 +0200 Date: Tue, 2 Oct 2001 15:14:59 +0200 From: Utz Lehmann To: Tad Dolphay Cc: S_Elble@yahoo.com, linux-xfs@oss.sgi.com Subject: Re: IRIX 6.5.6m/XFS CVS: Any problems? Message-ID: <20011002151459.C16538@de.tecosim.com> References: <014601c14aed$34616ff0$0a00a8c0@intranet.mp3s.com> <200110021239.HAA17289@fsgi158.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <200110021239.HAA17289@fsgi158.americas.sgi.com>; from tbd@sgi.com on Tue, Oct 02, 2001 at 07:39:45AM -0500 X-Scanned-By: MIMEDefang 1.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Tad Dolphay [tbd@sgi.com] wrote: > > > > Utz, > > > > Thanks for the information; do you know if this patch needs to be applied > > for NFS v3 to work from IRIX to Linux? It looks really easy to apply > > For the most part NFS V3 will still work using a pre 6.5.13 IRIX client > and 2.4 linux server. The problem is that sometimes when doing a pwd on a > NFS mounted directory you won't see the entire path name. Yes, and the IRIX ftpd, Midnight Commander (mc), xemacs, ... are confused too. I just tested a 2.4.10 xfs kernel (with preempt patch, but _without_ the nfs patch i had attached in my last mail). It's seems to work. My ftpd and mc tests are ok. Tested with IRIX 6.5.3 and HP-UX 10.20. So you dont need the patch for 2.4.10. utz From owner-linux-xfs@oss.sgi.com Tue Oct 2 06:51:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f92Dp3G15903 for linux-xfs-outgoing; Tue, 2 Oct 2001 06:51:03 -0700 Received: from kendy.up.ac.za (kendy.up.ac.za [137.215.101.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f92DowD15884 for ; Tue, 2 Oct 2001 06:50:58 -0700 Received: from [137.215.95.15] (helo=mx1.up.ac.za) by kendy.up.ac.za with esmtp (Exim 3.15 #1) id 15oPvD-00036f-00; Tue, 02 Oct 2001 15:49:19 +0200 Received: from tzone.up.ac.za ([137.215.145.210] helo=it.up.ac.za) by mx1.up.ac.za with esmtp (Exim 3.15 #1) id 15oPvC-00006P-00; Tue, 02 Oct 2001 15:49:18 +0200 Message-ID: <3BB9C5DE.4456EC81@it.up.ac.za> Date: Tue, 02 Oct 2001 15:49:18 +0200 From: Paul Schutte X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.10-xfs-tzone i686) X-Accept-Language: en MIME-Version: 1.0 To: Florin Andrei CC: linux-xfs Subject: Re: 2.4.9 is bad References: <1001963944.21818.32.camel@stantz.corp.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanner: exiscan *15oPvC-00006P-00*mn8jCgTpznc* http://duncanthrax.net/exiscan/ X-Scanner: exiscan *15oPvD-00036f-00*jhNMOyOgqiM* http://duncanthrax.net/exiscan/ Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I am amazed that it worked. If I am correct, the XFS-1.0.1 was a patch against the 2.4.5 kernel. The VM changed a LOT in the linux kernel lately. XFS depends very heavely on the VM. The guys from SGI did a lot of work to adapt XFS for each of these kernels. My guess wil be that the XFS-1.0.1 VM implimentation is drasticly different from that in 2.4.9 and 2.4.10 and this combination will result in strange errors. I am using 2.4.10-pre9 (That was the last release that I have before yet another major VM change occured) on 5 different mail servers. All using XFS. All very stable. I would advice you to use the kernel from the cvs tree instead. Paul Florin Andrei wrote: > Looks like there are some serious problems with 2.4.9 > This is what i get from a system running XFS-1.0.1 on linux-2.4.9, RAID > hardware (DAC960): > > xfs_force_shutdown(dac960(48,4),0x8) called from line 4072 of file > xfs_bmap.c. Return address = 0xc01b8b9c > Corruption of in-memory data detected. Shutting down filesystem: > dac960(48,4) > Please umount the filesystem, and rectify the problem(s) > > I saw this at least twice on this system. > Anyone knows if 2.4.10 fixes these problems? > > -- > Florin Andrei > > "This is a Klingon." "Where did it came from?" "Oklahoma." > (from Star Trek Enterprise series premiere) From owner-linux-xfs@oss.sgi.com Tue Oct 2 07:07:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f92E7d516236 for linux-xfs-outgoing; Tue, 2 Oct 2001 07:07:39 -0700 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f92E7ZD16217 for ; Tue, 2 Oct 2001 07:07:35 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f92E7SL02240 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Tue, 2 Oct 2001 07:07:28 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id QAA1600476 for ; Tue, 2 Oct 2001 16:06:34 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA3111287; Tue, 2 Oct 2001 09:06:09 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA14573; Tue, 2 Oct 2001 09:06:09 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f92E5Hn09775; Tue, 2 Oct 2001 09:05:17 -0500 Message-Id: <200110021405.f92E5Hn09775@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: tommy@teatime.com.tw cc: Florin Andrei , linux-xfs Subject: Re: 2.4.9 is bad In-Reply-To: Message from Tommy Wu of "Tue, 02 Oct 2001 11:06:17 +0800." <20011002110216.26DF.NEWSLETTER@teatime.com.tw> Date: Tue, 02 Oct 2001 09:05:17 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Florin Andrei wrote: > > > > I saw this at least twice on this system. > > > Anyone knows if 2.4.10 fixes these problems? > > I also got the same message in here.... 3 times in yesterday night :-( > > 2.4.10 has some other problem in VM.... it will freeze my linux (deadlock) > . > I've tried the vm-tweak patch and linus's deadlock patch... but it seem no > > work here (for SMP, HIGHMEM linux). Since Florin works for SGI we are going to start trying things out on his machine. Steve > > > Looks like it's time to go back to older kernels for production > > machines. :o) > > So... do you know which version of kernel is stable with XFS now ? 2.4.9 (and 10) are stable for most people, but feeback from people seeing this problem as to what hardware they are using would be good. Highmem is always a possibility. How long the machine stays up, how active it is, cpu count, memory size, use of md or lvm on the filesystems which are shutting down. These would all be useful things to know. Steve > > -- > > Tommy Wu > mailto:tommy@teatime.com.tw > http://www.teatime.com.tw/~tommy > ICQ: 22766091 > Mobile Phone: +886 936 909490 > TeaTime BBS +886 2 31515964 24Hrs V.Everything > > From owner-linux-xfs@oss.sgi.com Tue Oct 2 07:14:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f92EECO16490 for linux-xfs-outgoing; Tue, 2 Oct 2001 07:14:12 -0700 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f92EEAD16470 for ; Tue, 2 Oct 2001 07:14:10 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f92EE4L02970 for ; Tue, 2 Oct 2001 07:14:04 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA3093131 for ; Tue, 2 Oct 2001 09:12:49 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA76183 for ; Tue, 2 Oct 2001 09:12:49 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id f92EBvp09855; Tue, 2 Oct 2001 09:11:57 -0500 Message-Id: <200110021411.f92EBvp09855@jen.americas.sgi.com> Date: Tue, 2 Oct 2001 09:11:57 -0500 Subject: TAKE - rename physmem to xfs_physmem Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Helps out XFS on user mode linux. Date: Tue Oct 2 07:11:15 PDT 2001 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:103758a linux/fs/xfs/xfs_log.c - 1.242 linux/fs/xfs/xfs_mount.c - 1.262 linux/fs/xfs/linux/xfs_globals.c - 1.24 linux/fs/xfs/linux/xfs_super.c - 1.138 linux/fs/xfs/linux/xfs_globals.h - 1.6 From owner-linux-xfs@oss.sgi.com Tue Oct 2 07:18:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f92EIbv16698 for linux-xfs-outgoing; Tue, 2 Oct 2001 07:18:37 -0700 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f92EIZD16679 for ; Tue, 2 Oct 2001 07:18:35 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f92EIUL03617 for ; Tue, 2 Oct 2001 07:18:30 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA3097667; Tue, 2 Oct 2001 09:17:13 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA00356; Tue, 2 Oct 2001 09:17:13 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f92EGLh09881; Tue, 2 Oct 2001 09:16:21 -0500 Message-Id: <200110021416.f92EGLh09881@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: tommy@teatime.com.tw, Florin Andrei , linux-xfs Subject: Re: 2.4.9 is bad In-Reply-To: Message from Steve Lord of "Tue, 02 Oct 2001 09:05:17 CDT." <200110021405.f92E5Hn09775@jen.americas.sgi.com> Date: Tue, 02 Oct 2001 09:16:21 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > 2.4.9 (and 10) are stable for most people, but feeback from people > seeing this problem as to what hardware they are using would be > good. Highmem is always a possibility. How long the machine stays up, > how active it is, cpu count, memory size, use of md or lvm on the > filesystems which are shutting down. These would all be useful > things to know. Oh, and if you are experiencing this problem and used to not do so, at which release did it show up, or if you don't know go try older versions until it reliably goes away. Since this is not something we have replicated locally (Florin is half a continent away I think) having people try stuff out and report back would be really useful. Steve From owner-linux-xfs@oss.sgi.com Tue Oct 2 07:20:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f92EK1F16870 for linux-xfs-outgoing; Tue, 2 Oct 2001 07:20:01 -0700 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f92EJwD16849 for ; Tue, 2 Oct 2001 07:19:58 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f92EJrK31822 for ; Tue, 2 Oct 2001 07:19:53 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA3122481; Tue, 2 Oct 2001 09:18:36 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA23855; Tue, 2 Oct 2001 09:18:36 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f92EHiC09888; Tue, 2 Oct 2001 09:17:44 -0500 Message-Id: <200110021417.f92EHiC09888@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Paul Schutte cc: Florin Andrei , linux-xfs Subject: Re: 2.4.9 is bad In-Reply-To: Message from Paul Schutte of "Tue, 02 Oct 2001 15:49:18 +0200." <3BB9C5DE.4456EC81@it.up.ac.za> Date: Tue, 02 Oct 2001 09:17:44 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I am amazed that it worked. > > If I am correct, the XFS-1.0.1 was a patch against the 2.4.5 kernel. The patch conflicts of applying that patch would be so large that I don't think anyone in their right mind would be attempting to fix the conflicts - and I think you would fall over in an ugly heap before you got a filesystem mounted. I was assuming Florin was running a cvs based kernel, but I may have assumed too much. Steve From owner-linux-xfs@oss.sgi.com Tue Oct 2 09:10:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f92GAnA19111 for linux-xfs-outgoing; Tue, 2 Oct 2001 09:10:49 -0700 Received: from the-penguin.otak.com (mail@the-penguin.otak.com [216.122.56.136]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f92GAiD19092 for ; Tue, 2 Oct 2001 09:10:44 -0700 Received: from lawrence by the-penguin.otak.com with local (Exim 3.32 #1 (Debian)) id 15oS82-0003VT-00 for ; Tue, 02 Oct 2001 09:10:42 -0700 Date: Tue, 2 Oct 2001 09:10:42 -0700 From: Lawrence Walton To: linux-xfs Subject: ACLs Message-ID: <20011002091042.A9759@the-penguin.otak.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.22i X-Operating-System: Linux 2.4.10 on an i686 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello I have been using XFS on a couple servers; And want to start exploring ACL support in Linux and Samba. I am using yesterdays CVS build and have installed these additional packages. with the help of dpkg-buildpackage. acl_1.1.3-0_i386.deb acl-dev_1.1.3-0_i386.deb attr_1.1.3-0_i386.deb attr-dev_1.1.3-0_i386.deb dmapi_0.2.2-0_i386.deb dmapi-dev_0.2.2-0_i386.deb xfsprogs_1.3.8-0_i386.deb xfslibs-dev_1.3.8-0_i386.deb So I think I have my bases covered. When I go to set a acl with the command line of setfacl -s u::rw,g::r,o:-,g:staff:rw file I get this error setfacl file: Resulting ACL `,user::rw-,group:staff:rw-,mask::---,other::---': Invalid entry type at entry 1 Or even a more simple command line; setfacl -m u:lawrence:r file setfacl: file: Resulting ACL `,user::rwx,user:lawrence:r--,mask::---,other::-w-': Invalid entry type at entry 1 what in the world am I doing wrong? Samba acls don't seem to work either..... -- *--* Mail: lawrence@otak.com *--* Voice: 425.739.4247 *--* Fax: 425.827.9577 *--* HTTP://www.otak-k.com/~lawrence/ -------------------------------------- - - - - - - O t a k i n c . - - - - - From owner-linux-xfs@oss.sgi.com Tue Oct 2 10:55:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f92HtTI21079 for linux-xfs-outgoing; Tue, 2 Oct 2001 10:55:29 -0700 Received: from otto.cfht.hawaii.edu (otto.colonization.com [128.171.80.37]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f92HtOD21059 for ; Tue, 2 Oct 2001 10:55:24 -0700 Received: (from isani@localhost) by otto.cfht.hawaii.edu (8.8.8/8.8.8) id HAA11523; Tue, 2 Oct 2001 07:55:03 -1000 From: Sidik Isani Message-Id: <200110021755.HAA11523@otto.cfht.hawaii.edu> Subject: Re: XFS on laptops To: kaos@melbourne.sgi.com (Keith Owens) Date: Tue, 2 Oct 2001 07:55:03 -1000 (HST) Cc: linux-xfs@oss.sgi.com In-Reply-To: <8064.1001554820@kao2.melbourne.sgi.com> from "Keith Owens" at Sep 27, 2001 11:40:20 AM X-Mailer: ELM [version 2.5 PL0] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk | |Can anybody recommend tuning parameters for XFS on laptops? Since |converting my laptop to XFS, the disk never spins down so the machine |never suspends. Hello Keith - Aren't suspend and disk spin-down controlled separately? I've been running the following on my laptop with great results ever since July 5th: o linux-2.4.6-xfs-07052001 - Uni-processor I don't remember exactly why I didn't go with 2.4.5-xfs-1.0.1, but it may have been that 2.4.6 helped somehow with letting the disk spin down. I may be switching back to 2.4.5 soon so I'll find out. o /tmp and /var are "tmpfs" o /dev is "devfs" o / is "xfs" but mounted "noatime,osyncisdsync" * mount -o remount,noatime did NOT work with the versions I tried. * The standard initrd method (including a /linuxrc) does NOT work because of the way Linux treats the special name "/linuxrc". * So init must be something other than /linuxrc, and init itself must do the mount and use the new pivot_root stuff, and exec the real /sbin/init so that init still gets PID 1. It's the only thing which worked for getting root mounted with the special options. o I cat a bunch of things to /dev/null at the end of sysinit, including complete files from /lib /usr/lib /usr/X11R6/lib o I set spindown time to 90 seconds with hdparm (maybe a bit short) o ~/.netscape/history.dat is a symlink to a file in /tmp netscape's caches are turned off. o I don't run noflushd, but the disk still spins down if I'm not doing anything on the machine, or using it as an X-Terminal. I'm sure I'm forgetting something, but those were the key elements to keeping the disk quiet. Be seeing you, - Sidik From owner-linux-xfs@oss.sgi.com Tue Oct 2 11:19:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f92IJuZ21627 for linux-xfs-outgoing; Tue, 2 Oct 2001 11:19:56 -0700 Received: from otto.cfht.hawaii.edu (otto.colonization.com [128.171.80.37]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f92IJqD21606 for ; Tue, 2 Oct 2001 11:19:52 -0700 Received: (from isani@localhost) by otto.cfht.hawaii.edu (8.8.8/8.8.8) id IAA11636 for linux-xfs@oss.sgi.com; Tue, 2 Oct 2001 08:19:51 -1000 From: Sidik Isani Message-Id: <200110021819.IAA11636@otto.cfht.hawaii.edu> Subject: corruption on 2.4.6 w/ low memory? To: linux-xfs@oss.sgi.com Date: Tue, 2 Oct 2001 08:19:51 -1000 (HST) X-Mailer: ELM [version 2.5 PL0] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello - I'm having a problem with XFS and/or the 2.4.6 kernel. Since 2.4.6+XFS is not an official release, I'm guessing the first thing would be to use 2.4.5-xfs-1.0.1... unless this is a known problem which 2.4.5 might have as well? In any case, I'd like your advice on which version to use, to try and recreate this and get more debugging information. (I know what I've included is probably not enough.) The symptoms are files which were written *minutes* ago retain the right size, but seem to develop blocks full of zero bytes. I think this mostly happens when memory runs very low, but I'm not sure. I'm running an SMP kernel, with no swap space, and I'm writing files to "tmpfs" at the same time. (With the UP kernel, I've noticed a different, but possibly related problem when memory runs low where bdflush gets stuck taking 100% of the CPU.) Usually, there are no errors from the kernel while this is happening, but eventually I got these: kernel BUG at ll_rw_blk.c:700! invalid operand: 0000 ... And "free" showed: total used free shared buffers cached Mem: 254120 243684 10436 0 51688 215380 -/+ buffers/cache: -23384 277504 Swap: 0 0 0 Any suggestions? Thanks for your help. Be seeing you, - Sidik From owner-linux-xfs@oss.sgi.com Tue Oct 2 11:41:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f92IfdQ22129 for linux-xfs-outgoing; Tue, 2 Oct 2001 11:41:39 -0700 Received: from smtp4.163.com ([202.108.44.204]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f92IfQD22110 for ; Tue, 2 Oct 2001 11:41:26 -0700 Received: from wlpb.net (kent.jbic.com [205.133.156.76]) by smtp4.163.com (Postfix) with SMTP id 4C6A01C4E6678; Wed, 3 Oct 2001 00:56:55 +0800 (CST) From: To: Subject: Is your site ranking? Free report. MIME-Version: 1.0 Content-Type: multipart/mixed;boundary= "----=_NextPart_000_008A_9141F7CF.697ED164" 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 Message-Id: <20011002165655.4C6A01C4E6678@smtp4.163.com> Date: Wed, 3 Oct 2001 00:56:55 +0800 (CST) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk ------=_NextPart_000_008A_9141F7CF.697ED164 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMC8vRU4iPjwhLS0g c2F2ZWQgZnJvbSB1cmw9KDAwMjIpaHR0cDovL2ludGVybmV0LmUtbWFpbCAtLT4NCjxIVE1M PjxIRUFEPjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sO2NoYXJzZXQ9aXNvLTg4NTktMSI+DQoNCjxUSVRMRT5GcmVlIFJhbmtpbmcgUmVwb3J0 PC9USVRMRT4NCjxNRVRBIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD13aW5kb3dzLTEy NTIiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPFNDUklQVCBsYW5ndWFnZT1KYXZhU2Ny aXB0Pg0KdmFyIG1lc3NhZ2U9IkdldCBBIEZyZWUgU2VhcmNoIEVuZ2luZSBSYW5raW5nIFJl cG9ydC5cbiI7DQpmdW5jdGlvbiBjbGljayhlKSB7DQppZiAoZG9jdW1lbnQuYWxsKSB7DQpp ZiAoZXZlbnQuYnV0dG9uID09IDIpIHsNCmFsZXJ0KG1lc3NhZ2UpOw0KcmV0dXJuIGZhbHNl Ow0KfQ0KfQ0KaWYgKGRvY3VtZW50LmxheWVycykgew0KaWYgKGUud2hpY2ggPT0gMykgew0K YWxlcnQobWVzc2FnZSk7DQpyZXR1cm4gZmFsc2U7DQp9DQp9DQp9DQppZiAoZG9jdW1lbnQu bGF5ZXJzKSB7DQpkb2N1bWVudC5jYXB0dXJlRXZlbnRzKEV2ZW50Lk1PVVNFRE9XTik7DQp9 DQpkb2N1bWVudC5vbm1vdXNlZG93bj1jbGljazsNCjwvU0NSSVBUPg0KDQo8U0NSSVBUIGxh bmd1YWdlPUphdmFTY3JpcHQ+DQo8IS0tDQp2YXIgcG9wdXA9IkdldCBBIEZyZWUgU2VhcmNo IEVuZ2luZSBSYW5raW5nIFJlcG9ydC4iOw0KZnVuY3Rpb24gbm93YXkoZ28pIHsNCmlmIChk b2N1bWVudC5hbGwpIHsNCmlmIChldmVudC5idXR0b24gPT0gMikgew0KYWxlcnQocG9wdXAp Ow0KcmV0dXJuIGZhbHNlOw0KfQ0KfQ0KaWYgKGRvY3VtZW50LmxheWVycykgew0KaWYgKGdv LndoaWNoID09IDMpIHsNCmFsZXJ0KHBvcHVwKTsNCnJldHVybiBmYWxzZTsNCn0NCn0NCn0N CmlmIChkb2N1bWVudC5sYXllcnMpIHsNCmRvY3VtZW50LmNhcHR1cmVFdmVudHMoRXZlbnQu TU9VU0VET1dOKTsNCn0NCmRvY3VtZW50Lm9ubW91c2Vkb3duPW5vd2F5Ow0KLy8gLS0+IDwv U0NSSVBUPg0KDQo8TUVUQSBjb250ZW50PSJJQk0gTmV0T2JqZWN0cyBUb3BQYWdlIFY0LjAu MyAgZm9yIFdpbmRvd3MiIG5hbWU9IkdFTkVSQVRPUiI+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxGT1JNIA0KYWN0aW9uPSJtYWlsdG86 d2luZF9pdF91cEBleGNpdGUuY29tID8gc3ViamVjdD1FbWFpbCBGb3JtIFJhbmtpbmcgUmVw b3J0IFJlcXVlc3QiIA0KZW5jVHlwZT10ZXh0L3BsYWluIG1ldGhvZD1wb3N0Pg0KPFAgYWxp Z249Y2VudGVyPjxGT05UIGNvbG9yPSMzMzMzZmYgZmFjZT0iQXJpYWwsIEhlbHZldGljYSwg c2Fucy1zZXJpZiIgDQpzaXplPTI+PEI+PEZPTlQgc2l6ZT0zPkNvdWxkIHlvdXIgd2Vic2l0 ZSB1c2UgbW9yZSANCnRyYWZmaWM/PC9GT05UPjwvQj48L0ZPTlQ+PEZPTlQgZmFjZT0iQXJp YWwsJiMxMzsmIzEwO0hlbHZldGljYSwgc2Fucy1zZXJpZiIgDQpzaXplPTI+PEJSPjxCUj5X aHkgbm90IHB1dCB5b3Vyc2VsZiB3aGVyZSBwZW9wbGUgY2FuIGZpbmQgeW91LiBXZSA8Qj48 Rk9OVCANCmNvbG9yPSNmZjAwMDA+Z3VhcmFudGVlIHRvcCBwbGFjZW1lbnQ8L0ZPTlQ+PC9C PiBvbiB0aGUgPEZPTlQgDQpjb2xvcj0jMzMzM2ZmPjxCPnRvcCB0ZW4gc2VhcmNoIGVuZ2lu ZTxGT05UIA0KY29sb3I9IzMzMzNmZj5zPC9GT05UPjwvQj48L0ZPTlQ+PEI+PEZPTlQgY29s b3I9IzMzMzNmZj4hPC9GT05UPjwvQj48QlI+RmlsbCBvdXQgDQp0aGUgZm9ybSBiZWxvdywg YW5kIHdlIHdpbGwgcnVuIGEgZnJlZSByYW5raW5nIHJlcG9ydCBvbiB5b3VyIA0Kd2Vic2l0 ZS48L0ZPTlQ+PC9QPg0KPFRBQkxFIGFsaWduPWNlbnRlciBib3JkZXI9MCBjZWxsUGFkZGlu Zz0wIGNlbGxTcGFjaW5nPTAgd2lkdGg9NjAwPg0KICA8VEJPRFk+DQogIDxUUiBiZ0NvbG9y PSNlYWVhZWE+DQogICAgPFREPg0KICAgICAgPERJViBhbGlnbj1jZW50ZXI+DQogICAgICA8 UD4mbmJzcDs8L1A+DQogICAgICA8UD48Qj48Rk9OVCBmYWNlPSJBcmlhbCwgSGVsdmV0aWNh LCBzYW5zLXNlcmlmIiBzaXplPTQ+UmVxdWVzdCBhIDxGT05UIA0KICAgICAgY29sb3I9I2Zm MDAwMD5GUkVFIFJhbmtpbmcgUmVwb3J0PC9GT05UPiBmb3IgeW91ciB3ZWJzaXRlITwvRk9O VD48L0I+PEZPTlQgDQogICAgICBzaXplPTQ+PEI+PEZPTlQgZmFjZT0iQXJpYWwsIEhlbHZl dGljYSwgc2Fucy1zZXJpZiI+IA0KPC9GT05UPjwvQj48L0ZPTlQ+PC9QPg0KICAgICAgPEhS Pg0KDQogICAgICA8UD48Qj48Rk9OVCBmYWNlPSJBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNl cmlmIiBzaXplPTI+QSBjdXN0b21lciBzZXJ2aWNlIA0KICAgICAgcmVwcmVzZW50YXRpdmUg d2lsbCBjb250YWN0IHlvdSBzaG9ydGx5IHdpdGggYSANCiAgICAgIHJlcG9ydC48QlI+PC9G T05UPjwvQj48Qj48Rk9OVCANCiAgICAgIGZhY2U9IkFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMt c2VyaWYiPjwvRk9OVD48L0I+PC9QPjwvRElWPjwvVEQ+PC9UUj4NCiAgPFRSPg0KICAgIDxU RD4NCiAgICAgIDxESVYgYWxpZ249Y2VudGVyPg0KICAgICAgPFA+Jm5ic3A7PC9QPg0KICAg ICAgPFRBQkxFIGJvcmRlcj0xIGJvcmRlckNvbG9yRGFyaz0jZWFlYWVhIGNlbGxQYWRkaW5n PTIgY2VsbFNwYWNpbmc9MSANCiAgICAgIHdpZHRoPTQwMD4NCiAgICAgICAgPFRCT0RZPg0K ICAgICAgICA8VFI+DQogICAgICAgICAgPFREIGhlaWdodD0yNSB3aWR0aD0iNTAlIj4NCiAg ICAgICAgICAgIDxESVYgYWxpZ249bGVmdD48Rk9OVCBmYWNlPSJBcmlhbCwgSGVsdmV0aWNh LCBzYW5zLXNlcmlmIiANCiAgICAgICAgICAgIHNpemU9Mj5Zb3VyIG5hbWU6PC9GT05UPjwv RElWPjwvVEQ+DQogICAgICAgICAgPFREIGhlaWdodD0yNSB3aWR0aD0iNTAlIj4NCiAgICAg ICAgICAgIDxESVYgYWxpZ249bGVmdD48SU5QVVQgbWF4TGVuZ3RoPTUwIG5hbWU9bmFtZSBz aXplPTI1PiA8L0RJVj48L1REPjwvVFI+DQogICAgICAgIDxUUj4NCiAgICAgICAgICA8VEQg aGVpZ2h0PTI1IHdpZHRoPSI1MCUiPg0KICAgICAgICAgICAgPERJViBhbGlnbj1sZWZ0PjxG T05UIGZhY2U9IkFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiIA0KICAgICAgICAgICAg c2l6ZT0yPldlYnNpdGUgYWRkcmVzczo8L0ZPTlQ+PC9ESVY+PC9URD4NCiAgICAgICAgICA8 VEQgaGVpZ2h0PTI1IHdpZHRoPSI1MCUiPg0KICAgICAgICAgICAgPERJViBhbGlnbj1sZWZ0 PjxGT05UIGZhY2U9IkFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPjxJTlBVVCANCiAg ICAgICAgICAgIG1heExlbmd0aD01MCBuYW1lPXVybCBzaXplPTI1PiA8L0ZPTlQ+PC9ESVY+ PC9URD48L1RSPg0KICAgICAgICA8VFI+DQogICAgICAgICAgPFREIGhlaWdodD0yNSB3aWR0 aD0iNTAlIj4NCiAgICAgICAgICAgIDxESVYgYWxpZ249bGVmdD48Rk9OVCBmYWNlPSJBcmlh bCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiANCiAgICAgICAgICAgIHNpemU9Mj5UZWxlcGhv bmUgbnVtYmVyOjwvRk9OVD48L0RJVj48L1REPg0KICAgICAgICAgIDxURCBoZWlnaHQ9MjUg d2lkdGg9IjUwJSI+DQogICAgICAgICAgICA8RElWIGFsaWduPWxlZnQ+PEZPTlQgZmFjZT0i QXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiI+PElOUFVUIA0KICAgICAgICAgICAgbWF4 TGVuZ3RoPTUwIG5hbWU9cGhvbmUgc2l6ZT0yNT4gPC9GT05UPjwvRElWPjwvVEQ+PC9UUj4N CiAgICAgICAgPFRSPg0KICAgICAgICAgIDxURCBoZWlnaHQ9MjUgd2lkdGg9IjUwJSI+DQog ICAgICAgICAgICA8RElWIGFsaWduPWxlZnQ+PEZPTlQgZmFjZT0iQXJpYWwsIEhlbHZldGlj YSwgc2Fucy1zZXJpZiIgDQogICAgICAgICAgICBzaXplPTI+RW1haWwgYWRkcmVzczo8L0ZP TlQ+PC9ESVY+PC9URD4NCiAgICAgICAgICA8VEQgaGVpZ2h0PTI1IHdpZHRoPSI1MCUiPg0K ICAgICAgICAgICAgPERJViBhbGlnbj1sZWZ0PjxGT05UIGZhY2U9IkFyaWFsLCBIZWx2ZXRp Y2EsIHNhbnMtc2VyaWYiPjxJTlBVVCANCiAgICAgICAgICAgIG1heExlbmd0aD01MCBuYW1l PWVtYWlsIHNpemU9MjU+IDwvRk9OVD48L0RJVj48L1REPjwvVFI+DQogICAgICAgIDxUUj4N CiAgICAgICAgICA8VEQgY29sU3Bhbj0yIGhlaWdodD0yNT4NCiAgICAgICAgICAgIDxESVYg YWxpZ249Y2VudGVyPjxGT05UIGZhY2U9IkFyaWFsLCBIZWx2ZXRpY2EsJiMxMzsmIzEwO3Nh bnMtc2VyaWYiIA0KICAgICAgICAgICAgc2l6ZT0yPjxCPlBsZWFzZSBsaXN0IHRoZSBrZXl3 b3JkcyB0aGF0IHlvdSB3b3VsZCBsaWtlIHVzIHRvIHJ1biBhIA0KICAgICAgICAgICAgcmVw b3J0IG9uOjwvQj48L0ZPTlQ+PC9ESVY+PC9URD48L1RSPg0KICAgICAgICA8VFI+DQogICAg ICAgICAgPFREIGhlaWdodD0yNSB3aWR0aD0iNTAlIj48Rk9OVCANCiAgICAgICAgICAgIGZh Y2U9IkFyaWFsLCBIZWx2ZXRpY2EsJiMxMzsmIzEwO3NhbnMtc2VyaWYiIHNpemU9Mj5LZXl3 b3JkIDE6IA0KICAgICAgICAgICAgPC9GT05UPjwvVEQ+DQogICAgICAgICAgPFREIGhlaWdo dD0yNSB3aWR0aD0iNTAlIj48Rk9OVCANCiAgICAgICAgICAgIGZhY2U9IkFyaWFsLCBIZWx2 ZXRpY2EsJiMxMzsmIzEwO3NhbnMtc2VyaWYiPjxJTlBVVCBtYXhMZW5ndGg9NTAgDQogICAg ICAgICAgICBuYW1lPWtleXdvcmQxIHNpemU9MjU+IDwvRk9OVD48L1REPjwvVFI+DQogICAg ICAgIDxUUj4NCiAgICAgICAgICA8VEQgaGVpZ2h0PTI1IHdpZHRoPSI1MCUiPjxGT05UIA0K ICAgICAgICAgICAgZmFjZT0iQXJpYWwsIEhlbHZldGljYSwmIzEzOyYjMTA7c2Fucy1zZXJp ZiIgc2l6ZT0yPktleXdvcmQgMjogDQogICAgICAgICAgICA8L0ZPTlQ+PC9URD4NCiAgICAg ICAgICA8VEQgaGVpZ2h0PTI1IHdpZHRoPSI1MCUiPjxGT05UIA0KICAgICAgICAgICAgZmFj ZT0iQXJpYWwsIEhlbHZldGljYSwmIzEzOyYjMTA7c2Fucy1zZXJpZiI+PElOUFVUIG1heExl bmd0aD01MCANCiAgICAgICAgICAgIG5hbWU9a2V5d29yZDIgc2l6ZT0yNT4gPC9GT05UPjwv VEQ+PC9UUj4NCiAgICAgICAgPFRSPg0KICAgICAgICAgIDxURCBoZWlnaHQ9MjUgd2lkdGg9 IjUwJSI+PEZPTlQgDQogICAgICAgICAgICBmYWNlPSJBcmlhbCwgSGVsdmV0aWNhLCYjMTM7 JiMxMDtzYW5zLXNlcmlmIiBzaXplPTI+S2V5d29yZCAzOiANCiAgICAgICAgICAgIDwvRk9O VD48L1REPg0KICAgICAgICAgIDxURCBoZWlnaHQ9MjUgd2lkdGg9IjUwJSI+PEZPTlQgDQog ICAgICAgICAgICBmYWNlPSJBcmlhbCwgSGVsdmV0aWNhLCYjMTM7JiMxMDtzYW5zLXNlcmlm Ij48SU5QVVQgbWF4TGVuZ3RoPTUwIA0KICAgICAgICAgICAgbmFtZT1rZXl3b3JkMyBzaXpl PTI1PiA8L0ZPTlQ+PC9URD48L1RSPjwvVEJPRFk+PC9UQUJMRT4NCiAgICAgIDxQPjxJTlBV VCBuYW1lPVN1Ym1pdCB0eXBlPXN1Ym1pdCB2YWx1ZT0iUmVxdWVzdCBSZXBvcnQiPiA8L1A+ PC9ESVY+PC9URD48L1RSPg0KICA8VFIgYmdDb2xvcj0jZWFlYWVhPg0KICAgIDxURCBoZWln aHQ9MjA+Jm5ic3A7PC9URD48L1RSPjwvVEJPRFk+PC9UQUJMRT48L0ZPUk0+DQo8UCBhbGln bj1jZW50ZXI+PEZPTlQgZmFjZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiIgc2l6 ZT0yPllvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgYmVjYXVzZSB5b3UgaGF2ZSBwdXJj aGFzZWQgc29tZXRoaW5nIHdpdGhpbiB0aGUgcGFzdCA2IG1vbnRocyBhbmQgcmVxdWVzdGVk IGluZm8uIElmIHlvdSB3b3VsZCANCmxpa2UgdG8gYmUgcmVtb3ZlZCBmcm9tIHRoaXMgbGlz dCwgcGxlYXNlIHNlbmQgYW4gZW1haWwgdG8gPEEgDQpocmVmPSJtYWlsdG86c3VuYnVybnRf a25lZXNAeWFob28uY29tIj5nZXRsaXN0ZWR0b2RheUBleGNpdGUuY29tPC9BPiANCndpdGg8 QlI+cmVtb3ZlIiBpbiB0aGUgc3ViamVjdCBsaW5lLjwvRk9OVD48L1A+PC9CT0RZPjwvSFRN TD4NCg0KICAgIA== ------=_NextPart_000_008A_9141F7CF.697ED164-- From owner-linux-xfs@oss.sgi.com Tue Oct 2 13:08:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f92K8oX24081 for linux-xfs-outgoing; Tue, 2 Oct 2001 13:08:50 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f92K8jD24062 for ; Tue, 2 Oct 2001 13:08:45 -0700 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id WAA28061; Tue, 2 Oct 2001 22:08:40 +0200 (CEST) Message-Id: <4.3.2.7.2.20011002220555.030356b8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 02 Oct 2001 22:07:51 +0200 To: Sidik Isani , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: corruption on 2.4.6 w/ low memory? In-Reply-To: <200110021819.IAA11636@otto.cfht.hawaii.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 08:19 2-10-2001 -1000, Sidik Isani wrote: >Hello - > > I'm having a problem with XFS and/or the 2.4.6 kernel. Since > 2.4.6+XFS is not an official release, I'm guessing the first > thing would be to use 2.4.5-xfs-1.0.1... unless this is a known > problem which 2.4.5 might have as well? In any case, I'd like > your advice on which version to use, to try and recreate this > and get more debugging information. (I know what I've included > is probably not enough.) Can you try a CVS kernel? > The symptoms are files which were written *minutes* ago retain > the right size, but seem to develop blocks full of zero bytes. > I think this mostly happens when memory runs very low, but I'm > not sure. I'm running an SMP kernel, with no swap space, and I'm > writing files to "tmpfs" at the same time. (With the UP kernel, > I've noticed a different, but possibly related problem when > memory runs low where bdflush gets stuck taking 100% of the CPU.) What compiler did you use? Egcs 1.1.2 is the recommended compiler for production use. > Usually, there are no errors from the kernel while this is > happening, but eventually I got these: > >kernel BUG at ll_rw_blk.c:700! >invalid operand: 0000 >... > > And "free" showed: > > total used free shared buffers cached >Mem: 254120 243684 10436 0 51688 215380 >-/+ buffers/cache: -23384 277504 >Swap: 0 0 0 Why run without swap? Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Tue Oct 2 13:18:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f92KIHt24412 for linux-xfs-outgoing; Tue, 2 Oct 2001 13:18:17 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f92KIFD24392 for ; Tue, 2 Oct 2001 13:18:15 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA04480 for ; Tue, 2 Oct 2001 13:17:08 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA3124331; Tue, 2 Oct 2001 15:16:59 -0500 (CDT) Received: from sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id PAA86096; Tue, 2 Oct 2001 15:16:58 -0500 (CDT) Message-ID: <3BBA2010.9AECC02A@sgi.com> Date: Tue, 02 Oct 2001 15:14:08 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.8-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Sidik Isani CC: linux-xfs@oss.sgi.com Subject: Re: corruption on 2.4.6 w/ low memory? References: <200110021819.IAA11636@otto.cfht.hawaii.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sidik Isani wrote: > The symptoms are files which were written *minutes* ago retain > the right size, but seem to develop blocks full of zero bytes. > I think this mostly happens when memory runs very low, but I'm > not sure. I assume you see this after a crash? Or is this on a live system? -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Oct 2 15:08:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f92M8hd28082 for linux-xfs-outgoing; Tue, 2 Oct 2001 15:08:43 -0700 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f92M8dD28062 for ; Tue, 2 Oct 2001 15:08:39 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with SMTP id f92M8WL28452 for ; Tue, 2 Oct 2001 15:08:32 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA28663; Wed, 3 Oct 2001 08:07:15 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA85257; Wed, 3 Oct 2001 09:07:14 +1100 (AEDT) Date: Wed, 3 Oct 2001 09:07:14 +1100 From: Nathan Scott To: Lawrence Walton Cc: linux-xfs Subject: Re: ACLs Message-ID: <20011003090714.D472533@wobbly.melbourne.sgi.com> References: <20011002091042.A9759@the-penguin.otak.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011002091042.A9759@the-penguin.otak.com>; from lawrence@the-penguin.otak.com on Tue, Oct 02, 2001 at 09:10:42AM -0700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Tue, Oct 02, 2001 at 09:10:42AM -0700, Lawrence Walton wrote: > Hello I have been using XFS on a couple servers; > And want to start exploring ACL support in Linux and Samba. > I am using yesterdays CVS build and have installed > > these additional packages. > with the help of dpkg-buildpackage. > ... > So I think I have my bases covered. > Yes, these all look correct. > When I go to set a acl with the command line of Ah, I see you're trusting the man page - alas, it is wrong. I will get a fixed version into the cvs tree soon. > setfacl -s u::rw,g::r,o:-,g:staff:rw file eg. the above is an invalid ACL specification - try instead something like "u::rw-,g::r--,o:---,g:staff:rw-,m::rwx". > > Samba acls don't seem to work either..... > See the list archive for some discussion on issues with building the Debian samba package with ACLs enabled (I assume thats what you're trying to do) - as recently as the last couple of weeks, IIRC. Its certainly possible to get it working though. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Oct 2 15:22:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f92MMct28448 for linux-xfs-outgoing; Tue, 2 Oct 2001 15:22:38 -0700 Received: from otto.cfht.hawaii.edu (otto.colonization.com [128.171.80.37]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f92MMWD28428 for ; Tue, 2 Oct 2001 15:22:32 -0700 Received: (from isani@localhost) by otto.cfht.hawaii.edu (8.8.8/8.8.8) id MAA12053; Tue, 2 Oct 2001 12:22:13 -1000 From: Sidik Isani Message-Id: <200110022222.MAA12053@otto.cfht.hawaii.edu> Subject: Re: corruption on 2.4.6 w/ low memory? To: knuffie@xs4all.nl (Seth Mos) Date: Tue, 2 Oct 2001 12:22:13 -1000 (HST) Cc: isani@cfht.hawaii.edu (Sidik Isani), linux-xfs@oss.sgi.com In-Reply-To: <4.3.2.7.2.20011002220555.030356b8@pop.xs4all.nl> from "Seth Mos" at Oct 02, 2001 10:07:51 PM X-Mailer: ELM [version 2.5 PL0] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk | |At 08:19 2-10-2001 -1000, Sidik Isani wrote: |>Hello - |> |> I'm having a problem with XFS and/or the 2.4.6 kernel. Since |> 2.4.6+XFS is not an official release, I'm guessing the first |> thing would be to use 2.4.5-xfs-1.0.1... unless this is a known |> problem which 2.4.5 might have as well? In any case, I'd like |> your advice on which version to use, to try and recreate this |> and get more debugging information. (I know what I've included |> is probably not enough.) | |Can you try a CVS kernel? Sure. Though I am testing this stuff for eventual use on production systems... |> The symptoms are files which were written *minutes* ago retain |> the right size, but seem to develop blocks full of zero bytes. |> I think this mostly happens when memory runs very low, but I'm |> not sure. I'm running an SMP kernel, with no swap space, and I'm |> writing files to "tmpfs" at the same time. (With the UP kernel, |> I've noticed a different, but possibly related problem when |> memory runs low where bdflush gets stuck taking 100% of the CPU.) | |What compiler did you use? Egcs 1.1.2 is the recommended compiler for |production use. gcc-2.95.3 -g -O |> Usually, there are no errors from the kernel while this is |> happening, but eventually I got these: |> |>kernel BUG at ll_rw_blk.c:700! |>invalid operand: 0000 |>... |> |> And "free" showed: |> |> total used free shared buffers cached |>Mem: 254120 243684 10436 0 51688 215380 |>-/+ buffers/cache: -23384 277504 |>Swap: 0 0 0 | |Why run without swap? On this machine, there is no good reason. I will try to create some, and see if the same problem occurs when both swap and memory fill up or not. Other similar machines need to be disk-less NFS-root but those won't exercise their XFS, code of course. Is there a fundamental difference between having, say, 1 GB of RAM versus 512MB RAM + 512 Swap? Be seeing you, - Sidik From owner-linux-xfs@oss.sgi.com Tue Oct 2 15:28:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f92MSiK28718 for linux-xfs-outgoing; Tue, 2 Oct 2001 15:28:44 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f92MSfD28699 for ; Tue, 2 Oct 2001 15:28:41 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA05313 for ; Tue, 2 Oct 2001 15:27:22 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA3122802 for ; Tue, 2 Oct 2001 17:27:02 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA46575 for ; Tue, 2 Oct 2001 17:27:02 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id f92MQwb12934; Tue, 2 Oct 2001 17:26:58 -0500 Message-Id: <200110022226.f92MQwb12934@jen.americas.sgi.com> Date: Tue, 2 Oct 2001 17:26:58 -0500 Subject: TAKE - fix hang with mmap writes to a full filesystem Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The delayed allocate code in xfs and the way linux created mmapped space in files meant that we got into an infinite loop on a full filesystem and fell off the bottom of the stack. This removes the flushing of mmap data from this case - all we need to do is flush delayed allocate data in the hope it will free some space before we finally give up. Date: Tue Oct 2 15:23:13 PDT 2001 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:103823a linux/fs/xfs/xfs_vfsops.c - 1.327 linux/fs/xfs/linux/xfs_lrw.c - 1.112 - Fix the full filesystem delwri flush code to avoid mmap data. linux/fs/pagebuf/page_buf_io.c - 1.99 - Cleanup the read and write page paths From owner-linux-xfs@oss.sgi.com Tue Oct 2 15:31:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f92MVcc28933 for linux-xfs-outgoing; Tue, 2 Oct 2001 15:31:38 -0700 Received: from otto.cfht.hawaii.edu (otto.colonization.com [128.171.80.37]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f92MVZD28914 for ; Tue, 2 Oct 2001 15:31:35 -0700 Received: (from isani@localhost) by otto.cfht.hawaii.edu (8.8.8/8.8.8) id MAA12084; Tue, 2 Oct 2001 12:31:22 -1000 From: Sidik Isani Message-Id: <200110022231.MAA12084@otto.cfht.hawaii.edu> Subject: Re: corruption on 2.4.6 w/ low memory? To: sandeen@sgi.com (Eric Sandeen) Date: Tue, 2 Oct 2001 12:31:21 -1000 (HST) Cc: isani@cfht.hawaii.edu (Sidik Isani), linux-xfs@oss.sgi.com In-Reply-To: <3BBA2010.9AECC02A@sgi.com> from "Eric Sandeen" at Oct 02, 2001 03:14:08 PM X-Mailer: ELM [version 2.5 PL0] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk | |Sidik Isani wrote: | |> The symptoms are files which were written *minutes* ago retain |> the right size, but seem to develop blocks full of zero bytes. |> I think this mostly happens when memory runs very low, but I'm |> not sure. | |I assume you see this after a crash? Or is this on a live system? Actually a live system! Often one with no other sign that things have gone wrong other than files developing zeroed-blocks. Sometimes a running program will suddenly generate a segmentation fault, after which the binary (and other random files) have zero's in them and are useless from then on. I.e., the binary which previously would run, will no longer run, even after a reboot. At first I though some buggy applications (which I'm running as *root*) were screwing things up. This is still a possibility, but I ran "rsync --checksum" against the original disk and found a bunch of recently copied .a and .h files which were also affected. I'll try to narrow down the conditions which cause this... Be seeing you, - Sidik From owner-linux-xfs@oss.sgi.com Tue Oct 2 17:26:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f930Qio31510 for linux-xfs-outgoing; Tue, 2 Oct 2001 17:26:44 -0700 Received: from linux0.echostar.com (w146-253.echostar.com [205.172.146.253]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f930QeD31489 for ; Tue, 2 Oct 2001 17:26:40 -0700 Received: from echostar.com (linux10.echostar.com [10.79.98.110]) by linux0.echostar.com (Postfix) with ESMTP id 8AFD879085 for ; Tue, 2 Oct 2001 18:26:29 -0600 (MDT) Message-ID: <3BBA5B36.463BFEA4@echostar.com> Date: Tue, 02 Oct 2001 18:26:30 -0600 From: "Ian S. Nelson" Reply-To: ian.nelson@echostar.com Organization: Echostar X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.4.3 i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-xfs@oss.sgi.com" Subject: Trouble using IOC_XFS_FREESP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm hacking together a little "trim()" function and I'm having trouble getting it to work. Here is my code: int trim(int fd, unsigned long long offset) { struct xfs_flock64 flock; int rc; flock.l_whence = 0; flock.l_start = 0; flock.l_len = offset; rc = ioctl( fd, XFS_IOC_FREESP, &flock ); printf("rc: %d\n", rc); } And I'm always ending up with 0 length files when I'm done. I'm creating a file of 20000 bytes and then trying to poke a hole in the first 10000 bytes. Am I missing something? I don't have the irix man pages so I'm kind of guessing. rc is 0 (zero) when I run it. thanks, Ian From owner-linux-xfs@oss.sgi.com Tue Oct 2 19:07:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f93277q01381 for linux-xfs-outgoing; Tue, 2 Oct 2001 19:07:07 -0700 Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f93273D01358 for ; Tue, 2 Oct 2001 19:07:03 -0700 Received: from dhcp10 (static031-81-151-24.nm01-c3.cpe.charter-ne.com [24.151.81.31]) by falcon.mail.pas.earthlink.net (8.11.5/8.9.3) with SMTP id f9326t609696; Tue, 2 Oct 2001 19:06:56 -0700 (PDT) Message-ID: <015601c14baf$e783d060$0a00a8c0@intranet.mp3s.com> Reply-To: "Sean Elble" From: "Sean Elble" To: "Utz Lehmann" Cc: References: <014601c14aed$34616ff0$0a00a8c0@intranet.mp3s.com> <200110021239.HAA17289@fsgi158.americas.sgi.com> <20011002151459.C16538@de.tecosim.com> Subject: Re: IRIX 6.5.6m/XFS CVS: Any problems? Date: Tue, 2 Oct 2001 22:05:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Utz, So, in other words, I shouldn't have any problems checking out the XFS tree at kernel version 2.4.10? (At least based upon your knowledge) -Sean ----- Original Message ----- From: "Utz Lehmann" To: "Tad Dolphay" Cc: ; Sent: Tuesday, October 02, 2001 9:14 AM Subject: Re: IRIX 6.5.6m/XFS CVS: Any problems? > Tad Dolphay [tbd@sgi.com] wrote: > > > > > > Utz, > > > > > > Thanks for the information; do you know if this patch needs to be applied > > > for NFS v3 to work from IRIX to Linux? It looks really easy to apply > > > > For the most part NFS V3 will still work using a pre 6.5.13 IRIX client > > and 2.4 linux server. The problem is that sometimes when doing a pwd on a > > NFS mounted directory you won't see the entire path name. > > Yes, and the IRIX ftpd, Midnight Commander (mc), xemacs, ... are confused too. > > I just tested a 2.4.10 xfs kernel (with preempt patch, but _without_ the nfs > patch i had attached in my last mail). It's seems to work. My ftpd and mc > tests are ok. Tested with IRIX 6.5.3 and HP-UX 10.20. So you dont need the > patch for 2.4.10. > > > utz From owner-linux-xfs@oss.sgi.com Tue Oct 2 19:06:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9326M701279 for linux-xfs-outgoing; Tue, 2 Oct 2001 19:06:22 -0700 Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9326GD01258 for ; Tue, 2 Oct 2001 19:06:16 -0700 Received: from dhcp10 (static031-81-151-24.nm01-c3.cpe.charter-ne.com [24.151.81.31]) by falcon.mail.pas.earthlink.net (8.11.5/8.9.3) with SMTP id f9325h604282; Tue, 2 Oct 2001 19:05:44 -0700 (PDT) Message-ID: <015001c14baf$bcf4bbc0$0a00a8c0@intranet.mp3s.com> Reply-To: "Sean Elble" From: "Sean Elble" To: "Tad Dolphay" Cc: "Utz Lehmann" , References: <200110021239.HAA17289@fsgi158.americas.sgi.com> Subject: Re: IRIX 6.5.6m/XFS CVS: Any problems? Date: Tue, 2 Oct 2001 22:04:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk OK, thanks for the information. Do you know if the patch Utz sent me will fix any of those problems? Thanks again! -Sean ----- Original Message ----- From: "Tad Dolphay" To: Cc: "Utz Lehmann" ; Sent: Tuesday, October 02, 2001 8:39 AM Subject: Re: IRIX 6.5.6m/XFS CVS: Any problems? > > > > Utz, > > > > Thanks for the information; do you know if this patch needs to be applied > > for NFS v3 to work from IRIX to Linux? It looks really easy to apply > > For the most part NFS V3 will still work using a pre 6.5.13 IRIX client > and 2.4 linux server. The problem is that sometimes when doing a pwd on a > NFS mounted directory you won't see the entire path name. > > Tad > > manually if it doesn't apply automatically . . . I've been wrong before > > though. :-) Thanks again! > > > > -Sean > > ----- Original Message ----- > > From: "Utz Lehmann" > > To: "Steve Lord" > > Cc: "Sean Elble" ; > > Sent: Monday, October 01, 2001 10:31 AM > > Subject: Re: IRIX 6.5.6m/XFS CVS: Any problems? > > > > > > > Hi > > > > > > Steve Lord [lord@sgi.com] wrote: > > > > > Hello, > > > > > > > > > > I have a Silicon Graphics Indigo2 here with IRIX > > > > > 6.5.6m installed (love it, BTW), and a Linux server > > > > > that is about to have the latest CVS version of the > > > > > XFS kernel installed, along with the kernel-level NFS > > > > > server. > > > > > > > > > > Are there any known problems, or catches, using NFS on > > > > > IRIX with a Linux 2.4.10 server? I would like to use > > > > > NFS3, if possible, but I would appreciate any comments > > > > > any users may have. Thanks, in advance! > > > > > > > > > > > > > You may want to upgrade to the latest Irix release, there were some > > > > problems with NFS V3 between Linux and Irix. The Irix implementation > > > > expected the NFS file handles to be of a specific size, and Linux used > > > > a different size. I think this is fixed in 6.5.13. This only affected > > > > V3 NFS I think. > > > > > > > > Steve > > > > > > I had grabed a small patch for the linux nfs server on lkml. It's set the > > > file handle size on the linux nfs server to a value (older) IRIX Versions > > > (and HP-UX 10.20) can understand. I have used this patch till 2.4.9. Maybe > > > it works with 2.4.10 too. > > > It works for me, but use it at your own risk. > > > > > > Or use NFS v2. > > > > > > > > > utz > > > > > From owner-linux-xfs@oss.sgi.com Tue Oct 2 22:07:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9357DN04499 for linux-xfs-outgoing; Tue, 2 Oct 2001 22:07:13 -0700 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f93579D04480 for ; Tue, 2 Oct 2001 22:07:09 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f93573L16638 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Tue, 2 Oct 2001 22:07:03 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id HAA1675272 for ; Wed, 3 Oct 2001 07:06:17 +0200 (CEST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA78068 for linux-xfs@oss.sgi.com; Wed, 3 Oct 2001 15:05:36 +1000 (EST) Date: Wed, 3 Oct 2001 15:05:36 +1000 (EST) From: Nathan Scott Message-Id: <200110030505.PAA78068@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsprogs docs, mainly Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Oct 1 23:31:37 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:103748a linux/fs/xfs_support/kmem.c - 1.13 - we no longer need to pass in debug flags here for QA - this can now be done using just the standard kernel CONFIG options without any special case handling here. Date: Tue Oct 2 21:59:54 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:103848a cmd/xfsprogs/man/man8/xfs_bmap.8 - 1.2 cmd/xfsprogs/man/man3/handle.3 - 1.2 - fix up some minor typos. cmd/xfsprogs/man/man5/xfs.5 - 1.3 - fix typos. add a slew of documentation for the XFS-specific ioctls. cmd/xfsprogs/bmap/xfs_bmap.c - 1.4 - ensure we don't issue XFS ioctls against non-XFS file descriptors. cmd/xfsprogs/bmap/Makefile - 1.5 - remove an unused libtool argument. cmd/xfsprogs/doc/CHANGES - 1.39 cmd/xfsprogs/VERSION - 1.30 - bump to 1.3.9, document changes. From owner-linux-xfs@oss.sgi.com Tue Oct 2 22:33:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f935XNM05046 for linux-xfs-outgoing; Tue, 2 Oct 2001 22:33:23 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f935XGD05025 for ; Tue, 2 Oct 2001 22:33:16 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA06010 for ; Tue, 2 Oct 2001 22:32:09 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA94433 for linux-xfs@oss.sgi.com; Wed, 3 Oct 2001 15:31:58 +1000 (EST) Date: Wed, 3 Oct 2001 15:31:58 +1000 (EST) From: Nathan Scott Message-Id: <200110030531.PAA94433@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsdump inventory and FHS compliance Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Issue reported by the Debian folk, but affects all distributions. This is the first of two steps in fixing it. New xfsdump users will now use /var/lib path by default, but the previous location is maintained for backward compatibility with pre-existing xfsdump inventories. Ivan's new xfsinvutil will be able to convert one to the other, and also does all kinds of other nifty things. cheers. Date: Tue Oct 2 22:22:21 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:103849a cmd/xfsdump/inventory/inv_files.c - 1.1 cmd/xfsdump/inventory/inventory.h - 1.3 cmd/xfsdump/inventory/inv_mgr.c - 1.3 cmd/xfsdump/inventory/Makefile - 1.3 cmd/xfsdump/dump/var.h - 1.2 cmd/xfsdump/dump/var.c - 1.2 cmd/xfsdump/dump/Makefile - 1.8 cmd/xfsdump/common/types.h - 1.4 cmd/xfsdump/common/main.c - 1.13 cmd/xfsdump/common/inventory.h - 1.3 cmd/xfsdump/restore/Makefile - 1.8 cmd/xfsdump/inventory/inv_priv.h - 1.3 cmd/xfsdump/invutil/invutil.c - 1.5 cmd/xfsdump/invutil/Makefile - 1.4 cmd/xfsdump/debian/changelog - 1.13 cmd/xfsdump/doc/CHANGES - 1.23 cmd/xfsdump/man/man8/xfsdump.8 - 1.8 cmd/xfsdump/man/man8/xfsinvutil.8 - 1.2 cmd/xfsdump/man/man8/xfsrestore.8 - 1.5 cmd/xfstests/common.dump - 1.18 - First step toward making the xfsdump inventory not break the FHS spec. Previously, xfsdump wrote to /var/xfsdump for all its inventory data needs. This is now a runtime decision - for existing installations we continue doing just that, for new installations we use the compliant- with-FHS directory /var/lib/xfsdump. NOTE: cannot just mv one to the other as xfsdump is "clever" enough to keep full pathnames in some inventory files - this issue will be resolved by Ivan in an upcoming xfsinvutil checkin. cmd/xfsdump/common/Makefile - 1.7 cmd/xfsdump/common/stkchk.h - 1.2 cmd/xfsdump/common/stkchk.c - 1.3 cmd/xfsdump/common/inventory_priv.h - 1.3 cmd/xfsdump/common/inventory_priv.c - 1.3 - unused, removed. From owner-linux-xfs@oss.sgi.com Tue Oct 2 22:56:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f935uNc05486 for linux-xfs-outgoing; Tue, 2 Oct 2001 22:56:23 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f935uKD05467 for ; Tue, 2 Oct 2001 22:56:20 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f935uDK01271 for ; Tue, 2 Oct 2001 22:56:13 -0700 Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id PAA12161; Wed, 3 Oct 2001 15:56:08 +1000 Date: Wed, 3 Oct 2001 15:56:08 +1000 From: Keith Owens Message-Id: <200110030556.PAA12161@sherman.melbourne.sgi.com> Subject: TAKE - Remove ia32 XFS syscalls from ia64 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Somebody had patched the ia32 syscall table in ia64 to add the XFS ACL syscalls. The ia32 syscall table is only used by i32 binaries running on ia64, running ia32 on ia64 is only intended as a band aid for binaries which cannot be recompiled for ia64 proper. Since all ACL utilities can and should be recompiled for ia64 and since this patch is a big nuisance when porting XFS to ia64, I have removed it. Just use ia64 versions of XFS commands. Date: Tue Oct 2 22:51:22 PDT 2001 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:103850a linux/arch/ia64/ia32/ia32_entry.S - 1.13 linux/arch/ia64/kernel/ivt.S - 1.12 From owner-linux-xfs@oss.sgi.com Tue Oct 2 23:24:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f936Ott06078 for linux-xfs-outgoing; Tue, 2 Oct 2001 23:24:55 -0700 Received: from TYO202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.247.6.41]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f936OnD06059 for ; Tue, 2 Oct 2001 23:24:50 -0700 Received: from mailgate4.nec.co.jp ([10.7.69.195]) by TYO202.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id f936OmQ24151 for ; Wed, 3 Oct 2001 15:24:48 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id f936OlP05902 for ; Wed, 3 Oct 2001 15:24:47 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (THKTNES98740.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id f936OkX08045 for ; Wed, 3 Oct 2001 15:24:47 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA364 for ; Wed, 3 Oct 2001 15:24:45 +0900 Received: FROM tnesgate.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Wed Oct 03 15:24:43 2001 +0900 Received: from rifu.bsd.tnes.nec.co.jp (IDENT:root@rifu.bsd.tnes.nec.co.jp [10.1.101.142]) by tnesgate.tnes.nec.co.jp (8.9.3/3.7W00091816) with ESMTP id PAA76481 for ; Wed, 3 Oct 2001 15:24:44 +0900 (JST) Received: from tagajo.bsd.tnes.nec.co.jp (tagajo.bsd.tnes.nec.co.jp [10.1.101.146]) by rifu.bsd.tnes.nec.co.jp (8.10.2+3.3W/3.7W/BSD-TNES-MX01) with ESMTP id f936Oii24548 for ; Wed, 3 Oct 2001 15:24:44 +0900 Received: (from sasaki@localhost) by tagajo.bsd.tnes.nec.co.jp (8.8.5+2.7Wbeta5/3.5Wpl1-97090809) id PAA10888; Wed, 3 Oct 2001 15:24:44 +0900 (JST) Message-Id: <200110030624.PAA10888@tagajo.bsd.tnes.nec.co.jp> To: linux-xfs@oss.sgi.com Subject: Re: wbee (sample_hsm) dumped core In-reply-to: Your message of Fri, 28 Sep 2001 20:26:17 +0900. <200109281126.UAA22550@tagajo.bsd.tnes.nec.co.jp> Date: Wed, 03 Oct 2001 15:24:44 +0900 From: Takayuki Sasaki Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Takayuki Sasaki wrote: > migin daemon in sample_hsm started with the patch which I > posted, but if I try to read the migrated file then it > stalled. It was caused by > linux-2.4-xfs/cmd/xfstests/dmapi/src/sample_hsm/wbee which was > dispatched by migin dumped core. In the above situation, I killed the stalled command ( cp ) and migin by pressing Ctrl + c to find out what is wrong. Then, unmount the XFS file system, the following console messages appeared: XFS unmount got error 16 linvfs_put_super: vfsp/0xc2acb38c left dangling! VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day... I am wondering whether this is a problem or not because if sample_hsm/mrmean -v -k -s session_no is executed before unmounting the filesystem, these messages does not occur. When I saw this, the kernel was 2.4.7-pre6, and I verified just now the same thing occur on the CVS kernel complied at Tue Oct 2 08:33:33 JST 2001 ( including the dmapi patches except wbee ). Any comments? --- Takayuki From owner-linux-xfs@oss.sgi.com Tue Oct 2 23:25:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f936Pkp06189 for linux-xfs-outgoing; Tue, 2 Oct 2001 23:25:46 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f936PiD06168 for ; Tue, 2 Oct 2001 23:25:44 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id XAA06521 for ; Tue, 2 Oct 2001 23:24:37 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id QAA13893; Wed, 3 Oct 2001 16:25:32 +1000 Date: Wed, 3 Oct 2001 16:25:32 +1000 From: Keith Owens Message-Id: <200110030625.QAA13893@sherman.melbourne.sgi.com> Subject: TAKE - Sync with kbuild-2.5 for 2.4.10 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sync with kbuild-2.5 for 2.4.10 Date: Tue Oct 2 23:23:47 PDT 2001 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:103853a linux/arch/i386/Makefile.in.append - 1.1 linux/arch/ia64/Makefile.in.append - 1.1 linux/Makefile.in.prepend - 1.2 From owner-linux-xfs@oss.sgi.com Tue Oct 2 23:34:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f936Y3Q06492 for linux-xfs-outgoing; Tue, 2 Oct 2001 23:34:03 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f936XwD06472 for ; Tue, 2 Oct 2001 23:33:58 -0700 Received: from TYO202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.247.6.41]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAB09293 for ; Tue, 2 Oct 2001 23:32:53 -0700 (PDT) mail_from (sasaki@bsd.tnes.nec.co.jp) Received: from mailgate4.nec.co.jp ([10.7.69.195]) by TYO202.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id f936OmQ24151 for ; Wed, 3 Oct 2001 15:24:48 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id f936OlP05902 for ; Wed, 3 Oct 2001 15:24:47 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (THKTNES98740.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id f936OkX08045 for ; Wed, 3 Oct 2001 15:24:47 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA364 for ; Wed, 3 Oct 2001 15:24:45 +0900 Received: FROM tnesgate.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Wed Oct 03 15:24:43 2001 +0900 Received: from rifu.bsd.tnes.nec.co.jp (IDENT:root@rifu.bsd.tnes.nec.co.jp [10.1.101.142]) by tnesgate.tnes.nec.co.jp (8.9.3/3.7W00091816) with ESMTP id PAA76481 for ; Wed, 3 Oct 2001 15:24:44 +0900 (JST) Received: from tagajo.bsd.tnes.nec.co.jp (tagajo.bsd.tnes.nec.co.jp [10.1.101.146]) by rifu.bsd.tnes.nec.co.jp (8.10.2+3.3W/3.7W/BSD-TNES-MX01) with ESMTP id f936Oii24548 for ; Wed, 3 Oct 2001 15:24:44 +0900 Received: (from sasaki@localhost) by tagajo.bsd.tnes.nec.co.jp (8.8.5+2.7Wbeta5/3.5Wpl1-97090809) id PAA10888; Wed, 3 Oct 2001 15:24:44 +0900 (JST) Message-Id: <200110030624.PAA10888@tagajo.bsd.tnes.nec.co.jp> To: linux-xfs@oss.sgi.com Subject: Re: wbee (sample_hsm) dumped core In-reply-to: Your message of Fri, 28 Sep 2001 20:26:17 +0900. <200109281126.UAA22550@tagajo.bsd.tnes.nec.co.jp> Date: Wed, 03 Oct 2001 15:24:44 +0900 From: Takayuki Sasaki Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Takayuki Sasaki wrote: > migin daemon in sample_hsm started with the patch which I > posted, but if I try to read the migrated file then it > stalled. It was caused by > linux-2.4-xfs/cmd/xfstests/dmapi/src/sample_hsm/wbee which was > dispatched by migin dumped core. In the above situation, I killed the stalled command ( cp ) and migin by pressing Ctrl + c to find out what is wrong. Then, unmount the XFS file system, the following console messages appeared: XFS unmount got error 16 linvfs_put_super: vfsp/0xc2acb38c left dangling! VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day... I am wondering whether this is a problem or not because if sample_hsm/mrmean -v -k -s session_no is executed before unmounting the filesystem, these messages does not occur. When I saw this, the kernel was 2.4.7-pre6, and I verified just now the same thing occur on the CVS kernel complied at Tue Oct 2 08:33:33 JST 2001 ( including the dmapi patches except wbee ). Any comments? --- Takayuki From owner-linux-xfs@oss.sgi.com Wed Oct 3 09:22:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f93GM4b18062 for linux-xfs-outgoing; Wed, 3 Oct 2001 09:22:04 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f93GM1D18043 for ; Wed, 3 Oct 2001 09:22:02 -0700 Received: from clink-eth.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA02868 for ; Wed, 3 Oct 2001 09:21:38 -0700 (PDT) mail_from (roehrich@clink-eth.americas.sgi.com) Received: (from roehrich@localhost) by clink-eth.americas.sgi.com (SGI-8.9.3/8.9.3) id LAA10706 for linux-xfs@oss.sgi.com; Wed, 3 Oct 2001 11:19:31 -0500 (CDT) Date: Wed, 3 Oct 2001 11:19:31 -0500 (CDT) From: Dean Roehrich Message-Id: <200110031619.LAA10706@clink-eth.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - Cleanup for dmapi test migin Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Wed Oct 3 09:18:54 PDT 2001 Workarea: clink-eth.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:103869a cmd/xfstests/dmapi/src/sample_hsm/migin.c - 1.4 - - Add newlines to some error messages. - Allow it to daemonize itself. - Do not daemonize if user requested verbose output. - Get signal handlers set, whether or not daemonized. - Use execlp instead of execl, to alleviate some guesswork about where it expects to find wbee. - Fix cleanup routine so it can cleanup the session--mostly, remove all the fancy stuff that wasn't looking for the right thing anyway. From owner-linux-xfs@oss.sgi.com Wed Oct 3 09:39:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f93GdQY18515 for linux-xfs-outgoing; Wed, 3 Oct 2001 09:39:26 -0700 Received: from localhost.localdomain (dsl-64-130-65-177.telocity.com [64.130.65.177]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f93GdID18496 for ; Wed, 3 Oct 2001 09:39:18 -0700 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id f93Ghmq12492 for ; Wed, 3 Oct 2001 09:43:49 -0700 Subject: [Fwd: *** ANNOUNCEMENT *** LVM 1.0.1-rc3 available at www.sistina.com] From: Thomas Duffy To: linux-xfs@oss.sgi.com Content-Type: multipart/mixed; boundary="=-cIpPaX3PwvixZCiD0w3Y" X-Mailer: Evolution/0.14 (Preview Release) Date: 03 Oct 2001 09:43:47 -0700 Message-Id: <1002127429.12479.7.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-cIpPaX3PwvixZCiD0w3Y Content-Type: text/plain Content-Transfer-Encoding: 7bit so, is this going to be merged into the xfs tree now that it is backwards compatible with 0.9.x? -tduffy --=-cIpPaX3PwvixZCiD0w3Y Content-Disposition: inline Content-Description: Forwarded message - *** ANNOUNCEMENT *** LVM 1.0.1-rc3 available at www.sistina.com Content-Type: message/rfc822 Received: from afara-gw.afara.com ([10.2.4.30]) by afara-ex.afara.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 3 Oct 2001 00:55:21 -0700 Received: from www2000 ([209.39.16.169]) by afara-gw.afara.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 3 Oct 2001 00:55:20 -0700 Resent-To: tduffy@afara.com Resent-From: Thomas.Duffy.99@alumni.brown.edu Resent-Message-Id: Resent-Date: Wed, 3 Oct 2001 02:53:32 -0500 Received: from vger.kernel.org (unverified [199.183.24.194]) by www2000 (Rockliffe SMTPRA 4.5.4) with SMTP id for ; Wed, 3 Oct 2001 02:53:32 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 3 Oct 2001 03:54:16 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 3 Oct 2001 03:54:07 -0400 Received: from p3EE3E475.dip.t-dialin.net ([62.227.228.117]:44302 "EHLO srv.sistina.com") by vger.kernel.org with ESMTP id ; Wed, 3 Oct 2001 03:53:56 -0400 Received: (from root@localhost) by srv.sistina.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id JAA19835; Wed, 3 Oct 2001 09:53:39 +0200 Date: Wed, 3 Oct 2001 09:53:39 +0200 From: "Heinz J . Mauelshagen" To: linux-kernel@vger.kernel.org Cc: mge@sistina.com Subject: *** ANNOUNCEMENT *** LVM 1.0.1-rc3 available at www.sistina.com Message-ID: <20011003095339.A19833@sistina.com> Reply-To: mauelshagen@sistina.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i X-Sender: mauelshagen@sistina.com Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: linux-kernel-owner@vger.kernel.org X-OriginalArrivalTime: 03 Oct 2001 07:55:20.0921 (UTC) FILETIME=[C0022C90:01C14BE0] Hi all, LVM 1.0.1-rc3 supports both version 1 and 2 of the metadata. There's *no* need to run any metadata update tools. A tarball is available now at for download (Follow the "LVM 1.0" link). This release contains minor changes to LVM 1.0.1-rc2. See the CHANGELOG file contained in the tarball for further information. Feed back LVM related information to . Thanks a lot for your support of LVM. Regards, Heinz -- The LVM Guy -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Heinz Mauelshagen Sistina Software Inc. Senior Consultant/Developer Am Sonnenhang 11 56242 Marienrachdorf Germany Mauelshagen@Sistina.com +49 2626 141200 FAX 924446 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ --=-cIpPaX3PwvixZCiD0w3Y-- From owner-linux-xfs@oss.sgi.com Wed Oct 3 13:03:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f93K3kU22852 for linux-xfs-outgoing; Wed, 3 Oct 2001 13:03:46 -0700 Received: from sws5.ctd.ornl.gov (sws5.ctd.ornl.gov [160.91.20.105]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f93K3iD22833 for ; Wed, 3 Oct 2001 13:03:44 -0700 Received: (qmail 10155 invoked by uid 3995); 3 Oct 2001 20:03:42 -0000 From: "Dave Sill" Mail-Followup-To: linux-xfs@oss.sgi.com To: linux-xfs@oss.sgi.com Subject: newfs speed? Date: 03 Oct 2001 16:03:42 -0400 Message-ID: Lines: 5 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Academic Rigor) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Delivery-Agent: TMDA v0.36/Python 1.5.2 (linux-i386) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've got a 200GB h/w RAID 5 that I want to convert from e2fs to XFS. It takes ~8 hours to fsck it now. About how long will it take to newfs as XFS? -Dave From owner-linux-xfs@oss.sgi.com Wed Oct 3 13:12:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f93KCB023105 for linux-xfs-outgoing; Wed, 3 Oct 2001 13:12:11 -0700 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f93KC9D23086 for ; Wed, 3 Oct 2001 13:12:09 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f93KC3L02314 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Wed, 3 Oct 2001 13:12:03 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id WAA1726781 for ; Wed, 3 Oct 2001 22:12:31 +0200 (CEST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA3137574; Wed, 3 Oct 2001 15:10:43 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id PAA13380; Wed, 3 Oct 2001 15:10:42 -0500 (CDT) Subject: Re: newfs speed? From: Eric Sandeen To: Dave Sill Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.14 (Preview Release) Date: 03 Oct 2001 15:07:43 -0500 Message-Id: <1002139663.26431.27.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2001-10-03 at 15:03, Dave Sill wrote: > I've got a 200GB h/w RAID 5 that I want to convert from e2fs to > XFS. It takes ~8 hours to fsck it now. About how long will it take to > newfs as XFS? By "newfs" I assume you mean mkfs.xfs? That shouldn't take long at all... certainly not long compared to the time it might take to restore your data on the new filesystem... -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Oct 3 13:12:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f93KCVP23225 for linux-xfs-outgoing; Wed, 3 Oct 2001 13:12:31 -0700 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f93KCTD23206 for ; Wed, 3 Oct 2001 13:12:29 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f93KCNL02346 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Wed, 3 Oct 2001 13:12:23 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id WAA1745877 for ; Wed, 3 Oct 2001 22:12:52 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA3126770; Wed, 3 Oct 2001 15:11:02 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA01529; Wed, 3 Oct 2001 15:11:02 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f93KAoK28151; Wed, 3 Oct 2001 15:10:50 -0500 Message-Id: <200110032010.f93KAoK28151@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Dave Sill" cc: linux-xfs@oss.sgi.com Subject: Re: newfs speed? In-Reply-To: Message from "Dave Sill" of "03 Oct 2001 16:03:42 EDT." Date: Wed, 03 Oct 2001 15:10:49 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I've got a 200GB h/w RAID 5 that I want to convert from e2fs to > XFS. It takes ~8 hours to fsck it now. About how long will it take to > newfs as XFS? > > -Dave About the time it took to write your question - well maybe a few seconds more. Steve From owner-linux-xfs@oss.sgi.com Wed Oct 3 13:13:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f93KDto23375 for linux-xfs-outgoing; Wed, 3 Oct 2001 13:13:55 -0700 Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f93KDqD23356 for ; Wed, 3 Oct 2001 13:13:52 -0700 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.6/8.11.6) with ESMTP id f93KDoK26913; Wed, 3 Oct 2001 16:13:51 -0400 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Wed, 3 Oct 2001 16:13:50 -0400 (EDT) From: Joshua Baker-LePain X-X-Sender: To: Dave Sill cc: Subject: Re: newfs speed? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 3 Oct 2001 at 4:03pm, Dave Sill wrote > I've got a 200GB h/w RAID 5 that I want to convert from e2fs to > XFS. It takes ~8 hours to fsck it now. About how long will it take to > newfs as XFS? mkfs will take about 5 seconds (if that). Ditto for recovery after a hard crash (as witnessed by me when the system drive of the box hosting my 560GB h/w RAID died). Does that work for you? ;) -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Wed Oct 3 13:15:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f93KFdR23529 for linux-xfs-outgoing; Wed, 3 Oct 2001 13:15:39 -0700 Received: from chef.cc.absoval.com (cpe-66-1-218-101.fl.sprintbbd.net [66.1.218.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f93KFaD23510 for ; Wed, 3 Oct 2001 13:15:37 -0700 Received: from ieee.org (IDENT:bs@thebs.cc.absoval.com [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id QAA17383; Wed, 3 Oct 2001 16:15:29 -0400 Message-ID: <3BBB71E2.C0DC311B@ieee.org> Date: Wed, 03 Oct 2001 16:15:30 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts/AbsoluteValueSystems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Dave Sill CC: linux-xfs@oss.sgi.com Subject: Re: newfs speed? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dave Sill wrote: > I've got a 200GB h/w RAID 5 that I want to convert from e2fs to > XFS. It takes ~8 hours to fsck it now. About how long will it take to > newfs as XFS? Near-instantenous, because XFS creates inodes on-the-fly. Now if you want to convert to XFS, that's a whole different story. Backup and restore works fastest. ;-PPP -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com From owner-linux-xfs@oss.sgi.com Wed Oct 3 13:18:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f93KIue23685 for linux-xfs-outgoing; Wed, 3 Oct 2001 13:18:56 -0700 Received: from cis.ohio-state.edu (root@mail.cis.ohio-state.edu [164.107.115.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f93KIqD23666 for ; Wed, 3 Oct 2001 13:18:52 -0700 Received: from cis.ohio-state.edu (blitz.cis.ohio-state.edu [164.107.60.170]) by cis.ohio-state.edu (8.9.1/8.9.1) with ESMTP id QAA21643 for ; Wed, 3 Oct 2001 16:18:52 -0400 (EDT) Message-ID: <3BBB728E.9AE20CF7@cis.ohio-state.edu> Date: Wed, 03 Oct 2001 16:18:22 -0400 From: Arun Ramakrishnan Organization: Cluster I/O Lab,CIS Dept, The Ohio State Univ X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: newfs speed? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, One our 120 GB RAID disk, mkfs took abt 10 seconds and of course recovery of a crashed fs is nearly instantaneous when compared to fsck.Also the file system is extremely stable when bombared with single files as large as 3 GB:-) Dont think one can ask for much more. Cheers, Arun Joshua Baker-LePain wrote: > On 3 Oct 2001 at 4:03pm, Dave Sill wrote > > > I've got a 200GB h/w RAID 5 that I want to convert from e2fs to > > XFS. It takes ~8 hours to fsck it now. About how long will it take to > > newfs as XFS? > > mkfs will take about 5 seconds (if that). Ditto for recovery after a hard > crash (as witnessed by me when the system drive of the box hosting my > 560GB h/w RAID died). Does that work for you? ;) > > -- > Joshua Baker-LePain > Department of Biomedical Engineering > Duke University -- Arun Ramakrishnan Graduate Research Assistant / Sys Admin Cluster I/O Lab The Ohio State University Ph : (614)-294-5523 (H) (614)-292-8458 (O) From owner-linux-xfs@oss.sgi.com Wed Oct 3 14:17:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f93LH0N24941 for linux-xfs-outgoing; Wed, 3 Oct 2001 14:17:00 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f93LFtD24910 for ; Wed, 3 Oct 2001 14:15:55 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA08835 for ; Wed, 3 Oct 2001 14:15:53 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA3134135 for ; Wed, 3 Oct 2001 16:14:02 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA76075 for ; Wed, 3 Oct 2001 16:14:02 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id f93LDnK28359; Wed, 3 Oct 2001 16:13:49 -0500 Message-Id: <200110032113.f93LDnK28359@jen.americas.sgi.com> Date: Wed, 3 Oct 2001 16:13:49 -0500 Subject: TAKE - merge up to 2.4.11-pre2 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seems to behave pretty well as far as xfs is concerned. There is an updated 2.4.10 patch on the ftp site for those of you who want to stick with 2.4.10 for now. Steve Date: Wed Oct 3 14:08:38 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:103889a linux/drivers/char/mwave/tp3780i.c - 1.1 linux/drivers/char/mwave/smapi.c - 1.1 linux/drivers/char/mwave/3780i.h - 1.1 linux/drivers/char/mwave/mwavepub.h - 1.1 linux/drivers/char/mwave/mwavedd.h - 1.1 linux/drivers/char/mwave/mwavedd.c - 1.1 linux/drivers/char/mwave/README - 1.1 linux/drivers/char/mwave/Makefile - 1.1 linux/drivers/char/mwave/tp3780i.h - 1.1 linux/drivers/char/mwave/3780i.c - 1.1 linux/drivers/char/mwave/smapi.h - 1.1 linux/net/sunrpc/xdr.c - 1.6 linux/net/sunrpc/sched.c - 1.20 linux/net/socket.c - 1.25 linux/net/sched/sch_teql.c - 1.11 linux/net/sched/sch_tbf.c - 1.10 linux/net/sched/sch_sfq.c - 1.4 linux/net/sched/sch_red.c - 1.8 linux/net/sched/sch_prio.c - 1.5 linux/net/sched/sch_csz.c - 1.4 linux/net/sched/sch_cbq.c - 1.12 linux/net/sched/cls_u32.c - 1.7 linux/net/sched/cls_rsvp6.c - 1.3 linux/net/sched/cls_rsvp.c - 1.3 linux/net/sched/cls_route.c - 1.6 linux/net/sched/cls_fw.c - 1.5 linux/net/irda/irlan/irlan_common.c - 1.16 linux/net/irda/af_irda.c - 1.27 linux/net/ipx/af_ipx.c - 1.24 linux/net/ipv6/tcp_ipv6.c - 1.27 linux/net/ipv6/sit.c - 1.18 linux/net/ipv6/af_inet6.c - 1.18 linux/net/ipv4/tcp_timer.c - 1.22 linux/net/ipv4/tcp_output.c - 1.23 linux/net/ipv4/tcp_ipv4.c - 1.35 linux/net/ipv4/tcp_input.c - 1.30 linux/net/ipv4/tcp.c - 1.33 linux/net/ipv4/ipip.c - 1.19 linux/net/ipv4/ipconfig.c - 1.18 linux/net/ipv4/ip_gre.c - 1.17 linux/net/ipv4/devinet.c - 1.13 linux/net/core/neighbour.c - 1.12 linux/net/core/dev.c - 1.44 linux/net/bridge/br.c - 1.19 linux/net/appletalk/aarp.c - 1.12 linux/mm/vmscan.c - 1.77 linux/mm/page_alloc.c - 1.56 linux/mm/mmap.c - 1.42 linux/mm/memory.c - 1.63 linux/mm/filemap.c - 1.89 linux/kernel/sysctl.c - 1.42 linux/kernel/panic.c - 1.15 linux/kernel/ksyms.c - 1.112 linux/ipc/sem.c - 1.15 linux/init/main.c - 1.59 linux/include/net/tcp.h - 1.25 linux/include/linux/timer.h - 1.11 linux/include/linux/sysrq.h - 1.6 linux/include/linux/sysctl.h - 1.40 linux/include/linux/swap.h - 1.42 linux/include/linux/slab.h - 1.18 linux/include/linux/sem.h - 1.7 linux/include/linux/pagemap.h - 1.30 linux/include/linux/nfs_fs_i.h - 1.9 linux/include/linux/module.h - 1.23 linux/include/linux/mm.h - 1.67 linux/include/linux/miscdevice.h - 1.11 linux/include/linux/lockd/nlm.h - 1.5 linux/include/linux/lockd/lockd.h - 1.7 linux/include/linux/list.h - 1.9 linux/include/linux/kernel.h - 1.27 linux/include/linux/isdnif.h - 1.13 linux/include/linux/isdn_ppp.h - 1.10 linux/include/linux/isdn.h - 1.19 linux/include/linux/fs.h - 1.122 linux/include/linux/concap.h - 1.6 linux/include/linux/capi.h - 1.5 linux/include/linux/blkdev.h - 1.39 linux/include/asm-sparc64/uaccess.h - 1.6 linux/include/asm-sparc64/string.h - 1.8 linux/include/asm-sparc64/spitfire.h - 1.6 linux/include/asm-sparc64/shmparam.h - 1.5 linux/include/asm-sparc64/ide.h - 1.9 linux/include/asm-sparc/uaccess.h - 1.7 linux/include/asm-i386/unistd.h - 1.16 linux/fs/umsdos/inode.c - 1.19 linux/fs/smbfs/inode.c - 1.24 linux/fs/romfs/inode.c - 1.25 linux/fs/qnx4/inode.c - 1.25 linux/fs/proc/inode.c - 1.15 linux/fs/pipe.c - 1.23 linux/fs/ntfs/inode.c - 1.13 linux/fs/ntfs/fs.c - 1.32 linux/fs/ntfs/Makefile - 1.13 linux/fs/nls/nls_cp874.c - 1.6 linux/fs/nls/nls_cp869.c - 1.6 linux/fs/nls/nls_cp866.c - 1.6 linux/fs/nls/nls_cp865.c - 1.6 linux/fs/nls/nls_cp864.c - 1.6 linux/fs/nls/nls_cp863.c - 1.6 linux/fs/nls/nls_cp862.c - 1.6 linux/fs/nls/nls_cp861.c - 1.6 linux/fs/nls/nls_cp860.c - 1.6 linux/fs/nls/nls_cp857.c - 1.6 linux/fs/nls/nls_cp855.c - 1.6 linux/fs/nls/nls_cp852.c - 1.6 linux/fs/nls/nls_cp850.c - 1.6 linux/fs/nls/nls_cp775.c - 1.6 linux/fs/nls/nls_cp737.c - 1.6 linux/fs/nls/nls_cp437.c - 1.6 linux/fs/nfs/write.c - 1.28 linux/fs/nfs/inode.c - 1.29 linux/fs/ncpfs/inode.c - 1.22 linux/fs/minix/inode.c - 1.23 linux/fs/lockd/xdr.c - 1.12 linux/fs/lockd/svcsubs.c - 1.8 linux/fs/lockd/svcproc.c - 1.7 linux/fs/lockd/svc.c - 1.11 linux/fs/lockd/mon.c - 1.9 linux/fs/lockd/lockd_syms.c - 1.5 linux/fs/lockd/host.c - 1.8 linux/fs/lockd/clntlock.c - 1.10 linux/fs/inode.c - 1.55 linux/fs/ext2/super.c - 1.19 linux/fs/ext2/inode.c - 1.30 linux/fs/devpts/inode.c - 1.11 linux/fs/buffer.c - 1.84 linux/fs/block_dev.c - 1.28 linux/fs/binfmt_elf.c - 1.32 linux/fs/binfmt_aout.c - 1.23 linux/fs/autofs/init.c - 1.7 linux/fs/affs/inode.c - 1.15 linux/fs/adfs/inode.c - 1.18 linux/drivers/video/fbgen.c - 1.7 linux/drivers/usb/usb.c - 1.55 linux/drivers/sound/wavfront.c - 1.20 linux/drivers/sound/v_midi.c - 1.7 linux/drivers/sound/uart6850.c - 1.9 linux/drivers/sound/uart401.c - 1.9 linux/drivers/sound/trix.c - 1.11 linux/drivers/sound/sscape.c - 1.12 linux/drivers/sound/soundcard.c - 1.20 linux/drivers/sound/sound_core.c - 1.19 linux/drivers/sound/sonicvibes.c - 1.35 linux/drivers/sound/sgalaxy.c - 1.9 linux/drivers/sound/sb_mixer.c - 1.10 linux/drivers/sound/sb_common.c - 1.19 linux/drivers/sound/sb_card.c - 1.28 linux/drivers/sound/pss.c - 1.10 linux/drivers/sound/pas2_card.c - 1.6 linux/drivers/sound/opl3sa2.c - 1.10 linux/drivers/sound/opl3sa.c - 1.9 linux/drivers/sound/opl3.c - 1.9 linux/drivers/sound/msnd_pinnacle.c - 1.19 linux/drivers/sound/msnd.c - 1.8 linux/drivers/sound/mpu401.c - 1.12 linux/drivers/sound/midibuf.c - 1.8 linux/drivers/sound/maui.c - 1.9 linux/drivers/sound/mad16.c - 1.14 linux/drivers/sound/gus_card.c - 1.7 linux/drivers/sound/es1371.c - 1.35 linux/drivers/sound/es1370.c - 1.34 linux/drivers/sound/cs4232.c - 1.10 linux/drivers/sound/adlib_card.c - 1.9 linux/drivers/sound/ad1848.c - 1.13 linux/drivers/sound/ad1816.c - 1.12 linux/drivers/scsi/wd7000.c - 1.12 linux/drivers/scsi/ultrastor.c - 1.10 linux/drivers/scsi/u14-34f.c - 1.16 linux/drivers/scsi/tmscsim.c - 1.13 linux/drivers/scsi/t128.c - 1.8 linux/drivers/scsi/sym53c8xx.c - 1.26 linux/drivers/scsi/sym53c416.c - 1.10 linux/drivers/scsi/st.c - 1.32 linux/drivers/scsi/sr.c - 1.28 linux/drivers/scsi/sg.c - 1.22 linux/drivers/scsi/seagate.c - 1.14 linux/drivers/scsi/sd.c - 1.45 linux/drivers/scsi/scsi_debug.c - 1.14 linux/drivers/scsi/scsi.c - 1.39 linux/drivers/scsi/qlogicisp.c - 1.23 linux/drivers/scsi/qlogicfc.c - 1.22 linux/drivers/scsi/qlogicfas.c - 1.9 linux/drivers/scsi/psi240i.c - 1.7 linux/drivers/scsi/ppa.c - 1.12 linux/drivers/scsi/pci2220i.c - 1.19 linux/drivers/scsi/pci2000.c - 1.16 linux/drivers/scsi/pas16.c - 1.9 linux/drivers/scsi/ncr53c8xx.c - 1.22 linux/drivers/scsi/megaraid.c - 1.28 linux/drivers/scsi/inia100.c - 1.16 linux/drivers/scsi/ini9100u.c - 1.15 linux/drivers/scsi/in2000.c - 1.9 linux/drivers/scsi/imm.c - 1.12 linux/drivers/scsi/ide-scsi.c - 1.17 linux/drivers/scsi/gdth.c - 1.16 linux/drivers/scsi/g_NCR5380.c - 1.12 linux/drivers/scsi/fdomain.c - 1.16 linux/drivers/scsi/fd_mcs.c - 1.6 linux/drivers/scsi/eata_pio.c - 1.14 linux/drivers/scsi/eata_dma.c - 1.17 linux/drivers/scsi/eata.c - 1.17 linux/drivers/scsi/dtc.c - 1.8 linux/drivers/scsi/atp870u.c - 1.18 linux/drivers/scsi/aha1740.c - 1.7 linux/drivers/scsi/aha1542.c - 1.18 linux/drivers/scsi/aha152x.c - 1.23 linux/drivers/scsi/advansys.c - 1.19 linux/drivers/scsi/NCR53c406a.c - 1.11 linux/drivers/scsi/NCR53C9x.c - 1.11 linux/drivers/scsi/Makefile - 1.29 linux/drivers/scsi/Config.in - 1.24 linux/drivers/scsi/BusLogic.c - 1.13 linux/drivers/scsi/AM53C974.c - 1.12 linux/drivers/scsi/53c7xx.c - 1.13 linux/drivers/scsi/53c7,8xx.c - 1.14 linux/drivers/net/yellowfin.c - 1.26 linux/drivers/net/wd.c - 1.15 linux/drivers/net/wavelan.c - 1.22 linux/drivers/net/via-rhine.c - 1.28 linux/drivers/net/tlan.c - 1.22 linux/drivers/net/sunhme.c - 1.31 linux/drivers/net/strip.c - 1.15 linux/drivers/net/smc-ultra32.c - 1.13 linux/drivers/net/smc-ultra.c - 1.18 linux/drivers/net/slip.c - 1.17 linux/drivers/net/slhc.c - 1.11 linux/drivers/net/shaper.c - 1.19 linux/drivers/net/rcpci45.c - 1.20 linux/drivers/net/ppp_deflate.c - 1.6 linux/drivers/net/plip.c - 1.21 linux/drivers/net/pcnet32.c - 1.26 linux/drivers/net/ni65.c - 1.11 linux/drivers/net/ni52.c - 1.14 linux/drivers/net/ni5010.c - 1.15 linux/drivers/net/ne3210.c - 1.13 linux/drivers/net/ne2k-pci.c - 1.22 linux/drivers/net/ne.c - 1.19 linux/drivers/net/lne390.c - 1.14 linux/drivers/net/lance.c - 1.21 linux/drivers/net/irda/w83977af_ir.c - 1.20 linux/drivers/net/irda/tekram.c - 1.8 linux/drivers/net/irda/irtty.c - 1.23 linux/drivers/net/irda/irport.c - 1.23 linux/drivers/net/irda/girbil.c - 1.10 linux/drivers/net/irda/esi.c - 1.8 linux/drivers/net/irda/actisys.c - 1.9 linux/drivers/net/hp100.c - 1.18 linux/drivers/net/hp.c - 1.14 linux/drivers/net/hp-plus.c - 1.15 linux/drivers/net/ewrk3.c - 1.19 linux/drivers/net/ethertap.c - 1.11 linux/drivers/net/eth16i.c - 1.20 linux/drivers/net/es3210.c - 1.15 linux/drivers/net/eql.c - 1.15 linux/drivers/net/epic100.c - 1.25 linux/drivers/net/eexpress.c - 1.17 linux/drivers/net/eepro100.c - 1.33 linux/drivers/net/eepro.c - 1.21 linux/drivers/net/e2100.c - 1.15 linux/drivers/net/dummy.c - 1.10 linux/drivers/net/dgrs.c - 1.20 linux/drivers/net/depca.c - 1.17 linux/drivers/net/defxx.c - 1.18 linux/drivers/net/de620.c - 1.13 linux/drivers/net/de600.c - 1.16 linux/drivers/net/de4x5.c - 1.22 linux/drivers/net/cs89x0.c - 1.20 linux/drivers/net/bsd_comp.c - 1.7 linux/drivers/net/atp.c - 1.16 linux/drivers/net/at1700.c - 1.13 linux/drivers/net/acenic.c - 1.31 linux/drivers/net/ac3200.c - 1.16 linux/drivers/net/8390.c - 1.23 linux/drivers/net/82596.c - 1.19 linux/drivers/net/3c59x.c - 1.30 linux/drivers/net/3c515.c - 1.20 linux/drivers/net/3c509.c - 1.25 linux/drivers/net/3c507.c - 1.20 linux/drivers/net/3c505.c - 1.22 linux/drivers/net/3c503.c - 1.19 linux/drivers/net/3c501.c - 1.15 linux/drivers/isdn/sc/timer.c - 1.5 linux/drivers/isdn/sc/shmem.c - 1.3 linux/drivers/isdn/sc/scioc.h - 1.3 linux/drivers/isdn/sc/packet.c - 1.4 linux/drivers/isdn/sc/message.h - 1.3 linux/drivers/isdn/sc/message.c - 1.5 linux/drivers/isdn/sc/ioctl.c - 1.4 linux/drivers/isdn/sc/interrupt.c - 1.5 linux/drivers/isdn/sc/init.c - 1.6 linux/drivers/isdn/sc/includes.h - 1.4 linux/drivers/isdn/sc/hardware.h - 1.3 linux/drivers/isdn/sc/event.c - 1.3 linux/drivers/isdn/sc/debug.h - 1.5 linux/drivers/isdn/sc/debug.c - 1.6 linux/drivers/isdn/sc/command.c - 1.3 linux/drivers/isdn/sc/card.h - 1.3 linux/drivers/isdn/pcbit/pcbit.h - 1.7 linux/drivers/isdn/pcbit/module.c - 1.8 linux/drivers/isdn/pcbit/layer2.h - 1.6 linux/drivers/isdn/pcbit/layer2.c - 1.8 linux/drivers/isdn/pcbit/edss1.h - 1.4 linux/drivers/isdn/pcbit/edss1.c - 1.5 linux/drivers/isdn/pcbit/drv.c - 1.13 linux/drivers/isdn/pcbit/capi.h - 1.4 linux/drivers/isdn/pcbit/capi.c - 1.6 linux/drivers/isdn/pcbit/callbacks.h - 1.4 linux/drivers/isdn/pcbit/callbacks.c - 1.5 linux/drivers/isdn/isdnloop/isdnloop.h - 1.8 linux/drivers/isdn/isdnloop/isdnloop.c - 1.10 linux/drivers/isdn/isdn_x25iface.h - 1.4 linux/drivers/isdn/isdn_x25iface.c - 1.6 linux/drivers/isdn/isdn_v110.h - 1.6 linux/drivers/isdn/isdn_v110.c - 1.9 linux/drivers/isdn/isdn_tty.h - 1.10 linux/drivers/isdn/isdn_tty.c - 1.17 linux/drivers/isdn/isdn_ppp.h - 1.7 linux/drivers/isdn/isdn_ppp.c - 1.18 linux/drivers/isdn/isdn_net.h - 1.10 linux/drivers/isdn/isdn_net.c - 1.25 linux/drivers/isdn/isdn_concap.h - 1.4 linux/drivers/isdn/isdn_concap.c - 1.7 linux/drivers/isdn/isdn_common.h - 1.8 linux/drivers/isdn/isdn_common.c - 1.29 linux/drivers/isdn/isdn_audio.h - 1.5 linux/drivers/isdn/isdn_audio.c - 1.10 linux/drivers/isdn/icn/icn.h - 1.10 linux/drivers/isdn/icn/icn.c - 1.17 linux/drivers/isdn/hisax/teles3.c - 1.12 linux/drivers/isdn/hisax/teles0.c - 1.12 linux/drivers/isdn/hisax/teleint.c - 1.11 linux/drivers/isdn/hisax/tei.c - 1.9 linux/drivers/isdn/hisax/sportster.c - 1.11 linux/drivers/isdn/hisax/sedlbauer.c - 1.17 linux/drivers/isdn/hisax/rawhdlc.h - 1.5 linux/drivers/isdn/hisax/rawhdlc.c - 1.6 linux/drivers/isdn/hisax/q931.c - 1.6 linux/drivers/isdn/hisax/niccy.c - 1.13 linux/drivers/isdn/hisax/netjet.c - 1.17 linux/drivers/isdn/hisax/mic.c - 1.10 linux/drivers/isdn/hisax/lmgr.c - 1.6 linux/drivers/isdn/hisax/l3dss1.h - 1.7 linux/drivers/isdn/hisax/l3dss1.c - 1.13 linux/drivers/isdn/hisax/l3_1tr6.h - 1.5 linux/drivers/isdn/hisax/l3_1tr6.c - 1.9 linux/drivers/isdn/hisax/ix1_micro.c - 1.10 linux/drivers/isdn/hisax/isdnl3.h - 1.6 linux/drivers/isdn/hisax/isdnl3.c - 1.13 linux/drivers/isdn/hisax/isdnl2.h - 1.5 linux/drivers/isdn/hisax/isdnl2.c - 1.12 linux/drivers/isdn/hisax/isdnl1.h - 1.6 linux/drivers/isdn/hisax/isdnl1.c - 1.14 linux/drivers/isdn/hisax/isac.h - 1.6 linux/drivers/isdn/hisax/isac.c - 1.11 linux/drivers/isdn/hisax/ipac.h - 1.6 linux/drivers/isdn/hisax/hscx_irq.c - 1.9 linux/drivers/isdn/hisax/hscx.h - 1.6 linux/drivers/isdn/hisax/hscx.c - 1.10 linux/drivers/isdn/hisax/hisax.h - 1.22 linux/drivers/isdn/hisax/hfc_2bs0.h - 1.6 linux/drivers/isdn/hisax/hfc_2bs0.c - 1.13 linux/drivers/isdn/hisax/hfc_2bds0.h - 1.6 linux/drivers/isdn/hisax/hfc_2bds0.c - 1.13 linux/drivers/isdn/hisax/fsm.c - 1.10 linux/drivers/isdn/hisax/elsa.c - 1.15 linux/drivers/isdn/hisax/diva.c - 1.14 linux/drivers/isdn/hisax/config.c - 1.24 linux/drivers/isdn/hisax/callc.c - 1.15 linux/drivers/isdn/hisax/avm_a1.c - 1.10 linux/drivers/isdn/hisax/asuscom.c - 1.13 linux/drivers/isdn/hisax/arcofi.h - 1.7 linux/drivers/isdn/hisax/arcofi.c - 1.10 linux/drivers/isdn/hisax/amd7930.c - 1.11 linux/drivers/isdn/avmb1/capiutil.h - 1.6 linux/drivers/isdn/avmb1/capiutil.c - 1.9 linux/drivers/isdn/avmb1/capidrv.h - 1.4 linux/drivers/isdn/avmb1/capidrv.c - 1.18 linux/drivers/isdn/avmb1/capidev.h - 1.8 linux/drivers/isdn/avmb1/capicmd.h - 1.5 linux/drivers/isdn/avmb1/capi.c - 1.24 linux/drivers/isdn/avmb1/b1pci.c - 1.15 linux/drivers/isdn/act2000/module.c - 1.8 linux/drivers/isdn/act2000/capi.h - 1.6 linux/drivers/isdn/act2000/capi.c - 1.6 linux/drivers/isdn/act2000/act2000_isa.h - 1.5 linux/drivers/isdn/act2000/act2000_isa.c - 1.7 linux/drivers/isdn/act2000/act2000.h - 1.6 linux/drivers/char/sysrq.c - 1.17 linux/drivers/char/softdog.c - 1.13 linux/drivers/block/loop.c - 1.37 linux/drivers/block/genhd.c - 1.19 linux/arch/sparc64/prom/misc.c - 1.9 linux/arch/sparc64/mm/ultra.S - 1.19 linux/arch/sparc64/mm/init.c - 1.33 linux/arch/sparc64/lib/blockops.S - 1.14 linux/arch/sparc64/lib/VIScopy.S - 1.7 linux/arch/sparc64/kernel/ttable.S - 1.10 linux/arch/sparc64/kernel/traps.c - 1.15 linux/arch/sparc64/kernel/sys_sparc32.c - 1.39 linux/arch/sparc64/kernel/sparc64_ksyms.c - 1.34 linux/arch/sparc64/kernel/setup.c - 1.21 linux/arch/sparc64/kernel/ptrace.c - 1.13 linux/arch/sparc64/kernel/process.c - 1.22 linux/arch/sparc64/kernel/dtlb_backend.S - 1.9 linux/arch/sparc64/defconfig - 1.50 linux/arch/sparc/mm/init.c - 1.27 linux/arch/sparc/kernel/process.c - 1.19 linux/arch/ppc/kernel/traps.c - 1.22 linux/arch/ppc/kernel/process.c - 1.32 linux/arch/mips/mm/r4xx0.c - 1.10 linux/arch/mips/mm/r2300.c - 1.11 linux/arch/m68k/kernel/process.c - 1.13 linux/arch/i386/kernel/traps.c - 1.40 linux/arch/i386/kernel/process.c - 1.35 linux/arch/i386/kernel/entry.S - 1.36 linux/arch/i386/kernel/apm.c - 1.34 linux/arch/i386/defconfig - 1.72 linux/arch/i386/config.in - 1.63 linux/arch/arm/kernel/process.c - 1.20 linux/arch/alpha/kernel/traps.c - 1.16 linux/arch/alpha/kernel/process.c - 1.19 linux/Makefile - 1.127 linux/MAINTAINERS - 1.74 linux/Documentation/sysctl/kernel.txt - 1.5 linux/Documentation/oops-tracing.txt - 1.8 linux/Documentation/filesystems/ntfs.txt - 1.11 linux/Documentation/filesystems/fat_cvf.txt - 1.4 linux/Documentation/fb/matroxfb.txt - 1.8 linux/Documentation/Configure.help - 1.103 linux/CREDITS - 1.61 linux/include/linux/isdn_lzscomp.h - 1.2 linux/fs/efs/inode.c - 1.8 linux/drivers/sound/cmpci.c - 1.26 linux/drivers/net/irda/toshoboe.c - 1.27 linux/drivers/net/irda/smc-ircc.c - 1.21 linux/drivers/net/irda/litelink.c - 1.8 linux/drivers/isdn/isdn_bsdcomp.c - 1.6 linux/drivers/isdn/hisax/telespci.c - 1.11 linux/drivers/isdn/hisax/s0box.c - 1.8 linux/drivers/isdn/hisax/isar.h - 1.8 linux/drivers/isdn/hisax/isar.c - 1.15 linux/drivers/isdn/hisax/elsa_ser.c - 1.10 linux/drivers/isdn/hisax/cert.c - 1.7 linux/drivers/isdn/hisax/avm_pci.c - 1.12 linux/drivers/isdn/hisax/avm_a1p.c - 1.8 linux/drivers/isdn/eicon/eicon_pci.h - 1.4 linux/drivers/isdn/eicon/eicon_pci.c - 1.9 linux/drivers/isdn/eicon/eicon_mod.c - 1.14 linux/drivers/isdn/eicon/eicon_isa.h - 1.7 linux/drivers/isdn/eicon/eicon_isa.c - 1.8 linux/drivers/isdn/eicon/eicon_io.c - 1.8 linux/drivers/isdn/eicon/eicon_idi.h - 1.6 linux/drivers/isdn/eicon/eicon_idi.c - 1.12 linux/drivers/isdn/eicon/eicon_dsp.h - 1.5 linux/drivers/isdn/eicon/eicon.h - 1.12 linux/drivers/net/arlan.c - 1.20 linux/drivers/net/arlan-proc.c - 1.8 linux/drivers/parport/share.c - 1.17 linux/drivers/net/ppp_generic.c - 1.23 linux/drivers/net/ppp_async.c - 1.14 linux/drivers/net/hamradio/yam.c - 1.16 linux/drivers/sound/esssolo1.c - 1.32 linux/include/linux/isdn_divertif.h - 1.3 linux/fs/partitions/check.c - 1.31 linux/drivers/isdn/isdn_ttyfax.h - 1.3 linux/drivers/isdn/isdn_ttyfax.c - 1.7 linux/drivers/isdn/hisax/saphir.c - 1.9 linux/drivers/isdn/hisax/jade_irq.c - 1.7 linux/drivers/isdn/hisax/jade.h - 1.4 linux/drivers/isdn/hisax/jade.c - 1.8 linux/drivers/isdn/hisax/isurf.c - 1.10 linux/drivers/isdn/hisax/hfcscard.c - 1.8 linux/drivers/isdn/hisax/hfc_pci.h - 1.6 linux/drivers/isdn/hisax/hfc_pci.c - 1.20 linux/drivers/isdn/hisax/gazel.c - 1.10 linux/drivers/isdn/hisax/bkm_ax.h - 1.5 linux/drivers/isdn/hisax/bkm_a8.c - 1.12 linux/drivers/isdn/hisax/bkm_a4t.c - 1.12 linux/drivers/isdn/divert/isdn_divert.h - 1.5 linux/drivers/isdn/divert/isdn_divert.c - 1.8 linux/drivers/isdn/divert/divert_procfs.c - 1.15 linux/drivers/isdn/divert/divert_init.c - 1.6 linux/drivers/isdn/avmb1/t1isa.c - 1.13 linux/drivers/isdn/avmb1/kcapi.c - 1.15 linux/drivers/isdn/avmb1/capilli.h - 1.2 linux/drivers/isdn/avmb1/b1pcmcia.c - 1.13 linux/drivers/isdn/avmb1/b1isa.c - 1.11 linux/drivers/isdn/avmb1/b1.c - 1.14 linux/drivers/isdn/avmb1/avmcard.h - 1.7 linux/drivers/net/sis900.c - 1.27 linux/drivers/net/sb1000.c - 1.14 linux/drivers/net/fc/tach.h - 1.2 linux/drivers/net/fc/iph5526.c - 1.16 linux/net/atm/mpc.c - 1.8 linux/net/atm/lec.c - 1.14 linux/net/atm/common.c - 1.15 linux/arch/sh/kernel/process.c - 1.15 linux/drivers/sound/maestro.c - 1.25 linux/drivers/scsi/ips.h - 1.10 linux/drivers/scsi/ips.c - 1.18 linux/drivers/scsi/ChangeLog.serverraid - 1.2 linux/net/irda/ircomm/ircomm_tty.c - 1.14 linux/net/irda/ircomm/ircomm_core.c - 1.11 linux/drivers/pcmcia/tcic.c - 1.13 linux/drivers/pcmcia/i82365.c - 1.21 linux/drivers/pcmcia/ds.c - 1.15 linux/drivers/pcmcia/cs.c - 1.28 linux/drivers/pcmcia/cb_enabler.c - 1.9 linux/drivers/net/starfire.c - 1.21 linux/drivers/net/pcmcia/ray_cs.c - 1.21 linux/drivers/net/pcmcia/pcnet_cs.c - 1.16 linux/drivers/net/pcmcia/3c589_cs.c - 1.19 linux/drivers/sound/nm256_audio.c - 1.13 linux/drivers/sound/ac97.c - 1.5 linux/drivers/net/dmfe.c - 1.20 linux/drivers/net/wan/cycx_drv.c - 1.6 linux/arch/i386/kernel/pci-pc.c - 1.26 linux/include/linux/pci_ids.h - 1.45 linux/drivers/net/wan/sealevel.c - 1.10 linux/drivers/net/wan/hostess_sv11.c - 1.10 linux/drivers/scsi/sim710.c - 1.8 linux/drivers/video/tdfxfb.c - 1.13 linux/drivers/net/pcmcia/xirc2ps_cs.c - 1.15 linux/drivers/net/pcmcia/3c574_cs.c - 1.17 linux/drivers/net/pcmcia/nmclan_cs.c - 1.13 linux/drivers/net/pcmcia/fmvj18x_cs.c - 1.12 linux/drivers/net/pcmcia/netwave_cs.c - 1.15 linux/drivers/net/pcmcia/wavelan_cs.c - 1.10 linux/drivers/net/pcmcia/smc91c92_cs.c - 1.13 linux/include/asm-i386/highmem.h - 1.8 linux/fs/bfs/inode.c - 1.15 linux/drivers/isdn/avmb1/t1pci.c - 1.14 linux/drivers/isdn/hisax/w6692.h - 1.4 linux/drivers/isdn/hisax/w6692.c - 1.10 linux/drivers/net/sk98lin/skge.c - 1.16 linux/drivers/sound/trident.c - 1.26 linux/drivers/net/pcmcia/aironet4500_cs.c - 1.12 linux/drivers/net/aironet4500_proc.c - 1.9 linux/drivers/net/aironet4500_core.c - 1.16 linux/drivers/net/aironet4500_card.c - 1.14 linux/drivers/i2c/i2c-velleman.c - 1.4 linux/drivers/i2c/i2c-elv.c - 1.5 linux/drivers/i2c/i2c-philips-par.c - 1.5 linux/drivers/i2c/i2c-elektor.c - 1.8 linux/drivers/i2c/i2c-algo-pcf.c - 1.9 linux/drivers/i2c/i2c-dev.c - 1.12 linux/drivers/i2c/i2c-core.c - 1.11 linux/drivers/i2c/i2c-algo-bit.c - 1.8 linux/drivers/pcmcia/yenta.c - 1.28 linux/drivers/net/irda/old_belkin.c - 1.3 linux/include/asm-sparc64/pgalloc.h - 1.13 linux/net/ipv4/inetpeer.c - 1.6 linux/net/sched/sch_ingress.c - 1.6 linux/net/sched/sch_gred.c - 1.7 linux/net/sched/sch_dsmark.c - 1.7 linux/net/sched/cls_tcindex.c - 1.5 linux/drivers/ieee1394/raw1394.c - 1.12 linux/drivers/ieee1394/pcilynx.c - 1.13 linux/drivers/ieee1394/ohci1394.c - 1.17 linux/drivers/ieee1394/ieee1394_syms.c - 1.10 linux/include/asm-i386/io_apic.h - 1.5 linux/drivers/scsi/3w-xxxx.c - 1.13 linux/fs/autofs4/init.c - 1.4 linux/drivers/usb/usb-uhci.c - 1.29 linux/drivers/usb/scanner.h - 1.16 linux/drivers/sound/ac97_codec.c - 1.19 linux/drivers/net/irda/nsc-ircc.c - 1.16 linux/drivers/net/mac89x0.c - 1.7 linux/arch/ia64/kernel/process.c - 1.10 linux/drivers/sound/via82cxxx_audio.c - 1.21 linux/drivers/scsi/qla1280.c - 1.11 linux/drivers/video/sun3fb.c - 1.7 linux/drivers/net/8139too.c - 1.26 linux/drivers/isdn/hisax/hfc_sx.h - 1.3 linux/drivers/isdn/hisax/hfc_sx.c - 1.10 linux/drivers/isdn/avmb1/c4.c - 1.15 linux/drivers/isdn/avmb1/b1dma.c - 1.17 linux/include/linux/hysdn_if.h - 1.4 linux/drivers/isdn/hysdn/boardergo.h - 1.3 linux/drivers/isdn/hysdn/hysdn_defs.h - 1.7 linux/drivers/isdn/hysdn/hysdn_init.c - 1.8 linux/drivers/isdn/hysdn/hysdn_net.c - 1.9 linux/drivers/isdn/hysdn/hysdn_pof.h - 1.3 linux/drivers/isdn/hysdn/hysdn_procconf.c - 1.12 linux/drivers/isdn/hysdn/hysdn_proclog.c - 1.11 linux/drivers/isdn/hysdn/hysdn_sched.c - 1.8 linux/drivers/isdn/hysdn/ince1pc.h - 1.3 linux/drivers/scsi/pcmcia/aha152x_stub.c - 1.6 linux/drivers/isdn/hysdn/boardergo.c - 1.12 linux/drivers/isdn/hysdn/hysdn_boot.c - 1.6 linux/drivers/net/skfp/skfddi.c - 1.11 linux/fs/lockd/xdr4.c - 1.7 linux/fs/lockd/svc4proc.c - 1.4 linux/drivers/video/matrox/matroxfb_misc.c - 1.3 linux/drivers/video/matrox/matroxfb_base.h - 1.8 linux/drivers/video/matrox/matroxfb_base.c - 1.11 linux/drivers/video/matrox/matroxfb_accel.c - 1.5 linux/drivers/video/matrox/matroxfb_Ti3026.c - 1.5 linux/drivers/video/matrox/matroxfb_DAC1064.c - 1.8 linux/drivers/video/matrox/i2c-matroxfb.c - 1.3 linux/drivers/net/tulip/tulip_core.c - 1.30 linux/arch/mips64/mm/andes.c - 1.8 linux/arch/mips64/mm/r4xx0.c - 1.9 linux/drivers/net/bonding.c - 1.6 linux/drivers/video/riva/fbdev.c - 1.13 linux/drivers/sound/awe_wave.c - 1.9 linux/drivers/sound/aedsp16.c - 1.6 linux/drivers/sound/aci.c - 1.7 linux/drivers/ide/ide-pci.c - 1.17 linux/drivers/ide/ide-floppy.c - 1.9 linux/drivers/ide/ide-disk.c - 1.15 linux/drivers/ide/ide-cs.c - 1.6 linux/scripts/kernel-doc - 1.11 linux/drivers/net/tokenring/lanstreamer.c - 1.8 linux/net/ipv4/netfilter/iptable_mangle.c - 1.7 linux/net/ipv4/netfilter/iptable_filter.c - 1.4 linux/net/ipv4/netfilter/ipt_unclean.c - 1.6 linux/net/ipv4/netfilter/ipt_tos.c - 1.4 linux/net/ipv4/netfilter/ipt_state.c - 1.4 linux/net/ipv4/netfilter/ipt_owner.c - 1.6 linux/net/ipv4/netfilter/ipt_multiport.c - 1.5 linux/net/ipv4/netfilter/ipt_mark.c - 1.4 linux/net/ipv4/netfilter/ipt_mac.c - 1.5 linux/net/ipv4/netfilter/ipt_limit.c - 1.5 linux/net/ipv4/netfilter/ipt_TOS.c - 1.5 linux/net/ipv4/netfilter/ipt_REJECT.c - 1.11 linux/net/ipv4/netfilter/ipt_REDIRECT.c - 1.5 linux/net/ipv4/netfilter/ipt_MIRROR.c - 1.7 linux/net/ipv4/netfilter/ipt_MASQUERADE.c - 1.8 linux/net/ipv4/netfilter/ipt_MARK.c - 1.4 linux/net/ipv4/netfilter/ipt_LOG.c - 1.7 linux/net/ipv4/netfilter/ipchains_core.c - 1.8 linux/net/ipv4/netfilter/ip_tables.c - 1.11 linux/net/ipv4/netfilter/ip_queue.c - 1.11 linux/net/ipv4/netfilter/ip_nat_standalone.c - 1.11 linux/net/ipv4/netfilter/ip_nat_ftp.c - 1.7 linux/net/ipv4/netfilter/ip_conntrack_standalone.c - 1.10 linux/net/ipv4/netfilter/ip_conntrack_ftp.c - 1.7 linux/drivers/net/pcmcia/xircom_tulip_cb.c - 1.14 linux/drivers/isdn/avmb1/capifs.c - 1.12 linux/drivers/isdn/avmb1/avm_cs.c - 1.6 linux/drivers/isdn/avmb1/capifs.h - 1.3 linux/drivers/scsi/dmx3191d.c - 1.8 linux/drivers/net/pcmcia/ibmtr_cs.c - 1.9 linux/fs/ramfs/inode.c - 1.13 linux/fs/nfs/nfs3proc.c - 1.7 linux/drivers/usb/serial/usbserial.c - 1.23 linux/drivers/sound/i810_audio.c - 1.16 linux/drivers/sound/emu10k1/main.c - 1.12 linux/drivers/net/pppoe.c - 1.16 linux/arch/s390/kernel/process.c - 1.8 linux/drivers/s390/net/iucv.c - 1.7 linux/drivers/s390/net/iucv.h - 1.4 linux/drivers/s390/misc/chandev.c - 1.6 linux/drivers/s390/char/hwc_rw.c - 1.5 linux/drivers/s390/block/dasd_eckd.c - 1.7 linux/drivers/s390/block/dasd.c - 1.13 linux/net/ipv6/netfilter/ip6table_filter.c - 1.3 linux/net/ipv6/netfilter/ip6t_mark.c - 1.3 linux/net/ipv6/netfilter/ip6t_limit.c - 1.2 linux/net/ipv6/netfilter/ip6t_MARK.c - 1.3 linux/net/ipv6/netfilter/ip6_tables.c - 1.8 linux/Documentation/DocBook/mousedrivers.tmpl - 1.3 linux/drivers/ieee1394/video1394.c - 1.11 linux/drivers/net/tun.c - 1.11 linux/net/ipv4/tcp_minisocks.c - 1.10 linux/drivers/sound/cs46xx.c - 1.15 linux/drivers/net/natsemi.c - 1.12 linux/drivers/media/video/zr36120_mem.c - 1.2 linux/drivers/media/video/zr36120.c - 1.9 linux/drivers/media/video/videodev.c - 1.8 linux/drivers/media/video/tvmixer.c - 1.5 linux/drivers/media/video/tuner.c - 1.7 linux/drivers/media/video/tuner-3036.c - 1.3 linux/drivers/media/video/tda9875.c - 1.6 linux/drivers/media/video/tda7432.c - 1.7 linux/drivers/media/video/stradis.c - 1.7 linux/drivers/media/video/saa7185.c - 1.5 linux/drivers/media/video/saa7111.c - 1.5 linux/drivers/media/video/saa7110.c - 1.3 linux/drivers/media/video/saa5249.c - 1.5 linux/drivers/media/video/pms.c - 1.6 linux/drivers/media/video/planb.c - 1.7 linux/drivers/media/video/msp3400.c - 1.8 linux/drivers/media/video/i2c-parport.c - 1.3 linux/drivers/media/video/i2c-old.c - 1.3 linux/drivers/media/video/c-qcam.c - 1.7 linux/drivers/media/video/bw-qcam.c - 1.7 linux/drivers/media/video/bttv-if.c - 1.4 linux/drivers/media/video/bttv-driver.c - 1.13 linux/drivers/media/video/bttv-cards.c - 1.9 linux/drivers/media/radio/radio-zoltrix.c - 1.7 linux/drivers/media/radio/radio-typhoon.c - 1.7 linux/drivers/media/radio/radio-trust.c - 1.7 linux/drivers/media/radio/radio-terratec.c - 1.7 linux/drivers/media/radio/radio-sf16fmi.c - 1.8 linux/drivers/media/radio/radio-rtrack2.c - 1.7 linux/drivers/media/radio/radio-gemtek.c - 1.7 linux/drivers/media/radio/radio-cadet.c - 1.6 linux/drivers/media/radio/radio-aztech.c - 1.7 linux/drivers/media/radio/radio-aimslab.c - 1.7 linux/drivers/isdn/hysdn/hycapi.c - 1.8 linux/drivers/isdn/hisax/nj_u.c - 1.8 linux/drivers/isdn/hisax/nj_s.c - 1.8 linux/drivers/isdn/hisax/netjet.h - 1.4 linux/drivers/isdn/hisax/l3ni1.h - 1.4 linux/drivers/isdn/hisax/l3ni1.c - 1.6 linux/drivers/isdn/hisax/icc.h - 1.3 linux/drivers/isdn/hisax/icc.c - 1.5 linux/drivers/isdn/eicon/xlog.c - 1.4 linux/drivers/isdn/eicon/uxio.h - 1.5 linux/drivers/isdn/eicon/sys.h - 1.4 linux/drivers/isdn/eicon/pri.c - 1.3 linux/drivers/isdn/eicon/pr_pc.h - 1.3 linux/drivers/isdn/eicon/pc_maint.h - 1.3 linux/drivers/isdn/eicon/pc.h - 1.4 linux/drivers/isdn/eicon/log.c - 1.4 linux/drivers/isdn/eicon/linsys.c - 1.4 linux/drivers/isdn/eicon/linio.c - 1.5 linux/drivers/isdn/eicon/linchr.c - 1.6 linux/drivers/isdn/eicon/lincfg.c - 1.4 linux/drivers/isdn/eicon/kprintf.c - 1.6 linux/drivers/isdn/eicon/idi.h - 1.4 linux/drivers/isdn/eicon/idi.c - 1.4 linux/drivers/isdn/eicon/fpga.c - 1.3 linux/drivers/isdn/eicon/fourbri.c - 1.3 linux/drivers/isdn/eicon/dspdids.h - 1.3 linux/drivers/isdn/eicon/dsp_defs.h - 1.3 linux/drivers/isdn/eicon/divas.h - 1.3 linux/drivers/isdn/eicon/divalog.h - 1.3 linux/drivers/isdn/eicon/constant.h - 1.3 linux/drivers/isdn/eicon/common.c - 1.7 linux/drivers/isdn/eicon/bri.c - 1.4 linux/drivers/isdn/eicon/adapter.h - 1.3 linux/drivers/isdn/eicon/Divas_mod.c - 1.6 linux/drivers/input/mousedev.c - 1.6 linux/drivers/input/joydev.c - 1.5 linux/drivers/input/input.c - 1.5 linux/drivers/input/evdev.c - 1.5 linux/drivers/md/raid1.c - 1.13 linux/drivers/md/raid5.c - 1.19 linux/drivers/md/linear.c - 1.4 linux/drivers/md/raid0.c - 1.4 linux/drivers/md/xor.c - 1.5 linux/drivers/media/radio/radio-maestro.c - 1.5 linux/drivers/net/hamachi.c - 1.11 linux/drivers/net/sundance.c - 1.10 linux/drivers/net/winbond-840.c - 1.12 linux/drivers/scsi/cpqfcTSinit.c - 1.11 linux/include/asm-ia64/module.h - 1.5 linux/drivers/usb/pegasus.h - 1.4 linux/drivers/usb/serial/belkin_sa.c - 1.11 linux/drivers/usb/serial/belkin_sa.h - 1.4 linux/drivers/media/video/tvaudio.c - 1.7 linux/net/irda/irnet/irnet_ppp.c - 1.6 linux/arch/parisc/mm/pa20.c - 1.2 linux/arch/parisc/mm/pa11.c - 1.2 linux/arch/parisc/kernel/traps.c - 1.2 linux/drivers/sound/ymfpci.c - 1.11 linux/drivers/scsi/osst.c - 1.7 linux/fs/reiserfs/namei.c - 1.8 linux/fs/reiserfs/inode.c - 1.13 linux/net/ipv6/netfilter/ip6table_mangle.c - 1.2 linux/drivers/sound/maestro3.c - 1.6 linux/drivers/sound/cs4281/cs4281m.c - 1.7 linux/arch/s390x/kernel/process.c - 1.5 linux/arch/cris/kernel/traps.c - 1.6 linux/drivers/s390/s390io.c - 1.5 linux/drivers/s390/net/netiucv.c - 1.7 linux/drivers/s390/net/ctcmain.c - 1.4 linux/drivers/s390/block/dasd_fba.c - 1.6 linux/drivers/s390/block/dasd_eckd.h - 1.5 linux/drivers/s390/block/dasd_diag.c - 1.6 linux/drivers/s390/block/dasd_3990_erp.c - 1.5 linux/net/ipv4/netfilter/ipt_tcpmss.c - 1.2 linux/net/ipv4/netfilter/ipt_TCPMSS.c - 1.2 linux/drivers/scsi/aic7xxx_old.c - 1.8 linux/drivers/scsi/aic7xxx/aic7xxx_linux.c - 1.5 linux/drivers/net/sungem.c - 1.9 linux/drivers/media/radio/radio-maxiradio.c - 1.3 linux/drivers/isdn/hisax/sedlbauer_cs.c - 1.4 linux/drivers/s390/char/ctrlchar.c - 1.3 linux/net/wanrouter/af_wanpipe.c - 1.3 linux/drivers/isdn/hisax/elsa_cs.c - 1.2 linux/fs/nls/nls_cp1251.c - 1.2 linux/fs/nls/nls_cp1255.c - 1.3 linux/drivers/media/video/w9966.c - 1.2 linux/drivers/media/video/bt856.c - 1.4 linux/drivers/media/video/bt819.c - 1.4 linux/drivers/media/video/adv7175.c - 1.4 linux/net/bluetooth/hci_core.c - 1.5 linux/net/bluetooth/l2cap_core.c - 1.4 linux/drivers/media/radio/miropcm20-rds.c - 1.2 linux/drivers/media/radio/miropcm20-rds-core.c - 1.2 linux/drivers/media/radio/miropcm20-radio.c - 1.2 linux/drivers/usb/serial/cyberjack.c - 1.4 linux/drivers/usb/serial/pl2303.c - 1.4 linux/drivers/isdn/tpam/tpam_queues.c - 1.2 linux/drivers/isdn/tpam/tpam_nco.c - 1.2 linux/drivers/isdn/tpam/tpam_memory.c - 1.2 linux/drivers/isdn/tpam/tpam_main.c - 1.4 linux/drivers/isdn/tpam/tpam_hdlc.c - 1.2 linux/drivers/isdn/tpam/tpam_crcpc.c - 1.2 linux/drivers/isdn/tpam/tpam_commands.c - 1.2 linux/drivers/isdn/tpam/tpam.h - 1.2 linux/fs/sysv/super.c - 1.3 linux/drivers/net/irda/ali-ircc.c - 1.5 linux/drivers/scsi/pcmcia/nsp_cs.c - 1.6 linux/arch/mips/mm/rm7k.c - 1.2 linux/arch/mips/mm/r5432.c - 1.3 linux/arch/mips/mm/mips32.c - 1.3 linux/drivers/media/video/meye.c - 1.3 linux/drivers/media/video/zr36067.c - 1.4 linux/drivers/usb/usb-skeleton.c - 1.4 linux/drivers/net/lp486e.c - 1.4 linux/drivers/parport/parport_serial.c - 1.3 linux/drivers/net/dl2k.c - 1.5 linux/drivers/message/fusion/mptscsih.c - 1.4 linux/drivers/message/fusion/mptlan.c - 1.4 linux/drivers/message/fusion/mptctl.c - 1.5 linux/drivers/message/fusion/mptbase.h - 1.4 linux/drivers/message/fusion/mptbase.c - 1.4 linux/drivers/s390/char/hwc_cpi.c - 1.2 linux/drivers/media/radio/radio-gemtek-pci.c - 1.2 linux/drivers/s390/block/dasd_int.h - 1.2 linux/drivers/net/irda/vlsi_ir.c - 1.4 linux/drivers/sound/rme96xx.c - 1.2 linux/drivers/usb/usbvideo.c - 1.2 linux/drivers/scsi/dpt_i2o.c - 1.3 linux/drivers/isdn/hisax/hisax_if.h - 1.2 linux/drivers/isdn/hisax/st5481.h - 1.2 linux/drivers/isdn/hisax/st5481_b.c - 1.2 linux/drivers/isdn/hisax/st5481_d.c - 1.2 linux/drivers/isdn/hisax/st5481_init.c - 1.2 linux/drivers/isdn/hisax/st5481_usb.c - 1.2 linux/drivers/net/ns83820.c - 1.4 linux/drivers/scsi/53c700.c - 1.2 linux/drivers/scsi/53c700.h - 1.2 linux/drivers/scsi/53c700.scr - 1.2 linux/drivers/i2c/i2c-adap-ite.c - 1.2 linux/drivers/i2c/i2c-algo-ite.c - 1.2 linux/drivers/scsi/lasi700.c - 1.2 linux/drivers/scsi/lasi700.h - 1.2 linux/drivers/isdn/hisax/fsm.h - 1.2 linux/drivers/isdn/hisax/hisax_debug.h - 1.2 linux/drivers/parport/parport_cs.c - 1.2 linux/drivers/usb/serial/xircom_pgs_fw.h - 1.2 linux/drivers/md/multipath.c - 1.2 linux/drivers/ide/ataraid.h - 1.2 linux/drivers/net/pcmcia/xircom_cb.c - 1.2 linux/drivers/ide/pdcraid.c - 1.3 linux/drivers/ide/hptraid.c - 1.3 linux/drivers/ide/ataraid.c - 1.2 From owner-linux-xfs@oss.sgi.com Wed Oct 3 16:33:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f93NXjM27975 for linux-xfs-outgoing; Wed, 3 Oct 2001 16:33:45 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f93NXhD27955 for ; Wed, 3 Oct 2001 16:33:43 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f93NXaK07425 for ; Wed, 3 Oct 2001 16:33:36 -0700 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA17140 for linux-xfs@oss.sgi.com; Thu, 4 Oct 2001 09:32:19 +1000 (EST) Date: Thu, 4 Oct 2001 09:32:19 +1000 (EST) From: Nathan Scott Message-Id: <200110032332.JAA17140@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsdump Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Fixes a subtle bug in the new inventory directory handling, where we ultimately ended up creating the new directory even when the old exists (exactly what we're trying to avoid!) - thanks Ivan. cheers. Date: Wed Oct 3 16:30:36 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:103917a cmd/xfsdump/dump/var.c - 1.3 - don't unliaterally create the new format here - this code is called even if the old format exists (it just silently ignores the failed mkdir calls). From owner-linux-xfs@oss.sgi.com Thu Oct 4 00:05:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9475PF03679 for linux-xfs-outgoing; Thu, 4 Oct 2001 00:05:25 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9475JD03660 for ; Thu, 4 Oct 2001 00:05:19 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with SMTP id f9475DK15657 for ; Thu, 4 Oct 2001 00:05:13 -0700 Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA10618; Thu, 4 Oct 2001 17:03:55 +1000 From: ivanr@sgi.com Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id RAA20862; Thu, 4 Oct 2001 17:03:54 +1000 (EST) X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs Date: Thu, 4 Oct 2001 17:03:54 +1000 X-X-Sender: ivanr@omen.melbourne.sgi.com To: Charles Radeke cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump/restore from cd In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 1 Oct 2001 ivanr@sgi.com wrote: > > On Fri, Sep 28, 2001 at 03:42:47PM +0200, Charles Radeke wrote: > > > I would like to backup a partition of some GB by burning cd's with > > > splitted xfsdump , each is 650MB. Is it possible to use a cdrom-drive as > > > a tape (like/dev/rmt)? and if, how to simulate the tape change? > > This option might not be as hard as it looks. ... I've had a quick look at this, and I think I've got something working (at least it _seems_ to work on a zip drive here). If you, or anyone else for that matter, would like to try it out, let me know and I'll send you a patch. The code is a very hacky, but I don't really have the time to clean it up properly at the moment so I wont be checking it in for a while (if at all). All I've done is to make the drive_simple strategy think it's writing to removable media instead of non-removeable media (such as a file or pipe). To do this properly will mean setting up a new strategy, rearraning some code in drive_simple.c, and adding a command-line option to manually select a strategy. My code will probably break normal drive_simple operations, and may very well have other bugs... I only did it to see if it could be done in principle, and to see how much effort it would be. Still, if you'd like to try it, let me know. Ivan -- Ivan Rayner ivanr@sgi.com From owner-linux-xfs@oss.sgi.com Thu Oct 4 01:35:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f948ZQi05016 for linux-xfs-outgoing; Thu, 4 Oct 2001 01:35:26 -0700 Received: from TYO202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.247.6.41]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f948Z5D04994 for ; Thu, 4 Oct 2001 01:35:06 -0700 Received: from mailgate4.nec.co.jp ([10.7.69.193]) by TYO202.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id f948YsQ28192 for ; Thu, 4 Oct 2001 17:34:54 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id f948Ysw10761 for ; Thu, 4 Oct 2001 17:34:54 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (THKTNES98740.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id f948YpX25540 for ; Thu, 4 Oct 2001 17:34:51 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA315 for ; Thu, 4 Oct 2001 17:34:50 +0900 Received: FROM mailsv.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Thu Oct 04 17:34:49 2001 +0900 Received: from rifu.bsd.tnes.nec.co.jp (IDENT:root@rifu.bsd.tnes.nec.co.jp [10.1.101.142]) by mailsv.tnes.nec.co.jp (8.9.3/3.7W01031510) with ESMTP id RAA35728; Thu, 4 Oct 2001 17:34:49 +0900 (JST) Received: from tagajo.bsd.tnes.nec.co.jp (tagajo.bsd.tnes.nec.co.jp [10.1.101.146]) by rifu.bsd.tnes.nec.co.jp (8.10.2+3.3W/3.7W/BSD-TNES-MX01) with ESMTP id f948Yni03681; Thu, 4 Oct 2001 17:34:49 +0900 Received: (from sasaki@localhost) by tagajo.bsd.tnes.nec.co.jp (8.8.5+2.7Wbeta5/3.5Wpl1-97090809) id RAA14958; Thu, 4 Oct 2001 17:34:49 +0900 (JST) Message-Id: <200110040834.RAA14958@tagajo.bsd.tnes.nec.co.jp> To: Dean Roehrich cc: linux-xfs@oss.sgi.com Subject: Re: wbee (sample_hsm) dumped core In-reply-to: Your message of Wed, 03 Oct 2001 11:37:32 -0500. <200110031637.LAA33083@slobber.americas.sgi.com> Date: Thu, 04 Oct 2001 17:34:49 +0900 From: Takayuki Sasaki Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Thank you for your time, Dean. Dean Roehrich wrote: > > >Takayuki Sasaki wrote: > > > >> migin daemon in sample_hsm started with the patch which I > >> posted, but if I try to read the migrated file then it > >> stalled. It was caused by > >> linux-2.4-xfs/cmd/xfstests/dmapi/src/sample_hsm/wbee which was > >> dispatched by migin dumped core. > > > >In the above situation, I killed the stalled command ( cp ) and > >migin by pressing Ctrl + c to find out what is wrong. Then, > >unmount the XFS file system, the following console messages > >appeared: > > > > XFS unmount got error 16 > > linvfs_put_super: vfsp/0xc2acb38c left dangling! > > VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day > >... > > Do you have a trace from the wbee core dump? Yes, but you know, it was fixed by a patch as I posted ( and it have been committed to the CVS tree already ). Offcause, these masseages are not appeared with the latest wbee. What I would like to know is why these message are displayed. If the cause is a bug, then it may be fixed :) but if the cause is wrong operations, I would like to know correct one. > You should also know that memory-mapped I/O is not going to trigger DMAPI > read/write events, yet--I've been experimenting with a fix for that for a > while now. Apparently your cp didn't do memory-mapped I/O in this case, else > it wouldn't have blocked. Something to keep in mind. > > Is your stagedir on the same filesystem that migin is monitoring? They should > be different filesystems. Here are the operations which I do: sasaki]# cd linux-2.4-xfs/cmd/xfstests/dmapi/src/sample_hsm sample_hsm]# uname -a Linux XXX.YYY.ZZZ.nec.co.jp 2.4.10-xfs #1 SMP Tue Oct 2 08:33:33 JST 2001 i686 unknown sample_hsm]# lvscan lvscan -- ACTIVE "/dev/vg0/kana1" [100 MB] lvscan -- ACTIVE "/dev/vg0/migfs" [32 MB] lvscan -- ACTIVE "/dev/vg0/xfstest11" [52 MB] lvscan -- ACTIVE "/dev/vg0/dmapi_fs" [32 MB] lvscan -- ACTIVE "/dev/vg0/masano1" [32 MB] lvscan -- 5 logical volumes with 248 MB total in 1 volume group lvscan -- 5 active logical volumes sample_hsm]# mkfs.xfs -f /dev/vg0/dmapi_fs meta-data=/dev/vg0/dmapi_fs isize=256 agcount=2, agsize=4096 blks data = bsize=4096 blocks=8192, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 = imaxbits=17 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200 realtime =none extsz=65536 blocks=0, rtextents=0 sample_hsm]# mkfs.xfs -f /dev/vg0/migfs meta-data=/dev/vg0/migfs isize=256 agcount=2, agsize=4096 blks data = bsize=4096 blocks=8192, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 = imaxbits=17 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200 realtime =none extsz=65536 blocks=0, rtextents=0 sample_hsm]# mount -t xfs -o dmapi /dev/vg0/dmapi_fs /mnt/dmapi_fs sample_hsm]# mount -t xfs -o dmapi /dev/vg0/migfs /mnt/migfs sample_hsm]# mkdir /mnt/dmapi_fs/stage_dir sample_hsm]# xfs_mkfile 1m /mnt/migfs/tfile sample_hsm]# ./migfind -s 800k /mnt/migfs >& cand_file sample_hsm]# cat ./cand_file 24 6e581f87d41649a90e000000000000008300000000000000 1048576 sample_hsm]# df -k /mnt/migfs /mnt/dmapi_fs Filesystem 1k-blocks Used Available Use% Mounted on /dev/vg0/migfs 27968 1072 26896 4% /mnt/migfs /dev/vg0/dmapi_fs 27968 48 27920 1% /mnt/dmapi_fs sample_hsm]# ./migout /mnt/dmapi_fs/stage_dir < cand_file sample_hsm]# df -k /mnt/migfs /mnt/dmapi_fs Filesystem 1k-blocks Used Available Use% Mounted on /dev/vg0/migfs 27968 60 27908 1% /mnt/migfs /dev/vg0/dmapi_fs 27968 1096 26872 4% /mnt/dmapi_fs sample_hsm]# ./migin -l dmapi_log /mnt/migfs & [1] 1205 sample_hsm]# ./mrmean -l Session (3) name: DMAPI test session sample_hsm]# cp /mnt/migfs/tfile /mnt/migfs/aaa <<<<< hung [other terminal] # ps -ef (snip) root 1205 1165 0 16:48 pts/0 00:00:00 ./migin -l dmapi_log /mnt/migfs root 1207 1165 0 16:49 pts/0 00:00:00 cp -i /mnt/migfs/tfile /mnt/migfs/aaa root 1208 1205 0 16:49 pts/0 00:00:00 [wbee ] ( Press Ctrl + c to terminate cp ) sample_hsm]# df -k /mnt/migfs /mnt/dmapi_fs Filesystem 1k-blocks Used Available Use% Mounted on /dev/vg0/migfs 27968 1076 26892 4% /mnt/migfs /dev/vg0/dmapi_fs 27968 1072 26896 4% /mnt/dmapi_fs sample_hsm]# ./mrmean -l Session (3) name: DMAPI test session sample_hsm]# kill -SIGINT 1205 sample_hsm]# ./mrmean -l Session (3) name: DMAPI test session [1]+ Done ./migin -l dmapi_log /mnt/migfs sample_hsm]# ls -R /proc/fs/xfs/dmapi_d /proc/fs/xfs/dmapi_d: fsreg sessions summary /proc/fs/xfs/dmapi_d/fsreg: 0xc6da68a4 0xc6da6ab4 /proc/fs/xfs/dmapi_d/sessions: 0xc59f0000 sample_hsm]# cat /proc/fs/xfs/dmapi_d/summary dm_sessions_active=1 dm_next_sessid=4 dm_next_token=3 dm_next_sequence=3 dm_fsys_cnt=2 sample_hsm]# cat /proc/fs/xfs/dmapi_d/fsreg/0xc6da68a4 fsrp=0xc6da68a4 fr_next=0x00000000 fr_vfsp=0xc6d5a5cc fr_tevp=0x00000000 fr_fsid=? fr_msg=0xc6cca524 fr_msgsize=100 fr_state=mounted fr_dispq=? fr_dispcnt=0 fr_evt_dispq.eq_head=0x00000000 fr_evt_dispq.eq_tail=0x00000000 fr_evt_dispq.eq_count=0 fr_queue=? fr_lock=? fr_hdlcnt=0 fr_vfscnt=0 fr_unmount=0 fr_rattr= sample_hsm]# cat /proc/fs/xfs/dmapi_d/fsreg/0xc6da6ab4 fsrp=0xc6da6ab4 fr_next=0xc6da68a4 fr_vfsp=0xc6d5a4f4 fr_tevp=0x00000000 fr_fsid=? fr_msg=0xc6cca38c fr_msgsize=97 fr_state=mounted fr_dispq=? fr_dispcnt=0 fr_evt_dispq.eq_head=0x00000000 fr_evt_dispq.eq_tail=0x00000000 fr_evt_dispq.eq_count=0 fr_queue=? fr_lock=? fr_hdlcnt=0 fr_vfscnt=0 fr_unmount=0 fr_rattr= fr_sessp[16]=0xc59f0000 fr_sessp[17]=0xc59f0000 fr_sessp[18]=0xc59f0000 sample_hsm]# cat /proc/fs/xfs/dmapi_d/sessions/0xc59f0000 sessp=0xc59f0000 sn_next=0x00000000 sn_sessid=3 sn_flags=0 sn_qlock=? sn_readerq=? sn_writerq=? sn_readercnt=0 sn_writercnt=0 sn_newq.eq_head=0x00000000 sn_newq.eq_tail=0x00000000 sn_newq.eq_count=0 sn_delq.eq_head=0xc6da6cc4 sn_delq.eq_tail=0xc6da6cc4 sn_delq.eq_count=1 sn_evt_writerq.eq_head=0x00000000 sn_evt_writerq.eq_tail=0x00000000 sn_evt_writerq.eq_count=0 sn_info="DMAPI test session" sample_hsm]# umount /mnt/migfs sample_hsm]# dmesg | tail -5 XFS mounting filesystem lvm(58,1) xfs_unmount: xfs_ibusy says error/16 XFS unmount got error 16 linvfs_put_super: vfsp/0xc6d5a4f4 left dangling! VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day... sample_hsm]# P.S. migin which is used in above test is not updated yet ( i.e. "TAKE - Cleanup for dmapi test migin" is not taked yet ) cheers, Takayuki From owner-linux-xfs@oss.sgi.com Thu Oct 4 01:50:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f948o2005440 for linux-xfs-outgoing; Thu, 4 Oct 2001 01:50:02 -0700 Received: from dmz.tecosim.de ([194.24.222.241]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f948ntD05418 for ; Thu, 4 Oct 2001 01:49:55 -0700 Received: (from uucp@localhost) by dmz.tecosim.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) id f948n1f06700; Thu, 4 Oct 2001 10:49:01 +0200 Received: from ns.tecosim.de(194.24.222.9) via SMTP by dmz.tecosim.de, id smtpdVE2t6W; Thu Oct 4 10:48:59 2001 Received: from donner.tecosim.de (donner.tecosim.de [194.24.222.109]) by ns.tecosim.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id f948mvb06474; Thu, 4 Oct 2001 10:48:57 +0200 Received: (from leh@localhost) by donner.tecosim.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) id f948mvD25294; Thu, 4 Oct 2001 10:48:57 +0200 Date: Thu, 4 Oct 2001 10:48:57 +0200 From: Utz Lehmann To: Sean Elble Cc: Utz Lehmann , linux-xfs@oss.sgi.com Subject: Re: IRIX 6.5.6m/XFS CVS: Any problems? Message-ID: <20011004104857.A24928@de.tecosim.com> References: <014601c14aed$34616ff0$0a00a8c0@intranet.mp3s.com> <200110021239.HAA17289@fsgi158.americas.sgi.com> <20011002151459.C16538@de.tecosim.com> <015601c14baf$e783d060$0a00a8c0@intranet.mp3s.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <015601c14baf$e783d060$0a00a8c0@intranet.mp3s.com>; from S_Elble@yahoo.com on Tue, Oct 02, 2001 at 10:05:38PM -0400 X-Scanned-By: MIMEDefang 1.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Sean Yes. I tested it with a 2.4.10 XFS kernel (CVS from Sep 24). The pwd problem is gone. But I didn't tests it deeply, make some tests yourself. utz Sean Elble [S_Elble@yahoo.com] wrote: > Utz, > > So, in other words, I shouldn't have any problems checking out the XFS tree > at kernel version 2.4.10? (At least based upon your knowledge) > > -Sean > ----- Original Message ----- > From: "Utz Lehmann" > To: "Tad Dolphay" > Cc: ; > Sent: Tuesday, October 02, 2001 9:14 AM > Subject: Re: IRIX 6.5.6m/XFS CVS: Any problems? > > > > Tad Dolphay [tbd@sgi.com] wrote: > > > > > > > > Utz, > > > > > > > > Thanks for the information; do you know if this patch needs to be > applied > > > > for NFS v3 to work from IRIX to Linux? It looks really easy to apply > > > > > > For the most part NFS V3 will still work using a pre 6.5.13 IRIX client > > > and 2.4 linux server. The problem is that sometimes when doing a pwd on > a > > > NFS mounted directory you won't see the entire path name. > > > > Yes, and the IRIX ftpd, Midnight Commander (mc), xemacs, ... are confused > too. > > > > I just tested a 2.4.10 xfs kernel (with preempt patch, but _without_ the > nfs > > patch i had attached in my last mail). It's seems to work. My ftpd and mc > > tests are ok. Tested with IRIX 6.5.3 and HP-UX 10.20. So you dont need the > > patch for 2.4.10. > > > > > > utz From owner-linux-xfs@oss.sgi.com Thu Oct 4 02:29:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f949TM906219 for linux-xfs-outgoing; Thu, 4 Oct 2001 02:29:22 -0700 Received: from hyperion.charter (charter94-nat.clients.easynet.fr [212.11.21.141]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f949RpD06182 for ; Thu, 4 Oct 2001 02:27:52 -0700 Received: from biendecider.com (unknown [192.168.1.195]) by hyperion.charter (Postfix) with ESMTP id 43E6BB52B for ; Thu, 4 Oct 2001 11:27:48 +0200 (CEST) Message-ID: <3BBC2B94.3030503@biendecider.com> Date: Thu, 04 Oct 2001 11:27:48 +0200 From: laurent ribeyre User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20010913 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Xfsdump doesnt work Content-Type: multipart/mixed; boundary="------------080205090808020504050005" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------080205090808020504050005 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello SGI.com I hope that you will be able to help me. I join this attachment with this mail. I dont undersand why xfsdump doesnt work is a syntax error? bad install? my computer has xfs filesystem everywhere (/, /usr......) the version of xfs is 1.0.9 the error is segmentation fault thank a lot for you help laurent ribeyre (im from france, sorry for my bad english) --------------080205090808020504050005 Content-Type: image/jpeg; name="xfsdump.JPG" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="xfsdump.JPG" /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAsICAoIBwsKCQoNDAsNERwSEQ8PESIZGhQcKSQr KigkJyctMkA3LTA9MCcnOEw5PUNFSElIKzZPVU5GVEBHSEX/2wBDAQwNDREPESESEiFFLicu RUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUX/wAAR CAJ2Az8DASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDstZ1hdHiEjxoYli3sSo4AUEnoSawR46u2 GY/DGqyoeVeK0V0YeqsMgg9iDg1a8bQvcac8MS7pJLZ0UZxklABXnuualqF1b6ZZ2un3bwWN itqxksdwZsYZk3DIB2rg8MMdsmsoRnUrKmpKKe7fTT+v60OdVPfmnLa1lp2PQbLxmbxpI209 7aeLBeC4RVdQc4JGDjODwecYOMEE2v8AhJH/AOfaP8l/+JrkrW5Oo+I9X1Nbe4ghuxAUS4iK Ou1SpB7Z4zwTwR3yB10yC5sNKQJDG947JJIsKA8OAOgH6YrCnOcopy0dlp59jjq16qqSjCWi 8l5f5if8JI//AD6x/kv/AMTSf8JK/wDz6x/kv/xNPTSNNl1JLSO5k3+a6OgOTgAnOSoAORjH PXrVex021um8xmkFs8qQo7OFYuRzwFb8MkfWrvPuR7XE3+Jfh/kS/wDCSv8A8+sf/jv/AMTR /wAJM/8Az6x/+O//ABNU7SL7Lrq2xCSqLgQtvjDBhuweDnFW3sre6utTluGWKGzfYqxqIxgu QMlVP8iaFKT6ijXrtfF+CD/hJn/59Y//AB3/AOJo/wCEnf8A59Y//Hf/AImoptP06PT57uO4 nlQTmKIqoG75MjIOMYPU+3Tmpr3SLK2N/tFwwsjHuzIv7wOO3y8YJHrRefcr2uI/m/L/AC8h P+Enf/n1j/8AHf8A4mk/4Sh/+fWP/wAd/wDiaoajp8dlq0toJwsaEYkkB4BGRnAPrjpU2hW8 L6/BC5iuIjuz8pKt8hPRgP5UKUr2uJV6/NyOXW3Qs/8ACUP/AM+kf/jv/wATSf8ACUv/AM+k f/jv/wATUGnabbXh82RXitnmWCMmb5txHI4Q5/Qe9OvNGgtreBUeaS7nlkijAChWZZAvOenH 15PUU7y3KVbENc1/y/yJf+Epf/n0j/8AHf8A4mj/AISl/wDn0j/8d/8Aiamh8O2c80SiaQD7 Q9vKqvuwQhbglF7j0PXrUNvpVu9ibuIyKstnO4R9rlWRgOpXvnsAR60/eK9piO/5f11E/wCE qf8A59I//Hf/AImj/hKn/wCfSP8A8d/+Jqtqml29rYxXFnJ9oidgpmEoPO3OCm3Kn8TjHNXf Ks/7A/tPy4N32b7L5OBnzN2N+f72OcYzjvReXcFVr3acttehH/wlb/8APpH/AOO//E0n/CVv /wA+cf8A47/8TUGpSA6Fp0gigV7jzfMZIEUnawxyBx+FYtJya6kyxFWLtzfgjof+Esf/AJ84 /wDx3/4mj/hLH/584/8Ax3/4mudpKXMxfWavf8jov+Etf/nzj/8AHf8A4mj/AIS1/wDnzj/8 d/8Aia5yinzMf1mr3/I6L/hLn/584/8Ax3/4mj/hLn/584//AB3/AOJrnKSjmY/rNXv+R0n/ AAl7/wDPnH+a/wDxNJ/wl7/8+Uf5r/8AE1zdFHMx/WKvc6T/AITB/wDnyj/Nf/iaP+Ewf/ny j/Nf/ia5qkp8zD6xU7nS/wDCYv8A8+Uf5r/8TR/wmL/8+Uf5r/8AE1zNFHMx/WKnc6X/AITF /wDnyj/Nf/iaP+Eyf/nyj/Nf/ia5mko5mP29TudP/wAJk/8Az5R/mv8A8TSf8Jm//PjH+a// ABNczSU7sft6nc6f/hM3/wCfGP8ANf8A4mj/AITR/wDnxj/Nf/ia5ekoux+2n3Oo/wCE0f8A 58Y/zX/4mj/hNX/58Y/zX/4muWNFF2P20+51H/Cav/z4x/mv/wATR/wmz/8APjH+a/8AxNct SU7sftp9zqf+E2f/AJ8I/wA1/wDiaP8AhNn/AOfCP81/+JrlaKLsftZ9zqv+E3f/AJ8I/wA1 /wDiaT/hOH/58I/++l/+JrlTSUXY/az7nV/8Jw//AD4R/wDfS/8AxNH/AAnD/wDPhH/30v8A 8TXKUlO4/aS7nV/8Jy//AD4R/wDfS/8AxNH/AAnL/wDPhH/30v8A8TXJ0lFx+0l3Ot/4Tp/+ gfH/AN9L/wDE0n/CdP8A9A+P/vpf/ia5KigftJHW/wDCdv8A9A+P/vpf/iaT/hO3/wCgfH/3 0v8A8TXJUlMfPI67/hPH/wCgfH/30v8A8TR/wnj/APQPj/76X/4muQooHzyOu/4T1/8AoHx/ 99L/APE0f8J6/wD0Do/++l/+JrkKSgfOzsP+E+f/AKB0f/fS/wDxNJ/wnz/9A6P/AL6X/wCJ rj6KY+ZnYf8ACfP/ANA6P/vpf/iKT/hP3/6B0f8A30v/AMRXH0lA+ZnY/wDCfv8A9A6P/vpf /iKP+FgP/wBA6P8A76X/AOIrjqSgd2dj/wALAf8A6B0f/fa//EUf8LBf/oGx/wDfa/8AxFca aQ07Duzs/wDhYL/9A2P/AL7X/wCIpP8AhYT/APQNj/77X/4iuMoosO56TZ65q9/aR3NtosLQ yZ2sbmJc4JB4IB6g1N/aOu/9AOD/AMC4P8KraFcwWfhKxnupo4IUR90kjBVGZXAyT71fs9Ss dQ3/AGG8t7ny8b/JlV9uemcHjofypDKsGs6zcwiWHRYGjLMob7VCASrFTjj1B5qT+0dd/wCg HB/4Fwf4VX0m3iutG0yKdN8ZknJUkjOGmI6e4q7HY2dveW7QWyRsS4JDMePLc9yfQUwM+y8S 6lqMlwlpo8Mht22SH7READz0JGD909Kt/wBo67/0A4P/AALg/wAKxvBPTWP+u8f85Kyv7Qn+ 1eV/aF5/wi/2nH9o5O/dn/V+du3eVu48zH+zuxzSA6eHxHd/21Dpl3p8MEsilsrLHJgYJ/hH t61ueD2LeGrdmJLGSYknqf3r1xsn/JQ4v+uf/tNq7Hwb/wAizbf9dJv/AEa9NAbtFFFMQUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAchrlrN cyQeSm7agzyB/CtVI4r+KBYks7f5f42jjZjyepOfX9B753J/9YP9xf8A0EVz7+Ica3Lp+dPj 8qZIsT3uyV9yq2Vj2HP3sDnkjtWLgm7nNPCQnNzbabC6tL67mMskABxjh8/qSSfxP6VG2n37 xpGysUTO1TIMLnrgZ4qSw8SQzxSyT8gunkpbRSSsymGOQnAXcQDJjO0dVyATW1FKk0SSxOsk bqGV1OQwPQg9xS9mjN4Cm3e7/D/IxzHrLFS01wSpyCZ+hxj19zUUNpqltu8gyRbuuyULn8jW jrGo/wBlaa93tjba8afvZPLQbnVcs2DgDdknHaoINcjNnHPcmFjMzeUNPd7sOowC3yoDgHg8 YHHOTij2aH9Rhe/M/v8A+AUv7O1DzfN2N5m7dv8AMGc9c5z1pyWeqRStLGZEkfO51lAJzycn NJpfigXhsIp4cy3UIdmgR3CPshbBG35R++65IAAycnA6Gj2aEsBT7v8Ar5HPy2eqTqVlMkgL biGlBycYz1644pHs9Vk8zeZG83G/MoO/HTPPOKvaxq/9l+SMW6+bu/e3c/kRDGON+0/Mc5Ax yFY54qUarbxzpbXDbLg7VfYrvGjkDCmTaFBORgHBOV45FHs0P6jT7v8Ar5GTLpuozyGSVGkc 9WeQEn8c01NLv43V0iKspyGDgEH8609I1y31a1tJFWSGa5h84RPG44ATdgkDcAXUZHB7d6Lf xDp11IiQzSMH2YkMEgjy6qyguV2gkMuATnLAdTij2aD6jT3u/wCvkU1t9ZSR5FknV3xvYT4L Y6ZOeail0/VJwBKHkCkkBpQcEnJ79zXSVTvb14JYre2iWa7mVnRHfYoVcbmZsHA+ZRwCcsOM ZIfIh/Uod2ZjQ64xUtNcEqcqTcdDjHHPoTUS2OrLGI180IFKhRMMYPUYz0PetR9WjtFRNR2w zld0iw75UiXJAZnCjavB5YAcN6E1BdeJLOC1vJIvMke2SUhXieNJGjDbkVyu0n5W6Z6E9jRy D+pw7spT2OrXW37R5s237vmTBsfTJqP+y9T8nydjeVu3bPMG3PTOM9a2F13T2lETTNFJ5XnF JonjKx/Nl2DAbV+Q8nA6f3hmI63HLdWUVtuzNceVKk8Lxuq+VI4IVgDglMZxg4YdRwciF9Th 3ZmNpepvGkbIzJHnYpkBC564GeKj/sW//wCeH/j6/wCNdZWZqGsfYHu0MG5obYTQqXwbhiWX y14652DjPMi8cjJyIf1Kn3Zjf2Lf/wDPD/x9f8aT+xb/AP54f+Pr/jWtP4itYLhstGbRUVzc qxZTmOSQgbQckIitjPRwfQNONcsTEzl5lZWC+U1vIspJzjEZXcRw3IH8LehwciD6nT7swv7E v/8An3/8fX/Gk/sTUP8An3/8fX/GtSy8R20tqJbpmjYyyj5YJMRxrK6K0nH7sYXktgcN0wcX H1mxjjeR58KiTSMdjcLE22Q9OxOPftmjkQfU6fdnP/2JqH/Pv/4+v+NJ/Yeof8+//j6/4119 UdT1WDSjaNdPHHDcTeU0skgRY/kdgST7rj8aORD+qQ7s53+w9Q/59/8Ax9f8aP7D1D/n3/8A H1/xrZg8S2M5uCknnJHN5UbWoacygIjFgEBOAXCk9Acc84pkXiO2+1XMUjNIolxb/ZYJJi8f lROW+QHjMo54HIp8gfVId2ZH9haj/wA+/wD4+v8AjR/YWo/8+/8A4+v+NdfFKk0SSxOskbqG V1OQwPQg9xTqOVD+qw7s43+wtR/59/8Ax9f8aP7B1H/n3/8AH1/xrsqKOVB9Vh3Zxn9g6j/z 7/8Aj6/40n9g6l/z7f8Aj6/412lFHKh/VYd2cX/YGpf8+3/j6/40n9gal/z7f+Pr/jXa0Uco fVod2cV/YGpf8+3/AI+v+NJ/wj+pf8+3/kRf8a7aiiw/q0Dif+Ef1P8A59v/ACIv+NJ/wj+p /wDPt/5EX/Gu3oosH1eJxH/CPan/AM+3/kRf8aT/AIR7U/8An2/8iL/jXcUU7D9hE4b/AIR7 U/8An2/8iL/jR/wjup/8+3/kRf8AGu5oosHsInC/8I7qn/Pr/wCRF/xo/wCEd1T/AJ9f/Ii/ 413VFFh+wicJ/wAI5qn/AD6/+RF/xo/4RzVP+fX/AMiL/jXd0UWD2MTg/wDhHNU/59f/ACIv +NJ/wjeq/wDPr/5ET/Gu9ooH7GJwX/CN6r/z6/8AkRP8aT/hG9V/59f/ACIn+Nd9RQHsonA/ 8I1qv/Pr/wCRE/xpP+Ea1X/n1/8AIif4139FMfs0cB/wjWrf8+v/AJET/Gk/4RnVv+fT/wAi J/jXoFFAezR5/wD8Izq3/Pp/5ET/ABpP+EZ1b/n0/wDIif416DRQP2aPPf8AhGNW/wCfT/yI n+NH/CMat/z6f+RE/wAa9CoouHIjzz/hGNX/AOfT/wAiJ/jR/wAIvq//AD6f+RE/xr0Oii4c iPO/+EX1f/n0/wDIif40f8Ivq/8Az6f+RE/xr0Sii4+VHnR8Lav/AM+n/kRP8aT/AIRbWP8A nz/8ip/jXo1FO4+U85/4RbWP+fP/AMip/jSf8IrrH/Pn/wCRU/xr0eii4WOKFl4jGmR6c1hb SWkalfLlEbhvmLcgtg8n9BRZ2PiLT9/2HTbK28zG/wAmKJN2OmcHnqfzrtaKLhY46KLxPDax W62VsYotxVXWN+SzMScsf7xqRD4qjbdHZWaNgjckMIIyMHkGutoouFjidPsvEumJcC1tY1Nw 4dyWQ9N3A+b/AGj+lWvM8X/88Yv/ACH/APFV1lFFwsclpum6y/iSDUNSgVQAQzqy/wB0gcA+ 9dl4N/5Fm2/66Tf+jXqKpfBv/Is23/XSb/0a9NAzdooopiCiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigDBn/1g/3F/wDQRWIslxp9/fmPTby6 W5mWUPGYQo/domBukBP3O4H9TU8e69d+H7OC5tNpLbQysAc/KtcD/wALR1f/AJ5xfkP8Kmw7 ncR+DEighBltbmSJQq/a7TzY8eVFGTt3D5v3IIOeAxGD1ro7aBbW1hgQ5WJAg+ULwBjoAAPw AFeSf8LR1f8A55xfkP8ACj/haOr/APPOL8h/hRZhc9Q1y3mudLZbZWaZJYpUCqrElJFbozKC Pl/vCqFtDq95Kl1OFtLyBWjRprZTG8b7SRtSZjuBQclgMHoeo8+/4Wjq/wDzzi/If4Uf8LR1 f/nnF+Q/wosFz0HTPDb6U9vJDeK0kSrGxeHho/LhRgAG4Y+QpByQMkYPWt+vH/8AhaOr/wDP OL8h/hR/wtHV/wDnnF+Q/wAKLBc9N1ifU4fJ/syHzc7vM/cq+OmPvSx47+v4d8zTvC8MUlvc LBHEE8skXdtHJcqY1VFxIGKqCEU8AnlsEEjbwv8AwtHV/wDnnF+Q/wAKP+Fo6v8A884vyH+F FguejQ6LdWkVoLa9hElnE1vC0luWHknZwwDjL/u1+YEDr8vpT0zw7eWyvaTXEf2GOa3dcRfv JTFFCAwbdhQWj5BUnAPPII4X/haOr/8APOL8h/hR/wALR1f/AJ5xfkP8KLMLnsFU72yeeWK4 tpVhu4VZEd03qVbG5WXIyPlU8EHKjnGQfK/+Fo6v/wA84vyH+FH/AAtHV/8AnnF+Q/wosFzu tVstRd5U8qS5+2Wwt7uS3hjVSgL4CB5gUbDtydw6ccEVak8PrfaZFbTySRK01xO67RvAmWUF cgkAr53XkfL7153/AMLR1f8A55xfkP8ACj/haOr/APPOL8h/hRZhc9LbR3ulvvt9ysjXtotr IYI/LAAMnIyW5xJ79M98BqaNO+pQ6heXcclxE6kiKEohVUlUDBZiDmZiTnsBgda82/4Wjq// ADzi/If4Uf8AC0dX/wCecX5D/CizC57BWLrMDTX9lIunXVyLdt5aFowGGQ2z5pFIIdI2zg/d x0Jrzn/haOr/APPOL8h/hR/wtHV/+ecX5D/CiwXOzj0BrzTzp/2W6sEDSuJphGwIMLQomFkY 5VGQZ77OeTWxeaO9xqf9oQXKxzosflB496gqJQSwBBIImPAIwQDz0rzT/haOr/8APOL8h/hR /wALR1f/AJ5xfkP8KLMLnfr4anFvcRG+jP21Hjuz9nPzK0kj/u/n+Q/vXGTu7ccHMs/he1n+ 07m/18wccH5UO7zE687vNn56jzePurjzv/haOr/884vyH+FH/C0dX/55xfkP8KLMLnsFZ+qx yF7G4it5rhra4Mnlw7MkGN06uygD5vf6dx5f/wALR1f/AJ5xfkP8KP8AhaOr/wDPOL8h/hRY LncNoTare3F3PZLDIZS6JqNvHPHhkjU4VJD8w8kHJI4YjB6iVNBvbHV4pdOuIVjMUgZ5oAwX 5LdFXarJyfKJyMAdMdK4L/haOr/884vyH+FH/C0dX/55xfkP8KLMLnrNjaJYWFvaRFjHbxLE pY8kKABn34qevH/+Fo6v/wA84vyH+FH/AAtHV/8AnnF+Q/wosFz2CivH/wDhaOr/APPOL8h/ hR/wtHV/+ecX5D/CiwXPYKK8f/4Wjq//ADzi/If4Uf8AC0dX/wCecX5D/CiwXPYKK8f/AOFo 6v8A884vyH+FH/C0dX/55xfkP8KLBc9gorx//haOr/8APOL8h/hR/wALR1f/AJ5xfkP8KLBc 9gorx/8A4Wjq/wDzzi/If4Uf8LR1f/nnF+Q/wosFz2CivH/+Fo6v/wA84vyH+FH/AAtHV/8A nnF+Q/wosFz2CivH/wDhaOr/APPOL8h/hR/wtHV/+ecX5D/CiwXPYKK8f/4Wjq//ADzi/If4 Uf8AC0dX/wCecX5D/CiwXPYKK8f/AOFo6v8A884vyH+FH/C0dX/55xfkP8KLBc9gorx//haO r/8APOL8h/hR/wALR1f/AJ5xfkP8KLBc9gorx/8A4Wjq/wDzzi/If4Uf8LR1f/nnF+Q/wosF z2CivH/+Fo6v/wA84vyH+FH/AAtHV/8AnnF+Q/wosFz2CivH/wDhaOr/APPOL8h/hR/wtHV/ +ecX5D/CiwXPYKK8f/4Wjq//ADzi/If4Uf8AC0dX/wCecX5D/CiwXPYKK8f/AOFo6v8A884v yH+FH/C0dX/55xfkP8KLBc9gorx//haOr/8APOL8h/hR/wALR1f/AJ5xfkP8KLBc9gorx/8A 4Wjq/wDzzi/If4Uf8LR1f/nnF+Q/wosFz2CivH/+Fo6v/wA84vyH+FH/AAtHV/8AnnF+Q/wo sFz2CivH/wDhaOr/APPOL8h/hR/wtHV/+ecX5D/CiwXPYKK8f/4Wjq//ADzi/If4Uf8AC0dX /wCecX5D/CiwXPYKK8f/AOFo6v8A884vyH+FH/C0dX/55xfkP8KLBc9goriPBmv6v4u+3f6X DZi0CEkw7924ke2On610/wDZ2q/9B22/8Az/AI0rDNCpfBv/ACLNt/10m/8ARr1laY1z/aGo W11drc/Zoo2Vki8sZYntyTwP1Navg3/kWbb/AK6Tf+jXqkJm7RRRTEFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHnPju3a7k0uBNN/tMySqv 2TeyeaNq5+ZSCuBznoMZPGa4Oy0a0h8VeGbey09dT064mGL14pAt8N+HYxk/KI+Rt/2dzZVg K6r4tf8AIGt/qv8AJa8epIDtPI1LW/Em7XNBv3kgtN/2bFxK+zfgPsklEjjLYwrrj73IDAg0 yCPVtQk0vSpZ7q2kthFZ2kkvmwq0ZMkgAJZJEdVBDF1RnKndgGuUvdOvNMmEOoWk9rKy7gk8 bIxHTOCOnB/KoYYZLiZIYY2klkYKiICWYngAAdTTA9Fu9Bi1HxkFl0pZD/blzFf73kQeQ7oY nc7htJ3vsxjeQAAx6si8EG68PwSP4fure9+yMXKJNuMgFwQSrEjJMEIwAB++PGWTb57NDJbz PDNG0csbFXRwQykcEEHoaZQB2Ot6PaRabPcpozWEBsra5gut8hSaZxFuiQuSCuHkbby2UJ3Y G0Yuv2f2P+zP+JX/AGf51hFL/wAfHm/aM5/e/wCzu/u9sVT1LVLnVrhZ7wxGRY1iBihSIbVG FGEAHAwPoAOgFVKANHQLL+0NZt7f7JLeA7nMEX3nCqWOBkFuBnaCC2MAgkEdT/Y2lPr/AJTa ZLEY7DzVsEhlM0svm7cNAZd4Owltok+6ofoStcLRQB2lloVs+s6nt8P6pPbweUvkPaO0kLOu 7mFZVcAkNtJc4AAO4sCJtI0SwlvL6aXRftNiL+SFJ43kltYkUgkGVXQxoAwPmsr5HIUbSG4W igDpoNKu7rwLcXEOkThYrmJ/tMSzFZows+9mGShCEAbgBjJyeTVg6NAunLJFpPnRrb20ttdf vT9tuHMe+DIba2N8o2oA48vrkNnlBDI0LTCNjEjBWcA7QTkgE+p2n8j6UygDsfE/h6K1h1qW z0eezh0zUVtlkJkbfG+85YtxgYi24xxIMliQ1czpcUs2oxRwaf8A2jIc4tdrt5nB7IQ3HXg9 vSqlPhhkuJkhhjaSWRgqIgJZieAAB1NAHXX2hvF4x16KfTZ7mZGlmsrSfzS12DOFB4IdxsLt kHJ2ZJIBqzrWn3Fz4j1OS60W6u3GixXAF3cGOSDEEYMzMQPMKsGBGOTnjiuImhkt5nhmjaOW Niro4IZSOCCD0NP+yXH2P7Z9nl+y+Z5Xn7Ds34zt3dM45xQBDXaaf9o/sK08vzf7H/sy7+2b c/Z/tP7/AMvzP4fM/wBRtzz/AKvH8NcXU32S4+x/bPs8v2XzPK8/Ydm/Gdu7pnHOKAOu1Y6l a+CNNgh0aW30+4tFluLhBcKhfzmCsw3+WSwWM5YH7wxgbQC80q7Fz4QPiG1uorIRx21xJdq8 aov2mX5CxxtxHjAyMLjtXF0+GGS4mSGGNpJZGCoiAlmJ4AAHU0AddrEC3N3pn9u3Go6Zblph 9jv3LNAqqpUoqxjy0cnYNsZC7CfmxtG1f6THqFzpV3qa/bA+mSPbW1nbTlZT9pJVI428tmRY 5chVYEKgP3cbvPbrTryxVGu7Se3V2dVMsbKGKnDAZHJB4PoarUAdvY6Jpj6nqqnStRkkhaER ae9m7yqHQl3MSyq4UMFAJdsB1B3Egiz4R05LbxBaTadp1/O6au0MpJZZ7GFSmwyBOF3bpA+4 EEIwG3k15/RQBom006G3kS8ub+DUY9ytbfYl2q4JAUsZAR2z8vHPBxXR6h9o/sK78zzf7H/s y0+x7s/Z/tP7jzPL/h8z/X7sc/6zP8VctHpOoy24uI7C6eBo3lEqwsVKIcO2cYwpIBPbPNVK AOu1fSNRZPCw1i3ureE262sk13uiWP8A0iXCl2U7MJgjIOFwcEVpXPhaw+1aXcy6Xf2VvNJc RSQyWkkW90iDxKEeVmYuxK4DruxhdpBY+f0UAdHren6Xa6wkc9vqmkwtbhyj2OGL7iPlR5ch CB1Ln5ge3ANCgsBqM7WWo7bobY7D7VbSKzO4ILhYhIQ6nG0A/eKtn5dp5yigD0u40vX7fxTr UlhBdXNtJqcgFtbxMEuXchgs5IH7oK6538HcQvDM4yLI6la/D9JNP0aVo7mS6S5uohcLuiCp hnKOFIG6QDcCvynjO7PF0UAdpqH2j+wrvzPN/sf+zLT7Huz9n+0/uPM8v+HzP9fuxz/rM/xV hJZ6NNeWcNtf3Unm3CJJ9qgS2RUJwSZA8mPrtOOT2wciigDvbzRjpV9oOr6bot5DIt6Q1rPb vbCQx7JECh5JDuf5wPm+YrgLkHNO7/tgeIbaS3k1aW+e2DPbTXG6+t08wgxq5XcGKjf8qghJ DkFdxPHUUAd7Hptjfaxqkt1Zz313GtsBaQwPPIC0WZWkVJI2LqyqrvkDexyoLDbzL2mjR3l5 Fc3OqWnl3DpHE1kkjqgPG/MiYfsRjtWRRQB2+nGT/hFI0VJzZtZXJmlRiLNJMy7VmTGGmOE2 sWUjdD8p2jczVIdnhbZZ/b7TT1tLeTeJv9EvZiI/MQKFGZAzOSSzEeURgBRt4uigD0PUJY3m sl1Np7WWfVYJILLV7YCKyg+feqqX/wBSNyA8RhgnH3TtsWy6jdX9us9prJme01BLi1upWku3 h8gbcuUH7sucIChAcMfmJwPNKKAOrNjp1lrNpNfpBpky232iSwuUlaJZxKyrG64d1UoFchs5 BwCoYEdHf2NzZardztDqN/rLW1hsaxeSK5CeSVlcF4i2C0agsBkbtpIJZT5jRQB2+hLqEWvX cUdzPf6YL10ubyGQeU/zDMt1jJeEruO1mAIL4YfMarWmj6a/hFbr7Bf3c728sktzbWzSLbyK zhVaQSBUGFRmDIx2sSCMjbyNFAHXano+m2/hZLi2sL+R/s8Mgv0tmMJkYLvVpfMKEAsy4CKQ wAJODuv6lo2k6fqWm/ZrKeG3XUYolv7y0b7JPFk/O7tKVkBADfKI1K7jjkY4KigDqPFzXD2e ntfRX8N15kwMeqSGW62Yj2kuVU+WTu2jbwRIcnOBy9FFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQB6h8HP9Xr3+5B/6E1dDZ6j4mfxC/2rRfL0iTCJiaIyRf7Z w3Oc8gdBjGSDu5b4T215cprC2d4lqP3O8tD5hYfOcdQB0/8A1DNeh/2Rq/fWYv8AwDH/AMV9 f85xLGR6d/yHda/64QfzNavg3/kWbb/rpN/6NeqdhpU9hNe3F1drcy3EaAlYvLxtb0yfX26e ucXPBv8AyLNt/wBdJv8A0a9NAbtFFFMQUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAec+O9/maX5X2Dd5q5/tHb9nxtXO/dxjGff05xXB2U1j b+KvDM2lSWcelRzBke7MAnUB8yG4PZuuzP8ADs2/Nmuq+LX/ACBrf6r/ACWvIYYZLiZIYY2k lkYKiICWYngAAdTSQHUWSznXjJqEeiSyRW25Ujns4kYbsfKQDCX5Jw4J2g45CkTSPaXGoamb KPSXui1uqxTGGKHyhGRMoYlU3b9gLxlSfmZNoJxy97Yy6fMIpngZiu7MFxHMuPqjEZ46dahh iaeZIkKhnYKC7hVBPqSQAPc8UwPQpW0+68WRSS3GjeTBrVxJcSymFlktpWQpk4PmZzIM8lM/ MUAyCLTLCfw/BBeSaELtLRoyUurVG34uCuWVhk7ltPmz684aTPAXdrNY3k9pcpsngkaKRMg7 WU4IyODyKhoA7TxAsAsJnuLfS4FmsLSW3FsIlla5ZIS7MiHcgKGXjCp0ONxBOFr/APzDP+QX /wAeEX/IO/H/AFv/AE1/vfhVG91G81OYTahdz3UqrtDzyM7AdcZJ6cn86rUAaOgRrJrNuHW1 ZV3PtupVjjbCk43N8oJxxuBXONwIyK6n7RpT6/ult7AzJYbYoEktUQTebn5pdnkOfKLHJTHR fvrmuFp80TQTPE5UsjFSUcMpI9CCQR7jigDsbIWw1nU50sNLVR5SiB9RtCQSuWZGkRoWBIyw VQVLKFwNwM2kTafHeX12U0aW0kv5D5j+SmyIEHd9nlDOY8NwkRVzhlJztxwtFAHRw2zXPgqb e2liSK4SSDMtulwYws3mZ5Ejc7MKck8YGKtn7L/Zy+R/Zfk/Z7b7Fv8AI837XmPzPM3fPsz5 /wDrP3eMdttcjRQB2PieG0nh1qS2TSYo7XUVFmtpNCGaBt5YgK25wSYjznbyF2gMBylrbPeX CQRNErvnBllWJeBnlmIA/E1DRQB2kyWqePNXuJnsLlZ5Jp7UfaYGSTdLx87bo0O3cf3gPTAA YqRfuraK2t9TOlf2JuuZrOaKKe/tJFjYQyecdpYISHcrgrt+bKqMAjhYLC4ubS6uYVVorRVa bMihlDMFBCk5IyQOAcZGetVqAO6059BX+0FsbG1vI2v5gEuLyC3/ANF+XygGnUtz8/KFXHc5 24xbSyd/Bt8fPs1aS5hnWN7yJZCkaThjsLbs5ZcDGTngGufooA19R/5F3Rv+QX/y3/49v+Pn 74/1/wD7L7VnWl1NY3kF3bPsngkWWN8A7WU5BweDyKhqzd2FxYrbNOqhbqETxFJFcMhJGflJ wcqQQeQRyKANHw/rLWfiHQ7i8lUW1hMi5eIOI4vMLNxg5PzuQeSD06CtewEUeqvLrI0ma7Ns RbQW0lpHGGDryzBGgBKGX7+T8vY7DXHUUAdpZC2Gs6nOlhpaqPKUQPqNoSCVyzI0iNCwJGWC qCpZQuBuBZa6lvh1yz0uTSS0uorcQfaLaCKJoh5oJUT8KBujwhOQCcfxVy4sLhtNbUAqm2SY QMwkXcHILAFc7sEKecY4PPFQpE0iyMpUCNdx3OASMgcAnk8jgZOMnoDQBbm1G6jjezS6WW3W E2oZE+V4vN83jIBwX+bJwe3tVGiigAop7xNGsbMVIkXcNrgkDJHIB4PB4ODjB6EUygAooqa0 tZr68gtLZN888ixRpkDczHAGTwOTQBDRRRQAUUUUAFFWbKwuNQaZbZVZoYXnYNIqnYgyxGSM kAE4GTgHjioYoZJ2KxRtIwVmIQEkAAkn6AAk+woAZRRRQAUUUUAFFFFABRRRQAUU9ImkWRlK gRruO5wCRkDgE8nkcDJxk9AasW+l3NzZy3aCJII85eWZI95AyQgYguQCMhcnkeoyAVKKeYmE KykrtZioAcbsjGcjOQORyeDzjocMoAKKvQ6NfXC2DQxK41CYwW+2VCWkBUFSM/KfmX72OCD0 qjQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAeqfBb/mNn/rhz/3 8/z/AJyPVOntj/P9Pbp2x8vlfwW/5jZ/64c/9/P8/wCcj1Tp7Y/z/T26dsfKhkc3+rcf7HT/ AIEv+f8AOBX8G/8AIs23/XSb/wBGvVib/VuP9jp/wJf8/wCcCv4N/wCRZtv+uk3/AKNehAbt FFFMQUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAec+O7hrSTS501L+zDHKrfa9jP5Q2rn5VBLZHGOhzg8ZrgINdsh4k8O3trf/wBm6ZaSbvsO 6Z/sKhyZF3Bcv5gycjP3tpwFBrs/ihaXF9p1pb2dvLcTuRtiiQuzYVScAcngE15NZ6JqV/NZ xWtjPI18xW2OwhZSPvbSeCB3PQd8UkBu2Wpywa8bq78TQXcyW2I7qf7Wyk7v9XvCrKhwWbK8 fwk4ZhU0mvRXeoanJFqq211O1vi8uEkdJI0jKSRHCs7IzFCA4O5UG/5uuLqHhrULDVItOSKW 6upo/MSOK2mVmHPRXRWP3ScgY9+DismjX5vpLSW0nglhXzJxJC+YI+Mu4ALBQCCTjoaYHa/8 JFpzeJre6bW2jtrHWJ7xHSOUl4JmjOxBgYAw+8HHDHbvzgui1XSX8Pwafe+IrWd4rRrcb47l lGRcYAzF0DPbH/tiP7i1x134c1W11I2Isp5pTNLDEYYnZZzGSH2cfMBg5x071Wm0nUbe3S4n sLqKCSPzUleFgrJlRuBIwRllGf8AaHqKAOy8W3NzbW0kGsXbPNdadaeXZyRSCSOYLFumfcoU thJELhmbnb0BA5nX7z7Z/Zn/ABNP7Q8mwii/49/K+z4z+6/2tv8Ae75qndaTqNijveWF1bok giZpYWQK5XcFORwdpBx6c1FcWlxaeV9pt5YfOjEsfmIV3oejDPUH1oAl0uWWHUYpINQ/s6QZ xdbnXy+D3QFuenA7+ldZLrFta6p4qurDXoAuoq01sFjm5kM4kXgx4Dqqthv4S4w3UjjrW0uL 64S3s7eW4nfO2KJC7NgZOAOTwCasHRr9rm6gt7Se4NrMIZGihcgMW2qCCAQSeACAc8YzxQB0 0+p2sd1d/wBna/Fa3lxHau2oxidNxSIrMpYJvJeQq/TDYyTu4rltWuLe71i+uLKLybWa4keG LaF2IWJUYHAwMDAot9J1G7vJbO2sLqa6hz5kEcLM6YODlQMjB4qpQB6Ha6xpc/hm1stQ16Bp UsjB5c0dw4jJW4wv+rIwGe2PHGYQR9xarW+r2914d+wWt9EtytvD9hhAuTcLdK6E7VQGJSSJ ArKAx3Dccs5rkJtJ1G3t0uJ7C6igkj81JXhYKyZUbgSMEZZRn/aHqKF0nUXt4LhLC6aC5kEU MohYrK5JAVTjBOQRgehoA6zx9cmO+1Wyu7tbi4Oo+bbwpE6C0j/eFhhlUAvvjYlMhiu4k8E5 3gOO8m8QyR2O7L2Vysn7ppEwYWxvQBty79nGDk4GCcCsK6068sVRru0nt1dnVTLGyhipwwGR yQeD6GmW9pcXfm/ZreWbyYzLJ5aFtiDqxx0A9aAOuXW4I0vpRrUT6kumC3+2OkrNczfaBKGV mTOVjVUDNtIYLjgBhNDrNjZatdT2erWpnuLe23XLfao0Zlj2zbmjVZd7OA391skt8wXHMw+H r+U30TRNDeWaxs1nLG4mcO6oNq7euXTg4J3DGarW+k6jd3ktnbWF1NdQ58yCOFmdMHByoGRg 8UAdrZa7p+j6pqNxp2sWsNnLfvMsUEVxFIIeGXy9oCMcEqElBRSv91mzm2mu28fhFbCGWwiI t5UnhuftO6aQs5DqqZiYhSgVnGQyDsqmucsdJ1HVPM/s6wurvy8b/s8LSbc5xnA4zg/lTU06 8ksZL6O0naziba9wsbGNDxwWxgHkfmKAK1buurZf2bpKWuq2t3Ja25gkSJJlOTLLJuG9FGMO o65z2xzWFWjeaO1pZm5S7tbpI5FimFuzHyXYMQpJADZ2PyhYfL15GQCbxTefb/EV1c/2p/au /Z/pn2fyPMwij7nbGMe+M96f4XvEsNSkuGvoLN0hPltOsu1ySBt3RfvEOMncvXG08May7q0u LG4e3vLeW3nTG6KVCjLkZGQeRwQaLW0uL64S3s7eW4nfO2KJC7NgZOAOTwCaAO9sfE9gmo3l 3LqqrcXFzbhLlxOWg8u3kQzLgZdQzAKr5Lrw4GS1Ymm3avpuuWd94kiVLzIVJTcMssoljczE CM9VRhk/N6gVipoeqyX0ljHpl415Eu57dYHMiDjkrjIHI/MUyPSdRltxcR2F08DRvKJVhYqU Q4ds4xhSQCe2eaAOyu7m5svC+jSapdsttNpU0S2ckUm+4JaURHJXaypuiZQzfKBlRyMni25u ba2kg1i7Z5rrTrTy7OSKQSRzBYt0z7lClsJIhcMzc7egIHG2+k6jd2ct5bWF1Naw58yeOFmR MDJywGBgc1NceH9XtdOi1CfTbpLKWMSrcGI7NpOASegyemeuQehGQDqU1W3TX/DOo3HieK4l sdsd3P8A6SXKiWRzyY8sCjBMe+MYyahttQguDppm1KK81Nbi6gi8mGUtEHjCW5QbBhEkBdVT ldw2rnIHOf8ACPaz5vlf2Tf+Z5nlbPsz537d+3GOu35senPSq4068ZbVltJyt2xW3IjbExBw QnHzHJA470Ab/jaS7RtIsr28+0T21ofNAV0xI00hJZHVWDsuwksoLcE5yCc7wx82trCOZLm3 uLaIf3pJIXjRfbLMoyeBnnApkXhnW5r42K6TeC7ELT+S8LK/ljOWwR04wPU8Dk4piaBqbS3c cljdRGzjMlxvt5P3I2lhvwpK5A4JwO5IGTQB0eha3BbaXoVrc61FHBFfyPd27JKxFs2wmMkI QUYo+UBIJdSRwStaDVLS20gWw1JTbQ21xBNZIsm27mYyeXMFKhSBuiOXIYeX04XPPx6TqMtu LiOwungaN5RKsLFSiHDtnGMKSAT2zzRa6TqN8iPZ2F1cI8hiVooWcM4XcVGBydoJx6c0AVK9 An8XR2FxpuzVvtcNnfxTAWInQNCgZW3JLhYyVbASLCYLA8Bcef1ozaBqcF5b2TWN19tnjMi2 32eQS4yw+6VBPCk5GRjvkEAA6nS77TLKxsIH8Q2ryWP24ATW8zxfvoFVAgMZym7JYMF5LcEc mnF4iFprtrMuqyyT/YJrS51GNpB5sj+ZsckgOwTdFyRkeXwDhc84uk6i9xBbpYXTT3MYlhiE LFpUIJDKMZIwCcj0NTQaDqN5qlzp1jay3VzbeYXWKNgcJ1OGAI9MEA5IGMnFAHQabqn2aXWf M8VK1zd20aC5nSd1eUSKwZTsLZRFIDFVZWb5em6n6Hr8VlZ3MDXtg1093JJcXF8bspeIQoXI i5kGQ5Kyj+PpywrnE0DU2lu45LG6iNnGZLjfbyfuRtLDfhSVyBwTgdyQMmq9tp15eQzzWtpP PFbrumeKNmWIcnLEDgcHr6GgDpbTXbePwithDLYREW8qTw3P2ndNIWch1VMxMQpQKzjIZB2V TRd63GnhFtNTVIp0kt4lWC3WdGD7kdhIjfugAQw3R/MzBST8z55xdPZ9Hl1FZoikVwkDxfNv BZWZW6YwdjDrnjpVSgCzp3ljUrXzplgi85N8rxCVYxkZYofvAddvfpXoWn6vea3rdtbWd99r ljtL7zTCLme3VHhwu4TBpG+dVyuCv3MDcTni4vDGpzWCXMVtK8kkiLHaiGTzZFdHdZFG3DIR G/IJ+6eMc1WttD1W9WJrTTLydZlZozFA7BwpAYjA5AJAPoSKAOmtdftbfVkllvYrm9WwMB1O UzhWm87fvLrtm/1X7vIGeNv3Oah/tlXvdUa31a1029uJIHW/tftCxsiowdd20y5ZijHcPmKE k5xnnItJ1Gfd5NhdSbfL3bIWOPMx5eeP4sjb65GKrzQyW8zwzRtHLGxV0cEMpHBBB6GgDqLP UkvbPxBFe+IVij1FiyRXEcqh5POjfzWSNWRSVVhwSQeOnNMi1SQeCrexh8SfZnSS5aSy33A3 xsqBY/lQoclXOCcfP15OMK109ruyvrlJol+xRrK8bbtzqXVMrgY4LLnJHXjPNDaXdppa6jJB Klq8gjjkaJwsh+bO1sbTjaQRnPoDg4ANjUrmO78J6dDNrkV1dWckjLbt55ZI3WJVjUsm0bdj ZGcehNa+r+JdPu7yxmb7BPpkN/HOtmi3DzRQAkmPbKfKUbcAqhCkhccAY5D+ydR/s7+0PsF1 9h/5+fJbyuu372MdePrU2peH9X0dFk1LTbq1jbbiSWIhSWXcBnpnHbqMEHkGgDa1V31nTdKs E1iDV9UN7Io2LKHkEgiVNzyIu4goRljkAqOg4xfEN1DfeJNUu7Z98E93LLG+CNys5IODyODW dRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAeqfBb/mNn/rhz/3 8/z/AJyPVOntj/P9Pbp2x8vlfwW/5jZ/64c/9/P8/wCcj1Tp7Y/z/T26dsfKhkc3+rcf7HT/ AIEv+f8AOBX8G/8AIs23/XSb/wBGvVib/VuP9jp/wJf8/wCcCv4N/wCRZtv+uk3/AKNehAbt FFFMQUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAeZ/EWS3hi06W8muoII5UdpLQDzVwFI2ZIAOcc54684xXnQ8QadP4k0bWJ0ltvssivcWlpb qIYtj7lEKl+A3VgcYYs3OcV6R8QNPj1U6Vp8s7QLdTxwiRIw5UsFA4yOMkZ56evSvL7/AMMi LU7XS7CaeTUp22ta3sKWzplFZOTIy5YNjBIIIwRkikgGafc6Tp1/K0V/fmB7faHawifL7wdr xNIVdMDPJ4bacfLVltes7ie8R5ryzjkmtp4rm3jVpFeFGQEJvUIDvLAK2EwFAIwRmxeHNTnv jYxW6yXghaY26TIZABnK7c53jBzH9/jpTI9CvZbiaFDa/uNu+U3kIiBYZA8wtsJIzwDnhvQ4 YHR/8JPoz+IEvpVv2gt9Xk1KJVjRWk8wxllb5iF2GPjGd+cfJ1qa08R+HrXR47D7RqjbLdof M+xRjOVuhnHnf9PX/jnvxzMXhzU5prSFbdVlvJpIIkkmRG8xMBkYEjY3I4bBORjORTI9Bv5N LGpLHELI7wJWnjUbl6py2Q+DkL95hyARQB0HiO9trOFoReteXNxpVrZ7I3jkhtwnlM22RZGy d8RG3av3icnjdz+r3dvd/Yfs1xfzeTaRxSfbXDbHGcrHjpGOw+tZ1bs3ha8g0f7VIkv2o3cd qtsiB8s6sduVYkSApgxkBhuXPXFAGRarbvcIt5LLFAc7nijEjDjjCllB5x3FdLc65pR1DxJd 2l3qKNq0LiMfZkUqXlEjKxEv3cKFz3DnjjB5++0u507yzcCJkkztkgmSZCRjI3ISMjIyM5GR 6im2VhcahMYrZVJVdzNJIsaIOmWZiFUZIHJHJA6kUAb99q2jXqzWnn36WssdmfO+yoXDwQtF jZ5mMMG3Z3cYxg9awtWvv7U1i+v/AC/K+1XEk3l7t23cxOM98Zqz/wAI7qIu5rd0gRoVRnkk uoliw67kxIW2EsvIAOSAfQ4LLw3q2oTGG2s2Mwm8jynZUcyD7yhWIJK5BbH3Qctgc0AdHp/i TQrfQYLGaXURKtsYXKWkZUFlugcZlGQPtXtnZ23cVodc0+80afT2kliuLq0itUU2sOFdGjIL XLOH2Ex9DwgYAZCCsi58L6ra24uGgikhMZlDwXMUwKgkE/Ix/uufojnojEQjQb828c5jiVJN pw08YZFYgK7qWyiHK/MwC/MvPIyAbvjXUrRtR1i3tryW+e9v1uWmYoURUEgRUZXbeNsuP4du 0DHYUfBRC+IRIbxbMJbXH78zJGyFoXRSpZlBbcwwMj1yACRTvfDmp6bMIr23WFzN5DB5k/du egc5+QHBILYBAJBI5p9/4Zv9P1Q6e5tZp/MdP3F1G4Gz7xbBygAySX24AOcYOADRTXdOgsLu 0guL9MaYbC3lWFVMu6czMXAk+QHOzALZBJ/2ambxBpIupRDLdCGS3tU82ewimw0MXlkeS7lD kYYPncvKjhiTkW3hm/utRayBtY5BbvcK73UYidFBJKuDtb7pHB4IOcBWIZb6DczT3cReAm0h aV/JuYZCQEZ/l+cbx8vO3JUZ4zwQDoD4m0lNUvb6Oa/YTX8l4lvJZxEENtbCuXLQPncpkTJw EPBUCqNv4ihXQIbTzmtri3tpbZdmnwzGUOzk/vWIeMESFSFzgDPcisey0a+1GEy20Ssu7Yoa VEaVv7sYYgu3I+Vcn5l45GZn8OanHYx3pt1NvLD58bLMjGRBncVAOWK4O4AZQcsBQBl1u63d aNNZpFpc1+VhkAggmgSNEQg72Yh2LyMQmWwOmMABVXCooA0dfu7e+1m4uLO4v7iB9u2XUHDz thQDuI4PIIHtijSLy3the294ZUgvbcQtLEgdo8SJICFJAbmMDqOue2DnUUAbqajp00F5YXM9 +trLJA8dwY1ml/dI6AFCygAh8gbjtChfm61rx+K9OkvLK6nkv4dmtS6rcW0cSunzFSqglxuI 2YyQP9Y3phuLooA6aLWdOtNIa3huLydxDNCsctpEv3y4UrMGMka4YMYxkE7wThyaoS3mnXek 2iXJulurK3eCOKNF2SZkdw5cnK4Mn3dpzt6jdlciigDqL3XdOXWdJ1SzuL+6fTvsqLbXMKxr shVQdrCRsZZScbeNx69yDWNGsrG0tbZr+TypLpZJJIUXclxAIi4UOcFcfcyd2M7lzgcvRQBt W+pWdlqcJilvJ7NLaW1LzBQ6iVHUlY8kKB5hO3dyQTkbuJtLudCsNQlkNxqPlfZpYFcW0ZaQ yRuhYr5g2Bd44y2cE5XOBz9FAHV6XrmladDo8Ju9RaKx1Vr6VBbIFkA2hOPN+9+7HXp5jYJx 81nTLyyXS5Ln7fLAlnYXenrGTGDdK/mshZPM3j5pV4CuoKg7upXi6KACurh1XQrXUPDtxHc6 jIuksu8NZxqXAlklyP3p5ywXHpk57VylFAHQXF7pV5pttbXF/qLyre3FxNO1qjMwkCgHmXlv 3ak5P8Z5O35n3esacfF15qds109rffafMEkKo8XnK6nADkNtD56rnGOOtc5RQB0Gl3OhWGoS yG41Hyvs0sCuLaMtIZI3QsV8wbAu8cZbOCcrnAt+GvEOnaNNCJnnMVre/aEY2UU7TJ8vADv+ 5b5PvISTuGT8i1ylFAG7HcaNH4fvbIXd+Z5rhJo/9DQL+7EqqCfNyNwkBPB24I+brWFRRQB2 h8V6dHJNeRyX8k8mrw6sLN4lWJHVnLoH3k8hwN+wZ2DI54hsdW8PWljDa+fqn7n7YPM+yxnz fPgWLO3zBs246ZbOM5GcDkaKAPRZtY0nWpNXurXULqzjawmikMqxRynzLvz9samYeZlWdSMj gdywWuI1i9jv9Q82FWESQxQIXADMI41jDEDOCducZOM4yetUaKANrRbnSrfT9Ri1C4vI5byE QAQWySKoEkcm7JkXn5CMY75z2otrnSk8M3VnLcXi3k80c4VLZDGDGsqhd3mA4PmDJ28Y6GsW igDo7vWrJtCa0hlup5pLeKIia2jjMZXYT++U75UBUqqMMAFT1QVT1O806/gS5zdC+FvDB5Ox REnloqb9+SWyE+7tXBbqdvzZFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAeqfBb/AJjZ/wCuHP8A38/z/nI9U6e2P8/09unbHy+V/Bb/AJjZ/wCuHP8A 38/z/nI9U6e2P8/09unbHyoZHN/q3H+x0/4Ev+f84Ffwb/yLNt/10m/9GvVib/VuP9jp/wAC X/P+cCv4N/5Fm2/66Tf+jXoQG7RRRTEFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFAHm3xA1CPSjpWoSwNOtrPHMI0kCFioUjnB4yBnjp6da8v g13TbXV9Lv4dOvGaxmErme/DvKEC+WmfLAVV2ehJBxkYGPQfi1/yBrf6r/Ja8+vtDtZvGT6F pbtbhblrRZL2XeHkDlQcogwDwMYOCeTjokBDY6ppWn6m1xFp141u1tLAYnvU35kRkLbvKxja xwNvXnPaptL8Rx6Q15FZJqNvZ3LRvi3vxHOCgYAGQJgqd7EjaP4eeOaaaIXuZIhqFmY4IfNu Z1Z2jg+YJgkKSx3MoygYfMCDjJDx4elSW4+1XlrbW8Plf6TJvKP5il48BVLfMgLcqMYwcHim Bc07xRDZ3kFxcWMt4bW/a+t/Ouju3MU3eYwXLnEakEbfmySGB21Wk1TSpNFTT/7OvA0U000U n21MAyBQNw8rkARp0Iyc9MgB8PhoCzv5L/U7XT57G7W0khnSRsMQ+fmjVh1QgYz0OSON2jp+ gW1xoUcj20WJLCa6e6d381ZV+0bI0AO3BFuSdynjf8wJUUAcjXUHxdbrJNdwadKuozX8OovI 9yGi85Gc4CBAdh8xuN2RxycHOdfaJBZaTZXo1a1kkurcTC2Ecof/AFjIQDs2nG05yR0OMjBM 2oeE73TLO1vLqSJbWeRI2n2SbIywJHzFMSDAY7o94468rkAh13W/7Y8j97qknlbv+P8Av/tO M4+78i7enPXPHpUOiajDpd49xLHdM/llYpLS6NvLExI+YNtb+HcpBHRjVm68Mz2utJpJvbOW 8MzwukTswjKnudvzE9lXc2fl27vlqzN4Lvbae5iubq1t/s9ut0WuBJFviL7C4DIGGG42kBj/ AAhsjIA+18YSQXd+4W8givGiZmsrwwzkxqVBeTadxbcWf5Rub5uOlWNA1vTReJc6tJKEsb86 hbhrhjNKzFSwYiJhIf3SdTHkk88/Ll2/h8m8u7ee5gEkFs1zGgZwbhPJaVWQ7CMbQGw20kHH Bzg0Pwzc67DLNDcQQRRMFd5RIyp33OURvLUf3n2jrgna2ADUsvGGnWujw2D6TdSbLcwtIt8q 7srOCQPKOP8Aj5kx16L1wc1LnxT9u0uGyvDqhRI4Ymhi1DZbske0DERQ4JVRzk/N82O1c5V6 CyjOkXV9csygMsNsFIHmSEgt16qqA5xyC8fY0AaWqeILPUYdYCafPFLqV6t4GN0rLGRuyuPL GR+8k7j+H0O4k8RWrav/AGommst5NM81xI1xnDMGyYcKPLILFlLbypVDng7q1xp9pLo+l3Nk ksU9zcS20ouLhChZFiO4HaoQEyHqTjHWrnivw3F4b+yRCXzLiXf5m2ZHUbNqHAXkfvFlxkfd 2j7wcAAffeK47u+sbn7PeSNb20tpK13eiaSaOTeD82wYYCVwCQRwvHBzWsNX0ixvZZl0q6MZ t3gRRegNh0dHZ2MZBOH4wFA2jIJyTQ03SZ9VW4W0ZZLmJQyWqhmlnGcHywAckdSMg4yecHGr pvh6we/1NL/VrV7bTYw7vbvJtmy6p8riJsAMw52nPGOCWABDp2v2+n+Riylf7DdteWObgDY5 2cS/J84/dp93Z/FzyMTW3iHTofsG/Tbp/sthNZNtvFXf5m/LD92cY82TA5/h54O5mneFn1qa 8ksLqCKzgmKCWXzXVV7M7LH8i453OEB5/usAaR4ejuraSe9mVd9lcXMEKTBZCI1ch8FSGXdG ylQQ/wDFjaM0Ac/RW1J4beOa8RtQswtpDBcNJ+92vFLsw6/JnA8xMggHngHFXJfA1/DqUNm9 3Z/vbkWomDPsEhLquflzgvHImcdUJOFKkgHM0Ve1DSpLCGGYzwXEUrNHvgcsqyLtLpnAyRuX lcqc8E81FZadeanMYdPtJ7qVV3FII2dgOmcAdOR+dAFait3SNKtxqVzY67ZX8c8VvLMEWQQM myJpMMrIx+YKMdMZzzWLMY2mcwoyRFjsV2DMB2BIAyffA+lADKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigD1T4Lf8xs/wDXDn/v5/n/ADkeqdPbH+f6e3Ttj5fK/gt/ zGz/ANcOf+/n+f8AOR6p09sf5/p7dO2PlQyOb/VuP9jp/wACX/P+cCv4N/5Fm2/66Tf+jXqx N/q3H+x0/wCBL/n/ADgV/Bv/ACLNt/10m/8ARr0IDdooopiCiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigDyf4tf8AIGt/qv8AJa8+vtctYfGT 67paNcBrlrtY72LYEkLlgMI5yBwc5GSORjr6D8Wv+QNb/Vf5LXCX2mWN74+fRYIl022+2tZI 0CvKc+YVVmDvyemcEDHIHYpAZqa0kNzI8GmWcVvND5M1qplMco3Bhkly4O5VPysPuj1OXjxD K8tx9qs7W5t5vK/0aTeETy1KR4KsG+VCV5Y5zk5PNEOlWM89wY9Qle0s7cTXEyW3Od6piNSw 3Dc68sUOM8AjBmfQLe1NzNe3sqWUXkbJIbcPI3nRmSPKF1A+RTu+Y4OAMjmmBWj16czXr31v BfrezC4mjnDKrSjdh/3bKQfnfjOPm6cDFkeJN1kVeCVbsW8lqr28/kxGJ3ZyGjRRn5nbADBe FBUgEGYaBp1pZ6r/AGte3UV1p9+tm32W3WVDkScjc6k5MZ9MYHBz8uppWlQXGgIDHAYm0q4u 5VECvM0oa4CPvPzIi+SgODjcVBB3k0AcyusN/ZyWslpazPFG0UNxIrF4kYlioGdh5ZzkqSN3 BGFxcuPE5u7eeK40qwd7q4S5uJczBppFLfMcSYGd7ghQB8xxjAwzUdN0q00fTriK8vGvLu28 4xPbp5efNdD82/IA2HHynOM8ZwtnVPC8Wl2cd09/5kaXCW90qqheJmDH5UEhb+B+JBG3QYBz tAK134ke51c6kmn2dvcSNKbjyvNKziQEOGDOcAhmHy7SNxx2xNN4q8zT3s00bToo2tjahkM+ 5I/M83jMpGQ/zZOfTpxRd+HbWDxGdGg1Jp5IZpY7iX7PtRAmTlSW5OAc7tqqRy2356sTeErS 3a5afVtsEdot7HIkSS74/O8pgfLkZQ+77oDEHjcyc4AK48VY1Brw6Npxka2FqFJn2rGIzEcf vc5KELk+gIwck1rPXxYYeDS7ATx3DXFvORJvt2O3AU78MFKggOG75zk5s2+h2qajd2s1yzut k11bZgysim3aYb8OCjBdvA3Dd1yByzw9oNprW4XGpfZn8wIsccaO5z32s6FvZYw7HB4GV3AG FVu8vvtNvaW0cflQWse0LuzvcnLuegyTgdPuqgJO3JqVow2sMWhXF7cpueeQW9qMkYZdryPx /dUquD183I+6aALiarY2dnosdv8Aap3s7t7ucMPI5YRfIjqxP/LM/NweQcVD4g8SX3iO4hlv ZpXWGMKqO+4BiAXYem5snHYYUcKAJnsoL/R9Ga2tIra6uLuW0d4/NfzNqw7WK5Y5zI3CDnsK 0fHXhmDwz9ghhj+aXzN0u2Vd+zbH0cY5Ks/BP+txyoRmAOf03Vp9KW4a0VY7mVQqXSlllgGc nyyCME9CcE4yOMnNyLxEkVzqUv8AY2nGPUFCyQASrGgDByECyAgFlU9eMYGBxUOh6K2vTS2d rIx1JlBtbcINs5HLguWAUhctzwcEcHGdLStP0Fb3V5Z7qe9s9PhEkLfZSFnBkSMllEqsBlxg bgT1OMbSAULPXxYYeDS7ATx3DXFvORJvt2O3AU78MFKggOG75zk5fp/iR7GGJJNPs7toYZLe OSfzQyRSbtyfI6gg+Y/JBPzdeBizpOh6drl5ckah9kjNxthhjiVnCk8HY8oZvQKhkbgjrt3P 0bRbFrYyX0iyT3WnXVzBCyOAAiyBWDqw+cPETtYbduec4FAFaDxTLHbyQzadYXQmt0t5mlVw 0qIU8sEq4K7Qij5cZx8244I14PHwutTtZNT061hgju47t5LRJGl3JI8owGl28tLIDnoHPHAA y5fD9nFNfg6hOYrW2trtWFqu545fKzkeZwy+cOMkHB5FaM/gSODVbe1OpsYZb1bPzRbDcCzy xq23fgjfBJnnhdp5JKqAc/quppebLa0t4raxgkd4o41YZLYBc7ncgkInG4gY47k51aOo6ZDa 2dvd2t39qglkkhLmMp+8QIW2gnJTEi4JwTzlR3r2VjLqExiheBWC7sz3EcK4+rsBnnp1oAsa Pq40iWWQWFrdvJG0WbgyfKrKyMBsdeqsRzn2xVGZ1kmd0jWJWYkRoTtQegyScD3JNdBoml6d DPqj623mf2fbrKI7fbcRPudE5ZJVzjzBwrDnqfl2thXbQveTtbLtgMjGNdpXC54GCzEcdtx+ p60AQ0Vo6bawmzvr67TfBbx+UiZI3zSAhBkcjADyeh8vafvCtVNFsbbQ9U8+RZtQisre6UFH XyhI8RXYwbDDZLhgygg425GTQBzNFdXd+DrTT762tbzW4Ii1yLW5IaFzExyNwUSk7ARhi4Qg EcE5Ay9U0i307ToZvtF0LqW4lj+y3FqImVEON5+cnk8Yx95XGfl5AMiiumi0XTW1xtKvJJ4G srKY3MkCB2e4jR5GGGYABcFODhvLyMbsitpmh2Wp3F0Y9QljsoNgWWWKONmZgeDvlVB91uN5 Y4yAQG2gGFRXUDwfCrw202p7L6W/m00Qrbll89GQA7tw/dneMtgMM8K3JFeHwwj6AuozajBD LLC88ULyRKGVGZcHLh9xKMAFRgTt5GTtAOfooq9e6Rc6fCJZpLNlLbcQXsMzZ+iOTjjr0oAo 0V00unWMnicRrarHbDTlvfs6O+wsLMTlckltpYYPOcHgjrWbrUFusenXVtAtuL22MzQxsxRC JZI/l3EtgiMHknkntgAAy6Kt6XY/2lqMVsZPKjOXll27vLjUFnfHfaoY4HJxgc10Hh/SdM1L WrK5u0WCxv8AUWtreybe64BQsrSKwYELKoU4OWHzbRk0AcpRXQQ+GEfQF1GbUYIZZYXniheS JQyozLg5cPuJRgAqMCdvIydr7rw9p0FvdXCaldNBFaRXEMrWaqs7yHAjB8wjIOQcZ/1cvHyc gHOUVqG0tbbSLR7zcs19N5iug3NFbqWQkLkBizbuCQR5Xo+auXfh21t9fm0mHUmne1af7TKL faqrErMdmWyzbVbg7RuGAxHzUAc/RXQavpNvLcaFBoyLI9/bLtK7k82QzSRgkOx2sdqggHaD nBxzTJNO0uaW9ukuZYdLtJIrZZIIfNeZyrYk2Oy7Q3lOxGfl3AYPUAGFRXV6XpOmNNYW+xb+ LUtVksFum3xska+UFkjUMMMfNJw4YcLx1zFo2i2LWxkvpFknutOurmCFkcABFkCsHVh84eIn aw27c85wKAOZorXkt7M+H9KuHi8l3u54Z5ogXZ0UQsDtLYyPMYcbc8Z9am1zw9DpX20W9/8A azYXf2S4PkmMbjvK7ckk8RtuyBg9Cw5oAwqK1PEUFvb6qBawLbxSW1tN5SMxVS8KO2CxJxlj 1JqpZWMuoTGKF4FYLuzPcRwrj6uwGeenWgCtRXR22k2KaJf/ANqSRQTWl3Av2m1b7SzrJHId i7X8tuUU5yMYbknC1i6jZSaZqV1YzMrS2szwuUJKkqSDjPbigCtRW1ZJYnRZpLuxVECuq3Zk fzZJ8ZVI1yF2jKFsg4BPzAsgrUg8KSxeFb26uNKupLk2gvI7kRv5caF4toVh8rEo0rN97AC8 ghwADkaK6a9TS47LT7yzsbO6s4WtheeXJcJMZDHl43LHaAzLJgoDjaORxmWPTtO1VtHR7WDT DcQ3N3M9u8pQwRhsA7y5DZhlyQDgMpwx4oA5SiuoksbVJru9awsJLaCwFzbpbPP5FxmdYSzb 2EgwWcYyvKA8j72RrtrDaakEt08uOW3gnCZJCGSJJCozzgFiBkk4AySeaAM6iiigAooooAKK KKACiiigAooooAKKKKAPVPgt/wAxs/8AXDn/AL+f5/zkeqdPbH+f6e3Ttj5fK/gt/wAxs/8A XDn/AL+f5/zkeqdPbH+f6e3Ttj5UMjm/1bj/AGOn/Al/z/nAr+Df+RZtv+uk3/o16sTf6tx/ sdP+BL/n/OBX8G/8izbf9dJv/Rr0IDdooopiCiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigDyf4tf8ga3+q/yWvOL7xAH8TPrmlwNaXDzNcYnZ LgLIzEkrlAMDPGQSCM59PU/iLHbzRadFeQ3U8EkqI0doR5rZCgbMggnOOMc9OM5rz2DQtNtP FWhaVdBr5Z5kW5nt7geROHfavlMFyVHRjnJYMo24zSQGL/bt6Lz7SotUcx+UyJZwrE65zhow uxucHkHkA9hgj16/juJpvMikM+3ek0EckfyjC4RlKjaOFwBtBIGAcVpefpmvax51xby2VlDb /vNgjUA7sAs0MACjLAZ8tiTgcA5WWfStM026u7w/ajaW8lqsIJjkOZYjIJCGUCRBsJCFULBh u2EEUwMW21m+tZp5RKszXDb5RcxJOrtz8xEgILcn5uvzHnk1NJr09xaeVd28F1cBXRLucM8q KzMzD720ks7ncylgWyCMDHTXXhvTr3xZBbxW10EutavLKWK2dQERGQqyDYdoVZMkHPCdR2px eGNOu/D8F7A11FO1o0r75FdS4Fw3ACggYtWGMn/WA5+QhwDn4tZvobE2aSqItrIGMSGRFbO5 VkI3Kpy2VBAO5uPmObMnifU5bcwStayI0iSuXsoS0jqchnYplzyclic7mznJzf1TRdKjhu/s BvFlt7K3vj57oygSeUPL4UZI80Hfx0xt/irK1e0t7T7D9mt7+HzrSOWT7agXe5zlo8dYz2P1 oAfdeItRvL5L2V4BcqzsZI7WKMyFvvb9qjeDyCGyCCR3NTTeLNUntHtXNmIXhMBVLC3XEZbd tBCAgbvm4789eah8O2lnf6vHaXyTyCdWSFYJVjZpsfu1yVYYZsL2xuyTgGte30HR5DD9pknt Tb6ct5e+bPlSXdFRVKxMVBWRH+6/3gpwQTQBnDxZqgu2ugbPzmhEBY2Fv/qwpUKBswBtJXjq MA8AAQweItRtoXiheBFaZ51ItYt0UjYy0Z25jPyrjbjGBjGKvwaZobT6yftF1c2tlbx3EMtu wXdl41aM70BPMm3fgY27thztp/h/SdH1KYfbBeILi58m1iWXaz9PlV/KZXf5lBDeWBlTnDHa AczVm7vZLxbZHVVjtoRDEiA4AyWPXkkszMfduMDAF5YbSTwnPPHHKt1DdwxyOzIyuGWYjaNg ZcbBkbiD1I4GLkmj6dDbyq63Tz2dpb30ziZQsqSmLMarsJQgTD5iW+6fl54AKZ1i3is9Kgtr HP2G4a5kF1IJUndhGCCoVcJ+76ZPU81T1LU7jVbhZ7ptzrGqDknoOTyTyzbmY92Zj3rY8QaJ p1h/aY057o/2bfizdrgqfN3eYQQAPl2+UR1O7OcL92sWwaSO7WSG2W5eNWcRvGXUYUksV7hc bucjjkEZFABBf3FtaXVtCyrFdqqzZjUswVgwAYjIGQDwRnAz0q8vifU1vL66LWrzX+PtBkso WEmCD90pgZIBOByQCcmrOtWTahe6cdLtWuJL22MiiC2EbzFZJFJ8mPKoQExhSQQu48kgQ6XI LLQb/UIoYHuY7m3gVp4EmUI6zMw2uCuSY15xkY68nIBDB4i1G2heKF4EVpnnUi1i3RSNjLRn bmM/KuNuMYGMYosPEWo6bCsVu8BVVZFM1rFMyq2dygupIU7myo4+ZuOTTPENrDY+JNUtLZNk EF3LFGmSdqq5AGTyeBTItPtpLE3DatZxyhWP2Z0m8wkZwMiMrk44+bHPOKALNt4o1W1tzbxz xNC0YidJbaKQSKCCofcp37cALuztHAwOK0bbx5qZv7abUxFdwQ3CXDRRwQws7o5dTvEZI+dm Jx13N/eJrmoZWgmSVApZGDAOgZSR6gggj2PFeharpenXniD7FcC1lgl1oWUf9lwrbtaIS6lJ D5YBJJjKkhs+VIAw5JAOI1TVZdTm5Cx26MxihjjjjVAe5EaqpbAALbQTtHoAKNdRpegadc6Z YXF8l/B9qjviZUZSD5EayK6KVG4feUru5I+8OlEej6MbSa9lW/SA2C30UazIzLi58ho2OwA7 jyGAG3P3XxyAYum6xd6Utwtp5G24ULKJraOYMAcgfOp4yAfqB6Cqk0rTzPK4UM7FiEQKoJ9A AAB7Diujt9LsIdWu7VkncvpzXds5dCIgbVptrgod55C7htORuGDjBpOi6Vf2Ok+abxbzUb17 EFHTy1P7vEmNucDzACn8XXcvQgGFLeyS2NtZ7VWG3Z3AUHLO+NzEnvhUHGBhRxkkm2niLUUs ZLPfA0UsPkOz2sTSNGMYUyFS2Bhcc8bVxjAxpaXoulSQ2n283jS3FlcXw8h0VSI/NHl8qcE+ UTv5642/xVzNAF691i71GER3XkOQ24yi2jWVz6tIFDMTnJyTk8nmnrrt9/akGoyy+fdW+DE8 vOxhkhsDqQx3853Nktuyc6up6To9npqzwC8mlguY4bpWl2MmQ5KsrRDy3Ow4AMgGGBJ43ObS tMuPEr2s32qK0bTFuY2jMZeIi0E3ICqH6Efwls5JznIBztrdTWVwk9u+yRc4OAQQRggg8EEE gg8EEg8VeHiLURM0heBlZQvkvaxNCoGSNsRXYpBZjkAH5m/vHN/+x9O2f2htuvsP2D7b9m85 fN/4+Ps+3zNmOvz52dPlx/FViOxsLHX5bOzRp7eTR5JWe7RGZma0MwZRj92QduMEkYPzHNAE Vx4zuZtNCLCq6k1zJcy3vlw8s4UEovlgxt8iHcrA5yTyRjHi1i7isTZ/uJIdrKvnW0cjoDnI V2UsoySflIwST1JNauj6No82jre6xqP2Tz7h4Izl/k2KhL7Vjff/AKwfKSnTrz8uVFp9tJYm 4bVrOOUKx+zOk3mEjOBkRlcnHHzY55xQBRp8MrQTJKgUsjBgHQMpI9QQQR7HiuguoNOt9N0e Ww026bUZbQ3LOZlljJSWQMzRGM5G2MnGQAMZzglrHibTdKi1LVri1inWKy1X7PNECiK4cynE YAPlhfLKjO7OQcLjbQBkXPiLUbq7gupHgWaBditFaxR5XaF2sFUBl2jbtbIxkYwSKqXt/cah MJbllJVdqrHGsaIOuFVQFUZJPAHJJ6k1vz6FpB8XTaPby3UcFnJc+fcXDj51iVmwAqkrwhXd 82fvbR92mpo+hzarIYL5pdNhtvPmZXYCI7wgUyGIMRllOViPLBcYBcAGFBeyW1pdW8SqBdKq SOQS2wMG2jtgsqnpn5RyASDY0zXr/SNv2OSIbJBLH5sEcvlvx8yb1O08DJGM7R6CtefRtO0i 6u7qSeWe1gktfJMaq2PPiMqsQ6gSBQuNpCb887OlX77QdDGpatPqN6thE+q3VrAqBlWEIVOQ qxvvA8wfLlPu4zz8oBzJ129a3kgcWrxvuwHs4WMYYkkISuYxkkgLgAkkYJqu+oXUljHZPOxt o23LGegPP6DcxA6AuxGNxz0WiWNhb2y/aEaW5vtKvLhC6I8ahVmULgjKsDFvEgOf4dvJauUo At3OpTXWoressQdNgSPYGRVQBUXDZ3AKoHzZzjnPNWbrxFqN5fJeyvALlWdjJHaxRmQt97ft UbweQQ2QQSO5rLooA15fE1/PtMgtd0dvJbxGO1ji8pJM7wAgAOQzjkHG9iME5qnY6pc6d5gt zEySY3RzwpMhIzg7XBGRk4OMjJ9TVSigDRt9f1K280pc73kkMpklRZHSQ9XRmBKOcDLKQeBz wMPsPEWo6bCsVu8BVVZFM1rFMyq2dygupIU7myo4+ZuOTWXRQBqf29czWMOn3SQPYRsCY4ra GOTHy5Ik2FgxCqC3JOBnNWdd8UT6xqkt1FDFbQNcfaBb+VEQX65chFEmCWxvB4YjnJJwqKAL 2p6xd6u0bXnkFolCqYraOI4AAAOxRkAKAM9AOKo0UUAaNjrt7p1nJaW4tWgkkErJPZwzZYAg HLqTwCcemT6mqM00lxM800jSSyMWd3JLMTySSepplFAGpD4i1G3sVs43g8pIXgVmtYmkWN92 5RIV3AHe3Q/xGq1nqlzYW93BbmIR3kflTB4Ucsuc4BYErzg8Y5APUDFSigC9e6zfajCIrmVW XdvYrEiNK396QqAXbk/M2T8zc8nLBql4L2O8879/HGsQbaMFFQIFIxgjYNpBByM5zk1UooA0 f7ev/tn2nzIt3l+V5XkR+Tsznb5W3Zjd82Nv3vm681Uurqa9uHnuH3yNjJwAAAMAADgAAAAD gAADioaKACiiigAooooAKKKKACiiigAooooAKKKKAPVPgt/zGz/1w5/7+f5/zkeqdPbH+f6e 3Ttj5fK/gt/zGz/1w5/7+f5/zkeqdPbH+f6e3Ttj5UMjm/1bj/Y6f8CX/P8AnAr+Df8AkWbb /rpN/wCjXqxN/q3H+x0/4Ev+f84Ffwb/AMizbf8AXSb/ANGvQgN2iiimIKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAPLfihd3Fjp1pcWdxLb zoRtlicoy5VQcEcjgkV5HDq2o2/2byL+6i+y7vs+yZl8nd97Zg/LnvjrXq3xa/5A1v8AVf5L Xj1JAaP/AAkOs/bPtn9rX/2ry/K8/wC0vv2Zzt3ZzjPOKht9W1G0vJby2v7qG6mz5k8czK75 OTlgcnJ5qpRTAvf25qpmmmOp3nmzMjSv577pCnKFjnkrgYz0xxVn/hLPEP8A0HtU/wDAyT/G siigDX1rxJe62kEMp8i0gjRI7SKWQxLsXapCuzYO3jI/mSTnXF3cXflfabiWbyYxFH5jltiD ooz0A9KhooAKsxajeQXxvorueO8LMxuEkYSEnOTuznJyc/Wq1FAGjH4h1mG4muItWv0nn2+b Kty4aTaMLuOcnA4GaYuuaqkNxCmp3ixXTM06Cdwspbhiwz8xPfPWqNFAF6LXNVgsTYxaneR2 ZVlNuk7iMg5yNucYOTn60xdW1FLeC3S/ulgtpBLDEJmCxOCSGUZwDkk5HqaqUUAXp9c1W6hn huNTvJorhg0ySTuyyEYALAnkjavX0HpVSGaS3mSaGRo5Y2DI6EhlI5BBHQ0yigC3/a2o/wBo /wBofb7r7d/z8+c3m9Nv3s56cfSm2Wo3mmTGbT7ue1lZdpeCRkYjrjIPTgflVaigAooooAfD NJbzJNDI0csbBkdCQykcggjoamn1G8upp5ri7nmluFCzPJIzNIBggMSeQNq9fQelVqKANRPE +uxtI0etairStucrdSAucAZPPJwAPoBTP+Eh1n7H9j/ta/8Asvl+V5H2l9mzGNu3OMY4xWdR QBqDxPrqzNMNa1ESuoVnF1JuIGSATnoNx/M+tMXxDrK7NurX48uRpUxcv8rtncw54J3Nk99x 9azqKANq18Vajaabe2aSsxvWdppnmlLNvG18rv2MSM8spPOc5AIxaKKAL1zrmq3k0E11qd5P LbtuheWd2aI8HKkng8Dp6Cpj4n11plmOtaiZUUqrm6k3AHBIBz0O0fkPSsuigDUs/EWo2t3Z zvdT3AslKwRy3EoWMFduFKsrKMY+6R0A6cU+bxTrMmo3N7FqN1bTXO0SfZ53TcFG1QTnLYHG WJPckkk1kUUAXrbXNVs5p5rXU7yCW4bdM8U7q0p5OWIPJ5PX1NUaKKALdtq2o2dube1v7qCA yCUxRTMq7wQQ2AcZBVTn2HpUzeIdZbfu1a/PmSLK+bl/mdcbWPPJG1cHttHpWdRQBeudc1W8 mgmutTvJ5bdt0LyzuzRHg5Uk8HgdPQUPrmqyX0d9Jqd415Eu1Lhp3MiDngNnIHJ/M1RooA0f +Eh1n7Z9s/ta/wDtXl+V5/2l9+zOdu7OcZ5xRH4h1mG4muItWv0nn2+bKty4aTaMLuOcnA4G azqKAL1lrmq6ZCYdP1O8tYmbcUgndFJ6ZwD14H5VRoooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA9U+C3/MbP8A1w5/7+f5 /wA5HqnT2x/n+nt07Y+Xyv4Lf8xs/wDXDn/v5/n/ADkeqdPbH+f6e3Ttj5UMjm/1bj/Y6f8A Al/z/nAr+Df+RZtv+uk3/o16sTf6tx/sdP8AgS/5/wA4Ffwb/wAizbf9dJv/AEa9CA3aKKKY gooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA8n +LX/ACBrf6r/ACWvHq9h+LX/ACBrf6r/ACWvKdLks4tRifUY/MtRneuwvng44DoTzj+Ifj0K QFSiuj+2eHP7Y8z7H/oP2fbs+yyf6zd12/as9O+/H+z3ot7zw4uo3rz2e61fZ9nX7LIduB83 AugRz6s+f9npTA5yiuj0+88OR/avttnv3XDtD/osjbY+No4ukx34O4/7RqG2utCXQmiuLXdq PluBJ9nkPzHO07hcKPTny+PRu4BhUVu3N1oTaEsVva7dR8tAZPs8g+YY3Hcbhh68+Xz6L2m1 C88OSfZfsVns23CNN/osi7o+dw5unz24G0/7QoA5yiujuLzw42o2TwWe21Tf9oX7LIN2R8vB uiTz6MmP9rpR9s8Of2x5n2P/AEH7Pt2fZZP9Zu67ftWenffj/Z70Ac5RXR2954cXUb157Pda vs+zr9lkO3A+bgXQI59WfP8As9KNPvPDkf2r7bZ791w7Q/6LI22PjaOLpMd+DuP+0aAOcord trrQl0Jori13aj5bgSfZ5D8xztO4XCj058vj0buXN1oTaEsVva7dR8tAZPs8g+YY3Hcbhh68 +Xz6L2AMKiuj1C88OSfZfsVns23CNN/osi7o+dw5unz24G0/7QouLzw42o2TwWe21Tf9oX7L IN2R8vBuiTz6MmP9rpQBzlFdH9s8Of2x5n2P/Qfs+3Z9lk/1m7rt+1Z6d9+P9nvRb3nhxdRv Xns91q+z7Ov2WQ7cD5uBdAjn1Z8/7PSgDnKK6PT7zw5H9q+22e/dcO0P+iyNtj42ji6THfg7 j/tGoba60JdCaK4td2o+W4En2eQ/Mc7TuFwo9OfL49G7gGFRW7c3WhNoSxW9rt1Hy0Bk+zyD 5hjcdxuGHrz5fPovabULzw5J9l+xWezbcI03+iyLuj53Dm6fPbgbT/tCgDnKK6O4vPDjajZP BZ7bVN/2hfssg3ZHy8G6JPPoyY/2ulH2zw5/bHmfY/8AQfs+3Z9lk/1m7rt+1Z6d9+P9nvQB zlFdHb3nhxdRvXns91q+z7Ov2WQ7cD5uBdAjn1Z8/wCz0o0+88OR/avttnv3XDtD/osjbY+N o4ukx34O4/7RoA5yit22utCXQmiuLXdqPluBJ9nkPzHO07hcKPTny+PRu+FQBN9kuPsf2z7P L9l8zyvP2HZvxnbu6Zxzioa9FS50+13ysNG/spNXtpIlVoXeSyHmr88WSzFVkHLL5nzEknb8 tfSLKK10+0SSbw/JcwrfJKJZbRipaJWgBL8OfM5DAsACVJHKgA4KivSLrT7GC61IaVDolwn2 JniLzwOkbpeBI2LFsKfJZPvEBz94MdwriNe+z/2tJ9l8rb5cXmeTjZ5vlr5u3Hy48zfjb8v9 3jFAFSO0uJrea4it5Xgg2+bKqErHuOF3HoMngZqGug8P2T3Gla1iezjM9ssEaz3kUTM4mhcj DsDjapOenGM5rU0KDTbrw+baRLAvJbzl5Zbq3gaOcB/LB8weYeRHyjKnOCDh9wByN1aXFjcP b3lvLbzpjdFKhRlyMjIPI4INQ12niAQCwmW4OlsqWFpHbvbTxSytcqkKvuKMWACLKuOE+UHG 4glnihdPuYY4dKsrOOFrkJa3Av7bd5RyAGRVV1BG0lpiSuMEgk5AOUurS4sbh7e8t5bedMbo pUKMuRkZB5HBBqGt3xXbGK/t5BNayo1pbRZt7mObDRwRowOxjjDAjnrjjNQ+HvK8+7/49ftn 2f8A0T7Xs8rzN6Zz5nyf6vzMbuM4x82KAKM2nXlvdvaTWk8dzGpZ4XjYOoC7iSpGQNvP05qt XeyxLPr92u7RBaS6VGhDXVs6xyC0KIsbuxYESrjhs8KScEGq3hGDTUza6klhLuu/Ku2kureP y4vlG4PIG3g5f/UlWGMljlNoByP2S4+x/bPs8v2XzPK8/Ydm/Gdu7pnHOKhro4dNkj8J6lG1 xYCQ3cMoj+3QFmWNZ1cgb8nllxj72QRkVLefYv7Cl2/YPsv2SD7Js8v7R9q/d+bux+9x/r/v /J0x/BQBy9FdprqwJ4f1OW0t9LNq1/DFZzwCJpRbETMqtglkPyqSWAc8hicYHLaXJZxajE+o x+ZajO9dhfPBxwHQnnH8Q/HoQCpRXR/bPDn9seZ9j/0H7Pt2fZZP9Zu67ftWenffj/Z70W95 4cXUb157Pdavs+zr9lkO3A+bgXQI59WfP+z0oA5yiuj0+88OR/avttnv3XDtD/osjbY+No4u kx34O4/7RqG2utCXQmiuLXdqPluBJ9nkPzHO07hcKPTny+PRu4BhUVu3N1oTaEsVva7dR8tA ZPs8g+YY3Hcbhh68+Xz6L2m1C88OSfZfsVns23CNN/osi7o+dw5unz24G0/7QoA5yiujuLzw 42o2TwWe21Tf9oX7LIN2R8vBuiTz6MmP9rpR9s8Of2x5n2P/AEH7Pt2fZZP9Zu67ftWenffj /Z70Ac5RXR2954cXUb157Pdavs+zr9lkO3A+bgXQI59WfP8As9KNPvPDkf2r7bZ791w7Q/6L I22PjaOLpMd+DuP+0aAOcordtrrQl0Jori13aj5bgSfZ5D8xztO4XCj058vj0buXN1oTaEsV va7dR8tAZPs8g+YY3Hcbhh68+Xz6L2AMKiuj1C88OSfZfsVns23CNN/osi7o+dw5unz24G0/ 7QouLzw42o2TwWe21Tf9oX7LIN2R8vBuiTz6MmP9rpQBzlFdH9s8Of2x5n2P/Qfs+3Z9lk/1 m7rt+1Z6d9+P9nvRb3nhxdRvXns91q+z7Ov2WQ7cD5uBdAjn1Z8/7PSgDnKK6PT7zw5H9q+2 2e/dcO0P+iyNtj42ji6THfg7j/tGoba60JdCaK4td2o+W4En2eQ/Mc7TuFwo9OfL49G7gGFR W7c3WhNoSxW9rt1Hy0Bk+zyD5hjcdxuGHrz5fPovabULzw5J9l+xWezbcI03+iyLuj53Dm6f PbgbT/tCgDnKK6O4vPDjajZPBZ7bVN/2hfssg3ZHy8G6JPPoyY/2ulH2zw5/bHmfY/8AQfs+ 3Z9lk/1m7rt+1Z6d9+P9nvQBzlFdHb3nhxdRvXns91q+z7Ov2WQ7cD5uBdAjn1Z8/wCz0o0+ 88OR/avttnv3XDtD/osjbY+No4ukx34O4/7RoA5yit22utCXQmiuLXdqPluBJ9nkPzHO07hc KPTny+PRu5c3WhNoSxW9rt1Hy0Bk+zyD5hjcdxuGHrz5fPovYAwqKKKAPVPgt/zGz/1w5/7+ f5/zkeqdPbH+f6e3Ttj5fK/gt/zGz/1w5/7+f5/zkeqdPbH+f6e3Ttj5UMjm/wBW4/2On/Al /wA/5wK/g3/kWbb/AK6Tf+jXqxN/q3H+x0/4Ev8An/OBX8G/8izbf9dJv/Rr0IDdooopiCii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigDyf4tf 8ga3+q/yWvHq9h+LX/IGt/qv8lrx6kgCiiimAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAWbbUbyzhnhtbueCK4XbMkUjKso5GGAPI5PX1NV qKKACiiigAooooAKKKKACiiigAooooAs3Oo3l5DBDdXc88Vuu2FJZGZYhwMKCeBwOnoKrUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQB6p8Fv+Y2f+uHP/fz/P8AnI9U6e2P8/09unbHy+V/Bb/mNn/rhz/38/z/AJyPVOntj/P9 Pbp2x8qGRzf6tx/sdP8AgS/5/wA4Ffwb/wAizbf9dJv/AEa9WJv9W4/2On/Al/z/AJwK/g3/ AJFm2/66Tf8Ao16EBu0UUUxBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQB5b8ULS4vtOtLezt5bidyNsUSF2bCqTgDk8AmvIWsZ4JrdLxGtFu FWRJJ0YKY26PwCSvXkA9OM17f4vKrqegSSSxRRxXkErySyKiqqlGJJYgdAfr0HNeT6ndWEjQ 6dLe3k0UVzPPPetEjyPI4QEBRKVYZjB3b+dx9OUgM2bR7yPWrjSYoWuryCZ4SlurOXKEg7Rj JHBPTpTLfSdRu7yWztrC6muoc+ZBHCzOmDg5UDIweK6B/EOnR+JdXvbZ5zbaqr7mnsopGgLT CTHlM5WQfKBkkdc44GWReIbU3t8bi5ldJ/J2XDabA4AjQoF+zFvLHBADA5AXA++1MDCsdJ1H VPM/s6wurvy8b/s8LSbc5xnA4zg/lTU068ksZL6O0naziba9wsbGNDxwWxgHkfmK6s+JtJTV L2+jmv2E1/JeJbyWcRBDbWwrly0D53KZEycBDwVAqjb+IoV0CG085ra4t7aW2XZp8MxlDs5P 71iHjBEhUhc4Az3IoA5mrw0PVWa1VdMvC12pa3AgfMwAySnHzDBB47VRrt5PF9jca1a38s88 cP8AaKX89rDpkCEFSzAearhpCCxXLAZDFuvBAOWt9E1K6vrSyisZzc3ih4I2QqZFPRhn+Hgn d0wCc8UPoeqx30djJpl4t5Ku5LdoHEjjnkLjJHB/I1sR69Z2i6XPHNeXt5ZarJfP9ojVBMGM fV97HcfKBPB5c8nGWZpmp6To886Wsl1NHdW5ikuLizifZ86OMQMzK3+rxksPvZABX5gDHj0n UZnmSKwuneCRYpVWFiY3Ztqq3HBLcAHvxVeaGS3meGaNo5Y2KujghlI4IIPQ10sGuWTXmsyX Wo34+22kdpHNb2McZ2Ax5BjWQKo2x7MAnIPOOh5qYRrM4hdniDHYzqFYjsSATg+2T9aALC6e z6PLqKzRFIrhIHi+beCysyt0xg7GHXPHShdLu/s8F3NBLb2M8gjW8lifys5IPzAHOMHgZPB4 q/bXOlJ4ZurOW4vFvJ5o5wqWyGMGNZVC7vMBwfMGTt4x0NakPiDSZ9Gns7uW6hM9pFbERWEU rIUaM7vOLq7g+X9w4C7gBwooA5/VdHvNHuZIbuFlVZpIVmCt5cpjba2xiBkAimXGl3djeRW2 pQS6e8mDm6idNqk43EYyRwegPQ101/4ssxrUuo2jXl40+qw6iy3SLEYxEX2xghnyMPjPGAo4 OeM7VNSsdRazge/n+xxNIzeVpMFuYywXkJG4Dk7VByRgAdelAGRqNlJpmpXVjMytLazPC5Qk qSpIOM9uKt6H4ev/ABBNKllExjgUNLKI3dYweBkIrMST2AJ6noCQeI7uz1DXry+0952iu5nn IniWNkLMTt4ZsgZHPH0p+iXWnQWuqQ6jNdRfa7dYUNvAsuMSpIScuv8AzzA/4F7cgFZtGv8A zr5ILSe4WwZhcSRQvtjAzy2QCo+U/eAPBzjFMj0nUZbcXEdhdPA0byiVYWKlEOHbOMYUkAnt nmtjStY06w+x+Y1039l373ttthX/AEnPl4V/n/d/6ocjf948ccwi+06TwnDpsl5fxzx3E1yY kt1aJ3ZUVAT5gPAQ/NtON5wOOQDCrdTwdrK6jZ2d9Zy6f9skSKKe6icRb3GVUsFPJ6Y7HOcY OMKuosdY0ZdZ0zVrxr8T2v2YNDFChVfJVFBDFwW3CMcYXG/OTtwwBhLpOovcQW6WF009zGJY YhCxaVCCQyjGSMAnI9DQdLu21STTreCW5ukkaMRxROWYrnOFIDdicEAjuBWrcXulXmm21tcX +ovKt7cXE07WqMzCQKAeZeW/dqTk/wAZ5O35rE2saS/ifU9Riur+OC+8yQBrKKTDtKG2PEzl ZEA5ySPmCnHFAHO3VpcWNw9veW8tvOmN0UqFGXIyMg8jgg1b0XQ7vXLxILZdiNIkTXDo5ijZ zhA5VTt3NwPc0zWb2PUNTkuIVYRlUQbwATtQLnaOEBxkIOFB2jgCtjw1r1npjaa13NeQNp16 10ptY1czBxGGQ5ddoxHjPzZDnjjkAxP7J1H/AJ8Lr/j3+1f6lv8AU/8APTp9z/a6U+fQ9Vtp khuNMvIpXZFVJIHVmLZCgAjqdrY9dp9K2rHWNGi+zi5a/P2a0ubCNo4U5STziJSC/X97jy89 s7z906V3r+iX+jyaZbTX/ny2628bTW8UabgtqoLMZcKCbXk9t/8As8gHHXWnXliqNd2k9urs 6qZY2UMVOGAyOSDwfQ1DDDJcTJDDG0ksjBURASzE8AADqa6vxrqVo2o6xb215LfPe363LTMU KIqCQIqMrtvG2XH8O3aBjsOf0a5gtNTjmuZZ4YlVwXgRXbJQgAqxCspJAZTwVJHegAfQ9Vjv o7GTTLxbyVdyW7QOJHHPIXGSOD+RplvpOo3d5LZ21hdTXUOfMgjhZnTBwcqBkYPFdAnie0j1 CTaGMEll9kM7WUJAPmiXcLYnywOAu0EDOX+8SKZFrtm17fTXOoXTeb5KxMdKtnjZUQr80DNs UqNoUqeBu/vUAYttoeq3k08Nrpl5PLbttmSKB2aI8jDADg8Hr6GmNpd2mlrqMkEqWryCOORo nCyH5s7WxtONpBGc+gODjoLDxJYQTT3crXiyPeyXS2rRJcKVO0gLO5EkTnBBkXLcKeq1nW1z pSeGbqzluLxbyeaOcKlshjBjWVQu7zAcHzBk7eMdDQBQXSdRe3guEsLpoLmQRQyiFisrkkBV OME5BGB6Gm3WnXliqNd2k9urs6qZY2UMVOGAyOSDwfQ1tSaxp01vKztdJPeWlvYzIIVKxJEY syK28FyRCPlIX7x+bjmXXdd07VU12RLi/knv7+O6hE0K4VFVwEZvMJGBIQMA8IOmflAOXrUT w5qU+pyadaWzXV3FD50kcALGMbAzKw7MudpHXd8vJxWXXR3up28PjK/1Dd5lrfee+YiGaNLi Nu2cF0EnK5+8pGe9AGamgam0t3HJY3URs4zJcb7eT9yNpYb8KSuQOCcDuSBk1Cuk6i1ml4th dG1k3bJxC2xtoJbDYwcBWJ9Np9K1dLudCsNQlkNxqPlfZpYFcW0ZaQyRuhYr5g2Bd44y2cE5 XOBr+HPEmhaLZwwyy6jI0Vy0wKWkeGHnW7j/AJa8HFsM+hfvt5AORTTrySxkvo7SdrOJtr3C xsY0PHBbGAeR+Ypy6TqL28FwlhdNBcyCKGUQsVlckgKpxgnIIwPQ1ur4htY9GWyguZYXtrea 2ib+zYJGmR2kOTIzb4siQqVXdjkgnOKr3OtWctjcvGJ/tl3ZQWTxMiiOMReV84fdlifJHy7R jeeTt5AMr+ydR/58Lr/j4+y/6lv9d/zz6ff/ANnrT9U0TUtEm8rU7Ge1YsyqZUIVyvXaejDk cjI5FbGra1pV/Y6t5QvFvNRvUviHRPLU/vMx53ZwPMJD/wAXTavU0NevNO1G8ub+2N0bq9uG nkjkRVSHcSSgIJL8n73y/d6Hd8oBT0zS7vV7xbaygllc4LGOJ5PLXIBYhATgZHQGi10nUb5E ezsLq4R5DErRQs4Zwu4qMDk7QTj05qz4cu7PT9es77UHnWK0mScCCJZGcqwO3llwDg88/Srk N7pVtouoadFf6iFu7m3csLVFDRoGyGHm9cuSByMovIz8oBz9aNto7Xdm00V3a+f5byrabmMr IgJZuBtXAVjhmBIHAOVyeILy31HxBqF7ZmUwXVw8y+agVhuO4ggEjgkjrzjPHSrOm6lZ2Gm3 KmW8Ms8LxS2eFMExIYJIxyMFNwYAq3zJkMM/KAQzaDPDYtcG4gaWOFLiW2Ut5kUT7djkldpB 3pwGJ+cZAwcGpaDPpsMjvcQTNbzC3uY4i263lO7CNlQCfkflSw+U88jNy51qzlsbl4xP9su7 KCyeJkURxiLyvnD7ssT5I+XaMbzydvJretWd9DqBtROZdTvVvZllRVWAjzPkUhjvH70/MQv3 RxzwAYUMMlxMkMMbSSyMFREBLMTwAAOpq2+h6rHfR2MmmXi3kq7kt2gcSOOeQuMkcH8jRo1z BaanHNcyzwxKrgvAiu2ShABViFZSSAyngqSO9bqeJ7SPUJNoYwSWX2QztZQkA+aJdwtifLA4 C7QQM5f7xIoA5+30nUbu8ls7awuprqHPmQRwszpg4OVAyMHij+zLgW95K67Hs5FSaBgRImSQ SVxwAwCknoWUd62J9Ysr839tfXV0YLiS3kS5iso1YeVG0YTyVcKow/UN/AOOeK0F5GbPX7mS Vi14qwoksoeZi0yy7mOBuAERDNj7zLxzwAYtFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAeqfBb/mNn/rhz/wB/P8/5yPVOntj/AD/T26dsfL5X8Fv+Y2f+uHP/AH8/z/nI 9U6e2P8AP9Pbp2x8qGRzf6tx/sdP+BL/AJ/zgV/Bv/Is23/XSb/0a9WJv9W4/wBjp/wJf8/5 wK/g3/kWbb/rpN/6NehAbtFFFMQUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAeT/Fr/kDW/1X+S149XsPxa/5A1v9V/kteSWt3cWNwlxZ3Etv OmdssTlGXIwcEcjgkUkBLY6e2o+YkE0X2kY8q3bdvnPPCcYJ46EgnIC5JxVeaGS3meGaNo5Y 2KujghlI4IIPQ1ojW5J5mutUM+pXqKFt5LqcyJHjP3lYHeOcgZAz1DAkVRurqa9uHnuH3yNj JwAAAMAADgAAAADgAADimBe0/wAP3epabNfQS2aRQzLCwnu44WywYj77Dj5T9e2cNiGLRr6a xN4kSmLazhTKgkdVzuZYydzKMNlgCBtbn5Th+najbwWdxZX1tLPazyRykQTCJw6BwvzFWGMS NkY9ORjnSHitm0Y6eRf28axyRRRWV+0UG12ZsPGysX5cj7wyoA6jJAM1tBv10575o4hDHGsr qZ4/NVGICsY928AllwcchgehzT9X8P3eihDdS2bh1jYCC7jkb50Dj5VbdjB64x6Eggmzc+II ZNCXTbe3ukTy0UpPeGWGNhgtJFGVGx2YHnccB3GOeK19qlrfWys9k328QxQGYz/uwsaqqlUA BDbUUElmHLcDI2gGXRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAeqfBb/mNn/rhz/wB/P8/5yPVOntj/ AD/T26dsfL5X8Fv+Y2f+uHP/AH8/z/nI9U6e2P8AP9Pbp2x8qGRzf6tx/sdP+BL/AJ/zgV/B v/Is23/XSb/0a9WJv9W4/wBjp/wJf8/5wK/g3/kWbb/rpN/6NehAbtFFFMQUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAeVfFWJp9MtIkKhnd FBdwqgkL1JIAHueK8+uPBWoQajZWKyxS3N3vIjEUyOioNxYo8auRjONoOdrAZIxXonxPuPsl lYXHlRTeTLG/lTLuR8bThh3B6EV5efEMqS2/2Wztba3h83/Ro95R/MUJJksxb5kAXhhjGRg8 0kBZfwbqMetR6ZIVWSWHz0Zo5QXTJGRHs80nIIxszgFsbfmog8IXdzq91p0NzBJJaqpdo0mk 5IBxsVDICM4bKgKRg4JANNNXto7mSVdE04xSQ+UYGMxQHcG3gmTcG4A4YDGRjk08a+JJbh7v S7C7EvlBFlEg8lY1KIqMrq2NuAck52gnJGaYANFQWuryfbbWeTT8jZDI3zASonmKdhVkO/AG 5TznoMFkOgzzWK3AuIFlkhe4itmLeZLEm7e4IXaANj8FgfkOAcjM1t4keM6g91p9nfTaizG4 ln81WcF1cjCOoA3KDwM9unFQw69PDYrbi3gaWOF7eK5YN5kUT7t6ABtpB3vyVJ+c4IwMAE2o eGZ9PhlkF7Z3PlQx3DJA7FvJfbtk5UYGXUbThuc7dvNYtbtx4nM/2z/iVWCfa7SOzbaZvkSP btK5kPI2R9c/cHHLZxYXWOZHeNZVVgTG5O1x6HBBwfYg0Aa97osb+IYNP00siXMMEsYuHDMv mQpIQSqjcRuIAVcngAEkA3v+EPa1bUbbUX8ieK0S8guHZootnnLGxdHQP3bAwCSvAbcuaNz4 kefUILyPT7O3kih+zssXmlZYvLEWxtzk42DblcHknOcEWf8AhLV+y/Zv7B0vyfs/2bbuuP8A V+b5u3Pm/wB/nPXt04oAZY+DdRv7u5hhKlLdY2MyRyyqwkXdGQsaM+GXnlRjocHAqtDpKxw6 7DfRyx32mxhgFkXarCZI3Vhg5+/wQR075oHiGV5bj7VZ2tzbzeV/o0m8InlqUjwVYN8qEryx znJyeaLHXY7GK9jGj2EqXmVcSNP8qblcIMSDgMinJyfUmgDIroJPBuow6RFqc5WG2dY5HZ45 dsUbkBXLbNrD5l4Qs3PTg45+tSTWkuIYlutMs7ieNY0+0OZQ7ImAqkK4XG1QvABxznPNAE2p eGZ9LmkjnvbNvIuRa3LxOzrbsd20theQQjH5dxGCGAbiprvwo6eIzo2n38F/cCaWNhFHKGjE edxYFeTgE4TeeCBnjMOoeJH1GHUkk0+zjbUblbqSSPzdyyDP3cuRj5n4IP3z6Lgk8TTyXf2o WVmtxIztdSBGLXRdWV9xLHaGDvkR7B83suACaTwdfw6v/Zs0sEMzWz3UTT74VlVQxI+dQUPy P98KPlznBBLNM8K3WsXF0mn3EVxBbbA9zFDO6ksCQAqxl+zclQPl68jMNtrsdnqLXdvo9gga 3eAwbpymHBVm5k3ZKsV6456Z5pkWtJE1yn9mWbWdwyObNjL5augIVgQ+/OGfqxHzHjgYANLQ /CbXOtQWmrutujXrWTRCcJI8ikBwjbWXKblODjdnC5J4xP7P/wCJP/aH2u1/4+PI+zeZ+++7 u37f7nbPrV/TfEj6bNG6afZzLb3JuraOXzdtvIduduHBI+ROGLfdHqc05tTWTTXsksLOJWuT cCVIz5qDGPLDkk7B1wcnPOaAKNbWpQaDuMel3E4LXrxrLcOSi24ChZGAjBJYljxyAuMEnNYt FAHQXfhR08RnRtPv4L+4E0sbCKOUNGI87iwK8nAJwm88EDPGR/Buox61HpkhVZJYfPRmjlBd MkZEezzScgjGzOAWxt+aoZPE08l39qFlZrcSM7XUgRi10XVlfcSx2hg75EewfN7LiFNXto7m SVdE04xSQ+UYGMxQHcG3gmTcG4A4YDGRjk0AXE8LoLnVbe51ezgbToUlZykrK25kUg4TcpUu AQRkNxjqRDZwaCkSi/uJ5ZVmn3tbuURo1jzFt3Rk5eTjJ6AcqM5EK69P9unuJbeCWK4hW3kt nDCMxLt2JkMGwvlpg7snbyTk5o3Vx9quHl8qKEHAEcS7VUAYAHc8DqSSepJJJoAhooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAPVPgt/zGz/ANcOf+/n+f8AOR6p09sf 5/p7dO2Pl8r+C3/MbP8A1w5/7+f5/wA5HqnT2x/n+nt07Y+VDI5v9W4/2On/AAJf8/5wK/g3 /kWbb/rpN/6NerE3+rcf7HT/AIEv+f8AOBX8G/8AIs23/XSb/wBGvQgN2iiimIKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAPJ/i1/wAga3+q /wAlrx6vYfi1/wAga3+q/wAlrx6kgCiiimAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA eqfBb/mNn/rhz/38/wA/5yPVOntj/P8AT26dsfL5X8Fv+Y2f+uHP/fz/AD/nI9U6e2P8/wBP bp2x8qGRzf6tx/sdP+BL/n/OBX8G/wDIs23/AF0m/wDRr1Ym/wBW4/2On/Al/wA/5wK/g3/k Wbb/AK6Tf+jXoQG7RRRTEFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFAHk/wAWv+QNb/Vf5LXklrClxcJFLcxWyNnMsoYqvHfarH24HevW/i1/ yBrf6r/Ja8epIDR/sy1+2eR/bdh5fl7/ALRsn2Zzjbjy92e/THvniiPTLV7iaJtbsI0j27ZW SfbLkc7cRk8dDkD2zWdRTA0bfTLWbzfM1uwg2SFF8xJz5gH8Q2xng++D6gUyLT7aSxNw2rWc coVj9mdJvMJGcDIjK5OOPmxzziqNFAF6XT7aOxFwurWckpVT9mRJvMBOMjJjC5Gefmxxxmn3 GmWsPleXrdhPvkCN5aTjywf4jujHA9sn0BrOooA0ZNMtUuIYl1uwkSTdulVJ9sWBxuzGDz0G AffFH9mWv2zyP7bsPL8vf9o2T7M5xtx5e7Pfpj3zxWdRQBox6ZavcTRNrdhGke3bKyT7Zcjn biMnjocge2aLfTLWbzfM1uwg2SFF8xJz5gH8Q2xng++D6gVnUUAXotPtpLE3DatZxyhWP2Z0 m8wkZwMiMrk44+bHPOKJdPto7EXC6tZySlVP2ZEm8wE4yMmMLkZ5+bHHGao0UAaNxplrD5Xl 63YT75AjeWk48sH+I7oxwPbJ9AaJNMtUuIYl1uwkSTdulVJ9sWBxuzGDz0GAffFZ1FAGj/Zl r9s8j+27Dy/L3/aNk+zOcbceXuz36Y988UR6ZavcTRNrdhGke3bKyT7ZcjnbiMnjocge2azq KANG30y1m83zNbsINkhRfMSc+YB/ENsZ4Pvg+oFMi0+2ksTcNq1nHKFY/ZnSbzCRnAyIyuTj j5sc84qjRQBel0+2jsRcLq1nJKVU/ZkSbzATjIyYwuRnn5sccZp9xplrD5Xl63YT75AjeWk4 8sH+I7oxwPbJ9AazqKANGTTLVLiGJdbsJEk3bpVSfbFgcbsxg89BgH3xR/Zlr9s8j+27Dy/L 3/aNk+zOcbceXuz36Y988VnUUAaMemWr3E0Ta3YRpHt2ysk+2XI524jJ46HIHtmi30y1m83z NbsINkhRfMSc+YB/ENsZ4Pvg+oFZ1FAF6LT7aSxNw2rWccoVj9mdJvMJGcDIjK5OOPmxzzii XT7aOxFwurWckpVT9mRJvMBOMjJjC5GefmxxxmqNFAGjcaZaw+V5et2E++QI3lpOPLB/iO6M cD2yfQGiTTLVLiGJdbsJEk3bpVSfbFgcbsxg89BgH3xWdRQBZvbaK1mCQ3sF4pXPmQLIFB9P nVTn8Mc1qaBpWm3dneXurXXkwW8kUKrvaPczhzncsch4EZ42856jGDhVZstRvNMmM2n3c9rK y7S8EjIxHXGQenA/KgDorTQdEuVsIo7i8mlvtRl0+KdCqxsAY9k20ruAxIMx9T/eXGCaJY2F vbL9oRpbm+0q8uELojxqFWZQuCMqwMW8SA5/h28lqxV8Q6yuzbq1+PLkaVMXL/K7Z3MOeCdz ZPfcfWi38Q6zaeb9m1a/h86QyyeXcuu9z1Y4PJPrQBnV12p2Wmado+o2awyyvp2rxW8zsIw8 gCzBikm3Khtg+Qhgu0HLZOORrRHiHWRbx241a/EEW3y4vtL7U2kFcDOBggEemBQBpXOlWk/i iG1TzY7NrSG4blNyJ9mWVslVA4GcsFJ6na7cG3a6ZY2PjPw6LJ4ryx1CSJtkq+cu1pWiZTvR d33SclBjPHQMefudc1W8mgmutTvJ5bdt0LyzuzRHg5Uk8HgdPQVMfE+utMsx1rUTKilVc3Um 4A4JAOeh2j8h6UAGm2ln/Zt3qGoJPNFBNFAIYJViYlxI27cVbgeWRjHO7qMYO1a+FtOi1iLT 9RnupPP1eTTUlt9q7fLaMFipznd5gHUbcZ+fpXPprmqx30l9Hqd4t5Ku17hZ3EjjjgtnJHA/ IVZ0LxJe+HfPawO2SbaQ/myLsK5wdqsFbr0cMPbBOQDLmMbTOYUZIix2K7BmA7AkAZPvgfSr cun20diLhdWs5JSqn7MiTeYCcZGTGFyM8/NjjjNUaKANG40y1h8ry9bsJ98gRvLSceWD/Ed0 Y4Htk+gNEmmWqXEMS63YSJJu3Sqk+2LA43ZjB56DAPvis6igDR/sy1+2eR/bdh5fl7/tGyfZ nONuPL3Z79Me+eKI9MtXuJom1uwjSPbtlZJ9suRztxGTx0OQPbNZ1FAGjb6Zazeb5mt2EGyQ ovmJOfMA/iG2M8H3wfUCmRafbSWJuG1azjlCsfszpN5hIzgZEZXJxx82OecVRooAvS6fbR2I uF1azklKqfsyJN5gJxkZMYXIzz82OOM0+40y1h8ry9bsJ98gRvLSceWD/Ed0Y4Htk+gNZ1FA GjJplqlxDEut2EiSbt0qpPtiwON2YweegwD74o/sy1+2eR/bdh5fl7/tGyfZnONuPL3Z79Me +eKzqKANGPTLV7iaJtbsI0j27ZWSfbLkc7cRk8dDkD2zRb6Zazeb5mt2EGyQovmJOfMA/iG2 M8H3wfUCs6igC9Fp9tJYm4bVrOOUKx+zOk3mEjOBkRlcnHHzY55xRLp9tHYi4XVrOSUqp+zI k3mAnGRkxhcjPPzY44zVGigDRuNMtYfK8vW7CffIEby0nHlg/wAR3Rjge2T6A0SaZapcQxLr dhIkm7dKqT7YsDjdmMHnoMA++KzqKANH+zLX7Z5H9t2Hl+Xv+0bJ9mc4248vdnv0x754oj0y 1e4mibW7CNI9u2Vkn2y5HO3EZPHQ5A9s1nUUAaNvplrN5vma3YQbJCi+Yk58wD+IbYzwffB9 QKZFp9tJYm4bVrOOUKx+zOk3mEjOBkRlcnHHzY55xVGigC9Lp9tHYi4XVrOSUqp+zIk3mAnG RkxhcjPPzY44zT7jTLWHyvL1uwn3yBG8tJx5YP8AEd0Y4Htk+gNZ1FAGjJplqlxDEut2EiSb t0qpPtiwON2YweegwD74o/sy1+2eR/bdh5fl7/tGyfZnONuPL3Z79Me+eKzqKANGPTLV7iaJ tbsI0j27ZWSfbLkc7cRk8dDkD2zRb6Zazeb5mt2EGyQovmJOfMA/iG2M8H3wfUCs6igC9Fp9 tJYm4bVrOOUKx+zOk3mEjOBkRlcnHHzY55xRLp9tHYi4XVrOSUqp+zIk3mAnGRkxhcjPPzY4 4zVGigAooooA9U+C3/MbP/XDn/v5/n/OR6p09sf5/p7dO2Pl8r+C3/MbP/XDn/v5/n/OR6p0 9sf5/p7dO2PlQyOb/VuP9jp/wJf8/wCcCv4N/wCRZtv+uk3/AKNerE3+rcf7HT/gS/5/zgV/ Bv8AyLNt/wBdJv8A0a9CA3aKKKYgooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooA8n+LX/IGt/qv8lrx6vYfi1/yBrf6r/Ja8epIAoqze6deaZM IdQtJ7WVl3BJ42RiOmcEdOD+VQwwyXEyQwxtJLIwVEQEsxPAAA6mmAyinzQyW8zwzRtHLGxV 0cEMpHBBB6GmUAFFFFABRT4YZLiZIYY2klkYKiICWYngAAdTRNDJbzPDNG0csbFXRwQykcEE HoaAGUUUUAFFTfZLj7H9s+zy/ZfM8rz9h2b8Z27umcc4qGgAoqzc6deWcME11aTwRXC7oXlj ZVlHBypI5HI6eoqtQAUVNcWlxaeV9pt5YfOjEsfmIV3oejDPUH1qGgAooooAKKKsvp15HYx3 0lpOtnK21Lho2EbnngNjBPB/I0AVqKKKACiiigAoop5hkWFZjGwidiquQdpIwSAfUbh+Y9aA GUUUUAFFPeGSNY2kjZVlXchYEBxkjI9RkEfUGn/ZLj7H9s+zy/ZfM8rz9h2b8Z27umcc4oAh ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKAPVPgt/zGz/ANcOf+/n+f8AOR6p09sf5/p7dO2P l8r+C3/MbP8A1w5/7+f5/wA5HqnT2x/n+nt07Y+VDI5v9W4/2On/AAJf8/5wK/g3/kWbb/rp N/6NerE3+rcf7HT/AIEv+f8AOBX8G/8AIs23/XSb/wBGvQgN2iiimIKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAPOfHe/wAzS/K+wbvNXP8A aO37Pjaud+7jGM+/pziuDsprG38VeGZtKks49KjmDI92YBOoD5kNwezddmf4dm35s11Xxa/5 A1v9V/kteQwwyXEyQwxtJLIwVEQEsxPAAA6mkgOoslnOvGTUI9ElkittypHPZxIw3Y+UgGEv yThwTtBxyFImke0uNQ1M2UekvdFrdVimMMUPlCMiZQxKpu37AXjKk/MybQTjl72xl0+YRTPA zFd2YLiOZcfVGIzx061DDE08yRIVDOwUF3CqCfUkgAe54pgehStp914sikluNG8mDWriS4ll MLLJbSshTJwfMzmQZ5KZ+YoBkEWmWE/h+CC8k0IXaWjRkpdWqNvxcFcsrDJ3LafNn15w0meA u7WaxvJ7S5TZPBI0UiZB2spwRkcHkVDQB2niBYBYTPcW+lwLNYWktuLYRLK1yyQl2ZEO5AUM vGFTocbiCcLX/wDmGf8AIL/48Iv+Qd+P+t/6a/3vwqje6jeanMJtQu57qVV2h55GdgOuMk9O T+dVqAJrW2e8uEgiaJXfODLKsS8DPLMQB+JrsXWxj8c63PdGzu/tDTT2O27gMblphgl3Dxqf L3nDj04DFTXEVZu7C4sVtmnVQt1CJ4ikiuGQkjPyk4OVIIPII5FAHULdWMl9f2Dx6dpitNBc pOyQXgTbt81Q6rtIYZk2rgZQxhfnxVnTdQ0rUEu7r+ybBpri7kMlq1za2qx2+1fLRTIn/XQF o9rcZJyVI4WigDoLSyd/Bt8fPs1aS5hnWN7yJZCkaThjsLbs5ZcDGTngGufoqzBYXFzaXVzC qtFaKrTZkUMoZgoIUnJGSBwDjIz1oA6LxHNAYdblS4gkXU9VS7thFMrs0Q8/JYAkof3icNg8 njg4xdB+z/2tH9q8rb5cvl+djZ5vlt5W7Py48zZnd8v97jNZ1Pmhkt5nhmjaOWNiro4IZSOC CD0NAHb6gI7jT4rOY6Mt1PpnloIp7crHcLdmQ4cMRFmN2OMqpztA4CjRS3sJI7xhL4dkWSOC WBw1rHukFo+7CttZQZ1iypAHJyMFq80ooA9Fez0+22KsOjHSotXuYpbhpIWc2X7p9qNu3SHa 55XdIvABXOD51XQQaRr+oaHAouVOmKpnjhn1GKNEG8oX2O42jeSM4HJ96zdW0a+0O5W31CJY 5WUsAkqSDAZlPKkjIZWBHUEUAbV59i/sKXb9g+y/ZIPsmzy/tH2r935u7H73H+v+/wDJ0x/B T/GU11P5DPJpMluIbZc2ZtTIJBAoYHy/n2hgw/u8DH8NcpT4YZLiZIYY2klkYKiICWYngAAd TQBo+Gb+PS/E2l3s7KsMFzG0jPGHCpuG44weQM4wMg8jnFbVmuzWBLqraNLc/Z2ENvbtaohI ZeS4UwKcFzlwx+XGASjVzl9pdzp3lm4ETJJnbJBMkyEjGRuQkZGRkZyMj1FV4oZJ2KxRtIwV mIQEkAAkn6AAk+woA7prW1h1LWvsceiMktlby26XF3auqXBMZba2QuQRMSowhwAV2lQYfC66 fJNJFqkenSNNelLwme2hWKLj5lLghl5fAg2EY6nKbeIooA7r7JDJb6fYTroQLaZOLiZLi2DG ZDJ5ILhsA5MPIwWydxYKcZGpWzS+E9OndtLE8Mkm8QS26ymIrEI9yodzHO/OQWHOcVj2Ol3m opcPaw70t42kkYsFAAUsepGTtVjtHJCsQODVSgDrvE7WsWjrapFpccyXChGs5IJ/MVVcEq8a h1TJXiUszZU5yrZo6zZSaj4wktIm0lWlZAX00kWcY2AlweyqMlj2wxrIu7C4sVtmnVQt1CJ4 ikiuGQkjPyk4OVIIPII5FF/YXGmXbW10qrKqq3ySK6kMoZSGUkEEEHg96AN22vba+1W8NssC eTbCHSkvRGEXa6D5w/7sMY/NY54LsSPmIq8lzIumapIg0JruS7s0VFaARBljdHdY2IQ8uAW2 lMszLwNw5SysLjUJjFbKpKruZpJFjRB0yzMQqjJA5I5IHUirEeg38lxND5cUZg273mnjjj+Y ZXDswU7hyuCdwBIyBmgDqTaQ2ia5Dpi6FIY9TU2DXNxbOVhKyZKmRvnG0xDDbgCTgbgSM2z+ xf2FFu+wfZfsk/2vf5f2j7V+88rbn97j/Ufc+Trn+Ouamhkt5nhmjaOWNiro4IZSOCCD0NW4 tGvprE3iRKYtrOFMqCR1XO5ljJ3Mow2WAIG1uflOADavPsX9hS7fsH2X7JB9k2eX9o+1fu/N 3Y/e4/1/3/k6Y/go8S3kmq2sV2JtLFqLe3CiKOBJ2lWJUddqL5gAIf72Ewox/ADhf2XcjTvt zCJID90PMiu4ztyqE7mGcjIBHB9DivDDJcTJDDG0ksjBURASzE8AADqaAGUVoyaDfx3EMPlx SGfdseGeOSP5RlsurFRtHLZI2ggnAOaP7Bv/ALZ9m8uLd5fm+b58fk7M43ebu2Y3fLnd975e vFAGdRV5dGvnu7i1ES+dbwtO6mVBmNV3FlJOHG35htzkcjI5qjQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAeqfBb/m Nn/rhz/38/z/AJyPVOntj/P9Pbp2x8vlfwW/5jZ/64c/9/P8/wCcj1Tp7Y/z/T26dsfKhkc3 +rcf7HT/AIEv+f8AOBX8G/8AIs23/XSb/wBGvVib/VuP9jp/wJf8/wCcCv4N/wCRZtv+uk3/ AKNehAbtFFFMQUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAec+O7hrSTS501L+zDHKrfa9jP5Q2rn5VBLZHGOhzg8ZrgINdsh4k8O3trf/wBm 6ZaSbvsO6Z/sKhyZF3Bcv5gycjP3tpwFBrs/ihaXF9p1pb2dvLcTuRtiiQuzYVScAcngE15N Z6JqV/NZxWtjPI18xW2OwhZSPvbSeCB3PQd8UkBu2Wpywa8bq78TQXcyW2I7qf7Wyk7v9XvC rKhwWbK8fwk4ZhU0mvRXeoanJFqq211O1vi8uEkdJI0jKSRHCs7IzFCA4O5UG/5uuLqHhrUL DVItOSKW6upo/MSOK2mVmHPRXRWP3ScgY9+DismjX5vpLSW0nglhXzJxJC+YI+Mu4ALBQCCT joaYHa/8JFpzeJre6bW2jtrHWJ7xHSOUl4JmjOxBgYAw+8HHDHbvzgui1XSX8Pwafe+IrWd4 rRrcb47llGRcYAzF0DPbH/tiP7i1x134c1W11I2Isp5pTNLDEYYnZZzGSH2cfMBg5x071Wm0 nUbe3S4nsLqKCSPzUleFgrJlRuBIwRllGf8AaHqKAOy8W3NzbW0kGsXbPNdadaeXZyRSCSOY LFumfcoUthJELhmbnb0BA5nX7z7Z/Zn/ABNP7Q8mwii/49/K+z4z+6/2tv8Ae75qndaTqNij veWF1bokgiZpYWQK5XcFORwdpBx6c1FcWlxaeV9pt5YfOjEsfmIV3oejDPUH1oAt6DdQ2WrR zTv5Y8uVUlwT5MjRsqSccja5VsjJGMgEgV017rFtcWIsZdegna6077NPMscwjEqXXnK8g8sF iVLDcFZixbPUseLhhkuJkhhjaSWRgqIgJZieAAB1NW30PVY76Oxk0y8W8lXclu0DiRxzyFxk jg/kaAO9TxFp7x3hPiji5jgZBOlwHEqWjx73ARgH83ynyGb/AFYOcqKfNdJZ2MGoR3yx+Hxr Fy6Rrbyhbm2by2+zx/u8BTiRSjFUZgeu3I88t9J1G7vJbO2sLqa6hz5kEcLM6YODlQMjB4p9 toeq3k08Nrpl5PLbttmSKB2aI8jDADg8Hr6GgCjXYtqtpPoF9bjVoIoZNOhhgsJIpC8cyNE0 m0hCqh2jduG+Yspbkccy2l3aaWuoyQSpavII45GicLIfmztbG042kEZz6A4OBdJ1F7eC4Swu mguZBFDKIWKyuSQFU4wTkEYHoaAOs13XLO80Um11KAXNtcxTWCp9pE8UYDAryPLjYZjJEW1P k46KKLnxDbT+KF1a71hr6F5p3tbaUTMtkJFbYXPBQqxj/wBVuPykg5Vc8jdadeWKo13aT26u zqpljZQxU4YDI5IPB9DTLW0uL64S3s7eW4nfO2KJC7NgZOAOTwCaAOrGub/GlhfnWrOyaOFl bUbWCe42nDj5xMN7sQQuTkAbcfd446rZ0u7bVJNOt4Jbm6SRoxHFE5Ziuc4UgN2JwQCO4FTX mh3dtezW0K/bfJt0uWktUdlETIrhzlQQMMMkgYoAm0aS2TTdbS4vIoJJ7RYoUdXJkYSxyYG1 SBxGRyRyR2yRu2mpWX9naZYS61apaDTLiK5iMU2POYytGHxH821pEI6hSjkckbuLqymnXklj JfR2k7WcTbXuFjYxoeOC2MA8j8xQB1FxrFpfWOrzTaywuNQ063iNvKkjF5ofKyZGwRubY+08 8MdxToec0O9j0zXtOvplZorW5jmcIAWIVgTjPfion068jsY76S0nWzlbalw0bCNzzwGxgng/ ka0Z/DM9vMkT3tmGW5S0uSXZVtJWzgSEqBj5XyV3D5Tz0yAXrS+sNMXT7QX8Vw0Ml3KLqBJA kLywokbfMobKOgckKccFcngPt/Edza6/DLP4gnu2FlLaG9TzAF3q+35iA7KrurEkZBHAO1c5 3/CNvJNpqWeoWd2uo3JtY5IvNVUkGzO7einH7xeQD3qt/ZAkvPJtb+1uYlj82W5QSLFCucEt vRT6dAclgBkkCgBmsSGW+Mj6m2pzMo825bfhj0ABfDEBQoyQOcjGACaNakWkW0rXO7W9Ojih ZFEribEpYE/KojLYGCCSoAJHqKmXwzOdSuNPa9s0vIrlrSOEuxa4lU7cLhTgEkAF9oOevDYA NTwxq+ixQLZ6gstmFt7gSTC4ISd3R0UlVhdshZMA5wuGIGSQ3I0VqTaDPDYtcG4gaWOFLiW2 Ut5kUT7djkldpB3pwGJ+cZAwcAFzV4rCSz0aGDWbOZreH7NKUjnATM0r7/mjGVAcZxznoDU2 oT2kfiTSryz1qArGtojXEUEjG3MUcaFyrou4ZUkAZyBzjNZV5o7WlmblLu1ukjkWKYW7MfJd gxCkkANnY/KFh8vXkZY+ialDfR2U9jPb3Mi71juEMR285Y7sYUYJLHgAEk8GgDSjvbebVNfj udRVxqKui38kTKjnz0k3sqgsoYIeADgsBwMkWPO0q81Ke5e/tUktre2t7b7VFK0UrJEsbSYV GJAKZCsBncC3AKHAvbaK1mCQ3sF4pXPmQLIFB9PnVTn8Mc0WFlJqF2tvEyqSrOzuTtRFUszH GTgKCeATxwCeKANf7asWn+I4E15pFuZoyEe2LNqIEhO8seYyPvcnJziprTUbFLGzuHulWWz0 65sjbFH8yRpPO2spA27R5y5ywPytweM1h4Uu/tk1o9zaxzrdvYwoxc/aZkIBVCFIHLJy+0fM OeDihFpZNibu4uoLVWVmgSbfvuMZB2hVPGRjLYBOQD8rYANrVNVsb7R8vLayOLS3gt4Utttx FLGsas7yBBuQqkgA3t95PlGPl520jhmvII7mf7PA8irJNsL+WpPLbRycDnFW7fRLi50a61QP EkFv/CxO6TDRq23AxwZY85I+9xnBxDpWntq2qW1hHNFDJcyCJHl3bdx4AO0E8nA6d+cDmgDo Dd6dZXlssOpwPaGG6t1hgjlKW4khMayOzIpdmLZYhc4QYGNqBn26w+z/ANlfb4tv9mfY/tmy Tyd/2r7RnG3fjb8v3fvdsfNWLBpM73cEF4y6es8JnSa8DIhj2lgwwCSDtIGAcnAFXF8NvJqu mWMWoWcg1NQYLhfNEZJdkAOUDA7kI+7jkduaANG2u9On1+e4k1OC3hi077EryxynzW+yGDco VCdu4Z+bBwRxnIHLzIsczokiyqrECRAdrj1GQDg+4BqxY2KXnmNNfWtlGmBvuCxyTnACorMe h5xgdyCRmK7tZrG8ntLlNk8EjRSJkHaynBGRweRQBDRW1ZeFdRvNFm1YRNHZorsjtDKwl2DL YKIwAHTLFRnPPDYhm0GeGxa4NxA0scKXEtspbzIon27HJK7SDvTgMT84yBg4AMuirNzp15Zw wTXVpPBFcLuheWNlWUcHKkjkcjp6itG68M3MWtJo9ncQajqDTPA0NqJMo6nBBLoox15BIABJ IFAGLRW7deFbqyv3trm4ihSO3FxLPLDPGsaF9gJVow5yxUfKp6+xxW/sQxXc0N3qFnapGqMs 0rOVkDruQqqqXwVOeVGOA2CQCAZdFaKeH9XmvLu0t9NuriezkMU6W8Rl8tgSMErkdQfyo0zR LjVYLuaF4o47WNnYyE/MQjybRgHkrG55wPl6gkZAM6itG30S4udGutUDxJBb/wALE7pMNGrb cDHBljzkj73GcHDxoF0dIg1EyQLHPMkSI8m1sOZArkn5Qu6KQcsCNuSMEEgGXRV7UNLNlDDP FdQXltMzIs0G8LvXaWXDqrZAZT0x83Xg4o0AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFAHqnwW/5jZ/64c/9/P8AP+cj1Tp7Y/z/AE9unbHy+V/Bb/mNn/rhz/38 /wA/5yPVOntj/P8AT26dsfKhkc3+rcf7HT/gS/5/zgV/Bv8AyLNt/wBdJv8A0a9WJv8AVuP9 jp/wJf8AP+cCv4N/5Fm2/wCuk3/o16EBu0UUUxBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB5n8RZLeGLTpbya6ggjlR2ktAPNXAUjZkgA5x znjrzjFedDxBp0/iTRtYnSW2+yyK9xaWluohi2PuUQqX4DdWBxhizc5xXoXxLsLjVLSxsrRV a4ndVjV5FQMdq4GWIGT255PFeU2Ph6+v7nS4E8iM6oxFu0s6KCAxUkjOQMggZGWIIGTxSQFn T7nSdOv5Wiv78wPb7Q7WET5feDteJpCrpgZ5PDbTj5astr1ncT3iPNeWcck1tPFc28atIrwo yAhN6hAd5YBWwmAoBGCKd74f2akLTTbhbpfJ815ZJYESMZx8zrK6KM4HLA5YDHIyyLw3fnUW tZYseX5ZkaKSOTIcBlEfzBZHZTlUU5bBx0OGBu/8JPoz+IEvpVv2gt9Xk1KJVjRWk8wxllb5 iF2GPjGd+cfJ1qa08R+HrXR47D7RqjbLdofM+xRjOVuhnHnf9PX/AI578YV54Tv4NYFhb+VP 5t3NaW8hmjTzXibBBBb5CcrgN13DGciqz+HNTSxjvfs6vbyQ+erRTI52c8kKSQflfgjOEc4+ RsAG74jvbazhaEXrXlzcaVa2eyN45IbcJ5TNtkWRsnfERt2r94nJ43c/q93b3f2H7NcX83k2 kcUn21w2xxnKx46RjsPrT7/w5qemQtLdW6qiqr5SZHyjY2yAKTlDkDePlycZzxVbUNLvNL+y /bYfK+1W6XMPzBt0bZ2tweM4PB5oAfo1zBaanHNcyzwxKrgvAiu2ShABViFZSSAyngqSO9bq eJ7SPUJNoYwSWX2QztZQkA+aJdwtifLA4C7QQM5f7xIrmrW1mvbhILdN8jZwMgAADJJJ4AAB JJ4ABJ4q8/h3UY7mOBkgJkh88SrdRGIR7im4yBtgG4FeSOcDqRQBqRa7Zte301zqF03m+SsT HSrZ42VEK/NAzbFKjaFKngbv71PsPElhBNPdyteLI97JdLatElwpU7SAs7kSROcEGRctwp6r WLHoN/JcTQ+XFGYNu95p444/mGVw7MFO4crgncASMgZqa38L6rc3ktokESTx3BtiktzFHvlB wUQswDkEjIXPUeoyAPtrnSk8M3VnLcXi3k80c4VLZDGDGsqhd3mA4PmDJ28Y6GrMmsadNbys 7XST3lpb2MyCFSsSRGLMitvBckQj5SF+8fm45yjpUq6KdTYqYjMsQCSRsQSH+8A25T8hxlcE ZOeBl40G/NvHOY4lSTacNPGGRWICu6lsohyvzMAvzLzyMgGvruu6dqqa7IlxfyT39/HdQiaF cKiq4CM3mEjAkIGAeEHTPy87arbvcIt5LLFAc7nijEjDjjCllB5x3FW9T0DUtH3fb7byikhi dd6sY25wGAJK5AJXONwGRkc1RhEbTIJnZIiw3sihmA7kAkZPtkfWgDo73V9KuNc1qaOS8+x6 wr73a3QSQEzLLgJ5mHHyAZ3L94nHGC6+1zTrrVr27+36yftGmLb+YoWN5ZljVMS/O26Ntm5u c847ZOXc6FcR69f6XbMspsppI2mkZYkAVtu5mY7VBOByepA5JFWYfC1zPYXcitturS4jjljk KJEI5EZlk84ttwduAeh3LgncBQBhV1ei+IdOttNS2vHniK209swjsop2bzBIAyyO6tGB5n3F 4O0nOXasW30DUrnzQltseOQxGOV1jd5B1RFYgu4yMqoJ5HHIyxNPjk0GfUBO3mw3McDQmMbS HV2DBs9f3ZGMdxz2oA2NQ8RQ3uimCOZoZmtoLZ4F0+HDiMIObjIkIPlhsY4OF6DNM1/X7fVL N4onupPMuBNFFOoCWCAN+5h+Y5Q7lHAT/Vrx/dx7jS7y006yv54dlrfb/s8m4HfsOG4ByMH1 xTdOto7zUrW2muFtoppkjed8bYgSAWOSOBnPUdKALz6nbveaWFa6ht7G3WNJYiBMj5aRnHOD iV2IGVyoAyD81aieKY49QkeO91FWlsvsr6ooAunPmiXeV38nAEeN/wB0A5/hrOi0KC/vdLs9 Lv1muNQZhicLEsI8xlQMdzfMQu7b1+ZQN2RVb+wr03n2ZTau4j81nS8haJFzjLSBti84HJHJ A7jIBcGt26+Ko9WCSkW+2SMkDdNNGg2vIM/xyKGfkn5m5J5pnh/UrPS5hczS3iyo3zwRBWiv I+CYZMkbVOMHhwQ33fl+atHoN/JcTQ+XFGYNu95p444/mGVw7MFO4crgncASMgZqzH4V1GSG 9dms4WsrkWs0c95FGwk+bP3mAx8p5zz2zg4AKcWr3MNibNY7MxFWXc9lC0mDnP7wpuzzwc5H bpWlNr6JoDWEMrXMtzCkUsk9pFG0SqyttWQEvIMqoG4gBVxt6ba0el6cdNFxJqu2f7I9wYFi U4cS+Wked4OSMueOF5AasigDprrVNEgmspdOfUZI7K5SSK2dFt1EY5cmRHZjKxCfOMYxwAAq rePirT4F09ra4uvPtpLkGWHT4bTYs0Ij3qI3wXQruHTPTcuBXF0UAbuoeIC9/FcWrfa5I7fy ZLrULaOWS4O8tuZX3gEAqgOScIOQDgMsdfVJrlb6xs5ob1oxOVhMe1V7KsTxjHQlc4JVSeRm sWigDt5vF2mnV726tvtlvby3r3bwRxgLfqwXMM+ZDhcq/Pzj962FX7pzrfxLGmgQ2Ms94Vgt pbcWAwbeYuzsJWO7hlMgIGw8xryM/LzNFAHUWviWwfRr60v9PiSdrBbO3kgjkOdrK2WBmCr8 yhjtXlmLEHkNX0zxJt1rTbnUkgS2tLlLlvsWnwRyEocgZUJkHpycd8HArn6KANfV9Rt7izgt bae6utlxNcyXN1GEd3kCAggM2f8AV53Z53HjjJuWusacPGNvqlw11HZWUkJt1jhV5HSHYqB8 uACUQZIJ56DHTnKKAN3TLjRrC4upBd36yjYLS6WzRmj4O9tnmgK4OArbjjk4DbStZdX/ALPm uItMjgazMzNEb2ygml29txZDzgDIHGc1l0UAbX2nSpfDNvZy3F4l5BNPOFS2Ro2LrGoXd5gI H7sZO3+LpxzZu9ft59Ca0V7pt1vFClk6j7PbOmzdMh3ffbY2flX/AFr8n+LnKKAOo1/xHa6x vfzJfLubsXM9nHYwQY+9x565ZyN7AMy85JIzxT18RWf9taLc3d5qN+thc/aJLy4iUzuAUKxA GQ/KChIO7jzG44+blKKANqyuNO0/Ui1tqN4LZocM0mnRSbzn7rRNIVZeAcknkDjgGrkeu2F5 qd5qN6Z7K7KxR2j2tukogVE2Z27owHwqYYDAO4hVO0rzNFAHQRalpSQrAsuowRWV7LdWbRBP NkDbAoZsjy2HlL8wDcsTjjmx4e8S2FmkVtqunxNBBbzxpLFHI0jNKpU7lEyL0bBbG7CqMjAI 5eigDqLXxLYPo19aX+nxJO1gtnbyQRyHO1lbLAzBV+ZQx2ryzFiDyGmfxLo+p6Xcw6np/wBm nubuCR/sMbkCKPKnaXmIUhHZVULtAAGOQV5GigDX1260678hrCa6dk3JslgWGKGPjYkah3PU uSScknJySSciiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA9U+ C3/MbP8A1w5/7+f5/wA5HqnT2x/n+nt07Y+Xyv4Lf8xs/wDXDn/v5/n/ADkeqdPbH+f6e3Tt j5UMjm/1bj/Y6f8AAl/z/nAr+Df+RZtv+uk3/o16sTf6tx/sdP8AgS/5/wA4Ffwb/wAizbf9 dJv/AEa9CA3aKKKYgooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooA8w+JctrBaWMt/bNdWyOpeBJfLMg2rxuwcD1xzjpjrXnB8UrceINN1zULWW 41C2kEtzIsyoLlkOYzgJhMAKpxnIXsSTXo/xLtFv7SxtWuoLUSuq+dcMVjQ7VxuIBwO2cYHf A5rzK28LyvrGlabfXcVlcX8gR4pEfzbbLbV3rt4LdVGehBO0HNJAMstV03TtSNza2eoxL5O2 No9RCTRSZ5dZFjAwVyuCp+8eemHya/b3ct6t9ZSyWt1JFKVhuAku+NWRWZyjBiwdix2jcxzx 0L30O01PWo7LQbhXjMO9maSSY5BOQAIUdjjHCo2Bk5wDtYPDTQajcQ3N1amC1kijkkErRh3c FhECyZR8K4JdQFKndjuwLw8Y2v8AbQ1B9JaQRai2owRNdcLI5QyBiFG4fICuMYPXeOKmt/GO lW2mpYpo14YkhaEE6gm7BE4P/LHr/pMn5L6HNS98IldeSxtL6ARXOo3FhAZi+5HjYAB8J1be mCuR83OOcVv+EUu20uK/gubWeOS3M+xC4ZQN5KncoGcQzHgkfuzzkqGALev6rpsaPDpj/apr mwtrW4uRI3l4jWPIVGjVgd0K8kkYJ4BPy4WoXFncfZfsVj9k8u3SOb96ZPOkGd0nP3c8fKOB ir+oeGZ9PhlkF7Z3PlQx3DJA7FvJfbtk5UYGXUbThuc7dvNUNQ0/7B9l/wBLtbn7RbpP/o8m /wAvdn5H9HGOR2oANLu4bHUYrm4hllSPJAhmMLq2DtZXAOCrYYcHpW2njCSPVZLqNbxVltvs zzLeEXbjeH3Gfby2QFzt+4AvvXP2sKXFwkUtzFbI2cyyhiq8d9qsfbgd61z4aaTU9ZtkurW2 GlyN5guJWPyCTYWDBAGwSOwLZ+VSeKAJrfxLDDqN7eMNZM9xsCXKaqVuFUDDK0nl4cE7T90Y 2CjT/FENj9qlWxljnuLh5njtboxWsinG2KSHaQ8YO75cjIcjPeqY8PSpLcfary1treHyv9Jk 3lH8xS8eAqlvmQFuVGMYODxWdd2s1jeT2lymyeCRopEyDtZTgjI4PIoA0bfU9Oi8P3GnSWN0 888iymdbpVUOgkCfJ5ZOMSHI3c44IqZtft5bdllspTPPbw2ly63ACtDGY8BF2Eq5ESfMSw+9 8vIwf8IpdtpcV/Bc2s8cluZ9iFwygbyVO5QM4hmPBI/dnnJUMDwne/2NHqrSRLaNtMkmyQrE rMF3FwhRsEjKozMMkFchgAB+qeILPUYdYCafPFLqV6t4GN0rLGRuyuPLGR+8k7j+H0O7FtWt 0uEa8illgGdyRSCNjxxhirAc47GtHV/Dlxo32gS3FrO1rcfZ7gW7lvKc7toJIAO4Ix4JxjDb TxVbSNKk1m7e2gngilWGSVfPcor7FLEbsYBwCcsQOOSKANV/E1uPEl5q1tZ3Vv8AbN7SbLsC aJ2fcWikCDZ/d+6flLDPPFjUPFOlapFcLd6ZqLtcNbtJIdSQuxhjaNSSYeSQxJ9T6VXtfDUM kN8JrqI7bRby1vFlKQMgmWJyysm84JbAwDlOA24VDZeE72+1Geziki3RRpKHVJJPMRwGRlRE Z8FSDkqMZAbBIBALdt41uF+1/aGv4ftF3LeH+zL02vzyY3Bsq+4DaNvTGW5OeM631PTovD9x p0ljdPPPIspnW6VVDoJAnyeWTjEhyN3OOCKs6d4Ov7+a8iklgtGspjDOZd7rGw+8XMasEUY+ 82FODgna2GW3hHU7vQm1aKP9x5byqPLkO5EzubeF2Lja3DMCccA5XIBm3FxZyadZQwWPk3UO /wC0XPmlvtGTlflPC7Rxx1qpRWjqlnb21rpU1sJR9rtPNkEjhsOJZIzjAGAdmcc4z1NAFfTr 2TTNStb6FVaW1mSZA4JUlSCM47cVr2HiG10i5dtLtLy1imhMUsiX2LggsrfLIECqAUH8BJDO CeRtytU0/wDsvUZbP7Xa3fl4/f2knmRNkA8N3xnB9wafo+kz61fC0t2VXKlssGY4HoqBmY+y gnGSeASADVt/EsMOo3t4w1kz3GwJcpqpW4VQMMrSeXhwTtP3RjYKpw6xbv8Ab4r6xza3lwty YrOQQeW679oXKsAgEjDGP7vPHOpb+DDcRXtsk6m8s7mFJboM5t443jdiZB5e9CrIFYtgKSQQ ME1kQaTFLp+p3KXkEzWS5EaGRWZfMRPMGY8FTvxglW5zjjBAM6Z1kmd0jWJWYkRoTtQegySc D3JNMrabwzP9hguo72zkNxbNdRQo7eYypu8wYKjBXYxOSAcfKWPFGoeGZ9PhlkF7Z3PlQx3D JA7FvJfbtk5UYGXUbThuc7dvNAGLRW6fDgl1PSLC2vrVzqUYMdzuk8pmMjoBgxhl5XbjB55z g8Qnw5cGW3WO4tZY5fNDTRuWSIxKHlBOOdqkHKbgc/KWPFAGRRWjqujtpUVnI93a3Au42lj+ zszfIGKhjkADJU8dRjDBTxTNGso9Q1OOGdmW3VXmmKEb/LjQu+3PG7apxnjOM0AUaK2rHwzP f2NpdQ3tmDdzNbxQu7CRphtxHjb1bepDZ2jPzMpIFQw6DPNYrcC4gWWSF7iK2Yt5ksSbt7gh doA2PwWB+Q4ByMgGXRRXTf8ACEXatp6S31nE9/MkMQkEwBZgSCreXtdc4G5Cy5ZTnBBoA5mi ug0Xw9HfxQyTTKy3cN2IQkwjMM0MfmfvC67dpBXoejZJGCKZaeGhcaitvJqdrHBJaS3cN0Ek ZJVQPnA27hzG4OQPukgH5QwBhUVr2ugC9e+FvqlgY7KNZXlYyIrIWVSy7kB+UsMggE/whjVn SvBuo61DNNp5WeJJmgjdI5WWZxg4BCHYPmXmTYPm68NgA5+it228I6nd6E2rRR/uPLeVR5ch 3ImdzbwuxcbW4ZgTjgHK5ZL4ZuYdAGryXECwsqsqESZfLAbVfZ5bNzkqGJADZAKkAAxaKfDE 08yRIVDOwUF3CqCfUkgAe54ro5vBF3Bdx2rX1mtxLDLMkcwmgYiNdxyJI12gjdhjhfkb5hig DmaK3bXwne31+ltZyRXET25uVuIkkdWjD7CwQJ5h+cFcbM9/u80yXwzc2l3dw6hcQWKWrRq8 04k2kyKWQbVQuCygnlRjGDg8UAYtFa40VBa6vJ9ttZ5NPyNkMjfMBKieYp2FWQ78AblPOegw bNro+mL4ZOp3t8v2idpo4IFd0KuiqcH90wYnevGVGMfNydoBz9FaN5piWuj2N7HcRT/aZJEY xs3yFVjOwqyDBG/qCwOeMY50tQ8Dazp32VZIN0lxcJahNjptlbO1NzqqtnB+ZCy8dcEZAOco roLvSNNsLHR7uW5a5guLmWO5ltJAweNPLJKKyqyNh2GH6kA9CKyNRspNM1K6sZmVpbWZ4XKE lSVJBxntxQBWooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA9U+C3/M bP8A1w5/7+f5/wA5HqnT2x/n+nt07Y+Xyv4Lf8xs/wDXDn/v5/n/ADkeqdPbH+f6e3Ttj5UM jm/1bj/Y6f8AAl/z/nAr+Df+RZtv+uk3/o16sTf6tx/sdP8AgS/5/wA4Ffwb/wAizbf9dJv/ AEa9CA3aKKKYgooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooA8w+Jd2thaWN01rBdCJ1bybhS0bnauNwBGR3xnB75HFeXx+Jrkalp2oz28F1e2L bvPnMjPOQcoZDv8AmK8Y6cAA5AAr1D4lxWs9pYxX9y1rbO6h50i8wxjavO3IyPXHOOmeledx eF4LXxNpWiatcTxXdxMsd5DFGpNuWbCAPuIYkFSTjChh94gikgM1NXto7mSVdE04xSQ+UYGM xQHcG3gmTcG4A4YDGRjk08eIZXluPtVna3NvN5X+jSbwieWpSPBVg3yoSvLHOcnJ5qy9to+s a1HFZSrYWvk/MWi8ss4J4AknZc4xy0ijAOBnAZ76BZ2N7cyT3u+ytZIEDy25xI8qF1DBHyI8 KwLozZGCu4EGmAL4zu11RtQFjYGb7Wb2NWR2WKVtvmFQW/i2DOc46rtPNSxeOJILNbSPRNLW BYzEEzcH5SJQRnzc9J5f++vYYmvvC1i3iSG0gupbeC71e508IId/kFHUJgl8uCJEyTgjB696 6+E459Fh1C1v2ZntjO0csAUKQJiVBDHIxbTc4HOzj5iVAGa7r9ncIINJg2pJaQW09zLEUllE aoNpHmOgGY0bIAPGPUtj6hqH2/7L/olrbfZ7dIP9Hj2eZtz87+rnPJ71q6l4dtbWG4az1Jrm SC2hvGR7fy8RSeXgE7j8+ZV+UZXHO7Py1lahb2dv9l+xX32vzLdJJv3Rj8mQ53R8/exx8w4O aAIrWZLe4SWW2iuUXOYpSwVuO+1lPvwe1a9z4nN1PqszaVYJJqkZScqZuCX8wsuZOCWCn0+U cYznItVt3uEW8lligOdzxRiRhxxhSyg847it2TQLM6t4hgnvfsiaVI7Dy7curoJhGQuXJB+Z doJOe7D71AEM/ic3Mr+dpVg1u8cKNbZmCExKUjbPmbshCV+9g9SCeayLu6mvrye7uX3zzyNL I+ANzMck4HA5Na76Bb2puZr29lSyi8jZJDbh5G86MyR5QuoHyKd3zHBwBkc1l6jZSaZqV1Yz MrS2szwuUJKkqSDjPbigDdtPGs1ppsViuk6dJFHD5OX87cwxKDnEg5Pny9Mff4xgYrQeIw1v JbXdjat9ot0tJrvbIZfKUptwokVCVEaY4GdoyTk5sr4Tjn0WHULW/Zme2M7RywBQpAmJUEMc jFtNzgc7OPmJVh8LxJowv5L/AAY4457iIKm5InZVyqmQOT86n5kVTzhiCpYAZ4n8QW+q319/ ZtstvZ3Vz9qclWEkr/NguC7gEb3Hy4BznHQCt4ZvrHTdWNxqQlaD7PNFsji37y8bJgjehxhi eDnjHGcibXPD0OlfbRb3/wBrNhd/ZLg+SYxuO8rtySTxG27IGD0LDmqeiaZDq17JbTXf2TFv LMshjLrlELkNg5Awp5AY9ODQBZPiRzBdQDT7MQTWwtUjHm4gj3+Z8h35J8z5ssW5GOnFPn8T m5lfztKsGt3jhRrbMwQmJSkbZ8zdkISv3sHqQTzVu10TTRaXzzTbrWSwW9truSJlliAuViYe WrlST84AJI+6dy84itvC8Ut7cRz3/lW0ccMiS7UUsJU8xM+ZIiKdvVd5Oc4DAFgAMk8WO99L fjSdOW9e5a7S4VZd8Up2nI+fBAZdwDBgCTxg4qgurhtOS0ubC1uTDG0UM8hkDwqSWwNrhThm ZvmB69xgVq6d4Tgn1K8sL/U1guLW5NsUhRZGJBwWCs6M4J6BA7HH3Rld0MPhhH0BdRm1GCGW WF54oXkiUMqMy4OXD7iUYAKjAnbyMnaAc/WpqmtJqdpbW40yztRarsjeAylgm5mK/O7DG5ye mffHFZdbWqpYppsJWxWyunZWhjSR3doCD88244DH5Cu0LkbiVAKZAKGqah/amoy3n2S1tPMx +4tI/LiXAA4XtnGT7k0affJYvKZbG1vUlj2GO5DYX5gcqVZSD8uMg9CR3o1S3s7TUZYdOvvt 9quNlz5Ri38An5TyMHI/Cn6Xp8d6bmS4naG2tIfOmeOMSPguqDapKgnc69SOMn2IBpW/i65g kLfYbOQGaOQq4k2lEiaJIiA4ygRiMHlv4iwyKrWOux2MV7GNHsJUvMq4kaf5U3K4QYkHAZFO Tk+pNPXSdNIurr+05202BoYxNHaAytJIjNgxlwABscE7jyBjIOReHg+FXhtptT2X0t/NpohW 3LL56MgB3bh+7O8ZbAYZ4VuSACK51+zh0bTbbToN17DaSW011NEVZA7OWVMSFSCJXXLJnuME jaa7r9ncIINJg2pJaQW09zLEUllEaoNpHmOgGY0bIAPGPUtDp2g2l9o814+pbZ445HFvHGjn 5VJAILh+cfeVGUA5J4bazUdN0q00fTriK8vGvLu284xPbp5efNdD82/IA2HHynOM8ZwoBMvi ry7nTLiLRtOjfTGBg2mcgAMzgHMpyN7lvXIA6cUy18RiJLW2Fja29vFcSyO0SyOxSVdkiYaT kFML1B+UfMCSTZPhvTf7c07TF1ed5L9oNrCyH7tZUDLuzJ97LLkDIwc7iflqnZ6DHeWVjcpd soma689TEP3QgjWRivzfOSjcA7eRjOOaAGeIdTs9RntE0638i1tLfyUG0ruy7uTtLuRy5H3m 6Z4zgVtGvY9P1OOadWa3ZXhmCAb/AC5EKPtzxu2scZ4zjNaWn6Tol5qYhXU7yS2NlPcFltFS RJER22lS5BGEDZB5yBxyRDp2n6beXl7FFdTuI7aaW3861AEhSF3bdtl+QjbxjcCcZGMigA0/ xI+nQ6aken2cjadctdRySebuaQ4+9hwMfKnAA+4PVssHiGVbcxR2dqjrHJDDKN5aCKQtujXL YI/eOMsGb5jzwMWdN8O2uo2Ony/2k0dzf3L2ccBt8jzRs2ktu+5+8XLfeB6K3JBpvh21uobd rzUmtpJ7aa8VEt/MzFH5mQDuHz5ib5Thcc7s/LQBz9bU/iaczJLYWVnprLcpdkWiNtaVM7Dh 2YALubAXA55BwMYtdGNCsbrVtBs7e7lW31OMAXBtsSBjNJGCyeYR1UDIYcY4znIAQeLzbwJA mi6X5MXnCJMTDYJUCSDIkBbIHViSM8EAACg2vT/boLiK3giit4Wt47ZAxjETbt6ZLFsN5j5O 7I3cEYGHzaVYwJaXJ1CWSxmkkheaK2ywkRVJ2qzDch3pgkqeuVGMG5Holi3i7VtNvZpYYLT7 WVa1i3cxK7AAO+QMKeCxJwBnncACtB4iS3N0q6NpxguYVgMJEoVUDh8AiQMSWAOWJPAAIHFQ wa0kcLwTaZZ3Nt5zzRQymULAWwG2lXDEEKg+Yt90epzNp2n6beXl7FFdTuI7aaW3861AEhSF 3bdtl+QjbxjcCcZGMipvD/hga7CD9sW3llm8i3V9iq78dS7rkfMvCB2HdRldwBQXVw2nJaXN ha3JhjaKGeQyB4VJLYG1wpwzM3zA9e4wKfNrZksWtoNPs7VpYUgmmgVw8yLtIDAsVBLIrEqo JI68nJFBbyeFbucwL9phvYEWYM24o6SkqRnbjMYPTPJ5rLoAmtLj7JeQXHlRTeTIr+VMu5Hw c4YdwehFdBpPiKxj1CI31otrp8MNwFtrSN5FeSaPy2Lb5Q2Cu3OG/hGMEk1eg8Laa6Npkl1i +TV4bCW4WFi0bssqkBS+1o96LhuG+9kDgHL0vw/Z39lbXM2oTwiVbveqWqvsMEayEDMgyCjd eMEYxjmgCt/wkMvn/wDHna/Y/s/2b7F8/leXv8zbndv/ANZ8+d2c8fd4pkWtJE1yn9mWbWdw yObNjL5augIVgQ+/OGfqxHzHjgY1J/B8NlNex3+p+V9kt/PLJblwwWcwSKPmHO8Hb2YYLFOc YWqWP9nXpgEnmIY45Y327SUdFdcjnB2sMjJwc8nrQBcsdfFnFepJpdhcm9yJmkEifLuV9oWN 1VRuQHge3TimLrSDRY9Mk0yzlWNpHSdzKJFdwAW4cLnCrjIx8vTk5NLgt59K1ozQK8sFsk0M pZg0Z86NDgA4IIc9QegxigWNq3hmW9jlZrmO5iilR4sBAyykbWD8g7OcqDnGD1yAE+tJPosW mf2ZZxrExdZ0MvmByEDNy5XLBFzxj0Ap9x4hlmvIr+OztYNSS4Fy17HvLySA53FWYpy3OAoH pgcVM2g2g8OvqKal5k6Rq5gjjRgMuFIOH3rjP3mjC5GATuUszxBpulabJFHp95eTStDBKUnt 0RcPEr53Bzz8w4xxnGTjJACTWrS9hsrG40yCzsIbkzSGyMhlw20SbfMdhkhVxnuo9TnO1G9k 1PUrq+mVVlupnmcICFBYknGe3NVqKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigD1T4Lf8xs/wDXDn/v5/n/ADkeqdPbH+f6e3Ttj5fK/gt/zGz/ANcOf+/n+f8A OR6p09sf5/p7dO2PlQyOb/VuP9jp/wACX/P+cCv4N/5Fm2/66Tf+jXqxN/q3H+x0/wCBL/n/ ADgV/Bv/ACLNt/10m/8ARr0IDdooopiCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigDzD4l39xpdpY3toyrcQOrRs8auFO1cHDAjI7ccHmvJrf Xr+1fT3hkiD6bu+zM0EbFMsW7qd2GJIznBORivZ/F4VtT0COSKKWOW8gieOWNXVlYopBDAjo T9Oo5rzWT7FrniLSLLyd+lz3CQC7t7SO0ld3SIOp2ptOxznGDw2NxyDSQGKniK/juZJ41s1a WHyHRbGARum4Ngps2k7gDnGeBzTI9ev47iabzIpDPt3pNBHJH8owuEZSo2jhcAbQSBgHFXNM s9G1HVntsX8dqtpM/nb0Ll442ffsxjBC/c3cZ+/U2labot8l/f3UstnYwSRQxxS3B3FnVzky JC2f9W3GwdevHzMCsni7WY76S9ju1S5km88yLBGCsnGWX5flLYAbGN44bNTJ421qOEQpJZrE FKhBp9uFAO4EY2dP3kn/AH23qat6d4d02/vtHgtzeXcV3qM9nJLCQpeNPLKyqpQlAFk3EHPC nkds77JpUXhm3v5UvGvJpp7cIkqCPKLGwf7pIA8wArznruXGCAP1vxIdTSOCzt/sdqtvFA6n y2kkEahRukWNWYfKp2nIyAewAzdQ1S81T7L9tm837LbpbQ/KF2xrnavA5xk8nmqldu2hWEsM +h2xZLiHXLewe5liRmy3mozqwAbaSgPlkkDaPmOTgA461uXs7hJ4liZ0zgSxLKvIxyrAg/iK 0Z/E+p3L3rytal76Py7hhZQgyDcW7JwdxzuHOQpz8owa7a6Pb+Q2j3vn79wkj3O+zGMHe0Uf XJ4CnG3OecCHRLSzurx/7ReVLWKMu7pkBeQBuYI5QZIGdjckDjO4AE0nifU5bgzSNauWjSMo 1lCYyEGE+TZtyoJAbGQDgHHFZc00lxM800jSSyMWd3JLMTySSeprqx4e0WO61Ca6uZYLCD7M sQlmIMhmiMgbekLnGFJAMakhhnaQVMOlaBpFzeWcVxdXU8F/qb2MFxbqEwqGP5yjAk7xIB1G zGfm+7QBUt/GOs2tnHaQy2ogij8pUaxgb5cMMElMniR85672/vHMNt4kvYrc2kxiltZIxBN/ o8PmvECPk81kLDG0bTzt2rjoK2j4Z0q90VL+y+2W7PbPNsmmSUAgXLDoi8YtWH1kB/gw1S90 fQ9O02Bpr5pL/wAmC4eBHYNIJAjlADFtQhXzu3t937vzYUAp+I/EcuvX1xKsS2ttNMZvIRIw SxzyzIi7yMtgtkgMeeSTD4e1WDRdT+2T2rXQEMkaxq6qMuhQk7kYEYY8EYzjPGQdLW9F0rT5 tQ+ym8ki0zUVtJvNdA0wbzD8uF+QjyiMnduyDhfu1LqGi6bN4ru7Kxsry2srO5nS4kacSIFQ OwAOzKDbG553tgEgMRhgDIPiLUWW6QvBsuoRA6C1iCiMHdtQbcIN3zfLj5vm680+TxPqctwZ pGtXLRpGUayhMZCDCfJs25UEgNjIBwDjitePRNFg1mIHzb7T7rTLi7iEU5Uo0ay/xtGpbmIn 7i4JHDAfNR0y1sJ7y6H2K8hSWynmtGllRwAkMhYnMWHBZCAV2lSDzkZoAhk8W6vI0rtNB5ks zTmQWkIdJGCgujbcox2qcrg5GevNU4tYu4rE2f7iSHayr51tHI6A5yFdlLKMkn5SMEk9STWl omi2d9Dp4ujOZdTvWsoWidVWAjy/nYFTvH70fKCv3TzzxMui6VNY2PlG8S8u9OmuyXdDHGYv NzxtBYP5RAHGzOcv0ABzNampeItR1aGSK8eArLMJ5DFaxRNJIN2GYooLH526+prLooAt6pql 5rWoy3+ozeddTY3ybQucAAcAAdAKbZX9xp8xltmUFl2sskayI464ZWBVhkA8g8gHqBVaigDR j16/juJpvMikM+3ek0EckfyjC4RlKjaOFwBtBIGAcVND4o1WD7MVniZ7a4a5jkktonfzW+85 ZlJYnjkk/dX+6MZFFAGpJ4i1GS0+zF4Fj2uimO1iR0V2ZmVXChlUlm+UEDDEYwcVDFrN9DYm zSVRFtZAxiQyIrZ3KshG5VOWyoIB3Nx8xzRooA1L3xFqN+0LyvAksLI0ctvaxQyIUGFw6KGw ABgZwMD0FPk8UarKkMbTxCOCRpIo0tolVNy7WUALgIw+8n3WySQSTWRRQBefWb576O881Vli XYipEixqpzlRGAF2nLZXGDubIOTmzD4n1OC4eeNrXe0flAGyhKomGBVFKYQHc2QoGdxznNZF FAGvD4n1O3+zeS1qn2W4a5h22UPySN1YfJ9MDoNq4xtXFmz8UvbabdQvbLLczLLHHIUiCQpI CGVR5e5R8zkBXVQW+71B5+igAraPizVPOtJQbNZLJt1uyWFuvln5jxhOmWJx0yc9eaxaKANT /hIr/wAmKErZmKGZ50Q2MBUO/DHGzkdODwNq4HyjDLnXr+61QalLJELvnc8cEaB853b1VQGz uIO4HIODkVnUUAa8PifU4Lh542td7R+UAbKEqiYYFUUphAdzZCgZ3HOc0yy8Rajp0xltngVv O89Q1rE6xSf3owykIeB93H3V9BjLooA1P+EivxYzWQWzFvOxZ1FjACSd3IOzII3tjB+UHAxW XRRQBryeKNVktzCZ4l3SJK0qW0SytIhyrmQLvLgk/NnPJ55NTR+MdZjQRrLa+Wu/ZGbGArGH Xa4QFMKGHUDAOSTyTnCooA6iLxxdSC8fU4Iry5mt2hikEECLHukEjFk8oiTLqDz0yxHJyOdu rqa9uHnuH3yNjJwAAAMAADgAAAADgAADioaKANHT9dvdLt5YLUWvlzf6wS2cMpYZBwS6k4yq nHTIz1oh129g0t9NjFr9lf7wazhZifmwd5Xdkbmwc5GeMVnUUAaNzr1/d2a2s0kXliNIiyQR o7ogAVWdVDMBtXgk/dB6gUyXWb6axFm8qmLaqFhEgkdVxtVpANzKMLhSSBtXj5RijRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHqXwYbb/bZJwAICeMn q/uPWvUBcIP42/79/wD2Xt/nAx5b8HP9Xr3+5B/6E1ej1LGhkOotc6jqNptHl20MRVsYLFjz kZx2H+cAWPBv/Is23/XSb/0a9ZWnf8h3Wv8ArhB/M1q+Df8AkWbb/rpN/wCjXpoDdooopiCi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigDy34o XdxY6daXFncS286EbZYnKMuVUHBHI4JFeUyeIdZmuIbiXVr954N3lStcuWj3DDbTnIyODivU Pi1/yBrf6r/Ja5K6WXXPixJZ38cuownU5LfypHdtkPmNkDaQVCgluDgY54zSQHOf8JDrP2z7 Z/a1/wDavL8rz/tL79mc7d2c4zzimJrmqx30l9Hqd4t5Ku17hZ3EjjjgtnJHA/IVtQ6STqdx FN4dlguIbQSWunTCbfdHzFXLDIZjsLsdm0fu84ABFTDRoFutQ+w6T/aN5F9m/wCJd+9fyt8R ab5UYP8Au5Aqck4zhstg0wOcj1bUYXmeK/ukeeRZZWWZgZHVtys3PJDcgnvzV9dR8SzaRcTJ d6s+mbmWdxJKYcucsGOduWL8567vete1s7RYdcsdL0eDXJbfUVFuT5kkrwDzQXHlMuVGE5HG XGc/LizafY7OytEuvmvU0W7jh2ZlTBe8VtpjyCc7cMfk27yTnaaAOFq9Lrmqz2IsZdTvJLMK qi3edzGAMYG3OMDAx9K2r22F34Y0+Wx0O12JaH7TqCeYPKkWV+GYvs3soQ4YEneAvVQNLWPD MEOlrdado11I9tdwwj9xKYrtH3DcJN580FlQB0EefMHHzKFAOQvtW1HVPL/tG/urvy87PtEz Sbc4zjJ4zgflTbLUbzTJjNp93Paysu0vBIyMR1xkHpwPyrq9U0GC28Yrp7aHLZWC3FwIDKZS 14FyQFJID8gBVTaW3KpfJ31fvPC9taW15f8A/COXj2404XSrNDNB5Mqz7CuN7EKU+dgWLYyQ UzwAcPb6tqNpeS3ltf3UN1NnzJ45mV3ycnLA5OTzV/SPFWo6LNdz20rNc3TB2meaUNvGTuIV wrnLE/OGHtyc9BbeG7q31y+tYtBusS6YZwwScNbO9q7bFwRwZN0eH3Z2leTnNbwvoUTwySap oc86rcmCSWVJPKhK43iRkdTABuyXYOMdF+QhgDCh8T67bwpDDrWoxxRqFREupAqgcAAA8CoY dc1W3tEtIdTvI7aNgyQpO4RSG3AhQcA7ufrzVGtf/kG+HfS41b9LdH/L5pU9iPJ9HoArT65q t1DPDcaneTRXDBpkkndlkIwAWBPJG1evoPSmPq2oy/ZPMv7p/sePs26Zj5GMY2c/L0HT0Fbf mT6roPh63vJp7hf7Rnt0UuzMse22ARcBiBycAKfYHpWj8Rzp8U2n2umXCyRRrIxRZS+0fKkZ 5ReDFHFjk5AB5zvkAJvB2g6r8QZria68R3kUultG0Lyl5mUtk5UlxtI2Dp7elVvGNrrPgnxA YIvEd/cT3luk0twsjxM+CyqG+YlsBeMnvXU/Av8A5j3/AG7/APtSsf41/wDI4Wn/AF4J/wCj JKAOFTVtRi+1+Xf3SfbM/adszDz85zv5+bqevqamj8Q6zD5Platfp5EflRbblx5acfKvPA+V eB6D0rOooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigD0b4UWLXqayPttzaqghLfZ9uW5cc5Feg/wBhp/0GtV/NP8K4j4Of6vXv9yD/ANCauhs/ C13beIXvJNb1CXT1w8No9zIcN6Mc8qOMDvnB6fNLGaWjwLbavrESzzz7YIMyTkFj8x9BWz4N /wCRZtv+uk3/AKNesrTv+Q7rX/XCD+ZrV8G/8izbf9dJv/Rr00Bu0UUUxBRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBw3iXStJ8RxpbahfmF IwOIXTduwOuemMelY2p+CPDur3jXd7rFy0753PGttFuJJJJCKASSTyea9B/4R7Rv+gTYf+Ay f4Uf8I9o3/QJsP8AwGT/AApWA8y/4Vp4T/6C97/38i/wo/4Vp4T/AOgve/8AfyL/AAr03/hH tG/6BNh/4DJ/hR/wj2jf9Amw/wDAZP8ACgDzL/hWnhP/AKC97/38i/wqyngXQI7GSxj8Raqt nK257dbmMRueOSvQngfkK9E/4R7Rv+gTYf8AgMn+FH/CPaN/0CbD/wABk/woA8y/4Vp4T/6C 97/38i/wo/4Vp4T/AOgve/8AfyL/AAr03/hHtG/6BNh/4DJ/hR/wj2jf9Amw/wDAZP8ACgDz L/hWnhP/AKC97/38i/wo/wCFaeE/+gve/wDfyL/CvTf+Ee0b/oE2H/gMn+FH/CPaN/0CbD/w GT/CgDzL/hWnhP8A6C97/wB/Iv8ACj/hWnhP/oL3v/fyL/CvTf8AhHtG/wCgTYf+Ayf4Uf8A CPaN/wBAmw/8Bk/woA8y/wCFaeE/+gve/wDfyL/Cny/DrwvOwaXW9QkYKqgvNESAAAB06AAA ewr0r/hHtG/6BNh/4DJ/hR/wj2jf9Amw/wDAZP8ACgDgZPBugyQ2UQ1y7iWxYvAYPs8TI3y/ NlVBLfIvzHJ461Tl+HXhedg0ut6hIwVVBeaIkAAADp0AAA9hXpX/AAj2jf8AQJsP/AZP8KP+ Ee0b/oE2H/gMn+FAHK+FNK0Twf8Aa/7O1GSX7Vs3/aGRsbd2MYI/vGq/ijw5oHi3Uo77UNTm jljhEIEDxhcAk988/Ma7L/hHtG/6BNh/4DJ/hR/wj2jf9Amw/wDAZP8ACgDzL/hWnhP/AKC9 7/38i/wo/wCFaeE/+gve/wDfyL/CvTf+Ee0b/oE2H/gMn+FH/CPaN/0CbD/wGT/CgDzL/hWn hP8A6C97/wB/Iv8ACj/hWnhP/oL3v/fyL/CvTf8AhHtG/wCgTYf+Ayf4Uf8ACPaN/wBAmw/8 Bk/woA8y/wCFaeE/+gve/wDfyL/Cj/hWnhP/AKC97/38i/wr03/hHtG/6BNh/wCAyf4Uf8I9 o3/QJsP/AAGT/CgDzL/hWnhP/oL3v/fyL/Cj/hWnhP8A6C97/wB/Iv8ACvTf+Ee0b/oE2H/g Mn+FH/CPaN/0CbD/AMBk/wAKAPMv+FaeE/8AoL3v/fyL/Cj/AIVp4T/6C97/AN/Iv8K9N/4R 7Rv+gTYf+Ayf4Uf8I9o3/QJsP/AZP8KAPMv+FaeE/wDoL3v/AH8i/wAKP+FaeE/+gve/9/Iv 8K9N/wCEe0b/AKBNh/4DJ/hR/wAI9o3/AECbD/wGT/CgDzL/AIVp4T/6C97/AN/Iv8KP+Fae E/8AoL3v/fyL/CvTf+Ee0b/oE2H/AIDJ/hR/wj2jf9Amw/8AAZP8KAPMv+FaeE/+gve/9/Iv 8KP+FaeE/wDoL3v/AH8i/wAK9N/4R7Rv+gTYf+Ayf4Uf8I9o3/QJsP8AwGT/AAoA8y/4Vp4T /wCgve/9/Iv8KP8AhWnhP/oL3v8A38i/wr03/hHtG/6BNh/4DJ/hR/wj2jf9Amw/8Bk/woA8 y/4Vp4T/AOgve/8AfyL/AAo/4Vp4T/6C97/38i/wr03/AIR7Rv8AoE2H/gMn+FH/AAj2jf8A QJsP/AZP8KAPMv8AhWnhP/oL3v8A38i/wo/4Vp4T/wCgve/9/Iv8K9N/4R7Rv+gTYf8AgMn+ FH/CPaN/0CbD/wABk/woA8y/4Vp4T/6C97/38i/wo/4Vp4T/AOgve/8AfyL/AAr03/hHtG/6 BNh/4DJ/hR/wj2jf9Amw/wDAZP8ACgDzL/hWnhP/AKC97/38i/wo/wCFaeE/+gve/wDfyL/C vTf+Ee0b/oE2H/gMn+FH/CPaN/0CbD/wGT/CgDzL/hWnhP8A6C97/wB/Iv8ACj/hWnhP/oL3 v/fyL/CvTf8AhHtG/wCgTYf+Ayf4Uf8ACPaN/wBAmw/8Bk/woA8y/wCFaeE/+gve/wDfyL/C j/hWnhP/AKC97/38i/wr03/hHtG/6BNh/wCAyf4Uf8I9o3/QJsP/AAGT/CgDzL/hWnhP/oL3 v/fyL/Cj/hWnhP8A6C97/wB/Iv8ACvTf+Ee0b/oE2H/gMn+FH/CPaN/0CbD/AMBk/wAKAPMv +FaeE/8AoL3v/fyL/Cj/AIVp4T/6C97/AN/Iv8K9N/4R7Rv+gTYf+Ayf4Uf8I9o3/QJsP/AZ P8KAPMv+FaeE/wDoL3v/AH8i/wAKP+FaeE/+gve/9/Iv8K9N/wCEe0b/AKBNh/4DJ/hR/wAI 9o3/AECbD/wGT/CgDzL/AIVp4T/6C97/AN/Iv8KP+FaeE/8AoL3v/fyL/CvTf+Ee0b/oE2H/ AIDJ/hR/wj2jf9Amw/8AAZP8KAPMv+FaeE/+gve/9/Iv8KP+FaeE/wDoL3v/AH8i/wAK9N/4 R7Rv+gTYf+Ayf4Uf8I9o3/QJsP8AwGT/AAoA8y/4Vp4T/wCgve/9/Iv8KP8AhWnhP/oL3v8A 38i/wr03/hHtG/6BNh/4DJ/hR/wj2jf9Amw/8Bk/woA8y/4Vp4T/AOgve/8AfyL/AAo/4Vp4 T/6C97/38i/wr03/AIR7Rv8AoE2H/gMn+FH/AAj2jf8AQJsP/AZP8KAPMv8AhWnhP/oL3v8A 38i/wo/4Vp4T/wCgve/9/Iv8K9N/4R7Rv+gTYf8AgMn+FH/CPaN/0CbD/wABk/woA8y/4Vp4 T/6C97/38i/wo/4Vp4T/AOgve/8AfyL/AAr03/hHtG/6BNh/4DJ/hR/wj2jf9Amw/wDAZP8A CgDzL/hWnhP/AKC97/38i/wo/wCFaeE/+gve/wDfyL/CvTf+Ee0b/oE2H/gMn+FH/CPaN/0C bD/wGT/CgDzL/hWnhP8A6C97/wB/Iv8ACj/hWnhP/oL3v/fyL/CvTf8AhHtG/wCgTYf+Ayf4 Uf8ACPaN/wBAmw/8Bk/woA8y/wCFaeE/+gve/wDfyL/Cj/hWnhP/AKC97/38i/wr03/hHtG/ 6BNh/wCAyf4Uf8I9o3/QJsP/AAGT/CgDhtH8K6JoSzrp+vX0QuNvmYki525x29zWj9hsv+hj v/8Av7HXUf8ACPaN/wBAmw/8Bk/wo/4R7Rv+gTYf+Ayf4UWA5+wj07TmupF1OS5luFVWad04 CnI6fU1qeDf+RZtv+uk3/o16uf8ACPaN/wBAmw/8Bk/wq7b28NpCsNtDHDEudqRqFUc54Apg SUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQB//Z --------------080205090808020504050005-- From owner-linux-xfs@oss.sgi.com Thu Oct 4 04:02:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94B2CX07739 for linux-xfs-outgoing; Thu, 4 Oct 2001 04:02:12 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94B28D07720 for ; Thu, 4 Oct 2001 04:02:09 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.6/8.11.6) id f94B22t23486 for linux-xfs@oss.sgi.com; Thu, 4 Oct 2001 07:02:02 -0400 Date: Thu, 4 Oct 2001 07:02:02 -0400 From: Alan Eldridge To: SGI XFS Dev List Subject: This AM's kernel build barfed in .. sysrq.c? Message-ID: <20011004070202.A22002@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk | /sbin/genksyms -k 2.4.11 > /home/alane/rpm/BUILD/kernel-2.4.11/linux/include/linux/modules/i386_ksyms.ver.tmp mv /home/alane/rpm/BUILD/kernel-2.4.11/linux/include/linux/modules/i386_ksyms.ver.tmp /home/alane/rpm/BUILD/kernel-2.4.11/linux/include/linux/modules/i386_ksyms.ver /home/alane/rpm/BUILD/kernel-2.4.11/linux/include/linux/modversions.h was updated + make -s CC=kgcc include/linux/version.h + echo BUILDING THE NORMAL KERNEL for i386... BUILDING THE NORMAL KERNEL for i386... + make -s -j 1 CC=kgcc bzImage sysrq.c: In function sysrq_handle_mountro': sysrq.c:234: too many arguments to function wakeup_bdflush' make[3]: *** [sysrq.o] Error 1 make[2]: *** [first_rule] Error 2 make[1]: *** [_subdir_char] Error 2 make: *** [_dir_drivers] Error 2 -- Alan Eldridge from std_disclaimer import * From owner-linux-xfs@oss.sgi.com Thu Oct 4 04:17:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94BHmB07992 for linux-xfs-outgoing; Thu, 4 Oct 2001 04:17:48 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94BHhD07973 for ; Thu, 4 Oct 2001 04:17:44 -0700 Received: from there (localhost.localdomain [127.0.0.1]) by wwweasel.geeksrus.net (8.11.6/8.11.6) with SMTP id f94BHc311621 for ; Thu, 4 Oct 2001 07:17:38 -0400 Message-Id: <200110041117.f94BHc311621@wwweasel.geeksrus.net> Content-Type: text/plain; charset="iso-8859-1" From: Alan Eldridge Reply-To: alane@geeksrus.net Organization: a local lack of entropy To: XFS list Subject: Yup it was the merge up to 2.4.11-pre2 Date: Thu, 4 Oct 2001 07:17:37 -0400 X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On line 234, wakeup_bdflush(void) is called with an arg. [alane@wwweasel char]$ cvs log sysrq.c|more RCS file: /cvs/linux-2.4-xfs/linux/drivers/char/sysrq.c,v Working file: sysrq.c head: 1.17 branch: locks: strict access list: symbolic names: Linux-2_4_5-merge: 1.13 Release-1_0_0: 1.13 PreRelease-0_10: 1.13 keyword substitution: o total revisions: 17; selected revisions: 17 description: ---------------------------- revision 1.17 date: 2001/10/03 21:08:38; author: lord; state: Exp; lines: +18 -17 merge up to 2.4.11-pre2 ---------------------------- Checking the two patches on kernel.org, the errant call was introduced in linux-2.4.11-pre2 and retracted in -pre3. So once a merge up to -pre3 happens *that* will be fixed again. -- Alan Eldridge from std_disclaimer import * From owner-linux-xfs@oss.sgi.com Thu Oct 4 04:21:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94BLHs08152 for linux-xfs-outgoing; Thu, 4 Oct 2001 04:21:17 -0700 Received: from smtp3.xs4all.nl (smtp3.xs4all.nl [194.109.127.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94BLBD08132 for ; Thu, 4 Oct 2001 04:21:11 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtp3.xs4all.nl (8.9.3/8.9.3) with ESMTP id NAA18129 for ; Thu, 4 Oct 2001 13:21:09 +0200 (CEST) Message-Id: <4.3.2.7.2.20011004130757.02f41830@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 04 Oct 2001 13:20:11 +0200 To: linux-xfs@oss.sgi.com From: Seth Mos Subject: Allocation failures Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Dell PE 2500 dual 1.13Ghz 2GB ram 200GB hardware raid 10 on Ami Megaraid Kernel 2.4.10-xfs compiled with HIGHMEM and SMP. Oct 4 13:07:38 coltex-2 kernel: __alloc_pages: 0-order allocation failed (gfp=0x70/0) from c0133a20 Oct 4 13:07:38 coltex-2 kernel: __alloc_pages: 0-order allocation failed (gfp=0xf0/0) from c016cc43 Oct 4 13:07:38 coltex-2 kernel: __alloc_pages: 0-order allocation failed (gfp=0xf0/0) from c016cc43 Oct 4 13:07:38 coltex-2 kernel: __alloc_pages: 0-order allocation failed (gfp=0x1f0/0) from c01300c0 Oct 4 13:07:38 coltex-2 kernel: __alloc_pages: 0-order allocation failed (gfp=0xf0/0) from c016cc43 Oct 4 13:07:38 coltex-2 kernel: __alloc_pages: 0-order allocation failed (gfp=0x70/0) from c0133a20 Oct 4 13:07:39 coltex-2 last message repeated 8 times During this time bash reported that a executable did not exist any more. A second attempt did work. The system was already running the mongo.pl benchmarks for about 1 hour. The benchmark was testing ext2 during this error. All the in use filesystems are XFS filesystems mounted without extra options. The test was running on the 200GB hardware raid partition. The mongo command (5 processes): ./mongo.pl ext2 /dev/sda11 /users ext2_results5 5 During the error mongo.pl was working on: 4.Read files of median size 100 bytes (5 processes)... Read : The error that this binary did not exist anymore. (/usr is xfs) [root@coltex-2 /root]# sar bash: /usr/bin/sar: No such file or directory [root@coltex-2 /root]# sar Linux 2.4.10-xfs (coltex-2.coltex.nl) 10/04/2001 11:01:00 AM CPU %user %nice %system %idle 11:11:00 AM all 3.92 0.00 51.46 44.63 The output from mount: /dev/sda1 on / type xfs (rw) none on /proc type proc (rw) /dev/sda9 on /home type xfs (rw) /dev/sda10 on /tmp type xfs (rw) /dev/sda5 on /usr type xfs (rw) /dev/sda8 on /var type xfs (rw) none on /dev/pts type devpts (rw,gid=5,mode=620) /dev/sda11 on /users type ext2 (rw) I did not expect this system to just report that binaries in /usr should vanish and return. This kernel was compiled with gcc-2.96-85. I will install egcs-compat shortly and retest. If someone has interest in this please contact me. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Thu Oct 4 04:56:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94BuOY09117 for linux-xfs-outgoing; Thu, 4 Oct 2001 04:56:24 -0700 Received: from main.braxis.co.uk (root@main.braxis.co.uk [213.77.40.29]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94BuJD09098 for ; Thu, 4 Oct 2001 04:56:19 -0700 Received: (from kszysiu@localhost) by main.braxis.co.uk (8.11.6/8.11.6) id f94BuJP15236 for linux-xfs@oss.sgi.com; Thu, 4 Oct 2001 13:56:19 +0200 Date: Thu, 4 Oct 2001 13:56:18 +0200 From: Krzysztof Rusocki To: linux-xfs@oss.sgi.com Subject: shutting down f/s Message-ID: <20011004135618.A13880@main.braxis.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I witnessed xfs_force_shutdown doing its best yesterday ;-) I was trying to untarbz2 little damaged .tbz2 archive (xaa+xab+xad+xac .... wrongfully connected files after split -b). Since it occured on rootfs I copied output manually. xfs_force_shutdown (ide0(3,1), 0x8) called from line 1020 of file xfs_trans.c. Return address = 0xc01b25b9 (which is xfs_trans_cancel+69 on this kernel) Fatal error on root filesystem Corruption of in-memory data detected. Shutting down filesystem ide0(3,1) Please umount filesystem, and rectify the problems(s) Then i did all things as usual - Alt+SysRQ+UUUB :) After reboot f/s could NOT be remounted r/w - same things happened (xfs_force_shutdown). So i booted from CD and repaired f/s. The only thing that may be interesting (during f/s repair) was: in_freecount/free mismatch, inode chunk 6/214624, freecount 1 nfree 0 After next reboot everything was absolutely correct. I tried to reproduce it but i didn't manage to.... Machine was up not more than an hour, i think. It was quite idle during that time. Kernel came from cvs checkout on 12 September 2001. No highmem, no lvm, md as module but totally unused. I would exclude memory corruption - I've been using it for quite a long time.. I'll memtest86 it out today, however. Hardware: UP Celeron 466 Mendocino / 96MB / VIA82C596 (southbridge) - nothing special i believe. 2GB WDC drive, one xfs partition (rootfs). about 130MB of swap. That was the only occurence of xfs_force_shutdown during my journey with xfs. I'll provide more info if needed. Cheers, Krzysztof From owner-linux-xfs@oss.sgi.com Thu Oct 4 07:05:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94E5Df11506 for linux-xfs-outgoing; Thu, 4 Oct 2001 07:05:13 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94E52D11487 for ; Thu, 4 Oct 2001 07:05:02 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f94E4jL13195 for ; Thu, 4 Oct 2001 07:04:45 -0700 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.191.42]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA68284; Thu, 4 Oct 2001 09:03:28 -0500 (CDT) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.32 #1 (Debian)) id 15p95z-0000Tn-00; Thu, 04 Oct 2001 09:03:27 -0500 Date: Thu, 4 Oct 2001 09:03:27 -0500 From: Nathan Straz To: laurent ribeyre Cc: linux-xfs@oss.sgi.com Subject: Re: Xfsdump doesnt work Message-ID: <20011004090327.B853@sgi.com> Mail-Followup-To: laurent ribeyre , linux-xfs@oss.sgi.com References: <3BBC2B94.3030503@biendecider.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3BBC2B94.3030503@biendecider.com> User-Agent: Mutt/1.3.22i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Oct 04, 2001 at 11:27:48AM +0200, laurent ribeyre wrote: > I hope that you will be able to help me. > I join this attachment with this mail. I dont undersand why xfsdump > doesnt work > is a syntax error? bad install? > my computer has xfs filesystem everywhere (/, /usr......) > the version of xfs is 1.0.9 > the error is segmentation fault Is there a core file that we can look at? You might have to fix your user limits to allow for core files. on bash # ulimit -c unlimited on tcsh % limit coredumpsize unlimited Then you'll need to reproduce the error. If you can make the core file available on a web site or FTP site, that would be better than sending it to the list. -- 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 Thu Oct 4 07:14:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94EE5P11721 for linux-xfs-outgoing; Thu, 4 Oct 2001 07:14:05 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94EDvD11701 for ; Thu, 4 Oct 2001 07:13:57 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f94EDpK26495 for ; Thu, 4 Oct 2001 07:13:51 -0700 Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA90672; Thu, 4 Oct 2001 07:13:16 -0700 (PDT) Message-ID: <3BBC6DA9.8520C887@sgi.com> Date: Thu, 04 Oct 2001 09:09:45 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: Krzysztof Rusocki CC: linux-xfs@oss.sgi.com Subject: Re: shutting down f/s References: <20011004135618.A13880@main.braxis.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Krzysztof Rusocki wrote: > > Hello, > > I witnessed xfs_force_shutdown doing its best yesterday ;-) > After reboot f/s could NOT be remounted r/w - same things > happened (xfs_force_shutdown). > > So i booted from CD and repaired f/s. We've been seeing a couple people with this lately... it's probably not a memory problem, it may be an underlying XFS problem. xfs_repair may "fix" the problem, but it's throwing the baby out with the bath water, as they say... You're running xfs_repair on a filesystem with a dirty log, which is not so good. I have a patch that spits out some more information on the way to _xfs_force_shutdown, if anyone is reliably hitting this error and would be willing to try it again with the patch, please let me know. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Oct 4 07:31:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94EVIP12219 for linux-xfs-outgoing; Thu, 4 Oct 2001 07:31:18 -0700 Received: from smtp-ft1.fr.colt.net (smtp-ft1.fr.colt.net [213.41.78.25]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94EVED12188 for ; Thu, 4 Oct 2001 07:31:15 -0700 Received: from [10.233.2.97] ([213.41.95.158]) by smtp-ft1.fr.colt.net with ESMTP id f94EYqK09545; Thu, 4 Oct 2001 16:34:52 +0200 Subject: Re: shutting down f/s From: David Rousseau To: Eric Sandeen , linux-xfs@oss.sgi.com In-Reply-To: <3BBC6DA9.8520C887@sgi.com> References: <20011004135618.A13880@main.braxis.co.uk> <3BBC6DA9.8520C887@sgi.com> Content-Type: text/plain; charset=ISO-8859-15 X-Mailer: Evolution/0.15.99+cvs.2001.10.03.20.06 (Preview Release) Date: 04 Oct 2001 16:21:07 +0200 Message-Id: <1002205302.3213.14.camel@localhost> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f94EVFD12189 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk le jeu 04-10-2001 at 16:09 Eric Sandeen a écrit : > We've been seeing a couple people with this lately... it's probably not > a memory problem, it may be an underlying XFS problem. I had this problem on machine with the red hat kernel (2.4.2 and 2.4.3 RPMs, ac tree) but never on machines running under linux-2.4-xfs cvs version (linus tree). Can be an interaction with the several patch applied by red hat people and xFS patch ? > xfs_repair may "fix" the problem, but it's throwing the baby out with > the bath water, as they say... You're running xfs_repair on a filesystem > with a dirty log, which is not so good. xfs_repair resolved all problems for me. > I have a patch that spits out some more information on the way to > _xfs_force_shutdown, if anyone is reliably hitting this error and would > be willing to try it again with the patch, please let me know. why not integrate it in linux-2.4-xfs tree ? verbose error message are good. -David sorry for my poor english, I'm french... a polyglot who speak several language is an european and a polyglot who speak only one language is french From owner-linux-xfs@oss.sgi.com Thu Oct 4 07:35:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94EZ7V12493 for linux-xfs-outgoing; Thu, 4 Oct 2001 07:35:07 -0700 Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94EZ2D12474 for ; Thu, 4 Oct 2001 07:35:02 -0700 Received: from bt02e0.god.bel.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id f94EYpD16284; Thu, 4 Oct 2001 16:34:51 +0200 (MET DST) Received: from god.bel.alcatel.be (bt02e1.god.bel.alcatel.be [138.203.145.14]) by bt02e0.god.bel.alcatel.be (8.9.3+Sun/8.9.3/1.1) with ESMTP id QAA08613; Thu, 4 Oct 2001 16:33:52 +0200 (MET DST) Message-ID: <3BBC72CD.7D5A0E92@god.bel.alcatel.be> Date: Thu, 04 Oct 2001 16:31:41 +0200 From: kris buggenhout X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen , "linux-xfs@oss.sgi.com" Subject: Re: shutting down f/s References: <20011004135618.A13880@main.braxis.co.uk> <3BBC6DA9.8520C887@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Might this be related to shutdowns taking a long time to actually unmount fs... I noticed since I upped the kernel to an 2.4.10 release ( dont know the exact checkout) shutdowns hang on umount for a significant larger period... as in taking 2-3 minutes istd of 20-30 secs. I also noticed a relationship with the write activity on that disk. Which did not occur with the 1.0.1 release... Eric Sandeen wrote: > > Krzysztof Rusocki wrote: > > > > Hello, > > > > I witnessed xfs_force_shutdown doing its best yesterday ;-) > > > After reboot f/s could NOT be remounted r/w - same things > > happened (xfs_force_shutdown). > > > > So i booted from CD and repaired f/s. > > We've been seeing a couple people with this lately... it's probably not > a memory problem, it may be an underlying XFS problem. > > xfs_repair may "fix" the problem, but it's throwing the baby out with > the bath water, as they say... You're running xfs_repair on a filesystem > with a dirty log, which is not so good. > > I have a patch that spits out some more information on the way to > _xfs_force_shutdown, if anyone is reliably hitting this error and would > be willing to try it again with the patch, please let me know. > From owner-linux-xfs@oss.sgi.com Thu Oct 4 07:42:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94EgdT12695 for linux-xfs-outgoing; Thu, 4 Oct 2001 07:42:39 -0700 Received: from main.braxis.co.uk (root@main.braxis.co.uk [213.77.40.29]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94EgZD12676 for ; Thu, 4 Oct 2001 07:42:35 -0700 Received: (from kszysiu@localhost) by main.braxis.co.uk (8.11.6/8.11.6) id f94EfR822409; Thu, 4 Oct 2001 16:41:27 +0200 Date: Thu, 4 Oct 2001 16:41:27 +0200 From: Krzysztof Rusocki To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: shutting down f/s Message-ID: <20011004164127.A22027@main.braxis.co.uk> References: <20011004135618.A13880@main.braxis.co.uk> <3BBC6DA9.8520C887@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BBC6DA9.8520C887@sgi.com>; from sandeen@sgi.com on Thu, Oct 04, 2001 at 09:09:45AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Oct 04, 2001 at 09:09:45AM -0500, Eric Sandeen wrote: Hello Eric. > xfs_repair may "fix" the problem, but it's throwing the baby out with > the bath water, as they say... Yes, i thought so... > You're running xfs_repair on a filesystem > with a dirty log, which is not so good. > > I have a patch that spits out some more information on the way to > _xfs_force_shutdown, if anyone is reliably hitting this error and would > be willing to try it again with the patch, please let me know. I can try it. Besides, as David mentioned, it won't make any harm if such patch is included in xfs/cvs tree, will it? Noone will be angry for that I hope :) > > -Eric > Cheers, Krzysztof From owner-linux-xfs@oss.sgi.com Thu Oct 4 08:01:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94F1kF13191 for linux-xfs-outgoing; Thu, 4 Oct 2001 08:01:46 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94F1fD13172 for ; Thu, 4 Oct 2001 08:01:41 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f94F1ZK28697 for ; Thu, 4 Oct 2001 08:01:35 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA3137777; Thu, 4 Oct 2001 10:00:19 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA99608; Thu, 4 Oct 2001 10:00:19 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f94F00o07330; Thu, 4 Oct 2001 10:00:00 -0500 Message-Id: <200110041500.f94F00o07330@jen.americas.sgi.com> To: kris buggenhout cc: Eric Sandeen , "linux-xfs@oss.sgi.com" Subject: Re: shutting down f/s References: <20011004135618.A13880@main.braxis.co.uk> <3BBC6DA9.8520C887@sgi.com> <3BBC72CD.7D5A0E92@god.bel.alcatel.be> Comments: In-reply-to kris buggenhout message dated "Thu, 04 Oct 2001 16:31:41 +0200." Date: Thu, 04 Oct 2001 10:00:00 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Might this be related to shutdowns taking a long time to actually > unmount fs... > I noticed since I upped the kernel to an 2.4.10 release ( dont know the > exact checkout) > shutdowns hang on umount for a significant larger period... as in taking > 2-3 minutes istd of 20-30 secs. Hmm, thats a new one to me too, my shutdowns on all xfs boxes do not appear to have become any longer - however, the systems are not busy before the unmount usually. The new VM showed up later in the 2.4.10-pre series, possibly this was the cause. Can you characterize how much activity there is on the system before shutdown - would there typically be a lot of dirty data in filesystems? Also, you mention write activity - is this during shutdown? Steve > > I also noticed a relationship with the write activity on that disk. > Which did not occur with the 1.0.1 release... > > > Eric Sandeen wrote: > > > > Krzysztof Rusocki wrote: > > > > > > Hello, > > > > > > I witnessed xfs_force_shutdown doing its best yesterday ;-) > > > > > After reboot f/s could NOT be remounted r/w - same things > > > happened (xfs_force_shutdown). > > > > > > So i booted from CD and repaired f/s. > > > > We've been seeing a couple people with this lately... it's probably not > > a memory problem, it may be an underlying XFS problem. > > > > xfs_repair may "fix" the problem, but it's throwing the baby out with > > the bath water, as they say... You're running xfs_repair on a filesystem > > with a dirty log, which is not so good. > > > > I have a patch that spits out some more information on the way to > > _xfs_force_shutdown, if anyone is reliably hitting this error and would > > be willing to try it again with the patch, please let me know. > > From owner-linux-xfs@oss.sgi.com Thu Oct 4 08:12:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94FCRb13570 for linux-xfs-outgoing; Thu, 4 Oct 2001 08:12:27 -0700 Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94FC9D13541 for ; Thu, 4 Oct 2001 08:12:09 -0700 Received: from bt02e0.god.bel.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id f94FC3625463; Thu, 4 Oct 2001 17:12:03 +0200 (MET DST) Received: from god.bel.alcatel.be (bt02e1.god.bel.alcatel.be [138.203.145.14]) by bt02e0.god.bel.alcatel.be (8.9.3+Sun/8.9.3/1.1) with ESMTP id RAA09973; Thu, 4 Oct 2001 17:11:03 +0200 (MET DST) Message-ID: <3BBC7B84.FEFEDBE8@god.bel.alcatel.be> Date: Thu, 04 Oct 2001 17:08:52 +0200 From: kris buggenhout X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: "linux-xfs@oss.sgi.com" Subject: Re: shutting down f/s References: <20011004135618.A13880@main.braxis.co.uk> <3BBC6DA9.8520C887@sgi.com> <3BBC72CD.7D5A0E92@god.bel.alcatel.be> <200110041500.f94F00o07330@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: > > > Might this be related to shutdowns taking a long time to actually > > unmount fs... > > I noticed since I upped the kernel to an 2.4.10 release ( dont know the > > exact checkout) > > shutdowns hang on umount for a significant larger period... as in taking > > 2-3 minutes istd of 20-30 secs. > > Hmm, thats a new one to me too, my shutdowns on all xfs boxes do not appear > to have become any longer - however, the systems are not busy before the > unmount usually. The new VM showed up later in the 2.4.10-pre series, > possibly this was the cause. > > Can you characterize how much activity there is on the system before > shutdown - would there typically be a lot of dirty data in filesystems? > Also, you mention write activity - is this during shutdown? > After a whole day of writing files / ftp logs / ftp data /archiving data on cd / removing data, . approx 1-3Gig/day. with some processes still holding a lock on that dir ( they should get killed before umount gets called) I would say this fs should amount to a high percentage of dirty data. as its a very active fs read/write/delete... From owner-linux-xfs@oss.sgi.com Thu Oct 4 08:17:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94FHHD13821 for linux-xfs-outgoing; Thu, 4 Oct 2001 08:17:17 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94FHDD13802 for ; Thu, 4 Oct 2001 08:17:13 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f94FH8K29681 for ; Thu, 4 Oct 2001 08:17:08 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA3145349; Thu, 4 Oct 2001 10:15:52 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA96124; Thu, 4 Oct 2001 10:15:51 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f94FFW607488; Thu, 4 Oct 2001 10:15:32 -0500 Message-Id: <200110041515.f94FFW607488@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: kris buggenhout cc: Steve Lord , "linux-xfs@oss.sgi.com" Subject: Re: shutting down f/s In-Reply-To: Message from kris buggenhout of "Thu, 04 Oct 2001 17:08:52 +0200." <3BBC7B84.FEFEDBE8@god.bel.alcatel.be> Date: Thu, 04 Oct 2001 10:15:32 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Steve Lord wrote: > > > > > Might this be related to shutdowns taking a long time to actually > > > unmount fs... > > > I noticed since I upped the kernel to an 2.4.10 release ( dont know the > > > exact checkout) > > > shutdowns hang on umount for a significant larger period... as in taking > > > 2-3 minutes istd of 20-30 secs. > > > > Hmm, thats a new one to me too, my shutdowns on all xfs boxes do not appear > > to have become any longer - however, the systems are not busy before the > > unmount usually. The new VM showed up later in the 2.4.10-pre series, > > possibly this was the cause. > > > > Can you characterize how much activity there is on the system before > > shutdown - would there typically be a lot of dirty data in filesystems? > > Also, you mention write activity - is this during shutdown? > > > After a whole day of writing files / ftp logs / ftp data /archiving data > on cd / removing data, . > approx 1-3Gig/day. > > with some processes still holding a lock on that dir ( they should get > killed before umount gets called) > > I would say this fs should amount to a high percentage of dirty data. > as its a very active fs read/write/delete... So this probably relates mostly to how the vm changes have affected flushing of data out to disk. Steve From owner-linux-xfs@oss.sgi.com Thu Oct 4 10:14:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94HEfC16617 for linux-xfs-outgoing; Thu, 4 Oct 2001 10:14:41 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94HEdD16588 for ; Thu, 4 Oct 2001 10:14:39 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA11424 for ; Wed, 3 Oct 2001 16:57:44 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA10532 for linux-xfs@oss.sgi.com; Thu, 4 Oct 2001 09:56:28 +1000 (EST) Date: Thu, 4 Oct 2001 09:56:28 +1000 (EST) From: Nathan Scott Message-Id: <200110032356.JAA10532@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - fix merge Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Wed Oct 3 16:56:28 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:103919a linux/arch/i386/kernel/entry.S - 1.37 - fix slightly botched merge from Linus' kernel. no bad side-effects though. From owner-linux-xfs@oss.sgi.com Thu Oct 4 10:15:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94HF2B16737 for linux-xfs-outgoing; Thu, 4 Oct 2001 10:15:02 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94HExD16690 for ; Thu, 4 Oct 2001 10:14:59 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id XAA27720 for ; Tue, 2 Oct 2001 23:17:10 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA84515 for linux-xfs@oss.sgi.com; Wed, 3 Oct 2001 16:15:53 +1000 (EST) Date: Wed, 3 Oct 2001 16:15:53 +1000 (EST) From: Nathan Scott Message-Id: <200110030615.QAA84515@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - ACL man pages Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Oct 2 23:14:32 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:103851a cmd/acl/man/man1/setfacl.1 - 1.2 - fix a couple of the examples - they had bogus ACL specifications. From owner-linux-xfs@oss.sgi.com Thu Oct 4 10:15:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94HF1Y16714 for linux-xfs-outgoing; Thu, 4 Oct 2001 10:15:01 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94HEqD16647 for ; Thu, 4 Oct 2001 10:14:52 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA01597 for ; Wed, 3 Oct 2001 09:39:04 -0700 (PDT) mail_from (roehrich@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA3131329; Wed, 3 Oct 2001 11:37:33 -0500 (CDT) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.187.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA09805; Wed, 3 Oct 2001 11:37:33 -0500 (CDT) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id LAA33083; Wed, 3 Oct 2001 11:37:32 -0500 (CDT) Message-Id: <200110031637.LAA33083@slobber.americas.sgi.com> To: Takayuki Sasaki cc: linux-xfs@oss.sgi.com Subject: Re: wbee (sample_hsm) dumped core Date: Wed, 03 Oct 2001 11:37:32 -0500 From: Dean Roehrich Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From: Takayuki Sasaki >Hi, > >Takayuki Sasaki wrote: > >> migin daemon in sample_hsm started with the patch which I >> posted, but if I try to read the migrated file then it >> stalled. It was caused by >> linux-2.4-xfs/cmd/xfstests/dmapi/src/sample_hsm/wbee which was >> dispatched by migin dumped core. > >In the above situation, I killed the stalled command ( cp ) and >migin by pressing Ctrl + c to find out what is wrong. Then, >unmount the XFS file system, the following console messages >appeared: > > XFS unmount got error 16 > linvfs_put_super: vfsp/0xc2acb38c left dangling! > VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day >... Do you have a trace from the wbee core dump? You should also know that memory-mapped I/O is not going to trigger DMAPI read/write events, yet--I've been experimenting with a fix for that for a while now. Apparently your cp didn't do memory-mapped I/O in this case, else it wouldn't have blocked. Something to keep in mind. Is your stagedir on the same filesystem that migin is monitoring? They should be different filesystems. Here's some other handy debugging info... Just prior to the unmount, cat all the files under /proc/fs/xfs/dmapi_d and include their contents in your bug report. There is a file called "summary" which will tell you if there are any active sessions. There is a directory called "sessions" which will have file names that look like pointer addrs--each file name corresponds to an active session and will dump many of the values from the dm_session_t for that session. There is a directory called "fsreg" which will have similar file names, but these correspond to each mounted dmapi filesystem and will dump the dm_fsreg_t for that filesystem. For example, here's a dm_fsreg_t: # cat /proc/fs/xfs/dmapi_d/fsreg/0xc7fca1a0 fsrp=0xc7fca1a0 fr_next=0x00000000 fr_vfsp=0xc74e6320 fr_tevp=0x00000000 fr_fsid=? fr_msg=0xc246c1e0 fr_msgsize=98 fr_state=mounted fr_dispq=? fr_dispcnt=0 fr_evt_dispq.eq_head=0x00000000 fr_evt_dispq.eq_tail=0x00000000 fr_evt_dispq.eq_count=0 fr_queue=? fr_lock=? fr_hdlcnt=0 fr_vfscnt=0 fr_unmount=0 fr_rattr= fr_sessp[14]=0xc631fa00 fr_sessp[20]=0xc631fa00 Thanks, Dean From owner-linux-xfs@oss.sgi.com Thu Oct 4 10:14:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94HEfM16612 for linux-xfs-outgoing; Thu, 4 Oct 2001 10:14:41 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94HEcD16571 for ; Thu, 4 Oct 2001 10:14:38 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA12981 for ; Wed, 3 Oct 2001 18:11:49 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id LAA06302; Thu, 4 Oct 2001 11:11:24 +1000 Date: Thu, 4 Oct 2001 11:11:24 +1000 From: Keith Owens Message-Id: <200110040111.LAA06302@sherman.melbourne.sgi.com> Subject: TAKE - Add drivers/md/Makefile.in to reflect XFS lvm changes Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Add drivers/md/Makefile.in to reflect XFS lvm changes Date: Wed Oct 3 18:10:41 PDT 2001 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:103932a linux/drivers/md/Makefile.in - 1.1 From owner-linux-xfs@oss.sgi.com Thu Oct 4 10:16:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94HGtu17171 for linux-xfs-outgoing; Thu, 4 Oct 2001 10:16:55 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94HGoD17151 for ; Thu, 4 Oct 2001 10:16:50 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA21089 for ; Mon, 1 Oct 2001 15:14:57 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA3054870; Mon, 1 Oct 2001 17:13:42 -0500 (CDT) Received: from sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id RAA30674; Mon, 1 Oct 2001 17:13:41 -0500 (CDT) Message-ID: <3BB8E9F3.8109CBBA@sgi.com> Date: Mon, 01 Oct 2001 17:10:59 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.8-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Florin Andrei CC: linux-xfs Subject: Re: 2.4.9 is bad References: <1001963944.21818.32.camel@stantz.corp.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Florin Andrei wrote: > > Looks like there are some serious problems with 2.4.9 > This is what i get from a system running XFS-1.0.1 on linux-2.4.9, RAID > hardware (DAC960): > > xfs_force_shutdown(dac960(48,4),0x8) called from line 4072 of file > xfs_bmap.c. Return address = 0xc01b8b9c > Corruption of in-memory data detected. Shutting down filesystem: > dac960(48,4) > Please umount the filesystem, and rectify the problem(s) If anyone else is experiencing these "Corruption of in-memory data detected" errors, please let me know - especially if you have a repeatable test case and can hook up a serial console. :) There's someone here who is also looking at this problem, perhaps we can make some headway. Resist the temptation to run xfs_repair on the filesystem, it will probably get the filesytem out of the state we need it to be in to debug this... -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Oct 4 10:17:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94HHQh17292 for linux-xfs-outgoing; Thu, 4 Oct 2001 10:17:26 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94HHND17273 for ; Thu, 4 Oct 2001 10:17:23 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA14789 for ; Mon, 1 Oct 2001 09:38:37 -0700 (PDT) mail_from (nstraz@sgi.com) Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.191.42]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA82054; Mon, 1 Oct 2001 11:37:21 -0500 (CDT) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.32 #1 (Debian)) id 15o64H-0008QW-00; Mon, 01 Oct 2001 11:37:21 -0500 Date: Mon, 1 Oct 2001 11:37:17 -0500 From: Nathan Straz To: Ray Muno Cc: linux-xfs@oss.sgi.com Subject: Re: Bad permissions with SGI XFS 1.01 Redhat 7.1 install Message-ID: <20011001113717.P10348@sgi.com> Mail-Followup-To: Ray Muno , linux-xfs@oss.sgi.com References: <20011001112251.A21559@aem.umn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011001112251.A21559@aem.umn.edu> User-Agent: Mutt/1.3.20i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Oct 01, 2001 at 11:22:53AM -0500, Ray Muno wrote: > We are installing Redhat 7.1 SGI XFS 1.01 on various machines. We have > noticed that there are quite a few system files with wide open permissions. This was caught a while ago. There is an update disk available to fix this for you. See the original post at: http://marc.theaimsgroup.com/?l=linux-xfs&m=99685493904396&w=2 -- 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 Thu Oct 4 10:18:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94HI6W17468 for linux-xfs-outgoing; Thu, 4 Oct 2001 10:18:06 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94HI2D17417 for ; Thu, 4 Oct 2001 10:18:02 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id XAA02826 for ; Sun, 30 Sep 2001 23:03:11 -0700 (PDT) mail_from (kaos@melbourne.sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by nodin.corp.sgi.com (8.11.4/8.11.2/nodin-1.0) with ESMTP id f91627s2178329; Sun, 30 Sep 2001 23:02:07 -0700 (PDT) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 038A3300095; Mon, 1 Oct 2001 16:01:58 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 75F07B8; Mon, 1 Oct 2001 16:01:58 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Timothy Shimmin Cc: Charles Radeke , linux-xfs@oss.sgi.com Subject: Re: xfsdump/restore from cd In-reply-to: Your message of "Mon, 01 Oct 2001 03:10:26 GMT." <20011001031026.L10761@boing.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 Oct 2001 16:01:53 +1000 Message-ID: <30436.1001916113@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 1 Oct 2001 03:10:26 +0000, Timothy Shimmin wrote: >(a) try using split(1) to split up the dump output from stdout > But this would require room for the split files. >(b) write your own drive strategy for xfsdump/xfsrestore :) (c) Use FUSD[*] to send the packets to a user space program that pretends it is a tape driver but does whatever you want, written in any language. [*] http://marc.theaimsgroup.com/?l=linux-kernel&m=100172648804985&w=2 From owner-linux-xfs@oss.sgi.com Thu Oct 4 10:18:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94HIAd17508 for linux-xfs-outgoing; Thu, 4 Oct 2001 10:18:10 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94HI2D17410 for ; Thu, 4 Oct 2001 10:18:02 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id AAA03906 for ; Mon, 1 Oct 2001 00:04:49 -0700 (PDT) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA01919; Mon, 1 Oct 2001 17:03:29 +1000 (AEST) Date: Mon, 1 Oct 2001 17:03:29 +1000 From: Timothy Shimmin To: Takayuki Sasaki Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - xfsdump/restore changes for ia64 Message-ID: <20011001170329.A1372@boing.melbourne.sgi.com> References: <200109280950.TAA36050@snort.melbourne.sgi.com> <200110010606.PAA26141@tagajo.bsd.tnes.nec.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <200110010606.PAA26141@tagajo.bsd.tnes.nec.co.jp>; from sasaki@bsd.tnes.nec.co.jp on Mon, Oct 01, 2001 at 03:06:20PM +0900 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Takayuki, On Mon, Oct 01, 2001 at 03:06:20PM +0900, Takayuki Sasaki wrote: > > FSG QA wrote: > > Date: Fri Sep 28 02:49:27 PDT 2001 > > Workarea: snort.melbourne.sgi.com:/diskb/build4/fsgqa/isms/2.4.x-xfs > (snip) > > cmd/xfsdump/common/stkchk.c - 1.2 > > - make a size long so comparison works for ia32/ia64 with ptr > > I have a question. > > The type of sc_sz in struct stkchk is changed to long from int, > but get_stacksz() is left declared to return int. > > stkchk.c line 90: > stkchkp->sc_sz = get_stacksz( ); > > Further more, I'm wondering because it seems that rlim_cur is > defined as unsigned long. > > [My box is RedHat 7.1] > $ grep rlim_cur /usr/include/*/*.h > /usr/include/bits/resource.h: rlim_t rlim_cur; > /usr/include/bits/resource.h: rlim64_t rlim_cur; > (snip) > /usr/include/linux/resource.h: unsigned long rlim_cur; > $ grep rlim_t /usr/include/*/*.h > /usr/include/bits/resource.h:typedef __rlim_t rlim_t; > /usr/include/bits/resource.h:typedef __rlim64_t rlim_t; > /usr/include/bits/resource.h: rlim_t rlim_cur; > /usr/include/bits/resource.h: rlim_t rlim_max; > /usr/include/bits/types.h:typedef __u_long __rlim_t; /* Type of resource counts. */ > > Which is correct? > Well, from this it seems it should be declared as : unsigned long. But I have a better solution forthcoming. This abstraction (one of too many in xfsdump) has a stack checking function stkchk() which is only called in main.c in a function "stkplay" (it calls itself recursively until it gets stack overflow and outputs at what address this happens at...unsure how useful this is) which is NEVER compiled in (#ifdef NEVER). So I am taking all references to it out and removing this file and its header from the tree. Thanks for the question. Any more files you want deleted ? :) --Tim From owner-linux-xfs@oss.sgi.com Thu Oct 4 10:31:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94HVhJ17982 for linux-xfs-outgoing; Thu, 4 Oct 2001 10:31:43 -0700 Received: from localhost.localdomain (wet-pants.ximian.com [141.154.95.105]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94HVeD17963 for ; Thu, 4 Oct 2001 10:31:40 -0700 Received: (from jacob@localhost) by localhost.localdomain (8.11.6/8.11.6) id f94HU4502643; Thu, 4 Oct 2001 13:30:04 -0400 X-Authentication-Warning: localhost.localdomain: jacob set sender to jacob@ximian.com using -f Subject: Re: 2.4.9 is bad From: jacob berkman To: Eric Sandeen Cc: Florin Andrei , linux-xfs In-Reply-To: <3BB8E9F3.8109CBBA@sgi.com> References: <1001963944.21818.32.camel@stantz.corp.sgi.com> <3BB8E9F3.8109CBBA@sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.14.99 (Preview Release) Date: 04 Oct 2001 13:30:04 -0400 Message-Id: <1002216604.2597.1.camel@wet-pants> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2001-10-01 at 18:10, Eric Sandeen wrote: > Florin Andrei wrote: > > > > Looks like there are some serious problems with 2.4.9 > > This is what i get from a system running XFS-1.0.1 on linux-2.4.9, RAID > > hardware (DAC960): > > > > xfs_force_shutdown(dac960(48,4),0x8) called from line 4072 of file > > xfs_bmap.c. Return address = 0xc01b8b9c > > Corruption of in-memory data detected. Shutting down filesystem: > > dac960(48,4) > > Please umount the filesystem, and rectify the problem(s) > > If anyone else is experiencing these "Corruption of in-memory data detected" > errors, please let me know like i had said in an earlier mail (2 or 3 weeks ago), i had also gotten this (on my root inode it appears) and have subsequently lost that partition to lost+found. jacob -- From owner-linux-xfs@oss.sgi.com Thu Oct 4 10:52:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94HqY218437 for linux-xfs-outgoing; Thu, 4 Oct 2001 10:52:34 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94HqPD18417 for ; Thu, 4 Oct 2001 10:52:25 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f94HqKK05270 for ; Thu, 4 Oct 2001 10:52:20 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA3130988 for ; Thu, 4 Oct 2001 12:51:04 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA21847 for ; Thu, 4 Oct 2001 12:51:04 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id f94Hoho10909; Thu, 4 Oct 2001 12:50:43 -0500 Message-Id: <200110041750.f94Hoho10909@jen.americas.sgi.com> Date: Thu, 4 Oct 2001 12:50:43 -0500 Subject: TAKE - merge up to 2.4.11-pre3 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Not much to say on this one. Date: Thu Oct 4 10:50:02 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:103959a linux/fs/smbfs/proto.h - 1.1 linux/init/main.c - 1.60 linux/include/linux/smbno.h - 1.3 linux/include/linux/smb_fs.h - 1.15 linux/include/linux/module.h - 1.24 linux/include/linux/genhd.h - 1.16 linux/include/linux/fs.h - 1.123 linux/include/asm-ppc/mmu_context.h - 1.12 linux/fs/super.c - 1.59 linux/fs/smbfs/sock.c - 1.9 linux/fs/smbfs/proc.c - 1.12 linux/fs/smbfs/ioctl.c - 1.8 linux/fs/smbfs/inode.c - 1.25 linux/fs/smbfs/file.c - 1.22 linux/fs/smbfs/dir.c - 1.15 linux/fs/smbfs/cache.c - 1.12 linux/fs/smbfs/Makefile - 1.7 linux/fs/nfsd/vfs.c - 1.38 linux/fs/nfsd/nfsxdr.c - 1.10 linux/fs/nfsd/nfsfh.c - 1.32 linux/fs/nfsd/nfs3xdr.c - 1.21 linux/fs/nfsd/export.c - 1.21 linux/fs/lockd/svc.c - 1.12 linux/fs/block_dev.c - 1.29 linux/fs/binfmt_elf.c - 1.33 linux/drivers/video/offb.c - 1.18 linux/drivers/video/controlfb.c - 1.16 linux/drivers/video/clgenfb.c - 1.20 linux/drivers/scsi/st.c - 1.33 linux/drivers/char/sysrq.c - 1.18 linux/arch/ppc/mm/init.c - 1.37 linux/arch/ppc/mm/fault.c - 1.17 linux/Makefile - 1.128 linux/fs/partitions/ultrix.c - 1.4 linux/fs/partitions/sun.h - 1.2 linux/fs/partitions/sun.c - 1.4 linux/fs/partitions/sgi.h - 1.2 linux/fs/partitions/sgi.c - 1.5 linux/fs/partitions/osf.h - 1.2 linux/fs/partitions/osf.c - 1.4 linux/fs/partitions/msdos.h - 1.2 linux/fs/partitions/msdos.c - 1.15 linux/fs/partitions/mac.h - 1.2 linux/fs/partitions/mac.c - 1.5 linux/fs/partitions/check.h - 1.3 linux/fs/partitions/check.c - 1.32 linux/fs/partitions/atari.h - 1.3 linux/fs/partitions/atari.c - 1.6 linux/fs/partitions/amiga.h - 1.2 linux/fs/partitions/amiga.c - 1.3 linux/fs/partitions/acorn.h - 1.4 linux/fs/partitions/acorn.c - 1.11 linux/include/linux/spinlock.h - 1.10 linux/drivers/pci/pci.ids - 1.33 linux/drivers/ieee1394/raw1394.c - 1.13 linux/drivers/ieee1394/ieee1394_core.h - 1.10 linux/drivers/ieee1394/pcilynx.c - 1.14 linux/drivers/ieee1394/ieee1394_core.c - 1.15 linux/drivers/ieee1394/ohci1394.h - 1.12 linux/drivers/ieee1394/ohci1394.c - 1.18 linux/drivers/ieee1394/ieee1394_types.h - 1.9 linux/drivers/ieee1394/ieee1394_transactions.c - 1.8 linux/drivers/ieee1394/ieee1394_syms.c - 1.11 linux/drivers/ieee1394/hosts.h - 1.7 linux/drivers/ieee1394/hosts.c - 1.9 linux/drivers/ieee1394/highlevel.c - 1.6 linux/drivers/net/8139too.c - 1.27 linux/drivers/net/tulip/tulip_core.c - 1.31 linux/drivers/net/tulip/interrupt.c - 1.12 linux/drivers/net/tulip/eeprom.c - 1.11 linux/drivers/ide/ide-pmac.c - 1.7 linux/fs/partitions/ibm.h - 1.3 linux/fs/partitions/ibm.c - 1.9 linux/lib/dec_and_lock.c - 1.3 linux/drivers/ieee1394/video1394.c - 1.12 linux/include/linux/gameport.h - 1.4 linux/fs/smbfs/ChangeLog - 1.7 linux/fs/partitions/ultrix.h - 1.2 linux/drivers/net/natsemi.c - 1.13 linux/drivers/md/md.c - 1.27 linux/drivers/net/wireless/hermes.c - 1.5 linux/drivers/net/wireless/hermes.h - 1.5 linux/drivers/net/wireless/orinoco.c - 1.5 linux/drivers/net/wireless/orinoco.h - 1.5 linux/drivers/net/wireless/orinoco_cs.c - 1.7 linux/drivers/net/wireless/airo.c - 1.8 linux/drivers/ieee1394/sbp2.c - 1.4 linux/drivers/ieee1394/sbp2.h - 1.3 linux/drivers/ieee1394/nodemgr.c - 1.6 linux/drivers/ieee1394/nodemgr.h - 1.4 linux/fs/partitions/ldm.h - 1.4 linux/fs/partitions/ldm.c - 1.3 linux/drivers/ieee1394/ieee1394_hotplug.h - 1.2 linux/arch/ppc/mm/mmu_context.c - 1.2 linux/arch/ppc/mm/pgtable.c - 1.2 From owner-linux-xfs@oss.sgi.com Thu Oct 4 11:06:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94I6wd18821 for linux-xfs-outgoing; Thu, 4 Oct 2001 11:06:58 -0700 Received: from ns1.tricord.com (mx01.tricord.com [64.240.27.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94I6iD18801 for ; Thu, 4 Oct 2001 11:06:44 -0700 Received: FROM ns1.tricord.com BY ns1.tricord.com ; Thu Oct 04 13:06:44 2001 -0500 Received: by mx01.tricord.com with Internet Mail Service (5.5.2650.21) id ; Thu, 4 Oct 2001 13:06:44 -0500 Message-ID: <6DEE94132593D41182D200508BDCA590F7E11A@mail.tricord.com> From: "Mostek, Jim" To: "'jacob berkman'" , Eric Sandeen Cc: Florin Andrei , linux-xfs Subject: RE: 2.4.9 is bad Date: Thu, 4 Oct 2001 13:06:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14CFF.531DD3F0" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk 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_001_01C14CFF.531DD3F0 Content-Type: text/plain; charset="iso-8859-1" We've been seeing some corruption with 2.4.9 without XFS. The last one I looked closely at we have a thread that has just allocated an inode, alloc_inode, which gets it from the inode_cachep kmem_cache_t. The inode is within a certain page that is full of characters that were written by syslog to /var/log/messages. I chased the inode_cachep slab_t structures and there is one next pointer that points to the start of a page (the next page after the one the inode is in). This is wrong as these pointers are offset from the start of a page. I followed all the prev pointers and all the slab_t's are correct and I can see where the bad next pointer is. For this problem, many fields in the inode are OK but the dentry list is bad. Oopsed in d_instantiate. We have had a few scatterred oopses for a few releases (2.4.7, 2.4.8, and now 2.4.9). This is the first one I really chased down in detail to see that it looked like something went wrong in the inode_cachep. I'm wondering if there isn't a bug somewhere in the way the slabs are freed (if all elements are no longer available) racing with a corresnding allocate. Or, maybe someone freed an inode twice or ... Anyway, just chimming in that we are seeing memory corruption on 2.4.9, too. Jim -----Original Message----- From: jacob berkman [mailto:jacob@ximian.com] Sent: Thursday, October 04, 2001 12:30 PM To: Eric Sandeen Cc: Florin Andrei; linux-xfs Subject: Re: 2.4.9 is bad On Mon, 2001-10-01 at 18:10, Eric Sandeen wrote: > Florin Andrei wrote: > > > > Looks like there are some serious problems with 2.4.9 > > This is what i get from a system running XFS-1.0.1 on linux-2.4.9, RAID > > hardware (DAC960): > > > > xfs_force_shutdown(dac960(48,4),0x8) called from line 4072 of file > > xfs_bmap.c. Return address = 0xc01b8b9c > > Corruption of in-memory data detected. Shutting down filesystem: > > dac960(48,4) > > Please umount the filesystem, and rectify the problem(s) > > If anyone else is experiencing these "Corruption of in-memory data detected" > errors, please let me know like i had said in an earlier mail (2 or 3 weeks ago), i had also gotten this (on my root inode it appears) and have subsequently lost that partition to lost+found. jacob -- ------_=_NextPart_001_01C14CFF.531DD3F0 Content-Type: text/html; charset="iso-8859-1" RE: 2.4.9 is bad

We've been seeing some corruption with 2.4.9 without XFS.

The last one I looked closely at we have a thread that has just allocated
an inode, alloc_inode, which gets it from the inode_cachep kmem_cache_t.
The inode is within a certain
page that is full of characters that were written by syslog to /var/log/messages.

I chased the inode_cachep slab_t structures and there is one next pointer
that points to the start of a page (the next page after the one the inode
is in). This is wrong as these pointers are offset from the start of a page.
I followed all the prev pointers and all the slab_t's are correct
and I can see where the bad next pointer is. For this problem, many
fields in the inode are OK but the dentry list is bad. Oopsed  in d_instantiate.

We have had a few scatterred oopses for a few releases (2.4.7, 2.4.8, and
now 2.4.9). This is the first one I really chased down in detail to see
that it looked like something went wrong in the inode_cachep. I'm wondering
if there isn't a bug somewhere in the way the slabs are freed (if all elements
are no longer available) racing with a corresnding allocate. Or, maybe someone
freed an inode twice or ...

Anyway, just chimming in that we are seeing memory corruption on 2.4.9, too.

Jim

-----Original Message-----
From: jacob berkman [mailto:jacob@ximian.com]
Sent: Thursday, October 04, 2001 12:30 PM
To: Eric Sandeen
Cc: Florin Andrei; linux-xfs
Subject: Re: 2.4.9 is bad


On Mon, 2001-10-01 at 18:10, Eric Sandeen wrote:
> Florin Andrei wrote:
> >
> > Looks like there are some serious problems with 2.4.9
> > This is what i get from a system running XFS-1.0.1 on linux-2.4.9, RAID
> > hardware (DAC960):
> >
> > xfs_force_shutdown(dac960(48,4),0x8) called from line 4072 of file
> > xfs_bmap.c.  Return address = 0xc01b8b9c
> > Corruption of in-memory data detected.  Shutting down filesystem:
> > dac960(48,4)
> > Please umount the filesystem, and rectify the problem(s)
>
> If anyone else is experiencing these "Corruption of in-memory data detected"
> errors, please let me know

like i had said in an earlier mail (2 or 3 weeks ago), i had also gotten
this (on my root inode it appears) and have subsequently lost that
partition to lost+found.

jacob
--

------_=_NextPart_001_01C14CFF.531DD3F0-- From owner-linux-xfs@oss.sgi.com Thu Oct 4 11:09:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94I9dK18963 for linux-xfs-outgoing; Thu, 4 Oct 2001 11:09:39 -0700 Received: from roujin.gargoylecc.com (mail@roujin.gargoylecc.com [65.100.85.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94I9XD18943 for ; Thu, 4 Oct 2001 11:09:34 -0700 Received: from ringram by roujin.gargoylecc.com with local (Exim 3.32 #1) id 15pCvx-0000xl-00 for linux-xfs@oss.sgi.com; Thu, 04 Oct 2001 12:09:21 -0600 Date: Thu, 4 Oct 2001 12:09:21 -0600 To: linux-xfs@oss.sgi.com Subject: XFS FAQ update Message-ID: <20011004120921.A3674@roujin.gargoylecc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.22i From: Russel Ingram Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk ----- Forwarded message from Greg Ferguson ----- Envelope-to: ringram@gargoylecc.com Delivery-date: Thu, 04 Oct 2001 08:26:27 -0600 From: "Greg Ferguson" To: announce@linuxdoc.org Subject: updates (Linux+XFS-HOWTO) Linux + XFS HOWTO : Linux on Steroids Russel Ingram ringram@gargoylecc.com v1.01 2001-10-02 This document describes how to build a Linux system that runs on top of the SGI XFS journaling filesystem. * NEW entry http://www.linuxdoc.org/HOWTO/Linux+XFS-HOWTO/ ----- End forwarded message ----- The filesystem migration howto for XFS that is listed in the FAQ under "Q: Can XFS be used for a root filesystem?" has been accepted for inclusion in the official LDP so you might want to go ahead and change the link to point at http://www.linuxdoc.org/HOWTO/Linux+XFS-HOWTO/. Russ -- Russel H. Ingram Gargoyle Computer Consulting (307)742-1361 or (307)760-1317 www.gargoylecc.com From owner-linux-xfs@oss.sgi.com Thu Oct 4 12:40:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94JeCk21303 for linux-xfs-outgoing; Thu, 4 Oct 2001 12:40:12 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94Je7D21284 for ; Thu, 4 Oct 2001 12:40:07 -0700 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id VAA10866; Thu, 4 Oct 2001 21:39:53 +0200 (CEST) Message-Id: <4.3.2.7.2.20011004213806.02ca7d18@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 04 Oct 2001 21:39:00 +0200 To: Russel Ingram , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: XFS FAQ update In-Reply-To: <20011004120921.A3674@roujin.gargoylecc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 12:09 4-10-2001 -0600, Russel Ingram wrote: >----- Forwarded message from Greg Ferguson ----- > >Envelope-to: ringram@gargoylecc.com >Delivery-date: Thu, 04 Oct 2001 08:26:27 -0600 >From: "Greg Ferguson" >To: announce@linuxdoc.org >Subject: updates (Linux+XFS-HOWTO) > > Linux + XFS HOWTO : Linux on Steroids > Russel Ingram ringram@gargoylecc.com > v1.01 2001-10-02 > > This document describes how to build a Linux system that runs on > top of the SGI XFS journaling filesystem. > > * NEW entry > http://www.linuxdoc.org/HOWTO/Linux+XFS-HOWTO/ > >----- End forwarded message ----- > >The filesystem migration howto for XFS that is listed in the FAQ under >"Q: Can XFS be used for a root filesystem?" has been accepted for inclusion >in the official LDP so you might want to go ahead and change the link to point >at http://www.linuxdoc.org/HOWTO/Linux+XFS-HOWTO/. Fixed. Can you send me the SGML version for checking it up with the current state of affairs? Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Thu Oct 4 14:13:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94LDdo22714 for linux-xfs-outgoing; Thu, 4 Oct 2001 14:13:39 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94LDaD22695 for ; Thu, 4 Oct 2001 14:13:36 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA02655 for ; Thu, 4 Oct 2001 14:13:34 -0700 (PDT) mail_from (eric@sgi.com) From: eric@sgi.com Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA3081170 for ; Thu, 4 Oct 2001 16:12:19 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA39634 for ; Thu, 4 Oct 2001 16:12:19 -0500 (CDT) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id f94L95v08977; Thu, 4 Oct 2001 16:09:05 -0500 Message-Id: <200110042109.f94L95v08977@stout.americas.sgi.com> Date: Thu, 4 Oct 2001 16:09:05 -0500 Subject: TAKE - More verbose messages on forced shutdown Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Oct 2 13:19:33 PDT 2001 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean We'll put these in here for a while, at least. The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:103805a linux/fs/xfs/linux/xfs_lrw.c - 1.111 - yank unused "iunlock" variable (leftovers...) Subject: TAKE - Date: Thu Oct 4 14:11:56 PDT 2001 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:103985a linux/fs/xfs/xfs_ialloc.c - 1.147 linux/fs/xfs/xfs_btree.c - 1.92 linux/fs/xfs/xfs_alloc.c - 1.141 linux/fs/xfs/xfs_bmap.c - 1.272 - More verbose error messages on forced shutdown From owner-linux-xfs@oss.sgi.com Thu Oct 4 14:38:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94Lc2c23294 for linux-xfs-outgoing; Thu, 4 Oct 2001 14:38:02 -0700 Received: from borg-cube.no-ip.com (IDENT:root@adsl-45453.turboline.skynet.be [217.136.49.141]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94LbvD23274 for ; Thu, 4 Oct 2001 14:37:57 -0700 Received: from skynet.be (IDENT:kris@borg-cube.no-ip.com [127.0.0.1]) by borg-cube.no-ip.com (8.11.2/8.11.2) with ESMTP id f94LUa201287; Thu, 4 Oct 2001 23:30:36 +0200 Message-ID: <3BBCD4FC.8FDA9C8C@skynet.be> Date: Thu, 04 Oct 2001 23:30:36 +0200 From: kris buggenhout X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.10-pre10-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: "linux-xfs@oss.sgi.com" Subject: Re: shutting down f/s References: <200110041515.f94FFW607488@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: > > Steve Lord wrote: > > > > > > > Might this be related to shutdowns taking a long time to actually > > > > unmount fs... > > > > I noticed since I upped the kernel to an 2.4.10 release ( dont know the > > > > exact checkout) > > > > shutdowns hang on umount for a significant larger period... as in taking > > > > 2-3 minutes istd of 20-30 secs. > > > > > > Hmm, thats a new one to me too, my shutdowns on all xfs boxes do not appear > > > to have become any longer - however, the systems are not busy before the > > > unmount usually. The new VM showed up later in the 2.4.10-pre series, > > > possibly this was the cause. > > > > > > Can you characterize how much activity there is on the system before > > > shutdown - would there typically be a lot of dirty data in filesystems? > > > Also, you mention write activity - is this during shutdown? > > > > > After a whole day of writing files / ftp logs / ftp data /archiving data > > on cd / removing data, . > > approx 1-3Gig/day. > > > > with some processes still holding a lock on that dir ( they should get > > killed before umount gets called) > > > > I would say this fs should amount to a high percentage of dirty data. > > as its a very active fs read/write/delete... > > So this probably relates mostly to how the vm changes have affected flushing > of data out to disk. > I suppose so, I am not that proficient in kernel hacking... ( i am not a coder) but it seems logical ... flushing to disks get's delayed... givven that I upgraded the memory too, 400M... which acounts for a larger possible fs cache. As not a lo of processes run, not much of system memory has to be devoted to running tasks... which can let the cache maximize. I dont remember the defaults in the kernel, but if they are set like in HPUX : default fs cache =50% ( HPUX11) this could amount to a cache of data holding 200Meg ... which could acount for the longer delay in unmounting ( flushing) the disk is actually ratling on umount... I will look into the settings.. kind regards... From owner-linux-xfs@oss.sgi.com Thu Oct 4 16:30:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94NU9B25159 for linux-xfs-outgoing; Thu, 4 Oct 2001 16:30:09 -0700 Received: from rover (rover.mkp.net [209.217.122.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94NU5D25139 for ; Thu, 4 Oct 2001 16:30:06 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=jaguar.mkp.net) by rover with esmtp (Exim 3.33 #1) id 15pHwJ-00080B-00; Thu, 04 Oct 2001 19:30:04 -0400 Received: (from mkp@localhost) by jaguar.mkp.net (8.11.2/8.9.3) id f94NU2h03176; Thu, 4 Oct 2001 19:30:02 -0400 X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f To: Thomas Duffy Cc: linux-xfs@oss.sgi.com Subject: Re: [Fwd: *** ANNOUNCEMENT *** LVM 1.0.1-rc3 available at www.sistina.com] References: <1002127429.12479.7.camel@localhost.localdomain> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 04 Oct 2001 19:30:02 -0400 In-Reply-To: <1002127429.12479.7.camel@localhost.localdomain> Message-ID: Lines: 15 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>>>> "Tom" == Thomas Duffy writes: Tom> so, is this going to be merged into the xfs tree now that it is Tom> backwards compatible with 0.9.x? I'm on the road this week with sporadic Internet access. And I want to do QA on the thing first. However, from the looks of things it should apply fairly cleanly to the XFS tree. -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Thu Oct 4 18:22:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f951M2O26845 for linux-xfs-outgoing; Thu, 4 Oct 2001 18:22:02 -0700 Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f951LuD26822 for ; Thu, 4 Oct 2001 18:21:56 -0700 Received: from dhcp10 (static031-81-151-24.nm01-c3.cpe.charter-ne.com [24.151.81.31]) by swan.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id SAA13996; Thu, 4 Oct 2001 18:21:33 -0700 (PDT) Message-ID: <012701c14d3b$eed96b80$0a00a8c0@intranet.mp3s.com> Reply-To: "Sean Elble" From: "Sean Elble" To: "Utz Lehmann" Cc: References: <014601c14aed$34616ff0$0a00a8c0@intranet.mp3s.com> <200110021239.HAA17289@fsgi158.americas.sgi.com> <20011002151459.C16538@de.tecosim.com> <015601c14baf$e783d060$0a00a8c0@intranet.mp3s.com> <20011004104857.A24928@de.tecosim.com> Subject: Re: IRIX 6.5.6m/XFS CVS: Any problems? Date: Thu, 4 Oct 2001 21:20:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I plan on now trying it this weekend . . . got hung up on some other issues. Thanks for the info! -Sean ----- Original Message ----- From: "Utz Lehmann" To: "Sean Elble" Cc: "Utz Lehmann" ; Sent: Thursday, October 04, 2001 4:48 AM Subject: Re: IRIX 6.5.6m/XFS CVS: Any problems? > Hi Sean > > Yes. I tested it with a 2.4.10 XFS kernel (CVS from Sep 24). The pwd problem > is gone. But I didn't tests it deeply, make some tests yourself. > > > utz > > Sean Elble [S_Elble@yahoo.com] wrote: > > Utz, > > > > So, in other words, I shouldn't have any problems checking out the XFS tree > > at kernel version 2.4.10? (At least based upon your knowledge) > > > > -Sean > > ----- Original Message ----- > > From: "Utz Lehmann" > > To: "Tad Dolphay" > > Cc: ; > > Sent: Tuesday, October 02, 2001 9:14 AM > > Subject: Re: IRIX 6.5.6m/XFS CVS: Any problems? > > > > > > > Tad Dolphay [tbd@sgi.com] wrote: > > > > > > > > > > Utz, > > > > > > > > > > Thanks for the information; do you know if this patch needs to be > > applied > > > > > for NFS v3 to work from IRIX to Linux? It looks really easy to apply > > > > > > > > For the most part NFS V3 will still work using a pre 6.5.13 IRIX client > > > > and 2.4 linux server. The problem is that sometimes when doing a pwd on > > a > > > > NFS mounted directory you won't see the entire path name. > > > > > > Yes, and the IRIX ftpd, Midnight Commander (mc), xemacs, ... are confused > > too. > > > > > > I just tested a 2.4.10 xfs kernel (with preempt patch, but _without_ the > > nfs > > > patch i had attached in my last mail). It's seems to work. My ftpd and mc > > > tests are ok. Tested with IRIX 6.5.3 and HP-UX 10.20. So you dont need the > > > patch for 2.4.10. > > > > > > > > > utz From owner-linux-xfs@oss.sgi.com Thu Oct 4 19:01:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9521C727372 for linux-xfs-outgoing; Thu, 4 Oct 2001 19:01:12 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95219D27345 for ; Thu, 4 Oct 2001 19:01:09 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA03897 for ; Thu, 4 Oct 2001 19:00:04 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id TAA33174; Thu, 4 Oct 2001 19:00:33 -0700 (PDT) Message-ID: <3BBD1365.8EA80AF3@sgi.com> Date: Thu, 04 Oct 2001 20:56:53 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: Andrey Nekrasov CC: linux-xfs@oss.sgi.com Subject: Re: 2.4.11-pre2-xfs References: <20011004141513.A5421@spylog.ru> <200110042051.f94Kp0Q08771@stout.americas.sgi.com> <20011005050215.A9629@spylog.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Andrey - I didn't get the 0-order allocation failed messages... I used "kgcc" (egcs-2.91.66), and this was a 2G machine (booted with "mem=1G"), highmem-4G enabled, SMP PIII-500. I let the tiotest go through 10 loops, no allocation error messages. -Eric Andrey Nekrasov wrote: > > Hello Eric Sandeen, > > Once you wrote about "Re: 2.4.11-pre2-xfs": > > Hm, it works for me... > > Me to work. But __alloc_pages: 0-order allocation failed (gfp=0x3d0/0) from c0127fe9 > > 1. What is compiler you use t compile kernel? > > andy@diamond:~ > gcc -v > Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.2/specs > gcc version 2.95.2 19991024 (release) > > 2. Hardware (cpu/ram)? > 3. highmem (4Gb) enable? > > #while (true) do ./tiotest -c -f 100 ; sleep 60; done -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Oct 4 22:36:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f955ajY29456 for linux-xfs-outgoing; Thu, 4 Oct 2001 22:36:45 -0700 Received: from mail.spylog.com (mail.spylog.com [194.67.35.220]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f955aeD29437 for ; Thu, 4 Oct 2001 22:36:41 -0700 Received: from an.local (an.local [192.168.4.50]) by mail.spylog.com (Postfix) with ESMTP id 7AFF32C626; Fri, 5 Oct 2001 05:02:16 +0400 (MSD) Received: by an.local (Postfix, from userid 1000) id DC71B14296; Fri, 5 Oct 2001 05:02:15 +0400 (MSD) Date: Fri, 5 Oct 2001 05:02:15 +0400 From: Andrey Nekrasov To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.11-pre2-xfs Message-ID: <20011005050215.A9629@spylog.ru> Mail-Followup-To: Eric Sandeen , linux-xfs@oss.sgi.com References: <20011004141513.A5421@spylog.ru> <200110042051.f94Kp0Q08771@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <200110042051.f94Kp0Q08771@stout.americas.sgi.com> User-Agent: Mutt/1.3.22i Organization: SpyLOG ltd. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello Eric Sandeen, Once you wrote about "Re: 2.4.11-pre2-xfs": > Hm, it works for me... Me to work. But __alloc_pages: 0-order allocation failed (gfp=0x3d0/0) from c0127fe9 1. What is compiler you use t compile kernel? andy@diamond:~ > gcc -v Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.2/specs gcc version 2.95.2 19991024 (release) 2. Hardware (cpu/ram)? 3. highmem (4Gb) enable? > [root@iotest ramdisk]# /root/tiobench-0.3.1/tiotest -c -f 110 #while (true) do ./tiotest -c -f 100 ; sleep 60; done Oct 4 22:38:15 buran kernel: XFS mounting filesystem ramdisk(1,0) Oct 4 23:03:38 buran kernel: __alloc_pages: 0-order allocation failed (gfp=0x2f0/0) from c0127fe9 Oct 4 23:03:38 buran kernel: __alloc_pages: 0-order allocation failed (gfp=0x2f0/0) from c0127fe9 Oct 4 23:32:54 buran kernel: __alloc_pages: 0-order allocation failed (gfp=0x2f0/0) from c0127fe9 Oct 4 23:39:21 buran kernel: __alloc_pages: 0-order allocation failed (gfp=0x2f0/0) from c0127fe9 -- bye. Andrey Nekrasov, SpyLOG. From owner-linux-xfs@oss.sgi.com Fri Oct 5 04:07:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95B7UK02858 for linux-xfs-outgoing; Fri, 5 Oct 2001 04:07:30 -0700 Received: from main.braxis.co.uk (root@main.braxis.co.uk [213.77.40.29]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95B7OD02839 for ; Fri, 5 Oct 2001 04:07:25 -0700 Received: (from kszysiu@localhost) by main.braxis.co.uk (8.11.6/8.11.6) id f95B7MA08018; Fri, 5 Oct 2001 13:07:22 +0200 Date: Fri, 5 Oct 2001 13:07:22 +0200 From: Krzysztof Rusocki To: linux-xfs@oss.sgi.com Cc: linux-kernel@vger.kernel.org Subject: %u-order allocation failed Message-ID: <20011005130722.A6570@main.braxis.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, After simple bash fork bombing (about 200 forks) on my UP Celeron/96MB I get quite a lot %u-allocations failed, but only when swap is turned off. When it's turned on, processes are still forking for some time until i get messages like 'fork: Resource temporarily unavailable' or 'cannot redirect /dev/null: too many open files in system' (or similar) and also 'cannot load libdl.so blah blah return code 23' (don't remember exact message)... load goes up to about 700 but _none_ of processess get killed. Machine is almost unresponsible that time... i hardly managed to Alt+SysRQ+UB ... As mentioned in some other mail - no highmem, no lvm, md as module (unused). 2.4.10-xfs cvs co 25th September (not 12th :/ - info in previous mail was incorrect) When swap was off first i got some of 0-order (gfp=0x1d2/0) from c012ac08 (_alloc_pages+24) beside it, in a few seconds also noticed 0-order (gfp=0x1f0/0) from c012ac08 0-order (gfp=0xf0/0) from c012ac08 at random order.... I also saw a really small number of 1-order (gfp=0x1f0/0) from c012ac08 During that time almost all processess were killed by VM, machine was more responsible so i could freely do Alt+SysRQ+K and everything went back to normal... I'm not familiar with LinuxVM.. so... is it normal behaviour ? or (if not) what's happening when such messages are printed my kernel ? Cheers, Krzysztof PS lkml people - please CC, ain't subscribing. From owner-linux-xfs@oss.sgi.com Fri Oct 5 04:59:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95Bxgu03407 for linux-xfs-outgoing; Fri, 5 Oct 2001 04:59:42 -0700 Received: from netbank.com.br (IDENT:postfix@garrincha.netbank.com.br [200.203.199.88]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95BxZD03387 for ; Fri, 5 Oct 2001 04:59:37 -0700 Received: from 1-102.ctame701-1.telepar.net.br (1-102.ctame701-1.telepar.net.br [200.181.137.102]) by netbank.com.br (Postfix) with ESMTP id E044646819; Fri, 5 Oct 2001 08:58:56 -0300 (BRST) Received: (from localhost user: 'riel', uid#500) by imladris.surriel.com with ESMTP id ; Fri, 5 Oct 2001 08:59:20 -0300 Date: Fri, 5 Oct 2001 08:59:19 -0300 (BRST) From: Rik van Riel X-X-Sender: To: Krzysztof Rusocki Cc: , Subject: Re: %u-order allocation failed In-Reply-To: <20011005130722.A6570@main.braxis.co.uk> Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 5 Oct 2001, Krzysztof Rusocki wrote: > After simple bash fork bombing (about 200 forks) on my UP Celeron/96MB > I get quite a lot %u-allocations failed, but only when swap is turned > off. > I'm not familiar with LinuxVM.. so... is it normal behaviour ? or (if not) > what's happening when such messages are printed my kernel ? This is perfectly normal behaviour: 1) on your system, you have no process limit configured for yourself so you can start processes until all resources (memory, file descriptors, ...) are used 2) when all processes are used, there really is no way the kernel can buy you more hardware on ebay and install it on the fly ... all it can do is start failing allocations On production systems, good admins setup per-user limits for the various resources so no single user is able to run the system into the ground. regards, Rik -- DMCA, SSSCA, W3C? Who cares? http://thefreeworld.net/ (volunteers needed) http://www.surriel.com/ http://distro.conectiva.com/ From owner-linux-xfs@oss.sgi.com Fri Oct 5 05:27:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95CR7R03881 for linux-xfs-outgoing; Fri, 5 Oct 2001 05:27:07 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95CQxD03862 for ; Fri, 5 Oct 2001 05:27:00 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 3EA28C00B62; Fri, 5 Oct 2001 20:26:56 +0800 (PHT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 17421C00B60; Fri, 5 Oct 2001 20:26:55 +0800 (PHT) Date: Fri, 5 Oct 2001 20:26:55 +0800 (PHT) From: Federico Sevilla III To: Linux XFS Mailing List Cc: Vishal Agarwal Subject: XFS & ReiserFS (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Fellow XFS users, At the bottom of this email you will find a forwarded message from Vishal Agarwal. I got this in the ReiserFS mailing list and thought maybe someone here has nice answers for this fellow. In particular as of writing nobody in the ReiserFS list has replied. Vishal, maybe you'd be interested in helping out with something in the XFS todo list? There's a lot that can be given thought to help unload Steve Lord and the other SGI folks. I can't quite remember where that todo list is, but I'm sure it's somewhere in the XFS site. As to benchmarks, you can find a number. In particular the ReiserFS website has at least one using Reiser's mongo.pl benchmark tool. It's a little outdated as that's as of kernel 2.4.5 and we're now up to 2.4.11-pre3. XFS is significantly slow with massive deletes of small files (maybe you can help tweak this? I'm sure the XFS developers would love to give you starting tips if you're willing to do so), but otherwise you will see that it's performance is good especially as file size increases. Hoping you will help develop what has become my filesystem of choice. --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: ---------- Forwarded message ---------- Date: Thu, 4 Oct 2001 19:04:28 +0530 From: Vishal Agarwal To: "reiserfs-list@namesys.com" Subject: [reiserfs-list] XFS & ReiserFS Hi, I'm a final year student, doing my masters in computer science from Bombay University, India. I'm doing my industrial training at Persistent Systems Pvt. Ltd. (persistent.co.in), and the platforms I work on are IRIX and C/Objective C (and X/motif sometimes). I wonder if I could contribute towards the development of any module of ReiserFS. I have a good experience in C, though I hardly know C++ and I'm currently honing my objective C skills. I have the following queries: 1. I want to know what are the major design differences between XFS (from SGI) and ReiserFS? 2. Where are the design documentation kept for ReiserFS? XFS has a VERY good set of documents for each module in PDF format on SGI's site. 3. Are there any comparision results availbale between XFS and ReiserFS? Thanks, waiting for your reply. Best Regards, -Vishal Agarwal P.S. I'm sorry for sending the same mail to hans previously. From owner-linux-xfs@oss.sgi.com Fri Oct 5 06:56:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95Dumr05570 for linux-xfs-outgoing; Fri, 5 Oct 2001 06:56:48 -0700 Received: from hammail1.truenorth.com (h-213.61.138.102.host.de.colt.net [213.61.138.102]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95DuhD05551 for ; Fri, 5 Oct 2001 06:56:44 -0700 Received: from fcb-wilkens.com ([170.200.66.15]) by hammail1.truenorth.com (Netscape Messaging Server 4.15) with ESMTP id GKQK2A00.U4X for ; Fri, 5 Oct 2001 15:56:34 +0200 Message-ID: <3BBDBC11.550DF378@fcb-wilkens.com> Date: Fri, 05 Oct 2001 15:56:33 +0200 From: Harald Wagener Organization: FCB Wilkens X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: linux-xfs compatible with CML2/kbuild? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello list, just another question: I came to like the new kbuild Makefile and would like to check out cml2 as well. Does anyone have experience to share about this? Regards, Harald -- Harald Wagener | Systemadministrator FCB/Wilkens GmbH | Tel.:+49-40-2881-1252 An der Alster 42 | Fax.:+49-40-2881-1263 20099 Hamburg | http://www.fcb-wilkens.com From owner-linux-xfs@oss.sgi.com Fri Oct 5 07:13:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95EDXT05970 for linux-xfs-outgoing; Fri, 5 Oct 2001 07:13:33 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95EDUD05951 for ; Fri, 5 Oct 2001 07:13:30 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f95EDPK07535 for ; Fri, 5 Oct 2001 07:13:25 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA3152753; Fri, 5 Oct 2001 09:12:08 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA28456; Fri, 5 Oct 2001 09:12:08 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f95EBdS12766; Fri, 5 Oct 2001 09:11:39 -0500 Message-Id: <200110051411.f95EBdS12766@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Harald Wagener cc: linux-xfs@oss.sgi.com Subject: Re: linux-xfs compatible with CML2/kbuild? In-Reply-To: Message from Harald Wagener of "Fri, 05 Oct 2001 15:56:33 +0200." <3BBDBC11.550DF378@fcb-wilkens.com> Date: Fri, 05 Oct 2001 09:11:39 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hello list, > > just another question: I came to like the new kbuild Makefile and would like > to > check out cml2 as well. Does anyone have experience to share about this? > > Regards, > Harald > -- > Harald Wagener | Systemadministrator > FCB/Wilkens GmbH | Tel.:+49-40-2881-1252 > An der Alster 42 | Fax.:+49-40-2881-1263 > 20099 Hamburg | http://www.fcb-wilkens.com I Keith Owens is still up he can tell you the real details, but the basic answer should be yes. Keith has been putting kbuild compatibility stuff into the XFS cvs tree. Steve From owner-linux-xfs@oss.sgi.com Fri Oct 5 09:45:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95Gjxd10146 for linux-xfs-outgoing; Fri, 5 Oct 2001 09:45:59 -0700 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95GjtD10127 for ; Fri, 5 Oct 2001 09:45:56 -0700 Received: (qmail 32382 invoked from network); 5 Oct 2001 16:45:53 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 5 Oct 2001 16:45:53 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id E46B33000B7; Sat, 6 Oct 2001 02:45:50 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id CA9939A; Sat, 6 Oct 2001 02:45:50 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Harald Wagener Cc: linux-xfs@oss.sgi.com Subject: Re: linux-xfs compatible with CML2/kbuild? In-reply-to: Your message of "Fri, 05 Oct 2001 15:56:33 +0200." <3BBDBC11.550DF378@fcb-wilkens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 06 Oct 2001 02:45:45 +1000 Message-ID: <10221.1002300345@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 05 Oct 2001 15:56:33 +0200, Harald Wagener wrote: >just another question: I came to like the new kbuild Makefile and would like to >check out cml2 as well. Does anyone have experience to share about this? The XFS tree is already kbuild 2.5 ready. Just apply the kbuild-2.5-2.4.10 patch and enjoy. AFAIK there is no CML2 support for XFS yet, just CML1. From owner-linux-xfs@oss.sgi.com Fri Oct 5 09:52:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95GqTZ10359 for linux-xfs-outgoing; Fri, 5 Oct 2001 09:52:29 -0700 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95GqJD10340 for ; Fri, 5 Oct 2001 09:52:20 -0700 Received: (qmail 32473 invoked from network); 5 Oct 2001 16:52:17 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 5 Oct 2001 16:52:17 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 90D833000B7; Sat, 6 Oct 2001 02:52:16 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 7A8919A; Sat, 6 Oct 2001 02:52:16 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Harald Wagener Cc: linux-xfs@oss.sgi.com Subject: Re: linux-xfs compatible with CML2/kbuild? In-reply-to: Your message of "Sat, 06 Oct 2001 02:45:45 +1000." <10221.1002300345@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 06 Oct 2001 02:52:11 +1000 Message-ID: <10342.1002300731@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 06 Oct 2001 02:45:45 +1000, Keith Owens wrote: >On Fri, 05 Oct 2001 15:56:33 +0200, >Harald Wagener wrote: >>just another question: I came to like the new kbuild Makefile and would like to >>check out cml2 as well. Does anyone have experience to share about this? > >The XFS tree is already kbuild 2.5 ready. Just apply the >kbuild-2.5-2.4.10 patch and enjoy. AFAIK there is no CML2 support for >XFS yet, just CML1. Note to self - avoid sending mail at 2:45 AM. The real story is :- Date: Sun, 5 Aug 2001 21:53:28 +1000 From: Keith Owens Subject: TAKE - kbuild 2.5 support for XFS Add XFS specific files for kbuild 2.5 support to the XFS tree. This is not the full kbuild 2.5 code, just the XFS and KDB specific bits. Using kbuild 2.5 with the current XFS tree is a little unusual because it must not disturb the existing kbuild 2.4 code, XFS must still build using the old method. To build XFS using kbuild 2.5 you need 3 directories, source tree 000 containing the main kbuild 2.5 code, source tree 001 containing XFS, KDB plus the full kernel and an object tree. This is not the normal configuration but it works without including all of kbuild 2.5 in the XFS tree. Create a file which sets and exports the required variables, replacing /build/kaos with your build area, and source that file to set the variables. Note that source tree 001 is the linux sub directory of your XFS workarea or CVS tree, do not point at the top of the workarea or CVS tree. # cat trees-2.4.x-xfs export KBUILD_SRCTREE_000=/build/kaos/2.4.x-xfs-kbuild-2.5 export KBUILD_SRCTREE_001=/build/kaos/2.4.x-xfs/linux export KBUILD_OBJTREE=/build/kaos/object-2.4.x-xfs # source trees-2.4.x-xfs Remove any files in the main kbuild 2.5 tree and the object tree. Create the object tree and copy in an initial config. # rm -rf $KBUILD_SRCTREE_000 $KBUILD_OBJTREE # mkdir $KBUILD_OBJTREE # cp .config $KBUILD_OBJTREE Fetch the kbuild 2.5 patch that corresponds to the current XFS kernel from http://sourceforge.net/projects/kbuild/. This was tested on kbuild-2.5-2.4.8-pre4-1.gz. kbuild 2.5 is designed to patch a current kernel but we want a separate tree containing just the kbuild 2.5 code plus the critical files that kbuild 2.5 needs, leaving the XFS tree untouched. # cp -al $KBUILD_SRCTREE_001 $KBUILD_SRCTREE_000 # cd $KBUILD_SRCTREE_000 # zcat ~/kbuild-2.5-2.4.8-pre4-1.gz | patch -p1 # find \( -path ./scripts -prune \) -o \( -type f -links +1 \! -name Makefile -print \) | xargs rm # find -type d -depth | xargs rmdir 2>/dev/null That leaves source tree 000 containing just the main kbuild 2.5 files plus the scripts (for make *config) and the kbuild 2.4 top level Makefile (for kernel version). You can now build XFS+KDB using kbuild 2.5. On a 4 way processor with plenty of memory, I do this # make -j8 -f $KBUILD_SRCTREE_000/Makefile-2.5 oldconfig installable # sudo make -j8 -f $KBUILD_SRCTREE_000/Makefile-2.5 install The only disadvantage with this approach is that the configure help is read from the XFS tree so you do not get help for the kbuild 2.5 specific options. Can't have everything. You can browse $KBUILD_SRCTREE_000/Documentation/Configure.help for the kbuild 2.5 entries. As always, Documentation/kbuild/kbuild-2.5.txt is your friend. Enjoy. From owner-linux-xfs@oss.sgi.com Fri Oct 5 12:06:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95J6UJ14287 for linux-xfs-outgoing; Fri, 5 Oct 2001 12:06:30 -0700 Received: from maple.sucs.soton.ac.uk (maple.sucs.soton.ac.uk [152.78.128.16]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95J6ND14266 for ; Fri, 5 Oct 2001 12:06:23 -0700 Received: from poplar.sucs.soton.ac.uk (poplar.sucs.soton.ac.uk [152.78.128.30]) by maple.sucs.soton.ac.uk (8.10.0/8.10.0) with ESMTP id f95J6LZ16059 for ; Fri, 5 Oct 2001 20:06:21 +0100 (BST) Received: from soton.ac.uk (pluto.sucs.soton.ac.uk [152.78.128.80]) (authenticated as idh) by poplar.sucs.soton.ac.uk (8.10.0/8.10.0) with ESMTP id f95J69P01528; Fri, 5 Oct 2001 20:06:09 +0100 (BST) Message-ID: <3BBE04A0.64D2A0BA@soton.ac.uk> Date: Fri, 05 Oct 2001 20:06:08 +0100 From: "Ian D. Hardy" Organization: University of Southampton X-Mailer: Mozilla 4.7C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: 2.4.11-pre2-xfs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-JKF-MailScanner: Believed to be clean Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I've also been seeing these '__alloc_pages: 0-order allocation' messages (sometimes 4 or 5 order). I must admit I don't understand what they mean. Looking through the archives of various Linux kernel groups these messages seem to be a regular re-occuring thread, that never has a conclusive conclusion! As in the previous messages in this thread 'HIGHMEM 4GB' and SMP appear frequently in the reports of people seeing these messages. Another observation is that whenever specific HW is mentioned the systems showing these problems seem to be based on ServerWorks LE/HE motherboards (as is the case with my systems, which are SuperMicro 370DL3 based) I wonder if this is significant and if it would explain why Eric could not reproduce the problem? What is the motherboard in your system Eric? I'm currently running 2.4.9 and 2.4.10 kernels but have seen these messages on earlier 2.4.x kernels. If anything they are much less frequent in 2.4.10, which appears to be the first version to include the additional '(gfp=0x3d0/0) from c0127fe9' info at the end of the line (I'm sure this means something to someone?). The most reliable way to reproduce them seems to be to exersise a disk/filesystem, particularly XFS (though I've seen the errors when exersising an ReiserFS FS. Indeed, I've recently seen these messages on a Dell 1550, 2Gbyte RAM, ServerWorks HE based, running a 2.4.2 SMP kernel, but without XFS built into the kernel (or as modules) --Ian >Hi Andrey - > >I didn't get the 0-order allocation failed messages... > >I used "kgcc" (egcs-2.91.66), and this was a 2G machine (booted with >"mem=1G"), highmem-4G enabled, SMP PIII-500. > >I let the tiotest go through 10 loops, no allocation error messages. > >-Eric > >Andrey Nekrasov wrote: >> >> Hello Eric Sandeen, >> >> Once you wrote about "Re: 2.4.11-pre2-xfs": >> > Hm, it works for me... >> >> Me to work. But __alloc_pages: 0-order allocation failed (gfp=0x3d0/0) from c0127fe9 >> >> 1. What is compiler you use t compile kernel? >> >> andy@diamond:~ > gcc -v >> Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.2/specs >> gcc version 2.95.2 19991024 (release) >> >> 2. Hardware (cpu/ram)? >> 3. highmem (4Gb) enable? >> >> #while (true) do ./tiotest -c -f 100 ; sleep 60; done > >-- >Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs >sandeen@sgi.com SGI, Inc. -- Ian Hardy Southampton University email: idh@soton.ac.uk \\'BUGS: The notion of errors is ill-defined' (IRIX man page for netstat)\ From owner-linux-xfs@oss.sgi.com Fri Oct 5 12:12:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95JCkM14640 for linux-xfs-outgoing; Fri, 5 Oct 2001 12:12:46 -0700 Received: from locutus.doe.carleton.ca (locutus.doe.carleton.ca [134.117.9.46]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95JCgD14621 for ; Fri, 5 Oct 2001 12:12:42 -0700 Received: from doe.carleton.ca (kelvin [134.117.9.220]) by locutus.doe.carleton.ca (8.10.2+Sun/8.9.1) with ESMTP id f95JCaI29300 for ; Fri, 5 Oct 2001 15:12:37 -0400 (EDT) Message-ID: <3BBE0646.6050000@doe.carleton.ca> Date: Fri, 05 Oct 2001 15:13:10 -0400 From: Mike Sowka User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010816 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Cluster XFS install without CD... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, Ok... I realize I should RTFM but I was hoping someone could just point me in the right direction. I've been working with XFS since it's 1.0 release, needless to say ... IT ROCKS. Now that I've been put in charge on building a computing cluster at school I'd like to use XFS for my cluster nodes. So far...: - I've intalled the main node with RH7.1 XFS-1.0.1 using the CD media (got a boot disk as well ofcourse) - and now I have no clue how to go about installing XFS RH7.1 base systems that have NOTHING but a floppy dirve... :) I could install a video card on each for the sake of install but other than that all I have is the boot disk... any ideas how I should go about this? XFS dump maybe? Thanx, Mike -- /************************************************************************\ | Mike Sowka o _ _ _ | | An Aspiring Engi"Nerd" _o /\_ _ \\o (_)\__/o (_) | | Carleton University _< \_ _>(_) (_)/<_ \_| \ _|/' \/ | | msowka@doe.carleton.ca (_)>(_) (_) (_) (_) (_)' _\o_ | | (home msowka@home.com) | \************************************************************************/ From owner-linux-xfs@oss.sgi.com Fri Oct 5 12:38:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95JcDB15582 for linux-xfs-outgoing; Fri, 5 Oct 2001 12:38:13 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95Jc6D15561 for ; Fri, 5 Oct 2001 12:38:06 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id VAA12933; Fri, 5 Oct 2001 21:38:04 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id VAA01286; Fri, 5 Oct 2001 21:38:03 +0200 (CEST) Date: Fri, 5 Oct 2001 21:38:03 +0200 (CEST) From: Seth Mos To: "Ian D. Hardy" cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.11-pre2-xfs In-Reply-To: <3BBE04A0.64D2A0BA@soton.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 5 Oct 2001, Ian D. Hardy wrote: > Hi, > > I've also been seeing these '__alloc_pages: 0-order allocation' messages > (sometimes > 4 or 5 order). I must admit I don't understand what they mean. Looking through > the archives of various Linux kernel groups these messages seem to be > a regular re-occuring thread, that never has a conclusive conclusion! Correct > As in the previous messages in this thread 'HIGHMEM 4GB' and SMP appear > frequently in the reports of people seeing these messages. Another > observation is that whenever specific HW is mentioned the systems showing > these problems seem to be based on ServerWorks LE/HE motherboards (as is the > case with my systems, which are SuperMicro 370DL3 based) I wonder if this > is significant and if it would explain why Eric could not reproduce the > problem? What is the motherboard in your system Eric? The server at work is a ServerWorks LE based board with 2GB PC133 ram. The lower end Dell servers have these. > I'm currently running 2.4.9 and 2.4.10 kernels but have seen these messages > on earlier 2.4.x kernels. If anything they are much less frequent in > 2.4.10, which appears to be the first version to include the additional > '(gfp=0x3d0/0) from c0127fe9' info at the end of the line (I'm sure this I can reliably kill the box by just starting mongo with 5 processes with any particular fs. It seems to be rather generic. Most of the time it just deadlocks and no further disk IO is possible. In a previous mail I also posted that on another filesystem I suddenly got a response that a executable did not exist anymore! Not that this is very likely to occur in multiple IO situations. I can run a single Bonnie without problems or a mongo.pl with 1 process. As soon as I have more then 1 process that generates any form of decent IO the system deadlocks. > means something to someone?). The most reliable way to reproduce them seems > to be to exersise a disk/filesystem, particularly XFS (though I've seen > the errors when exersising an ReiserFS FS. Indeed, I've recently seen And ext2 for me too. I can not tell if XFS is really any worse then the other filesystems but checking 200GB of ext2 in 8 hours time is not feasible either ;-) > these messages on a Dell 1550, 2Gbyte RAM, ServerWorks HE based, > running a 2.4.2 SMP kernel, but without XFS built into the kernel (or > as modules) The dell PE 2500 is ServerWorks LE based, 2GB ram with both 2.4.10 and 2.4.11-pre3. The only way to fix it is not using HIGHMEM. As soon as I compile without HIGHMEM (4GB) the box is stable and does not deadlock or crash even under heavy load. I have about a month before the system must go into production so if anyone has some hints or tests I could do they are most welcome. I can not get it over my heart to tell that we cannot use half the memory available. There goes my reputation :-/ Cheers Seth From owner-linux-xfs@oss.sgi.com Fri Oct 5 12:41:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95Jf1h15788 for linux-xfs-outgoing; Fri, 5 Oct 2001 12:41:01 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95JewD15768 for ; Fri, 5 Oct 2001 12:40:58 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id VAA14628; Fri, 5 Oct 2001 21:40:56 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id VAA01441; Fri, 5 Oct 2001 21:40:56 +0200 (CEST) Date: Fri, 5 Oct 2001 21:40:56 +0200 (CEST) From: Seth Mos To: Mike Sowka cc: linux-xfs@oss.sgi.com Subject: Re: Cluster XFS install without CD... In-Reply-To: <3BBE0646.6050000@doe.carleton.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 5 Oct 2001, Mike Sowka wrote: > Hello, > Ok... I realize I should RTFM but I was hoping someone could just point > me in the right direction. I've been working with XFS since it's 1.0 > release, needless to say ... IT ROCKS. Now that I've been put in charge > on building a computing cluster at school I'd like to use XFS for my > cluster nodes. So far...: > - I've intalled the main node with RH7.1 XFS-1.0.1 using the CD media > (got a boot disk as well ofcourse) > - and now I have no clue how to go about installing XFS RH7.1 base > systems that have NOTHING but a floppy dirve... :) I could install a > video card on each for the sake of install but other than that all I > have is the boot disk... any ideas how I should go about this? XFS dump > maybe? There is a link that I just added to the FAQ for cloning XFS systems. It is called "partition image" Maybe that will help. Cheers Seth From owner-linux-xfs@oss.sgi.com Fri Oct 5 12:49:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95JnIS16090 for linux-xfs-outgoing; Fri, 5 Oct 2001 12:49:18 -0700 Received: from sto-vo-kor.koschikode.com (sto-vo-kor.koschikode.com [195.124.129.42]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95JnED16071 for ; Fri, 5 Oct 2001 12:49:14 -0700 Received: from warp9.koschikode.com (pD95178D4.dip.t-dialin.net [217.81.120.212]) by sto-vo-kor.koschikode.com (Postfix) with ESMTP id 28B54F437; Fri, 5 Oct 2001 21:49:07 +0200 (CEST) Received: from koschikode.com (kaplah.koschikode.com [192.168.200.15]) by warp9.koschikode.com (Postfix) with ESMTP id 4BF5ACFB6; Fri, 5 Oct 2001 21:48:55 +0200 (CEST) Message-ID: <3BBE0EA7.B9BDE73B@koschikode.com> Date: Fri, 05 Oct 2001 21:48:55 +0200 From: Juri Haberland X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.10-ext3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Mike Sowka Cc: linux-xfs@oss.sgi.com Subject: Re: Cluster XFS install without CD... References: <3BBE0646.6050000@doe.carleton.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Mike Sowka wrote: > > Hello, > Ok... I realize I should RTFM but I was hoping someone could just point > me in the right direction. I've been working with XFS since it's 1.0 > release, needless to say ... IT ROCKS. Now that I've been put in charge > on building a computing cluster at school I'd like to use XFS for my > cluster nodes. So far...: > - I've intalled the main node with RH7.1 XFS-1.0.1 using the CD media > (got a boot disk as well ofcourse) > - and now I have no clue how to go about installing XFS RH7.1 base > systems that have NOTHING but a floppy dirve... :) I could install a > video card on each for the sake of install but other than that all I > have is the boot disk... any ideas how I should go about this? XFS dump > maybe? Hi Mike, I just did it today, it was pretty easy. You only have to have a NFS server from where you install with your floppy: On the NFS server create a directory where you copy all files from the first and second RedHat CDs to. After that, copy all files from the SGI CD over this directoy - overwrite as needed. Then create an install floppy disk from the bootnet.img file that you'll find in images/. Boot the machine that should be installed from this disk and follow the instructions for an install via NFS. That's it. Juri From owner-linux-xfs@oss.sgi.com Fri Oct 5 12:58:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95Jw4H16459 for linux-xfs-outgoing; Fri, 5 Oct 2001 12:58:04 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95JvvD16381 for ; Fri, 5 Oct 2001 12:57:57 -0700 Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sat, 6 Oct 2001 06:00:24 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10062001-060011-18.MMD@cymax.com.au; Sat, 6 Oct 2001 06:00:11 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sat Oct 6 05:53:40 2001) X-From_: owner-linux-xfs@oss.sgi.com Fri Oct 5 21:07:51 2001 Delivered-To: cymax@smartchat.net.au Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by entoo.connect.com.au (Postfix) with ESMTP id 169D4DD1F1 for ; Fri, 5 Oct 2001 21:07:51 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95B8qO02946; Fri, 5 Oct 2001 04:08:52 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 04:07:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95B7UK02858 for linux-xfs-outgoing; Fri, 5 Oct 2001 04:07:30 -0700 Received: from main.braxis.co.uk (root@main.braxis.co.uk [213.77.40.29]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95B7OD02839 for ; Fri, 5 Oct 2001 04:07:25 -0700 Received: (from kszysiu@localhost) by main.braxis.co.uk (8.11.6/8.11.6) id f95B7MA08018; Fri, 5 Oct 2001 13:07:22 +0200 Date: Fri, 5 Oct 2001 13:07:22 +0200 From: Krzysztof Rusocki To: linux-xfs@oss.sgi.com Cc: linux-kernel@vger.kernel.org Subject: %u-order allocation failed Message-ID: <20011005130722.A6570@main.braxis.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-OriginalArrivalTime: 05 Oct 2001 20:00:24.0828 (UTC) FILETIME=[5F2F13C0:01C14DD8] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, After simple bash fork bombing (about 200 forks) on my UP Celeron/96MB I get quite a lot %u-allocations failed, but only when swap is turned off. When it's turned on, processes are still forking for some time until i get messages like 'fork: Resource temporarily unavailable' or 'cannot redirect /dev/null: too many open files in system' (or similar) and also 'cannot load libdl.so blah blah return code 23' (don't remember exact message)... load goes up to about 700 but _none_ of processess get killed. Machine is almost unresponsible that time... i hardly managed to Alt+SysRQ+UB ... As mentioned in some other mail - no highmem, no lvm, md as module (unused). 2.4.10-xfs cvs co 25th September (not 12th :/ - info in previous mail was incorrect) When swap was off first i got some of 0-order (gfp=0x1d2/0) from c012ac08 (_alloc_pages+24) beside it, in a few seconds also noticed 0-order (gfp=0x1f0/0) from c012ac08 0-order (gfp=0xf0/0) from c012ac08 at random order.... I also saw a really small number of 1-order (gfp=0x1f0/0) from c012ac08 During that time almost all processess were killed by VM, machine was more responsible so i could freely do Alt+SysRQ+K and everything went back to normal... I'm not familiar with LinuxVM.. so... is it normal behaviour ? or (if not) what's happening when such messages are printed my kernel ? Cheers, Krzysztof PS lkml people - please CC, ain't subscribing. From owner-linux-xfs@oss.sgi.com Fri Oct 5 12:58:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95Jw7716480 for linux-xfs-outgoing; Fri, 5 Oct 2001 12:58:07 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95Jw1D16437 for ; Fri, 5 Oct 2001 12:58:01 -0700 Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sat, 6 Oct 2001 06:00:26 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10062001-060013-25.MMD@cymax.com.au; Sat, 6 Oct 2001 06:00:13 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sat Oct 6 05:53:42 2001) X-From_: owner-linux-xfs@oss.sgi.com Fri Oct 5 23:58:00 2001 Delivered-To: cymax@smartchat.net.au Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by entoo.connect.com.au (Postfix) with ESMTP id 82419DE638 for ; Fri, 5 Oct 2001 23:57:59 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95DwNd05656; Fri, 5 Oct 2001 06:58:24 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 06:56:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95Dumr05570 for linux-xfs-outgoing; Fri, 5 Oct 2001 06:56:48 -0700 Received: from hammail1.truenorth.com (h-213.61.138.102.host.de.colt.net [213.61.138.102]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95DuhD05551 for ; Fri, 5 Oct 2001 06:56:44 -0700 Received: from fcb-wilkens.com ([170.200.66.15]) by hammail1.truenorth.com (Netscape Messaging Server 4.15) with ESMTP id GKQK2A00.U4X for ; Fri, 5 Oct 2001 15:56:34 +0200 Message-ID: <3BBDBC11.550DF378@fcb-wilkens.com> Date: Fri, 05 Oct 2001 15:56:33 +0200 From: Harald Wagener Organization: FCB Wilkens X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: linux-xfs compatible with CML2/kbuild? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2001 20:00:26.0109 (UTC) FILETIME=[5FF28AD0:01C14DD8] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello list, just another question: I came to like the new kbuild Makefile and would like to check out cml2 as well. Does anyone have experience to share about this? Regards, Harald -- Harald Wagener | Systemadministrator FCB/Wilkens GmbH | Tel.:+49-40-2881-1252 An der Alster 42 | Fax.:+49-40-2881-1263 20099 Hamburg | http://www.fcb-wilkens.com From owner-linux-xfs@oss.sgi.com Fri Oct 5 12:58:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95Jw7N16488 for linux-xfs-outgoing; Fri, 5 Oct 2001 12:58:07 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95JvxD16416 for ; Fri, 5 Oct 2001 12:57:59 -0700 Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sat, 6 Oct 2001 06:00:25 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10062001-060012-21.MMD@cymax.com.au; Sat, 6 Oct 2001 06:00:12 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sat Oct 6 05:53:40 2001) X-From_: owner-linux-xfs@oss.sgi.com Fri Oct 5 21:59:17 2001 Delivered-To: cymax@smartchat.net.au Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by entoo.connect.com.au (Postfix) with ESMTP id A9454DE739 for ; Fri, 5 Oct 2001 21:59:16 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95C03x03522; Fri, 5 Oct 2001 05:00:03 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 04:59:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95Bxgu03407 for linux-xfs-outgoing; Fri, 5 Oct 2001 04:59:42 -0700 Received: from netbank.com.br (IDENT:postfix@garrincha.netbank.com.br [200.203.199.88]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95BxZD03387 for ; Fri, 5 Oct 2001 04:59:37 -0700 Received: from 1-102.ctame701-1.telepar.net.br (1-102.ctame701-1.telepar.net.br [200.181.137.102]) by netbank.com.br (Postfix) with ESMTP id E044646819; Fri, 5 Oct 2001 08:58:56 -0300 (BRST) Received: (from localhost user: 'riel', uid#500) by imladris.surriel.com with ESMTP id ; Fri, 5 Oct 2001 08:59:20 -0300 Date: Fri, 5 Oct 2001 08:59:19 -0300 (BRST) From: Rik van Riel X-X-Sender: To: Krzysztof Rusocki Cc: , Subject: Re: %u-order allocation failed In-Reply-To: <20011005130722.A6570@main.braxis.co.uk> Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 05 Oct 2001 20:00:25.0250 (UTC) FILETIME=[5F6F7820:01C14DD8] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 5 Oct 2001, Krzysztof Rusocki wrote: > After simple bash fork bombing (about 200 forks) on my UP Celeron/96MB > I get quite a lot %u-allocations failed, but only when swap is turned > off. > I'm not familiar with LinuxVM.. so... is it normal behaviour ? or (if not) > what's happening when such messages are printed my kernel ? This is perfectly normal behaviour: 1) on your system, you have no process limit configured for yourself so you can start processes until all resources (memory, file descriptors, ...) are used 2) when all processes are used, there really is no way the kernel can buy you more hardware on ebay and install it on the fly ... all it can do is start failing allocations On production systems, good admins setup per-user limits for the various resources so no single user is able to run the system into the ground. regards, Rik -- DMCA, SSSCA, W3C? Who cares? http://thefreeworld.net/ (volunteers needed) http://www.surriel.com/ http://distro.conectiva.com/ From owner-linux-xfs@oss.sgi.com Fri Oct 5 12:58:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95Jw9F16526 for linux-xfs-outgoing; Fri, 5 Oct 2001 12:58:09 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95JvwD16397 for ; Fri, 5 Oct 2001 12:57:58 -0700 Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sat, 6 Oct 2001 06:00:25 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10062001-060012-22.MMD@cymax.com.au; Sat, 6 Oct 2001 06:00:12 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sat Oct 6 05:53:41 2001) X-From_: owner-linux-xfs@oss.sgi.com Fri Oct 5 22:27:19 2001 Delivered-To: cymax@smartchat.net.au Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by entoo.connect.com.au (Postfix) with ESMTP id 5B231DD353 for ; Fri, 5 Oct 2001 22:27:18 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95CRi703964; Fri, 5 Oct 2001 05:27:44 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 05:27:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95CR7R03881 for linux-xfs-outgoing; Fri, 5 Oct 2001 05:27:07 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95CQxD03862 for ; Fri, 5 Oct 2001 05:27:00 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 3EA28C00B62; Fri, 5 Oct 2001 20:26:56 +0800 (PHT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 17421C00B60; Fri, 5 Oct 2001 20:26:55 +0800 (PHT) Date: Fri, 5 Oct 2001 20:26:55 +0800 (PHT) From: Federico Sevilla III To: Linux XFS Mailing List Cc: Vishal Agarwal Subject: XFS & ReiserFS (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 X-OriginalArrivalTime: 05 Oct 2001 20:00:25.0515 (UTC) FILETIME=[5F97E7B0:01C14DD8] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Fellow XFS users, At the bottom of this email you will find a forwarded message from Vishal Agarwal. I got this in the ReiserFS mailing list and thought maybe someone here has nice answers for this fellow. In particular as of writing nobody in the ReiserFS list has replied. Vishal, maybe you'd be interested in helping out with something in the XFS todo list? There's a lot that can be given thought to help unload Steve Lord and the other SGI folks. I can't quite remember where that todo list is, but I'm sure it's somewhere in the XFS site. As to benchmarks, you can find a number. In particular the ReiserFS website has at least one using Reiser's mongo.pl benchmark tool. It's a little outdated as that's as of kernel 2.4.5 and we're now up to 2.4.11-pre3. XFS is significantly slow with massive deletes of small files (maybe you can help tweak this? I'm sure the XFS developers would love to give you starting tips if you're willing to do so), but otherwise you will see that it's performance is good especially as file size increases. Hoping you will help develop what has become my filesystem of choice. --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: ---------- Forwarded message ---------- Date: Thu, 4 Oct 2001 19:04:28 +0530 From: Vishal Agarwal To: "reiserfs-list@namesys.com" Subject: [reiserfs-list] XFS & ReiserFS Hi, I'm a final year student, doing my masters in computer science from Bombay University, India. I'm doing my industrial training at Persistent Systems Pvt. Ltd. (persistent.co.in), and the platforms I work on are IRIX and C/Objective C (and X/motif sometimes). I wonder if I could contribute towards the development of any module of ReiserFS. I have a good experience in C, though I hardly know C++ and I'm currently honing my objective C skills. I have the following queries: 1. I want to know what are the major design differences between XFS (from SGI) and ReiserFS? 2. Where are the design documentation kept for ReiserFS? XFS has a VERY good set of documents for each module in PDF format on SGI's site. 3. Are there any comparision results availbale between XFS and ReiserFS? Thanks, waiting for your reply. Best Regards, -Vishal Agarwal P.S. I'm sorry for sending the same mail to hans previously. From owner-linux-xfs@oss.sgi.com Fri Oct 5 12:58:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95JwYG16640 for linux-xfs-outgoing; Fri, 5 Oct 2001 12:58:34 -0700 Received: from burgers (IDENT:postfix@burgers.bubbanfriends.org [216.140.122.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95JwUD16616 for ; Fri, 5 Oct 2001 12:58:30 -0700 Received: by burgers (Postfix, from userid 500) id EADAB4001C1; Fri, 5 Oct 2001 15:58:29 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by burgers (Postfix) with ESMTP id E94C72400080; Fri, 5 Oct 2001 15:58:29 -0400 (EDT) Date: Fri, 5 Oct 2001 15:58:29 -0400 (EDT) From: Mike Burger To: Juri Haberland Cc: Mike Sowka , Subject: Re: Cluster XFS install without CD... In-Reply-To: <3BBE0EA7.B9BDE73B@koschikode.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 5 Oct 2001, Juri Haberland wrote: > Mike Sowka wrote: > > > > Hello, > > Ok... I realize I should RTFM but I was hoping someone could just point > > me in the right direction. I've been working with XFS since it's 1.0 > > release, needless to say ... IT ROCKS. Now that I've been put in charge > > on building a computing cluster at school I'd like to use XFS for my > > cluster nodes. So far...: > > - I've intalled the main node with RH7.1 XFS-1.0.1 using the CD media > > (got a boot disk as well ofcourse) > > - and now I have no clue how to go about installing XFS RH7.1 base > > systems that have NOTHING but a floppy dirve... :) I could install a > > video card on each for the sake of install but other than that all I > > have is the boot disk... any ideas how I should go about this? XFS dump > > maybe? > > Hi Mike, > > I just did it today, it was pretty easy. You only have to have a NFS > server from where you install with your floppy: > On the NFS server create a directory where you copy all files from the > first and second RedHat CDs to. After that, copy all files from the SGI > CD over this directoy - overwrite as needed. > Then create an install floppy disk from the bootnet.img file that you'll > find in images/. > > Boot the machine that should be installed from this disk and follow the > instructions for an install via NFS. > That's it. I don't think that's what he wants to do. He basically wants the other systems to have no hard drive...instead, he wants them to run off of the first system. From owner-linux-xfs@oss.sgi.com Fri Oct 5 12:59:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95JxX017069 for linux-xfs-outgoing; Fri, 5 Oct 2001 12:59:33 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95JxTD17024 for ; Fri, 5 Oct 2001 12:59:29 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA09099 for ; Fri, 5 Oct 2001 12:59:47 -0700 (PDT) mail_from (lord@sgi.com) Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sat, 6 Oct 2001 06:00:26 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10062001-060014-27.MMD@cymax.com.au; Sat, 6 Oct 2001 06:00:14 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sat Oct 6 05:53:42 2001) X-From_: owner-linux-xfs@oss.sgi.com Sat Oct 6 00:12:57 2001 Delivered-To: cymax@smartchat.net.au Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by entoo.connect.com.au (Postfix) with ESMTP id EBAB7DDE25 for ; Sat, 6 Oct 2001 00:12:56 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95EDjR06050; Fri, 5 Oct 2001 07:13:45 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 07:13:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95EDXT05970 for linux-xfs-outgoing; Fri, 5 Oct 2001 07:13:33 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95EDUD05951 for ; Fri, 5 Oct 2001 07:13:30 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f95EDPK07535 for ; Fri, 5 Oct 2001 07:13:25 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA3152753; Fri, 5 Oct 2001 09:12:08 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA28456; Fri, 5 Oct 2001 09:12:08 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f95EBdS12766; Fri, 5 Oct 2001 09:11:39 -0500 Message-Id: <200110051411.f95EBdS12766@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Harald Wagener Cc: linux-xfs@oss.sgi.com Subject: Re: linux-xfs compatible with CML2/kbuild? In-Reply-To: Message from Harald Wagener of "Fri, 05 Oct 2001 15:56:33 +0200." <3BBDBC11.550DF378@fcb-wilkens.com> Date: Fri, 05 Oct 2001 09:11:39 -0500 From: Steve Lord X-OriginalArrivalTime: 05 Oct 2001 20:00:26.0328 (UTC) FILETIME=[6013F580:01C14DD8] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hello list, > > just another question: I came to like the new kbuild Makefile and would like > to > check out cml2 as well. Does anyone have experience to share about this? > > Regards, > Harald > -- > Harald Wagener | Systemadministrator > FCB/Wilkens GmbH | Tel.:+49-40-2881-1252 > An der Alster 42 | Fax.:+49-40-2881-1263 > 20099 Hamburg | http://www.fcb-wilkens.com I Keith Owens is still up he can tell you the real details, but the basic answer should be yes. Keith has been putting kbuild compatibility stuff into the XFS cvs tree. Steve From owner-linux-xfs@oss.sgi.com Fri Oct 5 12:59:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95JxxX17180 for linux-xfs-outgoing; Fri, 5 Oct 2001 12:59:59 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95JxnD17145 for ; Fri, 5 Oct 2001 12:59:49 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAB03500 for ; Fri, 5 Oct 2001 12:59:59 -0700 (PDT) mail_from (kaos@melbourne.sgi.com) Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sat, 6 Oct 2001 06:00:27 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10062001-060015-33.MMD@cymax.com.au; Sat, 6 Oct 2001 06:00:15 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sat Oct 6 05:53:44 2001) X-From_: owner-linux-xfs@oss.sgi.com Sat Oct 6 02:46:08 2001 Delivered-To: cymax@smartchat.net.au Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by entoo.connect.com.au (Postfix) with ESMTP id BC97DDE6AE for ; Sat, 6 Oct 2001 02:46:07 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95GlC510237; Fri, 5 Oct 2001 09:47:12 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 09:45:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95Gjxd10146 for linux-xfs-outgoing; Fri, 5 Oct 2001 09:45:59 -0700 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95GjtD10127 for ; Fri, 5 Oct 2001 09:45:56 -0700 Received: (qmail 32382 invoked from network); 5 Oct 2001 16:45:53 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 5 Oct 2001 16:45:53 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id E46B33000B7; Sat, 6 Oct 2001 02:45:50 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id CA9939A; Sat, 6 Oct 2001 02:45:50 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Harald Wagener Cc: linux-xfs@oss.sgi.com Subject: Re: linux-xfs compatible with CML2/kbuild? In-reply-to: Your message of "Fri, 05 Oct 2001 15:56:33 +0200." <3BBDBC11.550DF378@fcb-wilkens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 06 Oct 2001 02:45:45 +1000 Message-ID: <10221.1002300345@ocs3.intra.ocs.com.au> X-OriginalArrivalTime: 05 Oct 2001 20:00:27.0078 (UTC) FILETIME=[60866660:01C14DD8] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 05 Oct 2001 15:56:33 +0200, Harald Wagener wrote: >just another question: I came to like the new kbuild Makefile and would like to >check out cml2 as well. Does anyone have experience to share about this? The XFS tree is already kbuild 2.5 ready. Just apply the kbuild-2.5-2.4.10 patch and enjoy. AFAIK there is no CML2 support for XFS yet, just CML1. From owner-linux-xfs@oss.sgi.com Fri Oct 5 13:00:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95K0FI17287 for linux-xfs-outgoing; Fri, 5 Oct 2001 13:00:15 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95K02D17247 for ; Fri, 5 Oct 2001 13:00:02 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA05032 for ; Fri, 5 Oct 2001 13:00:11 -0700 (PDT) mail_from (kaos@melbourne.sgi.com) Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sat, 6 Oct 2001 06:00:27 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10062001-060015-35.MMD@cymax.com.au; Sat, 6 Oct 2001 06:00:15 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sat Oct 6 05:53:44 2001) X-From_: owner-linux-xfs@oss.sgi.com Sat Oct 6 02:51:49 2001 Delivered-To: cymax@smartchat.net.au Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by entoo.connect.com.au (Postfix) with ESMTP id 0A529DFBC0 for ; Sat, 6 Oct 2001 02:51:49 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95GqZA10439; Fri, 5 Oct 2001 09:52:35 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 09:52:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95GqTZ10359 for linux-xfs-outgoing; Fri, 5 Oct 2001 09:52:29 -0700 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95GqJD10340 for ; Fri, 5 Oct 2001 09:52:20 -0700 Received: (qmail 32473 invoked from network); 5 Oct 2001 16:52:17 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 5 Oct 2001 16:52:17 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 90D833000B7; Sat, 6 Oct 2001 02:52:16 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 7A8919A; Sat, 6 Oct 2001 02:52:16 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Harald Wagener Cc: linux-xfs@oss.sgi.com Subject: Re: linux-xfs compatible with CML2/kbuild? In-reply-to: Your message of "Sat, 06 Oct 2001 02:45:45 +1000." <10221.1002300345@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 06 Oct 2001 02:52:11 +1000 Message-ID: <10342.1002300731@ocs3.intra.ocs.com.au> X-OriginalArrivalTime: 05 Oct 2001 20:00:27.0343 (UTC) FILETIME=[60AED5F0:01C14DD8] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 06 Oct 2001 02:45:45 +1000, Keith Owens wrote: >On Fri, 05 Oct 2001 15:56:33 +0200, >Harald Wagener wrote: >>just another question: I came to like the new kbuild Makefile and would like to >>check out cml2 as well. Does anyone have experience to share about this? > >The XFS tree is already kbuild 2.5 ready. Just apply the >kbuild-2.5-2.4.10 patch and enjoy. AFAIK there is no CML2 support for >XFS yet, just CML1. Note to self - avoid sending mail at 2:45 AM. The real story is :- Date: Sun, 5 Aug 2001 21:53:28 +1000 From: Keith Owens Subject: TAKE - kbuild 2.5 support for XFS Add XFS specific files for kbuild 2.5 support to the XFS tree. This is not the full kbuild 2.5 code, just the XFS and KDB specific bits. Using kbuild 2.5 with the current XFS tree is a little unusual because it must not disturb the existing kbuild 2.4 code, XFS must still build using the old method. To build XFS using kbuild 2.5 you need 3 directories, source tree 000 containing the main kbuild 2.5 code, source tree 001 containing XFS, KDB plus the full kernel and an object tree. This is not the normal configuration but it works without including all of kbuild 2.5 in the XFS tree. Create a file which sets and exports the required variables, replacing /build/kaos with your build area, and source that file to set the variables. Note that source tree 001 is the linux sub directory of your XFS workarea or CVS tree, do not point at the top of the workarea or CVS tree. # cat trees-2.4.x-xfs export KBUILD_SRCTREE_000=/build/kaos/2.4.x-xfs-kbuild-2.5 export KBUILD_SRCTREE_001=/build/kaos/2.4.x-xfs/linux export KBUILD_OBJTREE=/build/kaos/object-2.4.x-xfs # source trees-2.4.x-xfs Remove any files in the main kbuild 2.5 tree and the object tree. Create the object tree and copy in an initial config. # rm -rf $KBUILD_SRCTREE_000 $KBUILD_OBJTREE # mkdir $KBUILD_OBJTREE # cp .config $KBUILD_OBJTREE Fetch the kbuild 2.5 patch that corresponds to the current XFS kernel from http://sourceforge.net/projects/kbuild/. This was tested on kbuild-2.5-2.4.8-pre4-1.gz. kbuild 2.5 is designed to patch a current kernel but we want a separate tree containing just the kbuild 2.5 code plus the critical files that kbuild 2.5 needs, leaving the XFS tree untouched. # cp -al $KBUILD_SRCTREE_001 $KBUILD_SRCTREE_000 # cd $KBUILD_SRCTREE_000 # zcat ~/kbuild-2.5-2.4.8-pre4-1.gz | patch -p1 # find \( -path ./scripts -prune \) -o \( -type f -links +1 \! -name Makefile -print \) | xargs rm # find -type d -depth | xargs rmdir 2>/dev/null That leaves source tree 000 containing just the main kbuild 2.5 files plus the scripts (for make *config) and the kbuild 2.4 top level Makefile (for kernel version). You can now build XFS+KDB using kbuild 2.5. On a 4 way processor with plenty of memory, I do this # make -j8 -f $KBUILD_SRCTREE_000/Makefile-2.5 oldconfig installable # sudo make -j8 -f $KBUILD_SRCTREE_000/Makefile-2.5 install The only disadvantage with this approach is that the configure help is read from the XFS tree so you do not get help for the kbuild 2.5 specific options. Can't have everything. You can browse $KBUILD_SRCTREE_000/Documentation/Configure.help for the kbuild 2.5 entries. As always, Documentation/kbuild/kbuild-2.5.txt is your friend. Enjoy. From owner-linux-xfs@oss.sgi.com Fri Oct 5 13:11:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95KBJe18069 for linux-xfs-outgoing; Fri, 5 Oct 2001 13:11:19 -0700 Received: from sto-vo-kor.koschikode.com (sto-vo-kor.koschikode.com [195.124.129.42]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95KBCD18046 for ; Fri, 5 Oct 2001 13:11:13 -0700 Received: from warp9.koschikode.com (pD95178D4.dip.t-dialin.net [217.81.120.212]) by sto-vo-kor.koschikode.com (Postfix) with ESMTP id 04282F437; Fri, 5 Oct 2001 22:11:06 +0200 (CEST) Received: from koschikode.com (kaplah.koschikode.com [192.168.200.15]) by warp9.koschikode.com (Postfix) with ESMTP id 0F00FCFB6; Fri, 5 Oct 2001 22:10:54 +0200 (CEST) Message-ID: <3BBE13CE.E6992BC4@koschikode.com> Date: Fri, 05 Oct 2001 22:10:54 +0200 From: Juri Haberland X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.10-ext3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Mike Burger Cc: Mike Sowka , linux-xfs@oss.sgi.com Subject: Re: Cluster XFS install without CD... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Mike Burger wrote: > > On Fri, 5 Oct 2001, Juri Haberland wrote: > > > Mike Sowka wrote: > > > > > > Hello, > > > Ok... I realize I should RTFM but I was hoping someone could just point > > > me in the right direction. I've been working with XFS since it's 1.0 > > > release, needless to say ... IT ROCKS. Now that I've been put in charge > > > on building a computing cluster at school I'd like to use XFS for my > > > cluster nodes. So far...: > > > - I've intalled the main node with RH7.1 XFS-1.0.1 using the CD media > > > (got a boot disk as well ofcourse) > > > - and now I have no clue how to go about installing XFS RH7.1 base > > > systems that have NOTHING but a floppy dirve... :) I could install a > > > video card on each for the sake of install but other than that all I > > > have is the boot disk... any ideas how I should go about this? XFS dump > > > maybe? > > > > Hi Mike, > > > > I just did it today, it was pretty easy. You only have to have a NFS > > server from where you install with your floppy: > > On the NFS server create a directory where you copy all files from the > > first and second RedHat CDs to. After that, copy all files from the SGI > > CD over this directoy - overwrite as needed. > > Then create an install floppy disk from the bootnet.img file that you'll > > find in images/. > > > > Boot the machine that should be installed from this disk and follow the > > instructions for an install via NFS. > > That's it. > > I don't think that's what he wants to do. He basically wants the other > systems to have no hard drive...instead, he wants them to run off of the > first system. Ahh, should read more carefully... Thanks, Juri From owner-linux-xfs@oss.sgi.com Fri Oct 5 13:18:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95KIsB18349 for linux-xfs-outgoing; Fri, 5 Oct 2001 13:18:54 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95KInD18329 for ; Fri, 5 Oct 2001 13:18:49 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id WAA07639; Fri, 5 Oct 2001 22:18:40 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id WAA03806; Fri, 5 Oct 2001 22:18:40 +0200 (CEST) Date: Fri, 5 Oct 2001 22:18:39 +0200 (CEST) From: Seth Mos To: Rik van Riel cc: Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: %u-order allocation failed In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 5 Oct 2001, Rik van Riel wrote: > On Fri, 5 Oct 2001, Krzysztof Rusocki wrote: > > > After simple bash fork bombing (about 200 forks) on my UP Celeron/96MB > > I get quite a lot %u-allocations failed, but only when swap is turned > > off. > > > I'm not familiar with LinuxVM.. so... is it normal behaviour ? or (if not) > > what's happening when such messages are printed my kernel ? > > This is perfectly normal behaviour: > > 1) on your system, you have no process limit configured for > yourself so you can start processes until all resources > (memory, file descriptors, ...) are used Fair enough. > 2) when all processes are used, there really is no way the > kernel can buy you more hardware on ebay and install it > on the fly ... all it can do is start failing allocations So it needs a handbrake in case of a emergency? The box at work deadlocks or crashes. I can hardly call that normal operational behaviour. I have a Dell PE 2500 (Serverworks LE) with 2GB ram and 2 1.13Ghz processors. If I disable HIGHMEM (4GB) support the box does not produce these allocations messages and does not deadlock or die under the same load or worse. What I used was a mongo.pl with 5 processes (does not matter if the fs is ext2 reiserfs or xfs) and the box dies within minutes/seconds after starting the benchmark. This happens using either 2.4.10-xfs or 2.4.11-pre3-xfs. Using a single process hides the issue. > On production systems, good admins setup per-user limits for > the various resources so no single user is able to run the > system into the ground. The system is beafy enough to tolerate something mundane as this. It should definitely not die. Cheers Seth From owner-linux-xfs@oss.sgi.com Fri Oct 5 13:23:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95KN9Q18540 for linux-xfs-outgoing; Fri, 5 Oct 2001 13:23:09 -0700 Received: from perninha.conectiva.com.br (perninha.conectiva.com.br [200.250.58.156]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95KN3D18519 for ; Fri, 5 Oct 2001 13:23:04 -0700 Received: from burns.conectiva (burns.conectiva [10.0.0.4]) by perninha.conectiva.com.br (Postfix) with SMTP id 409803996A for ; Fri, 5 Oct 2001 17:22:53 -0300 (EST) Received: (qmail 2321 invoked by uid 0); 5 Oct 2001 20:20:48 -0000 Received: from duckman.distro.conectiva (root@10.0.17.2) by burns.conectiva with SMTP; 5 Oct 2001 20:20:48 -0000 Received: (from localhost user: 'riel', uid#500) by duckman.distro.conectiva with ESMTP id ; Fri, 5 Oct 2001 17:22:40 -0300 Date: Fri, 5 Oct 2001 17:22:40 -0300 (BRST) From: Rik van Riel X-X-Sender: To: Seth Mos Cc: Krzysztof Rusocki , , Subject: Re: %u-order allocation failed In-Reply-To: Message-ID: X-supervisor: aardvark@nl.linux.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 5 Oct 2001, Seth Mos wrote: > This happens using either 2.4.10-xfs or 2.4.11-pre3-xfs. Ohh duh, IIRC there are a bunch of highmem bugs in -linus which are fixed in -ac. Can you reproduce the bug with an -ac kernel ? regards, Rik -- DMCA, SSSCA, W3C? Who cares? http://thefreeworld.net/ (volunteers needed) http://www.surriel.com/ http://distro.conectiva.com/ From owner-linux-xfs@oss.sgi.com Fri Oct 5 13:29:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95KTVe18772 for linux-xfs-outgoing; Fri, 5 Oct 2001 13:29:31 -0700 Received: from borg-cube.no-ip.com (IDENT:root@adsl-45637.turboline.skynet.be [217.136.50.69]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95KTND18752 for ; Fri, 5 Oct 2001 13:29:24 -0700 Received: from skynet.be (IDENT:kris@borg-cube.no-ip.com [127.0.0.1]) by borg-cube.no-ip.com (8.11.2/8.11.2) with ESMTP id f95KMsK02127 for ; Fri, 5 Oct 2001 22:22:54 +0200 Message-ID: <3BBE169E.DC625209@skynet.be> Date: Fri, 05 Oct 2001 22:22:54 +0200 From: kris buggenhout X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.10-pre10-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-xfs@oss.sgi.com" Subject: [Fwd: Cluster XFS install without CD...] Content-Type: multipart/mixed; boundary="------------DFAA89D6F50E546A0D24DF55" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------DFAA89D6F50E546A0D24DF55 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------DFAA89D6F50E546A0D24DF55 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mozilla-Status2: 00000000 Message-ID: <3BBE1686.F3DD2C8@skynet.be> Date: Fri, 05 Oct 2001 22:22:30 +0200 From: kris buggenhout X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.10-pre10-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Juri Haberland Subject: Re: Cluster XFS install without CD... References: <3BBE13CE.E6992BC4@koschikode.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Juri Haberland wrote: > Mike Burger wrote: > > > > On Fri, 5 Oct 2001, Juri Haberland wrote: > > > > > Mike Sowka wrote: > > > > > > > > Hello, > > > > Ok... I realize I should RTFM but I was hoping someone could just point > > > > me in the right direction. I've been working with XFS since it's 1.0 > > > > release, needless to say ... IT ROCKS. Now that I've been put in charge > > > > on building a computing cluster at school I'd like to use XFS for my > > > > cluster nodes. So far...: > > > > - I've intalled the main node with RH7.1 XFS-1.0.1 using the CD media > > > > (got a boot disk as well ofcourse) > > > > - and now I have no clue how to go about installing XFS RH7.1 base > > > > systems that have NOTHING but a floppy dirve... :) I could install a > > > > video card on each for the sake of install but other than that all I > > > > have is the boot disk... any ideas how I should go about this? XFS dump > > > > maybe? > > > > > > Hi Mike, > > > > > > I just did it today, it was pretty easy. You only have to have a NFS > > > server from where you install with your floppy: > > > On the NFS server create a directory where you copy all files from the > > > first and second RedHat CDs to. After that, copy all files from the SGI > > > CD over this directoy - overwrite as needed. > > > Then create an install floppy disk from the bootnet.img file that you'll > > > find in images/. > > > > > > Boot the machine that should be installed from this disk and follow the > > > instructions for an install via NFS. > > > That's it. > > > > I don't think that's what he wants to do. He basically wants the other > > systems to have no hard drive...instead, he wants them to run off of the > > first system. > > Ahh, should read more carefully... > > Thanks, > Juri Think U have to take a look at the diskless client ... http://www.ltsp.org/ --------------DFAA89D6F50E546A0D24DF55-- From owner-linux-xfs@oss.sgi.com Fri Oct 5 13:31:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95KVoW18951 for linux-xfs-outgoing; Fri, 5 Oct 2001 13:31:50 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95KVlD18931 for ; Fri, 5 Oct 2001 13:31:47 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id WAA15741; Fri, 5 Oct 2001 22:31:39 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id WAA06251; Fri, 5 Oct 2001 22:31:38 +0200 (CEST) Date: Fri, 5 Oct 2001 22:31:38 +0200 (CEST) From: Seth Mos To: Rik van Riel cc: Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: %u-order allocation failed In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 5 Oct 2001, Rik van Riel wrote: > On Fri, 5 Oct 2001, Seth Mos wrote: > > > This happens using either 2.4.10-xfs or 2.4.11-pre3-xfs. > > Ohh duh, IIRC there are a bunch of highmem bugs in > -linus which are fixed in -ac. Fitting XFS onto a -ac kernel should be fun :-( I will try this over the weekend or get a redhat kernel going which is also -ac based. That would come in handy for other people using XFS since a lot are using highmem in combination with this fs. > Can you reproduce the bug with an -ac kernel ? I am not that good/fast at patching. Expect something over the weekend :-) Bye Seth From owner-linux-xfs@oss.sgi.com Fri Oct 5 13:34:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95KYsL19164 for linux-xfs-outgoing; Fri, 5 Oct 2001 13:34:54 -0700 Received: from borg-cube.no-ip.com (IDENT:root@adsl-45637.turboline.skynet.be [217.136.50.69]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95KYnD19143 for ; Fri, 5 Oct 2001 13:34:49 -0700 Received: from skynet.be (IDENT:kris@borg-cube.no-ip.com [127.0.0.1]) by borg-cube.no-ip.com (8.11.2/8.11.2) with ESMTP id f95KSGK02139; Fri, 5 Oct 2001 22:28:16 +0200 Message-ID: <3BBE17E0.6167B4E7@skynet.be> Date: Fri, 05 Oct 2001 22:28:16 +0200 From: kris buggenhout X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.10-pre10-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Juri Haberland , "linux-xfs@oss.sgi.com" Subject: Re: Cluster XFS install without CD... References: <3BBE0646.6050000@doe.carleton.ca> <3BBE0EA7.B9BDE73B@koschikode.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Juri Haberland wrote: > Mike Sowka wrote: > > > > Hello, > > Ok... I realize I should RTFM but I was hoping someone could just point > > me in the right direction. I've been working with XFS since it's 1.0 > > release, needless to say ... IT ROCKS. Now that I've been put in charge > > on building a computing cluster at school I'd like to use XFS for my > > cluster nodes. So far...: > > - I've intalled the main node with RH7.1 XFS-1.0.1 using the CD media > > (got a boot disk as well ofcourse) > > - and now I have no clue how to go about installing XFS RH7.1 base > > systems that have NOTHING but a floppy dirve... :) I could install a > > video card on each for the sake of install but other than that all I > > have is the boot disk... any ideas how I should go about this? XFS dump > > maybe? > > Hi Mike, > > I just did it today, it was pretty easy. You only have to have a NFS > server from where you install with your floppy: > On the NFS server create a directory where you copy all files from the > first and second RedHat CDs to. After that, copy all files from the SGI > CD over this directoy - overwrite as needed. > Then create an install floppy disk from the bootnet.img file that you'll > find in images/. > > Boot the machine that should be installed from this disk and follow the > instructions for an install via NFS. > That's it. > > Juri linux terminal server project :http://www.ltsp.org/ or : http://ClusterNFS.sourceforge.net/ or : http://netboot.sourceforge.net/english/index.shtml additionally look at : http://www.solucorp.qc.ca/xterminals/ SQN Linux From owner-linux-xfs@oss.sgi.com Fri Oct 5 13:40:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95Keg719419 for linux-xfs-outgoing; Fri, 5 Oct 2001 13:40:42 -0700 Received: from moutvdom01.kundenserver.de (moutvdom01.kundenserver.de [195.20.224.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95KebD19399 for ; Fri, 5 Oct 2001 13:40:37 -0700 Received: from [195.20.224.219] (helo=mrvdom03.schlund.de) by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #2) id 15pblr-0000rp-00; Fri, 5 Oct 2001 22:40:35 +0200 Received: from pd958d002.dip.t-dialin.net ([217.88.208.2] helo=kernelpanix.aura.of.mankind) by mrvdom03.schlund.de with esmtp (Exim 2.12 #2) id 15pblr-00026i-00; Fri, 5 Oct 2001 22:40:35 +0200 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.11.2/8.11.2) id f95KeYo21856; Fri, 5 Oct 2001 22:40:34 +0200 X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f Date: Fri, 5 Oct 2001 22:40:34 +0200 From: utz lehmann To: Seth Mos Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.11-pre2-xfs Message-ID: <20011005224034.A21589@s2y4n2c.de> References: <3BBE04A0.64D2A0BA@soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Seth Seth Mos [knuffie@xs4all.nl] wrote: > The dell PE 2500 is ServerWorks LE based, 2GB ram with both 2.4.10 and > 2.4.11-pre3. > > The only way to fix it is not using HIGHMEM. As soon as I compile without > HIGHMEM (4GB) the box is stable and does not deadlock or crash even under > heavy load. I have about a month before the system must go into production > so if anyone has some hints or tests I could do they are most welcome. > > I can not get it over my heart to tell that we cannot use half the > memory available. There goes my reputation :-/ Maybe I have a solution for you (and others). I found a patch (linux-2.4.2-vm-1-2-3-gbyte.patch) in the redhat kernel src rpm. It allow you to change the standard vm user/kernel split of 3/1 GB to 2/2 and 1/3 GB. Without a HIGHMEM kernel your max available memory is kernel spilt size - 128MB. 896MB default, and 1920 or 2944MB with the patch. At work we have athlon based CAE workstations and numbercruncher with 1GB or 1.5GB RAM. They running 2.4.7 or 2.4.9 linux-xfs kernels (of course .-) with this patch. I modified the patch to 2.75/1.25 resp. 2.25/1.75GB. So they can use all their memory without HIGHMEM. Advantages are no performance loss due HIGHMEM and *NO* HIGHMEM trouble. Disadvantage is that the possible userspace size per process is reduced. If you don't have big processes it won't be a problem. I saw >1GB sized processes with the 2.25/1.75GB split. hope that helps. utz From owner-linux-xfs@oss.sgi.com Fri Oct 5 13:45:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95KjHh19657 for linux-xfs-outgoing; Fri, 5 Oct 2001 13:45:17 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95KjED19638 for ; Fri, 5 Oct 2001 13:45:14 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA27715 for ; Fri, 5 Oct 2001 13:45:11 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA3155819; Fri, 5 Oct 2001 15:43:48 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA24720; Fri, 5 Oct 2001 15:43:47 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f95KhG307514; Fri, 5 Oct 2001 15:43:16 -0500 Message-Id: <200110052043.f95KhG307514@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Seth Mos cc: Rik van Riel , Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: %u-order allocation failed In-Reply-To: Message from Seth Mos of "Fri, 05 Oct 2001 22:31:38 +0200." Date: Fri, 05 Oct 2001 15:43:16 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Fri, 5 Oct 2001, Rik van Riel wrote: > > > On Fri, 5 Oct 2001, Seth Mos wrote: > > > > > This happens using either 2.4.10-xfs or 2.4.11-pre3-xfs. > > > > Ohh duh, IIRC there are a bunch of highmem bugs in > > -linus which are fixed in -ac. > > Fitting XFS onto a -ac kernel should be fun :-( Its not that that simple - I tried before I got dragged kicking and screaming back into some Irix stuff. Just running mongo on ext2 on a HIGHMEM ac kernel should show if things are better there - since the problems seem to be fairly filesystem independent. Steve > > I will try this over the weekend or get a redhat kernel going which is > also -ac based. That would come in handy for other people using XFS since > a lot are using highmem in combination with this fs. > > > Can you reproduce the bug with an -ac kernel ? > > I am not that good/fast at patching. Expect something over the weekend :-) > > Bye > Seth From owner-linux-xfs@oss.sgi.com Fri Oct 5 13:57:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95Kv3m20047 for linux-xfs-outgoing; Fri, 5 Oct 2001 13:57:03 -0700 Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95KuuD20027 for ; Fri, 5 Oct 2001 13:56:58 -0700 Received: from [195.20.224.220] (helo=mrvdom04.kundenserver.de) by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 15pc1b-0000Rd-00; Fri, 5 Oct 2001 22:56:51 +0200 Received: from pd958d002.dip.t-dialin.net ([217.88.208.2] helo=kernelpanix.aura.of.mankind) by mrvdom04.kundenserver.de with esmtp (Exim 2.12 #2) id 15pc1b-0003PM-00; Fri, 5 Oct 2001 22:56:51 +0200 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.11.2/8.11.2) id f95KuoQ22058; Fri, 5 Oct 2001 22:56:50 +0200 X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f Date: Fri, 5 Oct 2001 22:56:50 +0200 From: utz lehmann To: Seth Mos Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.11-pre2-xfs Message-ID: <20011005225650.A22036@s2y4n2c.de> References: <3BBE04A0.64D2A0BA@soton.ac.uk> <20011005224034.A21589@s2y4n2c.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011005224034.A21589@s2y4n2c.de> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk utz lehmann [xfs@s2y4n2c.de] wrote: > Hi Seth > > Seth Mos [knuffie@xs4all.nl] wrote: > > The dell PE 2500 is ServerWorks LE based, 2GB ram with both 2.4.10 and > > 2.4.11-pre3. > > > > The only way to fix it is not using HIGHMEM. As soon as I compile without > > HIGHMEM (4GB) the box is stable and does not deadlock or crash even under > > heavy load. I have about a month before the system must go into production > > so if anyone has some hints or tests I could do they are most welcome. > > > > I can not get it over my heart to tell that we cannot use half the > > memory available. There goes my reputation :-/ > > Maybe I have a solution for you (and others). > > I found a patch (linux-2.4.2-vm-1-2-3-gbyte.patch) in the redhat kernel src > rpm. It allow you to change the standard vm user/kernel split of 3/1 GB to > 2/2 and 1/3 GB. Without a HIGHMEM kernel your max available memory is kernel > spilt size - 128MB. 896MB default, and 1920 or 2944MB with the patch. > > At work we have athlon based CAE workstations and numbercruncher with 1GB or > 1.5GB RAM. They running 2.4.7 or 2.4.9 linux-xfs kernels (of course .-) with > this patch. I modified the patch to 2.75/1.25 resp. 2.25/1.75GB. So they can > use all their memory without HIGHMEM. > > Advantages are no performance loss due HIGHMEM and *NO* HIGHMEM trouble. > > Disadvantage is that the possible userspace size per process is reduced. > If you don't have big processes it won't be a problem. I saw >1GB sized > processes with the 2.25/1.75GB split. > > > hope that helps. > > utz Please note that I haven't used this patch with 2.4.10. It maybe break things due the new vm. utz From owner-linux-xfs@oss.sgi.com Fri Oct 5 13:58:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95KwmX20358 for linux-xfs-outgoing; Fri, 5 Oct 2001 13:58:48 -0700 Received: from firewall.keyholecorp.com (w194.z064220189.sjc-ca.dsl.cnc.net [64.220.189.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95KweD20337 for ; Fri, 5 Oct 2001 13:58:40 -0700 Received: from core.keyholecorp.com (IDENT:root@core.keyholecorp.com [10.0.3.8]) by firewall.keyholecorp.com (8.11.0/8.11.0) with ESMTP id f95KwdI21208 for ; Fri, 5 Oct 2001 13:58:39 -0700 Received: from akebono (akebono.keyholecorp.com [10.0.3.33]) by core.keyholecorp.com (8.9.3/8.8.7) with SMTP id NAA02402 for ; Fri, 5 Oct 2001 13:58:39 -0700 Message-ID: <001e01c14de1$9cbae940$2103000a@keyholecorp.com> From: "Wayne Thai" To: Subject: kernel panic after installing XFS on a Compaq proliant 6500+Redhat 7.1 Date: Fri, 5 Oct 2001 14:06:33 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01C14DA6.F03EEC50" 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 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C14DA6.F03EEC50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable So I installed the XFS file system RPM's according to the instructions = given on the web, and I have also edited the lilo.conf file in order to = recognize the new file system. I type lilo and then reboot, and i get = the following error. /lib/cparray.o: init_module: Input/output error Hint: insmod errors can be caused bye incorrect module parameters, = including invalid IO or IRQ parameters Error: /bin/insmod exited abnormally! VFS: Cannot open root device "4806" or 48:06 Please append a correct "root=3D" boot option Kernel Panic: VFS: Unable to mount root fs on 48:06 Any suggestions? ------=_NextPart_000_001B_01C14DA6.F03EEC50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
So I installed the XFS file system = RPM's according=20 to the instructions given on the web, and I have also edited the = lilo.conf file=20 in order to recognize the new file system. I type lilo and then reboot, = and i=20 get the following error.
 
/lib/cparray.o: init_module: = Input/output=20 error
Hint: insmod errors can be caused bye = incorrect=20 module parameters, including invalid IO or IRQ parameters
Error: /bin/insmod exited = abnormally!
VFS: Cannot open root device "4806" or=20 48:06
Please append a correct "root=3D" boot=20 option
Kernel Panic: VFS: Unable to mount root = fs on=20 48:06
 
 
 
Any = suggestions?
------=_NextPart_000_001B_01C14DA6.F03EEC50-- From owner-linux-xfs@oss.sgi.com Fri Oct 5 14:04:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95L4sh20646 for linux-xfs-outgoing; Fri, 5 Oct 2001 14:04:54 -0700 Received: from linux0.echostar.com (w146-253.echostar.com [205.172.146.253]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95L4oD20627 for ; Fri, 5 Oct 2001 14:04:50 -0700 Received: from echostar.com (linux10.echostar.com [10.79.98.110]) by linux0.echostar.com (Postfix) with ESMTP id 1005379085 for ; Fri, 5 Oct 2001 15:04:40 -0600 (MDT) Message-ID: <3BBE206A.5FA9877@echostar.com> Date: Fri, 05 Oct 2001 15:04:42 -0600 From: "Ian S. Nelson" Reply-To: ian.nelson@echostar.com Organization: Echostar X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.4.3 i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-xfs@oss.sgi.com" Subject: Wierd errors with sync Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm debugging a bizarro set of kernel bugs and I think XFS may have something to do with it. I've got a system with all XFS on it. /dev/hda1 is a primary partition 200MB. /dev/hda2 is an extendo partition to the end of the disk. /dev/hda5 /dev/hda6 /dev/hda7 and /dev/hda8 are all logical partitions in /dev/hda2. /dev/hda7 is swapper. So I can go into /dev/hda8 and I can do an "echo foobar >ian; cat ian" and it shows up. If I do a sync and then "cat ian" nothing. The same thing is true for hda6. hda5 and hda1 behave like normal. Any ideas what this could be. My gut is the partition table but that looks okay to me. I'm getting beat up by mgmt on this so I'm just begging for any ideas that anyone might have.. thanks, Ian From owner-linux-xfs@oss.sgi.com Fri Oct 5 14:09:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95L9Co20839 for linux-xfs-outgoing; Fri, 5 Oct 2001 14:09:12 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95L99D20820 for ; Fri, 5 Oct 2001 14:09:09 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id XAA05985; Fri, 5 Oct 2001 23:09:02 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id XAA09533; Fri, 5 Oct 2001 23:09:01 +0200 (CEST) Date: Fri, 5 Oct 2001 23:09:01 +0200 (CEST) From: Seth Mos To: Steve Lord cc: Rik van Riel , Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: %u-order allocation failed In-Reply-To: <200110052043.f95KhG307514@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 5 Oct 2001, Steve Lord wrote: > > On Fri, 5 Oct 2001, Rik van Riel wrote: > > > > > On Fri, 5 Oct 2001, Seth Mos wrote: > > > > > > > This happens using either 2.4.10-xfs or 2.4.11-pre3-xfs. > > > > > > Ohh duh, IIRC there are a bunch of highmem bugs in > > > -linus which are fixed in -ac. > > > > Fitting XFS onto a -ac kernel should be fun :-( > > Its not that that simple - I tried before I got dragged kicking and > screaming back into some Irix stuff. Just running mongo on ext2 > on a HIGHMEM ac kernel should show if things are better there - since > the problems seem to be fairly filesystem independent. I don't have a HIGHMEM box without XFS filesystems. So i have to merge both -ac and the xfs tree to test it. I can reformat the box ofcourse but that would mean next week. If I can win a day and spare a reformat I am willing to make that sacrifice. From owner-linux-xfs@oss.sgi.com Fri Oct 5 14:12:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95LCaY21046 for linux-xfs-outgoing; Fri, 5 Oct 2001 14:12:36 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95LCWD21027 for ; Fri, 5 Oct 2001 14:12:32 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id XAA08032; Fri, 5 Oct 2001 23:12:30 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id XAA09731; Fri, 5 Oct 2001 23:12:29 +0200 (CEST) Date: Fri, 5 Oct 2001 23:12:29 +0200 (CEST) From: Seth Mos To: Wayne Thai cc: linux-xfs@oss.sgi.com Subject: Re: kernel panic after installing XFS on a Compaq proliant 6500+Redhat 7.1 In-Reply-To: <001e01c14de1$9cbae940$2103000a@keyholecorp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 5 Oct 2001, Wayne Thai wrote: > So I installed the XFS file system RPM's according to the instructions given on the web, and I have also edited the lilo.conf file in order to recognize the new file system. I type lilo and then reboot, and i get the following error. > > /lib/cparray.o: init_module: Input/output error > Hint: insmod errors can be caused bye incorrect module parameters, including invalid IO or IRQ parameters > Error: /bin/insmod exited abnormally! > VFS: Cannot open root device "4806" or 48:06 > Please append a correct "root=" boot option > Kernel Panic: VFS: Unable to mount root fs on 48:06 There were previous reports of people having trouble with compaq controllers. If I remember correctly they needed to be switched to factory default before they work again. There is something special with those but you will have to search the archive. Follow the link to the searchable archive which is on the mailinglist page. Cheers Seth From owner-linux-xfs@oss.sgi.com Fri Oct 5 14:17:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95LHuF21306 for linux-xfs-outgoing; Fri, 5 Oct 2001 14:17:56 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95LHqD21284 for ; Fri, 5 Oct 2001 14:17:52 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id XAA11319; Fri, 5 Oct 2001 23:17:49 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id XAA10064; Fri, 5 Oct 2001 23:17:43 +0200 (CEST) Date: Fri, 5 Oct 2001 23:17:43 +0200 (CEST) From: Seth Mos To: "Ian S. Nelson" cc: "linux-xfs@oss.sgi.com" Subject: Re: Wierd errors with sync In-Reply-To: <3BBE206A.5FA9877@echostar.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 5 Oct 2001, Ian S. Nelson wrote: > > I'm debugging a bizarro set of kernel bugs and I think XFS may have > something to do with it. > > I've got a system with all XFS on it. /dev/hda1 is a primary partition > 200MB. /dev/hda2 is an extendo partition to the end of the disk. > > /dev/hda5 /dev/hda6 /dev/hda7 and /dev/hda8 are all logical partitions > in /dev/hda2. > /dev/hda7 is swapper. > > So I can go into /dev/hda8 and I can do an "echo foobar >ian; cat ian" > and it shows up. If I do a sync and then "cat ian" nothing. > The same thing is true for hda6. hda5 and hda1 behave like normal. > Any ideas what this could be. My gut is the partition table but that > looks okay to me. I'm getting beat up by mgmt on this so I'm just > begging for any ideas that anyone might have.. It should not happen. Do you have any errors in you /var/log/messages? Is the whole partiton invisible after a sync? (eg, can you list any files in there?) Since You are using IDE, are you using and tuning options from hdparm? What chipset does your motherboard have and what IDE chip? You are certain that the hardware is 100%. Can you describe soem hardware configuration bits. Cheers From owner-linux-xfs@oss.sgi.com Fri Oct 5 14:32:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95LWDc21731 for linux-xfs-outgoing; Fri, 5 Oct 2001 14:32:13 -0700 Received: from linux0.echostar.com (w146-253.echostar.com [205.172.146.253]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95LW8D21710 for ; Fri, 5 Oct 2001 14:32:08 -0700 Received: from echostar.com (linux10.echostar.com [10.79.98.110]) by linux0.echostar.com (Postfix) with ESMTP id 1287B79085; Fri, 5 Oct 2001 15:31:58 -0600 (MDT) Message-ID: <3BBE26D0.5EC11066@echostar.com> Date: Fri, 05 Oct 2001 15:32:00 -0600 From: "Ian S. Nelson" Reply-To: ian.nelson@echostar.com Organization: Echostar X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.4.3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Seth Mos Cc: "linux-xfs@oss.sgi.com" Subject: Re: Wierd errors with sync References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have been seeing kernel BUGs in ll_rw_blk. To my /dev/hda8, requests out of range, or so it would appear. Well it's an embedded platform and we've been slowly turning off items. Here is my new theory. If the drive is blank then I have a flash the detects that and rebuilds it in said flash I do mkfs.xfs and then I do a C library call mount() That mount behaves different from /bin/mount. I'm guessing that's my problem. I'm doing mkfs and then it's not syncing or some such garbage. I'm going to retool my flash and try again. I've taken the problematic partitions and on the running system I've unmounted them and rebuilt them and everything is cool again.. Ian Seth Mos wrote: > On Fri, 5 Oct 2001, Ian S. Nelson wrote: > > > > > I'm debugging a bizarro set of kernel bugs and I think XFS may have > > something to do with it. > > > > I've got a system with all XFS on it. /dev/hda1 is a primary partition > > 200MB. /dev/hda2 is an extendo partition to the end of the disk. > > > > /dev/hda5 /dev/hda6 /dev/hda7 and /dev/hda8 are all logical partitions > > in /dev/hda2. > > /dev/hda7 is swapper. > > > > So I can go into /dev/hda8 and I can do an "echo foobar >ian; cat ian" > > and it shows up. If I do a sync and then "cat ian" nothing. > > The same thing is true for hda6. hda5 and hda1 behave like normal. > > Any ideas what this could be. My gut is the partition table but that > > looks okay to me. I'm getting beat up by mgmt on this so I'm just > > begging for any ideas that anyone might have.. > > It should not happen. Do you have any errors in you /var/log/messages? > Is the whole partiton invisible after a sync? (eg, can you list any files > in there?) > > Since You are using IDE, are you using and tuning options from hdparm? > What chipset does your motherboard have and what IDE chip? > You are certain that the hardware is 100%. > > Can you describe soem hardware configuration bits. > > Cheers From owner-linux-xfs@oss.sgi.com Fri Oct 5 14:46:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95LkHp22229 for linux-xfs-outgoing; Fri, 5 Oct 2001 14:46:17 -0700 Received: from locutus.doe.carleton.ca (locutus.doe.carleton.ca [134.117.9.46]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95LkED22210 for ; Fri, 5 Oct 2001 14:46:14 -0700 Received: from doe.carleton.ca (kelvin [134.117.9.220]) by locutus.doe.carleton.ca (8.10.2+Sun/8.9.1) with ESMTP id f95Lk8I00982 for ; Fri, 5 Oct 2001 17:46:09 -0400 (EDT) Message-ID: <3BBE2A43.3070400@doe.carleton.ca> Date: Fri, 05 Oct 2001 17:46:43 -0400 From: Mike Sowka User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010816 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: WAS: Cluster XFS install without CD... MY APOLOGIES Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm sorry it seems I have created some confusion on the list... I should have been a bit more concise in my initial post. The nodes DO have a HD. From the numerous replies I think my task will be an easy one, once I wade through all the hints ppl sent out (THANK YOU) ... Oscar, or systemimager (which is what the tool for intalling acutally is) unfortunately doesn't like my NIC which is a 3CSM905CX-TXM :( so after convincing my peers to use XFS on the cluster I'm sure with all the support I'll have not problem! MSC linux eh... :) Hmmm I'll have to give it a whirl... Thanx, Mike -- /************************************************************************\ | Mike Sowka o _ _ _ | | An Aspiring Engi"Nerd" _o /\_ _ \\o (_)\__/o (_) | | Carleton University _< \_ _>(_) (_)/<_ \_| \ _|/' \/ | | msowka@doe.carleton.ca (_)>(_) (_) (_) (_) (_)' _\o_ | | (home msowka@home.com) | \************************************************************************/ From owner-linux-xfs@oss.sgi.com Fri Oct 5 15:11:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95MBa322910 for linux-xfs-outgoing; Fri, 5 Oct 2001 15:11:36 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95MBWD22889 for ; Fri, 5 Oct 2001 15:11:32 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id AAA13875; Sat, 6 Oct 2001 00:11:30 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id AAA12716; Sat, 6 Oct 2001 00:11:30 +0200 (CEST) Date: Sat, 6 Oct 2001 00:11:29 +0200 (CEST) From: Seth Mos To: Mike Sowka cc: linux-xfs@oss.sgi.com Subject: Re: WAS: Cluster XFS install without CD... MY APOLOGIES In-Reply-To: <3BBE2A43.3070400@doe.carleton.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 5 Oct 2001, Mike Sowka wrote: > I'm sorry it seems I have created some confusion on the list... I should > have been a bit more concise in my initial post. The nodes DO have a HD. That makes sense when metioning it in on a fs list. > From the numerous replies I think my task will be an easy one, once I > wade through all the hints ppl sent out (THANK YOU) ... Oscar, or > systemimager (which is what the tool for intalling acutally is) It is a shame that tools Like Symantec Ghost are really slow in taking up on different filesystems. ReiserFS or XFS are unsupported. ext2 is your only choice for most commercial tools. > unfortunately doesn't like my NIC which is a 3CSM905CX-TXM :( so after What does it not like? > convincing my peers to use XFS on the cluster I'm sure with all the > support I'll have not problem! MSC linux eh... :) Hmmm I'll have to > give it a whirl... Good luck. Seth From owner-linux-xfs@oss.sgi.com Fri Oct 5 15:16:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95MGIE23145 for linux-xfs-outgoing; Fri, 5 Oct 2001 15:16:18 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95MGFD23125 for ; Fri, 5 Oct 2001 15:16:15 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id AAA16674; Sat, 6 Oct 2001 00:16:11 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id AAA12861; Sat, 6 Oct 2001 00:16:11 +0200 (CEST) Date: Sat, 6 Oct 2001 00:16:11 +0200 (CEST) From: Seth Mos To: David Schwartz cc: Rik van Riel , Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: %u-order allocation failed In-Reply-To: <20011005220627.AAA22897@shell.webmaster.com@whenever> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 5 Oct 2001, David Schwartz wrote: > > >The system is beafy enough to tolerate something mundane as this. It should > >definitely not die. > > A fork bomb with no limits attempts to create an infinite number of > processes. No system can be that beefy. I was refering to the mundane load of mongo.pl with 5 processes. Something the systems should withstand. If you have more then 10GB of database to access you would want it to work. I am not talking about a lot of processes but a lot of disk IO. I have just one box running SMP with highmem and that one is acting funny. All the other SMP ur Uni servers have absolutely no problems. Disable highmem and the problem goes away while halving your ram. That is not very efficient is it? Cheers From owner-linux-xfs@oss.sgi.com Fri Oct 5 15:35:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95MZeK23702 for linux-xfs-outgoing; Fri, 5 Oct 2001 15:35:40 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95MZaD23682 for ; Fri, 5 Oct 2001 15:35:36 -0700 Received: from gumby.uwyo.edu (gumby.uwyo.edu [129.72.5.18]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA08332 for ; Fri, 5 Oct 2001 15:35:44 -0700 (PDT) mail_from (ringram@uwyo.edu) Received: from uwyo.edu (localhost [127.0.0.1]) by gumby.uwyo.edu (8.11.6/8.11.6) with ESMTP id f95MawK01877 for ; Fri, 5 Oct 2001 16:36:59 -0600 Message-ID: <3BBE360A.A2C909B2@uwyo.edu> Date: Fri, 05 Oct 2001 16:36:58 -0600 From: Russ Ingram Reply-To: ringram@uwyo.edu Organization: UW Math Dept/Institute for Scientific Computation X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.10-pre10-xfs-091701 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: WAS: Cluster XFS install without CD... MY APOLOGIES References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > > It is a shame that tools Like Symantec Ghost are really slow in taking up > on different filesystems. ReiserFS or XFS are unsupported. ext2 is your > only choice for most commercial tools. On the contrary, my friends. :-P There was a post to this list probably a month or so ago about a linux Norton Ghost like util that supports just about every major fs available in Linux. I didn't actually get to try it out cuz I had just finished cloning the drives I needed with xfsdump/xfsrestore when the message came across but I remember it because I had needed exactly that not 2 days before the message hit the list. The link was http://www.partimage.org. You can also always just do what I did and pipe the output of xfsdump to xfsrestore(or do the same with tar for that matter), too. Russ -- Russel H. Ingram Unix Systems Administrator Institute for Scientific Computation University of Wyoming/Math Dept. Phone: (307)766-6546 E-Mail: ringram@uwyo.edu From owner-linux-xfs@oss.sgi.com Fri Oct 5 16:22:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95NMlf24895 for linux-xfs-outgoing; Fri, 5 Oct 2001 16:22:47 -0700 Received: from smtp.WPI.EDU (root@smtp.WPI.EDU [130.215.24.62]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95NMhD24875 for ; Fri, 5 Oct 2001 16:22:43 -0700 Received: from grover.wpi.edu (ian@grover.WPI.EDU [130.215.25.67]) by smtp.WPI.EDU (8.12.1/8.12.1) with ESMTP id f95NMa1Y029796 for ; Fri, 5 Oct 2001 19:22:36 -0400 (EDT) Date: Fri, 5 Oct 2001 19:22:36 -0400 (EDT) From: Ian Cooper To: Subject: XFS and NetBSD Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk There is some interest in the BSD community to work on porting the XFS filesystem to the BSD platform (primarily for the sgimips port of NetBSD). However, there are licensing issues related with that. BSD and its derivatives are licensed with a BSD licence (not suprisingly) and the Linux-XFS source code is licensed under the GPL. If a BSD port of XFS was to be integrated into the BSD kernel (NetBSD, in this case), then the source code would have to be relicensed for that use. Is this possible, and if so, how? Thanks. -- Ian Cooper ian@wpi.edu ---------- Forwarded message ---------- Date: Fri, 5 Oct 2001 16:48:03 +0000 From: Joseph Mallett To: Steve Rikli Cc: port-sgimips@netbsd.org Subject: Re: XFS and NetBSD [was Re: News & Installation ideas] On Fri, Oct 05, 2001 at 09:39:33AM -0700, Steve Rikli wrote: > IIRC though, from reading freebsd-fs et al, there *may* be outstanding > src license issues -- i.e. I believe SGI released XFS src under GPL. > The discussion I read in the newsgroups seemed to indicate that might > be a bit of a tangle in porting to *BSD . What I've heard WRT this is that if someone actually ports it to *BSD SGI would be willing to relicense as long as their lawyers okay'd it... This of course hearsay, but I've heard it from a number of sources, if that helps any. From owner-linux-xfs@oss.sgi.com Fri Oct 5 16:48:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95Nmg525513 for linux-xfs-outgoing; Fri, 5 Oct 2001 16:48:42 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95NmcD25494 for ; Fri, 5 Oct 2001 16:48:38 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA01868 for ; Fri, 5 Oct 2001 16:47:34 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id QAA93643; Fri, 5 Oct 2001 16:48:05 -0700 (PDT) Message-ID: <3BBE45E7.CE3B12F9@sgi.com> Date: Fri, 05 Oct 2001 18:44:39 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: Ian Cooper CC: linux-xfs@oss.sgi.com Subject: Re: XFS and NetBSD References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This has been discussed a few times on this list, and I'm sure Russell will chime in as well... :) But the bottom line is usually that it would cost SGI time, money and lawyers to relicense the code, and unless there is a compelling business reason to do so (i.e. perceived financial gain for SGI - or at least no financial loss), it probably won't happen. Getting XFS released under the GPL was a herculean effort in the first place, and getting it re-licensed would re-visit a lot of that effort. I can't speak officialy for SGI in this matter (probably no-one on this list can), but it's highly unlikely that SGI will spend the resources necessary to make a change like this. I know that sounds like corporate-speak, and I know how frustrating it can be, I've been on the other end of it for some projects I was interested in - but it's probably the reality today. -Eric Ian Cooper wrote: > > There is some interest in the BSD community to work on porting the XFS > filesystem to the BSD platform (primarily for the sgimips port of NetBSD). > However, there are licensing issues related with that. BSD and its > derivatives are licensed with a BSD licence (not suprisingly) and the > Linux-XFS source code is licensed under the GPL. > > If a BSD port of XFS was to be integrated into the BSD kernel (NetBSD, in > this case), then the source code would have to be relicensed for that use. > Is this possible, and if so, how? -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Oct 5 17:00:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9600r725946 for linux-xfs-outgoing; Fri, 5 Oct 2001 17:00:53 -0700 Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9600nD25927 for ; Fri, 5 Oct 2001 17:00:49 -0700 Received: from club-internet.fr (bas12-117.idf.club-internet.fr [213.44.252.117]) by relay-4v.club-internet.fr (Postfix) with ESMTP id E78D316CB; Sat, 6 Oct 2001 02:00:46 +0200 (CEST) Message-ID: <3BBE4DAC.AA3B0C85@club-internet.fr> Date: Sat, 06 Oct 2001 02:17:49 +0200 From: Jean Francois Martinez X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.5-SGI_XFS_1.0.1_Indy i586) X-Accept-Language: en MIME-Version: 1.0 To: Ian Cooper Cc: linux-xfs@oss.sgi.com Subject: Re: XFS and NetBSD References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ian Cooper a écrit : > There is some interest in the BSD community to work on porting the XFS > filesystem to the BSD platform (primarily for the sgimips port of NetBSD). > However, there are licensing issues related with that. BSD and its > derivatives are licensed with a BSD licence (not suprisingly) and the > Linux-XFS source code is licensed under the GPL. > > If a BSD port of XFS was to be integrated into the BSD kernel (NetBSD, in > this case), then the source code would have to be relicensed for that use. > Is this possible, and if so, how? > One of the nice things in GPL is that it does not allow SGI competitors to steal SGI's crown jewels unless they relinquish THEIR code jewels. With BSD license SGI could find its code has been used in say Solaris without Sun giving anything Another point is that if someone not from SGI contributed code to XFS then SGI would need either to get his agreement or to rewrite his code before thinking in relicensing. JFM From owner-linux-xfs@oss.sgi.com Fri Oct 5 19:46:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f962kwe28954 for linux-xfs-outgoing; Fri, 5 Oct 2001 19:46:58 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f962ksD28934 for ; Fri, 5 Oct 2001 19:46:54 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f962knL17100 for ; Fri, 5 Oct 2001 19:46:49 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id VAA3157608; Fri, 5 Oct 2001 21:45:33 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id VAA29754; Fri, 5 Oct 2001 21:45:32 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f962iwf08449; Fri, 5 Oct 2001 21:44:58 -0500 Message-Id: <200110060244.f962iwf08449@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: ian.nelson@echostar.com cc: Seth Mos , "linux-xfs@oss.sgi.com" Subject: Re: Wierd errors with sync In-Reply-To: Message from "Ian S. Nelson" of "Fri, 05 Oct 2001 15:32:00 MDT." <3BBE26D0.5EC11066@echostar.com> Date: Fri, 05 Oct 2001 21:44:58 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I have been seeing kernel BUGs in ll_rw_blk. To my /dev/hda8, requests out > of range, or so it would appear. > > Well it's an embedded platform and we've been slowly turning off items. Here > is my new theory. Ah ha, a minor detail emerges! > > If the drive is blank then I have a flash the detects that and rebuilds it > in said flash I do mkfs.xfs and then I do a C library call mount() > That mount behaves different from /bin/mount. I'm guessing that's my > problem. I'm doing mkfs and then it's not syncing or some such garbage. The xfs metadata cache and the buffer cache used by block devices are not coherent. There is an ioctl at the end of mkfs which is supposed to ensure that all buffers for the device are flushed out to disk before it returns. This ioctl: BLKFLSBUF must work, possibly this is an issue for you. > > I'm going to retool my flash and try again. I've taken the problematic > partitions and on the running system I've unmounted them and rebuilt them and > everything is cool again.. > > Ian > Steve From owner-linux-xfs@oss.sgi.com Fri Oct 5 20:14:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f963EGb29688 for linux-xfs-outgoing; Fri, 5 Oct 2001 20:14:16 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f963E2D29668 for ; Fri, 5 Oct 2001 20:14:02 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f963DvK03033 for ; Fri, 5 Oct 2001 20:13:57 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id WAA3141128 for ; Fri, 5 Oct 2001 22:12:41 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id WAA74362 for ; Fri, 5 Oct 2001 22:12:41 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id f963C7o08625; Fri, 5 Oct 2001 22:12:07 -0500 Message-Id: <200110060312.f963C7o08625@jen.americas.sgi.com> Date: Fri, 5 Oct 2001 22:12:07 -0500 Subject: TAKE - merge up to 2.4.11-pre4 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Fri Oct 5 20:12:00 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:104073a linux/drivers/mtd/maps/l440gx.c - 1.1 linux/drivers/mtd/devices/blkmtd.c - 1.1 linux/drivers/mtd/maps/integrator-flash.c - 1.1 linux/drivers/mtd/chips/map_absent.c - 1.1 linux/drivers/mtd/chips/jedec_probe.c - 1.1 linux/drivers/mtd/devices/lart.c - 1.1 linux/drivers/mtd/maps/cdb89712.c - 1.1 linux/include/asm-i386/smpboot.h - 1.1 linux/drivers/mtd/chips/gen_probe.c - 1.1 linux/fs/jffs/jffs_proc.c - 1.1 linux/drivers/mtd/maps/tqm8xxl.c - 1.1 linux/fs/namespace.c - 1.1 linux/fs/jffs/jffs_proc.h - 1.1 linux/drivers/mtd/afs.c - 1.1 linux/include/linux/mtd/gen_probe.h - 1.1 linux/drivers/mtd/maps/solutionengine.c - 1.1 linux/net/irda/irlmp.c - 1.14 linux/net/irda/irlap_event.c - 1.16 linux/net/irda/irias_object.c - 1.11 linux/net/irda/af_irda.c - 1.28 linux/mm/vmscan.c - 1.78 linux/mm/swapfile.c - 1.40 linux/mm/swap_state.c - 1.32 linux/mm/page_alloc.c - 1.57 linux/mm/filemap.c - 1.90 linux/kernel/sched.c - 1.41 linux/kernel/exec_domain.c - 1.14 linux/init/main.c - 1.61 linux/include/net/irda/irlmp.h - 1.8 linux/include/linux/swap.h - 1.43 linux/include/linux/pagemap.h - 1.31 linux/include/asm-i386/smp.h - 1.11 linux/include/asm-i386/io.h - 1.18 linux/include/asm-alpha/system.h - 1.17 linux/include/asm-alpha/pgtable.h - 1.29 linux/include/asm-alpha/core_apecs.h - 1.8 linux/include/asm-alpha/cache.h - 1.8 linux/fs/super.c - 1.60 linux/fs/Makefile - 1.35 linux/fs/Config.in - 1.66 linux/arch/i386/kernel/trampoline.S - 1.4 linux/arch/i386/kernel/smp.c - 1.35 linux/arch/i386/kernel/setup.c - 1.55 linux/arch/i386/kernel/process.c - 1.36 linux/arch/i386/kernel/io_apic.c - 1.30 linux/arch/i386/defconfig - 1.73 linux/arch/i386/config.in - 1.64 linux/arch/i386/boot/compressed/misc.c - 1.12 linux/arch/alpha/kernel/time.c - 1.18 linux/arch/alpha/kernel/sys_cabriolet.c - 1.12 linux/arch/alpha/kernel/setup.c - 1.22 linux/arch/alpha/config.in - 1.34 linux/arch/alpha/boot/bootp.c - 1.6 linux/arch/alpha/boot/Makefile - 1.7 linux/Makefile - 1.129 linux/Documentation/Configure.help - 1.104 linux/drivers/net/irda/smc-ircc.c - 1.22 linux/include/asm-i386/apic.h - 1.14 linux/arch/i386/kernel/smpboot.c - 1.23 linux/arch/i386/kernel/apic.c - 1.20 linux/arch/i386/kernel/mpparse.c - 1.13 linux/include/asm-i386/mpspec.h - 1.6 linux/drivers/pci/setup-res.c - 1.8 linux/drivers/pci/setup-bus.c - 1.4 linux/drivers/net/irda/nsc-ircc.c - 1.17 linux/arch/alpha/kernel/irq_alpha.c - 1.8 linux/Documentation/arm/SA1100/Assabet - 1.3 linux/fs/jffs/Makefile - 1.4 linux/fs/jffs/inode-v23.c - 1.13 linux/fs/jffs/intrep.c - 1.9 linux/fs/jffs/intrep.h - 1.4 linux/fs/jffs/jffs_fm.c - 1.6 linux/fs/jffs/jffs_fm.h - 1.3 linux/include/asm-alpha/mc146818rtc.h - 1.2 linux/drivers/mtd/Config.in - 1.6 linux/drivers/mtd/Makefile - 1.7 linux/drivers/mtd/ftl.c - 1.8 linux/drivers/mtd/mtdblock.c - 1.7 linux/drivers/mtd/mtdchar.c - 1.7 linux/drivers/mtd/mtdcore.c - 1.5 linux/include/linux/jffs.h - 1.4 linux/include/linux/mtd/cfi.h - 1.7 linux/include/linux/mtd/doc2000.h - 1.5 linux/include/linux/mtd/ftl.h - 1.3 linux/include/linux/mtd/iflash.h - 1.2 linux/include/linux/mtd/map.h - 1.7 linux/include/linux/mtd/pmc551.h - 1.3 linux/mm/oom_kill.c - 1.7 linux/net/irda/irnet/irnet_ppp.c - 1.7 linux/net/irda/irnet/irnet_irda.c - 1.6 linux/drivers/mtd/nftlmount.c - 1.5 linux/drivers/mtd/mtdpart.c - 1.4 linux/mm/shmem.c - 1.16 linux/drivers/net/irda/irda-usb.c - 1.8 linux/include/net/irda/irda-usb.h - 1.3 linux/drivers/mtd/nand/nand.c - 1.2 linux/drivers/mtd/nftlcore.c - 1.5 linux/drivers/mtd/bootldr.c - 1.2 linux/drivers/mtd/nand/spia.c - 1.4 linux/drivers/mtd/redboot.c - 1.2 linux/drivers/mtd/nand/Makefile - 1.3 linux/drivers/mtd/nand/Config.in - 1.5 linux/drivers/mtd/mtdblock_ro.c - 1.3 linux/drivers/mtd/maps/vmax301.c - 1.2 linux/drivers/mtd/maps/sun_uflash.c - 1.2 linux/drivers/mtd/maps/sc520cdp.c - 1.2 linux/drivers/mtd/maps/sbc_gxx.c - 1.2 linux/drivers/mtd/maps/sa1100-flash.c - 1.2 linux/drivers/mtd/maps/rpxlite.c - 1.2 linux/drivers/mtd/maps/pnc2000.c - 1.2 linux/drivers/mtd/maps/physmap.c - 1.2 linux/drivers/mtd/maps/octagon-5066.c - 1.2 linux/drivers/mtd/maps/ocelot.c - 1.2 linux/include/linux/mtd/cfi_endian.h - 1.2 linux/drivers/mtd/maps/nora.c - 1.2 linux/drivers/mtd/maps/netsc520.c - 1.2 linux/drivers/mtd/maps/iq80310.c - 1.2 linux/drivers/mtd/maps/elan-104nc.c - 1.2 linux/drivers/mtd/maps/dc21285.c - 1.2 linux/drivers/mtd/maps/dbox2-flash.c - 1.2 linux/drivers/mtd/maps/cstm_mips_ixx.c - 1.2 linux/drivers/mtd/maps/cfi_flagadm.c - 1.2 linux/drivers/mtd/maps/Makefile - 1.2 linux/drivers/mtd/maps/Config.in - 1.3 linux/drivers/mtd/devices/slram.c - 1.2 linux/drivers/mtd/devices/pmc551.c - 1.2 linux/drivers/mtd/devices/mtdram.c - 1.2 linux/drivers/mtd/devices/docprobe.c - 1.3 linux/drivers/mtd/devices/docecc.c - 1.4 linux/drivers/mtd/devices/doc2001.c - 1.2 linux/drivers/mtd/devices/doc2000.c - 1.2 linux/drivers/mtd/devices/doc1000.c - 1.2 linux/drivers/mtd/devices/Makefile - 1.2 linux/drivers/mtd/devices/Config.in - 1.2 linux/drivers/mtd/chips/sharp.c - 1.2 linux/drivers/mtd/chips/map_rom.c - 1.2 linux/drivers/mtd/chips/map_ram.c - 1.2 linux/drivers/mtd/chips/jedec.c - 1.2 linux/drivers/mtd/chips/chipreg.c - 1.2 linux/drivers/mtd/chips/cfi_probe.c - 1.2 linux/drivers/mtd/chips/cfi_jedec.c - 1.2 linux/drivers/mtd/chips/cfi_cmdset_0002.c - 1.2 linux/drivers/mtd/chips/cfi_cmdset_0001.c - 1.2 linux/drivers/mtd/chips/amd_flash.c - 1.3 linux/drivers/mtd/chips/Makefile - 1.2 linux/drivers/mtd/chips/Config.in - 1.2 linux/drivers/net/irda/vlsi_ir.c - 1.5 linux/include/net/irda/vlsi_ir.h - 1.2 linux/fs/jffs2/Makefile - 1.2 linux/fs/jffs2/background.c - 1.2 linux/fs/jffs2/compr.c - 1.2 linux/fs/jffs2/compr_rubin.c - 1.2 linux/fs/jffs2/compr_zlib.c - 1.2 linux/fs/jffs2/erase.c - 1.2 linux/fs/jffs2/file.c - 1.2 linux/fs/jffs2/gc.c - 1.2 linux/fs/jffs2/nodelist.c - 1.2 linux/fs/jffs2/nodelist.h - 1.2 linux/fs/jffs2/nodemgmt.c - 1.2 linux/fs/jffs2/pushpull.c - 1.2 linux/fs/jffs2/pushpull.h - 1.2 linux/fs/jffs2/scan.c - 1.2 linux/fs/jffs2/super.c - 1.2 linux/fs/jffs2/write.c - 1.2 linux/include/linux/jffs2_fs_sb.h - 1.2 From owner-linux-xfs@oss.sgi.com Fri Oct 5 22:58:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f965wgJ00426 for linux-xfs-outgoing; Fri, 5 Oct 2001 22:58:42 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f965wPD32674 for ; Fri, 5 Oct 2001 22:58:26 -0700 Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sat, 6 Oct 2001 16:00:47 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10062001-160012-74.MMD@cymax.com.au; Sat, 6 Oct 2001 16:00:12 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sat Oct 6 15:53:40 2001) X-From_: owner-linux-xfs@oss.sgi.com Sat Oct 6 08:36:34 2001 Delivered-To: cymax@smartchat.net.au Received: from yarrina.connect.com.au (yarrina.connect.com.au [192.189.54.17]) by entoo.connect.com.au (Postfix) with ESMTP id 54983F6E81 for ; Sat, 6 Oct 2001 08:30:20 +1000 (EST) Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by yarrina.connect.com.au (Postfix) with ESMTP id 1AA3729EEFB for ; Sat, 6 Oct 2001 07:22:41 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95LJ4m21419; Fri, 5 Oct 2001 14:19:04 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 14:17:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95LHuF21306 for linux-xfs-outgoing; Fri, 5 Oct 2001 14:17:56 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95LHqD21284 for ; Fri, 5 Oct 2001 14:17:52 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id XAA11319; Fri, 5 Oct 2001 23:17:49 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id XAA10064; Fri, 5 Oct 2001 23:17:43 +0200 (CEST) Date: Fri, 5 Oct 2001 23:17:43 +0200 (CEST) From: Seth Mos To: "Ian S. Nelson" Cc: "linux-xfs@oss.sgi.com" Subject: Re: Wierd errors with sync In-Reply-To: <3BBE206A.5FA9877@echostar.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 06 Oct 2001 06:00:47.0578 (UTC) FILETIME=[3E6A83A0:01C14E2C] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 5 Oct 2001, Ian S. Nelson wrote: > > I'm debugging a bizarro set of kernel bugs and I think XFS may have > something to do with it. > > I've got a system with all XFS on it. /dev/hda1 is a primary partition > 200MB. /dev/hda2 is an extendo partition to the end of the disk. > > /dev/hda5 /dev/hda6 /dev/hda7 and /dev/hda8 are all logical partitions > in /dev/hda2. > /dev/hda7 is swapper. > > So I can go into /dev/hda8 and I can do an "echo foobar >ian; cat ian" > and it shows up. If I do a sync and then "cat ian" nothing. > The same thing is true for hda6. hda5 and hda1 behave like normal. > Any ideas what this could be. My gut is the partition table but that > looks okay to me. I'm getting beat up by mgmt on this so I'm just > begging for any ideas that anyone might have.. It should not happen. Do you have any errors in you /var/log/messages? Is the whole partiton invisible after a sync? (eg, can you list any files in there?) Since You are using IDE, are you using and tuning options from hdparm? What chipset does your motherboard have and what IDE chip? You are certain that the hardware is 100%. Can you describe soem hardware configuration bits. Cheers From owner-linux-xfs@oss.sgi.com Fri Oct 5 22:58:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f965wZi00352 for linux-xfs-outgoing; Fri, 5 Oct 2001 22:58:35 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f965wOD32641 for ; Fri, 5 Oct 2001 22:58:24 -0700 Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sat, 6 Oct 2001 16:00:47 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10062001-160012-73.MMD@cymax.com.au; Sat, 6 Oct 2001 16:00:12 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sat Oct 6 15:53:40 2001) X-From_: owner-linux-xfs@oss.sgi.com Sat Oct 6 08:36:04 2001 Delivered-To: cymax@smartchat.net.au Received: from yarrina.connect.com.au (yarrina.connect.com.au [192.189.54.17]) by entoo.connect.com.au (Postfix) with ESMTP id 16C2FE0188 for ; Sat, 6 Oct 2001 08:29:15 +1000 (EST) Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by yarrina.connect.com.au (Postfix) with ESMTP id B6F9429ECA7 for ; Sat, 6 Oct 2001 07:13:43 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95LABG20956; Fri, 5 Oct 2001 14:10:11 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 14:09:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95L9Co20839 for linux-xfs-outgoing; Fri, 5 Oct 2001 14:09:12 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95L99D20820 for ; Fri, 5 Oct 2001 14:09:09 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id XAA05985; Fri, 5 Oct 2001 23:09:02 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id XAA09533; Fri, 5 Oct 2001 23:09:01 +0200 (CEST) Date: Fri, 5 Oct 2001 23:09:01 +0200 (CEST) From: Seth Mos To: Steve Lord Cc: Rik van Riel , Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: %u-order allocation failed In-Reply-To: <200110052043.f95KhG307514@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 06 Oct 2001 06:00:47.0312 (UTC) FILETIME=[3E41ED00:01C14E2C] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 5 Oct 2001, Steve Lord wrote: > > On Fri, 5 Oct 2001, Rik van Riel wrote: > > > > > On Fri, 5 Oct 2001, Seth Mos wrote: > > > > > > > This happens using either 2.4.10-xfs or 2.4.11-pre3-xfs. > > > > > > Ohh duh, IIRC there are a bunch of highmem bugs in > > > -linus which are fixed in -ac. > > > > Fitting XFS onto a -ac kernel should be fun :-( > > Its not that that simple - I tried before I got dragged kicking and > screaming back into some Irix stuff. Just running mongo on ext2 > on a HIGHMEM ac kernel should show if things are better there - since > the problems seem to be fairly filesystem independent. I don't have a HIGHMEM box without XFS filesystems. So i have to merge both -ac and the xfs tree to test it. I can reformat the box ofcourse but that would mean next week. If I can win a day and spare a reformat I am willing to make that sacrifice. From owner-linux-xfs@oss.sgi.com Fri Oct 5 23:00:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9660E901023 for linux-xfs-outgoing; Fri, 5 Oct 2001 23:00:14 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96604D00879 for ; Fri, 5 Oct 2001 23:00:04 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA04884 for ; Fri, 5 Oct 2001 23:00:32 -0700 (PDT) mail_from (knuffie@xs4all.nl) Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sat, 6 Oct 2001 16:00:48 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10062001-160014-82.MMD@cymax.com.au; Sat, 6 Oct 2001 16:00:14 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sat Oct 6 15:53:42 2001) X-From_: owner-linux-xfs@oss.sgi.com Sat Oct 6 08:49:19 2001 Delivered-To: cymax@smartchat.net.au Received: from yarrina.connect.com.au (yarrina.connect.com.au [192.189.54.17]) by entoo.connect.com.au (Postfix) with ESMTP id ED3A5DFBBA for ; Sat, 6 Oct 2001 08:48:25 +1000 (EST) Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by yarrina.connect.com.au (Postfix) with ESMTP id 9E9C529C831 for ; Sat, 6 Oct 2001 06:24:45 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95KJqe18455; Fri, 5 Oct 2001 13:19:52 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 13:18:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95KIsB18349 for linux-xfs-outgoing; Fri, 5 Oct 2001 13:18:54 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95KInD18329 for ; Fri, 5 Oct 2001 13:18:49 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id WAA07639; Fri, 5 Oct 2001 22:18:40 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id WAA03806; Fri, 5 Oct 2001 22:18:40 +0200 (CEST) Date: Fri, 5 Oct 2001 22:18:39 +0200 (CEST) From: Seth Mos To: Rik van Riel Cc: Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: %u-order allocation failed In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 06 Oct 2001 06:00:48.0656 (UTC) FILETIME=[3F0F0100:01C14E2C] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 5 Oct 2001, Rik van Riel wrote: > On Fri, 5 Oct 2001, Krzysztof Rusocki wrote: > > > After simple bash fork bombing (about 200 forks) on my UP Celeron/96MB > > I get quite a lot %u-allocations failed, but only when swap is turned > > off. > > > I'm not familiar with LinuxVM.. so... is it normal behaviour ? or (if not) > > what's happening when such messages are printed my kernel ? > > This is perfectly normal behaviour: > > 1) on your system, you have no process limit configured for > yourself so you can start processes until all resources > (memory, file descriptors, ...) are used Fair enough. > 2) when all processes are used, there really is no way the > kernel can buy you more hardware on ebay and install it > on the fly ... all it can do is start failing allocations So it needs a handbrake in case of a emergency? The box at work deadlocks or crashes. I can hardly call that normal operational behaviour. I have a Dell PE 2500 (Serverworks LE) with 2GB ram and 2 1.13Ghz processors. If I disable HIGHMEM (4GB) support the box does not produce these allocations messages and does not deadlock or die under the same load or worse. What I used was a mongo.pl with 5 processes (does not matter if the fs is ext2 reiserfs or xfs) and the box dies within minutes/seconds after starting the benchmark. This happens using either 2.4.10-xfs or 2.4.11-pre3-xfs. Using a single process hides the issue. > On production systems, good admins setup per-user limits for > the various resources so no single user is able to run the > system into the ground. The system is beafy enough to tolerate something mundane as this. It should definitely not die. Cheers Seth From owner-linux-xfs@oss.sgi.com Fri Oct 5 23:00:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9660wJ01491 for linux-xfs-outgoing; Fri, 5 Oct 2001 23:00:58 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9660rD01435 for ; Fri, 5 Oct 2001 23:00:53 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA04027 for ; Fri, 5 Oct 2001 23:01:10 -0700 (PDT) mail_from (msowka@doe.carleton.ca) Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sat, 6 Oct 2001 16:00:50 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10062001-160017-93.MMD@cymax.com.au; Sat, 6 Oct 2001 16:00:17 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sat Oct 6 15:53:45 2001) X-From_: owner-linux-xfs@oss.sgi.com Sat Oct 6 08:58:20 2001 Delivered-To: cymax@smartchat.net.au Received: from yarrina.connect.com.au (yarrina.connect.com.au [192.189.54.17]) by entoo.connect.com.au (Postfix) with ESMTP id DA161DE6A8 for ; Sat, 6 Oct 2001 08:58:16 +1000 (EST) Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by yarrina.connect.com.au (Postfix) with ESMTP id F257F29F5EB for ; Sat, 6 Oct 2001 07:50:55 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95LlOv22314; Fri, 5 Oct 2001 14:47:24 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 14:46:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95LkHp22229 for linux-xfs-outgoing; Fri, 5 Oct 2001 14:46:17 -0700 Received: from locutus.doe.carleton.ca (locutus.doe.carleton.ca [134.117.9.46]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95LkED22210 for ; Fri, 5 Oct 2001 14:46:14 -0700 Received: from doe.carleton.ca (kelvin [134.117.9.220]) by locutus.doe.carleton.ca (8.10.2+Sun/8.9.1) with ESMTP id f95Lk8I00982 for ; Fri, 5 Oct 2001 17:46:09 -0400 (EDT) Message-ID: <3BBE2A43.3070400@doe.carleton.ca> Date: Fri, 05 Oct 2001 17:46:43 -0400 From: Mike Sowka User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010816 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: WAS: Cluster XFS install without CD... MY APOLOGIES Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Oct 2001 06:00:50.0296 (UTC) FILETIME=[40093F80:01C14E2C] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm sorry it seems I have created some confusion on the list... I should have been a bit more concise in my initial post. The nodes DO have a HD. From the numerous replies I think my task will be an easy one, once I wade through all the hints ppl sent out (THANK YOU) ... Oscar, or systemimager (which is what the tool for intalling acutally is) unfortunately doesn't like my NIC which is a 3CSM905CX-TXM :( so after convincing my peers to use XFS on the cluster I'm sure with all the support I'll have not problem! MSC linux eh... :) Hmmm I'll have to give it a whirl... Thanx, Mike -- /************************************************************************\ | Mike Sowka o _ _ _ | | An Aspiring Engi"Nerd" _o /\_ _ \\o (_)\__/o (_) | | Carleton University _< \_ _>(_) (_)/<_ \_| \ _|/' \/ | | msowka@doe.carleton.ca (_)>(_) (_) (_) (_) (_)' _\o_ | | (home msowka@home.com) | \************************************************************************/ From owner-linux-xfs@oss.sgi.com Fri Oct 5 23:02:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96629H02274 for linux-xfs-outgoing; Fri, 5 Oct 2001 23:02:09 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9661sD02079 for ; Fri, 5 Oct 2001 23:01:54 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA01029 for ; Fri, 5 Oct 2001 23:02:14 -0700 (PDT) mail_from (ian@WPI.EDU) Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sat, 6 Oct 2001 16:00:53 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10062001-160025-119.MMD@cymax.com.au; Sat, 6 Oct 2001 16:00:25 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sat Oct 6 15:53:53 2001) X-From_: owner-linux-xfs@oss.sgi.com Sat Oct 6 09:23:28 2001 Delivered-To: cymax@smartchat.net.au Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by entoo.connect.com.au (Postfix) with ESMTP id 1293BDD41E for ; Sat, 6 Oct 2001 09:23:28 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95NORY25001; Fri, 5 Oct 2001 16:24:27 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 16:22:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95NMlf24895 for linux-xfs-outgoing; Fri, 5 Oct 2001 16:22:47 -0700 Received: from smtp.WPI.EDU (root@smtp.WPI.EDU [130.215.24.62]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95NMhD24875 for ; Fri, 5 Oct 2001 16:22:43 -0700 Received: from grover.wpi.edu (ian@grover.WPI.EDU [130.215.25.67]) by smtp.WPI.EDU (8.12.1/8.12.1) with ESMTP id f95NMa1Y029796 for ; Fri, 5 Oct 2001 19:22:36 -0400 (EDT) Date: Fri, 5 Oct 2001 19:22:36 -0400 (EDT) From: Ian Cooper To: Subject: XFS and NetBSD Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 06 Oct 2001 06:00:53.0781 (UTC) FILETIME=[421D0450:01C14E2C] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk There is some interest in the BSD community to work on porting the XFS filesystem to the BSD platform (primarily for the sgimips port of NetBSD). However, there are licensing issues related with that. BSD and its derivatives are licensed with a BSD licence (not suprisingly) and the Linux-XFS source code is licensed under the GPL. If a BSD port of XFS was to be integrated into the BSD kernel (NetBSD, in this case), then the source code would have to be relicensed for that use. Is this possible, and if so, how? Thanks. -- Ian Cooper ian@wpi.edu ---------- Forwarded message ---------- Date: Fri, 5 Oct 2001 16:48:03 +0000 From: Joseph Mallett To: Steve Rikli Cc: port-sgimips@netbsd.org Subject: Re: XFS and NetBSD [was Re: News & Installation ideas] On Fri, Oct 05, 2001 at 09:39:33AM -0700, Steve Rikli wrote: > IIRC though, from reading freebsd-fs et al, there *may* be outstanding > src license issues -- i.e. I believe SGI released XFS src under GPL. > The discussion I read in the newsgroups seemed to indicate that might > be a bit of a tangle in porting to *BSD . What I've heard WRT this is that if someone actually ports it to *BSD SGI would be willing to relicense as long as their lawyers okay'd it... This of course hearsay, but I've heard it from a number of sources, if that helps any. From owner-linux-xfs@oss.sgi.com Fri Oct 5 23:01:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9661Uk01741 for linux-xfs-outgoing; Fri, 5 Oct 2001 23:01:30 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9661ED01624 for ; Fri, 5 Oct 2001 23:01:14 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA06781 for ; Fri, 5 Oct 2001 23:01:24 -0700 (PDT) mail_from (kris.buggenhout@skynet.be) Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sat, 6 Oct 2001 16:00:50 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10062001-160018-95.MMD@cymax.com.au; Sat, 6 Oct 2001 16:00:18 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sat Oct 6 15:53:46 2001) X-From_: owner-linux-xfs@oss.sgi.com Sat Oct 6 08:58:36 2001 Delivered-To: cymax@smartchat.net.au Received: from yarrina.connect.com.au (yarrina.connect.com.au [192.189.54.17]) by entoo.connect.com.au (Postfix) with ESMTP id D6BFFDEA86 for ; Sat, 6 Oct 2001 08:58:19 +1000 (EST) Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by yarrina.connect.com.au (Postfix) with ESMTP id 94E7329E560 for ; Sat, 6 Oct 2001 06:39:21 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95KZqB19261; Fri, 5 Oct 2001 13:35:52 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 13:34:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95KYsL19164 for linux-xfs-outgoing; Fri, 5 Oct 2001 13:34:54 -0700 Received: from borg-cube.no-ip.com (IDENT:root@adsl-45637.turboline.skynet.be [217.136.50.69]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95KYnD19143 for ; Fri, 5 Oct 2001 13:34:49 -0700 Received: from skynet.be (IDENT:kris@borg-cube.no-ip.com [127.0.0.1]) by borg-cube.no-ip.com (8.11.2/8.11.2) with ESMTP id f95KSGK02139; Fri, 5 Oct 2001 22:28:16 +0200 Message-ID: <3BBE17E0.6167B4E7@skynet.be> Date: Fri, 05 Oct 2001 22:28:16 +0200 From: kris buggenhout X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.10-pre10-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Juri Haberland , "linux-xfs@oss.sgi.com" Subject: Re: Cluster XFS install without CD... References: <3BBE0646.6050000@doe.carleton.ca> <3BBE0EA7.B9BDE73B@koschikode.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Oct 2001 06:00:50.0609 (UTC) FILETIME=[40390210:01C14E2C] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Juri Haberland wrote: > Mike Sowka wrote: > > > > Hello, > > Ok... I realize I should RTFM but I was hoping someone could just point > > me in the right direction. I've been working with XFS since it's 1.0 > > release, needless to say ... IT ROCKS. Now that I've been put in charge > > on building a computing cluster at school I'd like to use XFS for my > > cluster nodes. So far...: > > - I've intalled the main node with RH7.1 XFS-1.0.1 using the CD media > > (got a boot disk as well ofcourse) > > - and now I have no clue how to go about installing XFS RH7.1 base > > systems that have NOTHING but a floppy dirve... :) I could install a > > video card on each for the sake of install but other than that all I > > have is the boot disk... any ideas how I should go about this? XFS dump > > maybe? > > Hi Mike, > > I just did it today, it was pretty easy. You only have to have a NFS > server from where you install with your floppy: > On the NFS server create a directory where you copy all files from the > first and second RedHat CDs to. After that, copy all files from the SGI > CD over this directoy - overwrite as needed. > Then create an install floppy disk from the bootnet.img file that you'll > find in images/. > > Boot the machine that should be installed from this disk and follow the > instructions for an install via NFS. > That's it. > > Juri linux terminal server project :http://www.ltsp.org/ or : http://ClusterNFS.sourceforge.net/ or : http://netboot.sourceforge.net/english/index.shtml additionally look at : http://www.solucorp.qc.ca/xterminals/ SQN Linux From owner-linux-xfs@oss.sgi.com Fri Oct 5 23:02:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9662LI02381 for linux-xfs-outgoing; Fri, 5 Oct 2001 23:02:21 -0700 Received: from sgi.com ([192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9662ED02336 for ; Fri, 5 Oct 2001 23:02:14 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA05480 for ; Fri, 5 Oct 2001 23:02:26 -0700 (PDT) mail_from (jfm2@club-internet.fr) Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sat, 6 Oct 2001 16:00:55 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10062001-160027-129.MMD@cymax.com.au; Sat, 6 Oct 2001 16:00:27 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sat Oct 6 15:53:56 2001) X-From_: owner-linux-xfs@oss.sgi.com Sat Oct 6 10:00:45 2001 Delivered-To: cymax@smartchat.net.au Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by entoo.connect.com.au (Postfix) with ESMTP id 6F163DD3DF for ; Sat, 6 Oct 2001 10:00:44 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9601t726051; Fri, 5 Oct 2001 17:01:55 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 17:00:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9600r725946 for linux-xfs-outgoing; Fri, 5 Oct 2001 17:00:53 -0700 Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9600nD25927 for ; Fri, 5 Oct 2001 17:00:49 -0700 Received: from club-internet.fr (bas12-117.idf.club-internet.fr [213.44.252.117]) by relay-4v.club-internet.fr (Postfix) with ESMTP id E78D316CB; Sat, 6 Oct 2001 02:00:46 +0200 (CEST) Message-ID: <3BBE4DAC.AA3B0C85@club-internet.fr> Date: Sat, 06 Oct 2001 02:17:49 +0200 From: Jean Francois Martinez X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.5-SGI_XFS_1.0.1_Indy i586) X-Accept-Language: en MIME-Version: 1.0 To: Ian Cooper Cc: linux-xfs@oss.sgi.com Subject: Re: XFS and NetBSD References: Content-Type: text/plain; charset=iso-8859-1 X-OriginalArrivalTime: 06 Oct 2001 06:00:55.0046 (UTC) FILETIME=[42DE0A60:01C14E2C] X-MIME-Autoconverted: from 8bit to quoted-printable by sgi.com id XAA05480 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f9662GD02340 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ian Cooper a écrit : > There is some interest in the BSD community to work on porting the XFS > filesystem to the BSD platform (primarily for the sgimips port of NetBSD). > However, there are licensing issues related with that. BSD and its > derivatives are licensed with a BSD licence (not suprisingly) and the > Linux-XFS source code is licensed under the GPL. > > If a BSD port of XFS was to be integrated into the BSD kernel (NetBSD, in > this case), then the source code would have to be relicensed for that use. > Is this possible, and if so, how? > One of the nice things in GPL is that it does not allow SGI competitors to steal SGI's crown jewels unless they relinquish THEIR code jewels. With BSD license SGI could find its code has been used in say Solaris without Sun giving anything Another point is that if someone not from SGI contributed code to XFS then SGI would need either to get his agreement or to rewrite his code before thinking in relicensing. JFM From owner-linux-xfs@oss.sgi.com Fri Oct 5 23:09:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f965wWM00322 for linux-xfs-outgoing; Fri, 5 Oct 2001 22:58:32 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f965wMD32620 for ; Fri, 5 Oct 2001 22:58:22 -0700 Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sat, 6 Oct 2001 16:00:47 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10062001-160011-72.MMD@cymax.com.au; Sat, 6 Oct 2001 16:00:11 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sat Oct 6 15:53:39 2001) X-From_: owner-linux-xfs@oss.sgi.com Sat Oct 6 08:36:00 2001 Delivered-To: cymax@smartchat.net.au Received: from yarrina.connect.com.au (yarrina.connect.com.au [192.189.54.17]) by entoo.connect.com.au (Postfix) with ESMTP id 8B84FE00B6 for ; Sat, 6 Oct 2001 08:29:08 +1000 (EST) Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by yarrina.connect.com.au (Postfix) with ESMTP id E956629FD68 for ; Sat, 6 Oct 2001 08:20:30 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95MHU523250; Fri, 5 Oct 2001 15:17:30 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 15:16:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95MGIE23145 for linux-xfs-outgoing; Fri, 5 Oct 2001 15:16:18 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95MGFD23125 for ; Fri, 5 Oct 2001 15:16:15 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id AAA16674; Sat, 6 Oct 2001 00:16:11 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id AAA12861; Sat, 6 Oct 2001 00:16:11 +0200 (CEST) Date: Sat, 6 Oct 2001 00:16:11 +0200 (CEST) From: Seth Mos To: David Schwartz Cc: Rik van Riel , Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: %u-order allocation failed In-Reply-To: <20011005220627.AAA22897@shell.webmaster.com@whenever> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 06 Oct 2001 06:00:47.0203 (UTC) FILETIME=[3E314B30:01C14E2C] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 5 Oct 2001, David Schwartz wrote: > > >The system is beafy enough to tolerate something mundane as this. It should > >definitely not die. > > A fork bomb with no limits attempts to create an infinite number of > processes. No system can be that beefy. I was refering to the mundane load of mongo.pl with 5 processes. Something the systems should withstand. If you have more then 10GB of database to access you would want it to work. I am not talking about a lot of processes but a lot of disk IO. I have just one box running SMP with highmem and that one is acting funny. All the other SMP ur Uni servers have absolutely no problems. Disable highmem and the problem goes away while halving your ram. That is not very efficient is it? Cheers From owner-linux-xfs@oss.sgi.com Fri Oct 5 23:10:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f965wOX32651 for linux-xfs-outgoing; Fri, 5 Oct 2001 22:58:24 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f965wID32573 for ; Fri, 5 Oct 2001 22:58:18 -0700 Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sat, 6 Oct 2001 16:00:46 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10062001-160011-69.MMD@cymax.com.au; Sat, 6 Oct 2001 16:00:11 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sat Oct 6 15:53:39 2001) X-From_: owner-linux-xfs@oss.sgi.com Sat Oct 6 08:33:28 2001 Delivered-To: cymax@smartchat.net.au Received: from yarrina.connect.com.au (yarrina.connect.com.au [192.189.54.17]) by entoo.connect.com.au (Postfix) with ESMTP id 689B4DFC05 for ; Sat, 6 Oct 2001 08:28:18 +1000 (EST) Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by yarrina.connect.com.au (Postfix) with ESMTP id F09B329FC63 for ; Sat, 6 Oct 2001 08:16:08 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95MCbC23022; Fri, 5 Oct 2001 15:12:37 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 15:11:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95MBa322910 for linux-xfs-outgoing; Fri, 5 Oct 2001 15:11:36 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95MBWD22889 for ; Fri, 5 Oct 2001 15:11:32 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id AAA13875; Sat, 6 Oct 2001 00:11:30 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id AAA12716; Sat, 6 Oct 2001 00:11:30 +0200 (CEST) Date: Sat, 6 Oct 2001 00:11:29 +0200 (CEST) From: Seth Mos To: Mike Sowka Cc: linux-xfs@oss.sgi.com Subject: Re: WAS: Cluster XFS install without CD... MY APOLOGIES In-Reply-To: <3BBE2A43.3070400@doe.carleton.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 06 Oct 2001 06:00:46.0875 (UTC) FILETIME=[3DFF3EB0:01C14E2C] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 5 Oct 2001, Mike Sowka wrote: > I'm sorry it seems I have created some confusion on the list... I should > have been a bit more concise in my initial post. The nodes DO have a HD. That makes sense when metioning it in on a fs list. > From the numerous replies I think my task will be an easy one, once I > wade through all the hints ppl sent out (THANK YOU) ... Oscar, or > systemimager (which is what the tool for intalling acutally is) It is a shame that tools Like Symantec Ghost are really slow in taking up on different filesystems. ReiserFS or XFS are unsupported. ext2 is your only choice for most commercial tools. > unfortunately doesn't like my NIC which is a 3CSM905CX-TXM :( so after What does it not like? > convincing my peers to use XFS on the cluster I'm sure with all the > support I'll have not problem! MSC linux eh... :) Hmmm I'll have to > give it a whirl... Good luck. Seth From owner-linux-xfs@oss.sgi.com Fri Oct 5 23:11:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9661Yt01804 for linux-xfs-outgoing; Fri, 5 Oct 2001 23:01:34 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9661PD01689 for ; Fri, 5 Oct 2001 23:01:25 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA03993 for ; Fri, 5 Oct 2001 23:01:37 -0700 (PDT) mail_from (knuffie@xs4all.nl) Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sat, 6 Oct 2001 16:00:52 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10062001-160022-109.MMD@cymax.com.au; Sat, 6 Oct 2001 16:00:22 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sat Oct 6 15:53:50 2001) X-From_: owner-linux-xfs@oss.sgi.com Sat Oct 6 09:00:32 2001 Delivered-To: cymax@smartchat.net.au Received: from yarrina.connect.com.au (yarrina.connect.com.au [192.189.54.17]) by entoo.connect.com.au (Postfix) with ESMTP id 69A18E0070 for ; Sat, 6 Oct 2001 08:59:38 +1000 (EST) Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by yarrina.connect.com.au (Postfix) with ESMTP id 62FC229CB72 for ; Sat, 6 Oct 2001 06:36:37 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95KWjr19040; Fri, 5 Oct 2001 13:32:45 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 13:31:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95KVoW18951 for linux-xfs-outgoing; Fri, 5 Oct 2001 13:31:50 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95KVlD18931 for ; Fri, 5 Oct 2001 13:31:47 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id WAA15741; Fri, 5 Oct 2001 22:31:39 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id WAA06251; Fri, 5 Oct 2001 22:31:38 +0200 (CEST) Date: Fri, 5 Oct 2001 22:31:38 +0200 (CEST) From: Seth Mos To: Rik van Riel Cc: Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: %u-order allocation failed In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 06 Oct 2001 06:00:52.0593 (UTC) FILETIME=[4167BE10:01C14E2C] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 5 Oct 2001, Rik van Riel wrote: > On Fri, 5 Oct 2001, Seth Mos wrote: > > > This happens using either 2.4.10-xfs or 2.4.11-pre3-xfs. > > Ohh duh, IIRC there are a bunch of highmem bugs in > -linus which are fixed in -ac. Fitting XFS onto a -ac kernel should be fun :-( I will try this over the weekend or get a redhat kernel going which is also -ac based. That would come in handy for other people using XFS since a lot are using highmem in combination with this fs. > Can you reproduce the bug with an -ac kernel ? I am not that good/fast at patching. Expect something over the weekend :-) Bye Seth From owner-linux-xfs@oss.sgi.com Fri Oct 5 23:12:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9662Aa02294 for linux-xfs-outgoing; Fri, 5 Oct 2001 23:02:10 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9661uD02127 for ; Fri, 5 Oct 2001 23:01:56 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA00781 for ; Fri, 5 Oct 2001 23:02:24 -0700 (PDT) mail_from (ian.nelson@echostar.com) Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sat, 6 Oct 2001 16:00:54 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10062001-160026-123.MMD@cymax.com.au; Sat, 6 Oct 2001 16:00:26 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sat Oct 6 15:53:54 2001) X-From_: owner-linux-xfs@oss.sgi.com Sat Oct 6 09:29:18 2001 Delivered-To: cymax@smartchat.net.au Received: from yarrina.connect.com.au (yarrina.connect.com.au [192.189.54.17]) by entoo.connect.com.au (Postfix) with ESMTP id 28669DFBFC for ; Sat, 6 Oct 2001 09:29:17 +1000 (EST) Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by yarrina.connect.com.au (Postfix) with ESMTP id 8865B29EBA5 for ; Sat, 6 Oct 2001 07:09:24 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95L5qU20744; Fri, 5 Oct 2001 14:05:52 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 14:04:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95L4sh20646 for linux-xfs-outgoing; Fri, 5 Oct 2001 14:04:54 -0700 Received: from linux0.echostar.com (w146-253.echostar.com [205.172.146.253]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95L4oD20627 for ; Fri, 5 Oct 2001 14:04:50 -0700 Received: from echostar.com (linux10.echostar.com [10.79.98.110]) by linux0.echostar.com (Postfix) with ESMTP id 1005379085 for ; Fri, 5 Oct 2001 15:04:40 -0600 (MDT) Message-ID: <3BBE206A.5FA9877@echostar.com> Date: Fri, 05 Oct 2001 15:04:42 -0600 From: "Ian S. Nelson" Reply-To: ian.nelson@echostar.com Organization: Echostar X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.4.3 i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-xfs@oss.sgi.com" Subject: Wierd errors with sync Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Oct 2001 06:00:54.0296 (UTC) FILETIME=[426B9980:01C14E2C] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm debugging a bizarro set of kernel bugs and I think XFS may have something to do with it. I've got a system with all XFS on it. /dev/hda1 is a primary partition 200MB. /dev/hda2 is an extendo partition to the end of the disk. /dev/hda5 /dev/hda6 /dev/hda7 and /dev/hda8 are all logical partitions in /dev/hda2. /dev/hda7 is swapper. So I can go into /dev/hda8 and I can do an "echo foobar >ian; cat ian" and it shows up. If I do a sync and then "cat ian" nothing. The same thing is true for hda6. hda5 and hda1 behave like normal. Any ideas what this could be. My gut is the partition table but that looks okay to me. I'm getting beat up by mgmt on this so I'm just begging for any ideas that anyone might have.. thanks, Ian From owner-linux-xfs@oss.sgi.com Fri Oct 5 23:14:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f965wSo32687 for linux-xfs-outgoing; Fri, 5 Oct 2001 22:58:28 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f965wJD32579 for ; Fri, 5 Oct 2001 22:58:20 -0700 Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sat, 6 Oct 2001 16:00:46 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10062001-160011-70.MMD@cymax.com.au; Sat, 6 Oct 2001 16:00:11 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sat Oct 6 15:53:39 2001) X-From_: owner-linux-xfs@oss.sgi.com Sat Oct 6 08:35:44 2001 Delivered-To: cymax@smartchat.net.au Received: from yarrina.connect.com.au (yarrina.connect.com.au [192.189.54.17]) by entoo.connect.com.au (Postfix) with ESMTP id 3C0F0F6FC7 for ; Sat, 6 Oct 2001 08:30:27 +1000 (EST) Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by yarrina.connect.com.au (Postfix) with ESMTP id 6CEBB29C3D7 for ; Sat, 6 Oct 2001 06:04:39 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95JxTV17027; Fri, 5 Oct 2001 12:59:29 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 12:58:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95JwYG16640 for linux-xfs-outgoing; Fri, 5 Oct 2001 12:58:34 -0700 Received: from burgers (IDENT:postfix@burgers.bubbanfriends.org [216.140.122.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95JwUD16616 for ; Fri, 5 Oct 2001 12:58:30 -0700 Received: by burgers (Postfix, from userid 500) id EADAB4001C1; Fri, 5 Oct 2001 15:58:29 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by burgers (Postfix) with ESMTP id E94C72400080; Fri, 5 Oct 2001 15:58:29 -0400 (EDT) Date: Fri, 5 Oct 2001 15:58:29 -0400 (EDT) From: Mike Burger To: Juri Haberland Cc: Mike Sowka , Subject: Re: Cluster XFS install without CD... In-Reply-To: <3BBE0EA7.B9BDE73B@koschikode.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 06 Oct 2001 06:00:46.0968 (UTC) FILETIME=[3E0D6F80:01C14E2C] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 5 Oct 2001, Juri Haberland wrote: > Mike Sowka wrote: > > > > Hello, > > Ok... I realize I should RTFM but I was hoping someone could just point > > me in the right direction. I've been working with XFS since it's 1.0 > > release, needless to say ... IT ROCKS. Now that I've been put in charge > > on building a computing cluster at school I'd like to use XFS for my > > cluster nodes. So far...: > > - I've intalled the main node with RH7.1 XFS-1.0.1 using the CD media > > (got a boot disk as well ofcourse) > > - and now I have no clue how to go about installing XFS RH7.1 base > > systems that have NOTHING but a floppy dirve... :) I could install a > > video card on each for the sake of install but other than that all I > > have is the boot disk... any ideas how I should go about this? XFS dump > > maybe? > > Hi Mike, > > I just did it today, it was pretty easy. You only have to have a NFS > server from where you install with your floppy: > On the NFS server create a directory where you copy all files from the > first and second RedHat CDs to. After that, copy all files from the SGI > CD over this directoy - overwrite as needed. > Then create an install floppy disk from the bootnet.img file that you'll > find in images/. > > Boot the machine that should be installed from this disk and follow the > instructions for an install via NFS. > That's it. I don't think that's what he wants to do. He basically wants the other systems to have no hard drive...instead, he wants them to run off of the first system. From owner-linux-xfs@oss.sgi.com Fri Oct 5 23:15:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9661k301954 for linux-xfs-outgoing; Fri, 5 Oct 2001 23:01:46 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9661eD01895 for ; Fri, 5 Oct 2001 23:01:40 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA06367 for ; Fri, 5 Oct 2001 23:01:54 -0700 (PDT) mail_from (lord@sgi.com) Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sat, 6 Oct 2001 16:00:53 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10062001-160023-114.MMD@cymax.com.au; Sat, 6 Oct 2001 16:00:23 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sat Oct 6 15:53:51 2001) X-From_: owner-linux-xfs@oss.sgi.com Sat Oct 6 09:11:17 2001 Delivered-To: cymax@smartchat.net.au Received: from yarrina.connect.com.au (yarrina.connect.com.au [192.189.54.17]) by entoo.connect.com.au (Postfix) with ESMTP id 87435E0171 for ; Sat, 6 Oct 2001 09:09:26 +1000 (EST) Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by yarrina.connect.com.au (Postfix) with ESMTP id 0485D29E796 for ; Sat, 6 Oct 2001 06:49:49 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95KkHY19767; Fri, 5 Oct 2001 13:46:17 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 13:45:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95KjHh19657 for linux-xfs-outgoing; Fri, 5 Oct 2001 13:45:17 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95KjED19638 for ; Fri, 5 Oct 2001 13:45:14 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA27715 for ; Fri, 5 Oct 2001 13:45:11 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA3155819; Fri, 5 Oct 2001 15:43:48 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA24720; Fri, 5 Oct 2001 15:43:47 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f95KhG307514; Fri, 5 Oct 2001 15:43:16 -0500 Message-Id: <200110052043.f95KhG307514@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Seth Mos Cc: Rik van Riel , Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: %u-order allocation failed In-Reply-To: Message from Seth Mos of "Fri, 05 Oct 2001 22:31:38 +0200." Date: Fri, 05 Oct 2001 15:43:16 -0500 From: Steve Lord X-OriginalArrivalTime: 06 Oct 2001 06:00:53.0156 (UTC) FILETIME=[41BDA640:01C14E2C] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Fri, 5 Oct 2001, Rik van Riel wrote: > > > On Fri, 5 Oct 2001, Seth Mos wrote: > > > > > This happens using either 2.4.10-xfs or 2.4.11-pre3-xfs. > > > > Ohh duh, IIRC there are a bunch of highmem bugs in > > -linus which are fixed in -ac. > > Fitting XFS onto a -ac kernel should be fun :-( Its not that that simple - I tried before I got dragged kicking and screaming back into some Irix stuff. Just running mongo on ext2 on a HIGHMEM ac kernel should show if things are better there - since the problems seem to be fairly filesystem independent. Steve > > I will try this over the weekend or get a redhat kernel going which is > also -ac based. That would come in handy for other people using XFS since > a lot are using highmem in combination with this fs. > > > Can you reproduce the bug with an -ac kernel ? > > I am not that good/fast at patching. Expect something over the weekend :-) > > Bye > Seth From owner-linux-xfs@oss.sgi.com Fri Oct 5 23:15:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9661lC01975 for linux-xfs-outgoing; Fri, 5 Oct 2001 23:01:47 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9661fD01921 for ; Fri, 5 Oct 2001 23:01:41 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA05134 for ; Fri, 5 Oct 2001 23:01:54 -0700 (PDT) mail_from (xfs@s2y4n2c.de) Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sat, 6 Oct 2001 16:00:52 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10062001-160023-112.MMD@cymax.com.au; Sat, 6 Oct 2001 16:00:23 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sat Oct 6 15:53:51 2001) X-From_: owner-linux-xfs@oss.sgi.com Sat Oct 6 09:09:04 2001 Delivered-To: cymax@smartchat.net.au Received: from yarrina.connect.com.au (yarrina.connect.com.au [192.189.54.17]) by entoo.connect.com.au (Postfix) with ESMTP id 045B9DE6AD for ; Sat, 6 Oct 2001 09:08:41 +1000 (EST) Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by yarrina.connect.com.au (Postfix) with ESMTP id CB3B129E6B8 for ; Sat, 6 Oct 2001 06:45:14 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95Kfea19531; Fri, 5 Oct 2001 13:41:40 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 13:40:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95Keg719419 for linux-xfs-outgoing; Fri, 5 Oct 2001 13:40:42 -0700 Received: from moutvdom01.kundenserver.de (moutvdom01.kundenserver.de [195.20.224.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95KebD19399 for ; Fri, 5 Oct 2001 13:40:37 -0700 Received: from [195.20.224.219] (helo=mrvdom03.schlund.de) by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #2) id 15pblr-0000rp-00; Fri, 5 Oct 2001 22:40:35 +0200 Received: from pd958d002.dip.t-dialin.net ([217.88.208.2] helo=kernelpanix.aura.of.mankind) by mrvdom03.schlund.de with esmtp (Exim 2.12 #2) id 15pblr-00026i-00; Fri, 5 Oct 2001 22:40:35 +0200 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.11.2/8.11.2) id f95KeYo21856; Fri, 5 Oct 2001 22:40:34 +0200 X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f Date: Fri, 5 Oct 2001 22:40:34 +0200 From: utz lehmann To: Seth Mos Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.11-pre2-xfs Message-ID: <20011005224034.A21589@s2y4n2c.de> References: <3BBE04A0.64D2A0BA@soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: X-OriginalArrivalTime: 06 Oct 2001 06:00:52.0953 (UTC) FILETIME=[419EAC90:01C14E2C] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Seth Seth Mos [knuffie@xs4all.nl] wrote: > The dell PE 2500 is ServerWorks LE based, 2GB ram with both 2.4.10 and > 2.4.11-pre3. > > The only way to fix it is not using HIGHMEM. As soon as I compile without > HIGHMEM (4GB) the box is stable and does not deadlock or crash even under > heavy load. I have about a month before the system must go into production > so if anyone has some hints or tests I could do they are most welcome. > > I can not get it over my heart to tell that we cannot use half the > memory available. There goes my reputation :-/ Maybe I have a solution for you (and others). I found a patch (linux-2.4.2-vm-1-2-3-gbyte.patch) in the redhat kernel src rpm. It allow you to change the standard vm user/kernel split of 3/1 GB to 2/2 and 1/3 GB. Without a HIGHMEM kernel your max available memory is kernel spilt size - 128MB. 896MB default, and 1920 or 2944MB with the patch. At work we have athlon based CAE workstations and numbercruncher with 1GB or 1.5GB RAM. They running 2.4.7 or 2.4.9 linux-xfs kernels (of course .-) with this patch. I modified the patch to 2.75/1.25 resp. 2.25/1.75GB. So they can use all their memory without HIGHMEM. Advantages are no performance loss due HIGHMEM and *NO* HIGHMEM trouble. Disadvantage is that the possible userspace size per process is reduced. If you don't have big processes it won't be a problem. I saw >1GB sized processes with the 2.25/1.75GB split. hope that helps. utz From owner-linux-xfs@oss.sgi.com Fri Oct 5 23:15:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9661CH01599 for linux-xfs-outgoing; Fri, 5 Oct 2001 23:01:12 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9660xD01494 for ; Fri, 5 Oct 2001 23:00:59 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA01488 for ; Fri, 5 Oct 2001 23:01:10 -0700 (PDT) mail_from (ian.nelson@echostar.com) Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sat, 6 Oct 2001 16:00:49 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10062001-160015-87.MMD@cymax.com.au; Sat, 6 Oct 2001 16:00:15 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sat Oct 6 15:53:43 2001) X-From_: owner-linux-xfs@oss.sgi.com Sat Oct 6 08:50:02 2001 Delivered-To: cymax@smartchat.net.au Received: from yarrina.connect.com.au (yarrina.connect.com.au [192.189.54.17]) by entoo.connect.com.au (Postfix) with ESMTP id C306EE0095 for ; Sat, 6 Oct 2001 08:48:40 +1000 (EST) Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by yarrina.connect.com.au (Postfix) with ESMTP id BEF7E29F271 for ; Sat, 6 Oct 2001 07:36:33 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95LXHE21838; Fri, 5 Oct 2001 14:33:17 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 14:32:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95LWDc21731 for linux-xfs-outgoing; Fri, 5 Oct 2001 14:32:13 -0700 Received: from linux0.echostar.com (w146-253.echostar.com [205.172.146.253]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95LW8D21710 for ; Fri, 5 Oct 2001 14:32:08 -0700 Received: from echostar.com (linux10.echostar.com [10.79.98.110]) by linux0.echostar.com (Postfix) with ESMTP id 1287B79085; Fri, 5 Oct 2001 15:31:58 -0600 (MDT) Message-ID: <3BBE26D0.5EC11066@echostar.com> Date: Fri, 05 Oct 2001 15:32:00 -0600 From: "Ian S. Nelson" Reply-To: ian.nelson@echostar.com Organization: Echostar X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.4.3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Seth Mos Cc: "linux-xfs@oss.sgi.com" Subject: Re: Wierd errors with sync References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Oct 2001 06:00:49.0453 (UTC) FILETIME=[3F889DD0:01C14E2C] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have been seeing kernel BUGs in ll_rw_blk. To my /dev/hda8, requests out of range, or so it would appear. Well it's an embedded platform and we've been slowly turning off items. Here is my new theory. If the drive is blank then I have a flash the detects that and rebuilds it in said flash I do mkfs.xfs and then I do a C library call mount() That mount behaves different from /bin/mount. I'm guessing that's my problem. I'm doing mkfs and then it's not syncing or some such garbage. I'm going to retool my flash and try again. I've taken the problematic partitions and on the running system I've unmounted them and rebuilt them and everything is cool again.. Ian Seth Mos wrote: > On Fri, 5 Oct 2001, Ian S. Nelson wrote: > > > > > I'm debugging a bizarro set of kernel bugs and I think XFS may have > > something to do with it. > > > > I've got a system with all XFS on it. /dev/hda1 is a primary partition > > 200MB. /dev/hda2 is an extendo partition to the end of the disk. > > > > /dev/hda5 /dev/hda6 /dev/hda7 and /dev/hda8 are all logical partitions > > in /dev/hda2. > > /dev/hda7 is swapper. > > > > So I can go into /dev/hda8 and I can do an "echo foobar >ian; cat ian" > > and it shows up. If I do a sync and then "cat ian" nothing. > > The same thing is true for hda6. hda5 and hda1 behave like normal. > > Any ideas what this could be. My gut is the partition table but that > > looks okay to me. I'm getting beat up by mgmt on this so I'm just > > begging for any ideas that anyone might have.. > > It should not happen. Do you have any errors in you /var/log/messages? > Is the whole partiton invisible after a sync? (eg, can you list any files > in there?) > > Since You are using IDE, are you using and tuning options from hdparm? > What chipset does your motherboard have and what IDE chip? > You are certain that the hardware is 100%. > > Can you describe soem hardware configuration bits. > > Cheers From owner-linux-xfs@oss.sgi.com Fri Oct 5 23:16:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96628h02251 for linux-xfs-outgoing; Fri, 5 Oct 2001 23:02:08 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9661iD01945 for ; Fri, 5 Oct 2001 23:01:44 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA06001 for ; Fri, 5 Oct 2001 23:02:11 -0700 (PDT) mail_from (xfs@s2y4n2c.de) Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sat, 6 Oct 2001 16:00:53 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10062001-160023-115.MMD@cymax.com.au; Sat, 6 Oct 2001 16:00:23 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sat Oct 6 15:53:52 2001) X-From_: owner-linux-xfs@oss.sgi.com Sat Oct 6 09:18:47 2001 Delivered-To: cymax@smartchat.net.au Received: from yarrina.connect.com.au (yarrina.connect.com.au [192.189.54.17]) by entoo.connect.com.au (Postfix) with ESMTP id 74912DFDB1 for ; Sat, 6 Oct 2001 09:18:33 +1000 (EST) Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by yarrina.connect.com.au (Postfix) with ESMTP id 9323529EA18 for ; Sat, 6 Oct 2001 07:01:33 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95Kw1K20219; Fri, 5 Oct 2001 13:58:01 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 13:57:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95Kv3m20047 for linux-xfs-outgoing; Fri, 5 Oct 2001 13:57:03 -0700 Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95KuuD20027 for ; Fri, 5 Oct 2001 13:56:58 -0700 Received: from [195.20.224.220] (helo=mrvdom04.kundenserver.de) by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 15pc1b-0000Rd-00; Fri, 5 Oct 2001 22:56:51 +0200 Received: from pd958d002.dip.t-dialin.net ([217.88.208.2] helo=kernelpanix.aura.of.mankind) by mrvdom04.kundenserver.de with esmtp (Exim 2.12 #2) id 15pc1b-0003PM-00; Fri, 5 Oct 2001 22:56:51 +0200 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.11.2/8.11.2) id f95KuoQ22058; Fri, 5 Oct 2001 22:56:50 +0200 X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f Date: Fri, 5 Oct 2001 22:56:50 +0200 From: utz lehmann To: Seth Mos Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.11-pre2-xfs Message-ID: <20011005225650.A22036@s2y4n2c.de> References: <3BBE04A0.64D2A0BA@soton.ac.uk> <20011005224034.A21589@s2y4n2c.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011005224034.A21589@s2y4n2c.de> X-OriginalArrivalTime: 06 Oct 2001 06:00:53.0250 (UTC) FILETIME=[41CBFE20:01C14E2C] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk utz lehmann [xfs@s2y4n2c.de] wrote: > Hi Seth > > Seth Mos [knuffie@xs4all.nl] wrote: > > The dell PE 2500 is ServerWorks LE based, 2GB ram with both 2.4.10 and > > 2.4.11-pre3. > > > > The only way to fix it is not using HIGHMEM. As soon as I compile without > > HIGHMEM (4GB) the box is stable and does not deadlock or crash even under > > heavy load. I have about a month before the system must go into production > > so if anyone has some hints or tests I could do they are most welcome. > > > > I can not get it over my heart to tell that we cannot use half the > > memory available. There goes my reputation :-/ > > Maybe I have a solution for you (and others). > > I found a patch (linux-2.4.2-vm-1-2-3-gbyte.patch) in the redhat kernel src > rpm. It allow you to change the standard vm user/kernel split of 3/1 GB to > 2/2 and 1/3 GB. Without a HIGHMEM kernel your max available memory is kernel > spilt size - 128MB. 896MB default, and 1920 or 2944MB with the patch. > > At work we have athlon based CAE workstations and numbercruncher with 1GB or > 1.5GB RAM. They running 2.4.7 or 2.4.9 linux-xfs kernels (of course .-) with > this patch. I modified the patch to 2.75/1.25 resp. 2.25/1.75GB. So they can > use all their memory without HIGHMEM. > > Advantages are no performance loss due HIGHMEM and *NO* HIGHMEM trouble. > > Disadvantage is that the possible userspace size per process is reduced. > If you don't have big processes it won't be a problem. I saw >1GB sized > processes with the 2.25/1.75GB split. > > > hope that helps. > > utz Please note that I haven't used this patch with 2.4.10. It maybe break things due the new vm. utz From owner-linux-xfs@oss.sgi.com Fri Oct 5 23:17:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f965wlm00513 for linux-xfs-outgoing; Fri, 5 Oct 2001 22:58:47 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f965wSD32693 for ; Fri, 5 Oct 2001 22:58:28 -0700 Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sat, 6 Oct 2001 16:00:54 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10062001-160025-121.MMD@cymax.com.au; Sat, 6 Oct 2001 16:00:25 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sat Oct 6 15:53:53 2001) X-From_: owner-linux-xfs@oss.sgi.com Sat Oct 6 09:28:32 2001 Delivered-To: cymax@smartchat.net.au Received: from yarrina.connect.com.au (yarrina.connect.com.au [192.189.54.17]) by entoo.connect.com.au (Postfix) with ESMTP id 11A24DFA7F for ; Sat, 6 Oct 2001 09:28:32 +1000 (EST) Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by yarrina.connect.com.au (Postfix) with ESMTP id DE2A629E87F for ; Sat, 6 Oct 2001 07:03:30 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95KxhQ20457; Fri, 5 Oct 2001 13:59:43 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 13:58:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95KwmX20358 for linux-xfs-outgoing; Fri, 5 Oct 2001 13:58:48 -0700 Received: from firewall.keyholecorp.com (w194.z064220189.sjc-ca.dsl.cnc.net [64.220.189.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95KweD20337 for ; Fri, 5 Oct 2001 13:58:40 -0700 Received: from core.keyholecorp.com (IDENT:root@core.keyholecorp.com [10.0.3.8]) by firewall.keyholecorp.com (8.11.0/8.11.0) with ESMTP id f95KwdI21208 for ; Fri, 5 Oct 2001 13:58:39 -0700 Received: from akebono (akebono.keyholecorp.com [10.0.3.33]) by core.keyholecorp.com (8.9.3/8.8.7) with SMTP id NAA02402 for ; Fri, 5 Oct 2001 13:58:39 -0700 Message-ID: <001e01c14de1$9cbae940$2103000a@keyholecorp.com> From: "Wayne Thai" To: Subject: kernel panic after installing XFS on a Compaq proliant 6500+Redhat 7.1 Date: Fri, 5 Oct 2001 14:06:33 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01C14DA6.F03EEC50" 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 X-OriginalArrivalTime: 06 Oct 2001 06:00:54.0000 (UTC) FILETIME=[423E6F00:01C14E2C] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C14DA6.F03EEC50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable So I installed the XFS file system RPM's according to the instructions = given on the web, and I have also edited the lilo.conf file in order to = recognize the new file system. I type lilo and then reboot, and i get = the following error. /lib/cparray.o: init_module: Input/output error Hint: insmod errors can be caused bye incorrect module parameters, = including invalid IO or IRQ parameters Error: /bin/insmod exited abnormally! VFS: Cannot open root device "4806" or 48:06 Please append a correct "root=3D" boot option Kernel Panic: VFS: Unable to mount root fs on 48:06 Any suggestions? ------=_NextPart_000_001B_01C14DA6.F03EEC50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
So I installed the XFS file system = RPM's according=20 to the instructions given on the web, and I have also edited the = lilo.conf file=20 in order to recognize the new file system. I type lilo and then reboot, = and i=20 get the following error.
 
/lib/cparray.o: init_module: = Input/output=20 error
Hint: insmod errors can be caused bye = incorrect=20 module parameters, including invalid IO or IRQ parameters
Error: /bin/insmod exited = abnormally!
VFS: Cannot open root device "4806" or=20 48:06
Please append a correct "root=3D" boot=20 option
Kernel Panic: VFS: Unable to mount root = fs on=20 48:06
 
 
 
Any = suggestions?
------=_NextPart_000_001B_01C14DA6.F03EEC50-- From owner-linux-xfs@oss.sgi.com Fri Oct 5 23:18:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9661bj01855 for linux-xfs-outgoing; Fri, 5 Oct 2001 23:01:37 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9661PD01685 for ; Fri, 5 Oct 2001 23:01:25 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA02579 for ; Fri, 5 Oct 2001 23:01:26 -0700 (PDT) mail_from (kris.buggenhout@skynet.be) Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sat, 6 Oct 2001 16:00:52 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10062001-160021-108.MMD@cymax.com.au; Sat, 6 Oct 2001 16:00:21 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sat Oct 6 15:53:49 2001) X-From_: owner-linux-xfs@oss.sgi.com Sat Oct 6 09:00:12 2001 Delivered-To: cymax@smartchat.net.au Received: from yarrina.connect.com.au (yarrina.connect.com.au [192.189.54.17]) by entoo.connect.com.au (Postfix) with ESMTP id E7F54E00B1 for ; Sat, 6 Oct 2001 08:58:54 +1000 (EST) Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by yarrina.connect.com.au (Postfix) with ESMTP id 3817C29CAD8 for ; Sat, 6 Oct 2001 06:34:57 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95KUR418871; Fri, 5 Oct 2001 13:30:27 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 13:29:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95KTVe18772 for linux-xfs-outgoing; Fri, 5 Oct 2001 13:29:31 -0700 Received: from borg-cube.no-ip.com (IDENT:root@adsl-45637.turboline.skynet.be [217.136.50.69]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95KTND18752 for ; Fri, 5 Oct 2001 13:29:24 -0700 Received: from skynet.be (IDENT:kris@borg-cube.no-ip.com [127.0.0.1]) by borg-cube.no-ip.com (8.11.2/8.11.2) with ESMTP id f95KMsK02127 for ; Fri, 5 Oct 2001 22:22:54 +0200 Message-ID: <3BBE169E.DC625209@skynet.be> Date: Fri, 05 Oct 2001 22:22:54 +0200 From: kris buggenhout X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.10-pre10-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-xfs@oss.sgi.com" Subject: [Fwd: Cluster XFS install without CD...] Content-Type: multipart/mixed; boundary="------------DFAA89D6F50E546A0D24DF55" X-OriginalArrivalTime: 06 Oct 2001 06:00:52.0359 (UTC) FILETIME=[41440970:01C14E2C] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------DFAA89D6F50E546A0D24DF55 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------DFAA89D6F50E546A0D24DF55 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mozilla-Status2: 00000000 Message-ID: <3BBE1686.F3DD2C8@skynet.be> Date: Fri, 05 Oct 2001 22:22:30 +0200 From: kris buggenhout X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.10-pre10-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Juri Haberland Subject: Re: Cluster XFS install without CD... References: <3BBE13CE.E6992BC4@koschikode.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Juri Haberland wrote: > Mike Burger wrote: > > > > On Fri, 5 Oct 2001, Juri Haberland wrote: > > > > > Mike Sowka wrote: > > > > > > > > Hello, > > > > Ok... I realize I should RTFM but I was hoping someone could just point > > > > me in the right direction. I've been working with XFS since it's 1.0 > > > > release, needless to say ... IT ROCKS. Now that I've been put in charge > > > > on building a computing cluster at school I'd like to use XFS for my > > > > cluster nodes. So far...: > > > > - I've intalled the main node with RH7.1 XFS-1.0.1 using the CD media > > > > (got a boot disk as well ofcourse) > > > > - and now I have no clue how to go about installing XFS RH7.1 base > > > > systems that have NOTHING but a floppy dirve... :) I could install a > > > > video card on each for the sake of install but other than that all I > > > > have is the boot disk... any ideas how I should go about this? XFS dump > > > > maybe? > > > > > > Hi Mike, > > > > > > I just did it today, it was pretty easy. You only have to have a NFS > > > server from where you install with your floppy: > > > On the NFS server create a directory where you copy all files from the > > > first and second RedHat CDs to. After that, copy all files from the SGI > > > CD over this directoy - overwrite as needed. > > > Then create an install floppy disk from the bootnet.img file that you'll > > > find in images/. > > > > > > Boot the machine that should be installed from this disk and follow the > > > instructions for an install via NFS. > > > That's it. > > > > I don't think that's what he wants to do. He basically wants the other > > systems to have no hard drive...instead, he wants them to run off of the > > first system. > > Ahh, should read more carefully... > > Thanks, > Juri Think U have to take a look at the diskless client ... http://www.ltsp.org/ --------------DFAA89D6F50E546A0D24DF55-- From owner-linux-xfs@oss.sgi.com Fri Oct 5 23:25:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f966PPJ05269 for linux-xfs-outgoing; Fri, 5 Oct 2001 23:25:25 -0700 Received: from monkeyiq.dnsalias.org (CPE-203-45-214-174.qld.bigpond.net.au [203.45.214.174]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f966PHD05249 for ; Fri, 5 Oct 2001 23:25:17 -0700 Received: by monkeyiq.dnsalias.org id f966OeV30354 ; Sat, 6 Oct 2001 16:24:40 +1000 Date: Sat, 6 Oct 2001 16:24:40 +1000 Message-Id: <200110060624.f966OeV30354@monkeyiq.dnsalias.org> To: linux-xfs@oss.sgi.com Subject: ENOATTR and other error enums From: monkeyiq MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Anyone know where these are defined in Linux? I dont seem to be able to find them, even with find/grep in /usr/include. Also, is there a function to get a string rep of the error that occured in the attr code? Thanks. ----------------------------------------------------- choose ferris. http://witme.sourceforge.net/libferris.web/ From owner-linux-xfs@oss.sgi.com Fri Oct 5 23:45:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f966j2x05778 for linux-xfs-outgoing; Fri, 5 Oct 2001 23:45:02 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f966itD05741 for ; Fri, 5 Oct 2001 23:44:55 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 8746DC00B63 for ; Sat, 6 Oct 2001 14:44:52 +0800 (PHT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 3E66AC00B60 for ; Sat, 6 Oct 2001 14:44:51 +0800 (PHT) Date: Sat, 6 Oct 2001 14:44:51 +0800 (PHT) From: Federico Sevilla III To: Linux XFS Mailing List Subject: We have a mail loop! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I thought it was just me but I don't think it is. A member of the mailing list, , has a mail loop on us it seems. See this trail in the received headers: Return-Path: Delivered-To: jijo@leathercollection.ph Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 02BE8C00B63 for ; Sat, 6 Oct 2001 14:13:44 +0800 (PHT) Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by gusi.leathercollection.ph (Postfix) with ESMTP id 92924C00B60 for ; Sat, 6 Oct 2001 14:13:41 +0800 (PHT) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f966CDx03773; Fri, 5 Oct 2001 23:12:13 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 23:12:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9662Aa02294 for linux-xfs-outgoing; Fri, 5 Oct 2001 23:02:10 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9661uD02127 for ; Fri, 5 Oct 2001 23:01:56 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA00781 for ; Fri, 5 Oct 2001 23:02:24 -0700 (PDT) mail_from (ian.nelson@echostar.com) Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sat, 6 Oct 2001 16:00:54 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10062001-160026-123.MMD@cymax.com.au; Sat, 6 Oct 2001 16:00:26 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sat Oct 6 15:53:54 2001) X-From_: owner-linux-xfs@oss.sgi.com Sat Oct 6 09:29:18 2001 Delivered-To: cymax@smartchat.net.au Received: from yarrina.connect.com.au (yarrina.connect.com.au [192.189.54.17]) by entoo.connect.com.au (Postfix) with ESMTP id 28669DFBFC for ; Sat, 6 Oct 2001 09:29:17 +1000 (EST) Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by yarrina.connect.com.au (Postfix) with ESMTP id 8865B29EBA5 for ; Sat, 6 Oct 2001 07:09:24 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95L5qU20744; Fri, 5 Oct 2001 14:05:52 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 14:04:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95L4sh20646 for linux-xfs-outgoing; Fri, 5 Oct 2001 14:04:54 -0700 Received: from linux0.echostar.com (w146-253.echostar.com [205.172.146.253]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95L4oD20627 for ; Fri, 5 Oct 2001 14:04:50 -0700 Received: from echostar.com (linux10.echostar.com [10.79.98.110]) by linux0.echostar.com (Postfix) with ESMTP id 1005379085 for ; Fri, 5 Oct 2001 15:04:40 -0600 (MDT) From owner-linux-xfs@oss.sgi.com Sat Oct 6 00:22:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f967MfW06671 for linux-xfs-outgoing; Sat, 6 Oct 2001 00:22:41 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f967MZD06649 for ; Sat, 6 Oct 2001 00:22:35 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA09948 for ; Fri, 5 Oct 2001 23:02:25 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sat, 6 Oct 2001 16:00:54 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10062001-160027-127.MMD@cymax.com.au; Sat, 6 Oct 2001 16:00:27 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sat Oct 6 15:53:55 2001) X-From_: owner-linux-xfs@oss.sgi.com Sat Oct 6 09:48:24 2001 Delivered-To: cymax@smartchat.net.au Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by entoo.connect.com.au (Postfix) with ESMTP id 9F047DFB8B for ; Sat, 6 Oct 2001 09:48:23 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95NnxS25658; Fri, 5 Oct 2001 16:49:59 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 16:48:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95Nmg525513 for linux-xfs-outgoing; Fri, 5 Oct 2001 16:48:42 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95NmcD25494 for ; Fri, 5 Oct 2001 16:48:38 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA01868 for ; Fri, 5 Oct 2001 16:47:34 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id QAA93643; Fri, 5 Oct 2001 16:48:05 -0700 (PDT) Message-ID: <3BBE45E7.CE3B12F9@sgi.com> Date: Fri, 05 Oct 2001 18:44:39 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: Ian Cooper Cc: linux-xfs@oss.sgi.com Subject: Re: XFS and NetBSD References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Oct 2001 06:00:54.0859 (UTC) FILETIME=[42C181B0:01C14E2C] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This has been discussed a few times on this list, and I'm sure Russell will chime in as well... :) But the bottom line is usually that it would cost SGI time, money and lawyers to relicense the code, and unless there is a compelling business reason to do so (i.e. perceived financial gain for SGI - or at least no financial loss), it probably won't happen. Getting XFS released under the GPL was a herculean effort in the first place, and getting it re-licensed would re-visit a lot of that effort. I can't speak officialy for SGI in this matter (probably no-one on this list can), but it's highly unlikely that SGI will spend the resources necessary to make a change like this. I know that sounds like corporate-speak, and I know how frustrating it can be, I've been on the other end of it for some projects I was interested in - but it's probably the reality today. -Eric Ian Cooper wrote: > > There is some interest in the BSD community to work on porting the XFS > filesystem to the BSD platform (primarily for the sgimips port of NetBSD). > However, there are licensing issues related with that. BSD and its > derivatives are licensed with a BSD licence (not suprisingly) and the > Linux-XFS source code is licensed under the GPL. > > If a BSD port of XFS was to be integrated into the BSD kernel (NetBSD, in > this case), then the source code would have to be relicensed for that use. > Is this possible, and if so, how? -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Sat Oct 6 02:11:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f969BIx08709 for linux-xfs-outgoing; Sat, 6 Oct 2001 02:11:18 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f969BFD08689 for ; Sat, 6 Oct 2001 02:11:15 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id CAA01317 for ; Sat, 6 Oct 2001 02:11:34 -0700 (PDT) mail_from (ivanr@sgi.com) Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA10104; Sat, 6 Oct 2001 19:09:45 +1000 From: ivanr@sgi.com Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id TAA23303; Sat, 6 Oct 2001 19:09:44 +1000 (EST) X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs Date: Sat, 6 Oct 2001 19:09:44 +1000 X-X-Sender: ivanr@omen.melbourne.sgi.com To: Seth Mos cc: linux-xfs@oss.sgi.com Subject: Re: Cluster XFS install without CD... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 5 Oct 2001, Seth Mos wrote: > There is a link that I just added to the FAQ for cloning XFS systems. It > is called "partition image" > > Maybe that will help. Perhaps you should add that it'd be a good idea to use xfs_admin (xfs_db) to change the uuid for the copied filesystems (unless there is a specific need for each filesystem to be an exact copy). Ivan -- Ivan Rayner ivanr@sgi.com From owner-linux-xfs@oss.sgi.com Sat Oct 6 02:33:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f969Xs309365 for linux-xfs-outgoing; Sat, 6 Oct 2001 02:33:54 -0700 Received: from smtp3.xs4all.nl (smtp3.xs4all.nl [194.109.127.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f969XoD09346 for ; Sat, 6 Oct 2001 02:33:50 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtp3.xs4all.nl (8.9.3/8.9.3) with ESMTP id LAA14389; Sat, 6 Oct 2001 11:33:14 +0200 (CEST) Message-Id: <4.3.2.7.2.20011006112644.04058458@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 06 Oct 2001 11:31:51 +0200 To: ivanr@sgi.com From: Seth Mos Subject: Re: Cluster XFS install without CD... Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 19:09 6-10-2001 +1000, ivanr@sgi.com wrote: >On Fri, 5 Oct 2001, Seth Mos wrote: > > > There is a link that I just added to the FAQ for cloning XFS systems. It > > is called "partition image" > > > > Maybe that will help. > >Perhaps you should add that it'd be a good idea to use xfs_admin >(xfs_db) to change the uuid for the copied filesystems (unless there is >a specific need for each filesystem to be an exact copy). Most of the time you would be cloning a XFS filesystem to quickly setup another box. If this is the case it would not matter would it? Only if you would clone a fs from one partition to another on the same box you would hit this. I will add something like this to the faq. I have a high Deja-Vu feeling while reading up on my morning email. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Sat Oct 6 06:57:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96Dvul14441 for linux-xfs-outgoing; Sat, 6 Oct 2001 06:57:56 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96DvoD14406 for ; Sat, 6 Oct 2001 06:57:50 -0700 Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sun, 7 Oct 2001 00:00:15 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10072001-000012-217.MMD@cymax.com.au; Sun, 7 Oct 2001 00:00:12 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sat Oct 6 23:53:40 2001) X-From_: owner-linux-xfs@oss.sgi.com Sat Oct 6 19:35:02 2001 Delivered-To: cymax@smartchat.net.au Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by entoo.connect.com.au (Postfix) with ESMTP id BC80ADDF33 for ; Sat, 6 Oct 2001 19:35:01 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f969Ywo09468; Sat, 6 Oct 2001 02:34:58 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Sat, 6 Oct 2001 02:33:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f969Xs309365 for linux-xfs-outgoing; Sat, 6 Oct 2001 02:33:54 -0700 Received: from smtp3.xs4all.nl (smtp3.xs4all.nl [194.109.127.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f969XoD09346 for ; Sat, 6 Oct 2001 02:33:50 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtp3.xs4all.nl (8.9.3/8.9.3) with ESMTP id LAA14389; Sat, 6 Oct 2001 11:33:14 +0200 (CEST) Message-Id: <4.3.2.7.2.20011006112644.04058458@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 06 Oct 2001 11:31:51 +0200 To: ivanr@sgi.com From: Seth Mos Subject: Re: Cluster XFS install without CD... Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 06 Oct 2001 14:00:15.0921 (UTC) FILETIME=[39AF4A10:01C14E6F] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 19:09 6-10-2001 +1000, ivanr@sgi.com wrote: >On Fri, 5 Oct 2001, Seth Mos wrote: > > > There is a link that I just added to the FAQ for cloning XFS systems. It > > is called "partition image" > > > > Maybe that will help. > >Perhaps you should add that it'd be a good idea to use xfs_admin >(xfs_db) to change the uuid for the copied filesystems (unless there is >a specific need for each filesystem to be an exact copy). Most of the time you would be cloning a XFS filesystem to quickly setup another box. If this is the case it would not matter would it? Only if you would clone a fs from one partition to another on the same box you would hit this. I will add something like this to the faq. I have a high Deja-Vu feeling while reading up on my morning email. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Sat Oct 6 06:57:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96Dvth14435 for linux-xfs-outgoing; Sat, 6 Oct 2001 06:57:55 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96DvnD14383 for ; Sat, 6 Oct 2001 06:57:49 -0700 Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sun, 7 Oct 2001 00:00:15 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10072001-000012-216.MMD@cymax.com.au; Sun, 7 Oct 2001 00:00:12 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sat Oct 6 23:53:40 2001) X-From_: owner-linux-xfs@oss.sgi.com Sat Oct 6 19:12:42 2001 Delivered-To: cymax@smartchat.net.au Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by entoo.connect.com.au (Postfix) with ESMTP id 7C61FDFE14 for ; Sat, 6 Oct 2001 19:12:41 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f969CsS08827; Sat, 6 Oct 2001 02:12:54 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Sat, 6 Oct 2001 02:11:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f969BIx08709 for linux-xfs-outgoing; Sat, 6 Oct 2001 02:11:18 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f969BFD08689 for ; Sat, 6 Oct 2001 02:11:15 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id CAA01317 for ; Sat, 6 Oct 2001 02:11:34 -0700 (PDT) mail_from (ivanr@sgi.com) Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA10104; Sat, 6 Oct 2001 19:09:45 +1000 From: ivanr@sgi.com Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id TAA23303; Sat, 6 Oct 2001 19:09:44 +1000 (EST) X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs Date: Sat, 6 Oct 2001 19:09:44 +1000 X-X-Sender: ivanr@omen.melbourne.sgi.com To: Seth Mos Cc: linux-xfs@oss.sgi.com Subject: Re: Cluster XFS install without CD... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 06 Oct 2001 14:00:15.0812 (UTC) FILETIME=[399EA840:01C14E6F] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 5 Oct 2001, Seth Mos wrote: > There is a link that I just added to the FAQ for cloning XFS systems. It > is called "partition image" > > Maybe that will help. Perhaps you should add that it'd be a good idea to use xfs_admin (xfs_db) to change the uuid for the copied filesystems (unless there is a specific need for each filesystem to be an exact copy). Ivan -- Ivan Rayner ivanr@sgi.com From owner-linux-xfs@oss.sgi.com Sat Oct 6 06:57:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96DvwQ14446 for linux-xfs-outgoing; Sat, 6 Oct 2001 06:57:58 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96DvmD14364 for ; Sat, 6 Oct 2001 06:57:48 -0700 Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sun, 7 Oct 2001 00:00:15 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10072001-000011-212.MMD@cymax.com.au; Sun, 7 Oct 2001 00:00:11 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sat Oct 6 23:53:39 2001) X-From_: owner-linux-xfs@oss.sgi.com Sat Oct 6 16:45:51 2001 Delivered-To: cymax@smartchat.net.au Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by entoo.connect.com.au (Postfix) with ESMTP id 9A63DDDF4D for ; Sat, 6 Oct 2001 16:45:50 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f966k9U05864; Fri, 5 Oct 2001 23:46:09 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 23:45:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f966j2x05778 for linux-xfs-outgoing; Fri, 5 Oct 2001 23:45:02 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f966itD05741 for ; Fri, 5 Oct 2001 23:44:55 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 8746DC00B63 for ; Sat, 6 Oct 2001 14:44:52 +0800 (PHT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 3E66AC00B60 for ; Sat, 6 Oct 2001 14:44:51 +0800 (PHT) Date: Sat, 6 Oct 2001 14:44:51 +0800 (PHT) From: Federico Sevilla III To: Linux XFS Mailing List Subject: We have a mail loop! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 X-OriginalArrivalTime: 06 Oct 2001 14:00:15.0343 (UTC) FILETIME=[395717F0:01C14E6F] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I thought it was just me but I don't think it is. A member of the mailing list, , has a mail loop on us it seems. See this trail in the received headers: Return-Path: Delivered-To: jijo@leathercollection.ph Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 02BE8C00B63 for ; Sat, 6 Oct 2001 14:13:44 +0800 (PHT) Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by gusi.leathercollection.ph (Postfix) with ESMTP id 92924C00B60 for ; Sat, 6 Oct 2001 14:13:41 +0800 (PHT) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f966CDx03773; Fri, 5 Oct 2001 23:12:13 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 23:12:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9662Aa02294 for linux-xfs-outgoing; Fri, 5 Oct 2001 23:02:10 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9661uD02127 for ; Fri, 5 Oct 2001 23:01:56 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA00781 for ; Fri, 5 Oct 2001 23:02:24 -0700 (PDT) mail_from (ian.nelson@echostar.com) Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sat, 6 Oct 2001 16:00:54 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10062001-160026-123.MMD@cymax.com.au; Sat, 6 Oct 2001 16:00:26 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sat Oct 6 15:53:54 2001) X-From_: owner-linux-xfs@oss.sgi.com Sat Oct 6 09:29:18 2001 Delivered-To: cymax@smartchat.net.au Received: from yarrina.connect.com.au (yarrina.connect.com.au [192.189.54.17]) by entoo.connect.com.au (Postfix) with ESMTP id 28669DFBFC for ; Sat, 6 Oct 2001 09:29:17 +1000 (EST) Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by yarrina.connect.com.au (Postfix) with ESMTP id 8865B29EBA5 for ; Sat, 6 Oct 2001 07:09:24 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95L5qU20744; Fri, 5 Oct 2001 14:05:52 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 14:04:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95L4sh20646 for linux-xfs-outgoing; Fri, 5 Oct 2001 14:04:54 -0700 Received: from linux0.echostar.com (w146-253.echostar.com [205.172.146.253]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95L4oD20627 for ; Fri, 5 Oct 2001 14:04:50 -0700 Received: from echostar.com (linux10.echostar.com [10.79.98.110]) by linux0.echostar.com (Postfix) with ESMTP id 1005379085 for ; Fri, 5 Oct 2001 15:04:40 -0600 (MDT) From owner-linux-xfs@oss.sgi.com Sat Oct 6 06:57:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96Dvpp14414 for linux-xfs-outgoing; Sat, 6 Oct 2001 06:57:51 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96DvkD14347 for ; Sat, 6 Oct 2001 06:57:47 -0700 Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sun, 7 Oct 2001 00:00:15 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10072001-000011-211.MMD@cymax.com.au; Sun, 7 Oct 2001 00:00:11 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sat Oct 6 23:53:39 2001) X-From_: owner-linux-xfs@oss.sgi.com Sat Oct 6 16:25:58 2001 Delivered-To: cymax@smartchat.net.au Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by entoo.connect.com.au (Postfix) with ESMTP id 82D60DFBCD for ; Sat, 6 Oct 2001 16:25:57 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f966QR805362; Fri, 5 Oct 2001 23:26:27 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 23:25:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f966PPJ05269 for linux-xfs-outgoing; Fri, 5 Oct 2001 23:25:25 -0700 Received: from monkeyiq.dnsalias.org (CPE-203-45-214-174.qld.bigpond.net.au [203.45.214.174]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f966PHD05249 for ; Fri, 5 Oct 2001 23:25:17 -0700 Received: by monkeyiq.dnsalias.org id f966OeV30354 ; Sat, 6 Oct 2001 16:24:40 +1000 Date: Sat, 6 Oct 2001 16:24:40 +1000 Message-Id: <200110060624.f966OeV30354@monkeyiq.dnsalias.org> To: linux-xfs@oss.sgi.com Subject: ENOATTR and other error enums From: monkeyiq MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 06 Oct 2001 14:00:15.0218 (UTC) FILETIME=[39440520:01C14E6F] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Anyone know where these are defined in Linux? I dont seem to be able to find them, even with find/grep in /usr/include. Also, is there a function to get a string rep of the error that occured in the attr code? Thanks. ----------------------------------------------------- choose ferris. http://witme.sourceforge.net/libferris.web/ From owner-linux-xfs@oss.sgi.com Sat Oct 6 07:01:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96E11o15046 for linux-xfs-outgoing; Sat, 6 Oct 2001 07:01:01 -0700 Received: from artax.karlin.mff.cuni.cz (root@artax.karlin.mff.cuni.cz [195.113.31.125]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96E0vD15019 for ; Sat, 6 Oct 2001 07:00:57 -0700 Received: from localhost (mikulas@localhost) by artax.karlin.mff.cuni.cz (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id QAA28175; Sat, 6 Oct 2001 16:00:21 +0200 Date: Sat, 6 Oct 2001 16:00:21 +0200 (CEST) From: Mikulas Patocka Reply-To: Mikulas Patocka To: Rik van Riel cc: Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: %u-order allocation failed In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > After simple bash fork bombing (about 200 forks) on my UP Celeron/96MB > > I get quite a lot %u-allocations failed, but only when swap is turned > > off. > > > I'm not familiar with LinuxVM.. so... is it normal behaviour ? or (if not) > > what's happening when such messages are printed my kernel ? > > This is perfectly normal behaviour: > > 1) on your system, you have no process limit configured for > yourself so you can start processes until all resources > (memory, file descriptors, ...) are used > > 2) when all processes are used, there really is no way the > kernel can buy you more hardware on ebay and install it > on the fly ... all it can do is start failing allocations > > On production systems, good admins setup per-user limits for > the various resources so no single user is able to run the > system into the ground. No, it's not normal. It is long-standing bug - I think from 2.2 kernels. You know that without swap and with certain memory allocation strategy (when process in a loop allocates one anonymous page, one file cache page and again...) this bug can be triggered even when there is half memory free. Buddy allocator is broken - kill it. Or at least do not misuse it for anything except kernel or driver initialization. Mikulas From owner-linux-xfs@oss.sgi.com Sat Oct 6 07:04:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96E4F115251 for linux-xfs-outgoing; Sat, 6 Oct 2001 07:04:15 -0700 Received: from netbank.com.br (IDENT:postfix@garrincha.netbank.com.br [200.203.199.88]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96E4BD15231 for ; Sat, 6 Oct 2001 07:04:12 -0700 Received: from 1-102.ctame701-1.telepar.net.br (1-102.ctame701-1.telepar.net.br [200.181.137.102]) by netbank.com.br (Postfix) with ESMTP id 2A0D646839; Sat, 6 Oct 2001 11:03:19 -0300 (BRST) Received: (from localhost user: 'riel', uid#500) by imladris.surriel.com with ESMTP id ; Sat, 6 Oct 2001 11:03:48 -0300 Date: Sat, 6 Oct 2001 11:03:47 -0300 (BRST) From: Rik van Riel X-X-Sender: To: Mikulas Patocka Cc: Krzysztof Rusocki , , Subject: Re: %u-order allocation failed In-Reply-To: Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 6 Oct 2001, Mikulas Patocka wrote: > Buddy allocator is broken - kill it. Or at least do not misuse it for > anything except kernel or driver initialization. Please send patches to get rid of the buddy allocator while still making it possible to allocate contiguous chunks of memory. If you have any idea on how to fix things, this would be a good time to let us know. cheers, Rik -- DMCA, SSSCA, W3C? Who cares? http://thefreeworld.net/ (volunteers needed) http://www.surriel.com/ http://distro.conectiva.com/ From owner-linux-xfs@oss.sgi.com Sat Oct 6 07:09:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96E9bh15450 for linux-xfs-outgoing; Sat, 6 Oct 2001 07:09:37 -0700 Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96E9UD15426 for ; Sat, 6 Oct 2001 07:09:30 -0700 Received: from walt400.localhost (user-uini6cb.dsl.mindspring.com [165.121.25.139]) by hall.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id KAA05800 for ; Sat, 6 Oct 2001 10:09:26 -0400 (EDT) Received: from mindspring.com (localhost.localdomain [127.0.0.1]) by walt400.localhost (Postfix) with ESMTP id DF1728171E3; Sat, 6 Oct 2001 07:07:54 -0700 (PDT) Message-ID: <3BBF103A.3030700@mindspring.com> Date: Sat, 06 Oct 2001 07:07:54 -0700 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010914 X-Accept-Language: en-us MIME-Version: 1.0 To: Federico Sevilla III Cc: Linux XFS Mailing List Subject: Re: We have a mail loop! References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Not just you :) Everything's coming back 'round again it seems. Just got up and found my mailbox full of stuff, started reading them and though "Man, these sure sound familiar...." It's like deja-vu all over again... :) -Walt Federico Sevilla III wrote: > I thought it was just me but I don't think it is. A member of the mailing > list, , has a mail loop on us it seems. See this > trail in the received headers: > > Return-Path: > Delivered-To: jijo@leathercollection.ph > Received: from localhost (localhost [127.0.0.1]) > by gusi.leathercollection.ph (Postfix) with ESMTP id 02BE8C00B63 > for ; Sat, 6 Oct 2001 14:13:44 +0800 (PHT) > Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) > by gusi.leathercollection.ph (Postfix) with ESMTP id 92924C00B60 > for ; Sat, 6 Oct 2001 14:13:41 +0800 (PHT) > Received: from localhost (mail@localhost) > by oss.sgi.com (8.11.2/8.11.3) with SMTP id f966CDx03773; > Fri, 5 Oct 2001 23:12:13 -0700 > X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs > Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 23:12:12 -0700 > Received: (from majordomo@localhost) > by oss.sgi.com (8.11.2/8.11.3) id f9662Aa02294 > for linux-xfs-outgoing; Fri, 5 Oct 2001 23:02:10 -0700 > Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) > by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9661uD02127 > for ; Fri, 5 Oct 2001 23:01:56 -0700 > Received: from defiant.cymax.com.au > (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) > by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: > SGI does not authorize the use of its proprietary > systems or networks for unsolicited or bulk email > from the Internet.) > via ESMTP id XAA00781 > for ; Fri, 5 Oct 2001 23:02:24 -0700 (PDT) > mail_from (ian.nelson@echostar.com) > Received: from defiant.cymax.com.au ([192.168.70.2]) by > defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); > Sat, 6 Oct 2001 16:00:54 +1000 > Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes > 5.00.2195) with SMTP (Global POP3 Download) > id MSG10062001-160026-123.MMD@cymax.com.au; Sat, 6 Oct 2001 16:00:26 +1000 > Received: by smartchat.net.au (mbox cymax) > (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sat Oct 6 15:53:54 2001) > X-From_: owner-linux-xfs@oss.sgi.com Sat Oct 6 09:29:18 2001 > Delivered-To: cymax@smartchat.net.au > Received: from yarrina.connect.com.au (yarrina.connect.com.au [192.189.54.17]) > by entoo.connect.com.au (Postfix) with ESMTP id 28669DFBFC > for ; Sat, 6 Oct 2001 09:29:17 +1000 (EST) > Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) > by yarrina.connect.com.au (Postfix) with ESMTP id 8865B29EBA5 > for ; Sat, 6 Oct 2001 07:09:24 +1000 (EST) > Received: from localhost (mail@localhost) > by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95L5qU20744; > Fri, 5 Oct 2001 14:05:52 -0700 > X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs > Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 14:04:54 -0700 > Received: (from majordomo@localhost) > by oss.sgi.com (8.11.2/8.11.3) id f95L4sh20646 > for linux-xfs-outgoing; Fri, 5 Oct 2001 14:04:54 -0700 > Received: from linux0.echostar.com (w146-253.echostar.com [205.172.146.253]) > by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95L4oD20627 > for ; Fri, 5 Oct 2001 14:04:50 -0700 > Received: from echostar.com (linux10.echostar.com [10.79.98.110]) > by linux0.echostar.com (Postfix) with ESMTP id 1005379085 > for ; Fri, 5 Oct 2001 15:04:40 -0600 (MDT) > > > From owner-linux-xfs@oss.sgi.com Sat Oct 6 07:44:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96EivH16250 for linux-xfs-outgoing; Sat, 6 Oct 2001 07:44:57 -0700 Received: from artax.karlin.mff.cuni.cz (root@artax.karlin.mff.cuni.cz [195.113.31.125]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96EinD16231 for ; Sat, 6 Oct 2001 07:44:49 -0700 Received: from localhost (mikulas@localhost) by artax.karlin.mff.cuni.cz (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id QAA30223; Sat, 6 Oct 2001 16:44:43 +0200 Date: Sat, 6 Oct 2001 16:44:43 +0200 (CEST) From: Mikulas Patocka To: Rik van Riel cc: Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: %u-order allocation failed In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1908636959-741352904-1002379483=:29342" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1908636959-741352904-1002379483=:29342 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 6 Oct 2001, Rik van Riel wrote: > On Sat, 6 Oct 2001, Mikulas Patocka wrote: > > > Buddy allocator is broken - kill it. Or at least do not misuse it for > > anything except kernel or driver initialization. > > Please send patches to get rid of the buddy allocator while > still making it possible to allocate contiguous chunks of > memory. > > If you have any idea on how to fix things, this would be a > good time to let us know. Here goes the fix. (note that I didn't try to compile it so there may be bugs, but you see the point). kmalloc should be fixed too (used badly for example in select.c - and yes - I have seen real world bugreports for poll randomly failing with ENOMEM), but it will be hard to audit all drivers that they do not try to use dma on kmallocated memory. Mikulas --1908636959-741352904-1002379483=:29342 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="vmalloc.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: ZGlmZiAtdSAtciBsaW51eC1vcmlnL2luY2x1ZGUvYXNtLWkzODYvcHJvY2Vz c29yLmggbGludXgvaW5jbHVkZS9hc20taTM4Ni9wcm9jZXNzb3IuaA0KLS0t IGxpbnV4LW9yaWcvaW5jbHVkZS9hc20taTM4Ni9wcm9jZXNzb3IuaAlTYXQg T2N0ICA2IDE2OjIxOjUwIDIwMDENCisrKyBsaW51eC9pbmNsdWRlL2FzbS1p Mzg2L3Byb2Nlc3Nvci5oCVNhdCBPY3QgIDYgMTY6MzE6MTUgMjAwMQ0KQEAg LTQ0OCw3ICs0NDgsNyBAQA0KICNkZWZpbmUgS1NUS19FU1AodHNrKQkoKCh1 bnNpZ25lZCBsb25nICopKDQwOTYrKHVuc2lnbmVkIGxvbmcpKHRzaykpKVsx MDIyXSkNCiANCiAjZGVmaW5lIFRIUkVBRF9TSVpFICgyKlBBR0VfU0laRSkN Ci0jZGVmaW5lIGFsbG9jX3Rhc2tfc3RydWN0KCkgKChzdHJ1Y3QgdGFza19z dHJ1Y3QgKikgX19nZXRfZnJlZV9wYWdlcyhHRlBfS0VSTkVMLDEpKQ0KKyNk ZWZpbmUgYWxsb2NfdGFza19zdHJ1Y3QoKSAoKHN0cnVjdCB0YXNrX3N0cnVj dCAqKSBfX2dldF9mcmVlX3BhZ2VzKEdGUF9LRVJORUwgfCBfX0dGUF9WTUFM TE9DLDEpKQ0KICNkZWZpbmUgZnJlZV90YXNrX3N0cnVjdChwKSBmcmVlX3Bh Z2VzKCh1bnNpZ25lZCBsb25nKSAocCksIDEpDQogI2RlZmluZSBnZXRfdGFz a19zdHJ1Y3QodHNrKSAgICAgIGF0b21pY19pbmMoJnZpcnRfdG9fcGFnZSh0 c2spLT5jb3VudCkNCiANCmRpZmYgLXUgLXIgbGludXgtb3JpZy9pbmNsdWRl L2xpbnV4L21tLmggbGludXgvaW5jbHVkZS9saW51eC9tbS5oDQotLS0gbGlu dXgtb3JpZy9pbmNsdWRlL2xpbnV4L21tLmgJU2F0IE9jdCAgNiAxNjoyMTo1 OSAyMDAxDQorKysgbGludXgvaW5jbHVkZS9saW51eC9tbS5oCVNhdCBPY3Qg IDYgMTY6Mjg6MTIgMjAwMQ0KQEAgLTU1MCw2ICs1NTAsNyBAQA0KICNkZWZp bmUgX19HRlBfSU8JMHg0MAkvKiBDYW4gc3RhcnQgbG93IG1lbW9yeSBwaHlz aWNhbCBJTz8gKi8NCiAjZGVmaW5lIF9fR0ZQX0hJR0hJTwkweDgwCS8qIENh biBzdGFydCBoaWdoIG1lbSBwaHlzaWNhbCBJTz8gKi8NCiAjZGVmaW5lIF9f R0ZQX0ZTCTB4MTAwCS8qIENhbiBjYWxsIGRvd24gdG8gbG93LWxldmVsIEZT PyAqLw0KKyNkZWZpbmUgX19HRlBfVk1BTExPQwkweDIwMAkvKiBDYW4gdm1h bGxvYyBwYWdlcyBpZiBidWRkeSBhbGxvY2F0b3IgZmFpbHMgKi8NCiANCiAj ZGVmaW5lIEdGUF9OT0hJR0hJTwkoX19HRlBfSElHSCB8IF9fR0ZQX1dBSVQg fCBfX0dGUF9JTykNCiAjZGVmaW5lIEdGUF9OT0lPCShfX0dGUF9ISUdIIHwg X19HRlBfV0FJVCkNCmRpZmYgLXUgLXIgbGludXgtb3JpZy9tbS9wYWdlX2Fs bG9jLmMgbGludXgvbW0vcGFnZV9hbGxvYy5jDQotLS0gbGludXgtb3JpZy9t bS9wYWdlX2FsbG9jLmMJU2F0IE9jdCAgNiAxNjoyMTo0NyAyMDAxDQorKysg bGludXgvbW0vcGFnZV9hbGxvYy5jCVNhdCBPY3QgIDYgMTY6MzY6MjggMjAw MQ0KQEAgLTE4LDYgKzE4LDcgQEANCiAjaW5jbHVkZSA8bGludXgvYm9vdG1l bS5oPg0KICNpbmNsdWRlIDxsaW51eC9zbGFiLmg+DQogI2luY2x1ZGUgPGxp bnV4L2NvbXBpbGVyLmg+DQorI2luY2x1ZGUgPGxpbnV4L3ZtYWxsb2MuaD4N CiANCiBpbnQgbnJfc3dhcF9wYWdlczsNCiBpbnQgbnJfYWN0aXZlX3BhZ2Vz Ow0KQEAgLTQyMSw5ICs0MjIsOSBAQA0KIAlzdHJ1Y3QgcGFnZSAqIHBhZ2U7 DQogDQogCXBhZ2UgPSBhbGxvY19wYWdlcyhnZnBfbWFzaywgb3JkZXIpOw0K LQlpZiAoIXBhZ2UpDQotCQlyZXR1cm4gMDsNCi0JcmV0dXJuICh1bnNpZ25l ZCBsb25nKSBwYWdlX2FkZHJlc3MocGFnZSk7DQorCWlmIChwYWdlKSByZXR1 cm4gKHVuc2lnbmVkIGxvbmcpIHBhZ2VfYWRkcmVzcyhwYWdlKTsNCisJaWYg KGdmcF9tYXNrICYgX19HRlBfVk1BTExPQykgcmV0dXJuICh1bnNpZ25lZCBs b25nKV9fdm1hbGxvYyhQQUdFX1NJWkUgPDwgb3JkZXIsIGdmcF9tYXNrLCBQ QUdFX0tFUk5FTCk7DQorCXJldHVybiAwOw0KIH0NCiANCiB1bnNpZ25lZCBs b25nIGdldF96ZXJvZWRfcGFnZSh1bnNpZ25lZCBpbnQgZ2ZwX21hc2spDQpA QCAtNDQ3LDYgKzQ0OCwxMCBAQA0KIA0KIHZvaWQgZnJlZV9wYWdlcyh1bnNp Z25lZCBsb25nIGFkZHIsIHVuc2lnbmVkIGludCBvcmRlcikNCiB7DQorCWlm IChhZGRyID49IFZNQUxMT0NfU1RBUlQgJiYgYWRkciA8IFZNQUxMT0NfRU5E KSB7DQorCQl2ZnJlZSgodm9pZCAqKWFkZHIpOw0KKwkJcmV0dXJuOw0KKwl9 DQogCWlmIChhZGRyICE9IDApDQogCQlfX2ZyZWVfcGFnZXModmlydF90b19w YWdlKGFkZHIpLCBvcmRlcik7DQogfQ0K --1908636959-741352904-1002379483=:29342-- From owner-linux-xfs@oss.sgi.com Sat Oct 6 08:31:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96FVjq17239 for linux-xfs-outgoing; Sat, 6 Oct 2001 08:31:45 -0700 Received: from artax.karlin.mff.cuni.cz (root@artax.karlin.mff.cuni.cz [195.113.31.125]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96FVWD17216 for ; Sat, 6 Oct 2001 08:31:32 -0700 Received: from localhost (mikulas@localhost) by artax.karlin.mff.cuni.cz (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id RAA32433; Sat, 6 Oct 2001 17:31:26 +0200 Date: Sat, 6 Oct 2001 17:31:26 +0200 (CEST) From: Mikulas Patocka To: Rik van Riel cc: Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: %u-order allocation failed In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1908636959-1328101436-1002382286=:32345" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1908636959-1328101436-1002382286=:32345 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 6 Oct 2001, Mikulas Patocka wrote: > On Sat, 6 Oct 2001, Rik van Riel wrote: > > > On Sat, 6 Oct 2001, Mikulas Patocka wrote: > > > > > Buddy allocator is broken - kill it. Or at least do not misuse it for > > > anything except kernel or driver initialization. > > > > Please send patches to get rid of the buddy allocator while > > still making it possible to allocate contiguous chunks of > > memory. > > > > If you have any idea on how to fix things, this would be a > > good time to let us know. > > Here goes the fix. (note that I didn't try to compile it so there may be > bugs, but you see the point). > > kmalloc should be fixed too (used badly for example in select.c - and yes > - I have seen real world bugreports for poll randomly failing with > ENOMEM), but it will be hard to audit all drivers that they do not try to > use dma on kmallocated memory. This is enhanced version of a patch that fixes select and poll as well. Again - not compiled, not tried. Mikulas --1908636959-1328101436-1002382286=:32345 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="vmalloc.patch.2" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: ZGlmZiAtdSAtciBsaW51eC1vcmlnL2ZzL3NlbGVjdC5jIGxpbnV4L2ZzL3Nl bGVjdC5jDQotLS0gbGludXgtb3JpZy9mcy9zZWxlY3QuYwlTYXQgT2N0ICA2 IDE2OjIwOjQ1IDIwMDENCisrKyBsaW51eC9mcy9zZWxlY3QuYwlTYXQgT2N0 ICA2IDE2OjU0OjQ0IDIwMDENCkBAIC0yMzYsNyArMjM2LDcgQEANCiANCiBz dGF0aWMgdm9pZCAqc2VsZWN0X2JpdHNfYWxsb2MoaW50IHNpemUpDQogew0K LQlyZXR1cm4ga21hbGxvYyg2ICogc2l6ZSwgR0ZQX0tFUk5FTCk7DQorCXJl dHVybiBrbWFsbG9jKDYgKiBzaXplLCBHRlBfS0VSTkVMIHwgX19HRlBfVk1B TExPQyk7DQogfQ0KIA0KIHN0YXRpYyB2b2lkIHNlbGVjdF9iaXRzX2ZyZWUo dm9pZCAqYml0cywgaW50IHNpemUpDQpAQCAtNDM4LDcgKzQzOCw3IEBADQog CWlmIChuZmRzICE9IDApIHsNCiAJCWZkcyA9IChzdHJ1Y3QgcG9sbGZkICoq KWttYWxsb2MoDQogCQkJKDEgKyAobmZkcyAtIDEpIC8gUE9MTEZEX1BFUl9Q QUdFKSAqIHNpemVvZihzdHJ1Y3QgcG9sbGZkICopLA0KLQkJCUdGUF9LRVJO RUwpOw0KKwkJCUdGUF9LRVJORUwgfCBfX0dGUF9WTUFMTE9DKTsNCiAJCWlm IChmZHMgPT0gTlVMTCkNCiAJCQlnb3RvIG91dDsNCiAJfQ0KZGlmZiAtdSAt ciBsaW51eC1vcmlnL2luY2x1ZGUvYXNtLWkzODYvcHJvY2Vzc29yLmggbGlu dXgvaW5jbHVkZS9hc20taTM4Ni9wcm9jZXNzb3IuaA0KLS0tIGxpbnV4LW9y aWcvaW5jbHVkZS9hc20taTM4Ni9wcm9jZXNzb3IuaAlTYXQgT2N0ICA2IDE2 OjIxOjUwIDIwMDENCisrKyBsaW51eC9pbmNsdWRlL2FzbS1pMzg2L3Byb2Nl c3Nvci5oCVNhdCBPY3QgIDYgMTY6MzE6MTUgMjAwMQ0KQEAgLTQ0OCw3ICs0 NDgsNyBAQA0KICNkZWZpbmUgS1NUS19FU1AodHNrKQkoKCh1bnNpZ25lZCBs b25nICopKDQwOTYrKHVuc2lnbmVkIGxvbmcpKHRzaykpKVsxMDIyXSkNCiAN CiAjZGVmaW5lIFRIUkVBRF9TSVpFICgyKlBBR0VfU0laRSkNCi0jZGVmaW5l IGFsbG9jX3Rhc2tfc3RydWN0KCkgKChzdHJ1Y3QgdGFza19zdHJ1Y3QgKikg X19nZXRfZnJlZV9wYWdlcyhHRlBfS0VSTkVMLDEpKQ0KKyNkZWZpbmUgYWxs b2NfdGFza19zdHJ1Y3QoKSAoKHN0cnVjdCB0YXNrX3N0cnVjdCAqKSBfX2dl dF9mcmVlX3BhZ2VzKEdGUF9LRVJORUwgfCBfX0dGUF9WTUFMTE9DLDEpKQ0K ICNkZWZpbmUgZnJlZV90YXNrX3N0cnVjdChwKSBmcmVlX3BhZ2VzKCh1bnNp Z25lZCBsb25nKSAocCksIDEpDQogI2RlZmluZSBnZXRfdGFza19zdHJ1Y3Qo dHNrKSAgICAgIGF0b21pY19pbmMoJnZpcnRfdG9fcGFnZSh0c2spLT5jb3Vu dCkNCiANCmRpZmYgLXUgLXIgbGludXgtb3JpZy9pbmNsdWRlL2xpbnV4L21t LmggbGludXgvaW5jbHVkZS9saW51eC9tbS5oDQotLS0gbGludXgtb3JpZy9p bmNsdWRlL2xpbnV4L21tLmgJU2F0IE9jdCAgNiAxNjoyMTo1OSAyMDAxDQor KysgbGludXgvaW5jbHVkZS9saW51eC9tbS5oCVNhdCBPY3QgIDYgMTY6Mjg6 MTIgMjAwMQ0KQEAgLTU1MCw2ICs1NTAsNyBAQA0KICNkZWZpbmUgX19HRlBf SU8JMHg0MAkvKiBDYW4gc3RhcnQgbG93IG1lbW9yeSBwaHlzaWNhbCBJTz8g Ki8NCiAjZGVmaW5lIF9fR0ZQX0hJR0hJTwkweDgwCS8qIENhbiBzdGFydCBo aWdoIG1lbSBwaHlzaWNhbCBJTz8gKi8NCiAjZGVmaW5lIF9fR0ZQX0ZTCTB4 MTAwCS8qIENhbiBjYWxsIGRvd24gdG8gbG93LWxldmVsIEZTPyAqLw0KKyNk ZWZpbmUgX19HRlBfVk1BTExPQwkweDIwMAkvKiBDYW4gdm1hbGxvYyBwYWdl cyBpZiBidWRkeSBhbGxvY2F0b3IgZmFpbHMgKi8NCiANCiAjZGVmaW5lIEdG UF9OT0hJR0hJTwkoX19HRlBfSElHSCB8IF9fR0ZQX1dBSVQgfCBfX0dGUF9J TykNCiAjZGVmaW5lIEdGUF9OT0lPCShfX0dGUF9ISUdIIHwgX19HRlBfV0FJ VCkNCmRpZmYgLXUgLXIgbGludXgtb3JpZy9tbS9wYWdlX2FsbG9jLmMgbGlu dXgvbW0vcGFnZV9hbGxvYy5jDQotLS0gbGludXgtb3JpZy9tbS9wYWdlX2Fs bG9jLmMJU2F0IE9jdCAgNiAxNjoyMTo0NyAyMDAxDQorKysgbGludXgvbW0v cGFnZV9hbGxvYy5jCVNhdCBPY3QgIDYgMTY6MzY6MjggMjAwMQ0KQEAgLTE4 LDYgKzE4LDcgQEANCiAjaW5jbHVkZSA8bGludXgvYm9vdG1lbS5oPg0KICNp bmNsdWRlIDxsaW51eC9zbGFiLmg+DQogI2luY2x1ZGUgPGxpbnV4L2NvbXBp bGVyLmg+DQorI2luY2x1ZGUgPGxpbnV4L3ZtYWxsb2MuaD4NCiANCiBpbnQg bnJfc3dhcF9wYWdlczsNCiBpbnQgbnJfYWN0aXZlX3BhZ2VzOw0KQEAgLTQy MSw5ICs0MjIsOSBAQA0KIAlzdHJ1Y3QgcGFnZSAqIHBhZ2U7DQogDQogCXBh Z2UgPSBhbGxvY19wYWdlcyhnZnBfbWFzaywgb3JkZXIpOw0KLQlpZiAoIXBh Z2UpDQotCQlyZXR1cm4gMDsNCi0JcmV0dXJuICh1bnNpZ25lZCBsb25nKSBw YWdlX2FkZHJlc3MocGFnZSk7DQorCWlmIChwYWdlKSByZXR1cm4gKHVuc2ln bmVkIGxvbmcpIHBhZ2VfYWRkcmVzcyhwYWdlKTsNCisJaWYgKGdmcF9tYXNr ICYgX19HRlBfVk1BTExPQykgcmV0dXJuICh1bnNpZ25lZCBsb25nKV9fdm1h bGxvYyhQQUdFX1NJWkUgPDwgb3JkZXIsIGdmcF9tYXNrLCBQQUdFX0tFUk5F TCk7DQorCXJldHVybiAwOw0KIH0NCiANCiB1bnNpZ25lZCBsb25nIGdldF96 ZXJvZWRfcGFnZSh1bnNpZ25lZCBpbnQgZ2ZwX21hc2spDQpAQCAtNDQ3LDYg KzQ0OCwxMCBAQA0KIA0KIHZvaWQgZnJlZV9wYWdlcyh1bnNpZ25lZCBsb25n IGFkZHIsIHVuc2lnbmVkIGludCBvcmRlcikNCiB7DQorCWlmIChhZGRyID49 IFZNQUxMT0NfU1RBUlQgJiYgYWRkciA8IFZNQUxMT0NfRU5EKSB7DQorCQl2 ZnJlZSgodm9pZCAqKWFkZHIpOw0KKwkJcmV0dXJuOw0KKwl9DQogCWlmIChh ZGRyICE9IDApDQogCQlfX2ZyZWVfcGFnZXModmlydF90b19wYWdlKGFkZHIp LCBvcmRlcik7DQogfQ0KZGlmZiAtdSAtciBsaW51eC1vcmlnL21tL3NsYWIu YyBsaW51eC9tbS9zbGFiLmMNCi0tLSBsaW51eC1vcmlnL21tL3NsYWIuYwlT YXQgT2N0ICA2IDE2OjIxOjQ4IDIwMDENCisrKyBsaW51eC9tbS9zbGFiLmMJ U2F0IE9jdCAgNiAxNzowNDozNyAyMDAxDQpAQCAtNzMsNiArNzMsNyBAQA0K ICNpbmNsdWRlCTxsaW51eC9pbnRlcnJ1cHQuaD4NCiAjaW5jbHVkZQk8bGlu dXgvaW5pdC5oPg0KICNpbmNsdWRlCTxsaW51eC9jb21waWxlci5oPg0KKyNp bmNsdWRlCTxsaW51eC92bWFsbG9jLmg+DQogI2luY2x1ZGUJPGFzbS91YWNj ZXNzLmg+DQogDQogLyoNCkBAIC0xNTM2LDEwICsxNTM3LDE0IEBADQogCWNh Y2hlX3NpemVzX3QgKmNzaXplcCA9IGNhY2hlX3NpemVzOw0KIA0KIAlmb3Ig KDsgY3NpemVwLT5jc19zaXplOyBjc2l6ZXArKykgew0KKwkJdm9pZCAqcDsN CiAJCWlmIChzaXplID4gY3NpemVwLT5jc19zaXplKQ0KIAkJCWNvbnRpbnVl Ow0KLQkJcmV0dXJuIF9fa21lbV9jYWNoZV9hbGxvYyhmbGFncyAmIEdGUF9E TUEgPw0KLQkJCSBjc2l6ZXAtPmNzX2RtYWNhY2hlcCA6IGNzaXplcC0+Y3Nf Y2FjaGVwLCBmbGFncyk7DQorCQlpZiAoKHAgPSBfX2ttZW1fY2FjaGVfYWxs b2MoZmxhZ3MgJiBHRlBfRE1BID8NCisJCQkgY3NpemVwLT5jc19kbWFjYWNo ZXAgOiBjc2l6ZXAtPmNzX2NhY2hlcCwgZmxhZ3MgJiB+X19HRlBfVk1BTExP QykpKQ0KKwkJCQlyZXR1cm4gcDsNCisJCWlmIChmbGFncyAmIF9fR0ZQX1ZN QUxMT0MpIHJldHVybiBfX3ZtYWxsb2Moc2l6ZSwgZmxhZ3MsIFBBR0VfS0VS TkVMKTsNCisJCXJldHVybiBOVUxMOw0KIAl9DQogCXJldHVybiBOVUxMOw0K IH0NCkBAIC0xNTgwLDYgKzE1ODUsMTAgQEANCiANCiAJaWYgKCFvYmpwKQ0K IAkJcmV0dXJuOw0KKwlpZiAoKHVuc2lnbmVkIGxvbmcpb2JqcCA+PSBWTUFM TE9DX1NUQVJUICYmICh1bnNpZ25lZCBsb25nKW9iaiA8IFZNQUxMT0NfRU5E KSB7DQorCQl2ZnJlZShvYmpwKTsNCisJCXJldHVybjsNCisJfQ0KIAlsb2Nh bF9pcnFfc2F2ZShmbGFncyk7DQogCUNIRUNLX1BBR0UodmlydF90b19wYWdl KG9ianApKTsNCiAJYyA9IEdFVF9QQUdFX0NBQ0hFKHZpcnRfdG9fcGFnZShv YmpwKSk7DQo= --1908636959-1328101436-1002382286=:32345-- From owner-linux-xfs@oss.sgi.com Sat Oct 6 09:25:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96GPLb18305 for linux-xfs-outgoing; Sat, 6 Oct 2001 09:25:21 -0700 Received: from linux0.echostar.com (w146-253.echostar.com [205.172.146.253]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96GPGD18286 for ; Sat, 6 Oct 2001 09:25:16 -0700 Received: from echostar.com (linux10.echostar.com [10.79.98.110]) by linux0.echostar.com (Postfix) with ESMTP id 6798779085; Sat, 6 Oct 2001 10:25:06 -0600 (MDT) Message-ID: <3BBF3063.9C9C3C0@echostar.com> Date: Sat, 06 Oct 2001 10:25:07 -0600 From: "Ian S. Nelson" Reply-To: ian.nelson@echostar.com Organization: Echostar X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.4.3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord Cc: Seth Mos , "linux-xfs@oss.sgi.com" Subject: Re: Wierd errors with sync References: <200110060244.f962iwf08449@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The problem is fixed. When running a flash image with an initrd doing a mount from within the linuxrc program (init) behaves much differently that spawning a process and calling /bin/mount. I'm going to put some tools in place to try and figure it out. A specific behavior is that C mount mounts the system, let's you look at it, but you can't do a /bin/umount to it. It doesn't show up in the mtab and as far as I know, there isn't any way to unmount it at that point. Steve Lord wrote: > > I have been seeing kernel BUGs in ll_rw_blk. To my /dev/hda8, requests out > > of range, or so it would appear. > > > > Well it's an embedded platform and we've been slowly turning off items. Here > > is my new theory. > > Ah ha, a minor detail emerges! > > > > > If the drive is blank then I have a flash the detects that and rebuilds it > > in said flash I do mkfs.xfs and then I do a C library call mount() > > That mount behaves different from /bin/mount. I'm guessing that's my > > problem. I'm doing mkfs and then it's not syncing or some such garbage. > > The xfs metadata cache and the buffer cache used by block devices are > not coherent. There is an ioctl at the end of mkfs which is supposed to > ensure that all buffers for the device are flushed out to disk before > it returns. This ioctl: BLKFLSBUF must work, possibly this is an issue > for you. > > > > > I'm going to retool my flash and try again. I've taken the problematic > > partitions and on the running system I've unmounted them and rebuilt them and > > everything is cool again.. > > > > Ian > > > > Steve From owner-linux-xfs@oss.sgi.com Sat Oct 6 09:53:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96Grdj18875 for linux-xfs-outgoing; Sat, 6 Oct 2001 09:53:39 -0700 Received: from locutus.doe.carleton.ca (locutus.doe.carleton.ca [134.117.9.46]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96GrXD18851 for ; Sat, 6 Oct 2001 09:53:33 -0700 Received: from doe.carleton.ca (kelvin [134.117.9.220]) by locutus.doe.carleton.ca (8.10.2+Sun/8.9.1) with ESMTP id f96GrQI06356; Sat, 6 Oct 2001 12:53:28 -0400 (EDT) Message-ID: <3BBF372A.2030005@doe.carleton.ca> Date: Sat, 06 Oct 2001 12:54:02 -0400 From: Mike Sowka User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010816 X-Accept-Language: en-us MIME-Version: 1.0 To: ringram@uwyo.edu CC: linux-xfs@oss.sgi.com Subject: Re: WAS: Cluster XFS install without CD... MY APOLOGIES References: <3BBE360A.A2C909B2@uwyo.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Russ Ingram wrote: >Seth Mos wrote: > >> >>It is a shame that tools Like Symantec Ghost are really slow in taking up >>on different filesystems. ReiserFS or XFS are unsupported. ext2 is your >>only choice for most commercial tools. >> > >On the contrary, my friends. :-P There was a post to this list >probably a month or so ago about a linux Norton Ghost like util >that supports just about every major fs available in Linux. I >didn't actually get to try it out cuz I had just finished cloning >the drives I needed with xfsdump/xfsrestore when the message came >across but I remember it because I had needed exactly that not 2 >days before the message hit the list. The link was >http://www.partimage.org. You can also always just do what I did >and pipe the output of xfsdump to xfsrestore(or do the same with >tar for that matter), too. > > >Russ > Hello Russ, I was hoping to tap into your vast knowledge on XFS... :) I've looked at www.partimage.com and it seems they don't support the bootdisk/rootdisk method (no CD drives on my cluster nodes) on the latest version... I like the principle of KISS (keep it simple stupid), and using partition image when I've got xfsdump seems a bit redundant :). I have a question or two about xfsdump, any sugestion are MUCH appreciated: #1) How is it that xfsdump is able to dump / while it's mounted? And how "industrial-strength" is that? #2) Can you elaborate a bit on your method of piping xfsdump to xfsrestore :)? #3) Here is my "plan" for the cluster: - after installing the "golden-node" I plan on dumping all of its partitions /boot and / and storing the dumps on our head node - in order to clone: using etherboot (if I can get it running) I run a system off of NFS on my head node and xfs restore the partitions onto the rest of the nodes (linux xfs doesn't support simultaneous xfsrestores yet does it?) NOTE: my nodes are head-less no == no video adapter HOW VIABLE IS THIS? Thank You, Mike -- /************************************************************************\ | Mike Sowka o _ _ _ | | An Aspiring Engi"Nerd" _o /\_ _ \\o (_)\__/o (_) | | Carleton University _< \_ _>(_) (_)/<_ \_| \ _|/' \/ | | msowka@doe.carleton.ca (_)>(_) (_) (_) (_) (_)' _\o_ | | (home msowka@home.com) | \************************************************************************/ From owner-linux-xfs@oss.sgi.com Sat Oct 6 09:58:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96Gwm219114 for linux-xfs-outgoing; Sat, 6 Oct 2001 09:58:48 -0700 Received: from netbank.com.br (IDENT:postfix@garrincha.netbank.com.br [200.203.199.88]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96GwcD19093 for ; Sat, 6 Oct 2001 09:58:39 -0700 Received: from 1-102.ctame701-1.telepar.net.br (1-102.ctame701-1.telepar.net.br [200.181.137.102]) by netbank.com.br (Postfix) with ESMTP id D1EA64681A; Sat, 6 Oct 2001 13:57:42 -0300 (BRST) Received: (from localhost user: 'riel', uid#500) by imladris.surriel.com with ESMTP id ; Sat, 6 Oct 2001 13:58:17 -0300 Date: Sat, 6 Oct 2001 13:58:16 -0300 (BRST) From: Rik van Riel X-X-Sender: To: Mikulas Patocka Cc: Krzysztof Rusocki , , Subject: Re: %u-order allocation failed In-Reply-To: Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.org MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="1908636959-741352904-1002379483=:29342" Content-ID: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1908636959-741352904-1002379483=:29342 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: On Sat, 6 Oct 2001, Mikulas Patocka wrote: > On Sat, 6 Oct 2001, Rik van Riel wrote: > > On Sat, 6 Oct 2001, Mikulas Patocka wrote: > > > > > Buddy allocator is broken - kill it. Or at least do not misuse it for > > > anything except kernel or driver initialization. > > > > Please send patches to get rid of the buddy allocator while > > still making it possible to allocate contiguous chunks of > > memory. > > > > If you have any idea on how to fix things, this would be a > > good time to let us know. > > Here goes the fix. (note that I didn't try to compile it so there may be > bugs, but you see the point). So what are you going to do when your 64MB of vmalloc space runs out ? Rik -- DMCA, SSSCA, W3C? Who cares? http://thefreeworld.net/ (volunteers needed) http://www.surriel.com/ http://distro.conectiva.com/ --1908636959-741352904-1002379483=:29342 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="vmalloc.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: ZGlmZiAtdSAtciBsaW51eC1vcmlnL2luY2x1ZGUvYXNtLWkzODYvcHJvY2Vz c29yLmggbGludXgvaW5jbHVkZS9hc20taTM4Ni9wcm9jZXNzb3IuaA0KLS0t IGxpbnV4LW9yaWcvaW5jbHVkZS9hc20taTM4Ni9wcm9jZXNzb3IuaAlTYXQg T2N0ICA2IDE2OjIxOjUwIDIwMDENCisrKyBsaW51eC9pbmNsdWRlL2FzbS1p Mzg2L3Byb2Nlc3Nvci5oCVNhdCBPY3QgIDYgMTY6MzE6MTUgMjAwMQ0KQEAg LTQ0OCw3ICs0NDgsNyBAQA0KICNkZWZpbmUgS1NUS19FU1AodHNrKQkoKCh1 bnNpZ25lZCBsb25nICopKDQwOTYrKHVuc2lnbmVkIGxvbmcpKHRzaykpKVsx MDIyXSkNCiANCiAjZGVmaW5lIFRIUkVBRF9TSVpFICgyKlBBR0VfU0laRSkN Ci0jZGVmaW5lIGFsbG9jX3Rhc2tfc3RydWN0KCkgKChzdHJ1Y3QgdGFza19z dHJ1Y3QgKikgX19nZXRfZnJlZV9wYWdlcyhHRlBfS0VSTkVMLDEpKQ0KKyNk ZWZpbmUgYWxsb2NfdGFza19zdHJ1Y3QoKSAoKHN0cnVjdCB0YXNrX3N0cnVj dCAqKSBfX2dldF9mcmVlX3BhZ2VzKEdGUF9LRVJORUwgfCBfX0dGUF9WTUFM TE9DLDEpKQ0KICNkZWZpbmUgZnJlZV90YXNrX3N0cnVjdChwKSBmcmVlX3Bh Z2VzKCh1bnNpZ25lZCBsb25nKSAocCksIDEpDQogI2RlZmluZSBnZXRfdGFz a19zdHJ1Y3QodHNrKSAgICAgIGF0b21pY19pbmMoJnZpcnRfdG9fcGFnZSh0 c2spLT5jb3VudCkNCiANCmRpZmYgLXUgLXIgbGludXgtb3JpZy9pbmNsdWRl L2xpbnV4L21tLmggbGludXgvaW5jbHVkZS9saW51eC9tbS5oDQotLS0gbGlu dXgtb3JpZy9pbmNsdWRlL2xpbnV4L21tLmgJU2F0IE9jdCAgNiAxNjoyMTo1 OSAyMDAxDQorKysgbGludXgvaW5jbHVkZS9saW51eC9tbS5oCVNhdCBPY3Qg IDYgMTY6Mjg6MTIgMjAwMQ0KQEAgLTU1MCw2ICs1NTAsNyBAQA0KICNkZWZp bmUgX19HRlBfSU8JMHg0MAkvKiBDYW4gc3RhcnQgbG93IG1lbW9yeSBwaHlz aWNhbCBJTz8gKi8NCiAjZGVmaW5lIF9fR0ZQX0hJR0hJTwkweDgwCS8qIENh biBzdGFydCBoaWdoIG1lbSBwaHlzaWNhbCBJTz8gKi8NCiAjZGVmaW5lIF9f R0ZQX0ZTCTB4MTAwCS8qIENhbiBjYWxsIGRvd24gdG8gbG93LWxldmVsIEZT PyAqLw0KKyNkZWZpbmUgX19HRlBfVk1BTExPQwkweDIwMAkvKiBDYW4gdm1h bGxvYyBwYWdlcyBpZiBidWRkeSBhbGxvY2F0b3IgZmFpbHMgKi8NCiANCiAj ZGVmaW5lIEdGUF9OT0hJR0hJTwkoX19HRlBfSElHSCB8IF9fR0ZQX1dBSVQg fCBfX0dGUF9JTykNCiAjZGVmaW5lIEdGUF9OT0lPCShfX0dGUF9ISUdIIHwg X19HRlBfV0FJVCkNCmRpZmYgLXUgLXIgbGludXgtb3JpZy9tbS9wYWdlX2Fs bG9jLmMgbGludXgvbW0vcGFnZV9hbGxvYy5jDQotLS0gbGludXgtb3JpZy9t bS9wYWdlX2FsbG9jLmMJU2F0IE9jdCAgNiAxNjoyMTo0NyAyMDAxDQorKysg bGludXgvbW0vcGFnZV9hbGxvYy5jCVNhdCBPY3QgIDYgMTY6MzY6MjggMjAw MQ0KQEAgLTE4LDYgKzE4LDcgQEANCiAjaW5jbHVkZSA8bGludXgvYm9vdG1l bS5oPg0KICNpbmNsdWRlIDxsaW51eC9zbGFiLmg+DQogI2luY2x1ZGUgPGxp bnV4L2NvbXBpbGVyLmg+DQorI2luY2x1ZGUgPGxpbnV4L3ZtYWxsb2MuaD4N CiANCiBpbnQgbnJfc3dhcF9wYWdlczsNCiBpbnQgbnJfYWN0aXZlX3BhZ2Vz Ow0KQEAgLTQyMSw5ICs0MjIsOSBAQA0KIAlzdHJ1Y3QgcGFnZSAqIHBhZ2U7 DQogDQogCXBhZ2UgPSBhbGxvY19wYWdlcyhnZnBfbWFzaywgb3JkZXIpOw0K LQlpZiAoIXBhZ2UpDQotCQlyZXR1cm4gMDsNCi0JcmV0dXJuICh1bnNpZ25l ZCBsb25nKSBwYWdlX2FkZHJlc3MocGFnZSk7DQorCWlmIChwYWdlKSByZXR1 cm4gKHVuc2lnbmVkIGxvbmcpIHBhZ2VfYWRkcmVzcyhwYWdlKTsNCisJaWYg KGdmcF9tYXNrICYgX19HRlBfVk1BTExPQykgcmV0dXJuICh1bnNpZ25lZCBs b25nKV9fdm1hbGxvYyhQQUdFX1NJWkUgPDwgb3JkZXIsIGdmcF9tYXNrLCBQ QUdFX0tFUk5FTCk7DQorCXJldHVybiAwOw0KIH0NCiANCiB1bnNpZ25lZCBs b25nIGdldF96ZXJvZWRfcGFnZSh1bnNpZ25lZCBpbnQgZ2ZwX21hc2spDQpA QCAtNDQ3LDYgKzQ0OCwxMCBAQA0KIA0KIHZvaWQgZnJlZV9wYWdlcyh1bnNp Z25lZCBsb25nIGFkZHIsIHVuc2lnbmVkIGludCBvcmRlcikNCiB7DQorCWlm IChhZGRyID49IFZNQUxMT0NfU1RBUlQgJiYgYWRkciA8IFZNQUxMT0NfRU5E KSB7DQorCQl2ZnJlZSgodm9pZCAqKWFkZHIpOw0KKwkJcmV0dXJuOw0KKwl9 DQogCWlmIChhZGRyICE9IDApDQogCQlfX2ZyZWVfcGFnZXModmlydF90b19w YWdlKGFkZHIpLCBvcmRlcik7DQogfQ0K --1908636959-741352904-1002379483=:29342-- From owner-linux-xfs@oss.sgi.com Sat Oct 6 10:49:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96Hn3L20244 for linux-xfs-outgoing; Sat, 6 Oct 2001 10:49:03 -0700 Received: from artax.karlin.mff.cuni.cz (root@artax.karlin.mff.cuni.cz [195.113.31.125]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96HmwD20222 for ; Sat, 6 Oct 2001 10:48:59 -0700 Received: from localhost (mikulas@localhost) by artax.karlin.mff.cuni.cz (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id TAA05808; Sat, 6 Oct 2001 19:48:52 +0200 Date: Sat, 6 Oct 2001 19:48:52 +0200 (CEST) From: Mikulas Patocka To: Rik van Riel cc: Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: %u-order allocation failed In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 6 Oct 2001, Rik van Riel wrote: > On Sat, 6 Oct 2001, Mikulas Patocka wrote: > > On Sat, 6 Oct 2001, Rik van Riel wrote: > > > On Sat, 6 Oct 2001, Mikulas Patocka wrote: > > > > > > > Buddy allocator is broken - kill it. Or at least do not misuse it for > > > > anything except kernel or driver initialization. > > > > > > Please send patches to get rid of the buddy allocator while > > > still making it possible to allocate contiguous chunks of > > > memory. > > > > > > If you have any idea on how to fix things, this would be a > > > good time to let us know. > > > > Here goes the fix. (note that I didn't try to compile it so there may be > > bugs, but you see the point). > > So what are you going to do when your 64MB of vmalloc space > runs out ? Make larger vmalloc space :-) Virtual memory costs very little. Besides 64M / 8k = 8192 - so it runs out at 8192 processes. Of course vmalloc space can overflow - but it overflows only when the machine is overloaded with too many processes, too many processes with many filedescriptors etc. On the other hand, the buddy allocator fails *RANDOMLY*. Totally randomly, depending on cache access patterns and page allocation times. Mikulas From owner-linux-xfs@oss.sgi.com Sat Oct 6 10:59:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96Hxg220606 for linux-xfs-outgoing; Sat, 6 Oct 2001 10:59:42 -0700 Received: from shed.alex.org.uk (shed.alex.org.uk [195.224.53.219]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96HxdD20586 for ; Sat, 6 Oct 2001 10:59:40 -0700 Received: from [195.224.237.69] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 96AFFA4CB; Sat, 6 Oct 2001 18:59:37 +0100 (BST) Date: Sat, 06 Oct 2001 18:59:34 +0100 From: Alex Bligh - linux-kernel Reply-To: Alex Bligh - linux-kernel To: Mikulas Patocka , Rik van Riel Cc: Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org, Alex Bligh - linux-kernel Subject: Re: %u-order allocation failed Message-ID: <462829506.1002394773@[195.224.237.69]> In-Reply-To: References: X-Mailer: Mulberry/2.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --On Saturday, 06 October, 2001 4:44 PM +0200 Mikulas Patocka wrote: > Here goes the fix. (note that I didn't try to compile it so there may be > bugs, but you see the point). (seems to replace high order allocations by vmalloc) & how does vmalloc allocate physically (as opposed to virtually) contiguous memory; can't clearly recall it being IRQ safe either (for GFP_ATOMIC). -- Alex Bligh From owner-linux-xfs@oss.sgi.com Sat Oct 6 11:16:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96IGmG21169 for linux-xfs-outgoing; Sat, 6 Oct 2001 11:16:48 -0700 Received: from lists.samba.org (samba.sourceforge.net [198.186.203.85]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96IGjD21149 for ; Sat, 6 Oct 2001 11:16:45 -0700 Received: by lists.samba.org (Postfix, from userid 1102) id E5B764440; Sat, 6 Oct 2001 11:14:15 -0700 (PDT) Date: Sun, 7 Oct 2001 04:12:01 +1000 From: Anton Blanchard To: Mikulas Patocka Cc: Rik van Riel , Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: %u-order allocation failed Message-ID: <20011007041201.D15309@krispykreme> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Of course vmalloc space can overflow - but it overflows only when the > machine is overloaded with too many processes, too many processes with > many filedescriptors etc. On the other hand, the buddy allocator fails > *RANDOMLY*. Totally randomly, depending on cache access patterns and > page allocation times. vmalloc space is also much worse for tlb usage when the main kernel mapping uses large hardware ptes. Ingo and davem pointed this out to me recently when I wanted to allocate the pagecache hash using vmalloc (at the moment it maxes out at order 10 which is much to small for machines with large memory). If you could get away with a single page stack, then you could allocate the task struct separately and avoid any order 1 allocation. But you would probably need interrupt stacks to get away with a single page stack. Anton From owner-linux-xfs@oss.sgi.com Sat Oct 6 11:28:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96ISpX21452 for linux-xfs-outgoing; Sat, 6 Oct 2001 11:28:51 -0700 Received: from roujin.gargoylecc.com (mail@roujin.gargoylecc.com [65.100.85.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96ISfD21431 for ; Sat, 6 Oct 2001 11:28:42 -0700 Received: from ringram by roujin.gargoylecc.com with local (Exim 3.32 #1) id 15pwAi-0001j0-00; Sat, 06 Oct 2001 12:27:36 -0600 Date: Sat, 6 Oct 2001 12:27:36 -0600 To: Mike Sowka , linux-xfs@oss.sgi.com Subject: Re: WAS: Cluster XFS install without CD... MY APOLOGIES Message-ID: <20011006122736.A6572@roujin.gargoylecc.com> References: <3BBE360A.A2C909B2@uwyo.edu> <3BBF372A.2030005@doe.carleton.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3BBF372A.2030005@doe.carleton.ca> User-Agent: Mutt/1.3.22i From: Russel Ingram Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, Oct 06, 2001 at 12:54:02PM -0400, Mike Sowka wrote: > Russ Ingram wrote: > > >Seth Mos wrote: > > > >> > >>It is a shame that tools Like Symantec Ghost are really slow in taking up > >>on different filesystems. ReiserFS or XFS are unsupported. ext2 is your > >>only choice for most commercial tools. > >> > > > >On the contrary, my friends. :-P There was a post to this list > >probably a month or so ago about a linux Norton Ghost like util > >that supports just about every major fs available in Linux. I > >didn't actually get to try it out cuz I had just finished cloning > >the drives I needed with xfsdump/xfsrestore when the message came > >across but I remember it because I had needed exactly that not 2 > >days before the message hit the list. The link was > >http://www.partimage.org. You can also always just do what I did > >and pipe the output of xfsdump to xfsrestore(or do the same with > >tar for that matter), too. > > > > > >Russ > > > Hello Russ, > I was hoping to tap into your vast knowledge on XFS... :) I've looked at > www.partimage.com and it seems they don't support the bootdisk/rootdisk > method (no CD drives on my cluster nodes) on the latest version... I > like the principle of KISS (keep it simple stupid), and using partition > image when I've got xfsdump seems a bit redundant :). > I have a question or two about xfsdump, any sugestion are MUCH appreciated: > #1) How is it that xfsdump is able to dump / while it's mounted? And how > "industrial-strength" is that? I'm not exactly sure what you're asking here. I don't know the technicalities of how it does it but if you're just asking if it can, yes, it can. If you want to know how, someone else will have to step in and answer that. > #2) Can you elaborate a bit on your method of piping xfsdump to > xfsrestore :)? The most basic form of xfsdump and its corresponding xfsrestore can be run back to back through a pipe to make a copy of a filesystem. Like this: xfsdump / - | xfsrestore - /mnt/ The above command says run xfsdump on the root filesystem, send the output to stdout and pipe it to xfsrestore. The dash on the xfsrestore command says to read stdin as the dump input and /mnt/ is where it is to write to. I noticed that when I ran it on my / filesytem it didn't do something right on the /dev/ dir so you might want to use tar instead and that can be done similarly like so: cd /; tar lcf - .| (cd /mnt/; tar xvpf -) > #3) Here is my "plan" for the cluster: > - after installing the "golden-node" I plan on dumping all of its > partitions /boot and / and storing the dumps on our head node > - in order to clone: using etherboot (if I can get it running) I run a > system off of NFS on my head node and xfs restore the partitions onto > the rest of the nodes (linux xfs doesn't support simultaneous > xfsrestores yet does it?) > NOTE: my nodes are head-less no == no video adapter > HOW VIABLE IS THIS? > Thank You, > Mike Ok, I'm not entirely sure I'm following you here but here's what I can tell you in regards to what I understand. If you are saying you will boot new nodes with etherboot with nothing on the harddrive but bare xfs partitions and run xfsrestore with a xfsdump file as the input device that sounds like it should work just fine. I don't know about running simultaneous xfsrestores. I haven't ever tried it but I can't imagine why it wouldn't work if you are restoring from a file rather than an actual device. Never hurts to try. Just one suggestion -- it might be just as easy to just do the filesystem replication by physically installing the new drive for additional nodes into the "golden node" and doing the piped method as shown above to copy the system. It will save you space on your server node. Russ -- Russel H. Ingram Gargoyle Computer Consulting (307)742-1361 or (307)760-1317 www.gargoylecc.com From owner-linux-xfs@oss.sgi.com Sat Oct 6 13:34:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96KYaG24479 for linux-xfs-outgoing; Sat, 6 Oct 2001 13:34:36 -0700 Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96KYXD24468 for ; Sat, 6 Oct 2001 13:34:33 -0700 Received: from scare ([63.231.179.33]) by lips.thebarn.com (8.12.0/8.12.0) with ESMTP id f96KajRP095452 for ; Sat, 6 Oct 2001 15:36:45 -0500 (CDT) Subject: Re: %u-order allocation failed From: Russell Cattelan To: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.14 (Preview Release) Date: 06 Oct 2001 15:35:22 -0500 Message-Id: <1002400523.2864.10.camel@scare> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2001-10-05 at 15:31, Seth Mos wrote: > On Fri, 5 Oct 2001, Rik van Riel wrote: > > > On Fri, 5 Oct 2001, Seth Mos wrote: > > > > > This happens using either 2.4.10-xfs or 2.4.11-pre3-xfs. > > > > Ohh duh, IIRC there are a bunch of highmem bugs in > > -linus which are fixed in -ac. > > Fitting XFS onto a -ac kernel should be fun :-( Actually it's not to bad ... I've been merging the with the ac kernels as the Mandrake people need them. I have a 2.4.9 ac 16 patch mostly worked out... if you want to finish it I could send it to you. > > I will try this over the weekend or get a redhat kernel going which is > also -ac based. That would come in handy for other people using XFS since > a lot are using highmem in combination with this fs. > > > Can you reproduce the bug with an -ac kernel ? > > I am not that good/fast at patching. Expect something over the weekend :-) > > Bye > Seth > From owner-linux-xfs@oss.sgi.com Sat Oct 6 13:34:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96KYZY24474 for linux-xfs-outgoing; Sat, 6 Oct 2001 13:34:35 -0700 Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96KYTD24462 for ; Sat, 6 Oct 2001 13:34:29 -0700 Received: from scare ([63.231.179.33]) by lips.thebarn.com (8.12.0/8.12.0) with ESMTP id f96KafRP095449 for ; Sat, 6 Oct 2001 15:36:41 -0500 (CDT) Subject: Re: We have a mail loop! From: Russell Cattelan To: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.14 (Preview Release) Date: 06 Oct 2001 15:35:18 -0500 Message-Id: <1002400519.2864.7.camel@scare> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hard to tell exactly what is going on. I tossed the duplicate message filter into the list procmailrc file that should catch any loop problems. On Sat, 2001-10-06 at 01:44, Federico Sevilla III wrote: > I thought it was just me but I don't think it is. A member of the mailing > list, , has a mail loop on us it seems. See this > trail in the received headers: > > Return-Path: > Delivered-To: jijo@leathercollection.ph > Received: from localhost (localhost [127.0.0.1]) > by gusi.leathercollection.ph (Postfix) with ESMTP id 02BE8C00B63 > for ; Sat, 6 Oct 2001 14:13:44 +0800 (PHT) > Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) > by gusi.leathercollection.ph (Postfix) with ESMTP id 92924C00B60 > for ; Sat, 6 Oct 2001 14:13:41 +0800 (PHT) > Received: from localhost (mail@localhost) > by oss.sgi.com (8.11.2/8.11.3) with SMTP id f966CDx03773; > Fri, 5 Oct 2001 23:12:13 -0700 > X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs > Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 23:12:12 -0700 > Received: (from majordomo@localhost) > by oss.sgi.com (8.11.2/8.11.3) id f9662Aa02294 > for linux-xfs-outgoing; Fri, 5 Oct 2001 23:02:10 -0700 > Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) > by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9661uD02127 > for ; Fri, 5 Oct 2001 23:01:56 -0700 > Received: from defiant.cymax.com.au > (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) > by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: > SGI does not authorize the use of its proprietary > systems or networks for unsolicited or bulk email > from the Internet.) > via ESMTP id XAA00781 > for ; Fri, 5 Oct 2001 23:02:24 -0700 (PDT) > mail_from (ian.nelson@echostar.com) > Received: from defiant.cymax.com.au ([192.168.70.2]) by > defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); > Sat, 6 Oct 2001 16:00:54 +1000 > Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes > 5.00.2195) with SMTP (Global POP3 Download) > id MSG10062001-160026-123.MMD@cymax.com.au; Sat, 6 Oct 2001 16:00:26 +1000 > Received: by smartchat.net.au (mbox cymax) > (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sat Oct 6 15:53:54 2001) > X-From_: owner-linux-xfs@oss.sgi.com Sat Oct 6 09:29:18 2001 > Delivered-To: cymax@smartchat.net.au > Received: from yarrina.connect.com.au (yarrina.connect.com.au [192.189.54.17]) > by entoo.connect.com.au (Postfix) with ESMTP id 28669DFBFC > for ; Sat, 6 Oct 2001 09:29:17 +1000 (EST) > Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) > by yarrina.connect.com.au (Postfix) with ESMTP id 8865B29EBA5 > for ; Sat, 6 Oct 2001 07:09:24 +1000 (EST) > Received: from localhost (mail@localhost) > by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95L5qU20744; > Fri, 5 Oct 2001 14:05:52 -0700 > X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs > Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 14:04:54 -0700 > Received: (from majordomo@localhost) > by oss.sgi.com (8.11.2/8.11.3) id f95L4sh20646 > for linux-xfs-outgoing; Fri, 5 Oct 2001 14:04:54 -0700 > Received: from linux0.echostar.com (w146-253.echostar.com [205.172.146.253]) > by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95L4oD20627 > for ; Fri, 5 Oct 2001 14:04:50 -0700 > Received: from echostar.com (linux10.echostar.com [10.79.98.110]) > by linux0.echostar.com (Postfix) with ESMTP id 1005379085 > for ; Fri, 5 Oct 2001 15:04:40 -0600 (MDT) From owner-linux-xfs@oss.sgi.com Sat Oct 6 13:48:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96Kmb125256 for linux-xfs-outgoing; Sat, 6 Oct 2001 13:48:37 -0700 Received: (from root@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96KmSM25102 for linux-xfs@oss.sgi.com; Sat, 6 Oct 2001 13:48:28 -0700 Message-Id: <200110062048.f96KmSM25102@oss.sgi.com> Date: Sat, 6 Oct 2001 21:13:00 +0200 (CEST) From: Mikulas Patocka Subject: Re: %u-order allocation failed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > --On Saturday, 06 October, 2001 4:44 PM +0200 Mikulas Patocka > wrote: > > > Here goes the fix. (note that I didn't try to compile it so there may be > > bugs, but you see the point). > > (seems to replace high order allocations by vmalloc) > > & how does vmalloc allocate physically (as opposed to virtually) > contiguous memory; can't clearly recall it being IRQ safe either > (for GFP_ATOMIC). It uses vmalloc only when __GFP_VMALLOC flag is given - and so it is expected to not use __GFP_VMALLOC flag in IRQ. NOTE: no allocations in IRQ are safe. Not only high-order ones. Allocation in IRQ may fail any time and you must recover without lost of functionality (network can lose packets any time, if you are doing some general device driver, you must preallocate all buffers in process context). Mikulas From owner-linux-xfs@oss.sgi.com Sat Oct 6 13:48:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96KmaK25247 for linux-xfs-outgoing; Sat, 6 Oct 2001 13:48:36 -0700 Received: (from root@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96KmSx25115 for linux-xfs@oss.sgi.com; Sat, 6 Oct 2001 13:48:28 -0700 Message-Id: <200110062048.f96KmSx25115@oss.sgi.com> Date: Sun, 7 Oct 2001 01:18:23 +0530 (IST) From: Vivek Malik Subject: usr quota setup Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I am using current development tree version of xfs (updated using cvs). All the file systems is my Pentium III computer are having xfs filesystem. I have mounted a partition /nfs as "exec,nodev,nosuid,rw,usrquota 1 2" The kernel is having quota support. "repquota /nfs" reports quota correctly. I am having problems in defining quota consraints. I tried using edquota but couldnt succeed. Please suggest how can i enable quota constraints. Thanx vivek From owner-linux-xfs@oss.sgi.com Sat Oct 6 13:48:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96Kmds25270 for linux-xfs-outgoing; Sat, 6 Oct 2001 13:48:39 -0700 Received: (from root@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96KmSH25146 for linux-xfs@oss.sgi.com; Sat, 6 Oct 2001 13:48:28 -0700 Message-Id: <200110062048.f96KmSH25146@oss.sgi.com> From: Benjamin Herrenschmidt Subject: Re: %u-order allocation failed Date: Sat, 6 Oct 2001 22:13:03 +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > >OK, but my patch uses vmalloc only as a fallback when buddy fails. The >probability that buddy fails is small. It is slower but with very small >probability. > >It is perfectly OK to have a bit slower access to task_struct with >probability 1/1000000. > >But it is ***BAD*BUG*** if allocation of task_struct fails with >probability 1/1000000. I missed the beginning of the thread, sorry if that question was already answered, What about all the code that still consider kmalloc'ed memory is safe for use with virt_to_bus and friends and is contiguous physically for DMA ? In some cases (non-PCI devices, embedded platforms, etc...), the pci_consistent API is not an option. That means that __GFP_VMALLOC can't be part of GFP_KERNEL or many driver will break in horrible ways (random memory corruption). Ben. From owner-linux-xfs@oss.sgi.com Sat Oct 6 13:48:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96Kmf125310 for linux-xfs-outgoing; Sat, 6 Oct 2001 13:48:41 -0700 Received: (from root@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96KmTu25179 for linux-xfs@oss.sgi.com; Sat, 6 Oct 2001 13:48:29 -0700 Message-Id: <200110062048.f96KmTu25179@oss.sgi.com> Subject: Re: %u-order allocation failed From: Russell Cattelan Date: 06 Oct 2001 15:32:57 -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2001-10-05 at 15:31, Seth Mos wrote: > On Fri, 5 Oct 2001, Rik van Riel wrote: > > > On Fri, 5 Oct 2001, Seth Mos wrote: > > > > > This happens using either 2.4.10-xfs or 2.4.11-pre3-xfs. > > > > Ohh duh, IIRC there are a bunch of highmem bugs in > > -linus which are fixed in -ac. > > Fitting XFS onto a -ac kernel should be fun :-( Actually it's not to bad ... I've been merging the with the ac kernels as the Mandrake people need them. I have a 2.4.9 ac 16 patch mostly worked out... if you want to finish it I could send it to you. > > I will try this over the weekend or get a redhat kernel going which is > also -ac based. That would come in handy for other people using XFS since > a lot are using highmem in combination with this fs. > > > Can you reproduce the bug with an -ac kernel ? > > I am not that good/fast at patching. Expect something over the weekend :-) > > Bye > Seth > From owner-linux-xfs@oss.sgi.com Sat Oct 6 13:48:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96Kmfc25306 for linux-xfs-outgoing; Sat, 6 Oct 2001 13:48:41 -0700 Received: (from root@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96KmR325078 for linux-xfs@oss.sgi.com; Sat, 6 Oct 2001 13:48:27 -0700 Message-Id: <200110062048.f96KmR325078@oss.sgi.com> Date: Fri, 05 Oct 2001 21:48:55 +0200 From: Juri Haberland Subject: Re: Cluster XFS install without CD... Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Mike Sowka wrote: > > Hello, > Ok... I realize I should RTFM but I was hoping someone could just point > me in the right direction. I've been working with XFS since it's 1.0 > release, needless to say ... IT ROCKS. Now that I've been put in charge > on building a computing cluster at school I'd like to use XFS for my > cluster nodes. So far...: > - I've intalled the main node with RH7.1 XFS-1.0.1 using the CD media > (got a boot disk as well ofcourse) > - and now I have no clue how to go about installing XFS RH7.1 base > systems that have NOTHING but a floppy dirve... :) I could install a > video card on each for the sake of install but other than that all I > have is the boot disk... any ideas how I should go about this? XFS dump > maybe? Hi Mike, I just did it today, it was pretty easy. You only have to have a NFS server from where you install with your floppy: On the NFS server create a directory where you copy all files from the first and second RedHat CDs to. After that, copy all files from the SGI CD over this directoy - overwrite as needed. Then create an install floppy disk from the bootnet.img file that you'll find in images/. Boot the machine that should be installed from this disk and follow the instructions for an install via NFS. That's it. Juri From owner-linux-xfs@oss.sgi.com Sat Oct 6 13:48:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96KmfE25311 for linux-xfs-outgoing; Sat, 6 Oct 2001 13:48:41 -0700 Received: (from root@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96KmRV25082 for linux-xfs@oss.sgi.com; Sat, 6 Oct 2001 13:48:27 -0700 Message-Id: <200110062048.f96KmRV25082@oss.sgi.com> Date: Sat, 6 Oct 2001 21:05:55 +0200 (CEST) From: Mikulas Patocka Subject: Re: %u-order allocation failed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1908636959-2044777418-1002395155=:7808 Content-Type: TEXT/PLAIN; charset=US-ASCII > This is enhanced version of a patch that fixes select and poll as well. > Again - not compiled, not tried. There is a bug that it does not align allocation - so things like (%esp & ~8191) won't work. This should be applied on the top of it. Mikulas --1908636959-2044777418-1002395155=:7808 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="vmalloc.patch.3" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: LS0tIGxpbnV4LW9yaWcvbW0vdm1hbGxvYy5jCVNhdCBPY3QgIDYgMTY6MjE6 NDcgMjAwMQ0KKysrIGxpbnV4L21tL3ZtYWxsb2MuYwlTYXQgT2N0ICA2IDIx OjAxOjAwIDIwMDENCkBAIC0xNzAsNiArMTcwLDkgQEANCiB7DQogCXVuc2ln bmVkIGxvbmcgYWRkcjsNCiAJc3RydWN0IHZtX3N0cnVjdCAqKnAsICp0bXAs ICphcmVhOw0KKwlpbnQgYWxpZ24gPSAwOw0KKw0KKwlpZiAoc2l6ZSA+IFBB R0VfU0laRSAmJiAhKHNpemUgJiAoc2l6ZSAtIDEpKSkgYWxpZ24gPSBzaXpl IC0gMTsNCiANCiAJYXJlYSA9IChzdHJ1Y3Qgdm1fc3RydWN0ICopIGttYWxs b2Moc2l6ZW9mKCphcmVhKSwgR0ZQX0tFUk5FTCk7DQogCWlmICghYXJlYSkN CkBAIC0xODMsNiArMTg2LDcgQEANCiAJCWlmIChzaXplICsgYWRkciA8PSAo dW5zaWduZWQgbG9uZykgdG1wLT5hZGRyKQ0KIAkJCWJyZWFrOw0KIAkJYWRk ciA9IHRtcC0+c2l6ZSArICh1bnNpZ25lZCBsb25nKSB0bXAtPmFkZHI7DQor CQlhZGRyID0gKGFkZHIgKyBhbGlnbikgJiB+YWxpZ247DQogCQlpZiAoYWRk ciA+IFZNQUxMT0NfRU5ELXNpemUpDQogCQkJZ290byBvdXQ7DQogCX0NCg== --1908636959-2044777418-1002395155=:7808-- From owner-linux-xfs@oss.sgi.com Sat Oct 6 13:48:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96Kmnw25509 for linux-xfs-outgoing; Sat, 6 Oct 2001 13:48:49 -0700 Received: (from root@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96KmRD25087 for linux-xfs@oss.sgi.com; Sat, 6 Oct 2001 13:48:27 -0700 Message-Id: <200110062048.f96KmRD25087@oss.sgi.com> Date: Sat, 6 Oct 2001 21:07:31 +0200 (CEST) From: Mikulas Patocka Subject: Re: %u-order allocation failed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > Of course vmalloc space can overflow - but it overflows only when the > > machine is overloaded with too many processes, too many processes with > > many filedescriptors etc. On the other hand, the buddy allocator fails > > *RANDOMLY*. Totally randomly, depending on cache access patterns and > > page allocation times. > > vmalloc space is also much worse for tlb usage when the main kernel mapping > uses large hardware ptes. Ingo and davem pointed this out to me recently > when I wanted to allocate the pagecache hash using vmalloc (at the > moment it maxes out at order 10 which is much to small for machines > with large memory). OK, but my patch uses vmalloc only as a fallback when buddy fails. The probability that buddy fails is small. It is slower but with very small probability. It is perfectly OK to have a bit slower access to task_struct with probability 1/1000000. But it is ***BAD*BUG*** if allocation of task_struct fails with probability 1/1000000. > If you could get away with a single page stack, then you could allocate > the task struct separately and avoid any order 1 allocation. But you > would probably need interrupt stacks to get away with a single page > stack. Yes, but there are still other dangerous usages of kmalloc and __get_free_pages. (The most offending one is in select.c) It is sad that core VM developers did not write any documentation that explains that high-order allocations can fail any time and the caller must not abort his operation when it happens. Instead - they are trying to make high-order allocations fail less often :-/ How should random Joe-driver-developer know, that kmalloc(4096) is safe and kmalloc(4097) is not? Now parts of a kernel written by people who know about buddy allocator (page/buffer/dentry/inode hash allocations, filedescriptor array allocation) are written correctly with the assumption that high-order allocation may fail. Other parts of kernel written by people who do not know about buddy allocator (task_struct allocation, select and probably a lot of drivers) assume that high-order allocation always succeeds. task_struct and select can be fixed easily, but cleaning the shit in drivers will be real pain and it will probably never be finished :-( Mikulas From owner-linux-xfs@oss.sgi.com Sat Oct 6 13:48:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96Kmrq25608 for linux-xfs-outgoing; Sat, 6 Oct 2001 13:48:53 -0700 Received: (from root@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96KmSN25164 for linux-xfs@oss.sgi.com; Sat, 6 Oct 2001 13:48:28 -0700 Message-Id: <200110062048.f96KmSN25164@oss.sgi.com> Subject: Re: We have a mail loop! From: Russell Cattelan Date: 06 Oct 2001 15:32:33 -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hard to tell exactly what is going on. I tossed the duplicate message filter into the list procmailrc file that should catch any loop problems. On Sat, 2001-10-06 at 01:44, Federico Sevilla III wrote: > I thought it was just me but I don't think it is. A member of the mailing > list, , has a mail loop on us it seems. See this > trail in the received headers: > > Return-Path: > Delivered-To: jijo@leathercollection.ph > Received: from localhost (localhost [127.0.0.1]) > by gusi.leathercollection.ph (Postfix) with ESMTP id 02BE8C00B63 > for ; Sat, 6 Oct 2001 14:13:44 +0800 (PHT) > Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) > by gusi.leathercollection.ph (Postfix) with ESMTP id 92924C00B60 > for ; Sat, 6 Oct 2001 14:13:41 +0800 (PHT) > Received: from localhost (mail@localhost) > by oss.sgi.com (8.11.2/8.11.3) with SMTP id f966CDx03773; > Fri, 5 Oct 2001 23:12:13 -0700 > X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs > Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 23:12:12 -0700 > Received: (from majordomo@localhost) > by oss.sgi.com (8.11.2/8.11.3) id f9662Aa02294 > for linux-xfs-outgoing; Fri, 5 Oct 2001 23:02:10 -0700 > Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) > by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9661uD02127 > for ; Fri, 5 Oct 2001 23:01:56 -0700 > Received: from defiant.cymax.com.au > (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) > by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: > SGI does not authorize the use of its proprietary > systems or networks for unsolicited or bulk email > from the Internet.) > via ESMTP id XAA00781 > for ; Fri, 5 Oct 2001 23:02:24 -0700 (PDT) > mail_from (ian.nelson@echostar.com) > Received: from defiant.cymax.com.au ([192.168.70.2]) by > defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); > Sat, 6 Oct 2001 16:00:54 +1000 > Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes > 5.00.2195) with SMTP (Global POP3 Download) > id MSG10062001-160026-123.MMD@cymax.com.au; Sat, 6 Oct 2001 16:00:26 +1000 > Received: by smartchat.net.au (mbox cymax) > (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sat Oct 6 15:53:54 2001) > X-From_: owner-linux-xfs@oss.sgi.com Sat Oct 6 09:29:18 2001 > Delivered-To: cymax@smartchat.net.au > Received: from yarrina.connect.com.au (yarrina.connect.com.au [192.189.54.17]) > by entoo.connect.com.au (Postfix) with ESMTP id 28669DFBFC > for ; Sat, 6 Oct 2001 09:29:17 +1000 (EST) > Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) > by yarrina.connect.com.au (Postfix) with ESMTP id 8865B29EBA5 > for ; Sat, 6 Oct 2001 07:09:24 +1000 (EST) > Received: from localhost (mail@localhost) > by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95L5qU20744; > Fri, 5 Oct 2001 14:05:52 -0700 > X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs > Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 14:04:54 -0700 > Received: (from majordomo@localhost) > by oss.sgi.com (8.11.2/8.11.3) id f95L4sh20646 > for linux-xfs-outgoing; Fri, 5 Oct 2001 14:04:54 -0700 > Received: from linux0.echostar.com (w146-253.echostar.com [205.172.146.253]) > by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95L4oD20627 > for ; Fri, 5 Oct 2001 14:04:50 -0700 > Received: from echostar.com (linux10.echostar.com [10.79.98.110]) > by linux0.echostar.com (Postfix) with ESMTP id 1005379085 > for ; Fri, 5 Oct 2001 15:04:40 -0600 (MDT) From owner-linux-xfs@oss.sgi.com Sat Oct 6 14:09:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96L9sI26721 for linux-xfs-outgoing; Sat, 6 Oct 2001 14:09:54 -0700 Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96L9oD26699 for ; Sat, 6 Oct 2001 14:09:51 -0700 Received: from alan by the-village.bc.nu with local (Exim 3.22 #1) id 15pylR-0002LE-00; Sat, 06 Oct 2001 22:13:41 +0100 Subject: Re: %u-order allocation failed To: mikulas@artax.karlin.mff.cuni.cz Date: Sat, 6 Oct 2001 22:13:41 +0100 (BST) Cc: anton@samba.org (Anton Blanchard), riel@conectiva.com.br (Rik van Riel), kszysiu@main.braxis.co.uk (Krzysztof Rusocki), linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org In-Reply-To: from "Mikulas Patocka" at Oct 06, 2001 09:07:31 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > It is perfectly OK to have a bit slower access to task_struct with > probability 1/1000000. Except that you added a bug where some old driver code would crash the machine by doing so. > Yes, but there are still other dangerous usages of kmalloc and > __get_free_pages. (The most offending one is in select.c) Nothing dangeorus there. The -ac vm isnt triggering these cases. > not abort his operation when it happens. Instead - they are trying to make > high-order allocations fail less often :-/ How should random > Joe-driver-developer know, that kmalloc(4096) is safe and kmalloc(4097) is > not? 4096 is not safe - there is no safe size for a kmalloc, you can always run out of memory - deal with it. Alan From owner-linux-xfs@oss.sgi.com Sat Oct 6 14:23:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96LN3a27277 for linux-xfs-outgoing; Sat, 6 Oct 2001 14:23:03 -0700 Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96LIGD27037 for ; Sat, 6 Oct 2001 14:18:16 -0700 Received: from online.no (213-145-179-154.dd.nextgentel.com [213.145.179.154]) by mail.broadpark.no (Postfix) with ESMTP id 1734B7DCB for ; Sat, 6 Oct 2001 23:18:03 +0200 (MET DST) Message-ID: <3BBFC654.84FB965B@online.no> Date: Sat, 06 Oct 2001 23:04:52 -0400 From: Knut J Bjuland X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.11-pre4-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: kernel panic with preemtive and XFS kernelpatch References: <1002400523.2864.10.camel@scare> Content-Type: multipart/mixed; boundary="------------A68F5C354E5AE013CABB8090" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------A68F5C354E5AE013CABB8090 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit When I rebot with booth patach eanble compiled with GCC 2.96-RH-96. I found this kernel bug. I am send along a jgp file off kerneldump. kernel BUg at sched.c:728! invalid operand: 0000 CPU 0 EIP 0010:[] Not tainted EFlags 00010002 --------------A68F5C354E5AE013CABB8090 Content-Type: image/jpeg; name="Image1.jpg" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Image1.jpg" /9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAUDBAQEAwUEBAQFBQUGBwwIBwcHBw8LCwkMEQ8S EhEPERETFhwXExQaFRERGCEYGh0dHx8fExciJCIeJBweHx7/2wBDAQUFBQcGBw4ICA4eFBEU Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh7/wAAR CAQ+Bb4DASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD6w1Sby4Txk+1c+s8jgGTIPatjWDlAQQOe TWGWAYknNTJal2sOZ5FO7cTn9KN5JDMAWHeofOHIAx60u5SeDnimFk0BkGSoHWgKxHy7QB2q F9xcYHHehiQck4FCLVk7kxkVGKngnqe1NyWGARzTVKkAN0p0akOQBlD0HpSsTLViN8qlTgn1 pIm6hj06UoXBIJGacFEbAlQwNNKwNKwgkBG7jBpkWWlIZwF7VIF3kqAB6ChExkOvI6Gi1iUl YSQFW4I9uKXBKccU7A3Atz7U1iFYlenYUXuDXYI2KmnLvZ2zjjmiJAyNJjJPUUxFOSN3U8Zp X1sOOg+R2KBAcc5NNZj2xikIKOQaeRHs+X7x60NjdkM3sNzOmF6D3p0W4oW/hpFdeQdxI6A0 0bh64POKTkxJXQ4uOmBQzgR443Z60zyiSWBpEQvJnimkJkiyrgDC5Xv3prcnPc02aMMuEbac 8mhQBwT0p2uF0mJvdX+XBHf2oLuMjsaSXajD364p4GeFOM1PLYNE7jULYyR1ppLHB6EfrUoR Q/JJFIzKD6imhu3QRyzJnZx34pkexRgcc+lSF+MY49KajKc56CjbQEriKSxww5z1p+4qMAAe 9MLDPGKUvlcdOKGxuNhCxJ60jiQHkZFA6A9+9IzOXAx8uKVylGNrj85HzEgdqQEJ1/DNJjcw BOFzTmKluRuHqaBSasP34yBzmmcA7cY9c0xyyngcfypGYv657n1p8qFGKe5IeSOcCkxtJ2Gk Xp7ilHXriiy2Ib6CyMzj5jwBUauRSsPnChhj1po6sOpB60bGlrIAWDgjr3NOdjwCOD3701mD 5JBzQCMkF+3AouGi1DBDdRtPSlVsHbjA7UxSCx65pcYJzz6e1HNfQmSUh5Y5AIz9KXcFIJ6+ vrUY2q4EYJPUk09grx4yQ4PzChJhK2wON/PWh8BRwc01WO/C8qBSFTggk4JzQ7ouEVuKYPlD twe1JyvY05d5z1IFIzDOOtGpLd2G5twPU0uVDkMMmmkjPXBPQUNweuadxSSTFXhCTkkmkABx 6mmhmAOcY7GngoI8EAse+aVkxXGsvVeuKUBvK+bBFKjqmQSOmKRjkHBp3B2ETqBtAHrSZy7Z AGKaGyecjFKuGHPJpArNjyQ8Yx0zSSqFwcEAio/L2tuHWlZmABbOM0lJsLagSCBjg96UhTjj p1pH2FjtOKN2SuQMAc09Adr6DSi9QvfmlCAsM/d7Ck3KHITODzS5OOKSlqFk9xH2qSPXpTBj JDZHoanZkZB8vzA1FIwZgoBye9Nti5UhdoJHOfSl8tQcdzTI1Yfe5PtTznGRzQ9CklYZJEjM VbgDmkwu7MaY/CkLFjznPrTkkAUoB070JikrCSqu3IAz9KYiLkNtHPBBp4OOoz/SiRzwqp9c UNiIWQBj9eBTw24hWVcDpQ6MHB4IHUUu4KwIHFCsPlBtu07jk1E6gyB4+gFKxLuQV4PpT4R5 a4I47UnpuF29AhIIYMAxI79qY6gkY4x0oL/vc7Mk+lK3zPgAimncNhwjEmVcggdyKbG0aZYx KCOAcdaEfDFSuaSVm2AFBjNTdoSVxFcgs44B9BTTDEWDHn0z2pEfptBwO1Pml8xQQoUjiqvd mllcSdSoUq/1qnICDwMmrLvyBtxxULcHI6+tVchrUrPJz0A98VC7BGLDnNWmRWbk4J61SuFX dgZODUp3E0TxzBVzsBz7VMu0LjqMZ5rOeRwm1Mbqmjdyq+ZwR1FUCL52hAwUBevNTpIr7Tjn tVXzASARuGOKmgUSHO7Zt6ZpMTbuTpy5BXPenOEaUZOBnpUG9kOQaVGUr1yaEPcu52oZFClu gGKgzLj5hj2pibiPlqRmbyi3J7YpXaG9B04UIPly3qKbE+EwQORTELfKF6+9Obdu4HzelNMb bsCyDG3b070O2Vzt4z2pFBY88exokcA7SQOaSZIvmHK4IwAOKfExVi3BqCORVYjnd2pfM9ea ewakrNvb9cUgKMxVhyR2pFcYKgAk06NTliCFIHfvSugtYayqIcAc96VEOzKg7R60yEO4LOMD tRIxI2hiOabEiVZWiXIAIPFJuG7Pb0qOQnyVAByDTywZArLyO9K1y72A7VP3Dtb9KM87S2QO hpzNmQORiMDGaYAATjnvzSaQ+ZpD4yc/MMH3qQhtwQqNvtUO3Me9myc9qEkbd1PSixDVyzM+ MKqgsO1RlyzH5QD9KSMgOGIyR39aVmySx4p7DVkKu/G2TG71pA+VKUZLgscZpDjGcYPelcGk wYhQOaZuY4GacWBHejKg4OPpTvcpRURwGD2NBILE4/CkD4bI4p25Fb5VOSOc0hxs9WEZG3K9 M9KV2wdqg8jmmbwpPFCMSjL+tJLUmTQucAYzQoGc7ufSiNVMeV6jrmkDjBVfqasTVgUc8nqa mYqMbD+dMhIeM4HSnyOgCAAYA5pXsNJyYkjAIV7mmwM/lfc3FaduQggDj3qEyFJ9gbjHNTG9 7lcvQm46ng0eYqyAEbv71MO4jrgUMBjPOfemm7kvTQRwAxZAAD1FSsowO4IyKiBBYYFToY1O JM89KbBWvqMVSVyx5HT3pm87vmXPrUgVd3O7aKFAYknj0qea6uNpdQxuPBwAOlEfCtnJB9e1 J5iKDngmnF2I+UDPUA04kNCRsRJnIIxilZ89Bz0pi5wOOScnmlO8L5hHHrmmxtIlKkqcjp2q PaWXnvTg2ADnk0IeSOPWi1itLAriMhSpx0B9KHkIOAvI7gdacrKc5XNKGYR5UL1pWbByVrDR kpk5U96cdpA4zUQfEgB71K+RxkfUVPKUpq1gZ8lVC/WhiNnUHb3qOWTJComAv3j609HBAK45 7VTWoJqICRzt2L7k0pbLcjINI5bkjAo6AZ5z+lUS7Mf5rbQD0FI8hbBAHHYUwtzjNKiBQWBy 3ehE27Dsl1AVufcdKcvTCjkVH34zzRyOhouW42tcczHaAwFC7uA2D6Ux8vjJ4zT3kARe2OlD HZLYecZ9KRiqrk9aXerqMCkDKflKgnsTU+pDbkJuUYYscGlyqkdcGiZVABYj8KRBgZPNO4kS SAK2YxxTCw3ZH3qQtj15p0KqxLFgAO3rTT01C4ueASPoaJX3IFBCnuajcsScJ34pTGMAlgWP XFK2o4j1cIPmOVpQ6htw5qKVuinoOlIRu444pNal3TJ95J70793jleahTJ6nBp+3Bz3ou2RJ JC+YIBhV5apBJITkcAcmoNrMpYDinKWGfmA7EUnHQbta6HSSsXUqM1M08hXB6VVHDcD8KVpC CNucUWRNna5YSWSNcDPtmpIriRQSxOaqM5xkgn8aGLbR833u1UKxZS6KE7MqWOSRUpu5CQC5 xis5RsYnJb2qRZFAJI5oaCVr6F37dKpClm9c0ovZg28SnPYE1SiUSncXwF9TSA5J9qBpdTSh 1CQMTuKk/eOetSNqE2/cDwOB71lOfl45xSF245/+tTEldmv/AGrcqeD9c1I+tMGBY89hWJkv wSfc1Izx7gojyMdTUuWppy23NoavIkLMy578U9dbDxKzrgH9Kw/Nz8qjHbFMjdeV64NJMU6b Wp0jauocFUJBFOfVVz86flXOSkgDaxzT1kbGP50czD3bGzrR2ovI56isJI280sz/ACHp7Vr6 2zKduAc96y1AUj+LjvVjjbqRTQEgsHyDREgiUgge2alTy1JLgn0FRuSxLdqicnsipRTVxilg DzzTWjkkU5zj+VSDAR8Y9afAWKHt6043M3oMt1QKQ+fbH9alBbIIOPc0whSOP0pib1G0knni i5SSWo7yyGJbk+tLKrKVy2M9KQlhgZAU96ilErtjdhQODVLYlyuyWRNkm/JJI608MzAkcnFR Iz+SE6ge1N83aeM81O43JdCQk+vWlMWIzIx+U9AKj3qxG1t2OtKxwM8n2p3sKzQ+BGMfBxUb LlhkE46H1pjyOEMgB3AcKO9Sxq7Rh2IVT271K31KcHuBBZsMTx2pMgtswaRsg8d+lVp76GDI lcBu3NJvqTa5czxjP0+lIAd2Mk1EtwssS7cZ9fWlG8KWJ6VaWgldD5Y3yDkjHYGkhOGO7I9K RWICtknNU765ECGQ8gc9KV7bg0XjGS3B5oIGMY6VitrYaMMq/Xir1ldRXMBlVwR6CpjUj0BJ FogZ9eaJEEYV9/UdKzNN1SO8uZYlBG1tvNLd3/2e7WJvnzTdSKVx7M0i5ByMAYpuMn61Be3M K23mocD0NYl3q93GI5EQtGTz7Cl7SK1K510R0IVgCG4IPbvREuzuPxqG1ulubaNwwyfSpCGJ yCM1akmSldiyKcjOVzT3UqRuOV7YpsWXIV2GT6050AlHzkjpmqsKc7sauW6Yp7HcBhQMdaZL hZCUGccGmFmI9M1DjrcVyQA5pCR+NZEmpEaoLQfMwrTI/ebu+PWhSTY4a7k4aMKTz700rhcr nb2zUY3kgBcH3p0rNgKTyKbiVPsg2gZbH1pTgZOQR6VGrEHDN19aBgMfnQH61PL7wS5UhFAH TinLuXJB4PHShl6EfNn0pHnCp5bEAGqkPnVrijB6ngdDUEsgiBZyKkMiYCgAgelZ3iBAdPZg x3EdqmcuVXIckX4ZYtoeN8k1Izq3Q/NWF4VkA0/NwrBhwM1sIejgA5ojrqNDgzZCkHFSMQFX AIJ6+9V5bqNHxJtz/KhZozlI3DZ5z6VTfQbsmTRIQGJY59KimvFiAWVsDtU25BGWbPArm/ED CV49km35hx+NRUlaNyHO2xvxSlzkHg1KwyQW6jpVPT8i3XJBFXGPbBJ9aqOquGrBgSc9xTGb B+XOKQlueuKZJNFChaTPTiqY27bk4J24x1qMoyjJNVV1OFlVOhJ6k1bMjGMICvsaT1WhKaE+ Xpkk4pVJxgce1UdXmeztDPHguvJpdMuZZ7cTORuqYtbD3FvL+K2u1t5huJqu2prDIWOAvbNJ fWAvLpZpAS4Ociq+tWCLpjPndIOi1nKpNOyQramrDcCaBpVb61Sl1iLO0K29eOB1pnhyOWbS 2JGDtwc9adFbw2/MybifUUKpLoh/MmstRWWYIQPMYcCnahqK2AKyJud+AKxoLdpNXWaLIwMc U3XmYapAJck5wfbihVnsTbsX11VdoLKUPfNaljOtwpbAxjrWPqv2f+ySyMm8dPWneGfOazVW B570U6jlJplLY0b68jtoipYbs/jTbC4Fyu5WBYDoK5/xc8iylkQ46e9O8KlxGjR5HHOaHVfP Yzpt3dzp43IY4+Y0SOVX5hgt2FNhwJC2eTQzfPycnP5VruaRFkZljCkYAqFX2jgZNBEzSHI+ X6U5o8AHI9hVbDbbYFyuNo69c05T3WjZvXd6d6SH+IYwMZz60aMTELMCQ31oZuMjj2pnLcnO c8CkkyOTnNJIpvQfgj5ug7c0NuAwTx1qLfhdwGfY0NnPX8qYr2AMQ+7FPkkIUPzyajyScdqD v2HaflHUUaLYW46ZlDAgHHrTWfcnJOaU/OmScbe1MI7jpQlpqCTewzzR2GMYpAw3ksDimzYV dwGT6VAEl2FS2QeR7UtkVFa6lkPyRyR60rNHgDmqas8YK5yDQH7ZxRuS1Zk1yvQpkJ+pqB12 EMRwasQAFfnY4AqFyGPfFA9Soy/Kc/hRjKAg8g06ZTv3KcoO1RsWCblIwTTuNRui7ESoVsda uLlxkDmsuCXY4WTPJ4rQSUBcrwBQyCRiTxnmmIhGTnHNNU7n3c808cyFS+KEVuh6yODlTj1q QsTyOFNQ5BGQc0I43Fe9LdiT6E0Yy4+YihmIlLBjmmK+OajDgOSMHPvTSAfJKynBBpJPuhiM 85xSRyK2WIyB0FMMo3EnkfyoL0Qp+Z9wzmgsc560hwT8pyKTPI9KYrCxSEt0IzUxLFtvpUY2 HJDYx2oWXjAGTU7k9SwhwMHJPtTkBR92N3oKrKzAjb1PWrETESbSeKTdg5R7lj8z459KbI22 IdwT6U2U7peDxTjkoE4wKaK0uDONoIGVHakDDGTTWAUAA9+RThKq5AUk+pp2E9dBSwUbVzsP XPXNNdT5YMYbJPOfShyhVfm+bPPFO3sHI3UMLAA6qCRle3rUjF1iyV5PaoS7EYJ4p25ivBPs KTWoTs1oOaYsqIU/KmuSTjB202Et/wAtCOf0p6vtkI4YHocUMOg6P2pJ+SGxk9xQud5UHbij JdiQ2CP1oHB9xQ+8cKBjvSszEAnk+1RnJ+4Qo7570+RjGoJAb0ANNiEWQEnK4FLkZwvA7UwS O6BjEBg84prb8hlGeaVrbBYd/ET/AFpwAAwO3NNAPUjnvRuxzQ9C1DQmjddhBzj0FNCyMpbG BUY57U9T2zQSnbYI2dsh8ADpTkRWbcTkUFQQcHOKjQYJIBp9Ba3uPdn3Hg7e1SR4K85I96Y7 YQdSMelORnYCMLgds1KYNEgA8vCgDBqEklyuMgdKeyvE2DyPWo2fbkjpSb7FcuhOryNHtA6d c0g+YAMOnpUSyttyODUm5yoAHPrRawnLoxFCE72OQPSnhWT5hwCeKjWNUBJJJNEUh5DZxmqQ WuSB3ySw+lKzBhtOcGmtnfyc56UhDDjAz3zSvdhIGIBHfb0pykSKZMFSeKjVPnJJ5HpTzuyM Dii7QNaCjj7pNDMQO9NYlTgHnvSoy7Rk9+hpp3JsIQcbhjFP3bvuikON2M8UKRtJwQ2aLofL fUVM8jsetOaNVYbD8vamLuABPSpGyowSD34pcw5DWdo0JyTSSu3lrgAAnOaVmHTP4U3YHPqB TuOMbodGm8+47U7nkDimFnDACkZivrmi5XJ5kgG3AYnJpN2XIKkY6+9JbyeYd4XOD3FErEuc EAGhWId+pJuBTaB8pNIeuCOnaojubGSQB0xTlcM2CcH1p3G27D9+1NoQHPf0pFJBb9M0M5wq hep60rE7sMpz0AFJscFeIF1MQyctT1B2BjzTVUDIcY4oEnyjaaGTJdgIbb/SkUllwQBg9aXe dpHfvSIwGN1Jt7Eku5toB6dqiA2sQp4JzS5Ykd/ShUYMSeBjpT0SGxX2rt3DnNOBTdg859Kh uGkKgRrk05NwVeDu70JlRV9CVfKDMOeRSH5l28j05pW2DnIHrSDlcrzRe4aJ2YqO64VeV9KR gCd2OTTlxyWG00khOQ2MA9MUJ62Y3FCHDna2VbHFLwuMrwBSZLSZyM460Oyq+1j1obRKTFyd gI4Hag4wOcnvSH0HQUhXJz3pOVikrj42Cg/LnPSo1k/eYK5/pTlUkcg/WlGE2kdT1qlqJxSF VlCkEH2xTUc4IwQM0HKtu9e1PwNhYjrSYpMbk7sgd6XG5t2Mc0iMM45qU8HrTFew2I5kKn5c UEDPH4UkUg5wuT05pCe3SpsxttyFIBPBwTTnKxkMuD6j1qID5hkkZqZ48AEHjvTaui2+jY0F myxGBTixIwe1DhS2AeMUjoXG1eMelSmkQ7G3riEsQr4FZA4UZbJHGa1tYkEj7hnAHSshwRwm KFowTVxkhJbI6UY3KcfLj1pF4bNLliefwpt2LbWwAx+T82S5rEnvriLVEgH3Cea3CWIC46dK 5i/BGriYuFABBB+tY1pOKTRk7JnVyKilWWRSGGeD0+tMmVWQDfhvWse3uJHuAgIKY60a7qcc c8MCbo2AAx61SqaA5X2NthH5KiNiz/xccVWlYMuCQMVz9zfy2ziQSYjOMitQmSfT3nicArzz RGrzXHdJFuOaIR4aQhh2zThtc5HPFct515PuZj0HUVraDeSvD5T54PPHNEKtyXJI01aCMEZ6 nrQ8kLOyRSAsOcVz32iRdTkgdsgn5aie4mstZESxFtx60KrsNPqdO8qIhdtqjFMS6s2HExLH tWDr95Ik6LsbBAyvpxVG+lcov2ZGDgelKVZDU2zr0yY9+eCeKwfFsERRZkxz19q09Ekll0+O KZ8OBk8d6zPFiubZVQDrj61FSTcbhe7NLQVi+xIxY4Aq44BUsG47CqmmZFhEvkhe+fWrLgnJ I/KtoO6C1hVjJjDZGKq6tHB/Zsm4ksatRsPLwoNUdbZV0+TYMNjnNKt8LE1oZOjmzGkzoWUM w+UE1J4eWOKzuPMZkO1toHrWdpumTSaI10X+Vea0tCnkfTp/MhVyEK5PauSmnKI1oVfCqiHU riRhvUvkflRqzhtbVzlQTwKl8IQvLcOZGxtckGi/+fxCQWGFOcHvTj8FmDfuoNakKPBDkeXw fzrUjtIGtAd4IdeM9qxddzLrUKyDChf4enapdaivtPsFuSSImX5fcU6crrUWljX063W2QRoQ QO9Wnjz8+cY7DvWd4fuTLYxNIhwR3rSUncSeh6D0rqgtNCltcYEBy7kjsKpazPJbqixNvGM5 Jq83JxyRWBLJJe60bAZUcYPpyaJytoZyS3JNP1R/tAhZuW65rU1CKX7NvjY4PQg9K5a4Rrbx B9mwfkzlvXGK6zDLEMNuGOlRCblFopO6ON/fnV2BJEgA+bPXrXV6Yj+UBMzMw5Nc/lW1wnOS uCR+ddOGjk2vCSFxgjPeopKz1Ki7D037yd3GeB6VJnHzHkVGG+XK96RS+wl8AZ4ro1Y7N6mf rlzLDbs8Kbjnis8wzXEQlMjL7A1tXn2eSLY/yn19awb22utPRbhJC0Wc7fWsKvNfRmb3NTS5 Z0Ry+WCjAFZgnmvLplViMHpWpa3sNzpjTxko5GCKpeDot+qSeRMN7MQN/TNKTdtwsMdbq2uU bLMjcGrmr700/eARkZ5qxe3duLoQu6GTdg/Wq/iJmNiUaUAY4FDuqeop7mPp6ahc6VNdIp2R k7jjp1rQ8P3gm09i7MWQdaLAzr4XuLdH2B8E4/i4NVtBRk02VdoyR2rLmlFDuVzcLLM7Bstn HWnWk866ioKkxEcc1Y8P2tvLdtC5EeOWZq0IzZtqPlRFW2ng1alJrmuKwmqXSqiwKSGbnFYO qwruhaR3D54HrVrW5FXWY2lByp4Pal10/aGhlDLhcdqKk20FtTW011FoqEEt3NXCnI2Pxj1q np7xPbLhcH1Hekvrk2iMTGeRkEGuin8KZexoxYl3AvtwOvrXN63dTNfxwH7ik9O9bFjMtxYi RgUc9RWJrwdNVhdcBAMEn8KmrLTQzerLT6fHc2rAEh+o9qvWIeKBY5HyRxk96iuNQtrW3jZX 3uwweKs2zLcwK7NgHoMURXvLUpJILhIp4jFIowfWmwIkMexAMCqviKS4htA9qu9x/Kn6dI8k CmRdrEc1TSuPoWo5wjmRlO0CsaSZ9RuiItxVW+bNaepvJ/ZzqABxxgc1m+FJZnhYuoEpJH15 pVH0Rnd3NmCJbVBkt5eOcViXl4tzetBFuG0DmtDXZrhNPdEba3sKxdIuIlVTOpL45x61HPZ8 pSNrTbYxMpLBSeh71ka8Xl1RYjwR39avWupfa7zZjywpwCazdZjmtNZhkmcNGx6ik+UVtQ1S B7e18zAZcZ5rT0md305Si7c8mq2vX8U1rHBFEQOn1q5pG6KyWMH3xUwfvlxehR8RxM1oJY3P mdwe9XPDUSJp5edcvgbQKZrUkkUBcgEehqzppElnG28An0rRwTqXBItRI4QSD16Uvy8/3jTS zA4VhgU1gxbO4g1sxpNEuSCASaSQ7Rg4OKYzlhgk570jghcjmhh1HI+0YY4U+lMkwrfISVpz bGCFW57iiUNsChRmhaFJJ7hnK5AApMoeNxLZ5BpqhtvH40gjw24YPvRuF7aIlZQFwB+NQ4Ck 5zUhJK8Go3bIwMketJD0vqJg9SMjtSqQ8ZBUjmmxhgcFu/FDmWJyhwVIyKZMtyORGdggVuBn I6VI0hMeGxkdhQZZEjwDgN1qLeCSq8nvSvcSuhobD5/h7ClzvHyr9aa8TAAluakiATrwKG9C ttSCSM7thBzTdikj5cbelW3eR92cEdvpUZQ7AMYNJXYlJEBQu4wcetJKGHIxgcGpHUgcd6rS ufu5osx8w5GXDLjANQSImwj9RSsQAMnFVbiWT5kToehqkieYkjkDOQVPyngmrkBITJyRWZCJ MqWNaNoXB60MGupcgZSu4Z/GnGMMNxNROWIDKwHPp1qUlh82e3Si4lq7CBMgbFI20jcNkj8a VJG7KQD3pGc5KYyPWmhxWo5iCB696SNUBI2nOOtRqCCxJ+lPW4kigwuPypSuVJWBnC5A4psK ouWb7ppA4mIbocd6SZyVCnGAeKIkjn2K+IwcY60Llck9DTVc4DHIP86NwKkknNKzTKumOI6h epqJAY+GPOeaaHIGSTntSo25vnGQaYrW2LEZxyeh6Gp48bTtGT61AkqA+X27e1OQ4JAOR2xR YVnIlSNmyc/hUgcrFtYDd61HGw8vaSS461HJvBzuJz2NJO+g+QlA356UqgAHfzjoKZBuAJbn vSOzP90bapaCWhIcMSVAXFA27S2SKYnX5qc5+b5QAtDVwjJIWEAvt3daUMc4wOO4puWIyp6U u9FITBBx19aTuCsDffJPNSGRWA2jC1GCAxbGRSKrMCR0qg3ZMM5BzkDjBpFQsW6Co1JVs9aU sxfrip2YmhxPG3A4qNVw5PJqTGzGM5PU01W8sNIQSooWw4PUOcnkqDT7cbRhnx9aUsxYOQMd gaa/zcsKLlyaHS/e4x9abJgkZyF9R1pVwM0igZw5O0ntQ0QmxylcHuCOKWNVYbt447U3Kr8s edvvSIuFIUUJCWpKx6gArnqaaSqOqnn1NDOxUA9B0oaPKAr1oJUug4yAuVVcL1FKxYumRkUi qFOeeeuaT52YkZCeopWKSJZpFU42kgCo0AbAIAB7UrYdQMcHjNIBs6knHepSsW32FEe4MpXp 09qVXZMqeoGM0YwCwLfNyOaQH5ACcMeprTcjrqKAZBnBFBARx3pHZsKA3IpVXzGz0osFwLqH 3Ed6eT8wwSx9aYxRGwRmmlipBXgntU2sN7EkknzEhMMD+dCP0yAB3phO45bJ+lG8F9oBxTWo N6D5eeQD9KbtBOT1p5ORkg570Hg4znPTFLyG2ORueEzjvQRwe/rSLKQMYxTQgfO18UOyBOwu cjac496kLIR1IqMgZ2+lIwHQ49qVgluKE+QtuGaFbZyOv86BtC9cYprNjsTmrVmhSfKScKxx yG6+1PlkPkeXtUgdD3qLjAKnml5PNJrUFIfFP5UJG3lqbkMwJpAQAQRn3o+YncSAB0pS7Ir4 VdjpCFHsaTfGHwE3AjrSR5J+foPSgZwWXG3PFNLSwOTsSgkjOMDPFIznk8kjoaaXxGE3ZB56 UvGwY5PpStYXNoKs25MMMY9e9MZju+UYFCAsw38+lPfC5zzTtrcqLTGqQRyeakGw5LEZ7U1V BXcBijcrHhcGi2om7CxttJBB9jSs+SSeM1HMzoi/xA8UbwOvNOxClfVjgy7gC2PUA04yY5C0 0KpcvxkDvSSSEuAF59aLIpXvdDgefmIx3qRGRV2qeAaip3ykdAD7Ukl0Brqx4cPKTninB8nI 6A9KjL4UBRg9yKaGLJkD60nHW41qDseQQMdRg06LaVBZck9jTIssm4kcU9XVlPXcO9NrQbts OYjqBikz6dDTN2VwetAbFJJBd2JAc4yTj600j95uB4o8xT8o4Ip27I2hAPcd6rYhu+4kjMpy Dn60sTMRhzx6U0FXU7+q9MU4OroGAx2pLUbswJBJwCBQpJ7mkLbRjHNOjLFQT0qguAIQgstO crwV446UMwYcjgd6YAS+BjHrS1Jvd6D0xj5hn0zTtp2BhjGajZWwC3bpTwSBjv6UmmOSGuF8 wFSdxHzCnRP5bEK3P1p8bhSDsBPPWiRgzZCgH6Umg6mpqzKH+Tk9/aqGEVMnliKs6qu6dpA2 3HUetUjs27lzz1otqatJRGHrUsQ3Z6dKjwGXcrY9RQW2ICOp9Kpq5kx0IkWXIUuQc4Arj9eW S51Ryny85IrrZ3litzLGcNisDSbO5n1cy3TgRseMCsMQvdViHq7ljQmidBC3+uB4Jqrq8DNr almRmBxiniwlttVebzCq56DvS6rZySXiXUTsrDkmsrXjqOSaLtxptpAIxdMMsAee1LdGGOxk COR8vHoaoSw3NzIplkJX3q7fwtPpwtlIBAwGHUU4qLi7EuLKXhwE2khlCnP51q20EMMRMY2k nkVl6DYS2cYj8xpWHUnvWyxVsk/LjjFaUqa5SnZ6HPxNA+vr5nCjrRqxjfxPvgk3Ir5FWYtN Uai87t97j6CpJdKiXUftMb59qiMHyhYz9dMi6xC2/fEwG4n8K2dUext5o/J8plKjOKiu7Nbg 7gAABg1Vh0KJJvO8x2zzgsSKzjTcdyoSSNSJo3VWjXYKxPF0kSXEMCzgk4Ymt4JsVRxgDjFZ 99pNvdy/aHHzrxitpwfKkJ6u5PYSBrWMIc4FWy2xSCMk9qrWMKwxAL0A4qd0yAWOT71pTvsX ZW0CLeuScH0GKzdduMwMJMA+taLNhSFxmoZ7aK5gIkXBHX3p1IOUbEt6GBp+qImjT2qqSXxj 2qXRrW4bTXdwV3Z4rUtrCyjB3QgnGAKswIsa4Xp6Z4rCnTlFWEznvDt22l3MwuIBIAcdPamR q9zrD3iJw3BGK3p7S2eQu6446CnRwwIA0aAfjSVOS0YbmRrtrICt1DuLovCetMub+fWNNSze NlCDgEHit5hkBflIpkkCFy2FGT2pqnJaRG421KmjpLbWSowDbMDmrzNnBOcGlj2KNrDK015P m2BeO2a2hFxWo+a+g7LKflNc7dJdW2rG7iTLcZroDjadx47c0kcieWSVyT60TjzK4pK6sc9q CXUs6XYUGRj8wx1rdQvJAm8bNo6Cn+Wjrk446CgYDnexxWdKDjuKyOd1PTZE1A3Nq3LjkVpa Qk0ZKysGJ7nitAcgnA5700BWbAA471ShZj5epNuBwoAwtNkLM2D92lwi8IciljCvuAOMVrYa nbRGfq8Ek8JWF8MBxWSbbU2hEckgZeh46V0LKCwYHpnINKBuJz9aiUOxNle5Q0yyENsyqQQR yCKpvpkqT+ZbEr3471vKqBc7gMds0yQkquD0PaodO8bD5HLYx7XTG+0meaMFl7kVPrFo97EA TgYABFaDl8YL4BPOKdMkUIVY2LLjJyehpezbjYmSSM21sHj0zyfMJHoafpFjFDlZWO3mrqkM MseO2KEWq9ldD0Md9MczyPG42c9BTtPs/KcsVCtn0rTIO8AcZ606QgJwPm6c0KkkrMTRn6jY JeMu9agfTA6GLd93pmtVmYAZABHGaaGDuSf0odKL2EnbcisbfyE25+6PzpuoQpcqFBYH0qQt g460RYB3nHB61fLpYe4y0geBdjDkdQajvLdbor5oAx0q3JKZZCeppij5/mxipdO6sNJWM7+z AWOSG2nrWhAipEoU0s+wEiMnB6+9JhViBXIqlBLUTHiMOdhxzRtjQkAHHTimRcjcOvrTx6Zw AaHFMaaSI7kboiuwsvrUFlaLbLlFIyc1aMpBZVXg0gYhfm60OC3EuwX4F1AEK4I4JArPXTUQ /LgkD0rQ34BUd6Qkkc9fUVLp8zuVbQpCxVNrjFSyWcM6/vl3D37GpsEjhsYp7uPLAXGfWmqa WhK8yg2m7SuQGHaraJ0UAKQKdMkggWQOMlumajdjkBQfrUxp8ruaS5baBNbx3MbJOwIzSLbr bIqRkYxRgg5796UEZO489q0cdbkJ2HbgiZC7u3FDseOgNIRlSq4HekX5upzVDWoOzB8sQO9D CR1ypwO/FOPIBbHHTFMVyM44yaQSRIItsYIYZxQ2RggnNR7mC5H6VICGjViAGouw5rDQWBye 9KGG3A6U0vuG1u3QimjHc4oEiRWyNjHaByCKaXXaVyBzxTevHp1NHysCrIOOQam47K+oYIwC OeuaURSSEuSTimu2AMnJ7UoZgMgkZ6jNO9xtpbEaK+DuGfTFJGpUkvgZPpT0kEYIB60rAMhH btmmkEXqE53DqPrTZBwFHIAzmmkZiCFsAdTUjhPKUKeMdaVgnoRxA8knipG3BQxKkGkVRtDc Edxmo5AQSGGEPQZp6k2uMkDvwvQVXMZfJC/dqyrHGQeBQr53MMDjn3oSKVkjMuEZ0zkACoYo yZCp4ArSVIXcb+B1pJTEp+Rcknk1SJZCyrgKAKU7o13HgU51AO7jpSyRLNEAxJHpmpa1L5kk OjYH7wyOwqVTu5PA9KhRGXAHAA71KhVvvfmKTRMtroe2/lQeMVENykbuQanjWMjBZvrmnFU8 vIHINO4uYZy3yngjp71HtYZLDjtUijI3Zxj1pkzqANysx7CgaXVkanBII4FN354I69KlfYyA H7wqC5GI8quWouVHUGkAOwnOaSCQ7SHXntUCCUKGkA5pXlZB6g0ydizJIDHtCjPrSR52ZBAI PIqoZOeOlWIjn5iPpSsO7RKZCZM4HSpI2VVJHPt6UxIztDHvUsMSq/z5wetMOYkiLE4AqYTb ovK8v5vUimQkM7EEADpSK5VyDjHY0CbbJEDKNvUnrQORtI78UI/O4fnTCCzbiTxU9RrYcTht vUimyA7htOR3FNjYOSFPTrUvyICC2SelWTsNIOOKeGz1wDTAdse0E57mn4UKDndSYIYplDEO crnjFOyc4BAx1FNZ3D7QvHalAOckDPrSSYXHPnYNtLG68qRzTSQFxgkmgHA9KVrhe5KG+QAt mgv5cWCPkNQk4GcginIS6hSRgUWKukh6S+c/AzikZgOCM+lK+EAK/Ke+KbEvmdTj3podla7J MhsDAFISFX1YGkz2IHHQihM4LY9s03qQmODnGAAPqKXfhQqge5puC3BOW9aDxhe4qOo3F9Bq tuYqe3WpQ5U55IHQ0j7RGSq5bPPvUbyjyQuCGptDsyYszNuxj60skxWMxRY5qJN3ClwTjrTx tD4xk9qdiU7DUk2gRyAlqepBLKG6c806YbmGfvDvTAoUk9SRRoUthy54zkpRxuwOnakGShyS CO1CsDGAAAB60X7DcbK485VQMDmkhfbnAJA68UDcybhyB0FN37FLhTzwRRsQ22KhJYMwp7mM EHIPvikYExjAApuA2QBina4SbY5xuG4YVRTIzkB0I47UI5A8thkCkCsn3FHsKQ15kzPty+Bk 9aakiMMfjTXDDBYZBoJUOAq8UrBoKrZHA9qRVUMWXOO9BL5YAYQ+9NyFAVc4NOw3oODndjaM HvUpADDPNRBQWwetOL7DtP3aHtYlJXEY7mIxt5qRlwqd8jJqIkHJUge9KCzqBkkiklYqT10H DYGOOeORS7mAwMFTSqBtOAAQOSe9J5iKACBincmyHIu5SN3I9KRlx0HFNEmAQq8HrTlYEEE0 Na3H6iqSCflyKYgUMRnA9KWNducHr6mhxg8j6n1p62Kik1qHCDOCQehxSqSoJCg5p24bQpH0 pmeSccelJPQlpNi7HKl+MelKG2oGUc+hpUYbNvIBPFM43FcHNNCv0FGTxkj1NCngnPI6e9Ny Q2ME+tPIGcj8vWgat1DLMOmKaTj2+tS71/hXFJIgfOTS2KWiAE43Ecdqeh3OuRgGo9xxjHyj pQrHBHQdaHrsD20JJAFfAP4U1hhc+/ShdjOd2RgUpKKeSaErCvfQASB0xmmSSAnABBA596eH XgEgnFRyEHggcdxQk0yuZWEHOMVICCCM4HemK4V8Y4p6hAjZG054pX0IdgwcAAGh2+6FABBo EgQEH5i3f0pvoFH400itGTxje2QBmo3ZuQhHHWk5BBPTvSIVab5QFWjW5N9SVC7xgFQCPTvS rlSBjNBO1iM5+lNkZgwKqOevNPUTHFWZwXXA7YpFBBIz8tBfIGc0MQOpoDV7A2QpA6E8087V ACZ6UolRYyHUH0pg2sDIARntQ7srTYUI0jj5jTsbDg9qVSNox1FKH2qWGKWopN20BlXapLDn tSMvzcHH4UoAePOzJ/vUnQdaNRWTL+rMTdsrADngCqrAcYyBVzWHR7t3AwQcGqUhTaNvX3FE r9CndjJFHmdecdqVNirhsk9jS7/3ZDIMnvimYwABQncljwwk4PNGI0IZVwo6imKABgCmz31t AdsqlSB+FJ2vqFrCMvmEkjgnvTmwE2MMgUkMishk4IbpSMSe/FG/Q1S51cVyrRbcDIqPYvB5 zUke30yKCRkgYzVWSJUW9EMYAYIyv070jIGbcSQadhQMqck9R2FLuzGMrij0CSs7EY5fAzx1 qTPTPSnF0CY2YfucVEUDnqfyqVqhabCgDeSchT2FK4zzjA9Kr3032e2aQDJHbFUtJ1P+0fmU EYOMHrU80U7MVrM1G+SMAgjAzSJIrAAD5jSlgZAkhz2rH1LUms9QSFIHYE4yo4qpNLcrQ2k+ UdOKazgtzmmxtvQHnJHINQ342WbSK3zjtRsrkpE86FXwSORxScsme4rC0G/ubhnjuDkK2Aa3 Ygp+8x9vehTUti4wGoSUY8AjtToxuHpim84xjBBoVhvORyKGrkz7CzAqvvTVyOMYPepTKJHC EqD70kg2OV3DI680RBWsRK20sMZz0pVGECuQOetImPNILDP1pHeMsQWBx0qyWubqSSIoZcnc uOooZgQdw4qME7Mk0xpkNuTvUc1N9SpJLYdIr8FenenKrMu0HHtSMQUH7zd9Kb5yJDlnBYHg elNsm9hw2LMA5IFLOqlztyRUUb28xGW+cdhSzum0BmK4/WgOZbk8QLIVB4HY1FJuJGwKPX3q BLuLO0Hjsc1IWABKntmpbbBStuPK88LjHWkJwu4dDVaS+XqWxjjipILuORljjxnryafQ0XLY kUsBk8VVuNSgtiElxvY8VYklG5twC7Blveuc8TS2V1f2/lRFeev51m5NGTZ0kW1ohJ3NAUlg B+FQadn7IVJOQPlzVbVL2W0tzIqk464q1K5cZcuxp/LtG7IY9qYSQdpqvpN0bq1W4YfKex61 aJUvyeT0ovd6CWruxYwFG0DAps/yMuH470/Pltl+fpVDV7sW9pKWU8jAI7U5OyuJjL/U44nI jO5lFM03VEuwd4IYHBzVLQbe2ltxdTTDc/Y1X1EfZdUVbcfI4yTWHtHv0FKyN/ULtI4QocPj vWY+r+UUBUhWOMgdKz551a7EIJ55rUvYbRdNAQbpuponUlH4ROxcEgkiMm8cDms24vGDDyiS M8is+C4k+yMQ2Bkg1c054I23y42k8Z71SquyBal3TbxZZNgcB+4NTarci1VRuDZ9Kw9SKwak DAuxXOcinefHcajHExJGOSfwpOq7FXsWU1OWO4XfHlD93FbMbCaPcDnPUCqF0IBYTBCm7ovq KqeFTKUMczk4P3u9EZy5rMFqbowqZ5GO1NkOXAQfKfvE0ki/vcDp70Nw/P3a3B2HeWhbhsD1 NOKkjOQRnGai3BWIUk56cUAORgA8dqGArptPJpoJI2gUvzFsNnNG5kmOBgYqVcpNMRF35IfB XtQBld+MZ4xTsDYSuAT1qJ94G3mnewtL6inJGDwKGAA2r2o3sAFdelIG3gleKSYtxuSRgnJF LuGOmCKfFt3YJANMfG44wRVbjWgHHY4ojxu5OBTSCxG0ZA6044Ocnn0ouO6Q4uD04pEwD82d nfHWmH2PPpSjIU460xX1EU/vDhjtJ4FK2VkJU80zDAZbHNI2VYZ+73pXKfvEnBXORUTZPQ07 dubKgAHpTguG2k8+tJMlKwRJxgGlkVmRVUkEHr60wk5xTl3KuCego0FuNP3sHrT94A24BzTW xjcMUijP17UJ3CwPhsIBhjS7vlx3HFJ2+YDcKDuI25FNDSDOCQY8570xm9KfklQApHPU1HIg BznOO1AP3mOTcF5xio5HJ+Umno2UBORTZGwRjGcdcVLlZjUdSLKqCMGmuWZAfugdRSOpOP4j TJS3mHIxTUricWQzHLd9vahT8vU09gNvH5VE2R0qhMnTnC59uakTMT7SCcc1TQkZOeM09rhh zk5pBuW/NAOCuc0JICzKFIFRwyKAGK5NWFK5Dr37UmNaqw5EDkKOO9KxYZ4yelLuBJ7H1pwY EAYye5o3QpKwihc7WPJ6VE4ZbjGeRUkqfP8AKPzpmTglVO4cZNDeoK/UXYWGSvA6nFMeME8Z x704ySBPmzk0soZUDnnPXHajca0K00PGVfI9KrSKyuuFyM1eRwDllO01GVy5OcL2p7D3KRVv tG0KduM5qYTIjKrdKkwrNtXr61C9uHbrgikJvUtRyDZxk/0qZSxbIOc8YrOUui/ewO/0qUXC qV2tih6D5bl7LJLjbxTTuOSPuZ71Cs3JbJYmpYZWb5DyO1MS00JA5yFJwKVyN2A3FNcFV7Mx 6mmthVG30pX7hYlAVfujBPXHelIVnBA6VAJAVBPHpUyvkABfyp3BrUkaQhsnrTS4LYAwKMkk bgMg8Zp6FASTjI6cd6m/cLXY3exyRxzSNyOtIm5Y2ZmBJNKgYgdM00wlBocWBTBNIPmyOtJg Ekdx1pqFeidaYcug5lUsAM4HanZUNkcKO1NVsZwOO/vTwVwcjOaYCx43EsRt9KWZ9w+X5V7Y FRMrB1cLlDwfapFHcg47VOxSh3GqXWMHBJFSRlnLELgDqKSSRmAXHHrTVz0J96L6E8uug9Ml ic4x2obJXHamDO/5TUnUAdxRYpXEBKpyRz2pMLkEk/WnDac54YdqBICNhUZ7VSE7iAYUHilJ Rh0bcDQ3zHk4wKUdCW69j60r6i5UxV3kgHoe/pTt2xiDnPY0yB16OcA+lI5PmY54FFgS1sPB ycEnPc0LGBIdvf1psYbPzKRTnz/CeKWwnfYfC6kHJxjjiiTGCDkelCDapbaOaZJK24fKCRTZ fJpcc0jGLplqasm1d2OcdPSnF9yDYgDd6AwVTwOe9JqxLd2MjyVLP17VIuOG3fepcxhR696j XHahByimRVAQknml+XaMjaQe9IqoTlvvA0o2O581Mr7UN2HZMPmHsDTd2MkdqHkCsABkU9XA LYQEmi+gWGhgeT3p/sx4pq5A+6KA21snpTvcppJCvgf/AFqXzcxBUwpJwaknlWRhtUAY7Cop QuRhKlsmS0uhwVnyg64zTHUBNxBIXpipUdgox6UiMATjBx60XuShIZAYz8uNw6GmohTrz6Us j7nG0ACldsLwOabdhtXBiwQZPWpSWkjHA47VDvBYBhjNPUnf8tJ6oqNktSJnwOBmnEB1BztY HNPXC5YqPxoVY3DbiBxRGXQTjfUkYhFDEbs0wBi2QOabsUDAf6UpJLLk9KdyGr7DlBXdvAJP cUz2Oc053Rm2rwMelNAIJZuvrimUldChcsDznvTp8HBXhaTepH93tzTZumT0FJ6l2uh+3PC7 sU0qRk46U+JsjjgN60b9rHjpTFa5GrE/Ngj604SFeSu4Ussg2bsZ9MCmo2WBP3fShu+gclg+ 8SQME0vlspLP9w0sayPuOFA96QhiNvp3pi5baDJmX5eSuKeZDIowKbPG7JyMkdCRRF8qg5wf SkrCcWORVEmZNwB/SlDjcdv3TSMTJjPNIUYcimPlaRJ/D1pvI+6BzThynJGfSkHTpSbDl0uT JtAJPJx1piqxbKHNIkgDAMDipCUUjygRTuK1xrAk8DAHamqRIM4KkHkGlHmMxz2p5wVww59a V0PltsMILkK4wB60/GCRnNBxhSCSfel5Jzxik2W43Q5dqrz1pu0lc4yKbJIdw+XI74qRyfK2 kkD60XsRa2jGbioABOD2FOfeOgpo+WPOM+mKejhowxBH1ocrCasi5fSbrt1x36+tQvEQNxxi rF66SSsdpypxUGC/DEjNTzWBxe5C5JA208g7FZuAKYQAwA6DjNK53DByaaXUOgBcsQvNZHiF Yp9kczbCp4wa1xnucH2rA8Q7jcRjcBlu9Z1Xy2JbdzUtlCQqqtuAHQ96bJewhcAYI7VNaKGg Te5B28EVgTmZPEG5F+VuDnp3/wAamc3EtS0NmDUrScCOEYkHDLnmla8WCfynUbmHANYd1KId cj2RbVP3sevFP8VSqdUtGjJQE8k9TxS9vzIITtqbsRYRvJjgVXtrprjcIxnZyR6VZldm0csC VTGOO9c34emNo13LKSSxIBzVqZLnfVmo2uiJpBLAQD8ucVbtZvNg8+I7h3rndVM8lm8ypuUc 4rQ8LETWIdSQCvSop1GpWZSXNqjQvP8AjzlYjqvSsDwkrKZcE5L8Zre1BmFhKVba2MGsbwrH Py7OHINKq1zIFfm1N5/uMzD5sdawJtQdtVFs8eePvV0kzFsI/wAg7muXvd6a4gjw4OQSB9KK kthTep0yxiONGZ+COvpWJql4S7xwtuA6mtG8UjTZX8zKomc1keG4xd6fPcbTtjStJT+yRqVv CgJkleRics2B+NdOdoVCM5HWuf8ADJK3LlVxhj17810EnmGQYAGeamk1exqr2A5Zs9M+tV9R uRawk9cirEpAO/dljwax/F8i22iPcs4JAPHetG2kE2mVWN1dRFlkK454qbw5ezXd29rJ8zjj OetV9Cea80sy+W4+Xt2qlojBdTkaPcJFbmsouSnYhbGlrMlzZ6qIGBG4cnPSq+oveWt1C28B Dyc96b4llnfWIDg7TgNnrVvxZEYpbGOOZJlI6j8alSk2wTsWdWvki09GMmwsOQDWMssOzekr EnqC1W9fjjbS4GKnOQD+lWrO0tU0yOWXazEc47VHPJysLQZ4dnE6SK8pXaOPes+8eWPUfJjk JDHoa3dMFuAQkakDuKwrry/+EgDBuewq23a9wdpKwsYurO/WVmYoeq1r6lMv2QMzAb+cd6t3 EYmdHePbgAHFYviExrPHGVJTPBFOLcY6iastCjdMQY9kxTB7mukslFxaKHJ3Y+9WF4jtbd1t mhk2qFVn+vet3SGRrZNrcYxRTk+ZoErrUwLMK2svbSz7I89TTVt5LXxAii5YRE889qSzXzfE EqyIp2tlTTrpmbxD5RQ7fX060oydir6WNHxFebp1tI3BGOGHU1l6jZIGtg0nLc5B6Gn6ysi6 nC7DheDj0qTxFJbfabVrTcVBG7Prikk5PURtWTH7OqHlgMA+tPniSZVifbg9c1DbNi3R0xnv VLXjci1MlucODkYrePwgkai2ghAjjcY9qeow+32qrp0kjQJu6kctVpz0xWiXUtaCyEscAgVR 19kGlugbB9TVosAcdar6rbC7smiZ9me9TU+EiW5z+n20j6fGsbFgoG5hRfnZNAjS5YdOateH r6PS53jnhLxqCuPWmJGuoX5aOIgbjt9K5rNRE9WUZ9/9ox7SOTjgVotBcweY8udrdMiotSga zuEmXnaealur2e5jUO2/dR9kppbFGTK6ZP5ZUAk/nUsFu19ZQxAcqc5FW49O32TgDgnpUWl3 01jMyhACvHIpJWFEj1IbL+GCc5deKjtUaXUGjXAK8D1q5bwtqF75lzgEn7x7VFq1u1jci5hO 8q3JHcVDjJsbsOktJILeYyMcdeTUnhFz5W8EHB70t1fpqSoI48HGGx61asrU28WFwvtW8U+d Ep3NM4fkkZqPG47WYkZ7UgDbVDHHrijnIIIAB5rezuUSAJ2AGPU0iuFcrzk9DUcpBY4Oc+lK pwCR97tmmk+oMc29RtIBakU4Q7zz2ppYsck5b1pXLGP1A6U7DTVhiHzHK5xjkGllfJGByO9J FyNmBk0hHJViBtoauFxGZ5Gy9OiX3GaA5Me3tTFX5ixzU2HcV2UMcnFL8p6Dj0psmWAyASOl IQ4j68n0ppMW7Fhk2napAz1pbjEchUHd9Kht/wB0CuCw6kmng4YEHrRa49ExqsQ3zYFPLMAe wNI43sCx5qR1JT5j0p2Jb10ImyIsn5mz0pcfJwOT60FdiA5zSEflU7FX0AKenQjk05TgAYAX 196ZLyhKsKapYR7CQaLXBakmVLY79qasZRjuYnd2PaltozI5APQdT2pVAcnEmSKfUHog+7wo 6UDk01TlmG7pQcDJHWi9hIVyyZB70RjcO2c035pMAcmljV0OBj3NNaCFYsCMklf5UkmNhIIw KcFZg43gGolBwNwBx+tJ6rQIvleo1XyoJ59KdDlmZBjJGcmo3cbsAfhTlQjcwbbxRZW1Kcr7 ERVlGeu09qjkDyOWc9ealZyYic4I71HGxZcd6FYG21qQgENg5xSshY8DrUjfK4LA4o3fOcKT TJSuQPGwYKMADr706KBpGx+Qqz5ZwM4JNL5bK45wPaluN67ELRkDaykEGk/erIFX8atSgugL du9NlU7QwOTQEHZjQ+PlzhjU0JcMNvJquowRu65708SbThT0oRUkWJGlMrGTFMclV3bhj0pq sd48wsS3SnEdjwfSmrEXsIGzhjyPQ0r7m3bRwfSmyDC4ApFJ2DjFDL5epETIEEYH4U4IdrAr kgUhJLcnjtRIWA6nn3oJdiGNiB83yt6UoDFd2QT3qV5IvuFfm/vUhjIUEHj2pi2IZMbOQT7V V8vdICcqoHarl0pZVOduO471Ew+ZQe/Q0DSY0YKjJIParEMzI3K9elQyoQ+Oo9RT0JVVyc/0 pITTLigq28nLHsaVs5xxzUG4kksee1OyRGCHJak1cE7MkVRtOQCcUQyhUywwaZv+RQR8w6mk YE53Yx6ilYuyZPFL5nJ55qTJKjPY1Vt15yhP0NW3OwAHvQloJtIPl3H5Tz0NIWk24OMiiTcQ G3fQUK+MbhnPrVWsHNfcZ5mAWAO48EU6MDHOMmlkXafQmlwIsuVLEjihEtgu5mPTAqTGVD8K PSo1wF3DqetP3FgBJxik2IN204wSDSbnYgk8KOBTsFlyDgDvTW9AeKLIq4473lChR060jBgS PSmx52Fsk80oYlDgkE9aa0Em0xyj0ODS5KMQKacMQNxGB+dB4AbO72o0K5nYcy55J5poOT3z UshbYrBMA0ikMMmhMTYLgjJNNLMcjjA6Uw/ezzT0B6kcUrCuIg9RU2/OMjJFMyQf9n19KGYZ xnp39aY+oSytuyxwT2pyb3YYwOO9NdvMUZAyOlNQOGznjHSi4myXc5winnNOMZ3AHhu9RYKM COM80ruxfLHOOhpN3Wg426jnIjG0HkdTS53KAwHtUJPzZAJbvTg2QSeTjimg0HBflO7p2qRA ynjB9KjLgAA5OfSnBsIGJ46UCemwpzktgZNMRpI+WXOfenA4Ge2adMEyArkjGamxcZRtqRE4 BUDO7rUkYIAxg00r83GQPenDGQarREsUdTnvTWIWMrjJPelLN5nGc9sU1mG8lxkj0pKyFdgh 7dMU8tlcUhy7bkwox0NNj3LJwv1qgJm5UDOCe4pZ9ojCqBu7mmSORhiuVz2pWGUDDODU2SYl qhF27RlefWhhxnrSJxgZyM0N944ztp2uUp9BuSv405CwOQctRgEDpT0Q9SeB2oC19QckDHU9 etRjDYzUuNrZxk0MAQSVFTezGn0CcxMyqq4K0oAJxnacdaiZfLCkck0u4ryRVXB2uOyMZ6VI zZjAwM1HnefmyB/OmgPuAAyoyaHqTezFTOfnAqVWVxs28+tNiZmDKcACoi4Rsqcg9xRboO7u TspZuccccU2VAMEHd601i3XJx3pC6j/Vk/jStYpMk4HHTikZcHPalYYKnqaJe23kdzTQcvQX e20KMYpqEmXY2MDoafGArYbBDd/Sk4UM6pu7fSgLxHF2yR2HAzTAnzZzmpFAONx7UgHOB+dC sDkIPlOR+NKp656dqeojKYIyRUR3Fs9Km+pSsxX4AYkfhSxvtbIH51G43yKDwBVj5I/vAEHo aZLauNaTfKW2808OpyT27UFQv3cHuDTZSGAOAD3xTsLd3HFtzf3QBxSPywHOabtcRsy88cCi KU5VnTHsadkhKVmP+bj5hx196bM+Wyi8elDIGfI4zTh94FhyOtRy6lqdthu4Z44zUjtlApHS o0X977deae2WbJGc02S9dxBIygFFBI9aWOV1BLqGLc4A6UcofLI60ZKng0cpUpK1i/eZaRyV AG7jHeq7sOOcnFS3SMbgYc4B5HrUUixiXzBnI7UktCVK6sxjAHBU5pKJT82U+VT2HrQwMYy/ 600tCW9LDlKryefr2rmvFVzEt5CCy4BGT6V0aOjDJ5HcVkajpMN1OWkXIP6VhiE3YFC2po6Y u9ECsGVlyOelc87St4vS13fKcZ9K37GJbeBUAOwcDmoWs41uDcKmHb+KqlG8SEm7mTrBc6+s UZUBc7uOtaWvWK3MEbxAPJGM1LPaRvKshALAde9TRuYWXCht3BFZ0ab1uaWaWhzEGoXlw/2M qyovBFX7yyeLSmMYHmdl9avG0jE5k2hSecVZIQsOOAOlaqDE1bQ5yyuVawkt3ibzweT2A9Ku +G5FWJkVDHjg8d6vyWsAmDKgIJ5qXyYlJ8pAlZKnJSuCbjsUtcnMFoxCeYWHYVl+FLhZA3mK 6Y7YrclVCdrLuz0NJDBHAd6quW9KuVJykmVFu+pOzr5b7sNxxxXJ3Ek6ayHC/ulHpXTttPHG ahFvGzlioHsaqpTcrEPV3C4Vbqw2RsVVhyuO9Y2m/arJZbUKyxt1x3roVC7MADHb2phiHGRn v9amVJt3Hcx9GElnfNlNyNzk9q32Jb5yeO9QyFZGP7sIAMDHelU84P3T1FVTpuOo07CuQQCO R2NZniSzFxp+w4bd0BrVZxs2KoUdhVaeNpFCHkjoaqUeZaivqYEH9q2kAtrZ2SNuo7Vd02ye FgX+V2IycVdcfMA+SR0pzzb+GUk4worJU2ndhc57xKbltSjjQgv396uWtnNKscsoyB+lVb2w uWu/NYsXB4PtXRWP/HuEPUetZQ1kxpIrXtoLu1+z5K4+6azYrC8jHkbyw7mugcopC7Dn1oVQ znHykDua6PZJu6FsQ6ZbNBYyRhPncYzWJJox+3C4ctuU8GuhXzFwMkqehzSEEZyc0ezVrE6k cO4KFLFhjvUOp2KXlv8AL8rL6VbQY6cn1oLPk7sAEdjVOCasVzNmSNKee38ncDxjmrFjb/ZX WJySFwMCrJ5bPTFDDIyPvVKpxi7kttIpppsUeqNcQkgyetOm09Ptjzl/m4q23+rB3fMOBUWx zjc+TVeziJXZXvrPz0DYIz3piabA8Sq7VoAFVIIOBUUg+6wOAOT71HIuhpFDLS3W2hKmUkZw M08Ku0rJkg1KyxuEYDH1pkmPMOea0StoHUfGir8iHCN+lRuJFcqCCo6GkbdggNgjtUg3iMbu 9VsNsYB82CD+VPIVmyAMDsacxHHIPFRIoEgxnnrQSyveW0M0u5YwueopiWyxDjjI4xV2VFWQ 4+lRuMDGfxqFTje4kQvCkkflFQQfUVXWzjjOOBirgHIweDTGRS2GzxQ6cWNJhH8tQzWscxZm UZ7mrC8AnjpjBpqYHGMj603CL0HtqMt4kRVC4wD1qaSOJ8oVBU+tC7S3yrtFPUgNjnFHKkS1 fUqQWVvbs3lpgE8Yq1FjcQ3PHFLtUEhTx70hQBQQeTSjFLULDSeMZqRlA6HcPaomGxip+YEc GkwI4w2eO4zVj3JPLVjnfg/SmM+4dAMegoOcAhSAaRywTb09KaCwjOoAyCfpQgwhGSc+9JGF Q/MxzTyV3cHihjaG8AZP3h3phJc/MPlqSMxsCDximOSF75/nU3EkPcpjC8YpoI+8TimE/MMH inkbjg4oLsk9QiYP34z1p0mUO0HINNAAO0YoYFWx3ouS463I2JBKinRIQSD36U0qSSSTmnDO du7HFNsSFbB4IxzSENu4JPtSMwAyTQXUKSGwQKSuxCsxB24zSEFxgnAxSxlJACpzjrSjJTpg UdRyd1oRgHaExyKc8e0D1NJJlSOnPTFIT8xDsc9hSbZSbsOUsinacU2PAU84zSgnGCR+NJGS wJYAEcCle4lroNCjzOB+NO8w4xgcUSKGBySAaaFVSDnIFNNFavQehJG7O0g4C09wUI3d6icn 72QTSByTz1o3Jsx75ySOeKiXMnAyMdacTt+6eoqIkkcdaIpCeo1yQflGT60LICOc+9LbElyS uMdj3p+wYeTIUDtVMIuzISVOVDc+lNjDqSwOAKajK2XC/Me5pQWPAzzR0LWu4jNIxAHIPrSJ vUsuehpSSGHPSnHDfNSEmPiSR2+VSam2sDtZTmooXZd2GI9KV5HYhgx9yaexKWpMuNpQ5Oe1 G3cwXgYqLewGR1pu8kEE8+tF7hYmliCkkVAVfliMelOSTAHmNux0pwcMxIOc0kxtjUV2GSc4 p+VDDP3uxxTQdr8HApHKkAnO6hbg+hPuLZAAzTMlRhsZFAzt4cA+tJI2/BJ/+vTsPrYY3csc A1XXzQzbuB2qaQqRhyeOgFJ8xPc0BYhYOcFTgj2qxbs5BVsVEZTu24GBRvOc4pJ3E03sWAjt 8pA2dqWaBQAR07CmxuxA38DsBT1yX35+Zeo7U5XHdrQqeWQx5JFOIXaABg+tTsnGRwGPSmtD hS2OlIHqyHaxbcQakVNmBzyKdsZQuG6jpSMRkBjkjpR0C19AdcDPrUkZwjA96RVz95scUxXK tjjNCaHytCxgqCOlTqcpuINRAMTuI/EVPE+FI7e9CZEtR0bNIu3AB6ZpsiyqAAN2KCxUjB4z zTg+TkEimNK5Gf1p8KnZuJ6mkTG8bqc5J6HFDdgaHEEnC8GggBMbtzelNwDg5O4d6SDoeMtm lcQ9eFxng0xlcuNvQdaSRN5wSVxUkavtyo4ovcGIx4AX5SOtO3fNkDIpsgG7GMUKjg7mJ2np THYkHJJx09KjQAsSD1NCnaxwx57U5l2AEdTStbUTH5YDbkmmjJBI6A85pZVaPlvzpEYsMhSw FCHFIBhmPOKUk7sA/L6Uv3gcbRTc8D1HBxT2C7voS4VUPPWoR78Uob5sEcehpzks+VQYxyDQ haschx0wfrQJvlKiME9BTN/VAvB6Z7UhLBAP4h39aNxEhOY9jAr60IfMVlxgL0PrTOWxwee5 pXITKiiw7aDkDRLnr70Jzl1BwetMJfYFHrTg7ICq8A9RQIf0GMDnvSY+XaOQKhDHcRzT1LNw OtGo3F7jy3HOMUwOMgAc9aTY4BBZTnpipN3loIyvJPWi4Iczljk9aRfM80AAYxk0hQLJ8wJO M05OG+Y/SjcLiTtvb+6V9O9JGRnBUbvpTg2wn5aijEjbpSuCKFoImj6bVx6nJoaT52VRQpEh ORjimpzgKnPc0LcpEqlvK2npTCx24XPFKyM/yDOfShVCnDHtUMalZDgZPLXcgBFJlwuAAc9q Qs5AwM9uaXJC47+oq0TbqGQVyR9BQBIyEhsEnvSKeuR27UONwGKHoJMUZD4fgY4PvTweTuIB 7U1QWUknIHSkIyxGCT1BqXYaRIGUdcZNEcgTcjIDx1IqFASMuAGHalbewJBGaqxV2TRZAJK5 +tJ5hHOADSB96AZxjriiUKZdo9M0hW1GIjNuGTz1p4VFACr0Heo45JQCMAc1KMdTnFFxMR2Y jBHOe1MiIbIwMg8ilaQM/wAoIUd6dGjEtIAKe4+a2wuCQQDilBJj5IAHQetEce58r97vnpTJ Mry2Mg9KBq7FXeF3MuBT0eXOVXgjpTHbAABOKfGC65Hy8UNCtZ6iAu7MAM460Ese+DSp8rHn GevPWkJyTj6UWKV2PEq79rbVP86kdgwHTiqzR+bjIGVqaHCthhn1pcpPPdaAFDHk7felYk8k AjsDSEOpJCnGeBTFLM5yceoppWFYepbGelOJGB2prEMuORg80rDAGT+FMaQhfGFU5B70oEm4 h2Bp6NEsZUj5uophOR260mx2tuOeRSoCY8zuPSmqeOWye9OhTO5/LzjqajV1OQy4NMUXFsmO Cm4n8KaCUPPPHFNBG0A8tninqOAG6+tK3cctNhofPXipQvJDHFMKqSCRyPeiWTLfKuB9abJt c0LhT/Ceaq5O4hgasXLbnO3oaiKjbnPIqbpIFfqRqQeh5HXNPLF+o3H3qHG2UOR26CnR4BYs cA9BScuw3EF3ISO/cU18u28nNFwQtu0pYACsSbUZhP8AJHlPUVMpR6lqStqbe042n7tAJEZ6 hB0zVW2u2ls3dc5Azisb+1b2VmhxnaeBmlKcSOuh0Abb93rTPvEOc9aoaTfh7uOBx8+eRUEu qbNXNkUOWPB7URqRvoOUm9zXRhvPzZ+tC4BJJJJ7isbxDdSWrR/Zl4JG4d6v2btJEG5HFVzq 9gtdXLS7WJUnHvSE7T14/nUUd1bw7hKNznpTkBdd3TjimUlzDvv9iAKR0IGW6HpQGxkY+tNJ 3cg5A9ulO9iVvqMUsbgEAbR61I3LZbB56DtTQQeOcmjGxiw5PpTE9NBspCggAkGnK/yAdu1I MleV+bNBYKQD949BS5khpXHZ56UhIzjnnpSCUmTlBgcE04/MTjFTd3CVkwlxwuMEClLnqMHA zTFDE/N+VUNbuI7eLZkqzcZpynyohvWxNeajaeUrKmHB+bnin2RjuYhMjfNWfpmnrcWzh2By vy571V0aY2t8bSXKjdhazhUbeoHRBN7liee+ajD7ZDx0p7na3TrShosbmGatb7FWsO8wFAAu Se9Nk5f5uuKQ4GT09KaGypPJq7u4NX1HDIXaGOAaYxYuMfcqVCCDtI57GmBSC3OR3oYkwMgV SuOOtIXAwGPUcCnbQy4CndTJVQKD/F9Ki5SsJgHvTGDH+LFOHTnrQxCoGyT+FUiHqDYHWmFj 2pct99uVNJuQSEdsU0MJCzLvaT8BQjDAPDexpMp02nJo8oIOD160DSsDlerEikJ3KT1FOWMG MknJpCAEByMdhQGg9VUoCeoPI70SMdvXjtTSAeQTnvTQ21cnHWk9RChivRcmnRkjnoTRE24h mOB29qJVAf5Wz707FXUtBH6+oofAT7wOe1JIWG3O1fp3pWO0btoIPSjoS1YZkABgQPamlt7c nDUitjPTn17U6WMjCg9ecijcLgzDkMctnggVExKkhSRxzmgYaU56qKlUl/nwMD1otYtRuLGd 6j0xxR+OBTcE88AUrAAFd2eOtG4WURkcvmB2AOVNSLnAPfvTfuxqoI5605mKxfL0PWgnqI+5 nVVxtoVCwYMRxSI21wP0pGwGJycUtgfujsuAFJ4HShnJABpqFnOGIFNlkGNoC+5xR1E2LlRI DjIpWZWc7BgCmgZQntTCVAyAQTVDjdkoQHnHHekQux2kAqD8ppiyNwA3HenuchQMrS1CSsDK CzNnn0pob5M/w96JOBzTS24kbsChscU5asQSIBkNj0pyHcg6lu5qI7WGCAQKfHIYxlRkUtyZ aD84GCfek4J3cUA7l3gZGKYWJjO0Dk8UyR2Vd8Fce9NcKOg/GgKyKAcbqHZd3zZDAdKTY0NA K/cYgHqKcz4HBpqtkAYpWXA5HFCdwERlJ3EkkdKcuWG8jJ71EjK2RGOPcUqF48gtn6U2tCtB xY7sPwO1LgM/Xbjv60m5ndQ69OlJMc44HBzUCTJP9ZlcgEU1Qu3DE5pkbMH8xhx6UMP3mTj8 Kajcadh2QKam1nIIIpGAYkDoDU3lELkMCcZ60JWG5ERDebtj5PelbMfUcEUse5yW4XHUU2Rp HTaxGwdKrYW2ojtuG5cDHAqEfMhPmAkdRT1bYNqL8tJsh5/5Z55+poC/MRBcfexQx44PNIyk mggqR79KYm2IHUgjHPrT1AwFU4B659aZJEVAzjk9qlC7RkjIFIpagU54P41JGM/KV+7SZXIC /dxnFAc+1LccnYew3NnIUVCYwHbkkVMG/dFjg1AHJUgetC0CzaDgjB+72FOiwq4HXOajIJ5p gaRSNvSmiUtdSxle7jJPSnDY7YHUVAHAydoOeOe1N5cbQ2CO4oKT5SwF5PIAH60KwBG4fSoV PrzipUZdmSfmNJMnfUU9S5AFQuzBcrjBpwaTecqGXHBphQAYYY700Ve4xjnHBoTIfnPNPaN8 pgcMetTCB1LH7/0oY+goJGN1O3c/JnmiE54wDnuaarbGKsDnPGBU3KU0lYchP3CdxHPNPjO8 kcjFJLJhl+UDjmkR5PM3YAHYUIhu7JGCHHXjvUL4z0Bz3xT5N3Qtg0qrlecDFNCasQnlcHpS Ih2808vycCnqjxRbyykN29KSQ+bQashEYi7A0/JUZ5quXfeAFGM/eqUs0jFQeQOtNIUh+1ny WLKewxSx8kKTyKRJTuw7bm9aQuASwGP607k6omdMHO7NKFwOT+FRxOWTO05PFKNwc7zk0tyn sSOheM7W2sP1pEyoBz8wobJXPYU1uVyhzTsCkrDlYsxznjrT1Z1J2k7aEBbOCFwOaQNmP5W5 9aYnYZIhkwdxGDzT2chcZJAo8t8AkrTVPzcdQc4oEnbcBu2bgKkzuiAI560zd5k24/Lnt2FP 2kZweKhysNvUazErg5I75NHGwbGK+uKFJViOMHsaXKqD2z2ql3C4rIBgoSSetNIPUHGTzTgN 3QHGOtOKMqjJ+U9KVwUuhGgbPJz6Zp2WDccDGKTOG6U7cxwMDAp3E9AYYQHB3DpQkjuOQMnr Ty+4BAAB701Ao6nmi40rilypCKMrimjk5NLLjOAcg85A6UhJOARwO9CYS0HMVGMHNMYljkH6 0jg/w4x3pxyvIA+lA+TTQQlckcj0pwLKoAIyaYuW64Bz3oZwuSwye2O1MSi2OX5WGQfenM43 ksxI7CmQYIcue3FPRFxuYZHakxWFJbGSOD3NNZlKjy80/wC8NrNgdaYylcYGKSY+Ucm5Sufm J65od2QkL+RpU5Uk0yMHJzg/hTTF0JoiAucEsR0pHcjAHGOtIk6plARkjmmfK7bScUAh8bMJ C+4ndSyhQgPOe9MRGU7W5A71M+1fl3A5pNoaQI6+XuyaQyKxAHB96ZIvTb25xQ5G9SVAJosD Q8Ftx4xjv60vAJ3NjPemOzLheeadIoMWO5/ShIaYq7mXMecD9alQMVLAY9ajtwy24XP3RQjN tw+VNJq7E5O1hF3MzBhz2Ip0imNR1JPXFMkc7lxwPanfM7cg0xpXVxBlQccDvTlKkHIGfWml dxAzjmnkIOM8570xNjoioQjGQe9J0Jpkit5YYOFAPNKrMULDketJO4Wu7jmYBenHtTUkABDM R9KeDuTaAuDTRtWQxuO2QRS2GkkKg6k5HoaaUy2GPB7mlkkYAB+nQU5gPJY+XuwetV0GnZ6g 7DaFI4HFKR5YBPQjjFRFiyA4pwVvLG/p/KpDd3FPzSfMvHqKd90FFGQeh9KPlKhix46AUi53 ZzyKpCbHI6kd9w60hVvM3Z4FNVyCWcDnpipFfDZOPxouCaStYew+UNuJJ601QigYJ3d6X72T wPpUZZXbCLz3NTzMErakg+aTpx60bOc55p8eUXccFR2qMuWk3gjB7UR0LulqB5Y46ik7+xpW bDcEZI5oVuSAuTjuKolu+r2DdIDsD4T0FSPD06HimD5Tnbz3BoUPtDMQAewpOViVBA6BU+UE n1p8e4pyCPrR5mQFxgCnMdxBPSmncp7keDuOeR2qQRhiQDgCkODKEUjBHNIQzSEDGAOwpOSQ r2LkmN2AKikbahJ4x2qT5gMN1z1qCUfMQSNwp2GndaiQOrx5U8980SMThccDoaYoiKlCSpPa nqcrg8gcLilZDuraGJrtw0bxxD5gxweavwWv7hUdVGRkGsvxOrfaYSnqDWvbyObJZZAcLwWN c/xVLGaXcS1j+zbiuCDkGudsriC11m53wllKnqeMnNdN+7mhkIkA2rkEdM1zWkwtcX0v2kMF BOMd6U1aVhQeo/SMjWPtcK5IPINJC+fEoEibmY9T2rctYIYjknAPHvXP2rP/AG66kdW+U96z UbSTRTleWpb8XxypqEYV0wrDOOhGa2bUhbSNwFCkdKwfFvmJeRJvA3OMk/WttVRLGNRMHYDt Wkf4rEroztR095L+K4EpCr1Ud601bcmwEgVSlvoEmWBj8x+6KtQMHIyuPpWse9y1F2uSldsW 5V3Y6g1ECf4V27utTP5iLlR1Peopg2M9D14rRMWm4rEg4IzgdqN37re3FG8lQKTPOScj0p7D 0auGcANwc+lRgmRjvABzwakLKMnFRgfMW31LjccZdBXRoz94Y9qbnnKjFPLAcuCQKb2DHGO1 Ca2FJJDlcg/Mc1j+JZEkIGzIHFa2N3pzWT4jgdVjKDIzkn2rKsvdMb+8Uku7iMxwxg+V1yO1 EKpJqAmclmB9a1bWTT/7OBxmTvWRYxCTUTOrEIDjFZJu+hokdROUEaBSSxFM+6QW4qVVjkUb SFx696ikd3lCggqOua6obaj3Q87CjbjkHpUcahBgDj604kY2nJxSDKnGee1NvsW/dVmIFC53 MeuR7U9mIX0zSt87cquR2NMRF8w/MT+PSlfuSodRVfjNK7/KNuPehvLOQc+1NKgL8vXvTsty G1caznBAOG7UwE7gpyeM57CnyKAq/NimMWQFc8daSdmPRkrMGXBOahc5AU4+tAO5Nw49qgMg abyyDx3psprTQnlLFFToFpoIUcZpGcluuSOlOi2yOxf5T/DR0Fux23ILhio9KYQuRuzt7Yp0 jbdydSaairt2tyfShEtWFLgU5WDIASMGmbBuJ/DFDoNy/MQKdw1Y4jqvamzA7VEfAB5z3qQg Bsqc0xxh8Hke1JiVk7CMC5OQAB70sRbcAOR70DaqdDjtSFj5g7CmgGopeRuQNp796SRVBOGb b3pQPmJHc9KbKTjaelGpWiEVRuGCcDvUnB4PHvSLGBEHzx6VG7vswoNS7sd02SFVLYDMcdOa NoAyCc9xTUb5ADndT14P3scdTRsDs2MJAPIyaYXKcYJBodgz+tBYDrzQm9ynFDipb5gMkd6f lZF4GPX3qFZCrfdyDRvDZOOnSq3IcXclfaijnk9qZtUMT2NMLFiC3WnZZmJxgfzpIJRsh8mY yNoBB/SonRmbhsd6e7nyyBwTTCG2Atz9KWo4SWw8oO9AGRhs8dKBkpuxx0oYkAH34qkHXUcI lZM7sH3ppjAHFCliM43E96G3hjk1N3cFLTQYDsONoOetOIBUbGwO9NZnQcLuJpY48ZYnn0qr CtcJH2JjOAajVuOOgqaQKqo5wxz09KJyjPlVCDuKAViJGJYliAe1DHc+8nJ6ZpzxZ+YdB0pk KjJHQDmkkERUALNuOB2oOAcZJ96G9OKIw4QlmBHYVNmDt0FwqE9eR1qIOOFBzzUj7mUDOBUW 0g8VaEh2795k55pzhWPFRkKF3E809iqRqwO4n9Klgo32HALgktgiowRn+ZNIp3A7iCKTC/3u PSq1KUbbkw2E+lIQvIBJFRx4VWMhBXtSMwjVQrZDVOtxySSJHOE+XOKajb8KSOe5qLcSCuTj NK33ApA9zTYlZiHCyEBgV7Uh2sRu5x0pOMqCAQOlDAM/UDFANWEYgMOTk+tOVwrfNknPFMcg nn8KUAMwLY46GmhWJJwrdOlKAQuzPA9aQOo5xmn7flDZGDSTDqNXjPFDBSpG47uwo75z+FAQ ZPdqE0O6CEAYVsgd6dJsD/J0B70qgBS3X6019uMjii2twUhVkU5YjkdBUbBfvE9fSm9eKTaw IGDjFOwSaexHIH3jaRt707aF6HrQVwSVGce9K5yvTBpA3oINm05yPQ0IdxzjnvTBkjB6elSK D24oa0BaDkIGRyQe1BAY7WzSYI+71FOAJO7vilcdtRyvkbCeF6U+ORV5ikJzw1N27VDZG4np UiIHcrxnGaYnpuAKqMqOO9OaQDjbz2qFWC5WnBgDwM07ErUSQFvnfg9qepwMtn2qKT5mDclh 2qddzJiTCjHApo0cdBAyh9rjJpZSqsOD0phTJAY8joacQccc1L0M3cZIikgjOaJVO3OKkG09 eDQRlhz07VN9SlZkSoAoPJHcUKQTkZA6VKSyv5g7jHsai2EAt2Jzj0qmw5W9RFwWbaelOJH8 XWiJdrcEDdQ3yyHfzTEk5aArMTgE/Sng4Y85b0NMTHmZGAKcxQsxBx60myrK1mTBwD1B4pBy eB+ApgWJYd6k7h1p8TZKtnGRReyIt0HSMFXnp6UIvygDgdcU5QXmIwGA702RcMRuwaE7j8kP kI2YPrxRGcHJpFDeWWLZBpoJOADmk7hytkjSAIeO9GA4UhyFpGO0YyOaQYKYPX270PUNgx8+ d2R2o6DHFHBAXsOlG0ge9PZWBMcmVTOTTJHLf6tsrnvTy2F201UC8YAFRdplcqlsOyAcdeOl M3biE3c+lOCKrk7ixNN2ndk4Hv61alcTiK2HIGCMdcd6eQcgd6YSNw2jp1qXJVtx54oFdkLe Yso/u45FS5wAPWmklm3evb0p0hIwD3ppkvzI58x/NjinSE4DqOCKdu4wxytMBUR7GJ68UFK/ QGIYEY5xTQNqg9vSl3DJKDOKF25UkketJ3GtB8h3qCg4poLZC9R29qduAJReATmnoCFLZwO+ alO24OQ122/KR+NNcvkYOR3zUm9duCv40g2lQPTvVKwnITBOdvGBSAkFWJx7U/ZtXPODTVG4 FS2O4zTBe8PKRj5urY61HyW3MOaVCSuM8CpEG77x2mkhytsICxTPf0pC2eXPI6087RDnnzM/ hTAByXp6MGkIPmGUJFTIu5vUg0xH+YY+6OnFK4HnNJng9MUNAtdCR23OQ2CVpCCelMTOSQcG pBktwQKjUm9gT1yaRG8wkg/nSCQrketKFDKV6cdapId7hISjDcuV7EUqyEgErigArHtySAMn NIW3ojK3yj2p7FN3XKhSqMnyOd4PNLglhwTio5WEZUjgE9qeSSeMg1N7kNBIJC/K4Q9KVN6D YBlcZNL9wAl92OcU/wAwt823GR09KadkCSGoo2BsYJNEnrnnvSbscjkelB5XnI/ClZs191Ib ExeTaynAqaQqp+Vjg9RUShmkCrjJqTY0bHcd3OKd7EXu9RrtswFXINEeSxVxnPenJwTt60EZ HXJNNC6ilDnAIpoKxMcgk+1BPGcnIPWnKgJ39QfWknqJ6gsYcFuoHNO2dO+eaQlgPkAzSFw2 B0I64oaHHzHjk8UgAXGBg96UU1f9ZlcnmkmU0gYujYbkHtTgVOMDA9KbIWJx1NOCiNf3h59q oWtgbYednIPWlyTJuHBpjSrgHGBTiCcbT170WHugYNuIY5okI2qMHinBgr/MCw/lQu1h8vXt SaCL0GlWKhgwAzzS7jx6UhyDg09VI+ZhwelC0NJ2aBH2MXRQSeDkU15CDlVPPpUufLyMVCPl JYd6bSZinfcuPwxUE1CyhW3HJqUdPMx85HSo2Y4Bxz6UPYqIm9BlWAzj0pu8KgK5FLGoJJcA nvTztHQcUJ6BK7Zk65YPc2yzx7gy8g/Sqg1S5ksW00qcdehroZCzRBckKO1QywQFxIkYBA5H rXO4Pm5okxV3qZ0ANvprBuW9BWZobXK38juDsPTiumVFUEMgI9DUflJncEAHtSlGcndCjHle gxoi/GdpPrWBqMM9hqSukfmEnkiukkLNjB5HeoZMF/mG761fs27MfUwrhZr67WSVOBz0rZhi /dqAACOD71IVUgEIBj0pYzg98nvUwg+a7KcHa5nXWmxPfRznBdPSr2wEKFJXnJxUsq/NlFGc d6jAYHGPm9q15VshapEkxxhd2ajOCuGzmlwCxBPIpOW644POO9NITAKFTaAST0NBGDjimNxM CSQg7U9SCxZQQCe9UxJ6DRGDyuMZpMdeTUny4xgZpjEetFx35tBGI2H5hiolCldpNOmUEDA4 oVF3YyKNC3fqJEwCletLcIJ7byznB6nFKBgHj8qV3wmApH0pSSaIeq0MYaOIuIpGI3ZIq/Db wwLgD5jVsrtALD8Kj+UvyBj0qOSKeg0tLhGcnFSbRtwDz60FVVwVC49Kjl3b88r7VbsxXY/H Tg02UHGB370iM+TnoKRpM5OBSSsF+4sJ3lt2dw7+tLKTgKi85yaSMNnLEAGnlhG2cg59KLFc +g3lSC5wKH2k7kzSSDK4fk5zk0gbAzxVWM2le43cHfFJO2GwTmlLg9cfhVW6m8vHGdxxRYSj rcmxuYDdgetI52tsVQx9ajt4pIsAjO48Z7VMAN7LkA+1G5d7CAoFJ/WlXaWBIyfWmsoCYGMU iSKIygHINLqK48NmbJGaWeRHYqgwT3puc7QcKSO9NCgnHrTAev7sAs240sjK7fKMU0IQdnUi hSBuJOMdqGNOzDDjkkHPpSEAp1IYGkRwzcc460rN8xxwKEJu7uPZhsH86jLHIOaUsGYJ3NMl UhvLIywpoQ5CSSxJNB4G717Go9xRsZFPEocFhztoeg1YepwNrnA9KaRz8ppsjlxuPWo1lUrw /wA3pU3YiVRhiTzSyYC8HI96RsBBtYZPNVnnXdtYgCjcdyQEAAAd+tI7K0hxwKYksbOEB478 1HMwL5BAAppBcsCQKPlxSYZcNxj2qFpoQMBhkjmn+ZHtGOo75oaHdWJJHQ8rye4pVdnIOcL6 VWS4jEpGQxqxFyOOlCJY9mXIwOlKW24OOKYxUNgnApXJ6cY7Um+gLRiiT5QSPlNKTvbavTtU YK7dv40qska7i4GKRUlbUchKnywcetIjdVJzg9ajSaKWQ4PWnjbv4HApiHSHAIXjPrTVVgoB JzTi8cjYbKAUxiVBG773rTBMcgznJGewpGO5ueKRgBjHJpjZI4OMUkNu4SltxVenrRgAhxkn GKcyfugQfmFJIUcAr8pA5+tBImNw5OKcf9kU0BXxtPI6+9NyecDOPShuxSSaHb+cAEn0odsv 0xUYJzkdT1qKVwOpx+NPpcaS3Jmw7KNueaJNhUoo71FFNkbgeF6kUyOeN3wDnFCaYX10HHgB QelOjYA8AFe9KxIYOqAU23ZUSQEZJORTFJtjmUnjBwac0XQkjjpRE5JwQSajklRJNufpmgL9 B4kAfIUe9RyH9akRTgP1zSOoJwODU21AbDGXycjI6e9Dsx+UoB64p+NiYB4HeowGZ8hutO41 puR7c8AdO1PjTOdx4p7hImG9wpb0NIPnkPzDGOtF0F77DFAVsLyDUq9hRGqnHQU+MxhmDv8A ShWCVxApwclaRAGRip6U1mDkgnAB596SbEcW4EClYh6CFnUDvTgC2O1EE0VxEELDjkGnkR8j cSQKopNWI8Y7gU8FmI6ZAqMAE5p4K4IOc9jSE0MlPODwahfdvGOMdRViQxnG48jvUWMnIAOa AEY/IW70qA7AScmpCsRj5B3GkUKBgnFDKQiL83zHGe9LllyDilJj6yZIHQVG7YG/tQhXFYBm zkAgU8EqFO4bjVNLhHkKsQG9Kn4OCO3ekN6osfMAHUZ9adJnO9BhG7VCHIA549KkduAoPH8q aE42Qo2hst1pcMzZzletMACsCcZpxcgHA5oYg3EsSM1LGSWOM5xUbtkKcYPejzWLbhxSHcce W6ZofKgH1oQqFzySaQEkbSSadhA27gAj3FByV28/SnpEgJZgc4poI3cHmi6GrkWQCRyGHenM VeNXB5xzSyAs/wDjUcriM+Xjjtii47NCpgrzzSomaQEBgm0jjrTlZgxCrnPf0pA0Gw8gU6Fu g/h9aaxZWJJyadC2EK5UZoexLY9XJbagwuakCF+T19aiBA+72pUkJ65FJIHboSbnJ2EcUxTh yozxS7wWGTUmECnBw1UC0E2nOT0qRl6dj7UxcjaSQT3okcu5x8uKAeo51PAJHHpSDI5FDMFj BPJzyaB8wzximSxCfm5796c5LYx0pjpvX0AppIyFBIPek0WpWJgQSUOBgdRTQp2k4OB1NDDG P50hfCbc4B7DuaVik76MUYDDPenMex61CnDfMOe1SDnqST3NOxOieg6PO05H407Y7EMWG2md sKaCcLjJ4oQnqxX5XbjNJ5ZI3k4HpTo2VVycGkBByDz+NS7phcUKqgEDBNDxFBuIOD3oVdzh R93sfSht6kxls49+KL3BMGUFQ2BilDb8RkjaO1RqvLNux7VGrIGLDknrTUUD1JWDJJtONopz Mq5UDIPSq+7qxJJpY3zgngGgTLBOY9nNOZCFGcfWolfacYyO1P3Kynk59BTbKvdWJEX5OMUu Cc9DTIgBJg5xSsFjZsE9c4ouhJDkxuz/ADpZsCP7uSetQrIp+dQce9LvyQTwDS5RqyFGWOAC opTw209e1O91OcUhOTnPNMGSKhWI469yaRfmXIOKarZJB6UA4PoKVgfkO2hdpODzT3CiT5Tk UxHXf8yZx60OcH60JMSHEDfkkqD0p0eFzxUZYlctyR0FLIx2LhMUWBCmVWjKbAxB4OOlOJYH ccZPHFNVgAQI+vejgdzii2g1YCVHABz60Fixxgg0KTgkEc/nQj/veVyB3pbaFREJKjgZ+tKD Iy5fnFKjbXz1yadIxUZ25z6U1cl7gmETnqTTsALncSTzg1CfMJ5A2ilyXx7dKTQ0tLkvzAcg An1pD8uRxQRuGCSaZzypGce9EU9xbimbaNuMgn0qUPtjbBG7HSolB2BsdKbExZydnze9U1cZ PbkbcyY5HWmnYNxAz9KHfPysAT7U3lMAjg+lMLXHxgmMPyAexpUPPTBFN4yBk4HvUsjBlA24 KjrSaKVmxsgVXJU5NMyzkfypsmeCAcE9aeG2r0OfahLQTn0BkVUbcMmnQEghs4APSkOcZbJz SuQrYx8tBJOwV8u3Hpio/l4YEj2xSN0HGB2FMCAvuYn86NRX0AspUnnHv1p5OAhVsntxSEjn AyKGZjHu8vAHFMvVocW3H5jnNOKrtHXNRnO0EdO1SRHzeMAEdc0ENWJUfzD3UUjsQMAGkkzH hfvY9utG92IUAZA7Cobs7Daa1RGCwxmNgM9aUZ3HPTtTi0zQgs+MGhfmx836U7lLa4AkqcHI HvTcxeWGVxk9Qaw/EclwgIgbYueo71TaO7FmsyPliM/WsnVUdCTpFaUtjI29yaGnSMHLgGq+ lh5YAZDisTxGjJqEamVhGx4x3qnNIlyszo1bKFsHB71W+0wmTHmADvT9MJNntlGRjArmZ4bj +2PJUfu3P5VMqjRV7nTNPEThGDUASEFgAR2rn3hn0/Wfs8kmF7r710AcrBgH86qE09x8z2HB 2K/N1pT8yDDfP6is+21SA3T2pXLCrzKmAY49pPWqTXQUVd7irGQCc9OST3oJ3DAXnrmosFSQ SR9aerd+w71SE42YwqzOTkECpOfLKimoEZS6EYPtRG4yQNpwKGxtWI1ye9OIZuAowBSR5DfN jOc0+R0YEKGBz1pXE04sYxJUYPNMCY6E7u+aElMcxGBn370pcBuRSbK520OwwB6nFNnlEUKs SMntTxkkBTjccZrC1ySVdRjiTDJ/E1TOVo3E+xJc600boH5VjgHFalrNHKuenqaq/ZLKax2D DPtyc9qxbKeeOGZeSFPb0rP2jvqK/Q07u+ZbgonOO9PtdSe4cxSZLLwM1U0Z4JZRPdDbntVf ViLW+jkTO0t1HpQpu4kzenfyo3d8qRVCz1GOWcx+npTrtZLm08xWJ3DkGsTQV+z6lJn59x/K rlUsxLU6vfEYmYsVHXFY0l+zSs0QYqvSrWtusFszE/MB0WqmhTQGNftCYDr+VE52dgSs9Sxa ai0syrKGz6VozjLbsbQegzXO3TNHqKiLlSeT7Vszs7w/IDyMfSiFRu9yk7O49yudocE47VCL VppPmfkcjNUNMjnjumMpLKTwa1XLoN69+laXugt1MW4vZPtrQhySOMVpWZcKN2fXmsRQP7Zd t3Pfit8H5QR078VlTldjsPJLOSWAXFVJrlInwvzZ9KL6dI4NxcA1nWUDzXXnK5MZ5welXJ2Y kbkbxyRpKykkDvShxyD1rNvrlLWPk8MeKpCe7AM4YBR7Uc9twW5vSSMnzd6yr+8kluAsI9mq xpN+l1azOyMSo6kdKx9PlH22WQN8uaiVRPYGy0Z7myuEkMhKt1GOlbAkCRLMw3BgT1rG1ub7 VbEoAGxgFataWxe1CSbmyMfSiMn0IcjPuNSaTUFQNt57V0EMjoFdhuJHUmuavbdYtTRQB1ro 4RmONS+5cdu1KEpOVmaxs1qZ+sXezcyAg1H4evTcwbpARzjjvUmt26tbSOpChe9VvDKBbPBI bIyDTc3z2Eki9qTS4+Xge1UJ7OaGyM/mONx4PetiVsx4wKytSv5Hh8mRSI16YFKb7ibWxJo9 272pLozBR3qrCZbu6kBBwOgFTaPGUgdQ+5SuarWUslpeG5jB3AnCnoaly91ClohiS/ZNSWN3 OGPNaWplJP8AUKQmOOeazZZEu7rzHXEhOc4rXhWNUHmDKj0pxbtYFsZd3BIlkXXIqTRppJrP bIQCKZe3Jnufs8edgq9aRx28JwueOeKabWiEZQkaPVdm8AGuhhPycEEDvXMX4SbUQY1+YVoa fcMlyLaVl+YZApQlZ6jual6XERkVc+1QWN/5wCOoDKMHmrKlN2yXJXvWPq0K2pNxCp5I4H1r Sba1WxUZK+ptkmQAIMEfrVe9t0mtnBkIf0FJY3BljVhwcZqeRVKlidvFVvEJO7MTTHaK+MPm buO9b6s4Y8ggisCwZf7QdeCwOa3UcmPkDJrOmrIXkP5IyRnHagbf4lyKaCDxyT7Upx9PUVo0 WrJBkDntmkLxbTgEk+tORQTkg8cAU0lVyrIOaSTIQibkQnPNNgZGc+/alkKmMIT0596SPBXJ wPoKdmVowkxvJT5ee1IsZYbl69+etI2H+72PSkVdzllYjHamrhsALJncMA/pWX4iZVtQYZSr Y5Y1qONx55P0rI8UiMWwQA/N14qJ35SWytol8VtHSRsyFep70ujMzXjeY2FJrP8AszxWquAd oHWrXhtvPdi+RgHArmjJk3Ny+kihlUmfK9AKPNiLfI2TWPcSR3VyYW6qaZqSz2Lp5bbtxH5V 0KdkPVm4Zdnzs2KxbqYnU1cudn1q+N1xbAsmeO1YU8cbakIXdw3XFEp2sw1OmjmJGVYlD0p+ 5uhJyajsYUijAzuFStjIx3pxlcpaocsjldoPynrQxSMcYwKYpABHYdqbJG0kfyjkirfkJPoz H1W+Z9TQRNtQDnNadvICA45z1FYV7b5usscFTwK3LCJRCCG596xg25AtCw0oCknimJcRSIFG AR39ar6g6qnIxmscyGOZCCcHiqlKzC9zpEKlcdyetVdTZWTyg/bqaktyGQMOlZ+u5WAlRlqq T90Hct6bGsdvtB4zVsy7FKYAJrM0ORmsyZR24qPV5JBFujbaexpppK4rGoZlQ5JHHvUokVoy 3Bz+lc4lxJNZ7scjrWhpNwLmFo0PzAc1Eal2ORFrV0EZUjlILHtV/TnHkrl95xWNrVvKkgbc MA9DWlpUT+SrMRzUcz5xIus4V8n7pqMzR4OGyaqaxOsBChwQRxWesziLKD5q0dVIEb0LrKMY JYUXCR+SS0qqcdKqaLOrbvOQjjg1Vu5/tFw8Sgkih1FYq9kVbRxJqJjLZYdDW8oeP5SMiuf0 6FFvyx+90ro2xsHzZNFN3QEa8nmpFA3YGaREYKX4OelJzn3rQTbJG4PzDNKXIiyB82ai+bGA cGpFJ2lDj60DbHt9wHHJ601TgD3pAwI254HSnRgBTkUkxrUljHyFgcNSNkAH+KowJABhhgnp TwdxO7qKGTYUytg9yeM1GmVI5560gPzZ7dqc2CoGcepppWG/d0JN6MxHfuaing83vjBp4CIQ V6D9aHYs3YZ5FGwAoKrl246fWkkZd4VD26UhAxtYlqaEy2QB8tAkBU554pQuCVyM9velZsg5 70xQAPX0oZXMicjy4wduSaC5KjNQxsxUB2JYHNK28NyRg9hQkK19iZSpO4Hp60bWLF9+c9BU JIJ2rnnrUrMqOIxkUMlk1v8AMG8w7SKcoBJ+YGq4LYPzZpwUA7xkdqB2sTOFJ25zSqhKjqCO vpTFKkfMM4pBI+7A6d6SuIkfBUYY5PaopAVGBgmlI2nI70bc/MTTTAdnAVCfcUMMN6mo3BI3 5Bx0pUXHO7n0oBhHGQX8yTIzwakb+EKe3NMPzgq2BikQkD0NJsfQmHygkEYpqnc3XimZY/Q9 KXaU6etMLEsipwQcqaaQqt8nTHekjRg2GPLdKV1ZchVzRoitGhyNIgz2NM2O/O4jmo4xJ5m0 AFT+lKTIznpheKCOUmMeR1HFRiJdzMDgHoBTGk3Lg8GmqwHQ/Sk2ynoP8vywRuDEnNIqZcls 47UgbPSnR+Zk85GaZLHojglgwAFKzMqFwu4n0oJQfMwLKeCB2oT5Js5JTHSiw76EqjeqSM+G I5HpTyQWz1PrUTEH7p4zQ7MkQ245NDQXsh2N2VGBS8hQjgcdDTcnAwMAdfekwM85FAMWJMsc cZPrT8lTg8YpoK7c56npSyD5fm4FDJbEL/NmnKckA8elIEOMn8BS+UCcRnPqPSgpMeh3A7zy KWXHB3UxgWXCggjrSYbHTPrTErpirnkg1LvLgBj044qNOCBg+9LI6ocjge9K2oSY5fkBUMSK MDODmolkBbJ4zUgJI6cUbBF3CJQoYdSTx7VJvKxlTgHPNQDO7I6j2p6tuXkbiTUtDbAsgjBy QT2p+9/LAHT3pkiBWGcZpWztwOfaqSADknrUilSgwORUaK3AHOO1HmYY7RzRYLseHw+COB1o eRCehC+vc01Q2CMHnk0EfLk4xTJTH7vn2KcqeakbaEBUneajj6AilPDYJFTK5SuwUxhxvzk+ lNkd3l2Ljb2zT9q+WTn5geBik8suAV4I5p30GnYXblSpHShiVwC31pZI8R7lfB7ikUL8qseT 60XBdx5ZiAoGFxTGP6UOCrFR1HSlTGDxn0pmd7scPlUAnrTZAFO5MnPUGmKrAkkkilC7jnJG KC4vUfl+NuD9aczKp69OtNRgVyO1NDHzN7KAf50hak6Fdh4BqLzDyCCBSyMWG/j6ChUxgsOS OlBXM9hd3ueOgoWVV6qee9IEA7j0pWGeDTuDXcsHbt5PzUxW2ZYdakYggLjHPBxUTg5561G5 rO0dBgYudpP4VIzhBhgCRTVCqSe56Uqsu7gZJ65qrGWpieJ9xijGCg3A/rUemXMc7GB1bAHG Kl8USSExoGBwRx2FPsdtrGsjxAFhwcda4+VOoI0IkCKFU4WsPxLKv9o2qOPlyK3raXKeZtyO 9c7rjpNqsUbAt82R7VrVjaNxtXOgBDxKkYIXArmb+WQaqFjyQO49a6eBz9lUvgEDrXO/vG13 K4KdWz/Ss568oknclggnvbozTj5l5ya2jhodhQE4605vL80MgIBFRztjlelawp2d2JspRabE tyZwoD561cJcOVzkD3rMs9Sea+eB0Ybe+K1HVWG7kY7ZqoI2vGw1t38YOacq5U479aa5d2Bx n1pRhQdprToJ6rQRQsQ2heKEEYfcRge1PyhiywINRMI2H7stj3pIPMlZgG3qAMU1s71GBk8i m+gI4oJC888dMmhKxDd2EhALFkBfpTV2iPLA5/lTMlzv55pWdBtJYjPBFCQndDlG4jqBXO60 QuqLEp4+tdOpCc4LL71h63bD7Ql2inbnoKyrfCJ73ICs0YLKG2gcmqMbF4pZUcgDrzWs+qRP byQw8My7WXFQ6fZLJZyK425HA9TWDV2NFOzjkntwY+cHrUerCctCjS7drdPWrekXrabLJDKi nJOARRMk15ebigK5yMCmrhZGvESdLAyMhe1YekIi6syeZnJ59q27i6tbTTtgjfzsYPpXPaRd xw37TTKAC3HvVTjZAmaniBAlmzs+0E4zVK0tWksIRG+5x1Nad8rX0I+UEdVWq2m6lLpckiG1 DMylQxGccUpr3kwbRRuQ6XibpdgBxt9a6K2dUi3ZzkVhWkMl1c+bMgBBOK3LlVFrsQHeKql1 HeyEjlhbONpPp6U9gWQCPBYDNZGlWMsVzJLK7HeOnpWsdiw7kJbjBFbR2FLU5yAOdWdnChc9 uua3iQAe2elczLLJDqxdY2IJ5HaukimE4B2jJHPtUU7Iu90ZWqWzyEOwOxeSKt6TcxtZ+XGR tzyBVu4VGTaQc1hBZbLUFEKZif72KUk0yEHiEFo1jU43OCPzrTsCPsCwNGpAA5qrq8TSbXRc 4wcGof7SeC0Efktlvak3+8dwTNQrAiMsY2gjBx3rEs0D3ssRACjoBWto7sQDMpYHsapX9rJb Xr3FsCzMeRTcdb9CLpjdUh+xWJcI3cgVc8O7mtUMo2l/0qiGuL9z54cjpj0rTT9zabACKUd7 lW0MvWMJrflFwzbuo71to23aqLt+XmucuFuJbsSLHlR0PetnTWLv+9JXA704/HcEg1UoLFw5 G09apaDJCIF2DKgYpdaefYVSMyL6Cqmkeei/NCUXPQUpJ+0uCT3N55F6HoahvreNdOnle3Zh jCt6VDqIkdPMgQhgvA96pia8mtCkqMM9VFVOSkiXHUboUi/2TK5JDY4FM0OOS4u9khX52wCx q3plofIaNRsBHOaqC1kt5HCMWbPBrJRfKrlt6BrUTWmrpDG4+U/NjvVrUbx1skgjXa5Oc+oq tawSvdebcHcafq9tLdFSjlSPSmm0tCGLYxKP3r4U+9Xo33ElMEHg1kKlwLfy2J3AYzV/Rd9q uJB5mRzmtIMduxlyhm1n92oByMfnUmowyw6rE7IRJjkH8Kbc2khu2njJBJz1qxFbSzTiWVmZ 8YGazkncDYtuYSzlScVmXcwml8gA/hVmaOT7OUQkN0o022UEeZndjk1rO7XKVYlsI0gXjJPv VqWRCr+aMYXio3KA7FJA96r6hHOygq2R6irUbRsD1MjSUEWrTOTkN0B/GuhlDYXAGB6ViaTZ lLh5Jyxycj2rcC4AwSRUUyrCodoJUDkU0EBSermnowB+Zenalwud5GAau+uoWGjzUOGOGPek wd/LfU0s7EYIORSfIqhs8nrVXJYx0LEMR17ilUHOO3vUk0gMY29u9MLAoOenWlzDaAjy33Lj PQ1GuE3EZpzqCcLkZ60H5W2kcUwceokTbvmUZFY/iQsY1bdg7sVtRyLG5IXII6elUNct3uow o4wcjioknykkVt9nOlPFOpMgGQwrO8PQyfaWUMBljgn61sxR7YdrIOmKgtLN4ZiT3JIrn2ig MyHd/acisoX58bs8H3q14iiIZY1kV2AHKmn39qTOHjB44xUP2GU3QdiduPyoTfLYexo6ftjt EOWLdx2rHmO7WWlmRdp9K24wI12jkVQ1W0kOyWM9TzitJR0TEtS1FPESVQnHbmpZEJjyhx7m qunQtCd/XjvWgdskXy7gO4rSDLiiNQu1Tn5u9CFnmCBtq55OaF5JAHAoQgHGOaoLKxg6mqrq exm4BzmtlJrdmhhgGc8E+9VNSs0lbzACSKisIPLfJ3LmsFdSJtYZrv7vU0tnbK5wKZrFqlrc RQhg4KhiynjJAOP1qzf2ZlnSXdlgc5NRz228AHk0STbElqXbRGNspR+O4qtrSn7OSV7VYsT5 Me3tUOpRSTKQMsprSXwlMj8PfNabec+hqPXURYyCxPHrU2lWz2n3mbkdPSnahGJ4yiZ3Z5Jq U242CxjqzDTGKjDAfLz1qz4TeXYTIAGbOSKkltmbT2DEKU/h9aNET7MCeSD2NRFDcWkSeJcO YvI42n5ie9WdMmVI1DHr1NNvoVuVJU7c9qisLOSNRvkJAPAqmrO5A3xF5TTxglSo5FWLO3th Z+aZB5hP3al1eyiuIk3KPMA7dKzzbygKi5xU2e7RXKraGlGYo4Xx3HFZmk+bLfujbVOcA1ow WjiHJJNVHsZBdCdJGU+lOS02JtcitkEeqnDLycEmtx0zKyKykD+IVlLpzC584EknrWpGD5aq FAx39aulogsh6J8p6YFOEY27t3JNRscY5IANSgKy/exn1rUpMRolJ+ZvmprIuSw4xxijoh3k 57UAfut2c0FK1rsQBAyjJOefpTsgEr19KiEgYZGRjrxT4ioJJ5zRoRsAIC8dc09P3oOchvSm gheoDZpRn+DOT2FDC4hXHHTHanhEQffyzdu1NWJi+CfmpjABtpPzDpQimiTYWfaOSKIhgEFs N2oQgHcPve1EZ3EgDJ96NwirasFxtwcbvWjcAOn196Y4IYHqP5UvVuDweMUipJPYeSpHHFIQ uBjFKcIMHkCosEncciqMkiUlVAUc5oiAZiMHHrUZKqcjOaUFtpIPBNKxpy6EhVFTOeT1FNba cHkn1oQF8kkCmt8x4bG3pU2YadSb5BCAAd561JAcp5VQKzlcjG49zQS6cj05xVCtoWNrZ2rt 4pAAgK5BJ6mmo3ygls560vy9ulCFawp2qOCffNRhowxbcTntmpnXEWQQc1FEwIOcZzxQgQrs oXO0kdhSJGykE5JNIx3EnvT97YyT0qbNIpyVhjEqTmnhVVRJIRjHTNNY8bjzUTuhAJzmjdgr EqSbpARnbUzMcgr071X3AYVeKkkdYx13E+lPyJa97QeX3MCeCKkBY52k9KhQhm3g7fWnK4Jz 2otYSFT5FbLGoEmODgdTUkjEbthxVVCfNwSKH5GiVyR3AbbzgioiTt54FBlGXUngUkZDA5PH YU0yZImgOR/KrY3KoAH1qsAWiG04+lWIwWT7xGKGQiSONcE80jZPXHtTg23BzmhQdpJkHPak rlNdhifK3TrTyRgk8tS7sJgHA75p4XauQPvU2HUhYqVBLE1KykorAjPpTAmCcAE9TTwGbau3 G6i4mrDSAQMD5s0rksozzinlJIWO0gj1pCcKHzyaVwSGI0hHJOR0p8Tn5iQQf602RucpwKXz MR4IGTRvqD0Y4Plc/wAXrQAwB5JHWkVlABPPrSgliduOadx2Y0ZGSCcGkkYsBuXIHankMoIB 4NIM9AKBDQd5wBjFPwxIQnbinhFMe4Hrx9Ka/wArbcgn1p7jWg3PTByc9ac6+WnB5701lZe2 DSpgnk80MliKjH58c471IrucAqOO9DMxwqnvTzhWGDk0mO/cYXKt3yaUgAbsdaRsmT5seuaV skYzkD0oQIR94UFSRS47Hr3pCxdQpPA6UoKhgTmi5NrChSq8dPakVRtGDgnualDJuOScUmEZ ctz6UilISNCRmVv9004MVxhsetDBSOc7gOPSolcsSoXJFNaA9RZGJkIA4pQrYDn5uetKhymG HIpRxwM4pNXHd2sJISrFjlgf0pVDMMBtppysVUjAOelMYknOcGh3JaEw6cM2ee1PRHbJyMD9 aXOVAIpGd2fOdoHQCn6lJXGkEHHQU5Q7fK3QdDmnhWkUkj8aamUBGeOxNK5Ss0I4dQNo6U51 Mkf3iGpVl2rjGc0iyKZADRuKLSECA4xkcVKYygDFWIP1qFi32gtuBHYVNuOPmyKasEiaWQbB gZz7dKhEqFtg5f09KnYbsnp6c1CgVGbaBlupxU3sU49WOTyyTuPzCgIR+8UcUELjI60Hdt4z inqUmmrIwdctrm4kBiO0Zyar3Mepy28MW87Yz3FdC6DHJ5xxSxF9hVVByOhFYOm+a5m4cpDZ qwgVW4AHPFYl/ZXMl8J4D0PcVus53BSoB7471IRvXCjGB1FVNSasTZlNFk+yBWJL96w202+T VBctOdvXb2rpOAxBBIxTQoYZIyKTptpeRatESLe8YJI3U44QnIBb0phcL90bR2FDKNwkLZJH I9K0SsJK+5CloBIZAnzN7VMpywVx04qVnGF2ngdKhYl2LZpxVg8iSJFMjAfLx1qPlTg4OD1o Cs3yhgueMnpSZVQwYktnt0NWF2hyOrKVxn8KMIi88elLGCEwcA9eajMqMdpXBHWpswV7Dmyy 7qYzHjcuR2NJvAyNvWnrsMOP4qTuJJEXHOemOKQLldruAacsbkEgZxSFVZcMOQc00x21AgrH jzDg8A0kiJ5PlklietSFYiATn2FRMwDEEA4qZLm0DSxTj0yMFpVAB7+9WdgjCrkc1LuU4xkZ 60rBdhBHzDnNTGnGIculyjdWcU0mSATU1tD5B+Xj3p4Qu+4LipN4CcHkHpVezje4ldlaaJJC cgH61E1jayfM8a7l+7gVZJ5yBQW3HsKTpqT1EtGLDHsBVDuJHPHSoxDGzcrlu+aljZQ42n6+ 9OJHLZX2FOUFYLJvUhVFiYqMEHpTmba/zcnNEpLMPujHpQzLj5gC3aiKURtqwrkcMRgGomYR OFUfeqbG6IMGDD09KjVNx+UgMe5qxWIZYI/Ny6AY9BToxGvyoMY70NIqkqzZbpmnKURMY+f1 qVBIewpUN9e9Quih9mBx3xSsRtBzz7U1WLHjoO9U0mgjbqLIQvG3cDwKQQx7CWAwPanNKRJt +UKaXzYS4iLryeeay5E9RX6AAAoMZ59hT32gcYJI5phGxtgPPbFNUHHOM1a1VgtYI49vzKMe tOUAhj3HqKcGKYA4HpTZHHpkmiyQR1dhkcKOGLKM9sVIBGi/MByeKASEBwM0m9NuGAPHFHIk 7jasKkaFvmAxVcR7ZCOmDxUyvuPQikyGbb396GlcqNrDNzADAyc0kaFnfnbmp42CNgjjpUcz Acds0NJkqxEARlVzgUhCYyFp27Kk55pFbCbQKrlVhCRogJzyD3pCigYUdO+KM4BPcdqSEMyb yAB6Gp5UVFLqNZU3DjLDrxSk7WPygZHNPYgkFQM96LgqGyvzHvQkkEoxWxCkaufm4FLtIYgd ulOYBuQeCOnpTfuHqaqyJSHoXVyzMTxyMU8AFN2cZ6YqIP19e9SRn5eRStqU7bIIgG5P8utP JeP5QpZW68dKSJ8ZBWlSUmbhsKB0pslpoAIU+V1PFOZgCCucY4FJKg3Ft3ao45PlJIpJWAkf JUFDz3pIXZh83Y01CQwAGVPWnyEqpCADNDRXNoP5OdpGKa6xtjIzTNzbBx070sRDHBNKxK1G EAcAcU+DG4gkAetNYocrjkd6RiwAxgikadLD8KWILZNNbdkAk+1RksXzgAGnFjkIx+lUjOzQ 75d23PNNlkJG1uSO9MKHPGcg0/YwUE4qgQsYLrjNIVPJIP1pPmLUp3bCc8elSl3G0RIxMuCn A709ioB3DGeOaQhk5Ixmmt8wAb8AaVkNx0Huv7sHj0AoZdqBWII60J90lhxio34ZfQ1WhK0F wANo4X1pUchWQCpI41eQ7mIAHFJtUAkk0aDT0GJt8kgkh801Adhc8GlKl++MUpJfAzjaKXUa dyPf8hJHWlVcr0FHDkgEZFKCACGbFNitrqIUBHJpsKru+YY9akJAADHHpSBVDUk0O/YaVUH5 cdelLn5eOppGIJIRee9IQFAyRT0Je4HPOeaY3zYBAH0p74zx6U0ryCRxSa7FX0IbqEMwA6d6 RdijZip5ChkOPlWq7MpbKnOKlpFXZOzRRxqT94mpUKls4GKrttkVdy9OlWIzCgAOWPpVJGb3 HNgkkdKTaMZ70YHQdKVgC4IPAp2LUdB+cKNp5pNo5zyRSbwo5xQG4zjrS5e5PKwfZxtpUIxt PbvS7Aw3NTWXinYVrDZJVXb1bPQYqUhl5PU80xAMjI4FSebGRjcd1FilotBjMchj8xPBHpTn CjAH40Bl2MABnuajAOc5wMdKES7khKmJiMDjAFRxgqi5/OpMLgZ5pQzIpVlBU9j2oCzYFgEA wDmkVSZNwYqQMUDaCGB/CkkwfWi4W1HAqqnkls00tjqBzSxoXGVFJkb8YwRSv0NHy2JIflLk 4yOlM53buhNPOCCc4/rSSFXRSOtNEpgTk9qRxjBGOaWIoQwOcgdqRNrx5bg9qVhqVw2YXGet OQqFMZBPpSAZGOM9qjXepJP4U73BKzJHj243d+9N2ktgEY6inNI8oUOASBimsu3HOKEF+wbh 8oYcd6ZJtUnZ0NPYbBhjwfWmMp2bVwAKYkrkjgjbluMdqQHB+91pp+VFycmk+UDLc+lIlslG Gcqpx6VIF2Ltbk96hMmQNoAPepN6hd4b5qZUugcqnynj3p4VdowQRUMjEgM2Bk0nIbGQfpSs JomRcAjOaYxPTGKVeCdjfnTBIzOScDtSuyo0+YUMQMDkfypkxU84wKWUKGyrHGOTUW4YxnIo QneIB/4wc47U+MhiCTgUzbtA4wDTVbZIMimNKyuWU+XPOQTxTt/OeBTO+Q2F9DSyoj7Cc+po BRs9R8rq/PQ/zqpJJn5R69assEIPPbpVHb8x9KL3J22JG2hdpxmmhdrEg8VI6AABsNnoamTy ioQ4yOtCY7aD7fIGCatQkj2qEBCBtwRU7IFVT5mfagl+Q9QGyM4qKOM/NvYk54p6xq8bHccj tRGAqjqBQVJWQ4Aj5TgnFPj5UjPBNR/KWyDmlK5Xnp6UzNXJUADhM/jTcnBHcHrSKu5gcdKd GQoIJINLyHqISqbcknPUU103jHOKR+C2Ru9Panphl6nmhJDGEKq4HWlAyODg04oN3Ximsozj JFMN2SRKFznp6GnLERHvyPm96ib5+PSpI12AgtuJHagcrjgvBBPIpu4oM5AzTGBU5zwaAg2Z J+X37UWEhR83IYg+nrSEPJkjg9KFjYt8pA46mpN235ep71Oty2o20AxHIzIScUrgJGV7/SmN kYJYZz2pdjFS+6qMtmCRlioDFcc0uzZJwc0wEgjB571KuSOooBq4OQCP605yNoAGBTJAAoJ5 9qa7lyD0UdqCk7EqJhAWGR2xSxqXU4BOP0pFwUGHwR0BojkYZYHA7gUidWxChKfeKn2pYtpc kk8ClJGAz9D70gkBBCYOaSWgx7pkYRixPPShFRQAH+b+LFMUui538ntSbVU5z16mgpRsL0Yg c04uEQEng+lMQbicEfjSDaMqw3GqGrXJcgjgUcHPAyabnaucYFEpBRSnGetJg9XYepAPJwPW mlXySuOOme9RPGTKreYdvoKmBZizPn29KL33BEgVmj3IwU9waVI1x94H5cnimIw2lccnvSOG WMKrqT6+1K6BJrQdtyCT0pGCsAOB3zSPh1CbjQiAnaM8CmhvQdGuRuyPapJBJkEPnIqDYARh iD3qUMAOuG70N2Dl6k7nABPODwKR9pORxnqaXZ/FyRUDjceMkZpO1xXvoSKCMnOcd6cD+7Iy Q2aTGF4Hy9qUuVzgLk09yW2ik17bxzlZX3HHakj1C2LgI5BPv0rH1i3EepK0hw0g6CiawUSR yxOd/fFc8qjvoCd3qbdzdWsLhpHPNVTq9p5j4cqo9ah1hEFghkA3r1NUbK0trq0ZWK5YZBol Vkht6m0t1CbfchJyc5qCPUrfzRAuC5PHNR6NYKLSWJz0UkZrF0u1iXW5GkbndwcU/atWQrXO plUlwSOlJMw8oll2qB19ac5jWIKvJHRqxtSuy0wt0LZHXitr6aildMvwzJIMAnNTIMK7s23a KwlE9pOrSEqje1WdXuEjtw6sxVh1rNVVYFqEmqRxFwxyKt2lykyeejqwHaqGmWMdzblwAcLu O6naZppgE5T7hOcelHtJdAaa3E1HVDHLkKWOegpbDUlnkMbjax5waqaY/wBn1ZzcosiMcAMO Km1Cy3aqs9ovyjrj0qHVlfQpGsWZ88YUUIfmABODTcyeXzjOKyvtF5HfCEpuRj2Fa8/ccmmt DZlMqybRwp7560LHwzYoV26OOR2NKskmWQgKtUmrXITY1PmA3joaqalcpDGRgBu3vVtAXZlG MYzmsC8ZpdSCO4KKeamcuXVC1uJJqF1HMhMeYz39K1BMZrcXHb0qK+ksnsTGo+dRxxWPb3LR 2JQksAcio9rbQd2W5b66mlkEYIC9Pep9KvDO5SVdrA96bpFxbqnmyjJIwFqrdIh1DdC5HfAp SqNME9S7ql5NCdlug3E4NURcXVtPvmJMZHeo7V5v7SdpseUAMZ9ea0NVvobjS/KaNBtzhgOa bnfVEq/UuQTRTQBzhMcg5rHv9WIvlijTjOOKtaEEliEb5ZGHB9KzNX05oNX2rIODyKUqjtca 1OghY+X8+FJGc5qhqVy8kyxW7Dd3qzZwytaNIVyFXvWPp8my6kmZfmDU3PRFJE0s95YXC+fn yzWi12otzKrAEjgGq2s3RvbYSM4LDjFZlySLVSRkVKq2dgLax3c8bTYyAe1WNPuhuCzZOOuT S2d+IYEixgMOnrxWaWZb2X6ce1O7TuK/ctXs/mzlbaQhfQ1GjXFtKsjP8rcEVDYSxruLAZzy al1SUTwgqfu9MVPPcCxezTSQgRYOT1Haq9xBJHa+bITuxyRV/R1T+yw7Ebsd6p3kr3EhhQEA Dmne8biiTabMZkVnLcVfw33gCeetQWFuI1C4wO5qxJ8mVVjtJ4b1q6d7aly2G8lvvAD3pUXe x3HAHemkHbweaRA7LtJw3rWoX0HnceD90DjFACBRnJPf2prsyN1zxQgLKWNAr33JywUAZGPU 0xQACzcn1oIAX5hkEUgwU+XgUkgBvu9c1GkTeZuPzDHQ05cq3H40jld20bgeue1NgNkUI+Rj 6Ub1YlgOaSQEEYyc03kc7eT1AFJai3EmYZz1z3oWRduCCTQ+zIVePY0SIoGD27imUhgfB4ps ZJkyDg55p5wyZUBajYbfqRninoSObAYlnxzTwc5wOneolVXGTTssFIU49qBpXEUN1PJqZVYB SeAelR8bOnzVHhzJu3nHTBpMZbO5nJjHGOaQH5iOB703bJ5gZDwF5HrQvz9eM0BfqLuycZpd wwUZciowpT5Sc89aXY4Y4Oc+1PYPiZM8gQBEUY9ajEhwQVz6GlG4R7sZxxTGBbay8eopaMLW JAu5OpyaXYiDA+Ujk5pgwrjcTj1pJ2DHJ5PTI70mXCN9xd0eM5NMWeMsV2596YVIwCKfbKkT l2jyO9NIh3b0FBIOW5HpSbhxnt0okILlgMDNLv8Ak+6DTFfoxHkyAy596kkBCKyZIPXNNRTt 3AAe1D7gmAcA80mNqwzeVJxSI25iuSTQDleBwO9PwoyE4ovcE7bgcsRk5I6U18mTLjn2pylP 7p44pCCwAHHNA1Kz1FzmMp1BprxsuASNval8zDbdo4ppyewzRsJ7jkf5doPFMeTaQMbuacUy fkGMDnPem9FwRzRYNlqIG+Y7c5NLuG7AXr1PpSISr7hjNI5cvxxnrTFbsPPlxLtAyx70i4D/ ADAEe9IyZz2IpAGzljmgVwAPzbsEZ49qV3DEL93jr60O/wA3yAbcc0OMqEBBPap0LtYGzG2B jBHWmkbjjqKNrbcMQcUEE9OKdhK17jZH+bbtycdqROuDzn1p8KhXz1J6k1FKCHzjODSB6sim DKTuPGcVVZmjkI7djV2R2QZOCp7GqZdXkEbDA96UkXzEkLMwODnFWreRdh3D5qrQkJIcAEdO lWVCYwRyaZFh8ZbJ6EVLHk5I7UzMaYCg+5oZgT8uQKG7CuxzjeMt1pyjGMn6ULwopo2t3OKY 3zEjNtHNIrISN2SCKQjchOc+lIuSAMAUylC6uK/y5K5NMYNwwABJ6GpuAflO7FNc5/3utAk7 AuAuR1z0pecktg56UR4wCQKVtuc8jHagSuxoUiUOGwB2pXd3J43Gm/efIPFLnDHb0HepY4u2 hEd24EcDuKkydwxjFLIy9hz3ojG4Fm49KaE7scHK52nioy/zAhSWpyrk8d6UgLx1Io0BqwRM S53LxS/dHykHJ7dqaSCcDNO+VU2gfWhhFNgiqjGQso+tIx3fw4zTSkW0F/XOKezKzZUHaOlF rg00IVJwxfGO3rUifMMMPxpu4MwD4FLI8eNhPOeBQLUR8bsISMUZPBI+fv6UOUL/ALsYHenF 0VCDyexouVyvoJIfmDN8xPQelDYalUKTxTyE25xzSQeRFOQQMYGBjNR7GdQBipdueQOPekYb ePbtVIVtCFlONuSD3NNQnOACQKsBdwByM+lNSIPIVDhfXmgVwZkdFbPTsaVG2vkYwetRiPBI OOKTd/CRyO9K40myZ+5UcGomBVl3A4oEgxwaa7Mx9RS6lu8Q+Yg4xjtUe35sA4z3pGJV8nOK dkEDjJFAIELbypYttpxJMgZQDg85pUQKeOp65qXYgyAOfWqRDbTGqSZvnGc88VNIrHmMAfWn KobHGOOtOjJMgRvu+tJhdsgXptYHPbFRbCHIPWrU25ZyiEbD0pCj4B4xnkmhFNNkaDHUA1JG gDjgZNPQAtuKj6U4j95kDB9qSM2+gF2DsoUD6d6dGMnkc+lBQ5yBzSvkNkL161QD24JwePWk SQupGCPrSAMzADp6U84HXih6FX7gibfmHFOZucA5NAUkgMMUDajFSM5qSUrO7GFnBG3vUnJ5 wMgUmM9Kfj5Bjg09Bt3GKXA+bGT0owWHXHPWhWLHaRg+pp24AGMgHHegaHKw256jOCaUqCc9 vWo8YUBSCD6U5cFSnQ0yUmKpUN7UjL5UhaI/IfWmeW56dBUi7NvzE+mKCmxyqZAWyCB2pjg+ XjHA6CnQKVyFOAP1oJIbp1oJYiFjg8g0rHLZqRCPKMe0ZPJNRjBPPA6UXDUcm3JLc04qxiPO BTE/uhcgd6cW3EdfpSY7JojA2jABNPU4zv4GOPWlRkJJyd4ocpnPVvSjoSGFyrdSKH+bGBTV IANS4ZYQxXBPek9BpCMNqgcFjTSuw4J6+tLxsXjJB60SLFJkksCo6Ux2uAjMQBzuBPINSKhk lJjXAAqMZ2hucdKcjFXKqTtPU0MaSQFOcEimxE8hgDT8HzGLcg9PanrjGGA/AUbkuTehDyrH AwfWnEJng5J7ilkAc4JxnvUSxlOFPH0poGtSZiTwOPWlQAGoypBz2+lOG7aB3pFJWY6NBvYj PPSnsJFUIT1qHdsYFuvpTlGW3sfpSaHqmL8v8Wce1A671x9TQOc8HinPwOD9KdguxBljk9fa nn92flzUa7lwTkGpCQ2MD609iHJkYJIyxHXilDFTgxFqc5zhcDipUQyjjKgfnSdi03yj/MwP 3pCqfSouFkbaOByM96llweKgPmDID5X+VJjlBW0JGlZlx0FMU7Ru64p6D5cYpCNy7QAO5p3s U1HlOZ8QfaZLtXjIxnoa0NHyy/OOT61U1Nh/aUYE23b/AA+tX55re3Kqj5cjPFcfL77uZeg7 XVzZYOC2entWLpMUyyRFMCPvWrrUw/s0EMQxHORTdAZDYorAMcdfelNe+kEN9S9cKUhdgccc 471gaQ6HVG/dMxB5z3rfnyYXLNxisDSpCb+QvKoUH5SPpWkopNXBT946HZ5jPhSFxkL6Vydz PLFrbLGCxHUHmtuLUG81ljc7uhxWbA2/XAoUGQ9fzpVqm1hsh1nUJ55rf7SuDnHAwO9TaqoX ToCcEFhxn6VN4mWFZ0jC4fvmjU7TzNLgkic/LjIrFq6sg3egkU7w2h2jginaHfNexSbcgqcN SWc0c2nNHI211HHHWo/DxaC2nQLtZ/atPactkEr9S3q1klzZKYjiQnBweao6VNcWM/2aSRmO MZI7Uun3pjuZIrh9ydiOoqOQebf+YjkoDzTk7K6EjfRgUB2Zpg2lzJwMGh5iMMvAI4X8Ky4k nOoszOwXH3exrWT2Hymu+XG7J46k9aN+1gGG4U3njHA96V2ZAwXGO/FaJpoEh0YHmfM21SOa 5i8QnWXjjJ2nOMV0SM7DAORisjV7WeOSK5iYYLfMKzrLRDasxLmzktoW80fMRke1Z0TMLUhw CccmrmoX32lktVR9+MM5qwljttNoXk96xqRfQm2pBYWUl3AJYhgJVeZWS+DscEDBqxDdzWW6 3w2T3FOt4fPmEpLA+9Tq9B2uylagyXrxbjz1zV2+06Syt2L4MbjIycik1GBoJPPjXLE8/nVe a5uL9RERIVHHNNX2DQ0PDAYDyscn7uO1UfEAkj1JEKv5xcZPfrzWpaI1oFkiyHTpWTrF1fTX n2kJ5j7stkVTbUCDdaNhYsysQNvNYFmjS3jx7QFLY+ta1neGa18mWNkHXI71RuYJrW5WeAkA nIzRJNpWHyiavAunJslUg56VSuUaSCLccJnirtw9xqEzNdKXGQc1YltFa0xGCSBwPSk1d6DU Xa41LVJ4VKgAoOCay0WQ3Uu5TkDg+tTR3F7CghkibHQEVpaZBIFZiu7cMZPanq3YVjL0qJZJ ZFdBgnvUmrRrbxBYRn2qW4gltpw8QJBPNJFFc3ErNOBgfdHeo2dh9BgumSyWLaA5HTNT2NtK Lb7RIpA9ap6raSlkdVORT3kvfsoiQn6HtWsHbRiSNaKfIOOalQ71KYx6CszTo5UULISz+1aJ VhggkN3rdS5kUwX6c96A2QSOg/Wo1bc3cY7+tPcsRgAADrTsLrcQEOCw4WlG3OO3agABOCMe nrTInw5Vx24ouVox6qMEMSR2pyjAwcYpd4CCmuys6E5298UIUnYVyNmDmjzP+WeBt65xzmkB BY84FROdzbV9e1CYkh6Ng7RTIWWOUl2zkUu1Q245xUbYaQ8cU2W0rWEcKZNxHQ8mnqQHKgcd RmiUIemaZ1UgZxRchoRyHc8FR7VGVQSEsWyB0zUqqduM8etKxK/u2QHP8VG442IOeoBApVba 3IzT2DAcDJpGVSnOcmmF9R8LKdxcdentQ+NhRh1pikIuOcikL7myRkHuaTQ022SltiCNW7da RhhVO761H0G0cDrTsjA4zigm2orsgGUJP1oE25j82DimbeMrwM1Lt8xiQoAApNmieg6Hczbc /wD16JU2SnceMcCoy7dCAMdDRuJ+8SRTSIV2ODukZIwQRTI2JIHbrQjbuAMAdjSH5ZCO3rQV zaWHSEFuaVnUnaSQMdBSeYp+UL070h4cMBihIamkLHgvt5IFOfapZVGM9KaxycqAO5oVt+T6 UbmctdQA+Q5zup5fIGR0FRMx3HtSxyYJDAHPSlYpKy1E8wYIXgHtSI2HyR1pXxuBVODUaBvM JOMdh6U0kEndkxfLnjFAxkHuKhLESdCc+lPAwOtDHa5IRzngmlyAgDD5ieoNR7gFIxwTTZA3 QEY7EVN+4mmtRxbqRmkByMelIrFlwBjHFG7Bp8yE+Zi9MEc0kpUSBt3XtT0KK5ZiTkcVG3zN kgU7iTaJAwIOTUb7yewGaRzhhj86WcrjfyTSG9QKnpRlFfaWAOODSRSMSSQKdI0SgNt7c5pv YFfYYCA27dk04tn2HpSSYIVh07YoBVjyalMFuIrgDBPNMkdVG48UrNl84BqC4fecbcA00ynv oNuTuUENgdapOcyAnOO1Ty7toULnPFOSIbRuGMClZlJKwyCTL4HI9TV+IlQQOc1DCijBC9as qCjdKHoKSsriovJzUkYwBnFMC856VIxDAcdOlIz3BnJYnjgcCmqGfHQL7UbFbLE4IpYXIQop BUnmqRopWVgYYYH0pGyW/rSnqaAeeAPSqIuCM0YKpzn1oIO7BFIc7gD+lSDaW64pDi7biHsT 0FAwzEZ4pshJJUDr3NCdxnpQF+xJlQpXAPNHIALAe1NIU8rnJ60OGChCfpSkJXew1hzkHg0R 4xtB496RGUswzytKxyOnvxT6FR13H8joOe1JIAhyTyetNySwIbGB09ac6eYoEh2jr9amw+W4 1Qcj5hUgGMkDce9DbWjCKuCO9IvBwG5xyKpbCXujkVGGWPNM6N7A9PWgsAowCD3oXDE5ycdK W24rvqDFWGQuM0sexudoLZ6mgRjnccUiKF4FNMSV2SsNsm7avvimxorSlmOB2FKke4tI0mAB wtRFd3y571PUrXoTsUEbdc5pFUlhk4XFNBxuUrk9qXqOSRTsStxdx2lexppBxil7A8ZpQx6H v3oWgnqMIxjH40nyRt8uNx9aVsq5XOVxUbFQ2QB7ZqhoflSWJYZqGV1CgDgnqfWop2HU5yah eRmPGCFHNTYpXQ6QsCMHgU5H5PJqusgb1xTNzKTngdqNhfEaMTRscuxApUVCzbTu+tVoCGAz 26CraNtIITr1oeo1oSRRsY+2RUkUWcbuPrRDkkAA89vSp3+U4U59aWorpIVkERKDDDFNX5V2 t1PNJk8AU9hlucU0TcFVGGPSo2UZxk7c85p7EcbBn6U0sXGAu0+9UO7Y5QpBy2B2ojCqg2tz nFNwGXBBxSmMbF7YPBqQS7kkalHYliQacvfH60xTlsk08YGd2elF7AtAiHzEjvQVEhw5wBTo wAcZyKaVyCe1DWoN3HSYcAhzxwDnmhlLc9aYrqOFzkVJGd6ttb5u4p2uiYy7jQccE4qZcFeT z2qN2TC4JzjnilRsHdjPpU7aGt4sGC5IckehFAwiHPX19aHO6QE4NKFP3QQT71XQHKNrIai9 8Fc0ssR6lsgfrUsspcgMOnHFRqG39SRQRzD15TduxntUTkKwLZp7qXUsDhhQMMgBzupiHxlQ STzmlk7YG0e9RyKVThd1IyOIw5Jz6ZzSGhXbYwUc5pzn5dzjnsBSIAYvmU+ppskhcAdAOlGg /IWJlLYyVY9BT5UKIDvBJpg2ja235qcI1K5O496LiUQI+4QMEdfeiRlDbypUGjcdnc+1InJw cfjTGo3HMVVtpIOeQaGcsCM5HbnpSHcG2thvQU50IJOABSEkmxEYAYbOaVuM5UcjtSc7Aufl PT2p8YBBDZyBTHsMikdATjIzgVKvXJHFIoBG09KHAK7dxxSYJEjFQpOck0kagKXJJPpUe1TH znI6U3BI2njvSSsKKdybbkbiwHsaHdSAQMVG6bkAbNPCDZ8uTQnbcbHrtJBbr7UhY7SAuSTT Y1KpgnJzT432HknmjUSYzIx83FOHIyOaNhG7+tNRlU4ZsA8ZptlOHUV2BIGT8woHAxnI7UrK S5EYBUdDS4Tbk53UDk1bQPnIHO6gNgEgZNPj4U5xTFIGf6UrijFvUVAWbdnp2pWLLIcNxTSS pJQ/nSnEnJGDQy4pLSRYYEkjHTvUWCo5Oealc5JwTtJqF1HmcEkUmxbbkijimzIRznn60hOW xgihNwk9VpOwNXRi6hpP2ifz1GHB4NRxaTJHcpMzhsDmugfaeV7npULrubbnbXP7J3uHIuXQ z9SsJLuMlWIFP022NvH5YHHrV/eUUbQCR196b8xJJQrnnFdHIrpmaQ24jEqiHpuGCayJdHZH JVgFB7Vsrv3bxjA7UNlyTiolBSY1CzuZlnp/kt5q8kjnNLBYRpdmflXPVq0Qo2ZIwfSmHaC3 zHkUKlFoHdlO8tUurjzJOSOhqXywkRiXBVvUVLlVUDaxz39Ka4JOB07Vapq4WZTGlKCGjI3f xVPbwrCxYrntip2zFHtAO7uaYWIAPX1rP2UWxpsptp0LTF2XaG54pIbZInJCg1dcsVACkKet MbCNtxkHvT9nEOVjWxjJAyKepDR52jd60MABlgB60b8DdGucdPStFFNEuT2FkbIUFeR1pEJd tuPrSOsjIJSevanwHByRT5Rq9iKRF28NjB6UjhZE2MoxmnsAXzSbTz8tJx5tB8z2ZD9ngDko uBUwBEYII25pnrjtTgRsHynrSUUhOKRG0MMpLyLk4wMUsCqOCoAH608gKcHgGkkHzfJ0pezi tRXsI8cbodzge1NjgiVdwOG9MU5xGUXKYYnrQzHzAseG45oUFe4mwz3I/Oo2jhYcqOfSpcnb gj5fcUgRFTcCB7GhxT3GmiONEVsqoAHY058SD51yvp6UuGdwAOtKWC5QLhx1pcqQ+a7sMTy4 8qijLetKjhAwUcmkYZb0oCDdznpmqjFId/dGECQgMBkHrUqMy5VDhRTMqvzNwO5pGBK7w3ym jlSJ3HSyJvBKZx7VHKd7b9qqfYUISRk8/WlJJX5AMD1pcibuPYjY+YAMHgd6dswueOaldovI XYMN3OaYDgdM56U3BA2R42neuA1JK5HJPJqRinPqahZTn2qkrE6jw6iJSE+bvUe+QsS3c06M AZ75qKd40Cjfk56U2G5LlU75pPPGR8mRTUZZV3AdegpYnCb43j5xwaLFJ2JGcBjgDFNDYOMd ajJ9etKo3cljQEpXJWcE42gepqJZCrYUde9PZSBzQZECYZMluh9KaQk7DSx575odt44AA9QK IQCrE/w0ZzlQcDOTSsCm27jEYYIJ+lKjgZyOvSmMY3YMhpGyWz7VPUuWqHE4XcWxTSzP1OfS kGD94ZB9aduRBndiqSsRsAk25yMtUbNjj1qAXcQkLFgSD60qXsLSkMqsx9+lLQTZNKjZ3Fhi kAGNwOfamvJGq8+tRJdRZ27sE8AU9ENOxZG0v3xSA/MVzzUc0hQc9PWoo7qFp/LXJPfNArll mGMZpQzYxnHtTHCkhgMCmyTeSA+Rz60rD5mThwcgjIFNR8tx1FUlvkd8Bhuzzg9asRy7zvT7 tC1G31LCvhjkCkOScqM461VmuUjbnv2zS212k0mwfKe/NMI2b1LA5bAwPWnlt4AOMDioneNS fUd6pyajbibYDwOvNAlZSL6nDEN09qaxwCVqISo4BQ5BqO4uY4cb2xUoqTs7koYBgGPWlfcG +UcZqqLuOWX5MVaaTP3uBTYr33HByBS4Xsc00fO/GNtOCnqvI71OpUhQNgBBoCkrv7UBuoB6 +tI+VwoORSdwTsA6fSkBGMj8qFQlc9hShMAZPU02tCW0NBx93ikBIlHAI705h8+0fnSZCkqS Gqkhp6g5BcjbS7MKSW+lIu5eo4obDYC8ClLQHqyNj8p7+4poJ25J4qQEJlRSJjG0CmkNuw4D C7s0znqwBz2p4CkEk9B60zkY75p7k3HnAj68VGw4Uxkc9aMgfWlX5efWptYasAQH5icEdqjZ CW6E09t4b7vDDg0+NthyMU9iuRblYR7iRyCKl2kwkHlh0FShgTjAyaQEoxPGKlXFZXsNQdAV wBUzYU5OSKqTX0aTFRyfSmxXizHKnjPShvUiSsWScfQ9KdG3Xd26e9MldFUluBiqf21FfAIJ 9KrQd7I00UNgsSKjQCPd8vJ/WmRTGXGSB7Ul1cLHgEdKb0EmT5LAEjH0pMbRxVaC7SWTZuxU 5KrBknkdzSuNW6jm2lBz83c0AAcdRVH7fFvK5H51agm3RnZhgelFik9SVm5ye1Jwxz0qC4nS BcuwGfU02K7SQAAj2pXZmWQcDA4FJJI7HcDjHGTTjJhP4Rj1qpcamhIjbbx6VTKjpqWtuAGz yetOJAXjrUUcgdVYHORSS3CxNgY/GknYT7koUN+FBZnYqeVXpUMNzG+MttY9BUyH5tzDijcq 9loCklvk4oZcPuBqKS8iDmMADJp4YdcjFC0FZslCqy+p9KEUEEDg+lMjk2SBgKAxckgYYmhl XVrIJM7yC3IHSlSQLGCpzuODT9xLknBPQn1pNoIO1cfSmKL6scNuOaRRGZNqvgCkTkEFh+NM jVUkDsu4Z5xSsTzE5GO/WmtuGXJG3tT7lYhIGRjjHTNMlbaoVjxRcpK2oRFVG4/NnoKdwQcj BPSok6A9QKezF1AyABTsGggX+An5vWoZVWNsZzUwIQcnIFU5Jo5pDtOSPQ0dRFW8Zt4O7AqA y7iABg/zqxOh3YYZ44NUyrxnO3JzUu5pEkR/nwxxUykFcFNw9fSoFiZyOcZ71eiiAwqk47j1 ppXM3LXQdEhHJq5bjcPUU1S0Y3BR07ipYuVBwFPegFdE/wAqYKEjjmmOGXD9z60MyhMngUh2 vg5z6UuW4k7kwUhA3QGjI9aZFkjBOVFKYyGY54xxTvYEh42RsDGT70zaWJJOBTJJPL2liACa HvIBlyw2jgUXuF7EuMIDnij5WGC3ToKT5TGrkgow4IpnmRrnd+FIHsSHaAG6UrMWOf0pBIjx 54yKRZFkbJdUFC7i1ZKgKnOe/WjbtDYPBpkUscilg3A6e9OOSuR0p2FZhEFRzIRnIp3BkyoI PfFQvOqYXP1qSGUPwpHPoaGNDhywAHIomnw20ryOgxSsGQbiMYqNZo1bc2CWHWmNaEq4Zd3O TzSoyb1JJFNTPUdDTZCqnLMuBQwtdkuCCzZyCeKGb5PlzTAMjejghhSxlUT5myT09qLCe4oO UADHOeRTiCEyevaliSNgMPGC3qaaN2SpbkGmNascrkrjOKdx1zzUaqWJHTFSJtDbmPI6UrBL R2BpPkIjHJ65qPGB2yakjcFypHJ70HG/BXcegNCY72WgKuYgwPPpQCQMDrQiklkXjFCjkndj jijqNO6GqWOQ2FOetLs4IV+nehQehOT60bgrYI4HegnVIX5F5DbvU0pYlhkn2HrSKFKkKB61 IxB2c8imLfYiMhZyrKVI9qfLK0jZIC8Y4p5wSzPy3rTEeMjATmlcfK7BuA6HJp0YV8OM4I6+ tJCAJMkZz2py8kgABR0HpSHEQZznkYp4+djjAPemsTnGfypBtD5xnvTQXuyXcmRu6YxTEZlb ajAd8H0pCFbBxtHoTSKgL5HXpmklcUtNCbByBjrUTLgnkflUr5LBGYcUHbuwPmAqhRaQ0qQo 2uW3UbV3BGXPNNOR8wGKE3bgRjBpPQ0i7vUf82444FKBu5OOB1oIUMRkmlHOARx2paCepE0p 3hAvHrUgK524wKRs7geOOKaikuTnj0oS6lSkrWQ7I5xk1LjCjANNwDyakLKoHQ0tWQ5XHAgn BJXHJqPILHb0H509lDNkD5vpTW/dthhTsim/IajiQnqMGnbiMnBPpQSM5UU132pgHBJzS5Qj ccirjL8fSomALn+Zqrc38SSBTnI9KdFdCSQRgdegpXVgUmlYnXDzcNgDqKkLsZSpwy9qrXk6 W5JkGM+lR294kjgIRu9D1ptrYm9i25JfHSkU53dcrUF5L5CmWQ8U23kNwC8ZXOMmhJIG31JD v3ZY8Z4psgHDZAqqbvzLkJHg7evNS3rkxEhPmA7U+aKEm0ySKXOEJ61JKVWTYWBIHas3Q5Gm LNOCvOBxWiV2sQAG9xSUlLYpyuM8wc88+tRnO0n061MFUAnbn0qrfBktjISMEYPNLbUXNZ6l K6v3LmGEHd+lMsr/AHXHkSA7vU1HpcywsZ5wrc8VBrMnmXqSW4WMORmsZT5dRts0tRvmgiYJ iQ9hVA3tzD5cjg+WeuO1Rz7kvI42XK55rRlktpYZoo9uQOBVe0bV0Re5aguQ1qZlkULjvWXN c3Mjnyn+mKowmRbORH+VQx5q7YTJEoBAOeho9o2NMn026mlIjm+V88ntT9Vu5I5ligfJ6Zqj OxS4UDv3pkMq/azvGcVLrdCNWyWK4u7aU7yGB5BrQa9Dw73+/wC1V9Qa3lgzE4DKOnvWYWZY Edn49qJVeV6Fu7Zbea7l3srNz0HpU9jdyGMJI5JHWn6VeW9vjzEV944DVmsSt7LtwAxJGOlJ z5XdCLepTtclYreVlA9KgZru0uYwSSpXkn8KbpjrDO8pYYHXNSazdG8tC6DJAOCKHJvUGjSN 0ZLbexYhehxWJ9vkm1JUjclR970FaWkK0unbDk55xjvWRJatb35AwuTnirlKQROiR2MZXd2z xWNBLcHUmWVmC56mtuALHbqWGcjOa5vUknlv8QykHrzUt6Jhf3jpEYMuATjtTmYgh8Enp9Ky LC6kQCKVhuFbCgsmQcit09NB26DN+M5wc9iKZEd2QOB707Ch+enalchW4Ax3pXuO1hqAHcWy FHcUKcfdztpWUN8w4HpSElBtABFUhu7Qxgc8D5TT2YBRmhOcA5GTyKc6hTtGDmhkEUyZK7fw prSCOTa7DgUs9x5FvIQoxjAJ7VgQzfaX3GQkZqOZRC5towdzg4PasbxJHKiI8T4cNnii1v2X UPIUbl6g1a8Tb4oY5U2uzjkelQ5KSBaE2my77dXGM8VZmkJbJ4Nc/btPGqOfkU1rIzXEZxjg daKcrou6JQwOcAk+1CTIjc59qy4bh7eZg4II6H1pJJpZ5QYyAuec1p7REvU15JJHTfnn1qsl +r3PkhgSg5FTp+7RQW3Liq8VrGLnzlQBmPJpyk9LCtqXAQF6E55NISS3SlIK5A6UgJXhSMN3 p3AacBvlGF9BQJIVJZ87fSnlcnao6+tZGpTtHOsSMNpPNS/d1Fdl9rmKR9uQoqO5QTW7Kpw4 PWqtxZMI1kxy3INW7cYj+flqSnzaD3M6KylWIs/zetU7fC6gwyeegNbU120CFnAweADVKzhM 0nmsmBng4qJwsDeoutyyCJI0AUdzVK3hb5XyWA6VLryXJwowMd/arGiki2KSAE+tDd2kInaN ngAOcGsmCZEvXVgdyd/at8eaICV5X6VzwVbi9cKBuBwfeqnoI3IZlmjAFZGpu32tY2ZtvoDU un3K29ybeZ/mP3cVHqRAuQM5Y96UpXiUye5to4LNZydpboPan6TMpsZpScbB8qnvVO5M7KqP llH6VNBKyWDpGitx1xUPR6CG2jtqFzkx7AOM0TRrZ3RIck1Bpz3McbZIBJJxSXs7s8e5e/XF LrcL2LV9cvPGqIfLb19afFYgWJP3jjknrVKfKyq33jjg1YSWR5BuJAI7VSlfcCS0mMUfl7sA dTUUG69vWVm/ddiRVaMkyTCRj8p+UetPtZWZcqCDQpLYepJeZs33KpfnAINallMssAZgSSMY rI1CfNsqtlD0zV/R8rajd8xz1q4ys9BqNy/GeoweKcrFVIQ8HrTY+OnQ+tLtKscjArRtlrzY sZA65NGCCSDwaGOw44OaNvybs4pkSfRAWYjAJFGcAc5oLN8uV+X1FNjSRpGOBgdM0DikxTgD JPWq81xHE543VYkMXksWUlgOCO1c9PKXuySCMColOyE9HobQvYt4XkkjvUmRjcSR3rn5nm3x NCvJPOR2rV1KRjYpJkKcYNR7S61EWJLq3JwpI9S1EMqSOQrZx6Vm2kC3MJLyfMOgA61JZ2r2 8xbnb3qlJhqWZpkWTYTzU6sFG449qzdSi+bzVDACojcmW38kEhj1NCnbcEjS8yOVyFyfUio7 +QxRgqSPQVHZRPFHgc4FSXBEsC7/AL2aTu9RskgkeWNdxPHSpXUjAI5pEi8uJQCM1MQfLD9T 0q4XtqPmGqcjpg1Hcny4846d6FO5iCKj1D5bNotv3u/pTbJ1M6w23dzISnQ8mkv1+xS4hUkE 1DYM6mSNGyQeaWdi23eDkHriue63DXqWLm4kaFRzkjpToLVWhWXo2Oc1UZwWVDuBHepUnZJC hDEY60009wuPtbxhI4CnKmlj8y9vCrSYFVUUrKxB60WW+AsSxYnvT5nsBbv7draYBTgA/eFP ub0vbJGTjn86q3Nw7RHeeCeM1EyxYRzkn0NRKaQN9DRgsYmtmmXIPpTNOuPK3KB0pizPHhPm CkVXjJWaQAEg03KyHcmLJf3vlORwefaptRsjaTK0b5XsQeCKp2arCzMo5Y1LcSzPEA7YC+tN SuriLF7qZ+yJH5Q3E43Ci2gR4SSPm61QfLR8EZzxVyG5ZYhGPlwOuKObm1Y1ILK6EUpDEken pTkZry9K8BQetUi/+kHcOvoKmtZNsrFCR7YqXLoDZY1FFtGB3httWrecyW2c844FZ1yxnhbc vPuKu6MFaLBXlRzVx30FcyZ5H/tKPdnr0ro4lwik9cDNY14qnUgcAj+VbURfyl4BX1og3ezH ce42x/cyT0xSxFE5cEHtQCf4m+lNYhhg8n1rcqK5hyqSxI+tPXqTQxLIu0gYFNcqmMknPpSe pTs3YMKXycCnNk/KnNMCg5Zjx6U8BtuV6ChIzmhAhOVb73agyrGP3iAgdc0qKcFgxz6GszWL hol+ccscc0paBzl1bmFyQhAHpUilXjJBzisCN9g3nirulzOx3Mp2Z5NRGpdjv0L9wyqu1+Mi sWxRRfkgnBNT3U/nSsBk84qtpsPl3rOzNyehqHO8tBXNK92xHBOc9Ki2LIoOakvUd139h3qi tzHBGQz/ADtwK15rbjTsWY1wRGrDGe9W5CIgCTtxVCxt3MnnPk56VozQC4i2SdBVX0uhOWoW 0guGODkD0q0rgSAeWdoNU9Os3t95i4X6VcUbujYxSTfUq3uiygMx4wPSkUKcjkY7ClbDNy34 0hJhDHgkjg1V9LhpykkbwhGBkC4HAotJllPllhnsaxYojdXWFY5zzU1tDNBeujsNueBWXPck m1e2ebavmEBT1FVLm022u4nK9ea2lEewiQA8dcVlazKskawRA5zzipnCyvcTH6NKTbbWJIGc D0qjeSzz3W2OTaFbBFaljAkMB35DBeB61ix3OdRZAmDn86Utkg6Gzp8jorZUHIxzVbVw5tSY 22nPatKKJRGGY4JFZ+tlTFhjt4xwaqcbQGmWdKdfsiqetWbyUJbExud3cdqxbJmt4wxbK1qr JBc2RZflIHJPehVPd8xXKOnR3N8krFgNoJptpO0NyIju69e1MtLkxSOIRuByKl09RNqcYkZV Q9R6Vk5PmVgLOp3RLKiuRn0qkIJ0USNKxVTmpNV2DWGMJyg7VLJcRNCYjnOOBVzeruNSuW7a +jazLFskdqoeZcXUx8pT5ZGc1Vg2iJlLAAVas7kwRfuzhSADSVTm0ZN2T2k7wuEkJC0/UbsO Alv8rnvVW+eKR0ZCc4pls3+lAuM4p8/QLjmhuiFEzHA53Ctu2ljaJQGJOOvrWde38N1A9smY yo5o8PAbCg3Nt65pwn71h7M2IzhuuKiO53xnGDUq7ZG4+X0pGBV8dxW+45PqSLsVfmBJqNmA 2kHHpT2IdA2cY60rLCFBIBH8qNgiuYZvfJHOe9OhXG4FieKeMBdxxj1pCWf7g9+KLlSikNTG Pm/CmMASd2SD6VLlcDjPrSA7CSoz7Ggl+o2JjGQAcelSSsGwQCCKaBvXdgCj5h1IOaY0hzOV wcZp0agqeNoPWmooyOaGf5yOmOtFhO5LCY8MhySOjU0qxOVYD29aHk2jbgHPpTUZicY6dxU9 RXsOJCIztncD2oHIEhHJoCupPU56ChVL4ZzgrT2AUEMpJzuHtSKwAIwOafI2Bj16VGMEetLl KeqJgqk5Ycjpikydx6YpgLDvxnpUgHOOlLUnoIJF3bXU49qecAkAYHaopAxICHnNTlXcAu3A 61Y47kShirMRjBxj1pdzqApXINKgAc5yV7Gk2kKQCcE9aWwru4MMYoRQvbim4JTAJz3NSrlY 1Lc0wTCTbxtJ3dxUYVQM8gk81KA33kIGetIEAHUnPqKjlZpOaUSRwA4YMRmonzuILbs96llA HQ5qHa272prUUr2JdoCA7h9KrXpCWrO3XsRU+F3AkZAFRXxH2Z8jORwKUnZDb92xzCTb5SGz k9KmtEnF95wDEYxU+mG3G6Wbbu6AGrkF7GkmYQCPSudJtXuZtNjby4RowsiZ9Mnoax1nmGor iPAH8QPWrN68kGoxyzgeUx4HamXZ/wBNDgqI25HtWc22rlRVjbWMXNsUl5JHFYN0Z7Kby4iR k4PNbBuHS3DgYIHBrKlt5b1ywY565q5tuKsS73LOl27GUuf4uTWlLsTIJ4IxWTpVzKhaBsjB wKu3u7ym2gmtIaxG3YsQKvl5G0YNODfOSh5xzWdpqyiIGQEE84NX2PG5BgkYrSNrDinuMLzl TuwEX0qHUwFsTnBzzU6lgCJCcH0qO4Amt2iyAG45pv4SZ3bMaws31GMxwleKgvYvLkjhmB3I eKmsJV0mZoWDFeoIqSHN5M0vYnoRXJb3UmPmdrFTLNqSsvQjFXJbH7Orz55fj60t/ZvCEnib IU8gUx7mS6j8vBUAU7NIT12KbkvbPnOATxV2wtFukRxuG3t6VJDZIlgwTJYnqagtbq4txLEp wOh4ocXFCIboBL7aSWXOBTIEV7pkO7Jq7Z2wlffKSQTketR6nFNbyiW3jLDuO9Ry63AS+sUt rDMTEyOeQTVJ12afFuHORn9KuSXEt86q8LQqRnNWpLBZLLyhnA6ZqpwvsNOxHZ6cl1tlLDCr 61nmJ0vpFzlB0NTJNd24NvtbaO471Z0y0abLS5B65pyg9Aa6lTTrdZLp4pBkN2qxqVmLGAxj 7uOMU2/tZYLhZ7fIPQ+9NjFxcXW2QNjHU0NaWC92XNF3ta7UZlzzx1rNvEDamok3bgeueta5 X7LFhW+bsRWJd/aml8zBZt3WrldRKVpaG+HVoRtU4AxWBsd9TLBjnOMVsWBdYSD6Vkz29xHe m4Qkg+1PRxQrWHaizR6lGrJgnjitiPcEHXFZscUs8yzS/fHrWsWACpn8KqndO3QIuwRsC/PH rSzr8/BzTJZVRs461I0ibBkEZrVpDTuxCx6dKjbdj5RSjB6sc+vrSkYwxOAaIoHIUNtw2M0q r8/mEZNISu0k546ULIDF9386Gib6lXVt4smZsLHzWN4ft4BAxBJBOa3JlM0TLjI9DWWIZbcl VGF7AVjUTuCZYhtrbzQUUK2etQ67hEQYPB5pbCCYSGSRz8x4HpVrWrdZbdI4pDvxzmkkrMDP maL+zwFUs/Wp9FeUWpbYFBGDmq629yIwpxhaubWW28sAjNTTve4WM7WcSnCE8elS6PschXzw Ks2luqvukTI96hubSRbhZIWMY7jtQr3vYNjQkVUGMZGOKzoNQVrs27ghgavRHj942eKgjt40 lM4QFieSe9b3dirouZfbuBHHHNR4b+I80rSEtuxge1NkYnDE/hVJAmmTBwI8jlu2e1c5fpL/ AGoAwJQ8/jW4p49qrX0bSn5UIx0NZVU7aCdkyeVxHBHvcEAflT4vLkjyGGO3tWY9vPsVGbJq 9ZoI02HpjrRB+Q7mPrCia5jjMvIOQM9a1rc4gAPTuKq3Nor3IfHIq1GG+6eB60L49RWVjN8Q f6uMeYV56A1Y09AbYFWyaj1SxkkkGGG30NPs4WiTaBjFDXviW5bUkxPlsADOM1kaYEj1jJUE ucnmtJlzkZPIrKewP2kyrKwPtTqRdwe465ydcKpGGAbrUepFjfr5o5+tXre0ZD5xzz3pb+0M jhh8xxWbTCxFfeX9hwhw/fB61Fpaytp7Y5JFKLOYyFWY4JrTtUFqjR7Qcrihr3hozNMAMm2c 45NRajuMixxgbVNTS2RExljdgCehqWG1zLh8njrQtwSuULxDGsUkasSMZrTW4tlsh8ga4bkt /dqWSJHhKHoOlZq2MigkvxmhRa3FYbbwPLMzBgQelOtU23xikbAX8qv21skMQwck+lRXNmSV mBJJNLkadxkOtiN1VYRz3q5YI62ygjt+dVIrYic+a5IboPStIIwCgP8AKOBVxuwTHR7nO0dB 604sXyDnio8kZwcYpUbd/jW72F1HAoTg80rvgHHT0pgZd5yD7UjKc7t2fakncGh4c7c4wvoa FO2TLEkN05pucqP5U85dVyR8vSn6lR8xJcAER9+tYSKj3z7sjB5zW265BzkVn3FmN5ZSS5rO paxNuxNOYIiApVh2wah1UpLZKApwOMCmrZSMy5Jx3q9NbgRiMEdPyrNtNWsO1inpPkpb/PLg rViK7hmlIRs4OM+tVVsGRXCtxUtjbeWBkcirg7bi3ZJqdyi2zQKBuPIzWKqtFtnkBJrVmtfN n8xs5FWLuCNrZI1UYxzUSjzMd7DraZJ0DjC5HIFVtRlMacYA7VLZWyw7g5+mKdLEkp2su6tF sF7kenymWDc3DVbBz68VAoRAqgYPcU/djpxVJ6DaJCQVyoxUNy7tAVxkkd6fEC3fp1pWBDgn mhu5NzG0xIku5PMJQ55J71LqSq8gWCTjPUipr2zaT94vc022smWMu5+Uc9awtbQCoY5AdxGS Kuq6mBs7c4/Kp4gkyEgj04ql9iKyNhiVY8mm/dEQwKZmOOaks1WOcpKcitG3ijgQBF4xVa5g JyYweaTT3H0I79bcLiM7mz+VVLhdkas6lsEVdgtSDuIJ9TVuWNDhWUMMU+Ry1EQ2y2509md8 y9QKoWwM7M6gg/zqy0DrJhR8h7Vas40iByp9qbV9ARnQRutx+9GADVnWSvkhYCrnvUl3ZvOp cPjFR29oxYbmJNTqtLAV5rZvsqTtwg9KuWbQyQdg2M81O8WIinUenaqQtWjYneTuH5UuVxGt ytbxGe9bZyD0Pap4AI7nDYznpVzToFtgdnHei8t977x1PeqUerB76EeteU4QWzru2jdgd6n0 tSkGWGTiq1nasXJK9KvYxF+7b60RVpXAyNRDrfph1UZyRW5blPIDAgj0z0rDmsZZbkSl81p2 ULRkDP1pp6gWmOBnOaR3XYFQ0kpIJAwQKhB3EEDBrZ9yotxHozdc5pwIJ559KafkXb60DCZL c0IGru5KMn/GnqCq8tnPeo4nz9DUysuRx+dURazAYyFVuTWV4iXcypL2PGa02bZPlRg9qh1O NbxFMgJK9DWck2gKtvBC9mfMQcjGanUxR6e0Ua/NnrntVN47hv3S5C+oq7awhYChOWx3rKL8 hmVpxZJXcgEA0+2O68Y5wPSp/srCbMeVBPNPS2cTk7ufWkvd6CL8wiWz3lx9M1ztxEHmEhTP zce1bN9CrxiLJ98d6WK2QxhPu4GOac7yYMWymDRBDjA44qSV/LBPtVeKBo3wOmau3KRywoij BHU+tXG9rFaWILG6kcMmPl7e1SeYysFK5GetNhjWE4qcMgbOCRVxWmoh0gUewpLj5rRsEDHr Tk2vkkHHakeNHgYlsHpiiWwGVoUU7X7bGGM9c1qzny7jY+Nx75rJ8iaOXMbMqg9qms7eRrkt LIzZ6A9qyi7WVh2NK5XZCGyCPasbTnFxeybgwKnr61tTRBYinU9iKo6fbyxzlmVcZpybckhG mkbtlsLwMZPpXPCNDqjYA3A1vykhHYEncMY9K5+C0uFvWlJJDGiatYLWRviE+SGLD5u2ay9b jUwgSYIHTFainEYBz05rP1aJpY/3a5Pb3q5q6Fcr7YU0sOzEMTj6U6yLDTyvB96ggiuZIQks fB4K1pWliq2siMTgdMdq5+WTYhugWT307xRlFKqScmqjpJHqGFwVBxmkhjubOV3ty24+9T2F vNNKZmBUA81Uo6oEiG+XZdpuTlupq7LaQCz+0bvmIxipr6BJeQcketZ0a3kjmPGUHSm01J3G tCrbocSKee+K0dKs2ltt0g2qPerkFnGtqxY/OwqhiaFiEZtvpWVnF3FYhvAi3RCfdX0pscTG 4DRt97rmremWjS3TSXAwhqe+tChDQnAJwBiqUXuMS5tLeC3MxlUyHrimaC0iqx4OSeR6ZqAw zXBNswII6kdK1dPgFtBsGSBxmrpq8riau7lsEuRtHTvTk5UtwWPfvTdpTk55HGKciMV3DINd AyNVcoduAAeQaVkZSOhGO1AYg4p55b2PamkCeoAbVAdjjsKcTtPyHAxQQCxUHketNY0uo7hI vA2k/WlKkIGyKOMdeewpTnA3Ht2oKugjwjMSwxjrSB0LbgQTUY2qrKMlT296fGqlAANp7imT ckI3YI49TTX2pweSehqRSCdiHoO9Nx6/epJApIQISm4EfQ08IfLLRmkOCB6gUq5wQDj1oC43 cx+Y5zinbXAG45JoDlV69vSnY2KDnJbmgaY3BGAxyKkZV2rtAFRn5iCetO3Z4bqKkfUdMFZV x8pHUikK5UMCM/WmyZI+VgOelIN6KDjOTVIuaSRKo53kAYGBSSklCqkgmlBwMg5z0FDhiQ+N oPajYzTsEKAR7N3PvSxqzvt3AKBSBV++3UUxtxcFTgd6BprqSBSMgEf40bWIA3D6UowoGKPM w27+L1oEpWuKm5VO4/hTTwMbjjrSSSMxJbp60qMnXnFFmK6a1JWO47R60gymUP3j0pZUAGCM HOeKg2vK+fMxj1pJGl00SCNgOp4PJpH5YgDgilky4+R9qjqPU0wZ2kdHH602r7jaSjczJtNR 3JKkA9aktdOjt0CqCe/NaPWMFhz9aaRIQpYYXsaxcYmWtyne2UcsY3fMOwPaojYxvGqOuQO9 XHOHCknrQ2QxXmn7OMkNbkUlmr25gDnaOlNt7cRx4Q/L0561P8wTOcVATIDuxkDmnGmrWF1G m0iDbvutS7WIx1p5O4BiMbu1Jk87Tz3qoxURpXHKMfKFJPc46UbjjaVGB0OKFcqpxgEjrmiB dqbn+amrWE7piEbgQqkmmlO7DipDIRITCh2nrUauQTgUrFJIjmghZfugt9KI7baC6gDipl4U MoGe+aRiGJ38Z9KSggsIEzHtHIJ6VGtmFc8AU9iyncpFDyhnDMw/CiVOL3GmrClNqeWMYHSo GgjdslMjvgVMTuBwfxpobI4PPcChwurGdlcbCFxuWMgKaVvnYk8j0pAJCG3fKOgGaVA8OSZF YYxT5EkU12GJApfAGKeSoG3OCO1PVkC71lVj6DtTI8SMWcAHPFSoWDTqRFARyB+VORdv3elL M42YDgt6Uu5hGAwAo5LO49AZVccA4HrQhVCWABbGAKaJNr43KFPXNMWSNpOeQPSiUEKxKcYw VBzzUYjjyRtBz+lOcgDchBz2oUDG48E0WTQJgY0AO0445pgjMmFH3c5pcEDBO6lbmHjIIPQU 7CVuokkcUbE5wKIyMbmwfSo1lR/l+97HtUikBTuXOeKaSKsNn/ehdpCnPpUkuQqhmBIHFRnC rtx3pecjPIqmJIawZh1+lOKlwoyeOtOMRVQwp8WOMgZPrSv0HoQnH8YPtSe1SArlsnOKjypY hjzQ2JIdg9gcd8VFJtJAC5P0pzZjUgZ+lJk8Fhg9hSUe4kkA+4yhSCD1xTJFUBWPJB5qaR8j GcUwgnCDGKErAiJ/Vj16UrAcZ5qN5k3+XkZBqRgSgJ4ppIptNkSqwJJOFPSnHcVyxBFRysAo yxGOxpyMHUEHFHkO6toD/cUkADtTHbAHepCF4yM+tMjIDHIyB2qtCLC7SRk4ApqYbgEAetLu DEkDj0pqjjoRUsqw8liu1VHyng+tG5mBYnHHSmKW+6p5pcY4JGaaQSshUfkPjOKeV3gug49K YXwMKoHtTdzdFbHqKVncTeoYUA5GT2zSbx5YQhT3zioZr5I3VWAwTTBMHkOwcdhRZXF0J5My YJHSkK4UECop5wozwuOtQwX8MhA3UWQ07FgsGOAMYphG09s05txXcKjYFiC3WmD1JonJTZnI 96djZkZ5qA/IpIH41DNeJGRuOT70XJLTYByME00Fs/MQT9KrC+QN061PvUgOAM4zmpuPQkAV pQGXnrigfKxHTJqm18m7f/EOKbHfiSbbihWLjdal4gFiEFJhQCHFAJI3mkY5GOTTaE3d6gwB A28AUHOBg9KRX6KVP1pl5L9nCkFTmpd0NpJDgRv3HBNSMdqiqkFws0jZwKtZXAx1pxZN0IeO T0NKSMDsKHGODxQrB2wy8Cm1oJ3YI2GzxipTs25Awe9RAjLDOfTFIwwoB+8P1oQ7kisoBBHN J90Z65qPerDaEIPrTwNoyDz70cokOIOBubijA6nrUQ5ODz7U89OvFG5S0HEgcmkLK3ykfjTd 2BuPNNedYl/ecZ6ClZDbHsVBHYd6GI5CnA7VXtbuGfdgdDjaas7Rs3ZxinZIhiI2PSmtimxl S2QevWngKcjHX3pXRS2FYlkyMZpyEABguDiowdpxxgU55CSBjFMWw07Sfu/N3NNyA2Opp4Yj J70IkwAMihSRTsUpCMzjlCBnrRlSQGbHqaQA4YA9OpNIoHlgMQxzmpVrk9SV8DjORUUhyhRT wRUkil1G0YHek4Xpina4tmRWcKQwMqnnrzUtsSUOU+lVJZ0ib5m5Jp323A+UAHFJ2Bu7LTsC MUgOE4HBNRQyrKAe564oluFTcmRRoVdEqlwrc/LQMcHtUUFwkw2g9DSyzLCx3AEAUPyFe+49 2BbsKc+0gkVXjkWUBgoI9an7gAU7X3G0lsIhJ7E47VONu0fJg1SlvRA+0EbjRHfbmAP3qlp7 ITsWHfMm3bgUEDHIyc00O6yqxXcD+lStJmXJUVdg0YoGMDbxTWZQSPWkd98wwwXI55qtLdxx S7B8zZxU3d9SrLoW4weSgIHekA2k471Xgv1LlCQKmYsRuXp702kyYrXUfjLHCgYpWPAAXBqP JGMmkaQ5zyaSiUmloOkBbocY60ibQR79T6VGWLU9ccHtT2G7WHMF3nHOKBuzjjBFLwfmAH0p Qf4QAB6UXHpYdEpVQhGTnqKlZWLDdwBTSQqggYxT1c+Vk4OORQzNu+gjcc9aCBgDOR1xTd28 bu/elGMkqPmo3G7WBjtO5eKR1jyrDPvTG9c5OaJieNoxSsS9CVWTcdo+U9j1py7EHzLnNQxg 43EipBk9qdkxpDjx82AaXOcsR1NIrbcgjOadn09aB6IawB5AIzTWAfAXII6+9T7s/wCtUDjA AqADLE9BSSHzX0FYKQMjJBp6R7gRxmo+Wbbxmnop5b0600S0LEGz8wxipGKs2w8HtTATkkGn gFm3DkDvSHohhXBwelOVUBJHGKJTgjcDzSLjvjAqkkToSE5IJoXbuJaopJ1Zdu4A5qLz7cDB kJPrmptqDZaBYSA4BX0pwCjdwPmpiTK+CuCuKSWaONcs2OelW0DtclXKqVAzS7Q2AF6U2ORX j3q1RNOImJ3YHekVy6EjRgPleFpyqDkKDg9aTKuFKygg+lSgqOdwx61KRDG+UijLdDTwqlQE G0fzqGa7giyGkHPShJhKBtI3UwVrkoSPkMDmiFSG6AA+lCAkEkjI7VIzKAAAc02DIyMHHbNO MKlRkD3pxGWAHXvTGlRJhHJlSDyamSXUroOgWIEgg4HSmuvGB0zmnF+cJgrngikzhsHvQoiu IsYJOO/epCCiYYrg+lBTHofpSxqhVtxb2pqKQK1tRIv3nBJ2jrTIduX2O7PnoakIwoKLgZwT 60KC7bxhSOMj0p3Q+UQDJPXI60/gJ8vWnE7XJAGCKjBLEjGAKAtYcpXgdzTgSONoIHeoyMcd CfWpIAqr85PIpi2EHlFcqcvnmhwBtIJz3GKaFG8lBjv0p+c5ORQJiMqYG05owQMd/WlC4Hy0 rkMowMYpBa46PaV64pMkvgj6UwAo4JOVPapCOd2Pl7UDSAKFbJpzcxkKcDuaYJFPITAHWnYQ AFT17VNythUwBzhs8D2pGJBPG7bSqNudo5NA3xk4wCevvTsJOzGghmyMcUHlWbvTlQrk4ApM npRyhe41AfvE9anP3Pak8vHPBNErSIgjC7vpSfkO/cAwA24FA3bhzx6Y6U8RMYvMPHtmmAkN nbk090EZ8vQe6gZOcntTGJA4XNOK8Bjgn0po4yRkZoVxb7jlIxjtSEdcdKVFDHHA+poKcmi9 mXZWEz8uAOaRFB+XOMU/btwT36U9CIyTgc0a3E7co6RsMFGSajCgNz19KczfveFzUMe5pGzl mzVBGzWpOqgscd+gps3BAIwQeaVMIxIJzUUrqrGRmJPvU2IbsLICTx1pN7eWAxyap3GpEYCx jGetOs7xJJDHwWI4qYuNir3JjBI8m4Y2jrmhh0w3OeRVafUHiPlbdw7iqkGpiSQxuhRgeMiq 5kN2aNU45GPpmsy9vGtrxIwM56mruGKEDLZGcisi5lX7WA/0pSfYzim2bCBpgJW79DSsqKvy 8HufWowriNOcjHFRaoZBabYVw+M5o2WpSepNHKpYZX8KkkUg7kb5fSs/SDKbZZJiN/SrhPGF B96E77Be7HjcE2gkCoz8ntR5mexBpl5L5cRdlyAOMU27Ceo5XBODyKcVDIxyMjtWDDc3jln2 4XqpFXbK6MreUfv96jnj0HytlHULm8W8jhijYq3Vqh1Nr228vAxuYZ+ldE0KqAxA3A9c1j60 0k1wixjcxOKiTdrg1Y0FlJs1dUwFGCfWsUT3T3DzxuViX06VqTF4NJZHAJ6AZrP0YyGJoHA2 t2FKVSySElc0LS8ee3BPIPeqj/aZrpooyUXsc9a07e0CxfKoCr2pt3sjjEg4I6Crv7uoXaMe IT2NyY3kLFjzk1oz3BjtQzZAPes65DXd+JCCFXpjvVvWJytmiiH5AOeOtSpWQS1KQmuGLtty f4fetm1mEtsfMBVgM5NZWgMtyuCDgdPate4hiNpIuMOozkU1J7iMmd2un8sAjae3eoxLJa3S qQSp4NNtLv7OC2CSDjJFLqbmSJJAMMTzUOd9WUnY2Y2BBPRe3pTlcNnBHFUPnFih38HsO1UF nuIJwqEkHrmr50hyaZumRVIwNwPb0qpql2LZGCv+VOkZvK83IyfSscutw8v2nI2nI96cp2RH LqS6A8sly7ht271rb3MuOOKxdGaPzHAO0DoRWwmOxJFKk20maTViTGRkHr1pCQuAAaesiqjJ tqLnPNatkXJGfC4OcdqAQy4x+NMDMSc4K/wilOQu1RuYnnFGyBaiEAH0FRHLD5etSSK2RvXB HakRGHQcdqV+rGnYFYnh2zjqajkmj8wAvx0zTL6TyrdiO454rEiuDIBjnvmonOz0BO7OgQxm Y4BfAoDo0nlu2xWP3j2rH0+4m+2eSM4bvVjVGwfsysAxPWiFRPcUkUr6LytVIjnyAecdDW0G DQK27865/wAt0u1jc59/Wt2Hb5AR13elZwb5gM7Vhvh2CUxnP3hVmyx9nAyS2Byao64ZEX5U 78+1XtMGbPfnpitN5agnZj3JFVjcqZSikbu9W2yzdCxPQVUisQk7OQNzHPNVKTTsh7ssKwyA Ryepp8zZIKnAHrTCODjihQzRkj7wq7XE7oQMvXkEmmSyxKDvJ3elKpIwXHI7ViX1xJNqgjPH PFJvlJ1NaO4Rm25+b0p0kzwq0oxjp61myWMyyebGSGzyfWpr/cloULHnr7VPPoNkFtC15Iz8 EiopppbO9jjILK3XHamWc5hiIhY4OAabfvI1xHjkdWNZt3GaE8TSzBQeDzmqupQi2QFfTqKv GPbbIfmBI4yKx7oTBvnbcp9qHZIErs1tNLNaq0kuTSTXADlQcgVUicxWJdQPSq2+Rl3Ac1fP yoe2hrxTR5AkJMZ9O1Y+oAyX4AOVBNLp004uiSAUHY07UIHe5E0anPOFHepnK8Sbal62t4nb bkAEU+5UwW7ZJxjis4yyQgbgRVzzXvdOK9wPTmlsG5V0qDh3d94Y5Ge1XobZV+ZTyOprPtIZ 4l2ZJHapbO7/AHzwseRTi1cpNo0GlQIxZ+V5x60W08bKWLYHpUF/5Sw7SwLntWUJgkypjHrT lKzsJo3Z5SsRx0PSs2ItPMfM6Z4zVyRz9iyFByOtZdq0oBLfeJ4olLWwtSa8iFnKGikyG7Vq xMWhRmIrHvZt1sFkTkfxVo6Z5jW4YqduMc0oaMaVyBtag+0va7N7Ho3pV+OQmIZ6d6oR6ZAt 8boqDk81qSmJX+VcKRwK1uDGJgHco5o2k8swNMyY/mwTQ0hEYcrwTTG9UKCRnJpUI253EmkH zZx6UcADC4FMNxUycsBjtUck4jbbnmnlmG4p0FYE9w73WDyM1E5WDmNf7SpfGePSpL6OOS1L l92Bxx0rG3nzBhcnNawaZtPKEKqAZPrUc/MrAmZ9jdxwsWIyRxnFbKyh0DZ3bhxiuetQJFY/ ewSOBV6wuwkwi/AilF20ZL1LLzqkm3FOW4QttJ4xVDViYbnaFyCc0y7WZII5oiM9xVSmxmyO Rnt2qteytEAcEk/pS2bvJErEc49OlOuVZwACAc1TlpdAOtWeRdxqwWfA3Zz2qLy/LQAN25xU yM5iDkgovFOLbQNkIfGd6k5PambNgZl4B7VNyQ7DG3vVe8lAtWkVSMd6d0hu1xPtm0FaW3mD nnvWXpyG6kLmTI9KspHMk6lCMZ5FRzMLonv7TznGOF96r3luscOzeSSPvCtOT1mPbgCs25nE snkLjC9KiSVhNhoJMMcjFixHTNVpmZ71mLcHtV+3jMcJz1x2rImWQ3oYDK/yqU+WIM0raGWK cELhTyan1Ta0Ryu0461NAJdiO5yO2Kr6uWNuFZSD2OKqS0HfoQ6XKEiMRJarsuI4zIGJ44rI gDRwF0/E1o2sgmg2MA2fTtRGdkJso6Ysd1ess5ZeevpT7rEGoGOMM0f96kktpI5SUOMHmo3L eYCzVE3bUDYSdY4cnP1qM31u0mxGO4dc9KqarN5ccSIc5qMWzPBuI257gVfNZ2Q9DR81Nr4A OVwDWZpsQnu2Ej7cNyTU0ERWPBYnFQSB45TsXrRNttCE1FBHeKI2wFb8621kU2iEuv0Fc1O7 GZRJyasT3DRQxADqaUW7gnY1nuY2jwDgjtToZlKY9aoQW7ywtKCDmprBZIlxKuatSd7AtWXV AIxig5VdoGfWiHIJ4GO1ShOATzmr3GIinaM1KiqB1OaSMbRg8+lBOGBHfrQ9CuS5ImwptxnJ pTgR7emKYxAXCrihSjIS6nPY0bitYXHAPT+tNkZUywOMDpT48/UDoKoatPjO1cCm2kiWTG4i CgnqfSnBlcAg1iLMwiL4JPpVzTnlCn5cjGfpWSndg3cvvcQxHazdalt54xmMYy3Q+lYckn79 g+eTxmrCQSmRZw/yjsKpTEbAZIkYPk+hNQmdFActg9hVfUVmazEjE47Vnw7mtXd8swHFEqli uhv+eJ+erY5pk8ghgdmU57fSs3Qbgy/eXaelac6ecpQnrxg007q4RINLnW7JJBU/wmrjZRiB jI4NQ2dmbclB1HIxU0g+b3pxbe4dbiqVVcYoMm3IXgHqKapO0Ark+tNu3ZIdwUdOTim9EGjH XEqBVy3NAlgA25LEjisVWa5kVlbIB5FWYklW44+7jjNQphJpE1xA8mVXI3fnVe90xYrFGEvI PIzWmjHr3qhq0qsBCgOelRUj1JWoujOXibeOgxxTL93aVUXBGeam0mDybdzzkCs0TSjUSjKS GPU0pS0QjTsFeJsOSyHtSa0N8R8s4yOKtwCMyAEHHfFV9dEfk/uVYGqkrRKQukMPLCOQDjrV m8l8u0fC5Y9KybHzUi8xxnHU1qDbe2BkV/mHaiE9LA9TNtI5LuM+YvTkj0p9vObe6VM9TgCm 2RnttwGRngmq0BY6r8wJXrz2qFbm3EdKrA/O20E07zAs3DKQB1rIupmDBAM56Uxo7lFWYBgu fmOK0dSzsBtXshtohMRuLDIwaxIxcam29WZGB55qxcMxt8sTiqmlXr2+9o4yee4rOc7ysNy0 N2KPyYwo5IHU1LEQZF3gD1zVG1vhcOTJ8lVb24P2rYrls9K2UlFDVmbCEGRwpB9KezqUCbQK w1+0xzBs7RjkEVqwkSAM3UCiMuYVtSeFm2mMnvQGyWiCYIqISbmAVT71OMrliecU+Uty6CEK EXruoLE9T0pACcN/CaCAvJ6U7EbilQQpJ5JpSWU4fG3tT2CSQghcY6VGhTad6knPHtTKaurj i3OB8ueDmmsPl2KBxSoGZiCQcnipEWPJDEjigkjRweATin7Tux3qNQu5t2QD0qRnY49aTLit BwUJkuM1GkhZdrH5e1PxnjH50qKCMEcChEOS2BVABCrwemaTaUAVutIkhJKkbQDSth8nOfSg cVcdvB4IpJHwCegqMKWfP90VPJtaPaRz1zSuNxsRxkkZDEj0oYMWznilztUKqgY60kRyQelC ZMtFoORZFYhmyOxpVkcOc8E0SOoYAZwaWQ7fmam0EXpqK2Sv3jgdqaZXYDZhRihGUkHv6U7p 0HX9KWw+g5FwgOcseuaVQedxwB+tMMmUKqQCKE37AHOc9KFoC1EJLOHU4HpTkc7+V+XtUb7v 4fxqRVYkDmnox2sKJG8wqVG0dM0jqW+6AaUtt+TAzT4lXGS2TQOyiKhBbBPy9ajVmEh24waQ yqVAUY96a3T5c5pWGnFMlVcFst9Ko6sDFbmQHPHSrse454Jz+lVdUJWxcKm9gcik7pESUWYN sZZYSyqwyc/NVnTIZ1uvMZQuTwc1JpNzbLbObwlML0X1qeyuRNMGj5i9a5opvqVdJWKuoq1v IXVGc5p8KxXW11wGxyKfJcRvetDISqYyWqgSiXu63Y4Jxj1qtmQtzbSNkXCygfjWDe28jamr bwEHX3NbWdqAnB4rE1KUDUYiFbGc8GrcrJDWhtwLIFVjnApZiyrmRgc0Rncok3ELjoKg1OKS W32JlWHOR3rTmugurkw2IoKEGnrMpQZBz3FUtLglWFfNJ3e9XvKIO8rkHvQmDaY3hwSp6GqW q5Ee3fnIrQYqEIXvVDUYTJD8uc0S1RJFo22OIxuNy4xViC2jWRnRADWdZ3RtgzPGWA4xU9jJ PNK0hBVT0FZQiuXzKTaH6pKY0+ViF9aisYXdd/Uk9al1mMiz3AE+1N0dXS2UEt680S+JIpO+ 5LqKD7MwcHgdKo6CYxkEZJOBntV7VZGNqSqkyEcelU9FDQ5LJkv96lKKuiU7M2G4UqGx361H HHFM+2Q8eopZI8ovzA5/Sslpbu1vWQqDCc8+9bOyWotytqjra3yBGbaW21f1YRPpcYV28wHn 0qnHm8uAzR5VG5yO1XdbXChIFG3b+Vc8tEw6kOkIVj3KuF74q9dhltmfBIIxmqWiJcLCYS33 uavspJ2sSV9M1qleI92Y1hEsxIbk5zim6sgEGDu3Z4Aqe6jubSbzLZQec0xI3u7oSS5A9K52 rIrlchk7yQwQJg/PUd/DJC0TCQEOATzVzULOXKvGdwHSqYS4nQmWMoQcAn0ocGyLamvYRpNZ lXxnsTVGWwAWRwPlA5NWbCNo4hvYnHepdREiwssZIWRe1b8icQe+hi6NHGZ2VGIGa3wI2AjG 7I5JrC0i3a3zuPJat1ySmAwVsdRTp6ItptCYxlR29aAMNgiiJtmGYb8etPdG2+YSMHtVtk2s NYYx3FMYmM7umT2p2MNyeKWUAkc5HanfsUrWsAYyMXY54pB8oySTihh8oXNN+ZWIJG007Jkb FfUX3Wjovfms3RbaNbXLjkjvWnew5iwpySOKzI4J4oyCxJx2rmqq0rjRcgjtUnJ3ncQcis+Z Fl1ZSCcp2z1FW7GD5leYEHvUd/bEXO+BcEHrStdXSBIr6k0YvxIGKkHAFa0R2qhjAYnvWbPa ySxq5XqeprQgAWFUAwRTpayB6FPXnIYBmG4nn0qSxI8kDP4CoNXtJJmG2THOSasWaFEC1X2x XJnlMa7k6rVG0vjPcOgYk56GtBsK2Dyf51AkSRzFwoQk9q1kNXRIDG58vdhh1pq7tx2sBilk X593UmmzY8sckEdapD1bHIRyzNjFc/O//E5V2XAzwa2FIKZ7Gs+/tjJIr5wAeMVnUWgNWNO6 uQFjBK7AOMVVvNz2rMFBz61Tijlkco2Stap4hEZHAGMUlrGxMvIztLWLBDIAO+aguFH2klPu elTTwOCShIHpUlrbEKHIPTOKze1gRNHdkKiSYZQMLntVDWdzQKEIHPGKmurd5F3xkrg9Kqz2 ssgVAxHrTltsF7MZGu6yK85xVjTYQV/eEBamktgsKoM8Dk+tRi1mjHy7iD0FO2ibBasliFub gpHgYNPaZRIwwABUdrCUO91GTSX0DvGTG2GPpVt2WxTs2VdZYPahI+T14FT2MypZxsy8kYIF VhazLGA7kn1q1Eu2LbkBsVH2riasWbW4iZDudVA6Vjoyf2g2372etTfZZEbcCSD71YtIEEha Tk0S1lohXK9++67TeOPUUy8jjVwUx9auXUYl6cCoHtQ6AHNJpth1LsILWBUnntVKxfy5z5gB APer1p8iBZM4AwKq3EBZzIvANVJa3F1GanhiQgU7vStG03JZgLkgjAqla2p3b3fOe3pWlsCq ADnHQCnFXGhnzhRkc0oPOSKGJ6kknNKACCwboK02G49RrkkYB59KWMoMB+g7U1PnGQMGmkYb 3707CuKZBu3L06UsjMy/J60zb15wD2p5bAVVBAzyaWxb5bDsYjbccYHrWFCVN0xCgDPWt1my MHkVnz22X3ouBWVS7IasSS/ZYmQLHy3UiprnP2ZivTFU0gkMgYk7ewq5PGxh8vzOMUl6AjM0 9gEkK4TBPFNtdhvQpyWJzU32V0OV5HerEMO35s4cd6lXbHaxU15Al3Fub9adNIBahFYFz3B6 VBqo86RQ5JPr6VNY20jJ8+Co6mnN6sErmhp+8oEHPH51HfyPCflXk9qmtsKPlPHY0txGkow/ PvVq/KJhbOHiGR81PkZsBBwM801P3ajA/GnFxu+Y81cU0h6WJo1DKc1W1KTNkY1QNt5x61Mk gViw7ioJQ5UshwTQ9SSjo21mA2qg7irEt0n2lo0X7vcVDPbyRn93wTyTRb2zpMZD3FZxbS1K Vi3Kcxkjnjms+yVfPJYZ5rRkCKpCEnIqG1g2Nn170patAyzu2qcDII71kbwt6UYdfStZmyGX BBrN+yMLnceM06iskFrmpCw2KFPSq+rXG6MtI3AFSRDYdpOar6hGJYNuM81UtYg0QWs0X9nS bHViTwM807SHdWztAqrb2REg2LgKK1rSJI0O5eveosxW1JJGQyEuQO5rHunilvR5fCqelW7u KSSYMgIA7etLDabn8zoaJO+lilG5X1JMSLtAK9R61ajmRbEFmwfSo7q23qQGIbtVA2c+MM5a lsxW1LlrdLK7Mq5GamDI78kKo5qtZQeXD8oKmopba4Z+H+Vutaq1rgtGRXB36gvlLuXOOKn1 KAxrgLk4qSystj7lzkdat3MMjw7j0rKSfQOW4aa0aWIkeTaR2q1BKshyMNWY1nK0W1M4NXbO Awp17daan5Ao2LwQjkgA05c0gYsqlz8wHBp2/wDd4xznrW2o0JhjIO6nrTsBTxUYdgRzTy3y nPT1pi1uAI60+TZkbAcd6bgMOOe9AU9BS5impDmYqSpB5HWsrVOpTOPrWpxznOaqajbfaEzg bh0NTKLZnLYjs7eBrIyO4DDt61LaSxRK2ACWFUzbytCIiMY61YtrdYY8k5z29KyV+wcuhTv2 Vm5AyOntTbK92SCNiMA0alaSk71JxWH5M6SuxYk9qpMpROt1KZxbM6puUjNZ9q3m2UrsQjY+ 6TUC30stosLnAAos4HuYzEu7Hdqie43ZFjQxhyWJPPA7VuTy+Um4jGR1qrp1qseFVfzq5fIJ IUjccitor3RXIracyHcrZ/GrDOfLw5+YmoIbYRMAuAOuamkYIw43E96IvuIVGAJON1MuMtby ZYAY6GnFeeKfOivCd2ORxVSegWMXRFWW7McXUHqehrYuJolm2soBAxiskW8sdxuhG0e1Pgik e4LS5JHQ1jFtKzQmy88oWNiBz6+lZdhJBd3zAtll7ZrVwuwqVzniqVjZ+ReF0UAN1rSWskgN Fo0XCA4HfmsmdGF78pBAPU1tXaqANoySO1Yps5ZLzzAx2r2qKnQFqbVsoWPd1NU9W+eMrH8j Y61ftf3QCyjcCMgCqmoRu6NsAz2rSewFSKV108xNzk9RUugyExPCPl9c1Tjt7oR7W7HOa07R GhQMF5PfFYQTcwsWAIjISy4UDkVjRsrXzheArdPUVZvJLt3+WPPuPSrFharuLuBnvTmry0Qy lcNuvFCrtUVtxHfaCOVlCdgazdRgO5XiB61DtvJJTE3ygDimtJO5Ni9qbIbYKgUEcVX0WMzB wI/Mwpzj6VObYtb+Wykn1qisdxZl1iVl47HrSn8V7FxVxluAt6YieQTmmn5tWXqqr+tWbG1J u1mnZsEcgUt/blbrzUyQfug1OrY7cqNKfDuC+3gcVImxVBUDHcVkSGedQnIPrWpaIY1VWGcD k+tbwt0E9rkzYLfu/lzUigbQpOSOppr4XkDGaVD8hGc5q7isBbnHOO1OVS0Zc4wOgpU2kHJ2 kDjPemZJG0k+9A4q7AMNvp7Ug5JJ4GOlOKLJghsEU8hBH833h3oKvZWGpxzt69xUhwOWz9ag jdj14HanuxIXGD60miUricsW3MMDpTogSMsenSmyqAQRjnnAqbdE2FORinawmxGOGU44oUgE 8nnpSZKyY3DB4oboB6Uw5AwM5yB65pSVz8pwB6UgCjA604AKxIxz1FJMfK0NAUAsrHBpN3yc etOfYifKPl96AApVgpKnrmguCvuPVU2Fm6gdqbEQTkkgdqSPiZmTPPY0sakj5j06UehLQ9lV h7igcjnn0BpUV3HyryKYZW2lGABHekrolK45MI27A96XO9jtOaaXJAV8BgOvrTY2CscdD1oa uXZW0HKiq2WA5PShizvkFgB2piuJZiNh2jn61YiIkfP3e30pktJaguwxlWximEkE4NPbarEA 0u3eeAKFoF7jVQsu4kAilXlcgcUoIAO7jikVzjCEY96L3HewrhUjwuCT6io14wSCRUsinYQy hWqJQxUAE8elJBJ9hRJICWX5Rnn6VHP842dcnPFSKjFiWGRUUjKsvAJUn8qN9GO+pROnQM7M UGDjIPerdpEsCBY4lC/yqxgbhuYAVGCo3FM4zWTpxjqJ66lWe2hmLLs5PWmwWMKEMUHy1a3Y BAOM0pCgLlgSe2eRT9lFu5Fm9iMxJtyQcHpVKezjJEhXoa0SACMNkVEwZnIYYx6dKtwTHFtb kNsNpIVcgdsdKezY+bnBNSbTFzn71Rvnp2p2SDlugH945pHkYfdOQaft3jacmhIV2ttYDb60 9AIldg/I3AikK728xGK7eQDUjMN6hgSKVkQ8jIWi4LzKslujOXZRzzgVKqRjAQbRT5BjBxge tIFG9WB+XHT1pKCvcd3LQbICw2scgdKUJgbRycdu1OwCpdemaRNoBbdhvapaS1DVDSgKYY1F HGFbAqdWLKTgADvUannqMUWT1FdiEhCSM/SlcKYwzqDkU8x/NyB9aZMwGE25z3qmrgtBoRVU MqgjvillVJMZHHenhlUGNeRTNrZHYUnBDfmCIuCU6KKWLZKhyoUr096SUgHEZIB7UAY4HFFr IaStcaqjf0z6jFCpGrEIuSfanjIJPems3yAqu0ik4phFseFYqy8YHWo2VdoA59qeCSv161Gc 7s0JIT1YsW0MQTx2pGPGCdxBpqhs84PPBFLyrZwM+9UDi0IsXyM4CjFMVQQfepMBWI6596MI FPUEdqE0gTdhAgbC5x/WllLE7QQAKRWL4GBjqKNwUjPejRg23oKT6dcUhOBz2pWBIIyBmmov lkMxOBwadxC5wA/Uk8UjYOS/JFNlCsm7OB9agFyjfuxjjvmhCSbJkIZd2OKAYw/zgAY4OKPM U4wMcfnUUkkMLc/MeuCelTKPMaKSSsSsC0e4qcZx0oZUWQbeeOhojnMwIXp1phQMxbJLelCS RG4oAIII+lMChWznmoreZJJCrHGDjrT+FZiW79aaS6A0P4JIAHPrTdm3pUazwLJtZuKmhdJA xDACi6uNEaqzNjFOkAAI20Hg5jJJ70kshLjAA9fej4im2tGMYjA7VG5ZhwPrQ5w/J4bpTXco hzQnYlpX0ImyXwOFphfGVAz9ac0gKqR+VRzEk8AA0b7i3HxnDdMEVIzYBJPNV4i2CGH5U5yV Qd2zR6A0SyFSisnJPUU7JRO2KgU/KW6GhSWPvUtAlclkIAG09ai25BZMcdc9zSqCyksM0yIs CS33R0FXpYahqPTcRyvNTl2TqwyRUJkwx8s8EcimjLKVIwM9alIJIk284pp4OB1pVH9401vX BwKbVxIjk54xUYTC5PAqb5jwoyaikU+WS3OOgoURtEeXUkhQfSplclAzAbu9Z5mEbk7uvbNT W0qyMEGSScUaIWhc+XFM/hIGT9KZcHyHIPPrVdboB8qfrRoPlLiMccng04rvGwGqwfeeOQaf 5xjYggBSO9AMnC4UHGD0OKUMUzzmooZxIpwePemy3CJE3Ukc0PYEiWN9w54NOBAJAqlBeRvC Dt+bPWrEbqV9TTEPYuGG3AzQGG45zx1px+ZcnAxTIxuHTGO9TcALbsZOBTs54BziopBubZg4 HOaeq7Wzk09x20Hgjt260h+Y4BxSMDnOKZ827oKmQNEhHzAKcDvS7ld8KOlIrIBlj1pgPzd/ rTQJEzptTAOc01Nq84BApo3M2AvFI+MYHWhqwRSMrUVmluCVwqE8HFadkqLb43/N3GKaFRjh hnHapFjG3jioUfeuxbPQcobgLgD0qQAAc8t6VEQ3rjFOVWI3jkjrWvQb1JCSQeBx2qu7ZlyV 5x1pSzFu/NP29jwKSZI3Py+9KD8u0U0gFsDk0qAByTnNNoaQ9VZlznAz3oLkDBpGJMeO+aWQ 7yNuOBjFTa5a0QzcA2cU5XKt8oHJ5pjKQM4qG5mJKhFAxxRaw3sTvIBljyR6VA0xdyxPHaqx ldZMZPvQXJwe1VYizZZWRmztPNOQ5UBjVeIkSYHQ1MCA3HOKVgasiWFSuSM5PWphxhTnBqJQ WYMSQalLDOCePWk9AvoSbiVwQKbxtOQeelRoSVbByR0FCklcsaEhO4u0cZHNTAAIPkGPXFR/ MUJHWlwxj2k0SQ277CoI1IO1T9aCiNuICr+FJtPApWHlnaetPoFrDkCBcY47mkLKOMfLTCzF eO1Ru3yjOevWhAtSwmACc4NKG5ACg565qJOuQakXhhk96LIE2tCRwQQWI2449qTbwW5xQecg DIpY24KkEigdxFB68EdqXACnqaWFeu77vpTjwxI6dqBczsKjAqMDaRSlhyecmk7jnrSEdCaH FFRkOJJG7jpTM56098KFIHXrQwHUAU1Yl3tqRMMcZ4PemYLt5YHPapJHOzBHGagGTINp5Pek y7aEVwHCMjtlhWY9uZDggj1rXdCGI4Le9O8ndGMAbu9TYi/Q5+5sZySsTgAD0q/oPnwjDAjH H1q+IRtzipIEUN0zQ4XYNstbwzhgAv0pxfc/zEkDqaYgTDbVOaeMMACNtWtBWuKXVTkdPens T8u5R0yCKjChmG7OAamIAPHK+lGhUlYGJC/KufU1GSCQCCAKl8zZlVGB6UqkyE/Lmhii7LUj 5EZdcHPGKiVQG3dacdisRtPFOMjG2KbFHPBpC3Y1Qck96XPJPQ0+QLsQqOf4qTbvYMTgDoKd h3voPRwVPPPQ00KG+RTjNOwNnGBSKBuyaWjE00SbQhCluRQSiElm4PenBtzbsA4GDTcHaWZM jtzTsPVsSSOPGQQfoKRWTO0E/SniRm+dlA9hSooboACe9KyQtbioQo2jAz1prblbaq++ak2I CDjp1pMq/bjtQrbjWgi8AErkZpQqh92OtOAUvhmICjgUnygdM0cqKlZ6jt5WTjIQ9B700Jyx Y5J6UhZgFTbnmnbyrbWTp3pcpHXQaBtX5lycUpCuFYLwPWhuXLHnNKCRjA61VtBuwqqn39oy aVMRjAOQfXtTpBtGD07UyMoWwcEDtSSsJCtuDYY5I70u5N4CA4xz9acQA2QPl9KC6k5ChR6U 0Ny6CSDcBnt0o3nO4DJqRVJJGR06mkG0DOM8+vWmJMeHUqVIwccYphyRtK4x1JpCcszbcA9B 6U/crId+QT0pC1Qi4A5Ax2pw2FMAfMaZwVHHTvT43UNzwKGN6Ee3DfMDgU75T9wfMKkZQxKh uPc0yJxHmM4o6APBDoGx9RScY4NI6chiMenvQDkcE578VKTKXkPYL5QcN+FNyAgK5JIpUwx+ UY+tMOfung57VQ+VsespdBkDijd8u05z1pE+VgcDFSbcMSKHoJvohi8DcDg09m3JwMHHJqMg Ej0z1p5Uq/DcGkKSaCJ2V+p6c0rIS2SRg0hGw4xk1JCAck8AdaGhbkLqAeOT2qSNBuG459cU jqCnmDGB+dOT5kGOPWn0KUrDUxsZkI4NKxIAxyT2qKYiNMqpYk4wKEyPmPWhahzWHsSvJ5Ge 1SM2YwVyD3pUIC54OarRmR52UvhRQrJCbdtCxtJAGakIX+FSB6Go9wUYxn3pC744GaLFRb6j pzvGGY5HU0yMgDgnFSyLxx19aiUNnbkUNXBPlDDsQyOfcZpCE56gntSjbuKrnOKjZgjHeeKl g11KuoTNBhs5A60W1wZVDAnBqrq90GtnTZlB1OOtO0coYFdlKoOxrL2l5WCMbo01Qud5JyOa SSMFvN7ngmqM+peVM6xZwfbtTbTUfMPlMCB7itHNX1Go6M0YyFUqfumkDp5xAYkdBTlCmHhs t1xWM7XEeobmVvJzjgU3KKFCL6mnOCH2McfypWTJwh3U98SgHGQKaco21eCc4FCZfLdBsZVy CM1Q1CdoflTv1xV2VfLIV3yT1rCu2H25lZ2PpUzk0jJqw5p7wyrJK3yVo+fmz8wAYHXmmXlz BNYiFYwNo+9WSZQkBUsStZKq47itcsPNNcKJBMQg5wO9T2N7vkMRB/pSaZcRWkeTGr7lxtIq o641FSrgRnnA7UOo1qWrIv31w0ERAJH0qHTLh7gk7Tx1qbVbWCS1MiTnKrnbjrVLw+SIyQSO eaam+dJk2vdl2/u/IhEYcDd2NUBFdlPPEx2DqKn1xFkj8xlBC96iF2r2SwBSMDk05T7hyu1y 7YXDyoAzZHrVojn1rM0hNoIVuM961ccAYwa1g7q4NajCo6j8ac2QgCkk+9GCODyaNv8AePB7 02ymuYafmYEcY9Kc8akgjPTmmKuGLbsccU2RmZgQe/NNEuL6E1wVjK5GBgde9IpUjp+FMdhI 4D5ZgPl9qGBDAN264pOVh8jQOMd8A00sqvtZhWfqF2yz+WgO3+VVWeRAJJHBGeMVPtIoDaWN pG2RNxmmnBm8tmGRxmqcdyTB8uQSOtUt0s0jDeQQePel7RFPexskAOVBzjvSru5IANZlu0iS eW3fvitDKlAOh7801JMU9CJbiJ3MUZy4PNPRXDKDyKqWtksV48qZy3WtErhMpnPeiMm0QmRy BunGaQDeCC3A55p0fQbu/emtsUMT0NUtAZm6jMxm8iNse9RTWlxDCJN2Cw6k1HL5X20t1b0q c3O+BkcnAzgGueUrvca0Yq3TJAjOQccZqGO3kunaTcSzflVOKM+S43kxseAe1W7aYwQIoJyP QUlUctGFri2rS2s7RMWJzjNWNWuCke5NwPtVS6meW5Rg2HJ6etX51D2pDp82ODinTle4rGbp kzSzHKH6nvV7VzJFbF4uhHX0qppBKTvhd2PWrOo5Nq/IxjpVJuxTWpX0+286FnlkJIGQRUen OwndPmODmktJZo7dlj6HqaNPXbOX3EseoNTD4gW5rwneG2Nj1BqJgc4p8fQgAAmkbHJJxW+w 35kbAP8AePSopmBbA9KlJVsljj6VBKV+8BiqTJsRSAlgQ+MdRTCMgupz7UokUFmKgkjGaLcL nlsCgfQWFjnJGPrSyZB5HXpQvyn1qvfSER5GT9Khuwrj/tBUtuYDFPhKsxZTnj1rJi3Trhsj PrVjT90UhU5KikpXHFaGi8oQDDdetRecu/KvkkVSv2Jl5yo7YqF1eNA8fzsT0pc403HQ11kT tzmo72ZLYLvfIJ4xTbYkR5ZRkim3EaTIvmDODxVt6XRHXUmiYORjJ4qZiqwnMgAHUVWhGw5U 9qWWPfGxpptjla44seGUjmobiQxW78fe7+lSKUUAYqpqrlYNuaUnYLMp26LOck59zULtJb3I 2NwTRE7pGCFzn0pJ8lwSDWd0ncGixcz73WMsSWHJ9KPs7LEGU9+vrVHcUusE5GOKsLNK48pW +Wpvd3DUu6bOXmKAgEdc1T1iWZGYkk44qOw3rcsGOPQ1c1RU+zoV5c9QapSdiXcdp/z26E55 HOKiv3KzqiNweMVPpaP8qouSe1V9TXbPuGFccAGrv7o9SaS3K2XncbT6VJppYxqBzmqjGU2w VhhD1FWtMRfLAQ4A9aiLu9C42tqaWWQbWUEmkZlVfvUoBEe9Dkn1HSowQCdqhjjkVcbrcGlY eCGGaSPcExu6mkRSY84Ix2pf4D0ptMgViVX5ieaTKlPekbcYhtYE+9DR7EDsR05o5SrggXOD 0708sCNoPyjoKYQdoPY0isN+O/0pobu9hWEgG+NuOhpgWRk/mac+S+egpU3Fgq8UXJtYjSN9 +QeB1qXcqtk5IxQWAJUcZoO1MBcE45zUt6lqzHxkE55IpJSFfCE7fSiNlyT0FJtYtlaaJcUm Iu7GAwyakjQ9HbOOpo8pWTOcEU1eOATmhsagmOUxlSSNpzwT3pDjt19aGBk+UgYFIxCqq0Ng 42Ac9c5peUO786CcdBUXnDLBjwaBtXQ93BQ81TZlLHNLIwJ4PB6VXlyGxuFJ3HHTcQqScBif rU0aDHXAqOIEmp0JA2KMg98VWxK7jkVo2OSCCPlNPWIkg5pI41VSBk1MpKKDgHPb0obY3qOj GzIJLZ6e1MkyR1wKXGW4J4FOfAXrx2FK99GEY6BEDyQwp+AO3FRRIevqalI4IDYo2C1tR0ak Dr1pyr8/PBpqEjvxUrBQhYnntQ0LmQEc+voaa5UcscnPU00FxwTxSOAT7ChXQugrAkFgcD0p iqMnIzTwMIcmmjqSeMU22NOw5BtcYGfapcbiWyB7VExOQykVIiowyTzQ1qVZMVARwrDntT1y AR0pIQik71OOxoL/ADYqWRdbCrz2xQuN+1s4oVw5A6YoICt2OKoNB+3cTjIA70wino5IbkAY 6UijK5zyKLFJIBkEIMEdqc25ZBlRTFI34zzTmYlgGPBoE0RXBYjO3J9KRVBXdwtTS9QuQeeD io3UhiKV76CVxgB3hsZz3pxABOeTT41yMA9+BSkAPtcc09gaGwhgCXAB7U0YUMeSW7Cpu3PT tRHt3daoVxYmAVVHB96UACT5myppjEhz0+tOYj5eBgd6RcbCuct8vQdqfvJIwAKTzAij5OD7 UvykjB4pWG2rajgQBk0sY2SFlYjd1FIFAI5wDSk4OMZHTNNq4m00LLGpIYDnFRSKQME8VKrc HJz6UokAVkZAc96ViI6EaFF2huSelOwQxDdKUYxlVyR39KXJBzjNA7K43cpOAfmpQNz4HUdq WFI8ux9OKQgjnOM96LEvclChFLZ5PWhWDLk8CowflAU7gO9PJBVRjmlYuMRMnOFxjNSY2djU bKUYc5z19qk3MwALVQ3ZaIQq7A7fu0pwAvbHpSlyO3X0pF3EHcMc8e9GhG24rMpYsw4PSlBK nGM8Um7cmDjA6VJGMMARxUsqya0Ggbx0ANLgkdyacrJGzbgW+lNZ+AkYwaVgWm4hjbeAB26U p+U4bPHQUp/8e70nU5Y/jVIndjgsjYI/WmugDbguDSybgwKMAPXFG7cQOvqaZdkokgkWReBg jrSbUPLZIpTGpJUtgAZpCgwMniixLiOG1mI6ccUu0BP6U3IVsA5/ClXlsMaCbWYR/Kj7sY7U gXIBOce1PkCsgRumacAqjaD0HAouXfQbgAkZ3DtSOoC56n2pcfNmpAEABzz3FLqTJ32I4yxB Q4A96WVRjcAOtIQ3mMQd4PTinZK46Enr7U2gWwjJ+7HP4U1ASnpUynJG7GO9EqgrlTwKSKUu gwAjgcUbCW3HGBQC3XjB4qT5VC4Jam2kCVwKrjJIzQDxgEgEc0kmN2F6Uv3QOMg/pU7gxAo3 DHTsKdtOSOlISm/rz2oYhFLufl9aES276iscHs2KQKzJk8etHIAIHBoBwCuevWqRSl5AR8oR entTo+OOc+tNVcnaM8UrAp3waGW1ceEXk9DUQdXJVVxjqaez5xnAFL85T92FGfWghJIamASM fjTyoxuwKZ8wbYcbgOtKrHHIwKb2CNrhCC2cjGKcCPurnHrTE3bjscEGghsfIQB6UrMuVkrk j/L17+naq4LF8k81M6nBweahhYqcE/NUvRkya6En3fm/lWdrE4htTIRz3xV+R8nAGR3NUtUV WhKD0yc0pbEN6WM3Zu01pXlHzdBnmr2ixq9ph23KBwaqYjmsgGJJB5HtVrSHUWrLHwnOawhb mG5WjYqXKG3ui5G5T+lWYFSdVcYBz0qN7xfOaJkyOxNR2cq/bCQCB04qpJX1HGTNhAEXa47c Gmb1ZgnGSe9PWVcEEErWQsMo1NpXkfyz90DtTsXFp7muQVO1Wx9KYwbzw5OcU2MZbINSkDBC itkhNpuyEdC53Lj8a5+Rd2otH/F61uqGbco4wOaytSthGy3DdB0xWdUzaEns5YIXLHI74PFU GjURc5GTzVo3D3lsUXcpPr3qzFYhrQkkZHBU9awktBrREcVl5yxuDk46CqYRBqbJkgjjGamt bya1naFUPA4NSWMHm3f2idec5JHekoNq4ky0yYs2x0HrVXSxuLK2FI6YqTWLx0tzHFGTzwBV LSZZku381d0ZHANayVpIcdCxrA2tGu4lD1FLNFF9gyvysR1pdVjlYCQRjHUVFNeyyWyQmH7v TgUmr3uDaHaECI/KZtx7mtTd25qhpMRQNI6kZ7VeT5jnoe1XBOwN3QFiJFDKSM/lT5FLN+75 XPOe1MJYEqT9aCzY2g/LWyQXTWgspO4DHAHaowGaXAANOkZnjKDIIo27OTnd2xQSpNDjktyc EUkG9g24Dk8E9qRc7tzEkmgc/e4/GhpMcm2YeoYOqCMSZJ4wKsy6a2R5ki7McLTNQikFyJoI t208+tRzSXUrYOQD09RXPKKuJF+2ijWLkrjpzVK4hkjfzUOEB7d6sLDMtttY8gdaqp9oRCkv z8/LiiaVtBptMuWE0cvMigex61ZZgAWUDFZWl2TC5eeRzz2PatQj5SOoxgVUNglqyAXivLsT Ab0qwJpPN7AYwazobMJe+cwOQcjmtFzv3E8E1UWVZA5IXkE1HK4wpxjjvTgWChWbIFNZh5m0 YPrTUWS5XZhzokWo+dhstge1aNxahIBJtBD9xRfRA8qvzDnFVQbh/wB224J1xmsHCzE3cryB liKoucc1b01YpLYPKBn+7VmK0Aizzz0qi9rPBIx3Hk9KlU3Fj06CXm37apjTj1rQdna2wccL Ve0hO/Mh7U+8d1jCIpIJ5NVCLVwcrlDRw0d3IfM4J59qta0+LV8DIHcVRjgnimMiAkMe9akq NJZeQ6jDdeK0i/dsgTsytpojayck444qlZhvtZbPQ1NBBLGChyADwKfbW7rOWJ+XsKhaMq3U uByecc0EkmhiC3pRkKTzW0dSbkEjKHIFRORjJPFSSjnOABVdwSParQJjGddvyYcdqAxI3Hj2 oUiMbdoxQcMMkYoYbksbBlyePQU0kISZACpqNy2VKt0pJkM44ZgcVLsNaFO5B+9Ewx6VPpUy zDLDBWofJlyeMgVPYwBPnAwO4rNE3aFuyk7HccY9KpxyNCxDDchqe9iZpS0fC+lVxG7H5hxS kr7FKRfhlBjBPI7VX1K78ggEE7j2qSCNimCMAVHcRbmIbB54NadBczuTQShlBX0qxG+VweKp W+6I7Tg1MGLMDnB9apLQdiZgpbcByKr6mpe2BAFThthIyGNQsrPKdwO2pabCb7FGwHysgILA c1BcB2kVVPfmpZrbZI3k5XPvTreEgYY89yaza6CuUpU23A3qTjvVkPBtYnIOOMetS3sJkXbn gVQNqzfISVA5z60KNtxXJtN8ySRmI4U8ZqxrpzErHCvjgCmW2Uj28/WormKSbCHJPrVKNoju XNHlZUTJ2kVU1R8X4faWU8bjT7aKSNgSTgDFTXUQcZxTWqBMSbL2gYHpTNKdm+ZlIANMMUgw AxxjkVZtkKx88AUoqzF0NLzzGQ2Bz6U3JwTGBnHJqs0nyrkg+lPjdgfl/GtLFJ6E8bSFcE4J 70ErkgduvvTckAtux6CkilXzcsvJoK0sBbDbsbVp7sGOAMjFJJK3mEbQU7e1NR8DtQhOSJS7 Ko2qKY2d27PJpMkY9Ka4JY7c0McZoedzgbxwvQijflc96iQsF6ke1SR569KEtCXJMjkfG0kH rUkYEkmDx70OAW4BJHWo1bB4OKVrkp6kqYWVl/hHf1qRC3UGo8AsDjpStIVYEAnPU07Ftkis Bk8mlPK5UgVGjbiRjGKc2wYIbn0pMFNLYRGDZAGcdaZK42qCeh4octuLAYpoQNjOSaEg57oV pQuVP3jVSWXDY9anmjIOW6+tVpMH0zT6g3oNYjfgZPFMjX5jzj0zSKzAlcdalhTaRvG70oJv fcliXAGevc1cRlj5ULzUAXcemKmMTxFQVG0980mUr3sgGRnA60J8wA5z3qReQQKTYB8y5FJD vZ6i7SVC+npQPm/CowWDblbHrUsZyd2M0Icn2HAhRyPxoYoRu5GO1NkGHCk5+lLksCTgUWux L4R4wAG7mmqytnINABLZ6jFPVCRx0qpbkR31EHIxUkfUKq89/eolG3jvUsjnAxgMKTuW5dBk pLHBGMGkXLAjaCKcchQQRuPWlVW8sbnAYntVLQS2FhUHhsYFCkFiMY54FM2lSVLE45zTwPk3 UrBfoOYqQQTz6UAkgE9qYo3nng9aOvBp2JdkSsc4Jx0pC6Ahc/Smn74Ap3AOGouO1xcZA9Kc gGeTTSxD4HSk6NliT9KLlKN9x7KjuD2HTFPZcc+tRqV6qML70M5yFPIpJBJ9BGGWX0706Uhe nIpScAAde9Em0sF7YpsFqOgJ3jHX+VKxBkPmDJzTMHZ8vb0ojJJ3MTt9KLXJitdRB8xIz0NS RqoByelNG4ucDApcnfggHFBStcNjHnGBT4wgU560HIAViQaYWcKUGNoP50bEdSUE4BPQcU9z GiBlGT6VVjZ3ZlUEhetPQleTzmhjVk7slVd2XJ5PSkL9ulI8xOAMYoVv3eGOfSi4pJ3uKAQ+ Ac+9K7naUXGaWFto+XpSEHzQdhye9MpyVrD1L4AA69feo5FIU7jxT5W2j5cg0LzHlsk0tiEw jztAbp2p5G4bcVE+7CnNPiZk5PNJq5ba6BjaQApFPyVPTmlaTec429qaWyevNHQlO7Fzld3N Kp3phRj1NDMeijA7ipNw4I+XjH1pobbQi4C8k8UoyAATmlGB978Kjcs7AkY9BQS3cfxk/KKc CScmkXOMdCeM03G35d2feixSlZaEvROmM02LK5GaTc2wLnIFIu0DJ4zRYm9x4Ib5gu0dMUuA rbc8e9DSDaQATjvTN6/K23PsaBod94lAM46U7IC7cdKQuA+V+U45pB19aLD5hVJ5JIwTT8Bl AQ4xULuFGCKlgKEkMTjFOwOVxw5fhQAadIPm47cfWmt8oBHJpRvX5uoPUVNidQZiFC5GMc03 JDYGSfWkYjOSPlp5k3MpziixfNbQdllQhsBiOM1GglKgFsnPJqS4ZpJBu529KbuYDcQQKEhN okxtJwSKcEJG4ng+lQ7nwCpxmpXk2IoHOetDE3fYVkO3KkCkJBj2t1FOyQoJzSuqGMEE7qmz vcd4pEeVAO4ClV+g7UsQL5JXOKSQYAXHy+1WxxXUlVVd8AgD3qPcySspbIBpgBIBjGMHkmnF QWDE5PqKlRKVTuOkYuBJs5+lOJBQI6hlPUU1SqpjLbgaeHLpg4xTsTKSbDB4OOOwpoHPGBn1 psjE4CseOtOJVuB1pWaKdrC8qwOQaCwdSGXvxSqMNj26Ui5KlimB0wabWgc91YF2BNjAEnua cTtUAdBUckO4AsCMdKlU5jCmkkF0nYjydwOfrTi6kle9I20qAucjrS7cEU0iG10FiUIN2Mj0 pfvDcq7RnpTd4QnOQKSR84ALAe1KSb2CWqHTSMRyOnp3qp87PkDp7VbmKeWCBUGU25DEN6UX TEpME3Ou1ePWmMpYOuBg9zTiQB8hwT1pASoIPND7DbbZAtooUEY20sVqqtwdo9BVnB2DKlcU KcOSuPxpKnEHtYqTWaO2Soz9KIrWOJ/lUA9xV0ruxgYNMlwRkD5h39al04oIyZDtOeOBnpUq xqGI659e1KWGARxxyKZv4LbPpVeSBuwAEcAYGaeAUQbjzTQ2famy72cNu+UcYqtRx12Ff7xx np+dQbBIdrjjuKs7S43BgDR+7Cfd+b1z1oaTWpD3ITBFFuAUFQODimxAOnmdO31qRlJXOeDS IAFxnmoUEik0QvGjud0Yx606NQuBjiplUCLcee1QsCE+Vs5PTNEYJDZFJAjuST07U94IjDkI A3tTtmFyMg0xWbcUI+XHWnKF2SIijythJJpksUEZHcnt6GpwMJle1NcLks6hientT5U0VaLE iDdcDbSyA43LxTUJJ2jtzSA4OGIJoignFoX7w5PNShT5Q4/GogMHduBB7elPLHbjqKpkrQap KZ3c5oAUEnJJPehHOCvagAFCdwXFJCsGDuGM4FHVueoprN8owQc09124yy8jtVCTsxGGc8gY HQd6r+WFbL1ZAGScjimNtZ+Bx6VnKOpV7kbgeWrDPTmkyrbcL8w7091LA7VOB2pI2bJTjmm4 popWsJhd2WpsrOBtjP0p8YBZgW5ApEBON/AzwRSWhL13AgxqA5DP3xTNx34AqRtoZhu3AnjN NZHxwVXB6+tVdCV+gMVdwTxUYwJskZ5p0iAtuHpTsKSM9aFoNWtqMIVpSrHaMZoSMMw4/Cms y9x+NCuCcK1K3UHFpXQ52KkoMgA01jvkDPknGKRgGzg4x+tNduMkjA7VVhWJCIifl4I600lW wAKIpFMRAIJpCqqvGd1SkFmx204AIBGaaSHkO9tuBwBQCQOCaZIuGyDkmmrAlYVtpG52yc4z QyxgFt3ApvBOOOKQjI7EelLl1KbsiKY52sDgVEzN/AN3r7U+coSQxxtHaqyzdlOPWmwbVh8z KVHPNRbWChiQQT0ok+6D/OhQNoI4J60LYhEMhIbgcelISwTPHNTFQ2QvPvUDD+A8juaaKSuL wR60oJReTigIoBUHNNwW4P3R3pWBki5IyKcQOMd6jUfNs3YNPxt460WQncUDbkqNxpuwMuSo BHPFKXVOlAKuBh8HPNDQJXBmXbtUHNV5RnHzcZp7hY5CVkyT2NRthj6EUIrlsIr+W5XbuOOt CYVCSM+lBAXGTjNDFS2B90dqaYN6gXIK9z3qdWdUO05BHNVkIEh4/CpXk2qccA0m7CbuRuc0 p5QU1JY5TtVhge9OkQ5zuoExhHy7W/OowuBg81KBjG85NLKq4Yhhmi1x2KqkKdop6FSCGzuq ELtc5J69aC6hyByfWgdi7tLIASOOgqNs7cDoDTFb5QSeaVWJPWi1hepIuNnSnrjBDZIqLIB4 NKWx8pOaC3ZaIepAOdox2zU2Nqh/XtVdmRI8uCSelO8w7htXPFDuZvRkpL8PgFTxUiIsbeYx DZ6j0qru55OCT61JvKqAw5zT6FRbRMQSpbPU8UiqNu4YBpFY5wuMUmzewBoQWdhylSeSRjpS hiWwh+tRqwVtvNHnJDu9DSkJIecmQYxSkswZVAyO9VjdKFGSMHoafHOpHXihbC1JFLIMhs+t MPJJHFOzFHCSSQxPFRW0ySFgR0oHdliL5sKcinhwuVJBqCUhQDnimwyCRzsA4o3EyxuIUnIx mkQryzDIqGYnYdvU9qhaRowu8Yp20CxbBZo9/BGaam4c44qKK4TcVAwvbJqTAkgyrncOtSuw 2htxJIx2M3Sqsi4ZQ3XtUk8gUnJyai3K5+9k0bCvcaQWY4OOasxYxzUHCcZFStOhxhQCBg+9 K47WLuAsS4YZ9adkMq5YnHrVaJhIeW+UVJ5wibAzx603caRP0GR1oaQlMYxTDLG6Kc5z6Glk KBMZyDUoTaYsY+XjBpsZbewBwuabHIpj2r1FKicFmPWqQ7JljCYDdaTeJMBlxjtSQoirtycn 1NDoQ3y4OO9C2BRYobJIHApy7VyAc+9DEAggcNUewrOcuNp6CjVkj/vcdPU0+RkGNvSmswxk Y4qNjkjIwpodylqyRm9KQSAjNRtgSYU5FKVA7Y5oQtUyaKYHcMBiaU5BCH8qqyEI3ytyadG+ X6kse9LUqyvqT4Ktx60mWZyAOlOVcg+uaGVlPBwe/vRfUUlroL5g2gkcipEYvGCyjrxUO5S3 zdfSnqwzjNUrMkkde/FCkYz+lRjKo2Fz70o5wenrTuVZtDwV4Xv1FLtUHLHj2pmAX3AYxSnd gNtJBPNALzHKhVsFs55FSKp5Iwcdc0xChJZsClUHcSvIpXBO7FZsNlMr7UsYRwQTgilA4wOn vRhUPAye9C1HL3Q3EDFOQIBk9TSnDfexxTNu7kfhRYndjpWLAdOKailBuyG+tINxOe/pStvy QwGfSmgauNzIrfJgZ61NJGEA3MDkZ4oUjHzfePYUigODhckHrQncWxCVbqCAKFLZyBxUyozr 2GKArKMKm4tRYvmurDQV3gDgdxUjueBngZxTdu1gGADd6lbbnCgYouQNj5+Ynr6ilOSpHSh9 uzBPOaU8uNzHBHGKV7saQqKu1dwIwKCQ52DIPr7UKGI2s2fQ0rBVI5zRcVmGBs68imrhsHHF O79aOMUgQrt3pEyw4pjHK7T0JqRhtQFBnHWqWgmOjWTPzHKin8nrSKeMMcZHakJAAXflqV7j SuBbB9hUgEewsvJPSmMgxgdD1pqDaNo4Ap7ASRttkAIyMUjYL5A4qQHGIzwO5FMjXfKypyB1 oQNDsHG7AwaaUDcY6d6I2LZGcAdqWQAjA496E+4K9gjBHYEU5skkldvoKS3QmXaWxjnNSSvv b6cUxIjwufmFOVtwPG0+wpCoC8tzQ2WjCq20jqaCrOw4D5cZ5FBZg20d+/amL05PSrCKgxk8 U7BpYYcFdvB98UKyrGVKj1FSny3ysYGfWo3RQgAyT3qRNCwhChbksTSMSx2t+VKkeGA4FOYK X2917igBdqqAFNG0lyEO7HWkzlsA8U4KB9w7T3x3pglcVnO3aetIhAABOfU01ehyvOevrQyM FDDAFGwWJiGY/K+FA/Oq+VBOX78Zp5bywAMEHuKQLGeGUHnrSQ0lsx4YhuQOlNGS3GOtIRtf n5gTxUuF3FRgEdjRccly7DWXnAPNPyoAXOTRxj7oyOppI3XcxkXgdDS3JGlTvyOATQEVZioJ zTh8xBX8KU9dx6mm0O9w6gpjk0hyAFZiNvvS85z0ppUu3U+/vQ0FiWWRpIlVckg/pTRnB5xz TVPJ2t060uM5bK49KGi48q3HEI6jsRTgDtH9aj79jinF/T9aLaEaCSKWwODjtSHdjhRT1bPP ekdmPQUJlStYqSu6ucnjtiq8k3z5zzUlwXLkDIqs8e44wSeopE25iOa8aOZRn5j0p1zfyoqS RgMw61Dc229CnPPQ1UlSTywAQuDjPrSk2lcqUNNC8dUuZsyuMEDmr1jcpPCGC81lwsiWsmfm O3ipdNaUQiRl2+gzWMKzkTZmv84JJGB2NIigyfM2AazW1Fi+M5I5waWC/eebDpg56CtedPQN jQmUdB83071GS6qpKkZ4AqG9vI4WVWJDngAVTbUnDAvu9MmhTS0HdM0UY7ipxmnOSyjA6dar rNEsZlc4qmNQYlmjBAx6U3JLUFdPQ0/MyMHI9MUmemTzVLT7kXHzA8jrReXirJiNTk9KfOrX E3qaEo2EA5wRxUbkg4wfY1mjUH3jzzkDpVu7uES3V1Ykn9KFJMknJxggn3FJGwVi+3I9D2rK F5OfmRcqOtWba4WXliQvel7SI7M0Bznpz0qOWQNhNuMdqybm/Zp2W3VsIeKS3vpml2zRFSe+ Kj2qGkaXIPU4NI0igkKCTnmlDAKWHPGcVGp3MX24yea0TCKuyZG2kuF5IqpqLskJeNMsKtcH gA1Q1jzYoRNGMr3pSemoOWu4/TnfysyZJxVkSsPlUA57+lQafITAcKMN1z2qG5uXtC0gGVx6 VMZWBst5Jc4/nUuUKjHPrWNcXDpAs6nC5yfpWjZzedBuUD5qfNF7A9SHVPM2ARfKRz9aktd7 RKWB6ciqusTTQxhioYA1a0w+Zbb3JUEZxUxd5BYdcymKNjtHNQ2Uu5d7nr0wah1bc6FY8gVV 0mGRIwJGLMOhoc7SsJGykvJXcQTS7dnBJLU2NVXGeWIp4JOfM5arb7DuN6D371FLMAmVzt96 ldkABziqmqPEIThCMDk0tUrha5Wikke6JZjt7AVeBwSCxKkd6paYVaLfjIqzfFfs+9G2t3rK nfdl2SQ/zMDYOlSJw4JxWPDcG4QhA2U68VJaXDb9rAg/zrVVFexnY0JViaGQtuBPSsqz3RTH 5yy+h7VoXUjSxhE+UAelZ9iWe6ZSBnPWpm9Soy01NNPmGR0qlrPyRMwkwfarl3L9khJDAgda xb2V5YGlIyp6Gqm7REr3LmjvlFY5zjOTWhMSo3/ezWbpWfs4GQBjrV+bmAhM7iOvtSi7rQpu wyOZXJVetAGDnkk1VsrUwklmLEnJrQZcDOCARkZqoy7iTIDhck0nAIYE89qkZ9qldgbP6U1h wvHNUKRQ1OVlQ+WAD71l6Y/nyFDJhgcHNbV9bM0DPtyAPSsnS440lfgEE/lWMr3EjS8pc4ft 0pFQqO2af24J9s04fMgUDLVomFiALtzk9O9V5I8ruBIq28RIKsRx2qOVAU6EY9Kb1BOxXi+V cH8aJNoBGTinHIGQvJ65qK8kBh2BcOvelcGwEqg8/n6VYhKuMZ4xWSgkYYHXFT2EsyKfNUZH ApcwXJLuZYlORkiorGVWfcx5pmpr5kZKjFVtPikVtxOfak5vmsWkmar7WlDYps8kauBkbhTT jyxk4xWdMV83dnmqcrEGoJFdsuOMVE4URGXPy5wfUVXtpS3zEVBds0km3oM8ihtWDUuQyxhc oQeetNuCxUknOaotC0C5TpnJGKtMzNbg9vSle4LQg091WV02Hg/nWgX544z2rJWQKxYcVZgZ 2O/Jz61MZWYMt+aCxXIBFQ+bGJNocZ96pX7GGUFTknrUEwPyvjJ9apysCZozESA8kHNVxIrP 1xjjmlicmM9MjrVS8UiIvnGfSqbsFy8XwflO7PpUgbYQWPBrL05yYuSTnpT7iVxIEBoTBs1Q 8f8AC/4UMUYcNislmaJcg9e9XY94i3YyCPvYpXQJliScY2uc7elJHKGbhqzJJcv8wJI6UQTN 52xhjNJTA2Bt6+1L5yE7c81XD5QKe1VzC7PlW5zTcuwJmtEd4JU9PWmmbtnFVoWZbdkyufpU CF5H2jPpzQpdwbNISBjwcetR3cYcAZ+WoFjeN8E8DtVoMrfeHAFD94LlRrcJASmCvp6VHZGR yQDyOoqa7lULhRgegptpE3mGVWx3qHGz0EJqJk2rGsg3fTpSWuVxvJI9qh1Jm+0Bk5Y9as2x zgkc4pPWQ9Sebb5LHJ9qoWMhWQkSHHpV6Y4U/WsxVk858Y9RTlowTNUOD8xaqNzcE3SKcsp4 otJju2v16GnXEGyRXIyDyMdqJu60C+lhb+38oDEhIIyCO1SwOUtC/mfMBjmqd9LKbcKp5z3p 21X08qxII6mphuF9BYQ8xc5HHJqIHyZMkE7qaGMMYK8jpTZpGlKluBSvfVjWhO8u6NgCQakE LFNwcniqi8SbdvarySsqbR0ND94B9lKmWEgbaB29aUM93IArEYOKrISImHepLSUxjcOG70+b Swrk1wDazfMxCirluwmhDE5XtWbfzecAz84PSr2myHaAUHTH0ohLWwIrSN5F0zByoPatG2ZZ YiHYDHOTVDUoyHG4Dr1NT2aMQVxuqovWw7WVy2JI8Akn0FOjQqrEueaibAUYHTtSq7M24jt0 q5Nou9tCzgbQRkmkcLt3MfmqATbnCqcKakIYk5INNdzMf8pX3pmdvHJFNIYAHsaUhsjGMGh3 Yth5UKcgnmkIDnDHAFLyR3oRM7s8jtQmkO7GtFxgHOO9Cx7TkVIwKqMA/lRyoB4ye1BTTtcX t3zSkDK5JzQh3D5hijd82SRn1pNCT1HkKWJK8nvTShVhnk07IYHn5vSj5gd2efSqQmOABbIf AHUUuBk7e9NbHU9T1pYthUncc9qGrlxdtxw+YdeaFYhev4UMowDnJxS7SB+FJEylcI1yM54q QlcfKcVEGIXjinRjcMkU7CFdjlQBgDvTkwc7s+3vSEgLtIyDS7VO3nGKAuGMHJ6kUvzYypxj rSMBvyc+1KeSOo9aCrCqrOcinfKAS5JccChW2nAYkVG2X4GRQTu9B4Ydxz60wOQdw4HelUkN ng8YxQ2CpPc9KEinYk+UrhXIyOc0gZtwUFuO9MCsuMqTTiCFDDAyaZKXQdIFLb8/N796AAS2 CR7U1WUr9xsg9TTiBt4PU9aAasNbJHpUkLMvGee2aRk3EAEbRT3zhRxx39qB82lhT83c5pGO xvmGc0hcE+lLGQQSRgDpmpJWgmecZOaPxIpABvz2pxdCC4B2jpVWHYUISnPWgN1UA06NmYbs cmgEEmMg5NISGlgQAx59Ke4Xerg4J7UGPYoO08e1DquASenNGiAceh+bJp3OzPP1qJFDrnIA pyPKH27cx7evvTCzTEQMGJySfU1KzE8oNueuKaH2nihWU8DqaQ73FXtnNJIWI+X1oVTvOOlK pHPGMdKW5TVhCcKNzUq5Q7hlsn8qDiQDC8570NuyFzjb1FNMlxH5JPODR8pJLE+2KABtJBx7 UKVPByKFcV2PjUMCWyOOKGbKqG6Z6gUiybRjH50B+CAKLsvk0HqjCQ+Uc5FSDoAR9aiUnbx1 pY920qOtJmTuS/LuJAOB1zTZNqNlM4IzijICDOSR+tNbmZXk4GOgplocvyjJz6mlRC6sd+Pa iJ1fco4X3pke4sdrDbnGKE2Gz0JNpWNRvJUH0pcLv2kE8ce1MYt0BXaKcQw7gUPUQxCpYoMj HU04DmlJGOQPw70xEVsF3KUkyrW3JMDHWo1GZC/LYp5VtxA4I/WkbG3CuAT1pomV0OJYsAN2 3vUkeCCoAA9fWmqwUYQ7uPSoyOcklcUXFuh4k2vheCKeuX5JwetMT5n+YBRT5QcHZjpQ5WGh HxtxgnNIg2seuO1BBwBnOKkYLgYbJPai5orW1GDZk7cgnrSELgKEPHf1pZT1z8p9qRSSo3ce lK7E4pjg20YHGeKaq7c5PNKRyc8+lKOMkjIp3E4j49hyCSGpyqSuc81CM/wjPoKeGfb6e1Ai rMvQnjB/Oo1QlsDAz61YlXdg0yEHzDxkjuai+pbVtCKaAPKq5wB6GqF/biJX2kEitVkCHrkt zj0qjqbRopOGJPAxRPYTlZWKGl2glhDM4+Y8qT0NbNmsMBYzqWAU4UetUtHlgKkZyw9ulaAI dHZmG4Dj3rCjFW1E22YKENqzJJjyiCQB1FWo4HhnFwmMA8A1TYxJqRJb534rfjSLySGzuxxV xSeo+XS5hXzNJfr5pG8nINWNakX7JHG0QVgOSO9R6iqrdLMyljnAx2FO1K4S5hSJV+YdzUJ7 3BRuhJyJNMQsOegAqfRRE9v86nPSoplYacqRxhnHJNJp95FBCybD5hHT0pw1eo72Vi39lRN7 R7FHX61ilLm4uWBIVQeAK1rGUtIWlXIPY1RPmJctvX5AeDVSsQL9geXaT/CeRV+5gDQKi4UA fnVSS9YyqIkY84OKsXc0wCtt6URiDRSinMBMJX5TxzWjYiIRkkDHcVnXVzHPGFMfzHuO1WrB HEWASWojy7DabRVvgI5mkhXvzxU6XK3BTeqhgMUxLkRtKk8W4g9aiiw9yHjX5TU3jcEn1NGH 1apZZT5wRFG2m4UINmSx6ildtp4GHroi0xWQE5YjoRVDWv3lmYmcqBk8Vb3OWJYYNUNUY7cl CwNKdraiUHzE2k7BbhQcjHfvUGtOwjzHHnkACnabIWjKrHtCnOaNb83yIzGOSRmsW7x0G1Yg u0/4lg3kcj5gKsaaoe3CjIA6VBMH+ybdu7NXLFSsC5GDRHyEQa4GECb14yABUmnbWUKzEAVD 4hkZ0RUVnxjNSaXHvAUnbxzTWsy1qibU4CYyy/cPQ1BpK4BjzlvWrGoK/klA3HasqDzl+UMy v605fFci2psLGPMLFsN9aUkJnc2TUNuGIXzCcd/epggdsEgAHirTuaNJIHMborKOT61T1Ibo DGT171bbAYqDwKhkVWbaQSpp6k3synpyqqKq9Bx161cvog8JKkAAc1WjAinwFOM8CrF7g2jS 4Zc8H0qIbMb97Yz9IfaZNqEA5BzUVg7/AG+SNuVzlc9qhs5HSR1V92c1bsoHVzI3XPWsn8Wh KNNo0KNkhCFzn1rD0gSJeSsz5LtwfSte5LrAQE3llrLtBIk/Knnkj0q5MEW9Y4TcD8vQn1qm dv2EqB8o6D0q/e25kt1BbIPOKoxpK2+NoyFHT3qZt3GiTR1LQbgOB1rSkkzCDgCsywjeDIUs Ax5FXpsSRhBxjrWkHpoJ6kUE8cjlQRke9TPvds7zgetVbe0SGUshyzdauopwSegq4vuVay0G yDdHtAw2c0kfAwT81SSFGYMpxmm7AI927BJpuQuR7kd38sRAkGMdAay7GGGNjk4Oat6qTsKR Kc461mWsU6Fs/NnmsJtuSHaxqNsCbh81QXEgjPyvtJqa3O2L51wT3rH1hDJex+Uxx3raUkkN 9kaok3jerZoB3N1psSYt1GPyprfK3AOO1CaZDQOrJlmwR2qOQKysxKg46Gpicrk9Owqtdw74 jsbDUSEVJIhFGJI3+8eR6VNZhZFLMeBVRPNUbWXJAqWziOz5d2WPIPasU3cpIdfoptyAxGTx UWn4SPG/p1Jq3PAXiIzkg1RW3mMm0Lhe9XJtSuIm1FvLiDKNwNVDEJLfzSDg8Voywbrcx/MG xgVThiePdE5JHapnK4C6MsUUjGXLDacD3qqzH7eWLAjPIqzaRPHMzF85/SormFzJkDnuaWtg Whcl8tVBYjBFRyOhiKrgCqmJ3OJF+UcDAqyUUQYXO7FXpsDMlYwzMQScnpV62bYu0tUGn27e bKZAQedpNPt42D/Oep5pW1BK4ahh8ELx61DKoEI5yO1SanIVjCKDnNQxq5QKR2pt6sQKcQkh iD6UQp5tuzvyoqYwbYgW796rokgcryEPQUPUBtooGQvJNJclvPCYGe9WbeJkbI+UioLpGMpb PzE9aE7DFvW8yKNSQCvYVZhci22jOD2rMk3K47+taFu5deTjAoEMgXLnfjA6VNtjxn+IGoJo 5UJYc5p0QLMDIcChLQZOGJ4FDBvvZPNO2FDjjp2pN/y8jihxfQdiVNqAu67gRVWwZvNkBY53 VOrhxsJwBVWdHjmDRkbTQ1bcTRqtJAI15Jk3c+mKkQJJnBAGPWsqJJZJeSQPWtFWAQBlwuMZ FWpBYoFg140bA7RWimNoVelUDA63G/GUNXUkAbIBGOwqYvUGilqGGlHOwg1atCmA3oKoXqST Xe7BxVuLgYyQKS+INieZtwZscVQtGJnY4q1JIpj2qMetUSjpJlCQD1omtRCEn7dxyK2ZCWSP CbTj86yLdP3pJNXrnzmgwj4I6UQXcqxBfDEe4LuJ7VEN4tdrnAPWpY45XC7mxjrU00K+XsD7 h3FT10FZlS18to9g6Z6029Co4WM7hUTxNEz/ADYXtiljBYDn86VtBtaCMXyCASc9a0otphDn hgOfeqzRgxfK2CP1qKJZmPJwOwprQFG49T5jsVJx6VNZszEqRU8EQC4wAe5qOSBozujbcD1H pQl1EwvEClVX1q3ZALERnj61WijeRwpOB/eqxL8ibE7d6cfiCxDq4IVQWZvoansG2Rg7iM1A uZW55qfKiPac7gegpxdmNXehbjZdxGcnrTZWKnqOagtpCG244PQntTwoYlSCSPSrZdr6ksG3 BZh9KsMpCBhxmoEwVIB6Gpg5YbSc4ov0Ia1A8DqfenDJ6Aih4wQQp5Io2kcZ6dqdx6CsHA2n j0oIfd0G3tikOSMlqIizZDHHp70mkwaY9mdk5OMVECQ2SckVJt3d+lIUGN1EUK/RiISzhSet JKADk5IzS7CHByDxUmcoM4p3G7PYawIUShTzT4zzuNISxAx9KSINyCenenuFlYlbPDYyDQrJ kEDkUseWTaOaCigbSMGgW4pOeSM+1Oye5/CooQVY5OakOc/WmSPOWGDigHC5zgCmKWDHuKUZ f5MZFBVrocpLrlRketOAGM5ORTEPljYpx7UpBQghuooFsSsFwG3c+lNiLO5OKjyVYMp5p2W8 wuGwaQ7j8YOB17ClDsD6nvmmoBgl2JNAODnrmhD8xY8eZluR6U4DDEMowelMP+s4/KnFuecm kyXqDB+m7JFN75A5FP5AJAznj6U2NTkAnFM0UlaxICAg3jP0oxlMDGDTd2xiNv0pW6bQSDTM rhtIO3ORj1p4RmXKngDnNNgZ0PAz60quuSuTg0rjFiVTA0nAwelKm14+AcnpSBQVxnApxIKj DdOuKEN2GRrtBFSFUKKASB1NNByCQPl96RQTk9qVx9CQNjIx16YpVLKC3c0fLtz3JxSO2CV5 6c0ydBT5jqBup/zABcBjTY5Dt+Ue9IGYjdnk9qTAFDbsKvHpUnQHrj0qH5g28Ng9x61IATk5 OD2p3sUkA+fKqAPpSouGBZR6UkYVCWUcnvTmJztKk+9S3clgoySAc4pcdsg5pqhkck9fanA/ vA+NuDVLQfNpYa4bGBwaahJY8/XNSSsXYuB856+9RxZWUqRkHtQK/Qk4YcdKeTnHGOKhDNux 0A6CpFZwfu5B70O43ZIe2CMgY9aapxQCQNo70qleRzQriuPhyzsxwF7c0q8ngkYpF2+XkHJ9 KcORl+D7UxWDLPJgABQOT6mnFQRvJBzxj0pioASMnFSDYU/dg+9K4CGMZyelNMSgEIep60rb m45ApY94P3TjtTuNqwu1NgHcUhJI4IpXxjjqaSOJyTnHTpQJsUkHGRn6UreWOQoYZ4FO2hRy eO4oKptBiP4Gk9Cn7yHBt+MkZpkgjHOAPemuNikooYmlVCwAb8aV7kNdBylNuR17UBj82/FI YwzBFPIoZCG+amNKyBAcAhc5708HH3gDTgzBADjHamb03dwR2pPUpWHAnkcc+tEYCvzzTVKS Hbkgg5pXIycD8aGtBrUdO24jaAMUjksMnHNBBYD5unalX50HzAYoiJoMfICBk01d2CM4zRtJ IJJAHapJGARcKQp6U2yrXWg1HCLkkAnjmkO4uTwRSP5ZHz5yOgxSqYwOc/hTJtYiuGIIAwoH FJtBTO48+lS3fllBtU7s8mo4dqjkdRU7GkmnohdjKAfX1qpqCryRwPpV13CqCxJqpqEzFMBB g9Kh2luZyiV9OtEiVpB908mrdrbPJDJMXACnAWktvk08A4z60WrGKNgTv3c1UYxSFYrG0jMo d1G4d8VbVSoLZBVfWjDg7mAwelG0qwyevQUoxS1Li+hHNEJCuVwD04qE6fA7+YWK7DkD1qy5 O4lzzQcfX3qZU09Q1iRqyHcoBWoVtYTNuA2k9TirTbRyVAFM4AyKapojdiCNVc7AMeppJII2 GXz9akDLtA5zmnbsqUc4A6U1BWsGrKkNrGikjg9ealEcbKQ5pV+UMzDcCMAmkwQgY4oUUkaK LY0Wdr5Z+QZoyiJiNSuKWVhwQKczh4toUAUvZpaitbQgeGKQGVxk1HFGiYMYBqQumSgycdaV VVemAD0FNQS1HKy1FRWHzYP1pVyWz396MkNsYkLQFVmJZjkdMU1ZEu8hSW3HK1FJGrKc8jtT 5CSgCn6mhXTOGNKTTDle5EiJGoKjr1odVYAMQfb0qRBEZclj7UknkRjAJyTzk0JREtQaNQAq ilVEztz9aYGBXO7kcVIiIOQ2c1XKhLQhdFLnjgd6cyAP8g4x2p8jIE2n7xpIwAhYt0FKyTG2 I6gjkkUzYhIO0celPYgjAFI37rHPany3DmBcZ+X7vpSHhTsAyDQSAOSDnmm7okUncdxNKMeU fxbipgnLDrSsY1wdvFNjkBIwMg0jYPJwB2Bp3E3qPKI67gKrXzOLYxfwVNuAkDkn0xSSbJAc g+1T0YtWYullY53XyyM9yK14kzUeyIRg8A5qbcrKgTjHephTs7sadhI8lyDnPTmlSLyyQCMn qaGdN3GSw6mkLZ6+lW4g32ECqTt6j1pjDPGOKUAudoyCaRz5bbWIJFNxTGpdA2oI8fxUsbRm NlI5pPvnIwKFVSxG5R75pRiog29hAFC4GQaeGIibHTvUAZQ7AMMg1Iqgd/ve9NxuNSaGoARu A4p05j2qVyPWmM2wsMjj3oJV4gCOSetCQnK7HFQ0WdoPvVcxqnPvVgBFjJD49iajBVuAwpOK CVk9COQe+RVdoI2feo5HU1cZQFPIJ71BxkjOKHFbD5nYQ4VAccVHPkMv0pwQFjycj3pXCoQW IYelCiugk7kYI2ij5cHjNKnltuBbB7YpYYxjJbP1pktakbqroAVGR3pgO3gAA+1WF8tSQxwO 5pkixF8RuCD3NJJJhZkTlcbQ3zZ5oOFBz+dI4iR+evc0kjx5wHzTsmNCOXODtpJNjfdPNTPK jIdw57YquFUMuOD3pWQIYUI60m0Drn2qdkUEsW4+tMyE5GDmnYG7kLqwACkle4xUZxwB171O gyxfdtx196iYIoYjqTnmhWB+RDcIRtO7g01Dgg4zQHBbmn5jJGD0pbMehnagZDMCi9+amt22 jockc8VZmCFQe9NHygBMZapSd7smw0jMWMk89KiI5AIwRVjGxcnhgaiJ3uWzk1asx2FQgHDE 81Vu4zyy5ODVwgFdpwCO9ROwAILAY/WhoRkYMjgqCMHnIq9CAkeTndQzRGUHoKe+D9zkVKVg Y8SE4J5zQwAPFQBgmVY9KcJVOCGyPSqSGiwjYj6fNSFjtI4565qMyfOOpFI0gEjLvBFJhcem AKl2hl7DFQIwJwCOKkaZF5YUKw2SK5UFVOM09WbYil+PcVSWZN3zHr0qSVyEBDA0aCsWmbBx uJUUpkUkbT9apiYAAZ605ZAB2zTVhWZZJAbjk0knIznFRluAVc570MfkIJ60WsNqw1M9Mlql UJK+BhQBzUKSKvCnFPjaMBwW7dRUtDTKyyKl046jtWhGyeVls5PSsq0w1wxAzmr4+UgMcfWk mJakknQLn8aYZWBOMKe9LvTJUnJ7VDO2wAt3p2S1Hcc4UoRjJJqGRvlxgDFNNwuD39KqPOS/ 1p2uJpF+Ns49KsAFTnse9ZKT7e/FWluwVCg8UNCRpoVYEZINPQlYznHNUI5gec04z4PLfKel NajLYZFTg80hlV++TVJ3RsqW/Wo1lEZHIAqbJMtbFwSLH9SeKcDl8gnPeqiyws24nPpViM5U EOPcUuXUaRcXAQEH5s1IhfadhwTwxqssqhCpH51Yt2HAzTT6mezJowijC1JFv3nIGMcUw4D8 Yp4JGPc1SsOz3Jdp4bPWlBzJjqcVEWK9aepC4cNxRbUSi2L5b7iO1PVSRx2pm/OVDHJ601mS PG5jRa5SdtyYnjmmNnoThaYZ1buABSo6OMg8j3osS+4q4zkAmnHOSB2pCSoL4wKI5VIO3ofW jS4R3FBwue1S42imHOANvHrQZRkKTzQW1oShtqB1OADTQWZtzHJox+6B3DGelL5kYOCcYFMz TGDf94gg+lSoGODTFkRpBliRUuQAcGgQ4AhjkcU3bkjacfSmpOrOYywGB61JNGpCGGQkjk0X sUtCPygJPMLNkdalZcYPY9MUxnDnBO31NIXQPsQkqOlAtyYIVVWcDmg528LkZ603dx83NNWd CzLuxjtQ0CRIBkcU5UbZkHimL+82tuAxT03RyNhxgimPm6CouTljgnuaSRlBAA6Ur5dQT29K AVPfHrRYkcgfJIIC0wjdIRnC+tOaWNUMeQx9c0xWZ12DG0c8UBG49Bzyc4HWnIU53EnOcGon Ixwe1NjkUrgnp0pWG/MnB2khck0uASGIGaiDkLxSxSoDh2wPWiw7PoT/ADOuwAEdRTAp9AD0 pVPy7g2QabkJ1bknuaYth7IcbTSlGVCFOKSFldypP40rhd5G7IFFhKTCLbyGzwM059znJGRU SSLu5GQelSphXwT19KAWjDbtxg/hSsUQZAPvSMPnbLjFAaKQkKcYHJPep3KbuAG9qmTABUHm oYjlmGCMd/Wk3LuLBsH0psWpKMqfLx+NKThcDr61H5jKMkE54zSyBiglDAAcY700kDHjr83X FLkMME8E0xCrHI+Y4pTkYAAAzQTZpjwMHjtTTwdw69zSByXKgHI71I6EIrdA3SgqxGobneuM 9KlX7hAbAHUU1tx45J9KOCOTQQ02x8Gw9TkEU1FKsQuTzTY/kOBmpA+QSM/UUXC7vYaofqB0 NSBsA5AIP6UgJx1PP605zGpx0PtQWgDcnsBToWwCVGfWmqQGwOc+tJGwEm3oR1pCsxwJOSen 8qfHLgckegqM7W3EOoA7Z6mlEZKb+OOgpg79B4UsTgDnmiMjozjPfFNDOFBXAycGnAKDjaM0 tAvfcejoVKD5ie5o2qnyDketR88lgAfapR5bIHBbd0xSsCYkbFJO3TvQf3jkg4A646U2RcsV IOcdaREAi8pMg9zTSsx3bYioN+4MSc04k78A7qRAUYLyAKWTaZQycMevpQF2iUuSBleKaUDP leAPWmltrYP4nNOwOpzx0xRsNSFVVBJxk0jA5z2FIWIIIHNLGTISWOzH60CbF3/NtxSko4O3 5SO1KGXBGzJPGaagBXg0cpVO63Hw5C7nwaaJJSCDg88DHQU1gMYY4pQxBBABHekkrilIX5Dw xwT60oweMYx3onCEg46VGx+b0plxTewk7RiNnG7I5qGBw6Bhxn1qa5I8vaAMd6ih+5gLn0xQ kQ3YldcgbskVnavcJGI13EGtMsM4zWLrsXmXKN/AnNKTshXbA3JEIZs7auWlwssQGMr7VU3x S2fk7l3Gl0qL7JZuoOQWzk1nGpJ9BNu1yxdXYSREUNzxUyFSdzZJrn7+6ZroFAQQa17O5M0C jbgjqapTu7DTLLb3+TA29ye9LKCrBDyV7Cq97cSRxDaMmoba7ZpwNuWPc1pdD1ZeKGQAYBH8 qQIudpzTJ5RHu5x61nvfsibxyM1DaQJmg67chTms67upROqDr71ZsLn7Wm9cIf51n6gjSXqk ttIqJy00HGTW5sh3S3wQGB5+lNByueR6iqTXIXYikuT1NWs5UE9SOauHvRBzYokVTyKUEdgS Kyrlrn7UNn3B14rSiI2jY/1pqS2BO+4kir5o28bu1OYYO0jBFNJAccZ9/SlkcLjJJptilqEn UDmnK8ZRhjkdKqXV5tCooG7HeqjXbxN5kiEIOuKnmS3BNo1InZQzPgCsy7nkeYNCAV6GrU9w s1uGVSARwaraf9njjcygkknGDWcpq+gXaEtrtRcKsoIOeAe9PvpzLcNHGmCPTpVTVHiWRJAp znitOFFW3jZgu485pKfQUmUJJJYiC5wO9X7QiSPIPJNUb0m5dkABPtWjp4ht4Cjrnjv2pxbu Pm0K+pl44jnO4DINR6RJ9oTbcE474qDUrl5Y2K5IAwBTtCeT7IN6qGY9+1DleWg+bTY0yyRD OG8v3rHe7L3Pyy8Zxg1avZmDeSpyM81lmKMXQO0jBzSlUa2JujafaIAy7s96plnYE5PsKvxl WjG4YWoL6SJGAjXAqt1did7lewl+Zkck7e9Nu5vMOI3JIP5U+yhKuxwPmOeaqTw+Tes23GRy R0pN+7oPVErSSQhfMYtnvUs1zJHblk5b0Peq2r3PmW0CxhQUOOB1qxPAWslZjg9qly5NEO7I olnlgMzHB9B2qSwmKtjduHc0kEzJblVXPGDmmabBuclSFB7Uc2qswjqaTJkjBxmkAdBhyNwP anHgYdST0GKRQNxBHB7mujYSGzsFh35AOeuazz5shaQN8vYVLqa7E2v0PSoYJ41QIoO6spy9 6w07Ba3EhXbJjANNv5iSEjBJ7EVDK5W6IKgZHAptsXaYliAoqIyd7CbZJukjw8oxxVo3caxB sdagup4p7dlAHy8ZxVFWVogAcgVV7BqyzEjyzPMjNjHKk1JbTFbjy5XG3rTYLhIQoYZJNQXB jl1Auq9ewpXa1EW764SWfy4+oHb0qvIskLhskiobePbds+as3EsbW5cHkHGBRe+rAsLPGYc5 w2Oc1nxrcMrOXzk8YqJsCL5n25HerVnMsEKg5bHahyuWmR20sgd1cEtnilmR5TjLKfaozMrX 425BNaTItuT5+CxGQRVRelhXfQy7jzLeRFY8d60rRtw5G4VQWJrmdlLZX1q8wWBSOQB0oUra C13KupM6higH0qGyd9vK54yRUd40jxMyhgAKk0li9sSMZI5NJO8hqRDcSPJKVHAHaorhmgKs QQCe9EmIbjfkk56UmpTC52mQbR6CkndXEXIRKwB6kjIoZiOpy2aSxUCJcFmGKkdQzkKMfWtl qh7jC28BTyKAAvytn8KdHsyARjHWqU0pkuD5Jx65olJIWxajG4tg/d5qveJ5sJOOaZIZYirb CM96shQQM5ANS3caVzPggfG0uc1DCzJctGzZx0Nalzsij3A54rMTLv5iRHk81DuInvzsRSrg 5HT0qlHvEg3M3HvTtScbkUggd8U+2EciEnPtTvqCJyzvGTnpVCB2ExHOc1eLBEwc4qhGoJd1 JJBpy01HrsaAY9CuSRVC8fM23BIq1azAjn73pVO7QpKcnk81V7oRFKjrHu/hNOtpCyEhiAB3 pkkmI/mPHpS7QYyUztxS0uIjaQu5yTk9KbuFsQGYncaN+Bu4zUUzZCllBNK4F2S5HlIo4Oaj YkDfjJqo0qZHtTvPBOFzRe4y1FNt53YI61H9o81iAfpVLzAHYE9e1Njl2uCuOKHJIC9K5GKe s+QATjFZ1zcFl+XOPalglzGNy89jQpajSZorcbSQeaUTdOaoF85z1pscjA5PIq1qJ3NuC47c Z9aklkTygyNz6GufW7L3BjTsKnjkfkZpaDuaG5mBGTntileKRIN+Tju1RWTDg7smrFzOVt2i LYB5IoaEU9KMnnFVcnB4NaGoSPHIokPPaqWnod52A/Wpb9wjgMcsemah6ASW5fO7JbP6VYm3 zJtJyQO9RWeQmcc+lTkZR+MEDk0K4jGJcTMOgzTSrSOGBII6+9TSqGLEZ4qokxSfac4NODGi xeBHYCPcvH606NGijG5s+9Vnl+bg896leXcME59KbYFuCbAY81E0rklepqWAIIMEfNSQAAGQ j2pXHYqJcOsoDkjJxVu6fKgqRnHSq88O+RW9Dn61Iq7jyMUr22KV0hqecyAjAq7p8jBipzkd 6Io1IwAcipIkKhsDGaV0ib2LOXmmBDKB3qZQbd2YuSv8qj09NibuCR1BqS6k35kC446VLs9R JmrDIk0C7VAJ6mlAZW5yfeqmmj9yNxzV87tpIGeK0iVz6WGnLNgHjHP1pquEfb29DSt+7iVu /es6VjPICpIwapyGptI10dA2BtOe/pVG+WQyYQ5WmxB1bgE561fRFZQFBJqU7qxD1Mz7O3lm Qk8CpNKkBYb+mamvpCg8roahsIfLidyCxzxUtJSDUdqEzibarYXmm2jOvyg5qlcyuNQBxkDq K2oo0YCQDb3xUpXkCdh8twwgCngL0rMkuZWnGBx3rUaHzRl+B2NZN2VhvfJjbc3pVTbQ2+hr QjdAXyRjqapTzNcTBFA2CrwUPYbS20dce9ZlvtBdum09+9W3dWFcsEGDLBs+1TNdKbYFeGPW q1xcI8SnbgnjFVpUJCsGxz0qE+ULlmFXYNMoyT61dtLhl+Ujgiq8U4EO3gVCZCZfl7Ur21G3 dlieZnuSi5ApHM0ZD8BfeooXb7RuJFTXkm6Iqw5olK65hXJ5bpFgViMk+lQKrOWdeT61TXKx AD5q0rC4gVirqenSjmutQbF0+4Bk8t25zzV91APy9D0rDzu1ItHhQe1bjcxovQgZJrWLQ4iL u3lSCPeort0QEA5qcEucd/Ws3VFKOo4+tE5WQtRtuk8od2Pyg1Ytp+dpOPSmRXCCHY2Bx2NU k2mV9m41lzW1uGqLF7OZJvLiypA5xTQZIwMkkd6S0byrgsy54qxqE0U8YdVCHpgdKqUkPcka 4BhA5U9qrGKWRdzNkA9BUJYkDPJq9bzAQ9Bmoc3Ji5mh1jcBSA7Y29qbeztcTHy0IGaqyuGm O1QDU2ntHGXaaUY7Cm5t6CvfUQzTWsibgSmefars88Xkl1cgkdKo3rebGEVuSc1C5ZYxxn2q lK2xNyxELkqSTxmrtlcqhPmZOBx7VFFKgjIZTnHAqozES4Azmhysyia6mlkucBiFpY5ngkTK lgTzmm2hUTFmOQOmadeSrJkgcipUluBfvLyM2oSJvmPWqGZRiRj8gqrtJAYNz6GtAyoIFUqN 3eqUlLcWpPZXqNCQ5wPSq9xM0j4jZlWqwb52wAKlsZUjmLOA49KHPohk1nPNG/JH1rXVhJGG ADEdaxrmUOxZAFHpV7TRJ9nLbsYohO7sKzbLEgIIIIpx3AZPzZ6A9qG+YAKOaa8ohUmQZAGB itLlNWHPIfLGRkj0p6qfKDFetYjXM0gby+uauWFxMziJ2wMc0KaYMsXU6Q25YsFI9az9Ovnm kZNwKluMVZ1G2SaNg5DAA4FUNMjhhusIgC/xY7VEm7oDanfy0IQnGKymkuJIiyEgg960zGHb CtwOmagvZQkBiVF3e3eqnHW4ENlM7RnzJMyD0qFp7iW5KI+CBk1Lo0TFJ3MJ57ntVZXEN3li AB+tQ59GK7sXI1uCfvn8am1CaeKAMpBx61LFe28pztGQMUagwezJVUGDkcU7JRdhRbRHpkzT KDIMcZxWgjocsWKiue0u5aOZnbBzxg9BWyZBJbl8KPQAUQneNiuhU1G+aMlYQWzRaXUyOvmc Bh+VVrdB9s3yHK56VPrM8MjKbddijA5pJu12S5F28vMx7gx3DjI71QivLqMbh0Y81WbeQg3Y Pf3rTMtulj5YXLkdafN1BMtQzLJDuZxketULu7kafbbISg659apRSuRtQc+9X9MkihYvOgI5 zjvUc7bG5aC2l2zt5cww2eK0x97npWFdyRNe+dGoUZwBWxCHaJWbjd0rZO44vTUn27m5OBSE YBGPpQn39pPSmXUqxEhWBIHpVbD5roeOEDk4BOKjklSGF8YA55rPTUnRiPL3A8cirETRzr8x BHpUxkpbE3ZSGoSScKC3PGKkg1KXz1gMbbs85q/CkMI3Roq46ZFZhkM+pD5QvP3hWbbTJu2a VzK0Sb349qht7sTLl1ZcdBUGvybZo4WkJPFS2MCyqWJ6cVHPJvQbm47Fu4ZUjChT7mm2zhAP bpU10VG4hcA1BBtJUlcCt7mlkSIMl2Y8tWbqbQGRY2BG4889a0rhlAYYOT0NcvrAuDfRyMwK IeBTa0IsM1x0spRLAxZCOh7VNZ3zPGp5ORnFRX8cV7aHew3KAQvc1NpcCCBWwcAdKwi7MfQo ane7L5NyAbzjiuispIgieaoXjII71jalbj7QJWQAY4p9rcO5GRkDgZoptJjaLmo3SmXZEpIx VSKSRbpVKkE+namrdNBcNuQBexNWJZFlmDqAD1oc7yErom1JtkQwfmPWptNhint9syLgDjFM vmM9qhRFVhwfemWlxFDAR1bGMZ6U1JOWo1oXrSJLblYwQp6Vj61MWuy0a4Jq9ZztJ98nBqld sP7QEZiZkz1pTty6E9R2lqrsNxAJ657VpzEA7VGQO471nyhIZw0aNtb9Kuc+WMc0UpaGijdX EWaAP+8AzjFPEgUFUUBT7Vk3aTfawRjZV+IehJyK0VpMhkykK3Ue1K3zfICOepqBiRGS5x6U +3w0Q+bvVNBexkX+9rwbXUbTjJrVlhils4cIAduGJ/iNZmoRtHdEspwOala/86BFUbSvAFYq 13cE+pcuo1isdqkAelZcMZmjCjJGcDFaKQtcQkMSGqpBMNPn67mycZpSik7he5DeJ5LqjHkd jVmec/ZkVD8x4qPD3NwZZOTng0y5fy7hR2HJqbpaoRZ0+IJKJCMmpNVlXyHZuPpVe51HMINs gwBzTv3lxp+ZFG49a0i/dbKexDGqmyEw6Yp+mHzDuBGDximBituIQMKO1SafiJcIlZw1Er2E urMm4MisQ31qk8Uv2nYXyO5rddz5fIBxzmsS4nY3oxHlWPJ9KdSDSuO2holWtoP3jjGPWqse 2aQspBBPWpb7L2m4gscYwKgtLgRwkeTtwOhovoriuacSA/KSMgU2WJJSFcYFVLCaWWUYX5TV m9nCTD5cnGK292wSkUNThSJgkKBvTNPunZbFN5wT1xUZ8ye6BBwAehqxqMJMI+XPHasJq+wa jYVj+z9zxwar2LFbkxFie9OSZorcRrFkkflUlhEwYNgBz1p2WlhovuxJCk4C96jl+4CDnNTu qNkOe1IXXy9m0cdxXRF9xbGdq8ZeFMuDx27VHp9lNcMqxLlgMk1bmiDIxHpVO0muYd+MoDxw axnpIa1K10WW+KyDcy8GmwLunKs2FbtVi3tybgzyHLHrkUt3GkcvmopOewqEne4rdyKeBYYW 2jC+/eqiHbEGC7VzV+Z5J4whPyjouKlFsr2oQqAaerCxXjt0mTcx4/hJqq0e243AHcO9W2d4 12bSVXpTraJmfzW574ovfQRUtQZJ2WQ7O4NT3FqIo3YEDHP1p97GGcSooB9KileSdwhGAetJ DKzRq1uJGOc9j2qxa2xlhEg4X1q01lGINqsDkflVFXeD/Ro9zKDz7UJNasVyHGL0qAOO4qWd 2ZgDlvXNS26ASlmXjvVWdWiunaMsyt93NXceppwQCFFLMF3DjFVNdLiHZv6HtVZ5ppyIjuUL 3q7NCJLTd1cHvVaWHpYpSPIbIBTj196m03yvIYeXyBnioXSVsKnUdRU1n8oKkkKeuOtTF2Ek UgftF4QRnB4BpNVQKQBHgjoDVi4TyJjLCpNMuJXu3XzEPFJfCxvyH2UsvkgFQoqYoxGQePWh EKttIxxUrI235Bwa3jqgWg3YvZu3JNZXBuiOMCtdUAbb19ay72Py5wUjZlJqKmwrl91Bt1Z5 Axz93NNXEgLDotUHeQnBQgZ4xVpNyLkdPSqTQijdOwuGjPOeRirQiK26tsw3eqkkPmXPnc5B q6zuIym+oV3IroZWoDDqQMg9antgqxH5eT3qtqWWZVViD7VNZ7jDtbJIoW4krsWbletU7Z1R 2UDk1al5GFH1rOUNFcFkBINU2mD0ZLAUF2SQRnrS3hUzHYSRnjNJEzNJuxhqLiIbs5pLQQXM KLagsfnPPHeq0ch8njIFSSOzrt6gUirkZPFNagVUAZ9oOOe9MucI+wMPrTLiNkmJyeelQtk/ ezUtADnEmMcVIgGPvYNR3DB8Z4+lV5XYLgZpXsA9yBIwHPvTYyQSQPlpoIxjNRuJB86thM1L GTSJtTvg9KfZlyMOR+dV2kLlQxPHQVKg2pktk+lF9SkyySMn/Gm5PTPFQ7x1JxSq4HU9au4h ltlLl2UdeKvJLhCTwBVWPKOWXvTLjLqR/e4xQhM1LKZGIZGAwabeTs0n3gATyar6cNq42AD0 ps+WuF3DCg9K0b0EbdixEeVGcU2/kDsrFRx0pIZ2S22Kwwfaqty7MRzwKTSsM07Rv3Y55qWV gQcnHFZ9nPwA3IqaW4+VowAQe9NLQNCO2bM5XAbJxiqN5tSYqOoNQTSTxXR2vhAOtRCYsd2c 571mNImiK+bzzntVye2O1WHygVRiAEiv3rWkme4iSMDGOpo6DuQRvJs5qbT3SdthyOeQKsQW ZaIDIAqKG1e0udyZJJzSEie6ijTG3NIIT8pAqxHC00ivKT9KuPbqo2qaTv0BsZbWyhSwJyRz UXOSy44605DIrlFJ5qxbW4jV8jcW9aVr6Ba5DbbS+CcZPOKkvkjXCJyCe9I8WzJUYJ9KWJGl dd4yBRayFYu6eUWEptO4HirakgcVEiFBg4x61Ig4x1JrSMdBpoSYZibnnFZujGWG7YuoPzcZ rSmGYmXIGKzoRJE5YA8noamWjEa7BVlJDDPemyFlU+XwetZ6iWQkbiAavBHEZGdxAxmnFPcF a5nhne4+Y7snr6VqwwosZy3HesuzSSG8cFeG5FaTbvLKgZNKKvqx3uZNxEF1AspyDWwmxYVw ayLhZhcK5XPPQdq07Q7l2OhA9aILViVrk7MdqnIx9azL0Y1Ff3anI+8K0JCI0YqeB0BrHeaa SZj5RXB6+tFQHY2GTfFtXsM1mwq7XBUgdeBV61LlAx5wKqzJKlx5sYxRqxEl7a+WnzMAx7VW kXESDGSe9TFbmadXckgjvVqW1Hl4B5qbNjRFaW29TI2CoFQShUmJQjmnWouInIY/J6CrNtbB jvkUHNDjdWE3YqWsbSXG1zt9Ks3kQjTqCaW6iZJxIinb6UxllllDHKqO3rTskrAQFSIweAPW ryW8Utv5gfG39aRrQND0J9qhSSaNvK8o+WeM9qVrBYhgT/TdwyPU1vSMrBdpHArMtrfbIW3c elX4wB0q6avqxlhn8wAgAEdR61lar5hlG0Aj3NaABL8Hb61FdQCRCT1FFVXWgXK1taZhaRhk 49arliHKRLhu9TM9wi7Ezg9RU1pbM0nmYKnvWfSw7NlS2XfMYT9/POalvLfyhsAz6ipZofKn aYZz296i3zzTbyMDrzQ3dWFcgEY2KFJBFX4rPfDuXqBk0+S3IiDAZJ5xVQyXEJIOSrccdqEr biRAvzO2MZBxipLOATysrABqsWlmMnjDMc0SxSQ3GV7dSKahbUBl5AYQBGoPrk1BNuTaoTJP cVZAluLgoGxjqTVme3CxhVbLAdaXK7hcWC0E8DSDhlXNZhjdWPzHd61bSaZICvI3cHFS2NsW jy2W5zzVTXYEynZqHch8jjipbyLywF796dcRtbzlkBI64pF866lB4GTyDSSTBFYZVwSfl9Kv iHfCZAMACpLy1CKUUA4GaqfaLgQeWqHcO1EVYBiKF8wZzn17U/TrbfJ5YBLGrljarJFJIy4P eoNr21zuQkDt60KDTuJjL63e3nCSAjHOAetatozG2yoxnpms47ru43yBiy8AmtaPekQjB4FO C1ZSY2J2Aw3J7modUYPGBGNqjqM1Ou5Tleppt8ryKd/PHFbPYF5lbR4yyPgLs9as+UgcNxuH es20l+yuVXJ9Vqa3uJJbjbsbBPWs6dhWNFo1e1kYYyvbPNZFlg3TfIck1oXkjRxnAwwGOO9Z dvLJHe+aA2AOfSibSaYm2bMpjRd+NuKoxobmbe3ODwQafqEi3NkCu4Z5qpp05hTaoJXvmhyu 7DadjdjASMrkLnrg1Uazhkk3FQzelQWdxJNM4IIUcCnSXTQP86nAp3j1GtUQ6hA0Ei7FAGem ats4mtiD8p28c1RuJGuphhT0q/Ogjs1BPzY7VHR2EUrARx2ciTRhpT91gadaSSCJ0Yg/jVeG fYGRoyzdqu2cW4bipGeopQs1oHUr2MUk8jLGDhfWlvIGHyyfzpzq1tMxUtsP92kjkNzOEXcf qKFB2dxtEBbG1S3tzVsWjsrPu4AzUl1aGPvnvTXuj5flZIJGMUknYSKeXyRjpVi2glmh5/LP NSw2277zY780ltOLO5DtllX9aUVbcOpXeLZIoZe/5Vv23mNCnHyqOtZEPnXV204GEJ6GtpHJ i25wK0p3GlcV0OeoJrK1lpBwRtJ9O9aqqABtJPqaz9WV3GeuOlaTvYNLD7WHzbZGfZtxjHep re1SJTsUbSaoQ3kcECmUjPTirVldmZSy/d6VMLLYTYupTJHBiJfnHXNM0633RLcMOvYVDrIj MIwzBie1W7A+XboQSFxjmpjeUhxVzO8Q2+6RJgSW7CtbQVAtfmQZ75rO12cRunzZGe1XNJlC w/fyDRTtzMUo6jriRd3zZOaLfGDn8MUTJxu4IzxmiA/LjBB7VaRvJ2uSy8x5OMDism5thK2W Fa0oYIVAHrVSBWlc4BG085707dzNRuZ4sEDghRn6VdKRwRKdmM+1TMQZPu4oPOFY5A6UlBLU fLbcguYopowNuarraxpyF6dhWkEy3y4AxTP48gDI44qeWN7iSTMqW3iuUcOMH0pVgRFX5eBx V+RfMdvlwR7VWmjY8Z70uVXNFTS1JVTMQAHFRG0Tfkgc9amhyQBnp0FTYJ+UL8/XNXyLcjla 2Gxwoh2lcLTDCpfIGasAqPvjJ9aaHVUMY6mjkTFYjeNG5IxioWxGxB5HtVmYER/eA4rPeQt9 c0lBLYL2ViO6dFYds0yO4UPtB5xTLgZbBORVKZAJhJyBgjNXy2BeZpBwQTndzUqON42jC9xW QLxY1KA49amtr1JcKCMijmH7JM0rra4Bkxz0qIW0eAwAwKgNwDwTnFWUkwFyBjqKjlTY3HsW V+VDt5JFQeQhO8oCT3xUkkrg+YcBcURTBhjPBq3FMizGwosRDbAQDQ8Mc8hZkGG9qnBBUhel IhKtjvU8iHdIrpZQomEj21JHEoO08f1qwJNv3gvNN/5aHGDjpSUVEbldWIbmGMHcoAqOONRk 8n6CrryIcI8WSKaJAiEKo5/SjlQkl1IyirjJH0NV5LeIuXxgmpd27qPpTudm3HTqaLJ6FOCI Ah2Y2bhjk1FJbDZkAdasx7gSF+6e1KCFJJ7U+SNiGiCOJIlGwYPtStAjnczc/SpWILZGMGiX qMAYpJInlVxkEKB/MK9OnvTgu/e3cnpSl22kY+WgMNw2gYx0pqOhpa5A8KKDxuNPEZVVcEKf Wno371iq/WmbmZmVgu0Hinypak2QOScjgj1pjAk5GABUz7RH0wfWoxkpwOO9CY0+wrR7lUrx TWSJuVXAHX605pDsCYzikDqgC7flPaiUbhoRoqEsCMYpHVc8DpT32mQDOB6UjsN7bcbaaikr CZFCFjfdtB+tOk2qDzx1odwCGYChdrnJXd7UlFIW5Gyo6rheCevrT3PlqI/lA9RQ8mSFVcAe lNcLwxG4ehpKmr3NEl1GKke4h80wIquQO/SpTITnABx2pvJ5XHr9KORXuRbUVeMUyRFZi4AB xzTmz1/M012woY9O1Ds9BNEe0EA4OKR40Y42njvSs+WGCOKGchsr196HHQNCKSNEQHbk0pBA AHfrQ0zZPAz3pCSHAAyD3oURpIdGFQkgdRg1FtRD8q5zUruoOCOfSmkgDjg0KKQ3FilVIw4G KjVYw/AwBQxz05NNGSxQctVWQmrEhAZietMZwMLTfMbBVU+Ydc0rcD7oyf0p2BasM4yv51FJ tyoJJA6DFALBySefWhULS4bGOuR2pNIck0RMAz7cdTSyRlT7UrYLlfTvSZPIznNCSQr2I2AI 3BcVE7DPTmnO218ZGO4pJSrNkdKdkgZHIFdQdg461CDhmA44pzMwGOMZqB2DPt3DNTy3YIRy dpx1qFNvVhwetTbQJMtzUU2ASAMLUtBoI5TcQgxio3b5eDznmmmQBsgUx8ghsjBqktAsOcoG 4XAPXFVpTg/KeKkMmAQDVeTnINNKwhJmDNnFQSMu3pzSy4UjmoJjtbnBzSbCwxjtBB5qPKkb qa7ndgjI9aY7rjArKTGkI2ACPWmq7bQGHAqNmGO9N3nA5pX0LtoWQ4BzgE0nmAsOQD2qqH3H GMYoDKWOaL6CWha3qTiUZ9MU4sCQWIGOlVzKNgGOlOjIJG7GDQgaRcSTI7GnOAcVTaQI+AQQ O4qRJA7YJ6dKtMlmhD8pHNKqF5SSRgUyEqFJbPtSI48wbjxmrTuItTzLFEBtIOOvrTbaQSg9 hVTVnZ4Ayk7V6Vm6RfGSQhsgA4p36Da0OhBVDhcnNO35BAxUCyruwrDAqAtmQt0xTsKw+ZgQ QevSq8CjnaO9SuWLbxg5pYAGbIBHrUOOpa2JolI+8MGtOyC/KMVVdEZ1PJ4q/ZKoXrxmnuOy NGNdqccmnCFWXdnB70sZVRlec9qejqPvHFKxDt0FijXOB6VIARjAyKCqZA3A554NLgg7RT5Q SECKQWGM1JjC598U5MJwSORSPE+AVfABzihRGmh0YjDZYVJGir8+B9KiIQc8mnRfNIcZye1H LqElckWTc+GGfX2qRTt6UxFcMQwCt3oHzNnIx6UcvYS3HHY4JKndQI0O0Yy1AQl8rx61LChD OwYEjoKTikNrWwyULG2CuKem3y85PWm4LYaTk96JSmTngVWgrakieWHLMnbigOf4OM0xmjyM yAg+9PjChiS2fSp5bDSsNWKJEywZmPU08AYwhwPQ01ySeOac4iCqyN83cU0rC0GygEr8vHrS mKJiDtxSDg/MflNTsu1AQVOaJIQwIFbavIp8ir5Jwgz61HGzEsKUEdN5FTy2BACHCFTgr196 eSA2D1NJC64YbQT60KN+duDiqjoGlyPbuOADx7VZiwF+6CCOKiQ5Pp60FEIwMgA+tNWHIkPJ 2mgIFI3DNAI4xxTmPcc0nBNkigqcgZWmGIdCM07Ixls5pS7NjJ6cU3FMobsVVGAR60o3A8Yx igKcHmg7dxUMelNKwWFUBsFvXoKfgFuP1pAE2YDfMOtI+WVWOQfShghxRc9KktyoLbhxjio0 IKdTnvTkyXwO9LkQ42T1FePzY14y2eBS7YfOK+SVIHJ96ehIOVYKRTXfeeoJ60lFCe90BVs4 Q010UoFCcjrmnxyMrA45okbBxj5ieaHFX1ExoR4wJEAP1oIWRzv6mnM2EwcgemaFZD8w4Ip2 6D0sSRxxRxA7fm70Ig6kZU9OKRiDgg5pVY7cdqOWyJGNHEDuPNOPyxAIRg80pUnPIPtQFYYU qAfakoorQbtDLkqD2pY4EUE4wTSjqQCOKUSFhsGAfWnyq5LJFVRFjblh61A0C7i7KQfTFSBi oweT60qtuBDA/XNDimNJXGxHAKgDHfFK8aEqXGfwp7BcnYeKQODheh96drobHbUU8R/KRxRj by3IpmGI2+buYfpSlifkLDdjipUbEkhVsc5ANJsB3ZY+1KPNEIDvnHSkXnvVIbsR/Z0MuSBk +1SrCkbFMAN2NIxCsBnJ9aVwBIGzkipUUmCVxTAJRl+SOTUXkxBsgDFPMh5z1NKhHXApygmN WW414dzY2AK3T0oSzjwQQBg1N8wAYklfT0o3DGcnFS4Ibs9hbaJIs4VfaiW3Sdt0gAHcUkbA KXbgdqfknG1gAaOVEWsMW1tkfKDAp4hXbIrDII4odFkU5P3afGwKHgmmopF26lZLSLcGCZwO c1PDEEyoHDetGTnCk05dwGG5PrQopEjJoEZCrpgg8H1plvbRxPu4yR2HSpiWIyxJHvR83AT8 afKlqOOu41oCVyeRUX2SNhv2/MPap/m3feOD1GaViRgKwHqKHFS3Fs9BkcabMhPYgimS2qFN pUZ65qxtfHPHpQMrkSNk4qeVMuMbshtoQqbgPlB6CrTLxvIAz2pinCkDI+negsSB1A9DVWts JLWwsan2FJcRo64IOc05M9ecGl3FSSDyaGwaTKZ0223D5R69KkghSE4UDFTwg4OWy1KRnqOn PFEYpamdtRlxEk43PCEK9D60FUMapjAFKxc53E47ClC7ipUcd80JJO5dmtStcWUMwGV59TT7 a2WJTtXPOKtFlQDgkkdfSkg2gkspOfelyK9xJ3K94VUE5+lRW7HaCVJ/Gk1DPTuTxT7Y5j8s VSNdEtSbPyMQfmI71VtBL8wkIHOQamcNEMYJz61ErErgLzmpadzOO4pYFcEZbOM00dSCOlSI pVgcUPtDfrVLQbuwOUUEcA0kLBiSc8U8yMV2KoI/lQR8oCqAO9In0IyVDtnOTUbpld2DThyS B1HWnAsTtzx2o5RrUpiYAlMYPqaljcg5zzUNwnzkk/hTo5FMY6cHpSuXZ9yyT82Su4+lRyud xYrj2FK7HAkBxIeh9qpXVz5Zwxw3vVXFyFt8FNrE5I6VSkBXgetOjm3DrzT2AY5J6UkLluym Yy0gBB+tJPCGXBzgdKv7VC7yQC38NEkagDYcj6UWHtqcbqVrcCfchwuajijnjk37iB6Cupu7 Ysw75qlLZ8/Kv6VLizTnujPE5VQXJyOau2NxKyBn6Z4rNn+S+WFq3AUKbERQCKzbfQTlpZEj Tbojkkiqyzu33Fzj0qm3noXQNlc1f0vbBGRkZbqaftLoyu0S2V9ulKkH5T36VNeXjJuYcs3p VDV3VLuFYAME/MR9KYJc3Oxh8o70Kegutx63Nxjc0bAZrShfzITIDgjrVedojBtPQDiqVpK5 iIY4Hb3o57LUG7l65u524Tk9qXT5yzbbjIYelR2WxB5sh3HPAxUVw4W83rk5qZVHa4i1d3AV iqk9eKrfapE+ZycH0qItuu/3nC1cv2hNsvkgZXrmjnb2Lkrakkc6KqzBjuHaqT3EsszMGIX2 qAzEKOM5q1aFSoDAAGqU29iGwtpmDlWbcB0qW7uowAEB6VRdgk7hRgCmQSGS4CsoHpmj2nKi rOxZa72OqvuAJqee5REDpnHSor54GsHG1TIpxkdqpaUxeMB2GB60udoaXYtCW4JLlgFx0FTa dcCWJlkO1s8VWnlCKe+egpLGJRIZcNk+tJt3WoJGw+SAuQaYdyIY/wCE9cetRxvg5Han+ZkZ 28mtdS9lqOiwmATuJ6E0OwDbSoz60yWdYI2kZMkrx7VmRXDyZY5xSlNJ6merNO4cAZKgnpxW Q01z55jQDb2Jq7byloTt5GcHiljhjVg75P0ob5thtaGbI1wJRHK2PpV9JfLi3ljwOtVNRKvd L5e7aKku5PL0/LofbipTd7CRWnuZPN3I3BPNXYnaZF2dTxWdZvHK3yAZ7itOFdijaMc04Ntl yVkULqWe3vRG/H0q/ESU46nnis3UWZp85y2eKmsbplBX+LpRGXvak3uSXc4hTBfOTWaZJ9zO XLL2A7VZ1SFioLsMnkVWRzHEQ2CMcmhvUnoS2M25ySwwPWk1G4eR9seQTxkdqq2QIWR8qQT+ VMVgLosG3DGMUlO6KtoOSd4HAkdmzxk1oC6XyP8AazwRVK78l4Ac5cGqhkb7jA8nrTUuUnc0 ZDNJl4wWI61LbTAkK45Pr2pLKYwWhxJyaqOPMlL5IPtUuT3Hdli/uU88xwscjrUBaZWWUMwH tTFAEhyBu9akuJA8AiBxVc91cqLu9S5FMG+ZMg4796fJu2DccZqhphCqY2zx0NW5CT6tVxeg paMQFSDimNKFTofrTnGyPgYzVC5kJ+TdxTehPM3qMa4bziF6Va8weRk4Hp61lRIRcFmIx0q1 cMvlHacY9azi+oXImlkmcqAQc9aSOWWKTymCnHUmmwzYXnv3pt4R5oxRd7jbH38gUKFbcTyc dqpO7rgjr70qNslJkBIqWZ0eEnaAafMLYFnAHfOOaptJIznnvxRtZVLHoaLeTy33YyPemgZG zMr7T6c0yWXK4zSXUg3luhPWqc+3zF3E8elDlYEyYSS7j8pCjvS+apBPrRJMCgUHAxVIyfMQ BgClcB9zLuYDHTvVKaRo5NzZYVP5yDqCxBqtdzBzkcE9qlsaYtxMqwhg2M9qpPLnnceaJWBU K5GBUW9BwCKhu5SkiRZsjBNLJIu3gYqmxJkIAGB3qV0Lw7w446ipu7EtllCGTIOMUm4VThnX oCOO1SmUHkACiOpaLO4Y6UodTwpORVTzcKCRTw42bg2M1V2GhJv+Y5PFOhmPnCMZyazPOdZi nVT3qXzWjYZHOKdxM6ISkqAW4HHFKoZgSgyfWsz7RugULx6mrtncgFVz171dyOpDqErInlMx 57VUhttyqysQRzxT/FU8a3cSr/dGf0qTSpYyASeTST1Gy+iOsS881OiZO4U6dkZ1CdAOtSxA beRx61rckbsPYYFWbdOeBmoFGScE4qzaMElyGxRdMdxy5Eg569qvwRsxyBxVUnfLuK4q/bzq ihepzyaljbJclExnmm27TynaADUkxVskEe1JYT/Z5i+Bu96zbdhpE0EMiyHdkmrUZYfMRUMd 1vlLdDmnSyMORVx2DUtb1ODx9PSlLYRmJ7dKzUnIOCMe9XCrPBu74qk0KxXaVpBhSQaW3kki fczHjvUNrkOd/XNTTyZACjn0qObqBqbpJEWXIJanAKAd3FVbFiY+vzDtVo5RQWIJbtVxZUV1 HDBGN2MUxSUfzOo6daX+AnbwOtUbqTzWCRbhjnHrUyaiK2peViWOSMdhVbUTJgKp5PpUccrC ZUYEY68VoJHGSMng+tLcXUy0SUR8nJHOat6a77skkk0/UBDwicH1qOwRogcHJJ4NF9RXC5nY Ssq8YpLN5DJgpx61WuWP2zLHJPGK07eMoo9aFJt2Q42ItUDrGdjYzRpsjNEAzHjrmpdQ2i1J cZPas21lZXDZ49KTb5hyszYYiLcwPOKzvNd5QofljV9pvNgICrk96zYomS6JOAOxobbYrEhl eOXbk9efetCNsjI+Wse9lHmqCMtntWgZY47ZMsdx4INOEgVi1Gfmw3apM+ahRQcd6yI5Ji7H cdg7Yq7Y3LnoCFI5NWpJjluWlJAAJ6CpAu4gDJ9ao3MrpyMge9Os7t8BQRk9cUOdnYlrsWgc uRgjHel+VW4bJNMu7nbCAqjNZ8ck4bdj5aOdLcHc1XII4GDQEO0E96rWsjOTvHHY1aY/Kqg/ hVJ32HcagGTjqKegAU5Gc/xelER8sEYHNQXUwRdq8H3oYrlpcD7nUd6dsLAsXC+prLSWXYcH NWYXLWkhdsNjgVHOkF7kE8xMpRWzx2pkBeJsuxIpthKsdwPNQE1Nq00cqny02nHas3K4FxJT tLKazrnUJjegY+U8A1ZsRJNbhWwGA/Os24glS+B6jjiqlO2wdDejXcoLnOR1qrfzLbqdvPNW rdiyAHB44qlqUG4HPTNVKTUblLYWxnaQAsCMmtLDBOnHeszSl4CNg88Y9KuahKYf3cZ4IpRl 7upFirfXRV1CuMg1dt7hjCZPvZHU1gXURZ96nBB61u6X5T2wjHLEcVKk+YexSP2h8ky7Tu7U kc0y3Ww/dHJNXi8EEh81NxB4FZk8gnvwFDKM546UO6Y2bZAaAMoHNLDlFIbk461VupjCqoD8 uKqR3MoLZfC9q0U0Ju6NV3WOMFjj0rLkkmnnDRtgZ/OrKSrPa7V+Y+9VrKUWsucDA6ZqZSs7 AtSSC5VZ/JZsP71qAJkPw30rDIWW5MoAZietbUYCqE745pQlzFRTYSNuAYZAz0p4Maj5yRgd qY4yo6bahvmxBlRzitNhNoqT3jG58uNCR/eqS2uyCyzdT0NM0SW2DSNdRlx0AHY1DeFPN3Iu Fzxms+dvUV7F+4k8tRhgSRVK4uLmMxmMZBPNRiTfIAxyOlal21sLRVAywHUUKT3Em2Pjui0f mFlzjkVSkuZXYiMHAqjFLlSF3DB71o6SyKCZ+h4NHPfYdyW3uCQFl60t9OUQKjZPtVS4IFyT H93tSQsTckuuRU+0Gh6Xc0WC4JHfFajSPFbJMuD5g6VRvDC0ClFKt0NVDO5TYWOB0pqehN3u WZLm4A+Vc881bsr0SBQY8Y+8fWm6WYVhbzyOVOD15qipVbjapOT2oUmtRk81/NPM8UeflOBx UlpeTLJ5cvDDtVsQxQRLOAM9/WqEaPc33mKAPcmndom9mW7u7ERCx5yRk5qkt1cGUEqMZ5NG pwyiUDcAQeTT5pIjahFU7hUKTe5pK3Q01mLw+aX/AArPv76VMLCu4nsaZAssdrk9+SPSn6Q0 UpkacYYZxmmqjJvY0bR3ZFZ+GxU2GkJb+lMi8sRB45FbJxj0qUFmXaua3WqKixG4VaRBluck D0pWjk2BgByeabLJ5MZPrRshKSuSOFQgjoaZNJ5aFl49qzpNSMfzFM47VZjmW5GSOD29KmMk 9gbKR1OSRyVRlIOMGn22pSGXY+auLZpuOCAevNZN3Gv2tfLBznms5SlYfMas12sUROcqRVJd RuHjCghQOgOKdqDBLZGbaD0xTLG1juYjIVJYnr7Ue0ZN7li8VywY9AeM1NbOHw7E8cVDqUjG ER4PByMU+0UMOPTP1ra5UbMsXLFwSOQKgiwoJb5s9PapA+FO3PFMRgwyOPakr3E7dBzZC7yC RUbHIzgDPrU5cBeSdo7Uxtkkgx0ovqIahMeSuCTTlLSAh8Aj0pApUkZFNOQ2PWluXHQbyQFR R70vYk5AHenIACeof+lEpULzk1SJZRvZo1hIkGH7H1rMN/GnG4DNXNTGAO+RXPXXzZODgGou VF30NyLUbcqN0m7HTnpWRqN0J71dq7lzyc1nklOzVo6XF5pDlCDmh66GkVZGtbKpKgHBxzVh v9Zt6061jLEs4zgc01w2/KYxnpTjFohy10JowobLYwDzmpJGUklF49KTYAQOvGcU6QENnAHH aqM7tsgdQVDdz1qGQNxtAzVnaOc1C5AzlgtFyrMwL6Mi9BZAWJzmrMUUgLMegGabqZWImQHI Heqa6gHi43K5GAK529xWuSu5w2Dg1NbQPJa796gg9B1qom8w/PkuevpTbLUlspWV8k9uKlLQ pp2LFyQJVU53e9LGSZcEYJ6VELtbqffLjrlTirMiiNlmHK4pWuQyc27iIu2dpHGaqn5Y8KBj tVue/ae0jiTmpYbGRrbzcYAHNNx0AggU+WBnJqN94cYAJz3qS1lEJYnOe2aVR58m5uKlL3Rt alVQZLlg447GrDxOITxnjgGluEEM6sASvY0k10ZDtU/NVRWgNsqMrrbrkgHvUsUbSKoBPHpU xtmeDpkDvQk6JGEGAwPWmk4k2uV7hNsg7fWoo2Rp9qMCxGOtWok+0TksSFomtUtJgy4IPXHa peupd7KxFLaPBE6bTuPJyajtYwkRZhg1aurxpVWFQxP97vUU6MkHy8sOoNU9BJlaFGmkznOP StKLMWOenrVOCceRuEZQ9/WpNOkknZtyEKvc1St1HZl1GDSbscmp2lO7aqgZ4NRjAXIzkU9O c8fnWqBu7M/WN6ABX79KfZ7XtwRxijVoPOxweOhFV7eXyYREDgjrmsppc+oJl6OMqMqMA81H dypDCxYnpUdlPK0jhkO3oCTRq0Tpalwu9z0WtHZR0E2yOwAkXcOQe9Wb/BtsNjA6UzSTmELK Ar45A6UuoEGMgjIFRH4Rbmfo7r57lUAJPpWm/DMAcYqjprgZ2qFq8mGkwXAzTpMHdmXd4aZS Ad2aS7RomR0A560uqtsulw/X2qOdpJjGASADzUtaghdRuMwK2cnGMCooIGngY8fKuTmrGoQr JGPKwMCqbSkReUuQwGCR3oSu9QsVrVmBkXbjBqvbuftL5OB2qaNDzubBNQXKmEghSQT2oSSQ XLEsTKhfPy9qjJDAMGOc1DczSeWFXJFaGm2rvCfkB4zmhq6DYfHB5pXa3IGaibzFmxxjvUyT +RlSMN0zTbeJpZd+889qElYGMhjLTttftwDTpreVIDKVwvc0t2jW9yGCEZqK8uXkRYmLbCe1 K1gRJp6l/wDV9evNWWZ+4waitlCRjbkUr7i2STWkBtdSQ4wNxyD2B6VQmtyZsoMg1aLBW+U/ MetNLFGyhpzVybXMm8V1mAAPWrN06i3BIwQOTVe6lkku8gEDPNWzGJrdlx8xHFZJMq1ilDAZ owVJHOabdFhIM/MBTo2ktoyrcY4zREwkcHGQaoVyu3zzc/LinyIRGxJwvapLuIbs9KrtM0o2 Afd/WqSE3dkG8SRYBLKKTBaPIxjHSpkQDPGM+lVidpZQKQEMrdM4zVd2Bm59KllG/wCYr0qC 5B+Ug4KnOaTVx2FkXC7qpNMPmG4VPdXZkXIxwMcVTKow4496BB5mQQKrXcqIo7MeKY8phc/M faqd3dGSTDYPpRYBZJQeGGTUQdySuAAOaguHxyTzVGe72nO4+9JRAuNOd5AY0ST/ACEBsZrH kvMsSOlNN7vJ+Ujinyga8EqxKR1JqdLgFT61z63pYcmp4LzdxyBQoDubizFuC3FWLdo2BjwT 6VixzjPBq1FclBuB5pOIXJDIVuyjrjB4q3PuKqePrWXLcgybjkse9SR3fzhSc8dzUrQd7Fme aRdoDAKOtXdMn824Vd3GRWe0kbApgZp1l+6PmKDwc1dtbiuW/FKodQXy2PAHBq7pMTOqnGax bi7WfUhvb58dK3tOuCj4TgdyKaWoM0QCgqdywgVhwpFMkKyIMZ5qVFJtsNnjp6UO99BC2CMU JzuFXoYh5mWGPeqNuDEOOB6VoQuzYB5xQhlsRKQAWHHSnyQBFLLnJqBiwIO3pU0s5kRVBwQM U5MRYsj5iYIHvVo2qlwQM461WsVEcZDEkmljnkidssc+gpJq2o7jJEK3W5W4PGKs3MjmJUBA I/WoMtM+8gjJ6VLOmwrg5zU620BsrzRlkUsSueeK0IizWgG/AAqrM2+NeOFOKu2u0xiMgAet ESr2RWihZpQE5JNS3cLRjaw2yL1pu54pS6DBB4p0zTXDbpCWJ60LawkyexL+WM4ye9XkUKNp bPcmoIYjEi9CD0FTIeeQDWyVkNIbcFxA3lkYNULLeXyeTntWhMCVIA4qjFvhkyg4rKbV0TZ3 NRIo3UyORn0ps+1I+GHArP8ANmaRiqkCr4iH2ZSMknqKqO90Nooq3nS4z0rTVMW2QVzjp3rM s2zfsrRFFHetVzGDuXIFJWeotjEni2Xq7nBLHgjpW1ENigZyaxrhj9qCqqkA5Ga2LaQ+Xkrk 0qb1YEeokG221QtEQWzN3FW7/csJIBf0FUVMnlfOm0nkihvUFuWNPcO5AbNXHtY3y2SMVT0y II2cYzzV6e5hCYAKyZ59DTjtqGiM2eNUmAHJ7GnaigeOMj/WCnxrJNITsIwakuoMqAWKkdxU rqC1JrBVVVMik8VMURWYxnr2qmLlxEF/ujipIC7JnHJFVFoaV0Q3DtLIFBJA96jsXAuGVQww eTTtjwysArZPJNPt22HcF61Cd3diH6oygq2TtFXrPy2gB/iPrVK+jaWEELuJ6CiGVggQqYyO 1NWb1HLc0Y1RRhcVLEED7yuT6GqVizSgttIOcc96tqQGIP61rHRaBy32HPkg5AB61n6gI/Mj Ysd3pmtNgQc7gcjBrN1SFWwQM46Upt8pJasY43hWPADdcmnSxKI3BGMdxVJJ5Ug2KBuqeF3k Qb1we9SuVopWKduEeZh82R3pbu1Ma8seealkJhmLIOBST3Et2RuiK9qm1lYVyxpayMpyQCP1 qC83fbcnAUVdt9sMZZgTjpWTdSSy3DNyFB5ApyVkUldG5CqmJWXIOKivztgOAGY02yn+QZHy 44puoXKbQojww6mqb9wTehFpuAVXG1u5qfU7bziFBPHPBqpYy5ckjnNaoYnD0ormjYErmLdW 0gTaDgd/er+koYoh3GKg1ViD8pPvU9kXNvuGdvoai1pBZluWGOR8OcLjrWbIgjugEPyg1YW7 aJ33IGyNoz0qty0ucZ3d6uVmxbDNS8xmAQ5BPJNSx2NzLal4k+XuxpbuKVFU46dalhvwls0Q Q56+lRy3kIkEJtbTCsCxGDiqunWguJ2ZySQCQKuCOWaHfjiqdvM1tM5DEN0NNpcyKtZXA/u5 CYkwc8itcNvRWHBxzWQhM90G3YH8620wEUjr6U4KzY4uxGjHgNgDNRX77VbYMkjGatY3J8wA xUMsQeFum6tnsQZVpE0gYggHOaJ0KnDAVLAwtnYFd2KRSLtt23Ck8Zrn0sCK4XBA7GrX2eRL fzDytS3lsIkXHJoku3Nv5A9ORUxvbUpXuURjBIGatWkTTfKBj1pbW0bySe3Wlt5PImId8cdB TirMlkM8ZhfAfJ7UoO5hyA1SiP7RdDAJGaW9gMUweLgLyQRRya3ENEE6xOzDeBzUEZzFll5P 6VeuNRju4lSJfL4wcdSaBaZt94OPahxvsNMhjt38kHPA5zUaYW4yfvd6sLMseI2yRTLeMzSO SMc1STSKbZZvJ4y626lmLDt2qxp9usce3JznjNZ0MqQXR3ZyDjIFWZtRQ3IRQTnocUJ3d2T6 jNXkKSqjAcnAxSyWYS1EhfkjpmnamNyJL6c5Ipsl2ktoIwoLj+Luahu9xpXFjDNp7SbjhevN Q2NuLiNm+bj0qe1RhYsm773UUmnzras6uSBgjilF3JaG2n7m4EYckE+vStqMFWOCT75rFgjj kuWdOpbINbIYiMAgcd63pO61LWg4SHaRg4+tUNXY+UFU5z0q4qndjOQao6srrt8tc461U/hB kunwRSwnzYweOtS2dqkUjMvc9DVO3v4oYCjk7wM8VbsLgXJ3MSBjioglbQncdf3KJG5bg9sd qq6WvmHzTluKbqyneCOmeav6fNtsxGsYCk8HvQ9ZDM3XLcgK7HPfFS6Ssgh+UcelLrEi7Rvb kVNpE8flEE8diKSXvajvroUdQyBuDfN6VZ05j5SyODzVbVsCVZduD0NWbMM1uG4C9RWutxtJ ljd8pA4zSRRkL7UnSnqGK8HHrVCVxFEfmFi20Y5pCcx5XaQT1HWjC7mVlDUgiQKNilfak0Sw JGMY+bFJGCr/ADLn0pzbehUgjvSEMcDdg9aEPdAWJchlw1MO4krjNTZ2od2WY96ZtB78mhFQ lYy70B3ICn6YrOns2YEYxn2rbkTnOT1o2qDnG6gpS7nOf2bJ35I9q0NOgdCBt5rUC8FlXHtS GAqqydKLCclYYUIzt4J60JHg5xk9zUzRlUBYFc8896RAxJAO3PFFyEw4HOcUhQlMg9qV43ic KWBI70jDnercnrmhlqPUjkJxhcDNQSgDH8WPWrLrlQegzUMiM0rJ1wOtTe7FJNGXqUYlGBgc Vki3bzQR0Fb88LOmR8uDSLaLtyNtKUUwijN8tmQrnkCqBgLt+8UZzW/9mO7bjt2pJNOyQzLy KTirF3SMqG22MAcewrUgiKsQ6hlI4FItkd2/cK0raAeSWIGB3NCikgk0UorULghRz04q8hYJ s3ED0pOh4HTrSk/ONvOacYJGT1K08CSHGOexxTkj8tdoQE1ZZSclQM1E6OoDYGTQoK9waGOQ V8lo9wPQY6VDFZrkh8Kw5HFWFeQDnHHem793zN94/rVciYakaq24dj0I7VHNaoHJZQamdlUb uQTSqdyjI/GhxT0KWoxY0CgLgUjW+7gsMetPO1AVVeveoy/OBSUElZCY1bYJMAgDEc0+5USN u2bMj0pUPJGSDTSZGJDHI7UnBWBoha2iKBR940/yBCdgb8qGcA44zSqNy4FL2MR3AH5MKeRS jIGOc96bwD2zTjnjdnmtNhJai54AbkVDLaIw+bA54IqQnHvSZJ6dKmUFJluNtR8MccbDadwx TZMEn60uCvA9KUMqD7o5osrGbI1QKflH40ydPM+9xn0qVcAjJ70MecihpbFasqxRKnTsfSpX CEhwBT5CpGMYNCxB49u4A+9NJRCyRVlhjkIZl3HtSJAq+571LtKEDIJFOCFmwv3j1qXFbk3K 7xBgcDAqlLbqWJRcEdTWm5K5QsMjuKqyhivyfiKHG7GnpYzHjGc4/SkljRhjaeOtX1iIPmcZ FN2+XMJcZHenyoVih9ljYAheK0bcssGxAQO9NLZlJKjB6Yp6krkEYzTSsMheFWb5lyfpT1RU IAGfSpNwVuKauA+4dzzSskNojnGSTIcmmLEqkZC4PrU8oRiemKhkIyASDRZMTGkAD5eg6U18 t04UUrMFDAg9KYBiHA4Gc07WDRoYMhyAoJ96RhuJzgUKSGO7r60wEA7QcH3phsxXgQyqpOBn k0SIsTMqvu54NL0PJFMl27s4GKSikJsilSNh+8YYqNI440wn4GpGVTwBmmyMAuB0HSly6hYj dcqAeTVOdEVjtHJq1u54PJqKRlJ9+9O1gtYhCfL2FVpUQ5J5NTsPlzmos7upAI70WEVXVSp5 OfSqkozxxVuRvnJBGO9UpyMkihpDKzoi5Y4x6VRuGCE46VZuHGOeeKy7iT5+TkVKiIZJLESf Nz04xWVdSKuSp5NPu5NpIU59KxNQuSCRnBqlFAPmvwjMkjA56VmXV+DhcjGaytVuSsm7OKyJ dRGSCwp2A37i+VWIDcVFHfZ6yD865K41Lk4P61XGpEDrz9aYHbJeAlgGxj3qxbX4YBQwBFcI mplmyWq9b6iu7lhSsB31rdq2cvircVxxkjIPeuJstQVmxu4+tXm1SRV+U98daGkB1izpzmqV 9eCN1KdPWsSLUi7bSce9TX0olsTtBLDnNQ4XGtToLSdXXeZPm9K2tPu0MBRhyR1rhNAmeQYb PtXWaeCpBIyD2qooRbjtw1z5oHOetbtpJtChkAqhbRYO4jp1rShTcc+3ApOJVzVglWUjaMY4 q8hGwAmseDhx2NaERPHOQaIiZbKIBn72f0p5nitYxJISPao1Palv7MT28ZZupo5QRoWU8Vwh IGcjirccMeAzYzWfpUHkR5JHHArTiHHzAYp8oOxMgBHbFOEaMQWxTYskEcD0p0Y5OalofkTm JEYYbcPan7YyoUjJpseeRipIym1gRkmqSQKxGUUDhc8+lWEjj3gZwKao8tdoIxTm2k/KcnvU 2Q2kPMEMrlMnjkGmJEQ5X9aWLGdwJBHapgQ2WxihxQhSGxj070AYb5sU1Xl3kBAE9aUj5wDk Cq3L57Ifx5mORmmtBGWwSRUjEvMFA4A600MeQwBIPFS4JkylcRYlQ/LyKkByOOD3pAeKbE2X ORtHYmhRsCSe4oQB6kYKQAKJDt+XI+tIoIbJ/WqskDj2InsovNEvc9atRKgBwDgDgVGwG7NO DqDycVCSFyjgFxmRfyqJ4o2yQmQeQakkYKoDZLN0oRTkBSDVNRY1EREQR8daSWCJgoZcnqDU 2VBKcYFM4Az0FHKmKSVxYU2xkqcHsKAu/AccnrmkIV2BU9Kk5CsSdzdhRypCsRG2Uy9sdjUj IYvlC/N60FVKYLbT160+NvmAYgqO9EYq4aoi8vqxJLHrmiOPk4UEVIcMzBD3pRhMYJ603FD0 ERRnBHbijyQ77sfNT5WVCDnk07OF5x83NJxQnqCqqR5AyRTjucggAetNwR6+1PjXCFWyzDnN UtBp2DjODyM80ksak7VG40qoMhiRg9cVJKnzhomwMUNCWrIWtRGwZ1AqURqgyMYPSk3PuYM2 4kd6aAXO0PjHrUqCTuO2ojIkpOUpRAiupAOPSiQEEbTnFSAlT8xGcZGKLK4mhHKuNgUBQelR rbRkncdox6VKxDHJ6mkJ3DA5NNxUhpjVULhygCjilkhidgSu7PJx2p0asVKOwAHapEXCYxgU ci2GkiE2sIwVOD6YqdBlCM49qRMuxXjI44pduJMFScelLlS2Fe2hBJbKxVmGAKeka5+WnOcg /MMA9CacFUIrA/hQorcWpBJbRynL4GOgp0cMYHIwexqQ4DkgAk9aVeuCafKr3C3UR0LxiI4w O5qGO0jJ5X8auxIpyJGwO5poEa8ZOO2e9JpAwVFVdq9PrUDW8LSZYAjvVsIhHPXHIqukZ3nj imooTbCO2jRhIExjoDU5HelV8n5xkUqrvYgDimlYaGM2QCBx9KPlKkEdelKSA5XBwKSQHAKL 370wdugk0W5E3Ig98c0RW8cagJg/hTyA5w1OeTCAEcDip5Ve4mmNKKyneCfSq/2aMyBsAN61 azjg849KcQoTfkUOKYDFTHAzTZLJJG+ZMsfaplIUgsueOKC53btxz9aHFMLXGxWv2eTk49KV 44yvzqST3p28tjzCTTmkCPhMsD2PajlVrDS1sQQ2VsDuZcegAqywjddhTavbFRoTuJY9emaf J0AzwPQ0KKWw7JMrPYIDlQSo71KibY9oUYb2qbeFUKxwD2zTd377ci4VRwKOVIRWltVLZGM/ SlaygO1lXkdT71ZRjIxLgiiUFcP26ACp9lElK7CaFZIgjgFe1V1s4kfaqc+tW1YlOOM0qA8B Tkj1FHs4jaEhgjWMqy81A+npIhchevepI3G5l/iz3NSSMGj5JDDqDT9mrAivBZrCAwA56cVa i+8c4/GmBiQpPanKwyd7AE9KaSWhWw8HAOce1RFQ7fMM0OxZcg06GTMYU4+tN6g1cqSaZDLM S+FJGalihSOMAAACp5iWZcjkelMOMkEZFJRSKVNX1EliEygMOnU0+3QIMdVHSlPOCrBfUetP wYzgHqKaityWkpaFO9sluvvLlSc9Kfa2kMA8uJAVA9KsjcgADUcKmQdpJ5pcsb3HKzMjXWCG HOAZO1WLaIpCp3Kwx2PSs/W0Z2VWYdfTpVvTYgIQTlox39aWolEssTxtx+NPLgrgZz3zTSeM bcDtQoycU7hZ2E3cnHBH60pY7BhSfr2pxcq67UGB1zUZkkeQgjAPpTeo07bjsllIZwOKFYhQ WOeMUdPl2gij6A8daSViXqALdSRmmkc7znNKBuY45H0pCBuO7Bx1xTZUVqRgDBB70bVBIIOe 1PVXlX7mBnAOKbMHXOTz0pPcV3sNAZV65z1pz7zCAD8o6GlhOYy74IHGKYJAIio6HnFAmriN JJIg807tvApCzY4zge1CguePSnRlkByQR6UxIjV3cjcTihmXkd6cW5wV6+lNYBvnGAemKVy+ bQQcqTu47CkUkHPNGBg5pIzuPz8ADik4g5DZVZ0KkEU2NBjBPSia5ESjJJz0qot6jyMCDweT SUknZiTb2JLiQxkvtII/Wqaai8+WUEAcYq9I6zoSMED0piwxQxkpGMnrkUpOXQrbcpWU8jSE yEHnir9xOUj+Xqe1Z9uEF0wVeScnipNUcrIqpis1NtXYSaexKl9mRQUOT1HpVqWVUQuM49qo RWymQOvzE9cCtC5Ym32hAqqOeK2Um43FNJIq2V75zEKTjOOatyl0fawOMZBrIhnRHyq5BOOB WpJJG0Y+YnK96UJ3DoUri7eNtqEHd1qGG7lQfvV4zTcbbsFgGBPepNaKKEwV5xwKiVR2uhJF wSmQAlRtpfm3gA5FQRSCOx8wkAnsahN+oQBQTk1ope7dlNWd0XZSQ2GPHaoww3DGNw71HDMJ F3d/eo5LxIcggfNxnFHMgcSxI+8jaee5pHVzyGIxVBboCUB+hPBq206KhctwB0o50iWmR3ks cMKuWy3Qin2cpki3txWTdytMpZVyOwNXdM3PHgjFZuo2xpXLpVSM4ORRudhy2COlIr+nagsO 1bWuh7C5JPJp+cDHSq8lzHDGS/JzxVN9UkEm5k3KelRoh83NoagK7eSc1XuZliIwcnHSoorl ZFyDVaOUNcliAee9DkTLckiuZWl+YcetXY5G3B8g4qnqDROgeM7PUCi1fzYtoOM9KlSdyW+w tzdq1wB0bParCMWXdj8axZ4XivuTyTwa2InJhCY6d6IzbY2NuZBGm9mGar2Vy0hYhiM03ULe WSBnRgAPWqujiUDMhHtTlJt2DQs3kjIpx1qKyuHkiJkUhgetSX7ARlT96s60uGSRlPOKHKwJ XZqsy7eDwRzVCadw+xOlXLdxNHsRQCDnNRNHGsuXGMnrTbdhyKaTFHbeTjsKuNIh2sCenIqn qJAmwgBWpAhljGxSDiiEri6DJrtftQizjPSrEZIU5bkVkXMUqyo20fKec1qo2LHJxmhO7sK5 Bczu0h2A49KiEkomUt93FR7ylwQMgEZpLty7KFOAOtQpAXyxfJzk4owBHktk0lsoMW4tg96H IxhcYrVaoexGzBhk0kjoG+ZSWx2p4XOQMZqnPMFYgEE9CabQJ2ZOxU4yOTUTPscl0OAKrG6k 3gsuQOlLqE0ksWQ2PSpUkge9yN55MMyjA9KS3uVYfOh9KSBlEY3nJPWq12rCQGJ8AnJFSm2y S47p1A5FUXl3Oc9aWSTjA+9VXA8/JJq2x3LRIIwSBxVG6mKttUZNXWKsCduKz7qPD7we1Deg hoG/cxJBxVK7k2g8flVpWJXr2qrcrkEntRugMi6kYPksQPesy4lkYHYOc9avagSTxyaybqVo 42UHb60RAz765OSM4bviuV1y98skB84rR1W5IBIIGK4fXbwncc1QFXVNUdyV3E1jS3Duc5pk rl2JNMoAcWJ6mkyaSigBcmnCRh3plFAFu3vHTjJrZsr8PGQxrm6mt5CrCgDoo7h2lATOQeld PYK8loMDg9a5bSVLyAmu20iTYACgxjpigCxpFsIpAccV1drEjhWUHcPSsaBAXyvy+lb+lSJF 94ZPapbsBftE5+bOD1rSjULgHlfWqKkM2/gH0FXVl3RBcY5qbgPfCyAKuQe9WIDt6mqhbNwi jI4q6ig9OaUXqBN5644NXLdhIoGTWd5IxmtGzB4ximnqPcsSS+Wqrgk+oqeOaQDLcD1NOSM8 EhcjrTbmQSxiNQBzVSYNF2CTeB3+lWRkAEcD371SslAUAEDFTyy/KAe1K/cb0ZcZmEmBg8U6 PO3gfN3qC0ZGYFjkZ9akuZVVMLxzSUkitGWI2XaMqM5p4Qbiw4rPjmJOSRirtpIHVhnJoUk2 SydQpGM4NKwIOAecVRWdmdlGMjp7U+GcGTy3OWHelzXdhrUtlWCgBs+oo5Y7c05Anl8E7ieT 7UhXa2P1q7DSTeo5SQcZ5oIBJyeaQkDJxnFVZblfOwo61LfcqyLZGVG04welV72d1UACmwT/ AL0qw4Bq3Ikcj4yNvapeq0M7dCmzTmPfycCpdLuGl4cEt0NSXbKkHl7uB0FRaQJDI+QFT19a lXUrFXurCX108TFVUkmnW05kwXHTiqszH7Y6kZTNX7eDIDKQE9O9NN30BD9QkdADEQSFHBpt hI8seThW9KW/Ki3HTd61n2czI20ndnuKrmd9SXc1slVJIOTVKW4kdvLRT71bWV5YSEUnjk+l UrVo47kls4zzQ5CY+3uXgmClC1X5rhFizt2sTnNZt64e8DRDAqW5kDwqjDpUqV9htaCvPJI2 /qe+KmtZecMKZbmAQ4ztY1X8xlnOBx60KTWoi3czshKw8MahimnUgTg7u5plvJ+8JbnnvU11 IHTco6UObY4q5aMiGHdxu7Zqp5rnGWPvUG5tgGavWLRKpDoD9aHUutAsrj7W4c4z90dM1c3b myCQO+KxkYm+ID4T0rZjjPlnY4OK0i7oGiUeWBlRwRUM86xxHOD6Uu4napwAKp37hDlRkd6J O2oWIfNnPzcZPNXLabeADjdUNrJCIGVkLEjj2qASbJDt61nzNak31Jbq6ZJTEqnI6+lNiupE fLgqB0J71DaMkt4Vc7RjkmrGqi2eP5WI20OQ2y5JN+6DDkmqJvJUkDpu47etQLKzRqFPHart q0ItyCv7zsaHUfQEWLe4EilujNyQabcXDgFR1HQVnhmjl37qltRvvFMr/L69qfP0Fcfb3Msc oDgknuK0fOMCly4beDx6VR1AqHcIRjPBFVw7FQzGkptaAStcP5mQpIzwau28rSHbnOOtQQGP yCMjnmqpbYxKMRnrTTad2BoXNxhAqABvX1qK3nkWQBxkjvUVrteXEnIp9+0RH7obGHehzbeg 7svSTsoZjWfLdzn512kA9+1RGUmNQ75rRiNv/ZJj2AuW5b0pc/MwZLaTrIo3MMkZJpJ7zyGy vGfXvWfb7Uk2KKNbtJG2MWIA5FWpe7cll2yuZLncxRgoPBq6u9AGAxu4qjo5f7KV3AY7VcaR miCjtVJ3GtR24rIUfp2xTo3ZSVVM8dTUaEhcnkijzFClpM59qoCYDCkkck8mmgActlh6VnS3 oLlUyFzwKmtbrzGKkEYqeZXDchvbx4H/AHaE9qhkvZ408x0z3xWhJbK67sjrVfUUVIkBwWNQ 5MfUns5ZLmESkYGPyqtNfFH27ScVLYMUiYFtoxyKpQBJLkhuQTSc246ArXNW0lE3IPHXioLi 78mb5gdhOATU1rAISTHwKpa0wyCEyKJSkkHU1YyGiEijcrCmSs0a78cA5PNVdLvVNvHGcbaf qikQsyv8rHj2q+Z8twuQNeyyOT5eAOmavaddpcAnPOMVRszF9mKSnLEcGmaWFNw4Y4HbFRGb tqHU2UIGc5JpzHcADnHas+a78oYAzSwX2/AbgDirU0GzL24qFU9DT2z/AA8/SoZpYosNkOpG arJqQyyqML2puaQmrl8RtuyMDjNUbi7Csckk/SpDMj2xcsc+gqjZRo5Pz5BySTUTqdh3sW9P uzc53/KfQ1dVgxJIAxwBWNdlYZg8TcVp2Km4XIHQd6cHfcpK+pM2CmFGKfAgjXgBqH4zx0qO V1jQSMflPaqbKVmOGd5wcnrz2pWR1GGIOfSqR1RInKiMMPpU32lZlLIc+1LmRLdhl1cCIMcc jpioLbUCZV8xCwY9T2psKie8MYOWHXPSl1G3VcMrAc9BUKo7XJUkzWnPlxhjjBGazp7zc23r ilcvcWYKNyBjOaxvJnSQjfk+tOU3YaJtXljW5IIOSe5rQ07cIAg+52FY/iKSKW9hzkMh5P4V saWzm3DdUFadSr2J9xVTkZPSgj5ehBpysrOWwSe1B8wNlgDTE32HYBiIPU96j24H0496fJKG T5Qaji8xznP4UrBpYcpIAGafcAgoUBwetMcFSOOtKrMOM5Gc0NhyNK4u1tuFHPUj0pjjgMgA PcetOLs7hgSD0NIeHKZye2KLCcuwAybPlbj0qKQjmJ/vYyDT3kYDgfNnmkkZdudpNLcFKxGc JGFIOc04BSgzjmnscoDjI9KF2gEMOcZFNApIYFwxAIFRucnGaUMzAtgjHrSZzzge9CG2hVJV d5G4DtTF3Mu4jrT/ADSu4KOtMj3NGTwdtFhRegbcgHI68+9MkbZJgKQB37UrSMUznFPVvMi2 9/WgTMi+d5JyMgZPGKsPp/mxiJQVc9T61TvInjvwc5Wrk98YYlkUksBg1zxScncpaakkMBts RKc9jk1Fq8jKFSFlLd6tWjiVfMIyCMmsmeSJrxjuySelVJ2RLfMyxZ25YbyMMaqavbusoy5w e1alqccrnA9aparMJbpQxxx2okrQGty1p0G21WQHvjmprn/UO2Occ+9R2p/dBQ3HpS3PyxMH JA9acL8oTk7mNZRoUdlb+LOKsWrbnGchfSm2zJuZgAP60yyEgvfMc5i7is1ok0NSLM1qkrbu QAeMGqGo24idJSxK5HBrVkuIlU/L0PFZ2oOLiRRnK9eKc1ZaA7Mj1Ab7VSuQR15qW3gV4wBj cR2qPVGK2a7yuCOgqC11K3t4g5kGRxilF3WoWZo20UcO5XOeDWYHaW7aNgMds0+z1/TJJJGu QSuDgKe9ZFpqlk2qO/mEg5wPSqlaxUUjomtQTggEjke1RX0TtENhx2qOTU4VZUicln45qVbj aPLchiec1Simib2KM/mRwhT29KsaPJIYd0g2ml1S5tRAvl9e+e1JptyjYVjnA4qOWzFfsaJ5 AOaaQpO49veoXmCnNMM4zitubQaempBqbkgcA59adapGVCnG3FVNXuUyNilf72TVVNWghhAc j2rKTuy4xW5t2kcYcrjC4qjb7GnlijJ+Vu9V7bWIfnDg5I+UisuTXrW0u2HLHPNTLdEzi2dB JC8MRz8xJqbT8Kqlx19Kx38SW94UhhQjA5zWzpkiC3D4DA/mKpR1uLoNvlj89SW6njJq1HkI B39qzL90e5Q4yFOetaNu6lA3XPQU1a4rDrwILU/eyRVDS2RSdwOc8e1XbqXERVjgdhWbpkqm 4dGbAHeiTV9BLzLN/hYGxlifaqEMaNExJw1aN2uLRnQgn0rOiaM2pJJ3HsKJO4DrCUsxXOD0 NXpId7YY7sDjFU7BAGJxwamhvfnc4K7Tj61cdgepSuYdjkNzk9zVqNwqqo4wOxqveyLcSDb2 7UFvLj3dPrUQeoWZBqaH7Qu2QjHPNWJ5V+zrj8ax9SmZ3Ds52+1Mt5mkQlXZsdqSeuhSRcDC eULu5FFwvlMM/Ng1WtPMWUsUKmprkb3DZPvQloSy9C5MQ96kTBHXGKgth8vOelThhnOM+tbL YNwmwyHHWsobVnKEdfWtMhihAFZcvzXWSelTK4ixJHjaBiq918qEYqWS4VRs43HoaSUM8W4g Z7mk4rcCnErOgxx70lzkP1zipYZhGhXGRVc7pXyoI5oRSVwlhlAV0wc9RVaTeJsFce9asRKk ktjFZlzITOxVtwJ6UMkkjHynn8Kq3zADGNtWoyNm7p6iqV66ORt6e9U9gIUX90WXpVK9k2KV HINWjL8rIDgDtWZft+8xng9qSegGfdMVbcKwtWYsruMcda2dQm/dBFAXFczq0paFlyeatAcr qtwMMX/KuD1iXfOwB4zXW665AYEdOlcVenMpNMCvRRRQAUUUUAFFFFABT4fvimU+EZcUAdRo QyRjmu20eMPwVycVxnh5RwTkGu2sXRUXZnOKANu3iwMHir9sCAoI79aqWUbNCGYGr9sWxwMA dKze4GlFwcgE8VejViox1qhYkyMccYrWgHc5HrUW1AVc7lHFX7TCkgrmqMow/wC7BArRtvmj AOBjrVRQBLsxwMGrVkiAgFsE1UuCCMLyR0qzYMxwXXn6VVtR3LsrBeASSe9SWUJmlyQMAcmq cjFXAPepxOYrV2UEEihg2WJXWJiAQfQUwSl/l74rEt7qWZyBu3g85rQt5dqZYZNS1cDQ0xmj nZXUlSeOelT6iSjnnd7CqOmyEXOXJ2t2q7dorTGRM4xxUWtEadiSGJTAp3EFqswxERsQwG0f nVWK4AteIiWzxVovugyAdxHShR0ug8xtqoySDjJ5q29siOHTkkcmqFoSkmHOc81bW4L3IQ/d ApxikhpltAQOhqRUyOOnemh8gLzxTwxB/uitFqE1YimdI4WHtWfbssky/KWBNacyK8RJ4xWf AVjmD5IXpipm9UF9C/JZxh8ocdzUiABCWA46VWFyGcqoJqy2XjJJAwPzoTQX1uZk7vdXIEbA Ip5rTig+TYCR6kGs6w2rcSfIRk8itRjj7rHFEddRN3Mq6jdJ8J645rUgVY0GRzjrWXNLK1yy ONxzwRWshXyFVeWH3iamn8TBEGoo/lA7eD3qpDEi2j5Q+YTlWz0q7qBdrUIJCKpW0yqjRBS3 uact9QZJZzSLAwRsHGD70y2Uz3WwDBHU1JaFGVvlIPcUkREc5cHAqb3YhLuPyLjDEsfalvWT bHzjNLKwuJQ6HjvUlzAWgTaAcHNTHS47jEgYqpJIHrUUoEchCNmrQmCRlW54x16Uy0jSV/Mf pzRZ2Aht1EjZJYYqWYOqbjwO1I6tFcBgCE9aluZTNhCpx6imtgRWBAjOTlz0qe3jkZMkc96l ktCLdZFXJpYbnykZDyT1pJWElqRAHzwoAJz1rViD7ACMACs+xRmcyoc5PetWNiwPnHIPBxV0 w6kZGTms/UhIHXYwwOprUOMhF4UdCfSq2oW2+IbSevarm/dG7dCrDA/lGRSfrUbqUIzg+tTC 5WOIxjJIptsjXBJVTnuKwd2kKxFCvmynauGAp9zAwiG/nPWpArRXG7HHeluJhOSgPXiq5dAK ioFBDHC9sVPFbu0QZXPNOkgbygwPtUlrcrChSQA8cY7GlazEVmiK5Gc/WnRIwYdCO3tU8du8 0nmEjaAc0jg28gYDg0mncBl3C0XzMcDGagKhrbeHz6g1duJnuEC7QT79qa9pm2LMCFz271Vm 5ALDayPCrJwB1HrVaQHzGAHNXbS+S3Qg8kjCqe1RwRvJl8cnrTdw2K8KF3BySw64qSeN1GCT Tx/ozbnGR14pbiV7hhtXaD2pRGVgAUCnj0zVqKCZk2xHavU0stt+7VueKkguVSNkZsvjHFEV qCI7UYuMluelWdTwIQzMxAHFQ2UPnZnQ8Kean1G5Q2XkFBnOQaqK91jdhmilXgLEnrxWkgG/ LDNY+jXCBNu0dcfStcOQPlGc8ZrSLVhJIdwckDHoKhvSv2cr/H61Ngs+1FO4Dk1Vu1xkDmm0 2tB6FfSIYpWYTcsOhq21oiS5U/NWfZyC3lYvySeKuxXDSTHA46/Ss47CtctyOixHI2kVmyRr dTIQcbTk1Zv5CIN5HTqcVBpW55OVytOWtkDVmXHghS3J3MG9hWRZQ5u2COdxNbtwyrEw27fr WNauPtRZexpNWYupuoqwou5hz1NZ2qOm8Rt+BFaDJGsmGy4xx+NZupgRspwxcdc9MVc9Yg0l sQvbxRxJsYgda0beNLmFQx+XGM+tZ5eOa2VFJyetaVhsSzBIPBwMVlC+wJIqXGnAI3ls20e9 QacqJI5BOR1q9LdRtvAfHHSodNtyfMYqDkVRUmR20fmXxLONnoe9aMlnCZAYwNpPSspJlW62 spXa1ab3oWTEY3cflUxWmorlPWP3UgCgquOnvVeONpIA23Bq1qCPPEsjNxU9pd2qWZRlDMPu 1PLd6k3IYIZIbZwfunkk1WtFJZnRuM9K04wbuE4z+HSqdgy2c8qzrhP4T603DlRW5BcIxdTI cZ6Vr6ajiL5WwBVC7LXcwKEbR0rWtIZEtlHGacL3G7XFJdJDk5zVHVCDGQ3cdqvkE/f7VS1R F2Fx92tZbDbViDSraF4d75YkYxVj7H9nzKhwh7GotIult4GZSpJ4+lXI7hZflkyVqElYi9zJ Rf8ASJJI35J5xRKsgUl5fl71IkYt5pGYrtZsipZ3hlQLs49+9ZW0bCxZ0dI/L28bSM5rOv4s XT7clc8YrUs9qQYcbQBwBWdPIPOOXAXtVSeiYLQy9ZMRuUkckfN0FbtmwisgqL97r6VyeqTS CeNAm92bp6Cup0sbrTBz9K6RrsXQ6/ZwHQBieCKjZiOeSaVRkeooUAgbeKB2HbSw6YNAJGBg KaZltp2sNwPejO48nmk2CgxxZjkORkdPemkN1KkUMQq5IIo+Y/NvJXH3aVkNyvoOwMk9hSRH 59w4PrSYJGMZzTIwRIVbG3FUZ8o6bHmbkU80zG1uualLLxvPsAKimALZBpIYjMc46/SlOBgg 5I6inIQFIxTdqg7hkA0DSuRyl2GQNvpSIWABdfr706dnOAuNo9aHzsBYg/ShIGmhGySdg470 wDau4A4qWMyJkqOCKjYk4AOMn1pjV2RjDqDjing8YA4pGXaxzzTkVmAAIFK4rXZUurcXBxkr k9ag+yZcISCo9e9XpWKEKFBOeaGQEArUOKvcq3QbGgRGHRcdKpfZYjJ5gQA89qufMD22Hqe9 BTuBkH1qnBNWE1YEULH0qC5sy0ofI5GasZHAUYPvTwo2lcZzSlFPQRBaR7OO9WJyjwMkgDZp BlYtpUFs8H2pNu0A5BJp2SVhaszGswjA+1SxIsIMigFvQirex2cjbzio3jATk/NStFDsYl9K GYg5Bz2ppKwQeYOSR3qxrFsrFBFuweWxVeaAtblVyR3qJxTZrGJzep6g7SGPkkVjvOWyp4ya v6zp9xJMWjQgeoqG18PzvIGy2T60KJTVmZySxqSAoAz+dS20cfnZQAZ9K3LfwikswRpWDjnq cVLD4d8i4IJJP1p8iJWrIrJA7hmPToa0llUEHnjuakttM8tOB371OLIA4OMU1EjluytORL82 0DNNtolh3OjZbP3aum1bPyYI9aT7IAdy9T1p2TK+HcrzXLBRu+Wokui24/e7AirclqS2GAKn tTreyRAQF4qdh7u5m3rHycNgs1Yc9szvkrnFdncWKMFKDIqJdOiL9O3NPluN6as429aeOCNI 4h7msK+hvpJDsAV+oJHWvTn02FztK9KkutI04APHD8o4yfWk4DurHnGlRXuFZlAOcHjrXcaG k7QgOCB6VoQ6bboqkIDzmrcaKikqmKqxDd9iCezhVwynJI5qSGEIQAelO+8MFCSaeFAQ5Q57 mpUYpkJtEMsSyMd4LVCtjEh3DjdU68HbzS7izYIxtqnFA0xPLR4fLI4FVfsKJucEAE8Cr28M tNkCsFyMYpNIa0RDEvlKQqjBHeoZYVYj5QB3qy3GSOc0O27CqMACnZDlexTNlFE4dcYb2pbq NWQrtXaenFThQzcnikaPfk9QOlCikT0OfudOG7IYkehqWysTHIm4qqHrWsMICzpuUjpULqNu 4YAqbJMdytdQguShGM4qAw7Tz0q5IEyS2QR2pijfn3o5ExWuRDAI2dMc0/Ge5FIqAZXtU3yl cDp2rRLQpXK8jSKowN1RmJX54FTN0JOcgcU3crRDHB70NXIe5WNqh+bHzCiRWwApwvepySBx zUchwucHBqeVDSKwhQtub8BTdm1sjjmp2XnpUbEHKk9OlLRBawxzknpzVBolWQtirzKRGcCo nC+V05qrJg0isThSB371Unijwfmye1WX2qQvOKrylQxycntQ0SUZlxnA61QvArclQMd60p3X AFZk7ZYgjipUQMe+Q7SRgiuc1MgIQVz711V0CEIrndSg3BjkVaQHB68hZTjFcJeDExHvXpmq W27IZeCa4jXNNMMrOOhpiRiUUpBB5pKBhRRRQAUUUUAFW7CIySiqyKWYAVv6LZng4oEzZ0aH aowK6vS4W445rN0ezymcV0tlCGAIypHpQCNPTkfbt6nvWpbwbhz8tVLMYI9T1Na8KfLtxSaG JboR/DjntWpCmVFVokPYVegFSkA9IVb61YjTHGOe9JECvIUVOrgnkYNO1hkZt0ZlP3cVaiQo 3HAFNGd3Sp1DEgY4ppCHLGsgDEZNPeAFCOcGpoxiIkYA9KerMSFIGKlxGZK2vlE7RVqOEEfd PSrTovdRk96XBVBzx60DsQ2qYkAIywrVKpPGF5Vs1SgGG3gc+taEBMkeGWi2gWEa1HCDgj0q VY9oGRgdKfGUCZLkdgKepEhCkHimo6C3IXtwr9etSx2vlgOcZNOlXP3uSO9TRyRtHsKYYd6m yuNqw1cEnP3qkG4jLDJFMVTk7e/engkDGaqxokmtRy/vFPGPaoWtonIMi9OwqQuBnginqx5Y d+KmUb7kNWKsMG2RmUcVZC4Q9TxRt24BOT608bgu0YxSSigTuyCOHBLnGTU4RmXjoetNXO4j GAKkUEMADx7mqirA421KzW4DHB5NWY1VI9vehQpfk4Ap8ajJLNkdqOVJ3EkNlRWi5GAKqm1T IZRg5q63z8549KG+8CAMUOKYOKIo4go+vXimT28TZ+Uj1qy5IJ4IoiYbskdKOVAolSO3URr5 fHtVxFQLg9aQZEhbqDTg45GAe4o5Ui2o2Kz2YkJxwCcmpUt/LXOOB2qRGyOKdubaQetPlSIV rjJIUmi2MOp4FRwW22Xa5AAFTIvPUnFOK9yevelyJitfYVWzGY88VXNnFLMpBCsOp9anIwM4 /GgFNwHc9abimDi0JDbiI5XNTMULZcYA9KGOEB3YIpgOMnrmly2HYkwhYbDx70rOCpC4weDU SHOc4Ap6gdO1PyBxRE9qmBleD7U+G1SFso+CfapVeQptYDHY96dkbjkZPrQoJCd+pG8AeIgj JqKO0RWIUAEe1Wd/Bw2DSE8B36UOKYRV3YEWMRFXGapyW8JfIWprhiMMuQp61CnmOGKrnFQ7 MqUbFq3VUIx0xzSSRK7HdyvUCo4nO3LcGrGcgfSrUU0TYiitlR+h9asysJBsA+UAcYpik4JB z+NPDEoWxwB0FCSWw2mir9hTzCxCknv6VaswLcsoUMDweKApKAjPNOjIKkZIY9BQkriaYk8E Lw/Kvz981FDahWJ7Z9KnBxwetI2QuM/rS5Fe4R7CsqBSmeCKqLZrJICVCnvjvVkbWxk08Fdu 0HkdDRyJj1QkEaRRNGowAfSqt3Zx3DKWA4PHFXy+IcdWqJFkOTgY9afIthWZWWxhiOEwD1NW 8AIEUYFKoDdVw1Kww2TjNCikCdhYwyEspOMYoSMSMc/jRzjrkelSK20EggVQN31KlzYQu2dw 49BUllaRoSWJAH61Ose4FhilGM4bhu3vUcqQ0upHJGrAqPu+lMSBY5iyZXHapXJXkYznpTyc FSSCe9U0mJ6jLhGuBtbv6VXGmQW589Zclv4RVxzz8vfpTQoPcc0rJhYETKgDr61FcQhxzz2q zjO1VwPWnLGOSSMCm1dWCyuZ8VgqtgLjFXfJjMapFkL3GKeHVuQMCnqvGQwANJRUQaKLaZCz 7/Q81bEaLgKu1R1NOXDOQrdO1LIyhRx160uVA1YpXNpHNPu2AD1xSw2So52nI+lXMjpzn0pA VI5Yrn3o5USou4yeBJIxEzBV+lU4tMQ/c27VNXyke1fnLH3NEqA7Qp2+uO9DikWoNjIESKEp GCueG96gubRbgFXPTtV4bc88dqCFz0z702lsJqxS0yySBG8xiTnirik4A7U7AyARTeFODTUU gaBiMZJqKZA8fP3fSpuDweRQBEdygnj2oauPSxly6XDLGBGzICc4FXra12IAP4epPepEA3Yx kY6VOUVYgSxqVBIlK7Kl3aRzjapwT61Ba6eyTks2SOxq8u0tnORTlVvvAjPrRyplcrIrmEmP YQDnpWcdJibkj8MVp8sQ248VPgDpg0Spp7ilCVtDj9WiU34KqFwf0ra00hYl6mszWIs3ibTk 57VpWKny8ZOR2qy9Ohdjj2j0z0qGSTyHYkrx0FSrzHyCfSsrUZMXiRbdzHqR2pOXKJFlb6F5 cghWPUVZR5GxLxg9DVGfT0MIkCqX+tWYAwgQOxAUcViptvUdn3JA7OTvAAz0xS7sA7ePoOtR yzwLnLc0sDF1LKQSBWifMhLQjup/s6+Zzgdar21wsxLgkgmprhM2shbkiqGjIsalc7jmpcnG yFuap2MgYjkdBVd7yISKjj5qnIYsOxrF1H91qAjKhmPIp1JSilYaWpsxNkED1ocHr2psTjau 4YYDBxSDdyRk+oppu2pduVXFlAHDHIqpPqAtDsK53DvU7btwaqOo2wlmEy52+lEm47GdroRd VynJOPTFSW13HLJhAWJ9e1ZxjLXBj2gA9DVq1TyJGLIcDvWSqSbsxp21NKV1Ujjk8EUwbt2V IGaiNxEWDN34Bp6yq77UOa2voCbvccVcy7WXJ65FI/IwOD3FMnlELAnIqOO4WaQ7Dtz0zQpJ ieuqJVz5ZD9uafklBkg+wpkrYQ7jyKhju0CkZGSabBK71LAK5wev0pQGYEqCMVDC4d/enXNw IlCE4JqW+oPRkg+4DhqjLbuD1HTFRC7QgRh9x74qwzBsbVAwOo70r3LSTI3Yr85YjtioyhIz zzUV7cLHtjI3E+1WJJTMiZUIVHbvT51ewtEiHY6jacfWkJ2LjYuT196fICyYB70BM9QTiqfc lNlIKIpWeJBg+ozVaW7iVwpRd5Oc4q+4BZgDtA9ayDF517+8UfKcg+tRKSQK7L0civLnbg47 VLsVsnq1ORFbBRMADnHekP7sGndWCzSGv8hwRioW2nG0E+tVW+1XN4WU7UB4HrV5lEa7n4pR Y9bDMbUKpwDQpIUKwzimtcxkYTpTlZCmT1FO6G7takd1IkKF8Ek1BFceYuCSCaF3XFwRnPbF F6iREbOo61m5O4o3uWY1JX5Sxx1pgnRJdrH6CkgmJiyvasy43tdq5456U+eyG7tm4QWbcPlq GZgqly3A7VLbjdCCWqpqKFlKoaObS7Ju0Ptp1lPyHg1cG4p7CsnRgIflYdOvvWnJKI1LA4B6 CrUrodyK8ulij3A8io4ZQ6hzIWDDtWZev5suSeAelW7KLEW5elQpe8Fr6kklwFYkcketRwXX nNtlUpnpU/2dRKHfn+tU9U+W5DRAAE9KHKVwWpfyAAqg4HSnMwI561XgbK75W2jHFMa6QnJO BT5r7jv0LOXyZGxt7AVUu7oBtqqamjl3xsic981lxlRdM77iOnNDl2JbJ4rxiwWRNpz19ath vvEnAHQVmasiCeNo3OM9BVuPLxnvx1ojNvQaj1JN4kjKjOTUaJg7OTgVUEjxSENnGeKtxncu 8Eg45ppiZBdFgCQQTVaK6Cy7GBB9BV2QKWDMOB+tZN0hbUd3Y9hScrFRL4AyTyM0ittyAelO G4oMHHsaaxXqwGaqMrotWQ4MDnIzuqtdSeTDkpnB6ipSwLbv0FVtQfEZx0IocrGYkM5c7lBC 1I/Khs5HpUNuFEatnIPapWKhiF+7SUmxNjJBk/eKg1XkZQx2fNjjNS3M48ortGaq2iOqkgZB OaG77DTJJQ4HJ4IqsGUqQ2cin3M4Vtu75j2qq0ys2OBTWxI6UqAD2rLuZNm5gM1cuZFwQO3S qQwxw3GfWlKVhFKeYyD04qtL93IPTip7uNFm3Bqp3STE5j4Q0JsCvMS5K9qy7yDDHitdEJGO pHeoLu3J+tUpXA4/VbfJJx9K5fWLIyRkMpJ9a77ULU7DkHFY09pmErjOfancDyy/06RGOFrN khdDgqa9JvtNXJyvNYt1pquCCvI9qYHG4NJW7PpeD8opg0pgoLD9KBXMbBqSKF3OAK2otKAY bhmte00lfl2p+lAXMTTtPJcbhXZaVYBIsMv0NRWemMJvu9PaupsbbES5TmgCGxiZQEA4rZsY 9rd6ZaW2H5H0rUiiBUAr09KhyGXbaNSBhcd60bcHgZzVewRvLzjGauRrtYdgOtK4FmNBjOeT Usa7DSQbWPqB0qYxkLnFUhjI5SrHcT1q9D8wzjrVLZlgCK0IAPLG0EEdTSu7jtclQcjp9KsQ 8tzUMec5YZxU0bIoyeDTCxLKY40JG7gVXimLrw2Dmp5wdpO3r7VXtovmLFc5rN6DsjQVAyAn lqCBtxjpSocMFGcU+Yr/AAirQLQiWQbgoH4VoQEiMgc5rOt4SziTqQavtOkMYJHOaE7hdFuN AEzgetOBXywB94nk1TW5IIA6EVJ5o8sk9R6UOS6BGw2afY5TcSBRDc5GTUFmTM74XcAfSnTh UQMOAfap59AlI0txEYkHANQG6DPtTANIh8y3UbjxWcgk+3njC4pTqCRukDyAd4A96ZJPGsRL NjAzihVDxAAHI61S1CFTAzlsFe3rRzaDd1uXbOdbmLeoOBVreMjAHFZ2hOzpgYUEdMVbnkSN ScjcDQtYiT1JGcFgCDyeopwZEJ3AlRVKW9DxhVxxzxU4dJIAeS5HIqrroF7vUhkuw0+EX5R3 oiuz5u1xxnioLNo47l965HpTrwj7QhiHBPPtU87CUuxqKdzbxgg0KnU54qKJyke7rkVDDdgT Ecke9WpIvmui6+S+GOfegYClSfpUaOjxlyeAcAVBLcLGwU9TTvYlal2PYIyZCd3akfYq7iwq vBdxtG0RwRnOT2qdwGjwAGFDd0T1FEySAbFAI9O9K+duepNZoLx3ILD5fatCORGyVBK0oyuO wySR488dRUUFz5h2k5xVjAZWbHNZ8KRpdNg4J6ilOTTGmamTsB3de1OjKjnGaaGWSJVVCCv3 jTgpwMirWqNG09CUBTGT3J4qtcXKW0ZZk6VOE2t33dqp6qzBAzlfQ0pOyM9kFvOZ5BJj5W7V f2BmwFIFU9KEPUjI7VcLYPSpi7ivcCwQD2pYpkaQnjFULuWV2AjZQveprWNY4ssvGablfRFt JlgqgzuzgnIpT8ygHnA4qGW5jTJJ3LjvTba6hbAY4Wi9kJNIsSkmIhyoA6Vn+e6SYiznuKdq Uq/Ns5UngUtjHG8BZztbHFQ5O+g2rk1qyzKfM+VqmmkWIKCD0rOSTyrlc85PFSa2ksisI3we 2KTm7EbE8UwkZggyKtEvDB5g4XPSsjQDJGvlMSXJ5NXNTmEOULkr3PvVRn7twbbGPqX70R4I x3xVqGcSLkMMiq9skLwF2YdOOKrwsEkKr1JpKbTHctPeFpmDA8dD61cj3S4x6dKyLmTbON2B 7CtK1nQoADh8UQm3oNWaJZGSHJfkjtVGG/8A33KkZ6cVNqLBYgRnPeqtlD5h/d5YcnJFNyd9 B6Wsa9u6spYnPFQ3FyI1OelFmNqlJByD2qhq8W77rnk0Sm4oVrF6wukm3ZDE9qLqYo2ScVDp Ctj5ew5qTVYh5QbOSafM3G5GhPazpIjZBPFSw4X5nOc9hWZpd1GkuxufUelar+Wy5QGnCV0C 2sIJ080qTtB6YoVj5mcZHrWbcxMt0HGQvpV6xmD/ADYDD0ovd2LbsrEtwwCA4wfWs2O/LTsj AjBx9a1XUOfunjsaxr0IsxJXHNKUmthdDWjbcvBzxUiFT0zkdahtQ6WanywM9DipN3lqHPOe vFVF3QraE/CkFAeeuaiuJCsbOSAR29alVxs4HJqpqQLQ4QjdilNtK44pdSGHUGd/LWMmtCMu VVguPY1n6KuyQBsFj3xWlKwD/u+cdc9qmMm0JtX0HSYVi2Bkjmo4njfjPSoNQuxGg8sAsfao tNT5zJMCU9u1NS1sV1NAtk5PNBCkcjIB6VWe7SEsFwQemaZZ30ckjFgS3TFUtBymnoWZ3SOI uCAfQ1R/tICQKRgnoe1N1ZkaLbjB7VJBbwSWnON6iplL+UiUrFuOUOAdwJ74pt3diMKGIUj1 71n2jmJsZwPSm61ulUuUOAOBUufVlRkmjXt7hZgO/wBKdLwN2OKztEcGMYBB7+1WtSeU2zRx LkjnIFUpNK7Fe5Gt4PtXlhvmHNWJ5PLjaVhz6Vh6fJi7UzIwkNb1yoW3JbBYjNEKjaYK17Ed lfpLnAwT2qzu3DBFc9aXEMF+fM5Y9AK6J5Y5lEkZAyOQKUZ3QrWZRub+GKTysZOeCKLW9ZpN oIGT0NOFhEJS5YAnnpVG7UNcr5fy7Tgn1pOUkwbsbUjADIAHHaqUuoxwOQxxmpZPMFiduOB1 NYE5uS2fJDfWipV5TSMizfqrSgqmGFXrMgRjIIJ61SvNwn+Revc1oW6usQd9u7FaohrUsIVD c8L6ZrEvh/xNVYcFjitT5m7c/wAqoXsR+0LLL/D92onbRkqVtC9HGVAB9KWeRY4G3jI7c1X+ 1KsG7JckdKr30jmzEihmYjlfSkrFN+7ylS6kjlUFQVAq9pzFowQ3T3qqUH2dWZOT2qxpf93G DUXd9BR2LV4rKjEn5SOmazNOGCwxh89BWtfoogO5iTisfSkaC4dmO4k55ok9UOO5rAmRCQOV 4JrDv1j/ALWiZt7MB1zXQEfOrnAVuoFYt+Q2oBoiCM1c9kLqaYQbQwIINPLEptXhh1PrTU4U YORTsO3KDB/nWiG23oMdiU2nApsjBogmOPanOMgetOVBhju5AyMVLaFZoxPn+3FeFwa05VJg OcNkc1mlg9+zYGeBn8a1o9uwgn5QOaxi7sTMFwzzbc5A6AdqmgEkUuB95jxRAiG9cx8EnvWr 9nAcMzKXFOHvBexVviVIEmCwFZkszJcKRxu4qze+Y19n+A8EmkvYYhKihwzAZqXuNMsXkjHT wACHHJb1qvp0CzJlyQfWrGo7nsExJtOOgqPR9vkEyv0HFXKYKLHwQm3lYlifT0FUb25dbzay kq3TFaKyq7lAM+5qrIMXuxgCPX0qX7qFZlWYyRgvDECa17YzCFJHHDCm3Jtofundkc0uXKps Y7RzVwQ+gk0e/DADIp8Y2nLAHiq19PJHOqhcoe4qxAxaLdj8TVpK4WshpYMTtBFOVz5RTBD9 j60MxBX5M+uKDuZgQQAO3em1cG9Cu0eSc5zisvy3W8OWyPStm4wvK+nNZY5vMtnjtWdVaoUJ GhwMFeMCqWozeWvc564q4jHb8vSoriFXgY8l+3pVOOgN6kNlEqx72fJboM9Kj1NiUA3YHSi2 mKS+XJGWGOtLqsSNaqdxAz2qdosbZFa2RktT8wJByDT/ACXjQZJqW2ZEtwyt0FOtbpriNo8g fUUuW6uFzKjVmnZlJDL6GnXCSNbs2MZ6GpTGYrxj69RTr6VXiWJAahtlJ6kujsqgeYMj3qtq jR/aA+zqeAKtWUZWIA1U1IBrkIvybf1p2tG7Jd2XYuECgHpS3Cs0DFccUW+BEu0npSXjNHAU Bxnqau3NAd1YqWA3MQw6dal1MZjHlg8D86h02XZnuTV5lGN3FKO1hGIPOaFt0YX6irum+cIF 8zABPanagV8gj86bpuGgVVLMVGeam1pjiixP5pBII2jgVmzhllTzMnJ4q+86YILEY9az7ppD KrZJ9BWktRPcmvZCLYRAd85qoo3KBjirOoea0aNHhWxz70ts4SABkHuaztdglzaIbbiSJGO7 IPb0FQR5km2oM81aSeJlcBc+hqlFMIrphtIOOtNaA10Fu0aGb96p5qa3m/dsOMfWsrVJ7ieV TvO6rFnC4YyEk8cjtRF2KiiW9ZZAGOQw6YpLe5kMnlkHGOtV55ZHuPLVeKuQxnAAXmmndg46 E5Zmj2DHHes2QhZs45z1rQ3MFP8ACR1rNMgM+GxjjFOZGqL4PA9SOtR5wT0NO2kjocdqUAen TrTjsVpYaNo7VUvWYoRx+NXd4Z+Exiqurq4iExHDcDFOWwJ3IbIu0JIKkCrD7FhDKSX96hsX TyCuztxinNkj2pR2JMx2dpm3Hj0qwodgVTjHfNNuExyvFNRsr8pOe9CWo1puZs8m262Sc5PX NJNCCcAmnXUarNvK554PpTZHYKXzlu1HUXoQzqShA7VUlWQx88H1rSILoCMc9aiCcEGhrUDG mBDqzDIHFWUVZI+cY/lUs8OQCBmkjWNNwORx1pLQRmGMLOyqTinPGCMEZPrVkKhcMOakePcc hSKqIGDf2pCbOx5rN+ygcFM10t/GgQEAsRWc0bEggcmqvqBzOo224sdnHpWNLpx2k4HNdxeW xK4KjNVJLeMQbCgz1zVCZxJ0nefu02bS22hdg46GusjtgCWVM0otw33xx7UCsckmktuX5Oa1 7awURcjDDoK1mtQXwoI9KvW1ioXcVY+poHYxoLTBwAc1rWcIVcNUwt8NwOKtxQ5GAOaluwyv BbAuVUkd+atwRGIYbkmp4YirZYVLcRcrsGT/ACrJ6sC3aZ8tVwABVt0Xp1zUdopCjfggVYfD MABge1adAGQHbIqbeO1aIG7rxiooY+mRnFWUwOo601sMryLtcKozmrkSFUA9aquf34wGq9EB 5Q3ZyaSeoheUIUqcGp1QNjgDFQktwM/SpImY5yPpQ2WmTT7lg3dR3NQWW2SQNu6VLMc27RqS QRkiobLap2gYANQ3cUt9DWRsW7ABcN+dUi/zADirW3dFuU5HpUbQ8A45pu4LQsWoXAXHJ64q G8mHnBHUY6Cn2oPnjJIHem3yr5uScqtS37tkDsywIx5asMEmnBRHA/TJ9ait5l8nJGSelWQ6 vAVZcnHBp2VhtqxVh3+Wdp8sn0pbg4jCnnjvS2w8p/mO4981NdyCZgUj2gdqjlaJuWtNw9t8 6qCvUDvVJnBumZQOD0q9YboYxIyDB7Gs64w900qp5eTzVNWQGvAXCiQOo3cEVXvyoRiuGWn2 T74gqnNN1BkjiK7QfU1WnKU3ci00lRvVQKZqLnJIwSetGnuFODzn1p+pKhO5QVFSnaAk7FWN WK7wD0q9prZQ7gc+9ELQpAgXlu9WImwwKqOe9EY6iIXtyXJUcmq0yvHKEyM55rUklEDb+OPW qVwwurpZFUDntSktbBYmeaNbcKSVz2qg7hckcD1q1qChdpdeOlRyJHJbFD1pMC1ZYa1aRnAI /WoIMTzk7s4qe0RFgYHPA4FVoMxSscAZNVcLXLZtI/NyFwParSoEJ+btxUH2oBQqgGp/MTyw w5arjZgyG8+WAlcbjUWkzu8ZVlAIqJ5HeYqylgehHar9pCsUQXBGec1K+IpaIkUNh34xis45 8/K43E1oTOFixnrWXHuN2Ap+WnN6iW1zXjYqhXABNO4HLMSe1JsCj74NKql8lRnFXug0kI7N weuKp6iVaPBOM9jV1HH3Sm73qpqzoWUmPA6VMthJXH6cRhTtzk9qu3pKqQmOetVdNeMRGMkZ 7YqxgZG4ZoitB3M+3D7thwavTOwt9i9B61UmjeObzIjjnvU8cwmB6Hb96oTtcFoUEzLNsYdK vmzhaEEA5HaqkMiJqfluGC4zmtB7gbjGDwen0oVmJq5SvQm1E2kk+g6UkcLGLaCfrU96gb/V np1NLp90tvbsrKJGxxmonfm0G1YpRMY5xG3zEd607qTbbnaoI9apWsZuLoOVK1evngSz2Hht 3eiOidw0KujsXlbYvPc03VVONvr1o0qURzMRxnirWpKrFZI1BXHOapW5BIprvEPyjjtUSBvt KgnHrV2CZBbtGwHqDUUamScMCNtNCI7uNZLgN0VRgUsbGGZSPWnXLJ523qPQ0TBZJEZMqBxi lHQqJPqomkiEgAGRxTNCidICZJRuPvVi5lAsMt1Hqag0iSKWHcpwuehoWshGoBzxz71W1Les BiwORnOKsqyAgEnHbFRalIhh+9yPWrnsUpdyrogbAUsR6mpdSAbgk4U0zS54+oww71Jqe9gS O3YVN7RJbRSisx5LXKths1fsLlTFtIywPJqlFKGtSOQxqXTbcrucnA60qTEaVyEkjLFNtZ1v vSfCt8vYVJe3roVTBKtxxUlnCCfMB4znHrVW94bRdicBW8wncelZl8o80HPfpWkxBbcQVbsa zNRZTcYLZOeTVTdhNmpY+YbFSx+XsKkyCmMVBbPmBFB4HapwGVMkg57VUdhrUUYyFAJ9Kqak jRocsAO5FW1OMEjFV9RBMO4jIxipqXsO6ZX0UOW3IQx9TWhISiMCAGPWs7R5Qshxge1aQO9m 3DOentRF+6JRvqY6uZboqU4B61sqGa1cQ7VCjkHqaz7+HYcoenJqSynSWA7iwcehpReuoims XnXYRmwKuSWKxuGjbnuRVSBQl6XllwPSr093EHwhIBpRd0NRTK2qAvEuFLFe9Rj7QY124Hri rN1lkwn3TUlpcWsMLRtHuY96zd0TLyKEaB51D53LzWlqhD2aADBC4NUIVZ7reqnbV/VpY5LT GfmAwe1OL0CKUSHSUaIHDCtKRzgnoSMEis3SGTaymTlRwa0HeMwMGPzdq0jtqPcx0UtfNGGU kHqe1atyNkAydxxisiJoxqYGRub3rZlIaIqg+app6XFe0jDitVluHYbd/vVvT5njkaE44qC3 Km4kzwR/Onw5M+QOvUilB2HfU0NTuUhh2tGSxxjB6VHaQLKQz9xVOZt8w8x+M96vmaGELtlU iqtd3uVKSZbkVVhCg5C9qwdRkYzEA49hW0rxyJuMgWsjUGgW4K5yeuaVZRaBtWJLyN2lAB2r nmrERZSExuUd6inmD3RADfWrVsEcMMjI962SNXG+qJMnGWXbTLq3WVSGOCRwakG7bxyPekk2 4wrZpNcxk48ruZCWEok3CT5QelXfIkdC2AO2KnVFxzTnOE+UnFSoBuZf9nukpLSEhug9Knjt QG++QQOo71ajBePdjJ7ClZCv3uG7CkoWBaEN1E8sRGcHHBqlZWE0LlpHDZPpWlI25OR0pquW G1gMVXKmw2GA/McZK9MVnTWhEpdD1rTfGM4I9BSYAj3FAfem43QnuV7ON402nJHept+xc7hk +lSZCKeAdw9agYA9Bn0pouy3QrDdE26TaSeBimSLlQq9hyaeifL+85NLCuZT82BQ1cTkzJm0 uYXQmjbdnkgc4FaIjdl2KOoxUkLiOeRFcn1IpYGy2ZGwB93FQoWIbuZQ0+RJmffgZ6VeWMja cHjvUrbnc5HNJnnaT09+lOMeUat1KV9ayTL+6ba2ckmohYFlDscuOCRWkyN/e69DTG3K2F4A 6+9LkuW0r6EPkqIAGG7NVpLR4ztiII64xWlGjDL7cp/Kmb1+Y7ST2qZQT0JSZStbNkyx5z2N F3bbgGXG76VeDNhRjjvSybey1XIkrC1My305zumkck9lNX4P3Y+dOD0pXywUhiMelOMm4BSD x3pqKTGmQPC7oWCZx7Uo3KqggVLl13KHwDTHAwMnLd6aS3E9xrvtyQvJqMg7hkYqXZnnOD2o woX52y3rQ2aKy6kbBeQADkelZ7WTecXUnc3U+lX3IyAG5NALDODgYxmlJJk21K8EZi/iDfWp CuATnGaQJglTzTmBC5PNUirJlWSEkBgcAU14zJFsPIFWmQfKS5KnnHpTeAeKTitjN9jOWzZY 9qseTmrNpbCIEnJNTO2CcDJNPZioz/Ge1JQRSjcpXNp5rhsnPtUaWjmQtkDb1q7lgAQODSce mc0nBN3E3Yj2MAAvWqF3p888wYNhj0NaeSWz3oyQeT0olHQelipBBJENjNkr1NOuI2nYg/dq dlLHg4BoyUOAKajpYnoZqWjxSkq3BPStCFPkw3OKHySCBzTWb5uetKMbMRUvrdpuVbHPNS6f buiONwzipGIDdRihMYJJ7U3FXuXZ2uUprXLZPPPFJ9jlRlZ+jGrikYweTTZWcAByT6e1S1cc IrqRXEabMA8iqE0MjoVViBnmrTS7pzHggetP8vk8Db2pcnUbtFkVhHHGoBTIqK7tTKWwAp7Y q1sO4YIFKsgD7cgkdTTcDJ7mdHY4UbsMQOtTeWVjOOM8GrUpVjjHftUcignAzgfrTjCxdzOj twJt/wDF61dVHUK+QWJpHX5/kHFO2SRw4BG4/pTUbEttkV7GzDJbk1SWzUSiTcc+9XSNuQ4y aQ8qOOKThcbd9BMDYCW6cYpRENofPBPSl4ZABxxzTR8q7c9KaVh2GuCHIxxUVxH58axkkgdq nKs3zdKayfL8vU0WuFuxSgtTEW2nrUgjbbz271Y2gcYJJqKTPPWklYSKsqAggjk1Rz5RbPB7 VembPB7Vn3GWk561TBkdxtJAx1FQeUCSc+1OByxyec1JGQeAMEUuVMLWBItse0AVDLH2PFXl Az0zUc8Dld6rkj1okhWKSwBlJ6GomhXB3LkYq5EGkUkjaR1FDRbQDkNnnjtTtoIyltSshwOD 2FTyR7eh6irTKS3HAqKWLPPeklYZn3NtuUN61Te1OQOeO9bYi3IQ3OKiMBHQZo5WIw57fj5g c5qu1nk5IrcliB4IFMe3IGKYGMtoQhJwAajNku/gZzW15eF5GSe1M8hiOMA00BmGx2kcA5qw IMLgZx3FXYoGVhnG6pmi29fxoAyxZsGD9j0FSeSRyMCtDZuUDsOlOWEDllBBqWgKwgJCtng1 PFARztyKkVQDgDAq1EP3fBqeUdhiQqEFSRRBTkHJp4wSAFxUkajeQBVWESoo4CnJqUgsOQBi lRU2DA+b1p8SfPyOKroBX8og5xxVmHKckZ44zTpI+cZ47U6OM7gCc4qUkNIaYmJDZyTycdql CgYqUKR0oMZCg9aLD2GAc5Axng0G2ZXLLjB6VIseeMj61Oy7VC0nEE3cZbb0Y5HA6gVOsmc4 HWoFDg5U9etSqhwSAc+lUkHQXyuc55NOljDQYZct3FL84C71wRUoXcPMBye9LlQmrFWOElcY wOwFXraJowEcgkc8UkOCx4+brUqADnipskFmxjwCSVnJAPahLYB1LE+9TOyqgK4zT0IwDxnF NrW4+UR0ZgFQnFVJLfcSeaugspyO9BBH50SjdhYjsI/IXbjrTZ4PPYr71NvO/wCb06UqkgHA puOhfLzbleKyKSDJ6VYuIUdApySDzTiG4J608dRwalR0M2rMoSW7l1CcIKv26+XGVIByOtOi IO4FelSfLjgdqbjroUrdSpcRB02MCc96LW1SLHJGPWrAYtjI6UpyxwwAFHJfUHYS6VZYhEQM LznvUBtN6lSdox1qccYJ6VODgbWwwocESyraRbVYMcjsajltNzZBOau5+baoCgU6QARhlNDg NFC3tPLZupJ65qyUOzGOM1J1wSeKc2M8cU1Gw07le3g2THJwMZFTKWJ+Y0mcnvinEYTII5PG aaikKRFPF5wKjrUcFoIsEnJq2hxyBzSMEHzfMfXNDimSJzkEbR+FOyyj5eKcAu2hcdKaLihk S8bueaJYVmJD/hU3IGBgY9aZlmOcCla6E4tMq29r5bMR61dypUZByBim70XHPOe9KSGyfWhK w1HuDJvjIIHFQW0UaN93AJ7CrMRGcU/5Q/QHFDimJpIqXdpuYsvSktbM+Z5pbIA71oHAUngg 9qaoA4zxUOCewJ62YKsIiKuh3HoRVQWRzlfwq8h3HD42jpScqevfjFHJfcHboRWkCQgkn5xU V1bfaZD8wGfWrO1TMOuSOvakf+LI+YGq5VawkUVstjjnH0q8IQ0flrlmPoKU7VUHkn3p0TNG 5cN82OKaikG2pQksm80qpx6irNtbRohDZyKkzhyxY8nNOVsSZ6j3pcqTHqyrc6es+AvDdM0W tk0GY3+YirLsd+eQfQVOhOPmo5VuSU57XzAEKYU0yGyW0wM5DHgDtV3qwyckdOaUBQTnJY0+ RXuO9gijzgHAPqaqXVrvchuR61dVVO7cSCBx701Hym0jpRJX0CxnrYtAymPhD6VenhXYAxJJ 6mlO7Ix0qQvtGBgj3pcqtYVrmdHp58zIJPtVuGILGUfg5qQMC2QcVKQuePSiMFEbViibf94D 95e/tVrfsVQqDGaeV4yMc0kihSNpyMc1XKgeo+Zg0YXIx64rOezR5d7MetaCmMqQw69DQiAH bkGk4Ji0QkCLGNsZ3VKSMA7TikVVV96Dmn7iSwOB3p26FXEG0nk8VHOgbcGY7cVIqbnJBA9a V1XHfPalo9CZy6IzbfTlRzMGYei5rQjIUcmgtzj0p+M/MaFFISuhZo4jAVbljVK3tRETtGAa vsN8Qfj0wKbGrFMkcChxRdrlO601JsOpw2aRbAjDEZAq8ORjtTgy7SoP4VPIhJIa8SNGBgKc YqjNppaRZtxx0+tXVOc5GT60oEpKiM7vam4J7g12IoIRF0yAeoqK9s/tBbHH0q58xcqQB6k0 6QfKNooUElYlmVa6YYXzG5wTmr00G9NvOatwRkIW4AHrTMc8EU+VbFw0MU6Rvn81dwcd61II 2TjJBPGad8wkyCQT1qQk5z1pKCQSjdmdcaYplKo+MnJYd6ngtlgA3Atx2q067sKCBmljJX5T ztGM0uRIFHUz7zTUuV3hsDPTNRppO5lQtkAZHNabYz70+LKnKNjjmj2URtPYrtAvlCMjoODW XcaKZz5jsSc44rdTksx5GaHzGOARnmm4JktGXIv+lkKfl9asQxqHLKADUM6ESBy2F9qsKcoM Y4oTLldbCgqMjJxTUQpnHRqeASQCoA9fSkI7ZJ96bZO+4hXIBBxTWB24DECnkbWC5z3NMdup wcDpSTBvsI6goAr4IPzCghSQwJP1NLApYFnXkfrTWVVjyoOSckVVwSbFYoB3z2qOMk54xipl VmQFhgdhTcLzk80IGlYikdR+FV57+OJhGWz7VYVkUsSoII9KxUjMl8425Ung1nOTWwRt1Nlp vOQbVGO2KeFVIwMbn7+1RJG0ICjFLckwRCR2AJ6VUbvcqW2g8kpncowRxUP3QSp5JqrHcTyM ARkE8VYLeWfn7daaldijYeSoHC847Uw5wGZSPTNNFxF5yjzMBqluJD5WTyo4FO4aEU12qsOQ ppiSJL1IPuKpxxJdXHzruX09KGiFpKUDcZrNza2GkjU3KI+SRjpVeOYSuQDnHWoJrh1hAVQw 96z9Lac37lvlQ9KTmFrG+oPlnBwvpUEkgiX5iNp5qRQ6g85FYOqmd5NqNjBq20tWTdm2sr7B tK4NDzxR4V2y2enaoLH5o13HGB+dVtYhDMrK23BqZSsrgpJGlDh2JUde1OdWWTae1V7B/wB0 ApJcCp2f5SdxL571Sd9RSZHM8cXymQMT09qRexI61g6tLcGcKpCksP51uQ4WGMbt+F5OO9Sq nvWHZWFkIGSSAMcVDFLG7HcxAxxiotRkAj2jrVKwUh+WyaOa0rDjZamqsTSAkDkDrVYShDyQ cetT3MjRQswPBXmslI2uSSp5HaiUnAL3NaJt8ZlfBHbFCupbk49ar2I2LtkBzUN350Smfgqe ABTUrq7C5blXk7WB9DUcgfaWBw5FMtZPNj3Zx7VLLlh7Y61SaYvMrvc7NvI3gdaf5vmDcSCT 1NVdUhWWHerGNx1NFkmY1UnIHcVHM07Gm+xabcQqA05hsOG5pQoK5XOBTQoJyc81eplYkjAK +YOgqjNdKjEbg5zyB2q79xSN2U9KxIoQuoPgH5z+FRKbiUtjTgkyASOvOPSpZDnmhIkU7Fyz DrgUpGCxBAx2NNNtCVivIxbJUhSO3rTHbKgkc96pySyPeFYwcCrxDIm49SKXNd2QOxECpk5y QelPlPy/KMGo/MiC4U5OeR6U4t+73Zz9KsL2I2byxlvwqJrnf7Y61GzPczqhbCim3NoLdid2 7PJqJSa2KVpblgKDHvBponXlM8dqbZu8lucLhexrPmEn2rGfl9RRz2RTaaNSIGVcL8tNZNgL MMH+dS2oVIQSSx71U1Gd5BtGcCjnaVyFYljaNhlW5peCmOpHJqhpQKyEv29a0nZVRmZcE96c Z31C2pEuOoGKSRcockg0wTKTkcjsaljHmDg5NV0E9GV0QliTyKHUJHnoueKdcMsbbelRGSI4 +bJ9KLiE4wSxpkk67gFXrUlzs8ndsOMcVnxhmyAwJ7UpzsNM0A3TJ+tQyypHJ8zjBpLcMo2S nJqhqQVZF3ZxS5tLlLTQ0WkGODk9qgkl284+bvUULhkzuGB0ofcxJIwvY0+dDtYrXEg28ZyT VOUyMdxOcccVLIW87BB465qURg5YDANK9yLXM4IUfeRnNTWj/OSyg5q4IA8e4AkDviq0qbZg Bx7U27CbZbRPlJ6A0Ox2gAkgVIiZQbQeKBGd+4/lRuBRn3cyKp98UxGAQnHJrQKggqOBnmq0 0P3j2HemmDKm7JxTm+Yc4FNSME5HPNWJVVmG0YGOaadxFYDg7W69RUD7gMrVicbfudKhCknv Q3YCsIzuJbpSvsGBuyTVrZtPPIqvPGDcl4hhCOh7UkMa6BsYXBFRMoQ8nNaIiBiyhA2jn3qm sRkkxjIptiIAAWyDVhYi/OaWaBI3GF4qaNWKZXjFJMCGYIuFUGlCErtxx2NJKW8xQCAe9XIg hjO4fSi4FN4/LG6iOZGUYz16VLMu47QaSWMoAVwT34pNjuSqcgnHSkEu1s880zccDt7VMqbl HHNCkItWx3H1q2oDcg49azrPKylCc1eDxpnfk0N3AeUyNxUj0pQQME5yab9pHCnNTkKxGRgC luykKB3zTwCTx0pHZEIAIxTklDIcU9AY1sKx4pEmUttLc0knHfrUKxbpA+BxxScrAtDRiUZH NOBG8imQD5eeKryymOXaFJY98UxtlyQkEqWOT3pfmRVbtTYgsiAsfnFTDONpHB70IS3IvtCq 5J4J4qeByUJXGO+aoX0CIVDSZOc4q1Z4MZyTgdKUZXdmNsniQZywOD2qwuGPyj8KaeNoJByK kHyngVYm2K4KwmQg8cAVTN8Pl2gZzzViWRiCC2VIxj0rNscS3TxiPgHrjrUSk0wVzTiYSyBg M8flUgXb65zSQ4h+UKMmllk2J8ygmqWxXMxsp2tlnz6VMrMG3ZHIrMVzJNs2kAc1pjMUYd8Y IqL66D0tdjwGRSw7mkH3sjjNVpLtEYAn5SenpVgShoWVBnPINVEh6jJ5fLbOeR3qKO7WSUIT g+9QANcOCzbcHGKbeoqFTj7p7Clza6ArF+aQRnHWomu1UbiOKiiAmQL39KfPCI4juwOKfMxq N0W4JklUMDjNRzTqsnllsmq2lo7rgHd6VZltj5gZlxjqSKHJ2JTvoN+0BiUzU+4Ku8txWfOo +0qI+MdTVq6ZViWNW3dz7UozfUp2I3u9j7ACd36VcikWQLkciq9tZpOjSGQLsGfrUET+XMw3 EEChza3JNBpTHlhjjpSJfCQbX27jzVRX3/LnOaWazWOJZSRkdKTm3sI0VDPlh2FQG4iEmwMd 2OaZYyzGElTn1rOZ5GvjwAv0puXKXc24i0vPpUMl1sXGQeeg7U6MfuCVJzjtVFAnnlSMZOSa OZpCbLQuY3Kg9qt7kCjHKnpntWXdxqsq+Ucir4Z2t1UoM+tCmF9SWDY8mN3FSlVCng5zWbZk RTlMkHPNaG4FM+9UncNxsswjA43D19Kqx3gZiGHerEkeY8Bse1ZiI4vMZBUUm7MTs2bSuGX5 QacnIySBioUyqj5sZ61KY1KlW5z05q2NofATliWAB6VBczLGx3Z+tTEKYlXaBiqWqAkD3qZO yuJxH294Jxwc44HFWOvtVXSYkUbpMAGrb8E/3e1EW2hJ9ACqkfL5I65pEcNyOaqXkwTPzA4p 9gSQGbIU9DinfUpPQuHBO0H5qVcqu1jk+tVp544GDDkk0q3kMzhchSPegVidzs+aqk2oIs4U jk9DS30mAAjZzUcNrugExCsR1zUSlrZA9i4Jg+COabNLtGcjdVG2eRLrG4YJyaXUtx3bD16U +dJXC91Y0IbhZW56+3ep2GxsMhwemay9GR2jBYfN6ZrQv5JMZDbuMfSmpXVw6XIjcRiUoQBi rOdi7mGAea52EP8AamMoLHPFbrq0toMYxj8qSncT1GXF7AjKASC3GKk+1I4RFQBu/PWo7Wyh cfviMgZGaolSl2MngGp5ncE+U0ZrqOA7GIGegNNfUUVMbcc8tVC+EcsgBGQDxmtKHT7ea1Bk lXBH3cUc8r2Q3Zk9tLv+ZDxioTeRxyYkBK55IpRGLe33LjaOBxVS3HnyEMox2FDmxJmlBLvz tACt0NS4+UtzuFQRxqpWMHaKS6mZAY1Ocd6qOiuO6vqMa6RZPLYgHNW0dMZHIrm3LPfBm5X+ Vb0cZNsCpG6iMrivdkyOA2FwBnvUnO5h1FY6TTR3BDjjsa04JBIm4EZ9Kadwuwmm8vIcYAqG G/t3kCQ9e9WZVEkbmTHp9axFSNLoqqbSDyRSk2gbN0g5G1gcinR5Vckd+1RWoV0y2QMcGpfm 6A/QnvTT0GyMmMsZCu0g0ye5VRlugHSpsYGSOR1BrJ1WRV/dlSN1E3bYroXre8WYFVbPpirc aoY8Enf1PpVTSLaOG3MiqMnpVjaAAWOPeiKb3EmLuA5z0pcZAYNxnkVQv7jKiNfvHgGpbQsi qHznvQndgpWZYDKzsVHApxycn1qOa8tlGAQo7+9KZFkQGPp2ovqaTatcjnlWBQWPPrTba/ik lIU9qpzMJ73yW42880+/skhiWaBkBPUCoc9TG5qMWEQfsarS3a7sM27AplpP5lptGWwOwrEu JJ1uWKpx7iiU7IGzdnTBAfvUsK5UKMH1JqG5BecPnAx0pybhyGI9vWrtY1d3sSM3lsQOc/lT TlmC+venRoRnLcHnFDLg8U9xNqL1GyIQ2FIB7mkKDkk8UknY5Oe9NBbGCcj+VTYckmrolDHa FBwKZIoVskZ+hqPBxgnPvTg+35cZ/pVMSbix2/AxTAoPGQCaBjHBowCal7jcVcLlBHb4DKSe prFsk23bsZD8x6Vry8KRjPFY9r5S38gIJ5qJPQhrU1mwDjOapanKksq2/mjpzmrwwoyQSe1V dWtongE6riTvTk3y6C62C1iEeNjZ96q6q0hlUI4wetTaZIHiXPyn0NQaqS92oRdvPUVN/dHd LQU2W2zR0bdk9D2p8ytHajc/NWom2WwVyFxzzTJ5UntiFVcDofWlFW3ZN9bGbBN5MZaPJZj1 FE7M7I7jPPNWLBIT17dqh1DDXAVDjnkCstWtDXmVrF6NI2gVHOAehFZdpvi1CSORgRnitaNl +zrGRxjgmsqCNDqLksW55NaO65Rp66mzj92Oc5rN1SJARg5PrWiFEaja24EVnaqcsoGEAOT7 1c0rK5n1LVgf3QUYx1yaq6uN7j5uvSrNkyhASAc9M1W1QfvVAIGKUl7gS5XsRW4khYYODWpB h4zuHJ5z71m3MrmNWKZHQEVbsSwhzzzU02+oPVFPVI1RldwuSeKvWgQwqOc96o6uUEihiSMi rluqCBXV85HIppL2guViXkMbRFiRWdp8aLOyKwyetazqEgcMBz2rJ0tFa6kxwSfzq5WU0CVi 7qhUWhVOTisrSd4O08HNbNzGsdi7nhu3vWXp/wAzsXHU8YqZ7oaa6mm3QZ78CopkLrtLDA7V YOfLWMjIByKr3DpF8x+/WmlrA7XM9pDFPt24U8VoxkGIbhn0rORWuLrdyf5VoFHjGCOlTE0a 5UV9SiDWzHOA3HFR6ahWMRg8e9S6iyLACAQB602xUvFuxWcn7wlexZKuowSMA0hBbJNPOdvA zilYjgJnnsa6CepCuF+Z13A8Vn5Auyy/dPb0rUACkl+QO1Y0IIvmLE7SaymlcSNqJgsQKthq z72dvMK924Jq+I9owx57VSvrY8SdDngU2rxshNEdlbOFMrFai1NpEUbHwSeamhnUERE8+lJq 4UkHAVQM5qItKPmPl1Kkdu3ls+RkjJ96Wzhl2u6y5GOhqxBxCu5gR61KHDIyxYDY5A701dla Ixo2kEjEkE56Cnyzllwcg55p8CoNQzKpUD9amvmgSM7Uyc/pSsybok02MyKUB2qB07VVv08q cKB1q5pwIhADZDevaqOqYa5ADnApfZDqXbYYQAsCD2FJeBBAcgH6UtphUU9frTbnDKw5HcVq 17o5KyKFjuIIzzngmrVwziLZIwJxVOwYmQqUOFOan1OTIU9AeKmKsK5nzPsQLHJt56Vc0+Rm hMmQMDGD1qvOkewAAVJattjJYAnHFTdjurFKeQzXpHmEbe1Dbg2VOKVATcuHUDJ64qeYQJBv 3ANnGKSbJEnYm1yznHpmqFpIsTlg3T3qS8usWhQD5j0NYq3AR8ZySeRVSV7DSOi+1B24I3Gq eob2lAJBJ61nxyMJQc/hVqTDsrkkGm1oaNW1HIjRqHyducVdTzTGCq5X3qKUBkjAJ46irtsh Me3cealPUm5UuIGZSxHNRWwblSOBVu4lVX8lWyaIYucdM1TavoSrsbGAFIJPsKpXAxcjvWls aNs8Gs294nX1JpyC12XYwRH6U9coN+M/Wmw7VUfeNHOCGPGeKtbAtGM3F8nbjNQzAmFgeBjm rSqSOSAuahuQdrAkY9aHsDdzOtwA20Z21ZCH7yr8o60yxKZIzwDVkAuGQPtHWpTEjNnAyV7E 1LDbt5e4AEVLNBgfSi2ct+7GQTxTBopXalWVD8tN8lvKyCN2anvQBOFbkjpT9h2BmI9qNwKx jYR5qCNPKJK5yTWh8rRbec1XjTBKepzQ9BEE28r0z9amgX93nHNOnhYYw34VPaJggk4o6gUp 0+cHAz61Oq/JnHNFyp8w4IwDT0IeDBBDClfUaVyoOpOOaV3ZQeMk0/YQ3NPnQFQyigRXiG7O /wDCphvHCjNAXjmrVvnyy7AgYxU9QIrDKy7icsetTS4MvB6moLc5k4JyDUxDNOCMqM0O47k3 ksMHjNWMsISz88UpZAgUtuIpjvmMjGAaEhorlDgNET16Zqe3Mpm2kcY4p9moEfL96nDKJPlO CKS1E3crX4ZYzj74qbTQzgbuppL4b04+8at2YzAEVeepNFtQuWMLkp0I70wwBuQOnenxqNwL ZplxKQSqk4xWkthrUq2rEzsgBxmtFwyjHUVUsY2Y7sY5q+VyCpyTUxbEZmo4WRWYZ9DVi3jL xjcSFJxkVDqYfZsGCRVzTkYw4OOOtJbldCVV8r5GO7jrUw3eaCDgY6UDaycg8UiMyHJXJrS5 Is6bo2O0Z9RWdYNL57DheeK02WRoWdRwOvNZ8T4n3HhTWU3qO+hrIm4ZxyKpX7FZEXHBq0CM AqzZNQXab+x+XnNVK9tBJ2H28KNHvABaq2pSsjrHyAeKksZ1PA3Bs4qPWQWlVS2SBnpUbIq4 2O2EkRDDPfNWIUkSLYM5A60tnIq2+5iAMdKsRSLgnllI4xVIm+plo2JCobnNOuZZAg2pk9Kf GVW7KyLx1z61JqLxOqpCCp71MdLgkSaNL5MbSNGCSPyps+Z5SWOQeoqLmOLBLAGp7FSEMjMC M96fNdWBX6Fu0QW0RVYwMjrUN5O20KMknipPOaVWC4JA4rPjkM0vzHaQcGq2Q+W2paggYqNz An2pNUg2Iu0gZ5OKnieOOAkNhgfzqvd7p083Bx7UJaCGQs3lDrioi5+0bCmSQTmrtu0IgAYA cVXdRJcADIxWMm7DbTGRDbNu9qlndim1idtRiJvtYIJC9CKtahIggCheh7UK9ibD9KZFQjnB 61BdhfN2ouOansBiMMTgGmXxQ3I2/d9a1duVXGmXbViISOAAOayyGe7fYc+1aEMbNAxTJGKz 7X93fsRlVJ5qXqht6CymQyRgHbg8+9bEDs0KoiqB61nagySSYUY44Iq3ZgLbIxyT3pw+Ilor airqrNFy9WLSZmwkgHSo7ubdOBHHhasQIVAboaq+ugXJ2B252ds1mEoLksOST0FajENESz4Y Dp61kcfbAwGGFE+gJmwmwxABRnrzSLuIxxmkDBhkDBPWpoVAHBrQrViKDjnrWdquxhsIK/jW i0jhhlePWs/WJCTHuXH4VM9hXH6ftNsoLE44xVqSQfZmUJhvU1V04qflx24q25LxYI6U4v3Q S7GakazXA5B9RWgTtj2IuFA6VnkeTKSBj3q/FKr2xfHUetZxkBQO6aQqvJ6U42LQShivzEVF aM4uX3kKAcg+tab3KMwyvPvRG7FdlHUIwgj2vhupqPzZIwAuSpPPNTamFwJNhwe/pT7N4WtS HXLY4NTb3htFWPJuAWYYJ6Vo3vkCIkoflGKpWsSSXIAxwau6k6NE68A4wB6042cWJEOksuwn JyemK0Qg2nzOTWdpCqhHBDDpmtMhTDJIxO70rSLVjRLQypiiXIwQOa1kbdbqoUDPORWFc/NI pOOvNbsckKWa53EgdqmFr6GezK9xDLJG0aYyBkY61mwgiUo5O4dc1rQXUMmVL7W9c1mSJE97 5hJBz270N6ikWLq2bYpX73WottygEjZ2j3rRaVBAokbkcCmX2BZqu/73ahrqgWxALhpLUjI4 5AzVOzWZ3eRScjqoqW0UGBwBngAE1PpmxVdSw3dOtS3fYLjLa4l8/EvPfGabqN2/mg7cBuAB SJhdQZDn1zWosCuN2xWHvTTbVhmFJKvnKFUjHNbtnIZIAuOlZmopClx/CozWxbEJZxkLgH9a VMFe5FexK0QJwCKg064G4qBwD1pbyQGRUjbcGHOe1SWdvGqggYJ5+tNO0h21LjsrZcg7fasW V2OoIQy7TwfWteR9sR2nA7isby4m1FHOTzziqmwa00N1lKKoVgQeakeVmRY+Fx3qESIzAD5R UrBDlSeccYq0lYrlBvm7jPr61mantyNxDHtWoioqqDzjrWPrWBIXUFdpyKmT0FK6Re03P2YK 2fvetSXsjJEYxjHcim6aY2iyzYJGVAqaVFkiIK845p82gtbGbZxiZiSwJXkGr10ALcyM4XaP xNULYi2mbjCn1q5qjwy2yhF7fNWalo7Exd2Z2n2637kykBT0q5bwywylVb5B0zTdEMK8ggBe xq411FKzqcD0xUx95FrUx5HlF07KAc8ZzTpZZmj2Hj3pZmEVyNykIT1q1fGBrRWQ7T0GKlbE tpMk0IiGNgfT0qhqu0T7hIOew7VoaUPJjUuNy9TUF8Ld7l32hQTwKqVrIlK7LDkSPg5wp7VN GoZGORhahYjzPLyQD3qRcKuAM+9a2Z0KWuo1/u5BOKWI713MGCjpmlQFVwy5JNKCclW3ACnc Jay0DGVI4qJgVGPanEyMQ0afKPvZp2VdNzcdgKFqS046MjbY6oQSCDz71IIwTvVTUS8k9gOl SB+27GenNHUbV9hjiMPgDnvSMQMZp8pET5GWz1pjlCck4Bo3EnbcRnXaR2xistreQSs8acdS xrREatNhWJHuaHwGMecD0zSlC6IScWNgLyQhmGMdKHRWzu9OlPKMMKhFK+OgIzjpQl0G02zO EBEnAOAaW7tZSodTV0bChDJzn1oLcBCeO1HKLlZliKdzh2z2xVyKERJsZTjsKsKg5JOPQ0rE mMbzn0NZpaj5dLmVLAyzEpwh7VJbWEsrmZSNo+8CeauDGckZFLwEwuVbPaqULCsVLqOd9kcZ AUHrVBLa4WV2CjaOnHWt5/L28H5u4qIjC/WiUW3cdyvCX8gEgA45FZ93bXErE7sKfQVqgE4y MH0p5Qrgcc9aJRuhGbaQzK6knIWpNWt5JXDpgVd2BRuzinKQwCnt1NVy6WBRbMjy7hgqMPkW rkatHDwevarZVR8vVc0xQHZwBwP0qIwsNqxjXcUrlWAzz3qxZQTGbDNtjx+VaaRK/wApI46V G2BIQOD3oUGpXHGRRv2k83YCTx1qlDBNBOsp79a2mUY34Bx2psbJMSGXA7UNNu4typei4nsm UNg9hVSzgkhA3kn8K1myGxxj1prAu2NwGKTi2w6kSyOGAYYx0zVPUfOup8lAqeorQYbmBJ6d KZPGcgMeM54rQcrdCG3iESDrxUwd5VKqpwOtK2WUAkcdqXzDGPl6mnawWbRl6hHNKPLUkAet WbRWjiC8VcO0pk4yaa6Ln5RisktQSYwHCnPakdl4Ck56k08qAvzHJqMg7c4rS5XLbYjcq7Hk 9Kz5YZFkyD+laEaY4XkmllUAYkGG7USjcjqQ2rttwxOR3NTEl2w3I9aaoOPT3p2feqS0sOSS KU9nhhIMZzxTruzee0KowD45z3q6SZAFPQdKZIAW5OAPSo5NRK7ZkraTLDsJHFWLO3wOWIbF XMc8UmMNRFaiaZRngK/Nt3HNQrBI8meB9a1GBznHFNyMjilyO9wehDIgESoo2kdcVm3MMhO/ Bx9K13UbiQc5pjsQu0DihxvoIoWSOv8ArAT70XKSPkIeg6VdJXB+TOemO1RFdshIyMjmqadr Fp3MiKK9jmGwggnnirc8W5dpByOvtVplAYYPNIflz3z1qeXQUjMa3bhQOKVY2XggrV6QYAYk e1Ubm4xknnihQsG7KeokxSZBzmsm4mZ35apb6dnct+FZ5XPCsQTzk0uXQq3QS4lYgrkmobaP ByVLHPWneVK25Rwexq/p9rIQocAsOpquUGrDreIl8kZJqf7NJKcHoD2q7bWwBwe1XU4baAAO 1KSuJ3KkMDYGRmrYjKodgxxUkQIk2gc0rqwkILcntS5e4rMprbB5hKy/OeKnkQq2BUrrtPWm nBxyefWqUR3sis6yMSoU9Koi3czB5BkA8ZrWkDA5VwuBUYGUBPINNxuENyLyyq559eKWPBQD HPqakKcggkDpUfl/OVU5qtBNK41lIJHWobgeYmwjj0q0FOSHGAvpTc/PwOTxzQ0mJGZbwMD8 q8Zq6I9pGRU+wqeuDQ8Z6E5qbWKcSAjeWAj4HSqnlSrLu27cVeAcAgHFGCynJz6mqsSUbmHf tdly2aheOTPStMoenakCjkY5qbCsU4oDjp2qKS2w2VOTV8KR160KuGJHem1oBnLC/mktmrPl fJ8vWrPl4z0zQFAAUZBqUmVYyp4W37jmpLWA4O/OavSRsRjaGoK5YZOCPSnbqKxTlhZx8qqM e1QPBIoAfv6Vp+UzNtU0kyENhuaVgTK32dBGqjqepqOSOQL5YYlR7VdjUZwVyKftAIK/lTaB lK0tyDvK/pU08bfw8mrMWFyHY5PSnpg5PcUNAimICeoINXI7ceSCefSpAueR+NKobOAeKlIC uIGJIx9KLW2PmkHr1zV7ZkdOlOChVyBzTUbCKdxAznjjFT2KSIp9BU2R16ZFIrgHAJxRy6l2 0JoSMHjORVaRCX4GamjBLYVsDNSvGBjDZPem0mF2NhQheRwe1OO5DkGnxDBBNEgJlJ42+lPT Ym5nzRSS7ipwT3NXbZDHCASc1MIw3OOKeyYjyOT6VPKkwuNXBTPekbc2BnFNDZ/hx7VIvzKM A5PXNUh6sew3RlMkZ9KovayrIuzoDzkVfkZVAGeacjfKQO461LjcEhsDfuiGUfWnhiFICjBH WkVFHDdKeGwTgZ9KrpYpxZUntmDoUGOc8VJPCZcEfMwHPFWJc4UZpYgytlepqOQi1jMihZ0Y FcDPGau2CbcCTlank4O7HfrTduT71Sj3BakF5CpclBxn5eKgjtWWTc+CTV9VZsgrinGMY6nI pciuU20rFS5t2MW0Nzj0qCKGUQbD1rRLMBkYJ96VsvzgUezSJWhTsoJY872x9KhFo6zO/UHp Wmqk8dTSqpb2pOmx3ZRigdj82CPSraqPJMXQdQKlEeQSeMelG3J55NKMNRFEW7Z4T5fWrNvH xkqBj2qzGEaIndjB5p0S5yduVxVciuJlK6t2IypwT0qKK1bzAHJP1rRI2jHJIoJbAJwQetJx RTi7DGBWHyioA9cVnTWbSOBubg1rsHdQTjA7UxdvnZwMUOFxWKtrHJEhQMdtRXEL7vkGavqp LHPA7Cl2ZbrT5EkC1ZQWBiwJ696tOhRdqcjHOKlkAPTpnGaQA5+bORxRGCArR27ZViTVz7o6 5xSJuGS3TsaHbBX5QAepqlFIEht0jSLuBHy+lU44XEocg5NX/mEgHBUjmpV2qC4XPYZpOKFb UZIh2KVBHrT0bAwaQE7cls89KU8kNjGKpbDd0SI2RuYEgdB6VVvoHmAz17VYRiqgsMg9KdEQ A4OfVfak4pkpmbbROjDOVIrQRSULHvSTOQg3Lk+tOQkqF6Gkk0jS7iQXcKSJtxhv51BYW0lu zB8nP8J6Cr5UN6Ar39aDkgNnn9aOUlyuZVzazAlo+COxqWK1dtjyqQw5rRm3MAdufemR7x99 uOwo5AQTL5kG0Lx0IrNls596+WdqjqK1QVzmnLIBwSORQooG2UbOzEDGQZy3XmkvbN5cFXHr mtD16UIvrxQ42VgSM20spomDM5bNaDjdHtwc+tSpgfxA09dvzA4zjg0oxshXMaazcsSoOewq 5bRSCARvxVvawAZiKFI788cU4xsF+pky2OLgyKWzipba1lzvYAnNaSDsfxqQ9MKoCjqaGkmU 7zRn3tqZlVVGG65phtpWO1yWwME1pJIMk7AwXtUaSOqOSvDHgelNxTM3F7EdtZqIiORxxVK4 sH80mHO49614pNuCtCEmXIAGDkZqZQ7DgkZ1tbMvzzfeHFaCDIx0AHFK0gkZ96ru9ulKB054 FOEbIq2pl3VkZZd4TJBzzV+3hl8kLu5xwKlJAJ4oiLfdC8dj6Vmo2bG421KMdm5mDOpDA8it JiojWNQBjrRkrwfvdz60xQA4bPNawjYEhLgCZfkG3tis2CzljmO4ZwfStgjLb8fiKjO4Z55P 50pRuHLdCIB5ag9R0GKcdoPA+bvQmM80p2ZO773b2qlsNJMMgDI5PpVHVLSa8+eNgu0cjsav YBHynPrT8kR4Cmk43Bu2hQ0+3khZQfnJrQXcC25cBevvSLwc0pIbcWYgjvSUQS7la8sftIDo 4XBzikSEhChHXjNWyuVGTx2xTc44PT1o5ERKNncyZrJ45QYW471as7RlYSkZrQZEAAU5JpVw PpRyRQ1cq31mLlNucMORVCCydWPmEsAeBWyCCcjpTU2HIYHcelSoJjcWMEB+zjy33E8YFZk1 hPKxO4CtiACKUBc5xmlx87Bj3zROCsKKM9sLIQx78VKhGBgcA1FOqbkJOGzUq4UZIzitEOQr FuCuMD1od5VJ3EHjqKAS8g4wKJxGU5NG5cXyvUiQSeWcOdrHtSyABcnJIokXyyqjnI4xSrwn I698U7Cu5O7EBAwT36UojWQFmHI6UxVDHOOnSpolLHoaljV0Mckd6Y8eRzUsoUHH8Xc02MgA vuz2waEQ3cjjCkcnpSgKeT170rAZzgVExCufLXefcUymLuG7A4FCDdKdvTt609U+XJ6nqPSm FQj7kJzQQ3dhKCHwQSaRiSvypgjrSllyG3bvU0O5IyP/ANdGw02NVsw4ZSG71Gee/FWJVyit 0yORUaIM4xkUhxfMrEYB/ClODgg/lTiRu6j6UvloSWXKj0ppkvQaiqSWAOKUSKwK+h4NNbeI WZQcjt60BQ0AYDA9O9FgTGyDuOvrTuSN7ZxQyhUXvnrSE4Hyg49KGNAzA8dqSLnGKGU8EY57 U4kAhduAKErApMdIoxkdPeogDuODgEU7BY8/dHQU2QHPAwKYLzFjyTsXkimBdhcnPPrSqW5K HkUMyE4JycZoFohrjC0Ky7eQM0hILEqc/WomJLYZcc1NgbuSZLnA5ppiRmAkyCO4pE7kcUYO Sdxwe1Gw73H/ALvzTGGyAKjBcgsWXIOBmgoi8459aBg/eGfQU73B6aAHBk2spz3NRyYLHHFO U7ju9Ka5y+QAKLFPRCKiAAbiGpzMwYc/jSSDpTpSNgXgHPWlZBfQHCtls/NTRtJG4nimpjBO Dmm5bcvykKeposg5rIftIO4evSoyuSSzFucinSZaTKk7elSR4jb5gCKozuRkhkHy7QOtNKfx 5/Cjbuc46Z4FOKjjAo2KequRqDu+8fWjao5LjNSMVGF28jvUMijOcCpWrFfsKqgfNnNKSVXP UHpTQcRgN19abFIsjgYJxTsDbe5LMdxAXAHcU1lwpIGcUu0K5Yd6TJ55ypoBIib7uQaQKQOS M08qD8vb1poBUkHBoRWgyQYPB4qMkM2ASKmfBABwBTCRtPA+tIE0iJ1YllTAPqe9MmdFhXGN +eabMxVuDnvVWTczEnODSepcddSG5mLOcEis+5lA4bOTVyVPL65IJqpJE7FiMY7ClqP3bmfP ER0BxTDbbgARleoxW5HbB4lyMt34qWO0VDnH4UdRXVzLtLLBGTya0ltUj4A/GrMcQUZ2ipFT 1OAapGblqRJEivjcTle1NjjjDEPu9qm2Oo3oARmmEHzM4o6jvoKU2gENn0pQUBDbctQVAXoc 54pGRiOeAKegtRzjnOevaoHGJAOTUuxiA3OKTaSx2jAosFtBrIp5Ipu0Aeg9KsgqnUcYqIxg 4brmgL9iPbleT9BUaxjOTnj0qaRcHb2pIwyHb69zSaDbcgZBsPzdetSRqhjwc8dKeQoyCmSa GQjHAPrTRN9RjLkFvSmFOASpJNSiMEE5PpilBKgDJIFFiuZoiZeOtMZenb1xVhSobp1pJkXd mPOPegSZA4JIVTimkZGOhqVlyOOfemZOccE+tMBNoJx6daQqA+0cmnqAv405gpHHU0tREZjO 87ecdaQjLA8cU+TaoBU89DTATu2lcD1oRRGWy3yk0o+UhiufrT5lCHIOfpSZLYyetAJDGO5s gYokQYyGPPanKm1+TmiVlB46H2oYmhq9cseBT2VAm4ZyaYwXO00/YGi2857UrjtchLADLZqW LLHHNRTq6pj0NWLYMF3Bc0MFoSKwEWzBzT1G0At1pEG7jb0qTZsTLKx5600UrWFX0IIzyKki UbCGfmlJDRhsc0qgHkLxiluTYjcNjcEJHrSuUZRxggdqkw4XG7imuDt+VR1pod3sMt8+YQTk VZBBXaOtRIoJ4GMd6kUEHpz/ADoDZilSo+9jFIu18AmnEjYS2cUxIwCGHOKWwiwjfJt5zSgf /XqJHYkkgA+gpyOT1GDT2RINjcBgkU4sUGe9G4bgMdO9KRzkgEHpU3K2Dh+cZp8Um/5AMbaa cBsAgmmo+GJAxTeoJ2JgGfIUcCgMSmDwajUszNk7VbpinAED5SeO9O1kNydx7DBBHU05TjkN +FNVkB55oOM5GBQT0JCxKHqKFyVHU4oUMdxJX8qXcygcYz1pjXkKGcHJNKc/ePNJy56YNA3h QCRjNITv1FZVxuDc+lOddgU55PpTG5PGKUDng0wuPGAP9qkYnHBwaRAN5Zxk0446EYFAcwmS FAapI2BwTz7U053DHzD6U5sAgrwTSC4jttPyrhT2xT432pwDUYYFSGOKVMBMbqYxwz949DQF AjJYn2FORwwG7p0pCwJK/wBKVkDkxFkYAHPbpTkZWbOMZ7UKoAyaXHzbgAAKYrisSDjORRgK 3JzkUm7LnJFOBQPz196BLQZypHy8Z4FLLnDZ4Jp0hDMCMjHTFOBH8XOaVik+4wcqAATkd6kY RkDcvzDoKb8qHAyfShgzNlgc+tAtmKMenJprK2fvHHpTkXkDOBSANuxncO1FinJDkCglWGfT FDqQRk8elOJjI2jhieaGjBIHX8aYm7iqOAc9PWnNndgkH6UMMZU4/OmRgE7sdaLEhJluAMqO lOjXPLHHrT2yyhVwAOtNC85PK0rFvUjKbidpOM0o5J9KlR9qMqLye9CuHGCu0jrRuCaTGhyp 244xSckYBA9SalUpsYSdccVEg+XDYPvTuDS3FWNiueMClZOASvB6UjEKoOePSpDM4jVsAgdB QRcJAxi6Dijd+7HUCkZs/MenXFKJUTkgHPQGkyhoQMODjHNTFVEYJPzUxWGeOM04jBbcc56U EsYuX4POKnjbd0TGKjUhQF5A70uQv3OlDAeg2Et6+tDAhee9NLh8A9qVmwenFTZmikhykCPb j5vUUdwOMHrSIV3YyAtMmGVBAzzxVohj/LHmErninMquAoyCajjyflPftTyAhwMcUDUbai7D yR2HNNUgrlTTw2VJyAT7UzKCPaBg+tLoLqSL5a+/rmmsSXyuQvbmmJgnapyPWpExuAJzGOoH rQkO+g/BPTk0kgyV55HWnKSGJTjFNXdkbnzmncF5jw2eg6Uz5tp5BJqTHDbTnFMVWVMlgSaR d1HUAQF6HPeg43/N19qRNrH5m2gdTThhjkHimSndiq4zxkVIzOFHc01Vy2DilPyt9DSSCdrg SCQTwaQ85GBiiQBm3sefakXPmbhyPSmxqVt0KWXATP4U+NFYDd0pjrGZN6rj1JpwYeWGYjri hBJ3VxzbUBJBI9aI2Xbls4phAKnByKdGYzlWUkAcUhWbVxzOqt9egpSMc5yaZtVuT1pQCD14 x0p27Du3uODfMaCFyW3ZJNAByMY96GUKxwPwpMm2uhTfa7cgcdM0o255OR3qJxnGTjFTRlNo fnnrQgW412XKqqsSeSakwVPQEEUrFSd0fAphc5GO9Tqy5rW4jgSMGPBXjimvnZgc+xp6ABXD dT0qMNhfmPTvTQR0FiG1MNgU5XI4BxRJjy1PGD0NMjVyflxuFGgSV9RZBnGeoPrTPvZIAxT5 GZVJ2gmoyf3Q5wSeBTsJRH/J5J/vCo4h/ED1qTK45HboKaq/IQOntSuJp7BnDEZoZSRk4A7C mbGxkdqkjZXByCcU7ksZH5asEcAZ6elDgBuDx61GquylgOAe9SHbs3L34K0mVYBICuNv401T tyQetA5+RR07UMN0WwqOaLoSQjAbSR1J7UwcDAJ/GkTcpw3bpinuwAyad7FSSYjtlAvpQsiq uGOMmmI2ASR1GKci5UgEcdqLmdgPLdc0MfmCgHAoGQRsxSnLfxrnPT0otqO4hGG5AOfSk3AZ GM5pVzuGDg0BQZCGbGKG7DSI5Q4YYH1qRskbt3PpQpYDZ1z3NIgLOy46UXB3sJgr864qMgE5 PWpXB+7nIqJuVzgUrhfQVEXaxz05prhGUYzyKTa2BtYgEc05WAUD0qW3cdlYjQDgFvu9BTg3 OTj8KVlB+c4po3fw9aokDwcsOtMb5TnI5pse/kFgxB70pBwCR17UDTHKgVTx19aj2nGW/CnG QkdDxUZ3SHbtNHUGBORzUgxKhyvTvUUYfcdwGBUgOBkdKbHJvlEkJiIBwCegpqo2Tk5700OC SXUknoaHc8cfjRYlaqw8sgYBl6+namSAs2F5owScDmiNtsmBnI6ik9SklYTJU4K8+tL97g5z TmBLEnOetMJZR70DjZbiHBB3NgjpTUGR82DSgFmPPOM00g9aNhStccq5QnbxTVTByDtFHOMA kUpbK7Rye9UQOfYSAAdtNYAOdmQKQHnFLlicHpSY0NG0Ajv1zmkCrkM5OD0xTpQFHy5I9KRm GBgYHoaLhruQy7BypyKcgR4sFaRgocjBpduAeuTQ1dFXRWlCIDuGeKqsQx4HA7VdlQketV/L AJ4/GptZD5rIpMjMflAA9DTvIJiJxgmriwqzgDqKmI+bGwcCgaaZVt4hHCrKvPrT2UbgSOD1 p5XB4yKDwhLcEdM0CWgzBAO0A80EZIBwDTkUnkelNTd5rO+DRsTa4MSseFHTsKYiEfOyVJnc /wDSmzhiwO8gDtQgasNkDbQCPlJyKR8Muc9KklLsn+z2qKIlcjHNNFpuwkJAA5OD1pzlQ/yd KjU7iylcCl2YI5ouS0xS2JOVyD0pshZWyoAHpSSsQcD7wpSZGXDJnikxqNxkh+YAg5PenY96 ljUOnPDdhTQhycjGOtLmG43IzyBg8ihMuDjqP1pXcIQF60qqWXcDjmqTIdthIgMncSpFI/zD gDjsKcy55NSIBu4HNO9hFUDIzjFOzkZ5NT7RksRuHYUQ8Er0+tF7jaKx+/gcKRzUSAI7KFz6 VZWJQGJJ3Z4ppQsdx6gUAR4JA6YoAwSuM5FSqqn5pD+A70gwFK+9AkVxFh8EcU5lLccVIc+t NYZJxQgZDJtAAXPNCfeXeOalZDsyCPpSKNz8nmk2CBkB6dDUMo4AHFTvkgKScZqN42L4VqGP lZEF5zUwPlqWHPFIEI46mmsxXg8j0ouNKwkZMoPIBI61LErRxAGTcc84psCfOcDAxmnpERIW yR6ihMErsliG7HO3mpQ3OOo96aq87h27VIFLkMAPpT2E12HI3zbduRTmOeilQOlIAe3FORep JJouCuhv3ch+/Oaa5GdwByeKlIU/K2STTRHnHfHFJbjchFJHJP4U5JN3BPSlEeBg8VGAsZ4H B60xWuPyJCVC4A7+tSkJsGM5pi/M/HHpT5CnlkMDkdKAt0FRf4iMH1p7YzkCkXLR+wFIGZuD jHalcGHBb3FKeO/NOChCCelNO4uePlP6Uw3YgUH/ABpEABxxn1p6ow5DYFMOCT1BoYcutiTP PWpAvocCoo14HOTU69Dx0pcwcruRyBEAA5pyhWXnNHAH+NKny54BzT0BbCoApPOQelPGCQM8 U0jpgZpRnngcUbjjJJkgIViOCaQ8knFNAPJHenNuwBQlYbabuPUKQeMGkhUcqFP1pRgYVh+N PUMjHjoOtFxKI0jB57Ubg4PUselB6nvSc7h0AApg0h2SvBGAOMCnFEY85HHHNJv2Z+UOW4+l MOQuWyT2oJJAuV3MBgUjlD2GaRclM/pUUa5m35ORxS2Ha5IhBHOcipY85yeR3Job922Mg5pS 4I7L7etJMbQ1jufAHFL5cinknaelNO5Wzng0qljnkmm9Q0uKVUuC46dMU5VZwTtyB3piNtU7 sk9qn3nYFHyjv70XstQa5WMUDJPNOZQFyQOentQTlcAAY603zAGGRnFSmwil1ETcB8xLGnjz c5YcY4odwGJxwew7UDcWzuOPSquKyBCWGCMc09V2jINBKqN3TNG7JAxg0lIQKgGGIzSnrkEg UZ7DnsaHBI8sHaop3EGxAd6kknqO1HIOOlMA2xli3TrTk3Bdx+bHSjVisIWxwPvGnpuIwBge lIqrwzD5u9PTcME4xQ9jX3bWG4bBPcUkQbeWkXgjgZqXbnnJHqKVQAQDn8aEyNthFwTh+lD7 BwgwBSyIuCN23FRODuUqeD2ouTa4/ryQCMcCgAngHFMUbCdxJPanHPbGKEVsKuBJhuQO3rQN sgO9Mc/KPSgghgfWpGAY/LkN3pgMVtrcjJqXJdPmxkdKh27m2kketSHgEH8KASH7iybQPrQi kYxn6U2AMrfNnHXmpWZgcgjNJjsMX7+XApxwykheOwzTGy3zEc0qZZgo6d6BbCqozkDjuKUZ JPA9sUzc4aRFGMd/WpFyUAOQ1CBAMKu7GfpSFgxAK54p33U560mAoBUgEdjQncvm0sxGA29R 9KjKnIqQhMgnJJobkcDFASSsI5VVyvBqSPB27ep5NQEOHKFTT4iQMFcYNMixOGCsQeCfSiMI W2kCkXOfu5GOvpQpDLwP8aVi7XVx0ow+xW/LvTlCAYJ59KYMg9cGkb5snvTJY4oMZ7U4D5tw PHpSZ/0bys8GnSJ5QUKwb1obBK4SZ3BifoKauSPalU7yBgEiiPMcjHrnt6Uk7hZsN2W2EYFS blwNp4xgmm4BGc85pMY4xihovdajzgjIOBTWw38I4/WkChuCTilIbI6ACktBxS6gh3LnG3Ha pFlLKUCgAe3WmhWz0pTjcCGKkdfemyW2hQQo6Uin5SSPpihickgUDlR70DumtRFfOCARTurF mJzRgFvpRnPbFMFotClKNvPan223YwbBz0p0xwcKobJxmnJGMcDp1walSQvh1GwbkyuAR70S qrFWwcj0p/AyCOfWk3pggDDD3pi5iNgA4PP40Ehh8yDFB5P9KUAEEZ7UWJcgwpTy1Xj0pgQA ZB5+lJEjoc7sg05iQMAc0rDvcVRknt+FKQgfBHFRM7LzjJqRmygZiOemKV3sJqSBUXDMn5Gq +/rxjFPYtuAzxShRypOW65pxKWgxX3ZIBA+lSABU2oeDTAjcMGA9fenKQMjGfxo2YrNsUAbS M8/zqMoinIb5T1HpSOp+9uI9KN3mtnbgjr70y7aiMyKQVIJPtSOSPmAJNOAXBXGGzxTS4WTD KTRYnm0sKdvBY4J6mkmCFMAbvQ0MGckqOB2oRf3WTtx6UNCi9SFgSRxinsM42jBqTCgYK5J5 zQKAm7sYuOeRnFNRURiQM5796Co3cEAk0OAHKimJsUHn60krKn3qWUMijIzSMisvzd6LAmPQ fIr7hjtSFiCSpxngmmEfLgUiH5cEYI70rA5scxG0JnIHfvUaAluelSSKAgYMCe4qIMS+D+dF kLqOUo4YjcMdOKbJt8rHPHNByhOTkGhAu/c34c0rD1Y3ZmNXzge9NZlz+7OKe4E2VO4AelQk L0Wi1yoi4UPkDjuaQgOc5OBSRRyZ254PSnBQpKjOe9Fhyk7gQr5BBUdvemyJxkMRinBtp+YZ Pb2pmQXxnIPamhNtoa2XxjqOvFTgKFDEfLUYXYSd2c+lPZX8rk/KeRSdibMiMqg5xnPTimFt u4kA/hUkceQWOBj1prgNg9qOppFoIlzGX7Z6UBgCeOT3pdpUdaY4OcqMCmNajtxUk55Ipmc5 bHFOnZtgyg+tPhRhEF3DDc/ShKxDbI4y65dF3celRKcjeQRntVjDo2I+tN8pvKLMy5z0oFyk QGOetOwoGTxk80IpC88GnDG/B5x3pbjeoyQ7XxGuRQ7ZP3cYok56HbSHPTPNOwkAIYckbvSm Y3cDjHJ96cseHJH4mnEKGBHApbMd2McqTlVxTXPzUqshy6t3prHnkc+tGoKOtxM4HTr0pCMj JUDHFPcgAcc+tMKgjqc0A5MjwAdx4NKwydwbqKBgHDnNAdNxUgjFJ3FdoiI5Bz3p0u1ztIBp WKElmOPSk4I469qNEGo0qyD0FIgAySMihmJXBf5u9ObYBjcCcUmirNEcjKWztwaYy7uVH1qR FjMhLA5xQV5+XihaaCd73IiwKFCcZHFMCqqhRk4HU1Iyc5xSNwcZ61QuZkT7SoxwRRETuw3I xUnl4AJ70ix4c45J9KB6siUBJCXIwelShSOVamlRuO4AgdqeB0Ixik0OzWokWfNOR2oYjB3H FTOQOgGBVfaXfgYU+tNK5LuRumE3L3p4IAUAfWlYbX2E054gSMHBH603oNJCZU5Ocn0oQbWO CeaSLaJiNp4HWpeC3vQ1oLoRmNvM3KxAHalILHJ4qXG07d2TTHDEgYAHrS1BMjZMSqmQTjNR lZMMx5GccVLLGSeD82OtLtbZjketPoJXuQFAuCST7U1vUcVZdfkB5Pao5FAUc5FJDu2RxLvJ GPxpkzIiDk7icVLbgEnqRjigxqxwCB35pjtfcrygiAhAd/v3p8ecLuXBpSDkqWyakRP3eD2N FhRZEzbSBtzn2pxQdQp6c5pyrl9tTSR9h0oaBvUqldpUg4o8jcc4JzVgxs4AChiKlUIyYU4I 61Fkg5mQRx7F54NDj976n1qZweNqZzwc0KVSQqODjvVMd2NTJJUDpTk3emBSwj5iCakLggYX A6U7CfYFU9+lCBixAIpwOVOTTVVt2AcZqSnsG09G5NKEbtT1X5juBoDlieMGlcnVjSWYZYYI 60gyeMDHapFjK7mJzQG3DOMGmmNaDGDqQYxz6UjCRnBdealwS2T0ApF6k5OT0p3GlrcFLEYx yaeiAAHdt5pgJ4bkGlILAE5pBswk+96j1pVJ6j8acMHI64pdoAHT8KqwW6ojDAMMj8KeVyCx AyemKVkwelPKN5YBGB60roTdiLHz4XtUgyTzkUm3J+XtSjcBuxyadroE7sUKPXNNk3gYX170 vOc05cyLk8YotYXUQFtoHTFO+Y9KM7jtPGKcDnK9D60DUWxwODtx83ejzWRsBAwPr2pOQRk0 oOQc4oJHqu89cfWl3MikDOKjjyTgc04jBw2Qe9Fi03cVMFsetLsBlAZvl9qDsCFcdeh9KYig dDmhCbuTNt3fIMY60nJYtjpTcjac5FKuVXG7OaAWgqsNxOM8dKRixwNop67lPI47UEnOQMmh lxaQ09OAKRfKkHzDkdDQM4PHOeaeAnG0AetKxM5NjTkADrjrTt3+zinFQRg4zSPwuD3pkjkk wudq0SOCMsO3ao4gAwzzUrLkFeme9GhcrBGcAgjOe9SBkWPG0ZPc03IQlCN3pTVz1Zc0WM2K Ac9Oe9A4bcOD0pGJUbj3pVO4AKvNFgvYDnvQemTT03NkMuCOgof7mMdOtFrCbbEVsYIBpZJG Y5IFMA3D2HrTxGcBiRinYauAZZONoGO1PR+PmXCj0phUZ44p27I2FeaLCasKybvmQ9fWlaVt gQoCB3FNJbAXAGPSnjaOlJKwAG655pFchgRzxjBpRtBPoelJJy+V4ApjYpOfehjsxu4z0pwB 2BgDTTjfufnHTNJjsITk8cgUq8Nk8ijoOOhowfSiwmtLiP1JGcelKJPkBUEGnxjZ975iaawK 5ZlzQNRH8YyVwTT5PnRcqBiocNKgPYdKfuIUA5NMTHoc5+bpTlkVc5Uc+tMcIEBQ5JPNLJHv RBjG09aTQ1qJkk5HC1IgHUg4xziggMMdqIicGP7pA60XHKNgjw2R90UKSATuyM8cUiAhCG5O aCFZgAwz3FK9hNWA4LZznNIyjG6lJWNjHg80MoI6H3o5bA3qOg8tjk/dx0ppPPt2pMLGg3Hq e1SbQvGc5ppDW2oisNw3nr3pMZlwDkU5l6HNSQoDzt3ChijLuDs6IFGCCeaSXD4WMFSOuKdI QeMbacnAyO1JJ2HezI1yGwfxzQT1OMDtTm+ZieQaUAFCp5zVFyasRphzgH8aeECuV37l7+1I UX5Qo24qQNGD8y9e9BnGVmImFU7Tz2NNLhmKkfPinwbWLBlIx0pHHOQBU2sxt6gM9CPxpeMD nJ9Ka74YKqfMetO24yaZSsBJ4AHQVL2BPOahG3JAJzUgXaoBOaCJX6AWO7cD07UzAkZgTjHN SOUb5U4I6+9IFBOABmmOPmIpBHtSjinKvmHYNoxTZGEeQc59qBN3dhW+fB5pejEYzSLycZBP fFOKd/5UJBqUJo5GlVlcAKfmFWBt2/KTUQ+Zxk4OeamcKD8p61LRpGz3GMQfvGnPGCA4SlYL tweTio4mLOc5GKL6E2dxwKlTkVEMYLDJp0hbJ2DjvSRfIpXOKIhJJD4n+TcQfYUhAOW5BNMY /KF5pxzgKe1K1mSo9QJBXgZPrUT84z07CpMgDk05RlcgA5qtDRO61ImBJzjgelNLouACck0+ V2jVtuOnNYbrNPOY/NwAcjHWolOyM23exusw4G3PvSfJg8c1DbK0abSSeMZNPO0octtIpbl9 CORiG56AUfwAjr2qo1wGkKDkj1q5BjZlhkCri09BXsCyOPmZfoaaxDgsetPklG3b2qIkJGXH SqJT1JPNjjGQWB96iV1aT3NZkk0lxOwQ4CnmpIWeGcCTlOxrNzsx2vqjRc4BxyajDup25AzT bm4UoWUbcDis21uzLckgk4PNN1EEXfQ1e45/GlTyy+C2FHU96S8kU24MQw3es0wXLnepIGOe OKUpBdXNMuHfapJHakleNOHY5PTFZthK4kAZgGB603UpJUuRsO455oU9CTURWMXJyPWhwmFz zUVqxaEEt8x7DvRfylLdjGn7wVd9LjSHPIisNp69aAE35JyKzokuZIA5HzdTgUtpclmkjPzM OlQ5pFOKaLrsCxUkYFNLbpQARxWXcJdS3o2Phe4pZjNbON/G48HFHPpci9jV+bJbPGOcU1Vj wF3KM85NUp3eK2Vyw+YcAVTi86Zd6Ek96G7I0ia6nk88DpikLH7wxk1UspjKfK5yvWnTyrG4 Q5HtTTQpJFlT8uD83PJoUKpIC9R1pIShQBc/jS8biCxFUtSXoMmZY1AxgDkml3mVxsJA/ums 7VfOW2bYx744qXSXlaNC3LDrUpq+or3LrAklWGMVGeOO3apzkuc8mo2Qtk5GFqmio7aEcocO AT15pSp8sNx+dCx+a5+bDe9ZMrTvdkGUhFPQVMmF77mqXDLkZIoUj+Him2oYZ8zIGPSlcqr8 dM1Sd0U0iRfXNROH8zL8AVHeXMcMgC5P0qTzTKoLcccCpUrsnUeWDPkrgYqNwFPXOaExjAPP vStg4wOfWmNWSGPkjJI4ppYEA7gKp3dwqyCONjuPWozLJG4G35fep57Ex1Zpb12nOahaZUTJ JJ7VEtzEqszc8dKx7i9kNzsVcD1p8yA2vMRVA+7k+lI+0SgljUMDrIigruPfNU5Xmnn2qNu0 46U5Ow07I1dykZDHbSM3fp9azJjJbzKr5B9Kt3csj267VGQOSKhSuJrQnAU8N+FRlQwO4Eiq tpO7sMjgHBzV1zg89Owqua6B6EaqBztyo7Go1k55wPaluH2RknPPSsyK4d58HgA96V11G2rG mcE5xjNKFBbLcgd6F+VQzdTQSGO3cBVrVBdhk7snGKHdevGBTHDHIA6Cs4tI9x5YkGD2qHZa ksvGUZO5sA9KWQhYgww5PeqbxMRtPY1ZQMkeAOAOhppj0JMExLng+lIE+fhiAaiS5XIUIQR1 JqzkbOQeTnNCs2D0IrhNvcUKylQoI4FOm5iIHJ7VmSSNFMiMDk0SdhqVlY0gATk9ulI5yQDm hGOMFRx1NOO05x83oaaHMYwx8xFIWY4YjipmcrGFIUg9KjnyIi4wMU20QAdeh4zTyATlelZN s8ks5Z/u54rWJwAI+o65qb8z0He4saj5iT9aTazNgYx2pH3Fs8BQMmoDc5mCrTvYNicDnFOc fNgGkXP4dzSYDElecdaYIaFcNgnBNQyABVAJJzzUgyzjL8gVQu2czGMf99UgbsaCeXtO1sE8 YFNkTZtGDhv4vSqEfnIy7uAOnvWgr+ZAWZ8YHSlfUfMrEbsoY5wcd6FdtmBn8qzbqVvNCjgC tK0O5Bu4AFNSQrdSSEEA5jBz0NOc4+UjDdxRK5jj3g9OhrONyzXIfcTmk5JAa0KnYWBwehFN ITzAFIHcikVt2z1PWlKoCxyBj9aHbcq2gjOd+M5qNx85J606VX2bxgimTtgKenrTWwroejqz Y4AqVxjABGKxbm4mWVTGBgnmtW2Y7FLjdkUlK7shXJY/3ZY8YNOyuAd2D61BfrMIjsKj2NVr Rt/Eoye2KTetgvc0HlQY+bp3pUdWYksFGM1m3Yf+FSfQUzy7hI/MfoegpN9ik7GssqEjngmp HXgk/hWfpjA5yDmpZJ2jlwx+WnFq1yG9SyQ3l8Zz6UhLDC44FEDGTLoeKV13cjgmrt1Ls2iJ pFJwT14qWPeI9pYEA8VmXokSVQQevWrlnnb82SajmVxItADG/OD6U5cEVGeD0xSxna2TnGKt aku6JJJFjCg87ulNaUfdL5HpSy8w5CrgetY5MrXPyNjnlanRD6GumCmc809HZRjGRUUCHGQM jHNSEkEkHAFUJD2A6g0pkQRhMfPnrVLz3aXBXI7GrXGMkdqSdyk7COmOQec1IhAG5+RUe8Hk 809QWQADjrVW6BzDWkU89qdHIGAwOvWs+eb96Vzx6ChWliHDcHpWblZk+hq7VTIVjTVYGTBb B9+9RW1wghLMuWIqjLcbp9uOc9abmkO5rMRnAxzQMINzdKhj/wBWHJzUM8rSMI1b8KOaxJe8 3zFGzG0U7btXPf8AlVW1jkRSv5U+5m8tTk5NO+lyr6DvMGSCxJ7U4vn1ArOjMkw3DI+lTW9w sIZHy57E1PtNRJlwy7EAfGRSRyxsTtJ5rMuHaeUAZ3ZodngkUDO7vRzob0NZv3al2O4nt6U1 njdVBbpVea6C2oVhknqcVELed4TMFPlg9cUOokNM0VIZPkPT1p7tmMLu59KzNPuCZmQKSB61 buJY4Q7upJxwKpSTVyXuSZVjweR15qeKTYpXHGKwbG+aS4DooHPOa2QwdWkbk+gFCmmhbj2L EgHGMUseFcMp571SivSCUxwT1PWrlu6E7n4HrT5uw2h00wQmQ9CKSKZWXPGDTLuATRMFYFR1 561kx7459iscDgCk5WEbmM9PwoLEgLjGDRGQYA24lqSLcUZyBuFMt6oWTcTnpimqyq+8uFHv SeYeCwPzVW1Ioi4HTvTvbUzvcsxyLIWKPzSwhwm52zWbpqyKNyvuB6VrRqSgH8VSpcxQoOTR j584qKSfyvkON1Nt5yznHJ78UOVnYelizvcDYMiPPNKyDHzgkHpTUmXc3mMAvajep7ZHY4ps G9LDlj3jC9u2aa0qgEswGOtVbyVo1yCVqosE06mVCfl5NJuwNmqxBUODn+dSbwAc9+xrOsJi 0+xmwM8Zo1eZ4mYB+nQ0ubS4J3NSEKYyyHAHXJojycqD161k6ROJSWeQke1aPmEMTjKinGVx DnKxNtJ4B7U7zy42g4A9e9Y2pXreZtjwWPar+mb5IASuWHJzRGV3YNi4DlcVIwyu4cEDp61B I5Rc45JpROWAHGe1O1gY9naNQz4FMSWA8knce9UNTkJYrk59qgkguFtVkU5H8qhyC5tD5lLe neo/PjUn5+MfrVCG7Y2oTkkdaijge7kAXtzihzshqxqRvGy5BySakUjO4sST61j27yQ3GD0B rVklHlCQKBkdDVRldC3JbiWFSFjbPHNLFIwGQ2A1YF1cu9ztB2j2rYtmY26gjt1NCkmNJFlm DE+1OQFeRwT61npOYJRu+YE1cEjMO22mpX0Q+ZdRWZlADnv1FPN1AXyo6Dp61BdRuwCRsMt1 J7VkPHNDfeWZAyjo3rUttDkla6N5DuG7GM9qcACRkUyCRmiAIwQOtO+YOOw9fWqRN0OJyQuC B2ondYo9j8E980M7KcgAmsrWiZI2BchvUGom3uhqxfjkVuA2cd6niAZiD061naVExtwGbJHe r6tjA79qqMm9wT7Ckd1GcdaNzZ61Vu7tkLsmA/cDvSWlwZYclTkmmT1Life+tPIx8wIx3qKN gEJd1BHSpVdQof5WB60wb1GtIEIZuF7UsdxbvIACfcms29uXkfyFGe/SoJLa4gjS5QjZnBBH Ws5TsM3hNE3yRx49/U1GJlTgZz3qtYXqNFmRNuOwFYN9dzG7cKzBeooc0g12OgIDNx8pp2CO Cc+9NeNWJIYj604ZEeAOBVvUqWuwYAOc0R9TgAZoDA8BelMVjyB0o0J5mkPwGUgkD6VF265x Tgu1TikBbk8GhIafcdH/AKzcq8ikY7mJGaI2Kr1P1ods8AYFDQXGkhhnbj1pVcovyYpWY+Uq hRnuaMgcbQaT31E/Irvhj+8zg+lZEagaozjO0dOe1bbiIRsXYj0xWNCAbxzuLc9KyqAka64Y 5PC1VvJgqYzVp2DglFCg9hWZfIVYN1HeqnpHQTdmLawO37xsU+9ufIjMattfvU9pKsu1VQYH Ss/WmVbsKQCSccVKVlcL3ZF5lwFyWz3zV0s0tgw6cZyTUsUcZtlznPfjikuIk+zkEnB44pwT tuDKFjLGgJAAOcE+tMv5VZ4yuQo6nNLp0STl4kBAU0mqILVkiZSykgDjpWOtmFy6kPn2gdQD WdZJ5dyyYXrwK1bIH7NsHGPSsy2KjVm8zOe2K0kk7BHSRqFeP6U1rx4fl42kVYbaMsGyaY8c LRMXIz2rWysS5amPbpm7Zwep6VNrTsJFAYAkDGBTbVg14Y1XjPJqXXv3RRCgHIrK/uMLkNnM Y2XzGPpWmoWRSTzms+5gjjsIp0lVnfPyY+7Vm1nW3sw8mWfquKcHpqXbTQdLL5CuAcZGMVT0 6FhI0xUAtTIvMvZyz5wxrUePycJkcDtS5eaXkD00InVPvjGe9Z2qyJcusQJ4xxV+7ZY4twXB HWqmnp5uZdobPOaqSXwiGXELJCpPTHFNs7zyLd41VSGHJxUuqPIsACAde9NtreNrZ8r83XIq JJgivpoYXBfO3Jq7exKzE4yfWqlhva4MTEbR0rROVJJ5xVwV1qNpmbBKyP5bk5zxWhkOob1r LuCXusxknnBrURcwrhcHvTg7MGtCrqhQ2pUMVIpmnOyQALznqfWnajta22kcjOaXSHBiYeWO nApPSQItJ1JAO6o5Iwxzkjv1qRnIHv6VGxIUZBya1K5GhzlEjDKx3d/SsSNQNQaRpM56CthV RgwZjjHWsWNz9seMrhR0NZ1ETY2pCSoCsG4zx2qOd1WHqNwGadGCEADYHX61S1NHVUcLgHrT WkQb6DLSMzHfjv0NWLq4WGNjwGHQ9qjtJUC45+tUPEJBiALfJ396mKsrja1CS5kdQWYgd9ve rEF3ut96vwOMZ5pbBoXstjIgAHBPWmoiRI7Kucjn0ppXe4nsV7eWL7Q0vU96fdTLLyCCaqRR NvOwYBOamu7Z0gMn3cjis3uCaRJBCHg4PPpVKe3CSB2OTVzQ5pAdr4+pqHVAFlAbOCe1UtYg tWaNmsSwqcdetK+2PMoAHem2o2244GD0p0kPmx7d/HpWqVx2KGqS/bHSRRyOtWiq/YiF3A45 qrcoYCBVjfK9ixU8DqcVhbclszY5HiA+YnnpWlbTqy4kPPrVC2jDB2dselNs5MysuAV6U4XW o0S3UjNKUzuXsc9Kqxoou/ncewzViW1kab5cn0xVORCbgKRhge9Em2x2NqedY4FUckjrVIu5 GV496Zdl0hBY7cDipdMj89QpJLVau9CX2H2dwX3qM8DBJqnuWK5yBljnnFaaxRxsV5DZ5A70 ye3G4FQADSktLBYht7lGJDZ3VbQLJxkD1rOvIhGyEjay1ds3zHvYE54oT1sBWu7crKWVztqW 2m3HbJnjiprl18naV5qtaBhIScMM8UN8rGtNy5uQDGOvSs69/wCPgHjitPYxXey4B6Gsu8iz dA547057IV9S3CUYAFyFbrUrqi5VTwOBTFhBgBBBHbFPwVQDsKuL0G2mAGB7Uy8DLCcEbaep I+XHb8qbcIPsrMWJPalJKwNaGdpr5lPHIPFayYaQs3QcECszTUbdl14zxWoQ4wUABpQZLKt3 MFLRqPlNNtIFPzDj2qO83+dvZc5q5akPb/eG8dvWhq7HYiuZgPlXIwORVaN5QC2do9qXUEVJ FZZSCeoNWoYlMWWXqOal3eg27ohDoYieTmqEJMk7ux4HAFaaLGoZGHGOMVnW0ZZ2AHOe9OTs hEt3KjQqCpyO9P09VniJWQDHrTLtHiQcfUmpdNQbMnpUfaEUr4ATD5eau2rf6N5ZHzZzmq19 GxutzN06CrcCl4+1VBasq+hWknLEoT04quNolBJxk1ca0PJUcVSkt3+0Ddxg1NSLbFc2JWRL IOud1UGuHcBm9Ks3efsao4IqpawErgEkdhTne6Q7lm0l3HZv6dqZfSMQEyMZ4pbe1PnNjgkd KLmzPmKWz7VSvYkpGNt4OeM1r27oI/mOAB1rMnik84DPyjtV0KBadMhv0qIaMZHdSvIzYJ2g etJpYcsGfgZ6ZpYImaNlUFto5pdNIacqM/L60JNyQrmq6xMx+XHpVO8m/gBBI4xVu72pHvB5 xWVEfNuh8hJJ61o0th3uWbNNvzc4PWnX0RlGVHAq7bwFC6SYpHZI4mcNz0xSUfdEUrSXaQrd CcYFXjtznbx2rJt4y85kJPJrVjBK80Qb2HdlXVDlEDDGOcipNOyq71IJxUeq71ZWwAuKk0xQ Uzkqrd6LK4Jlg4f5jSqcocDNOI2jCnimsXQBVA960sNq7GucoQcg+lULNh9vI2fU1oSqREW2 knHGKytPd1umZhhiazmrsLG2hZS3l8g9arXcqqvBODU3IICtwR2qlfwStymAopt2QW0JNOh3 lm5PcCpbt2WMKDg9SKNPwsOfMAcdQO9U9YjJfcjsp61mk0ritqCvMQSq/U1btmdkO44wKfpz L9jAZRk8EmpGSPyjgkYp+9e4bmTEMXD8grU93LH9nUKhDjjrVeKNhcMBzk1avIfLjzwcjile 6Yk2mO0/c0QUYOcVXvIWgulDsM5qzp2fLXjaw64pmo/65d1Pl90dy/A4FuQUDDHB9KzEnEc5 THU8mtK2CG3ODxjmqUMUbXuzopNOb6CZaGor5iw5G4cg0urFZkRhgHviqt9CkdxuQZIOM069 QPbR4JB9RS5mo2HYdZTFEK9KhkAa64PXnFWLa3LQK2enWopYzFcgpgtmoew00EQ2SGQ560y9 nDXAcA5rWCqyKWUdOazb+JVkUqcc9KbjaIMfMudPYj7+OKZaXchtzCZCvHzLnrWhap/o5B25 PTNNe2U5ztVu/vVcmlxNsoabL/pbgDBHTPSpb+Ys+CMk+lNt0zcEjAwccVeksfMYOmBx3pXa RN2ZMG2KVQyck9q3o2eVCyIAoHasR7ci7++Tg81sWyvEoCtwadPVDTKN0hR9xyF65q1YXKPh W5Wm6hNuhaFjlfpTLOHGCBgdqvYrdGggAY4HFY2AdRc7vrW0EKghm4I61jyxIt0XD7TnH1pV NkSa8WFjAzkHpTlI3cg4pi7zArM2QOgpxLbc8ba0T0GkJMGzlV47VT1Fgw2lTnHNX+D0yao3 2VyeQe9Etg0DSWVE+Vfl96vzSDG4DFU9IZRAwKjmrckZMQU9DWcH7oMzZ3NxLgDhep9au2kR gjMgGSRWcqG3udrE7Se1a0nzW5K8ADoTTSvqyU7Mzbh5JphswADytOje5ViSpKhsD2ptqCt1 ubpnmtYpGSV3gjqKhJuW5o5XM/UpGeNSyDIFMsriSOMjsRyKNWWYlSvAPGaksrYy25bOQg5P c0K6kQyl8/2sMgGCcmr2owM9v5oX5SP1qqgP2rHUCtO/KvZqEUgCkneLDbYp6SiRR7VA9x6V PqDqi/KWAPWoNJy8mGGMfrV6WETnaTjmqhsMxJFjOZGOG9a19MlVbJnEgB9M1n3tkySbySY1 7etW7OELbmTjGOBmknaQiC5ut8uQ34Zot7tllAb1qC3AubkhT0PArSGn+WBI+OtEZSlqO6Ga h5gZXCFgw61BJeyiNY9oCgVtJEBAEdwy+lU7+KFIgepHQU3H3biKulLkSeWPvcsWqOGZrW4Y xk5OaLZzscA4J9Kk05keVg6b8elRZ2DcapLTEnuetTajdkRqr9AMVBco4vk8ttik81pXVmJQ qlxxjk1cb2FflMQ/dVic5Nb9rJutUTHQVk3duIpiFf5RWrYxDyFZmz60objUrDNQtRsWUZ+g punXG8lHUjHap764jiQrv+Wq1irM3mA5BNP4ZaCkaiKpBBHUcVi3QKX3X5c9PStkAsDztIrG unX7UMjDE/nTqbFJ2NVCGQEDt1qcN8oUkgD0qGMooCgNnGakibIyR+daR2KST3HxoDuUHrzz WTrMICEo3zc8VqYwx2nOefpWbrTBVBTPPWom9CZE+jti12tySetWZmULycNUGlH/AEcnGRU8 8PnW+5VOQOvpTu0riiZsMTSXLNvyvoavzjyIMhOg7VnQzi2uQsmTk9a0L6YNaHy84I70o66g 7mdCJJwzjOD69qms/tC7o2BKjpRowZUMcvzAnOfStOVdpG0qCR2oautBq73MKeR4rpSRgGp7 q/ZoxCASoqO6VPta+YSfmyMVcu4IfswkiGGNRyrqJtoTSgpJLRlhjkGqOoxxpKTg8noKvaRv G7c+D2qrrRmidWjUMSec05pWQ17yNI7iTkGn/MwHGBSvy+V4HpT2bcoHTFamkpX2IvLxx5hG etOO2MBTjPY+tKOcelI6qZQTgqKZLjdaik4JI7jpUZYYO5D+HenuwJOOAfWgYJ5GR60AR4Xh sED0pTyflyR24peC+BwB+tPfy42AXnigl2GRHczIwC47mmgHfgDHoady0gycAdqT7jHJzzx7 UrIbVkRTKxz8oNYg86PUDKiYC9Rjg1vuc4UcZ6momjUdVDAVM1daEJtDIX8xN+3aD2olAdMs uVPAIqXA8vAGBQAWG3+EdqVtCuW+plJDLDJhX+Xrg0l7AzsrhTkd61mRcbmxx09aWYK/PHI6 CoUGwTsY0t44tVhjj3NnkVahjle2IbkDtVpIYVYEIMjrS/Kr5HTuM04xkkGljIIe0mEqA9c4 FNElzqN+00q4QHoRWs8a5LgqeeBTowFBbgEjtSdNjRVuZ1tQxjHBXHFYYuWWYzeWzZOPu9K6 ExBjtIBzSeSirs2gAfrTcWNaMiUObTeM5YdKz1upI0MTrnnritpmBHyKFA7VXeIEFyq8npTS kyTNsN8lyx2EfNx71NrsL7kMwYcAjiryxoi52he/WnXBExTzSZAAAaORpWE4u5gzmS6jEcWE /Crt1H5dnHjJbHNXFghST5FAHbNSSxD+I54qFTlazKvoZFjd+REzPEeRx7U/TbmaeZiynGfl Bq+tvCx+ZQR7UiRIvKjBFVGEkVFJrUh1tcwkOCMjoKh0dGS1RRlcDoauyleN43Enj2pyEREt gEnpVcr5rkvcp6jG0kfHQVUSdooHVOhHStUqGGW5J61C1vGVI2gnPFTODYmihpsbyESOhHPW pNTkYlowSM+lXYkKLsHA9qSSJOrLuJq4xaWoXZWsLZVjDNyD61ZIAU7CMUsQAGCCBSqUUY29 acYqIXdjJ1KRzEVjTLetWdERvKzIBnHIqw8KFuBxT1VI1yDgVm4SbuO91oDKrFgeDTHTI256 U+RlwMknPpTSApDM3y9q1Q22MCpGrI6k57jtWKwZbpmIynY1uMNy5wcE1C9vGxIIAWonBvYm 5BE5aMAr9KS6LNGFbt0qYKqrgDlelQXLM7ZJH0prRalJczMmeXypVTLDeabfRyywYUj2zVma HcwwOO9WoEWQBGwMDis7O9ge5kxzNHFgLvwefar9kfNj+UHafUVYW0UMRgDPWrMMQiwqAVai wlJ2Mu6gaJyfbpVeeWWdY49p2Z59q25kD539feoPJAAAUc0uV9BIqRRCNBtHAqrqEpklA2YA 74rYEXylcU02UO1nz856ik4O1gvZlaxkBhK85HTNRu7Ry8A81eSBExtHbmmPEHG08A9cVVpA 2Z1/I1w6AAECnybhaMiOVX+771Y+zJGmIyePWpBArBM9+tSqbsF9LGKGKBUbnPQ1JaQ4O/pk 81otbR7/AJVGB0pUixkYBoSdrB0I/NeIbk4I6VkysWud8g+YnrW2yADn8Kr/AGaIk7hyelVK LYkivebriIHbwoxiooZzCAyZGK0VQr9wY4ximfZlKtuUClZjvYgt3aWUs4JJpGllWVw3KjpV tFCAbVxxRKiyDDfpRZ2Bu7M25dJpF5LE9fatG0Vli6cAU1LdNu1VxzmrSRnbtPX0o5Nbsbkn ojOuUe4uxJuwg4wKuwwxocjOO9CQqrHHHqKew+U8YX+dEY63YWYkkpVSByuOKw7kStcq+75f St1ER02ucHtTfssW8jI4pyi2SyOIL5a4+XPY05sZ9qeQNuMdOhphzjoapIpRAAntTLhX8llH Qc4xUoVlXAbJpWRtnz9SOaGk1YluxjWbSoSr5yWzWn+9Cqcg5pEiUZO3Jz1qTacDb1qYxsDd yKVRIhUkk/yqG2CwEICdwq4gKseADSiFWDPgZ9aclqIz9Uh3Ms4Utg9qcZW2gspAxV/B8kpx jPSmSQhcKcZxUuLYFe3RnJznntUEsbRylgDWqiokQIHzdzTJI933iMGm43VgMmWRpWWN1J9D VuJDGpwKnEKhsjHy05SuGBI+ahLW4GHqO8yBgCcHtVqxZmXIBFWZYVJ6ZqSCNV5Gc0KLTuUm LtG0YGD3rMuBL9rIBG0VrgKSQxwKbPBEXBTnFE02IrzCSe1G3qvtVaN3jkAxtxyDWpGu2No8 gDqfeoHgj2jDfMT3pON3cErlWJ5JZScEju3vVxjI8attzt4pY08rjAApUUlC6vkMelOI3Gxl 3nmmZWXG3PzDFXImc2hQKMHnpVjyd7cjBx1oVdp2gUlF3FZlCFngYhSRnrTLbetyQeFPOa0Z YQrDjk0eQgw2Oe+amzTG1ZDpCjW7bjk4wKp2kJXJJ4q6UUr8oFOijVgSueKbu7By6XBSyqJA TzVS58yRwABs9avRrkjcTt9KcYgHwoyKuSuSQ20PGaskBVJY9BS52LkDJzQMkn3oUbDMm/Zn j7nJwKu6ehW2Ve4qdoFz0BpVUKNo4Hekk7gkKT7UYzS7SV4GaVMdCfm71WxajbcYzGNGXqCK xWjkS6OMkMa39qE4JPNQPEisSBkVLi2TKxHbCQqdoJKinoxcYk4B7VIpKx4TgkdaR0LJ06d6 dtCUjO8sQXJZScE1PeQmW3Lj7w6irCxqwBZRUyBfKKFck9xSUdCramXazu8e1VIA7EVct2Zs qy4HepvLRcgLUkSttPyClCLvqPla1MyWJ47lnH3OwFN3SSyhSpK+9ajR7lx+dIqKACFGR39a FAl3IoQIVOBWfdyuXG1SQT1xWxGF5zSCNAc7eDTcXbQVinaFmUx7SCKgmiaK5EikkdxWoiKC MnA7mlkiQkgHIpOLZbjZGZOZJnUjpV4wEwKD6cVPFHEgBC8nrmrEW1TkYyPWiMX1J3MkGWJm wSAe1PtYZJn3sMmrpg8x25GCc1IFVIdy/LjtSUNbA1Yq3DsMKONvb1qpHHJdzgMMYNabRRyA ZY+vHahUWIhhkmrcW9AlsMKeWpXg471SmllaUKM5961QgI344PWohGC5JA68UW0sJJkFjFgF woBbrmp3ZjlVOQvXFSOjJGCBnJ4FCo20hgAT6GmkrDSMZ/OFzlRlSefatSM/ucuDjFPjgB3E 7Rin5YhYwygDrUxjZCM7yZ55Plx5fU5rSEahVA4AFOSMBzg9aUjdlegFOMQV76kE7yFCApCg dfWsgwSTXG852A8Ct4L/AAE5x+VAiijUlhknpipnFsCOJTsCscYqRQFG3GaUeuKcBuI29Mc5 rSw/QQ8qpXH4VV1INySpIq0iYGRwD2pxJYGM857GlJXVhGTpvmIemRmtNTI5x0FLFGqk7V5q RQDz3NKK5QZVuLcy5xjcO9RW5IPly5BxV5lKtjoRSJGskuWOD2pcrvcOW5kTwTpeeYM+Xg8V KslwzqUXKHgitPYWOGOR6mlESIMDjHejldwSsRTQM0PzL1HFZ0Qni3ImVHc+tbGDjBOR7mmk iXbGUChelDg+gGfZQvISXABHT3qS685YCidCelaOVX92QMe1RiDcTnFJxaVhvQxdM+1pOxkx jPGBW1HGz4wdpPeljiUEjHNSKpAOKcU4jSe5matDLH8gOc+lO09WFt1yccg1fmVVAEg3FqWN FRePSlyO9xWMhoxb3AMS4LnsOlSpJcySmJzxnjIrTWJC2QoJ7Zp8u1pAxjAI68URTjoTFXZW YNGmF+c4qjM09w65TABwa1m2MOFx7UixKXJziqkpMpIrW1rGIiXIAPbFUIo5bK4cxk4Y8cVt 7ABzzQyIQQygn1pOL6Dt2MsRSTTKznOK03jPl435pYUjD8r8tSLtyQRkURTQOHcwtQjmeRRE BkHJz6Vp227yQHGMDoKmEarksoPvUjoiqu3kH26U0mnchozJrd5ZfmQFc1fhjSEbYwOnpUuz 5QTTkQd8A+9K2tx2IHB27u/esudJHlRlUcHkGtxlXIDYYUwxIZcjHHSlOLkynHQevzQ4Pytt 9KZH5ihCQGHSnuWALFfpSZORjPSrjpoDWmgrE5LbeprO1mCSeECLCtn0rRYMVVd2B3pG24wR kdqJK6Go3VzM017iJjEykr61qKxVcBuCORQAABxge1O2E8KAT2oitNQsUb213x7woPoadau8 tgYXiwwPXFXJd6qFCkc8inYxxx0pcthWuzF23FvyATntipbCK4kmBlJVDWmwjQhcbsj0pwUo uwgGpUWmJpooanbbkP2cDzB0J71St4r18JKmMda3VQ7ugBpfLYsQGC+pokuwWb2KccOyPCjB A61l38V/LJmNgB7it9wxOw4IHpSqioMYBFDi5IdrbkAAxg5JB60A5OacG5yOtIgBJIH1rRFy 8hpYBiOaBtIHvUrbVwcDFRjAJApbg7tDZokyOTx6U/gqAP1pAMnGRUbgl2A6Ckm7hy3HPxyK bnJGCKciBUYMRuHtTYwBkcZ/lVbibt0A5U5P5ilZY2G45PoaaSAxVGJ+op2H2gONvp70m7Cv rcjldlUAcZpqsADup2PMcrnkUIUHBGfrRF6Cdm7jVLbPWhSV6Z5pGyPmB+U0j7gAAP0p2Hfo hxIwSTimF+MY9803aJFwexpWBCqGGMd6BWHIQU5601gN23PWlXBcbiMe1I4CvnqCeKByjYZk K/1p5Q7sEUmSHPAokUhtwY7jQEVcUFV2k5J9KGYEkuCB2xTV5GD1owRgD170CvpYVgxG6MHB 9aRCWOHU7R3p25sccD0pqudpAzjNCEA2B8uSUzxTnaPzCYwdo7Gmuyr8uRimIGwTjj1pNhcJ ArfdyCeeO1PXCxbTlm9aI0YAsozxzTFyzegNNCuAADfK2CBSDGMkYp2zBPPSkQArlwTzQO9k Rk85AyKe0g8sfLn0oZRkhAQKQgAACmF76iAcUuERPvZJNNUZbA6ntTQCAUxketTYbd2G7EgG Dj1pW4BPUikWNlUDd3pSeKaYhju8ibiuPakB2jOMmgZPXk+1OK8DPJpNjWo3c2QyqOeuaSQD 1xnrTjn7o4prx5YK3UHvTvpcFdMSPITaxzTjt2YY9PWmkleKTZlcmpTuOWpJNJwoHI9BULSK qHcv0olBj24PB/Sq9x93lvzp63EkiGa4Xy9ucNmqZuFB2tyQapX5kZiYyRtPNZjyssxDlstR Js3SitjoJLuMHI4BFSRyJwRzmsSA5AHJHvV6zDsMAbcVK7mTh1NZG3dWqYurMBk4HpVWAFF+ c5zV2ONBECpJJq07hy33Izub60h9AOnen856cU5QrHAPHegnZkYODu9aAcZwMk0MpB68Ug9V PNLdjaGoTk71KnvScCTIGV7ZqQbm+Zvmb1ppUkZxkntVEpkUg6c4pq4bO47R61I2wgrjn1qL y/lwwO33pK9zSySHuFJAjORTC2OCCCKVRswQenanMhkDM1J6ENkciKcEHIpVKbCpUFvWlUKF +UYHvQqKASevY0Jhew1AeVxTJ1w4AbipkBYnHbrTJApOMcUtxXuxh44U5HrTgoK5HNLmPywq Aj1oXATaM0JWRSVwACNuFJuKtnuaCcECnABwSzDd2p9CnFLYTgkOeTRIUMiq2celJGoEnz8i nMVGWYc9qfQaEICgkNkdqavzkuBgUvVemc05AMbBwBQZtakI3l8EYHalLFTljg1MwqNl3kgi mN3FVcnduyMdqYepJYkdhUyBQu1RTQqmQgggetSSRodqkHnNLwADk047d3Az70OqhsBxnGab QCckknmkBbAXOFNKvTjrS4weaWhSQu0IoGd2abIONx/CnsQW+Tmk46MM1QmrDI/nOCSBTmxj GcgU+NOrHgCm7s5wnXpQNWuMXLIeQB2qPgKQOfrUhpsapvJYkVKKkl0ElBZV2kAd6a4dcenY 1KoCjZjIPc0whuUY/KOlNshaMjjaQMQy8HoakdvkAUY96cw3RhOeDnikZN3fIpIuyWpCi/MS SSTUqgFvpQFwMYp/QDAoaFzdgKkEF6iUjcwUEAGpXKLiR2J4wBUJDM4YHA9qSBak/wB6MNkB x2phdQpJH5UAbuxOOuKWJVxgD86GmCdtBUydrdfSpC2XIYDFNcIWG3Ix2oIIbdzj0qbNjlZi E7DkAkU5eejbM+lNR1fPXjsacMdCMmrSEtiT+LhuKVThic0gU4ximsCQNpAYH86aI6kysyg4 xz1GKaOGxQhZ3wOp70ElZdv60X1GrIPmwSOnej2B605xlTSoAw3cAihlRslcELI/HcUjLg8c E0+RgXDAY9RUbMzMewoRF3cVsgDgcdaEyc7T+FSIhZN+OBxTB8rbsYpjXcQKc8j8KRmfb0xn tUpJb5u5pDk8MTkdKQ1aTFKYiXJyTTESZGIPA9adjAByfpUkoYMPmDqRxTE9CIOQ2CM5qUEq OuM0yXBKkDBHWgYbtnPakGr6iOpBwG4pxUMB3I6U3BVcMOD0qRTtI6Aj0oByvoRIrbSX4IPT 1p4B4OeKklIKgnlyaRBgBTyaGC8xMKM55BqSNBt5PJ/SmN8p2tzS8gAnjPahIqcmx8y4IG8H ilA6dMmozyPWnJ065NFgdrDipBIHOKcmHUk520gxt75PelAwNgJzUrcTaeoGMKMKAAT1pQn7 wqvzHFM2yKx5JXHSlWZii7V2kGq2JWu46EMy7C2GPQU0syttAyQeaMkknofWnQg4JPJxzQtR yXKrj5eU+UsKaCAoyc+tAJdSQcBeoNIQAc8c0JdBXDBbI3cDkUR7Mkg4NPRRgNQ6qz5AwtA3 y2HAFhjH3ec0hKglsdeNtODkBgoAGKZHkDpwemaENWY7BXBwMd6UqGUOGB9vSgsMY7H2puOR zgUCtZj4wzZzjNJnDFT94dQKN+WKhTx3xQB1cnp3oC/QXcxP0pjqScgkNntTwfmBBpXGZM8A Z5ouO1kLjaCxPNJEGB3Dv29KdNGiyAKwcdiKQblbAHNMgduZ5MZ6dzQenQcU1QCx3cUR7fLY MPmJ49qTHsPR96YGOKUggA+tNRTACMYB7mnDleMk0xXZJH5cg2uTio5FCPwePWkO0xggENnk UpxjAORQIJFwQwYEHrUgdwBj7vbjmmrs+UU/OD6+lJuxdtBjAGTCk/jTwBjk9KQxnJI+91pF J25PNJ6iuxHBI3E5NOQ5UbjggUm4nqPwp7DO0eWQcUbIcXqIrAYJoZTvyc4o287eOKkj64c4 96EymkhhwG/nT1P8SjNIUUsWHT1pU7+3Sh3HKHLqJkE7sc96cNwUngA0wxqAAWIzjIp7BVPD ZA7U9SFqxgmTO3afrTwOA3OKjYKXAVSAak+UYUE4osNsedrKTkc9BQvAINBRDztNMmByCpJ9 aST6kof2C9qJCPlbgsOKRj0ZRgDrTfvHPSnYafvDw8aphgOelCFV5A4Pf0pjhTjIyalRQEB2 5b0ppDk+g12aRvv8AURsGzikKqWIAOcUoBj+6udx59qBIVeSQ2fanYbBBx7U08HGOlKxJxzx QN3WiE79T9KeMqOeM9KZlc9DmpIznqMjFNMJJiqx3bSD9fWkL/MR0zxTQzOCBwvY0/Hcdepp MUHYaqleR+FOJbOSDj1oHzHJOKRy2cRMGxSH8THAuBubp2pVZTjnrQQ5UHBYHt6Unyl/m+Xi ixUlyjijISchs0yZmUA4IJp6sRzx7Chm8xjvGPwoRmt9SucH5l9akTnsBUcSgkjBIFTYzwvH FFyr20QyQqEwwGTTRvKjOMCnl1OEZc470rZkJ2jAApJWKu2iIYOWHBoRuCBjFNAZmOBgUqAb DxT0IUmncHZFTkEknjFNB5Bxj1PrRjceQRjtQYwVPPA7UKyKs27scdiuFPXqMUksjSNg5+Wm spLBlJGKUfMfUnrSaTJdk7DWOPmyBUaYzUswwoXGP61HEQCN3JPYdqErA77IX5XBUYzUYbc+ 0HaR15qRwiybhkkdKTYpO5eSetPcr3YojYEEEdAegp2A6/M2R6U4rtBduCOKRsAqSDg0Mhu7 0EAjVwSBtpH2uScADPFLOqkhc5XtQACx805QelAJ33IiCHOSKU/3ehpZlj35QN7E03cxb5xg /wA6OhQp+UjkH3oyHbLjj2olUBcKetAZxGAADzQhNKwAjd1A+tIX78DNMmQ+YNy8mnuimTG/ tTEMcB5FzgD1qQuqjyV5A5zUZX5h0J7CmsSmRwDU76DkrEiu4JK/lTUcMC2DkUgDJgg8nvSO kkc67SCDySKpIlisxMQZeGJ5FG9tgAHQ81IwU5k6MaiwQMg4HegakloG5yw2nn+lIDnmnIUz hsgmmFGSQhWylArigHfuU8ikz1z1o2scYbBprho5CrDd6GlYBQePmPPYUBRz1prFcZJ5oEm5 9oHAHU0mhpXAKyt2HrTcsWIPHPFSoxUndg+tNLI5yuMdqVyo6Ow3aSx5yfWhupyCwFKgMQbv mkjVt/mZOMdKfTUHdEe4HOVIJ6A0KCflzjPWnyZLfNyvXI7UmUA+XPTvTVkKzsEiKjbVO4iq d2p8onjmrQUj94fwqveY8ssDk9aTYI56YEOygmqTROSVIzg5Ga2WjjcCQA7s0BAxxsHuajU2 VrGZbRMzAFSCK1raE8HdUsUAUF1wamiCLgKDzzzVCclYcqANkjIqwoUJhTwTTGBHJHFORuzH C9sVS2IV2KBsYgEEnvTVjZd0qj6470pZQeTxmlAK9CSD70NkdSOFty/N8uTyDQoGWCEHHWpJ FQYOcsabu2oQMD+tG5e+rGJKFcpjJNKCUJOeaFG7OAcmo2BBIPNDRFtSNkO0sCR3zSkN5Ydj le1SnHlhQeT2pirvDLnheoouOzY0KBGGDAk9qAyscE4ojRQSFHWk2gNRZA0M2ktkdBQzc47e lSOwX7p/CmEjgsKTdxxj1GEsvAxz1oA3KVHbvSuhL7lyAfWnZ4waaKbSEWLYMbt3vTW3IeBw acN5crjikG5iVcHjvQKK6jDlj0p4iOzcO9O29x0p6HjA70EyepEo2KVU5PfNAGUyxz6U5gAh 6ZpByMZwKBXaExyApGPehh0OSKSTy8AHk5pW+9gjAHpTBitwPUGnYUrtDYyKUkYxjjtTUK7s ZyKAu7CR4Vcg5psg3ClcJu4yAOtOYqFyAalotWsQZwMYOKSNAWz3x1qVwHZdvQ96QxgdTQTe zEGe1OHIIzz2FIF6hjjFBPQqORQ0VqxyjAAHHNKFCt3xTgvQ9iOhpBgtznjtRcjVi8E4z1pD ge2KbjHI69acMkGm9RojKE5GeM5prbSRjBqTgcn8RUbDC/KuKLFbMeV4yzDnpUIfezKOMHv3 pUy2VJzinQrGfvAnHPFFhyQ6MAZXIpdnYfpQrIWO0Zz1NSZYKduM0WI2G8AdM+9Nbb09qcGO 3BHNNxg7sUA1Yi6kbjnFKpG1vk+nNNkOG4HJ/SnDPCkn60aAnYeqsyKxG04xkU5E8oYzmjJx tzkU/AWMsec9vSlcbeoxVzk96VODyd3GKViUwDxu6Um0Y4PNMlrqhFXnHenbAeSTTVB3cdak 2ndjsOtMBFYgkHt3p2FbHQmkySSMA0zkONvagdiUjad2eRQMFtx4zSqRt+bk5601sM/pikKw 4kMSAQacOACD36UiYMnGBmnD5JDkg46UxpjNrc5pyIWJzgYoIJckHrQQQvfFAnG2pKjMo68G msoXIzuzSZL/ACjOBRG3O3sTjPpSHcTDAfKRToioVmlUn0pWIVyB0FNaUng8gdsUJjbXQa6b 5AyuUHWnrsJ+VjSOSUBCjPp60qnA5ULTuTcY5O87uh7ipFUgDHFMB3Ng9etTNuUZbGTQFiMZ HBOaXK789RSqzGQ/Lk460BP3hQKSfWkO9hSMtuH3e1Kf9nr1poJXCHoD+VKXwTjmjqPSw7Ym zeSSaSWM7FfOVP8AD3FOQbhnGD6UuGRsk896ZKfcRCFJTse57U2PbvIUkjOM1JFgghucigKU +VMYPWkV7th2zDH5ztojjDMzgkleaBxznJqRM4yF2/Si5LGI2/aVJwTzT5drMcDileMooOMZ 6YqFFZck9M9qLgo3HyEjaFwR3Ip20oflUlT3prfeCheoqXeFXZ2oB6qxBIo4LEipVAHTkUwn JBIHFSllwTkKMZAoG1ZCLjnr+NBIPAGKEBcbgMDqaUHDY/ho3FZIZtIHJzmnxqeQST6CkIy3 JG2nxttINHQaG4KrzQoLDODTnOWwvNSrIPJKsOe2KBORETsU9CTTCcnaSM1IiAtlyB6UqKmS zj6U0CT3EIRkAbjHpQw3AnnHSgEGPnrmpVGRuA4HUUrBuRKFB+nApSTnIJFPMascqOKRlDEA cDvQDEVdxyeakREUPuX6UmwFgFfbjvSE/NzzRcEribmdMPkjtmnR7QvykjA70FRgMTSsD2wQ OaYPsNRiTuxUiqDyx5PWgMu0Nxn0pSVK5zyeoqXoVGPMIFBJHQdaTkttBwR3pxYBM5yQeBSF P3gYtwR2oi77g0Ij5IBzSyHDZXik2kPn06U48nOM07akobExI5GGBzTpSxwxZs9c0vAY4wD6 UCNmBw2c9j2ouCQDg7s80p5HBGfSmyLt2bM5/jzUgEa/M2ee9MGhhwH2Bsn2pUyHKsp9qDGV bIx7H1pNkhdWZuh6UFJ6aj2wDz1ofGAduTmlkBdiQATQWyAR09qnVE7DmyTjAyegpGX5gSuM CghcE7sEdxSbS8agt8uetUFhQWKbQx55+lPiAaMrnpTZFAwquMd6FHzcEGkGo4fLhRjFNlGW AORSlfmApJwd6srHp3oTLjZbiwp5pO09OvvSMxzhQcipNpQDjGe4qN+uB68UCvd6kgLD2IpD kYJXOe9KeQQ2RTcNjjkds0yrWFwx9velUYY85pzfMoViBxTFfYCy844o3C+lyfOYwioOKY0T DlWwT2pE3HD8jNPbO7nOTS2JbuhiF0jw5GAeMU75tvGPegMqEh1DUgbJOB9DSbKikkOLdMAd MUhV0HK4+lRyhmUfMQe+KkiYggk7j2Bpp6ErTUPmx8rkD0pVXPJ6+pprsxY4A6807J/D0pib 1uKY+eTxTEjbeVX5hT2Y4xTV+To360LQncYZJFUhAAT14p4ZTHn+KmN1yKauBn0pIbjqKQ33 qVEXYWEnPpTW5TAOD6UkbDB6ACk20aX0sOHy/eHNMDjHTFOZs8k8npTXjJPHShPQlK7FOCu8 sd1IGBGeRmmglFyUyD0pFUu6gttxQmNyb0F55GKaSQ4GcY9KdtILHfnJxSOpcKU6DrVGVtSN 3MmTkZFBI+8BhsdqeyEOCGU57UFD523p70jW+gxQxGTjNHmNEwVFOWNOlO07Aef0ojKnKscZ pb7E7sJSMYYZPf61CwcoRkHnp6VIw3qSrYxxTQAoGRnNKN+o5SSeggTIycDHbFPVFMZLHbjt QehOQKjlOVG4Ek9xVbkKTkD7pCqKQBnk1LcqqMFJBKjrUKkMDtVlcfrTHyyjk570N2ZaQ9s5 zxzTWO1gMH1oQf3uaerAE5XtSeg+hE7sx659KVpADkDPbOKliQuxVQF4zz0qKMEMRtHBpmad 2IXAAORkGkUrKSWGQOtShYyzbl+lQ4G7BBXHNCY+V9R7qqsCvA9M005JypxQ2AevanSBVC4f cSOfahCGj3YFvSm4LLkcUqlQ/wB0e7VJuXOVHFF7gvMhYhdoJ5NOjdlJAGRTnwwwQPX6Ugxw Bj60XbLXKN4AKuevT2pJMs673C7e/rTmCs+5+cUjMDkbQQDmi/cNOg0hS2eCB3p33nDbQMDo OlJtAUMMAGnRYG7cM+mKUnoG5Exzu4wRTY1DJg/L9KkwCuSB1qNX/u9M0kraiY5IzuxnPsaG JXORg0nzFgwzmgl9xDdarcG2Myw4BGDxihMbiDxgUbkDlWXmmeYyuAo3ZHNFtATI0cgthvl7 A0y6z5WXA6dBUmwsxytPYEgZGcdqTWg425jNjhYoCDwecVNBAHRjnGP1q0w2yAhhgjBWnhAp I4HfFSi5FSJe5G1e9SNjPC1I7Bj90KB2pqKFGQck9c1SIW9hrFn9OKliHBBXPFNHUAAZpCXD 4yR71Q5SS2D5WQseoOAMU5Cc4PBNJ0PHNLh26Dk0mDSeo3BLEjoO5pG2bApU5qR2JHI4X0pq 5YEnAFJuwrESl1b5W4oC/OWY8nrT/ucimyDJBDYpoTsISMEYpiDLMDx9Kc2cBzjFAILAL+dD Q7aDDx2prLkipZOE29fcVGuCvPGOlJIaQrRb+gwR096TG7AwAB1pct97oKQ5LUWYXVrMV3IX nG0DgVFLwqsDkHrjtUpwVIfBpNq46VRGw1GAXjPIpdpIz+lLt460oCngtzQCuxhB6Uz5gfpT +pIzn0pJOmCOaC1FLcbwcqevrTgqqADyO9NRQMkmlGWKleR3oJsDKgOeqg06NNwZgOO2aY6o c4JBz0p+7C8HAoEMIz0zTYwinKg+9SZGQwBJPWkON2O5oK0SELBnzj9KcXj27R97NAQgMc4I 7U2OP5MkgN/OlYUXYQFVOMdaAAVJPNKoP+NDAKmAM0WCzkRsytnIJNABwPQU3nJUVLjHDHmg bTiOG3aS5PTimoyufl//AF0AMVxwfekRQDxxSSFexIVDc5/CgKoXhufSmBWGVBx70oOBg9u9 Ah2BtycU0rvxk4xSkZ4HNKcAUNjeg3Aj5x170uxQPlxz1oUBxiTkdqMY4H5U+hV+YaUVT8vT vS7xtwDSYYRnBHXmkSMZJpJhJJArEk5xg0oYgbSRgU5kAAbIqJmLPxjFBNmwI+bIGcURtwN3 Kk0N+7GSeKU4wNvIpFdLEoKZ4BzQdu0ggnNRn5cZOKkyAv3utCSJbYpGU5YcDikRTtx3pjkC VVRST3NSvywAOCBVFN6CKUAO7r2FIxAyTmmYYycjipSuVIyAaFczFUp5OSDu7YoI3Y4waarB VGRmpJGBPXqKLDuxoU7NrUEHAXGPej7xwDyDU29X4YYwMDFMLXIgVBIIJPanSBdoz1pvGcCn sAFGRnP6UFWs9Ri4+9k57U5WY8N0pCAtSxqgT5zuz0pdRyegI3ltx6UwkFiVHWn54IHSkXbz joKLhdWGjI9ab/t49qWMPI5UDGOeakGBhTjrTJbQinOPWlfnvk0kkYR2YHPoBSbzs24AJoJF RCDu71KGXIx8x96jiJ27Cc07Zt74zQxpjk3B8rjPvRlgxOee+KAF69h70i/MxCggUrDS5tAx n5Mde9OeNYSMMH45oixyCBntTZEOc5HNND0vZih3fAAC4NDk8jOaWNUYcsQ1I6gPgHIoE0rj ww2ggDOOaFOBzQdijjikaNjGCGHXpSYW0BR828HAqUM23mgqNgORkdBTlC+VvyM9MU2SNJfB Pvxk05Fz0IA6mmLhQSzEkngelOK8ZzxSQx7lnHyEDA5qPa3lBmwcmmtjG0E4qRowuArZGO9M m9hoBIwRTpQQgQgbeoNLgbvpScuDlvwpFaMVHCgKxAzTsK6lBnA53U0RhQCRkDoT2oX5QRu6 +lA+mg4coOAMdTR1GQOKAoLBetEgI4BIOaYJDo8qeOKAysQjHbjqaZsYyDLfWpWCg7VbJxyK BMRzEzKqAnb3oOS3TANIByQB0pWY7ATwBUtsByhADnhqcxBwAcU1cN/EDTAyhyPTtTuCQ8Ar znC9j60qsZDtxg0NIXRUI+UdBSd96nbxjFAJ2EYFDtzSbCcEk4p2OmMmkOQPftQ9B8w+UARF gOvQU1HBRcjb2pUGRuPJpzoN2cAUCbD5WIAHIpECZ254J5NKpIOR9KWJAJMY4PSmxxk0JgI/ GSKezHqAaGUl+uacqMIz5mA2eBSemwNXEDAke9BO2QAHlaQuuc8ClChZDkcnqaN0JaCzY3F2 TJ7Gmhm3DC4zRKTv2jkDpTsHdhsZpiYEYYqDz60+MIykP0NNQqMpt5PenrsVcOxyKTdh2bQP wiqG6dBRGzFSGXLetIoBAJOT2PtTpGjwCgKsOvPWi4+XmVgICkAnr1pMAcD7uaYGJJyc+gqR hluvQcigdkkOO08kYHpUfbABI9KUZLc0p3lwF4x1oEIQpOMc045xsAGc9acVWTLAYPQ0zBRg PSmEdSQKTgDr61GAwJ3EZFOZju4J96STGCc9O1RfUqSSY5MsnI49KRVCtnjP0pUkATJ6UoIb 7vOapvQUVcQt8wHPPenMA3ynpQSScEBQKEy/3SAF6+9JajT6CLheDyPenNgn5cAelNPzEljw fShAAmASSKNSpWaF2sV6nHTihg64blgOAaVX2jB5o8zIIxkfXiizuTewZyBupFJAIWkw2wMc cdqUcqWJxVibHpkqBQD0i2jJ70xM8EfrQdwOQcGp3CMlsyRgVbmnKctgDHpSAFh2zRtOzPp1 NMi1nqOkK+mDTSqbMjrnrTQS44704ldoVRjFBUfdISTt25xTokZiaYQ+8lulSqzBAV6g0tBu 6eozClzjORQMKuccdxUoPJyBzTI1JLKDwaWrKUkM3Zj4Gecg0jZI3KxX1pzkqMAcUj/MuMdu 1Ggm7akbNlcHOO2KQj0cilUNj5RuC9aFIckjBNGxL7kbljwKRFkzuBwuORUyl1JO0EepFNPX 2ouNu6Gq2TjpRIwztB/GlVVQlgoY/Sse/upo5sIueaTklqTG7NTf+9G7nPHFNkZQTjkDuaZp 5keDc2A3pUzjCnCjkc0X1sVZ7kavngDmnMWK4A4qI3SRkIQMnjpU8ZDIG7Z6U76ktXZGc5Cs KkYMVKAgelDNwXYA+lR5IAZh2qhWaYpdw6q33ugpHVkb5uKoXt7IWUIASOKbHeOZgGGT3zWT kky4xbLzsd3HFJuO7B5HqKQybR5hGVPNU49Uilv2t9h/AVcpISuaCEM5+YqAOKQHjaWzUM8p hXcF7c5qhHeyOzBUyv8AepOcUK1jSXI78Z60ow/3j0qlaTTzOUwVX3FXFO0HGDjgk0RlF7DT bEYbT90E0fNsDFevWkWTaCvBzQDJng4HTFWJ7huQqAp570rcYBNVLy4it32/xZ5BqW3mZwdy g5HFRzK9gsTB0IZU+93zSZAwGXj2pvABOPmz2oMgKgniqSsPle4ZJU9sUE7V5Gc96hnZkTdn 5arWt4JnaNc8e1TKSRUY3LrZwMHinTBTgQsfeo0kYJhgKbJOiOFyFJoauPQeyHPDcd6j53hc gL608lgSF+YHqaVYieMjJGQTVIi9ncSQgEDcAB/FTJs5+V8/7VUri52IS6k7euBxU9g5uI+u EPOKXMr2KXdksbKW3SKSemakcgDhQrU0LzgEkUjoxOM5xR1Cy3EUtvLDn1pSSWxjApwKsuR1 FZ15ftFMI9m4HjIobtuJ67F5xgjGCB3prsFAduTmooZGcdflqUjPyED60blaNCO4kO49cUrb MAd6ZMyxYTGTQhyCRjpzT2JaS2HZRUPBJ9abGWHG3dnv6Uo7AjAp7OVGAMD2obEkN2cj1NOb KEop571UuboRr0zzxUSXm6QB+C3TPek5ILl8oM5zximOUAznI9BRG5ORjPtVO5uBHPsAAHeh 2W5a992LnDpxn2phGIwCQaS3JdcjpUF1Msakj7xPShMT0ZKfmXAztHrSKAowBUFpceZkA5x1 qyil2PIAo3HKd1sNwAMDpRgEnA7VBcXkcU4hA59alikJjLjj1ouTuhw2kc5zTQpJwOfWqU14 nm7VIz6U43LIVGCd3oKTmkJIuAKEOeuaQEnAGKiz8oZjUBuwZzEgHPQ07q1wktS3wmSTSsCT 9wgevrQoAIOM8d6iurvaxQ84HHtT5kC0HkbWC45pwZdhVlG71qiLsbgHbk1PHIHQsDnFHMmG rH/KQQaVOBlR0qOKSNgdrDcDzzUqPgfKAQe1MdmM5PzY5pXKOvAOe9JK7LyAM+lVTcYbqB61 LaCLu7FsN8u0DFJgE5NLFsaPODk04jAoTDl1F+XaeRmmAbm5zxQuMZK49KaxYHf2FO4ONkSF csNpxTiOeo4qkLoFyMdKmDkxh+MGlzXdhIewBJ5A96jx8+C2femyOAmWqJZkLYHAoaQ3qWWw Oh4oXqOeO4pYwxGABgdKaFYFiecmqCSQ87fMO0nHvTM4YjNAHfoPWoJpcHjqKmWg9LXLcZGO c0TiJUXy2IyehqjFdHdggg1YEinl8VMbXJbvuPAwdpbNTqAIi7YB7VmXNyFbryelWrdi0YJO atsa8h4GVLDH0pO2elKSu47hge1VnuQGKfrRoh3a3LKhm6kYpG8tQOu6hW/dZxk0nzsFLJ19 KTQK7EYBsBjSjG7GBj1FLj5tj8UKFwxzj0FCIe4SkFtuMilADYGB9KqXF4sbIgTcSeanLp95 GyCKSkr2GmWCuAc4FNGB15zVE3DZKhs806O5jEgWTLUlJDk7l1SOR2ppGDuJz6VXvboRyEoN qkcVVF5IDjbnI601JErU1BnduwCKEYFskY7VStbkygj0qdXGATnIPAp8yZbjZE4+8wAA96eo IOSPpTBhl3H73WnFyyg9MCmS7rUXAznv6U9WO0Lx171m3dz5R+Ynk1ctJVdcA5aldMNyc8gr kYFN2gNksdvtSMqupX5ge9LGvHJGR0FNFNaAA+75VJX1NIB1Ge9PdysZwePSsxr1vMOY8DOK luzDlvsajBkYEt1FIEJO7OQKhgIYYJJHWptyj7gIQU1NMbp21AqTwDSeUSd2CccZpDMAOcYq QSFozhsD2o5tbGcvIZjB4Y89KldcKPm+Y9aau3aMfrTlTJ3twtNlqK5bjSHChhjHrSu+VA4z Ve7lwcjoO1V/tZMuNhx71LkkJK7uaEJLEksF4496cGwmD8xqK3BaLeeo96gmuAJgqtz3quZb ib1LgOHwSKGKmXKjgUyFkdCTnPakZtg3AFfU0XBrQdJhmOMgY6VJhzGF6gVTjvEMxTdzViSZ wvXAxwKnmT0GmyTaGnAWXK45qVVzkgjj9ayjOQrYXHOTip7S6Ei4VgfWhTi9BbvUtZO7JxzQ 4ffyRg+lQ3UxCjCj/Gq63Lq435+lNyS3KsnsaGVGAAMjg06bO1SCB6k1CreYu+Jee9TACUqr DgdaadxTjYfL90YIzimLjbkHk0+QIrZ6hapXVywYsigegobRKaRe6jG78KOo2Hhqylun3gsc Zq8s3mRAgZYdxSVgsSoxUgDOR3p7KGYOWJz2qGK5jMm3ALY5qaN1GcjinYqVnsIp2nK5pQ25 iWPzUyV/kyoyazlu3W6CSJwelJySJSNYEKwYsQKUIJX2o3AGeaZGd6YHfnNKgOGbA44NNO4L cZ5e1twNKwwN4HfmnxBWyGOBjjiq143lqcEkA0XG2iygBZcnANSldmW2hgOBzWTa3DSN347E VoqjCP7zEmkmnsSOwWfHIJ6AU4L8xVsCkkYQrtB+bHJqG2uFkk2k54707j30LCquNpJ2+1Pc cqQcgdBUS7ScdKdGWbPzAY6UJ3J5WmLt+bnIU0KCJfv/AC0xpQVJbtWZdXTgbkBJ6YpSdi0a 7fK+Vb3peXJJJL/pWfZXTSABsBu4qxcTpHEWLfN7UJqwm7FhIwcOecdqeB95utZmm3xnBA65 xWiJMccg0N9ilaw0kDmpNpZVwQd3OPSs/UbpIs7QTgc+9Safcs8AZR17UcyYpMu4EZw3405W i8s4/Csi6ubt5HCqAM8ZpltdyxlVuMBs/hU81x3sjYDqh+YcUjbPM+8MVm3twx3Pn5B3Hao4 fNdN4JIPeneIoy5Wa8Y3MSvahdgly5JJqnE80URJB+vrVWW4lmceX+NPnQ2mzY+ZWLBh7UDJ yS3PrWVb3MiS7HBz6VYv7mXy9ix49sVPMmCfRlwPhQNxB9R3qWTaqBieTWDJJNHCCwYqK1bO 6WSFXKKcDBzRzJhH3WTIV37mPFLnc+7jbVP7S/nFMLycD2FW8bVCA5AqkOUr9BFQFm9DzzT1 B2kRsBjsTUcrZj27W3Z61k+dc293skG5SeDSlNRITsbLL8o3DIPWnxYAIyAuMA0o3SwLLwF6 UmMJjHB6VSd0VfqAKbeOMUqPhDgAeppskZbb5YC4HOaz9SleOIjcVFD0K5rmiMMhdCD60oJ2 AKMNVDTI5yFI5THJFaBXaxIyRS5k9jO9xCHK89aIUywHTJyaZNKUjLZz6CmWV0LhWKofl6+1 PmNHZItvwxoQMTsUdaYgyxYuOnTNPViCGDYX1oIaTeg1mRRgFtwPNLHOmNpPHSqF3PuYqv3q pN56rvB788VPMrg7M3QQvAUketJv2n5Tj6iq9tcCSAK7YOKxtVvriK7KxtlAMCnKajuWopo3 5AS3vTYsjPOeeaef50vAOVGCetAm7gTk+lNk3K4Kn5aVyFIGeTTGbj6GhMqEGLlWAJ46U0jc x6Be3NBBIyDzRlR9/JFHkHJbVjY2K5AJAbr70oWJV+XhjSsqOCBwvamhMYUcZoaC6Y2Ut5io CNtBQkkcDH60jAZIJpzoY0UMc5pbijaMtRu4BWGFyRxWJNkamI1kjJ6kCtlsBMDOc1iymNdW UrGQ/c1FRWWpN/eNpUAGcr+FQzzeU+SM4qUgEbsEH0rM1BH5Em4Ieh9Kb2uJysR27NdTyS7G Uqe4q/LOscSngNjn3pumyRtEyoc54+pqpqoZWCnOR2qU7K7Lixgv5GkEexgnXNWvOR7ZmMjF h2pbaMTwqmAuBTmtxBA5ZQV6U4ybVyZ6mfY4a4ZmA+ppdS8qOYGJh05IqvapI8j4JIz8oouo zCNsgPNZcwR0LkayPakITgjrWdaxPFdZPUHrWzpspS1K/wAJ9azvmN+wEgZewqpvYd7SNO/K tp+8Llu5qhozQIjhyepIrQZc24iJx61QSxCKxWTHOcU5LUjQvIw3/KVyfaoL248gYwDzziqt uTFdGN3PJqPVQReja2R6etCmkthqVtiYXib1KpgH8a0Ayuw2N15rCZJnAEaHrWtp0e23O8EP VRmwk+YydTjk+1GSRQxJwDWlYY8nBzu9ag10smxUwScVc0yFmg3DGe9RF3qFRkkrDZ7qKMkK p3d6qtdbmUHoT2qtdM5uXUYOD2pGEsmAsQUAVUpsammrGtKy/ZXK4YY54rFtJlt59q8k1qx5 Gnsu358VmRW6tISBlye1Ko+azFFtaG0rxzRptX5u9VNUgJXeqgutRadcMl4YwQWXnFaQ2yF/ MznH5VcW2KWhmWczEYPHrV9NzpnqR3rKuXWC5WNMsWPNatru2deKE9bBe6KuoqVtSAqkc5qL SFkWIlmGc8Y9Kl1EF4ChOFPXHeo9IAKsHbaAPl96U0k0Ca6loswapRlVLhl5FROC3Q496CvV cjp19a03K02QzzdsbLtBz3rKP7y98vt71p4GSpBI7kVlTvF9sCISO9RPzJSNaR0iiG2MADgg d6UsEVZQMd8Go4eF+YbuOtVNSuD9xc8ngjtTcrIlpEczT3N5vU4XsKujMIBfB9ai06OMjbk7 /X1pmqlhBsHX1zUxbtzFX6Ekt2pztORnipIpi0RIAK96r2ltE1vtYNvPTFSwW5j3AvtA9e9V GTYnboUfME16YghI7GrGpRRxxqyr861VBKXLeXnd2pXMrRHzs59ay5tWGxZs5iYmIyHxxWTf vMs6ljvyea09GQornzNwB4DVFqJj80DgE8gU5JuKKi7S0LlrhbXJBGRxzWe7l7kq3Qd60bUe ZbMrOAB3NY4SWW+ZEbAHp3qm7RsKTu9TYRII0RYwCxHNBJXOcgj0rOuBNb7c5HPer1tI0keD 1PtTjLQco9TEuopf7QEpO5T2zW5akNbMh446is3UCySjgjJ64rTs8m3xvwMenWkl7xCbMaKO IXzEoT7mtdVtxGpGC5qlJZv9pMoJweopsu+GRSTwaI6bg2Wb5kWI+WuPUVWsEj2gsM89akvP ns1IIyOpqraxzyJ+6HA9KJMDYXaEIwDnpVZoAGYyxgg9DUNm8hm2MwLA81dm/eKQzYwMVVk0 FzO1COIJGYFGR61Pp4f7GwKrlqpXsJg2sZSVPIq3atm2Vw2fxqLe8PYrhTDLkDGevNW4ymBg k/jUc5URM7HmqNhKRIfm5bsaq7ixqRsMCwyBxWLqEareqykgk9O1bULsOg6isy+2faQxwCOm aJ6ocWky/FIViVSuT0pzsVYc8VCvCgluo61FcOwGBk1aJcrloypggEE1WuLyP7OwGQ2etQ2y DBIBye5qG4s2kR9z/SiS00B3aI7C486RwVGfWrcYmaUjI2Dp71X0S1bziMDA9e9arIFb5eBS iEVdlSbiPL9aghiaWQEqQB0NFyzi4wSCvfNadrj7OAp5J6UviY20mN8zapBOOKqm869SOlN1 NgsoVWIHfNOt7dZ4mcHG0dKHK2iJLEd2Xj27RgDk1QU+ZdsQcKfWrEMYTcGbauDVDcRMxDDv UzemoF26iQRmVJACvOM9ajs3eaLlaoXV26W+ZB34AqTTZjL9x896lfEO6H3Mf7/D9c5rYtCh RAchfWsK+MpkBP3vetOylLWw+Uk9xVx1YE97Ig/dR889ayZEZbsfMTzyKtzmRXBC9apzy7JP uksazm3cd7m02FiD4wMVXNyAww35moLm4AsVI3f7VZ9pMJlY54FNyY4ySNdLpXk3M2Wpt9ej YFAAYfrWVJKyy5HC/wA6r3HmzuvzMuDVp6EPXUeZZhMxlPyk8YrSjuv9EaLywT94N6Vi3e75 BuOcitmyjElqck7ulRFagRaVcxtKzTjOOKdJKpvF8sAZPSlFickKOT0xUMdvJFd4kOMcAE0N WRexriPzQTIoY0tzHELYBhtANTx7VgBXIIHNZ9xJ5023P4VVlyktLoP09gJG2qCMYFOud6Dc v4g1NbRqiAYwalkVGRt3pRFXjYbbuMsJkkj5IzVl9mMIfrWRDhJ8KeD0xWnEx25A5FOG2pLb KOsBUXKgGrWlbGjG4Y71V1UHyS3frVjSmV4MlcEUnvoFi4XVW29iaVggmDAkjFMJBOcZHpSr Kokxjb6VpFWKT0sErsFZVwAay4MtebHG4DnNasrfuydgOe9Ztp5i3hcMMelRME7Gsi7fuBfm 4NRXEghZ1UqOKkZ8gbVNZuothhvHJOKdtB876iLGZjk5wPSrpzDGAcVFZKhG3dg4qPUvkAO4 7RSjouYh7kq3fUnBIqaO4863+VSMHJqtp9us6M4BGOTU6xlUbYc+1TztMabKcjK8uGYgGrGp C18lPs+dwHzZrP2t9sYEHHappkdIstkCpUt7ju1sWLNzJEU5BxwaqXSFJ1Yrz61d0QiRS0mA i9B61BqzgzZ2tk9AO1Va8SZXuXbdCUBHFV7qc4KAj2q3bsGtVRgQeu6s67hy3AJAOatu0bIO hBFEwvQ7EKG9a3FjaRcoBgDrWA7uZVypKVvQb2iUICoxWdON2NOxG5ijgKmMeZnlqp2flx3E mYsg+lWbiNnB7e9V7SVBPtcZxRJWC5GssjXRGflB4zVy4VWiMoUZA61BIkZuiIzjPSnSLIqY bOKXNzLUE7Mdp9wdhGSAOozUou3jlwOhqvZzogc+WDkYqC6dliaZYmYA9BT57IpvmRswMJFI 4z65qOaOPcGOTjrUGkOrxq8gZQR0p13KVU+WAfStE1KN2TYgv3SS5jSLCgdR61oWSBUJC5wK q2cBkfzdvzY5q/GCq7RjnrSir6hFNmVciS2m82Nc7m5FaNrKJUPTJpt4u5CQoyP1qpY5Dg7S OelO/KxqOpqOnAwccc1i6jiO/jCngnmt0FWb5gFAHSsW8Aa8DDnmpqbD0TNePlAV6Yp6ttUk KCe2aitvlQDBx3BqVAM5J4rRaIQsWSCWUZ6kCqGqsqqWUbQPWr5IRyY24PaqWrn91tYAjrRL YljdJG9DuALeoq6NwwGJyKq6PtaPCcNircmDGxzhxUQ+EV7lLUblwQq8knFTWMe1fMYAnFZ6 uxuCsoHJ4Najsoi+UkEDnHShO7KWhXuLrb+FNtbyQSEhQVPFU4nAvNjtk56dq1WgDOdibc9h TiDZWvpsqQOAabp3lhf3m0rjvS6iqRwqpH1NRQ2rfZRIp+Umob11FcQnyrvcnQmrepWzS2az rx681UAKygN+FajxZsTiQ4x0zSi9LCepn+HIvJuOdp3HnP1rT1GdYEZSq5zWdpDL9oKtlgKt ajB5iZALHPANXF2RSMy5LbwwOR6VraSnmRkJGMgdayp4pI1xzmruiFyhBO0dz61nB++Tdtlq QRxuG6sOtZ97ItxeKQowDxitg26SxuBIF4/OsWVBb3KbcnHUetXOVgaH35ZIR8m1G4wT1q5Y 3UC2mw8DPBp8ttDe2yPICR6elV7mxjWBsHCjoKSjb3hs0Ayy27KrKMD8KwrSVYLx13EHOc9u tX9JceUUcHHQVZaxRwzEgEDP1ppJ6lOTsZk9wXv0aMDrya1GG4b3wx9TWWY/LuOCMn1rZgH7 lA4ye/pUQeort7mfcXYZGhAHHJFXNLhkRBNIg2OcDiqeqwJDumTAY9B61Nod1JLbCN8rzkg0 2veGtWRaja+XO1whLA8cGrmmyiaEYG0r270t+cExg4X0FULITx3gEQHlnOSapvlYKTNeQEoX z0rGvGc3KknvWxISMgKTjtWRfuftS4Ube9Ook1ccmraGvAwa0VGHvT9zFhGQNqjgmorEjySz YHHFSEM+GHFXFWRNPVhJ94YPSqGqKSuXAKYq6xK9aqa2zfZc4IUDmlPYbJdGOICwLYPA9qsy tsXdu5FVdEINnnJAJ6GpL+EyQkB9v0qYqyuG6KcredKUOTznIq5GUtocY2A/e9TVLTp2tZgr 8kdyKvagwnt3kYD604tMlme9zcyOxhjG0dMGpbW5lZSsisuD60zQY+CY5t4J59q1JbYJOCxH TJoV3qLm10Ma7lCXYHHNXJr1JrEQDZkegANVLhkN4y7QD61JNbOsAmVc8djWV73B7j9L2tGy dxxVe8shHKd5DA1d8Pgl2Jj5I6GqutGRZjsAznkGqnHmSNI67GwZAvBGR9KcuCcjkZqIDg8U sbFQMiteUT1Fk++eMUzNBBabfvPI6GlIySadjWEm9EKdhxsBGetN2BV+9u+tI27I29KR2GBn AxQjN3bsJnDBc5J5xTpHAjAAy2etIz4k8wJ8xGOKThcMfmoEotDWjB2sfwoYnd/eHfjpSuA2 HHGe1IwJQFRiixT2uxsikkEHBPArHvf3V9ywDDqa2mKgYHeqzW0TKTKgdj0JqKkeZGd9Sa1u AyBnXPHaku1WRfv5yOmKSNUjjCgYxS4IO4du9NRJk+qMwK1tMvBAJ9Kl15km8qVQRjqanuIh ckSPkEGpJIEKBc5HvScBqbtqUIr2CC28zk9qksLn7XGyyqY1OSAalfTVYbUClRzim2wZB8y7 SDjkUuR2sHNzK5QR1trooVIUHrTdTkF1MkcBJ5BzWncwJOOnzelQw2qQkYGDS5GlZAmPj3RQ 4ZRjHpWTviGokrwT1rZlTeu1m6e9Vl0+IHzMD5jSknoNSsWJHTy/3YLADrVZLpXQsNoxwatR R8ldwAFVLjTYZ8qSUGc8HFWrtC5rlBSH1Fd+dp7jtUt5GEvlVSGUnhjV6GzWPAQAhRyT3ptz arKBx3qXB8uo9A+0pDH5KquR/EBUlu7KmW53c1X+wbyAe3pVsofL2Aj5eKIxaE2ZusyRoiu3 XFS6fcKIQVY5I5pJrBXGHy2Tnmn2tmsR4wPaiz5hq1jPbZHqDEggt3xxWhPdQQqgDAtjOKmv YDOu3CgqOoqsumFiC5U4GSxNEo2VgROtwBbSSBQSRtGazbGRhMzj5cGtRYv3OwDjvVOTTHE5 cSBRjketTKLsrDb1K9nGVvGl/iPetCW42RsCeWpsNuI1yx+lOmsxN3xjmrhFrcmUrlK0hMk7 O5+mRWrADt25wO/vUEaLHjB/GpSOMZz6U1G2o+bQp6vP+4KIAT2FR6Yp2Fdq56kZ6U6/sRIy kOc5zwaVIXjUEDjv71Li5MaLSHaSuAQaaV+YgHj3pobOfpwKQ7guCMnvWqJZFKzL9xsDNY7p t1HeTnIrYdT1GDntVK5tmZgc7SKmcbjuaEUiCDy0GWPU1FdRGSPbgDHoKS2G0DOcVZbI6GhK 6sJ6GbZyLHMY+cjrUmp+W4VY92O5qWSzErh1ba47+tLLADFg8nvip5Og79RlrIkCb3PA6U4X KTPyCc+lQSWLcE5KGrUMSqPlUZAoV1oNNFF4jFcEsCvcZFO1CdGslijUebnr61avYpJV3sSe 3NV7azw4BO7HIHpUOm0Dk2g05DFCGf75HIqnqLIZwQMMK13QsrHAwB0rOlsmmbO7jtTs1EV9 SxbeW0JVnxgZ4qhbvs1AhSM1ehtWjJGc1HPar5pkUYYjrV2uhXuQazN5lxFETnHNXrZUFoJF bLbsY9qpiyZn3tyR0NWhGVXbjFKMdR3ZS1d/3qngg1as5SEUY6dqrTWG8/MxPpVi1t3U43Ek Cml71xD3nxMd/fsKp6i4aRWVcgdqsXFvvmEhPzYxxSQ2Tscyfh9KU3pYZXuowbIvGcnHQU/T 3jjtiu0qxFW5IowpXGPSqhtJWbCuAAc/Wk00hFPS9pvnwm3DfePeta4niEu3Gccmo4rQKMse SaS4td4AB6U1dopu7KurvE4X5flbse1JaqAgVQQKmNkxOJHDDPHtUwjaNCgIx7U7XYcxm38i r8vJHSpLW2XIkIAyP0qRLRtxz83erEaEd6ajqClYlj+XkHhaytREUt4mThs5xWnJC5B2ZIIq oLINMJHwWHFE1dE3LTxgIuzFVrpcgEKfergQIoAJP1qNgCxQg800rIt2aIYPlXbgY9cU+5iI gJyBkUvk/KUJNPEeY/L5NOWxNyhprqrbdxyDzmtUxo6bs4qkLIq29cZ9KtAYwpGKhFJla5gV l3gDNRW92YyqHHynitHIKYCjNZs1q3mA/wAWc0WZD3KeuMZ7gSxjq3NOjmZEwDjjnFXbqFWV VAGe9Vvsr7WwPlHelaw76FVp3mjZFY56VXiiZX+ck1p2doI1JGCTU88CsgYAAjqKbXNERi3K tICi9PermlQQRwAh8MD8w9amlt8yBiBz6VObRMAoMEilFO43oVNQjR51ZWOPStKxMXkgYwwq oLQ7s9frVqCIxnimtGBaEMZlG8cYrFv9q3ZVcFQa2GUeWcZPHes+4sxIwcAjHaicbgxk8Qks sqwA9DWfZiNInTHOeK2FhzEQ3p0rP+wMrsUPU5qOV3HeyICvmPg846CrdrAC4HGTyc0+C1wd xX5qslNuCw6itIh0MfVQiTHaM49BV7TCGhBwRxmo7mzMkhZTtFW7dDHEqZ7YNQovmuPRokE6 gHJ+lV9hluVlJBx60skQEoVMnNTW1uInyWzmiSb0EXJfLW1+U/ORyKyLONXv2ZjxnGK1Sm44 /KoltlSQsevtTcHoJOxYC5cgEVBcSiNW6NxVpE3YZAA1RPaEyNISMHqDVNWWgNlXT4Bw7Dgn pWhkAE9KRF2BUCjLHg9hTgNjNGxDdiaIJrcRmarIjRhd2GqxYxlIV560XFhHJJjAbPerSWxg jVT07VN/eKkrDguRxT3TKg8GkCHZkMPpSKzEYJxWgkKPnibrge1Y0dwsN4UwSc1vK37ojgAj BrOayDSlxgVlK7YFuImRsxsAMc1HcQrMpU9e1EIC4SpVLA8Y9q0S0sIoQMIJAjAkDjJ607Uo 98XBIU8j2qe7t8uCDk9SaURtLb4cqQKXK7WEVLOby4eH2jOKsRPkErUa2OwEZBB6e1WIYTCu duQamKkh3KTAws0j5OelSXD74VVW3Fx37Vckg8yMjg1Xjsn8xQOT6VKi7gFhB5MYy3NQanNl y7sABxxWg8W0EEYxVV7LzQXz8voabi7DvcnsJUmtl2ng+tSkIASwBFQ29qYgFJ49qsGMNGeS PQVcVpqGhkTSwm5ZFGCO1aEcrrGhDYIqCSyDzBuh9RV2O3DfJx04JqYpptha5GbgGBgR8xqt aQl5y6gbhUhs5EkKlwR6irsEDQRgYyT0pNSZL0M+aIRXIlb8cU+acshGc8cGrs8Ikj3Pgn2q uloocbhx6U3G2gyqEb7OCUAzSQyMtrJG3rnitSWGPCojYHeoJLNPOzuPl561Lphch0xzsCsu eOlRzviYhztTPX0q9DaBZC6OAD0BNMntA528HNDjLlsNuzGvdxgIsYIGOvrVi3lEiFs1A+ng DlsAdKsW6KIhzntVq4XsVpJTJIY+gFWbWLC89RSw26LIS5BqUY37RwM0KLcrsExZdsce/I3d hWRNIWuQMgHPStS4hLfJuGPWoRZxKwkbBb0NFRXQXLZ2yQxtk7l4NL8pGG4+lI7KiBihGTil JwgwuTmqiu43IaMcZ4zVXVlPlFVbg1YYsT1GccinvDDNCVdm/CiSuhWRmaVMBEIlHTqe5rWQ KRuIB9BVKOwjRwysRj1PUVcAIwyLx3pQTtqDKOpWzmF2hXDjml0+6EtoInjww4Y1dJ35XkKe tRR2gUkjGSe9O1mGpmTgRXQk2cZ61de++cMOvTippLXzvlOBxTY7KNG3E9OtSk0xMbdwm7tC F9KrWUwgtjC4+6eM1qKpiAwQcjgVWms1mySuMHPFEotgVoUWSXzByD7dKuak0a2qoh5xk4p1 tF5akxjjHpT5LdJItw5PpS5XYaMnS5tt0cbTxxW3EwcljjOaqQafDkuOGHPFTqgVMAnOetVB W3BrQqaoflYkGl0mWP7E0SryTnJ/H/Gp7qDzBh+uOtEFusa/L175qeV81xJNFVb1org7hwOn vUVzI1zMGRsEnnFaL2qSkBgM0sNrDAxwobPpRKLYr9CCSWSK3+UdOuKi+2Rz2o3cMTwD3rRM W8HAXB61HLYRHbkAYGc0WlawNlbTMM2W4FSXN5HCS2chetWLeFVTAIFI1nA+8uBgjpT5WkPm RQt1NxN5wPynpkVNeSzQINvIH8quQwxxRGMKNvalmijlA3YyOAKSg7XY7XMua7S5gCuFI6DH arelwOiNI4wB0NSfZrdZNqqPcY71OAdoQHAp2dxxutjOu5WkmCjIHrV2zhbHGcgcmnrChBb5 Tg1KzAYCjHrT5dbhyq4yZjGCymsW93yXKFR1PNbUih24PB7U1LaIueO1TOLkJ+RIqgxIMAKB yakKlFGefcVEo4KqT7ipdxKhARgVeqVi4WI1LvJgnavrjrVLVjKYsAllPatBjhSSQAtMZEkT dkEelNq6JluUdMnMcapwA3r2rVZQRzyMVVFvGHBAHAqwvTIqYRcdxLQztQtDJIJFJXGeKmgJ ewaJlOQc59RVuY7gvAApsS4BzxU8juObTehjwg2bDy0IUtlgKs208tzcMqgqAepFX2jXbjAI pI1VBgKPrTjFoIrqVNQtG/1sYBkx6VXjmneFUZCCDjFaqgsST0FOSKF33H8qTh2E4tkMIMMH mLlSeuKzb0yySk7Mn1xWzIApZFOfY00xgIMqOafK7Cu0hRKVUj5eTwKRsfjSSJsIO0E0ijcw Hf2rRFPyAjgGmuWCYXrTyCvymjGBz+FAKTiMTIUEjFK6BmDMOe1AZdvfOaXliAScCk/IfNZ3 BQMEnCn0qLdliAuMVKHCyMGUE44NM+ZOexoWi1Ki3e4RAeWS+c9qaSQnPfoKXzGRSjAbc0wq Sc/qKEkJvUYDhdmAcfpTiSy47ClCjd8ox6mlI9aZmrXGE5OSPwpWIB2g5XtT8gkjjNRuMgKO uetK5TAMuCGBz2oOOQOlJKGV9pIIx2oA+XP6UyXYQblHynFNQ7nY8kEd/Wn84AbrSsdoAIGO 3FSxu1tBhG1PU1DywPGafIrZ3Hn1wKGjbg5HNNBy9RqAPz1p+U+6Ccjrmo2+Vyq9u9CgE4zi jQVrj8BV3dc01vmXjBNB3Fti9BSEFSPXvQNxHKJFjJHpzSRFfKy+adEQ7FSaibcrMxwVHagL Cq4D4jJH1oYoPlzlu9ImD82eCKTawOQAFJ60wHNkoPWmgZY7jtx0PrTiMDjJ96aqlgCxByeB S0EJErZOWOTQ4yVUk++KVkff1xikV95IK4x3o0YK4v8AsDmhgckNzRgICinJ65NNGCm5j8+e vtSaTHdIHAJG3O0dKduIOD3FMZz0AwPWlG3aMHJ700hXuNYALnHemqSDTpDmTGKRgQfWmCeg +XBAwpyKawJQZPFP3kKVI6ioiAQAAeKSBMQxxqu4A5qPf8/B471NtdkIyOO1Rhduc0AyJ3zI duKUozsCSKcIkVtwUZpzDLHggn0pjsMXbt2k8jp70sRzgHj1ofYzKoHzDrxT0jHJPBHtQDBy PM+UDbTQQSSOKUD5t2M0+cHcDtAGO1JAloMIBIUE+p5pMAe1OVSWzkDHrUU3zPwRx6U7CRIQ CmCeKRQqoGHBzxTBuJ/2aUucYpMbQ3JzuHcYp0anBCkLim/dGRzSKQWxnA9abswSBVfGST70 hXnHJp3GfUVGC4kORgDvQOMUxdwB5BXFRCTc/fNPY55NNU7XycflSQnvoP5DAtyM09fllLJ3 FNyCckgA9CaTA27TknuaGOO+ojrz2Gepp0zv5Y2DJFJyW2qKcuVGQKLFSS6DVC7QW59faj5B 8xPXpQSQucZJ60zA2gBeBRbQzsPYFsHBP0oCA5xwRSK7oQqnb6ilzhiehPWiwkNzxg80iKAe nFSMQ5VAACOpprkKpWgrcgzliRkD2pyR4JJyfpT0UDt9KUbgcpgAUw2IwW2EncmD0pUCkknI NPJcjLYIpp5GO1KwWVhWPAyaFHJbODSFdxHGcUFzgAr09KLDuEmTg9TTgjbQ2MEUbjgMBzTi HnkzkA0EjWQ7N/P1pmCfmB4qQ7iTH6UjrjaM0FIYgwTuJ9qZISw2gZPrUzkcYGGFI20gZXDe 1C0FuyoFJAyOe9KrLtZG4HYVK5wQpzz6ULGAeVyRQDRCYwgyCKaN3IA4qcDuV70jYVuecjih jS0K8ZKNl13Cno7BzhTintnaQV4prGTCgDtQrBbuSKAQRzQo5Bzj2po4A9e9KQSM0DWg/wCY tnPFKOTginQtt/hzx3FEPBO75qYm7oaUKjLAc9KYR82T1qZkyc+lIkeTycUg5e5GiLuBLc09 0UufSleIgAgDHrT8BRkc5oB7lUoCckZpXQbsjoe3pUzYIwVwaRQN2DzQhMYihWyCMnigKCxL AcdqeFUE8cnvTwFwSo5xzRYE7CZBIBGKe6KoAHNIu1VOeDUkph8lSgbceuaCr3WwzkYwevf0 pYwrsQ7nbSRHKkFcinbAmew7CmSIwXHyk4HSmgA5wQPrSgE9eaVhgdBmgd0MVWAJ3cmpCz7V Vmz7mnkgAZAzimKPmIJpWQS1FJ6FhkHuKCppw8tBgnOacWG0AD86ATI8fNhuntQRtDFG6etO OMe5NSKqbMN1oSQN3IlClA2eT1FLKFJGzjFK7Ju5U89MUIvXimSKjkAllDZFRomVJXj0FSBU K5U455p6gAYAouO9hsWSNvekbfkCQ8ZxxSry+48AGnSBXk64XNAXGqPLk4OfanE/Nu24JPOK eoXBHftTJGIXpjHFKxMZ30EB+ZsocnvS/Lj5eAKN5yAfTrQMZ55HamUKrqQAOvfNIeuOTmgY DE7cHNGQXOB0oBCsAsec/NQqkKpz1pSCVLY6U2IfNtZxk80rBew9UQyFS+RjNPILAHdjFQgK shznnrUinKkj7ucUxMCCBmkzuBON1I7nBHUmnxABNu3kjtQAqBdoPHvSqyngnjFN2gDaDmkU IGAP3fSi1xpj8EpkYpiAqmGxn1p6HKHHAFBIYAkUMV7jDuILFx9KcigLkY5ok27MKopqMT8p XFIe6JPwoGQeelCHkjHApH83zFESgg/ePpTEkKSGHPQ099pAPGR3prBR70hwV4OBSauBIXLD DHIFG8sCi0yMDIU09sK3HFMY4rGCNpBbHNG1WycfSmBP3nmKMHGPrTolHPzZOenpQJMCwZQC OlPLZQHcOaYke4lTw1KoTDRkcjvSKaHxlVU7ep6fWkQshDSYLnrinqEEXykelMGeM/nQJXQ+ QF2yD8xH5U1kOBHjjuaRSRIWA5xTidykY+Y0EtsQkDAANOVRnjOD1qNCQuG7Gnh2U/KOO9MH cczrGTEBkHuKRFAcpkdKZGPn3Yxk8U+MR/aDvz060Gja5bIcdoUEHk9aMgLg/d70z7spJGB2 Bp8m1RluQfSloiUmK8mVCImV7H0pOvXmkiYqpJFOLYxxwaGrjT6Cr8o9PWoppljbI4FSb9yk FcEdMd6img3hQ45NCM3uKjM6kg4Q1Kcso6YWmKhjXbxxTkYYIYcUyxUj3gkDOPSnfNx8pOaI S4TYAAAOtNUu4OSFxQCsG5mc54ApzYwCVppf5RgAj270rSbgqkD2pLUbfYDEA+/1605ht5Jp Ap2kjJpxKIq7ufah6CTuIHBYHb8vtSseoAGfeh2y3CgD2pDgLk8ntQncJPQRffGafECD8xAP rTdx8sjyxuJpI2bO1xtNMG9LErusfGMmkhcjf0G72pn/AC03EZNSEDnpQVdJCou1c7QQfWlR cqSxA9KjjDlSSQQOlJFuLZYHjoKCb9R5/lR14o3M2TgCjBU57ikF7geDg9qmyMdD0qEPu+8M GnMGAwCcmmApWhVJGe/emhmHXrT1PyZ796ATdrC/KFGKFAjOduQab5ikbSvuDT9rAfORgjjF BXM9hJD5jbtm0+vrSqcR46nNKGOVGBx0pG+9jHNAlJLch6j5iaWIlZVwKH4fFOKYIPIqWylo JI5km5HJ702XIXA5xTnHzALjPvSMHLkOVCgUJjs7DI8g5wKduH8XGaWJCTtAJpGRtxzjApg4 tobJyBx8tIQ5ABHFO3jG3mlfcUAUgHNS2JJoiOHwSKduwSqj5TQU2rjA460xAVAK8jPNO4mM IZSWBOPSlDnP1pySn5kK8HpxTMjdtxyeh9aaYWHFFkPLEEU0r70OrLyetDFwwPGKGhN9BjBg emaEDH5zkAU9gTKpBITHNI77HG3JB6UJiaGysQ28A5xTZCWUZzk+lSDJbBzn9KQjHTrQx2uN 5CfKwFG4beT1ocBflI75zTHDlQ3BUULUNg37l2gD1zTFDH7oORUgHGemaXftHGQe9MLaaER3 NwCc+1KCcAPyBQuc5WhlZcqTljzQK7EGM56UxsfxGpOVx6nrSMqsckcdqVg3CMLtOR9KYGLB ucgelSHBGSwz6VHC23ftx83WmNqw5SxUEDA96c2N25RtJ70m4lcN932obAHGfxpJE2B8sMn/ APXUaksM4PFOY5wOeOlGeuetKw73GKAWDEH6U9jlQMDGfypuWVgytginENnLd6EmgsJuUxkE cjpUUQ+ck96cpJkIPanynYMFMk9PancelrDFIEpVgeO9PyMHk5qNchskZx1pVySd33T0pi0Q o3OM80xCctgYx609d6/d/WmTFgfkBJzzSDRbDiGJBAxxyaiYksQOCKfEp3fMxwelGQu5uo6U WKjZjGiwVdsn3oZdp3ZJz+dPD7owCePSlVPlBByO1Fu5PUicc/L17+1P/dEZVzuHUHvSgH7u cZNMlBTK8dfSmLqBY4AOfpSktt5Jx2pqB+SDz3zSsOgXNIqyDlVAxkGmFCG6HmnL8zEA8rTk dk3ZUEdj6UmCSuI67QVXmmAZPzDnvT9xIOO9MQMpJycE96SKdhGC5xgjH60gHVgMe1K5OQO1 LLuAAB5NUJu+iGg/KOMAU3czkhsD0p4k8sBWTdk01xk8Lmi5UUktRXMZwF645qPHzfMvAPep CM/NtxQw3jrjHWnclDSEICngE8Cgrhypx9aRiQRxn3oY7lOR1pWFa4cbuBzShSflBxz60+EB VLMuc9DTfmxnb360MEtRsi7ZCFP1pjpuj2881IOp96URPtBPC+tMbdiNgMZ70Kp7HrTgpzn0 oOGYFcgelBNhrAFTkHNNGAB0NS7+o24z3prKuRgGkWmkhGJPzGkV8LtHepGdjFtAwPWo1Q/X HemQlcFPYGnbSVBPT1pCGRcr39qdl/JVSeKGLZ2GMSoxyDQpyuQe3en5z15NNCHdggkUkMMq FHOM0xCpbGTj2qURjo2aiRMSMMHAPWgfQkQ7WOOT60qsucuNwoX5RnGQaTYRyelFyQbYWzjg dhSJJsO4KCSOAacQFOR0pEGRvIxTHuBU4DnAJpgz5m4U5xuyFJx703BJ4z1pXBjXUdaQouMk 5apmVioIHFRyEFQNu33poLkaDPBbgU1uACPm56VKE7UmFDcDHakylIYVHBOCfanwqWO0c+1K sYycCmj5WOMj1NOwN3JJXZ2wVAwMcUoUDkDHtSDGPn49KVevXp3pA9NBQuWOO9IpXcVJ5p67 d+7n3phjBbI4oDdCjOcZwKWQ4QBU4z1oeN16kHilVfl+Y4HamJ7DSVyNo5pmNrlsZ3VIoGen enBcylW+VQOtIEtRsagqc9B+tNJG7KrgU4E7iONueDSAZyTRcb0YhIYjPapCS7dgAKay9NuO adEQjZIzQJyFVN5IXg05icBTjI701gQ25ep9KXy8ncM4oFcbKCsm3tjqKJCeARmnMeeTn3pG HcHOaYaICV2A/pQApfAIAx3pVXIAABNIY9zAtnPQUgTEbBPHanRAbsnp3p+zC89aYeEBxzT6 DuOcp5h8o8D1ppBOWYEmhRt5H8VKZCw9McfWkCjcc7bgm0AEDmlaVWA2JjHBPrTCoKZU8nqK SPco2KOOppg4il2Y42gKKkjBWPPGRSEkn0FDh9mVBNJ+QJXFOdwY4APpSkJnryOeaZG/y7ep FOJVcsw3Me1CG9BiO5kDBc/XtTmJV84zupQ7bjxt46Uu04zkn3pkDtwK7dvSmtgHrSMSEBC5 an8FQe9ILkbZI6kURMS2MUuWZ+nTvSp8tzz3GOKEXLltoK7Ak44FCKpOW6ClCRh25JIOQDSy NvAYIFHQgU7iUbjQBvzn5aVMYJH3fT1pudo2JGWGMn2qRShAYLgYxzSBaEZC7huztPpT9oU8 H9aVUAPPANDL8xz0xSbKUbrQNpDE5yKayqZN3elVsDBBA96QriTIOBTsTe2hI0ZZlcEY6baW XhAAuCKSLJPz8Dt60rKzAlTgD9adyHHqNUBuSeaJgfLynDZ608gbPlHzd6MZUA9KBrQahJXN KAGb/WFTjpmkChGOMkHtTgq5BOMetIqIm0HjJBFORN3YD2pTjqCM9qfIjbQ7Pg/Si4WuRMnz 5zjFO69aBjcM8A05l2qT196ZL0EYnaMnHoakiBQswxux1qIDcPXFOjJ78Y9aBWAu/mA+vU0A BhuzSlm3DacD6UMg4yKC07Dduex/CnqcoQe1ABznHA5pUbe24IMelBLldiDLDG7BNPRcNyeO lMByScYGeKduPrSYWBgQTnG007av8J49KcBlMbQT3NMJA6H86LlMXapbczd+BSlQScOOKdGu 45GBjnJppYOxpkO4xlLfxZPrTnXIVN2SKcQM8EUoIYnsaTRV9AlBjwOop2cg55OOtJKzbRyC aZgDOM8+9JsaHhCUypzTfLZyGMnA7GnAnytoOKWMjyx3I4NMhIjHPbnNOQZfaSAfenKo83d1 FI8AeYZO09c5plpXHD+7kj1IpjqC21W4Hc08AopDc570w7SpVRQTfoJ/HjHT3qVIkfgtj601 MAkZwaBtYnINA7XQRh1YqWG0dMUoUMwzilIwFAHNN3EMR+tAkrEmwHIzjFMUDJIPWlYEEFic GkAwdoBFLYYsZAbay/jT2G7k9aY29jkngdaUSDgYOaGOwrow4BH1pFXA5Hen7nxxjB6Zpsy4 wAc+tMS3FTg9cjHAoGQ2c8elKAgUKvA96RsliMYA7+tIbQ5sEZH5ZpISwDA85oAwQWxjtTnO PmHBPU0D32Axgxbict2xSjdIuCce/pTI/unBp6cE5GV96GGnUUKFO3duPrS4RlIz+FNzz8vS lYZ5wM0ybW1EVAqbSKVUycbiV9PSk3/Ng092VADuHNAm2tRWABwhHFEnHfNJtPGCDn0p5UnO B3pN2Ek5blY5DHnipEbcmcnilwu7nkUGPJ+UgUzSTuNMeW8wilkbrlc5o3c7QaHAxweaT1EC scZFRZO/GOO5pxBUAnGCcU7YMZ7elGwWaZD5Y3b+mOnHWpMMACTyTSHG7jNNkjfcuGznrRa4 xz5UHPeozgRlj69KXDFwrHGKa4CucZIFCHJpRHgF4gFX5qaFJQbscU7zAzgAFOOtR87tvJA6 UWIctNBJC2cN1p6gBS3U46GmyDpnJJ/SmfPuHem9QHPGRtJOAe1OiKlGUKMg0Phjy3IGOaAo RcKQc0thtkY+9uBPWkmJVxtUEetOlUSKCnBXqRTFwWCHqe5ppCGhcjPY09FCqeOPekkJDkHb gdxTHY7Se1ALUD06U2TLfNTUcnJx1o3kArjOentSaK5tLDogd4GOvrT5lbPzEfhVdW57jFKp ZuSePrTFqldD2jKAEY+akZN+OOlGwtzk0JuDFQSDRckjd2booUj9acEAC+9OuYyQgjAL/wAV Rlmz6UXAfgnJGMClYvsAK4HbIpgO59mdtSfKvytIzYPFAxiKSCSpzQvIAIGaVy7bihxj1oRS 0YfIznpSYMSULtAIIwaduO3b1GOKSUBWwRuJoQHo2BQFuYAeM4FJIpEe8DNNkfDYA49aeJHC FRghqNAa1IZccMAR7U5DuGTj6UYIXoT2po3Yxg/hTD1HhnMmRtAxzxSEHGQ3PfimBAh5YgGk XI6UbCWgpGTmkI+U8/hTiQq9M0iAGIseDSuAxU29CTmnAkHjgU8qCoIPzCm8gj0pjsxPvsob sadMuPnY5zTX25yM/NxSumFA3HildA00IwAA2kUoYg5xjimqu0Z5IpQu/IzjjrRYE7i428qA S1M+ZWZXAz6VLtKjGSfeoXjyxY5LHuaNGVG62AHjPT2pJC0nyoMKfXtSgbs7flx60mMjBPNF gtbUaoZAQRkCnBl2HIJ4pWxjOCeKaiFskcZoauJy7DIzvJIBx705tygKoHzd6aUYMeoH86kY uyBeAvrSaC7EUtkq53emKSUDcccUiK2GYZxTVBC5OefWmlYExWPygE5FNd8qFC4ApwXcOKQQ k/LzxTGkmhRgpgk8dqU7xF8rAZoUJuKNkfSlVWBwcHFISTQxSBgc5okdimwscZpzxneTnt0o EJABYrzQGg1MtxQfkbaRzS4+U4wCO9KyllBZhn1pX1DoMf07inKreWGJyaQJwT1HrSx5UYzn NNg1oKo+XB+6ajGSwAPFScxgk9CMYpsSgLvTpQJOw/DLGxbAWmHBjyvWkbLDJOR6UAAnnj3p ILairtGMjOewpu9kJKj86cUO75DwP1odwYimzLZ61RTixoY7eTmlw20lTx3owSgXb0pFXKEE nmgTTAZIxnimxs25l6jPpShRGuAc0uQORgCgQhcgFB368U2M84FOJDtnvQqgZyBntQNIceB0 waQMUBGAcmkZi3OeKQEHpnBqbBIQF8k9qY4/iPQGpEyrMM8GlcArj86ew+UhZicNninKu45F OzkcDilQNyq4UEUE21EwxOAKEb5trLwDTt20gBucYpFj+YkZJoGxrjecHt2pxTZxnNKoUP8A N+JpQeTzmmK9wX1yM+lK5IbOBnFIY227twpqH5iDkkd6AHPuZd5OW9KWRWWNcsCD29KOq4Hb rTVGecnFAX0FBOACaOTzmkVXXLMAF7U5ShTrzQVfS40AAdCaAhb2PpUkuwL8nJ96YuTzn5qL E3DOMYINB5cEjFNiVFJXOCTmnZ9Dk5pWHJ3Y+XBYFBtA60PvALMFK44APSmtuXlQCp60pw+A q8UMcVrqOAzGNx69gKagZBjn8adnBAPG2lDBmy3TtTCdug0ZAO3j1oAYrnORTyquwwvApJQA +Ogz0oIE3EkYyaH4APrSuzKQFC0iqDksKCrBlQuDkk0yMlyyHkjp9KlhbZJyA3saeGC7iqgF vagalYjizgkdcYo+YMRxnvQRt6nNEXHXkmgnUc0qEKNuD60+Ics24jjgVGcdwKcvqDxjpQNP QjTcWJYd6lII59KUfMpGOQetKvLbePc0AtdyKVN3OSKcWZVCgcZ706UDPHzY9aCX2jeoBHpQ LSwrkPjAxRLuVRkcmkRHZsgjgUFmZgD370CQ7LFQuPxAph3qdwHPvUvEfyg5Hrmk3DdtPIoA jDMTubAPelUsTx1pf4umVPalTO5gVHt7UFXEbzY2/dvweCKepLDBGMCmsGJBzwOppU5lJB+Q jkUkS7MAxzgDK0SFs5z0oJVXIQ8U75SACOaY0yFWD/N1qYnOCCOtNZArBRjHtT2xjPANAuoZ 81t3TFJHs3ksTgU1Gw3HUU9ChYhx2zSSG30HsGABBIyOKiQS+XhmB5p/mM44ywHQego3ZxgY z2piEbgZHSmqCy4GQKcdxY8jHalJ2AUAhSvAJGcdKkdw2BjOKZkbR1pQB3454pBcX7zDnp19 qWUsxULyBTVVkZt3BPpSoxXpTAY8e1ldWP0p7HPuT1pVx/ETikwpkJXOKYbCopBPOaXHzjBp WzxgAH1oK5dWU80rBe46VhgHoaTOcMvHHNPiRXDeYQCKjctkAYwOgoAASAV4wTmnhEDht2fb 0ppLb9zAU5QCQGPDUBYdcY3/AC/dqLAL42nFSuE37UzjvmmqpMvDYA7UWHcVSWA4x2pY1UPh +APSlYZYY570kZVw2SQwpDGOrLIJOSOy08nJyOPb0oRzkgj8TS/dPHemR1AknhRmlKfKMdaa qnzCQMZ61IG3KEGBjvSsWmREkcYJpxwoAU4yOac5XAwMEcH3pihudy4PamV7r2FQnaRjk0/G V6kGmnGOvPrT8DG0fnQG2qGqOckk+1LlT0/CkjYxuQw3IeKXaq54z70NXJegSBMDAIPc0qhQ gxQF3KSc8UDHG4kD2oQXFTbggtzTWAOFBOBQvlkkRuTTmDxpkLnJ60dRtokLZYccAc8Ug2vn Axj1pqtuXOMEdTmlQrjdjv0zQK90N2rkfNz1xT8KckgA9qOGlwFApJco+wc+46UFKTSFc78Z 4xSvjf0+XFISGAVhS7fmwG4HrQkZXdxCwVTkfQ0El9vGMUhAIwRn0p25VAA696GrGrkx0yKc YbIBzimnnqQB3pDycZ4oBUEgruz0oFe48D5MrggehpEJxyKLePbEfmHXpmn8DHYUCRHGjBjk 5zyMU8tngYJHWhTz1/KkVl3kHgCmhMcyllyABihkUxqHALUBsjr8tIMAADJOaRbtoKzRrtUE gmpN+OAaYihm7cd6dInfv3xRoJtdCN+fY+lL90dc0bCCS3UUgxkbRwanYuTi1oRjG4BQcmnM jckjZk09gFkJQkke1I5d8lhu71ViL6BdR4EY8wNwDxTXJ2Zzj2p4+aNcjB9qOBGwdTuPSpYX uyMbnADNgD0oDJkleQDUZLEfdxTojtQ/KOaEXJx0DG59+SR702TAJ296fkdAajdCMhj+VNIl 2A5ICk5PoKcEZQcUiyBV28ZH51Qvr6SF9oUkGlN2QoW2L0Z/hJwPU0hwDxyKgtJWki5XlqmU 87MdPale+wnuNkjOSfWnRx4UAtSPLgHLYpFZQnGTRzBJajSdgOFJBqNRk8fWnKzMO2M9DQ43 7VTAbvVdAQTJlcK2TioApWL73PeodQu0hHy8AVSh1J5eNmPQ0m7GjjZFxpDu+U4PpSs7EZXr UBkCtuZDk0xp0Eq/Nz3FCfczsX9pKA8B+4pqKSQBkGnQZkUSDp6VXurtYSTgj2ppiu7WL6bQ rEscjpioVOQWyc9qrQXSzD5cgH1qUfu28z73bFJO4WJF3ZwDgmiVMHGeR1pDyM5xmlyDj070 7CGry/K4NPJXfk8AVVkuUDnBBxTopkkyScmi4bkzSZ3MM46UsZXg87fTvVSa4jikCk4pTfxJ GTjI9qLoZZfqCPXp6UkmfM2jketRxyh4fPBwre1QtdAPgH8aLoEn0LDDikUhefypsMqyEKOu afJEI5DufijQtIYCWJpwJ3cdqUbPLBBwM4o2kruXG0e1Mm2o0t8jBgM54pUOCowOnNQTzKDh h0p1s3mkAd+lK4Ja3ZK/JzikfaRjtT5I/m2OcEUwpjJz07UIXoNGd2OAO1KSxXpgA0sXQnaC W457VDJMkcmx35HvT2HcVMiQEnI7VJySec0yN943dRT03bumQanRibYmCRimsxVQMZxUudp5 GKZKpBGAMUyIttiIHYqckDqKVtxYluT7UgUrkl8A9AaOQO5NDNbNIQEM20VHuUMVXJI60SjY d+cE96YJEGGRgSetGwrsmjIJOcijdGvAJowCNyocHvio5SqcsRzTEo3FkbIwM4NKcrGOSKdG m5Mxrx6VFNLg+WxGR2pMG7qw4vjADY96QkMwwcio0lymMAinptUbs8DmmhEjMY1zj6YpA0rY ZvlIqu10pbfnJ7VOkqyDcxwcdKVxt9glG7J598U0DLBlZsAdKbNK0QC5HJ5oEoeRQpAOMGi6 G2yQEluCQKHGeSenQUyQhM5IPvUC3CF+vFMkl2sOoIHvTiRhRg1G8zyPheQKWaREfYxx9KCu hKwCDliF60Lt3ArnHbNQNcRkBZADT/MDcrwooViVdkkpbcS2QD0pUKKo560x5fMwrEkDpxTi g25BBoGkNkDEZQYGaaykg9eOuKfuIHXAqEXRBKqRk8HNK6Q1qh6HJx2oR3UnjikHJ4p4Dc44 piu2MYtuz+tKDkY6e9Kmf4xyKJMAEjgCgBpztOBnFEYGSSOv6VEk5QnkHNPiZmGWXbQDiPC4 LEAUK2cmQECnphjxwKSYbTg80mx3dhrJmMbSB9KVU4PXNJGBnIqQfMQM4b1piTsRkjIJ7U8A YznkjpQwVX65A61FLIIzvPTNAN3HKChyTwaRvmfgnNMWbdxkEdcVIDsO7A57UANWPBPU47+t OBw2RjHpUZnCfLnJp8RDbvpQDjYR1LEHpT229FBzUck42beOO9RrcAnqKTY1YlGSSCcUqYAw c0IyHljj+tMe4Rc5A9qYiVQwyQOO9PZhtDIh4HNV4ZUfO185pZphFgbsj0oF1JiwMY8xhgn8 qa6lHUABge9VpJ43jG/AGanUhsMCCuKSKtoOlUqSR830oViCDtHvQsnJ54HFKGVotykdaYhG 27s4HNBB28Up2CPJPzd6hN0kZA4JoCxNCWGQVyKcHXfwMe1NgmYuWHPtS8FC5YA59KATFDYy f71BOcALwKC2QBj6e9KoZCXY4GOlASaBQ+3I4xQxbadygn1qGWZN4IYjPrUqlGQEZJ7mp5tR 2GsW4+lTQkHA6mmogMbc9qZygwetOwr6Ejx/vGJODSKeBkYNKRyGRs5HQ1Ve5QvyQCOoosDs WhyKaVwOfXrSRSIwO05FSKCY9x45piv2DBZc4BAHAoBxg4waAyodxOc8UbgWJ7daB3sh0ZYM T2amtuPzLxipCS3KjoKikXcoKE5HUUCF2uUG0jB5IpxyFBIznpUEpaM8PkYpi3obCdBngEUM aLIL884A6Cjod27j09KNykArnGOtQyShZQoYYNFwuiw0bP8AMvIHNIjEDpz6UL1wpz60krLG uS3PpSbESAEANj603fukIHBNV0ud5+Y8GpGkVHBXjH60J6DRMAUBUk5pflVBtwB3qrLeKSWP Wlt545QPn+X2pKaYrFhgpI2AZPanttUjghu9U5Z/LY4P0pFuiepyT1p3QF2Nj3HToaG4YFhk etMiIaPO7mmXE22PHvTGTblHYZpDkElR81QxSq6jGMilluViceYw56ClewmTByVCD5SfvEU4 5B+7lcYFRKBMwlBwvep3K7sL9zsaYAjLFHwmSPWkJV2DS4GeRTC6yvgNlhxj1p5RcfN94UXC zHuP4iDt7UwgEZfJUelBk2jByVqpHfJKzxY25NJtIehdXDjj5h6k81KgEjYRegpixqsSBe3X FKrEDKnFCaBobJggKR0pUKbcZ2tQoGMluTQIwx3HincVrAAGX96SfTFKQoKbSw9acqMw2ZGO 1I2fudSooFoIVy+c7hTvMCttbrSR9PSpSyGIAqBg/e70xNNiZBQBgQ2eKaqqsofG7HSk3ZYA 4C9s1LhRER/HnOfap6lp6DYhmdi2MHtSPhSWxnFBGME9T6UoJzyOvrQmFhFLjY/3cnihzhi5 XJzTsjoeQO1OBXaSNv0xQ2MY2Wyp4zQ64YAnOOhojVc5z2oUFj8ynb70Jk8uo4OQKBHlcgfL TQjFmGeKVCVXHWm3cpqw5hg8/hT+QoJH0NQmMuMb+c81KUCNtznHehC22GbNxzkj1xTiF56+ 1KCRyKVFHl5Zuc0Be4gJ8kRhcmo8spweR3p5I6B+npTkXe+N3GM80XEwZt4zkAdMUmM4xmk4 PQ9DTkYK3rQPYGALYQdBTxI5HlnoDwaRwOWAPPWo1baRz19aA5eorDaMAdacnLgsf/rUo2Nk HJI6Um0AkjvQinZKwMBuwDn3qRSFi2YOajSMCRitKZN7fNxTZOou7HQEN2J6UsYDbmYHNKVU p1zikxhQS2PQetFgAApzgkUp5Ykgcj8qc8rmIIMfWmRqc438HvSHuLEBs2sATT2VVAX06VGA FY7eTUkaZjMpPzDqppCAZI6ANmkJYNjHB60iBsnJ68gU6mCTQiqgBIyRSYDc4p+cAhFwpoVX K5XANFwdxi5DEDpT8MpOR9KfCq4/eHB/nTXfYuGPGe9JsaaCPJJUClIbJyOaFyF4NO5Pue9C Jv2IlyCeetKdqjGfmpUHfBOKVduSWH0FJq+po2uhGwJI2n607IAyMg96QMBkZFNyCdtOxIrv lfl4I7+tMcs5yWwfWnsoCYHamBWPQcDrRaxSSew1GQ7huGR2zTs8Dofp1ppGBwOfWmMZEcMh 9jRuN8q3HkYJwfl7U2SJnIw+0CnPyox0J71I4xIoRs8c8UJWIk30IJApxkDPqO9ZWohTdLyc DtWs3yOS/PNYmryYvo8vsHYDvUVNUSr3NSABQpHcZqdXCkuxA46moLYDaDn86i1Pf5WQQoPG aNIxuN7lO4cXc/yMcA9qvcxw4Y1HpUKbB3I5J9aj1hmFu4Q4OetTFfaBsbLqCJtUkHsAKmhm R4y5kAKjgZ6mq9lbrLbEMOccN6UyC2McTqpLt15NNSbQ1sZ7TG4vZEfsfwpL3yoQGRiuKhWT ddOqn516iibzXhbzU2j6Vjzu1hyuW0Z5rQOxz6Gq0SbrlQQat6Yi+UEZuOxNRzgwagFXLc8M KuSbiiU2aqusETOMggcCs20Rru4zKcAk1p3LMbNgygsw61k2quild3z5JFJzsrB6D7z/AEY8 VZtLkCFWYjBqnc+YwTzwDzxmkmd2dE2qI8U4ySK5u5pC7QvuXBGaLtTcQtsJCt3FQPYFLRZU OVPYVPaGRYCgyARyDWqbYpO5Bb2QSNPNPGOWqmoVb0xJIwUnIz0q7di6lYLEQUA6VStxunw+ A2TU1HoEVctzWZluVyQQehqPVLBII8B8c9K0FygDHHyjis2/na9uRCCu7IyaG9AkmhRIY9Nw Sdp5pLGFJ0JZwqgZ69autaL9kMDntWf5UkSlY8kClJ6CvYbHMouSkbZx2q3fGcBXXkHrms62 iBvzNu2noRW2yqygNnpRB3K5mtSnaT7zjGCOxq9k9HHy46VlTMtrIGx1NacJDgHO7Iq4+YSk U7+IBS2R0qDR92CwfIBq9qa7ombHIFU9FVXhLbShz0qZaMUWaDuWbceSaj2sX3ZJHpUzgAHD DIqKJie5bJ6elaeYvQecKpyBnHrWDdoJNUALEE8EVvj5JBt+bFY7uX1Jy+Cc5HtUT2EmaogW FAoY8jNScIuGGc9DnpTY8bNxbNV76YxwMygs2OBSWxTbKl/cv5yLGWYZ5NXU3CIF2zVLTopp IhJJjLcmrF/MyKEC7cDGRRGTYJJEolj25bDHsPSnwOJGOAMVkrbkoSsjZPU1NaLKmFYsF6A+ tOM9bCbuMvrwyXht1UgKO1E1o9tCsoOQ3Xmo3ZY7pl4Ld/Wny3TSW7RkHaKjm1YIs2VzJJBn JCjsKytRmka72JkjPNXNJUohjDE55INJqESRyggEAnmm2+S6AuWE0oRPL47Gq81vJJduWwSR 1FWbJSqDaQVNLMWiQlWByelXuimklco3kP2HaTIGyMkA064nV7TCpjjrVW+JkwJG2kmrn2dF s1UuSfWstVchsbp9k1xb7gQpQZJJqPTTK1wY2ZcE8ZNNt55AjxqSFFGlxxm5M0pZhu5xRzN2 AuSRNLPtIxz17VWv4JYpFCvyCOhq/O4RQd2FxwTWe4a4mVgx2jpVSiUtSeRGNkxBwarLYuYx IGPHBNankiOJQzDkZxUd0fKjAUgBh0zT5W1cT7GbZo0UhHmnk1NJBPLOGDZUdRS2ke99xGO2 a0mVFRVU8Dq3rRyuwGPf20kShiOvSrNuN1uASc+1Qalco9wLdWZiehq5ZoVRQD8w4OaVmpBe xWkuTBIqBDye9XeGXjgmo9Qi3glQCV71BZTHdtPWqu0yr3Ljo2NhHJ71l30Bt7sfPkYzgVtD cUHHzVj6u7CVSo5zg+1TU2Qupdsywj83HFS56Mec0mnj/R2PLDFJIGCDYQB/KtI7A0PZQBmm XjRG1YFDuPenZYDap478UydWKFto20apEvyMa0hZ7jBc+wrZCMIgpzgVm6euyd8E8nIz2rTJ bHzk/hUQvubRetx6RKYXldwqp3z1NZslyZbgLE25e5pb2b5jEpJHpmpLK3AjEuB9B3qm9bEX V2ydGVcADp604yAHcCoIqpqFw0QyEwfSolgldBIGKluTTcrEuzNGOVWY5Awe9Z0xM92YgScd qlgzsYNk+9UoGb7U5JII6VE5O10DLF5aywos7BlA/Wp7aRZIVbPNQXM8k9uULEhegpdKP7tT txU8zUkhkF3K6y4QZweav2m94N/IB4qpqiBJCUbrzV20OIUGGwe3bNOMnzDvcry27yTBTwB3 BqK+gWEDYcEe9aEmQuAOe1ZV7IxIDgnnFVJPcS1LKyO1lwAWB602CE3DYY84qQL/AKOFzgGq 0EvlOUj3HHcVDbbELbgQysgyOeKTUjIZo1B4J5qS3YvcYlGPc1JewuJSyYx2o5nYEhRZK0aq xyDz1q3axeSDGeg75qgs7xqDJyw7CrJug0PAIyMmqpvTUCcOiEkBWT1oiaB3JXG3H3fesvzW ctgnAPTtUUVw4vPL2nHrTVQC7fSlflBwW702O1aSPPXHejUiHaLaOnWnRyyJGVXP4VEpcwC2 kpjfAPI4p8xkB3ngHsaz0dvtgRASSQTWvKnnxhWBDAU1N7BYdasZkGWHHSpo2VnKlskd6ybd /Jl8nDDPQ1pI2G8vYN3rVxdxMoazEDJvXIUHNTae5Me0EnNJrORDkZC07TAwX92C2B6VD0kB bUkDCgU7eGcmRRwKakmDjZz6+lLsJyzGthtCHBUsOnbFYoaNr5lx83c1tsx2nYBj0rGdokvd pXDE88VnNsEaVnGkTkqc56g1NJ8jbs5BpYY1ZGZcjA796qzykAll2j0NVF6D5exHLKzSAL0z VlGxEdwyTVa0iDPksSuOMU66YouCSBUxlrcGmiytyEPljI45xSpIGBINULSB33lJDuPrU1rH L5pRuw5Ip892F7qxXuZ/NufIAII5zT54fJjVzgmoJU23jFT8xPFOupJWjZD96oUtXcLFq0nd 4sZGKo38hM6+Xjg81b0MmHggP6g1HqyKsuYkAJOaTu43JZdsnxbHHXNVpy0kmwOFOetW7SIf ZtwcZxyKoT83GQ2MelW3pYfQmu44oogyvkgc060kEluQRuY9KgaQMhTg/hUumEGUfL8o7Cpc tLIaVwFqhLM55IqtpgUah9nDbscla0r6RN+1Rg1Fax4n8wLtJ/ipSSWwmrElxb7pfm4H8qqX 0SxEMXA9xWjcSLGNhO4nvVNIftMgX74zwKp7Ayzp5LphmVVAyD61S1eXzA6qcZ4BFW7tDFFn GOMbR2rKkOCd3ApSnZDSuXNDBVVV/nIPJpNbjCXIdcMoPSjSzl/lPy0/UygOM4oTvET3Lmm3 ETWxHIb3qdnOzaoBFYyLJFEJAwYZrWsZg8O7AO4VUJXEUDKba5XJ+8a1Yf3iGTIxVTUIIpEz gggcVBpMxVdsz45wAab0K3RqmMGNjnGBWNcLtnABAOa1wDgkNxWPqSyC9jZAGGeaip0YrM14 AwjH64qUAYySBntUUDhYguMHuakCb+euOlaoNhUwVJIGadDJtJPB9aFCv984Ip4VQfk59QaY PUYpU9OB1peD0/A01yN2SAB6U8yZHygYpMJR5RCAVzkZpFUqBvww7CljZJfu/wANDNlgDknN VfQQrjc/YEChyTjdjHbFOl5CkDB9fWmgliN2DjtUl8rsOibCkEA56Uu0jr1PrSR5LHAxTnYA jLfSk3qUouwwL84H3fU+tO4DnZg4pUZWb5lJA6U1I23sU4HvTFazHCIbd5x83WkcvgbRu47U FuB3FOjdlBRMcmgck1qRI3y5AOaejFF479eKeUVIyWOG9PWiOJpI95UhO9AnqrsYo3Nleeac xGemKCAvC8CkznkZGKXUcYuwuVDjDZPcUjD5jSHarZC5J4p2ehIzTTuTyJDduGBGKkQ7zjIB /lSsFOAG5xyaRCifuwMkmgbsJIhVvvDA60gSP74J/pT5MbMn15pqsFQrjIPSncOW+wSAg4Bw MUhIZdjoMg8H0p56dKVwhUep60rjd0h2xUwD3HUU0csVU49zQT8oHpQwB4amZQv1HSLj5uD9 KaAjZGQDjIpSzggKRjvQ6gvxg55zSua8rQ0rlR7d6QqBtJORmnq2eBkL70ojVcgrkHnNNPuE IoRgSeOBTkTORnBp+5fLESqD7+lI2AflOBSuS1YQAgnnPvSk856GmMykbQDkUI7lt2MBaYKN tSQckyE4I9aTgxli2B1pkpWQhh96pJD8iAqMHqaQL3XcMMVBUAr3oG5TxnHpinApsOGI9B60 7dxuORgUJ6DvzOwfKc5BJxxntTTEMgOc96A28kk07qDtyQO57UtxNdAxyORSjcrEggCo49zt 8vJqQ8ffOD/d/rRLYFAikALcNmlSP5MlqaBktzjbSswwoziqCyQwqCc45pUUqOetGD2IGDSv kt83JoYMjZiykDI+tKhOz5lOaR0bkA4pQGVBuO40mVGFyMMyy9Mg0rkF8KMe+Kfy0eeB7Uh3 BQcA0XIu4uwmAy7u4prk444PWnnBX0aomUZDE8ihNDalYFSRjmTbyMg4rI1bD3KiRQAp4OK2 22unL4I6c1Se3W4kOWGMd6mSutCbMSzlRotg5I5zSyo0nyEjHvUlrarbqSoyM4p2zgnJ9cU0 rqzBszwxtgRux2JFGpqj2Q25OevtVw26yf6zhe1NaIEbdw2ioUGrolNlbTJEW2MZbAC1BFK8 7OsalWHH1qSXTMS7wzYPIANTtHHGBs3bu9CbWhSbaMeG1igv2kfILH5qk1SWN42EQyuOlXbi 2WVgwyWIqKGyjRv3rsTnNRKOtkNW6i6dH/xLVMiBCemetUbvfJeRqrgBTk+9a06/JsVicdKo LZOXzk5NVK6sCZdk/eWo2sOPeqdr5az4c9+TVuyt44omDu5PYVDcWOXLRbix60nHmQmJqMpn McWFwnAI71Sv45IpYkXDDqavwWBDGSYnI6CpLyAOqsB839KXKnsJuw+3kVLRmZwoHG2mpIjR liefUVUntJgVyRsbtVuK3HkeWF4HWrU+hTtYdaOJ3ZFITAPzVjlD/aLdSVPJ9auzWkqDbHlW PSi2tXUBpcFu9Kb5tBJq5aumdbNyyjle1Z2irEjeZKu9j0PetGdWeFlycntUFjapBGBk7utJ x95FXTVi4xDkkDH1pjEOB91do596dhR949qzJ7e5aVirZjrVqyIsV4w5v22qAmOorWZ0jhDk 5/pUOn26wZbaeeeaS8Qz8j5V9KzjoW3oVNhvJWVzwOa0rdPKTan51FaRYTIHSratx12jvVxu tyHsU9SYLBuB+c1W0pmcYB6cnFGpI7HaMnPQ+1O0y1khj5GOefepkkwjsKsrNfSI6HYBVu2a FoztPfgUrAB96D60saqpLBQCa1T0DmsxYDiRiQMDpWNLk35JA5rXfJXHesq5tpmuEkjbGDyK znsNKzuX42+UDNR3cTucKcGi2DZJZT9KtOquvQgU4q6B6szrKV/Na3nbaq8hh3pNaUS24KMa dcQFZNycmnyQGW3xjaxFSl0CRDYEiLLdh+dXI23gAEZHIrORJo3KFcj1qzZQSiQu/wAvcCnF 2ZLKvkE3zytjcexqa4TZau6Fckd6kvLd5W8xR83ciq3kyyIVYHbU8uuo4uw/Q1Z497n5selJ rWd6eU2Tn5qv2yCG3WJEwwHX2rKuo7h7g44UdQaTdo2G3dmhZ7Uj+bPNSb0AwFB9zVbTg/SQ YwabdxXCEvG2VY9PSrukg3Q3VUTykIQMw5psnm/2eGLAZPIoeOeUgHjA71alheSz8tI8sDWb 1vYSIbKNFtmypYkZBqtaBvtDBQMZzinqJ4sqc+nFS2NusYZssXJzmhbWHYbqTNMUjCgAcGrS QQwQIyH68VRnE0U5k2FlNNla4kVRtYZ6CmpdWFzURd678nBrNvR+/wBm45PvWjYpIF9DjHNU rq1kN+GlX5R0OatvTQRaiCpGig8YyaLsn7OWU4z2FSCFSAdxAPQCo7lD5LbEzjuavoGhR08K 7gkDIPXFaRjIbggnPaqtij+UflAPU1bQMvzKpyR0qIvuDRBqcpiUxwSAsRzn1qrpqSD5pfvn vRJBI1zvfovQVcRQQvGPWn8TBJkrEqpZecVmau5d0woz3xV+VSARu/GsyVJWuVG3KClU2Glq aForC2yGwD2qUKu3LNio4kIj7/SpIzlTuGSOlWnoFncELIxIAIxUdxlYmyxJPNTnnr1qK4Vh GVHU80dBWMzTX8yU7/lwcA1pYbYWwcetZi29wJlfjYD0rUg3bNpyQfWs6bC9ipd2+4eYh5+l LaTOoC9MVedFdcKABWY1uY7skMxHp2pv4rjsxNcL7wWZRnmrNmVNuu77x71HdQCcfMMmoVMn KYIA6VLdncC+UjO9UI4FZKx/vmJ7mr9nFtPOeepJpl9bN5uY2705e8hbDLgQJb/KCNw5o0wK sICnOBio3id2xg8VfhHlxgCMAjrzSS97QaSKOpgsmARv7A1csWZIU3EE+/aqFzDPPKzkYOeD Vu2STAVh8xpJ2kBZldBznnNUtT2tECsfz06a3kEpGCR35qEpLJIyMpGOhqpT6BsKpf7Jnv05 7U/TdihkYAbu9WIoGa3YGqccLRuQCSue9R1Ehk+BdhScgnAxWgGUAKx6frVa2gzOXZGOPWpb mFidynA7UQerbBi30SCIS4XJHGKqWxLRPuHQU50mkh27Tkd6ks7Z1gw7AtmrTTegXKenhCzh CeT0NXxBEjAdW9aiWIxzk7MYFAilmlDudqg9KlWW5SVx2pxgOkm7afQVJbeWQG2kkCrE0Cyw eWFy56Me1UUjkiBjB5HX3pSVtSER2+4XRPHXqK0biXZ8ynJx6VDZ24B3evWi7idn2qce9OKt qXdldA0jBwM5PJ9K0lOUUMM7ehHU023iaOEAAEDqac4zynAq4RsK5V8QOptlijkDepxRo7SI hEbdsHFQ30LMMYJBPFWtOhMEe0ZB7+9S3qFrlg8HPpR5mT6U8kccYqN1LMMAc1qgbuPLfKVC jpWOn/H5iRlAzxxWy+UjwVw3cVkNb75mxkNnOaio9ASNeJUEZbfn0qtfx+bEMHJp1sm1ArVZ JXG3bkdvaiLvEG+xm6bcNA+whSTxginajkJkgZPpT7q2fbvjUEileCSeFcsEIHTNJbWC47Rh 5mdzqmBnJ4pwmyHVCBnuKpLDMg7EVNYxzCQseh7UoS1sCKdz/wAfS5zwau3SxtEHBxIw61Je WzOCygA1XaKVh5bDgdDRJWbC4mmjy3Af5lB596frMqtIWiUInarcESJAcn5+1ULi381+QeKN oCZa09le3J9R0qrKsi3eCRt71YtI5F5IA9MUs0BkYnBL4496LJoLjbnZsBCrux2qLSd7SMG+ Qg01bacPycexNaVpGioSFG/1PeiELjbM29dvtnlgAgd604hiBGYDH0qpLb/vy2OfWrkCO8G3 HSmo3lqBQvJjLP5YAU9j61Ytwtmw3H5+vWql3YtNOrjdlTxinBHOdwLHpzUuVmFjQJE7bn5B 7iq17DbrEcj581Pa7okCkEg02+jaVsBevT2q5LmiBU0sRrNgk0/XgmzYqjNSabA6SMJk+7xu HepdRtUlTcuWftURT5RFGZYms0QZDHrgVb0pQkAyTlfWqwtbjKb9uD6dq1Io9sG0fe/nTs+Y EV7ubfgcHJpba2B+Z14HtTUt5Wny64welXypHydKau2VGXLsOQoind07cVjXpDXSDIU57Vqy g7CgI4rN+xSvd+cCGHoe1FSN0Ju7uaCZaMKVHHcVNHvH3RnA602NdiYBpVODwa0SBsRVcgkj p3p8ZMikAYI71Ii5U/MBimbMHKtnPpTsJSGEHAGPrT04G08A/pTYmPmEFcqKkBXcSVyPSpbs U3diZX7qDn+dCkkcrgikeMqwI4B7Uu4EHI+gpisKG3/ITyvQVGwdX2g/NTowrA5OD2NLIu4r k9KYeQilupFOA3DJ4oGcHHNPQAoOee9Ip3Q1WwKcGBGc8UMnOAOaarEEKV4oJtbUe23IPOMU gHIYHj2pzMrArjHHSo448Jt5OKEUpXiK6tuGSxz0OKfllTaWOPel3vt28YFNYjbzyT1pibFk fKqQBSA55xxRxgLjAxTE3Z9scmk0O+hIMKCKMbmAA5pdowct2oimUoy4ORQlYTYu3bx3NNUb s5UA+vrT0ckbcgE96NnPUc0MakIApXDjIpkf7tcAFh6U9uOwyOKbtKkHPNC1BtRJC67FKnHr SAgjg9ajHHDAH0NPKFUyM/WqRF7g21cFG3HuDT87vmYYqID5N3c9aRSSwjGMUhrRki8ueeKc RycdBSYVGCbSfQikLlCUKgk0FSdxxII2t0A4ApUOE27sn0NRxrk7j1NOYEehNG5C0YqBVbI6 56Ypzk7c7aacB1xgA9alcgNjOeKCnpoMZgB93JPWnRgbSuMk81G33iuCeOPanw7l4Xr3JoBu yETYHwTgVIu3J2ndQYh97aAKJFSEqu7Ib07UEp3EYBX3HFSAoRksPeoxzyxB9BSDBY5XjFP0 Fdjyql8gEDNSMxVNmRtJ7VCxx8uPpQgCnBP50mi4psBw+c4HtUhOG37VYnjkdqQKXAIGR71I /wC7AyRRYLtOxXdWXqOKQrnBOfrU0YJi5BbB5NJuRgwXoOMUhx7MaoBpHU9Q2408hVQY49qa MdVHGelRdsppDXZeME7sc5pXGI15BOOcU6RUULkckUxQSOlUO9o3IynPoKUFscdBUjY24yA1 JzhV60MmWupHjPTk1EytvJzx0qeQY5wBTKbsCuyIAnO0c06IHGWH5U7H92gyfKBtxikNq5HI CXCqWA9KUcSFepFGGkUjOD60qhI8EA5PUmqIlHlGuW8vyyM0xI2bPHFTPzyKRM5z6UthrYRy PLB3EY4xVdyVbeO3eppgoxt79RSYXkZpWE9NSKdW2JI7D5ugFNWLegbPHrT3UNxjvQsYT5Sc A07CZGFKuQOeMZojXGWJOe1TrnqoHFITlfmXFL1E5WREpwxyuafAwyx5P0pQFbjigAIPlGOa dgTuRSbwrOAWJPC96kcFYgXHPUUwFmbcMgg0pZnbBHOKSSRT1CPLw5ZePemF2UkDoetOZGVh 3BHHtQ0ZU9eaLXY7WEdAIgxYsSeKYi4IbOalZiwCt0XpTHjAb5CTnk09CbIHXjcp5bg0wKyg kgAjrSykkAZxj0pXOEAz1HWhIS3EKEKCcYppHzZUnB4xUkaJkbmIHc05wPuqflPtQO6uIC4j KEDHamKm8bcc09y7fu8dOhphBDbTkdqLA9RFjfJAUgL1p2wHrSSZVsbuvpSOTkAAgHvTDcbc YLncoPHFMhVlJO4nPamuGLkd+9OhYkZwRilYptW0FQYYnkk07Yx5HQdRRGRyc84ojcjJYcni h6bEpaDsLgcjJ4phjAYqWximFm3gYz6cVJzzkDPvRuPm6DFUoMkjk8U/dhdmfrQANwD/AHaJ AgJKNkU7AxuwdVzu70EkMFKlh7dqflTH8uQfWm79owv3j1osJu+o3y1zn8qduO4AgE0ikk4I xTn2EgrSsITBRj0H0qJowy5HyjPIqdFG0k5OelNOT/ASoNCBWGMMkFTgjtSTLk5xk96kGCCT wRTQQfm9aTsVZBHGqqSoyfembc8EHNSrhhk8CmkFpQAQPfFC3EHyhgHFK4UZ2tz9aAjfMW7c ZpAAWz1zRYLCRMuxx5QbPc9qQ+WI8KpDDnNCq6kgkc0uBuIGR60OIXGPHuAYjIPSmvncGbGB 0NT5+Xb0A7UwohGGGRTsgik2IXHUUoG8HI3H3NNIAOUHToKFJdvmAX6UWHKNnoKVGAQenag7 iu0H5T1FIY2SQgsGHanE+WPmHX0osIZsCybkwAe1DsVzt60ucAnsakCKV5GTRZCb6EQYOgJG DTRt5xyadLuGML1NIF+YEDBFM0UexJEg2kuajWJckk09id3uaaynkHOTUrXRkNai+YcGPAA9 aYgHY59akCKUxzvB69qI1QDng+1NDT6DCn7zcWwD0o+Yvng4obMjCNgcDpT9oRQpzuHf1pgl crEEueAKltyVBwMk8DPag5bkAZpok287eRSVhNDt20kHOe9IUU85ANDSY5KnmkdXOGxgmixq oc2o8RqVyAcDrUTDyz8q7s9qmZjtBC89KCjA7mI6UEWVxiBcZxzQcEYxzQykYcH8KFyzkAhe KFYlifIrZA5FOYFiABzTBkg5XHPBpzodvzMST0INMaVxQCpOQGphUyEOnGOoqaNMp97jvTQq rkq1TpcJKyBQMHJIb+dRbwZNvTHepmJO0nGRSMgYbsDmjl1uJDY1ZMgnO7+VIyAEALyeafnc MdMdKPmzwegp7jdgO8E7sdPSmu4I2heB3pcMy7nb5qRwzAY4pIQR9STzTmVAu44yelIQDjml 2KxGegp7BoI4MigkAU5EIfDLwB1pSy7to6UgY7j82aBxv0EJ2nPJoZUYZIwaFbd0wMHvSyHj dijQLBEuVwBxRs+fOBmnJjYAM7jR04IJxQ9R2EJCA8daQFQgx37U7J25YcE01QpJxzj2oE1c XCkbWHFEe1QfmOc8U7knoKM+ynFK1xXsNKszh+3enKocFlbaFNOVwRh/l+lMGAenHrVWEAJ3 Hc2c0znJwvFSpjaQQMdqYQyncMnJqWrl6NaCuSsajbnP6UpCrgqcginp8qkbck9zTVReRnBH ShJE2FjYlSvSmNgdOAPWgEhicYpJD8u0gY607DQ4oGAIAFNjUpg9eaejHbg9aXaNm5uT2xQN xutBz7Qmcnkd6aqqY+uadImVCk7h1phT5c5waNGRYWNcEk5K9vWlWMHJUZFGGRPlbOacGAQY bnvSdgsAZMYAppOScrj0NL8m4YU4PWjA5AOT2FHKC0GhAfWpFBKAEACm4I5xSl9rAdTTSsNt dBGRXXmngHyxzjHGaQ4biPIPcGnOvGHzxzinYTGArHz0J70joByRz7U/aJSFxwT0p0qgPtGe OtKw7WQyMkqCQcdqedzZIGfpSZyFTJ6U5Qyr8rYwetOwCYYrtB/ClKvsPBGPWnBsLncDITxS hpXjILlmHagGRojY3YqVhiMAKOe/pTVBKBuhz0pd7L2BB45pWJQwyODn0pDJkgEHk53U7YAT liQelKQPLBxxRoUkxpQMwJ3Eeop33Gzg49qer4TYcZ7AUmcr5nccEetF7g0wVN+SvSmqoLDr gdqmUqxAXA45qNzhzt5IpgLL97AGM0iDylx609fnUZGDTQOSOtFwSXQcmeSgp67HDeZknHam Zx1O0d6ahHIHOO9DQWuKpYAKCSO9DBS24AgUbip4GaX2JwKQICTkYUADv60BQsgc5weooX/W 46gVIx2Nzjr0pom7uM8shywPyn9Kf8uBjORQdw5B69qDgUi73V2IB8xIzk04EHAAwaRdxcbe p4JpWX5xjPHemQ3djuA3PUe1Myck5PPWjq23PNKeFIJHWg00SE56Z4p6Kv3jkjtTCMjcoOB1 pFkOwBgQO1BJJNyNxxtPpREiJCWLkk9qjyu0AdD61IGym3AoQxMoxOQenFIVxyOTQoPTHHrU pwOlIfLcYinrQzDOKWQuCBGclutL5eMg4z3oE9XoRMRIwwT8p6U4qR7DtT3VAeDgdfrTQUMg Jz0pisIcFgrKfr61I3GAScdqRmG0Ec84pQG6kY+tTdjVhAMNx07mmr5aOTg49fWntncffqMU 10yqnOParVxxs0OZgW3AED0pCdzYPJ7GhepzwO1DAb9x70rCfuhzuzk56UHduwQfc0LuDbie D0FPUq4JzyKAtbUa4xgAVJHkDGATSNGrorAMD60OAFGDk9zSY+ZPQa6bW3Ak56g0BuR1GKlR QfemYDAn0p3YmuZWHh9wUHgCmuVJxgk5oUA57YpTtOD3PSglLl0HBELDg9KJMqMIMnNIF+XO efpS7sEDHNK7THa44ABAeh7igbXXJGMdKAPm+ZscdKJBgDDUXuwbsKCFyFyB6Gm8kkE1Iqhu h5PU1EVyxB7cUwtd3A5WMqrbR35601F4DKPwqQiM/Kcnnilj2xkggn0pI0lJWB0AGGIxUZOx dq9KmZlZARmmEZUFsEUMmnqM3g438j1oaRVzjGDQwXYNtMaKPGW6DqKExuNmIcHngH1pR8rg 9xSu4CbxggcBe9JGwmbLnA+lMLDJXDtuHA7/AFoRlzg80+OOI7hkgfzqFsK2egpWuC1Y7jO4 cD0zTHK4HHPrml37nZQO1CbSoGPrQtCmnuMA5IB60oRl4JzxSlcKSDTd+2Lcct6UyJJgB1GQ D70EdMdR196Yrs+Sy/hTwSMEcGlbUTk7WD5SNxyKYwCydSRUqvnKcZ71Cx3Fm6AHFMbjeJIR xuGKiY+tOjOTilkIDDdnFK5CTGkZGeBTJQW6np60uwGXcScdhRIrNICCMA0B5MZtJB2jtyaW NjnZycUSRSCXO4j1AqTeYo8qoJbgUxrQTgcCnAIV+bOaiZZNu44yaemcZPSpaHcUkdAcikQR kEEnP1phQ7xtOF706EqzMndehoQ7gQofrxTShHzbgBSYzKyg8ikYsY8dTTRNhxVWIYDofzol 2E4C9aQFlZVJABHSnJg7sjJ7UAM6qF4xSlMqSCOKSENu5waa27Lbjjn5cUxpDwxY8seBikJB wcc+tN+5GCckn0oiYbC5Bx0oJtqI4G4KxO31p0igxgJnjuadsLKWxxjvTckLhuQKAREwC84w x9aTcc5pZ1MnJNNDjyNvIfOaTQ7CoqglievalbDHgfrUcZeQZfrUsI4IY/NntTENGGIA4xQS Tknk0KGV3HUGmrkOTuIx2oC1xWwQBgg0pCZK7COOT600tl/50/BJLs3SgpIawGxeSPQU/aoO 9fvU3cGXI6+tKCcD60hDnA2Avw5PTtR5alOevalkZmOGIIA4pitIWwcBB09aCdQznKE429KV s+VgOAe4z1pr4VgeDSgDnpQgew2NiOdvGKVRkYyBSk5GO49KbgZ4plK9hQMjgHAqPkSAcnNP UbejcU+PceMjA5FJKwDWBbI3YGaQbVBU8n2pv+s6nGDz70SuMYKgYPykUy7cw6NlctyeKRjk bVODSBiFGMflSYZQCATQTy2F3A/KBhh196VwTjIJNIynjjOTTlDoPmP60CtYZGGYE7SuDSPw wJOM08GRSwByp7UqkOArAcUB6jHAxgHjFIN4AIGR71IyhQRkUxGwCu4DPTNIEuw1wW+ZRg/z p6Z2jPBxSgssZjBBY96jVJlwsrZxRcVr7gdxcDH40pUBzzTyj4DnBAqMsTk459KV9C4KwKm0 M2TnPFKxYj5jlsdaAfMi3fd29R60u4FAOaErEtDYMlDvbHp70Ox3BFWlOMDPXtSOW3deaYlu J5TE5L8ilZWkUAtinL1+6Tn0pPky27cqjvQMbsxhAwU+tMwcFWAz6ipGCPGGRjn3pyBdnJ5/ lQmDdyMnICkZxS4+bLE04rggZBpJMDjPNNO4+bSyCQjnb0poPA3mkj9BTgMNhhmgViOTJcY+ 7TpFXygAMN3pZSPaja3HAzQU4jUKmPGeaUKAuOfxpwAySBg9sdM0hZv4+veglMYjYJBNPcjy 8gc5oKq3JODTkGWwwO2kNu4Ig7nr601o8sACNop74wRnjsKaU4BzgigkAGB4pEUmTkAinc9c /hQCMZzzTKXmRuiyOqltvtmlZnHyKuSDg+9SMEwrYO73FDLhgQcg9xSHJdhp5bAXHtmmr8zb RgnuKlI4POfpTUUISwHJovcSWg14sZGOaSOMgkfxU7cevJpykN82aCk9NBI1MnBXaR1pHzv2 4yPWn5PzYbGe1BACZLYxxii1yX3E5XGDSspU9etNkO0A9c09toIIPGOc0CbuNbJPPelHycjF O+Rh1z9KbJsDgjOAKZKdwViucAEtRGoLBc455oRvmypxSpn7zDBoGLKgL/L2pnqCMg1Jjd7U ixgjJ7GgBRheBSFFCHDE804g7SV7daYkhDEFcDH50mrjWhIi7hywpAE+YKMv6U3JODilI+bd gZosCQgDMBxj2pNuV5ODT93XacULJmLYR8w70IHoMaJh0G44oTITBByakTLA8kDuaar4YjB2 U7Am0KCVXFIQduQM0Zzkjp70qjA5OaQCYYqQuMmgKAvUA05FJOQwII/Kkw33dgznrmmkDF2s TwM0MGZAAoV8YpWLJ8oPT0pxZmIJJBHpQNK4gWRFUSLj0prLufKgZpQ0hJ3kH0pqhgSS3Wgm 2oSrnbsO1h1qXaVJbcG4pkJzISMUD5VJjPXtRctWDknd0PtTgW5Ycn+dNiHHz5yegqULg4JA J646UEMEHlguEyTSqTjfg4pHOBjJ46H1pVZSpwSfagaQio2N+B+dLknGDtpFfsSc+lI0bnB3 YAOaASuOQHPJyaMDIyMKOSaVMHkDFOOGHIPTtSBaOwOgGCrZB6UzJAxnvQEIGQeB29KT5WPO cii1y3poiQKu3I+8aYpCbgATmnLIdvyr070jAAKx5GetFhMcYyCG3DBpzkfLzjgA0k3Zl4Hp THDyEMp+tMltkmfkyB0pGYfexilThdgHWmOrB8EYFALQeF85WLgU1VVRgcUsYKcEnBp3zMcn BUdOKVxrsIDhMYBOeSaUDc2SvApJFZQGHTPNKgPBzgUNDbih0rIhG3rQv7w7jjI9aWRVPzAY FMKnbkE47GhE8tx4FNcfQUKTnBp2Sy7AMg96GNLoxsYIbOeB6VNKhIDI4C96iCMuVH5UvQel AKCuHbeVo4AHHXpSDcW4PAFOYk9T9KYaJ2GKGBO1v1qdWzEOmR1phUldwGB7U0ZP3sZ9qWyG 0nsS/KeWxmmCIMc54HcUwfKpySSelP3nYBsI9aZKHEdNvQUj5Vge1R7iI9qEgnmpUP7sF+T3 FBXNyqw2E8llNK2S2Bn60gIUcYp8bqQQchh0pNE+oxgcZ9KIjnll6dKQbj1PNSBiqZ4xQUtx hG8h4/lXutSNksCc57Ui424IINLEc57470xNaiM5HPU02L5lywzzUki7RuwcUiEKcr+GaB6W 0BsMTnHsKcqlhkjkUwhQwZzyelPhY792SR39KBSlrqO6+9IEUDIwKGbfPyQi+1Lhd2cn8KEF 2KpdQFByD1prjcueh96MgucGlMgPylSMd6LjcWtRIicfSlXGc4wPSlAViCo6etO5LbhxSaHz XGGMMc/j1oVdzAY6UpjZQTyAaXdn7nFCJYMgEmd34ZpCWB+XFBVgPm60qcDk8euKYJDTvZ85 AA61KBkjpTHGQNmfxp8AIyTjGOBQKUSVXEedoyxGKjBznd1ppPPHBNOCgkkg0noHLYbtZkLo wBHrRGGaPLHmlwQcGmyoSQA2MUk9C5sbsaMkZ70LvMm3nFPwDyOvekjyCS3I7CnfQcZWDO1z zmmEZJJ4z2pzqATg9eeaTGTtzzQiebXUYqgjJIoygG4D8hTsbSyueR0oJA2jbgH0pNFSlfRB 2OFwtREDPNSktuwT8nYU2QAdeKETZoYsaFT0DdjSQANI2eMdc0soZSFGDnvmmMrADHJzzTHL mWg/b5mQPwqARbZcHJNPbIztbmkyepJ96BX0HOgUfKdwoyCPSneYBHzwKYVLLntTARlOAVOM 02RTGQDgnGcU+RsqM4wBTSoOGJBY0D9o0rDFYk7gApPanNwctzSTKW27MBge9SOvAwQeO1Ak 2McKh5Oc9KTBUc96PLycnk0AfNtOcYqb6g1d3GjJk69e9LjAw2SB0p7JtAPSk8wFOU6U9yVv qNVwSwxnFKqkgP27g96ReRjpQ2MAc8HtSaZbfKJJICx+QD0Apg+UEgZLU4op5NNAI4B5FNIH JNDFYknIwe9OGeAOKkfhtzEHjtQpEgzgChuxFrkbMu8DIJ9fSlYLuCgnA7+tOVFR8rSOADu/ ShO4bDclT8tODKFz1Y+tMKgIQTk5znNOBUICVJJ70wSbGt83UUwsdu1R0p6j3FKMKDgZzQmN aPUTJbJ5UelI7BlAAAPensPugDGOtDLyDxgUiXboRY2px3qEK/mMNp+tTuoLblI4FPxhS2eK Y1IqiMhgVJyeOakaN4x90knqal3BhwQuKUzPjGd3vSHyt6lYgk9TmkkAC7s8+lTKzKxxjJ9a hnRtxzQ2Ciyqzktn0NTxnjpnNQsjNIFHIqyi7eCcGgqWwq5zgLj1FDDAwppwViSAee5oVSF2 4yaBWS0DKrhc5NBYq3TIpY4+dzsMfypxwz8kAdqNyWhspDMPlwcU1wRjqeelP4BwTk+tK4wR tP1oBakYU7zgYHvSFXZiFXIHpUpyfmP501SQeMj3pg00NOdiqFx657U5ImYsQeFFEgBHzEgj v60+EMEJBI9aBPUacCM+WoJaotoVR5q5Y1LkLkjgVGx3YZicD1pbjirEZJ3e3anxtIDtzhcU 7tu9OlKhWZC75X2plyVlcRhs75xSIdwJPJNC4IKn1pVCxuRgsKCCNVbzP9kVJ905A+lKqsFw CDmo/nJ5OcVPNcBw+YFmGMVFtV/vDp0qZpVxwuCKjYMWBOPcU0wuGw7Dg4PbinrvEKiQg+h7 0q4BwQTTCWLFOw6UXuKzbH8nhckDvTAhzuxz3pUfCnb1poLmTcx5PGKY3oxxXJPbPamDoUIx ipHK8Aj8c0zJ3dc+lJFKN0NGG6A0oQge1APzc/jUwLHkgbQMCi5LVhihhlgccU0ZdSGHGadG XBbI+TsabwHyc0AgI6YH6U1o2KAjhs8j1FPLEj5V5ppDeYBmhAOC7nJ+6PSiRCo5wT60PkN1 pXJyvIb1piIUKAcqc+uKeuQQSeD608EltrAAHpSgKX2sRjtRcCIgkEYBprrJt+bOCOMVMSMt swStRhmK/P1pFaiRFmxERgjnNKyZb8etKd+eeg6UwEsdqtyOtK1w5tBfLCyEk7uOKcW2p7Gj 0waSQhzjb0qhIXALDHJIp2HC4Cg4pqZH3SMnvSAMF++cnrQSlrdi5Zk5UDNNRQuQRzT1XgBS aJAAgJJJzyaRTdwO9yvI245NBAUlevpSo7rAU2g85BpVIxk/n6UXC4wL1XJU+lId2BxmnF97 bx97PX1ppYtJtxQOKSVxV4ApQqsSyAgd6VVL4zxik27iUz+tDAaAxY8cdqSXvu5JqYN5Q2Ae 3NRJhySO1A426j4wxUMR2pCCQVIFCy9UOcjpTTv5PGKCZLsPVFU7VGMU/Z8wXuelMUOW3np0 p7LiTcGyaZOw3BVijDkd8VJIGxnrnuaYWYt0OfWhnyNiNyKBvUUBlOGIJpzEfdJ60xM5znNL 1Y7x06GjcOUR4n2K6uAvTHc01ssAR171IqEjJdfxNMRVEhUnmgfNcHUDBQk04klVGMU5cK53 DIFBUk8Hg9BSuCEbPQgfWmtheaeqlWyR0pkxYHgZzTBu48nCBdvQ00nqTwT2xTkIKc5DE96C CCQR+IouOw3CiPHelCqItzHOfSkTryRz60EbTktgdPrSuCQ+AqqkKp9qOcc4pqNiboSvrShk LvjNNCYuOQScCjIJyvSjkDPXNLhiBtX5RQIU7mkAIAzQ64BGOnU0mWVtx54qXJVTkcMKVwIl +5hcA5/Onx7DlX+UgelR7SGzkY7UOrL945zTGtR6N94ED2NOHzKU2gHsTSRhnHQZ7Uu4cAjL Um2BE2WGw/w+lSJghVX5cDn3pmCXI2cVIuMAKuGpp6AhSE4243d6EAyck8UixHccHmlbIwqq M96A6jVOM805GbzAAMg07aNpXZmkbehUKoGfWi4MSQbWwRz1xQC23IQGj5t/zMGz3qRSygqx +WlsA2Poc8Z6gU4higYquwHikGQ2T0HagYKsVyAe1CdyXJ3Glv4xjbmpEYSMMfKveoxyhHRs 8jtipFdx+7VQBjrTKBgvmYA4FSSECPczfNmoGLFQSMYp7MJgPMGKVhNjd7SMAVJA6kDrTvmz gNiM/pTgVA+Xj8aYseG3ZoKUh6hjnIyB0zSg4GT0NMhlYBlbrmmsZNuRyCelC3DcfIHGMcgd qeCDGUZflPOBSEEYyQc0bwg5HXigL66DBHn5QcU8KQu3H40KOSQacXGACufXmmTKTuIGKv6e me9EjErnaT+FCq2W3HIHT2pCzbAAcc0mWu4RruBdWGe9KPmIBHFPCqFBUAewoZTjO4UBa7Ed toCpyaTdn5cDI60n8Hy9e5pUUqcjoaBPRaASFIAO729KWbcxDdAOtIxXOcCneZtUgqDkUxDC 7NnKgemKkBOMEDIqO3ACncpLHoTUjOUyvHNFhX6AFAbPUGkCjBwO9NQktz0p7FVHHTND0Gr7 gPk7A0IyHlsjB9KRdzHknHanZypj25NJFO+4K4LMu3J7GkDusZyAOe1AUiMkLtPrQpKptZg2 T+VMT1HLIxQjqDUXKnPXPSpApBCkjJ9KTaVdunTjNCErCrzwQDTmysQVUx603IUgAYNPEnmH aRjA70NFNaaEJL4GRg56VNs2kZ6mkZ+BkDilOei9OtBPUXYAS2DkdKVo1WMyMwG6l8xmAzgU 1juGDz7UiveEjcdB0pWMnQL9CaIwoGR94mlMmRjrimOyjqD7lTOctjGMU5UxGMnk8n2oXe4D gYFKzq3y9/X1qbWRDd2OVC3QjApucYzjNMkYqAME08dMnrVdBPzFP3ulKR8+fWkVgG5GaCST jt2FA1G41fkcjJP4U7P1xSAbTg1IuD0xSZT3GTMBknJwe1CkNhjzTXKqPmpIxl8hTiiw+a49 dpYnOATRvCudvI6UhZdoXb9aYMLJ8wKpQkEmKVLFieaQAg7jwccVSvrqVJ9tv909TSQzs77W JyPWpc0mFrl5iDHhslupNIW+7jkYpQCyZLYPYUhUPHhmCY9KvcelhS2fmJGaY6hlLevrTjIN vRfyqnqNysajqcegqLii7O7LG4KuABxSRsxfPHvUFmzXCbgD0zip1K+hzTVty5yu7jWjBYkY DGmoDk78DHpTmwCWH4CkRg6gng+lMS1FkIdeg4pFchdp5pNrbmKnIpdyLGSTz7U0TOw1mzwM E+lSJ9wcdKhSMh96knIqVnIJ/Wgiw1wpfOKGCjkA/jUclxEgLgZ9qgtr1JQzds8g0r23LlG2 pa3lRkGmYz8wB575p5ZDGGUALUBvolG2JAexzQ49QU9CYDK/MSSOlMBYSALT8jyFkyMk9PSk ZQV3I2fWktiVZj3jTG/PNRHJ6dB1pcbkPOMc4qI7wC3IHcU0Fr9SRNucZOe9BGNy4zk9arrK jBgJAMVIkgIBz0obFYndFWIYYMKjJ+UYXmohcRGYrnk9h2qfaCMqcijcLNDU+Zfm602QjO3v TtwDAd6DzJkrwPagHtqIIwFxwSaam4MAoBHfNPkjBy+7btGQM1Ek0KId7gOTxnvTCMl0HkbW II3UKrHO0DGKYJYy4+bJPXFOjO13/eELikncTHc7Dng9jTCSYwCelN85JJAM0pKmTaOlMfQC m6MlmUH0FImCuDn6U+RdrZC0r5HOAN1AlZECAEtkn6GlwwhLbgOcU/zYY+ZQRxUBmhZvb0pX NLuRYWNVCsp3t3qKYs5JApqy7clB+NOWVVI5GPehhG6GshARlABHBpQgMhJ5PrQrKzE7hT3A woXnPWmS3cRz8y4GAOOKUKOo9OlIOuCcY7Yp0CkSbiQFI5pA2MOC5AHXtTtjEBCOlAKOzFHU Y681GJgx+RuR3phe+xJsBYAdfemg4Y4Oexp5kJQAgfWoi6K2Mg5oEtdiRg4GP4T0pAcZFNdV 4JbOORilIL5wD0ouDv1GuS4x0wetKjuRzSYYcYO2nlQqjJ60BowWQqhXj8qSMK4PbFRo6s5X OCP1pxBCnJosONkxW5+ooI+Q5XgU0yIFwTz2NOJTylw4JbORSE5NkSgkkZNSSgRxrtYse9OQ hcDHJ70xipJC9KYIZOHKLyVz1x3pAzA8dMYqX7w2g9BzmoZWRFyDn2pJFSs1oIVJDSHII7et S2zK0RYjk8c1DE7SKHb8qmQhjgYFMgODwDTlGTgrTfkDkK4PrSjLqeee1FrFXArg5xgGjKk5 TP400HaNpbn3peEU46UmGm4oKspVxk+1NCbRjmmbkUhgTz1pZZQMKDnNS4sOa+xIFAG78MUh BwADjHakUjZ15HWozIQ/BBzVWBu5M+4n5M7e9I+3bz26k0KSI8DIyeaRgrEoQD60xIRCFXOc Z6UkpJbJPPtT1XDAhc9uaUjL8kUAtEN8vozE8imqQG2nP4UtxKEbbuDep9KcssIiHBLdjmgL jHiOV2uQOpp2UZioOcd6Dyo2/jSxqoUcYyaA6DZFUtlPl9aVNp43ClfHPYUwRgEKDnvmiwXE dWJ25PPcU9YkjwQee5pyn5dpHOetICATvOAPWo1HZJAY9r4PJIoIAO3hfWozOCxKEYFIzxu6 kHJp2ZKZISitg03J3ErTWyxO0qrDoTTg/wA+HIyBgkd6qw72Bd3BPU0Ek8HgDtSk8kDvSIOS 2CT0oDzHhWDAL0pvAkO8fLTssoDAUyZxtBJ79KkNxY4gnHUGkaNlOcD3prSBSBv59KUM0nPS mDRIvJ6mmL8su4HaQeM96Vn45GMVGjxyLvUkFTgqaLCJA24GV3BycYpCVGevPSkRRglxxnjF OmURled+7rjtTCzGg4HTNO27jnJAPalCcE0oUqOD70FJCOzImFyR6U6MMU4U56/Sj8KVfNwx BAjA/OgLCRuxZtw9qa4CHK8E9aFkDMMEA9hT48szcBm7+1FxMarqRk8ClBPIZcg8D2oCrt4G DTyrqgHBB7+lAIaEHQH2oxhjk5I7UbgDk9O+KYJU3F/4h09qBEkmW4JwaeCoC7fvdDmo0kDe 5NKjBFZpCpHQDuKAB2EeVJJYnmgMW4H61GZUVwVw3c08Ek7sYU9KAH5XO44+lN8wl+VyMU4q SvzJ070g+V92ODQXa6GZBYpsx3zSsucBu1G4gkkj2pI5BK5GeRQTcUDDBt+AP4fWlU8nAwpN IyluR2700SjG3+VAkPZsY5OKlEiBcclT0qNWJX7owD+dKzllCgAY9KBA+78KTcxXbzgdqcUZ flPXrzToGjUMZVJHbFC1HsRE4ODk0/73BPNMM8eRv4GaVWUglMYz3pXGlceVkQqM4z0pVXEm T1J5NOUkgFmxgce9RM+ZMk/hQwJXbJK+nf1ppBKgqSPWmh+OlPyFAKnOetMQZPmFQT07UofY wLDP0pHYIQ0YySKY0iqPm60DSJxJyWHy+1MZnkcHNJEwYZ4qXO7nAFANiIFRiDgnFLvUD5h+ FDKueDz60m35sOwLCkxCnGBj15zSBwZduPoKMsW5TAC9afGMjOB060IY1yE/GhT82OtAPYke tRPdAOVZAFHRvWnch3LDnjJ/KkIzHjnd2qGKUSHHU9qDcLG7LIQT7UiuhIi8AbssOTTpHUNg E5qquooh8sqMHvU6MHAkUAijqCHgq3Jpqn5sjOB2o547mnsSRkptxTsNajsgqDznrikYbn4W ozLHHj5uvU0z7epfyiABng+tIb0Jjx2z7U48jOOT+lLGVxnBNVZ7xFd0UYPemTdNFnnb7Z5z QemQM1FDNHIvDZPcVKCcYFJlqWlgAAbJz0pwPzn09aay+vNOEuxANi8d8UWJ1HKy4OelRK0h ZhtwB0zVeS/iDMpxxUsE6yp8rg0XTHzWWpJsz0/HNPVCWznG3t61BPcLCNrDn1pi6gjv5e0Z xwaG0gbuW5HHAOcmjG75cUu52RQVGMcUm4KM0bg1Zh8oyp5PpQyEjHFB5+b9agub1YxtIAx1 NKTsgSt1LZVkXkcY61GmT8xGBVa11FZAUBBqRnVQSWP0oUroHK+hYYqqjkkHr7UHy84/Ksxt SCSqoAz3zV6CUScrt4pqSYJroSLhXA5LdyegFIzEuFAJJNLvG7bgZIp6OHbaRtx7Uybakbbg 2CM49aBhj8uaeobzWcH7valyPMzwCTnFDZqrKIFI2I3jgUrldw25IHSknJb7pA55pOrDB4qd WFk1Yc+D16ihThScZz+lI2QTxk0oKg7d2c0+oNNKwRKew4FOYYDN1IHSn5wCFbIphQA5HXvT MeZ3HrI7Q7QSFPOMVGEU4PoacCUGOhPY0ZwvA6GkiraCkZ6g0oGVLEgYpXZi4J6kcU1wVGCo Oec0xqI5yGGfSkXJTIGfemrz7e1So/y4Ax61DG3ZEecMGK7j6U8P8xITj0HamtkMflzQspj5 A61SFZsjdT0Ip6DAKrxRIwB2kEn1pyo33iQF7UMCMoB1/WmTA+WSTwB1qd1LLuA6etNvdxhG 4AD2pN6ClK2hkWYR5SCSwzzk1eSAOxIQADpiqummIzMMFfmx9a0SyRk4LY9qzjFSRbdldFO6 uhbjk8iqy3fILA80l8kct6uQ2OuDRqQWGMSLGSuOMUpzaWguQu7kKZLcVl6jOzR+XFgkmpi4 /s8FCRnnmojFGLQAbg5PLU5VPdJSa0LmkeYLYsG6Dk0l5diIfT0pNNwbSQfNgL2rKDO1w4Iy M1MJcsLjb1NKzvBMuVHB6ZqySxXkAZ7isyNJDcIsaYXuBWtsGNpPatIzuPm6FBpZRcmME7RV plbapKjB6804wwIykfMc81KxGTjIHYU436iYxGMZ+7kelNKlnLMwA7ing496ZOVEJOfmNUN6 GTcurXQjB7/nTp4RDF5wOKgf5LrhctTp3llt3SRCMdKwk+gMmtpvOtWdSQo7VTtbSSQyMrsS Tke1PhYfY8R5A9KXSSSx+ZgM+tOTeiE7F6yRkXY5J9zVpY8ZA6GgR8EqOB3pWlwpBXJHetYq yDQYQQao6pcskBVT97irzszJjNZerIjMisSuSOlKbaiJobHaN9l8wcCktZjnY5OKf553rboS Vx+dQWpY37B1woNYqTuGwM2y83KAB3Na8Uo2gKcisq7jMt86odqHpntUljmNzGzZwetXzWlY p6q5qjaee3rR8xB7+pot1Qg7jxQ+CPkJArXcmWqsQX+VgJbjI4NZVnbG9+Z2LbTlT6Vp6gXM JXqPSsuz81eV3IAeRWVS62FCKuXbazCzMWkP4mo9Wm8vbFGSPenWk7yybWUYzwTUGsERyY27 vpTjLlRUkQwJOZw5kOPStVFY+1VrB0lhUFSpHU1dXjAGce9OLbdybXAI+eW3Y70SMSuDz6e1 PdQnKE/MKZjC8de+a0ElYxL17ia52bsKOKsx2cqrtL8kZBqK/EguwUQ7SetWDeOcCTjaODWL fvFpt7Eksf2a2BZwc+9U7e3mnd3iO4KMnmrl8qz2eUPQZJNU7KYxxuI8hyME05PUV2Ns5ZfN xKMDOOta3GRtJ/GsezVpLn5vWtxI0OMv0ohJvcbSsRuCH+bmob92ihaWMfJjBq3IqqobOfXF UtSTNqcA7GHNaMTuZ9vbzTgyoSF/iGam0/Klg55zwAais7owRGKMEBqXT0M16ZWyMdvWsE2U rpGmfmXaDz6VkTefFfkM2V7D0rU1OeNXU24IYDv61kSNI1wGYksTyapyYRlY3oMi1DcYPX1F EYJyRUcBU2wJJD/oakU4yCQBWiFfXUby2Q3A9qpanceWFXOQeOD0q8GwGP5VkXhVroE0SdkL qWLSByykyZWrN+skcJKHIFV1uohsj2hTj86fqDq9sEAPPcVPMnHQpxKdslxNK0mcpjgDtVmC 2k84sc4HvVTT7gQLllZADj61pw3BZ8Kw5qI+bE1YkEbMw29aGQedtOPfFOIYHCnn1pq8Ek8k +tarUVuoy4XYpKtwKyJpZWlwpG0da1pdi20mSS3UViWJVrlv4ueRmpnKwXL9mzYIbNW3wibi RimLCQC4GF7Cq184+6DnI6U4ysrsG7kFzdBLqMW6jk4Y1qwjMYyOTWEYQsquvU9q27LcFB7g etRzNyBgRghWAJ7VIq7s5HFKWEjeYQSRTHLFhjK57VsD1Rm6iXhkKxkMPShYLhkWRc+9N1CP bdBhuB71Yhu3jhCZOzPSsXJ81hpk0ZZoSpOOOtZqyzLfiIj5PXNa8arIMjgHpWNdgrfAI/zL 2FVL3VcEbalTGQSTQVQS70JYEd6p2k5k5PUdRVwAsof7v+zVRd0CHY3t6VFNny2YHoM1IPkB J6mo3jBt5GU+1WjO+pixzSzSsEQ4HU+tW1jlbAU4x1qralopyQT15rRW5Qvk/e71ipXTL2J4 +E5JzinqVbgHBqC8mEMQ2K2GGeaz/tLBcg5PqKtOy1B6s1HYZAwSM84obCklSQO1VdPuCQe5 PWruAByAc01K4NWEDgKM9fWq2oM+wM2eBxVoom3O4Z7Yqpqm42hG87qGxFO1WeRMqnH1q1ai ZSISgJJ49qrafO8cPzZBHBNXo7gSMOMkdGFZq7BbEV+xhyWIJHXFVIJ2JDE5BOBUurEbQWIA 4yPWn6dbxtCCpAC0nNt2Q7l2Ncrl2yD09qkAGMHI9KbEMA5/CpAof5QwBxmtU9AsNO4oFB6d DWVqJeOcfOAB1xWgyyqMF+BWVq6P9oV05B4IpS2HsPjWSZCwJye9W7VJokCysSfemxuFiRBk Y61ZMgfkN0Hes469RCSAFSQRis6B5DdNuI2k8Cprm4ByqYHrVW2U+fudjt7AVblYmN27G1I2 xQpIIAzxTXORuHAzT1QeUpPelkQHGDx6VSKasRfOWIyMEUo+XCswz9akACw5bg+tZl3OVulR TkUSlYDSRgzBVOM1BqDSovlJ2PJB4qvvlikVmUhTV5GDQnK5JHelzDWhlGO6LAxgEDqT6Vas XYS7CSAe9K05jBUH2NVrE77hizE46YrOd7hfU1csXCnHpxTjxuA7U1AdinnOe9ByH789a2EV L19kZIJViaqqk8yEx/dA5Iq5qyqYs43AelU7K5aK3ZV4RhjFZTbvYFqS6dcuGMZUEjoabcvJ Jcfe2tnGKj09GadircHpTrzzY7pXEZOT1qeawK4XPn2+3chYHqc1o2hLRDms3ULh7gKWbaeA MVc0zeEAzk9KcW+awF5t/lnLcZpCzFAuRkUu8thDzikZduQFBY961XmF7FK8laM4PWqkDTpN uPEfrnk07VCTNggr6+9WLWIT2yM3QHgZqG9SS1KzLAsuMA9qov5k837lQqn0NWtQJFnsOenF Z1hKyOCu5dnf1qZNlGrGNsYB696efv8ACgVBBerM5AUH1zVhASx3rx2NaRd0Jjj8xy+ScfjU N0DFHwMA81YAUkl2/Gqt6x8sk5IA4FEtFoK90UoYZbgSYboM0yzkdZDC7ZI4IpNOuzEJGKcN wD6UlqyyX2716n1rJydi4s2ZeIkINY99cMkyBSTk1oXVyFTYOSOlZEzn7Um4HJ9qqb0C7N2I CS3RgvJ6mp1RVHA61DbKywrxxU7SfMELZ9KtXshXEkCsFTIUjv61l6xujYPHkLnvWqBlsPtF ZusqCNu4EfypTdkTd8xPpEmY2LshOOM1bxldxOK5+I+QF3bsZ4rWmuc2ykYwBSjLoy7ak6Oi q6seR0NJHiV8qBuHvWRGZJ2JDso9qnsDcQ3Sgkuo5JNNSu7FJJ7GqenJOR2o2ll6jAPSiSVT IXVcZp8eN2SPxqyHoV7xDsAB6iqC2k7JmRicc9a0pj83OfrVWa428bjluKiS6iZVsndZWG44 zipLuxmkdWjfaCeafp9szZc5OT3rQKsq7scDtUxTYzJ1SzlghHOXxwRVzSfMa3UtnA6iq+oz MyhVY7vSrtgjrAOoHcUoKXNqGnUmDb3YBSu3pmnAkRkyZanBy3DDp0NNkLMCq/MegrW5Wy0M u4kYyEFV5OKbcafILZbhJQSpziobpit0ATk55FWftpEckXlnaRjJFYybIvcIbqZbXcuCB1pb S3N+WUk7mHGKpoWWFgobB7VZsZ5bbaYzgkdPSkqnQLCW8f2SUw9GBwc962UG0gjB45rAuHlm nV3GCDnNb1qXMIkZQR7VUG76luwsnQbRn1qnfMyKcHFXTkn5e/as7W5fKgCumcnGK1lsL0Ir O0S4Jd+M9xUMe60uGiA3KOQaS3kaKFUVW2np7UkzFmzXOn7qZnu7MnaRriQRgAsfWn6pYzW1 usqFd2eeapwhvP3Ipz61ZuJpHgzI2CO3rTcro0fulzTp2ZFLHJxVuYFiCMAiqWkDzLYlABir 4BwSBmtYlJq1xJdwh3EfKvesWORLm+MchygNbUrS/Z2UH5T1FYEMbLOxVec0puyM2W9Ut4re VGiwoI7VA07tgE8etLcyNLDtlT5lqunKKpHTpWUnbYHbY0ordJYPMIXPaodNeUXDIwPXpmmq Z0VSylVI4NJZeYb1iCTt6mjm1Q47m06osgK8EjvUhOOfSk2iTEjdOopRuc4xXQOSswBxntnr Q+7y1JChs9fanSLtAzz6U4g4GMEU3Yd7IZsJB6UqKR1A9qSWQjlVJYU5ZOFyAGxzSuUou1xU /wBZk4FNkIMh4HtTg2OgyaXKx4BQs7fpQJNjUIUeWcc08HYeRnFI6gkZUEjnND53jJ4pMdri kFpGJAPGaF6dQM0mMZwaQhNmCDmmkR8LHpy5C/MB3FIQSexx1pEXany/KD1xTwMqAvUdfenY pTuAAHTpSnDHhccU5ULLyAPek2rG2M5z6UhtAAw+YEY6YNLGgdjlRimI+XYFTgU+LJLZJFMy k3HYbiIKPlbPc0hyBwc06cFJMHGMdqaGTO1W/OptcvfQZxu+8c+lExMi7MmlJG/bt5oCMzgY APeqsZOKi9TLdTDKT69OKIp5HvACOAK0ZYhvZTg02OBEycDcR1rFqS2NFqZ1zH5VyHcM2f0q G/uY5HSNdx3VrzhZAi7fYmoUtoopwWjDYpSjJqwkUbyESWgjGU46imSSs1qkTAfIMZA61rlF lkdflA21WS2RMhgGB/Shwdg1KmnOot3iZyBjtUFhmGZ5JVBB6AitOCGGNWLKMk8AVG9sJCQC AO+acoe6K5UN9EtztRf3jd8cYq+sv7tQUBPfiq0FlFHKGYZUHrV10QElPuVUFZGml9DLmkuW vhs2rF34rQUjcTnj3pojXzSNo56GnrGD+FVG5XNFvUSR1zg8E0xlyvqKcitvYHGKenOQMHPW myapiyOsN8rSISh4q1e3I8hlCrjse9TX1urLtQDI5BNVYNNmB8x5A4bovpWMkRoNtFH2J3YD kdxTdI8tUY5BJNXWhkki+zkDaue1V7HTykvGQo5qWmrAlrqXomHc4HemOSQSuAT609oweEZV HvUR2hgrcnsa6U9AaSZJCNxKlCaztVUqyEpwD1xWmGKENUNzAZlO5gR2FKS5lYVitbxweSsp OHHeqdkm/UXLEkdz6U6S3mIKjgdBVu0iMPJ4zwTWDjroMpTFf7QEYYHJ61DelU1BQXI5xxVi e1cTswXr3otLV5Z1LgADpk1MtWCepqbVEahJAcjn2obG7AHA7+tCxDJI4IGOtGQm3dzzya6V sTPV2QrFMfNggdOKjgaL5laMMp/SiVN+7Ydq44FZvl3EKH5mbJ7VMmluFtCu+U1Vo1b5DjGD VnWFRYPM6bRyTUVtZyG4+0upXPQE1Lq9s9zFsbIGOlZvuW3ZljTAhgBCgk96thVBO78qpaYG ECw7CpTue9WwvPOeetVT2KurCL9/OTj0p7qOoGB6U1lKnIGQaWVWAB659O1aehD1GOq4IcDL dKoapCqRgdyOKTUluFKyoWPNQ3CzXUYRgQfWspWuRdpjizf2bsx171No1vE6lHjdyEP3evSn pC5svJCjj+L3qnaGeAFUd1boT61LXvXZS1GxDZfHOQDnAzWu6jAaP7h6isyG2Ml2JGzmtfDL GI2A2g9RV09yhUVSD2FVdTmIsWiQAgnOfSpwGMg2niorwb0KKABWjV0KWm5Q0qOGSDMwwR93 ioLXcmpvGWIHHGOlPine3Y4jYkcDinW0Ms10ZWB3nv3rDlVxpuxHdhvtnl4PqSabdFY7uMor FSeRjpU93FPHeiQnKr1FRzxuZvMT/V+/WhaaMcLM1AyMgYLg+lTJ5ZhYOOeoFVbZT5anHWrh UBTnG6tou6Ib1Idny56D0NZEsZN/935fWtlwCuM1k6ipt5t6liDgYFTUWgx2rRRW8PnKodlG QKsWJSa1+fg4zmqszGYqo+ZTwQatKnlW+xFwOtZRelh3JEtraRCCu4isuGfbfNDtIx3p63Tx ZJJWktImkujMT8rdKuVtAW+propI+Y44zQdrJ15B5pzxsI1beCPagxkKr5H0FapBLcjuBGbY j05NYdn5L3zGPjBwa255F8lgIwSeprEs0kN2xCjyyeGFZ1FqghZPU2yuGI6+lVpbXzGyo6VZ jO1cY604Kd3GBxVON1YmRz9/HLFcxgEAE4xWxYxOsG9hx3NUdU+eUE/eU8YrQsWZrcCQnHpW ajaQybIWM7QDmmlmHLdaF+9sxx2qVQCNoI4PNbspaKzK8kSyHnGT61WurdY7dnP3R3p+oKRK zKTtHaobi5WWw8gjaCcYPespRT1Jdr6D9MkYxFH5B6VUkixejdjOetXNGtDBGcksxB257VTu EYXQkZjjNQrtaiWgl4DFqCiBsA8t71r27h/vnAxWZlXmBK7q1I1DAMSAT2qqRV2xAxyScMO1 Knygg42ntTlVRmmuPlzkZPatiOUgkhjkcKqgfSqOqJHazIBxnGfrU0tybe4Ckj1GagmX7Y+7 qN2Tn1rOWq0An1EmSBG3cFeKr21rI8O8AbV4q5c2xWJUDBsDNQQyGGFl3kgngVm7vcsfZWjL IWAIUcmrs7kKCE4+lQac7O7AMRgd+lWizbducnvWkfIGrbjFKnDKuPrSXMYO1mAIJ6U4Id2A cCo7g/uzySasaj3CS2tjExIJY9FFZtqoW7EUZwOuD0qaOWROpOT0qGBQ8+9lO6s5WWxLWo7W Yg8OSB17VNpCbrfdjGOMVDq8gEQEcZI74qfSnIiO5SoI4FR9tlJXLYyDkilwGYiMY96Qkn5R 970NKmEB54Nb30E00MVTg7myRTJY4XxnhqmIynHQVTvZMRbtp3A9qOgmmNu4QEbkgDvUVkrN C2W+lPa6aS0MW3hupxzS6ZGwiKKByO9Y6X0BNxRUtYlklcSkgA8H1p8Q23pUgGMdDTrdpbeV 0YBsnimsrC4RyCRnkA0lfqCfU1yQxXrgDgVITntikQxkA9OOKcoJOAK1T0GRz4KHg8CsiB4m veULEGtnkIyggZHOaxmVreTLON27ioqJtCZrSZlcKeQOx7U87EBXeOBxWa07yNhThu/vVi6J FqHQAy+tO60HfsSy2iSoZEA6ZYms+0IFwVjwBmnR3E4iKtnJ+8AeKSwhjWTeMhielKe6EtTU ZZY0BJBz0pVIx6nvSEyM2OoA605MKGJWtRNFPVJPLtWPHHtVfSoRPaEuBkjg1a1BRLHuRSRV C1kaOIxAFc9qymveFewlnJ5d2Ysgha2bpUlRAMcCsm1tlWYvtOWPJrQuHVF4yABTjFDTKesR W8dtAI1wQwLMe/SrelOwjLBB071ScG4dc/MAeK1LdPKiPTcR1FEUlIdrjwGZi4XABpCf3u80 6Ld5ZBOAKRBklMVoDSMzV1US7mJKkdTVzTUVLXOcqePpWfrUTzoEyQA3arunoUi2k5yKzejF ZCagSLfPJAqHTESeJiSAcdCKu3SExEN0xwKzEMsJY4wKUlqO9xIlkj1DYADGfT1raw+3DVk2 dvI9wJQxOT0rWyVkKFskd/WnC4txCmTtbiodRVki5Axjj3q1L93JxUF3F50CoT8tXLYaRT0i AXULsI1BXsTVUJImogBAqjrUkYe2k4BwOmKlto3a4MrKcZzzWN/dFcgu/O+3IsQHlHrmn6jg OhReeBkipr6GVpxJGdqelRujynJBwppTnoUnY0rMvHZgM2c9afGAR5mBhunrUVv5jQgY4HWp gwZiqjoK2hsJhKqsoAJ3Vl61uVAAuGJ61rZGCPUVmaxbzzIgjJOD1qmroehTl8z+zxjDSg/n U8JkNmJGUcjoe1MhWXAj2gj1rRijb7KYGUYNYO7loS2VtJxMjNwGHUetXxsOCpA9ayoYZIHf CtsGSMVasld8TKTg9eK0WmgJtF48H2p4EjkMq/IByaYwZAp25zT8ucgNtHUjtWjFuV72UKuT wBVK0JuJtxA2qeKv3Nubi2dg2W7Csq3iuIncIpwByc1nN9AZs+eNvljbt7YqK+mZLbk8dhVK 3tZXnVsuuf4SavzQtIm1l5UcA0RkmrId7FLTQLgZdMuDwa1iVBG1e3NZ2nrJbuWdce1X2ORl R1oguoWvIRmXzQSDg9BUnyISVTDdR7UwZJ4Q8d/SnDd/FyfWtCpIw7s7L7zmTcSecir16ts0 AkRgN3UAdKk1G2EkWV4zVJbKTYqc7O9YSjZ3ZGxAiyPEdjfux39au6Y8LqUnAye47VbtrdY7 byjGOnGKoyWxiYlFJJ64qfZ9Sug28jRp/lJwDwB3rVs8rCEPAODiqdtabHEzHLHse1aKhcdy TWkECQFQJCEORVDVozMvzDlaung+4olQOmxhjNXLVaFOLRnaa0Jh3SDOOMGqtxH5s/7rhfSr kljPEAsSZyantrUwybmGDjnisLacpGpnK32aZQ4+UnmrN75Ztx5aIeeDU97YpcqxzgDkc80y CwnUKJEO09KbvHQbHaSjRqeOWHIq+V2r8p/CmRIFGApXHFSenNaRHG7VhsjFoztUdOQKxYna O+IZCEHOTW0euP1qC6tvOUnGAfSnNXJtbQpahKtxjygo9OOtVp7V40DMORzxVuLTMOFbPB45 rQkhUoUIyCMc1ko3KlEoQXcU1j5bclfu02zgdp9wHBPOKF0zb/qjhSeRWhbRCGPap5p2bYrE 7ho8pkPgcChXwM469qZGW3nCkt70R7pAfkIb0Nb9B2ZIxBBx3pnzAc59qNpIHBBHWnAHaAe1 LQfqORkHLCgqjPuHA7U47CowOe9C7VJ4z6UmrA27DRjHXApQfmBFL5bshIGBTVAC45Jp3Fys djJOTzTQGxkjGO1KQfvEj/ChsjBZs5plNNIVGAbBBNJ3PfJ/KpApQAlt1NXBc/zo2Jeo6NM8 npQCP4eD3pzAK2M5Hc03aCxI/Wle7FsAfDbQeTTmLAkFV471GSd4wKfkEgjOT60w9QkmO4ZA GfQUoG0Bm6HpTiqGPOCX757UwHK/dLCgd11Bjudmck54FQjLuU8vGO9TO2U44wajJIzuOSfS ktAT1uSSKOCeMDr61C7MzAggClBIAB5HWgkFjtGB6UBpuwHByOaQFvMPpik37nUYxmkYsHxn 5R0oSKVh7fdwKCo2gnketBOzbkZ3nFRTyGLIHT0qZJ3ESmNJH7LxyR3qLA3YXpmmwnf6gYqh e35SXaiY2nGaXNYIq5oMUGSR9KanQ9Kradc+cr71ycVL5pjycA1V00NQuTcBT6elEbAjGdo9 xUSuW+Y457VFqEv2aNZME54xTQJWJ3bLcUAbmxnFQRzExZxnNCMaS3B2tdEqrtYjcGzS8JnA 60rABdwHNRPlhnOCaoV+Ycw/vdfahC6klTjNMLqFXg5JqSAbjt/GpcbgrbC7gAcnJzTC4LbR kAnqKQAEO4HIOKjGS4bOPamok83LqxzKMlQOB0zTCwZ+BwOtTyYx5gzk9aib26ZqtR3ugaQb cYzTlwB0qSOFQpIpOSCpxxzmpbBtWIz7dcd6YBuyrNgZpPNG7BH0pXf+AgHPemhJjy2cDIOK I1XBJXoKjQADgYp7H5AexpNWKsmKrK2QoJHrTH456+1OUnymRcDHNNgcFPmGaBcyRIiose5s k+npSRPlGGxceppJGyi7Rj1pgHI5PFDVxRaZJhSu05IHSoyRJ97tUzOuzbt59aix64pJWRUt dRdxOA3QUw/J0BINPGFzhRUcw3Kcnp6U0kJbEiMrHByq0gYDdnBx0oVd8Ak6YFIqgoGPOaLW C6tYjDHBHUH1pI4vmJC5z0pxwGIxTVZthXPHtQ0hNDgvG12xjjGaZ5ce4jGR2p6InmbXyy+l Ls2ueeKGio2SYgQLgKPn9aQkfjnmpGP8Xeo49q7sgnP86EJaCqygfLuJ70jNhgdoxnmnxELj jqaVtsimUDGDjFANX3EXytxd4wfQVHHDvLSIxSpJAOGXjvg0iuWOemfSi3UlqwxkH3nGc8Zp DABgcbWqfhgAwyB0prPtbGM4qbAtxhQRgBDkfyoAXd8wp8cmVxtA6c0xsbiGGeKaGI4UgjBC 560ksUTEbeV96nBQ2+NvI4PvUaxB1yCQFo30AZ5VuigqMHvS7VA3Hp70/aPN2n8KjkTOQ3PN EYJAo3YjW8LkEqCCc8ihkjQnAwo6UqYKEelOZMx47UWsy5QsNEgI2g/KTTmypB/h7mkWIbfp SI2+JkPSqJasIwVgduNtQxxorZUDFTx4iXYo4wetRgBRx1PNK19xJXJQ6LCcKCx6H0qONfMf cWxQAC2TTwF7g4FMRBdQQq4wp3dzUqYQAbAcjiibaHxzyaTICjIyRjFKwXsKpCvhuDjihAAz EHr1p8KB5GDelRE7flwDz1pjv3HSR5HPINV5reMkfLznirLgjBJODTVbqp5pWJS6ixLJng42 jFQSwo7BWxnNSOp3YDGgjoTzRYY0QKh6c+tPfAAJ7elKSWUelOGzy8Fc0krFLTUQJuXzNwwa jIJPPNOZcMNvC+lPj2H7wJp2RLZWljjmCl0G5TjNLFFGkoz90dh3qYKGOMdaR0EfyimNDCN0 nXC46VGLZBISFGO9WliGQeuetJPgMQoxihocmug1Qo+4gA9BSITktuyT29KdE5VcgDmkUqAT jk0JCbbEkPAC9T1JppXlRjg9TUhbjBAIxTVUPwc4oHqxDaoyljgY702OJVQjAOD1qXycxcNi jbjGKXKS7kRt4ifm6deKWOCMfMpxnpTm5boMUsnUEcdqGluCuNmg5zv5PTFJEhAEZPSllXhS DyaQggZwMimDHMML1570x0Vhj060YPmkn0zT5CByBQFxFghCBtueaciLnaAAKbG7Nx27CpFB Ztg4z3qVGwbkU8ALcIM0C3A2qRz3qR1YMcMfloPUdeRT5blXSFVSsgGBjtmhomSYndnPpURY ySBDkDtUqnaSG5I4zQohHUEUB9r8A96abdZmJLA49afMDtVyc54FNljEbAZ6jNFiWRi2UFiB 0qW3gWV9jMFXHWk27VBznNKUJj3Bsc0cqBrQY8CCUqMEZxmnJCqsY1UHHO6kAIGSeKCSAcUN Dgug5QQ2Q+MdaQKc4BzmkBj8kKFOc9acg69sUIVwZQqbD1zniomgVyCoUse9TSjCA0kKkuVJ 7Z4ptXFbqNVAmUyM0rJGTtGenzZoXnn3pZGUHAHelYNBscSh1CYJqRxI0hXADegpkJG/kc9s U5QRIWz160WGSOhjcgsD34qNVbcSe/SlZi0nI6UsjFEU9ycUyubSwhRXUqxAx2pUQA8cD1ok Bjl3DBPf3olYbzx8vXFKyFdC/eIZyNvamzRxs+cAinKytDt28dRTN2FAAwKLCTJfK2IAPl3d AKQoqsBn5u5oD8HuRSMRjIHNCVhX1JZQS2Djp1pu0EYOajyUZR1yKmQ7gccChjbGPAFAJAOe lKiAsAMChiCnAII75pIiWwDQkJO4sqjBBH4UxV/hxx6UvzbzyPlpyNls9D1ocUX0FaNthAyo PakVSrAcZbjmpNxb64pjDONwBxQrrQVrq4+dDE2zq3fHSmjcBgcUYbcDkUOSzknoDxTFe7sR tFtfdgVJ5YkjJ34I7etI3Q0sK71OeOKLDW47e3lqAvseKaEKAqDtUjtSwqZBycY9KHJ3AelK +pTQKcLgknHTNP3ArjAzUYBdjk051+X5eCKq4m0KRk4Bx7CgjGU24Hf3oEeRkscilbcwHPPr U2uZy1EkB8vzQSHXpSxyN99sswolJ8sk84pIgQMg9aLGsdUK/wA7FsDJp8I2pk4z6U3AZh25 o27ZeppWCXu6dSTzCpODwaQP37USJlvSgKMYqhSTtcawZhkDK0+PcF5xgHgUwMy5UHjvT4V3 jAYjmjR7iWoGSRM7cc+1LkGPIxjPNIf9a6HnaOtGDtxxg9qWhTQKqZznilKkDI+6ehpAg2nH Qc0KA4A5AoHJWsBBAycZ9c0AvgMeSKUqFO3k+lDrnqSCPSmOYgmmdcsxB9aVXLnrkjjNDR98 9qSJRg9hntRYhq4hdhIMAECpAx5LFj6UMqOBgEbf1pByASPSk0nqOMktGKGLZJ605TgZHBps y7AMd6cP1osD02GO2Wx3p5GxBgkn27U2Qc7jSsWEZUHGepplLVDU8wy7wSeadJKzAjjrSISO 5z0oVArcnPFJJGbdhUGDxnPalaQKAADvzzxQcqAynBpXzkk9adhxTkS4ckHHOM1CxbzQwYhh TmZgowetM6fhUpWC7JldySXwcelALbtxXIJpmSCv+3SyMUUDtmmkArZZjtwKF+U5ApOlOGex 4piuwZ36E4X0oY8/MSeOKJBg4JzSROZFKgAAdM0itQbGNwz7ipEwBkjtUSLhiATzUhDCTy89 BRYqTYrckKtNCbNzDr3FKrc+hAp4PB9T1otYhtMYG3LkDGelL2Geaa6MrKRjGaUDDZJPQ8UC Q52+YKvUd6QrgDcRnPNOAIBbjBpCQwwR0pjlC+o5WYnIxjvRuIYlQoHp2pJMBSy8ADpSMwCq cdqBuGh//9k= --------------A68F5C354E5AE013CABB8090-- From owner-linux-xfs@oss.sgi.com Sat Oct 6 15:33:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96MXVf28963 for linux-xfs-outgoing; Sat, 6 Oct 2001 15:33:31 -0700 Received: from artax.karlin.mff.cuni.cz (root@artax.karlin.mff.cuni.cz [195.113.31.125]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96MXPD28941 for ; Sat, 6 Oct 2001 15:33:25 -0700 Received: from localhost (mikulas@localhost) by artax.karlin.mff.cuni.cz (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id AAA06404; Sun, 7 Oct 2001 00:31:27 +0200 Date: Sun, 7 Oct 2001 00:31:27 +0200 (CEST) From: Mikulas Patocka Reply-To: Mikulas Patocka To: Alan Cox cc: Anton Blanchard , Rik van Riel , Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: %u-order allocation failed In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > It is perfectly OK to have a bit slower access to task_struct with > > probability 1/1000000. > > Except that you added a bug where some old driver code would crash the > machine by doing so. ? > > Yes, but there are still other dangerous usages of kmalloc and > > __get_free_pages. (The most offending one is in select.c) > > Nothing dangeorus there. The -ac vm isnt triggering these cases. Sorry, but it can be triggered by _ANY_ VM since buddy allocator was introduced. You have no guarantee, that you find two or more consecutive free pages. And if you don't, poll() fails. > > not abort his operation when it happens. Instead - they are trying to make > > high-order allocations fail less often :-/ How should random > > Joe-driver-developer know, that kmalloc(4096) is safe and kmalloc(4097) is > > not? > > 4096 is not safe - there is no safe size for a kmalloc, you can always run > out of memory - deal with it. This is not about running out of memory. It is about free space fragmentation. Think this: You have no swap. Program allocates one file cache page, one anon page, one cache page, one anon page and so on. The memory will look like: cache page anon page cache page anon page cache page anon page etc. Now some driver wants to allocate 4097 and it CAN'T. Even when there's half memory free. Mikulas From owner-linux-xfs@oss.sgi.com Sat Oct 6 15:34:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96MYEZ29094 for linux-xfs-outgoing; Sat, 6 Oct 2001 15:34:14 -0700 Received: from artax.karlin.mff.cuni.cz (root@artax.karlin.mff.cuni.cz [195.113.31.125]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96MYBD29068 for ; Sat, 6 Oct 2001 15:34:11 -0700 Received: from localhost (mikulas@localhost) by artax.karlin.mff.cuni.cz (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id AAA13008; Sun, 7 Oct 2001 00:34:05 +0200 Date: Sun, 7 Oct 2001 00:34:05 +0200 (CEST) From: Mikulas Patocka To: Benjamin Herrenschmidt cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: %u-order allocation failed In-Reply-To: <20011006201303.20370@smtp.wanadoo.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > >OK, but my patch uses vmalloc only as a fallback when buddy fails. The > >probability that buddy fails is small. It is slower but with very small > >probability. > > > >It is perfectly OK to have a bit slower access to task_struct with > >probability 1/1000000. > > > >But it is ***BAD*BUG*** if allocation of task_struct fails with > >probability 1/1000000. > > I missed the beginning of the thread, sorry if that question was > already answered, > > What about all the code that still consider kmalloc'ed memory is > safe for use with virt_to_bus and friends and is contiguous > physically for DMA ? In some cases (non-PCI devices, embedded > platforms, etc...), the pci_consistent API is not an option. > That means that __GFP_VMALLOC can't be part of GFP_KERNEL or > many driver will break in horrible ways (random memory corruption). You are right. Code that allocates more than page and expects it to be physicaly contignuous is broken by design. Even rewrite the driver or allocate memory on boot. It will be very hard to audit all drivers for it. Mikulas From owner-linux-xfs@oss.sgi.com Sat Oct 6 15:42:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96Mgen29458 for linux-xfs-outgoing; Sat, 6 Oct 2001 15:42:40 -0700 Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96MgbD29436 for ; Sat, 6 Oct 2001 15:42:37 -0700 Received: from alan by the-village.bc.nu with local (Exim 3.22 #1) id 15q09C-0002X7-00; Sat, 06 Oct 2001 23:42:18 +0100 Subject: Re: %u-order allocation failed To: mikulas@artax.karlin.mff.cuni.cz Date: Sat, 6 Oct 2001 23:42:18 +0100 (BST) Cc: alan@lxorguk.ukuu.org.uk (Alan Cox), anton@samba.org (Anton Blanchard), riel@conectiva.com.br (Rik van Riel), kszysiu@main.braxis.co.uk (Krzysztof Rusocki), linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org In-Reply-To: from "Mikulas Patocka" at Oct 07, 2001 12:31:27 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > Nothing dangeorus there. The -ac vm isnt triggering these cases. > > Sorry, but it can be triggered by _ANY_ VM since buddy allocator was > introduced. You have no guarantee, that you find two or more consecutive > free pages. And if you don't, poll() fails. The two page case isnt one you need to worry about. To all intents and purposes it does not happen, and if you do the maths it isnt going to fail in any interesting ways. Once you go to the 4 page set the odds get a lot longer and then rapidly get very bad indeed, Alan From owner-linux-xfs@oss.sgi.com Sat Oct 6 15:58:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96Mwsp30128 for linux-xfs-outgoing; Sat, 6 Oct 2001 15:58:54 -0700 Received: from artax.karlin.mff.cuni.cz (root@artax.karlin.mff.cuni.cz [195.113.31.125]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96MwoD30104 for ; Sat, 6 Oct 2001 15:58:50 -0700 Received: from localhost (mikulas@localhost) by artax.karlin.mff.cuni.cz (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id AAA01929; Sun, 7 Oct 2001 00:58:41 +0200 Date: Sun, 7 Oct 2001 00:58:41 +0200 (CEST) From: Mikulas Patocka To: Alan Cox cc: Anton Blanchard , Rik van Riel , Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: %u-order allocation failed In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > > Nothing dangeorus there. The -ac vm isnt triggering these cases. > > > > Sorry, but it can be triggered by _ANY_ VM since buddy allocator was > > introduced. You have no guarantee, that you find two or more consecutive > > free pages. And if you don't, poll() fails. > > The two page case isnt one you need to worry about. To all intents and > purposes it does not happen, How do you know it? I showed a simple case where it may happen. > and if you do the maths it isnt going to > fail in any interesting ways. Once you go to the 4 page set the odds get > a lot longer and then rapidly get very bad indeed, I hope you don't want to count probability that the server will or won't crash (yes, crash, because when poll in main loop fails, the server process has not many choices - it can only terminate itself). This reminds me some Microsoft announcement saying that Windows NT are 3 times more stable than Windows 95 :-) And it does happen - see this: http://www.uwsg.indiana.edu/hypermail/linux/kernel/0012.3/0711.html Maybe probability was reduced somehow, but the problem is still there. Mikulas From owner-linux-xfs@oss.sgi.com Sat Oct 6 16:27:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96NR2u30902 for linux-xfs-outgoing; Sat, 6 Oct 2001 16:27:02 -0700 Received: from shed.alex.org.uk (shed.alex.org.uk [195.224.53.219]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96NQvD30880 for ; Sat, 6 Oct 2001 16:26:57 -0700 Received: from [195.224.237.69] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id E47FAA4CB; Sun, 7 Oct 2001 00:26:54 +0100 (BST) Date: Sun, 07 Oct 2001 00:26:52 +0100 From: Alex Bligh - linux-kernel Reply-To: Alex Bligh - linux-kernel To: Mikulas Patocka , Alex Bligh - linux-kernel Cc: Rik van Riel , Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org, Alex Bligh - linux-kernel Subject: Re: %u-order allocation failed Message-ID: <482450248.1002414411@[195.224.237.69]> In-Reply-To: References: X-Mailer: Mulberry/2.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Mikulas, > It uses vmalloc only when __GFP_VMALLOC flag is given - and so it is > expected to not use __GFP_VMALLOC flag in IRQ. Ah OK. If your point is that people use GFP_ATOMIC when it's not needed, and demand physically contiguous memory when only virtually contiguous memory is needed, in several places in the kernel, then you are correct. [I am not convinced that vmalloc() is the best way to fix it though.] Most of the order>0 users of __get_free_pages() don't 'need' to do that. For instance I was convinced that networking code needed this for larger than 4k packets (pre-fragmentation or post-prefragmentation) until someone pointed out that the kiovec stuff was there, waiting to be used, if someone made the code changes. But the code changes are non-trivial. Note also that something (not sure what) has made fragmentation increasingly prevalent over the years since the buddy allocator was originally put in. (see my earlier patch for measuring fragmentation). There is currently /no/ intelligence in there to defragment stuff, and the 'light touch' patches (ideas I had and posted here) don't appear to work. If we want __get_free_pages to allocate order>0 this is possible to do reliably if we have some intelligent form of page out which attempts to defragment as it runs, or else run a defragmenter. It's also possible to do allocate order>0 GFP_ATOMIC far more reliably than at present if we had a target for defragmentation under normal operation, just like we retain a target for pages reserved for atomic allocation. The very original buddy code (circa 94/95 which I wrote) maintained that there should be (from memory) at least one entry on a high order list (I think it was the 64k list), which gave you a few guaranteed 8k allocations (which was I was interested in). It's trivial to patch this into __get_free_pages though I haven't tried this (i.e. rather than just look at total free pages, look at the existance of a page on either the order=4, 5, 6... queues). Note you will use memory less efficiently if you do this. In times of cheaper memory costs, it might be worth testing this approach again. -- Alex Bligh From owner-linux-xfs@oss.sgi.com Sat Oct 6 16:34:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96NYUV31161 for linux-xfs-outgoing; Sat, 6 Oct 2001 16:34:30 -0700 Received: from shed.alex.org.uk (shed.alex.org.uk [195.224.53.219]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96NYQD31139 for ; Sat, 6 Oct 2001 16:34:27 -0700 Received: from [195.224.237.69] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 3673EA4CB; Sun, 7 Oct 2001 00:34:25 +0100 (BST) Date: Sun, 07 Oct 2001 00:34:22 +0100 From: Alex Bligh - linux-kernel Reply-To: Alex Bligh - linux-kernel To: Mikulas Patocka , Alan Cox Cc: Anton Blanchard , Rik van Riel , Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org, Alex Bligh - linux-kernel Subject: Re: %u-order allocation failed Message-ID: <482899202.1002414861@[195.224.237.69]> In-Reply-To: References: X-Mailer: Mulberry/2.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --On Sunday, 07 October, 2001 12:31 AM +0200 Mikulas Patocka wrote: > Sorry, but it can be triggered by _ANY_ VM since buddy allocator was > introduced. Just for info, this was circa 1.0.6 :-) (patches were available since 0.99.xxx). And before it was introduced, rather a lot of other things would consistently fail, for instance anything that reassembled packets whose total size was >4k. And currently they still need that. Kernel memory is a limited resource. Contiguous kernel memory more so. Things that need it need to better deal with the lack of it, esp. in transient situations (such as by working round the absence of it, e.g. kiovec in net code, or by causing some freeing and retrying). And, when contiguous kernel memory is short, the allocator could do with some intelligent page freeing to reduce fragmentation. -- Alex Bligh From owner-linux-xfs@oss.sgi.com Sat Oct 6 16:36:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96NaFp31316 for linux-xfs-outgoing; Sat, 6 Oct 2001 16:36:15 -0700 Received: from shed.alex.org.uk (shed.alex.org.uk [195.224.53.219]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96NaDD31293 for ; Sat, 6 Oct 2001 16:36:13 -0700 Received: from [195.224.237.69] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 1C723A4CB; Sun, 7 Oct 2001 00:36:11 +0100 (BST) Date: Sun, 07 Oct 2001 00:36:09 +0100 From: Alex Bligh - linux-kernel Reply-To: Alex Bligh - linux-kernel To: Mikulas Patocka , Alan Cox Cc: Anton Blanchard , Rik van Riel , Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org, Alex Bligh - linux-kernel Subject: Re: %u-order allocation failed Message-ID: <483005851.1002414968@[195.224.237.69]> In-Reply-To: References: X-Mailer: Mulberry/2.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --On Sunday, 07 October, 2001 12:58 AM +0200 Mikulas Patocka wrote: > How do you know it? I showed a simple case where it may happen. Do you know two order=0 allocations with the same GFP_ value would not have also failed? -- Alex Bligh From owner-linux-xfs@oss.sgi.com Sat Oct 6 16:58:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96NwJ032557 for linux-xfs-outgoing; Sat, 6 Oct 2001 16:58:19 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96Nw4D32408 for ; Sat, 6 Oct 2001 16:58:05 -0700 Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sun, 7 Oct 2001 10:00:26 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10072001-100011-230.MMD@cymax.com.au; Sun, 7 Oct 2001 10:00:11 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sun Oct 7 09:53:36 2001) X-From_: owner-linux-xfs@oss.sgi.com Sun Oct 7 00:10:23 2001 Delivered-To: cymax@smartchat.net.au Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by entoo.connect.com.au (Postfix) with ESMTP id 58202DDECE for ; Sun, 7 Oct 2001 00:10:22 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96EAhG15553; Sat, 6 Oct 2001 07:10:43 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Sat, 6 Oct 2001 07:09:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96E9bh15450 for linux-xfs-outgoing; Sat, 6 Oct 2001 07:09:37 -0700 Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96E9UD15426 for ; Sat, 6 Oct 2001 07:09:30 -0700 Received: from walt400.localhost (user-uini6cb.dsl.mindspring.com [165.121.25.139]) by hall.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id KAA05800 for ; Sat, 6 Oct 2001 10:09:26 -0400 (EDT) Received: from mindspring.com (localhost.localdomain [127.0.0.1]) by walt400.localhost (Postfix) with ESMTP id DF1728171E3; Sat, 6 Oct 2001 07:07:54 -0700 (PDT) Message-ID: <3BBF103A.3030700@mindspring.com> Date: Sat, 06 Oct 2001 07:07:54 -0700 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010914 X-Accept-Language: en-us MIME-Version: 1.0 To: Federico Sevilla III Cc: Linux XFS Mailing List Subject: Re: We have a mail loop! References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Oct 2001 00:00:26.0734 (UTC) FILETIME=[11CD48E0:01C14EC3] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Not just you :) Everything's coming back 'round again it seems. Just got up and found my mailbox full of stuff, started reading them and though "Man, these sure sound familiar...." It's like deja-vu all over again... :) -Walt Federico Sevilla III wrote: > I thought it was just me but I don't think it is. A member of the mailing > list, , has a mail loop on us it seems. See this > trail in the received headers: > > Return-Path: > Delivered-To: jijo@leathercollection.ph > Received: from localhost (localhost [127.0.0.1]) > by gusi.leathercollection.ph (Postfix) with ESMTP id 02BE8C00B63 > for ; Sat, 6 Oct 2001 14:13:44 +0800 (PHT) > Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) > by gusi.leathercollection.ph (Postfix) with ESMTP id 92924C00B60 > for ; Sat, 6 Oct 2001 14:13:41 +0800 (PHT) > Received: from localhost (mail@localhost) > by oss.sgi.com (8.11.2/8.11.3) with SMTP id f966CDx03773; > Fri, 5 Oct 2001 23:12:13 -0700 > X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs > Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 23:12:12 -0700 > Received: (from majordomo@localhost) > by oss.sgi.com (8.11.2/8.11.3) id f9662Aa02294 > for linux-xfs-outgoing; Fri, 5 Oct 2001 23:02:10 -0700 > Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) > by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9661uD02127 > for ; Fri, 5 Oct 2001 23:01:56 -0700 > Received: from defiant.cymax.com.au > (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) > by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: > SGI does not authorize the use of its proprietary > systems or networks for unsolicited or bulk email > from the Internet.) > via ESMTP id XAA00781 > for ; Fri, 5 Oct 2001 23:02:24 -0700 (PDT) > mail_from (ian.nelson@echostar.com) > Received: from defiant.cymax.com.au ([192.168.70.2]) by > defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); > Sat, 6 Oct 2001 16:00:54 +1000 > Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes > 5.00.2195) with SMTP (Global POP3 Download) > id MSG10062001-160026-123.MMD@cymax.com.au; Sat, 6 Oct 2001 16:00:26 +1000 > Received: by smartchat.net.au (mbox cymax) > (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sat Oct 6 15:53:54 2001) > X-From_: owner-linux-xfs@oss.sgi.com Sat Oct 6 09:29:18 2001 > Delivered-To: cymax@smartchat.net.au > Received: from yarrina.connect.com.au (yarrina.connect.com.au [192.189.54.17]) > by entoo.connect.com.au (Postfix) with ESMTP id 28669DFBFC > for ; Sat, 6 Oct 2001 09:29:17 +1000 (EST) > Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) > by yarrina.connect.com.au (Postfix) with ESMTP id 8865B29EBA5 > for ; Sat, 6 Oct 2001 07:09:24 +1000 (EST) > Received: from localhost (mail@localhost) > by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95L5qU20744; > Fri, 5 Oct 2001 14:05:52 -0700 > X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs > Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 14:04:54 -0700 > Received: (from majordomo@localhost) > by oss.sgi.com (8.11.2/8.11.3) id f95L4sh20646 > for linux-xfs-outgoing; Fri, 5 Oct 2001 14:04:54 -0700 > Received: from linux0.echostar.com (w146-253.echostar.com [205.172.146.253]) > by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95L4oD20627 > for ; Fri, 5 Oct 2001 14:04:50 -0700 > Received: from echostar.com (linux10.echostar.com [10.79.98.110]) > by linux0.echostar.com (Postfix) with ESMTP id 1005379085 > for ; Fri, 5 Oct 2001 15:04:40 -0600 (MDT) > > > From owner-linux-xfs@oss.sgi.com Sat Oct 6 16:58:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96NwO032630 for linux-xfs-outgoing; Sat, 6 Oct 2001 16:58:24 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96Nw6D32432 for ; Sat, 6 Oct 2001 16:58:06 -0700 Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sun, 7 Oct 2001 10:00:26 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10072001-100011-231.MMD@cymax.com.au; Sun, 7 Oct 2001 10:00:11 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sun Oct 7 09:53:37 2001) X-From_: owner-linux-xfs@oss.sgi.com Sun Oct 7 00:46:02 2001 Delivered-To: cymax@smartchat.net.au Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by entoo.connect.com.au (Postfix) with ESMTP id 5C5C2DEB02 for ; Sun, 7 Oct 2001 00:46:01 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96EkLb16363; Sat, 6 Oct 2001 07:46:21 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Sat, 6 Oct 2001 07:44:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96EivH16250 for linux-xfs-outgoing; Sat, 6 Oct 2001 07:44:57 -0700 Received: from artax.karlin.mff.cuni.cz (root@artax.karlin.mff.cuni.cz [195.113.31.125]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96EinD16231 for ; Sat, 6 Oct 2001 07:44:49 -0700 Received: from localhost (mikulas@localhost) by artax.karlin.mff.cuni.cz (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id QAA30223; Sat, 6 Oct 2001 16:44:43 +0200 Date: Sat, 6 Oct 2001 16:44:43 +0200 (CEST) From: Mikulas Patocka To: Rik van Riel Cc: Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: %u-order allocation failed In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1908636959-741352904-1002379483=:29342" X-OriginalArrivalTime: 07 Oct 2001 00:00:26.0843 (UTC) FILETIME=[11DDEAB0:01C14EC3] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1908636959-741352904-1002379483=:29342 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 6 Oct 2001, Rik van Riel wrote: > On Sat, 6 Oct 2001, Mikulas Patocka wrote: > > > Buddy allocator is broken - kill it. Or at least do not misuse it for > > anything except kernel or driver initialization. > > Please send patches to get rid of the buddy allocator while > still making it possible to allocate contiguous chunks of > memory. > > If you have any idea on how to fix things, this would be a > good time to let us know. Here goes the fix. (note that I didn't try to compile it so there may be bugs, but you see the point). kmalloc should be fixed too (used badly for example in select.c - and yes - I have seen real world bugreports for poll randomly failing with ENOMEM), but it will be hard to audit all drivers that they do not try to use dma on kmallocated memory. Mikulas --1908636959-741352904-1002379483=:29342 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="vmalloc.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: ZGlmZiAtdSAtciBsaW51eC1vcmlnL2luY2x1ZGUvYXNtLWkzODYvcHJvY2Vz c29yLmggbGludXgvaW5jbHVkZS9hc20taTM4Ni9wcm9jZXNzb3IuaA0KLS0t IGxpbnV4LW9yaWcvaW5jbHVkZS9hc20taTM4Ni9wcm9jZXNzb3IuaAlTYXQg T2N0ICA2IDE2OjIxOjUwIDIwMDENCisrKyBsaW51eC9pbmNsdWRlL2FzbS1p Mzg2L3Byb2Nlc3Nvci5oCVNhdCBPY3QgIDYgMTY6MzE6MTUgMjAwMQ0KQEAg LTQ0OCw3ICs0NDgsNyBAQA0KICNkZWZpbmUgS1NUS19FU1AodHNrKQkoKCh1 bnNpZ25lZCBsb25nICopKDQwOTYrKHVuc2lnbmVkIGxvbmcpKHRzaykpKVsx MDIyXSkNCiANCiAjZGVmaW5lIFRIUkVBRF9TSVpFICgyKlBBR0VfU0laRSkN Ci0jZGVmaW5lIGFsbG9jX3Rhc2tfc3RydWN0KCkgKChzdHJ1Y3QgdGFza19z dHJ1Y3QgKikgX19nZXRfZnJlZV9wYWdlcyhHRlBfS0VSTkVMLDEpKQ0KKyNk ZWZpbmUgYWxsb2NfdGFza19zdHJ1Y3QoKSAoKHN0cnVjdCB0YXNrX3N0cnVj dCAqKSBfX2dldF9mcmVlX3BhZ2VzKEdGUF9LRVJORUwgfCBfX0dGUF9WTUFM TE9DLDEpKQ0KICNkZWZpbmUgZnJlZV90YXNrX3N0cnVjdChwKSBmcmVlX3Bh Z2VzKCh1bnNpZ25lZCBsb25nKSAocCksIDEpDQogI2RlZmluZSBnZXRfdGFz a19zdHJ1Y3QodHNrKSAgICAgIGF0b21pY19pbmMoJnZpcnRfdG9fcGFnZSh0 c2spLT5jb3VudCkNCiANCmRpZmYgLXUgLXIgbGludXgtb3JpZy9pbmNsdWRl L2xpbnV4L21tLmggbGludXgvaW5jbHVkZS9saW51eC9tbS5oDQotLS0gbGlu dXgtb3JpZy9pbmNsdWRlL2xpbnV4L21tLmgJU2F0IE9jdCAgNiAxNjoyMTo1 OSAyMDAxDQorKysgbGludXgvaW5jbHVkZS9saW51eC9tbS5oCVNhdCBPY3Qg IDYgMTY6Mjg6MTIgMjAwMQ0KQEAgLTU1MCw2ICs1NTAsNyBAQA0KICNkZWZp bmUgX19HRlBfSU8JMHg0MAkvKiBDYW4gc3RhcnQgbG93IG1lbW9yeSBwaHlz aWNhbCBJTz8gKi8NCiAjZGVmaW5lIF9fR0ZQX0hJR0hJTwkweDgwCS8qIENh biBzdGFydCBoaWdoIG1lbSBwaHlzaWNhbCBJTz8gKi8NCiAjZGVmaW5lIF9f R0ZQX0ZTCTB4MTAwCS8qIENhbiBjYWxsIGRvd24gdG8gbG93LWxldmVsIEZT PyAqLw0KKyNkZWZpbmUgX19HRlBfVk1BTExPQwkweDIwMAkvKiBDYW4gdm1h bGxvYyBwYWdlcyBpZiBidWRkeSBhbGxvY2F0b3IgZmFpbHMgKi8NCiANCiAj ZGVmaW5lIEdGUF9OT0hJR0hJTwkoX19HRlBfSElHSCB8IF9fR0ZQX1dBSVQg fCBfX0dGUF9JTykNCiAjZGVmaW5lIEdGUF9OT0lPCShfX0dGUF9ISUdIIHwg X19HRlBfV0FJVCkNCmRpZmYgLXUgLXIgbGludXgtb3JpZy9tbS9wYWdlX2Fs bG9jLmMgbGludXgvbW0vcGFnZV9hbGxvYy5jDQotLS0gbGludXgtb3JpZy9t bS9wYWdlX2FsbG9jLmMJU2F0IE9jdCAgNiAxNjoyMTo0NyAyMDAxDQorKysg bGludXgvbW0vcGFnZV9hbGxvYy5jCVNhdCBPY3QgIDYgMTY6MzY6MjggMjAw MQ0KQEAgLTE4LDYgKzE4LDcgQEANCiAjaW5jbHVkZSA8bGludXgvYm9vdG1l bS5oPg0KICNpbmNsdWRlIDxsaW51eC9zbGFiLmg+DQogI2luY2x1ZGUgPGxp bnV4L2NvbXBpbGVyLmg+DQorI2luY2x1ZGUgPGxpbnV4L3ZtYWxsb2MuaD4N CiANCiBpbnQgbnJfc3dhcF9wYWdlczsNCiBpbnQgbnJfYWN0aXZlX3BhZ2Vz Ow0KQEAgLTQyMSw5ICs0MjIsOSBAQA0KIAlzdHJ1Y3QgcGFnZSAqIHBhZ2U7 DQogDQogCXBhZ2UgPSBhbGxvY19wYWdlcyhnZnBfbWFzaywgb3JkZXIpOw0K LQlpZiAoIXBhZ2UpDQotCQlyZXR1cm4gMDsNCi0JcmV0dXJuICh1bnNpZ25l ZCBsb25nKSBwYWdlX2FkZHJlc3MocGFnZSk7DQorCWlmIChwYWdlKSByZXR1 cm4gKHVuc2lnbmVkIGxvbmcpIHBhZ2VfYWRkcmVzcyhwYWdlKTsNCisJaWYg KGdmcF9tYXNrICYgX19HRlBfVk1BTExPQykgcmV0dXJuICh1bnNpZ25lZCBs b25nKV9fdm1hbGxvYyhQQUdFX1NJWkUgPDwgb3JkZXIsIGdmcF9tYXNrLCBQ QUdFX0tFUk5FTCk7DQorCXJldHVybiAwOw0KIH0NCiANCiB1bnNpZ25lZCBs b25nIGdldF96ZXJvZWRfcGFnZSh1bnNpZ25lZCBpbnQgZ2ZwX21hc2spDQpA QCAtNDQ3LDYgKzQ0OCwxMCBAQA0KIA0KIHZvaWQgZnJlZV9wYWdlcyh1bnNp Z25lZCBsb25nIGFkZHIsIHVuc2lnbmVkIGludCBvcmRlcikNCiB7DQorCWlm IChhZGRyID49IFZNQUxMT0NfU1RBUlQgJiYgYWRkciA8IFZNQUxMT0NfRU5E KSB7DQorCQl2ZnJlZSgodm9pZCAqKWFkZHIpOw0KKwkJcmV0dXJuOw0KKwl9 DQogCWlmIChhZGRyICE9IDApDQogCQlfX2ZyZWVfcGFnZXModmlydF90b19w YWdlKGFkZHIpLCBvcmRlcik7DQogfQ0K --1908636959-741352904-1002379483=:29342-- From owner-linux-xfs@oss.sgi.com Sat Oct 6 16:58:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96Nw9132462 for linux-xfs-outgoing; Sat, 6 Oct 2001 16:58:09 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96Nw3D32386 for ; Sat, 6 Oct 2001 16:58:03 -0700 Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sun, 7 Oct 2001 10:00:26 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10072001-100011-229.MMD@cymax.com.au; Sun, 7 Oct 2001 10:00:11 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sun Oct 7 09:53:36 2001) X-From_: owner-linux-xfs@oss.sgi.com Sun Oct 7 00:04:59 2001 Delivered-To: cymax@smartchat.net.au Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by entoo.connect.com.au (Postfix) with ESMTP id 74698DE0F1 for ; Sun, 7 Oct 2001 00:04:58 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96E5FY15350; Sat, 6 Oct 2001 07:05:15 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Sat, 6 Oct 2001 07:04:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96E4F115251 for linux-xfs-outgoing; Sat, 6 Oct 2001 07:04:15 -0700 Received: from netbank.com.br (IDENT:postfix@garrincha.netbank.com.br [200.203.199.88]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96E4BD15231 for ; Sat, 6 Oct 2001 07:04:12 -0700 Received: from 1-102.ctame701-1.telepar.net.br (1-102.ctame701-1.telepar.net.br [200.181.137.102]) by netbank.com.br (Postfix) with ESMTP id 2A0D646839; Sat, 6 Oct 2001 11:03:19 -0300 (BRST) Received: (from localhost user: 'riel', uid#500) by imladris.surriel.com with ESMTP id ; Sat, 6 Oct 2001 11:03:48 -0300 Date: Sat, 6 Oct 2001 11:03:47 -0300 (BRST) From: Rik van Riel X-X-Sender: To: Mikulas Patocka Cc: Krzysztof Rusocki , , Subject: Re: %u-order allocation failed In-Reply-To: Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 07 Oct 2001 00:00:26.0640 (UTC) FILETIME=[11BEF100:01C14EC3] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 6 Oct 2001, Mikulas Patocka wrote: > Buddy allocator is broken - kill it. Or at least do not misuse it for > anything except kernel or driver initialization. Please send patches to get rid of the buddy allocator while still making it possible to allocate contiguous chunks of memory. If you have any idea on how to fix things, this would be a good time to let us know. cheers, Rik -- DMCA, SSSCA, W3C? Who cares? http://thefreeworld.net/ (volunteers needed) http://www.surriel.com/ http://distro.conectiva.com/ From owner-linux-xfs@oss.sgi.com Sat Oct 6 16:58:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96Nw8f32457 for linux-xfs-outgoing; Sat, 6 Oct 2001 16:58:08 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96Nw2D32366 for ; Sat, 6 Oct 2001 16:58:02 -0700 Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sun, 7 Oct 2001 10:00:26 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10072001-100011-228.MMD@cymax.com.au; Sun, 7 Oct 2001 10:00:11 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sun Oct 7 09:53:36 2001) X-From_: owner-linux-xfs@oss.sgi.com Sun Oct 7 00:01:39 2001 Delivered-To: cymax@smartchat.net.au Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by entoo.connect.com.au (Postfix) with ESMTP id A8726DE42E for ; Sun, 7 Oct 2001 00:01:38 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96E20N15152; Sat, 6 Oct 2001 07:02:00 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Sat, 6 Oct 2001 07:01:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96E11o15046 for linux-xfs-outgoing; Sat, 6 Oct 2001 07:01:01 -0700 Received: from artax.karlin.mff.cuni.cz (root@artax.karlin.mff.cuni.cz [195.113.31.125]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96E0vD15019 for ; Sat, 6 Oct 2001 07:00:57 -0700 Received: from localhost (mikulas@localhost) by artax.karlin.mff.cuni.cz (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id QAA28175; Sat, 6 Oct 2001 16:00:21 +0200 Date: Sat, 6 Oct 2001 16:00:21 +0200 (CEST) From: Mikulas Patocka Reply-To: Mikulas Patocka To: Rik van Riel Cc: Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: %u-order allocation failed In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 07 Oct 2001 00:00:26.0515 (UTC) FILETIME=[11ABDE30:01C14EC3] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > After simple bash fork bombing (about 200 forks) on my UP Celeron/96MB > > I get quite a lot %u-allocations failed, but only when swap is turned > > off. > > > I'm not familiar with LinuxVM.. so... is it normal behaviour ? or (if not) > > what's happening when such messages are printed my kernel ? > > This is perfectly normal behaviour: > > 1) on your system, you have no process limit configured for > yourself so you can start processes until all resources > (memory, file descriptors, ...) are used > > 2) when all processes are used, there really is no way the > kernel can buy you more hardware on ebay and install it > on the fly ... all it can do is start failing allocations > > On production systems, good admins setup per-user limits for > the various resources so no single user is able to run the > system into the ground. No, it's not normal. It is long-standing bug - I think from 2.2 kernels. You know that without swap and with certain memory allocation strategy (when process in a loop allocates one anonymous page, one file cache page and again...) this bug can be triggered even when there is half memory free. Buddy allocator is broken - kill it. Or at least do not misuse it for anything except kernel or driver initialization. Mikulas From owner-linux-xfs@oss.sgi.com Sat Oct 6 16:58:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96NwUL32719 for linux-xfs-outgoing; Sat, 6 Oct 2001 16:58:30 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96Nw8D32454 for ; Sat, 6 Oct 2001 16:58:08 -0700 Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sun, 7 Oct 2001 10:00:27 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10072001-100012-233.MMD@cymax.com.au; Sun, 7 Oct 2001 10:00:12 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sun Oct 7 09:53:37 2001) X-From_: owner-linux-xfs@oss.sgi.com Sun Oct 7 01:31:34 2001 Delivered-To: cymax@smartchat.net.au Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by entoo.connect.com.au (Postfix) with ESMTP id CBCB9DE263 for ; Sun, 7 Oct 2001 01:31:33 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96FWR517333; Sat, 6 Oct 2001 08:32:27 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Sat, 6 Oct 2001 08:31:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96FVjq17239 for linux-xfs-outgoing; Sat, 6 Oct 2001 08:31:45 -0700 Received: from artax.karlin.mff.cuni.cz (root@artax.karlin.mff.cuni.cz [195.113.31.125]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96FVWD17216 for ; Sat, 6 Oct 2001 08:31:32 -0700 Received: from localhost (mikulas@localhost) by artax.karlin.mff.cuni.cz (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id RAA32433; Sat, 6 Oct 2001 17:31:26 +0200 Date: Sat, 6 Oct 2001 17:31:26 +0200 (CEST) From: Mikulas Patocka To: Rik van Riel Cc: Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: %u-order allocation failed In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1908636959-1328101436-1002382286=:32345" X-OriginalArrivalTime: 07 Oct 2001 00:00:27.0062 (UTC) FILETIME=[11FF5560:01C14EC3] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1908636959-1328101436-1002382286=:32345 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 6 Oct 2001, Mikulas Patocka wrote: > On Sat, 6 Oct 2001, Rik van Riel wrote: > > > On Sat, 6 Oct 2001, Mikulas Patocka wrote: > > > > > Buddy allocator is broken - kill it. Or at least do not misuse it for > > > anything except kernel or driver initialization. > > > > Please send patches to get rid of the buddy allocator while > > still making it possible to allocate contiguous chunks of > > memory. > > > > If you have any idea on how to fix things, this would be a > > good time to let us know. > > Here goes the fix. (note that I didn't try to compile it so there may be > bugs, but you see the point). > > kmalloc should be fixed too (used badly for example in select.c - and yes > - I have seen real world bugreports for poll randomly failing with > ENOMEM), but it will be hard to audit all drivers that they do not try to > use dma on kmallocated memory. This is enhanced version of a patch that fixes select and poll as well. Again - not compiled, not tried. Mikulas --1908636959-1328101436-1002382286=:32345 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="vmalloc.patch.2" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: ZGlmZiAtdSAtciBsaW51eC1vcmlnL2ZzL3NlbGVjdC5jIGxpbnV4L2ZzL3Nl bGVjdC5jDQotLS0gbGludXgtb3JpZy9mcy9zZWxlY3QuYwlTYXQgT2N0ICA2 IDE2OjIwOjQ1IDIwMDENCisrKyBsaW51eC9mcy9zZWxlY3QuYwlTYXQgT2N0 ICA2IDE2OjU0OjQ0IDIwMDENCkBAIC0yMzYsNyArMjM2LDcgQEANCiANCiBz dGF0aWMgdm9pZCAqc2VsZWN0X2JpdHNfYWxsb2MoaW50IHNpemUpDQogew0K LQlyZXR1cm4ga21hbGxvYyg2ICogc2l6ZSwgR0ZQX0tFUk5FTCk7DQorCXJl dHVybiBrbWFsbG9jKDYgKiBzaXplLCBHRlBfS0VSTkVMIHwgX19HRlBfVk1B TExPQyk7DQogfQ0KIA0KIHN0YXRpYyB2b2lkIHNlbGVjdF9iaXRzX2ZyZWUo dm9pZCAqYml0cywgaW50IHNpemUpDQpAQCAtNDM4LDcgKzQzOCw3IEBADQog CWlmIChuZmRzICE9IDApIHsNCiAJCWZkcyA9IChzdHJ1Y3QgcG9sbGZkICoq KWttYWxsb2MoDQogCQkJKDEgKyAobmZkcyAtIDEpIC8gUE9MTEZEX1BFUl9Q QUdFKSAqIHNpemVvZihzdHJ1Y3QgcG9sbGZkICopLA0KLQkJCUdGUF9LRVJO RUwpOw0KKwkJCUdGUF9LRVJORUwgfCBfX0dGUF9WTUFMTE9DKTsNCiAJCWlm IChmZHMgPT0gTlVMTCkNCiAJCQlnb3RvIG91dDsNCiAJfQ0KZGlmZiAtdSAt ciBsaW51eC1vcmlnL2luY2x1ZGUvYXNtLWkzODYvcHJvY2Vzc29yLmggbGlu dXgvaW5jbHVkZS9hc20taTM4Ni9wcm9jZXNzb3IuaA0KLS0tIGxpbnV4LW9y aWcvaW5jbHVkZS9hc20taTM4Ni9wcm9jZXNzb3IuaAlTYXQgT2N0ICA2IDE2 OjIxOjUwIDIwMDENCisrKyBsaW51eC9pbmNsdWRlL2FzbS1pMzg2L3Byb2Nl c3Nvci5oCVNhdCBPY3QgIDYgMTY6MzE6MTUgMjAwMQ0KQEAgLTQ0OCw3ICs0 NDgsNyBAQA0KICNkZWZpbmUgS1NUS19FU1AodHNrKQkoKCh1bnNpZ25lZCBs b25nICopKDQwOTYrKHVuc2lnbmVkIGxvbmcpKHRzaykpKVsxMDIyXSkNCiAN CiAjZGVmaW5lIFRIUkVBRF9TSVpFICgyKlBBR0VfU0laRSkNCi0jZGVmaW5l IGFsbG9jX3Rhc2tfc3RydWN0KCkgKChzdHJ1Y3QgdGFza19zdHJ1Y3QgKikg X19nZXRfZnJlZV9wYWdlcyhHRlBfS0VSTkVMLDEpKQ0KKyNkZWZpbmUgYWxs b2NfdGFza19zdHJ1Y3QoKSAoKHN0cnVjdCB0YXNrX3N0cnVjdCAqKSBfX2dl dF9mcmVlX3BhZ2VzKEdGUF9LRVJORUwgfCBfX0dGUF9WTUFMTE9DLDEpKQ0K ICNkZWZpbmUgZnJlZV90YXNrX3N0cnVjdChwKSBmcmVlX3BhZ2VzKCh1bnNp Z25lZCBsb25nKSAocCksIDEpDQogI2RlZmluZSBnZXRfdGFza19zdHJ1Y3Qo dHNrKSAgICAgIGF0b21pY19pbmMoJnZpcnRfdG9fcGFnZSh0c2spLT5jb3Vu dCkNCiANCmRpZmYgLXUgLXIgbGludXgtb3JpZy9pbmNsdWRlL2xpbnV4L21t LmggbGludXgvaW5jbHVkZS9saW51eC9tbS5oDQotLS0gbGludXgtb3JpZy9p bmNsdWRlL2xpbnV4L21tLmgJU2F0IE9jdCAgNiAxNjoyMTo1OSAyMDAxDQor KysgbGludXgvaW5jbHVkZS9saW51eC9tbS5oCVNhdCBPY3QgIDYgMTY6Mjg6 MTIgMjAwMQ0KQEAgLTU1MCw2ICs1NTAsNyBAQA0KICNkZWZpbmUgX19HRlBf SU8JMHg0MAkvKiBDYW4gc3RhcnQgbG93IG1lbW9yeSBwaHlzaWNhbCBJTz8g Ki8NCiAjZGVmaW5lIF9fR0ZQX0hJR0hJTwkweDgwCS8qIENhbiBzdGFydCBo aWdoIG1lbSBwaHlzaWNhbCBJTz8gKi8NCiAjZGVmaW5lIF9fR0ZQX0ZTCTB4 MTAwCS8qIENhbiBjYWxsIGRvd24gdG8gbG93LWxldmVsIEZTPyAqLw0KKyNk ZWZpbmUgX19HRlBfVk1BTExPQwkweDIwMAkvKiBDYW4gdm1hbGxvYyBwYWdl cyBpZiBidWRkeSBhbGxvY2F0b3IgZmFpbHMgKi8NCiANCiAjZGVmaW5lIEdG UF9OT0hJR0hJTwkoX19HRlBfSElHSCB8IF9fR0ZQX1dBSVQgfCBfX0dGUF9J TykNCiAjZGVmaW5lIEdGUF9OT0lPCShfX0dGUF9ISUdIIHwgX19HRlBfV0FJ VCkNCmRpZmYgLXUgLXIgbGludXgtb3JpZy9tbS9wYWdlX2FsbG9jLmMgbGlu dXgvbW0vcGFnZV9hbGxvYy5jDQotLS0gbGludXgtb3JpZy9tbS9wYWdlX2Fs bG9jLmMJU2F0IE9jdCAgNiAxNjoyMTo0NyAyMDAxDQorKysgbGludXgvbW0v cGFnZV9hbGxvYy5jCVNhdCBPY3QgIDYgMTY6MzY6MjggMjAwMQ0KQEAgLTE4 LDYgKzE4LDcgQEANCiAjaW5jbHVkZSA8bGludXgvYm9vdG1lbS5oPg0KICNp bmNsdWRlIDxsaW51eC9zbGFiLmg+DQogI2luY2x1ZGUgPGxpbnV4L2NvbXBp bGVyLmg+DQorI2luY2x1ZGUgPGxpbnV4L3ZtYWxsb2MuaD4NCiANCiBpbnQg bnJfc3dhcF9wYWdlczsNCiBpbnQgbnJfYWN0aXZlX3BhZ2VzOw0KQEAgLTQy MSw5ICs0MjIsOSBAQA0KIAlzdHJ1Y3QgcGFnZSAqIHBhZ2U7DQogDQogCXBh Z2UgPSBhbGxvY19wYWdlcyhnZnBfbWFzaywgb3JkZXIpOw0KLQlpZiAoIXBh Z2UpDQotCQlyZXR1cm4gMDsNCi0JcmV0dXJuICh1bnNpZ25lZCBsb25nKSBw YWdlX2FkZHJlc3MocGFnZSk7DQorCWlmIChwYWdlKSByZXR1cm4gKHVuc2ln bmVkIGxvbmcpIHBhZ2VfYWRkcmVzcyhwYWdlKTsNCisJaWYgKGdmcF9tYXNr ICYgX19HRlBfVk1BTExPQykgcmV0dXJuICh1bnNpZ25lZCBsb25nKV9fdm1h bGxvYyhQQUdFX1NJWkUgPDwgb3JkZXIsIGdmcF9tYXNrLCBQQUdFX0tFUk5F TCk7DQorCXJldHVybiAwOw0KIH0NCiANCiB1bnNpZ25lZCBsb25nIGdldF96 ZXJvZWRfcGFnZSh1bnNpZ25lZCBpbnQgZ2ZwX21hc2spDQpAQCAtNDQ3LDYg KzQ0OCwxMCBAQA0KIA0KIHZvaWQgZnJlZV9wYWdlcyh1bnNpZ25lZCBsb25n IGFkZHIsIHVuc2lnbmVkIGludCBvcmRlcikNCiB7DQorCWlmIChhZGRyID49 IFZNQUxMT0NfU1RBUlQgJiYgYWRkciA8IFZNQUxMT0NfRU5EKSB7DQorCQl2 ZnJlZSgodm9pZCAqKWFkZHIpOw0KKwkJcmV0dXJuOw0KKwl9DQogCWlmIChh ZGRyICE9IDApDQogCQlfX2ZyZWVfcGFnZXModmlydF90b19wYWdlKGFkZHIp LCBvcmRlcik7DQogfQ0KZGlmZiAtdSAtciBsaW51eC1vcmlnL21tL3NsYWIu YyBsaW51eC9tbS9zbGFiLmMNCi0tLSBsaW51eC1vcmlnL21tL3NsYWIuYwlT YXQgT2N0ICA2IDE2OjIxOjQ4IDIwMDENCisrKyBsaW51eC9tbS9zbGFiLmMJ U2F0IE9jdCAgNiAxNzowNDozNyAyMDAxDQpAQCAtNzMsNiArNzMsNyBAQA0K ICNpbmNsdWRlCTxsaW51eC9pbnRlcnJ1cHQuaD4NCiAjaW5jbHVkZQk8bGlu dXgvaW5pdC5oPg0KICNpbmNsdWRlCTxsaW51eC9jb21waWxlci5oPg0KKyNp bmNsdWRlCTxsaW51eC92bWFsbG9jLmg+DQogI2luY2x1ZGUJPGFzbS91YWNj ZXNzLmg+DQogDQogLyoNCkBAIC0xNTM2LDEwICsxNTM3LDE0IEBADQogCWNh Y2hlX3NpemVzX3QgKmNzaXplcCA9IGNhY2hlX3NpemVzOw0KIA0KIAlmb3Ig KDsgY3NpemVwLT5jc19zaXplOyBjc2l6ZXArKykgew0KKwkJdm9pZCAqcDsN CiAJCWlmIChzaXplID4gY3NpemVwLT5jc19zaXplKQ0KIAkJCWNvbnRpbnVl Ow0KLQkJcmV0dXJuIF9fa21lbV9jYWNoZV9hbGxvYyhmbGFncyAmIEdGUF9E TUEgPw0KLQkJCSBjc2l6ZXAtPmNzX2RtYWNhY2hlcCA6IGNzaXplcC0+Y3Nf Y2FjaGVwLCBmbGFncyk7DQorCQlpZiAoKHAgPSBfX2ttZW1fY2FjaGVfYWxs b2MoZmxhZ3MgJiBHRlBfRE1BID8NCisJCQkgY3NpemVwLT5jc19kbWFjYWNo ZXAgOiBjc2l6ZXAtPmNzX2NhY2hlcCwgZmxhZ3MgJiB+X19HRlBfVk1BTExP QykpKQ0KKwkJCQlyZXR1cm4gcDsNCisJCWlmIChmbGFncyAmIF9fR0ZQX1ZN QUxMT0MpIHJldHVybiBfX3ZtYWxsb2Moc2l6ZSwgZmxhZ3MsIFBBR0VfS0VS TkVMKTsNCisJCXJldHVybiBOVUxMOw0KIAl9DQogCXJldHVybiBOVUxMOw0K IH0NCkBAIC0xNTgwLDYgKzE1ODUsMTAgQEANCiANCiAJaWYgKCFvYmpwKQ0K IAkJcmV0dXJuOw0KKwlpZiAoKHVuc2lnbmVkIGxvbmcpb2JqcCA+PSBWTUFM TE9DX1NUQVJUICYmICh1bnNpZ25lZCBsb25nKW9iaiA8IFZNQUxMT0NfRU5E KSB7DQorCQl2ZnJlZShvYmpwKTsNCisJCXJldHVybjsNCisJfQ0KIAlsb2Nh bF9pcnFfc2F2ZShmbGFncyk7DQogCUNIRUNLX1BBR0UodmlydF90b19wYWdl KG9ianApKTsNCiAJYyA9IEdFVF9QQUdFX0NBQ0hFKHZpcnRfdG9fcGFnZShv YmpwKSk7DQo= --1908636959-1328101436-1002382286=:32345-- From owner-linux-xfs@oss.sgi.com Sat Oct 6 17:33:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f970X1Z01463 for linux-xfs-outgoing; Sat, 6 Oct 2001 17:33:01 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f970WvD01440 for ; Sat, 6 Oct 2001 17:32:58 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 50A0AC00B62 for ; Sun, 7 Oct 2001 08:32:52 +0800 (PHT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 9D1FAC00B60 for ; Sun, 7 Oct 2001 08:32:50 +0800 (PHT) Date: Sun, 7 Oct 2001 08:32:50 +0800 (PHT) From: Federico Sevilla III To: Linux XFS Mailing List Subject: Re: kernel panic with preemtive and XFS kernelpatch In-Reply-To: <3BBFC654.84FB965B@online.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 6 Oct 2001 at 23:04, Knut J Bjuland wrote: > When I rebot with booth patach eanble compiled with GCC 2.96-RH-96. I > found this kernel bug. I am send along a jgp file off kerneldump. I'm neither kernel nor XFS guru, but I'm just wondering: is this the first time you're using this compiler with an XFS-enabled kernel? Because if it is (meaning you have zero experience that gcc-2.96 and your XFS-enabled kernel work fine together) then I recommend you use some other gcc. There is a FAQ entry you'll probably be interested in: --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Sat Oct 6 17:39:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f970dxZ01732 for linux-xfs-outgoing; Sat, 6 Oct 2001 17:39:59 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f970dsD01708 for ; Sat, 6 Oct 2001 17:39:54 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id CA2CEC00B62 for ; Sun, 7 Oct 2001 08:39:51 +0800 (PHT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 55579C00B60 for ; Sun, 7 Oct 2001 08:39:50 +0800 (PHT) Date: Sun, 7 Oct 2001 08:39:50 +0800 (PHT) From: Federico Sevilla III To: Linux XFS Mailing List Subject: Re: We have a mail loop! In-Reply-To: <200110062048.f96KmSN25164@oss.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 6 Oct 2001 at 15:32, Russell Cattelan wrote: > Hard to tell exactly what is going on. Like I said, it looks like the system of a certain is to blame. For emphasis, a much more condensed snippet of Received headers from a randomly selected message in the list will show where the loop occurs: Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96Nw8D32454 for ; Sat, 6 Oct 2001 16:58:08 -0700 Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sun, 7 Oct 2001 10:00:27 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10072001-100012-233.MMD@cymax.com.au; Sun, 7 Oct 2001 10:00:12 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sun Oct 7 09:53:37 2001) X-From_: owner-linux-xfs@oss.sgi.com Sun Oct 7 01:31:34 2001 Delivered-To: cymax@smartchat.net.au Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by entoo.connect.com.au (Postfix) with ESMTP id CBCB9DE263 for ; Sun, 7 Oct 2001 01:31:33 +1000 (EST) Who are we supposed to contact for such "emergencies" (where IMHO we should kick out the erring user with a decent message telling him/her to fix his/her mailbox before re-subscribing)? Is a proper venue for such grievances? I know I'm "clogging up the system" with more mail by sending to it (thus it will loop and loop and loop and ......). But it looks like this person's box isn't that fast so the flood is ... painful but bearable for now. It's just that while I know which developer to get in touch with, I don't know who the list administrator is. --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Sat Oct 6 18:13:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f971DB402490 for linux-xfs-outgoing; Sat, 6 Oct 2001 18:13:11 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f971D9D02468 for ; Sat, 6 Oct 2001 18:13:09 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f971D3L13527 for ; Sat, 6 Oct 2001 18:13:04 -0700 Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id SAA01876; Sat, 6 Oct 2001 18:12:32 -0700 (PDT) Message-ID: <3BBFAB37.DBAB0EC@sgi.com> Date: Sat, 06 Oct 2001 20:09:11 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: Federico Sevilla III CC: Linux XFS Mailing List Subject: Re: We have a mail loop! References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Federico Sevilla III wrote: > Who are we supposed to contact for such "emergencies" (where IMHO we > should kick out the erring user with a decent message telling him/her to > fix his/her mailbox before re-subscribing)? Is > a proper venue for such grievances? It's been done, as of this morning (US)... I still need to send the "decent message." :) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Sat Oct 6 18:24:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f971OJ502827 for linux-xfs-outgoing; Sat, 6 Oct 2001 18:24:19 -0700 Received: from netbank.com.br (IDENT:postfix@garrincha.netbank.com.br [200.203.199.88]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f971OED02804 for ; Sat, 6 Oct 2001 18:24:15 -0700 Received: from 1-212.ctame701-1.telepar.net.br (1-212.ctame701-1.telepar.net.br [200.181.137.212]) by netbank.com.br (Postfix) with ESMTP id D3DBC46810; Sat, 6 Oct 2001 22:23:13 -0300 (BRST) Received: (from localhost user: 'riel', uid#500) by imladris.surriel.com with ESMTP id ; Sat, 6 Oct 2001 22:23:58 -0300 Date: Sat, 6 Oct 2001 22:23:56 -0300 (BRST) From: Rik van Riel X-X-Sender: To: Mikulas Patocka Cc: Benjamin Herrenschmidt , , Subject: Re: %u-order allocation failed In-Reply-To: Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 7 Oct 2001, Mikulas Patocka wrote: > You are right. Code that allocates more than page and expects it to be > physicaly contignuous is broken by design. Even rewrite the driver or > allocate memory on boot. It will be very hard to audit all drivers for it. Better buy us all new hardware, then ;) Some devices really do want physically contiguous buffers for DMA... Rik -- DMCA, SSSCA, W3C? Who cares? http://thefreeworld.net/ (volunteers needed) http://www.surriel.com/ http://distro.conectiva.com/ From owner-linux-xfs@oss.sgi.com Sat Oct 6 18:31:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f971Vc503106 for linux-xfs-outgoing; Sat, 6 Oct 2001 18:31:38 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f971VSD03082 for ; Sat, 6 Oct 2001 18:31:30 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 66A90C00B62 for ; Sun, 7 Oct 2001 09:31:15 +0800 (PHT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 5C72EC00B60 for ; Sun, 7 Oct 2001 09:31:12 +0800 (PHT) Date: Sun, 7 Oct 2001 09:31:12 +0800 (PHT) From: Federico Sevilla III To: Linux XFS Mailing List Subject: Re: We have a mail loop! In-Reply-To: <3BBFAB37.DBAB0EC@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 6 Oct 2001 at 20:09, Eric Sandeen wrote: > It's been done, as of this morning (US)... Alright! Thanks Eric. (So now we know who to send our grievances to, hehehe). :) > I still need to send the "decent message." :) Hahaha. Well, technically, I don't think you -need- to send that. The kickout wasn't unprovoked anyway. :( ... glad the deja vu's over. --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Sat Oct 6 19:03:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9723PX03941 for linux-xfs-outgoing; Sat, 6 Oct 2001 19:03:25 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9723ND03919 for ; Sat, 6 Oct 2001 19:03:23 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9723IK11807 for ; Sat, 6 Oct 2001 19:03:18 -0700 Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id TAA08513; Sat, 6 Oct 2001 19:02:44 -0700 (PDT) Message-ID: <3BBFB6FB.1CA43350@sgi.com> Date: Sat, 06 Oct 2001 20:59:23 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: Knut J Bjuland CC: linux-xfs@oss.sgi.com Subject: Re: kernel panic with preemtive and XFS kernelpatch References: <1002400523.2864.10.camel@scare> <3BBFC654.84FB965B@online.no> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Knut J Bjuland wrote: > > When I rebot with booth patach eanble compiled with GCC 2.96-RH-96. > I found this kernel bug. I am send along a jgp file off kerneldump. Hi Knut - The information in the oops is not useful until you run the information through ksymoops on your machine - see linux/scripts/ksymoops/README for information on where to find the ksymoops tool. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Sun Oct 7 02:40:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f979ej010938 for linux-xfs-outgoing; Sun, 7 Oct 2001 02:40:45 -0700 Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f979egD10916 for ; Sun, 7 Oct 2001 02:40:42 -0700 Received: from alan by the-village.bc.nu with local (Exim 3.22 #1) id 15qAQ3-0005Eq-00; Sun, 07 Oct 2001 10:40:23 +0100 Subject: Re: %u-order allocation failed To: mikulas@artax.karlin.mff.cuni.cz (Mikulas Patocka) Date: Sun, 7 Oct 2001 10:40:23 +0100 (BST) Cc: riel@conectiva.com.br (Rik van Riel), kszysiu@main.braxis.co.uk (Krzysztof Rusocki), linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org In-Reply-To: from "Mikulas Patocka" at Oct 06, 2001 04:44:43 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Here goes the fix. (note that I didn't try to compile it so there may be > bugs, but you see the point). It isnt a fix > kmalloc should be fixed too (used badly for example in select.c - and yes > - I have seen real world bugreports for poll randomly failing with > ENOMEM), but it will be hard to audit all drivers that they do not try to > use dma on kmallocated memory. So you run out of blocks of vmalloc address space instead. The same problem still occurs and always will From owner-linux-xfs@oss.sgi.com Sun Oct 7 04:12:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f97BCrf12216 for linux-xfs-outgoing; Sun, 7 Oct 2001 04:12:53 -0700 Received: from tamaris.wanadoo.fr (smtp-rt-12.wanadoo.fr [193.252.19.60]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f97BCnD12193 for ; Sun, 7 Oct 2001 04:12:50 -0700 Received: from mel-rta7.wanadoo.fr (193.252.19.61) by tamaris.wanadoo.fr; 7 Oct 2001 13:12:43 +0200 Received: from [10.0.1.59] (193.253.217.166) by mel-rta7.wanadoo.fr; 7 Oct 2001 13:12:19 +0200 From: Benjamin Herrenschmidt To: Mikulas Patocka Cc: , Subject: Re: %u-order allocation failed Date: Sun, 7 Oct 2001 13:12:02 +0200 Message-Id: <20011007111202.17296@smtp.wanadoo.fr> In-Reply-To: References: X-Mailer: CTM PowerMail 3.0.8 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > >You are right. Code that allocates more than page and expects it to be >physicaly contignuous is broken by design. Even rewrite the driver or >allocate memory on boot. It will be very hard to audit all drivers for it. Well, the problem here is not code. Some piece of hardware just can't scatter gather, or in some case, they can, but the scatter/gather list itself has to be contiguous and can be larger than a page. The fact that kmalloc returns physically contiguous memory is a feature and can't be modified that easily. If you intend to do so, then you need different GFP flags, for example a GFP_CONTIGUOUS flag, and then make sure that drivers allocating DMA memory use that new flag. Ben. From owner-linux-xfs@oss.sgi.com Sun Oct 7 05:28:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f97CSYj18133 for linux-xfs-outgoing; Sun, 7 Oct 2001 05:28:34 -0700 Received: from artax.karlin.mff.cuni.cz (root@artax.karlin.mff.cuni.cz [195.113.31.125]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f97CSSD18110 for ; Sun, 7 Oct 2001 05:28:29 -0700 Received: from localhost (mikulas@localhost) by artax.karlin.mff.cuni.cz (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id OAA02527; Sun, 7 Oct 2001 14:28:17 +0200 Date: Sun, 7 Oct 2001 14:28:17 +0200 (CEST) From: Mikulas Patocka To: Alan Cox cc: Rik van Riel , Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: %u-order allocation failed In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 7 Oct 2001, Alan Cox wrote: > > Here goes the fix. (note that I didn't try to compile it so there may be > > bugs, but you see the point). > > It isnt a fix > > > kmalloc should be fixed too (used badly for example in select.c - and yes > > - I have seen real world bugreports for poll randomly failing with > > ENOMEM), but it will be hard to audit all drivers that they do not try to > > use dma on kmallocated memory. > > So you run out of blocks of vmalloc address space instead. The same problem > still occurs and always will I already said it in mail to Rik: Yes - you can run out of vmalloc space. But you run out of it only when you create too many processes (8192), load too many modules etc. If someone needs to put such heavy load on linux, we can expect that he is not a luser and he knows how to increase size of vmalloc space. But - you run out of high-order pages randomly. You don't have to overflow any resource - just map a file, touch it whole the first time and then periodically touch every second page of it. Or: alloc periodically one anon page and one cache page - read() (without readahead) does exactly that. You can't run out of vmalloc space just by mapping files and touching pages. The probability math is fine - only if you are sure that pages are allocated and freed randomly. But they are not. Mikulas From owner-linux-xfs@oss.sgi.com Sun Oct 7 07:08:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f97E89I19439 for linux-xfs-outgoing; Sun, 7 Oct 2001 07:08:09 -0700 Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f97E84D19417 for ; Sun, 7 Oct 2001 07:08:04 -0700 Received: from alan by the-village.bc.nu with local (Exim 3.22 #1) id 15qEfV-0005td-00; Sun, 07 Oct 2001 15:12:37 +0100 Subject: Re: %u-order allocation failed To: mikulas@artax.karlin.mff.cuni.cz (Mikulas Patocka) Date: Sun, 7 Oct 2001 15:12:37 +0100 (BST) Cc: alan@lxorguk.ukuu.org.uk (Alan Cox), riel@conectiva.com.br (Rik van Riel), kszysiu@main.braxis.co.uk (Krzysztof Rusocki), linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org In-Reply-To: from "Mikulas Patocka" at Oct 07, 2001 02:28:17 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Yes - you can run out of vmalloc space. But you run out of it only when > you create too many processes (8192), load too many modules etc. If > someone needs to put such heavy load on linux, we can expect that he is > not a luser and he knows how to increase size of vmalloc space. Not just that - you get fragmentation of it which leads you back to the same situation as kmalloc except that with the guard pages you fragment the address space more. Alan From owner-linux-xfs@oss.sgi.com Sun Oct 7 08:42:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f97FgcZ20775 for linux-xfs-outgoing; Sun, 7 Oct 2001 08:42:38 -0700 Received: from artax.karlin.mff.cuni.cz (root@artax.karlin.mff.cuni.cz [195.113.31.125]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f97FgYD20752 for ; Sun, 7 Oct 2001 08:42:34 -0700 Received: from localhost (mikulas@localhost) by artax.karlin.mff.cuni.cz (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id RAA10647; Sun, 7 Oct 2001 17:42:10 +0200 Date: Sun, 7 Oct 2001 17:42:10 +0200 (CEST) From: Mikulas Patocka To: Alan Cox cc: Rik van Riel , Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: %u-order allocation failed In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > Yes - you can run out of vmalloc space. But you run out of it only when > > you create too many processes (8192), load too many modules etc. If > > someone needs to put such heavy load on linux, we can expect that he is > > not a luser and he knows how to increase size of vmalloc space. > > Not just that - you get fragmentation of it which leads you back to the > same situation as kmalloc except that with the guard pages you fragment the > address space more. So - for example if you have 500 processes, each process 8k stack (plus one page for vmalloc alignment). Please tell me some alloc/free strategy that fills up and fragments 64M vmalloc space. You can't find it. The difference between memory and vmalloc space is this: you fill up the whole memory with cache => memory fragments. You don't fill up the whole vmalloc space with anything => vmalloc space doesn't fragment. Mikulas From owner-linux-xfs@oss.sgi.com Sun Oct 7 11:41:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f97IfK024042 for linux-xfs-outgoing; Sun, 7 Oct 2001 11:41:20 -0700 Received: from flinx.biederman.org (ebiederm.dsl.xmission.com [166.70.28.69]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f97IfED24019 for ; Sun, 7 Oct 2001 11:41:14 -0700 Received: from frodo.biederman.org (IDENT:root@frodo [10.0.0.2]) by flinx.biederman.org (8.9.3/8.9.3) with ESMTP id NAA07746; Sun, 7 Oct 2001 13:19:20 -0600 Received: (from eric@localhost) by frodo.biederman.org (8.9.3/8.9.3) id MAA01835; Sun, 7 Oct 2001 12:30:20 -0600 To: Alex Bligh - linux-kernel Cc: Mikulas Patocka , Rik van Riel , Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org, Alex Bligh - linux-kernel Subject: Re: %u-order allocation failed References: <482450248.1002414411@[195.224.237.69]> From: ebiederman@uswest.net (Eric W. Biederman) Date: 07 Oct 2001 12:30:20 -0600 In-Reply-To: <482450248.1002414411@[195.224.237.69]> Message-ID: Lines: 60 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Alex Bligh - linux-kernel writes: > Mikulas, > > > It uses vmalloc only when __GFP_VMALLOC flag is given - and so it is > > expected to not use __GFP_VMALLOC flag in IRQ. > > Ah OK. If your point is that people use GFP_ATOMIC when it's > not needed, and demand physically contiguous memory when only > virtually contiguous memory is needed, in several places in > the kernel, then you are correct. [I am not convinced that > vmalloc() is the best way to fix it though.] > > Most of the order>0 users of __get_free_pages() don't > 'need' to do that. For instance I was convinced that networking > code needed this for larger than 4k packets (pre-fragmentation > or post-prefragmentation) until someone pointed out that > the kiovec stuff was there, waiting to be used, if someone > made the code changes. But the code changes are non-trivial. The zero copy stuff introduced in 2.4.4 allows for skb fragments. I haven't seen any of the network drivers using it on their receive path but it should be possible. > Note also that something (not sure what) has made fragmentation > increasingly prevalent over the years since the buddy allocator > was originally put in. Actually it seems to be situations like the stack now being two pages > (see my earlier patch for measuring > fragmentation). There is currently /no/ intelligence in there > to defragment stuff, and the 'light touch' patches (ideas I had > and posted here) don't appear to work. If we want __get_free_pages > to allocate order>0 this is possible to do reliably if we > have some intelligent form of page out which attempts > to defragment as it runs, or else run a defragmenter. It's also possible > to do allocate order>0 GFP_ATOMIC far more reliably than at > present if we had a target for defragmentation under normal > operation, just like we retain a target for pages reserved > for atomic allocation. > > The very original buddy code (circa 94/95 which I wrote) maintained > that there should be (from memory) at least one entry on a high > order list (I think it was the 64k list), which gave you a few > guaranteed 8k allocations (which was I was interested in). It's > trivial to patch this into __get_free_pages though I haven't > tried this (i.e. rather than just look at total free pages, > look at the existance of a page on either the order=4, 5, 6... > queues). Note you will use memory less efficiently if you do > this. In times of cheaper memory costs, it might be worth > testing this approach again. > > -- > Alex Bligh > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ From owner-linux-xfs@oss.sgi.com Sun Oct 7 11:43:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f97IhcB24193 for linux-xfs-outgoing; Sun, 7 Oct 2001 11:43:38 -0700 Received: from flinx.biederman.org (ebiederm.dsl.xmission.com [166.70.28.69]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f97IhYD24170 for ; Sun, 7 Oct 2001 11:43:34 -0700 Received: from frodo.biederman.org (IDENT:root@frodo [10.0.0.2]) by flinx.biederman.org (8.9.3/8.9.3) with ESMTP id NAA07752; Sun, 7 Oct 2001 13:21:54 -0600 Received: (from eric@localhost) by frodo.biederman.org (8.9.3/8.9.3) id MAA01839; Sun, 7 Oct 2001 12:32:55 -0600 To: Alex Bligh - linux-kernel Cc: Mikulas Patocka , Rik van Riel , Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org, Alex Bligh - linux-kernel Subject: Re: %u-order allocation failed References: <482450248.1002414411@[195.224.237.69]> From: ebiederman@uswest.net (Eric W. Biederman) In-Reply-To: <482450248.1002414411@[195.224.237.69]> User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.5 Date: 07 Oct 2001 12:32:55 -0600 Message-ID: Lines: 34 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Alex Bligh - linux-kernel writes: > Mikulas, > > > It uses vmalloc only when __GFP_VMALLOC flag is given - and so it is > > expected to not use __GFP_VMALLOC flag in IRQ. > > Ah OK. If your point is that people use GFP_ATOMIC when it's > not needed, and demand physically contiguous memory when only > virtually contiguous memory is needed, in several places in > the kernel, then you are correct. [I am not convinced that > vmalloc() is the best way to fix it though.] > > Most of the order>0 users of __get_free_pages() don't > 'need' to do that. For instance I was convinced that networking > code needed this for larger than 4k packets (pre-fragmentation > or post-prefragmentation) until someone pointed out that > the kiovec stuff was there, waiting to be used, if someone > made the code changes. But the code changes are non-trivial. The zero copy stuff introduced in 2.4.4 allows for skb fragments. I haven't seen any of the network drivers using it on their receive path but it should be possible. > Note also that something (not sure what) has made fragmentation > increasingly prevalent over the years since the buddy allocator > was originally put in. Actually it seems to be situations like the stack now being two contiguous pages instead of one, where the demand for contiguous memory has increased instead of the amount of fragmentation having increased. Eric From owner-linux-xfs@oss.sgi.com Sun Oct 7 13:43:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f97Khts26640 for linux-xfs-outgoing; Sun, 7 Oct 2001 13:43:55 -0700 Received: from Elf.ucw.cz (root@[194.213.32.141]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f97KhmD26617 for ; Sun, 7 Oct 2001 13:43:49 -0700 Received: from bug.ucw.cz (root@bug.ucw.cz [10.0.0.3]) by Elf.ucw.cz (8.8.8/8.8.5) with ESMTP id VAA12351; Sun, 7 Oct 2001 21:50:02 +0200 Received: (from pavel@localhost) by bug.ucw.cz (8.9.3/8.8.5) id JAA01975; Sun, 7 Oct 2001 09:35:40 +0200 Message-ID: <20011007093539.C454@bug.ucw.cz> Date: Sun, 7 Oct 2001 09:35:39 +0200 From: Pavel Machek To: Mikulas Patocka , Rik van Riel Cc: Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: %u-order allocation failed References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93i In-Reply-To: ; from Mikulas Patocka on Sat, Oct 06, 2001 at 07:48:52PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! > > So what are you going to do when your 64MB of vmalloc space > > runs out ? > > Make larger vmalloc space :-) Virtual memory costs very little. > Besides 64M / 8k = 8192 - so it runs out at 8192 processes. Hard to do of machine with 1GB ram... There, virtual memory costs *very* much. Pavel -- I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org From owner-linux-xfs@oss.sgi.com Sun Oct 7 14:57:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f97LvRM28078 for linux-xfs-outgoing; Sun, 7 Oct 2001 14:57:27 -0700 Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f97LvOD28055 for ; Sun, 7 Oct 2001 14:57:24 -0700 Received: from alan by the-village.bc.nu with local (Exim 3.22 #1) id 15qLzV-00071D-00; Sun, 07 Oct 2001 23:01:45 +0100 Subject: Re: %u-order allocation failed To: mikulas@artax.karlin.mff.cuni.cz (Mikulas Patocka) Date: Sun, 7 Oct 2001 23:01:45 +0100 (BST) Cc: alan@lxorguk.ukuu.org.uk (Alan Cox), riel@conectiva.com.br (Rik van Riel), kszysiu@main.braxis.co.uk (Krzysztof Rusocki), linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org In-Reply-To: from "Mikulas Patocka" at Oct 07, 2001 05:42:10 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > The difference between memory and vmalloc space is this: you fill up the > whole memory with cache => memory fragments. You don't fill up the whole > vmalloc space with anything => vmalloc space doesn't fragment. vmalloc space fragments. You fragment address space rather than pages thats all. Same problem From owner-linux-xfs@oss.sgi.com Sun Oct 7 16:46:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f97NkjL30148 for linux-xfs-outgoing; Sun, 7 Oct 2001 16:46:45 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f97NkcD30125 for ; Sun, 7 Oct 2001 16:46:38 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id QAA01146 for ; Sun, 7 Oct 2001 16:45:37 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) 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 JAA17223; Mon, 8 Oct 2001 09:45:06 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA15664; Mon, 8 Oct 2001 10:45:05 +1100 (AEDT) Date: Mon, 8 Oct 2001 10:45:04 +1100 From: Nathan Scott To: Vivek Malik Cc: linux-xfs@oss.sgi.com Subject: Re: usr quota setup Message-ID: <20011008104504.U472533@wobbly.melbourne.sgi.com> References: <200110062048.f96KmSx25115@oss.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200110062048.f96KmSx25115@oss.sgi.com>; from csu98164@cse.iitd.ernet.in on Sun, Oct 07, 2001 at 01:18:23AM +0530 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Sun, Oct 07, 2001 at 01:18:23AM +0530, Vivek Malik wrote: > Hi, > > I am using current development tree version of xfs (updated using cvs). > All the file systems is my Pentium III computer are having xfs filesystem. > I have mounted a partition /nfs as "exec,nodev,nosuid,rw,usrquota 1 2" Is this filesystem of type "xfs" or "nfs"? If it is of type NFS, then you will need to build your quota tools with the "configure --enable-rpcsetquota=yes" option in order to allow remote quota setting for NFS. > > The kernel is having quota support. > "repquota /nfs" reports quota correctly. > I am having problems in defining quota consraints. > I tried using edquota but couldnt succeed. Can you give more details here? Do you see an error message or is the problem that after "edquota"/"setquota" running the "repquota" command doesn't report the limits? If it's the second case, then the problem is likely that the user doesn't have any inodes/blocks allocated, in which case repquota will skip this user even if he has limits assigned, by default. To check if this is the case, touch a file as the user, and then run repquota again ... "repquota -v" might also provide this information, even if no blocks are allocated for a user - I can't remember just off the top of my head. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Oct 7 18:14:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f981Etw31904 for linux-xfs-outgoing; Sun, 7 Oct 2001 18:14:55 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f981ElD31880 for ; Sun, 7 Oct 2001 18:14:48 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with SMTP id f981EfK21749 for ; Sun, 7 Oct 2001 18:14:42 -0700 Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA17696; Mon, 8 Oct 2001 11:13:24 +1000 From: ivanr@sgi.com Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id LAA74932; Mon, 8 Oct 2001 11:13:20 +1000 (EST) X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs Date: Mon, 8 Oct 2001 11:13:19 +1000 X-X-Sender: ivanr@omen.melbourne.sgi.com To: Mike Sowka cc: ringram@uwyo.edu, Subject: Re: WAS: Cluster XFS install without CD... MY APOLOGIES In-Reply-To: <3BBF372A.2030005@doe.carleton.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 6 Oct 2001, Mike Sowka wrote: > #1) How is it that xfsdump is able to dump / while it's mounted? And how > "industrial-strength" is that? xfsdump only works on mounted filesystems. As you suggest, xfsdump might miss files that are created during a dump, or report a warning if a file is removed during a dump. When you ask about "industrial strength", this depends on what your goals and expectations are. xfsdump is not really designed as a snapshotting tool. If you want that, then just umount your filesystem and do something like 'dd if=/dev/sda of=/dev/tape'. xfsdump is designed tp be run regularly, giving the guarantee that if a file was missed on one day because it was created while the dump was being performed, then that file would be included in the next day's dump. If this isn't sufficient, then you should probably investigate some sort of hardware raid mirroring configuration (which has its own drawbacks of course). (I'm sure I've written this several times before ... Is it FAQ worthy yet, Seth?) > #3) Here is my "plan" for the cluster: > - after installing the "golden-node" I plan on dumping all of its > partitions /boot and / and storing the dumps on our head node > - in order to clone: using etherboot (if I can get it running) I run a > system off of NFS on my head node and xfs restore the partitions onto > the rest of the nodes (linux xfs doesn't support simultaneous > xfsrestores yet does it?) Not sure what you mean by "simultaneous xfsrestores". But if you mean several client machines, all running their own xfsrestore off a single dump-file on an NFS server, then it should work. What isn't supported is a single xfsrestore, restoring from multiple dump-files or multiple tapes simultaneously. This is simply a performance issue, xfsrestore is fully functional otherwise. Ivan -- Ivan Rayner ivanr@sgi.com From owner-linux-xfs@oss.sgi.com Sun Oct 7 18:24:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f981O2632166 for linux-xfs-outgoing; Sun, 7 Oct 2001 18:24:02 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f981NuD32141 for ; Sun, 7 Oct 2001 18:23:56 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id SAA00428 for ; Sun, 7 Oct 2001 18:23:55 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) 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 LAA17752; Mon, 8 Oct 2001 11:22:24 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA05115; Mon, 8 Oct 2001 12:22:02 +1100 (AEDT) Date: Mon, 8 Oct 2001 12:22:02 +1100 From: Nathan Scott To: monkeyiq Cc: Andreas Gruenbacher , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: ENOATTR and other error enums Message-ID: <20011008122201.W472533@wobbly.melbourne.sgi.com> References: <200110060624.f966OeV30354@monkeyiq.dnsalias.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200110060624.f966OeV30354@monkeyiq.dnsalias.org>; from monkeyiq@users.sourceforge.net on Sat, Oct 06, 2001 at 04:24:40PM +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi there, On Sat, Oct 06, 2001 at 04:24:40PM +1000, monkeyiq wrote: > Hi, > Anyone know where these are defined in Linux? I dont seem > to be able to find them, even with find/grep in /usr/include. ENOATTR is not a blessed errno in Linux. In XFS we have simply defined it to be the same as ENODATA for the time being. The ext2 extended attributes project define it to be EDOM, also as a stop-gap solution I imagine. A similar problem exists with ENOTSUP (defined by POSIX 1003.1b?) - this is only supported via linux/asm-parisc/errno.h as a real errno, among all the architectures. Both the XFS and ext2 extended attributes implementations define this errno to be EOPNOTSUPP as an interim solution. Ah, wait - from a quick test, glibc does seem to do exactly this also, so this one is not a problem (except perhaps on the parisc port? -- hmm, that could actually be a bug on parisc). On a related topic, but not specific to extended attributes - for XFS in general, we needed one other errno - EFSCORRUPTED. This is used when XFS goes into forced shutdown mode for a filesystem that has been detected as on-disk corrupt, to stop making the situation any worse (user must umount/xfs_repair). We couldn't find any pre- existing Linux errno vaguely similar to this one, so it was defined to "990" until a real solution could be found. Obviously, these are not the correct long-term solutions ... they need to become real Linux errno's, I think, and ENOTSUP could be defined to EOPNOTSUPP? - EWOULDBLOCK, EDEADLOCK seem to do this. I'm not sure how to reach that point though (CC'ing linux-kernel for any advice) - for reference, in IRIX these errnos are defined as follows: ENOATTR = Attribute not found EFSCORRUPTED = Filesystem is corrupted > Also, is there a function to get a string rep of the error > that occured in the attr code? Someday it should become a part of asm-XXXXX/errno.h (errno's are architecture specific) and the libc strerror(3) routine should be able to provide a meaningful string. But currently that does not happen. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Oct 7 18:28:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f981S9832357 for linux-xfs-outgoing; Sun, 7 Oct 2001 18:28:09 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f981S1D32320 for ; Sun, 7 Oct 2001 18:28:01 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id SAA14702 for ; Sun, 7 Oct 2001 18:27:54 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) 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 LAA17765; Mon, 8 Oct 2001 11:25:56 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA83280; Mon, 8 Oct 2001 12:25:56 +1100 (AEDT) Date: Mon, 8 Oct 2001 12:25:56 +1100 From: Nathan Scott To: ivanr@sgi.com Cc: Mike Sowka , ringram@uwyo.edu, linux-xfs@oss.sgi.com Subject: Re: WAS: Cluster XFS install without CD... MY APOLOGIES Message-ID: <20011008122555.X472533@wobbly.melbourne.sgi.com> References: <3BBF372A.2030005@doe.carleton.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ivanr@sgi.com on Mon, Oct 08, 2001 at 11:13:19AM +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Oct 08, 2001 at 11:13:19AM +1000, ivanr@sgi.com wrote: > On Sat, 6 Oct 2001, Mike Sowka wrote: > > > #1) How is it that xfsdump is able to dump / while it's mounted? And how > > "industrial-strength" is that? > > xfsdump only works on mounted filesystems. As you suggest, xfsdump might > miss files that are created during a dump, or report a warning if a file > is removed during a dump. When you ask about "industrial strength", this > depends on what your goals and expectations are. > > xfsdump is not really designed as a snapshotting tool. If you want that, > then just umount your filesystem and do something like 'dd if=/dev/sda > of=/dev/tape'. Or use the LVM snapshot feature, with Steve's xfs_freeze(8) tool. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Oct 7 18:37:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f981b8M32621 for linux-xfs-outgoing; Sun, 7 Oct 2001 18:37:08 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f981b3D32595 for ; Sun, 7 Oct 2001 18:37:03 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f981auL14753 for ; Sun, 7 Oct 2001 18:36:57 -0700 Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA14803; Mon, 8 Oct 2001 11:35:38 +1000 (AEST) Date: Mon, 8 Oct 2001 11:35:37 +1000 From: Timothy Shimmin To: Russel Ingram Cc: Mike Sowka , linux-xfs@oss.sgi.com Subject: Re: WAS: Cluster XFS install without CD... MY APOLOGIES Message-ID: <20011008113536.V1372@boing.melbourne.sgi.com> References: <3BBE360A.A2C909B2@uwyo.edu> <3BBF372A.2030005@doe.carleton.ca> <20011006122736.A6572@roujin.gargoylecc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <20011006122736.A6572@roujin.gargoylecc.com>; from ringram@gargoylecc.com on Sat, Oct 06, 2001 at 12:27:36PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Mike and Russ, Just some comments re dump/restore... On Sat, Oct 06, 2001 at 12:27:36PM -0600, Russel Ingram wrote: > On Sat, Oct 06, 2001 at 12:54:02PM -0400, Mike Sowka wrote: > > Russ Ingram wrote: > > > > > Hello Russ, > > I was hoping to tap into your vast knowledge on XFS... :) I've looked at > > www.partimage.com and it seems they don't support the bootdisk/rootdisk > > method (no CD drives on my cluster nodes) on the latest version... I > > like the principle of KISS (keep it simple stupid), and using partition > > image when I've got xfsdump seems a bit redundant :). > > I have a question or two about xfsdump, any sugestion are MUCH appreciated: > > #1) How is it that xfsdump is able to dump / while it's mounted? And how > > "industrial-strength" is that? > > I'm not exactly sure what you're asking here. I don't know the technicalities > of how it does it but if you're just asking if it can, yes, it can. If you > want to know how, someone else will have to step in and answer that. > Yes it only dumps a mounted file system. It does mean that any files which are changing while the dump is in progress or just prior to the dump running, may not include its latest changes. > > #2) Can you elaborate a bit on your method of piping xfsdump to > > xfsrestore :)? > > The most basic form of xfsdump and its corresponding xfsrestore can be run > back to back through a pipe to make a copy of a filesystem. Like this: > > xfsdump / - | xfsrestore - /mnt/ > > The above command says run xfsdump on the root filesystem, send the output > to stdout and pipe it to xfsrestore. The dash on the xfsrestore command > says to read stdin as the dump input and /mnt/ is where it is to write to. > > I noticed that when I ran it on my / filesytem it didn't do something right > on the /dev/ dir If you know what exactly the problem is then we'd be very eager to fix it. ...ok just saw Ivan's reply to this email, so no need to say anymore...:) but want to know if there is still a problem with restoring on /dev dir. --Tim From owner-linux-xfs@oss.sgi.com Sun Oct 7 18:53:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f981r0A00542 for linux-xfs-outgoing; Sun, 7 Oct 2001 18:53:00 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f981quD00520 for ; Sun, 7 Oct 2001 18:52:56 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA15550 for ; Sun, 7 Oct 2001 18:52:48 -0700 (PDT) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA14876; Mon, 8 Oct 2001 11:51:29 +1000 (AEST) Date: Mon, 8 Oct 2001 11:51:28 +1000 From: Timothy Shimmin To: laurent ribeyre Cc: linux-xfs@oss.sgi.com Subject: Re: Xfsdump doesnt work Message-ID: <20011008115127.W1372@boing.melbourne.sgi.com> References: <3BBC2B94.3030503@biendecider.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <3BBC2B94.3030503@biendecider.com>; from laurent.ribeyre@biendecider.com on Thu, Oct 04, 2001 at 11:27:48AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Laurent, On Thu, Oct 04, 2001 at 11:27:48AM +0200, laurent ribeyre wrote: > Hello SGI.com > > I hope that you will be able to help me. > I join this attachment with this mail. > I dont undersand why xfsdump doesnt work > is a syntax error? bad install? > my computer has xfs filesystem everywhere (/, /usr......) > the version of xfs is 1.0.9 > the error is segmentation fault > > thank a lot for you help > > laurent ribeyre (im from france, sorry for my bad english) We need a bit more information. As Nate Straz suggested, a core file would be useful. There are some other things to do. 1) Run xfsdump with the option -v5 to give us more verbose output 2) Use gdb with the core file and give us a back trace (bt) i.e. $ gdb xfsdump core (gdb) bt BTW, the output from (1) and/or (2) can just be sent as ASCII text - don't really need jpeg file :) Ciao, Tim. From owner-linux-xfs@oss.sgi.com Sun Oct 7 19:21:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f982LHM01207 for linux-xfs-outgoing; Sun, 7 Oct 2001 19:21:17 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f982LBD01185 for ; Sun, 7 Oct 2001 19:21:11 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id TAA04325 for ; Sun, 7 Oct 2001 19:20:09 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) 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 MAA18008; Mon, 8 Oct 2001 12:19:41 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA01233; Mon, 8 Oct 2001 13:19:19 +1100 (AEDT) Date: Mon, 8 Oct 2001 13:19:18 +1100 From: Nathan Scott To: Alexander Viro , Jan Kara , Alan Cox Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: Quotactl change Message-ID: <20011008131918.Y472533@wobbly.melbourne.sgi.com> References: <20011006150731.C30450@atrey.karlin.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from viro@math.psu.edu on Sat, Oct 06, 2001 at 02:25:06PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Al, On Sat, Oct 06, 2001 at 02:25:06PM -0400, Alexander Viro wrote: > On Sat, Oct 06, 2001 at 03:07:32PM +0200, Jan Kara wrote: > > I'm sending you a change for quotactl interface which Nathan > > Scott proposed for XFS. Actually it's his patch with just a few > > changes from me. > > It allows quotactl() to be overidden by a filesystem and so XFS > > can do it's tricks with quota without patching dquot.c. Sideeffect > > of this change is a cleanup in quotactl() interface :). > > [snip] > > Umm... So you've just given to each fs driver a syscall with > completely unspecified arguments? I _really_ doubt that it's a good > idea, especially since each instance will have to copy structures > to/from userland. > > Please, put switch by the first argument and copy_{to,from}_user() > into the syscall itself. Yes, it means more methods, but it helps to avoid > large PITA couple of years down the road. > OK, if that's for the best, I'll rework it. I thought it would be cleaner to do it that other way, because it meant not having any knowledge of the filesystem-specific quota data structures and operations up at this higher (vfs) level. Since ioctl is available as a generic copy in/out facility already, I'm not sure why any filesystem would abuse quotactl in this way, but perhaps that's just human nature. ;-) The only other reason that I was thinking of - I expect that Veritas' VxFS will also wish to provide its own quota subsystem, as they seem to do for other operating systems. Since (and I may be wrong here) the intention there is to make VxFS a commercial filesystem for Linux, it would also help those folk out if the point of doing the user data copying was within the filesystem. So, I was trying to do the right thing by everyone in making it generic - your suggestion will work just fine for our needs in XFS though. Thanks for the feedback - new patch later. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Oct 7 19:22:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f982Mjl01358 for linux-xfs-outgoing; Sun, 7 Oct 2001 19:22:45 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f982M7D01291 for ; Sun, 7 Oct 2001 19:22:07 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f982M1K22538 for ; Sun, 7 Oct 2001 19:22:01 -0700 Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA14915; Mon, 8 Oct 2001 12:20:42 +1000 (AEST) Date: Mon, 8 Oct 2001 12:20:42 +1000 From: Timothy Shimmin To: Russel Ingram Cc: Mike Sowka , linux-xfs@oss.sgi.com Subject: Re: WAS: Cluster XFS install without CD... MY APOLOGIES Message-ID: <20011008122041.X1372@boing.melbourne.sgi.com> References: <3BBE360A.A2C909B2@uwyo.edu> <3BBF372A.2030005@doe.carleton.ca> <20011006122736.A6572@roujin.gargoylecc.com> <20011008113536.V1372@boing.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <20011008113536.V1372@boing.melbourne.sgi.com>; from tes@boing.melbourne.sgi.com on Mon, Oct 08, 2001 at 11:35:37AM +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Russ, On Mon, Oct 08, 2001 at 11:35:37AM +1000, Timothy Shimmin wrote: > > Just some comments re dump/restore... > > > > #2) Can you elaborate a bit on your method of piping xfsdump to > > > xfsrestore :)? > > > > The most basic form of xfsdump and its corresponding xfsrestore can be run > > back to back through a pipe to make a copy of a filesystem. Like this: > > > > xfsdump / - | xfsrestore - /mnt/ > > > > The above command says run xfsdump on the root filesystem, send the output > > to stdout and pipe it to xfsrestore. The dash on the xfsrestore command > > says to read stdin as the dump input and /mnt/ is where it is to write to. > > > > I noticed that when I ran it on my / filesytem it didn't do something right > > on the /dev/ dir > If you know what exactly the problem is then we'd be very eager > to fix it. > Was it a problem with restoring of the correct major and minor device numbers that you had ? Looking at cmd/xfsdump/doc/CHANGES: xfsdump-1.0.11 (12 July 2001) - correctly restore block and character device major numbers On July 12, Steve Lord added some changes to fix the device numbers set with mknod. It appears that the format for dev_t is different on Linux and IRIX. ------------------------------------------------------------------------ 12:13 tes@snort 30> p_modinfo -h 2.4.x-xfs:slinx:98712a mod 2.4.x-xfs:slinx:98712a header ================================== - SM_Location: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs - Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 - 2.4.x-xfs:slinx:98712a 07/12/01 - Files affected: linux/fs/xfs/xfs_types.h 1.51, cmd/xfsdump/common/util.c 1.2, cmd/xfsdump/restore/content.c 1.8, cmd/xfsdump/VERSION 1.10, cmd/xfsdump/doc/CHANGES 1.11, cmd/xfsprogs/include/xfs_types.h 1.3, cmd/xfsprogs/doc/CHANGES 1.22, cmd/xfsprogs/VERSION 1.20 - Author: lord - linux/fs/xfs/xfs_types.h: export dev_t conversion macros to user space, they are needed by xfsdump and xfsrestore. - cmd/xfsdump/common/util.c: convert linux dev_t in stat64 return to irix format used in bulkstat output. - cmd/xfsdump/restore/content.c: convert dump tape format dev_t into linux format dev_t before calling mknod. - cmd/xfsdump/VERSION: Bump minor version number - cmd/xfsdump/doc/CHANGES: Add new version number comment - cmd/xfsprogs/include/xfs_types.h: export dev_t conversion macros to user space, they are needed by xfsdump and xfsrestore. - cmd/xfsprogs/doc/CHANGES: Add new version number comment - cmd/xfsprogs/VERSION: Bump minor version - revised xfs_types.h file 12:16 tes@snort 12> p_rdiff -r1.2,1.3 util.c 137c137 < dstp->bs_rdev = srcp->st_rdev; --- > dstp->bs_rdev = IRIX_MKDEV(major(srcp->st_rdev), minor(srcp->st_rdev)); 12:16 tes@snort 14> p_rdiff -r1.8,1.9 content.c 7552c7552 < ( dev_t )bstatp->bs_rdev ); --- > ( dev_t )IRIX_DEV_TO_KDEVT(bstatp->bs_rdev)); ------------------------------------------------------------------------ If it is some other problem they we'd like to know... Cheers, Tim. From owner-linux-xfs@oss.sgi.com Sun Oct 7 21:51:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f984pHx04266 for linux-xfs-outgoing; Sun, 7 Oct 2001 21:51:17 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f984p8D04243 for ; Sun, 7 Oct 2001 21:51:08 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id VAB23352 for ; Sun, 7 Oct 2001 21:50:57 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id OAA09857; Mon, 8 Oct 2001 14:50:46 +1000 Date: Mon, 8 Oct 2001 14:50:46 +1000 From: Keith Owens Message-Id: <200110080450.OAA09857@sherman.melbourne.sgi.com> Subject: TAKE - Upgrade to 2.4.11-pre5 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Upgrade to 2.4.11-pre5 Date: Sun Oct 7 21:48:31 PDT 2001 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:104083a linux/drivers/usb/ultracam.c - 1.1 linux/drivers/usb/hpusbscsi.h - 1.1 linux/drivers/usb/hpusbscsi.c - 1.1 linux/net/core/dev.c - 1.45 linux/mm/vmscan.c - 1.79 linux/mm/page_alloc.c - 1.58 linux/kernel/sysctl.c - 1.43 linux/kernel/sched.c - 1.42 linux/init/main.c - 1.62 linux/include/net/route.h - 1.12 linux/include/linux/quotaops.h - 1.11 linux/include/linux/quota.h - 1.6 linux/include/linux/pagemap.h - 1.32 linux/include/linux/mount.h - 1.18 linux/include/linux/module.h - 1.25 linux/include/linux/fs.h - 1.124 linux/include/linux/ext2_fs.h - 1.16 linux/include/linux/dcache.h - 1.20 linux/include/asm-sparc64/processor.h - 1.20 linux/include/asm-sparc/processor.h - 1.16 linux/include/asm-ppc/processor.h - 1.29 linux/include/asm-mips/processor.h - 1.18 linux/include/asm-m68k/processor.h - 1.13 linux/include/asm-i386/smp.h - 1.12 linux/include/asm-i386/processor.h - 1.29 linux/include/asm-arm/processor.h - 1.19 linux/include/asm-alpha/semaphore.h - 1.9 linux/include/asm-alpha/processor.h - 1.14 linux/include/asm-alpha/page.h - 1.11 linux/include/asm-alpha/compiler.h - 1.9 linux/fs/ufs/ialloc.c - 1.9 linux/fs/ufs/balloc.c - 1.9 linux/fs/super.c - 1.61 linux/fs/open.c - 1.32 linux/fs/nfsd/vfs.c - 1.39 linux/fs/ext2/inode.c - 1.31 linux/fs/ext2/ialloc.c - 1.18 linux/fs/ext2/balloc.c - 1.14 linux/fs/dquot.c - 1.38 linux/fs/binfmt_elf.c - 1.34 linux/fs/attr.c - 1.11 linux/drivers/usb/uhci.c - 1.48 linux/drivers/usb/audio.c - 1.32 linux/drivers/usb/Makefile - 1.44 linux/drivers/usb/Config.in - 1.47 linux/drivers/scsi/scsi.c - 1.40 linux/drivers/char/Config.in - 1.50 linux/drivers/block/paride/Makefile - 1.7 linux/arch/sparc64/kernel/head.S - 1.12 linux/arch/i386/kernel/setup.c - 1.56 linux/arch/i386/kernel/entry.S - 1.38 linux/README - 1.11 linux/Makefile - 1.130 linux/MAINTAINERS - 1.75 linux/Documentation/Configure.help - 1.105 linux/CREDITS - 1.62 linux/drivers/usb/acm.c - 1.42 linux/arch/mips/dec/wbflush.c - 1.5 linux/include/asm-sh/processor.h - 1.16 linux/fs/udf/ialloc.c - 1.11 linux/fs/udf/balloc.c - 1.9 linux/fs/udf/udfdecl.h - 1.14 linux/include/linux/agp_backend.h - 1.14 linux/drivers/char/agp/agpgart_be.c - 1.26 linux/drivers/char/agp/agp.h - 1.18 linux/Documentation/usb/CREDITS - 1.8 linux/drivers/scsi/scsi_scan.c - 1.18 linux/drivers/usb/usb-uhci.c - 1.30 linux/drivers/usb/ibmcam.c - 1.15 linux/include/asm-ia64/processor.h - 1.14 linux/include/asm-mips64/processor.h - 1.11 linux/Documentation/DocBook/Makefile - 1.19 linux/scripts/kernel-doc - 1.12 linux/Documentation/DocBook/kernel-api.tmpl - 1.12 linux/net/ipv4/netfilter/ipt_mac.c - 1.6 linux/net/ipv4/netfilter/ipt_REJECT.c - 1.12 linux/arch/s390/kernel/entry.S - 1.12 linux/include/asm-s390/processor.h - 1.8 linux/Documentation/DocBook/kernel-hacking.tmpl - 1.6 linux/drivers/usb/microtek.c - 1.11 linux/drivers/mtd/Config.in - 1.7 linux/drivers/media/video/cpia_usb.c - 1.6 linux/drivers/media/video/cpia.c - 1.6 linux/mm/oom_kill.c - 1.8 linux/include/asm-parisc/processor.h - 1.5 linux/arch/parisc/hpux/entry_hpux.S - 1.2 linux/include/asm-s390x/processor.h - 1.4 linux/arch/s390x/kernel/entry.S - 1.7 linux/include/asm-cris/processor.h - 1.6 linux/drivers/scsi/aic7xxx/aic7xxx_linux.c - 1.6 linux/Documentation/DocBook/tulip-user.tmpl - 1.2 linux/drivers/block/paride/bpck6.c - 1.3 linux/drivers/mtd/chips/Makefile - 1.3 linux/include/asm-alpha/rwsem.h - 1.2 linux/drivers/usb/CDCEther.c - 1.4 linux/drivers/usb/usbvideo.h - 1.2 linux/arch/mips/au1000/common/serial.c - 1.2 linux/drivers/mtd/devices/blkmtd.c - 1.2 linux/fs/namespace.c - 1.2 From owner-linux-xfs@oss.sgi.com Sun Oct 7 22:09:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9859ss04747 for linux-xfs-outgoing; Sun, 7 Oct 2001 22:09:54 -0700 Received: from roujin.gargoylecc.com (mail@roujin.gargoylecc.com [65.100.85.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9859nD04725 for ; Sun, 7 Oct 2001 22:09:49 -0700 Received: from ringram by roujin.gargoylecc.com with local (Exim 3.32 #1) id 15qSfa-0002Dj-00; Sun, 07 Oct 2001 23:09:38 -0600 Date: Sun, 7 Oct 2001 23:09:38 -0600 To: Timothy Shimmin , linux-xfs@oss.sgi.com Subject: Re: WAS: Cluster XFS install without CD... MY APOLOGIES Message-ID: <20011007230938.A8528@roujin.gargoylecc.com> References: <3BBE360A.A2C909B2@uwyo.edu> <3BBF372A.2030005@doe.carleton.ca> <20011006122736.A6572@roujin.gargoylecc.com> <20011008113536.V1372@boing.melbourne.sgi.com> <20011008122041.X1372@boing.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011008122041.X1372@boing.melbourne.sgi.com> User-Agent: Mutt/1.3.22i From: Russel Ingram Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Oct 08, 2001 at 12:20:42PM +1000, Timothy Shimmin wrote: > Russ, > > On Mon, Oct 08, 2001 at 11:35:37AM +1000, Timothy Shimmin wrote: > > > > Just some comments re dump/restore... > > > > > > #2) Can you elaborate a bit on your method of piping xfsdump to > > > > xfsrestore :)? > > > > > > The most basic form of xfsdump and its corresponding xfsrestore can be run > > > back to back through a pipe to make a copy of a filesystem. Like this: > > > > > > xfsdump / - | xfsrestore - /mnt/ > > > > > > The above command says run xfsdump on the root filesystem, send the output > > > to stdout and pipe it to xfsrestore. The dash on the xfsrestore command > > > says to read stdin as the dump input and /mnt/ is where it is to write to. > > > > > > I noticed that when I ran it on my / filesytem it didn't do something right > > > on the /dev/ dir > > If you know what exactly the problem is then we'd be very eager > > to fix it. > > > Was it a problem with restoring of the correct major and minor > device numbers that you had ? > > If it is some other problem they we'd like to know... > > Cheers, > Tim. I don't remember what it was exactly. Seems like there were devices missing so, yes, it very well could have been incorrect device numbers. I didn't pay to much attention because once I figured out that it was just /dev that was screwed up I just reapplied the dev rpm. Russ -- Russel H. Ingram Gargoyle Computer Consulting (307)742-1361 or (307)760-1317 www.gargoylecc.com From owner-linux-xfs@oss.sgi.com Sun Oct 7 23:55:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f986tDu06821 for linux-xfs-outgoing; Sun, 7 Oct 2001 23:55:13 -0700 Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f986tAD06799 for ; Sun, 7 Oct 2001 23:55:10 -0700 Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.22 #1) id 15qUIS-0005Cr-00 for linux-xfs@oss.sgi.com; Mon, 08 Oct 2001 08:53:52 +0200 To: linux-xfs@oss.sgi.com Subject: Use CVS version or kernel patch? From: Florian Weimer Date: 08 Oct 2001 08:53:52 +0200 Message-ID: Lines: 10 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm going to set up a new machine with substantially more disk space I used to have before, and I wonder if I should use the XFS CVS version or the kernel patch. (Forgive me if this is in the FAQ, I haven't found it.) -- Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 From owner-linux-xfs@oss.sgi.com Mon Oct 8 00:00:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9870OB07082 for linux-xfs-outgoing; Mon, 8 Oct 2001 00:00:24 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9870LD07059 for ; Mon, 8 Oct 2001 00:00:21 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9870EL23562 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Mon, 8 Oct 2001 00:00:15 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id IAA2559910 for ; Mon, 8 Oct 2001 08:59:45 +0200 (CEST) mail_from (ajag@snort.melbourne.sgi.com) Received: (from ajag@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA77586 for linux-xfs@oss.sgi.com; Mon, 8 Oct 2001 16:58:54 +1000 (EST) Date: Mon, 8 Oct 2001 16:58:54 +1000 (EST) From: Andrew Gildfind Message-Id: <200110080658.QAA77586@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - Improvement request for xfsdump/xfsrestore exit codes Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This fixes catches some user-initiated interruptions that were previously missed, and fixes a coredump on linux. Date: Sun Oct 7 23:55:49 PDT 2001 Workarea: snort.melbourne.sgi.com:/home/ajag/isms/slinx The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:104099a cmd/xfsdump/restore/tree.c - 1.7 cmd/xfsdump/dump/inomap.c - 1.9 - wrap previously missed call to exit() cmd/xfsdump/common/types.h - 1.5 - Add RV_EXISTS cmd/xfsdump/common/mlog.c - 1.6 - update mlog_exit_flush logic, catch some user interruptions that were previously missed cmd/xfsdump/common/main.c - 1.14 - wrap calls to exit() for miniroot/linux From owner-linux-xfs@oss.sgi.com Mon Oct 8 00:08:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9878PB07365 for linux-xfs-outgoing; Mon, 8 Oct 2001 00:08:25 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9878FD07341 for ; Mon, 8 Oct 2001 00:08:15 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id AAA00207 for ; Mon, 8 Oct 2001 00:07:14 -0700 (PDT) mail_from (kaos@melbourne.sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by nodin.corp.sgi.com (8.11.4/8.11.2/nodin-1.0) with ESMTP id f9877DC3801266; Mon, 8 Oct 2001 00:07:13 -0700 (PDT) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id B2D62300095; Mon, 8 Oct 2001 17:07:11 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 0D5609A; Mon, 8 Oct 2001 17:07:10 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Florian Weimer Cc: linux-xfs@oss.sgi.com Subject: Re: Use CVS version or kernel patch? In-reply-to: Your message of "08 Oct 2001 08:53:52 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 08 Oct 2001 17:07:04 +1000 Message-ID: <3127.1002524824@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 08 Oct 2001 08:53:52 +0200, Florian Weimer wrote: >I'm going to set up a new machine with substantially more disk space I >used to have before, and I wonder if I should use the XFS CVS version >or the kernel patch. Are you feeling lucky? The CVS tree is bleeding edge with minimal testing. The kernel patches, particularly the official releases (1.0.1 is current) get much more testing but are against older kernels. From owner-linux-xfs@oss.sgi.com Mon Oct 8 00:10:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f987A6o07521 for linux-xfs-outgoing; Mon, 8 Oct 2001 00:10:06 -0700 Received: from smtp1.xs4all.nl (smtp1.xs4all.nl [194.109.127.131]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f987A0D07488 for ; Mon, 8 Oct 2001 00:10:00 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtp1.xs4all.nl (8.9.3/8.9.3) with ESMTP id JAA12975; Mon, 8 Oct 2001 09:09:58 +0200 (CEST) Message-Id: <4.3.2.7.2.20011008090816.03ebe8c0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 08 Oct 2001 09:08:54 +0200 To: Florian Weimer , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Use CVS version or kernel patch? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 08:53 8-10-2001 +0200, Florian Weimer wrote: >I'm going to set up a new machine with substantially more disk space I >used to have before, and I wonder if I should use the XFS CVS version >or the kernel patch. > >(Forgive me if this is in the FAQ, I haven't found it.) Depends on the hardware. If you have a VIA based system better use the CVS version. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Mon Oct 8 03:37:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98Ab5K11232 for linux-xfs-outgoing; Mon, 8 Oct 2001 03:37:05 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98AZeD11201 for ; Mon, 8 Oct 2001 03:35:40 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id DAA06428 for ; Mon, 8 Oct 2001 03:34:38 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) 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 UAA20044; Mon, 8 Oct 2001 20:34:20 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id UAA09162; Mon, 8 Oct 2001 20:34:19 +1000 (AEDT) Date: Mon, 8 Oct 2001 20:34:18 +1000 From: Nathan Scott To: Alexander Viro Cc: Jan Kara , Alan Cox , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: Quotactl change Message-ID: <20011008203418.A505344@wobbly.melbourne.sgi.com> References: <20011006150731.C30450@atrey.karlin.mff.cuni.cz> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from viro@math.psu.edu on Sat, Oct 06, 2001 at 02:25:06PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hi all, Al - is the attached patch more along the lines of what you were after? Jan - I think this is actually alot closer to what you were talking about when we last discussed this. Can you see any problems from a VFS quota point of view here? I had to make small interface changes to a couple of the dquot.c routines to make this simpler/more uniform in places - could you have cross-check those for me? many thanks. On Sat, Oct 06, 2001 at 02:25:06PM -0400, Alexander Viro wrote: > > > On Sat, 6 Oct 2001, Jan Kara wrote: > > > Hello, > > > > I'm sending you a change for quotactl interface which Nathan Scott proposed > > for XFS. Actually it's his patch with just a few changes from me. > > It allows quotactl() to be overidden by a filesystem and so XFS can do it's > > tricks with quota without patching dquot.c. Sideeffect of this change is a > > cleanup in quotactl() interface :). > > [snip] > > Umm... So you've just given to each fs driver a syscall with > completely unspecified arguments? I _really_ doubt that it's a good > idea, especially since each instance will have to copy structures > to/from userland. > > Please, put switch by the first argument and copy_{to,from}_user() > into the syscall itself. Yes, it means more methods, but it helps to avoid > large PITA couple of years down the road. > -- Nathan --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="quotactl.patch2" diff -Naur linux-2410ac8/fs/Makefile linux-2410ac8-quota/fs/Makefile --- linux-2410ac8/fs/Makefile Mon Oct 8 13:26:59 2001 +++ linux-2410ac8-quota/fs/Makefile Mon Oct 8 19:45:36 2001 @@ -14,12 +14,10 @@ super.o block_dev.o char_dev.o stat.o exec.o pipe.o namei.o \ fcntl.o ioctl.o readdir.o select.o fifo.o locks.o \ dcache.o inode.o attr.o bad_inode.o file.o iobuf.o dnotify.o \ - filesystems.o jbd-kernel.o namespace.o + filesystems.o jbd-kernel.o namespace.o quota.o ifeq ($(CONFIG_QUOTA),y) obj-y += dquot.o -else -obj-y += noquot.o endif subdir-$(CONFIG_PROC_FS) += proc diff -Naur linux-2410ac8/fs/dquot.c linux-2410ac8-quota/fs/dquot.c --- linux-2410ac8/fs/dquot.c Mon Oct 8 13:26:59 2001 +++ linux-2410ac8-quota/fs/dquot.c Mon Oct 8 19:53:03 2001 @@ -46,9 +46,12 @@ * Jan Kara 12/2000 * * New quotafile format - * Alocation units changed to bytes + * Allocation units changed to bytes * Jan Kara, , 2000 * + * Reworked the quotactl interface for filesystem-specific quota + * Nathan Scott and Jan Kara , 2001 + * * (C) Copyright 1994 - 1997 Marco van Wieringen */ @@ -65,6 +68,7 @@ #include #include #include +#include #include #include @@ -73,8 +77,6 @@ #define __DQUOT_NUM_VERSION__ (6*10000+5*100+0) #define __DQUOT_PARANOIA -int nr_dquots, nr_free_dquots; - static const char *quotatypes[] = INITQFNAMES; static const uint quota_magics[] = INITQMAGICS; static const uint quota_versions[] = INITQVERSIONS; @@ -988,10 +990,11 @@ } } -int sync_dquots(kdev_t dev, short type) +int sync_dquots(struct super_block *sb, short type) { struct list_head *head; struct dquot *dquot; + kdev_t dev = sb->s_dev; restart: for (head = inuse_list.next; head != &inuse_list; head = head->next) { @@ -1477,25 +1480,21 @@ * Initialize a dquot-struct with new quota info. This is used by the * system call interface functions. */ -static int set_dqblk(struct super_block *sb, qid_t id, short type, int flags, struct mem_dqblk *dqblk) +static int set_dqblk(struct super_block *sb, short type, qid_t id, struct mem_dqblk *dqblk, int op) { struct dquot *dquot; - int error = -EFAULT; struct mem_dqblk dq_dqblk; - if (copy_from_user(&dq_dqblk, dqblk, sizeof(struct mem_dqblk))) - return error; - - if (sb && (dquot = dqget(sb, id, type)) != NODQUOT) { + if ((dquot = dqget(sb, id, type)) != NODQUOT) { /* We can't block while changing quota structure... */ - if ((flags & SET_QUOTA) || (flags & SET_QLIMIT)) { + if (op == Q_SETQUOTA || op == Q_SETQLIM) { dquot->dq_bhardlimit = dq_dqblk.dqb_bhardlimit; dquot->dq_bsoftlimit = dq_dqblk.dqb_bsoftlimit; dquot->dq_ihardlimit = dq_dqblk.dqb_ihardlimit; dquot->dq_isoftlimit = dq_dqblk.dqb_isoftlimit; } - if ((flags & SET_QUOTA) || (flags & SET_USE)) { + if (op == Q_SETQUOTA || op == Q_SETUSE) { if (dquot->dq_isoftlimit && dquot->dq_curinodes < dquot->dq_isoftlimit && dq_dqblk.dqb_curinodes >= dquot->dq_isoftlimit) @@ -1529,77 +1528,85 @@ return 0; } -static int get_quota(struct super_block *sb, qid_t id, short type, struct mem_dqblk *dqblk) +static int get_dqblk(struct super_block *sb, short type, qid_t id, struct mem_dqblk *dqblk) { struct dquot *dquot; - struct mem_dqblk data; int error = -ESRCH; - if (!sb || !sb_has_quota_enabled(sb, type)) + if (!sb_has_quota_enabled(sb, type)) goto out; dquot = dqget(sb, id, type); if (dquot == NODQUOT) goto out; - memcpy(&data, &dquot->dq_dqb, sizeof(struct mem_dqblk)); /* We copy data to preserve them from changing */ + memcpy(dqblk, &dquot->dq_dqb, sizeof(struct mem_dqblk)); /* We copy data to preserve them from changing */ dqput(dquot); - error = -EFAULT; - if (dqblk && !copy_to_user(dqblk, &data, sizeof(struct mem_dqblk))) - error = 0; + error = 0; out: return error; } -static int get_stats(caddr_t addr) +#ifdef CONFIG_PROC_FS +static int read_stats(char *buffer, char **start, off_t offset, int count, int *eof, void *data) { - int error = -EFAULT; - struct dqstats stats; + int len; dqstats.allocated_dquots = nr_dquots; dqstats.free_dquots = nr_free_dquots; - /* make a copy, in case we page-fault in user space */ - memcpy(&stats, &dqstats, sizeof(struct dqstats)); - if (!copy_to_user(addr, &stats, sizeof(struct dqstats))) - error = 0; - return error; -} + len = sprintf(buffer, "Version %u\n", dqstats.version); + len += sprintf(buffer + len, "%u %u %u %u %u %u %u %u\n", + dqstats.lookups, dqstats.drops, + dqstats.reads, dqstats.writes, + dqstats.cache_hits, dqstats.allocated_dquots, + dqstats.free_dquots, dqstats.syncs); + + if (offset >= len) { + *start = buffer; + *eof = 1; + return 0; + } + *start = buffer + offset; + if ((len -= offset) > count) + return count; + *eof = 1; + + return len; +} +#define quota_proc_init() \ + create_proc_read_entry("fs/quota", 0, 0, read_stats, NULL); +#else +#define quota_proc_init() do { } while (0) +#endif -static int get_info(struct super_block *sb, short type, struct mem_dqinfo *pinfo) +static int get_info(struct super_block *sb, short type, struct mem_dqinfo *kinfo) { - struct mem_dqinfo kinfo; - - if (!sb || !sb_has_quota_enabled(sb, type)) + if (!sb_has_quota_enabled(sb, type)) return -ESRCH; /* Make our own copy so we can guarantee consistent structure */ - memcpy(&kinfo, sb_dqopt(sb)->info+type, sizeof(struct mem_dqinfo)); - kinfo.dqi_flags &= DQF_MASK; - if (copy_to_user(pinfo, &kinfo, sizeof(struct mem_dqinfo))) - return -EFAULT; + memcpy(kinfo, sb_dqopt(sb)->info+type, sizeof(struct mem_dqinfo)); + kinfo->dqi_flags &= DQF_MASK; return 0; } -static int set_info(int op, struct super_block *sb, short type, struct mem_dqinfo *pinfo) +static int set_info(struct super_block *sb, short type, struct mem_dqinfo *pinfo, int op) { struct mem_dqinfo info; struct quota_info *dqopt = sb_dqopt(sb); - if (!sb || !sb_has_quota_enabled(sb, type)) + if (!sb_has_quota_enabled(sb, type)) return -ESRCH; - if (copy_from_user(&info, pinfo, sizeof(struct mem_dqinfo))) - return -EFAULT; - switch (op) { - case ISET_FLAGS: + case Q_SETFLAGS: dqopt->info[type].dqi_flags = (dqopt->info[type].dqi_flags & ~DQF_MASK) | (info.dqi_flags & DQF_MASK); break; - case ISET_GRACE: + case Q_SETGRACE: dqopt->info[type].dqi_bgrace = info.dqi_bgrace; dqopt->info[type].dqi_igrace = info.dqi_igrace; break; - case ISET_ALL: + case Q_SETINFO: info.dqi_flags &= ~DQF_MASK; memcpy(dqopt->info + type, &info, sizeof(struct mem_dqinfo)); break; @@ -1886,6 +1893,7 @@ INIT_LIST_HEAD(dquot_hash + i); dqstats.version = __DQUOT_NUM_VERSION__; printk(KERN_NOTICE "VFS: Diskquotas version %s initialized\n", __DQUOT_VERSION__); + quota_proc_init(); return 0; } __initcall(dquot_init); @@ -1939,9 +1947,6 @@ short cnt; struct quota_info *dqopt = sb_dqopt(sb); - if (!sb) - goto out; - /* We need to serialize quota_off() for device */ down(&dqopt->dqoff_sem); for (cnt = 0; cnt < MAXQUOTAS; cnt++) { @@ -1963,7 +1968,6 @@ fput(filp); } up(&dqopt->dqoff_sem); -out: return 0; } @@ -2044,114 +2048,14 @@ } /* - * This is the system call interface. This communicates with - * the user-level programs. Currently this only supports diskquota - * calls. Maybe we need to add the process quotas etc. in the future, - * but we probably should use rlimits for that. + * Definitions of quota operations accessible through quotactl(2). */ -asmlinkage long sys_quotactl(int cmd, const char *special, qid_t id, __kernel_caddr_t addr) -{ - int cmds = 0, type = 0, flags = 0; - kdev_t dev; - struct super_block *sb = NULL; - int ret = -EINVAL; - - lock_kernel(); - cmds = cmd >> SUBCMDSHIFT; - type = cmd & SUBCMDMASK; - - - if ((uint) type >= MAXQUOTAS || cmds > 0x1100 || cmds < 0x100 || cmds == 0x0300 || - cmds == 0x0400 || cmds == 0x0500 || cmds == 0x1000) - goto out; - - ret = -EPERM; - switch (cmds) { - case Q_SYNC: - case Q_GETSTATS: - case Q_GETINFO: - break; - case Q_GETQUOTA: - if (((type == USRQUOTA && current->euid != id) || - (type == GRPQUOTA && !in_egroup_p(id))) && - !capable(CAP_SYS_ADMIN)) - goto out; - break; - default: - if (!capable(CAP_SYS_ADMIN)) - goto out; - } - - dev = NODEV; - if (special != NULL || (cmds != Q_SYNC && cmds != Q_GETSTATS)) { - mode_t mode; - struct nameidata nd; - - ret = user_path_walk(special, &nd); - if (ret) - goto out; - - dev = nd.dentry->d_inode->i_rdev; - mode = nd.dentry->d_inode->i_mode; - path_release(&nd); - - ret = -ENOTBLK; - if (!S_ISBLK(mode)) - goto out; - ret = -ENODEV; - sb = get_super(dev); - if (!sb) - goto out; - } - - ret = -EINVAL; - switch (cmds) { - case Q_QUOTAON: - ret = quota_on(sb, type, (char *) addr); - goto out; - case Q_QUOTAOFF: - ret = quota_off(sb, type); - goto out; - case Q_GETQUOTA: - ret = get_quota(sb, id, type, (struct mem_dqblk *) addr); - goto out; - case Q_SETQUOTA: - flags |= SET_QUOTA; - break; - case Q_SETUSE: - flags |= SET_USE; - break; - case Q_SETQLIM: - flags |= SET_QLIMIT; - break; - case Q_SYNC: - ret = sync_dquots(dev, type); - goto out; - case Q_GETSTATS: - ret = get_stats(addr); - goto out; - case Q_GETINFO: - ret = get_info(sb, type, (struct mem_dqinfo *) addr); - goto out; - case Q_SETFLAGS: - ret = set_info(ISET_FLAGS, sb, type, (struct mem_dqinfo *)addr); - goto out; - case Q_SETGRACE: - ret = set_info(ISET_GRACE, sb, type, (struct mem_dqinfo *)addr); - goto out; - case Q_SETINFO: - ret = set_info(ISET_ALL, sb, type, (struct mem_dqinfo *)addr); - goto out; - default: - goto out; - } - - ret = -NODEV; - if (sb && sb_has_quota_enabled(sb, type)) - ret = set_dqblk(sb, id, type, flags, (struct mem_dqblk *) addr); -out: - if (sb) - drop_super(sb); - unlock_kernel(); - return ret; -} +struct quota_operations generic_quota_ops = { + quotaon: quota_on, + quotaoff: quota_off, + sync: sync_dquots, + getinfo: get_info, + setinfo: set_info, + getdqblk: get_dqblk, + setdqblk: set_dqblk, +}; diff -Naur linux-2410ac8/fs/noquot.c linux-2410ac8-quota/fs/noquot.c --- linux-2410ac8/fs/noquot.c Mon Oct 8 13:27:00 2001 +++ linux-2410ac8-quota/fs/noquot.c Thu Jan 1 10:00:00 1970 @@ -1,20 +0,0 @@ -/* noquot.c: Quota stubs necessary for when quotas are not - * compiled into the kernel. - */ - -#include -#include -#include - -int nr_dquots, nr_free_dquots; -int max_dquots; - -asmlinkage long sys_quotactl(int cmd, const char *special, int id, caddr_t addr) -{ - return(-ENOSYS); -} - -void shrink_dqcache_memory(int priority, unsigned int gfp_mask) -{ - ; -} diff -Naur linux-2410ac8/fs/quota.c linux-2410ac8-quota/fs/quota.c --- linux-2410ac8/fs/quota.c Thu Jan 1 10:00:00 1970 +++ linux-2410ac8-quota/fs/quota.c Mon Oct 8 18:15:41 2001 @@ -0,0 +1,216 @@ +/* + * Quota code necessary even when VFS quota support is not compiled + * into the kernel. Allows filesystems to implement their own form + * of quota if they wish. The interesting stuff is over in dquot.c, + * living here are symbols for initial quotactl(2) handling, sysctl + * variables, etc - things needed even when quota support disabled. + */ + +#include +#include +#include +#include +#include + +int nr_dquots, nr_free_dquots; + +#ifndef CONFIG_QUOTA +void shrink_dqcache_memory(int priority, unsigned int mask) +{ + return; +} +#endif + +static struct super_block * +validate_quotactl(int cmd, int type, const char *special, qid_t id) +{ + int ret; + kdev_t dev; + mode_t mode; + struct nameidata nd; + struct super_block *sb; + + ret = -ENOSYS; + if (cmd == 0x0800 || cmd == 0x1100) /* both were Q_GETSTATS */ + goto out; + + /* version/compatibility stuff - needs to be early on in the piece */ + ret = -EINVAL; + if (cmd == 0x0300 || cmd == 0x0400 || cmd == 0x0500 || cmd == 0x1000 + || cmd < 0x100) + goto out; + if (type >= MAXQUOTAS) + goto out; + + ret = -EPERM; + switch (cmd) { + case Q_SYNC: + case Q_GETINFO: + case Q_XGETQSTAT: + break; + + case Q_GETQUOTA: + case Q_XGETQUOTA: + if (((type == USRQUOTA && current->euid != id) || + (type == GRPQUOTA && !in_egroup_p(id))) && + !capable(CAP_SYS_ADMIN)) + goto out; + + default: + if (!capable(CAP_SYS_ADMIN)) + goto out; + } + + ret = -ENODEV; + if (!special) + goto out; + ret = user_path_walk(special, &nd); + if (ret) + goto out; + + dev = nd.dentry->d_inode->i_rdev; + mode = nd.dentry->d_inode->i_mode; + path_release(&nd); + + ret = -ENOTBLK; + if (!S_ISBLK(mode)) + goto out; + + ret = -ENODEV; + sb = get_super(dev); + if (!sb) + goto out; + + ret = -ENOSYS; + if (!sb->s_qop) { + drop_super(sb); + goto out; + } + + ret = 0; +out: + if (ret) + return ERR_PTR(ret); + return NULL; +} + +asmlinkage long +sys_quotactl(int cmd, const char *special, qid_t id, __kernel_caddr_t addr) +{ + int ret, cmds, type; + struct super_block *sb; + union { + char *pathname; + unsigned int flags; + struct mem_dqblk mdq; + struct mem_dqinfo info; + struct fs_disk_quota fdq; + struct fs_quota_stat fqs; + } u; /* qualifies valid uses of "addr" */ + + lock_kernel(); + cmds = cmd >> SUBCMDSHIFT; + type = cmd & SUBCMDMASK; + + sb = validate_quotactl(cmds, type, special, id); + if (IS_ERR(sb)) { + unlock_kernel(); + return PTR_ERR(sb); + } + + ret = -EINVAL; + switch (cmds) { + case Q_QUOTAON: + u.pathname = (char *)addr; + if (sb->s_qop->quotaon) + ret = sb->s_qop->quotaon(sb, type, u.pathname); + break; + + case Q_QUOTAOFF: + if (sb->s_qop->quotaoff) + ret = sb->s_qop->quotaoff(sb, type); + break; + + case Q_SYNC: + if (sb->s_qop->sync) + ret = sb->s_qop->sync(sb, type); + break; + + case Q_GETINFO: + if (sb->s_qop->getinfo) + ret = sb->s_qop->getinfo(sb, type, &u.info); + if (!ret && copy_to_user(addr, &u.info, sizeof(u.info))) + ret = -EFAULT; + break; + + case Q_SETINFO: + case Q_SETFLAGS: + case Q_SETGRACE: + if (!sb->s_qop->setinfo) + break; + ret = -EFAULT; + if (copy_from_user(&u.info, addr, sizeof(u.info))) + break; + ret = sb->s_qop->setinfo(sb, type, &u.info, cmds); + break; + + case Q_GETQUOTA: + if (sb->s_qop->getdqblk) + ret = sb->s_qop->getdqblk(sb, id, type, &u.mdq); + if (!ret && copy_to_user(addr, &u.mdq, sizeof(u.mdq))) + ret = -EFAULT; + break; + + case Q_SETUSE: + case Q_SETQLIM: + case Q_SETQUOTA: + if (!sb->s_qop->setdqblk) + break; + ret = -EFAULT; + if (copy_from_user(&u.mdq, addr, sizeof(u.mdq))) + break; + ret = sb->s_qop->setdqblk(sb, id, type, &u.mdq, cmds); + break; + + case Q_XQUOTAON: + case Q_XQUOTAOFF: + case Q_XQUOTARM: + if (!sb->s_qop->setxstate) + break; + ret = -EFAULT; + if (copy_from_user(&u.flags, addr, sizeof(u.flags))) + break; + ret = sb->s_qop->setxstate(sb, type, u.flags, cmds); + break; + + case Q_XGETQSTAT: + if (sb->s_qop->getxstate) + ret = sb->s_qop->getxstate(sb, type, &u.fqs); + ret = -EFAULT; + if (!ret && copy_to_user(addr, &u.fqs, sizeof(u.fqs))) + ret = -EFAULT; + break; + + case Q_XSETQLIM: + if (!sb->s_qop->setxquota) + break; + ret = -EFAULT; + if (copy_from_user(&u.fdq, addr, sizeof(u.fdq))) + break; + ret = sb->s_qop->setxquota(sb, type, &u.fdq); + break; + + case Q_XGETQUOTA: + if (sb->s_qop->getxquota) + ret = sb->s_qop->getxquota(sb, type, &u.fdq); + ret = -EFAULT; + if (!ret && copy_to_user(addr, &u.fqs, sizeof(u.fdq))) + ret = -EFAULT; + break; + + default: + } + drop_super(sb); + unlock_kernel(); + return ret; +} diff -Naur linux-2410ac8/fs/super.c linux-2410ac8-quota/fs/super.c --- linux-2410ac8/fs/super.c Mon Oct 8 13:27:00 2001 +++ linux-2410ac8-quota/fs/super.c Mon Oct 8 13:29:31 2001 @@ -453,6 +453,7 @@ s->s_bdev = bdev; s->s_flags = flags; s->s_type = type; + s->s_qop = sb_generic_quota_ops; spin_lock(&sb_lock); list_add (&s->s_list, super_blocks.prev); list_add (&s->s_instances, &type->fs_supers); @@ -473,6 +474,7 @@ s->s_dev = 0; s->s_bdev = 0; s->s_type = NULL; + s->s_qop = NULL; unlock_super(s); spin_lock(&sb_lock); list_del(&s->s_list); @@ -604,6 +606,7 @@ s->s_bdev = bdev; s->s_flags = flags; s->s_type = fs_type; + s->s_qop = sb_generic_quota_ops; list_add (&s->s_list, super_blocks.prev); list_add (&s->s_instances, &fs_type->fs_supers); s->s_count += S_BIAS; @@ -623,6 +626,7 @@ s->s_dev = 0; s->s_bdev = 0; s->s_type = NULL; + s->s_qop = NULL; unlock_super(s); spin_lock(&sb_lock); list_del(&s->s_list); @@ -687,6 +691,7 @@ s->s_dev = dev; s->s_flags = flags; s->s_type = fs_type; + s->s_qop = sb_generic_quota_ops; list_add (&s->s_list, super_blocks.prev); list_add (&s->s_instances, &fs_type->fs_supers); s->s_count += S_BIAS; @@ -702,6 +707,7 @@ s->s_dev = 0; s->s_bdev = 0; s->s_type = NULL; + s->s_qop = NULL; unlock_super(s); spin_lock(&sb_lock); list_del(&s->s_list); @@ -757,6 +763,7 @@ sb->s_bdev = NULL; put_filesystem(fs); sb->s_type = NULL; + sb->s_qop = NULL; unlock_super(sb); unlock_kernel(); if (bdev) diff -Naur linux-2410ac8/include/linux/fs.h linux-2410ac8-quota/include/linux/fs.h --- linux-2410ac8/include/linux/fs.h Mon Oct 8 13:27:00 2001 +++ linux-2410ac8-quota/include/linux/fs.h Mon Oct 8 18:19:06 2001 @@ -376,6 +376,7 @@ /* * Includes for diskquotas and mount structures. */ +#include #include #include @@ -659,6 +660,20 @@ struct mem_dqinfo info[MAXQUOTAS]; /* Information for each quota type */ }; +struct quota_operations { + int (*quotaon)(struct super_block *, short, char *); + int (*quotaoff)(struct super_block *, short); + int (*sync)(struct super_block *, short); + int (*getinfo)(struct super_block *, short, struct mem_dqinfo *); + int (*setinfo)(struct super_block *, short, struct mem_dqinfo *, int); + int (*getdqblk)(struct super_block *, short, qid_t, struct mem_dqblk *); + int (*setdqblk)(struct super_block *, short, qid_t, struct mem_dqblk *, int); + int (*setxstate)(struct super_block *, short, unsigned int, int); + int (*getxstate)(struct super_block *, short, struct fs_quota_stat *); + int (*setxquota)(struct super_block *, short, struct fs_disk_quota *); + int (*getxquota)(struct super_block *, short, struct fs_disk_quota *); +}; + /* * Umount options */ @@ -720,6 +735,7 @@ struct block_device *s_bdev; struct list_head s_instances; struct quota_info s_dquot; /* Diskquota specific options */ + struct quota_operations *s_qop; union { struct minix_sb_info minix_sb; diff -Naur linux-2410ac8/include/linux/quota.h linux-2410ac8-quota/include/linux/quota.h --- linux-2410ac8/include/linux/quota.h Mon Oct 8 15:30:03 2001 +++ linux-2410ac8-quota/include/linux/quota.h Mon Oct 8 18:04:05 2001 @@ -107,7 +107,7 @@ #define Q_SETQUOTA 0x0E00 /* set limits and usage */ #define Q_SETUSE 0x0F00 /* set usage */ /* 0x1000 used by old RSQUASH */ -#define Q_GETSTATS 0x1100 /* get collected stats */ +/* 0x1100 used by GETSTATS v2, since replaced by procfs entry */ /* * The following structure defines the format of the disk quota file @@ -253,13 +253,6 @@ #define dq_bhardlimit dq_dqb.dqb_bhardlimit #define dq_itime dq_dqb.dqb_itime #define dq_btime dq_dqb.dqb_btime - -/* - * Flags used for set_dqblk. - */ -#define SET_QUOTA 0x01 -#define SET_USE 0x02 -#define SET_QLIMIT 0x04 #define QUOTA_OK 0 #define NO_QUOTA 1 diff -Naur linux-2410ac8/include/linux/quotaops.h linux-2410ac8-quota/include/linux/quotaops.h --- linux-2410ac8/include/linux/quotaops.h Mon Oct 8 13:27:00 2001 +++ linux-2410ac8-quota/include/linux/quotaops.h Mon Oct 8 18:26:56 2001 @@ -17,6 +17,9 @@ #include +extern struct quota_operations generic_quota_ops; +#define sb_generic_quota_ops (&generic_quota_ops) + /* * declaration of quota_function calls in kernel. */ @@ -166,6 +169,7 @@ /* * NO-OP when quota not configured. */ +#define sb_generic_quota_ops (NULL) #define DQUOT_INIT(inode) do { } while(0) #define DQUOT_DROP(inode) do { } while(0) #define DQUOT_ALLOC_INODE(inode) (0) diff -Naur linux-2410ac8/include/linux/sysctl.h linux-2410ac8-quota/include/linux/sysctl.h --- linux-2410ac8/include/linux/sysctl.h Mon Oct 8 13:27:00 2001 +++ linux-2410ac8-quota/include/linux/sysctl.h Mon Oct 8 18:04:06 2001 @@ -535,7 +535,7 @@ FS_STATINODE=2, FS_MAXINODE=3, /* int:maximum number of inodes that can be allocated */ FS_NRDQUOT=4, /* int:current number of allocated dquots */ - FS_MAXDQUOT=5, /* int:maximum number of dquots that can be allocated */ + /* was FS_MAXDQUOT */ FS_NRFILE=6, /* int:current number of allocated filedescriptors */ FS_MAXFILE=7, /* int:maximum number of filedescriptors that can be allocated */ FS_DENTRY=8, diff -Naur linux-2410ac8/include/linux/xqm.h linux-2410ac8-quota/include/linux/xqm.h --- linux-2410ac8/include/linux/xqm.h Thu Jan 1 10:00:00 1970 +++ linux-2410ac8-quota/include/linux/xqm.h Mon Oct 8 18:04:05 2001 @@ -0,0 +1,159 @@ +/* + * Copyright (c) 2000 Silicon Graphics, Inc. All Rights Reserved. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of version 2 of the GNU General Public License as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it would be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + * + * Further, this software is distributed without any warranty that it is + * free of the rightful claim of any third person regarding infringement + * or the like. Any license provided herein, whether implied or + * otherwise, applies only to this software file. Patent licenses, if + * any, provided herein do not apply to combinations of this program with + * other software, or any other product whatsoever. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write the Free Software Foundation, Inc., 59 + * Temple Place - Suite 330, Boston MA 02111-1307, USA. + * + * Contact information: Silicon Graphics, Inc., 1600 Amphitheatre Pkwy, + * Mountain View, CA 94043, or: + * + * http://www.sgi.com + * + * For further information regarding this notice, see: + * + * http://oss.sgi.com/projects/GenInfo/SGIGPLNoticeExplan/ + */ +#ifndef _LINUX_XQM_H +#define _LINUX_XQM_H + +#include + +/* + * Disk quota - quotactl(2) commands for the XFS Quota Manager (XQM). + */ + +#define XQM_CMD(x) (('X'<<8)+(x)) /* note: forms first QCMD argument */ +#define Q_XQUOTAON XQM_CMD(0x1) /* enable accounting/enforcement */ +#define Q_XQUOTAOFF XQM_CMD(0x2) /* disable accounting/enforcement */ +#define Q_XGETQUOTA XQM_CMD(0x3) /* get disk limits and usage */ +#define Q_XSETQLIM XQM_CMD(0x4) /* set disk limits */ +#define Q_XGETQSTAT XQM_CMD(0x5) /* get quota subsystem status */ +#define Q_XQUOTARM XQM_CMD(0x6) /* free disk space used by dquots */ +#define Q_XDEBUG XQM_CMD(0x7) /* do internal consistency checks */ + +/* + * fs_disk_quota structure: + * + * This contains the current quota information regarding a user/proj/group. + * It is 64-bit aligned, and all the blk units are in BBs (Basic Blocks) of + * 512 bytes. + */ +#define FS_DQUOT_VERSION 1 /* fs_disk_quota.d_version */ +typedef struct fs_disk_quota { + __s8 d_version; /* version of this structure */ + __s8 d_flags; /* XFS_{USER,PROJ,GROUP}_QUOTA */ + __u16 d_fieldmask; /* field specifier */ + __u32 d_id; /* user, project, or group ID */ + __u64 d_blk_hardlimit;/* absolute limit on disk blks */ + __u64 d_blk_softlimit;/* preferred limit on disk blks */ + __u64 d_ino_hardlimit;/* maximum # allocated inodes */ + __u64 d_ino_softlimit;/* preferred inode limit */ + __u64 d_bcount; /* # disk blocks owned by the user */ + __u64 d_icount; /* # inodes owned by the user */ + __s32 d_itimer; /* zero if within inode limits */ + /* if not, we refuse service */ + __s32 d_btimer; /* similar to above; for disk blocks */ + __u16 d_iwarns; /* # warnings issued wrt num inodes */ + __u16 d_bwarns; /* # warnings issued wrt disk blocks */ + __s32 d_padding2; /* padding2 - for future use */ + __u64 d_rtb_hardlimit;/* absolute limit on realtime blks */ + __u64 d_rtb_softlimit;/* preferred limit on RT disk blks */ + __u64 d_rtbcount; /* # realtime blocks owned */ + __s32 d_rtbtimer; /* similar to above; for RT disk blks */ + __u16 d_rtbwarns; /* # warnings issued wrt RT disk blks */ + __s16 d_padding3; /* padding3 - for future use */ + char d_padding4[8]; /* yet more padding */ +} fs_disk_quota_t; + +/* + * These fields are sent to Q_XSETQLIM to specify fields that need to change. + */ +#define FS_DQ_ISOFT (1<<0) +#define FS_DQ_IHARD (1<<1) +#define FS_DQ_BSOFT (1<<2) +#define FS_DQ_BHARD (1<<3) +#define FS_DQ_RTBSOFT (1<<4) +#define FS_DQ_RTBHARD (1<<5) +#define FS_DQ_LIMIT_MASK (FS_DQ_ISOFT | FS_DQ_IHARD | FS_DQ_BSOFT | \ + FS_DQ_BHARD | FS_DQ_RTBSOFT | FS_DQ_RTBHARD) +/* + * These timers can only be set in super user's dquot. For others, timers are + * automatically started and stopped. Superusers timer values set the limits + * for the rest. In case these values are zero, the DQ_{F,B}TIMELIMIT values + * defined below are used. + * These values also apply only to the d_fieldmask field for Q_XSETQLIM. + */ +#define FS_DQ_BTIMER (1<<6) +#define FS_DQ_ITIMER (1<<7) +#define FS_DQ_RTBTIMER (1<<8) +#define FS_DQ_TIMER_MASK (FS_DQ_BTIMER | FS_DQ_ITIMER | FS_DQ_RTBTIMER) + +/* + * The following constants define the default amount of time given a user + * before the soft limits are treated as hard limits (usually resulting + * in an allocation failure). These may be modified by the quotactl(2) + * system call with the Q_XSETQLIM command. + */ +#define DQ_FTIMELIMIT (7 * 24*60*60) /* 1 week */ +#define DQ_BTIMELIMIT (7 * 24*60*60) /* 1 week */ + +/* + * Various flags related to quotactl(2). Only relevant to XFS filesystems. + */ +#define XFS_QUOTA_UDQ_ACCT (1<<0) /* user quota accounting */ +#define XFS_QUOTA_UDQ_ENFD (1<<1) /* user quota limits enforcement */ +#define XFS_QUOTA_GDQ_ACCT (1<<2) /* group quota accounting */ +#define XFS_QUOTA_GDQ_ENFD (1<<3) /* group quota limits enforcement */ + +#define XFS_USER_QUOTA (1<<0) /* user quota type */ +#define XFS_PROJ_QUOTA (1<<1) /* (IRIX) project quota type */ +#define XFS_GROUP_QUOTA (1<<2) /* group quota type */ + +/* + * fs_quota_stat is the struct returned in Q_XGETQSTAT for a given file system. + * Provides a centralized way to get meta infomation about the quota subsystem. + * eg. space taken up for user and group quotas, number of dquots currently + * incore. + */ +#define FS_QSTAT_VERSION 1 /* fs_quota_stat.qs_version */ + +/* + * Some basic infomation about 'quota files'. + */ +typedef struct fs_qfilestat { + __u64 qfs_ino; /* inode number */ + __u64 qfs_nblks; /* number of BBs 512-byte-blks */ + __u32 qfs_nextents; /* number of extents */ +} fs_qfilestat_t; + +typedef struct fs_quota_stat { + __s8 qs_version; /* version number for future changes */ + __u16 qs_flags; /* XFS_QUOTA_{U,P,G}DQ_{ACCT,ENFD} */ + __s8 qs_pad; /* unused */ + fs_qfilestat_t qs_uquota; /* user quota storage information */ + fs_qfilestat_t qs_gquota; /* group quota storage information */ + __u32 qs_incoredqs; /* number of dquots incore */ + __s32 qs_btimelimit; /* limit for blks timer */ + __s32 qs_itimelimit; /* limit for inodes timer */ + __s32 qs_rtbtimelimit;/* limit for rt blks timer */ + __u16 qs_bwarnlimit; /* limit for num warnings */ + __u16 qs_iwarnlimit; /* limit for num warnings */ +} fs_quota_stat_t; + +#endif /* _LINUX_XQM_H */ --nFreZHaLTZJo0R7j-- From owner-linux-xfs@oss.sgi.com Mon Oct 8 06:14:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98DEv814067 for linux-xfs-outgoing; Mon, 8 Oct 2001 06:14:57 -0700 Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98DEsD14045 for ; Mon, 8 Oct 2001 06:14:54 -0700 Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.22 #1) id 15qaDw-0006e8-00; Mon, 08 Oct 2001 15:13:36 +0200 To: Keith Owens Cc: linux-xfs@oss.sgi.com Subject: Re: Use CVS version or kernel patch? References: <3127.1002524824@kao2.melbourne.sgi.com> From: Florian Weimer Date: 08 Oct 2001 15:13:36 +0200 In-Reply-To: <3127.1002524824@kao2.melbourne.sgi.com> (Keith Owens's message of "Mon, 08 Oct 2001 17:07:04 +1000") Message-ID: Lines: 22 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Keith Owens writes: > Are you feeling lucky? Full moon tonight? ;-) > The CVS tree is bleeding edge with minimal testing. Does it include new significant XFS development, or is it just tracking the mainline kernel? > The kernel patches, particularly the official releases (1.0.1 > is current) get much more testing but are against older kernels. Exactly that's the problem. For example, at least one significant bug has been fixed in 2.4.7, therefore I would hate to go back to 2.4.5 (although the fix is trivial). -- Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 From owner-linux-xfs@oss.sgi.com Mon Oct 8 06:48:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98DmxK14766 for linux-xfs-outgoing; Mon, 8 Oct 2001 06:48:59 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98DmuD14743 for ; Mon, 8 Oct 2001 06:48:56 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f98DmjL06814 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Mon, 8 Oct 2001 06:48:46 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id PAA2722865 for ; Mon, 8 Oct 2001 15:47:55 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA3259198; Mon, 8 Oct 2001 08:47:23 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA40275; Mon, 8 Oct 2001 08:47:23 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f98DkOj19129; Mon, 8 Oct 2001 08:46:24 -0500 Message-Id: <200110081346.f98DkOj19129@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Florian Weimer cc: Keith Owens , linux-xfs@oss.sgi.com Subject: Re: Use CVS version or kernel patch? In-Reply-To: Message from Florian Weimer of "08 Oct 2001 15:13:36 +0200." Date: Mon, 08 Oct 2001 08:46:24 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Keith Owens writes: > > > Are you feeling lucky? > > Full moon tonight? ;-) > > > The CVS tree is bleeding edge with minimal testing. > > Does it include new significant XFS development, or is it just > tracking the mainline kernel? Pretty much everything new in cvs is for tracking newer kernels, or for XFS bug fixing. There is not much in the way of feature work ongoing at the moment - a new acl interface is being worked on as is the quota interface, but these are not directly in the tree right now. Steve > > > The kernel patches, particularly the official releases (1.0.1 > > is current) get much more testing but are against older kernels. > > Exactly that's the problem. For example, at least one significant bug > has been fixed in 2.4.7, therefore I would hate to go back to 2.4.5 > (although the fix is trivial). > > -- > Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE > University of Stuttgart http://cert.uni-stuttgart.de/ > RUS-CERT +49-711-685-5973/fax +49-711-685-5898 From owner-linux-xfs@oss.sgi.com Mon Oct 8 07:14:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98EEut15471 for linux-xfs-outgoing; Mon, 8 Oct 2001 07:14:56 -0700 Received: from mailfast.internal.ima.pl (ip222ds.ima.pl [62.89.65.222]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98EEmD15449 for ; Mon, 8 Oct 2001 07:14:49 -0700 Received: from mailhub.internal.ima.pl by mailfast.internal.ima.pl with ESMTP id f98EDEl00574; Mon, 8 Oct 2001 16:13:14 +0200 Received: from mail.ima.pl by mailhub.internal.ima.pl with ESMTP id f98EDCX00544; Mon, 8 Oct 2001 16:13:12 +0200 Received: from blizbor.ima.pl (jurek.primark.gdansk.tpnet.pl [195.117.150.37]) by mail.ima.pl with ESMTP id f98ED2111110; Mon, 8 Oct 2001 16:13:03 +0200 Message-Id: <5.1.0.14.0.20011008161521.02697ec0@mail.ima.pl> X-Sender: blizbor@mail.ima.pl X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 08 Oct 2001 16:17:26 +0200 To: Keith Owens , Florian Weimer From: Blizbor Subject: Re: Use CVS version or kernel patch? Cc: linux-xfs@oss.sgi.com In-Reply-To: <3127.1002524824@kao2.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 10/8/01 09:07 AM, Keith Owens wrote: >On 08 Oct 2001 08:53:52 +0200, >Florian Weimer wrote: >>I'm going to set up a new machine with substantially more disk space I >>used to have before, and I wonder if I should use the XFS CVS version >>or the kernel patch. > >Are you feeling lucky? The CVS tree is bleeding edge with minimal >testing. The kernel patches, particularly the official releases (1.0.1 >is current) get much more testing but are against older kernels. Sounds interesting. I'm using only CVS tree kernels and never had problems. (OK - I'm using also released kernales, but only during install from CD). Have you any problems with CVS kernels ? Regards, Blizbor -- From owner-linux-xfs@oss.sgi.com Mon Oct 8 07:20:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98EKWF15741 for linux-xfs-outgoing; Mon, 8 Oct 2001 07:20:32 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98EKSD15719 for ; Mon, 8 Oct 2001 07:20:28 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f98EKML10444 for ; Mon, 8 Oct 2001 07:20:22 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA3257826; Mon, 8 Oct 2001 09:19:03 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA82801; Mon, 8 Oct 2001 09:19:03 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f98EI4T19319; Mon, 8 Oct 2001 09:18:04 -0500 Message-Id: <200110081418.f98EI4T19319@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Blizbor cc: Keith Owens , Florian Weimer , linux-xfs@oss.sgi.com Subject: Re: Use CVS version or kernel patch? In-Reply-To: Message from Blizbor of "Mon, 08 Oct 2001 16:17:26 +0200." <5.1.0.14.0.20011008161521.02697ec0@mail.ima.pl> Date: Mon, 08 Oct 2001 09:18:04 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > At 10/8/01 09:07 AM, Keith Owens wrote: > >On 08 Oct 2001 08:53:52 +0200, > >Florian Weimer wrote: > >>I'm going to set up a new machine with substantially more disk space I > >>used to have before, and I wonder if I should use the XFS CVS version > >>or the kernel patch. > > > >Are you feeling lucky? The CVS tree is bleeding edge with minimal > >testing. The kernel patches, particularly the official releases (1.0.1 > >is current) get much more testing but are against older kernels. > > > Sounds interesting. I'm using only CVS tree kernels and never had problems. > (OK - I'm using also released kernales, but only during install from CD). > > Have you any problems with CVS kernels ? Well, they are often based on pre-xx Linus kernels and people definitely have problems with those sometimes. We always make sure there is a patch available against a 2.4.x release before we move the tree up to a pre-xx kernel. Look in the patches directory on oss for these if you want to use a specific Linus kernel revision. These all represent the state of the cvs tree just before it was upgraded (???) to the start of the next pre-xx series. Steve > > Regards, > Blizbor > > -- > From owner-linux-xfs@oss.sgi.com Mon Oct 8 07:21:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98ELVF15876 for linux-xfs-outgoing; Mon, 8 Oct 2001 07:21:31 -0700 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98ELRD15854 for ; Mon, 8 Oct 2001 07:21:27 -0700 Received: (qmail 4684 invoked from network); 8 Oct 2001 14:21:24 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 8 Oct 2001 14:21:24 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id D4A0E300095; Tue, 9 Oct 2001 00:21:21 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 805099A; Tue, 9 Oct 2001 00:21:21 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Blizbor Cc: linux-xfs@oss.sgi.com Subject: Re: Use CVS version or kernel patch? In-reply-to: Your message of "Mon, 08 Oct 2001 16:17:26 +0200." <5.1.0.14.0.20011008161521.02697ec0@mail.ima.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 09 Oct 2001 00:21:16 +1000 Message-ID: <8163.1002550876@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 08 Oct 2001 16:17:26 +0200, Blizbor wrote: >At 10/8/01 09:07 AM, Keith Owens wrote: >>Are you feeling lucky? The CVS tree is bleeding edge with minimal >>testing. The kernel patches, particularly the official releases (1.0.1 >>is current) get much more testing but are against older kernels. > >Sounds interesting. I'm using only CVS tree kernels and never had problems. >(OK - I'm using also released kernales, but only during install from CD). > >Have you any problems with CVS kernels ? We track Linus's pre-releases so every bug Linus ships, XFS CVS gets as well. For example, Linus 2.4.11-pre4 had broken VM under heavy loads, it is supposed to be fixed in -pre5, we don't know if it is fixed yet. On top of that, the XFS merge includes kdb, lvm plus its own changes, if SGI make a mistake then the CVS tree is broken again. From owner-linux-xfs@oss.sgi.com Mon Oct 8 07:36:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98Ea6n16414 for linux-xfs-outgoing; Mon, 8 Oct 2001 07:36:06 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98EZvD16391 for ; Mon, 8 Oct 2001 07:35:57 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.6/8.11.6) id f98EZpZ10307 for linux-xfs@oss.sgi.com; Mon, 8 Oct 2001 10:35:51 -0400 Date: Mon, 8 Oct 2001 10:35:51 -0400 From: Alan Eldridge To: SGI XFS Dev List Subject: Linus broke it again? Message-ID: <20011008103551.A5610@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk + make -s -j 1 CC=kgcc modules objcopy: Warning: Output file cannot represent architecture UNKNOWN! pd.c: In function `cleanup_module': pd.c:590: warning: unused variable `gdp' bpck6.c:294: warning: `init_module' defined but not used generic_serial.c:1074: parse error before `this_object_must_be_defined_as_export_objs_in_the_Makefile' generic_serial.c:1074: warning: type defaults to `int' in declaration of `this_object_must_be_defined_as_export_objs_in_the_Makefile' generic_serial.c:1074: warning: data definition has no type or storage class generic_serial.c:1075: parse error before `this_object_must_be_defined_as_export_objs_in_the_Makefile' generic_serial.c:1075: warning: type defaults to `int' in declaration of `this_object_must_be_defined_as_export_objs_in_the_Makefile' generic_serial.c:1075: warning: data definition has no type or storage class generic_serial.c:1076: parse error before `this_object_must_be_defined_as_export_objs_in_the_Makefile' generic_serial.c:1076: warning: type defaults to `int' in declaration of `this_object_must_be_defined_as_export_objs_in_the_Makefile' generic_serial.c:1076: warning: data definition has no type or storage class generic_serial.c:1077: parse error before `this_object_must_be_defined_as_export_objs_in_the_Makefile' generic_serial.c:1077: warning: type defaults to `int' in declaration of `this_object_must_be_defined_as_export_objs_in_the_Makefile' generic_serial.c:1077: warning: data definition has no type or storage class generic_serial.c:1078: parse error before `this_object_must_be_defined_as_export_objs_in_the_Makefile' generic_serial.c:1078: warning: type defaults to `int' in declaration of `this_object_must_be_defined_as_export_objs_in_the_Makefile' generic_serial.c:1078: warning: data definition has no type or storage class generic_serial.c:1079: parse error before `this_object_must_be_defined_as_export_objs_in_the_Makefile' generic_serial.c:1079: warning: type defaults to `int' in declaration of `this_object_must_be_defined_as_export_objs_in_the_Makefile' generic_serial.c:1079: warning: data definition has no type or storage class generic_serial.c:1080: parse error before `this_object_must_be_defined_as_export_objs_in_the_Makefile' generic_serial.c:1080: warning: type defaults to `int' in declaration of `this_object_must_be_defined_as_export_objs_in_the_Makefile' generic_serial.c:1080: warning: data definition has no type or storage class generic_serial.c:1081: parse error before `this_object_must_be_defined_as_export_objs_in_the_Makefile' generic_serial.c:1081: warning: type defaults to `int' in declaration of `this_object_must_be_defined_as_export_objs_in_the_Makefile' generic_serial.c:1081: warning: data definition has no type or storage class generic_serial.c:1082: parse error before `this_object_must_be_defined_as_export_objs_in_the_Makefile' generic_serial.c:1082: warning: type defaults to `int' in declaration of `this_object_must_be_defined_as_export_objs_in_the_Makefile' generic_serial.c:1082: warning: data definition has no type or storage class generic_serial.c:1083: parse error before `this_object_must_be_defined_as_export_objs_in_the_Makefile' generic_serial.c:1083: warning: type defaults to `int' in declaration of `this_object_must_be_defined_as_export_objs_in_the_Makefile' generic_serial.c:1083: warning: data definition has no type or storage class generic_serial.c:1084: parse error before `this_object_must_be_defined_as_export_objs_in_the_Makefile' generic_serial.c:1084: warning: type defaults to `int' in declaration of `this_object_must_be_defined_as_export_objs_in_the_Makefile' generic_serial.c:1084: warning: data definition has no type or storage class generic_serial.c:1085: parse error before `this_object_must_be_defined_as_export_objs_in_the_Makefile' generic_serial.c:1085: warning: type defaults to `int' in declaration of `this_object_must_be_defined_as_export_objs_in_the_Makefile' generic_serial.c:1085: warning: data definition has no type or storage class generic_serial.c:1086: parse error before `this_object_must_be_defined_as_export_objs_in_the_Makefile' generic_serial.c:1086: warning: type defaults to `int' in declaration of `this_object_must_be_defined_as_export_objs_in_the_Makefile' generic_serial.c:1086: warning: data definition has no type or storage class generic_serial.c:1087: parse error before `this_object_must_be_defined_as_export_objs_in_the_Makefile' generic_serial.c:1087: warning: type defaults to `int' in declaration of `this_object_must_be_defined_as_export_objs_in_the_Makefile' generic_serial.c:1087: warning: data definition has no type or storage class generic_serial.c:1088: parse error before `this_object_must_be_defined_as_export_objs_in_the_Makefile' generic_serial.c:1088: warning: type defaults to `int' in declaration of `this_object_must_be_defined_as_export_objs_in_the_Makefile' generic_serial.c:1088: warning: data definition has no type or storage class generic_serial.c:1089: parse error before `this_object_must_be_defined_as_export_objs_in_the_Makefile' generic_serial.c:1089: warning: type defaults to `int' in declaration of `this_object_must_be_defined_as_export_objs_in_the_Makefile' generic_serial.c:1089: warning: data definition has no type or storage class generic_serial.c:1090: parse error before `this_object_must_be_defined_as_export_objs_in_the_Makefile' generic_serial.c:1090: warning: type defaults to `int' in declaration of `this_object_must_be_defined_as_export_objs_in_the_Makefile' generic_serial.c:1090: warning: data definition has no type or storage class make[2]: *** [generic_serial.o] Error 1 make[1]: *** [_modsubdir_char] Error 2 make: *** [_mod_drivers] Error 2 error: Bad exit status from /home/alane/rpm/tmp/rpm-tmp.33174 (%build) [alane@wwweasel kernel-2.4.11]$ aid this_object IS_THIS_OBJECT_TYPE linux/drivers/acpi/include/acmacros.h linux/drivers/acpi/events/evregion.c linux/drivers/acpi/utilities/{utcopy,utmisc,utobject}.c this_object_must_be_defined_as_export_objs_in_the_Makefile linux/include/linux/module.h [alane@wwweasel kernel-2.4.11]$ cd linux/include/linux [alane@wwweasel linux]$ xemacs module.h [alane@wwweasel linux]$ aid EXPORT_SYMTAB EXPORT_SYMTAB module.h EXPORT_SYMTAB_STROPS ../asm-sparc/string.h ../asm-sparc64/string.h ../../arch/ppc/kernel/ppc_ksyms.c ../../arch/sparc/kernel/sparc_ksyms.c ../../arch/sparc64/kernel/sparc64_ksyms.c [alane@wwweasel linux]$ grep EXPORT_SYMTAB module.h # if !defined(MODVERSIONS) && defined(EXPORT_SYMTAB) #elif !defined(EXPORT_SYMTAB) Well, that's special. EXPORT_SYMTAB is not actually defined ANYWHERE, so every invocation of the EXPORT_SYMBOL macro results in a #error directive. Folks out there who were gonna try this morning's kernel, you might as well wait a bit. PS. The tool 'aid' is part of the GNU id-utils package. I urge you to get this if you need to look things up in kernel source tree. Just install it, go into top of tree and do 'mkid'. Then 'aid symbol' finds symbol. See info pages (no man pages) for aid,lid,etc for more goodies. -- Alan Eldridge from std_disclaimer import * From owner-linux-xfs@oss.sgi.com Mon Oct 8 07:46:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98EkZR16732 for linux-xfs-outgoing; Mon, 8 Oct 2001 07:46:35 -0700 Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98EkWD16709 for ; Mon, 8 Oct 2001 07:46:32 -0700 Received: from there ([62.248.190.38]) by fep02-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20011008144630.FSNN26796.fep02-app.kolumbus.fi@there>; Mon, 8 Oct 2001 17:46:30 +0300 Content-Type: text/plain; charset="iso-8859-1" From: Hristo Grigorov To: Seth Mos , linux-xfs@oss.sgi.com Subject: Re: Use CVS version or kernel patch? Date: Mon, 8 Oct 2001 17:46:30 +0300 X-Mailer: KMail [version 1.3.1] References: <4.3.2.7.2.20011008090816.03ebe8c0@pop.xs4all.nl> In-Reply-To: <4.3.2.7.2.20011008090816.03ebe8c0@pop.xs4all.nl> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011008144630.FSNN26796.fep02-app.kolumbus.fi@there> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Monday 08 October 2001 10:08, Seth Mos wrote: > At 08:53 8-10-2001 +0200, Florian Weimer wrote: > >I'm going to set up a new machine with substantially more disk space I > >used to have before, and I wonder if I should use the XFS CVS version > >or the kernel patch. > > > >(Forgive me if this is in the FAQ, I haven't found it.) > > Depends on the hardware. If you have a VIA based system better use the CVS > version. > > Cheers Hmm, may I have more information on that ? I have VIA system but I thought that the other subsystems of the kernel are taking care about dealing with it. I didn't know every FS implementation have to implement workarround for that... -- Regards, Hristo. From owner-linux-xfs@oss.sgi.com Mon Oct 8 07:50:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98Eo9c17121 for linux-xfs-outgoing; Mon, 8 Oct 2001 07:50:09 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98Eo4D17057 for ; Mon, 8 Oct 2001 07:50:04 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f98EnxL14058 for ; Mon, 8 Oct 2001 07:49:59 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA3255488; Mon, 8 Oct 2001 09:48:42 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA69071; Mon, 8 Oct 2001 09:48:42 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f98Elhl24425; Mon, 8 Oct 2001 09:47:43 -0500 Message-Id: <200110081447.f98Elhl24425@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Hristo Grigorov cc: Seth Mos , linux-xfs@oss.sgi.com Subject: Re: Use CVS version or kernel patch? In-Reply-To: Message from Hristo Grigorov of "Mon, 08 Oct 2001 17:46:30 +0300." <20011008144630.FSNN26796.fep02-app.kolumbus.fi@there> Date: Mon, 08 Oct 2001 09:47:43 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Monday 08 October 2001 10:08, Seth Mos wrote: > > At 08:53 8-10-2001 +0200, Florian Weimer wrote: > > >I'm going to set up a new machine with substantially more disk space I > > >used to have before, and I wonder if I should use the XFS CVS version > > >or the kernel patch. > > > > > >(Forgive me if this is in the FAQ, I haven't found it.) > > > > Depends on the hardware. If you have a VIA based system better use the CVS > > version. > > > > Cheers > > Hmm, may I have more information on that ? I have VIA system but I thought > that the other subsystems of the kernel are taking care about dealing with > it. I didn't know every FS implementation have to implement workarround for > that... I presume Seth is referring to core kernel changes, there is nothing in XFS related to different architectures of chip. Steve > > -- > Regards, Hristo. From owner-linux-xfs@oss.sgi.com Mon Oct 8 07:50:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98Eo2x17025 for linux-xfs-outgoing; Mon, 8 Oct 2001 07:50:02 -0700 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98EnwD17000 for ; Mon, 8 Oct 2001 07:49:58 -0700 Received: (qmail 4840 invoked from network); 8 Oct 2001 14:49:55 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 8 Oct 2001 14:49:55 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 13D24300095; Tue, 9 Oct 2001 00:49:53 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id D57F29A; Tue, 9 Oct 2001 00:49:53 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Alan Eldridge Cc: SGI XFS Dev List Subject: Re: Linus broke it again? In-reply-to: Your message of "Mon, 08 Oct 2001 10:35:51 -0400." <20011008103551.A5610@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 09 Oct 2001 00:49:48 +1000 Message-ID: <8381.1002552588@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 8 Oct 2001 10:35:51 -0400, Alan Eldridge wrote: >+ make -s -j 1 CC=kgcc modules >generic_serial.c:1074: parse error before `this_object_must_be_defined_as_export_objs_in_the_Makefile' Don't blame Linus, blame the kernel build and modutils maintainers who put that change it. Oops, they are me :). Seriously though, the change was to detect objects that export symbols but the developer forgot to define them as export-objs in the Makefile. >Well, that's special. EXPORT_SYMTAB is not actually defined ANYWHERE, so >every invocation of the EXPORT_SYMBOL macro results in a #error directive. >Folks out there who were gonna try this morning's kernel, you might as well >wait a bit. EXPORT_SYMTAB is defined by Rules.make, based on export-objs variables. One problem with aid is that is only scans certain file types, by default it does not pick up files with no type so skips Rules.make and Makefile. Most of the makefiles are correct, only a few objects are missing. When you get that error, edit the makefile that compiles the object, add the object to export-objs and send a patch to Linus. From owner-linux-xfs@oss.sgi.com Mon Oct 8 07:59:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98ExV917611 for linux-xfs-outgoing; Mon, 8 Oct 2001 07:59:31 -0700 Received: from shed.alex.org.uk (shed.alex.org.uk [195.224.53.219]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98ExPD17563 for ; Mon, 8 Oct 2001 07:59:26 -0700 Received: from [10.132.113.67] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id A8929A4CB; Mon, 8 Oct 2001 15:59:24 +0100 (BST) Date: Mon, 08 Oct 2001 16:01:05 +0100 From: Alex Bligh - linux-kernel Reply-To: Alex Bligh - linux-kernel To: "Eric W. Biederman" , Alex Bligh - linux-kernel Cc: Mikulas Patocka , Rik van Riel , Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org, Alex Bligh - linux-kernel Subject: Re: %u-order allocation failed Message-ID: <1231218688.1002556865@[10.132.113.67]> In-Reply-To: References: X-Mailer: Mulberry/2.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --On Sunday, October 07, 2001 12:30 PM -0600 "Eric W. Biederman" wrote: >> Note also that something (not sure what) has made fragmentation >> increasingly prevalent over the years since the buddy allocator >> was originally put in. > > Actually it seems to be situations like the stack now being two pages Instrumentation posted here before appears to corellate fragmentation being /caused/ with I/O activity (single bonnie process and thus a single 8k stack frame). My own guess is that it is due to a different persistence of various caches. I haven't seen anyone before blaming stack frame allocation as a /cause/ of fragmenation - I've heard people say they notice fragmentation more as stack frame allocs start to fail - but that's a symptom. -- Alex Bligh From owner-linux-xfs@oss.sgi.com Mon Oct 8 08:07:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98F76R18015 for linux-xfs-outgoing; Mon, 8 Oct 2001 08:07:06 -0700 Received: from shed.alex.org.uk (shed.alex.org.uk [195.224.53.219]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98F73D17992 for ; Mon, 8 Oct 2001 08:07:03 -0700 Received: from [10.132.113.67] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 6B6ADAB65; Mon, 8 Oct 2001 16:07:02 +0100 (BST) Date: Mon, 08 Oct 2001 16:08:43 +0100 From: Alex Bligh - linux-kernel Reply-To: Alex Bligh - linux-kernel To: Alan Cox , Mikulas Patocka Cc: Rik van Riel , Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org, Alex Bligh - linux-kernel Subject: Re: %u-order allocation failed Message-ID: <1231676407.1002557323@[10.132.113.67]> In-Reply-To: References: X-Mailer: Mulberry/2.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --On Sunday, October 07, 2001 11:01 PM +0100 Alan Cox wrote: > vmalloc space fragments. You fragment address space rather than pages > thats all. Same problem Actually fragmented virtual space is theoretically worse, as you have now lost a possible weapon to defragment stuff (indirection on mapping to physical RAM - i.e. you could no longer move or swap out physical RAM and keep the virtual address mapping the same). -- Alex Bligh From owner-linux-xfs@oss.sgi.com Mon Oct 8 08:35:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98FZMj19445 for linux-xfs-outgoing; Mon, 8 Oct 2001 08:35:22 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98FZJD19417 for ; Mon, 8 Oct 2001 08:35:19 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f98FZEK08236 for ; Mon, 8 Oct 2001 08:35:14 -0700 Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA3255264; Mon, 8 Oct 2001 10:33:58 -0500 (CDT) Received: from sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA81749; Mon, 8 Oct 2001 10:33:57 -0500 (CDT) Message-ID: <3BC1C681.49B60A27@sgi.com> Date: Mon, 08 Oct 2001 10:30:09 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.8-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Hristo Grigorov CC: Seth Mos , linux-xfs@oss.sgi.com Subject: Re: Use CVS version or kernel patch? References: <4.3.2.7.2.20011008090816.03ebe8c0@pop.xs4all.nl> <20011008144630.FSNN26796.fep02-app.kolumbus.fi@there> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hristo Grigorov wrote: > Hmm, may I have more information on that ? I have VIA system but I thought > that the other subsystems of the kernel are taking care about dealing with > it. I didn't know every FS implementation have to implement workarround for > that... XFS doesn't do anything with system chipsets, I think Seth just meant that the later kernels might fix VIA problems. The "official" XFS 1.0.1 release is against 2.4.5, so if you need fixes in kernels after that, you'll need to go with a CVS snapshot patch. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Oct 8 09:31:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98GVcv20716 for linux-xfs-outgoing; Mon, 8 Oct 2001 09:31:38 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98GVWD20691 for ; Mon, 8 Oct 2001 09:31:32 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id RAA21565; Mon, 8 Oct 2001 17:03:00 +0200 (CEST) Message-Id: <4.3.2.7.2.20011008170107.03347d00@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 08 Oct 2001 17:01:45 +0200 To: Steve Lord , Hristo Grigorov From: Seth Mos Subject: Re: Use CVS version or kernel patch? Cc: linux-xfs@oss.sgi.com In-Reply-To: <200110081447.f98Elhl24425@jen.americas.sgi.com> References: <20011008144630.FSNN26796.fep02-app.kolumbus.fi@there> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 09:47 8-10-2001 -0500, Steve Lord wrote: > > On Monday 08 October 2001 10:08, Seth Mos wrote: > > > At 08:53 8-10-2001 +0200, Florian Weimer wrote: > > > >I'm going to set up a new machine with substantially more disk space I > > > >used to have before, and I wonder if I should use the XFS CVS version > > > >or the kernel patch. > > > > > > > >(Forgive me if this is in the FAQ, I haven't found it.) > > > > > > Depends on the hardware. If you have a VIA based system better use > the CVS > > > version. > > > > > > Cheers > > > > Hmm, may I have more information on that ? I have VIA system but I thought > > that the other subsystems of the kernel are taking care about dealing with > > it. I didn't know every FS implementation have to implement workarround > for > > that... > >I presume Seth is referring to core kernel changes, there is nothing in XFS >related to different architectures of chip. Correct, there have been a lot of core fixes related to corruption and instability. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Mon Oct 8 10:27:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98HRQN21692 for linux-xfs-outgoing; Mon, 8 Oct 2001 10:27:26 -0700 Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98HRND21670 for ; Mon, 8 Oct 2001 10:27:24 -0700 Received: from online.no (213-145-179-154.dd.nextgentel.com [213.145.179.154]) by mail.broadpark.no (Postfix) with ESMTP id AA5EF7FA8; Mon, 8 Oct 2001 19:27:15 +0200 (MET DST) Message-ID: <3BC2332F.CFE5F162@online.no> Date: Mon, 08 Oct 2001 19:13:51 -0400 From: Knut J Bjuland X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.11-pre5-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Seth Mos , linux-xfs@oss.sgi.com Subject: redhat 7.2 installer? References: <20011008144630.FSNN26796.fep02-app.kolumbus.fi@there> <4.3.2.7.2.20011008170107.03347d00@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Will SGI release a new installer for redhat 7.2 when'll be released or short after? From owner-linux-xfs@oss.sgi.com Mon Oct 8 10:35:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98HZbE22004 for linux-xfs-outgoing; Mon, 8 Oct 2001 10:35:37 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98HZZD21982 for ; Mon, 8 Oct 2001 10:35:35 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA04847 for ; Mon, 8 Oct 2001 10:34:34 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA3138414; Mon, 8 Oct 2001 12:34:17 -0500 (CDT) Received: from sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id MAA91519; Mon, 8 Oct 2001 12:34:16 -0500 (CDT) Message-ID: <3BC1E397.23C9D43F@sgi.com> Date: Mon, 08 Oct 2001 12:34:15 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.8-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Knut J Bjuland CC: Seth Mos , linux-xfs@oss.sgi.com Subject: Re: redhat 7.2 installer? References: <20011008144630.FSNN26796.fep02-app.kolumbus.fi@there> <4.3.2.7.2.20011008170107.03347d00@pop.xs4all.nl> <3BC2332F.CFE5F162@online.no> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Knut - Although it's not on the "official" XFS project plan, there are people outside of SGI who are working on something similar, and we hope to be able to build on their work to release an XFS-capable installer for the next official version of Red Hat... That's about all the info I have at this time. I'd like to see it too, since I'm running RH7.1/XFS at home, and I'd like to be able to upgrade as well. :) -Eric Knut J Bjuland wrote: > > Will SGI release a new installer for redhat 7.2 when'll be released or short > after? -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Oct 8 12:28:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98JSQn24240 for linux-xfs-outgoing; Mon, 8 Oct 2001 12:28:26 -0700 Received: from fep06-app.kolumbus.fi (fep06-0.kolumbus.fi [193.229.0.57]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98JSND24217 for ; Mon, 8 Oct 2001 12:28:23 -0700 Received: from there ([62.248.190.38]) by fep06-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20011008192821.KGKL1085.fep06-app.kolumbus.fi@there> for ; Mon, 8 Oct 2001 22:28:21 +0300 Content-Type: text/plain; charset="iso-8859-1" From: Hristo Grigorov To: linux-xfs@oss.sgi.com Subject: xfs for -ac kernel Date: Mon, 8 Oct 2001 22:28:22 +0300 X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011008192821.KGKL1085.fep06-app.kolumbus.fi@there> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I know it's really hard to maintain XFS patches for the -ac kernels but since nowdays they differ so much from the -linus ones it would be nice if we have at least one patch for them as a starting point. Like XFS patch for 2.4.10-ac1 would help a lot (I think I can do the rest myself). Then the next one can be for 2.4.11-ac1 and so on. -- Regards, Hristo. From owner-linux-xfs@oss.sgi.com Mon Oct 8 13:28:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98KSNj25333 for linux-xfs-outgoing; Mon, 8 Oct 2001 13:28:23 -0700 Received: from linux0.echostar.com (w146-253.echostar.com [205.172.146.253]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98KSLD25310 for ; Mon, 8 Oct 2001 13:28:21 -0700 Received: from echostar.com (linux10.echostar.com [10.79.98.110]) by linux0.echostar.com (Postfix) with ESMTP id 734E77908B for ; Mon, 8 Oct 2001 14:28:15 -0600 (MDT) Message-ID: <3BC20C61.88860470@echostar.com> Date: Mon, 08 Oct 2001 14:28:17 -0600 From: "Ian S. Nelson" Reply-To: ian.nelson@echostar.com Organization: Echostar X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.4.3 i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-xfs@oss.sgi.com" Subject: Difference between XFS_IOC_FREESP and XFS_IOC_UNRESVSP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk What's the difference between these two ioctls and are they both implemented on Linux? I've been trying to "trim" the front a file with FREESP and I keep getting 0 length files. thanks, Ian From owner-linux-xfs@oss.sgi.com Mon Oct 8 13:32:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98KW2e25518 for linux-xfs-outgoing; Mon, 8 Oct 2001 13:32:02 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98KVxD25494 for ; Mon, 8 Oct 2001 13:31:59 -0700 Received: from main.braxis.co.uk (main.braxis.co.uk [213.77.40.29]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA01197 for ; Mon, 24 Sep 2001 13:34:08 -0700 (PDT) mail_from (kszysiu@braxis.co.uk) Received: (from kszysiu@localhost) by main.braxis.co.uk (8.11.6/8.11.6) id f8OKT5I25713 for linux-xfs@oss.sgi.com; Mon, 24 Sep 2001 22:29:05 +0200 Date: Mon, 24 Sep 2001 22:29:05 +0200 From: Krzysztof Rusocki To: linux-xfs@oss.sgi.com Subject: cvsd on oss down ? Message-ID: <20010924222905.A25340@main.braxis.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello everyone, access to cvs from my home machine seems to be difficulty: cvs [update aborted]: recv() from server oss.sgi.com: Connection reset by peer While connection is 'up' netstat constantly shows: tcp 0 50 62.148.70.54:1233 216.32.174.27:2401 ESTABLISHED just reporting and patiently expecting... - Krzysztof From owner-linux-xfs@oss.sgi.com Mon Oct 8 14:48:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98Lm2W26802 for linux-xfs-outgoing; Mon, 8 Oct 2001 14:48:02 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98LlvD26780 for ; Mon, 8 Oct 2001 14:47:57 -0700 Received: from ausmail.coremetrics.com ([209.184.141.185]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA05748 for ; Mon, 24 Sep 2001 12:02:22 -0700 (PDT) mail_from (austin@coremetrics.com) Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Sep 2001 13:57:23 -0500 Message-ID: <85063BBE668FD411944400D0B744267A8885B5@AUSMAIL> From: "Gonyou, Austin" To: "'Steve Lord'" , khromy Cc: linux-xfs@oss.sgi.com Subject: RE: 2.4.10-pre13-xfs Unresolved symbols in pagebuf.o Date: Mon, 24 Sep 2001 13:57:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Why can't I connect to oss.sgi.com ftp or http? Is there a problem somewhere in the country with backbones or is it just oss.sgi.com is down? Please advise. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com > -----Original Message----- > From: Steve Lord [mailto:lord@sgi.com] > Sent: Monday, September 24, 2001 10:01 AM > To: khromy > Cc: linux-xfs@oss.sgi.com > Subject: Re: 2.4.10-pre13-xfs Unresolved symbols in pagebuf.o > > > > Latest cvs checkout as of: Fri Sep 21 19:29:04 EDT 2001 > > > > make modules_install fails with: > > > > depmod: *** Unresolved symbols in > /lib/modules/2.4.10-pre13-xfs/kernel/fs/pag > > ebuf/pagebuf.o > > depmod: discard_bh_page > > > > -- > > L1: khromy ;khromy at lnuxlab.ath.cx > > OK, this should be fixed in the cvs tree shortly. > > Steve > > From owner-linux-xfs@oss.sgi.com Mon Oct 8 14:58:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98LwuB27171 for linux-xfs-outgoing; Mon, 8 Oct 2001 14:58:56 -0700 Received: from linux0.echostar.com (w146-253.echostar.com [205.172.146.253]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98LwmD27145 for ; Mon, 8 Oct 2001 14:58:48 -0700 Received: from echostar.com (linux10.echostar.com [10.79.98.110]) by linux0.echostar.com (Postfix) with ESMTP id E07C67908B; Mon, 8 Oct 2001 15:29:34 -0600 (MDT) Message-ID: <3BC21AC2.499CBA57@echostar.com> Date: Mon, 08 Oct 2001 15:29:38 -0600 From: "Ian S. Nelson" Reply-To: ian.nelson@echostar.com Organization: Echostar X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.4.3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen , "linux-xfs@oss.sgi.com" Subject: Re: Difference between XFS_IOC_FREESP and XFS_IOC_UNRESVSP References: <3BC20C61.88860470@echostar.com> <3BC21863.E04AF644@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk So the fcntl is different from the ioctl? What I'm trying to do is poke a hole in a file where there used to be data. The specific application is with a big long stream of mpeg data and we want to truncate it from the front to avoid running out of disk space. Here is my function: int trim(int fd, unsigned long long offset) { struct xfs_flock64 flock; int rc; flock.l_whence = 0; flock.l_start = 0; flock.l_len = offset; rc = ioctl( fd, XFS_IOC_UNRESVSP, &flock ); printf("rc: %d\n", rc); } When I put an XFS_IOC_FREESP in then it makes a zero length file. If I put XFS_IOC_UNRESVSP in then it looks like it pokes a hole in the whole file. Am I trying to do something that XFS on linux won't do? thanks, Ian Eric Sandeen wrote: > Hi Ian - > > Sorry, I'm not an expert on this, but perhaps this will make a decent > preliminary answer. > > >From xfs_vfsops.c, these comments are in xfs_change_file_space() > > /* > * XFS_IOC_RESVSP and XFS_IOC_UNRESVSP will reserve or unreserve > * file space. > * These calls do NOT zero the data space allocated to the file, > * nor do they change the file size. > * > * XFS_IOC_ALLOCSP and XFS_IOC_FREESP will allocate and free file > * space. > * These calls cause the new file data to be zeroed and the file > * size to be changed. > */ > > Irix also has this to say in the fcntl man page: > > F_FREESP Alter storage space associated with a section of the ordinary > file fildes. The section is specified by a variable of data > type struct flock pointed to by the third argument arg. The > data type struct flock is defined in the header file > [see fcntl(5)] and contains the following members: l_whence is > 0, 1, or 2 to indicate that the relative offset l_start will be > measured from the start of the file, the current position, or > the end of the file, respectively. l_start is the offset from > the position specified in l_whence. l_len is the size of the > section. An l_len of 0 frees up to the end of the file; in > this case, the end of file (i.e., file size) is set to the > beginning of the section freed. Any data previously written > into this section is no longer accessible. If the section > specified is beyond the current end of file, the file is grown > and filled with zeroes. The l_len field is currently ignored, > and should be set to 0. > > F_UNRESVSP > This command is used to free space from a file. A range of > bytes is specified with the struct flock. Partial filesystem > blocks are zeroed, and whole filesystem blocks are removed from > the file. The file size does not change. It is only supported > on XFS and BDS filesystems. > > "Ian S. Nelson" wrote: > > > > What's the difference between these two ioctls and are they both > > implemented on Linux? > > > > I've been trying to "trim" the front a file with FREESP and I keep > > getting 0 length files. > > > > thanks, > > Ian > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Oct 8 15:00:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98M0pA27380 for linux-xfs-outgoing; Mon, 8 Oct 2001 15:00:51 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98M0mD27355 for ; Mon, 8 Oct 2001 15:00:49 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id AAA05170; Tue, 9 Oct 2001 00:00:47 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id AAA01066; Tue, 9 Oct 2001 00:00:46 +0200 (CEST) Date: Tue, 9 Oct 2001 00:00:46 +0200 (CEST) From: Seth Mos To: "Gonyou, Austin" cc: "'Steve Lord'" , khromy , linux-xfs@oss.sgi.com Subject: RE: 2.4.10-pre13-xfs Unresolved symbols in pagebuf.o In-Reply-To: <85063BBE668FD411944400D0B744267A8885B5@AUSMAIL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 24 Sep 2001, Gonyou, Austin wrote: > Why can't I connect to oss.sgi.com ftp or http? Is there a problem somewhere > in the country with backbones or is it just oss.sgi.com is down? Please > advise. It works from the Netherlands. Cvs, ftp, http are all up. Note to people trying. Ping is filtered out by their firewall. Cheers Seth From owner-linux-xfs@oss.sgi.com Mon Oct 8 15:25:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98MP3c27857 for linux-xfs-outgoing; Mon, 8 Oct 2001 15:25:03 -0700 Received: from artax.karlin.mff.cuni.cz (root@artax.karlin.mff.cuni.cz [195.113.31.125]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98MP0D27835 for ; Mon, 8 Oct 2001 15:25:00 -0700 Received: from localhost (mikulas@localhost) by artax.karlin.mff.cuni.cz (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id AAA20727; Tue, 9 Oct 2001 00:21:04 +0200 Date: Tue, 9 Oct 2001 00:21:04 +0200 (CEST) From: Mikulas Patocka To: Alan Cox cc: Rik van Riel , Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: %u-order allocation failed In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 7 Oct 2001, Alan Cox wrote: > > The difference between memory and vmalloc space is this: you fill up the > > whole memory with cache => memory fragments. You don't fill up the whole > > vmalloc space with anything => vmalloc space doesn't fragment. > > vmalloc space fragments. You fragment address space rather than pages thats > all. Same problem If you have more than half of virtual space free, you can always find two consecutive free pages. Period. You can fill up half of virtual space if you start 4096 processes or load many modules of total size 32M. Is it clear? Do you realize that no one will ever hit this limit in typical linux configuration? Mikulas From owner-linux-xfs@oss.sgi.com Mon Oct 8 15:37:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98MbBA28224 for linux-xfs-outgoing; Mon, 8 Oct 2001 15:37:11 -0700 Received: from warden.diginsite.com (warden.digitalinsight.com [208.29.163.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98Mb4D28202 for ; Mon, 8 Oct 2001 15:37:07 -0700 Received: from wlvexc01.diginsite.com by warden.diginsite.com via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 8 Oct 2001 22:37:04 UT Received: by wlvexc01.diginsite.com with Internet Mail Service (5.5.2653.19) id <42JDJ24G>; Mon, 8 Oct 2001 15:36:59 -0700 Received: from [10.201.10.67] (dlang.diginsite.com [10.201.10.67]) by viper.digitalinsight.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SCTK75B2; Mon, 8 Oct 2001 15:36:53 -0700 From: David Lang To: Mikulas Patocka Cc: Alan Cox , Rik van Riel , Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Date: Mon, 8 Oct 2001 14:16:04 -0700 (PDT) Subject: Re: %u-order allocation failed In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk only 4096 processes, sounds low to me (I realize that some of my configs are not typical, but this isn't that unusual on servers) does this limit go up if you raise the max number of processes/threads? David Lang On Tue, 9 Oct 2001, Mikulas Patocka wrote: > Date: Tue, 9 Oct 2001 00:21:04 +0200 (CEST) > From: Mikulas Patocka > To: Alan Cox > Cc: Rik van Riel , > Krzysztof Rusocki , linux-xfs@oss.sgi.com, > linux-kernel@vger.kernel.org > Subject: Re: %u-order allocation failed > > On Sun, 7 Oct 2001, Alan Cox wrote: > > > > The difference between memory and vmalloc space is this: you fill up the > > > whole memory with cache => memory fragments. You don't fill up the whole > > > vmalloc space with anything => vmalloc space doesn't fragment. > > > > vmalloc space fragments. You fragment address space rather than pages thats > > all. Same problem > > If you have more than half of virtual space free, you can always find two > consecutive free pages. Period. > > You can fill up half of virtual space if you start 4096 processes or load > many modules of total size 32M. Is it clear? Do you realize that no one > will ever hit this limit in typical linux configuration? > > Mikulas > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > From owner-linux-xfs@oss.sgi.com Mon Oct 8 15:53:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98MrQe28602 for linux-xfs-outgoing; Mon, 8 Oct 2001 15:53:26 -0700 Received: from shed.alex.org.uk (shed.alex.org.uk [195.224.53.219]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98MrND28580 for ; Mon, 8 Oct 2001 15:53:24 -0700 Received: from [195.224.237.69] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id F30B9A4CB; Mon, 8 Oct 2001 23:53:21 +0100 (BST) Date: Mon, 08 Oct 2001 23:53:18 +0100 From: Alex Bligh - linux-kernel Reply-To: Alex Bligh - linux-kernel To: Mikulas Patocka , Alan Cox Cc: Rik van Riel , Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org, Alex Bligh - linux-kernel Subject: Re: %u-order allocation failed Message-ID: <653073165.1002585197@[195.224.237.69]> In-Reply-To: References: X-Mailer: Mulberry/2.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --On Tuesday, 09 October, 2001 12:21 AM +0200 Mikulas Patocka wrote: > If you have more than half of virtual space free, you can always find two > consecutive free pages. Period. Now calculate the probability of not being able to do this in physical space, assuming even page dispersion, and many pages free. You will find it is very small. This may give you a clue as to what the problem actually is. -- Alex Bligh From owner-linux-xfs@oss.sgi.com Mon Oct 8 16:17:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98NHQq29186 for linux-xfs-outgoing; Mon, 8 Oct 2001 16:17:26 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98NHMD29156 for ; Mon, 8 Oct 2001 16:17:22 -0700 Received: from mail.computalog.com (mail.computalog.com [209.82.103.230]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA09365 for ; Mon, 24 Sep 2001 13:17:34 -0700 (PDT) mail_from (gerry.patterson@computalog.com) Received: from gerry.edmonton.computalog.com (mugeri.computalog.com [209.82.103.229]) by mail.computalog.com (8.8.8/8.8.8) with ESMTP id OAA22603; Mon, 24 Sep 2001 14:12:18 -0600 Received: by gerry.edmonton.computalog.com (Postfix, from userid 1000) id 34638165E43; Mon, 24 Sep 2001 14:16:50 -0600 (MDT) Date: Mon, 24 Sep 2001 14:16:50 -0600 From: "Gerard W. Patterson" To: Russ Ingram Cc: linux-xfs@oss.sgi.com Subject: Re: .deb kernel packages Message-ID: <20010924141650.A7619@computalog.com> References: <3BAF55CC.B35ED24@uwyo.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3BAF55CC.B35ED24@uwyo.edu> User-Agent: Mutt/1.3.20i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Sep 24, 2001 at 09:48:28AM -0600, Russ Ingram wrote: > I was just wondering how many people on this list are running > debian and would be interested in having .deb kernel packages. I > just learned how to make kernel packages on debian and would be > willing to provide them if there is enough interest. > > Russ > -- > Russel H. Ingram > Unix Systems Administrator > Institute for Scientific Computation > University of Wyoming/Math Dept. > Phone: (307)766-6546 > E-Mail: ringram@uwyo.edu I am currently running Debian using the XFS kernels and have been for some time now. Usually I just copy the directory and do a 'make-kpkg debian' in the tree to setup the directory. Some pre-compiled would be nice but the rate at which this tree gets updated...whoeee! lotsa packages. How would you decide what to compile as modules and what should be compiled in? If you would like someone to help or feed back let me know... Regards, Gerry -- Gerard W. Patterson, B.Sc | Computalog Ltd. Software Engineering | Edmonton, AB | Canada From owner-linux-xfs@oss.sgi.com Mon Oct 8 16:32:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98NWmk29456 for linux-xfs-outgoing; Mon, 8 Oct 2001 16:32:48 -0700 Received: from artax.karlin.mff.cuni.cz (root@artax.karlin.mff.cuni.cz [195.113.31.125]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98NWhD29434 for ; Mon, 8 Oct 2001 16:32:43 -0700 Received: from localhost (mikulas@localhost) by artax.karlin.mff.cuni.cz (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id BAA14911; Tue, 9 Oct 2001 01:31:59 +0200 Date: Tue, 9 Oct 2001 01:31:59 +0200 (CEST) From: Mikulas Patocka To: torvalds@transmeta.com cc: Alan Cox , Rik van Riel , Alex Bligh - linux-kernel , Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: %u-order allocation failed In-Reply-To: <653073165.1002585197@[195.224.237.69]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 8 Oct 2001, Alex Bligh - linux-kernel wrote: > --On Tuesday, 09 October, 2001 12:21 AM +0200 Mikulas Patocka > wrote: > > > If you have more than half of virtual space free, you can always find two > > consecutive free pages. Period. > > Now calculate the probability of not being able to do this in physical > space, assuming even page dispersion, and many pages free. You will > find it is very small. This may give you a clue as to what the problem > actually is. My patch is not providing "very small probability". It is providing _zero_ probability that fork fails. (assiming that there is more than half vmalloc space free). I'm just tired of this stupid flamewar. Linus, what do you think: is it OK if fork randomly fails with very small probability or not? Are you going to accept patch that maps task_struct into virtual space if buddy allocator fails or not? Mikulas From owner-linux-xfs@oss.sgi.com Mon Oct 8 16:40:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98Ne3d29672 for linux-xfs-outgoing; Mon, 8 Oct 2001 16:40:03 -0700 Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98Ne0D29648 for ; Mon, 8 Oct 2001 16:40:00 -0700 Received: from alan by the-village.bc.nu with local (Exim 3.22 #1) id 15qk40-0002Jf-00; Tue, 09 Oct 2001 00:44:00 +0100 Subject: Re: %u-order allocation failed To: mikulas@artax.karlin.mff.cuni.cz (Mikulas Patocka) Date: Tue, 9 Oct 2001 00:44:00 +0100 (BST) Cc: torvalds@transmeta.com, alan@lxorguk.ukuu.org.uk (Alan Cox), riel@conectiva.com.br (Rik van Riel), linux-kernel@alex.org.uk (Alex Bligh - linux-kernel), kszysiu@main.braxis.co.uk (Krzysztof Rusocki), linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org In-Reply-To: from "Mikulas Patocka" at Oct 09, 2001 01:31:59 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Linus, what do you think: is it OK if fork randomly fails with very small > probability or not? Your code doesnt change that behaviour. Not one iota. Do the mathematics, work out the failure probabilities for page pairs. Now remember that the vmalloc one has guard pages too. You are trying to solve a non problem with a non solution Alan From owner-linux-xfs@oss.sgi.com Mon Oct 8 16:45:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98Njv529890 for linux-xfs-outgoing; Mon, 8 Oct 2001 16:45:57 -0700 Received: from ente.berdmann.de (frnk-d514e189.dsl.mediaWays.net [213.20.225.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98NjtD29868 for ; Mon, 8 Oct 2001 16:45:55 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 15qk5k-00074F-00 for linux-xfs@oss.sgi.com; Tue, 09 Oct 2001 01:45:48 +0200 Message-ID: <3BC23AAC.1786D207@berdmann.de> Date: Tue, 09 Oct 2001 01:45:48 +0200 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.10-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: TAKE - Improvement request for xfsdump/xfsrestore exit codes References: <200110080658.QAA77586@snort.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > This fixes catches some user-initiated interruptions that were previously missed, > and fixes a coredump on linux. The coredump xfsrestore does when you stop feeding the pipe to | xfsrestore - . ? From owner-linux-xfs@oss.sgi.com Mon Oct 8 16:47:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98Nl9I30025 for linux-xfs-outgoing; Mon, 8 Oct 2001 16:47:09 -0700 Received: from artax.karlin.mff.cuni.cz (root@artax.karlin.mff.cuni.cz [195.113.31.125]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98Nl6D30003 for ; Mon, 8 Oct 2001 16:47:06 -0700 Received: from localhost (mikulas@localhost) by artax.karlin.mff.cuni.cz (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id BAA15808; Tue, 9 Oct 2001 01:46:52 +0200 Date: Tue, 9 Oct 2001 01:46:52 +0200 (CEST) From: Mikulas Patocka To: Alan Cox cc: torvalds@transmeta.com, Rik van Riel , Alex Bligh - linux-kernel , Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: %u-order allocation failed In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 9 Oct 2001, Alan Cox wrote: > > Linus, what do you think: is it OK if fork randomly fails with very small > > probability or not? > > Your code doesnt change that behaviour. Not one iota. Do the mathematics, > work out the failure probabilities for page pairs. Now remember that the > vmalloc one has guard pages too. > > You are trying to solve a non problem with a non solution I asked Linus, not you :-/ It's up to him, if he wants "stability-based-on-probability" algorithms in Linux or not. Mikulas From owner-linux-xfs@oss.sgi.com Mon Oct 8 16:49:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98Nns430198 for linux-xfs-outgoing; Mon, 8 Oct 2001 16:49:54 -0700 Received: from neon-gw.transmeta.com (neon-gw-l3.transmeta.com [63.209.4.196]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98NnqD30175 for ; Mon, 8 Oct 2001 16:49:52 -0700 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id QAA05191; Mon, 8 Oct 2001 16:49:39 -0700 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma005159; Mon, 8 Oct 01 16:49:11 -0700 Received: from penguin.transmeta.com (penguin.transmeta.com [10.10.27.78]) by deepthought.transmeta.com (8.9.3/8.9.3) with ESMTP id QAA13835; Mon, 8 Oct 2001 16:49:15 -0700 (PDT) Received: from localhost (torvalds@localhost) by penguin.transmeta.com (8.11.2/8.7.3) with ESMTP id f98NmUB01070; Mon, 8 Oct 2001 16:48:30 -0700 X-Authentication-Warning: penguin.transmeta.com: torvalds owned process doing -bs Date: Mon, 8 Oct 2001 16:48:30 -0700 (PDT) From: Linus Torvalds To: Mikulas Patocka cc: Alan Cox , Rik van Riel , Alex Bligh - linux-kernel , Krzysztof Rusocki , , Subject: Re: %u-order allocation failed In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 9 Oct 2001, Mikulas Patocka wrote: > > Linus, what do you think: is it OK if fork randomly fails with very small > probability or not? I've never seen it, I've never heard it reported, and I _know_ that vmalloc() causes slowdowns. In short, I'm not switching to a vmalloc() fork. Linus From owner-linux-xfs@oss.sgi.com Mon Oct 8 16:55:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98Nt6R30417 for linux-xfs-outgoing; Mon, 8 Oct 2001 16:55:06 -0700 Received: from artax.karlin.mff.cuni.cz (root@artax.karlin.mff.cuni.cz [195.113.31.125]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98Nt3D30395 for ; Mon, 8 Oct 2001 16:55:03 -0700 Received: from localhost (mikulas@localhost) by artax.karlin.mff.cuni.cz (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id BAA16360; Tue, 9 Oct 2001 01:54:49 +0200 Date: Tue, 9 Oct 2001 01:54:49 +0200 (CEST) From: Mikulas Patocka To: Linus Torvalds cc: Alan Cox , Rik van Riel , Alex Bligh - linux-kernel , Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: %u-order allocation failed In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 8 Oct 2001, Linus Torvalds wrote: > > On Tue, 9 Oct 2001, Mikulas Patocka wrote: > > > > Linus, what do you think: is it OK if fork randomly fails with very small > > probability or not? > > I've never seen it, I've never heard it reported, and I _know_ that > vmalloc() causes slowdowns. > > In short, I'm not switching to a vmalloc() fork. The patch uses buddy by default and does vmalloc only if buddy fails. Slowdown is not an issue here. Mikulas From owner-linux-xfs@oss.sgi.com Mon Oct 8 16:56:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98Nusx30574 for linux-xfs-outgoing; Mon, 8 Oct 2001 16:56:54 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98NupD30552 for ; Mon, 8 Oct 2001 16:56:51 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with SMTP id f98NujK22873 for ; Mon, 8 Oct 2001 16:56:45 -0700 Received: from fudge.melbourne.sgi.com (fudge.melbourne.sgi.com [134.14.55.184]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA23837; Tue, 9 Oct 2001 09:55:29 +1000 Received: (from ajag@localhost) by fudge.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id JAA04592; Tue, 9 Oct 2001 09:55:23 +1000 (EST) Date: Tue, 9 Oct 2001 09:55:23 +1000 From: Andrew Gildfind To: "Bernhard R. Erdmann" Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - Improvement request for xfsdump/xfsrestore exit codes Message-ID: <20011009095523.A4575@fudge.melbourne.sgi.com> References: <200110080658.QAA77586@snort.melbourne.sgi.com> <3BC23AAC.1786D207@berdmann.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <3BC23AAC.1786D207@berdmann.de>; from be@berdmann.de on Tue, Oct 09, 2001 at 01:45:48AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Oct 09, 2001 at 01:45:48AM +0200, Bernhard R. Erdmann wrote: > > This fixes catches some user-initiated interruptions that were previously missed, > > and fixes a coredump on linux. > > The coredump xfsrestore does when you stop feeding the pipe to | > xfsrestore - . ? Yes, I think the fix should address that. Although that's not the coredump I observed: just ^C'ing it would cause a coredump as well. The underlying problem is the dump/restore status needs to be initialised (with a call to mlog_exit) from every exit() call in the code. I missed a couple, and any of those exits() would dump. I've fixed those up, and changed the code so that if the status is not setup correctly it won't crash. Let us know how it goes. Andrew -- Andrew Gildfind - R&D Software Engineer - SGI Melbourne Australia email: ajag@sgi.com - work: +61.3.9834.8200 mobile: 0412.834.183 From owner-linux-xfs@oss.sgi.com Mon Oct 8 18:18:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f991IcG32197 for linux-xfs-outgoing; Mon, 8 Oct 2001 18:18:38 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f991IZD32170 for ; Mon, 8 Oct 2001 18:18:35 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAB02298 for ; Mon, 8 Oct 2001 18:18:34 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id LAA03671; Tue, 9 Oct 2001 11:18:27 +1000 Date: Tue, 9 Oct 2001 11:18:27 +1000 From: Keith Owens Message-Id: <200110090118.LAA03671@sherman.melbourne.sgi.com> Subject: TAKE - Upgrade kbuild 2.5 files to 2.4.11-pre5 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk kbuild 2.5 now prevents kernel files fr9om accidentally using user space include files, except for gcc install files. kdb deliberately uses bfd.h and ansidecl.h from user space so the Makefile.in files need to be changed. The kdb patch may be changed later to include copies of the user space files. Date: Mon Oct 8 18:14:32 PDT 2001 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:104168a linux/include/linux/module.h - 1.26 linux/arch/i386/kdb/Makefile.in - 1.2 linux/fs/xfs/Makefile.in - 1.3 linux/kdb/Makefile.in - 1.2 linux/kdb/modules/Makefile.in - 1.2 From owner-linux-xfs@oss.sgi.com Mon Oct 8 18:18:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f991Iqh32267 for linux-xfs-outgoing; Mon, 8 Oct 2001 18:18:52 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f991IeD32209 for ; Mon, 8 Oct 2001 18:18:40 -0700 Received: from gumby.uwyo.edu (gumby.uwyo.edu [129.72.5.18]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA01141 for ; Mon, 24 Sep 2001 11:38:10 -0700 (PDT) mail_from (ringram@uwyo.edu) Received: from uwyo.edu (localhost [127.0.0.1]) by gumby.uwyo.edu (8.11.6/8.11.6) with ESMTP id f8OIcaK25045; Mon, 24 Sep 2001 12:38:41 -0600 Message-ID: <3BAF7DAC.82267415@uwyo.edu> Date: Mon, 24 Sep 2001 12:38:36 -0600 From: Russ Ingram Organization: UW Math Dept/Institute for Scientific Computation X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.10-pre10-xfs-091701 i686) X-Accept-Language: en MIME-Version: 1.0 To: rvt@dds.nl CC: linux-xfs@oss.sgi.com Subject: Re: .deb kernel packages References: <3BAF55CC.B35ED24@uwyo.edu> <3BAF768F.6077E1F3@dds.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ries van twisk wrote: > > Russ Ingram wrote: > > > > I was just wondering how many people on this list are running > > debian and would be interested in having .deb kernel packages. I > > just learned how to make kernel packages on debian and would be > > willing to provide them if there is enough interest. > > I run Debian on my systems. I'm running xfs on a 2.4.9 kernel. > Peronally I don't need a deb package for a XFS kernel but I think a lot > of people just needs them for easy installation of a XFS enabled Debian > setup. Most people have problems/afraid to compile/just don't know how > to compile there own kernel. XFS patching in a vanilla kernel is just to > differcult for those who never done a kernel compilation. > > My point is yes create a debian package. I would suggest contact the > Linux Dell group and ask them for a pointer to your webside since I now > there are a lot of Debian Dell users. XFS would be great to have on a > Dell system like I have. > > Ries If I make them available to others at all I intend to actually become a contributing package maintainer for the Debian distro. I would also ask for space on oss.sgi.com to put the packages on the oss.sgi.com server to complement the rpm packages. I will definitely contact the Dell group as well, though, if you can supply me with a pointer to them. Thanx, Russ -- Russel H. Ingram Unix Systems Administrator Institute for Scientific Computation University of Wyoming/Math Dept. Phone: (307)766-6546 E-Mail: ringram@uwyo.edu From owner-linux-xfs@oss.sgi.com Mon Oct 8 22:01:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9951H403925 for linux-xfs-outgoing; Mon, 8 Oct 2001 22:01:17 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f99515D03894 for ; Mon, 8 Oct 2001 22:01:05 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9950xW28350 for ; Mon, 8 Oct 2001 22:01:00 -0700 Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id PAA02464; Tue, 9 Oct 2001 15:00:37 +1000 Date: Tue, 9 Oct 2001 15:00:37 +1000 From: Keith Owens Message-Id: <200110090500.PAA02464@sherman.melbourne.sgi.com> Subject: TAKE - Upgrade XFS to 2.4.11-pre6 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Upgrade XFS to 2.4.11-pre6 Date: Mon Oct 8 21:57:53 PDT 2001 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:104174a linux/drivers/ide/ide-m8xx.c - 1.1 linux/include/asm-ppc/commproc.h - 1.1 linux/include/asm-cris/tlb.h - 1.1 linux/scripts/split-include.c - 1.3 linux/net/sunrpc/xprt.c - 1.20 linux/mm/vmscan.c - 1.80 linux/mm/swap_state.c - 1.33 linux/mm/page_alloc.c - 1.59 linux/include/linux/smbno.h - 1.4 linux/include/linux/module.h - 1.27 linux/include/asm-ppc/ide.h - 1.13 linux/include/asm-i386/unistd.h - 1.17 linux/fs/smbfs/proc.c - 1.13 linux/fs/lockd/clntproc.c - 1.14 linux/drivers/usb/uhci.h - 1.24 linux/drivers/usb/uhci.c - 1.49 linux/drivers/char/Makefile - 1.49 linux/drivers/block/rd.c - 1.37 linux/drivers/block/paride/paride.c - 1.9 linux/arch/ppc/kernel/time.c - 1.16 linux/arch/ppc/kernel/residual.c - 1.8 linux/arch/ppc/kernel/process.c - 1.33 linux/arch/ppc/kernel/ppc_ksyms.c - 1.36 linux/arch/ppc/8xx_io/uart.c - 1.15 linux/arch/ppc/8xx_io/fec.c - 1.15 linux/arch/ppc/8xx_io/enet.c - 1.15 linux/arch/ppc/8xx_io/commproc.h - 1.10 linux/arch/ppc/8xx_io/commproc.c - 1.10 linux/arch/i386/kernel/entry.S - 1.39 linux/arch/i386/defconfig - 1.74 linux/arch/alpha/kernel/smp.c - 1.26 linux/Makefile - 1.131 linux/Documentation/Configure.help - 1.106 linux/arch/ppc/xmon/xmon.c - 1.17 linux/drivers/parport/share.c - 1.18 linux/drivers/parport/parport_pc.c - 1.38 linux/drivers/scsi/ips.c - 1.19 linux/arch/ppc/kernel/m8xx_setup.c - 1.17 linux/include/linux/pci_ids.h - 1.46 linux/include/asm-ppc/walnut.h - 1.4 linux/include/asm-ppc/oak.h - 1.5 linux/kernel/timer.c - 1.14 linux/drivers/usb/uhci-debug.h - 1.8 linux/drivers/ieee1394/Makefile - 1.8 linux/Documentation/filesystems/devfs/ChangeLog - 1.12 linux/fs/devfs/base.c - 1.21 linux/drivers/parport/ChangeLog - 1.19 linux/drivers/ide/ide_modes.h - 1.4 linux/drivers/ide/ide.c - 1.31 linux/drivers/ide/Makefile - 1.12 linux/drivers/ide/Config.in - 1.15 linux/arch/ppc/xmon/start_8xx.c - 1.3 linux/arch/ppc/kernel/m8260_setup.c - 1.11 linux/arch/ppc/8260_io/enet.c - 1.8 linux/drivers/video/sis/Makefile - 1.3 linux/fs/reiserfs/stree.c - 1.8 linux/fs/reiserfs/tail_conversion.c - 1.6 linux/fs/reiserfs/objectid.c - 1.4 linux/fs/reiserfs/namei.c - 1.9 linux/fs/reiserfs/lbalance.c - 1.3 linux/fs/reiserfs/journal.c - 1.9 linux/fs/reiserfs/item_ops.c - 1.3 linux/fs/reiserfs/inode.c - 1.14 linux/fs/reiserfs/ibalance.c - 1.3 linux/fs/reiserfs/fix_node.c - 1.8 linux/fs/reiserfs/do_balan.c - 1.4 linux/fs/reiserfs/dir.c - 1.6 linux/fs/reiserfs/buffer2.c - 1.3 linux/include/linux/reiserfs_fs.h - 1.9 linux/fs/reiserfs/bitmap.c - 1.5 linux/arch/cris/Makefile - 1.7 linux/arch/cris/config.in - 1.6 linux/arch/cris/cris.ld - 1.6 linux/arch/cris/defconfig - 1.7 linux/arch/cris/drivers/Config.in - 1.5 linux/arch/cris/drivers/axisflashmap.c - 1.5 linux/arch/cris/drivers/ethernet.c - 1.6 linux/arch/cris/drivers/serial.c - 1.7 linux/arch/cris/drivers/serial.h - 1.4 linux/arch/cris/kernel/Makefile - 1.6 linux/arch/cris/kernel/entry.S - 1.8 linux/arch/cris/kernel/head.S - 1.7 linux/arch/cris/kernel/ksyms.c - 1.2 linux/arch/cris/kernel/process.c - 1.8 linux/arch/cris/kernel/ptrace.c - 1.7 linux/arch/cris/kernel/setup.c - 1.7 linux/arch/cris/kernel/signal.c - 1.5 linux/arch/cris/lib/checksum.S - 1.5 linux/arch/cris/lib/checksumcopy.S - 1.6 linux/arch/cris/lib/memset.c - 1.3 linux/arch/cris/lib/string.c - 1.3 linux/arch/cris/lib/usercopy.c - 1.3 linux/arch/cris/mm/extable.c - 1.3 linux/include/asm-cris/uaccess.h - 1.2 linux/include/asm-cris/system.h - 1.3 linux/include/asm-cris/bitops.h - 1.4 linux/include/asm-cris/checksum.h - 1.3 linux/include/asm-cris/current.h - 1.2 linux/include/asm-cris/delay.h - 1.6 linux/include/asm-cris/processor.h - 1.7 linux/include/asm-cris/pgtable.h - 1.3 linux/include/asm-cris/module.h - 1.3 linux/include/asm-cris/irq.h - 1.7 linux/include/asm-cris/io.h - 1.6 linux/include/asm-ppc/spd8xx.h - 1.3 linux/arch/ppc/configs/TQM860L_defconfig - 1.8 linux/arch/ppc/configs/IVMS8_defconfig - 1.8 linux/arch/cris/boot/rescue/Makefile - 1.2 linux/arch/cris/boot/rescue/head.S - 1.3 linux/arch/cris/boot/rescue/kimagerescue.S - 1.3 linux/arch/cris/boot/rescue/rescue.ld - 1.2 linux/arch/cris/boot/rescue/testrescue.S - 1.3 linux/arch/cris/drivers/usb-host.c - 1.7 linux/arch/cris/lib/dram_init.S - 1.5 linux/arch/ppc/boot/prep/Makefile - 1.5 linux/arch/ppc/boot/mbx/m8xx_tty.c - 1.2 linux/arch/ppc/boot/mbx/iic.c - 1.2 linux/arch/cris/drivers/lpslave/bintocarr.pl - 1.3 linux/drivers/parport/parport_serial.c - 1.4 linux/arch/cris/lib/csumcpfruser.S - 1.2 linux/arch/ppc/kernel/cputable.c - 1.2 From owner-linux-xfs@oss.sgi.com Mon Oct 8 22:03:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f99535u04059 for linux-xfs-outgoing; Mon, 8 Oct 2001 22:03:05 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9952hD04023 for ; Mon, 8 Oct 2001 22:02:43 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with SMTP id f9952bK30694 for ; Mon, 8 Oct 2001 22:02:37 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA25796; Tue, 9 Oct 2001 15:01:16 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA77897; Tue, 9 Oct 2001 15:01:14 +1000 (AEDT) Date: Tue, 9 Oct 2001 15:01:14 +1000 From: Nathan Scott To: Linus Torvalds , Alan Cox Cc: Andreas Gruenbacher , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [PATCH] Re: ENOATTR and other error enums Message-ID: <20011009150113.A497835@wobbly.melbourne.sgi.com> References: <200110060624.f966OeV30354@monkeyiq.dnsalias.org> <20011008122201.W472533@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011008122201.W472533@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Mon, Oct 08, 2001 at 12:22:02PM +1100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hi fellas, Here is an errno.h patch which provides these new errno values. XFS needs both values. ENOATTR is also required by the ext2 extended attributes project (and any other filesystem intending to implement extended attributes in the future). Both values need to be visible in both kernel and user space, so this patch would be an initial step toward libc support also, hopefully. In the absence of any cleaner way to do this (?), could we have this patch applied please? Any/all feedback much appreciated -- thanks. cheers. On Mon, Oct 08, 2001 at 12:22:02PM +1100, Nathan Scott wrote: > hi there, > > On Sat, Oct 06, 2001 at 04:24:40PM +1000, monkeyiq wrote: > > Hi, > > Anyone know where these are defined in Linux? I dont seem > > to be able to find them, even with find/grep in /usr/include. > > ENOATTR is not a blessed errno in Linux. In XFS we have simply > defined it to be the same as ENODATA for the time being. The > ext2 extended attributes project define it to be EDOM, also as > a stop-gap solution I imagine. > > A similar problem exists with ENOTSUP (defined by POSIX 1003.1b?) > - this is only supported via linux/asm-parisc/errno.h as a real > errno, among all the architectures. Both the XFS and ext2 extended > attributes implementations define this errno to be EOPNOTSUPP as an > interim solution. Ah, wait - from a quick test, glibc does seem to > do exactly this also, so this one is not a problem (except perhaps > on the parisc port? -- hmm, that could actually be a bug on parisc). > > On a related topic, but not specific to extended attributes - for > XFS in general, we needed one other errno - EFSCORRUPTED. This is > used when XFS goes into forced shutdown mode for a filesystem that > has been detected as on-disk corrupt, to stop making the situation > any worse (user must umount/xfs_repair). We couldn't find any pre- > existing Linux errno vaguely similar to this one, so it was defined > to "990" until a real solution could be found. > > Obviously, these are not the correct long-term solutions ... they > need to become real Linux errno's, I think, and ENOTSUP could be > defined to EOPNOTSUPP? - EWOULDBLOCK, EDEADLOCK seem to do this. > I'm not sure how to reach that point though (CC'ing linux-kernel > for any advice) - for reference, in IRIX these errnos are defined > as follows: > > ENOATTR = Attribute not found > EFSCORRUPTED = Filesystem is corrupted > > > Also, is there a function to get a string rep of the error > > that occured in the attr code? > > Someday it should become a part of asm-XXXXX/errno.h (errno's are > architecture specific) and the libc strerror(3) routine should be > able to provide a meaningful string. But currently that does not > happen. > > cheers. > > -- > Nathan -- Nathan --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="errno.patch" diff -Naur linux-vanilla/include/asm-alpha/errno.h linux-errno/include/asm-alpha/errno.h --- linux-vanilla/include/asm-alpha/errno.h Sat Feb 10 06:40:02 2001 +++ linux-errno/include/asm-alpha/errno.h Tue Oct 9 11:15:13 2001 @@ -138,5 +138,7 @@ #define ENOMEDIUM 129 /* No medium found */ #define EMEDIUMTYPE 130 /* Wrong medium type */ +#define EFSCORRUPTED 131 /* Filesystem is corrupted */ +#define ENOATTR 132 /* No such attribute */ #endif diff -Naur linux-vanilla/include/asm-arm/errno.h linux-errno/include/asm-arm/errno.h --- linux-vanilla/include/asm-arm/errno.h Wed Jan 21 11:39:42 1998 +++ linux-errno/include/asm-arm/errno.h Tue Oct 9 11:22:29 2001 @@ -128,5 +128,7 @@ #define ENOMEDIUM 123 /* No medium found */ #define EMEDIUMTYPE 124 /* Wrong medium type */ +#define EFSCORRUPTED 125 /* Filesystem is corrupted */ +#define ENOATTR 126 /* No such attribute */ #endif diff -Naur linux-vanilla/include/asm-cris/errno.h linux-errno/include/asm-cris/errno.h --- linux-vanilla/include/asm-cris/errno.h Fri Feb 9 11:32:44 2001 +++ linux-errno/include/asm-cris/errno.h Tue Oct 9 11:22:41 2001 @@ -130,5 +130,7 @@ #define ENOMEDIUM 123 /* No medium found */ #define EMEDIUMTYPE 124 /* Wrong medium type */ +#define EFSCORRUPTED 125 /* Filesystem is corrupted */ +#define ENOATTR 126 /* No such attribute */ #endif diff -Naur linux-vanilla/include/asm-i386/errno.h linux-errno/include/asm-i386/errno.h --- linux-vanilla/include/asm-i386/errno.h Sat Feb 10 06:40:02 2001 +++ linux-errno/include/asm-i386/errno.h Tue Oct 9 11:23:02 2001 @@ -128,5 +128,7 @@ #define ENOMEDIUM 123 /* No medium found */ #define EMEDIUMTYPE 124 /* Wrong medium type */ +#define EFSCORRUPTED 125 /* Filesystem is corrupted */ +#define ENOATTR 126 /* No such attribute */ #endif diff -Naur linux-vanilla/include/asm-ia64/errno.h linux-errno/include/asm-ia64/errno.h --- linux-vanilla/include/asm-ia64/errno.h Wed Apr 11 05:23:06 2001 +++ linux-errno/include/asm-ia64/errno.h Tue Oct 9 11:23:12 2001 @@ -135,5 +135,7 @@ #define ENOMEDIUM 123 /* No medium found */ #define EMEDIUMTYPE 124 /* Wrong medium type */ +#define EFSCORRUPTED 125 /* Filesystem is corrupted */ +#define ENOATTR 126 /* No such attribute */ #endif /* _ASM_IA64_ERRNO_H */ diff -Naur linux-vanilla/include/asm-m68k/errno.h linux-errno/include/asm-m68k/errno.h --- linux-vanilla/include/asm-m68k/errno.h Sat Feb 10 06:40:02 2001 +++ linux-errno/include/asm-m68k/errno.h Tue Oct 9 11:23:24 2001 @@ -128,5 +128,7 @@ #define ENOMEDIUM 123 /* No medium found */ #define EMEDIUMTYPE 124 /* Wrong medium type */ +#define EFSCORRUPTED 125 /* Filesystem is corrupted */ +#define ENOATTR 126 /* No such attribute */ #endif /* _M68K_ERRNO_H */ diff -Naur linux-vanilla/include/asm-mips/errno.h linux-errno/include/asm-mips/errno.h --- linux-vanilla/include/asm-mips/errno.h Tue Jul 3 06:56:40 2001 +++ linux-errno/include/asm-mips/errno.h Tue Oct 9 11:14:37 2001 @@ -141,6 +141,8 @@ */ #define ENOMEDIUM 159 /* No medium found */ #define EMEDIUMTYPE 160 /* Wrong medium type */ +#define EFSCORRUPTED 161 /* Filesystem is corrupted */ +#define ENOATTR 162 /* No such attribute */ #define EDQUOT 1133 /* Quota exceeded */ diff -Naur linux-vanilla/include/asm-mips64/errno.h linux-errno/include/asm-mips64/errno.h --- linux-vanilla/include/asm-mips64/errno.h Sat Apr 14 13:26:07 2001 +++ linux-errno/include/asm-mips64/errno.h Tue Oct 9 11:17:07 2001 @@ -142,6 +142,8 @@ */ #define ENOMEDIUM 159 /* No medium found */ #define EMEDIUMTYPE 160 /* Wrong medium type */ +#define EFSCORRUPTED 161 /* Filesystem is corrupted */ +#define ENOATTR 162 /* No such attribute */ #define EDQUOT 1133 /* Quota exceeded */ diff -Naur linux-vanilla/include/asm-parisc/errno.h linux-errno/include/asm-parisc/errno.h --- linux-vanilla/include/asm-parisc/errno.h Wed Dec 6 07:29:39 2000 +++ linux-errno/include/asm-parisc/errno.h Tue Oct 9 11:23:43 2001 @@ -99,6 +99,8 @@ #define EREMOTEIO 181 /* Remote I/O error */ #define ENOMEDIUM 182 /* No medium found */ #define EMEDIUMTYPE 183 /* Wrong medium type */ +#define EFSCORRUPTED 184 /* Filesystem is corrupted */ +#define ENOATTR 185 /* No such attribute */ /* We now return you to your regularly scheduled HPUX. */ diff -Naur linux-vanilla/include/asm-ppc/errno.h linux-errno/include/asm-ppc/errno.h --- linux-vanilla/include/asm-ppc/errno.h Tue May 22 08:02:06 2001 +++ linux-errno/include/asm-ppc/errno.h Tue Oct 9 11:23:55 2001 @@ -129,6 +129,8 @@ #define ENOMEDIUM 123 /* No medium found */ #define EMEDIUMTYPE 124 /* Wrong medium type */ +#define EFSCORRUPTED 125 /* Filesystem is corrupted */ +#define ENOATTR 126 /* No such attribute */ /* Should never be seen by user programs */ #define ERESTARTSYS 512 diff -Naur linux-vanilla/include/asm-s390/errno.h linux-errno/include/asm-s390/errno.h --- linux-vanilla/include/asm-s390/errno.h Sat May 13 04:41:44 2000 +++ linux-errno/include/asm-s390/errno.h Tue Oct 9 11:24:08 2001 @@ -136,5 +136,7 @@ #define ENOMEDIUM 123 /* No medium found */ #define EMEDIUMTYPE 124 /* Wrong medium type */ +#define EFSCORRUPTED 125 /* Filesystem is corrupted */ +#define ENOATTR 126 /* No such attribute */ #endif diff -Naur linux-vanilla/include/asm-s390x/errno.h linux-errno/include/asm-s390x/errno.h --- linux-vanilla/include/asm-s390x/errno.h Wed Feb 14 09:13:44 2001 +++ linux-errno/include/asm-s390x/errno.h Tue Oct 9 11:24:16 2001 @@ -136,5 +136,7 @@ #define ENOMEDIUM 123 /* No medium found */ #define EMEDIUMTYPE 124 /* Wrong medium type */ +#define EFSCORRUPTED 125 /* Filesystem is corrupted */ +#define ENOATTR 126 /* No such attribute */ #endif diff -Naur linux-vanilla/include/asm-sh/errno.h linux-errno/include/asm-sh/errno.h --- linux-vanilla/include/asm-sh/errno.h Tue Aug 31 11:12:59 1999 +++ linux-errno/include/asm-sh/errno.h Tue Oct 9 11:24:25 2001 @@ -128,5 +128,7 @@ #define ENOMEDIUM 123 /* No medium found */ #define EMEDIUMTYPE 124 /* Wrong medium type */ +#define EFSCORRUPTED 125 /* Filesystem is corrupted */ +#define ENOATTR 126 /* No such attribute */ #endif /* __ASM_SH_ERRNO_H */ diff -Naur linux-vanilla/include/asm-sparc/errno.h linux-errno/include/asm-sparc/errno.h --- linux-vanilla/include/asm-sparc/errno.h Thu Apr 24 12:01:28 1997 +++ linux-errno/include/asm-sparc/errno.h Tue Oct 9 11:24:35 2001 @@ -132,5 +132,7 @@ #define ENOMEDIUM 125 /* No medium found */ #define EMEDIUMTYPE 126 /* Wrong medium type */ +#define EFSCORRUPTED 127 /* Filesystem is corrupted */ +#define ENOATTR 128 /* No such attribute */ #endif diff -Naur linux-vanilla/include/asm-sparc64/errno.h linux-errno/include/asm-sparc64/errno.h --- linux-vanilla/include/asm-sparc64/errno.h Thu Apr 24 12:01:28 1997 +++ linux-errno/include/asm-sparc64/errno.h Tue Oct 9 11:28:03 2001 @@ -132,5 +132,7 @@ #define ENOMEDIUM 125 /* No medium found */ #define EMEDIUMTYPE 126 /* Wrong medium type */ +#define EFSCORRUPTED 127 /* Filesystem is corrupted */ +#define ENOATTR 128 /* No such attribute */ #endif /* !(_SPARC64_ERRNO_H) */ --sdtB3X0nJg68CQEu-- From owner-linux-xfs@oss.sgi.com Mon Oct 8 22:23:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f995NRw04520 for linux-xfs-outgoing; Mon, 8 Oct 2001 22:23:27 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f995NMD04498 for ; Mon, 8 Oct 2001 22:23:22 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id HAA07315; Tue, 9 Oct 2001 07:23:19 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id HAA14503; Tue, 9 Oct 2001 07:23:19 +0200 (CEST) Date: Tue, 9 Oct 2001 07:23:19 +0200 (CEST) From: Seth Mos To: Russ Ingram cc: rvt@dds.nl, linux-xfs@oss.sgi.com Subject: Re: .deb kernel packages In-Reply-To: <3BAF7DAC.82267415@uwyo.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 24 Sep 2001, Russ Ingram wrote: > Ries van twisk wrote: > > > > Russ Ingram wrote: > > My point is yes create a debian package. I would suggest contact the > > Linux Dell group and ask them for a pointer to your webside since I now > > there are a lot of Debian Dell users. XFS would be great to have on a > > Dell system like I have. > > > > Ries > If I make them available to others at all I intend to actually > become a contributing package maintainer for the Debian distro. I > would also ask for space on oss.sgi.com to put the packages on the > oss.sgi.com server to complement the rpm packages. I will > definitely contact the Dell group as well, though, if you can > supply me with a pointer to them. Contact Matt_Domsch@dell.com Or visit his website http://domsch.com/linux/ Cheers From owner-linux-xfs@oss.sgi.com Tue Oct 9 00:04:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f99743o06521 for linux-xfs-outgoing; Tue, 9 Oct 2001 00:04:03 -0700 Received: from math.psu.edu (leibniz.math.psu.edu [146.186.130.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9973sD06499 for ; Tue, 9 Oct 2001 00:03:59 -0700 Received: from weyl.math.psu.edu (weyl.math.psu.edu [146.186.130.226]) by math.psu.edu (8.9.3/8.9.3) with ESMTP id DAA08326; Tue, 9 Oct 2001 03:03:49 -0400 (EDT) Received: from localhost (viro@localhost) by weyl.math.psu.edu (8.9.3/8.9.3) with ESMTP id DAA14708; Tue, 9 Oct 2001 03:03:49 -0400 (EDT) X-Authentication-Warning: weyl.math.psu.edu: viro owned process doing -bs Date: Tue, 9 Oct 2001 03:03:49 -0400 (EDT) From: Alexander Viro To: Nathan Scott cc: Jan Kara , Alan Cox , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: Quotactl change In-Reply-To: <20011008203418.A505344@wobbly.melbourne.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 8 Oct 2001, Nathan Scott wrote: > hi all, > > Al - is the attached patch more along the lines of what you > were after? Quota side looks sane. fs/super.c one is an overkill - just set default in alloc_super(). There is no need to bother with resetting it - in the places where you do it superblock is already deactivated, so get_super() in quotactl will not return it and at that point there should be no inodes left from that filesystem. From owner-linux-xfs@oss.sgi.com Tue Oct 9 00:30:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f997UGE07026 for linux-xfs-outgoing; Tue, 9 Oct 2001 00:30:16 -0700 Received: from downtown.oche.de (root@downtown.oche.de [194.94.253.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f997PQD06927 for ; Tue, 9 Oct 2001 00:25:27 -0700 Received: (from uucp@localhost) by downtown.oche.de (8.9.3/8.9.3/Debian 8.9.3-21) with UUCP id JAA14132 for linux-xfs@oss.sgi.com; Tue, 9 Oct 2001 09:25:19 +0200 Received: (from martin@localhost) by foehn.quickstep.oche.de (8.9.3/8.6.12) id IAA21263; Tue, 9 Oct 2001 08:41:25 +0200 (MET DST) Date: Tue, 9 Oct 2001 08:41:25 +0200 (MET DST) Message-Id: <200110090641.IAA21263@foehn.quickstep.oche.de> From: Martin Spott To: linux-xfs@oss.sgi.com Subject: Re: 2.4.10-pre13-xfs Unresolved symbols in pagebuf.o Organization: home User-Agent: tin/1.4.5-20010409 ("One More Nightmare") (UNIX) (SunOS/5.5.1 (sun4m)) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Why can't I connect to oss.sgi.com ftp or http? Is there a problem somewhere > in the country with backbones or is it just oss.sgi.com is down? Please > advise. It appears OSS only allows passive ftp. This might be the reason why, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Tue Oct 9 00:34:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f997Yxg07239 for linux-xfs-outgoing; Tue, 9 Oct 2001 00:34:59 -0700 Received: from atrey.karlin.mff.cuni.cz (root@atrey.karlin.mff.cuni.cz [195.113.31.123]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f997YtD07217 for ; Tue, 9 Oct 2001 00:34:55 -0700 Received: (from jack@localhost) by atrey.karlin.mff.cuni.cz (8.9.3/8.9.3/Debian 8.9.3-21) id JAA18402; Tue, 9 Oct 2001 09:34:25 +0200 Date: Tue, 9 Oct 2001 09:34:25 +0200 From: Jan Kara To: Nathan Scott Cc: Alexander Viro , Alan Cox , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: Quotactl change Message-ID: <20011009093425.A13307@atrey.karlin.mff.cuni.cz> References: <20011006150731.C30450@atrey.karlin.mff.cuni.cz> <20011008203418.A505344@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011008203418.A505344@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.3.20i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, > Al - is the attached patch more along the lines of what you > were after? > > Jan - I think this is actually alot closer to what you were > talking about when we last discussed this. Can you see any > problems from a VFS quota point of view here? I had to make > small interface changes to a couple of the dquot.c routines > to make this simpler/more uniform in places - could you have > cross-check those for me? I see two problems: 1) You changed interface do dquot_sync() - so you should also change DQUOT_SYNC() macro in quotaops.h (rename argument) and all callers of DQUOT_SYNC() macro... 2) It seems to me that validate_quotactl() will actually never return superblock - instead of 'ret = 0;' there should be 'return sb;' and that test 'if (ret)' should be removed.... Honza From owner-linux-xfs@oss.sgi.com Tue Oct 9 02:06:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f99964Z08893 for linux-xfs-outgoing; Tue, 9 Oct 2001 02:06:04 -0700 Received: from slime.wu-wien.ac.at (slime.wu-wien.ac.at [137.208.16.54]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9995wD08870 for ; Tue, 9 Oct 2001 02:05:59 -0700 Received: (from wlang@localhost) by slime.wu-wien.ac.at (8.11.6/8.11.6) id f9995uI05282; Tue, 9 Oct 2001 11:05:56 +0200 From: Willi Langenberger MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15298.48625.831518.499561@slime.wu-wien.ac.at> Date: Tue, 9 Oct 2001 11:05:53 +0200 To: linux-xfs@oss.sgi.com Subject: Bug in sgi-xfs? X-Mailer: VM 6.92 under Emacs 20.7.1 Reply-To: Willi.Langenberger@wu-wien.ac.at Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk First of all: Thank you very much for your work on sgi-xfs for linux! It's a great filesystem! Then, i have problem... The other day i copied 20GB from one disk (ext2) to an new disk (xfs): # cd /old ; find . -xdev -depth -print0 | cpio -pmdv0 /new After it finished, i made a diff: # diff -r /old /new Ouch! There were differences: Binary files /old/websites/200103/mirror-tar/10775.tgz and /new/websites/200103/mirror-tar/10775.tgz differ Binary files /old/websites/200104/mirror-tar/11349.tgz and /new/websites/200104/mirror-tar/11349.tgz differ Binary files /old/websites/200107/mirror-tar/11641.tgz and /new/websites/200107/mirror-tar/11641.tgz differ I looked into the syslog and found the following entry, which took place at the time cpio was running: kernel BUG at inode.c:650! invalid operand: 0000 CPU: 0 EIP: 0010:[prune_icache+95/284] EIP: 0010:[] EFLAGS: 00010286 eax: 0000001b ebx: c51540e8 ecx: 00000000 edx: 00000008 esi: c51540e0 edi: ea0712d6 ebp: c189dfa0 esp: c189df7c ds: 0018 es: 0018 ss: 0018 Process kswapd (pid: 4, stackpage=c189d000) Stack: c0284b20 c0284b7f 0000028a 00000197 00000004 00000000 0008e000 00000001 00000000 c189dfa0 c189dfa0 c0144af1 00001e95 c012a56f 00000006 00000004 00000006 00000004 00000004 00000000 c189c000 c02815f1 c189c239 c012a5eb Call Trace: [shrink_icache_memory+33/48] [do_try_to_free_pages+47/88] [kswapd+83/224] [do_linuxrc+0/216] [kernel_thread+35/48] Call Trace: [] [] [] [] [] Code: 0f 0b 83 c4 0c 8b 86 f4 00 00 00 89 f6 0b 86 bc 00 00 00 75 Is this a bug in xfs? What can i do to find out? Can i help anyhow? Any help would be appreciated! \wlang{} -- Willi.Langenberger@wu-wien.ac.at Fax: +43/1/31336/702 Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria From owner-linux-xfs@oss.sgi.com Tue Oct 9 02:12:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f999CZM09189 for linux-xfs-outgoing; Tue, 9 Oct 2001 02:12:35 -0700 Received: from slime.wu-wien.ac.at (slime.wu-wien.ac.at [137.208.16.54]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f999CVD09167 for ; Tue, 9 Oct 2001 02:12:32 -0700 Received: (from wlang@localhost) by slime.wu-wien.ac.at (8.11.6/8.11.6) id f999CUt05318; Tue, 9 Oct 2001 11:12:30 +0200 From: Willi Langenberger MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15298.49018.477634.619452@slime.wu-wien.ac.at> Date: Tue, 9 Oct 2001 11:12:26 +0200 To: linux-xfs@oss.sgi.com Subject: Re: Bug in sgi-xfs? In-Reply-To: <15298.48625.831518.499561@slime.wu-wien.ac.at> References: <15298.48625.831518.499561@slime.wu-wien.ac.at> X-Mailer: VM 6.92 under Emacs 20.7.1 Reply-To: Willi.Langenberger@wu-wien.ac.at Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk According to Willi Langenberger: > Then, i have problem... > The other day i copied 20GB from one disk (ext2) to an new disk (xfs): Sorry, forgot to mention: RedHat Linux 7.1 with kernel rpms from: ftp://oss.sgi.com/projects/xfs/download/latest/kernel_rpms/linux-2.4.5/ \wlang{} -- Willi.Langenberger@wu-wien.ac.at Fax: +43/1/31336/702 Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria From owner-linux-xfs@oss.sgi.com Tue Oct 9 02:20:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f999KLu09526 for linux-xfs-outgoing; Tue, 9 Oct 2001 02:20:21 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f999KHD09504 for ; Tue, 9 Oct 2001 02:20:17 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id LAA18395; Tue, 9 Oct 2001 11:20:13 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id LAA14032; Tue, 9 Oct 2001 11:20:13 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 3620557306; Tue, 9 Oct 2001 11:18:50 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 54AFD25835; Tue, 9 Oct 2001 11:18:49 +0200 (CEST) Message-ID: <3BC2C0F9.D9E3F955@ch.sauter-bc.com> Date: Tue, 09 Oct 2001 11:18:49 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Willi.Langenberger@wu-wien.ac.at Cc: linux-xfs@oss.sgi.com Subject: Re: Bug in sgi-xfs? References: <15298.48625.831518.499561@slime.wu-wien.ac.at> <15298.49018.477634.619452@slime.wu-wien.ac.at> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Willi Langenberger schrieb: > > According to Willi Langenberger: > > Then, i have problem... > > The other day i copied 20GB from one disk (ext2) to an new disk (xfs): > > Sorry, forgot to mention: > > RedHat Linux 7.1 with kernel rpms from: > > ftp://oss.sgi.com/projects/xfs/download/latest/kernel_rpms/linux-2.4.5/ Could you provide a dmesg output? -Simon > > \wlang{} > > -- > Willi.Langenberger@wu-wien.ac.at Fax: +43/1/31336/702 > Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria From owner-linux-xfs@oss.sgi.com Tue Oct 9 02:39:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f999dZx09974 for linux-xfs-outgoing; Tue, 9 Oct 2001 02:39:35 -0700 Received: from slime.wu-wien.ac.at (slime.wu-wien.ac.at [137.208.16.54]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f999dID09946 for ; Tue, 9 Oct 2001 02:39:18 -0700 Received: (from wlang@localhost) by slime.wu-wien.ac.at (8.11.6/8.11.6) id f999dGt05413; Tue, 9 Oct 2001 11:39:16 +0200 From: Willi Langenberger MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15298.50628.6988.697607@slime.wu-wien.ac.at> Date: Tue, 9 Oct 2001 11:39:16 +0200 To: linux-xfs@oss.sgi.com Subject: Re: Bug in sgi-xfs? In-Reply-To: <3BC2C0F9.D9E3F955@ch.sauter-bc.com> References: <15298.48625.831518.499561@slime.wu-wien.ac.at> <15298.49018.477634.619452@slime.wu-wien.ac.at> <3BC2C0F9.D9E3F955@ch.sauter-bc.com> X-Mailer: VM 6.92 under Emacs 20.7.1 Reply-To: Willi.Langenberger@wu-wien.ac.at Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk According to Simon Matter: > Could you provide a dmesg output? Sure (sorry, hadn't thought about that...): # dmesg Linux version 2.4.5-SGI_XFS_1.0.1 (root@exclaim) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Mon Jul 9 13:44:02 CDT 2001 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000001fff0000 (usable) BIOS-e820: 000000001fff0000 - 000000001fff8000 (ACPI data) BIOS-e820: 000000001fff8000 - 0000000020000000 (ACPI NVS) BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved) On node 0 totalpages: 131056 zone(0): 4096 pages. zone(1): 126960 pages. zone(2): 0 pages. Kernel command line: auto BOOT_IMAGE=linux ro root=341 BOOT_FILE=/boot/vmlinuz-2.4.5-SGI_XFS_1.0.1 Initializing CPU#0 Detected 1050.034 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 2090.59 BogoMIPS Memory: 511808k/524224k available (1503k kernel code, 12028k reserved, 935k data, 220k init, 0k highmem) kdb version 1.8 by Scott Lurndal, Keith Owens. Copyright SGI, All Rights Reserved Dentry-cache hash table entries: 65536 (order: 7, 524288 bytes) Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes) Page-cache hash table entries: 131072 (order: 7, 524288 bytes) CPU: Before vendor init, caps: 0183f9ff c1c7f9ff 00000000, vendor = 2 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After vendor init, caps: 0183f9ff c1c7f9ff 00000000 00000000 CPU: After generic, caps: 0183f9ff c1c7f9ff 00000000 00000000 CPU: Common caps: 0183f9ff c1c7f9ff 00000000 00000000 CPU: AMD Athlon(tm) Processor stepping 04 Enabling fast FPU save and restore... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au) mtrr: detected mtrr type: Intel PCI: PCI BIOS revision 2.10 entry at 0xfdb51, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Using IRQ router default [1106/3074] at 00:11.0 isapnp: Scanning for PnP cards... isapnp: No Plug & Play device found Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14) Starting kswapd v1.8 allocated 32 pages and 32 bhs reserved for the highmem bounces VFS: Diskquotas version dquot_6.4.0 initialized pty: 256 Unix98 ptys configured Serial driver version 5.05a (2001-03-20) with MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A Real Time Clock Driver v1.10d block: queued sectors max/low 340072kB/209000kB, 1024 slots per queue RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx PDC20265: IDE controller on PCI bus 00 dev 60 PDC20265: chipset revision 2 ide: Found promise 20265 in RAID mode. PDC20265: not 100% native mode: will probe irqs later PDC20265: ROM enabled at 0xdffe0000 PDC20265: (U)DMA Burst Bit ENABLED Primary MASTER Mode Secondary MASTER Mode. ide2: BM-DMA at 0xc000-0xc007, BIOS settings: hde:pio, hdf:pio VP_IDE: IDE controller on PCI bus 00 dev 89 VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: VIA vt8233 (rev 00) IDE UDMA100 controller on pci00:11.1 ide0: BM-DMA at 0xff00-0xff07, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xff08-0xff0f, BIOS settings: hdc:DMA, hdd:pio hda: IBM-DTLA-307045, ATA DISK drive hdb: IC35L060AVER07-0, ATA DISK drive hdc: SONY CD-ROM CDU4821, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: 90069840 sectors (46116 MB) w/1916KiB Cache, CHS=5606/255/63, UDMA(100) hdb: 120103200 sectors (61493 MB) w/1916KiB Cache, CHS=7476/255/63, UDMA(100) Partition check: hda: hda1 hda2 < hda5 hda6 hda7 > hdb: hdb1 hdb2 hdb3 hdb4 < hdb5 hdb6 > Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 md.c: sizeof(mdp_super_t) = 4096 autodetecting RAID arrays autorun ... ... autorun DONE. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 4096 buckets, 32Kbytes TCP: Hash tables configured (established 32768 bind 32768) Linux IP multicast router 0.06 plus PIM-SM NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. RAMDISK: Compressed image found at block 0 Freeing initrd memory: 356k freed VFS: Mounted root (ext2 filesystem). SCSI subsystem driver Revision: 1.00 ahc_pci:0:6:0: Host Adapter Bios disabled. Using default SCSI device parameters scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.13 aic7850: Single Channel A, SCSI Id=7, 3/255 SCBs Vendor: HP Model: C1537A Rev: L907 Type: Sequential-Access ANSI SCSI revision: 02 VFS: Mounted root (ext2 filesystem) readonly. change_root: old root has d_count=2 Trying to unmount old root ... okay Freeing unused kernel memory: 220k freed Adding Swap: 265032k swap-space (priority -1) Adding Swap: 530104k swap-space (priority -2) usb.c: registered new driver usbdevfs usb.c: registered new driver hub usb-uhci.c: $Revision: 1.259 $ time 14:00:01 Jul 9 2001 usb-uhci.c: High bandwidth mode enabled usb-uhci.c: USB UHCI at I/O 0xb800, IRQ 10 usb-uhci.c: Detected 2 ports usb.c: new USB bus registered, assigned bus number 1 hub.c: USB hub found hub.c: 2 ports detected usb-uhci.c: USB UHCI at I/O 0xb400, IRQ 10 usb-uhci.c: Detected 2 ports usb.c: new USB bus registered, assigned bus number 2 hub.c: USB hub found hub.c: 2 ports detected usb-uhci.c: USB UHCI at I/O 0xb000, IRQ 10 usb-uhci.c: Detected 2 ports hub.c: USB new device connect on bus2/2, assigned device number 2 usb.c: new USB bus registered, assigned bus number 3 hub.c: USB hub found hub.c: 2 ports detected usb.c: USB device 2 (vend/prod 0x5e3/0x502) is not claimed by any active driver. usb-uhci.c: v1.251 Georg Acher, Deti Fliegl, Thomas Sailer, Roman Weissgaerber usb-uhci.c: USB Universal Host Controller Interface driver Start mounting filesystem: ide0(3,70) Ending clean XFS mount for filesystem: ide0(3,70) Detected scsi tape st0 at scsi0, channel 0, id 3, lun 0 st: bufsize 32768, wrt 30720, max init. buffers 4, s/g segs 16. Winbond Super-IO detection, now testing ports 3F0,370,250,4E,2E ... Winbond chip at EFER=0x2e key=0x87 devid=52 devrev=17 oldid=ff Winbond chip type 83627 Winbond LPT Config: cr_30=01 60,61=0378 70=07 74=03, f0=3a Winbond LPT Config: active=yes, io=0x0378 irq=7, dma=3 Winbond LPT Config: irqtype=pulsed low, high-Z, ECP fifo threshold=7 Winbond LPT Config: Port mode=ECP SMSC Super-IO detection, now testing Ports 2F0, 370 ... 0x378: FIFO is 16 bytes 0x378: writeIntrThreshold is 9 0x378: readIntrThreshold is 9 0x378: PWord is 8 bits 0x378: Interrupts are ISA-Pulses 0x378: ECP port cfgA=0x10 cfgB=0x48 0x378: ECP settings irq=7 dma= parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,COMPAT,EPP,ECP] parport0: irq 7 detected parport0: cpp_daisy: aa5500ff(38) parport0: assign_addrs: aa5500ff(38) parport0: cpp_daisy: aa5500ff(38) parport0: assign_addrs: aa5500ff(38) ip_conntrack (4095 buckets, 32760 max) eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin and others eth0: Intel Corporation 82557 [Ethernet Pro 100], 00:90:27:2C:94:D9, IRQ 10. Receiver lock-up bug exists -- enabling work-around. Board assembly 689661-004, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. General self-test: passed. Serial sub-system self-test: passed. Internal registers self-test: passed. ROM checksum self-test: passed (0x24c9f043). Receiver lock-up workaround activated. scsi1 : SCSI host adapter emulation for IDE ATAPI devices Vendor: SONY Model: CD-ROM CDU4821 Rev: S0.Q Type: CD-ROM ANSI SCSI revision: 02 (scsi0:A:3): 10.000MB/s transfers (10.000MHz, offset 15) Unable to handle kernel paging request at virtual address 2ca0721c printing eip: c01449f2 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[] EFLAGS: 00010207 eax: ffffffff ebx: 2ca07218 ecx: c189dfa0 edx: 00134880 esi: 2ca07210 edi: 2ca07218 ebp: c189dfa0 esp: c189df88 ds: 0018 es: 0018 ss: 0018 Process kswapd (pid: 4, stackpage=c189d000) Stack: 0000028b 00000004 00000000 0008e000 00000001 00000000 c189dfa0 c189dfa0 c0144af1 00001839 c012a56f 00000006 00000004 00000006 00000004 00000004 00000000 c189c000 c02815f1 c189c239 c012a5eb 00000004 00000000 00010f00 Call Trace: [] [] [] [] [] Code: 8b 7f 04 8b 86 f4 00 00 00 a8 38 74 21 68 8a 02 00 00 68 7f \wlang{} -- Willi.Langenberger@wu-wien.ac.at Fax: +43/1/31336/702 Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria From owner-linux-xfs@oss.sgi.com Tue Oct 9 03:22:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f99AMpi10977 for linux-xfs-outgoing; Tue, 9 Oct 2001 03:22:51 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f99AMiD10954 for ; Tue, 9 Oct 2001 03:22:45 -0700 Received: from defiant.cymax.com.au (co3030476-a.rochd1.qld.optushome.com.au [203.164.197.112]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA00375 for ; Fri, 5 Oct 2001 23:02:36 -0700 (PDT) mail_from (lord@sgi.com) Received: from defiant.cymax.com.au ([192.168.70.2]) by defiant.cymax.com.au with Microsoft SMTPSVC(5.0.2195.2096); Sat, 6 Oct 2001 16:00:55 +1000 Received: by defiant.cymax.com.au (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG10062001-160028-130.MMD@cymax.com.au; Sat, 6 Oct 2001 16:00:28 +1000 Received: by smartchat.net.au (mbox cymax) (with Cubic Circle's cucipop (v1.31a 1998/05/13) Sat Oct 6 15:53:56 2001) X-From_: owner-linux-xfs@oss.sgi.com Sat Oct 6 12:50:06 2001 Delivered-To: cymax@smartchat.net.au Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by entoo.connect.com.au (Postfix) with ESMTP id 8EE62DDF21 for ; Sat, 6 Oct 2001 12:50:05 +1000 (EST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f962oOG29104; Fri, 5 Oct 2001 19:50:24 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Fri, 5 Oct 2001 19:46:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f962kwe28954 for linux-xfs-outgoing; Fri, 5 Oct 2001 19:46:58 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f962ksD28934 for ; Fri, 5 Oct 2001 19:46:54 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f962knL17100 for ; Fri, 5 Oct 2001 19:46:49 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id VAA3157608; Fri, 5 Oct 2001 21:45:33 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id VAA29754; Fri, 5 Oct 2001 21:45:32 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f962iwf08449; Fri, 5 Oct 2001 21:44:58 -0500 Message-Id: <200110060244.f962iwf08449@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: ian.nelson@echostar.com Cc: Seth Mos , "linux-xfs@oss.sgi.com" Subject: Re: Wierd errors with sync In-Reply-To: Message from "Ian S. Nelson" of "Fri, 05 Oct 2001 15:32:00 MDT." <3BBE26D0.5EC11066@echostar.com> Date: Fri, 05 Oct 2001 21:44:58 -0500 From: Steve Lord X-OriginalArrivalTime: 06 Oct 2001 06:00:55.0171 (UTC) FILETIME=[42F11D30:01C14E2C] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I have been seeing kernel BUGs in ll_rw_blk. To my /dev/hda8, requests out > of range, or so it would appear. > > Well it's an embedded platform and we've been slowly turning off items. Here > is my new theory. Ah ha, a minor detail emerges! > > If the drive is blank then I have a flash the detects that and rebuilds it > in said flash I do mkfs.xfs and then I do a C library call mount() > That mount behaves different from /bin/mount. I'm guessing that's my > problem. I'm doing mkfs and then it's not syncing or some such garbage. The xfs metadata cache and the buffer cache used by block devices are not coherent. There is an ioctl at the end of mkfs which is supposed to ensure that all buffers for the device are flushed out to disk before it returns. This ioctl: BLKFLSBUF must work, possibly this is an issue for you. > > I'm going to retool my flash and try again. I've taken the problematic > partitions and on the running system I've unmounted them and rebuilt them and > everything is cool again.. > > Ian > Steve From owner-linux-xfs@oss.sgi.com Tue Oct 9 03:27:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f99ARV611214 for linux-xfs-outgoing; Tue, 9 Oct 2001 03:27:31 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f99ARCD11183 for ; Tue, 9 Oct 2001 03:27:12 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id MAA06779; Tue, 9 Oct 2001 12:27:10 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id MAA19861; Tue, 9 Oct 2001 12:27:08 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 6E9DF57306; Tue, 9 Oct 2001 12:26:06 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 639C625835; Tue, 9 Oct 2001 12:26:06 +0200 (CEST) Message-ID: <3BC2D0BE.2CB6D5C1@ch.sauter-bc.com> Date: Tue, 09 Oct 2001 12:26:06 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Willi.Langenberger@wu-wien.ac.at Cc: linux-xfs@oss.sgi.com Subject: Re: Bug in sgi-xfs? References: <15298.48625.831518.499561@slime.wu-wien.ac.at> <15298.49018.477634.619452@slime.wu-wien.ac.at> <3BC2C0F9.D9E3F955@ch.sauter-bc.com> <15298.50628.6988.697607@slime.wu-wien.ac.at> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Willi Langenberger schrieb: > > According to Simon Matter: > > Could you provide a dmesg output? > > Sure (sorry, hadn't thought about that...): > # dmesg > Linux version 2.4.5-SGI_XFS_1.0.1 (root@exclaim) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Mon Jul 9 13:44:02 CDT 2001 > BIOS-provided physical RAM map: > BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) > BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) > BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) > BIOS-e820: 0000000000100000 - 000000001fff0000 (usable) > BIOS-e820: 000000001fff0000 - 000000001fff8000 (ACPI data) > BIOS-e820: 000000001fff8000 - 0000000020000000 (ACPI NVS) > BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved) > On node 0 totalpages: 131056 > zone(0): 4096 pages. > zone(1): 126960 pages. > zone(2): 0 pages. > Kernel command line: auto BOOT_IMAGE=linux ro root=341 BOOT_FILE=/boot/vmlinuz-2.4.5-SGI_XFS_1.0.1 > Initializing CPU#0 > Detected 1050.034 MHz processor. > Console: colour VGA+ 80x25 > Calibrating delay loop... 2090.59 BogoMIPS > Memory: 511808k/524224k available (1503k kernel code, 12028k reserved, 935k data, 220k init, 0k highmem) > kdb version 1.8 by Scott Lurndal, Keith Owens. Copyright SGI, All Rights Reserved > Dentry-cache hash table entries: 65536 (order: 7, 524288 bytes) > Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) > Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes) > Page-cache hash table entries: 131072 (order: 7, 524288 bytes) > CPU: Before vendor init, caps: 0183f9ff c1c7f9ff 00000000, vendor = 2 > CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) > CPU: L2 Cache: 256K (64 bytes/line) > CPU: After vendor init, caps: 0183f9ff c1c7f9ff 00000000 00000000 > CPU: After generic, caps: 0183f9ff c1c7f9ff 00000000 00000000 > CPU: Common caps: 0183f9ff c1c7f9ff 00000000 00000000 > CPU: AMD Athlon(tm) Processor stepping 04 > Enabling fast FPU save and restore... done. > Checking 'hlt' instruction... OK. > POSIX conformance testing by UNIFIX > mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au) > mtrr: detected mtrr type: Intel > PCI: PCI BIOS revision 2.10 entry at 0xfdb51, last bus=1 > PCI: Using configuration type 1 > PCI: Probing PCI hardware > PCI: Using IRQ router default [1106/3074] at 00:11.0 > isapnp: Scanning for PnP cards... > isapnp: No Plug & Play device found > Linux NET4.0 for Linux 2.4 > Based upon Swansea University Computer Society NET3.039 > Initializing RT netlink socket > apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14) > Starting kswapd v1.8 > allocated 32 pages and 32 bhs reserved for the highmem bounces > VFS: Diskquotas version dquot_6.4.0 initialized > pty: 256 Unix98 ptys configured > Serial driver version 5.05a (2001-03-20) with MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled > ttyS00 at 0x03f8 (irq = 4) is a 16550A > ttyS01 at 0x02f8 (irq = 3) is a 16550A > Real Time Clock Driver v1.10d > block: queued sectors max/low 340072kB/209000kB, 1024 slots per queue > RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize > Uniform Multi-Platform E-IDE driver Revision: 6.31 > ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx > PDC20265: IDE controller on PCI bus 00 dev 60 > PDC20265: chipset revision 2 > ide: Found promise 20265 in RAID mode. > PDC20265: not 100% native mode: will probe irqs later > PDC20265: ROM enabled at 0xdffe0000 > PDC20265: (U)DMA Burst Bit ENABLED Primary MASTER Mode Secondary MASTER Mode. > ide2: BM-DMA at 0xc000-0xc007, BIOS settings: hde:pio, hdf:pio > VP_IDE: IDE controller on PCI bus 00 dev 89 > VP_IDE: chipset revision 6 > VP_IDE: not 100% native mode: will probe irqs later > ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx > VP_IDE: VIA vt8233 (rev 00) IDE UDMA100 controller on pci00:11.1 > ide0: BM-DMA at 0xff00-0xff07, BIOS settings: hda:DMA, hdb:DMA > ide1: BM-DMA at 0xff08-0xff0f, BIOS settings: hdc:DMA, hdd:pio > hda: IBM-DTLA-307045, ATA DISK drive > hdb: IC35L060AVER07-0, ATA DISK drive > hdc: SONY CD-ROM CDU4821, ATAPI CD/DVD-ROM drive > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > ide1 at 0x170-0x177,0x376 on irq 15 > hda: 90069840 sectors (46116 MB) w/1916KiB Cache, CHS=5606/255/63, UDMA(100) > hdb: 120103200 sectors (61493 MB) w/1916KiB Cache, CHS=7476/255/63, UDMA(100) > Partition check: > hda: hda1 hda2 < hda5 hda6 hda7 > > hdb: hdb1 hdb2 hdb3 hdb4 < hdb5 hdb6 > > Floppy drive(s): fd0 is 1.44M > FDC 0 is a post-1991 82077 > md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 > md.c: sizeof(mdp_super_t) = 4096 > autodetecting RAID arrays > autorun ... > ... autorun DONE. > NET4: Linux TCP/IP 1.0 for NET4.0 > IP Protocols: ICMP, UDP, TCP, IGMP > IP: routing cache hash table of 4096 buckets, 32Kbytes > TCP: Hash tables configured (established 32768 bind 32768) > Linux IP multicast router 0.06 plus PIM-SM > NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. > RAMDISK: Compressed image found at block 0 > Freeing initrd memory: 356k freed > VFS: Mounted root (ext2 filesystem). > SCSI subsystem driver Revision: 1.00 > ahc_pci:0:6:0: Host Adapter Bios disabled. Using default SCSI device parameters > scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.13 > > aic7850: Single Channel A, SCSI Id=7, 3/255 SCBs > > Vendor: HP Model: C1537A Rev: L907 > Type: Sequential-Access ANSI SCSI revision: 02 > VFS: Mounted root (ext2 filesystem) readonly. > change_root: old root has d_count=2 > Trying to unmount old root ... okay > Freeing unused kernel memory: 220k freed > Adding Swap: 265032k swap-space (priority -1) > Adding Swap: 530104k swap-space (priority -2) > usb.c: registered new driver usbdevfs > usb.c: registered new driver hub > usb-uhci.c: $Revision: 1.259 $ time 14:00:01 Jul 9 2001 > usb-uhci.c: High bandwidth mode enabled > usb-uhci.c: USB UHCI at I/O 0xb800, IRQ 10 > usb-uhci.c: Detected 2 ports > usb.c: new USB bus registered, assigned bus number 1 > hub.c: USB hub found > hub.c: 2 ports detected > usb-uhci.c: USB UHCI at I/O 0xb400, IRQ 10 > usb-uhci.c: Detected 2 ports > usb.c: new USB bus registered, assigned bus number 2 > hub.c: USB hub found > hub.c: 2 ports detected > usb-uhci.c: USB UHCI at I/O 0xb000, IRQ 10 > usb-uhci.c: Detected 2 ports > hub.c: USB new device connect on bus2/2, assigned device number 2 > usb.c: new USB bus registered, assigned bus number 3 > hub.c: USB hub found > hub.c: 2 ports detected > usb.c: USB device 2 (vend/prod 0x5e3/0x502) is not claimed by any active driver. > usb-uhci.c: v1.251 Georg Acher, Deti Fliegl, Thomas Sailer, Roman Weissgaerber > usb-uhci.c: USB Universal Host Controller Interface driver > Start mounting filesystem: ide0(3,70) > Ending clean XFS mount for filesystem: ide0(3,70) > Detected scsi tape st0 at scsi0, channel 0, id 3, lun 0 > st: bufsize 32768, wrt 30720, max init. buffers 4, s/g segs 16. > Winbond Super-IO detection, now testing ports 3F0,370,250,4E,2E ... > Winbond chip at EFER=0x2e key=0x87 devid=52 devrev=17 oldid=ff > Winbond chip type 83627 > Winbond LPT Config: cr_30=01 60,61=0378 70=07 74=03, f0=3a > Winbond LPT Config: active=yes, io=0x0378 irq=7, dma=3 > Winbond LPT Config: irqtype=pulsed low, high-Z, ECP fifo threshold=7 > Winbond LPT Config: Port mode=ECP > SMSC Super-IO detection, now testing Ports 2F0, 370 ... > 0x378: FIFO is 16 bytes > 0x378: writeIntrThreshold is 9 > 0x378: readIntrThreshold is 9 > 0x378: PWord is 8 bits > 0x378: Interrupts are ISA-Pulses > 0x378: ECP port cfgA=0x10 cfgB=0x48 > 0x378: ECP settings irq=7 dma= > parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,COMPAT,EPP,ECP] > parport0: irq 7 detected > parport0: cpp_daisy: aa5500ff(38) > parport0: assign_addrs: aa5500ff(38) > parport0: cpp_daisy: aa5500ff(38) > parport0: assign_addrs: aa5500ff(38) > ip_conntrack (4095 buckets, 32760 max) > eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html > eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin and others > eth0: Intel Corporation 82557 [Ethernet Pro 100], 00:90:27:2C:94:D9, IRQ 10. > Receiver lock-up bug exists -- enabling work-around. > Board assembly 689661-004, Physical connectors present: RJ45 > Primary interface chip i82555 PHY #1. > General self-test: passed. > Serial sub-system self-test: passed. > Internal registers self-test: passed. > ROM checksum self-test: passed (0x24c9f043). > Receiver lock-up workaround activated. > scsi1 : SCSI host adapter emulation for IDE ATAPI devices > Vendor: SONY Model: CD-ROM CDU4821 Rev: S0.Q > Type: CD-ROM ANSI SCSI revision: 02 > (scsi0:A:3): 10.000MB/s transfers (10.000MHz, offset 15) > Unable to handle kernel paging request at virtual address 2ca0721c > printing eip: > c01449f2 > *pde = 00000000 > Oops: 0000 > CPU: 0 > EIP: 0010:[] > EFLAGS: 00010207 > eax: ffffffff ebx: 2ca07218 ecx: c189dfa0 edx: 00134880 > esi: 2ca07210 edi: 2ca07218 ebp: c189dfa0 esp: c189df88 > ds: 0018 es: 0018 ss: 0018 > Process kswapd (pid: 4, stackpage=c189d000) > Stack: 0000028b 00000004 00000000 0008e000 00000001 00000000 c189dfa0 c189dfa0 > c0144af1 00001839 c012a56f 00000006 00000004 00000006 00000004 00000004 > 00000000 c189c000 c02815f1 c189c239 c012a5eb 00000004 00000000 00010f00 > Call Trace: [] [] [] [] [] > > Code: 8b 7f 04 8b 86 f4 00 00 00 a8 38 74 21 68 8a 02 00 00 68 7f > > \wlang{} Hmm, I think it's the same problem I had with different systems. I had it with different CPUs, Chipsets, IDE-adapters and several kernels but I could not figure out what is causing the problem. The only thing I found is that it does ONLY happen if you have more than one IDE drive in a system with 2.4.x kernel. This will lead - under some sircumstances - to corruption. It is not filesystem specific, happens with ext2 as well. -Simon > > -- > Willi.Langenberger@wu-wien.ac.at Fax: +43/1/31336/702 > Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria From owner-linux-xfs@oss.sgi.com Tue Oct 9 04:13:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f99BDfN12243 for linux-xfs-outgoing; Tue, 9 Oct 2001 04:13:41 -0700 Received: from slime.wu-wien.ac.at (slime.wu-wien.ac.at [137.208.16.54]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f99BDYD12218 for ; Tue, 9 Oct 2001 04:13:34 -0700 Received: (from wlang@localhost) by slime.wu-wien.ac.at (8.11.6/8.11.6) id f99BDWi05787; Tue, 9 Oct 2001 13:13:32 +0200 From: Willi Langenberger MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15298.56283.834192.172685@slime.wu-wien.ac.at> Date: Tue, 9 Oct 2001 13:13:31 +0200 To: linux-xfs@oss.sgi.com Subject: Re: Bug in sgi-xfs? In-Reply-To: <30368.1002622509@ocs3.intra.ocs.com.au> References: <15298.50628.6988.697607@slime.wu-wien.ac.at> <30368.1002622509@ocs3.intra.ocs.com.au> X-Mailer: VM 6.92 under Emacs 20.7.1 Reply-To: Willi.Langenberger@wu-wien.ac.at Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk According to Keith Owens: > You need to feed the oops through ksymoops to convert addresses to symbols. Ok, next try (i am, as you have seen in the meantime, very new to kernel bug reporting -- thank you for your patience). Here we go: -----snip-snip------------------ # ksymoops -k /proc/ksyms -l /proc/modules -o /lib/modules/2.4.5-SGI_XFS_1.0.1/ -m /boot/System.map-2.4.5-SGI_XFS_1.0.1 Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): mismatch on symbol partition_name , ksyms_base says c0220940, System.map says c014fb50. Ignoring ksyms_base entry Unable to handle kernel paging request at virtual address 2ca0721c c01449f2 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010207 eax: ffffffff ebx: 2ca07218 ecx: c189dfa0 edx: 00134880 esi: 2ca07210 edi: 2ca07218 ebp: c189dfa0 esp: c189df88 ds: 0018 es: 0018 ss: 0018 Process kswapd (pid: 4, stackpage=c189d000) Stack: 0000028b 00000004 00000000 0008e000 00000001 00000000 c189dfa0 c189dfa0 c0144af1 00001839 c012a56f 00000006 00000004 00000006 00000004 00000004 00000000 c189c000 c02815f1 c189c239 c012a5eb 00000004 00000000 00010f00 Call Trace: [] [] [] [] [] Code: 8b 7f 04 8b 86 f4 00 00 00 a8 38 74 21 68 8a 02 00 00 68 7f >>EIP; c01449f2 <===== Trace; c0144af1 Trace; c012a56f Trace; c012a5eb Trace; c0105000 Trace; c0105647 Code; c01449f2 00000000 <_EIP>: Code; c01449f2 <===== 0: 8b 7f 04 mov 0x4(%edi),%edi <===== Code; c01449f5 3: 8b 86 f4 00 00 00 mov 0xf4(%esi),%eax Code; c01449fb 9: a8 38 test $0x38,%al Code; c01449fd b: 74 21 je 2e <_EIP+0x2e> c0144a20 Code; c01449ff d: 68 8a 02 00 00 push $0x28a Code; c0144a04 12: 68 7f 00 00 00 push $0x7f 3 warnings issued. Results may not be reliable. -----snip-snip------------------ Thank you very much! \wlang{} -- Willi.Langenberger@wu-wien.ac.at Fax: +43/1/31336/702 Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria From owner-linux-xfs@oss.sgi.com Tue Oct 9 04:13:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f99BDWx12209 for linux-xfs-outgoing; Tue, 9 Oct 2001 04:13:32 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f99BD7D12184 for ; Tue, 9 Oct 2001 04:13:07 -0700 Received: from idcomm.com (IDENT:cPZ+QHcxKnrU+OKDlmyjZvlY4lGxhiYS@x2-pip82.idcomm.com [209.60.72.93]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f99BEAq27064; Tue, 9 Oct 2001 05:14:11 -0600 Message-ID: <3BC2DBB8.1A6B301A@idcomm.com> Date: Tue, 09 Oct 2001 05:12:56 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 CC: Willi.Langenberger@wu-wien.ac.at, linux-xfs@oss.sgi.com Subject: Re: Bug in sgi-xfs? References: <15298.48625.831518.499561@slime.wu-wien.ac.at> <15298.49018.477634.619452@slime.wu-wien.ac.at> <3BC2C0F9.D9E3F955@ch.sauter-bc.com> <15298.50628.6988.697607@slime.wu-wien.ac.at> <3BC2D0BE.2CB6D5C1@ch.sauter-bc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk There was a problem that got fixed around 2.4.6-preSomething. Without a ksymoops, nobody will be able to verify it, but assuming you don't want to try something more recent than 2.4.5 (which I guarantee has this bug I'm thinking of within stock kernels), you can manually edit a file and test this. If you go to your kernel source, file fs/block_dev.c, find function ioctl_by_bdev (near line 596). Within that function, you'll see: inode_fake.i_rdev=rdev; Immediately after this, also add: inode_fake.i_bdev=bdev; A couple of lines before that, something else that wouldn't hurt is to initialize the struct. You can change the line that appears like this: struct inode inode_fake; Such that it becomes this instead: struct inode inode_fake = { 0 }; The new function will look like this: int ioctl_by_bdev(struct block_device *bdev, unsigned cmd, unsigned long arg) { kdev_t rdev = to_kdev_t(bdev->bd_dev); struct inode inode_fake = { 0 }; int res; mm_segment_t old_fs = get_fs(); if (!bdev->bd_op->ioctl) return -EINVAL; inode_fake.i_rdev=rdev; inode_fake.i_bdev=bdev; init_waitqueue_head(&inode_fake.i_wait); set_fs(KERNEL_DS); res = bdev->bd_op->ioctl(&inode_fake, NULL, cmd, arg); set_fs(old_fs); return res; } Be sure to do a make mrproper, config it, and then do a completely new build. If that fixes it, then you can bet 2.4.6+ won't have this problem. D. Stimits, stimits@idcomm.com Simon Matter wrote: > > Willi Langenberger schrieb: > > > > According to Simon Matter: > > > Could you provide a dmesg output? > > > > Sure (sorry, hadn't thought about that...): > > # dmesg > > Linux version 2.4.5-SGI_XFS_1.0.1 (root@exclaim) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Mon Jul 9 13:44:02 CDT 2001 > > BIOS-provided physical RAM map: > > BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) > > BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) > > BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) > > BIOS-e820: 0000000000100000 - 000000001fff0000 (usable) > > BIOS-e820: 000000001fff0000 - 000000001fff8000 (ACPI data) > > BIOS-e820: 000000001fff8000 - 0000000020000000 (ACPI NVS) > > BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved) > > On node 0 totalpages: 131056 > > zone(0): 4096 pages. > > zone(1): 126960 pages. > > zone(2): 0 pages. > > Kernel command line: auto BOOT_IMAGE=linux ro root=341 BOOT_FILE=/boot/vmlinuz-2.4.5-SGI_XFS_1.0.1 > > Initializing CPU#0 > > Detected 1050.034 MHz processor. > > Console: colour VGA+ 80x25 > > Calibrating delay loop... 2090.59 BogoMIPS > > Memory: 511808k/524224k available (1503k kernel code, 12028k reserved, 935k data, 220k init, 0k highmem) > > kdb version 1.8 by Scott Lurndal, Keith Owens. Copyright SGI, All Rights Reserved > > Dentry-cache hash table entries: 65536 (order: 7, 524288 bytes) > > Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) > > Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes) > > Page-cache hash table entries: 131072 (order: 7, 524288 bytes) > > CPU: Before vendor init, caps: 0183f9ff c1c7f9ff 00000000, vendor = 2 > > CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) > > CPU: L2 Cache: 256K (64 bytes/line) > > CPU: After vendor init, caps: 0183f9ff c1c7f9ff 00000000 00000000 > > CPU: After generic, caps: 0183f9ff c1c7f9ff 00000000 00000000 > > CPU: Common caps: 0183f9ff c1c7f9ff 00000000 00000000 > > CPU: AMD Athlon(tm) Processor stepping 04 > > Enabling fast FPU save and restore... done. > > Checking 'hlt' instruction... OK. > > POSIX conformance testing by UNIFIX > > mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au) > > mtrr: detected mtrr type: Intel > > PCI: PCI BIOS revision 2.10 entry at 0xfdb51, last bus=1 > > PCI: Using configuration type 1 > > PCI: Probing PCI hardware > > PCI: Using IRQ router default [1106/3074] at 00:11.0 > > isapnp: Scanning for PnP cards... > > isapnp: No Plug & Play device found > > Linux NET4.0 for Linux 2.4 > > Based upon Swansea University Computer Society NET3.039 > > Initializing RT netlink socket > > apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14) > > Starting kswapd v1.8 > > allocated 32 pages and 32 bhs reserved for the highmem bounces > > VFS: Diskquotas version dquot_6.4.0 initialized > > pty: 256 Unix98 ptys configured > > Serial driver version 5.05a (2001-03-20) with MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled > > ttyS00 at 0x03f8 (irq = 4) is a 16550A > > ttyS01 at 0x02f8 (irq = 3) is a 16550A > > Real Time Clock Driver v1.10d > > block: queued sectors max/low 340072kB/209000kB, 1024 slots per queue > > RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize > > Uniform Multi-Platform E-IDE driver Revision: 6.31 > > ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx > > PDC20265: IDE controller on PCI bus 00 dev 60 > > PDC20265: chipset revision 2 > > ide: Found promise 20265 in RAID mode. > > PDC20265: not 100% native mode: will probe irqs later > > PDC20265: ROM enabled at 0xdffe0000 > > PDC20265: (U)DMA Burst Bit ENABLED Primary MASTER Mode Secondary MASTER Mode. > > ide2: BM-DMA at 0xc000-0xc007, BIOS settings: hde:pio, hdf:pio > > VP_IDE: IDE controller on PCI bus 00 dev 89 > > VP_IDE: chipset revision 6 > > VP_IDE: not 100% native mode: will probe irqs later > > ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx > > VP_IDE: VIA vt8233 (rev 00) IDE UDMA100 controller on pci00:11.1 > > ide0: BM-DMA at 0xff00-0xff07, BIOS settings: hda:DMA, hdb:DMA > > ide1: BM-DMA at 0xff08-0xff0f, BIOS settings: hdc:DMA, hdd:pio > > hda: IBM-DTLA-307045, ATA DISK drive > > hdb: IC35L060AVER07-0, ATA DISK drive > > hdc: SONY CD-ROM CDU4821, ATAPI CD/DVD-ROM drive > > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > > ide1 at 0x170-0x177,0x376 on irq 15 > > hda: 90069840 sectors (46116 MB) w/1916KiB Cache, CHS=5606/255/63, UDMA(100) > > hdb: 120103200 sectors (61493 MB) w/1916KiB Cache, CHS=7476/255/63, UDMA(100) > > Partition check: > > hda: hda1 hda2 < hda5 hda6 hda7 > > > hdb: hdb1 hdb2 hdb3 hdb4 < hdb5 hdb6 > > > Floppy drive(s): fd0 is 1.44M > > FDC 0 is a post-1991 82077 > > md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 > > md.c: sizeof(mdp_super_t) = 4096 > > autodetecting RAID arrays > > autorun ... > > ... autorun DONE. > > NET4: Linux TCP/IP 1.0 for NET4.0 > > IP Protocols: ICMP, UDP, TCP, IGMP > > IP: routing cache hash table of 4096 buckets, 32Kbytes > > TCP: Hash tables configured (established 32768 bind 32768) > > Linux IP multicast router 0.06 plus PIM-SM > > NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. > > RAMDISK: Compressed image found at block 0 > > Freeing initrd memory: 356k freed > > VFS: Mounted root (ext2 filesystem). > > SCSI subsystem driver Revision: 1.00 > > ahc_pci:0:6:0: Host Adapter Bios disabled. Using default SCSI device parameters > > scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.13 > > > > aic7850: Single Channel A, SCSI Id=7, 3/255 SCBs > > > > Vendor: HP Model: C1537A Rev: L907 > > Type: Sequential-Access ANSI SCSI revision: 02 > > VFS: Mounted root (ext2 filesystem) readonly. > > change_root: old root has d_count=2 > > Trying to unmount old root ... okay > > Freeing unused kernel memory: 220k freed > > Adding Swap: 265032k swap-space (priority -1) > > Adding Swap: 530104k swap-space (priority -2) > > usb.c: registered new driver usbdevfs > > usb.c: registered new driver hub > > usb-uhci.c: $Revision: 1.259 $ time 14:00:01 Jul 9 2001 > > usb-uhci.c: High bandwidth mode enabled > > usb-uhci.c: USB UHCI at I/O 0xb800, IRQ 10 > > usb-uhci.c: Detected 2 ports > > usb.c: new USB bus registered, assigned bus number 1 > > hub.c: USB hub found > > hub.c: 2 ports detected > > usb-uhci.c: USB UHCI at I/O 0xb400, IRQ 10 > > usb-uhci.c: Detected 2 ports > > usb.c: new USB bus registered, assigned bus number 2 > > hub.c: USB hub found > > hub.c: 2 ports detected > > usb-uhci.c: USB UHCI at I/O 0xb000, IRQ 10 > > usb-uhci.c: Detected 2 ports > > hub.c: USB new device connect on bus2/2, assigned device number 2 > > usb.c: new USB bus registered, assigned bus number 3 > > hub.c: USB hub found > > hub.c: 2 ports detected > > usb.c: USB device 2 (vend/prod 0x5e3/0x502) is not claimed by any active driver. > > usb-uhci.c: v1.251 Georg Acher, Deti Fliegl, Thomas Sailer, Roman Weissgaerber > > usb-uhci.c: USB Universal Host Controller Interface driver > > Start mounting filesystem: ide0(3,70) > > Ending clean XFS mount for filesystem: ide0(3,70) > > Detected scsi tape st0 at scsi0, channel 0, id 3, lun 0 > > st: bufsize 32768, wrt 30720, max init. buffers 4, s/g segs 16. > > Winbond Super-IO detection, now testing ports 3F0,370,250,4E,2E ... > > Winbond chip at EFER=0x2e key=0x87 devid=52 devrev=17 oldid=ff > > Winbond chip type 83627 > > Winbond LPT Config: cr_30=01 60,61=0378 70=07 74=03, f0=3a > > Winbond LPT Config: active=yes, io=0x0378 irq=7, dma=3 > > Winbond LPT Config: irqtype=pulsed low, high-Z, ECP fifo threshold=7 > > Winbond LPT Config: Port mode=ECP > > SMSC Super-IO detection, now testing Ports 2F0, 370 ... > > 0x378: FIFO is 16 bytes > > 0x378: writeIntrThreshold is 9 > > 0x378: readIntrThreshold is 9 > > 0x378: PWord is 8 bits > > 0x378: Interrupts are ISA-Pulses > > 0x378: ECP port cfgA=0x10 cfgB=0x48 > > 0x378: ECP settings irq=7 dma= > > parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,COMPAT,EPP,ECP] > > parport0: irq 7 detected > > parport0: cpp_daisy: aa5500ff(38) > > parport0: assign_addrs: aa5500ff(38) > > parport0: cpp_daisy: aa5500ff(38) > > parport0: assign_addrs: aa5500ff(38) > > ip_conntrack (4095 buckets, 32760 max) > > eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html > > eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin and others > > eth0: Intel Corporation 82557 [Ethernet Pro 100], 00:90:27:2C:94:D9, IRQ 10. > > Receiver lock-up bug exists -- enabling work-around. > > Board assembly 689661-004, Physical connectors present: RJ45 > > Primary interface chip i82555 PHY #1. > > General self-test: passed. > > Serial sub-system self-test: passed. > > Internal registers self-test: passed. > > ROM checksum self-test: passed (0x24c9f043). > > Receiver lock-up workaround activated. > > scsi1 : SCSI host adapter emulation for IDE ATAPI devices > > Vendor: SONY Model: CD-ROM CDU4821 Rev: S0.Q > > Type: CD-ROM ANSI SCSI revision: 02 > > (scsi0:A:3): 10.000MB/s transfers (10.000MHz, offset 15) > > Unable to handle kernel paging request at virtual address 2ca0721c > > printing eip: > > c01449f2 > > *pde = 00000000 > > Oops: 0000 > > CPU: 0 > > EIP: 0010:[] > > EFLAGS: 00010207 > > eax: ffffffff ebx: 2ca07218 ecx: c189dfa0 edx: 00134880 > > esi: 2ca07210 edi: 2ca07218 ebp: c189dfa0 esp: c189df88 > > ds: 0018 es: 0018 ss: 0018 > > Process kswapd (pid: 4, stackpage=c189d000) > > Stack: 0000028b 00000004 00000000 0008e000 00000001 00000000 c189dfa0 c189dfa0 > > c0144af1 00001839 c012a56f 00000006 00000004 00000006 00000004 00000004 > > 00000000 c189c000 c02815f1 c189c239 c012a5eb 00000004 00000000 00010f00 > > Call Trace: [] [] [] [] [] > > > > Code: 8b 7f 04 8b 86 f4 00 00 00 a8 38 74 21 68 8a 02 00 00 68 7f > > > > \wlang{} > > Hmm, I think it's the same problem I had with different systems. I had > it with different CPUs, Chipsets, IDE-adapters and several kernels but I > could not figure out what is causing the problem. The only thing I found > is that it does ONLY happen if you have more than one IDE drive in a > system with 2.4.x kernel. This will lead - under some sircumstances - to > corruption. It is not filesystem specific, happens with ext2 as well. > > -Simon > > > > > -- > > Willi.Langenberger@wu-wien.ac.at Fax: +43/1/31336/702 > > Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria From owner-linux-xfs@oss.sgi.com Tue Oct 9 04:17:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f99BHUv12438 for linux-xfs-outgoing; Tue, 9 Oct 2001 04:17:30 -0700 Received: from main.braxis.co.uk (root@main.braxis.co.uk [213.77.40.29]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f99BHPD12416 for ; Tue, 9 Oct 2001 04:17:25 -0700 Received: (from kszysiu@localhost) by main.braxis.co.uk (8.11.6/8.11.6) id f99BHLP11582; Tue, 9 Oct 2001 13:17:21 +0200 Date: Tue, 9 Oct 2001 13:17:21 +0200 From: Krzysztof Rusocki To: Willi.Langenberger@wu-wien.ac.at Cc: linux-xfs@oss.sgi.com Subject: Re: Bug in sgi-xfs? Message-ID: <20011009131721.A9570@main.braxis.co.uk> References: <15298.48625.831518.499561@slime.wu-wien.ac.at> <15298.49018.477634.619452@slime.wu-wien.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15298.49018.477634.619452@slime.wu-wien.ac.at>; from wlang@wu-wien.ac.at on Tue, Oct 09, 2001 at 11:12:26AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Oct 09, 2001 at 11:12:26AM +0200, Willi Langenberger wrote: Hi Willi, > According to Willi Langenberger: > > Then, i have problem... > > The other day i copied 20GB from one disk (ext2) to an new disk (xfs): > > Sorry, forgot to mention: > > RedHat Linux 7.1 with kernel rpms from: > > ftp://oss.sgi.com/projects/xfs/download/latest/kernel_rpms/linux-2.4.5/ Personally i found 2.4.5 to be very very bad - machine didn't even manage to bootup. Have you used kernel-source package and compiled ? or have you used binaries only ? If it's the first case - gcc-2.95 series and early 2.96's were known to broke xfs kernels - xfs developers recommend to use kgcc aka egcs-1.1.2 aka gcc-2.91.66. So if you compiles with 2.9{5,6} try to use egcs and check if problem remains. I believe that feeding that "BUG" output to ksymoops program (see manual) and sending results to the list would be a good thing to do. You may also try to use cvs kernel which is 2.4.11-pre6 or patched 2.4.10 with patches from ftp://oss.sgi.com/projects/xfs/download/patches and see if the problem persists. I have a note to linux-xfs developers: don't you think that it would be a good step to provide 2.4.10 kernel rpms for 1.0.1 release ? or maybe the testing it received is still not sufficient ? Cheers, Krzysztof > > > \wlang{} > > -- > Willi.Langenberger@wu-wien.ac.at Fax: +43/1/31336/702 > Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria From owner-linux-xfs@oss.sgi.com Tue Oct 9 04:48:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f99BmZ713105 for linux-xfs-outgoing; Tue, 9 Oct 2001 04:48:35 -0700 Received: from netbank.com.br (IDENT:postfix@garrincha.netbank.com.br [200.203.199.88]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f99BmTD13083 for ; Tue, 9 Oct 2001 04:48:30 -0700 Received: from 1-212.ctame701-1.telepar.net.br (1-212.ctame701-1.telepar.net.br [200.181.137.212]) by netbank.com.br (Postfix) with ESMTP id 2858846805; Tue, 9 Oct 2001 08:46:58 -0300 (BRST) Received: (from localhost user: 'riel', uid#500) by imladris.surriel.com with ESMTP id ; Tue, 9 Oct 2001 08:48:04 -0300 Date: Tue, 9 Oct 2001 08:48:04 -0300 (BRST) From: Rik van Riel X-X-Sender: To: Linus Torvalds Cc: Mikulas Patocka , Alan Cox , Alex Bligh - linux-kernel , Krzysztof Rusocki , , Subject: Re: %u-order allocation failed In-Reply-To: Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 8 Oct 2001, Linus Torvalds wrote: > On Tue, 9 Oct 2001, Mikulas Patocka wrote: > > > > Linus, what do you think: is it OK if fork randomly fails with very small > > probability or not? > > I've never seen it, I've never heard it reported, and I _know_ that > vmalloc() causes slowdowns. I've seen it happen during stresstest of an underpowered test box. When that point is reached, the system usually is already so far overloaded there's little point in allowing extra processes to be started. > In short, I'm not switching to a vmalloc() fork. The only real use I could see would be to allow root to start up some commands to save the box when it's going down the drain. Probably not worth it since root could have just used ulimit for the normal users ;) regards, Rik -- DMCA, SSSCA, W3C? Who cares? http://thefreeworld.net/ (volunteers needed) http://www.surriel.com/ http://distro.conectiva.com/ From owner-linux-xfs@oss.sgi.com Tue Oct 9 04:55:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f99BthQ13483 for linux-xfs-outgoing; Tue, 9 Oct 2001 04:55:43 -0700 Received: from smtp1.xs4all.nl (smtp1.xs4all.nl [194.109.127.131]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f99BtcD13461 for ; Tue, 9 Oct 2001 04:55:39 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtp1.xs4all.nl (8.9.3/8.9.3) with ESMTP id NAA11162; Tue, 9 Oct 2001 13:55:27 +0200 (CEST) Message-Id: <4.3.2.7.2.20011009133023.02cfda58@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 09 Oct 2001 13:54:17 +0200 To: Krzysztof Rusocki , Willi.Langenberger@wu-wien.ac.at From: Seth Mos Subject: Re: Bug in sgi-xfs? Cc: linux-xfs@oss.sgi.com In-Reply-To: <20011009131721.A9570@main.braxis.co.uk> References: <15298.49018.477634.619452@slime.wu-wien.ac.at> <15298.48625.831518.499561@slime.wu-wien.ac.at> <15298.49018.477634.619452@slime.wu-wien.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 13:17 9-10-2001 +0200, Krzysztof Rusocki wrote: >On Tue, Oct 09, 2001 at 11:12:26AM +0200, Willi Langenberger wrote: > >I have a note to linux-xfs developers: don't you think that it would be >a good step to provide 2.4.10 kernel rpms for 1.0.1 release ? or maybe >the testing it received is still not sufficient ? That would mean a kernel needs to be heavily tested before it can be used for an update disk. Since the development is past 1.0.1 already and fitting 1.0.1 from 2.4.5 on a newer kernel wouldn't be a really good idea either. It is very likely that by the time a redhat 7.2 update disk comes along we will probably have a newer version included anyways. What you could also do is use the Mandrake 8.1 kernel since this also supports XFS and is well tested before release. Since the dependencies with the rpms are tricky you can download a tar.bz2 here: http://iserv.nl/files/xfs/ This is the contents of the kernel-source rpm but a bit easier to handle. It will extract into a linux directory and is a 2.4.8-ac12 kernel. YMMV Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Tue Oct 9 05:24:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f99COhR14259 for linux-xfs-outgoing; Tue, 9 Oct 2001 05:24:43 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f99CNSD14230 for ; Tue, 9 Oct 2001 05:23:28 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f99CNFW26705 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Tue, 9 Oct 2001 05:23:16 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id OAA2830035 for ; Tue, 9 Oct 2001 14:22:55 +0200 (CEST) mail_from (nathans@wobbly.melbourne.sgi.com) 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 WAA27705; Tue, 9 Oct 2001 22:21:46 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id WAA81765; Tue, 9 Oct 2001 22:21:44 +1000 (AEDT) Date: Tue, 9 Oct 2001 22:21:43 +1000 From: Nathan Scott To: Alexander Viro , Jan Kara Cc: Alan Cox , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: Quotactl change Message-ID: <20011009222143.A473872@wobbly.melbourne.sgi.com> References: <20011006150731.C30450@atrey.karlin.mff.cuni.cz> <20011008203418.A505344@wobbly.melbourne.sgi.com> <20011009093425.A13307@atrey.karlin.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011009093425.A13307@atrey.karlin.mff.cuni.cz>; from jack@suse.cz on Tue, Oct 09, 2001 at 09:34:25AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Oct 09, 2001 at 03:03:49AM -0400, Alexander Viro wrote: > > Quota side looks sane. fs/super.c one is an overkill... > On Tue, Oct 09, 2001 at 09:34:25AM +0200, Jan Kara wrote: > I see two problems... > Thanks - these three issues should be resolved now. I'll bang on this some more tomorrow, but this should just about do it, I think. cheers. -- Nathan diff -Naur linux-2410ac8/fs/Makefile linux-2410ac8-quota/fs/Makefile --- linux-2410ac8/fs/Makefile Mon Oct 8 13:26:59 2001 +++ linux-2410ac8-quota/fs/Makefile Mon Oct 8 19:45:36 2001 @@ -14,12 +14,10 @@ super.o block_dev.o char_dev.o stat.o exec.o pipe.o namei.o \ fcntl.o ioctl.o readdir.o select.o fifo.o locks.o \ dcache.o inode.o attr.o bad_inode.o file.o iobuf.o dnotify.o \ - filesystems.o jbd-kernel.o namespace.o + filesystems.o jbd-kernel.o namespace.o quota.o ifeq ($(CONFIG_QUOTA),y) obj-y += dquot.o -else -obj-y += noquot.o endif subdir-$(CONFIG_PROC_FS) += proc diff -Naur linux-2410ac8/fs/dquot.c linux-2410ac8-quota/fs/dquot.c --- linux-2410ac8/fs/dquot.c Mon Oct 8 13:26:59 2001 +++ linux-2410ac8-quota/fs/dquot.c Tue Oct 9 20:08:05 2001 @@ -46,9 +46,12 @@ * Jan Kara 12/2000 * * New quotafile format - * Alocation units changed to bytes + * Allocation units changed to bytes * Jan Kara, , 2000 * + * Reworked the quotactl interface for filesystem-specific quota + * Nathan Scott and Jan Kara , 2001 + * * (C) Copyright 1994 - 1997 Marco van Wieringen */ @@ -65,6 +68,7 @@ #include #include #include +#include #include #include @@ -73,8 +77,6 @@ #define __DQUOT_NUM_VERSION__ (6*10000+5*100+0) #define __DQUOT_PARANOIA -int nr_dquots, nr_free_dquots; - static const char *quotatypes[] = INITQFNAMES; static const uint quota_magics[] = INITQMAGICS; static const uint quota_versions[] = INITQVERSIONS; @@ -1019,6 +1021,11 @@ return 0; } +static int quota_sync(struct super_block *sb, short type) +{ + return sync_dquots(sb->s_dev, type); +} + /* Free unused dquots from cache */ static void prune_dqcache(int count) { @@ -1477,25 +1484,21 @@ * Initialize a dquot-struct with new quota info. This is used by the * system call interface functions. */ -static int set_dqblk(struct super_block *sb, qid_t id, short type, int flags, struct mem_dqblk *dqblk) +static int set_dqblk(struct super_block *sb, short type, qid_t id, struct mem_dqblk *dqblk, int op) { struct dquot *dquot; - int error = -EFAULT; struct mem_dqblk dq_dqblk; - if (copy_from_user(&dq_dqblk, dqblk, sizeof(struct mem_dqblk))) - return error; - - if (sb && (dquot = dqget(sb, id, type)) != NODQUOT) { + if ((dquot = dqget(sb, id, type)) != NODQUOT) { /* We can't block while changing quota structure... */ - if ((flags & SET_QUOTA) || (flags & SET_QLIMIT)) { + if (op == Q_SETQUOTA || op == Q_SETQLIM) { dquot->dq_bhardlimit = dq_dqblk.dqb_bhardlimit; dquot->dq_bsoftlimit = dq_dqblk.dqb_bsoftlimit; dquot->dq_ihardlimit = dq_dqblk.dqb_ihardlimit; dquot->dq_isoftlimit = dq_dqblk.dqb_isoftlimit; } - if ((flags & SET_QUOTA) || (flags & SET_USE)) { + if (op == Q_SETQUOTA || op == Q_SETUSE) { if (dquot->dq_isoftlimit && dquot->dq_curinodes < dquot->dq_isoftlimit && dq_dqblk.dqb_curinodes >= dquot->dq_isoftlimit) @@ -1529,77 +1532,85 @@ return 0; } -static int get_quota(struct super_block *sb, qid_t id, short type, struct mem_dqblk *dqblk) +static int get_dqblk(struct super_block *sb, short type, qid_t id, struct mem_dqblk *dqblk) { struct dquot *dquot; - struct mem_dqblk data; int error = -ESRCH; - if (!sb || !sb_has_quota_enabled(sb, type)) + if (!sb_has_quota_enabled(sb, type)) goto out; dquot = dqget(sb, id, type); if (dquot == NODQUOT) goto out; - memcpy(&data, &dquot->dq_dqb, sizeof(struct mem_dqblk)); /* We copy data to preserve them from changing */ + memcpy(dqblk, &dquot->dq_dqb, sizeof(struct mem_dqblk)); /* We copy data to preserve them from changing */ dqput(dquot); - error = -EFAULT; - if (dqblk && !copy_to_user(dqblk, &data, sizeof(struct mem_dqblk))) - error = 0; + error = 0; out: return error; } -static int get_stats(caddr_t addr) +#ifdef CONFIG_PROC_FS +static int read_stats(char *buffer, char **start, off_t offset, int count, int *eof, void *data) { - int error = -EFAULT; - struct dqstats stats; + int len; dqstats.allocated_dquots = nr_dquots; dqstats.free_dquots = nr_free_dquots; - /* make a copy, in case we page-fault in user space */ - memcpy(&stats, &dqstats, sizeof(struct dqstats)); - if (!copy_to_user(addr, &stats, sizeof(struct dqstats))) - error = 0; - return error; -} + len = sprintf(buffer, "Version %u\n", dqstats.version); + len += sprintf(buffer + len, "%u %u %u %u %u %u %u %u\n", + dqstats.lookups, dqstats.drops, + dqstats.reads, dqstats.writes, + dqstats.cache_hits, dqstats.allocated_dquots, + dqstats.free_dquots, dqstats.syncs); + + if (offset >= len) { + *start = buffer; + *eof = 1; + return 0; + } + *start = buffer + offset; + if ((len -= offset) > count) + return count; + *eof = 1; + + return len; +} +#define quota_proc_init() \ + create_proc_read_entry("fs/quota", 0, 0, read_stats, NULL); +#else +#define quota_proc_init() do { } while (0) +#endif -static int get_info(struct super_block *sb, short type, struct mem_dqinfo *pinfo) +static int get_info(struct super_block *sb, short type, struct mem_dqinfo *kinfo) { - struct mem_dqinfo kinfo; - - if (!sb || !sb_has_quota_enabled(sb, type)) + if (!sb_has_quota_enabled(sb, type)) return -ESRCH; /* Make our own copy so we can guarantee consistent structure */ - memcpy(&kinfo, sb_dqopt(sb)->info+type, sizeof(struct mem_dqinfo)); - kinfo.dqi_flags &= DQF_MASK; - if (copy_to_user(pinfo, &kinfo, sizeof(struct mem_dqinfo))) - return -EFAULT; + memcpy(kinfo, sb_dqopt(sb)->info+type, sizeof(struct mem_dqinfo)); + kinfo->dqi_flags &= DQF_MASK; return 0; } -static int set_info(int op, struct super_block *sb, short type, struct mem_dqinfo *pinfo) +static int set_info(struct super_block *sb, short type, struct mem_dqinfo *pinfo, int op) { struct mem_dqinfo info; struct quota_info *dqopt = sb_dqopt(sb); - if (!sb || !sb_has_quota_enabled(sb, type)) + if (!sb_has_quota_enabled(sb, type)) return -ESRCH; - if (copy_from_user(&info, pinfo, sizeof(struct mem_dqinfo))) - return -EFAULT; - switch (op) { - case ISET_FLAGS: + case Q_SETFLAGS: dqopt->info[type].dqi_flags = (dqopt->info[type].dqi_flags & ~DQF_MASK) | (info.dqi_flags & DQF_MASK); break; - case ISET_GRACE: + case Q_SETGRACE: dqopt->info[type].dqi_bgrace = info.dqi_bgrace; dqopt->info[type].dqi_igrace = info.dqi_igrace; break; - case ISET_ALL: + case Q_SETINFO: info.dqi_flags &= ~DQF_MASK; memcpy(dqopt->info + type, &info, sizeof(struct mem_dqinfo)); break; @@ -1886,6 +1897,7 @@ INIT_LIST_HEAD(dquot_hash + i); dqstats.version = __DQUOT_NUM_VERSION__; printk(KERN_NOTICE "VFS: Diskquotas version %s initialized\n", __DQUOT_VERSION__); + quota_proc_init(); return 0; } __initcall(dquot_init); @@ -1939,9 +1951,6 @@ short cnt; struct quota_info *dqopt = sb_dqopt(sb); - if (!sb) - goto out; - /* We need to serialize quota_off() for device */ down(&dqopt->dqoff_sem); for (cnt = 0; cnt < MAXQUOTAS; cnt++) { @@ -1963,7 +1972,6 @@ fput(filp); } up(&dqopt->dqoff_sem); -out: return 0; } @@ -2044,114 +2052,14 @@ } /* - * This is the system call interface. This communicates with - * the user-level programs. Currently this only supports diskquota - * calls. Maybe we need to add the process quotas etc. in the future, - * but we probably should use rlimits for that. + * Definitions of quota operations accessible through quotactl(2). */ -asmlinkage long sys_quotactl(int cmd, const char *special, qid_t id, __kernel_caddr_t addr) -{ - int cmds = 0, type = 0, flags = 0; - kdev_t dev; - struct super_block *sb = NULL; - int ret = -EINVAL; - - lock_kernel(); - cmds = cmd >> SUBCMDSHIFT; - type = cmd & SUBCMDMASK; - - - if ((uint) type >= MAXQUOTAS || cmds > 0x1100 || cmds < 0x100 || cmds == 0x0300 || - cmds == 0x0400 || cmds == 0x0500 || cmds == 0x1000) - goto out; - - ret = -EPERM; - switch (cmds) { - case Q_SYNC: - case Q_GETSTATS: - case Q_GETINFO: - break; - case Q_GETQUOTA: - if (((type == USRQUOTA && current->euid != id) || - (type == GRPQUOTA && !in_egroup_p(id))) && - !capable(CAP_SYS_ADMIN)) - goto out; - break; - default: - if (!capable(CAP_SYS_ADMIN)) - goto out; - } - - dev = NODEV; - if (special != NULL || (cmds != Q_SYNC && cmds != Q_GETSTATS)) { - mode_t mode; - struct nameidata nd; - - ret = user_path_walk(special, &nd); - if (ret) - goto out; - - dev = nd.dentry->d_inode->i_rdev; - mode = nd.dentry->d_inode->i_mode; - path_release(&nd); - - ret = -ENOTBLK; - if (!S_ISBLK(mode)) - goto out; - ret = -ENODEV; - sb = get_super(dev); - if (!sb) - goto out; - } - - ret = -EINVAL; - switch (cmds) { - case Q_QUOTAON: - ret = quota_on(sb, type, (char *) addr); - goto out; - case Q_QUOTAOFF: - ret = quota_off(sb, type); - goto out; - case Q_GETQUOTA: - ret = get_quota(sb, id, type, (struct mem_dqblk *) addr); - goto out; - case Q_SETQUOTA: - flags |= SET_QUOTA; - break; - case Q_SETUSE: - flags |= SET_USE; - break; - case Q_SETQLIM: - flags |= SET_QLIMIT; - break; - case Q_SYNC: - ret = sync_dquots(dev, type); - goto out; - case Q_GETSTATS: - ret = get_stats(addr); - goto out; - case Q_GETINFO: - ret = get_info(sb, type, (struct mem_dqinfo *) addr); - goto out; - case Q_SETFLAGS: - ret = set_info(ISET_FLAGS, sb, type, (struct mem_dqinfo *)addr); - goto out; - case Q_SETGRACE: - ret = set_info(ISET_GRACE, sb, type, (struct mem_dqinfo *)addr); - goto out; - case Q_SETINFO: - ret = set_info(ISET_ALL, sb, type, (struct mem_dqinfo *)addr); - goto out; - default: - goto out; - } - - ret = -NODEV; - if (sb && sb_has_quota_enabled(sb, type)) - ret = set_dqblk(sb, id, type, flags, (struct mem_dqblk *) addr); -out: - if (sb) - drop_super(sb); - unlock_kernel(); - return ret; -} +struct quota_operations generic_quota_ops = { + quotaon: quota_on, + quotaoff: quota_off, + quotasync: quota_sync, + getinfo: get_info, + setinfo: set_info, + getdqblk: get_dqblk, + setdqblk: set_dqblk, +}; diff -Naur linux-2410ac8/fs/noquot.c linux-2410ac8-quota/fs/noquot.c --- linux-2410ac8/fs/noquot.c Mon Oct 8 13:27:00 2001 +++ linux-2410ac8-quota/fs/noquot.c Thu Jan 1 10:00:00 1970 @@ -1,20 +0,0 @@ -/* noquot.c: Quota stubs necessary for when quotas are not - * compiled into the kernel. - */ - -#include -#include -#include - -int nr_dquots, nr_free_dquots; -int max_dquots; - -asmlinkage long sys_quotactl(int cmd, const char *special, int id, caddr_t addr) -{ - return(-ENOSYS); -} - -void shrink_dqcache_memory(int priority, unsigned int gfp_mask) -{ - ; -} diff -Naur linux-2410ac8/fs/quota.c linux-2410ac8-quota/fs/quota.c --- linux-2410ac8/fs/quota.c Thu Jan 1 10:00:00 1970 +++ linux-2410ac8-quota/fs/quota.c Tue Oct 9 20:44:43 2001 @@ -0,0 +1,212 @@ +/* + * Quota code necessary even when VFS quota support is not compiled + * into the kernel. Allows filesystems to implement their own form + * of quota if they wish. The interesting stuff is over in dquot.c, + * living here are symbols for initial quotactl(2) handling, sysctl + * variables, etc - things needed even when quota support disabled. + */ + +#include +#include +#include +#include +#include + +int nr_dquots, nr_free_dquots; + +#ifndef CONFIG_QUOTA +void shrink_dqcache_memory(int priority, unsigned int mask) +{ + return; +} +#endif + +static struct super_block * +validate_quotactl(int cmd, int type, const char *special, qid_t id) +{ + int ret; + kdev_t dev; + mode_t mode; + struct nameidata nd; + struct super_block *sb; + + ret = -ENOSYS; + if (cmd == 0x0800 || cmd == 0x1100) /* both were Q_GETSTATS */ + goto error; + + /* version/compatibility stuff - needs to be early on in the piece */ + ret = -EINVAL; + if (cmd == 0x0300 || cmd == 0x0400 || cmd == 0x0500 || cmd == 0x1000 + || cmd < 0x100) + goto error; + if (type >= MAXQUOTAS) + goto error; + + ret = -EPERM; + switch (cmd) { + case Q_SYNC: + case Q_GETINFO: + case Q_XGETQSTAT: + break; + + case Q_GETQUOTA: + case Q_XGETQUOTA: + if (((type == USRQUOTA && current->euid != id) || + (type == GRPQUOTA && !in_egroup_p(id))) && + !capable(CAP_SYS_ADMIN)) + goto error; + + default: + if (!capable(CAP_SYS_ADMIN)) + goto error; + } + + ret = -ENODEV; + if (!special) + goto error; + ret = user_path_walk(special, &nd); + if (ret) + goto error; + + dev = nd.dentry->d_inode->i_rdev; + mode = nd.dentry->d_inode->i_mode; + path_release(&nd); + + ret = -ENOTBLK; + if (!S_ISBLK(mode)) + goto error; + + ret = -ENODEV; + sb = get_super(dev); + if (!sb) + goto error; + + ret = -ENOSYS; + if (!sb->s_qop) { + drop_super(sb); + goto error; + } + + return sb; +error: + return ERR_PTR(ret); +} + +asmlinkage long +sys_quotactl(int cmd, const char *special, qid_t id, __kernel_caddr_t addr) +{ + int ret, cmds, type; + struct super_block *sb; + union { + char *pathname; + unsigned int flags; + struct mem_dqblk mdq; + struct mem_dqinfo info; + struct fs_disk_quota fdq; + struct fs_quota_stat fqs; + } u; /* qualifies valid uses of "addr" */ + + lock_kernel(); + cmds = cmd >> SUBCMDSHIFT; + type = cmd & SUBCMDMASK; + + sb = validate_quotactl(cmds, type, special, id); + if (IS_ERR(sb)) { + unlock_kernel(); + return PTR_ERR(sb); + } + + ret = -EINVAL; + switch (cmds) { + case Q_QUOTAON: + u.pathname = (char *)addr; + if (sb->s_qop->quotaon) + ret = sb->s_qop->quotaon(sb, type, u.pathname); + break; + + case Q_QUOTAOFF: + if (sb->s_qop->quotaoff) + ret = sb->s_qop->quotaoff(sb, type); + break; + + case Q_SYNC: + if (sb->s_qop->quotasync) + ret = sb->s_qop->quotasync(sb, type); + break; + + case Q_GETINFO: + if (sb->s_qop->getinfo) + ret = sb->s_qop->getinfo(sb, type, &u.info); + if (!ret && copy_to_user(addr, &u.info, sizeof(u.info))) + ret = -EFAULT; + break; + + case Q_SETINFO: + case Q_SETFLAGS: + case Q_SETGRACE: + if (!sb->s_qop->setinfo) + break; + ret = -EFAULT; + if (copy_from_user(&u.info, addr, sizeof(u.info))) + break; + ret = sb->s_qop->setinfo(sb, type, &u.info, cmds); + break; + + case Q_GETQUOTA: + if (sb->s_qop->getdqblk) + ret = sb->s_qop->getdqblk(sb, id, type, &u.mdq); + if (!ret && copy_to_user(addr, &u.mdq, sizeof(u.mdq))) + ret = -EFAULT; + break; + + case Q_SETUSE: + case Q_SETQLIM: + case Q_SETQUOTA: + if (!sb->s_qop->setdqblk) + break; + ret = -EFAULT; + if (copy_from_user(&u.mdq, addr, sizeof(u.mdq))) + break; + ret = sb->s_qop->setdqblk(sb, id, type, &u.mdq, cmds); + break; + + case Q_XQUOTAON: + case Q_XQUOTAOFF: + case Q_XQUOTARM: + if (!sb->s_qop->setxstate) + break; + ret = -EFAULT; + if (copy_from_user(&u.flags, addr, sizeof(u.flags))) + break; + ret = sb->s_qop->setxstate(sb, type, u.flags, cmds); + break; + + case Q_XGETQSTAT: + if (sb->s_qop->getxstate) + ret = sb->s_qop->getxstate(sb, type, &u.fqs); + if (!ret && copy_to_user(addr, &u.fqs, sizeof(u.fqs))) + ret = -EFAULT; + break; + + case Q_XSETQLIM: + if (!sb->s_qop->setxquota) + break; + ret = -EFAULT; + if (copy_from_user(&u.fdq, addr, sizeof(u.fdq))) + break; + ret = sb->s_qop->setxquota(sb, type, &u.fdq); + break; + + case Q_XGETQUOTA: + if (sb->s_qop->getxquota) + ret = sb->s_qop->getxquota(sb, type, &u.fdq); + if (!ret && copy_to_user(addr, &u.fqs, sizeof(u.fdq))) + ret = -EFAULT; + break; + + default: + } + drop_super(sb); + unlock_kernel(); + return ret; +} diff -Naur linux-2410ac8/fs/super.c linux-2410ac8-quota/fs/super.c --- linux-2410ac8/fs/super.c Mon Oct 8 13:27:00 2001 +++ linux-2410ac8-quota/fs/super.c Tue Oct 9 21:34:49 2001 @@ -437,6 +437,7 @@ sema_init(&s->s_dquot.dqio_sem, 1); sema_init(&s->s_dquot.dqoff_sem, 1); s->s_maxbytes = MAX_NON_LFS; + s->s_qop = sb_generic_quota_ops; } return s; } diff -Naur linux-2410ac8/include/linux/fs.h linux-2410ac8-quota/include/linux/fs.h --- linux-2410ac8/include/linux/fs.h Mon Oct 8 13:27:00 2001 +++ linux-2410ac8-quota/include/linux/fs.h Tue Oct 9 20:24:42 2001 @@ -376,6 +376,7 @@ /* * Includes for diskquotas and mount structures. */ +#include #include #include @@ -659,6 +660,20 @@ struct mem_dqinfo info[MAXQUOTAS]; /* Information for each quota type */ }; +struct quota_operations { + int (*quotaon)(struct super_block *, short, char *); + int (*quotaoff)(struct super_block *, short); + int (*quotasync)(struct super_block *, short); + int (*getinfo)(struct super_block *, short, struct mem_dqinfo *); + int (*setinfo)(struct super_block *, short, struct mem_dqinfo *, int); + int (*getdqblk)(struct super_block *, short, qid_t, struct mem_dqblk *); + int (*setdqblk)(struct super_block *, short, qid_t, struct mem_dqblk *, int); + int (*getxstate)(struct super_block *, short, struct fs_quota_stat *); + int (*setxstate)(struct super_block *, short, unsigned int, int); + int (*getxquota)(struct super_block *, short, struct fs_disk_quota *); + int (*setxquota)(struct super_block *, short, struct fs_disk_quota *); +}; + /* * Umount options */ @@ -720,6 +735,7 @@ struct block_device *s_bdev; struct list_head s_instances; struct quota_info s_dquot; /* Diskquota specific options */ + struct quota_operations *s_qop; union { struct minix_sb_info minix_sb; diff -Naur linux-2410ac8/include/linux/quota.h linux-2410ac8-quota/include/linux/quota.h --- linux-2410ac8/include/linux/quota.h Mon Oct 8 15:30:03 2001 +++ linux-2410ac8-quota/include/linux/quota.h Mon Oct 8 18:04:05 2001 @@ -107,7 +107,7 @@ #define Q_SETQUOTA 0x0E00 /* set limits and usage */ #define Q_SETUSE 0x0F00 /* set usage */ /* 0x1000 used by old RSQUASH */ -#define Q_GETSTATS 0x1100 /* get collected stats */ +/* 0x1100 used by GETSTATS v2, since replaced by procfs entry */ /* * The following structure defines the format of the disk quota file @@ -253,13 +253,6 @@ #define dq_bhardlimit dq_dqb.dqb_bhardlimit #define dq_itime dq_dqb.dqb_itime #define dq_btime dq_dqb.dqb_btime - -/* - * Flags used for set_dqblk. - */ -#define SET_QUOTA 0x01 -#define SET_USE 0x02 -#define SET_QLIMIT 0x04 #define QUOTA_OK 0 #define NO_QUOTA 1 diff -Naur linux-2410ac8/include/linux/quotaops.h linux-2410ac8-quota/include/linux/quotaops.h --- linux-2410ac8/include/linux/quotaops.h Mon Oct 8 13:27:00 2001 +++ linux-2410ac8-quota/include/linux/quotaops.h Mon Oct 8 18:26:56 2001 @@ -17,6 +17,9 @@ #include +extern struct quota_operations generic_quota_ops; +#define sb_generic_quota_ops (&generic_quota_ops) + /* * declaration of quota_function calls in kernel. */ @@ -166,6 +169,7 @@ /* * NO-OP when quota not configured. */ +#define sb_generic_quota_ops (NULL) #define DQUOT_INIT(inode) do { } while(0) #define DQUOT_DROP(inode) do { } while(0) #define DQUOT_ALLOC_INODE(inode) (0) diff -Naur linux-2410ac8/include/linux/sysctl.h linux-2410ac8-quota/include/linux/sysctl.h --- linux-2410ac8/include/linux/sysctl.h Mon Oct 8 13:27:00 2001 +++ linux-2410ac8-quota/include/linux/sysctl.h Mon Oct 8 18:04:06 2001 @@ -535,7 +535,7 @@ FS_STATINODE=2, FS_MAXINODE=3, /* int:maximum number of inodes that can be allocated */ FS_NRDQUOT=4, /* int:current number of allocated dquots */ - FS_MAXDQUOT=5, /* int:maximum number of dquots that can be allocated */ + /* was FS_MAXDQUOT */ FS_NRFILE=6, /* int:current number of allocated filedescriptors */ FS_MAXFILE=7, /* int:maximum number of filedescriptors that can be allocated */ FS_DENTRY=8, diff -Naur linux-2410ac8/include/linux/xqm.h linux-2410ac8-quota/include/linux/xqm.h --- linux-2410ac8/include/linux/xqm.h Thu Jan 1 10:00:00 1970 +++ linux-2410ac8-quota/include/linux/xqm.h Mon Oct 8 18:04:05 2001 @@ -0,0 +1,158 @@ +/* + * Copyright (c) 2000 Silicon Graphics, Inc. All Rights Reserved. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of version 2 of the GNU General Public License as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it would be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + * + * Further, this software is distributed without any warranty that it is + * free of the rightful claim of any third person regarding infringement + * or the like. Any license provided herein, whether implied or + * otherwise, applies only to this software file. Patent licenses, if + * any, provided herein do not apply to combinations of this program with + * other software, or any other product whatsoever. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write the Free Software Foundation, Inc., 59 + * Temple Place - Suite 330, Boston MA 02111-1307, USA. + * + * Contact information: Silicon Graphics, Inc., 1600 Amphitheatre Pkwy, + * Mountain View, CA 94043, or: + * + * http://www.sgi.com + * + * For further information regarding this notice, see: + * + * http://oss.sgi.com/projects/GenInfo/SGIGPLNoticeExplan/ + */ +#ifndef _LINUX_XQM_H +#define _LINUX_XQM_H + +#include + +/* + * Disk quota - quotactl(2) commands for the XFS Quota Manager (XQM). + */ + +#define XQM_CMD(x) (('X'<<8)+(x)) /* note: forms first QCMD argument */ +#define Q_XQUOTAON XQM_CMD(0x1) /* enable accounting/enforcement */ +#define Q_XQUOTAOFF XQM_CMD(0x2) /* disable accounting/enforcement */ +#define Q_XGETQUOTA XQM_CMD(0x3) /* get disk limits and usage */ +#define Q_XSETQLIM XQM_CMD(0x4) /* set disk limits */ +#define Q_XGETQSTAT XQM_CMD(0x5) /* get quota subsystem status */ +#define Q_XQUOTARM XQM_CMD(0x6) /* free disk space used by dquots */ + +/* + * fs_disk_quota structure: + * + * This contains the current quota information regarding a user/proj/group. + * It is 64-bit aligned, and all the blk units are in BBs (Basic Blocks) of + * 512 bytes. + */ +#define FS_DQUOT_VERSION 1 /* fs_disk_quota.d_version */ +typedef struct fs_disk_quota { + __s8 d_version; /* version of this structure */ + __s8 d_flags; /* XFS_{USER,PROJ,GROUP}_QUOTA */ + __u16 d_fieldmask; /* field specifier */ + __u32 d_id; /* user, project, or group ID */ + __u64 d_blk_hardlimit;/* absolute limit on disk blks */ + __u64 d_blk_softlimit;/* preferred limit on disk blks */ + __u64 d_ino_hardlimit;/* maximum # allocated inodes */ + __u64 d_ino_softlimit;/* preferred inode limit */ + __u64 d_bcount; /* # disk blocks owned by the user */ + __u64 d_icount; /* # inodes owned by the user */ + __s32 d_itimer; /* zero if within inode limits */ + /* if not, we refuse service */ + __s32 d_btimer; /* similar to above; for disk blocks */ + __u16 d_iwarns; /* # warnings issued wrt num inodes */ + __u16 d_bwarns; /* # warnings issued wrt disk blocks */ + __s32 d_padding2; /* padding2 - for future use */ + __u64 d_rtb_hardlimit;/* absolute limit on realtime blks */ + __u64 d_rtb_softlimit;/* preferred limit on RT disk blks */ + __u64 d_rtbcount; /* # realtime blocks owned */ + __s32 d_rtbtimer; /* similar to above; for RT disk blks */ + __u16 d_rtbwarns; /* # warnings issued wrt RT disk blks */ + __s16 d_padding3; /* padding3 - for future use */ + char d_padding4[8]; /* yet more padding */ +} fs_disk_quota_t; + +/* + * These fields are sent to Q_XSETQLIM to specify fields that need to change. + */ +#define FS_DQ_ISOFT (1<<0) +#define FS_DQ_IHARD (1<<1) +#define FS_DQ_BSOFT (1<<2) +#define FS_DQ_BHARD (1<<3) +#define FS_DQ_RTBSOFT (1<<4) +#define FS_DQ_RTBHARD (1<<5) +#define FS_DQ_LIMIT_MASK (FS_DQ_ISOFT | FS_DQ_IHARD | FS_DQ_BSOFT | \ + FS_DQ_BHARD | FS_DQ_RTBSOFT | FS_DQ_RTBHARD) +/* + * These timers can only be set in super user's dquot. For others, timers are + * automatically started and stopped. Superusers timer values set the limits + * for the rest. In case these values are zero, the DQ_{F,B}TIMELIMIT values + * defined below are used. + * These values also apply only to the d_fieldmask field for Q_XSETQLIM. + */ +#define FS_DQ_BTIMER (1<<6) +#define FS_DQ_ITIMER (1<<7) +#define FS_DQ_RTBTIMER (1<<8) +#define FS_DQ_TIMER_MASK (FS_DQ_BTIMER | FS_DQ_ITIMER | FS_DQ_RTBTIMER) + +/* + * The following constants define the default amount of time given a user + * before the soft limits are treated as hard limits (usually resulting + * in an allocation failure). These may be modified by the quotactl(2) + * system call with the Q_XSETQLIM command. + */ +#define DQ_FTIMELIMIT (7 * 24*60*60) /* 1 week */ +#define DQ_BTIMELIMIT (7 * 24*60*60) /* 1 week */ + +/* + * Various flags related to quotactl(2). Only relevant to XFS filesystems. + */ +#define XFS_QUOTA_UDQ_ACCT (1<<0) /* user quota accounting */ +#define XFS_QUOTA_UDQ_ENFD (1<<1) /* user quota limits enforcement */ +#define XFS_QUOTA_GDQ_ACCT (1<<2) /* group quota accounting */ +#define XFS_QUOTA_GDQ_ENFD (1<<3) /* group quota limits enforcement */ + +#define XFS_USER_QUOTA (1<<0) /* user quota type */ +#define XFS_PROJ_QUOTA (1<<1) /* (IRIX) project quota type */ +#define XFS_GROUP_QUOTA (1<<2) /* group quota type */ + +/* + * fs_quota_stat is the struct returned in Q_XGETQSTAT for a given file system. + * Provides a centralized way to get meta infomation about the quota subsystem. + * eg. space taken up for user and group quotas, number of dquots currently + * incore. + */ +#define FS_QSTAT_VERSION 1 /* fs_quota_stat.qs_version */ + +/* + * Some basic infomation about 'quota files'. + */ +typedef struct fs_qfilestat { + __u64 qfs_ino; /* inode number */ + __u64 qfs_nblks; /* number of BBs 512-byte-blks */ + __u32 qfs_nextents; /* number of extents */ +} fs_qfilestat_t; + +typedef struct fs_quota_stat { + __s8 qs_version; /* version number for future changes */ + __u16 qs_flags; /* XFS_QUOTA_{U,P,G}DQ_{ACCT,ENFD} */ + __s8 qs_pad; /* unused */ + fs_qfilestat_t qs_uquota; /* user quota storage information */ + fs_qfilestat_t qs_gquota; /* group quota storage information */ + __u32 qs_incoredqs; /* number of dquots incore */ + __s32 qs_btimelimit; /* limit for blks timer */ + __s32 qs_itimelimit; /* limit for inodes timer */ + __s32 qs_rtbtimelimit;/* limit for rt blks timer */ + __u16 qs_bwarnlimit; /* limit for num warnings */ + __u16 qs_iwarnlimit; /* limit for num warnings */ +} fs_quota_stat_t; + +#endif /* _LINUX_XQM_H */ From owner-linux-xfs@oss.sgi.com Tue Oct 9 05:33:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f99CXHi14475 for linux-xfs-outgoing; Tue, 9 Oct 2001 05:33:17 -0700 Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f99CXED14453 for ; Tue, 9 Oct 2001 05:33:14 -0700 Received: from alan by the-village.bc.nu with local (Exim 3.22 #1) id 15qw8x-00041l-00; Tue, 09 Oct 2001 13:37:55 +0100 Subject: Re: [PATCH] Re: ENOATTR and other error enums To: nathans@sgi.com (Nathan Scott) Date: Tue, 9 Oct 2001 13:37:55 +0100 (BST) Cc: torvalds@transmeta.com (Linus Torvalds), alan@lxorguk.ukuu.org.uk (Alan Cox), ag@bestbits.at (Andreas Gruenbacher), linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org In-Reply-To: <20011009150113.A497835@wobbly.melbourne.sgi.com> from "Nathan Scott" at Oct 09, 2001 03:01:14 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > XFS needs both values. ENOATTR is also required by the ext2 > extended attributes project (and any other filesystem intending > to implement extended attributes in the future). Both values > need to be visible in both kernel and user space, so this patch > would be an initial step toward libc support also, hopefully. > > In the absence of any cleaner way to do this (?), could we have > this patch applied please? Any/all feedback much appreciated Such an update needs to be synchronized with glibc to avoid people getting all sorts of odd "unknown" error messages. In general I dn't see why its needed. > > EFSCORRUPTED = Filesystem is corrupted EIO is normally used for this As to the string names for errors. They can't sanely go into the kernel or kernel headers. Remember there are a lot of languages out there From owner-linux-xfs@oss.sgi.com Tue Oct 9 05:34:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f99CYMt14611 for linux-xfs-outgoing; Tue, 9 Oct 2001 05:34:22 -0700 Received: from main.braxis.co.uk (root@main.braxis.co.uk [213.77.40.29]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f99CYHD14589 for ; Tue, 9 Oct 2001 05:34:18 -0700 Received: (from kszysiu@localhost) by main.braxis.co.uk (8.11.6/8.11.6) id f99CYEa28720; Tue, 9 Oct 2001 14:34:14 +0200 Date: Tue, 9 Oct 2001 14:34:14 +0200 From: Krzysztof Rusocki To: Seth Mos Cc: Willi.Langenberger@wu-wien.ac.at, linux-xfs@oss.sgi.com Subject: Re: Bug in sgi-xfs? Message-ID: <20011009143414.B9570@main.braxis.co.uk> References: <15298.49018.477634.619452@slime.wu-wien.ac.at> <15298.48625.831518.499561@slime.wu-wien.ac.at> <15298.49018.477634.619452@slime.wu-wien.ac.at> <20011009131721.A9570@main.braxis.co.uk> <4.3.2.7.2.20011009133023.02cfda58@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20011009133023.02cfda58@pop.xs4all.nl>; from knuffie@xs4all.nl on Tue, Oct 09, 2001 at 01:54:17PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Oct 09, 2001 at 01:54:17PM +0200, Seth Mos wrote: Hi Seth, > That would mean a kernel needs to be heavily tested before it can be used > for an update disk. So, you mean that testing 2.4.10 received is still insufficient ? > Since the development is past 1.0.1 already and fitting 1.0.1 from 2.4.5 on > a newer kernel wouldn't be a really good idea either. I really can't see the point why it shouldn't be good idea. What speaks against doing so? any known problems? Actually I tried to speak in the name of few people that either already reported issues concerning 2.4.5 itself, or - undoubtfully - will report such problems in future. I really doubt if 2.4.5 is more ,,stable'' (according to new stability definition that came with 2.4 series ;P ) than 2.4.10. Personally, I use cvs kernels so it does not affect me, what I said is just my suggestion/opinion, choice is yours ;-) > It is very likely that by the time a redhat 7.2 update disk comes along we > will probably have a newer version included anyways. Those words doesn't speak against upgrading rpms ;-) Cheers, Krzysztof From owner-linux-xfs@oss.sgi.com Tue Oct 9 06:33:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f99DXs415801 for linux-xfs-outgoing; Tue, 9 Oct 2001 06:33:54 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f99DXmD15779 for ; Tue, 9 Oct 2001 06:33:48 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with SMTP id f99DXfW32643 for ; Tue, 9 Oct 2001 06:33:41 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA27958; Tue, 9 Oct 2001 23:32:10 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id XAA40633; Tue, 9 Oct 2001 23:31:59 +1000 (AEDT) Date: Tue, 9 Oct 2001 23:31:59 +1000 From: Nathan Scott To: Alan Cox Cc: Linus Torvalds , Andreas Gruenbacher , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] Re: ENOATTR and other error enums Message-ID: <20011009233159.C473872@wobbly.melbourne.sgi.com> References: <20011009150113.A497835@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from alan@lxorguk.ukuu.org.uk on Tue, Oct 09, 2001 at 01:37:55PM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Alan, Thanks for the comments. On Tue, Oct 09, 2001 at 01:37:55PM +0100, Alan Cox wrote: > > XFS needs both values. ENOATTR is also required by the ext2 > > extended attributes project (and any other filesystem intending > > to implement extended attributes in the future). Both values > > need to be visible in both kernel and user space, so this patch > > would be an initial step toward libc support also, hopefully. > > > > In the absence of any cleaner way to do this (?), could we have > > this patch applied please? Any/all feedback much appreciated > > Such an update needs to be synchronized with glibc to avoid people > getting all sorts of odd "unknown" error messages. Yup, understood. I was punting that it would need to appear in the kernel headers first though, so thought I'd test the water with you guys and try to understand the process for such a change. The "unknown error" messages can't really be avoided in all cases anyway - even when there is a coordinated libc release there will always be (the vast majority of?) people running new kernels with older libc versions for awhile ... thats life though, I guess, if there's no other solution to the problem. > In general I dn't see why its needed. For ENOATTR, an error code is needed which doesn't conflict with any other used in the filesystem, so that a failure to get/set/... an extended attribute can be distinguished from other errors related to looking up the pathname initially, as an example. > > > EFSCORRUPTED = Filesystem is corrupted > > EIO is normally used for this Yeah, the semantics here are slightly different, but perhaps we can get away with this... (Steve? do you know of any cases in the code where we need to be able to distinguish the EIO value from EFSCORRUPTED? or any other reason why this wouldn't work? It is the obvious one - I'd imagine there was a reason for not using it originally). > As to the string names for errors. They can't sanely go into the kernel > or kernel headers. Yes, that wasn't being suggested. > Remember there are a lot of languages out there Yup - understood. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Oct 9 07:38:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f99Ecuv16842 for linux-xfs-outgoing; Tue, 9 Oct 2001 07:38:56 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f99EcnD16820 for ; Tue, 9 Oct 2001 07:38:49 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA02416 for ; Tue, 9 Oct 2001 07:37:50 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA56353; Tue, 9 Oct 2001 07:38:00 -0700 (PDT) Message-ID: <3BC30B01.183E0FCC@sgi.com> Date: Tue, 09 Oct 2001 09:34:41 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: Krzysztof Rusocki CC: Seth Mos , Willi.Langenberger@wu-wien.ac.at, linux-xfs@oss.sgi.com Subject: Re: Bug in sgi-xfs? References: <15298.49018.477634.619452@slime.wu-wien.ac.at> <15298.48625.831518.499561@slime.wu-wien.ac.at> <15298.49018.477634.619452@slime.wu-wien.ac.at> <20011009131721.A9570@main.braxis.co.uk> <4.3.2.7.2.20011009133023.02cfda58@pop.xs4all.nl> <20011009143414.B9570@main.braxis.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Krzysztof - A couple of points - "XFS 1.0.1 for Linux 2.4.10" is almost impossible, by definition - the VM has changed so much in 2.4.10 that XFS/pagebuf had to be rearranged around the kernel - and parts of the XFS code for 2.4.10 is fundamentally different code than that released for 2.4.5. So I wouldn't want to call any XFS code running under Linux 2.4.10 "XFS 1.0.1" Regarding testing of 2.4.10, there has not been extensive testing of that snapshot at SGI (at least not on the level of a release kernel). However, I have found the CVS tree to be quite stable, at least when it's at one of Linus' major releases (not -preX). In fact, Mandrake took the 2.4.8 snapshot for their release kernel, and they were very impressed with the stability. There will continue to be stable, heavily tested XFS releases, but not for every kernel version, simply due to how much time and resources are available. -Eric Krzysztof Rusocki wrote: > > On Tue, Oct 09, 2001 at 01:54:17PM +0200, Seth Mos wrote: > > Hi Seth, > > > That would mean a kernel needs to be heavily tested before it can be used > > for an update disk. > > So, you mean that testing 2.4.10 received is still insufficient ? > > > Since the development is past 1.0.1 already and fitting 1.0.1 from 2.4.5 on > > a newer kernel wouldn't be a really good idea either. > > I really can't see the point why it shouldn't be good idea. What speaks > against doing so? any known problems? > Actually I tried to speak in the name of few people that either already reported > issues concerning 2.4.5 itself, or - undoubtfully - will report such problems > in future. > I really doubt if 2.4.5 is more ,,stable'' (according to new stability > definition that came with 2.4 series ;P ) than 2.4.10. > > Personally, I use cvs kernels so it does not affect me, what I said is just > my suggestion/opinion, choice is yours ;-) > > > It is very likely that by the time a redhat 7.2 update disk comes along we > > will probably have a newer version included anyways. > > Those words doesn't speak against upgrading rpms ;-) > > Cheers, > Krzysztof -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Oct 9 07:46:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f99Ek2B17136 for linux-xfs-outgoing; Tue, 9 Oct 2001 07:46:02 -0700 Received: from main.braxis.co.uk (root@main.braxis.co.uk [213.77.40.29]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f99EjwD17110 for ; Tue, 9 Oct 2001 07:45:58 -0700 Received: (from kszysiu@localhost) by main.braxis.co.uk (8.11.6/8.11.6) id f99EjiC02613; Tue, 9 Oct 2001 16:45:44 +0200 Date: Tue, 9 Oct 2001 16:45:44 +0200 From: Krzysztof Rusocki To: Hristo Grigorov Cc: linux-xfs@oss.sgi.com Subject: Re: xfs for -ac kernel Message-ID: <20011009164544.A2512@main.braxis.co.uk> References: <20011008192821.KGKL1085.fep06-app.kolumbus.fi@there> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011008192821.KGKL1085.fep06-app.kolumbus.fi@there>; from Hristo.Grigorov@Kolumbus.FI on Mon, Oct 08, 2001 at 10:28:22PM +0300 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Oct 08, 2001 at 10:28:22PM +0300, Hristo Grigorov wrote: Hello Hristo, > I know it's really hard to maintain XFS patches for the -ac kernels but > since nowdays they differ so much from the -linus ones it would be nice > if we have at least one patch for them as a starting point. Like XFS patch > for 2.4.10-ac1 would help a lot (I think I can do the rest myself). Then > the next one can be for 2.4.11-ac1 and so on. If 2.4.8-ac12 can be enough for you than you may try starting at Mandrake 8.1 kernel-2.4.8-26mdk.src.rpm which does include xfs and is 2.4.8-ac12 based. Cheers, Krzysztof > > -- > Regards, Hristo. From owner-linux-xfs@oss.sgi.com Tue Oct 9 11:34:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f99IYuX21048 for linux-xfs-outgoing; Tue, 9 Oct 2001 11:34:56 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f99IYnD21026 for ; Tue, 9 Oct 2001 11:34:49 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f99IYdW01402 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Tue, 9 Oct 2001 11:34:40 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id UAA2813498 for ; Tue, 9 Oct 2001 20:33:58 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA3267065; Tue, 9 Oct 2001 13:33:21 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA01391; Tue, 9 Oct 2001 13:33:20 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f99IWB201347; Tue, 9 Oct 2001 13:32:11 -0500 Message-Id: <200110091832.f99IWB201347@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: ian.nelson@echostar.com cc: Eric Sandeen , "linux-xfs@oss.sgi.com" Subject: Re: Difference between XFS_IOC_FREESP and XFS_IOC_UNRESVSP In-Reply-To: Message from "Ian S. Nelson" of "Mon, 08 Oct 2001 15:29:38 MDT." <3BC21AC2.499CBA57@echostar.com> Date: Tue, 09 Oct 2001 13:32:11 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > So the fcntl is different from the ioctl? No, Irix uses fcntl for these calls, we made them ioctl calls on Linux. > > What I'm trying to do is poke a hole in a file where there used to be data. > The > specific application is with a big long stream of mpeg data and we want to > truncate it from the front to avoid running out of disk space. > > > Here is my function: > > int trim(int fd, unsigned long long offset) > { > struct xfs_flock64 flock; > int rc; > > flock.l_whence = 0; > flock.l_start = 0; > flock.l_len = offset; > > rc = ioctl( fd, XFS_IOC_UNRESVSP, &flock ); > printf("rc: %d\n", rc); > } > > > When I put an XFS_IOC_FREESP in then it makes a zero length file. If I put > XFS_IOC_UNRESVSP in then it looks like it pokes a hole in the whole file. Am > I > trying to do something that XFS on linux won't do? To remove space from a file you should use UNRESVSP, FREESP will only work at the end of the file I think. You say UNRESVSP is poking a hole in the whole file, are you saying that the complete contents disappear? Can you run the xfs_bmap -v command on the file before and after your program? This will report what the extents look like and should report the space being removed. Note that neither call can change the file offset of the data, so you cannot remove the first Mbyte from a file and have what used to be the second Mbyte appear as the start of the file, you can merely free the space used by the first Mbyte. It is entirely possible you are hitting a bug in the XFS linux code here, these calls are not frequently used. Steve From owner-linux-xfs@oss.sgi.com Tue Oct 9 11:41:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f99IftY21266 for linux-xfs-outgoing; Tue, 9 Oct 2001 11:41:55 -0700 Received: from linux0.echostar.com (w146-253.echostar.com [205.172.146.253]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f99IfnD21243 for ; Tue, 9 Oct 2001 11:41:49 -0700 Received: from echostar.com (linux10.echostar.com [10.79.98.110]) by linux0.echostar.com (Postfix) with ESMTP id 6475679085; Tue, 9 Oct 2001 12:41:38 -0600 (MDT) Message-ID: <3BC344E3.4F4A7D4B@echostar.com> Date: Tue, 09 Oct 2001 12:41:39 -0600 From: "Ian S. Nelson" Reply-To: ian.nelson@echostar.com Organization: Echostar X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.4.3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord Cc: Eric Sandeen , "linux-xfs@oss.sgi.com" Subject: Re: Difference between XFS_IOC_FREESP and XFS_IOC_UNRESVSP References: <200110091832.f99IWB201347@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: > > So the fcntl is different from the ioctl? > > No, Irix uses fcntl for these calls, we made them ioctl calls on Linux. good, I was starting to sweat that a little. I thought they were implemented in Linux. > > > > What I'm trying to do is poke a hole in a file where there used to be data. > > The > > specific application is with a big long stream of mpeg data and we want to > > truncate it from the front to avoid running out of disk space. > > > > > > Here is my function: > > > > int trim(int fd, unsigned long long offset) > > { > > struct xfs_flock64 flock; > > int rc; > > > > flock.l_whence = 0; > > flock.l_start = 0; > > flock.l_len = offset; > > > > rc = ioctl( fd, XFS_IOC_UNRESVSP, &flock ); > > printf("rc: %d\n", rc); > > } > > > > > > When I put an XFS_IOC_FREESP in then it makes a zero length file. If I put > > XFS_IOC_UNRESVSP in then it looks like it pokes a hole in the whole file. Am > > I > > trying to do something that XFS on linux won't do? > > To remove space from a file you should use UNRESVSP, FREESP will only work > at the end of the file I think. > > You say UNRESVSP is poking a hole in the whole file, are you saying that > the complete contents disappear? Can you run the xfs_bmap -v command on > the file before and after your program? This will report what the extents > look like and should report the space being removed. I will do that immediately and post a follow up as soon as I'm done. > Note that neither call can change the file offset of the data, so you > cannot remove the first Mbyte from a file and have what used to be the > second Mbyte appear as the start of the file, you can merely free the > space used by the first Mbyte. That is exactly what I want. I'm building a TiVo and so we are always recording what is on live TV so that the user can pause it and go back. We just want to be able to free space if the user leaves the box on for a week and never changes channel or does something to cause us to start the recording over. With our MPEG indexing, I think it's actually easier to have a sparse file of the same "length" and then to just remember that we cut the front out of it... Thank you for you help and I'll post a follow up in a few minutes. Ian Nelson > It is entirely possible you are hitting a bug in the XFS linux code here, > these calls are not frequently used. > > Steve From owner-linux-xfs@oss.sgi.com Tue Oct 9 12:36:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f99JaOT22169 for linux-xfs-outgoing; Tue, 9 Oct 2001 12:36:24 -0700 Received: from linux0.echostar.com (w146-253.echostar.com [205.172.146.253]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f99JaGD22144 for ; Tue, 9 Oct 2001 12:36:16 -0700 Received: from echostar.com (linux10.echostar.com [10.79.98.110]) by linux0.echostar.com (Postfix) with ESMTP id 7133879089; Tue, 9 Oct 2001 13:36:05 -0600 (MDT) Message-ID: <3BC351A6.2E5EFFBF@echostar.com> Date: Tue, 09 Oct 2001 13:36:06 -0600 From: "Ian S. Nelson" Reply-To: ian.nelson@echostar.com Organization: Echostar X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.4.3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord , Eric Sandeen , "linux-xfs@oss.sgi.com" Subject: Re: Difference between XFS_IOC_FREESP and XFS_IOC_UNRESVSP References: <200110091832.f99IWB201347@jen.americas.sgi.com> <3BC344E3.4F4A7D4B@echostar.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk My mistake. It looks like the unreservespace is working correctly now... xfs_bmap says there is a hole and it now looks like there is one in the file. thanks, Ian "Ian S. Nelson" wrote: > Steve Lord wrote: > > > > So the fcntl is different from the ioctl? > > > > No, Irix uses fcntl for these calls, we made them ioctl calls on Linux. > > good, I was starting to sweat that a little. I thought they were implemented in > Linux. > > > > > > > What I'm trying to do is poke a hole in a file where there used to be data. > > > The > > > specific application is with a big long stream of mpeg data and we want to > > > truncate it from the front to avoid running out of disk space. > > > > > > > > > Here is my function: > > > > > > int trim(int fd, unsigned long long offset) > > > { > > > struct xfs_flock64 flock; > > > int rc; > > > > > > flock.l_whence = 0; > > > flock.l_start = 0; > > > flock.l_len = offset; > > > > > > rc = ioctl( fd, XFS_IOC_UNRESVSP, &flock ); > > > printf("rc: %d\n", rc); > > > } > > > > > > > > > When I put an XFS_IOC_FREESP in then it makes a zero length file. If I put > > > XFS_IOC_UNRESVSP in then it looks like it pokes a hole in the whole file. Am > > > I > > > trying to do something that XFS on linux won't do? > > > > To remove space from a file you should use UNRESVSP, FREESP will only work > > at the end of the file I think. > > > > You say UNRESVSP is poking a hole in the whole file, are you saying that > > the complete contents disappear? Can you run the xfs_bmap -v command on > > the file before and after your program? This will report what the extents > > look like and should report the space being removed. > > I will do that immediately and post a follow up as soon as I'm done. > > > Note that neither call can change the file offset of the data, so you > > cannot remove the first Mbyte from a file and have what used to be the > > second Mbyte appear as the start of the file, you can merely free the > > space used by the first Mbyte. > > That is exactly what I want. I'm building a TiVo and so we are always recording > what is on live TV so that the user can pause it and go back. We just want to be > able to free space if the user leaves the box on for a week and never changes > channel or does something to cause us to start the recording over. With our MPEG > indexing, I think it's actually easier to have a sparse file of the same "length" > and then to just remember that we cut the front out of it... > > Thank you for you help and I'll post a follow up in a few minutes. > > Ian Nelson > > > It is entirely possible you are hitting a bug in the XFS linux code here, > > these calls are not frequently used. > > > > Steve From owner-linux-xfs@oss.sgi.com Tue Oct 9 13:58:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f99KwmU23694 for linux-xfs-outgoing; Tue, 9 Oct 2001 13:58:48 -0700 Received: from linux0.echostar.com (w146-253.echostar.com [205.172.146.253]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f99KwjD23671 for ; Tue, 9 Oct 2001 13:58:46 -0700 Received: from echostar.com (linux10.echostar.com [10.79.98.110]) by linux0.echostar.com (Postfix) with ESMTP id 3B6BE79089; Tue, 9 Oct 2001 14:58:35 -0600 (MDT) Message-ID: <3BC364FD.BBF46C42@echostar.com> Date: Tue, 09 Oct 2001 14:58:37 -0600 From: "Ian S. Nelson" Reply-To: ian.nelson@echostar.com Organization: Echostar X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.4.3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord , Eric Sandeen , "linux-xfs@oss.sgi.com" Subject: Re: Difference between XFS_IOC_FREESP and XFS_IOC_UNRESVSP References: <200110091832.f99IWB201347@jen.americas.sgi.com> <3BC344E3.4F4A7D4B@echostar.com> <3BC351A6.2E5EFFBF@echostar.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk My mistake was that my test harness wasn't multiplying my "kilobytes" to delete by the proper multiplier. When you poke a 2K hole in a file you might not actually free any blocks, where a 2MB file has to free some block. sorry for the error and thanks again for the help, Ian Nelson Echostar Technologies Corp. Ian S. Nelson" wrote: > My mistake. It looks like the unreservespace is working correctly now... xfs_bmap > says there is a hole and it now looks like there is one in the file. > > thanks, > Ian From owner-linux-xfs@oss.sgi.com Tue Oct 9 14:05:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f99L5kK24055 for linux-xfs-outgoing; Tue, 9 Oct 2001 14:05:46 -0700 Received: from wagnerlab.med.harvard.edu (wagnerlab.med.harvard.edu [134.174.146.27]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f99L5gD24030 for ; Tue, 9 Oct 2001 14:05:42 -0700 Received: from plato.med.harvard.edu (plato.med.harvard.edu [134.174.146.37]) by wagnerlab.med.harvard.edu (SGI-8.9.3/8.9.3) with ESMTP id RAA88231; Tue, 9 Oct 2001 17:05:36 -0400 (EDT) Received: from localhost (shyberts@localhost) by plato.med.harvard.edu (SGI-8.9.3/8.9.3) with ESMTP id RAA09136; Tue, 9 Oct 2001 17:05:35 -0400 (EDT) Date: Tue, 9 Oct 2001 17:05:35 -0400 From: Sven G Hyberts Reply-To: Sven Hyberts To: Eric Sandeen cc: Steve Lord , Sebastian Kun , linux-xfs@oss.sgi.com Subject: Re: CXFS [was: XFS (v.1.0.1 for RedHat 7.1) and XFS (Irix 6.5.13m) differ?] In-Reply-To: <200109271535.f8RFZf908442@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dear Eric, Thanks for all the activity my question produced! I starting to grasp the problems with a fast, distributed, file-system! I also have come to realize really how good XFS is! I made a couple of attempts to get GFS on a Linux machine. It turned out to quite hard - and once I got it through the compiler, I get the notice that several functions are not defined. Maybe I give it another attempt - yet after realizing that it is a non-journaling file system format, the lure isn't as "shiny" any more... I do not have enough money to check out SANergy from Tivoli - after all, it seem to be the only product around currently that is available cross-platform for SGI and Linux(RedHat). Still, it seem a bit as an NFS wrap more than a real product. Left is CXFS - if this is as good as XFS, it is most likely a great product. Yet, the price level still seem unreasonable for a non-critical environment, and currently there is no Linux release. If there would be a way to come in contact with someone who could respond to my concerns around CXFS, it would be greatly appreciated. Sincerely, ________________________________________________________________________ Sven G. Hyberts, Ph.D Research Associate Harvard University, Medical School e-mail: sven_hyberts@hms.harvard.edu 240 Longwood Ave; Dept BCMP voice: (617) 432-1721, 432-3211 Boston MA 02115 - USA fax: (617) 738-0516, 432-4383 From owner-linux-xfs@oss.sgi.com Tue Oct 9 14:55:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f99LtvV25135 for linux-xfs-outgoing; Tue, 9 Oct 2001 14:55:57 -0700 Received: from woody.fsl.noaa.gov (IDENT:root@woody.fsl.noaa.gov [137.75.132.225]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f99LtpD25110 for ; Tue, 9 Oct 2001 14:55:51 -0700 Received: (from tierney@localhost) by woody.fsl.noaa.gov (8.9.3/8.9.3) id PAA26527; Tue, 9 Oct 2001 15:55:05 -0600 Date: Tue, 9 Oct 2001 15:55:05 -0600 From: Craig Tierney To: Sven Hyberts Cc: Eric Sandeen , Steve Lord , Sebastian Kun , linux-xfs@oss.sgi.com Subject: Re: CXFS [was: XFS (v.1.0.1 for RedHat 7.1) and XFS (Irix 6.5.13m) differ?] Message-ID: <20011009155505.G26397@hpti.com> References: <200109271535.f8RFZf908442@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.6i In-Reply-To: ; from shyberts@plato.med.harvard.edu on Tue, Oct 09, 2001 at 05:05:35PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Oct 09, 2001 at 05:05:35PM -0400, Sven G Hyberts wrote: > Dear Eric, > > Thanks for all the activity my question produced! I starting to > grasp the problems with a fast, distributed, file-system! I also have > come to realize really how good XFS is! > > I made a couple of attempts to get GFS on a Linux machine. It > turned out to quite hard - and once I got it through the compiler, I get > the notice that several functions are not defined. Maybe I give it > another attempt - yet after realizing that it is a non-journaling file > system format, the lure isn't as "shiny" any more... I haven't tried GFS lately but it was pretty easy to get going except for the stomith. However stability was a different issue. I was using GFS 4.0.X under Alpha and could bring it down easy. I have no experience with Intel or the latest GFS. You can buy support from them. Maybe the cost is reasonable if you aren't trying to do too much. > > I do not have enough money to check out SANergy from Tivoli - > after all, it seem to be the only product around currently that is > available cross-platform for SGI and Linux(RedHat). Still, it seem a bit > as an NFS wrap more than a real product. > > Left is CXFS - if this is as good as XFS, it is most likely a > great product. Yet, the price level still seem unreasonable for a > non-critical environment, and currently there is no Linux release. If > there would be a way to come in contact with someone who could respond to > my concerns around CXFS, it would be greatly appreciated. IBM has recently released GPFS for Linux. It doesn't appear to just be a software solution as you have to buy their SAN and other equipement. A cool feature though is it looks to have a fowarding file system running over myrinet to provide high performance IO to all nodes of the cluster. Looks pricey though. ADIC has a product called CentraVision File System (CVFS). IT is a shared filesystem that came from the SGI world. They have been improving it and porting it to other platforms. It does support Linux/Intel 2.4.X. I think it is available now. I haven't checked lately. I don't know the cost though. Craig > > Sincerely, > ________________________________________________________________________ > Sven G. Hyberts, Ph.D Research Associate > Harvard University, Medical School e-mail: sven_hyberts@hms.harvard.edu > 240 Longwood Ave; Dept BCMP voice: (617) 432-1721, 432-3211 > Boston MA 02115 - USA fax: (617) 738-0516, 432-4383 -- Craig Tierney (ctierney@hpti.com) From owner-linux-xfs@oss.sgi.com Tue Oct 9 17:54:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9A0s5l28483 for linux-xfs-outgoing; Tue, 9 Oct 2001 17:54:05 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9A0s2D28461 for ; Tue, 9 Oct 2001 17:54:02 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9A0ruK13330 for ; Tue, 9 Oct 2001 17:53:56 -0700 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA45586 for linux-xfs@oss.sgi.com; Wed, 10 Oct 2001 10:52:39 +1000 (EST) Date: Wed, 10 Oct 2001 10:52:39 +1000 (EST) From: Nathan Scott Message-Id: <200110100052.KAA45586@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - dquot.c Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Oct 9 17:50:20 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/attr-linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:104241a linux/fs/dquot.c - 1.39 - fixes a little bug where we were being too restrictive in terms of allowing quota operations for unpriveledged users, introduced in the last round of quotactl changes (several weeks ago). would work with the -ac kernels, but not quite correctly with the base kernels. From owner-linux-xfs@oss.sgi.com Tue Oct 9 19:57:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9A2vOg05602 for linux-xfs-outgoing; Tue, 9 Oct 2001 19:57:24 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9A2vHD05579 for ; Tue, 9 Oct 2001 19:57:17 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA05761 for ; Tue, 9 Oct 2001 19:56:17 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id MAA14943; Wed, 10 Oct 2001 12:57:05 +1000 Date: Wed, 10 Oct 2001 12:57:05 +1000 From: Keith Owens Message-Id: <200110100257.MAA14943@sherman.melbourne.sgi.com> Subject: TAKE - Upgrade XFS to 2.4.11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Upgrade XFS to 2.4.11 Date: Tue Oct 9 19:54:51 PDT 2001 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:104249a linux/drivers/net/wireless/orinoco_plx.c - 1.1 linux/drivers/usb/serial/ir-usb.c - 1.1 linux/drivers/usb/serial/keyspan_usa28xb_fw.h - 1.1 linux/drivers/usb/serial/keyspan_usa28xa_fw.h - 1.1 linux/include/linux/fs.h - 1.125 linux/fs/namei.c - 1.39 linux/drivers/video/clgenfb.c - 1.21 linux/drivers/usb/usb.c - 1.56 linux/drivers/usb/hub.h - 1.16 linux/drivers/usb/hub.c - 1.39 linux/drivers/net/at1700.c - 1.14 linux/arch/i386/mm/fault.c - 1.20 linux/Makefile - 1.132 linux/Documentation/Configure.help - 1.107 linux/COPYING - 1.5 linux/drivers/usb/printer.c - 1.40 linux/drivers/usb/uss720.c - 1.20 linux/drivers/net/sis900.c - 1.28 linux/arch/i386/kernel/pci-pc.c - 1.27 linux/drivers/net/sis900.h - 1.11 linux/drivers/usb/usb-uhci.c - 1.31 linux/drivers/net/8139too.c - 1.28 linux/Documentation/networking/8139too.txt - 1.12 linux/include/linux/usb.h - 1.19 linux/drivers/usb/serial/Makefile - 1.16 linux/drivers/ide/Makefile - 1.13 linux/drivers/usb/dsbr100.c - 1.12 linux/drivers/net/pcmcia/xircom_tulip_cb.c - 1.15 linux/drivers/usb/mdc800.c - 1.13 linux/drivers/sound/emu10k1/mixer.c - 1.6 linux/drivers/sound/emu10k1/midi.c - 1.9 linux/drivers/sound/emu10k1/main.c - 1.13 linux/drivers/sound/emu10k1/hwaccess.h - 1.5 linux/drivers/sound/emu10k1/efxmgr.h - 1.3 linux/drivers/sound/emu10k1/efxmgr.c - 1.4 linux/drivers/sound/emu10k1/audio.c - 1.13 linux/drivers/usb/serial/keyspan_usa28x_fw.h - 1.2 linux/drivers/usb/serial/keyspan_usa28msg.h - 1.3 linux/drivers/usb/serial/keyspan_usa28_fw.h - 1.2 linux/drivers/usb/serial/keyspan_usa26msg.h - 1.3 linux/drivers/usb/serial/keyspan_usa19w_fw.h - 1.2 linux/drivers/usb/serial/keyspan_usa19_fw.h - 1.2 linux/drivers/usb/serial/keyspan_usa18x_fw.h - 1.2 linux/drivers/usb/serial/keyspan.h - 1.5 linux/drivers/usb/serial/keyspan.c - 1.14 linux/drivers/net/natsemi.c - 1.14 linux/drivers/net/hamachi.c - 1.12 linux/drivers/net/winbond-840.c - 1.13 linux/drivers/usb/serial/keyspan_usa49w_fw.h - 1.2 linux/drivers/usb/serial/keyspan_usa49msg.h - 1.2 linux/drivers/usb/serial/Config.in - 1.9 linux/drivers/usb/serial/io_edgeport.c - 1.11 linux/drivers/net/wireless/Config.in - 1.3 linux/drivers/net/wireless/Makefile - 1.3 linux/drivers/net/wireless/hermes.c - 1.6 linux/drivers/net/wireless/hermes.h - 1.6 linux/drivers/net/wireless/orinoco.c - 1.6 linux/drivers/net/wireless/orinoco.h - 1.6 linux/drivers/net/wireless/orinoco_cs.c - 1.8 linux/drivers/usb/serial/pl2303.h - 1.2 linux/drivers/usb/serial/pl2303.c - 1.5 linux/drivers/usb/storage/datafab.c - 1.4 linux/drivers/sound/emu10k1/passthrough.c - 1.3 linux/drivers/sound/emu10k1/passthrough.h - 1.3 linux/drivers/usb/kaweth.c - 1.5 linux/drivers/net/ns83820.c - 1.5 linux/drivers/usb/hpusbscsi.c - 1.2 From owner-linux-xfs@oss.sgi.com Tue Oct 9 19:59:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9A2xOw05760 for linux-xfs-outgoing; Tue, 9 Oct 2001 19:59:24 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9A2xLD05736 for ; Tue, 9 Oct 2001 19:59:21 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9A2xFW06709 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Tue, 9 Oct 2001 19:59:16 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id EAA2868396 for ; Wed, 10 Oct 2001 04:58:29 +0200 (CEST) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id MAA15009; Wed, 10 Oct 2001 12:59:00 +1000 Date: Wed, 10 Oct 2001 12:59:00 +1000 From: Keith Owens Message-Id: <200110100259.MAA15009@sherman.melbourne.sgi.com> Subject: TAKE - Remove generated scsi files Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Some generated scsi files had crept into the XFS repository. Date: Tue Oct 9 19:56:33 PDT 2001 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:104250a linux/drivers/scsi/53c8xx_u.h - 1.3 linux/drivers/scsi/53c8xx_d.h - 1.5 linux/drivers/scsi/sim710_d.h - 1.4 linux/drivers/scsi/sim710_u.h - 1.2 From owner-linux-xfs@oss.sgi.com Tue Oct 9 20:05:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9A35re05999 for linux-xfs-outgoing; Tue, 9 Oct 2001 20:05:53 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9A35pD05977 for ; Tue, 9 Oct 2001 20:05:51 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9A35jW07103 for ; Tue, 9 Oct 2001 20:05:45 -0700 Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id NAA15351; Wed, 10 Oct 2001 13:05:43 +1000 Date: Wed, 10 Oct 2001 13:05:43 +1000 From: Keith Owens Message-Id: <200110100305.NAA15351@sherman.melbourne.sgi.com> Subject: TAKE - Sync with kdb 1.9-2.4.11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sync with kdb 1.9-2.4.11 Date: Tue Oct 9 20:03:57 PDT 2001 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:104251a linux/arch/i386/kdb/bfd.h - 1.1 linux/arch/i386/kdb/ansidecl.h - 1.1 linux/arch/i386/kernel/entry.S - 1.40 linux/kdb/Makefile - 1.11 linux/kdb/modules/Makefile - 1.12 linux/arch/i386/kdb/Makefile - 1.9 From owner-linux-xfs@oss.sgi.com Wed Oct 10 00:18:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9A7InM10113 for linux-xfs-outgoing; Wed, 10 Oct 2001 00:18:49 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9A7IjD10087 for ; Wed, 10 Oct 2001 00:18:45 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id AAA02559 for ; Wed, 10 Oct 2001 00:17:46 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA83892 for linux-xfs@oss.sgi.com; Wed, 10 Oct 2001 17:17:26 +1000 (EST) Date: Wed, 10 Oct 2001 17:17:26 +1000 (EST) From: Nathan Scott Message-Id: <200110100717.RAA83892@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - quotactl Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Emulates the way the new quotactl interface is going to work, hopefully - tested out more extensively now in XFS, all seems to work just fine. cheers. Date: Wed Oct 10 00:12:17 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:104257a linux/fs/dquot.c - 1.40 linux/fs/xfs/xfs_qm_syscalls.c - 1.55 linux/fs/xfs/xfs_qm.h - 1.20 linux/fs/xfs/linux/xfs_super.c - 1.139 linux/include/linux/fs.h - 1.126 - rework for new quotactl(2) interface changes where copyin/out is done outside the filesystem, up at the syscall level. linux/include/linux/xqm.h - 1.9 cmd/xfsprogs/include/xqm.h - 1.7 - update the copyright, ditch debug operation. From owner-linux-xfs@oss.sgi.com Wed Oct 10 04:10:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ABAdG14943 for linux-xfs-outgoing; Wed, 10 Oct 2001 04:10:39 -0700 Received: from s1.uklinux.net (ns1.uklinux.net [212.1.130.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ABALD14920 for ; Wed, 10 Oct 2001 04:10:21 -0700 Received: from pyewacket.nic.uklinux.net (ppp-1b-179.3com.telinco.net [212.159.129.179]) by s1.uklinux.net (8.11.6/8.11.6) with ESMTP id f9ABAAu13174 for ; Wed, 10 Oct 2001 12:10:12 +0100 Envelope-To: Received: from [127.0.0.1] (helo=there) by pyewacket.nic.uklinux.net with smtp (Exim 3.22 #1) id 15rHGC-0000P7-00 for linux-xfs@oss.sgi.com; Wed, 10 Oct 2001 12:10:48 +0100 Content-Type: text/plain; charset="iso-8859-1" From: nic Reply-To: nic@uklinux.net Organization: Quixotic Hackers To: linux-xfs@oss.sgi.com Subject: 2.4.11 don't work yet. Date: Wed, 10 Oct 2001 12:10:48 +0100 X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi all, Maybe I'm just stupid for even trying it yet, but 2.4.11 seems to get to the stage between 'Mounting local filesystems' and before 'Enabling swap space' in rc.sysinit. You can hear it mount the local filesystems (~1second disk activity) and it prints "OK" on the screen but that's it. The filesystems must have been mounted, because they required recovery. Have been using xfs (on linux) since late march on this box (and since on 4 others) but I don't know how to a) drop into kdb b) drive it (assume similar to gdb, which I've never got on with either :-) If you need it, here's some info (if I've forgotten the bleeding obvious, tell me :-) Software info: Machine is RedHat 7.1 + glibc (and other bits) from 7.1.94 gcc-2.96-85 Hardware info: AMD Athlon Slot A 384MB RAM Asus K7V motherboard IDE disc IDE CD-RW (using ide-scsi) floppy, riva TNT2 GC, Netgear NIC, external: printer, palm cradle, 56k external modem. dmesg from running 2.4.9 kernel (rebuilt last week, because I bought a new graphics card): [root@pyewacket linux]# dmesg Linux version 2.4.9-xfs (root@pyewacket) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-85)) #2 Fri Oct 5 11:46:10 BST 2001 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 0000000017ffc000 (usable) BIOS-e820: 0000000017ffc000 - 0000000017fff000 (ACPI data) BIOS-e820: 0000000017fff000 - 0000000018000000 (ACPI NVS) BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved) Scan SMP from c0000000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f0000 for 65536 bytes. Scan SMP from c009fc00 for 4096 bytes. On node 0 totalpages: 98300 zone(0): 4096 pages. zone(1): 94204 pages. zone(2): 0 pages. mapped APIC to ffffe000 (fee00000) Kernel command line: auto BOOT_IMAGE=stable ro root=302 BOOT_FILE=/boot/vmlinuz-2.4.9-xfs-2 hdc=ide-scsi idebus=33 ide0=ata66 ide_setup: hdc=ide-scsi ide_setup: idebus=33 ide_setup: ide0=ata66 Initializing CPU#0 Detected 700.035 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1395.91 BogoMIPS Memory: 383692k/393200k available (1269k kernel code, 9120k reserved, 831k data, 216k init, 0k highmem) kdb version 1.8 by Scott Lurndal, Keith Owens. Copyright SGI, All Rights Reserved Dentry-cache hash table entries: 65536 (order: 7, 524288 bytes) Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) Mount-cache hash table entries: 8192 (order: 4, 65536 bytes) Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes) Page-cache hash table entries: 131072 (order: 7, 524288 bytes) CPU: Before vendor init, caps: 0183f9ff c1c3f9ff 00000000, vendor = 2 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU: After vendor init, caps: 0183f9ff c1c3f9ff 00000000 00000000 CPU: After generic, caps: 0183f9ff c1c3f9ff 00000000 00000000 CPU: Common caps: 0183f9ff c1c3f9ff 00000000 00000000 CPU: AMD Athlon(tm) Processor stepping 01 Enabling fast FPU save and restore... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX Local APIC disabled by BIOS -- reenabling... leaving PIC mode, enabling symmetric IO mode. enabled ExtINT on CPU#0 ESR value before enabling vector: 00000000 ESR value after enabling vector: 00000000 calibrating APIC timer ... ..... CPU clock speed is 700.0634 MHz. ..... host bus clock speed is 200.0179 MHz. cpu: 0, clocks: 2000179, slice: 1000089 CPU0 mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au) mtrr: detected mtrr type: Intel PCI: PCI BIOS revision 2.10 entry at 0xf0880, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware Unknown bridge resource 0: assuming transparent PCI: Using IRQ router VIA [1106/0686] at 00:04.0 PCI: Disabling Via external APIC routing Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 devfs: v0.107 (20010709) Richard Gooch (rgooch@atnf.csiro.au) devfs: devfs_debug: 0x0 devfs: boot_options: 0x2 SGI XFS with EAs, no debug enabled pty: 256 Unix98 ptys configured Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A block: 128 slots per queue, batch=16 Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes VP_IDE: IDE controller on PCI bus 00 dev 21 VP_IDE: chipset revision 16 VP_IDE: not 100% native mode: will probe irqs later VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci00:04.1 VP_IDE: ATA-66/100 forced bit set (WARNING)!! ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:pio hda: IBM-DPTA-372050, ATA DISK drive hdc: WPI CDRW-4424, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: 40088160 sectors (20525 MB) w/1961KiB Cache, CHS=2495/255/63 Partition check: /dev/ide/host0/bus0/target0/lun0: p1 p2 p3 < p5 p6 p7 p8 p9 > Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 natsemi.c:v1.07 1/9/2001 Written by Donald Becker http://www.scyld.com/network/natsemi.html (unofficial 2.4.x kernel port, version 1.07+LK1.0.8, Aug 07, 2001 Jeff Garzik, Tjeerd Mulder) PCI: Found IRQ 11 for device 00:0c.0 eth0: NatSemi DP83815 at 0xd8802000, 00:02:e3:12:42:3c, IRQ 11. eth0: Transceiver status 0x7869 advertising 05e1. PPP generic driver version 2.4.1 PPP Deflate Compression module registered PPP BSD Compression module registered NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 4096 buckets, 32Kbytes TCP: Hash tables configured (established 32768 bind 32768) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. Start mounting filesystem: ide0(3,2) XFS: WARNING: recovery required on readonly filesystem. XFS: write access will be enabled during mount. Starting XFS recovery on filesystem: ide0(3,2) (dev: 3/2) Ending XFS recovery on filesystem: ide0(3,2) (dev: 3/2) VFS: Mounted root (xfs filesystem) readonly. Mounted devfs on /dev Freeing unused kernel memory: 216k freed Adding Swap: 136512k swap-space (priority -1) Adding Swap: 136512k swap-space (priority -2) usb.c: registered new driver usbdevfs usb.c: registered new driver hub usb-uhci.c: $Revision: 1.259 $ time 11:55:39 Oct 5 2001 usb-uhci.c: High bandwidth mode enabled PCI: Found IRQ 10 for device 00:04.2 PCI: Sharing IRQ 10 with 00:04.3 usb-uhci.c: USB UHCI at I/O 0xd400, IRQ 10 usb-uhci.c: Detected 2 ports usb.c: new USB bus registered, assigned bus number 1 hub.c: USB hub found hub.c: 2 ports detected PCI: Found IRQ 10 for device 00:04.3 PCI: Sharing IRQ 10 with 00:04.2 usb-uhci.c: USB UHCI at I/O 0xd000, IRQ 10 usb-uhci.c: Detected 2 ports usb.c: new USB bus registered, assigned bus number 2 hub.c: USB hub found hub.c: 2 ports detected usb-uhci.c: v1.251:USB Universal Host Controller Interface driver SCSI subsystem driver Revision: 1.00 Start mounting filesystem: ide0(3,1) Ending clean XFS mount for filesystem: ide0(3,1) Start mounting filesystem: ide0(3,9) Ending clean XFS mount for filesystem: ide0(3,9) Start mounting filesystem: ide0(3,8) Ending clean XFS mount for filesystem: ide0(3,8) Start mounting filesystem: ide0(3,7) Starting XFS recovery on filesystem: ide0(3,7) (dev: 3/7) Ending XFS recovery on filesystem: ide0(3,7) (dev: 3/7) Adding Swap: 514040k swap-space (priority -3) scsi0 : SCSI host adapter emulation for IDE ATAPI devices Vendor: WPI Model: CDRW-4424 Rev: T2.0 Type: CD-ROM ANSI SCSI revision: 02 Attached scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0 sr0: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.12 spurious 8259A interrupt: IRQ7. parport0: PC-style at 0x378 [PCSPP(,...)] parport_pc: Via 686A parallel port: io=0x378 ip_tables: (c)2000 Netfilter core team ip_conntrack (3071 buckets, 24568 max) eth0: link is back. Enabling watchdog. parport0: PC-style at 0x378 [PCSPP(,...)] parport_pc: Via 686A parallel port: io=0x378 lp0: using parport0 (polling). devfs: devfs_register(): device already registered: "2" devfs: devfs_register(): device already registered: "a2" [root@pyewacket linux]# nic From owner-linux-xfs@oss.sgi.com Wed Oct 10 04:26:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ABQHe15340 for linux-xfs-outgoing; Wed, 10 Oct 2001 04:26:17 -0700 Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ABQDD15318 for ; Wed, 10 Oct 2001 04:26:13 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9ABQFNF089690; Wed, 10 Oct 2001 13:26:16 +0200 (CEST) Message-Id: <4.3.2.7.2.20011010132408.02d1f3f0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 10 Oct 2001 13:24:57 +0200 To: nic@uklinux.net, linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: 2.4.11 don't work yet. In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 12:10 10-10-2001 +0100, nic wrote: >Hi all, > >Maybe I'm just stupid for even trying it yet, but 2.4.11 seems to get to the >stage between 'Mounting local filesystems' and before 'Enabling swap space' >in rc.sysinit. > >You can hear it mount the local filesystems (~1second disk activity) and it >prints "OK" on the screen but that's it. The filesystems must have been >mounted, because they required recovery. > >Have been using xfs (on linux) since late march on this box (and since on 4 >others) but I don't know how to a) drop into kdb b) drive it (assume similar >to gdb, which I've never got on with either :-) > >If you need it, here's some info (if I've forgotten the bleeding obvious, >tell me :-) > >Software info: >Machine is RedHat 7.1 + glibc (and other bits) from 7.1.94 >gcc-2.96-85 Can you compile with compat-egcs and try again? Sometimes weird things happen with xfs and 2.96-?? -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Wed Oct 10 05:09:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9AC9LT16366 for linux-xfs-outgoing; Wed, 10 Oct 2001 05:09:21 -0700 Received: from s1.uklinux.net (ns1.uklinux.net [212.1.130.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9AC9HD16342 for ; Wed, 10 Oct 2001 05:09:18 -0700 Received: from pyewacket.nic.uklinux.net (ppp-1b-179.3com.telinco.net [212.159.129.179]) by s1.uklinux.net (8.11.6/8.11.6) with ESMTP id f9AC95o19282; Wed, 10 Oct 2001 13:09:05 +0100 Envelope-To: linux-xfs@oss.sgi.com Received: from [127.0.0.1] (helo=there) by pyewacket.nic.uklinux.net with smtp (Exim 3.22 #1) id 15rI4P-0000RJ-00; Wed, 10 Oct 2001 13:02:41 +0100 Content-Type: text/plain; charset="iso-8859-1" From: nic Reply-To: nic@uklinux.net Organization: Quixotic Hackers To: Seth Mos , linux-xfs@oss.sgi.com Subject: Re: 2.4.11 don't work yet. Date: Wed, 10 Oct 2001 13:02:41 +0100 X-Mailer: KMail [version 1.3.1] References: <4.3.2.7.2.20011010132408.02d1f3f0@pop.xs4all.nl> In-Reply-To: <4.3.2.7.2.20011010132408.02d1f3f0@pop.xs4all.nl> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wednesday 10 October 2001 12:24, Seth Mos wrote: > > >Software info: > >Machine is RedHat 7.1 + glibc (and other bits) from 7.1.94 > >gcc-2.96-85 > > Can you compile with compat-egcs and try again? > Sometimes weird things happen with xfs and 2.96-?? I've seen this said before (most often by your good self :-) but I've always built my 2.4.x-xfs kernels with it... including the one I'm running now. Will try and let you know, nic From owner-linux-xfs@oss.sgi.com Wed Oct 10 05:23:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ACNQT16892 for linux-xfs-outgoing; Wed, 10 Oct 2001 05:23:26 -0700 Received: from otto.plogic.internal (plogic.com [209.92.41.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ACNND16870 for ; Wed, 10 Oct 2001 05:23:23 -0700 Received: from rlatham by otto.plogic.internal with local (Exim 3.33 #1 (Debian)) id 15rIOQ-00072p-00 for ; Wed, 10 Oct 2001 08:23:22 -0400 Date: Wed, 10 Oct 2001 08:23:22 -0400 From: Rob Latham To: linux-xfs@oss.sgi.com Subject: Re: CXFS [was: XFS (v.1.0.1 for RedHat 7.1) and XFS (Irix 6.5.13m) differ?] Message-ID: <20011010082322.D17854@otto.plogic.internal> References: <200109271535.f8RFZf908442@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from shyberts@plato.med.harvard.edu on Tue, Oct 09, 2001 at 05:05:35PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Oct 09, 2001 at 05:05:35PM -0400, Sven G Hyberts wrote: > I made a couple of attempts to get GFS on a Linux machine. It > turned out to quite hard - and once I got it through the compiler, I get > the notice that several functions are not defined. Maybe I give it > another attempt - yet after realizing that it is a non-journaling file > system format, the lure isn't as "shiny" any more... GFS is indeed a journaling file system. ==rob -- [ Rob Latham Developer, Admin, Alchemist ] [ Paralogic Inc. - www.plogic.com ] [ ] [ EAE8 DE90 85BB 526F 3181 1FCF 51C4 B6CB 08CC 0897 ] From owner-linux-xfs@oss.sgi.com Wed Oct 10 05:23:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ACNqU16962 for linux-xfs-outgoing; Wed, 10 Oct 2001 05:23:52 -0700 Received: from gk.hm.epigenomics.net (qmailr@gk.hm.epigenomics.net [212.121.137.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ACNmD16935 for ; Wed, 10 Oct 2001 05:23:48 -0700 Received: (qmail 824 invoked from network); 10 Oct 2001 12:23:49 -0000 Received: from raman.epigenomics.epi (qmailr@192.168.2.2) by salam.epigenomics.epi with SMTP; 10 Oct 2001 12:23:49 -0000 Received: (qmail 4086 invoked from network); 10 Oct 2001 12:23:45 -0000 Received: from broglie.epigenomics.epi (qmailr@192.168.1.5) by raman.epigenomics.epi with SMTP; 10 Oct 2001 12:23:45 -0000 Received: (qmail 6979 invoked by uid 9); 10 Oct 2001 12:23:45 -0000 From: Robert Sander Reply-To: Robert Sander X-Newsgroups: epi.ml.linux.xfs Subject: 2.4.11 and large files Date: Wed, 10 Oct 2001 12:23:44 +0000 (UTC) Organization: Epigenomics AG Lines: 21 Message-ID: X-Complaints-To: usenet@epigenomics.com User-Agent: slrn/0.9.7.2 (Linux) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! I do not think this problem is XFS related, but as I got the kernel source from the XFS cvs, I just ask here: 2.4.11 compiles fine and runs, but when I try to create files that are larger than 2GB, I get SIGXFSZ, file system limit exceeded. ulimit -a shows unlimited, with 2.4.5 and XFS 1.0.1 it works. The problem is even stranger. When I do a dd if=/dev/sda of=/dev/sdb on two identical disks, I got the same signal. This shouldn't happen with block devices, should it? Anybody seen similar things? Greetings -- Robert Sander Computer Scientist Epigenomics AG Bioinformatics R&D www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Wed Oct 10 05:28:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ACS9917217 for linux-xfs-outgoing; Wed, 10 Oct 2001 05:28:09 -0700 Received: from main.braxis.co.uk (root@main.braxis.co.uk [213.77.40.29]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ACS3D17193 for ; Wed, 10 Oct 2001 05:28:03 -0700 Received: (from kszysiu@localhost) by main.braxis.co.uk (8.11.6/8.11.6) id f9ACRu924807; Wed, 10 Oct 2001 14:27:56 +0200 Date: Wed, 10 Oct 2001 14:27:55 +0200 From: Krzysztof Rusocki To: Robert Sander Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.11 and large files Message-ID: <20011010142755.A24683@main.braxis.co.uk> 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 ml-linux-xfs@epigenomics.com on Wed, Oct 10, 2001 at 12:23:44PM +0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Oct 10, 2001 at 12:23:44PM +0000, Robert Sander wrote: > Hi! > > I do not think this problem is XFS related, but as I got the kernel > source from the XFS cvs, I just ask here: > > 2.4.11 compiles fine and runs, but when I try to create files that > are larger than 2GB, I get SIGXFSZ, file system limit exceeded. > ulimit -a shows unlimited, with 2.4.5 and XFS 1.0.1 it works. > > The problem is even stranger. When I do a dd if=/dev/sda of=/dev/sdb > on two identical disks, I got the same signal. This shouldn't happen > with block devices, should it? > > Anybody seen similar things? Hello Robert, I've seen such reports about 2.4.11-pre series as well. Try looking at lkml archives - http://www.cs.helsinki.fi/linux/linux-kernel/ and asking there. AFAIR there was no solution provided for that. dd if=/dev/sda of=/dev/null works? huh ? :) Cheers, Krzysztof > > Greetings > -- > Robert Sander > Computer Scientist Epigenomics AG > Bioinformatics R&D www.epigenomics.com Kastanienallee 24 > +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Wed Oct 10 05:41:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ACf4l17572 for linux-xfs-outgoing; Wed, 10 Oct 2001 05:41:04 -0700 Received: from s1.uklinux.net (ns1.uklinux.net [212.1.130.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ACexD17550 for ; Wed, 10 Oct 2001 05:40:59 -0700 Received: from pyewacket.nic.uklinux.net (ppp-6a-93.3com.telinco.net [212.159.138.93]) by s1.uklinux.net (8.11.6/8.11.6) with ESMTP id f9ACelo22541; Wed, 10 Oct 2001 13:40:47 +0100 Envelope-To: linux-xfs@oss.sgi.com Received: from [127.0.0.1] (helo=there) by pyewacket.nic.uklinux.net with smtp (Exim 3.22 #1) id 15rIfX-0000JG-00; Wed, 10 Oct 2001 13:41:03 +0100 Content-Type: text/plain; charset="iso-8859-1" From: nic Reply-To: nic@uklinux.net Organization: Quixotic Hackers To: Seth Mos , linux-xfs@oss.sgi.com Subject: Re: 2.4.11 don't work yet. Date: Wed, 10 Oct 2001 13:41:03 +0100 X-Mailer: KMail [version 1.3.1] References: <4.3.2.7.2.20011010132408.02d1f3f0@pop.xs4all.nl> In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wednesday 10 October 2001 13:02, nic wrote: > On Wednesday 10 October 2001 12:24, Seth Mos wrote: > > >Software info: > > >Machine is RedHat 7.1 + glibc (and other bits) from 7.1.94 > > >gcc-2.96-85 > > > > Can you compile with compat-egcs and try again? > > Sometimes weird things happen with xfs and 2.96-?? > > I've seen this said before (most often by your good self :-) but I've > always built my 2.4.x-xfs kernels with it... including the one I'm running > now. No dice. kgcc caused the same problem. compat-egcs was already installed. Contrary to my previous statement, I think I built my 2.4.2,3 kernels with it, but all since (2.4.4,5,6-pre3,9) with 2.96. It was probably a bit after the point I went from RH 7.0.90 to RH7.1 after reading a discussion on the mailing list. However there is an inconsistency between the Makefile and the FAQ: the Makefile implies that the ordinary RH compiler works since 7.1. I have gcc3.0 installed too, but I think we'd be in clutching at straws land there. I've probably just cvs updated too quick before the tree was tested. #===== NOTE ===== # egcs-2.91.66 is the recommended compiler version for building XFS. # Most of the XFS developers are using that particular version for # development, testing, and performance analysis work, and it will # generate a functional XFS kernel (some versions of gcc will not) - # uncomment the following line to force that gcc version to be used: #CC = $(CROSS_COMPILE)gcc -V egcs-2.91.66 # On early versions of RedHat 7.x, kgcc is the recommended compiler # for building the kernel (kgcc is the same as egcs-2.91.66) - if # you use such a distribution and wish to use kgcc, uncomment this: CC = $(CROSS_COMPILE)kgcc # The default gcc with RedHat 7.1 (gcc-2.96-81) also appears to # generate good code, earlier versions of 2.96 are however an # unknown quantity and not recommended. nic From owner-linux-xfs@oss.sgi.com Wed Oct 10 05:41:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ACftY17701 for linux-xfs-outgoing; Wed, 10 Oct 2001 05:41:55 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ACfoD17679 for ; Wed, 10 Oct 2001 05:41:50 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id OAA17063; Wed, 10 Oct 2001 14:41:45 +0200 (CEST) Message-Id: <4.3.2.7.2.20011010142341.02d22170@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 10 Oct 2001 14:40:36 +0200 To: nic@uklinux.net, linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: 2.4.11 don't work yet. In-Reply-To: References: <4.3.2.7.2.20011010132408.02d1f3f0@pop.xs4all.nl> <4.3.2.7.2.20011010132408.02d1f3f0@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 13:02 10-10-2001 +0100, nic wrote: >On Wednesday 10 October 2001 12:24, Seth Mos wrote: > > > > >Software info: > > >Machine is RedHat 7.1 + glibc (and other bits) from 7.1.94 > > >gcc-2.96-85 > > > > Can you compile with compat-egcs and try again? > > Sometimes weird things happen with xfs and 2.96-?? > >I've seen this said before (most often by your good self :-) but I've always >built my 2.4.x-xfs kernels with it... including the one I'm running now. > >Will try and let you know, >nic It compiles most of the times but if you push the kernel hard enough some things budge. The mandrake kernel I am testing on is compiled with 2.96-85 and is working as one should expect. I have uploaded a new mandrake kernel to my website which has a working "make install". The kernel is fairly stable and includes the Gigabit drivers for the box. I am hitting it with mongo.pl with 50 processes on a 2GB dual 1.13Ghz box and it survives in a normal fashion. No hangs and no IO stalls. The benchmark time for "create" on a ext2 fs is down from 4200 secs to 2600 secs. This is the performance of Redhat-2.4.2 vs. Mandrake-2.4.8. Maybe someone is willing to convert the original mandrake source rpm for use on redhat/suse. If you are trying to convert the source rpm you will have to make sure that arch/i386/boot/install.sh is not altered. Mandrake added a -a argument for their installkernel program which confuses the redhat (and possibly SuSE) installkernel utility. Some XFS results are expected to follow soon. If people want a more up to date XFS kernel based on a -ac kernel this is probably a good choice. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Wed Oct 10 05:58:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ACw5718143 for linux-xfs-outgoing; Wed, 10 Oct 2001 05:58:05 -0700 Received: from mail.wearix.com (lorien.wearix.com [193.197.4.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ACvwD18118 for ; Wed, 10 Oct 2001 05:57:58 -0700 Received: from wearix.com (elwe.wearix.com [193.197.4.108]) by mail.wearix.com (Postfix on SuSE Linux 7.2 (i386)) with ESMTP id 979F23441DD4 for ; Wed, 10 Oct 2001 14:57:56 +0200 (CEST) Message-ID: <3BC445D3.AFD16366@wearix.com> Date: Wed, 10 Oct 2001 14:57:55 +0200 From: Lars Soltau Organization: Wearix GmbH X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: de,en-GB,en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfsrestore content listing Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms83CA4C819962072D1B17A377" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms83CA4C819962072D1B17A377 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit xfsrestore refuses to display the content of an archive if its current directory is not on an XFS filesystem. Is there a good reason for this? Amanda runs xfsrestore in /tmp/amanda, which of course is not XFS, when generating the list index. I can fix this by patching the Amanda code to run xfsrestore in a different directory, but I can't quite grasp the significance of the current directory's filesystem for an inventory listing. Greetings Lars Soltau --------------ms83CA4C819962072D1B17A377 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIH6QYJKoZIhvcNAQcCoIIH2jCCB9YCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BbwwggKLMIIB9KADAgECAgMFsvswDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMTA5MjExMTA2NDVaFw0wMjA5MjExMTA2NDVa MFUxDzANBgNVBAQTBlNvbHRhdTENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBTb2x0 YXUxHTAbBgkqhkiG9w0BCQEWDmxnc0B3ZWFyaXguY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQClx2kt4VyipqZjs4sMPH5CFocvvGTvtws/jSviiyV1I4OxCwC9rmGsALkd3GNm R0/MHMXV2DhUueDnb+QW0FbYkIMCBTc7bVdTCK/D6dqiXALz/TBXcN+xw39OpRh7B9O0gNNQ pUIQsWoD6HuoeTjx0WFVpol9hGASy7tTzwn5aQIDAQABoyswKTAZBgNVHREEEjAQgQ5sZ3NA d2Vhcml4LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBAgUAA4GBAJkynrVAbsHeqePR U4NmMlj41nbLEzp0OlB3SgnEJk0LV2akp1KDFbjN5GL8nFGinCR7nw5zOPqkMG9QgSsOFOwm imQnE2dA/uGywuueNG8hMaspiSItyfmfgaAJLiUj5GD/j87cO++gbQVE8/rtjkXRK89kAKj8 wmW1Fxvanxe7MIIDKTCCApKgAwIBAgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMC WkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQK ExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBE aXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZI hvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoX DTAyMDgyOTIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7j RCmKYzUqbXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagn rthy+boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEA AaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1Ud EwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8V NEtZYortRL5Jx+gNu4+5DWomKmKEH7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMB wgmn70uuct0GZ/VQby5YuLYLwVBXtewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5Ev qZa4BTxS/N3pYgNIMYIB9TCCAfECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMAIDBbL7MAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMDExMDEwMTI1NzU2WjAjBgkqhkiG9w0BCQQxFgQUEdTh ze+DeN3SNpDxnWDWxX3jbVgwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG 9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZI hvcNAQEBBQAEgYBus+CBYvwVrm+OYzgXvH71Cfl/0VghBch3GNyWxoQ2+ClYuHM5Km9j6YwA oyvAcvgN8dFEb4OuNv5aRW23qavJUWEVMiEckdmfwDMy3N824+B6EolsenPsJPYdrkQQUXIV MGb9gBaOYTHkBzmO8EcehoIE1eQKlIEmLbkN9ClHtw== --------------ms83CA4C819962072D1B17A377-- From owner-linux-xfs@oss.sgi.com Wed Oct 10 06:22:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ADMsl18864 for linux-xfs-outgoing; Wed, 10 Oct 2001 06:22:54 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ADKiD18806 for ; Wed, 10 Oct 2001 06:20:44 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id GAA08882 for ; Wed, 10 Oct 2001 06:17:31 -0700 (PDT) mail_from (ivanr@sgi.com) Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA05714; Wed, 10 Oct 2001 23:17:23 +1000 From: ivanr@sgi.com Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id XAA06636; Wed, 10 Oct 2001 23:17:22 +1000 (EST) X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs Date: Wed, 10 Oct 2001 23:17:22 +1000 X-X-Sender: ivanr@omen.melbourne.sgi.com To: Lars Soltau cc: linux-xfs@oss.sgi.com Subject: Re: xfsrestore content listing In-Reply-To: <3BC445D3.AFD16366@wearix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 10 Oct 2001, Lars Soltau wrote: > xfsrestore refuses to display the content of an archive if its current > directory is not on an XFS filesystem. > > Is there a good reason for this? Amanda runs xfsrestore in /tmp/amanda, > which of course is not XFS, when generating the list index. I can fix > this by patching the Amanda code to run xfsrestore in a different > directory, but I can't quite grasp the significance of the current > directory's filesystem for an inventory listing. This is a known problem that has existed in xfsrestore since day 1 on IRIX but has never really been a problem until its Linux version because most IRIX folk use xfs exclusively. Anyway, it's on our list of things to investigate and solve. Until then, you could, as you say, patch the Amanda code, mount an xfs filesystem on /tmp/amanda, or possibly write a simple wrapper script around xfsrestore to change directory for you. Or, if you're feeling adventurous, you could take a look at the xfsrestore code and let us know what you find... :) >From memory, there's a simple check to ensure that the cwd is xfs -- but the question is whether the check is simply wrong or if there is a real reason for it to be there. (I suspect the check could probably be removed, but I'm often wrong.) Ivan -- Ivan Rayner ivanr@sgi.com From owner-linux-xfs@oss.sgi.com Wed Oct 10 06:46:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ADkn019343 for linux-xfs-outgoing; Wed, 10 Oct 2001 06:46:49 -0700 Received: from e4.eyal.emu.id.au (CPE-61-9-149-34.vic.bigpond.net.au [61.9.149.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ADkjD19321 for ; Wed, 10 Oct 2001 06:46:45 -0700 Received: from eyal.emu.id.au (eyal.emu.id.au [192.168.2.7]) by e4.eyal.emu.id.au (8.11.6/8.11.2) with ESMTP id f9ADh7O13263; Wed, 10 Oct 2001 23:43:08 +1000 Received: from eyal.emu.id.au (really [127.0.0.1]) by eyal.emu.id.au via in.smtpd with esmtp id (Debian Smail3.2.0.102) for ; Wed, 10 Oct 2001 23:30:31 +1000 (EST) Message-ID: <3BC44D77.F499A15D@eyal.emu.id.au> Date: Wed, 10 Oct 2001 23:30:31 +1000 From: Eyal Lebedinsky Organization: Eyal at Home X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.10-ac10 i686) X-Accept-Language: en MIME-Version: 1.0 To: Keith Owens CC: linux-xfs list Subject: Re: TAKE - Remove generated scsi files References: <200110100259.MAA15009@sherman.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Keith Owens wrote: > > Some generated scsi files had crept into the XFS repository. > > Date: Tue Oct 9 19:56:33 PDT 2001 > 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:104250a > linux/drivers/scsi/53c8xx_u.h - 1.3 > linux/drivers/scsi/53c8xx_d.h - 1.5 > linux/drivers/scsi/sim710_d.h - 1.4 > linux/drivers/scsi/sim710_u.h - 1.2 You sure they "crept in"? I built 2.4.11 just fine but 2.4.11-xfs fails due to these files missing. The two .configs are identical apart from some new XFS items. -- Eyal Lebedinsky (eyal@eyal.emu.id.au) From owner-linux-xfs@oss.sgi.com Wed Oct 10 07:00:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9AE0XN19709 for linux-xfs-outgoing; Wed, 10 Oct 2001 07:00:33 -0700 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9AE0QD19687 for ; Wed, 10 Oct 2001 07:00:26 -0700 Received: (qmail 6089 invoked from network); 10 Oct 2001 14:00:22 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 10 Oct 2001 14:00:22 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 821B1300095; Thu, 11 Oct 2001 00:00:19 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 569BA98; Thu, 11 Oct 2001 00:00:19 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Eyal Lebedinsky Cc: linux-xfs list Subject: Re: TAKE - Remove generated scsi files In-reply-to: Your message of "Wed, 10 Oct 2001 23:30:31 +1000." <3BC44D77.F499A15D@eyal.emu.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 11 Oct 2001 00:00:13 +1000 Message-ID: <13546.1002722413@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 10 Oct 2001 23:30:31 +1000, Eyal Lebedinsky wrote: >Keith Owens wrote: >> >> Some generated scsi files had crept into the XFS repository. >> >> Date: Tue Oct 9 19:56:33 PDT 2001 >> 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:104250a >> linux/drivers/scsi/53c8xx_u.h - 1.3 >> linux/drivers/scsi/53c8xx_d.h - 1.5 >> linux/drivers/scsi/sim710_d.h - 1.4 >> linux/drivers/scsi/sim710_u.h - 1.2 > >You sure they "crept in"? I built 2.4.11 just fine but 2.4.11-xfs >fails due to these files missing. The two .configs are identical >apart from some new XFS items. All drivers/scsi/*_[ud].h files are generated. drivers/scsi/Makefile has rules to build 53c8xx_d.h 53c8xx_u.h 53c7xx_d.h 53c7xx_u.h sim710_d.h sim710_u.h 53c700_d.h How does 2.4.11-xfs fail to build? From owner-linux-xfs@oss.sgi.com Wed Oct 10 07:33:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9AEXlr20664 for linux-xfs-outgoing; Wed, 10 Oct 2001 07:33:47 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9AEXiD20642 for ; Wed, 10 Oct 2001 07:33:44 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9AEXdK00301 for ; Wed, 10 Oct 2001 07:33:39 -0700 Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA01292; Wed, 10 Oct 2001 07:33:06 -0700 (PDT) Message-ID: <3BC45B58.EEC0AA7E@sgi.com> Date: Wed, 10 Oct 2001 09:29:44 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: nic@uklinux.net CC: Seth Mos , linux-xfs@oss.sgi.com Subject: Compilers (was Re: 2.4.11 don't work yet.) References: <4.3.2.7.2.20011010132408.02d1f3f0@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Compilers are still a touchy subject... we just found one compiler bug last week w/ the RH 7.1 version of GCC, which caused filesystem corruption if you use xfs_growfs. gcc 3.0.1 from Mandrake did not exibit this problem... In short, "kgcc" is still the only compiler that we have a lot of confidence in - others may work most of the time, but I still don't have a "warm fuzzy" about any of them. -Eric nic wrote: > However there is an inconsistency between the Makefile and the FAQ: the > Makefile implies that the ordinary RH compiler works since 7.1. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Oct 10 07:42:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9AEg9r20885 for linux-xfs-outgoing; Wed, 10 Oct 2001 07:42:09 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9AEg5D20863 for ; Wed, 10 Oct 2001 07:42:05 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9AEg0K00895 for ; Wed, 10 Oct 2001 07:42:00 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA3188207; Wed, 10 Oct 2001 09:40:43 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA20119; Wed, 10 Oct 2001 09:40:43 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9AEdP407977; Wed, 10 Oct 2001 09:39:25 -0500 Message-Id: <200110101439.f9AEdP407977@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Robert Sander cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.11 and large files In-Reply-To: Message from Robert Sander of "Wed, 10 Oct 2001 12:23:44 -0000." Date: Wed, 10 Oct 2001 09:39:25 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hi! > > I do not think this problem is XFS related, but as I got the kernel > source from the XFS cvs, I just ask here: > > 2.4.11 compiles fine and runs, but when I try to create files that > are larger than 2GB, I get SIGXFSZ, file system limit exceeded. > ulimit -a shows unlimited, with 2.4.5 and XFS 1.0.1 it works. If you are using a non-xfs filesystem for I/O then unless your application opens the file without O_LARGEFILE it will get bounced out of the kernel this way when it attempts to cross the 2G boundary. This code is not in the xfs I/O path right now. Steve > > The problem is even stranger. When I do a dd if=/dev/sda of=/dev/sdb > on two identical disks, I got the same signal. This shouldn't happen > with block devices, should it? > > Anybody seen similar things? > > Greetings > -- > Robert Sander > Computer Scientist Epigenomics AG > Bioinformatics R&D www.epigenomics.com Kastanienallee 24 > +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Wed Oct 10 07:47:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9AElvf21133 for linux-xfs-outgoing; Wed, 10 Oct 2001 07:47:57 -0700 Received: from gk.hm.epigenomics.net (qmailr@gk.hm.epigenomics.net [212.121.137.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9AElsD21111 for ; Wed, 10 Oct 2001 07:47:54 -0700 Received: (qmail 2171 invoked from network); 10 Oct 2001 14:47:57 -0000 Received: from raman.epigenomics.epi (qmailr@192.168.2.2) by salam.epigenomics.epi with SMTP; 10 Oct 2001 14:47:57 -0000 Received: (qmail 9335 invoked from network); 10 Oct 2001 14:47:52 -0000 Received: from eigen.epigenomics.epi (qmailr@192.168.2.36) by raman.epigenomics.epi with SMTP; 10 Oct 2001 14:47:52 -0000 Received: (qmail 30968 invoked by uid 515); 10 Oct 2001 14:47:52 -0000 Date: Wed, 10 Oct 2001 16:47:52 +0200 From: Robert Sander To: linux-xfs@oss.sgi.com Subject: Re: 2.4.11 and large files Message-ID: <20011010164752.A30951@epigenomics.de> References: <200110101439.f9AEdP407977@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <200110101439.f9AEdP407977@jen.americas.sgi.com> User-Agent: Mutt/1.3.22i X-Operating-System: Linux eigen 2.2.19.client-piii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Oct 10, 2001 at 09:39:25AM -0500, Steve Lord wrote: > If you are using a non-xfs filesystem for I/O then unless your application > opens the file without O_LARGEFILE it will get bounced out of the kernel > this way when it attempts to cross the 2G boundary. This code is not > in the xfs I/O path right now. I see, but this must be new, because dd works on 2.4.5 and not on 2.4.11, hm. Why do these changes occur in a "stable" kernel. Greetings -- Robert Sander Computer Scientist Epigenomics AG Bioinformatics R&D www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Wed Oct 10 07:55:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9AEteW21430 for linux-xfs-outgoing; Wed, 10 Oct 2001 07:55:40 -0700 Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9AEtbD21408 for ; Wed, 10 Oct 2001 07:55:37 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9AEtlXe005660; Wed, 10 Oct 2001 16:55:47 +0200 (CEST) Message-Id: <4.3.2.7.2.20011010165349.03034040@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 10 Oct 2001 16:54:23 +0200 To: Robert Sander , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: 2.4.11 and large files In-Reply-To: <20011010164752.A30951@epigenomics.de> References: <200110101439.f9AEdP407977@jen.americas.sgi.com> <200110101439.f9AEdP407977@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 16:47 10-10-2001 +0200, Robert Sander wrote: >On Wed, Oct 10, 2001 at 09:39:25AM -0500, Steve Lord wrote: > > > If you are using a non-xfs filesystem for I/O then unless your application > > opens the file without O_LARGEFILE it will get bounced out of the kernel > > this way when it attempts to cross the 2G boundary. This code is not > > in the xfs I/O path right now. > >I see, but this must be new, because dd works on 2.4.5 and not on >2.4.11, hm. Why do these changes occur in a "stable" kernel. Because it is actually the start of the 2.5 series perhaps, and linus forgot to tell us :-) Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Wed Oct 10 08:00:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9AF0AO21746 for linux-xfs-outgoing; Wed, 10 Oct 2001 08:00:10 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9AF06D21724 for ; Wed, 10 Oct 2001 08:00:06 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA03577 for ; Wed, 10 Oct 2001 07:59:36 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA3275769; Wed, 10 Oct 2001 09:58:12 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA69543; Wed, 10 Oct 2001 09:58:12 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9AEusn08131; Wed, 10 Oct 2001 09:56:54 -0500 Message-Id: <200110101456.f9AEusn08131@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Robert Sander cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.11 and large files In-Reply-To: Message from Robert Sander of "Wed, 10 Oct 2001 16:47:52 +0200." <20011010164752.A30951@epigenomics.de> Date: Wed, 10 Oct 2001 09:56:54 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Wed, Oct 10, 2001 at 09:39:25AM -0500, Steve Lord wrote: > > > If you are using a non-xfs filesystem for I/O then unless your application > > opens the file without O_LARGEFILE it will get bounced out of the kernel > > this way when it attempts to cross the 2G boundary. This code is not > > in the xfs I/O path right now. > > I see, but this must be new, because dd works on 2.4.5 and not on > 2.4.11, hm. Why do these changes occur in a "stable" kernel. Well, stable does not appear to have its usual meaning in the 2.4 series, this code however, appeared in 2.4.4 back in April, so has been there for a while now. I am not sure what happened with dd though. Are you sure you are using the same user space - it may be that O_LARGEFILE has gone missing on you somehow. Steve > > Greetings > -- > Robert Sander > Computer Scientist Epigenomics AG > Bioinformatics R&D www.epigenomics.com Kastanienallee 24 > +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Wed Oct 10 08:25:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9AFPcp22505 for linux-xfs-outgoing; Wed, 10 Oct 2001 08:25:38 -0700 Received: from homer.mkintl.com (cloven-ext.nks.net [216.139.204.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9AFPXD22483 for ; Wed, 10 Oct 2001 08:25:33 -0700 Received: from illusionary.com (two.nks.net [192.168.1.22]) by homer.mkintl.com (8.9.3/8.9.3) with ESMTP id LAA08123 for ; Wed, 10 Oct 2001 11:25:27 -0400 Message-ID: <3BC46867.3895800C@illusionary.com> Date: Wed, 10 Oct 2001 11:25:27 -0400 From: Derek Glidden X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.10-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: 2.4.11 and large files References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Robert Sander wrote: > > Hi! > > I do not think this problem is XFS related, but as I got the kernel > source from the XFS cvs, I just ask here: > > 2.4.11 compiles fine and runs, but when I try to create files that > are larger than 2GB, I get SIGXFSZ, file system limit exceeded. > ulimit -a shows unlimited, with 2.4.5 and XFS 1.0.1 it works. > > The problem is even stranger. When I do a dd if=/dev/sda of=/dev/sdb > on two identical disks, I got the same signal. This shouldn't happen > with block devices, should it? > > Anybody seen similar things? Hi Robert, I compiled 2.4.10+XFS with "Quotas" turned on, and for some reason, it would no longer let me mkfs anything. (Not just XFS, but reiser and ext2 also did not work.) I always got "file limit reached" or something similar error message. I didn't try making any big files, though. But recompiling without "Quotas" enabled, let me successfully make filesystems again without receiving that error. Since I don't absolutely need quotas, I can make do, but I have had them on during the entire 2.4 series without ever seeing this problem until I built 2.4.10. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- #!/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/ http://www.sciencemag.org/cgi/content/full/293/5537/2028 From owner-linux-xfs@oss.sgi.com Wed Oct 10 09:22:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9AGMhE24064 for linux-xfs-outgoing; Wed, 10 Oct 2001 09:22:43 -0700 Received: from gk.hm.epigenomics.net (qmailr@gk.hm.epigenomics.net [212.121.137.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9AGMdD24042 for ; Wed, 10 Oct 2001 09:22:39 -0700 Received: (qmail 2853 invoked from network); 10 Oct 2001 16:22:40 -0000 Received: from raman.epigenomics.epi (qmailr@192.168.2.2) by salam.epigenomics.epi with SMTP; 10 Oct 2001 16:22:40 -0000 Received: (qmail 15880 invoked from network); 10 Oct 2001 16:22:37 -0000 Received: from eigen.epigenomics.epi (qmailr@192.168.2.36) by raman.epigenomics.epi with SMTP; 10 Oct 2001 16:22:37 -0000 Received: (qmail 31898 invoked by uid 515); 10 Oct 2001 16:22:37 -0000 Date: Wed, 10 Oct 2001 18:22:37 +0200 From: Robert Sander To: linux-xfs@oss.sgi.com Subject: Re: 2.4.11 and large files Message-ID: <20011010182237.A31879@epigenomics.de> References: <20011010164752.A30951@epigenomics.de> <200110101456.f9AEusn08131@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <200110101456.f9AEusn08131@jen.americas.sgi.com> User-Agent: Mutt/1.3.22i X-Operating-System: Linux eigen 2.2.19.client-piii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Oct 10, 2001 at 09:56:54AM -0500, Steve Lord wrote: > > Well, stable does not appear to have its usual meaning in the 2.4 series, > this code however, appeared in 2.4.4 back in April, so has been there for > a while now. I am not sure what happened with dd though. Are you sure you > are using the same user space - it may be that O_LARGEFILE has gone > missing on you somehow. It failed on 2.4.11, I rebootet to the still installed 2.4.5, so it must be the very same "dd" we are talking about. ;-) Greetings -- Robert Sander Computer Scientist Epigenomics AG Bioinformatics R&D www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Wed Oct 10 09:27:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9AGRRM24246 for linux-xfs-outgoing; Wed, 10 Oct 2001 09:27:27 -0700 Received: from gk.hm.epigenomics.net (qmailr@gk.hm.epigenomics.net [212.121.137.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9AGRND24223 for ; Wed, 10 Oct 2001 09:27:24 -0700 Received: (qmail 2881 invoked from network); 10 Oct 2001 16:27:25 -0000 Received: from raman.epigenomics.epi (qmailr@192.168.2.2) by salam.epigenomics.epi with SMTP; 10 Oct 2001 16:27:25 -0000 Received: (qmail 17885 invoked from network); 10 Oct 2001 16:27:21 -0000 Received: from broglie.epigenomics.epi (qmailr@192.168.1.5) by raman.epigenomics.epi with SMTP; 10 Oct 2001 16:27:21 -0000 Received: (qmail 15669 invoked by uid 9); 10 Oct 2001 16:27:21 -0000 From: Robert Sander Reply-To: Robert Sander X-Newsgroups: epi.ml.linux.xfs Subject: Re: 2.4.11 and large files Date: Wed, 10 Oct 2001 16:27:20 +0000 (UTC) Organization: Epigenomics AG Lines: 21 Message-ID: References: <3BC46867.3895800C@illusionary.com> X-Complaints-To: usenet@epigenomics.com User-Agent: slrn/0.9.7.2 (Linux) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 10 Oct 2001 15:26:24 +0000 (UTC), Derek Glidden wrote: > I compiled 2.4.10+XFS with "Quotas" turned on, and for some reason, it > would no longer let me mkfs anything. (Not just XFS, but reiser and > ext2 also did not work.) I always got "file limit reached" or something > similar error message. I didn't try making any big files, though. But > recompiling without "Quotas" enabled, let me successfully make > filesystems again without receiving that error. I see, and you sure get the error when mkfs reaches 2GB on the device when making the filesystem. And turning off quota solves that? Impressive. I do not need quota on that specific box, but having quota is an option I need to have. Greetings -- Robert Sander Computer Scientist Epigenomics AG Bioinformatics R&D www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Wed Oct 10 09:30:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9AGUBM24422 for linux-xfs-outgoing; Wed, 10 Oct 2001 09:30:11 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9AGU7D24399 for ; Wed, 10 Oct 2001 09:30:07 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA04241 for ; Wed, 10 Oct 2001 09:29:08 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA3275198; Wed, 10 Oct 2001 11:28:43 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA70815; Wed, 10 Oct 2001 11:28:42 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9AGROu13268; Wed, 10 Oct 2001 11:27:24 -0500 Message-Id: <200110101627.f9AGROu13268@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Robert Sander cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.11 and large files In-Reply-To: Message from Robert Sander of "Wed, 10 Oct 2001 18:22:37 +0200." <20011010182237.A31879@epigenomics.de> Date: Wed, 10 Oct 2001 11:27:24 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Wed, Oct 10, 2001 at 09:56:54AM -0500, Steve Lord wrote: > > > > Well, stable does not appear to have its usual meaning in the 2.4 series, > > this code however, appeared in 2.4.4 back in April, so has been there for > > a while now. I am not sure what happened with dd though. Are you sure you > > are using the same user space - it may be that O_LARGEFILE has gone > > missing on you somehow. > > It failed on 2.4.11, I rebootet to the still installed 2.4.5, so > it must be the very same "dd" we are talking about. ;-) OK, go back a step here - on XFS or other filesystem types? I am in the process of cleaning up the XFS write path here, doing this: [root@lord /xfs]# dd of=big if=/dev/zero seek=8192 bs=1024k count=8 8+0 records in 8+0 records out [root@lord /xfs]# ls -l big -rw-r--r-- 1 root root 8598323200 Oct 10 10:26 big Works for me. > > Greetings > -- > Robert Sander > Computer Scientist Epigenomics AG > Bioinformatics R&D www.epigenomics.com Kastanienallee 24 > +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Wed Oct 10 09:34:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9AGY9d24588 for linux-xfs-outgoing; Wed, 10 Oct 2001 09:34:09 -0700 Received: from gk.hm.epigenomics.net (qmailr@gk.hm.epigenomics.net [212.121.137.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9AGY5D24566 for ; Wed, 10 Oct 2001 09:34:06 -0700 Received: (qmail 2932 invoked from network); 10 Oct 2001 16:34:08 -0000 Received: from raman.epigenomics.epi (qmailr@192.168.2.2) by salam.epigenomics.epi with SMTP; 10 Oct 2001 16:34:08 -0000 Received: (qmail 19495 invoked from network); 10 Oct 2001 16:34:04 -0000 Received: from broglie.epigenomics.epi (qmailr@192.168.1.5) by raman.epigenomics.epi with SMTP; 10 Oct 2001 16:34:04 -0000 Received: (qmail 15995 invoked by uid 9); 10 Oct 2001 16:34:03 -0000 From: Robert Sander Reply-To: Robert Sander X-Newsgroups: epi.ml.linux.xfs Subject: Re: 2.4.11 and large files Date: Wed, 10 Oct 2001 16:34:03 +0000 (UTC) Organization: Epigenomics AG Lines: 22 Message-ID: References: <200110101627.f9AGROu13268@jen.americas.sgi.com> X-Complaints-To: usenet@epigenomics.com User-Agent: slrn/0.9.7.2 (Linux) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 10 Oct 2001 16:31:01 +0000 (UTC), Steve Lord wrote: >> It failed on 2.4.11, I rebootet to the still installed 2.4.5, so >> it must be the very same "dd" we are talking about. ;-) > > OK, go back a step here - on XFS or other filesystem types? dd fails when doing a simple dd if=/dev/sda of=/dev/sdb sda and sdb being identical harddisks. There are no filesystems involved. There must be a check in the kernel when accessing anything above 2GB, even block devices, which sounds a bit stupid to me. I think it is the same problem the other poster has, he solved it by switching off quota support. Greetings -- Robert Sander Computer Scientist Epigenomics AG Bioinformatics R&D www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Wed Oct 10 10:07:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9AH7VN25324 for linux-xfs-outgoing; Wed, 10 Oct 2001 10:07:31 -0700 Received: from homer.mkintl.com (cloven-ext.nks.net [216.139.204.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9AH7PD25301 for ; Wed, 10 Oct 2001 10:07:25 -0700 Received: from illusionary.com (two.nks.net [192.168.1.22]) by homer.mkintl.com (8.9.3/8.9.3) with ESMTP id NAA08663 for ; Wed, 10 Oct 2001 13:07:19 -0400 Message-ID: <3BC48047.5959D636@illusionary.com> Date: Wed, 10 Oct 2001 13:07:19 -0400 From: Derek Glidden X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.10-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: 2.4.11 and large files References: <3BC46867.3895800C@illusionary.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Robert Sander wrote: > > On Wed, 10 Oct 2001 15:26:24 +0000 (UTC), > Derek Glidden wrote: > > I compiled 2.4.10+XFS with "Quotas" turned on, and for some reason, it > > would no longer let me mkfs anything. (Not just XFS, but reiser and > > ext2 also did not work.) I always got "file limit reached" or something > > similar error message. I didn't try making any big files, though. But > > recompiling without "Quotas" enabled, let me successfully make > > filesystems again without receiving that error. > > I see, and you sure get the error when mkfs reaches 2GB on the > device when making the filesystem. And turning off quota solves > that? Impressive. > I do not need quota on that specific box, but having quota is > an option I need to have. No, actually, it had nothing to do with any 2GB limit. Even doing mkfs on a small test partition resulted in some sort of "file size limit" error. (I don't remember the exact error message now.) It looked to me like quotas were broken, but since I don't absolutely need them, I just assumed it was more 2.4 breakage and ignored it. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- #!/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/ http://www.sciencemag.org/cgi/content/full/293/5537/2028 From owner-linux-xfs@oss.sgi.com Wed Oct 10 10:34:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9AHYQJ26057 for linux-xfs-outgoing; Wed, 10 Oct 2001 10:34:26 -0700 Received: from gk.hm.epigenomics.net (qmailr@gk.hm.epigenomics.net [212.121.137.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9AHYMD26034 for ; Wed, 10 Oct 2001 10:34:22 -0700 Received: (qmail 3179 invoked from network); 10 Oct 2001 17:34:24 -0000 Received: from raman.epigenomics.epi (qmailr@192.168.2.2) by salam.epigenomics.epi with SMTP; 10 Oct 2001 17:34:24 -0000 Received: (qmail 11451 invoked from network); 10 Oct 2001 17:34:20 -0000 Received: from broglie.epigenomics.epi (qmailr@192.168.1.5) by raman.epigenomics.epi with SMTP; 10 Oct 2001 17:34:20 -0000 Received: (qmail 17573 invoked by uid 9); 10 Oct 2001 17:34:19 -0000 From: Robert Sander Reply-To: Robert Sander X-Newsgroups: epi.ml.linux.xfs Subject: Re: 2.4.11 and large files Date: Wed, 10 Oct 2001 17:34:19 +0000 (UTC) Organization: Epigenomics AG Lines: 17 Message-ID: References: <3BC46867.3895800C@illusionary.com> <3BC48047.5959D636@illusionary.com> X-Complaints-To: usenet@epigenomics.com User-Agent: slrn/0.9.7.2 (Linux) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 10 Oct 2001 17:08:28 +0000 (UTC), Derek Glidden wrote: > No, actually, it had nothing to do with any 2GB limit. Even doing mkfs > on a small test partition resulted in some sort of "file size limit" > error. (I don't remember the exact error message now.) It looked to me > like quotas were broken, but since I don't absolutely need them, I just > assumed it was more 2.4 breakage and ignored it. I just booted another 2.4.11 kernel the same as before just without quota support, and it works now. Starnge correlation, don't you think? Greetings -- Robert Sander Computer Scientist Epigenomics AG Bioinformatics R&D www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Wed Oct 10 11:02:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9AI2Yb26750 for linux-xfs-outgoing; Wed, 10 Oct 2001 11:02:34 -0700 Received: from groucho.maths.monash.edu.au (groucho.maths.monash.edu.au [130.194.160.211]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9AI2SD26728 for ; Wed, 10 Oct 2001 11:02:29 -0700 Received: (from rjh@localhost) by groucho.maths.monash.edu.au (8.8.8/8.8.8) id SAA13620 for linux-xfs@oss.sgi.com; Wed, 10 Oct 2001 18:02:26 GMT From: Robin Humble Message-Id: <200110101802.SAA13620@groucho.maths.monash.edu.au> Subject: 2.4.11 rocks? (and xfs / confusion) To: linux-xfs@oss.sgi.com Date: Thu, 11 Oct 2001 04:02:26 +1000 (EST) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Erm, just to add in some non-negative feedback for 2.4.11 - it works fine for me, and my toy memory thrasher benchmark(*) runs in less than half the time that 2.4.9 takes. xmms was also totaly happy whilst the system was swapping madly, although to be fair 2.4.9 was pretty good for this too... Go Linus?? :) On an XFS note (unrelated to 2.4.10 or 11) - both my laptop and desktop systems (2.4.9, 2.4.11) ALWAYS say on bootup that recovery is required on the root filesystem - even though it's been shut down cleanly. My laptop's been doing this for months and I think the desktop box started doing it in the last week or so (running 2.4.7). There's nothing unusual about the boot or shutdowns (everything seems clean) except this one thing :-/ RedHat7.1 with kgcc. I have cvs xfsprogs also. from dmesg on every boot: ... XFS mounting filesystem ide0(3,1) XFS: WARNING: recovery required on readonly filesystem. XFS: write access will be enabled during mount. Starting XFS recovery on filesystem: ide0(3,1) (dev: 3/1) Ending XFS recovery on filesystem: ide0(3,1) (dev: 3/1) VFS: Mounted root (xfs filesystem) readonly. ... I could probably xfs_repair (or just mount) the desktop disk with a rescue CD to fix it, but the laptop hasn't enough memory to run the rescue CD and I'd have to pull the @#$@#$@ disk out and move it to another machine to sort it out - big hassle. Any ideas? Maybe it's corruption left over from an earlier kernel version that's never being fixed? A friend of mine found it also and thought it might be 'cos we upgraded from earlier RH/XFS versions rather then re-installing. cheers, robin (*) allocates memory (eg. 400M when I have 384M of ram) and touches many of the pages whilst allocating, and then touches random pages 10k times once the full 400M is reached. It's designed to simulate an app that has bad data locality. From owner-linux-xfs@oss.sgi.com Wed Oct 10 11:21:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9AILNS27333 for linux-xfs-outgoing; Wed, 10 Oct 2001 11:21:23 -0700 Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9AILJD27310 for ; Wed, 10 Oct 2001 11:21:19 -0700 Received: from aegis.cs.princeton.edu (HELO magnolia) (128.112.152.6) by smtp.mail.vip.sc5.yahoo.com with SMTP; 10 Oct 2001 18:21:14 -0000 X-Apparently-From: Reply-To: From: "Zhifeng F. Chen" To: Subject: iostat doesn't report disk IO. Date: Wed, 10 Oct 2001 14:21:03 -0400 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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I don't know if I should ask you about this. I am using kernel 2.4.9 patched by xfs, /proc/partition shows: major minor #blocks name 33 0 60030432 hde 33 1 56196 hde1 33 2 30724312 hde2 33 3 1 hde3 33 5 1028128 hde5 33 6 28218141 hde6 34 0 60030432 hdg 34 1 4096543 hdg1 34 2 55930297 hdg2 I'm using sysstat-4.0.2-1. However, iostat only report: Linux 2.4.9-xfs (cluster-066) 10/10/2001 avg-cpu: %user %nice %sys %idle 0.04 0.00 0.08 99.88 Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn Does anyone meet this? Do you know any fix of it? ~~~~~~~~~~~~~~~~~~~~~~~~~ Zhifeng F. Chen _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-linux-xfs@oss.sgi.com Wed Oct 10 11:31:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9AIV5Q27597 for linux-xfs-outgoing; Wed, 10 Oct 2001 11:31:05 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9AIUwD27575 for ; Wed, 10 Oct 2001 11:30:58 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9AIUqW19426 for ; Wed, 10 Oct 2001 11:30:53 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA3276985; Wed, 10 Oct 2001 13:29:36 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA91766; Wed, 10 Oct 2001 13:29:36 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9AISH113517; Wed, 10 Oct 2001 13:28:17 -0500 Message-Id: <200110101828.f9AISH113517@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: mlrecv@yahoo.com cc: linux-xfs@oss.sgi.com Subject: Re: iostat doesn't report disk IO. In-Reply-To: Message from "Zhifeng F. Chen" of "Wed, 10 Oct 2001 14:21:03 EDT." Date: Wed, 10 Oct 2001 13:28:17 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hi, > I don't know if I should ask you about this. > I am using kernel 2.4.9 patched by xfs, /proc/partition shows: > > major minor #blocks name > > 33 0 60030432 hde > 33 1 56196 hde1 > 33 2 30724312 hde2 > 33 3 1 hde3 > 33 5 1028128 hde5 > 33 6 28218141 hde6 > 34 0 60030432 hdg > 34 1 4096543 hdg1 > 34 2 55930297 hdg2 > > I'm using sysstat-4.0.2-1. However, iostat only report: > > Linux 2.4.9-xfs (cluster-066) 10/10/2001 > > avg-cpu: %user %nice %sys %idle > 0.04 0.00 0.08 99.88 > > Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn > > Does anyone meet this? Do you know any fix of it? > > ~~~~~~~~~~~~~~~~~~~~~~~~~ > Zhifeng F. Chen > I am using an older iostat and a newer kernel and it works for me: rpm -qf /usr/bin/iostat sysstat-3.3.5-3 lord{lord}: iostat Linux 2.4.11-xfs (lord) 10/10/2001 avg-cpu: %user %nice %sys %idle 0.77 0.00 2.17 97.06 Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn dev3-0 6.89 13.08 21.28 4157 6765 dev8-0 14.44 219.98 25.40 69928 8073 iostat uses /proc/stat to get its info, here is what mine looks like: cpu 494 0 1413 97263 cpu0 300 0 528 48757 cpu1 194 0 885 48506 page 27531 1612 swap 2 0 intr 58066 49585 6 0 2 194 0 0 0 1 0 0 0 7 0 2192 0 4711 0 0 1368 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 disk_io: (3,0):(2192,320,4157,1872,6781) (8,0):(4630,3118,70176,1512,8635) ctxt 29325 btime 1002734286 processes 1040 I would check out your /proc/stat, and look at the iostat source, it may be having trouble interpreting the output. Steve p.s. nothing in this part of the system is changed by XFS > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com From owner-linux-xfs@oss.sgi.com Wed Oct 10 12:10:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9AJAoN28536 for linux-xfs-outgoing; Wed, 10 Oct 2001 12:10:50 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9AJAlD28514 for ; Wed, 10 Oct 2001 12:10:47 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9AJAfK17380 for ; Wed, 10 Oct 2001 12:10:41 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA3254009 for ; Wed, 10 Oct 2001 14:09:26 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA58580 for ; Wed, 10 Oct 2001 14:09:26 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id f9AJ86W13635; Wed, 10 Oct 2001 14:08:06 -0500 Message-Id: <200110101908.f9AJ86W13635@jen.americas.sgi.com> Date: Wed, 10 Oct 2001 14:08:06 -0500 Subject: TAKE - Bring the XFS write path back into line with the generic case Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Really just code cleanup. Date: Wed Oct 10 12:07:39 PDT 2001 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:104298a linux/fs/xfs/linux/xfs_lrw.c - 1.113 - Deal with ioflags in a cleaner manner linux/fs/xfs/linux/xfs_file.c - 1.48 - Replicate file offset checks from generic_file_write into the xfs path. Deal with ioflags in a cleaner manner. linux/fs/pagebuf/page_buf_io.c - 1.100 - Remove file offset checking - moved higher up the call chain From owner-linux-xfs@oss.sgi.com Wed Oct 10 12:20:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9AJKYh28931 for linux-xfs-outgoing; Wed, 10 Oct 2001 12:20:34 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9AJKTD28908 for ; Wed, 10 Oct 2001 12:20:29 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA05436 for ; Wed, 10 Oct 2001 12:19:52 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA3197263; Wed, 10 Oct 2001 14:18:34 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA07612; Wed, 10 Oct 2001 14:18:34 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9AJHEc13664; Wed, 10 Oct 2001 14:17:14 -0500 Message-Id: <200110101917.f9AJHEc13664@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Robin Humble cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.11 rocks? (and xfs / confusion) In-Reply-To: Message from Robin Humble of "Thu, 11 Oct 2001 04:02:26 +1000." <200110101802.SAA13620@groucho.maths.monash.edu.au> Date: Wed, 10 Oct 2001 14:17:14 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > On an XFS note (unrelated to 2.4.10 or 11) - both my laptop and > desktop systems (2.4.9, 2.4.11) ALWAYS say on bootup that recovery is > required on the root filesystem - even though it's been shut down > cleanly. My laptop's been doing this for months and I think the > desktop box started doing it in the last week or so (running 2.4.7). > There's nothing unusual about the boot or shutdowns (everything seems > clean) except this one thing :-/ > RedHat7.1 with kgcc. I have cvs xfsprogs also. This line in the /etc/init.d/halt script could be the culprit: #echo $"Remounting remaining filesystems (if any) readonly" mount | awk '/ext2/ { print $3 }' | while read line; do mount -n -o ro,remount $line done It is not xfs friendly. Steve > > from dmesg on every boot: > ... > XFS mounting filesystem ide0(3,1) > XFS: WARNING: recovery required on readonly filesystem. > XFS: write access will be enabled during mount. > Starting XFS recovery on filesystem: ide0(3,1) (dev: 3/1) > Ending XFS recovery on filesystem: ide0(3,1) (dev: 3/1) > VFS: Mounted root (xfs filesystem) readonly. > ... > > I could probably xfs_repair (or just mount) the desktop disk with > a rescue CD to fix it, but the laptop hasn't enough memory to run the > rescue CD and I'd have to pull the @#$@#$@ disk out and move it to > another machine to sort it out - big hassle. > > Any ideas? > Maybe it's corruption left over from an earlier kernel version that's > never being fixed? > A friend of mine found it also and thought it might be 'cos we upgraded > from earlier RH/XFS versions rather then re-installing. > > cheers, > robin > > (*) allocates memory (eg. 400M when I have 384M of ram) and touches > many of the pages whilst allocating, and then touches random pages > 10k times once the full 400M is reached. It's designed to simulate an > app that has bad data locality. From owner-linux-xfs@oss.sgi.com Wed Oct 10 12:50:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9AJo2U29533 for linux-xfs-outgoing; Wed, 10 Oct 2001 12:50:02 -0700 Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9AJnvD29506 for ; Wed, 10 Oct 2001 12:49:57 -0700 Received: from there ([62.248.176.219]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20011010194955.BREM18920.fep01-app.kolumbus.fi@there>; Wed, 10 Oct 2001 22:49:55 +0300 Content-Type: text/plain; charset="iso-8859-1" From: Hristo Grigorov To: Steve Lord , Robin Humble Subject: Re: 2.4.11 rocks? (and xfs / confusion) Date: Wed, 10 Oct 2001 22:49:58 +0300 X-Mailer: KMail [version 1.3.1] Cc: linux-xfs@oss.sgi.com References: <200110101917.f9AJHEc13664@jen.americas.sgi.com> In-Reply-To: <200110101917.f9AJHEc13664@jen.americas.sgi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011010194955.BREM18920.fep01-app.kolumbus.fi@there> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wednesday 10 October 2001 22:17, Steve Lord wrote: > > On an XFS note (unrelated to 2.4.10 or 11) - both my laptop and > > desktop systems (2.4.9, 2.4.11) ALWAYS say on bootup that recovery is > > required on the root filesystem - even though it's been shut down > > cleanly. My laptop's been doing this for months and I think the > > desktop box started doing it in the last week or so (running 2.4.7). > > There's nothing unusual about the boot or shutdowns (everything seems > > clean) except this one thing :-/ > > RedHat7.1 with kgcc. I have cvs xfsprogs also. > > This line in the /etc/init.d/halt script could be the culprit: > > #echo $"Remounting remaining filesystems (if any) readonly" > mount | awk '/ext2/ { print $3 }' | while read line; do > mount -n -o ro,remount $line > done > > It is not xfs friendly. > > Steve > It seems they fixed it in rawhide. Now it is: #echo $"Remounting remaining filesystems (if any) readonly" mount | awk '/( \/ |^\/dev\/root)/ { print $3 }' | while read line; do mount -n -o ro,remount $line done which looks better. And I run linux-2.4.11 w/o any problems. FYI: Compiled with gcc 3.0.2 on a RedHat 7.1 system (plus the latest rawhide upgrades). Hristo. From owner-linux-xfs@oss.sgi.com Wed Oct 10 13:25:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9AKPOg30289 for linux-xfs-outgoing; Wed, 10 Oct 2001 13:25:24 -0700 Received: from mx0.break.net (root@mx0.break.net [194.134.79.76]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9AKPLD30266 for ; Wed, 10 Oct 2001 13:25:21 -0700 Received: from hurricane.euronet.nl (node0844.a2000.nl [62.108.8.68]) by mx0.break.net (8.11.4/8.11.4) with ESMTP id f9AKRDu07107 for ; Wed, 10 Oct 2001 22:27:14 +0200 X-NCC-RegID: nl.euronet Message-Id: <5.1.0.14.2.20011010222046.0253bd78@pop.euronet.nl> X-Sender: sengaia@pop.euronet.nl X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 10 Oct 2001 22:24:35 +0200 To: linux-xfs@oss.sgi.com From: Arjen Wolfs Subject: stable release? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm seeing a lot of discussion about the 2.4.10 and 2.4.11, and I am wondering when the next "stable" linux-xfs release will be. So far the 2.4 series of kernels (with or without xfs) has mostly been a "try random kernels and kernel configurations until you find one that works for you"-approach, which is making life very difficult. It would be really good(TM) to have a tested 2.4.10-based (or later) official xfs release...is any such thing forthcoming? Cheers, Arjen Wolfs From owner-linux-xfs@oss.sgi.com Wed Oct 10 13:39:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9AKdrj30639 for linux-xfs-outgoing; Wed, 10 Oct 2001 13:39:53 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9AKdnD30617 for ; Wed, 10 Oct 2001 13:39:49 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA05566 for ; Wed, 10 Oct 2001 13:38:40 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA3250904; Wed, 10 Oct 2001 15:38:32 -0500 (CDT) Received: from sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id PAA18286; Wed, 10 Oct 2001 15:38:31 -0500 (CDT) Message-ID: <3BC4B1B3.10692C65@sgi.com> Date: Wed, 10 Oct 2001 15:38:11 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.8-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Arjen Wolfs CC: linux-xfs@oss.sgi.com Subject: Re: stable release? References: <5.1.0.14.2.20011010222046.0253bd78@pop.euronet.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Arjen - Yes, there will be another "stable" release of XFS for Linux, but when/what it will be is the question. With test resources here spread between projects, and the wild gyrations of the underlying kernel, it's hard to predict that particular bit of the future. :) Mandrake recently released their 8.1 system, with an xfs-capable 2.4.8 kernel that underwent heavy testing. So that might not be a bad place to start if you want a recent, tested, xfs-capable kernel. -Eric Arjen Wolfs wrote: > > I'm seeing a lot of discussion about the 2.4.10 and 2.4.11, and I am > wondering when the next "stable" linux-xfs release will be. So far the 2.4 > series of kernels (with or without xfs) has mostly been a "try random > kernels and kernel configurations until you find one that works for > you"-approach, which is making life very difficult. It would be really > good(TM) to have a tested 2.4.10-based (or later) official xfs release...is > any such thing forthcoming? > > Cheers, > Arjen Wolfs -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Oct 10 13:49:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9AKnX530906 for linux-xfs-outgoing; Wed, 10 Oct 2001 13:49:33 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9AKnTD30883 for ; Wed, 10 Oct 2001 13:49:29 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA03176 for ; Wed, 10 Oct 2001 13:49:26 -0700 (PDT) mail_from (eric@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA3266603 for ; Wed, 10 Oct 2001 15:48:13 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA69294 for ; Wed, 10 Oct 2001 15:48:12 -0500 (CDT) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id f9AKlqE00907; Wed, 10 Oct 2001 15:47:52 -0500 Message-Id: <200110102047.f9AKlqE00907@stout.americas.sgi.com> Date: Wed, 10 Oct 2001 15:47:52 -0500 From: Eric Sandeen Subject: TAKE - work around gcc bug during xfs_growfs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk xfs_growfs was creating corrupted filesystems on kernels compiled with certain compilers. A macro was passed to the function, but the function did not receive the correct value, i.e.: function(MACRO(foo)); had a different result than bar = MACRO(foo); function(bar); The latter case yielded correct results. This bug resulted in AGF headers being placed into the wrong filesystem blocks. This was exibited on the 2.9x compilers in RH 7.1 and Mandrake 8.1. "kgcc" and Mandrake's 3.0.1 compiler did not exhibit this problem. Just another reminder that when we suggest the use of particular compilers, it's for a good reason! :) Date: Wed Oct 10 13:42:43 PDT 2001 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:104314a linux/fs/xfs/xfs_fsops.c - 1.70 - Work around gcc compiler bug From owner-linux-xfs@oss.sgi.com Wed Oct 10 13:50:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9AKoIi30983 for linux-xfs-outgoing; Wed, 10 Oct 2001 13:50:18 -0700 Received: from mx0.break.net (root@mx0.break.net [194.134.79.76]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9AKoFD30961 for ; Wed, 10 Oct 2001 13:50:15 -0700 Received: from hurricane.euronet.nl (node0844.a2000.nl [62.108.8.68]) by mx0.break.net (8.11.4/8.11.4) with ESMTP id f9AKpCu07255; Wed, 10 Oct 2001 22:51:12 +0200 X-NCC-RegID: nl.euronet Message-Id: <5.1.0.14.2.20011010224317.024062a0@pop.euronet.nl> X-Sender: sengaia@pop.euronet.nl X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 10 Oct 2001 22:48:33 +0200 To: Eric Sandeen From: Arjen Wolfs Subject: Re: stable release? Cc: linux-xfs@oss.sgi.com In-Reply-To: <3BC4B1B3.10692C65@sgi.com> References: <5.1.0.14.2.20011010222046.0253bd78@pop.euronet.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 22:38 10-10-2001, you wrote: >Hi Arjen - > >Yes, there will be another "stable" release of XFS for Linux, but when/what it >will be is the question. With test resources here spread between >projects, and >the wild gyrations of the underlying kernel, it's hard to predict that >particular bit of the future. :) > >Mandrake recently released their 8.1 system, with an xfs-capable 2.4.8 kernel >that underwent heavy testing. So that might not be a bad place to start >if you >want a recent, tested, xfs-capable kernel. Right now I'm using 2.4.6 with the linux-2.4.6-xfs-07052001.patch which is stable but has very poor VM performance (especially when writing), I will just hold out until something "stable" with the post-2.4.10 VM improvements appears. I've had too much trouble with the 2.4 series already to be trying more "random" kernels unless I know that if I get it to work there will be a noticable improvement... Don't let Linux's VM-of-the-day get you down, keep up the good work :) /Arjen From owner-linux-xfs@oss.sgi.com Wed Oct 10 13:54:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9AKsJY31235 for linux-xfs-outgoing; Wed, 10 Oct 2001 13:54:19 -0700 Received: from smtp3.xs4all.nl (smtp3.xs4all.nl [194.109.127.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9AKsFD31213 for ; Wed, 10 Oct 2001 13:54:15 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtp3.xs4all.nl (8.9.3/8.9.3) with ESMTP id WAA05617; Wed, 10 Oct 2001 22:54:12 +0200 (CEST) Message-Id: <4.3.2.7.2.20011010224102.0301c638@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 10 Oct 2001 22:53:06 +0200 To: Arjen Wolfs , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: stable release? In-Reply-To: <5.1.0.14.2.20011010222046.0253bd78@pop.euronet.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 22:24 10-10-2001 +0200, Arjen Wolfs wrote: >I'm seeing a lot of discussion about the 2.4.10 and 2.4.11, and I am >wondering when the next "stable" linux-xfs release will be. So far the 2.4 >series of kernels (with or without xfs) has mostly been a "try random >kernels and kernel configurations until you find one that works for >you"-approach, which is making life very difficult. It would be really >good(TM) to have a tested 2.4.10-based (or later) official xfs >release...is any such thing forthcoming? No 2.4.10+ work reported yet. You might try rawhide (redhat) or cooker (mandrake) for something although they will probably be based on a -ac version. I think there is a certain person to blame :-) If 2.4.8-ac is good enough for you, try the mandrake kernel from 8.1 which seems to work well for me at work on highmem smp boxes. It also holds up well against some higher load I threw at it. In general the 2.4 -ac kernels that alan produces fare better then the 2.4 -linus kernels. Even when Alan is merging alot he still manages to retain a lot of stability. This is the exact reason why he is skipping the 2.4.10 VM change and is still holding onto the VM that Rik van Riel wrote. He is slowly inserting some speedups Rik sent in the -ac VM which a lot of people are also noticing. Both RedHat and Mandrake use -ac for their distributions. I don't know about SuSE. Maybe a SuSE user can comment on that. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Wed Oct 10 14:07:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9AL7I431617 for linux-xfs-outgoing; Wed, 10 Oct 2001 14:07:18 -0700 Received: from mx0.break.net (root@mx0.break.net [194.134.79.76]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9AL7DD31595 for ; Wed, 10 Oct 2001 14:07:13 -0700 Received: from hurricane.euronet.nl (node0844.a2000.nl [62.108.8.68]) by mx0.break.net (8.11.4/8.11.4) with ESMTP id f9AL96u07341; Wed, 10 Oct 2001 23:09:06 +0200 X-NCC-RegID: nl.euronet Message-Id: <5.1.0.14.2.20011010230201.00aca3f8@pop.euronet.nl> X-Sender: sengaia@pop.euronet.nl X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 10 Oct 2001 23:06:27 +0200 To: Seth Mos From: Arjen Wolfs Subject: Re: stable release? Cc: linux-xfs@oss.sgi.com In-Reply-To: <4.3.2.7.2.20011010224102.0301c638@pop.xs4all.nl> References: <5.1.0.14.2.20011010222046.0253bd78@pop.euronet.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 22:53 10-10-2001, you wrote: >At 22:24 10-10-2001 +0200, Arjen Wolfs wrote: > >>I'm seeing a lot of discussion about the 2.4.10 and 2.4.11, and I am >>wondering when the next "stable" linux-xfs release will be. So far the >>2.4 series of kernels (with or without xfs) has mostly been a "try random >>kernels and kernel configurations until you find one that works for >>you"-approach, which is making life very difficult. It would be really >>good(TM) to have a tested 2.4.10-based (or later) official xfs >>release...is any such thing forthcoming? > >No 2.4.10+ work reported yet. You might try rawhide (redhat) or cooker >(mandrake) for something although they will probably be based on a -ac >version. I think there is a certain person to blame :-) All these versions and VM's are fine and dandy, but at the end of the day people expect to get some actual work done with this supposed "stable" kernel series ;) >If 2.4.8-ac is good enough for you, try the mandrake kernel from 8.1 which >seems to work well for me at work on highmem smp boxes. It also holds up >well against some higher load I threw at it. Highmem+SMP is also what I'm blessed with, ~2.2 million files on a 250GB hardware raid5 xfs partition...removing 30 files of ~300 bytes each takes approximately 1 minute(!). >In general the 2.4 -ac kernels that alan produces fare better then the 2.4 >-linus kernels. Even when Alan is merging alot he still manages to retain >a lot of stability. This is the exact reason why he is skipping the 2.4.10 >VM change and is still holding onto the VM that Rik van Riel wrote. >He is slowly inserting some speedups Rik sent in the -ac VM which a lot of >people are also noticing. Are there xfs patches available for these kernels, or can the "standard" ones be applied? >Both RedHat and Mandrake use -ac for their distributions. I don't know >about SuSE. Maybe a SuSE user can comment on that. I am a SuSE user, but I never use rpm's, nor "official" suse kernels... /A From owner-linux-xfs@oss.sgi.com Wed Oct 10 14:37:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ALbWS32268 for linux-xfs-outgoing; Wed, 10 Oct 2001 14:37:32 -0700 Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ALbOD32246 for ; Wed, 10 Oct 2001 14:37:25 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9ALbaXe094190; Wed, 10 Oct 2001 23:37:36 +0200 (CEST) Message-Id: <4.3.2.7.2.20011010232741.03024870@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 10 Oct 2001 23:36:15 +0200 To: Arjen Wolfs From: Seth Mos Subject: Re: stable release? Cc: linux-xfs@oss.sgi.com In-Reply-To: <5.1.0.14.2.20011010230201.00aca3f8@pop.euronet.nl> References: <4.3.2.7.2.20011010224102.0301c638@pop.xs4all.nl> <5.1.0.14.2.20011010222046.0253bd78@pop.euronet.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 23:06 10-10-2001 +0200, Arjen Wolfs wrote: >At 22:53 10-10-2001, you wrote: >>At 22:24 10-10-2001 +0200, Arjen Wolfs wrote: >> >>No 2.4.10+ work reported yet. You might try rawhide (redhat) or cooker >>(mandrake) for something although they will probably be based on a -ac >>version. I think there is a certain person to blame :-) > >All these versions and VM's are fine and dandy, but at the end of the day >people expect to get some actual work done with this supposed "stable" >kernel series ;) Uhm, yeah. I suppose... >>If 2.4.8-ac is good enough for you, try the mandrake kernel from 8.1 >>which seems to work well for me at work on highmem smp boxes. It also >>holds up well against some higher load I threw at it. > >Highmem+SMP is also what I'm blessed with, ~2.2 million files on a 250GB >hardware raid5 xfs partition...removing 30 files of ~300 bytes each takes >approximately 1 minute(!). I suggest downloading the tarball of the mandrake 2.4.8 kernel which has XFS support. http://iserv.nl/files/xfs/ It will probably do a lot better. It is 38% faster with ext2 then the 2.4.2 kernel that came with redhat 7.1 I let the box run with continous IO from mongo.pl with 50 processes which produced a constant load average of about 52. The box was sluggish but had a good response. It run for a day without crashing. This was with ext2, xfs tomorrow. >>In general the 2.4 -ac kernels that alan produces fare better then the >>2.4 -linus kernels. Even when Alan is merging alot he still manages to >>retain a lot of stability. This is the exact reason why he is skipping >>the 2.4.10 VM change and is still holding onto the VM that Rik van Riel wrote. >>He is slowly inserting some speedups Rik sent in the -ac VM which a lot >>of people are also noticing. > >Are there xfs patches available for these kernels, or can the "standard" >ones be applied? Uhm there are no XFS patches for these (lack of time) and since the VM between -ac and -linus differ so much it can not sanely be applied. The mandrake people did have time for creating a -ac kernel with XFS which is why I recommend that kernel from now on. It is similar to the redhat kernels that are on installer CDs. >>Both RedHat and Mandrake use -ac for their distributions. I don't know >>about SuSE. Maybe a SuSE user can comment on that. > >I am a SuSE user, but I never use rpm's, nor "official" suse kernels... SuSE includes patches as well in their kernel but I don't know if they base it on -ac as well? Groetjes/Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Wed Oct 10 14:41:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ALfe932550 for linux-xfs-outgoing; Wed, 10 Oct 2001 14:41:40 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ALfbD32528 for ; Wed, 10 Oct 2001 14:41:37 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9ALfVW05142 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Wed, 10 Oct 2001 14:41:31 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id XAA2991823 for ; Wed, 10 Oct 2001 23:40:45 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA3276835; Wed, 10 Oct 2001 16:40:13 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA00954; Wed, 10 Oct 2001 16:40:13 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9ALcqb23310; Wed, 10 Oct 2001 16:38:52 -0500 Message-Id: <200110102138.f9ALcqb23310@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Seth Mos cc: Arjen Wolfs , linux-xfs@oss.sgi.com Subject: Re: stable release? In-Reply-To: Message from Seth Mos of "Wed, 10 Oct 2001 23:36:15 +0200." <4.3.2.7.2.20011010232741.03024870@pop.xs4all.nl> Date: Wed, 10 Oct 2001 16:38:51 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > >Highmem+SMP is also what I'm blessed with, ~2.2 million files on a 250GB > >hardware raid5 xfs partition...removing 30 files of ~300 bytes each takes > >approximately 1 minute(!). > > I suggest downloading the tarball of the mandrake 2.4.8 kernel which has > XFS support. > http://iserv.nl/files/xfs/ It will probably do a lot better. > It is 38% faster with ext2 then the 2.4.2 kernel that came with redhat 7.1 > > I let the box run with continous IO from mongo.pl with 50 processes which > produced a constant load average of about 52. The box was sluggish but had > a good response. It run for a day without crashing. > This was with ext2, xfs tomorrow. The problem may be related to raid5 and xfs needing to do 512 byte I/O. Steve From owner-linux-xfs@oss.sgi.com Wed Oct 10 14:45:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ALj4x32736 for linux-xfs-outgoing; Wed, 10 Oct 2001 14:45:04 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ALj1D32713 for ; Wed, 10 Oct 2001 14:45:01 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9ALitW05462 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Wed, 10 Oct 2001 14:44:55 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id XAA3004745 for ; Wed, 10 Oct 2001 23:44:08 +0200 (CEST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA3278254; Wed, 10 Oct 2001 16:43:37 -0500 (CDT) Received: from sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id QAA65592; Wed, 10 Oct 2001 16:43:37 -0500 (CDT) Message-ID: <3BC4C0F4.1403B30B@sgi.com> Date: Wed, 10 Oct 2001 16:43:16 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.8-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Seth Mos CC: Arjen Wolfs , linux-xfs@oss.sgi.com Subject: Re: stable release? References: <4.3.2.7.2.20011010224102.0301c638@pop.xs4all.nl> <5.1.0.14.2.20011010222046.0253bd78@pop.euronet.nl> <4.3.2.7.2.20011010232741.03024870@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > The mandrake people did have time for creating a -ac kernel with XFS which > is why I recommend that kernel from now on. It is similar to the redhat > kernels that are on installer CDs. > > >>Both RedHat and Mandrake use -ac for their distributions. I don't know > >>about SuSE. Maybe a SuSE user can comment on that. FWIW, I'm working on merging our 2.4.7 patch into Red Hat's upcoming(?) kernel release. Sure hope I got the right kernel out of rawhide... :) The idea, of course, is that the underlying RH kernel might be a bit more stable than generic Linux. I'll send out a note when it's ready for testing... -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Oct 10 16:20:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ANK6502223 for linux-xfs-outgoing; Wed, 10 Oct 2001 16:20:06 -0700 Received: from ente.berdmann.de (frnk-d514e1ba.dsl.mediaWays.net [213.20.225.186]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ANK3D02191 for ; Wed, 10 Oct 2001 16:20:03 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 15rSdo-0007zQ-00; Thu, 11 Oct 2001 01:19:56 +0200 Message-ID: <3BC4D79B.5CC419D5@berdmann.de> Date: Thu, 11 Oct 2001 01:19:55 +0200 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.11-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Seth Mos CC: Arjen Wolfs , linux-xfs@oss.sgi.com Subject: Re: stable release? References: <4.3.2.7.2.20011010224102.0301c638@pop.xs4all.nl> <5.1.0.14.2.20011010222046.0253bd78@pop.euronet.nl> <4.3.2.7.2.20011010232741.03024870@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I suggest downloading the tarball of the mandrake 2.4.8 kernel which has > XFS support. > http://iserv.nl/files/xfs/ It will probably do a lot better. > It is 38% faster with ext2 then the 2.4.2 kernel that came with redhat 7.1 What a lovely marketing number! 38%! Wow, great, it rocks so much faster!!! My grandma is dancing again!! (Did I tell you I don't like marketing guys?) From owner-linux-xfs@oss.sgi.com Wed Oct 10 16:23:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ANNDL02368 for linux-xfs-outgoing; Wed, 10 Oct 2001 16:23:13 -0700 Received: from e4.eyal.emu.id.au (CPE-61-9-149-34.vic.bigpond.net.au [61.9.149.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ANN7D02346 for ; Wed, 10 Oct 2001 16:23:07 -0700 Received: from eyal.emu.id.au (eyal.emu.id.au [192.168.2.7]) by e4.eyal.emu.id.au (8.11.6/8.11.2) with ESMTP id f9ANN3O14109; Thu, 11 Oct 2001 09:23:03 +1000 Received: from eyal.emu.id.au (really [127.0.0.1]) by eyal.emu.id.au via in.smtpd with esmtp id (Debian Smail3.2.0.102) for ; Thu, 11 Oct 2001 09:11:53 +1000 (EST) Message-ID: <3BC4D5B9.540960FC@eyal.emu.id.au> Date: Thu, 11 Oct 2001 09:11:53 +1000 From: Eyal Lebedinsky Organization: Eyal at Home X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.10-ac10 i686) X-Accept-Language: en MIME-Version: 1.0 To: Keith Owens CC: linux-xfs list Subject: Re: TAKE - Remove generated scsi files References: <13546.1002722413@ocs3.intra.ocs.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Keith Owens wrote: > > On Wed, 10 Oct 2001 23:30:31 +1000, > Eyal Lebedinsky wrote: > >Keith Owens wrote: > >> > >> Some generated scsi files had crept into the XFS repository. > >> > >> Date: Tue Oct 9 19:56:33 PDT 2001 > >> 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:104250a > >> linux/drivers/scsi/53c8xx_u.h - 1.3 > >> linux/drivers/scsi/53c8xx_d.h - 1.5 > >> linux/drivers/scsi/sim710_d.h - 1.4 > >> linux/drivers/scsi/sim710_u.h - 1.2 > > > >You sure they "crept in"? I built 2.4.11 just fine but 2.4.11-xfs > >fails due to these files missing. The two .configs are identical > >apart from some new XFS items. > > All drivers/scsi/*_[ud].h files are generated. > How does 2.4.11-xfs fail to build? I build everything possible as a module. gcc -D__KERNEL__ -I/data2/usr/local/src/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4 -DMODULE -DMODVERSIONS -include /data2/usr/local/src/linux-2.4-xfs/linux/include/linux/modversions.h -c -o 53c7,8xx.o 53c7,8xx.c 53c7,8xx.c:1579: 53c8xx_d.h: No such file or directory 53c7,8xx.c:3056: 53c8xx_u.h: No such file or directory OK, the Makefile is missing this dependency: 53c7,8xx.o: 53c8xx_d.h Also, a 'make mrproper' does not remove these generated files. I think that 2.4.11 leaves these alone. I am pretty sure the generated files are present in the 2.4.11 tars. -- Eyal Lebedinsky (eyal@eyal.emu.id.au) From owner-linux-xfs@oss.sgi.com Wed Oct 10 17:35:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9B0Zqf03750 for linux-xfs-outgoing; Wed, 10 Oct 2001 17:35:52 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9B0ZoD03728 for ; Wed, 10 Oct 2001 17:35:50 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9B0ZhW17613 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Wed, 10 Oct 2001 17:35:43 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id CAA2968468 for ; Thu, 11 Oct 2001 02:34:53 +0200 (CEST) mail_from (kaos@melbourne.sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by nodin.corp.sgi.com (8.11.4/8.11.2/nodin-1.0) with ESMTP id f9B0YdC4532892; Wed, 10 Oct 2001 17:34:40 -0700 (PDT) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 5A7DE300090; Thu, 11 Oct 2001 10:34:38 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 4DEE198; Thu, 11 Oct 2001 10:34:38 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Eyal Lebedinsky Cc: linux-xfs list Subject: Re: TAKE - Remove generated scsi files In-reply-to: Your message of "Thu, 11 Oct 2001 09:11:53 +1000." <3BC4D5B9.540960FC@eyal.emu.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 11 Oct 2001 10:34:33 +1000 Message-ID: <19302.1002760473@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 11 Oct 2001 09:11:53 +1000, Eyal Lebedinsky wrote: >53c7,8xx.c:1579: 53c8xx_d.h: No such file or directory >53c7,8xx.c:3056: 53c8xx_u.h: No such file or directory > >OK, the Makefile is missing this dependency: >53c7,8xx.o: 53c8xx_d.h > >Also, a 'make mrproper' does not remove these generated files. I think >that 2.4.11 leaves these alone. > >I am pretty sure the generated files are present in the 2.4.11 tars. They are present in 2.4.11 but should not be. Generated files that are shipped then overwritten cause big problems for source control systems. I will be sending Linus and AC a patch to clean up drivers/scsi. From owner-linux-xfs@oss.sgi.com Wed Oct 10 18:28:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9B1S3904701 for linux-xfs-outgoing; Wed, 10 Oct 2001 18:28:03 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9B1RsD04670 for ; Wed, 10 Oct 2001 18:27:54 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with SMTP id f9B1RmK00995 for ; Wed, 10 Oct 2001 18:27:48 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA10143; Thu, 11 Oct 2001 11:26:32 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA33966; Thu, 11 Oct 2001 12:26:31 +1100 (AEDT) Date: Thu, 11 Oct 2001 12:26:31 +1100 From: Nathan Scott To: Robert Sander Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.11 and large files Message-ID: <20011011122630.C486887@wobbly.melbourne.sgi.com> References: <3BC46867.3895800C@illusionary.com> <3BC48047.5959D636@illusionary.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ml-linux-xfs@epigenomics.com on Wed, Oct 10, 2001 at 05:34:19PM +0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Wed, Oct 10, 2001 at 05:34:19PM +0000, Robert Sander wrote: > On Wed, 10 Oct 2001 17:08:28 +0000 (UTC), > Derek Glidden wrote: > > No, actually, it had nothing to do with any 2GB limit. Even doing mkfs > > on a small test partition resulted in some sort of "file size limit" > > error. (I don't remember the exact error message now.) It looked to me > > like quotas were broken, but since I don't absolutely need them, I just > > assumed it was more 2.4 breakage and ignored it. > > I just booted another 2.4.11 kernel the same as before just without > quota support, and it works now. Strange correlation, don't you think? Indeed. Can you tell me whether you have both XFS Quota support and (VFS) Quota support enabled? - they are separate options at kernel build time. Could you try switching OFF XFS quota support (but leaving the normal Quota support ON), and see if the problem persists? FWIW, I have had both forms of quota enabled on all my kernels for, well all 2.4 kernels, and have not come across these issues, so I'm very curious & would really like to reproduce it locally. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Oct 10 18:54:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9B1sqe05215 for linux-xfs-outgoing; Wed, 10 Oct 2001 18:54:52 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9B1smD05190 for ; Wed, 10 Oct 2001 18:54:48 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA29109 for ; Wed, 10 Oct 2001 18:54:45 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA44080 for linux-xfs@oss.sgi.com; Thu, 11 Oct 2001 11:53:29 +1000 (EST) Date: Thu, 11 Oct 2001 11:53:29 +1000 (EST) From: Nathan Scott Message-Id: <200110110153.LAA44080@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - quotactl Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This final quotactl change allows XFS quota to be enabled independently of VFS quota. Adds one file, makes another redundant. Comment at quota.c head explains further. cheers. Date: Wed Oct 10 18:49:11 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:104328a linux/fs/quota.c - 1.1 - the one and only definition of sys_quotactl, handles the three cases of no quota, vfs quota, and xfs quota. linux/fs/noquot.c - 1.7 - empty file, kept for kbuild 2.5 which is based on Linus' tree, not ours. linux/fs/dquot.c - 1.41 - take the VFS quotactl rework one step further so we no longer depend on the quotactl syscall coming from this file. linux/fs/Makefile - 1.36 - add quota.o, remove noquot.o - XFS quota no longer dependent on VFS quota. linux/fs/Config.in - 1.67 - the XFS quota config option is no longer dependent on the VFS quota option. From owner-linux-xfs@oss.sgi.com Wed Oct 10 20:33:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9B3XNC07063 for linux-xfs-outgoing; Wed, 10 Oct 2001 20:33:23 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9B3XID07040 for ; Wed, 10 Oct 2001 20:33:18 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9B3XBW25049 for ; Wed, 10 Oct 2001 20:33:12 -0700 Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id NAA32023; Thu, 11 Oct 2001 13:33:07 +1000 Date: Thu, 11 Oct 2001 13:33:07 +1000 From: Keith Owens Message-Id: <200110110333.NAA32023@sherman.melbourne.sgi.com> Subject: TAKE - Update kbuild 2.5 files for kdb v1.9 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk kdb no longer includes files from user space, bfd.h and ansidecl.h are in arch/$(ARCH)/kdb. Updates kbuild 2.5 Makefile.in files to add new include path. Date: Wed Oct 10 20:28:59 PDT 2001 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:104331a linux/fs/xfs/Makefile - 1.123 linux/arch/i386/kdb/Makefile.in - 1.3 linux/fs/xfs/Makefile.in - 1.4 linux/kdb/Makefile.in - 1.3 linux/kdb/modules/Makefile.in - 1.3 From owner-linux-xfs@oss.sgi.com Wed Oct 10 20:47:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9B3loS07341 for linux-xfs-outgoing; Wed, 10 Oct 2001 20:47:50 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9B3ljD07319 for ; Wed, 10 Oct 2001 20:47:45 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9B3ldK03521 for ; Wed, 10 Oct 2001 20:47:40 -0700 Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id NAA00610; Thu, 11 Oct 2001 13:47:38 +1000 Date: Thu, 11 Oct 2001 13:47:38 +1000 From: Keith Owens Message-Id: <200110110347.NAA00610@sherman.melbourne.sgi.com> Subject: TAKE - Remove __exit attribute from several functions Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Functions marked as __exit must never be called from main line code or from code marked as __init. For a module, __exit code is entered directly from rmmod during module removal. When the code is built into the kernel, the entire __exit section is discarded and therefore must never be referenced from anywhere else. Unfortunately the linker does not flag references to discarded sections as an error. On ix86 the reference is resolved to an offset from the start of the non-existent .text.exit section, as if the section started at 0. So on ix86 you get a resolved reference to the bottom end of memory, if that reference is ever used, oops. On IA64 the linker may flag an error, but only if the distance between the reference and the low value assigned to the discarded symbol cannot fit into the instruction. An external reference in an instruction is normally a 21 bit offset, the kernel starts at 0xe000000004400000 so discarded symbols usually cause an error on IA64, but it is not guaranteed. pagebuf_terminate is called from the __init code so pagebuf_terminate must not be marked as __exit. Changing pagebuf_terminate also meant changing all the functions called by pagebuf_terminate that were marked as __exit. Date: Wed Oct 10 20:32:47 PDT 2001 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:104332a linux/fs/pagebuf/page_buf.c - 1.100 linux/fs/pagebuf/page_buf_locking.c - 1.14 linux/fs/pagebuf/avl.c - 1.5 From owner-linux-xfs@oss.sgi.com Wed Oct 10 22:13:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9B5DnY08593 for linux-xfs-outgoing; Wed, 10 Oct 2001 22:13:49 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9B5DjD08570 for ; Wed, 10 Oct 2001 22:13:45 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id HAA13417; Thu, 11 Oct 2001 07:13:44 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id HAA21831; Thu, 11 Oct 2001 07:13:44 +0200 (CEST) Date: Thu, 11 Oct 2001 07:13:43 +0200 (CEST) From: Seth Mos To: Steve Lord cc: Arjen Wolfs , linux-xfs@oss.sgi.com Subject: Re: stable release? In-Reply-To: <200110102138.f9ALcqb23310@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 10 Oct 2001, Steve Lord wrote: > > > >Highmem+SMP is also what I'm blessed with, ~2.2 million files on a 250GB > > >hardware raid5 xfs partition...removing 30 files of ~300 bytes each takes > > >approximately 1 minute(!). > > > > I suggest downloading the tarball of the mandrake 2.4.8 kernel which has > > XFS support. > > http://iserv.nl/files/xfs/ It will probably do a lot better. > > It is 38% faster with ext2 then the 2.4.2 kernel that came with redhat 7.1 > > > > I let the box run with continous IO from mongo.pl with 50 processes which > > produced a constant load average of about 52. The box was sluggish but had > > a good response. It run for a day without crashing. > > This was with ext2, xfs tomorrow. > > The problem may be related to raid5 and xfs needing to do 512 byte I/O. Should not be an issue on hardware raid? The hardware raid controller should just do what it is told. Maybe I am a bit to optimistic :) Cheers From owner-linux-xfs@oss.sgi.com Wed Oct 10 22:15:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9B5FKv08761 for linux-xfs-outgoing; Wed, 10 Oct 2001 22:15:20 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9B5FHD08739 for ; Wed, 10 Oct 2001 22:15:18 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id HAA13488; Thu, 11 Oct 2001 07:15:16 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id HAA21884; Thu, 11 Oct 2001 07:15:16 +0200 (CEST) Date: Thu, 11 Oct 2001 07:15:16 +0200 (CEST) From: Seth Mos To: "Bernhard R. Erdmann" cc: Arjen Wolfs , linux-xfs@oss.sgi.com Subject: Re: stable release? In-Reply-To: <3BC4D79B.5CC419D5@berdmann.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 11 Oct 2001, Bernhard R. Erdmann wrote: > > I suggest downloading the tarball of the mandrake 2.4.8 kernel which has > > XFS support. > > http://iserv.nl/files/xfs/ It will probably do a lot better. > > It is 38% faster with ext2 then the 2.4.2 kernel that came with redhat 7.1 > > What a lovely marketing number! 38%! Wow, great, it rocks so much > faster!!! My grandma is dancing again!! (Did I tell you I don't like > marketing guys?) Don't offend me. 2.4.2 == 4200 seconds 2.4.8 == 2600 seconds You calculate the difference. It is real. From owner-linux-xfs@oss.sgi.com Wed Oct 10 22:32:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9B5WSB09152 for linux-xfs-outgoing; Wed, 10 Oct 2001 22:32:28 -0700 Received: from gk.hm.epigenomics.net (qmailr@gk.hm.epigenomics.net [212.121.137.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9B5WND09129 for ; Wed, 10 Oct 2001 22:32:23 -0700 Received: (qmail 5774 invoked from network); 11 Oct 2001 05:32:26 -0000 Received: from raman.epigenomics.epi (qmailr@192.168.2.2) by salam.epigenomics.epi with SMTP; 11 Oct 2001 05:32:26 -0000 Received: (qmail 8774 invoked by uid 515); 11 Oct 2001 05:32:20 -0000 Date: Thu, 11 Oct 2001 07:32:20 +0200 From: Robert Sander To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.11 and large files Message-ID: <20011011073220.A7479@epigenomics.com> References: <3BC46867.3895800C@illusionary.com> <3BC48047.5959D636@illusionary.com> <20011011122630.C486887@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20011011122630.C486887@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.3.22i X-Operating-System: Linux raman 2.4.5-xfs-jfs-ngroups Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Oct 11, 2001 at 12:26:31PM +1100, Nathan Scott wrote: > > Indeed. Can you tell me whether you have both XFS Quota support > and (VFS) Quota support enabled? - they are separate options at > kernel build time. Could you try switching OFF XFS quota support > (but leaving the normal Quota support ON), and see if the problem > persists? I had both options on and switched off the VFS quota, XFS quota then went also off. I'll try the other combination later. --- /boot/config-2.4.11-xfs-ngroups Wed Oct 10 10:58:03 2001 +++ /boot/config-2.4.11-xfs-ngroups-noquota Wed Oct 10 19:19:51 2001 @@ -606,8 +606,8 @@ # # File systems # -CONFIG_QUOTA=y -CONFIG_FS_POSIX_ACL=y +# CONFIG_QUOTA is not set +# CONFIG_FS_POSIX_ACL is not set # CONFIG_AUTOFS_FS is not set CONFIG_AUTOFS4_FS=m # CONFIG_REISERFS_FS is not set @@ -653,7 +653,7 @@ # CONFIG_XFS_RT is not set CONFIG_HAVE_ATTRCTL=y CONFIG_XFS_DMAPI=y -CONFIG_XFS_QUOTA=y +# CONFIG_XFS_QUOTA is not set # # Network File Systems I also switched off ACLs, but I think they do not matter. Greetings -- Robert Sander Computer Scientist Epigenomics AG Bioinformatics R&D www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Wed Oct 10 23:26:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9B6Qjf10135 for linux-xfs-outgoing; Wed, 10 Oct 2001 23:26:45 -0700 Received: from ente.berdmann.de (frnk-d514e1ba.dsl.mediaWays.net [213.20.225.186]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9B6QfD10112 for ; Wed, 10 Oct 2001 23:26:41 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 15rZIh-0002Uy-00; Thu, 11 Oct 2001 08:26:35 +0200 Message-ID: <3BC53B9B.8AC295CA@berdmann.de> Date: Thu, 11 Oct 2001 08:26:35 +0200 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.11-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Seth Mos CC: Arjen Wolfs , linux-xfs@oss.sgi.com Subject: Re: stable release? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > > http://iserv.nl/files/xfs/ It will probably do a lot better. > > > It is 38% faster with ext2 then the 2.4.2 kernel that came with redhat 7.1 > > > > What a lovely marketing number! 38%! Wow, great, it rocks so much > > faster!!! My grandma is dancing again!! (Did I tell you I don't like > > marketing guys?) > > Don't offend me. > > 2.4.2 == 4200 seconds > 2.4.8 == 2600 seconds > > You calculate the difference. It is real. ok ok, in this particular case... Do you really want to compare two filesystems just based on this test? From owner-linux-xfs@oss.sgi.com Wed Oct 10 23:51:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9B6psU10649 for linux-xfs-outgoing; Wed, 10 Oct 2001 23:51:54 -0700 Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9B6poD10626 for ; Wed, 10 Oct 2001 23:51:50 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9B6ponV024855; Thu, 11 Oct 2001 08:51:51 +0200 (CEST) Message-Id: <4.3.2.7.2.20011011083952.02e3cb88@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 11 Oct 2001 08:45:00 +0200 To: "Bernhard R. Erdmann" From: Seth Mos Subject: Re: stable release? Cc: Arjen Wolfs , linux-xfs@oss.sgi.com In-Reply-To: <3BC53B9B.8AC295CA@berdmann.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 08:26 11-10-2001 +0200, Bernhard R. Erdmann wrote: > > > > http://iserv.nl/files/xfs/ It will probably do a lot better. > > > > It is 38% faster with ext2 then the 2.4.2 kernel that came with > redhat 7.1 > > > > > > What a lovely marketing number! 38%! Wow, great, it rocks so much > > > faster!!! My grandma is dancing again!! (Did I tell you I don't like > > > marketing guys?) > > > > Don't offend me. > > > > 2.4.2 == 4200 seconds > > 2.4.8 == 2600 seconds > > > > You calculate the difference. It is real. > >ok ok, in this particular case... Do you really want to compare two >filesystems just based on this test? Ahem, the filesystems were _both_ ext2. This was to illustrate that the later kernel is a lot faster then what whas shipped on 1.0. I was testing the machine for stability and was not using XFS yet. Dell configured the machine with the wrong scsi backplane which means I need to reinstall anyways. -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Thu Oct 11 00:01:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9B71Fj11460 for linux-xfs-outgoing; Thu, 11 Oct 2001 00:01:15 -0700 Received: from gk.hm.epigenomics.net (qmailr@gk.hm.epigenomics.net [212.121.137.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9B716D11437 for ; Thu, 11 Oct 2001 00:01:06 -0700 Received: (qmail 6336 invoked from network); 11 Oct 2001 07:01:05 -0000 Received: from raman.epigenomics.epi (qmailr@192.168.2.2) by salam.epigenomics.epi with SMTP; 11 Oct 2001 07:01:05 -0000 Received: (qmail 21729 invoked by uid 515); 11 Oct 2001 07:01:04 -0000 Date: Thu, 11 Oct 2001 09:01:04 +0200 From: Robert Sander To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.11 and large files Message-ID: <20011011090104.A17971@epigenomics.com> References: <3BC46867.3895800C@illusionary.com> <3BC48047.5959D636@illusionary.com> <20011011122630.C486887@wobbly.melbourne.sgi.com> <20011011073220.A7479@epigenomics.com> <20011011165935.E486887@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20011011165935.E486887@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.3.22i X-Operating-System: Linux raman 2.4.5-xfs-jfs-ngroups Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Oct 11, 2001 at 04:59:35PM +1100, Nathan Scott wrote: > > > > I had both options on and switched off the VFS quota, XFS quota > > then went also off. I'll try the other combination later. > > Also, your /proc/partitions and /proc/mounts would be useful to > see. Do you have quota actively enabled on any filesystems, or > is just its presence in the kernel enough to trigger this? And > is devfs in use? schrieffer:~# cat /proc/partitions major minor #blocks name 8 0 17921835 sda 8 1 96358 sda1 8 2 489982 sda2 8 3 1 sda3 8 5 2931831 sda5 8 6 979933 sda6 8 7 2931831 sda7 8 8 979933 sda8 8 9 1951866 sda9 8 10 7558551 sda10 8 16 17921835 sdb 8 17 96358 sdb1 8 18 489982 sdb2 8 19 1 sdb3 8 21 2931831 sdb5 8 22 979933 sdb6 8 23 2931831 sdb7 8 24 979933 sdb8 8 25 1951866 sdb9 8 26 7558551 sdb10 8 32 450396160 sdc 8 33 450390276 sdc1 schrieffer:~# cat /proc/mounts /dev/root / ext2 rw 0 0 proc /proc proc rw 0 0 devpts /dev/pts devpts rw 0 0 /dev/sda1 /boot ext2 rw 0 0 /dev/sda5 /usr ext2 rw 0 0 /dev/sda7 /var ext2 rw 0 0 /dev/sda9 /tmp ext2 rw 0 0 /dev/sda10 /usr/local ext2 rw 0 0 automount(pid260) /home autofs rw 0 0 automount(pid238) /vol autofs rw 0 0 automount(pid271) /mnt/nfs autofs rw 0 0 I have no xfs drive mounted yet and I have no devfs and no quota active. /dev/sdb is a copy of /dev/sda made with "dd if=/dev/sda of=/dev/sdb". /dev/sdc1 will become the XFS volume. It is a hardware RAID system with 430GB capacity. Greetings -- Robert Sander Computer Scientist Epigenomics AG Bioinformatics R&D www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Thu Oct 11 00:54:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9B7sKL12828 for linux-xfs-outgoing; Thu, 11 Oct 2001 00:54:20 -0700 Received: from gk.hm.epigenomics.net (qmailr@gk.hm.epigenomics.net [212.121.137.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9B7sED12805 for ; Thu, 11 Oct 2001 00:54:15 -0700 Received: (qmail 6567 invoked from network); 11 Oct 2001 07:54:15 -0000 Received: from raman.epigenomics.epi (qmailr@192.168.2.2) by salam.epigenomics.epi with SMTP; 11 Oct 2001 07:54:15 -0000 Received: (qmail 9845 invoked from network); 11 Oct 2001 07:54:12 -0000 Received: from eigen.epigenomics.epi (qmailr@192.168.2.36) by raman.epigenomics.epi with SMTP; 11 Oct 2001 07:54:12 -0000 Received: (qmail 9428 invoked by uid 515); 11 Oct 2001 07:54:12 -0000 Date: Thu, 11 Oct 2001 09:54:12 +0200 From: Robert Sander To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.11 and large files Message-ID: <20011011095412.A9418@epigenomics.de> References: <3BC46867.3895800C@illusionary.com> <3BC48047.5959D636@illusionary.com> <20011011122630.C486887@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20011011122630.C486887@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.3.22i X-Operating-System: Linux eigen 2.2.19.client-piii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Oct 11, 2001 at 12:26:31PM +1100, Nathan Scott wrote: > Could you try switching OFF XFS quota support > (but leaving the normal Quota support ON), and see if the problem > persists? When switching off only XFS quotas it works! Seems to be nailed down: --- /boot/config-2.4.11-xfs-ngroups Wed Oct 10 10:58:03 2001 +++ /boot/config-2.4.11-xfs-ngroups-noxfsquota Thu Oct 11 09:34:22 2001 @@ -607,7 +607,7 @@ # File systems # CONFIG_QUOTA=y -CONFIG_FS_POSIX_ACL=y +# CONFIG_FS_POSIX_ACL is not set # CONFIG_AUTOFS_FS is not set CONFIG_AUTOFS4_FS=m # CONFIG_REISERFS_FS is not set @@ -653,7 +653,7 @@ # CONFIG_XFS_RT is not set CONFIG_HAVE_ATTRCTL=y CONFIG_XFS_DMAPI=y -CONFIG_XFS_QUOTA=y +# CONFIG_XFS_QUOTA is not set # # Network File Systems Greetings -- Robert Sander Computer Scientist Epigenomics AG Bioinformatics R&D www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Thu Oct 11 01:46:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9B8kF813920 for linux-xfs-outgoing; Thu, 11 Oct 2001 01:46:15 -0700 Received: from k-7.stesmi.com (IDENT:root@as4-1-7.has.s.bonet.se [217.215.31.238]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9B8k8D13898 for ; Thu, 11 Oct 2001 01:46:09 -0700 Received: (from apache@localhost) by k-7.stesmi.com (8.11.2/8.8.7) id f9B8jM129451; Thu, 11 Oct 2001 10:45:22 +0200 X-Authentication-Warning: k-7.stesmi.com: apache set sender to mbox001@stesmi.com using -f Received: from 212.247.172.29 (SquirrelMail authenticated user mbox001) by webmail.stesmi.com with HTTP; Thu, 11 Oct 2001 10:45:22 +0200 (CEST) Message-ID: <63601.212.247.172.29.1002789922.squirrel@webmail.stesmi.com> Date: Thu, 11 Oct 2001 10:45:22 +0200 (CEST) Subject: =?iso-8859-1?Q?[Fwd:_Re:_Uhhuh.._2.4.12]?= From: "=?iso-8859-1?Q?Stefan_Smietanowski?=" To: Reply-To: stesmi@stesmi.com X-Mailer: SquirrelMail (version 1.2.0 [rc1]) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Check this. It might be good to have a look at either moving XFS into 2.5 directly and aim for 2.6 as the definitive time OR to start porting the thing to Alan's AC tree // Stefan -------- Original Message -------- Subject: Re: Uhhuh.. 2.4.12 From: torvalds@transmeta.com (Linus Torvalds) To: linux-kernel@vger.kernel.org In article , Linus Torvalds wrote: > >So I made a 2.4.12, and renamed away the sorry excuse for a kernel that >2.4.11 was. > > - Tim Waugh: parport update ... which is broken. Not a good week. On the other hand, the good news is that I'll open 2.5.x RSN, just because Alan is so much better at maintaining things ;) Linus From owner-linux-xfs@oss.sgi.com Thu Oct 11 02:01:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9B91WF14376 for linux-xfs-outgoing; Thu, 11 Oct 2001 02:01:32 -0700 Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9B91SD14354 for ; Thu, 11 Oct 2001 02:01:29 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9B91Tau057532; Thu, 11 Oct 2001 11:01:30 +0200 (CEST) Message-Id: <4.3.2.7.2.20011011105807.02cd43d8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 11 Oct 2001 11:00:15 +0200 To: stesmi@stesmi.com, From: Seth Mos Subject: Re: [Fwd: Re: Uhhuh.. 2.4.12] In-Reply-To: <63601.212.247.172.29.1002789922.squirrel@webmail.stesmi.co m> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 10:45 11-10-2001 +0200, Stefan Smietanowski wrote: >Check this. It might be good to have a look at either moving XFS into 2.5 >directly and aim for 2.6 as the definitive time OR to start porting the >thing to Alan's AC tree Maybe we can bribe Alan with a few DVD's or CD's ;-) Linus shines at releasing broken stuff it seems. How wonderful. :-/ Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Thu Oct 11 02:14:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9B9Evg14708 for linux-xfs-outgoing; Thu, 11 Oct 2001 02:14:57 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9B9EoD14685 for ; Thu, 11 Oct 2001 02:14:52 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id C1C3EC00B62 for ; Thu, 11 Oct 2001 17:14:47 +0800 (PHT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id E26BCC00B61 for ; Thu, 11 Oct 2001 17:14:45 +0800 (PHT) Date: Thu, 11 Oct 2001 17:14:45 +0800 (PHT) From: Federico Sevilla III To: Linux XFS Mailing List Subject: Re: Uhhuh.. 2.4.12 In-Reply-To: <4.3.2.7.2.20011011105807.02cd43d8@pop.xs4all.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 11 Oct 2001 at 11:00, Seth Mos wrote: > Maybe we can bribe Alan with a few DVD's or CD's ;-) I know Alan's in RedHat's payroll (and RedHat is rather ext3-centric, it seems, but this is just my opinion), but perhaps if we could get XFS on his good side he'd manage to keep his tree XFS-enabled? That would be really great (except I don't know what he thinks about all the internal changes that XFS needs done). SGI can still keep a CVS tree of XFS, where bug squashing can be handled. When a patch looks like it fixes things decently, it can be fed to Alan. But of course the decision of having an XFS-enabled tree is entirely up to Alan, so ... > Linus shines at releasing broken stuff it seems. How wonderful. :-/ At least Linus seems to know about it (self-awareness). Like he said, "Alan is so much better at maintaining things". In my humble opinion, it looks like Linus should start 2.5, and stay there. He can feed Alan stuff he thinks should go into 2.4, and Alan should handle the maintenance of the current stable tree (so we won't need to put quotation marks all around it). When 2.5 is done and it's out as 2.6, he should turn over control to Alan and start 2.7 ... and so on. I think they'd make a really great tandem with something like this. And seemingly more productive than having competing -linus and -ac trees of the same "stable" (?) kernel. Just my 0.0004230691 Euro. (That's how much two Philippine centavos is worth with the exchange rate...) --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Thu Oct 11 02:49:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9B9nAX15523 for linux-xfs-outgoing; Thu, 11 Oct 2001 02:49:10 -0700 Received: from zion.rivenstone.net (dhcp065-024-121-117.columbus.rr.com [65.24.121.117]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9B9n5D15489 for ; Thu, 11 Oct 2001 02:49:05 -0700 Received: from there (gibraltar.rivenstone.net [192.168.1.1]) by zion.rivenstone.net (Postfix) with SMTP id 96C8B1F9C3 for ; Thu, 11 Oct 2001 00:53:41 -0400 (EDT) Content-Type: text/plain; charset="iso-8859-1" From: Joseph Fannin To: linux-xfs@oss.sgi.com Subject: Re: Uhhuh.. 2.4.12 Date: Thu, 11 Oct 2001 05:48:52 -0400 X-Mailer: KMail [version 1.3.2] References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011011045341.96C8B1F9C3@zion.rivenstone.net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thursday 11 October 2001 05:14, you wrote: > On Thu, 11 Oct 2001 at 11:00, Seth Mos wrote: > > Maybe we can bribe Alan with a few DVD's or CD's ;-) > > I know Alan's in RedHat's payroll (and RedHat is rather ext3-centric, it > seems, but this is just my opinion), but perhaps if we could get XFS on > his good side he'd manage to keep his tree XFS-enabled? That would be > really great (except I don't know what he thinks about all the internal > changes that XFS needs done). SGI can still keep a CVS tree of XFS, where > bug squashing can be handled. When a patch looks like it fixes things > decently, it can be fed to Alan. > > But of course the decision of having an XFS-enabled tree is entirely up to > Alan, so ... Alan is on RedHat's payroll but he seems to put some considerable effort into being impartial, at least on kernel issues. He's not even in charge of packaging up RedHat's release kernels, and at least once he's refused certain jobs that could be viewed as a conflict of interest. Alan and the other kernel developers have stated their reasons why XFS is not in any of the official kernels -- largely because the code duplicates too many functions already present in Linux. SGI has their reasons for wanting to keep it that way (it's well tested, both on IRIX and now on Linux); the kernel developers have their own for not allowing it in the official kernels (it's ugly and not the Right Thing.) The problems with 2.95.x compilers is another stumbling block -- though some documents may say these compilers are unsupported for Linux, they are "unofficially" supported for 2.[4|5], as is, to a lesser extent, 3.0.x. Anything that won't build (and work) with at least 2.95.x is broken. I still think XFS will make it into the official kernels for 2.6, but it's not looking like SGI's developers are going to be the ones to get it there; there just isn't enough incentive on SGI's part to devote the resources to do it "the Linux way". But then, that debate died as soon as it started; both parties have bigger eggs to crack right now. (Whether Andrea's VM will live on in 2.4 is another interesting question... I have little doubt it'll be the 2.[5|6] VM.) This is not intended as a flame at SGI or any of the SGI developers... IMHO they're all doing great work, and I'm glad they've chosen to GPL XFS, and to devote so many other resources to Linux. Heh. Someone should make me editor of Kernel Traffic or something. ;-) -- Joseph Fannin jhf@rivenstone.net "Bull in pure form is rare; there is usually some contamination by data." -- William Graves Perry Jr. From owner-linux-xfs@oss.sgi.com Thu Oct 11 02:49:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9B9n2b15466 for linux-xfs-outgoing; Thu, 11 Oct 2001 02:49:02 -0700 Received: from zork.zork.net (zork.zork.net [64.81.65.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9B9mpD15442 for ; Thu, 11 Oct 2001 02:48:51 -0700 Received: from sneakums by zork.zork.net with local (Exim 3.32 #1 (Debian)) id 15rcSQ-0006EB-00; Thu, 11 Oct 2001 02:48:50 -0700 To: Linux XFS Subject: Oops on recovery with Linux-2.4.11-xfs on SPARC From: Sean Neakums X-Message-Flag: Message text advisory: NON-SEQUITUR, STYLE OVER SUBSTANCE X-Mailer: Norman Date: Thu, 11 Oct 2001 10:48:50 +0100 Message-ID: <6ulmii5wxp.fsf@zork.zork.net> Lines: 130 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I was feeling kinda adventurous and had been having excellent results with XFS on an IA-32 box running Debian unstable, so I moved a SPARC Debian unstable install over to 2.4.11 from the CVS tree. I built the kernel with the sparc64 cross-compiler from Debian's gcc-3.0-sparc64 package, version 3.0.2. Everything worked OK initially. Yesterday I moved /usr, /var and /tmp over to XFS , but this morning I started having a few problems. The biggest one was kernel oopsing on mount during recovery (see below). (I'm not sure if I decoded this properly.) xfs_repair got to phase three before dying with a Bus Error, but whatever it managed to do was enough the let the filesystems be mounted again, until the next reboot. I also encountered some strange failures with apt and dpkg, giving strange errors about files not being found, even though they really were there (e.g. apt was trying to move a file from the archives/partial into archives and failed, claiming the file was not there, but it was). Another problem I had was in creating symlinks: doing ln -s lib state would give me a symbolic link called state that pointed not to lib, but to state. This symptom *only* cropped up after I had mounted an XFS filesystem. Before mounting, symlink creation worked fine on my ext2 root; aftermounting an XFS filesystem it failed as described, on both ext2 and XFS filesystems. Regards, Sean. ksymoops 2.4.3 on sparc64 2.2.19. Options used -v vmlinux (specified) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.2.19/ (default) -m /boot/System.map-2.4.11-xfs (specified) No modules in ksyms, skipping objects Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file? -- snip many compare_maps warnings -- SGI XFS with ACLs, EAs, no debug enabled Unable to handle kernel NULL pointer dereference tsk->{mm,active_mm}->context = 0000000000000407 tsk->{mm,active_mm}->pgd = fffff800106a4000 \|/ ____ \|/ "@'/ .. \`@" /_| \__/ |_\ \__U_/ mount(14): Oops TSTATE: 0000004411009602 TPC: 00000000004dec1c TNPC: 00000000004dec20 Y: 00000000 Not tainted Using defaults from ksymoops -t elf32-sparc -a sparc g0: 0000000000000001 g1: 00000000004e5ebc g2: fffff80017843060 g3: 0000000000000000 g4: fffff80000000000 g5: 0000000000000000 g6: fffff800106ac000 g7: 0000000000000000 o0: 0000000000000000 o1: 0000000000620fd8 o2: 00000000000003f0 o3: fffff8001768aec0 o4: fffff80017ec93a0 o5: 00000000000003f0 sp: fffff800106ae6f1 ret_pc: 00000000004debfc l0: ffffffffffffffd0 l1: fffff8001768b0a0 l2: 00000000006c3000 l3: 0000000000620ed0 l4: ff00000000000000 l5: 00ff000000000000 l6: 0000000000620ed2 l7: 0000000000620800 i0: fffff800106ab800 i1: 0000000000000000 i2: 0000000000300000 i3: 0000000000000000 i4: fffff800106af078 i5: 0000000000000000 i6: fffff800106ae7c1 i7: 00000000004ec0b4 Caller[00000000004ec0b4] Caller[00000000004ec9c0] Caller[00000000004e6204] Caller[00000000004edb30] Caller[00000000004f4b90] Caller[00000000004f4d38] Caller[00000000004f4d7c] Caller[000000000050501c] Caller[0000000000469e0c] Caller[000000000046a580] Caller[000000000047df98] Caller[000000000047e2c4] Caller[000000000042db50] Caller[0000000000410a34] Caller[00000000000128ec] Instruction DUMP: 9336e000 4000016b 90100010 80a22000 0240000b 90100010 90100011 40009d3c >>PC; 004dec1c <===== >>O7; 004debfc >>I7; 004ec0b4 Trace; 004ec0b4 Trace; 004ec9c0 Trace; 004e6204 Trace; 004edb30 Trace; 004f4b90 Trace; 004f4d38 Trace; 004f4d7c Trace; 0050501c Trace; 00469e0c Trace; 0046a580 Trace; 0047df98 Trace; 0047e2c4 Trace; 0042db50 Trace; 00410a34 Trace; 000128ec Before first symbol Code; 004dec10 00000000 <_PC>: Code; 004dec10 0: 93 36 e0 00 srl %i3, 0, %o1 Code; 004dec14 4: 40 00 01 6b call 5b0 <_PC+0x5b0> 004df1c0 Code; 004dec18 8: 90 10 00 10 mov %l0, %o0 Code; 004dec1c <===== c: d0 14 21 f2 lduh [ %l0 + 0x1f2 ], %o0 <===== Code; 004dec20 10: 80 a2 20 00 cmp %o0, 0 Code; 004dec24 14: 02 40 00 0b unknown Code; 004dec28 18: 90 10 00 10 mov %l0, %o0 Code; 004dec2c 1c: 90 10 00 11 mov %l1, %o0 Code; 004dec30 20: 40 00 9d 3c call 27510 <_PC+0x27510> 00506120 Code; 004dec34 24: 00 00 00 00 unimp 0 1041 warnings issued. Results may not be reliable. -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Thu Oct 11 03:12:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9BACnS16118 for linux-xfs-outgoing; Thu, 11 Oct 2001 03:12:49 -0700 Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9BAChD16095 for ; Thu, 11 Oct 2001 03:12:43 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9BACxNe077926; Thu, 11 Oct 2001 12:12:59 +0200 (CEST) Message-Id: <4.3.2.7.2.20011011120818.030672f8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 11 Oct 2001 12:11:30 +0200 To: Sean Neakums , Linux XFS From: Seth Mos Subject: Re: Oops on recovery with Linux-2.4.11-xfs on SPARC In-Reply-To: <6ulmii5wxp.fsf@zork.zork.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 10:48 11-10-2001 +0100, Sean Neakums wrote: >I was feeling kinda adventurous and had been having excellent results >with XFS on an IA-32 box running Debian unstable, so I moved a SPARC >Debian unstable install over to 2.4.11 from the CVS tree. I built the >kernel with the sparc64 cross-compiler from Debian's gcc-3.0-sparc64 >package, version 3.0.2. Sparc is unknown teritory at the moment. You are probably one of the first. >Everything worked OK initially. Yesterday I moved /usr, /var and /tmp >over to XFS , but this morning I started having a few problems. The >biggest one was kernel oopsing on mount during recovery (see below). >(I'm not sure if I decoded this properly.) > >xfs_repair got to phase three before dying with a Bus Error, but >whatever it managed to do was enough the let the filesystems be mounted >again, until the next reboot. Lucky you :-) >I also encountered some strange failures with apt and dpkg, giving >strange errors about files not being found, even though they really >were there (e.g. apt was trying to move a file from the >archives/partial into archives and failed, claiming the file was not >there, but it was). This sounds like the behaviour that people spotted when kernels were compiled with early gcc 2.96 versions. There might be a few problems in the XFS code. >Another problem I had was in creating symlinks: doing > >ln -s lib state > >would give me a symbolic link called state that pointed not to lib, >but to state. This symptom *only* cropped up after I had mounted an >XFS filesystem. Before mounting, symlink creation worked fine on my >ext2 root; aftermounting an XFS filesystem it failed as described, on >both ext2 and XFS filesystems. This could be related to the symlink problem that has just been discussed on lkml. 2.4.12 should fix this but this one is also reported to be broken (just don't know what exactly yet). Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Thu Oct 11 03:48:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9BAmbK16769 for linux-xfs-outgoing; Thu, 11 Oct 2001 03:48:37 -0700 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9BAmXD16746 for ; Thu, 11 Oct 2001 03:48:34 -0700 Received: (qmail 24267 invoked from network); 11 Oct 2001 10:48:31 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 11 Oct 2001 10:48:31 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 85DC4300090; Thu, 11 Oct 2001 20:48:27 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 0A30798; Thu, 11 Oct 2001 20:48:26 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Seth Mos Cc: Sean Neakums , Linux XFS Subject: Re: Oops on recovery with Linux-2.4.11-xfs on SPARC In-reply-to: Your message of "Thu, 11 Oct 2001 12:11:30 +0200." <4.3.2.7.2.20011011120818.030672f8@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 11 Oct 2001 20:48:21 +1000 Message-ID: <24534.1002797301@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 11 Oct 2001 12:11:30 +0200, Seth Mos wrote: >This could be related to the symlink problem that has just been discussed >on lkml. 2.4.12 should fix this but this one is also reported to be broken >(just don't know what exactly yet). 2.4.12 has parport problems but it should have fixed the symlink bug. I will upgrade the XFS tree to 2.4.12 later tonight unless somebody beats me to it. From owner-linux-xfs@oss.sgi.com Thu Oct 11 07:30:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9BEUF522059 for linux-xfs-outgoing; Thu, 11 Oct 2001 07:30:15 -0700 Received: from s1.uklinux.net (ns1.uklinux.net [212.1.130.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9BEUBD22037 for ; Thu, 11 Oct 2001 07:30:11 -0700 Received: from pyewacket.nic.uklinux.net (ppp-5b-47.3com.telinco.net [212.159.137.47]) by s1.uklinux.net (8.11.6/8.11.6) with ESMTP id f9BEU3j16305 for ; Thu, 11 Oct 2001 15:30:03 +0100 Envelope-To: Received: from [127.0.0.1] (helo=there) by pyewacket.nic.uklinux.net with smtp (Exim 3.22 #1) id 15rgqb-0000KV-00 for linux-xfs@oss.sgi.com; Thu, 11 Oct 2001 15:30:05 +0100 Content-Type: text/plain; charset="iso-8859-1" From: nic Reply-To: nic@uklinux.net Organization: Quixotic Hackers To: linux-xfs@oss.sgi.com Subject: Re: Compilers (was Re: 2.4.11 don't work yet.) Date: Thu, 11 Oct 2001 15:30:05 +0100 X-Mailer: KMail [version 1.3.1] References: <4.3.2.7.2.20011010132408.02d1f3f0@pop.xs4all.nl> <3BC45B58.EEC0AA7E@sgi.com> In-Reply-To: <3BC45B58.EEC0AA7E@sgi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wednesday 10 October 2001 15:29, Eric Sandeen wrote: > Compilers are still a touchy subject... we just found one compiler bug > last week w/ the RH 7.1 version of GCC, which caused filesystem > corruption if you use xfs_growfs. gcc 3.0.1 from Mandrake did not > exibit this problem... > > In short, "kgcc" is still the only compiler that we have a lot of > confidence in - others may work most of the time, but I still don't have > a "warm fuzzy" about any of them. OK - I tried gcc 3.0.0 and it did exactly the same. I'm suspecting my source tree is corrupt. Not what you want over a 'phone line. Thanks all, nic From owner-linux-xfs@oss.sgi.com Thu Oct 11 07:38:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9BEcQA22313 for linux-xfs-outgoing; Thu, 11 Oct 2001 07:38:26 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9BEcOD22291 for ; Thu, 11 Oct 2001 07:38:24 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA22436 for ; Thu, 11 Oct 2001 07:38:21 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA61274; Thu, 11 Oct 2001 07:37:47 -0700 (PDT) Message-ID: <3BC5ADF7.5D4EBC83@sgi.com> Date: Thu, 11 Oct 2001 09:34:31 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: Joseph Fannin CC: linux-xfs@oss.sgi.com Subject: Re: Uhhuh.. 2.4.12 References: <20011011045341.96C8B1F9C3@zion.rivenstone.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Joseph Fannin wrote: > The problems with 2.95.x compilers is another stumbling block -- though > some documents may say these compilers are unsupported for Linux, they are > "unofficially" supported for 2.[4|5], as is, to a lesser extent, 3.0.x. > Anything that won't build (and work) with at least 2.95.x is broken. That may be the current opinion, but the fact is that there are compiler bugs in those versions of gcc that miscompile some of our perfectly legitimate code. See my TAKE message from yesterday, for example. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Oct 11 07:50:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9BEoc422614 for linux-xfs-outgoing; Thu, 11 Oct 2001 07:50:39 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9BEoaD22592 for ; Thu, 11 Oct 2001 07:50:36 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA04120 for ; Thu, 11 Oct 2001 07:49:38 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA3284563; Thu, 11 Oct 2001 09:49:19 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA05917; Thu, 11 Oct 2001 09:49:19 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9BElpZ30733; Thu, 11 Oct 2001 09:47:51 -0500 Message-Id: <200110111447.f9BElpZ30733@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: nic@uklinux.net cc: linux-xfs@oss.sgi.com Subject: Re: Compilers (was Re: 2.4.11 don't work yet.) In-Reply-To: Message from nic of "Thu, 11 Oct 2001 15:30:05 BST." Date: Thu, 11 Oct 2001 09:47:51 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Wednesday 10 October 2001 15:29, Eric Sandeen wrote: > > Compilers are still a touchy subject... we just found one compiler bug > > last week w/ the RH 7.1 version of GCC, which caused filesystem > > corruption if you use xfs_growfs. gcc 3.0.1 from Mandrake did not > > exibit this problem... > > > > In short, "kgcc" is still the only compiler that we have a lot of > > confidence in - others may work most of the time, but I still don't have > > a "warm fuzzy" about any of them. > > OK - I tried gcc 3.0.0 and it did exactly the same. I'm suspecting my source > tree is corrupt. Not what you want over a 'phone line. > > Thanks all, > nic You say it did exactly the same - can you elaborate? Did you run growfs and see corruption reported after this? Steve From owner-linux-xfs@oss.sgi.com Thu Oct 11 08:10:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9BFATI23273 for linux-xfs-outgoing; Thu, 11 Oct 2001 08:10:29 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9BFAQD23247 for ; Thu, 11 Oct 2001 08:10:26 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9BFAKW10142 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Thu, 11 Oct 2001 08:10:20 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id RAA3082725 for ; Thu, 11 Oct 2001 17:10:01 +0200 (CEST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA3075744 for ; Thu, 11 Oct 2001 10:08:58 -0500 (CDT) Received: from sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA49311; Thu, 11 Oct 2001 10:08:57 -0500 (CDT) Message-ID: <3BC5B5EE.731353D4@sgi.com> Date: Thu, 11 Oct 2001 10:08:30 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.8-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: linux-xfs@oss.sgi.com Subject: Re: Compilers (was Re: 2.4.11 don't work yet.) References: <200110111447.f9BElpZ30733@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Different problem, I think - nic originally reported > but 2.4.11 seems to get to the > stage between 'Mounting local filesystems' and before 'Enabling swap space' > in rc.sysinit. And then I went off on the growfs tangent. :) -Eric Steve Lord wrote: > You say it did exactly the same - can you elaborate? Did you run growfs and > see corruption reported after this? -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Oct 11 08:56:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9BFuaI24634 for linux-xfs-outgoing; Thu, 11 Oct 2001 08:56:36 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9BFuWD24607 for ; Thu, 11 Oct 2001 08:56:33 -0700 Received: from idcomm.com (IDENT:vVWZ8EgPlVMrog+MeVoO6Xagy5zd4Z1b@k56-pip8.idcomm.com [209.60.72.135]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f9BFw7q16360 for ; Thu, 11 Oct 2001 09:58:07 -0600 Message-ID: <3BC5C13C.2D04507E@idcomm.com> Date: Thu, 11 Oct 2001 09:56:44 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: Uhhuh.. 2.4.12 References: <20011011045341.96C8B1F9C3@zion.rivenstone.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Joseph Fannin wrote: ... > Alan and the other kernel developers have stated their reasons why XFS is > not in any of the official kernels -- largely because the code duplicates too > many functions already present in Linux. SGI has their reasons for wanting > to keep it that way (it's well tested, both on IRIX and now on Linux); the > kernel developers have their own for not allowing it in the official kernels > (it's ugly and not the Right Thing.) I'm curious how much the boot kernel size and required ramdisk would be reduced with a single set of functions? ... D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Thu Oct 11 08:57:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9BFvbR24775 for linux-xfs-outgoing; Thu, 11 Oct 2001 08:57:37 -0700 Received: from mail.loewe-komp.de (mail.loewe-komp.de [62.156.155.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9BFvWD24745 for ; Thu, 11 Oct 2001 08:57:32 -0700 Received: from loewe-komp.de (pippin.loewe-komp.de [192.168.169.19]) by mail.loewe-komp.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id f9BG0Tl07818; Thu, 11 Oct 2001 18:00:29 +0200 X-Authentication-Warning: mail.loewe-komp.de: Host pippin.loewe-komp.de [192.168.169.19] claimed to be loewe-komp.de Message-ID: <3BC5C1A4.7FFB877E@loewe-komp.de> Date: Thu, 11 Oct 2001 17:58:28 +0200 From: Peter =?iso-8859-1?Q?W=E4chtler?= Organization: LOEWE. Hannover X-Mailer: Mozilla 4.76 [de] (X11; U; Linux 2.4.9-ac3 i686) X-Accept-Language: de, en MIME-Version: 1.0 To: Eric Sandeen , "linux-xfs@oss.sgi.com" Subject: Re: TAKE - work around gcc bug during xfs_growfs References: <200110102047.f9AKlqE00907@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: > > xfs_growfs was creating corrupted filesystems on kernels compiled with certain > compilers. > > A macro was passed to the function, but the function did not receive the > correct value, i.e.: > > function(MACRO(foo)); > > had a different result than > > bar = MACRO(foo); > function(bar); > > The latter case yielded correct results. > > This bug resulted in AGF headers being placed into the wrong filesystem > blocks. > > This was exibited on the 2.9x compilers in RH 7.1 and Mandrake 8.1. > > "kgcc" and Mandrake's 3.0.1 compiler did not exhibit this problem. > > Just another reminder that when we suggest the use of particular compilers, > it's for a good reason! :) > Would you please provide code snippets or give a hint which portion in xfs_growfs triggers this compiler bug? Not that I don't believe you ;) It gives me really headaches.. Did you report this to the gcc maintainers? From owner-linux-xfs@oss.sgi.com Thu Oct 11 09:03:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9BG3IW25209 for linux-xfs-outgoing; Thu, 11 Oct 2001 09:03:18 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9BG3ED25183 for ; Thu, 11 Oct 2001 09:03:15 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9BG39W15794 for ; Thu, 11 Oct 2001 09:03:09 -0700 Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA3285008; Thu, 11 Oct 2001 11:01:53 -0500 (CDT) Received: from sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id LAA29054; Thu, 11 Oct 2001 11:01:53 -0500 (CDT) Message-ID: <3BC5C255.D11E41E5@sgi.com> Date: Thu, 11 Oct 2001 11:01:25 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.8-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Peter =?iso-8859-1?Q?W=E4chtler?= CC: "linux-xfs@oss.sgi.com" Subject: Re: TAKE - work around gcc bug during xfs_growfs References: <200110102047.f9AKlqE00907@stout.americas.sgi.com> <3BC5C1A4.7FFB877E@loewe-komp.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Peter - Peter Wdchtler wrote: > Would you please provide code snippets or give a hint which portion in xfs_growfs > triggers this compiler bug? You can see the diff at http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_fsops.c.diff?r1=1.69&r2=1.70 > Not that I don't believe you ;) It gives me really headaches.. > > Did you report this to the gcc maintainers? I probably won't report it to the gcc folks, since their latest compiler (3.0.1) does not exhibit this bug any longer. (Or maybe that's just lucky... perhaps I should report it anyway). When RH7.2 comes out (soon?) I'll check their compiler and report it to them if it's still there. It exists in the stock Mandrake 8.1 compiler, and I have notified them. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Oct 11 09:24:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9BGOBp25912 for linux-xfs-outgoing; Thu, 11 Oct 2001 09:24:11 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9BGO8D25890 for ; Thu, 11 Oct 2001 09:24:08 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9BGO3K24787 for ; Thu, 11 Oct 2001 09:24:03 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA3276845; Thu, 11 Oct 2001 11:22:41 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA60568; Thu, 11 Oct 2001 11:22:41 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9BGLDY31091; Thu, 11 Oct 2001 11:21:13 -0500 Message-Id: <200110111621.f9BGLDY31091@jen.americas.sgi.com> To: Peter =?iso-8859-1?Q?W=E4chtler?= cc: Eric Sandeen , "linux-xfs@oss.sgi.com" Subject: Re: TAKE - work around gcc bug during xfs_growfs References: <200110102047.f9AKlqE00907@stout.americas.sgi.com> <3BC5C1A4.7FFB877E@loewe-komp.de> Comments: In-reply-to Peter =?iso-8859-1?Q?W=E4chtler?= message dated "Thu, 11 Oct 2001 17:58:28 +0200." Date: Thu, 11 Oct 2001 11:21:13 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > Did you report this to the gcc maintainers? Well, since this was the redhat compiler they would just laugh. Steve From owner-linux-xfs@oss.sgi.com Thu Oct 11 09:30:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9BGU1w26089 for linux-xfs-outgoing; Thu, 11 Oct 2001 09:30:01 -0700 Received: from localhost.localdomain (dsl-64-130-65-177.telocity.com [64.130.65.177]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9BGTwD26064 for ; Thu, 11 Oct 2001 09:29:58 -0700 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id f9BGYd704422; Thu, 11 Oct 2001 09:34:39 -0700 Subject: Re: Oops on recovery with Linux-2.4.11-xfs on SPARC From: Thomas Duffy To: Sean Neakums Cc: Linux XFS In-Reply-To: <6ulmii5wxp.fsf@zork.zork.net> References: <6ulmii5wxp.fsf@zork.zork.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 11 Oct 2001 09:34:38 -0700 Message-Id: <1002818079.4388.9.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2001-10-11 at 02:48, Sean Neakums wrote: > I was feeling kinda adventurous and had been having excellent results > with XFS on an IA-32 box running Debian unstable, so I moved a SPARC > Debian unstable install over to 2.4.11 from the CVS tree. I built the > kernel with the sparc64 cross-compiler from Debian's gcc-3.0-sparc64 > package, version 3.0.2. Just so you know, sparc64 kernel is only tested and working with 2.92.something version of the compiler. gcc 3.0.2 is untested in it's own realm, so you are introducing two unknowns here: 1) gcc 3.0.2 and 2) xfs on sparc64. lets start with one and then move to the other... that said, have you had luck with a cvs kernel from vger.samba.org (dave miller's tree for sparc64) with gcc-3.0.2? or using gcc-3.0.2 on ia32 w/ xfs? hmm...and you are introducing cross compiling into the fray, but I don't think that should be much of an issue. -tduffy From owner-linux-xfs@oss.sgi.com Thu Oct 11 09:46:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9BGk9f26468 for linux-xfs-outgoing; Thu, 11 Oct 2001 09:46:09 -0700 Received: from trillium-hollow.org (IDENT:root@trillium-hollow.org [209.180.166.89]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9BGk6D26443 for ; Thu, 11 Oct 2001 09:46:06 -0700 Received: from erich (helo=trillium) by trillium-hollow.org with local-esmtp (Exim 3.20 #1) id 15riw8-0004UO-00; Thu, 11 Oct 2001 09:43:56 -0700 To: Eric Sandeen cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - work around gcc bug during xfs_growfs In-Reply-To: Your message of "Thu, 11 Oct 2001 11:01:25 CDT." <3BC5C255.D11E41E5@sgi.com> Date: Thu, 11 Oct 2001 09:43:56 -0700 From: erich@uruk.org Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: > When RH7.2 comes out (soon?) I'll check their compiler and report it > to them if it's still there. It exists in the stock Mandrake 8.1 > compiler, and I have notified them. You may want to check it against the rawhide -99 version, since you know exactly what to test for. If you'd like I could try that tonight for you. -- Erich Stefan Boleyn http://www.uruk.org/ "Reality is truly stranger than fiction; Probably why fiction is so popular" From owner-linux-xfs@oss.sgi.com Thu Oct 11 10:19:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9BHJA227105 for linux-xfs-outgoing; Thu, 11 Oct 2001 10:19:10 -0700 Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9BHJ5D27083 for ; Thu, 11 Oct 2001 10:19:06 -0700 Received: from there ([62.248.183.6]) by fep02-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20011011171902.HWLF27233.fep02-app.kolumbus.fi@there>; Thu, 11 Oct 2001 20:19:02 +0300 Content-Type: text/plain; charset="iso-8859-1" From: Hristo Grigorov To: Eric Sandeen , Peter =?iso-8859-1?q?W=E4chtler?= Subject: Re: TAKE - work around gcc bug during xfs_growfs Date: Thu, 11 Oct 2001 20:19:01 +0300 X-Mailer: KMail [version 1.3.1] Cc: "linux-xfs@oss.sgi.com" References: <200110102047.f9AKlqE00907@stout.americas.sgi.com> <3BC5C1A4.7FFB877E@loewe-komp.de> <3BC5C255.D11E41E5@sgi.com> In-Reply-To: <3BC5C255.D11E41E5@sgi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011011171902.HWLF27233.fep02-app.kolumbus.fi@there> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thursday 11 October 2001 19:01, Eric Sandeen wrote: > Hi Peter - > > Peter Wdchtler wrote: > > Would you please provide code snippets or give a hint which portion in > > xfs_growfs triggers this compiler bug? > > You can see the diff at > > http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_fsops. >c.diff?r1=1.69&r2=1.70 > > > Not that I don't believe you ;) It gives me really headaches.. > > > > Did you report this to the gcc maintainers? > > I probably won't report it to the gcc folks, since their latest compiler > (3.0.1) does not exhibit this bug any longer. (Or maybe that's just > lucky... perhaps I should report it anyway). gcc version 3.0.2 20010905 (Red Hat Linux 7.1 3.0.1-3) That's the latest one. > > When RH7.2 comes out (soon?) I'll check their compiler and report it to > them if it's still there. It exists in the stock Mandrake 8.1 compiler, > and I have notified them. > > -Eric -- Regards, Hristo. From owner-linux-xfs@oss.sgi.com Thu Oct 11 10:20:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9BHKk527278 for linux-xfs-outgoing; Thu, 11 Oct 2001 10:20:46 -0700 Received: from ns.caldera.de (ns.caldera.de [212.34.180.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9BHKhD27256 for ; Thu, 11 Oct 2001 10:20:43 -0700 Received: (from hch@localhost) by ns.caldera.de (8.11.1/8.11.1) id f9BHJwj14491; Thu, 11 Oct 2001 19:19:58 +0200 Date: Thu, 11 Oct 2001 19:19:58 +0200 From: Christoph Hellwig To: =?iso-8859-1?Q?Peter_W=E4chtler?= Cc: Eric Sandeen , "linux-xfs@oss.sgi.com" Subject: Re: TAKE - work around gcc bug during xfs_growfs Message-ID: <20011011191958.A12251@caldera.de> References: <200110102047.f9AKlqE00907@stout.americas.sgi.com> <3BC5C1A4.7FFB877E@loewe-komp.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BC5C1A4.7FFB877E@loewe-komp.de>; from pwaechtler@loewe-komp.de on Thu, Oct 11, 2001 at 05:58:28PM +0200 X-MIME-Autoconverted: from 8bit to quoted-printable by ns.caldera.de id f9BHJwj14491 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f9BHKiD27257 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Oct 11, 2001 at 05:58:28PM +0200, Peter Wächtler wrote: > Did you report this to the gcc maintainers? They would care as gcc 2.96 is RedHat's fork. Christoph -- Of course it doesn't work. We've performed a software upgrade. From owner-linux-xfs@oss.sgi.com Thu Oct 11 12:20:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9BJKVF29742 for linux-xfs-outgoing; Thu, 11 Oct 2001 12:20:31 -0700 Received: from zion.rivenstone.net (dhcp065-024-121-117.columbus.rr.com [65.24.121.117]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9BJKQD29719 for ; Thu, 11 Oct 2001 12:20:27 -0700 Received: from there (gibraltar.rivenstone.net [192.168.1.1]) by zion.rivenstone.net (Postfix) with SMTP id 030601F9C3; Thu, 11 Oct 2001 10:24:58 -0400 (EDT) Content-Type: text/plain; charset="iso-8859-1" From: Joseph Fannin To: Eric Sandeen Subject: Re: Uhhuh.. 2.4.12 Date: Thu, 11 Oct 2001 15:20:13 -0400 X-Mailer: KMail [version 1.3.2] References: <20011011045341.96C8B1F9C3@zion.rivenstone.net> <3BC5ADF7.5D4EBC83@sgi.com> In-Reply-To: <3BC5ADF7.5D4EBC83@sgi.com> Cc: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011011142459.030601F9C3@zion.rivenstone.net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thursday 11 October 2001 10:34, you wrote: > Joseph Fannin wrote: > > The problems with 2.95.x compilers is another stumbling block -- > > though some documents may say these compilers are unsupported for Linux, > > they are "unofficially" supported for 2.[4|5], as is, to a lesser extent, > > 3.0.x. Anything that won't build (and work) with at least 2.95.x is > > broken. > > That may be the current opinion, but the fact is that there are compiler > bugs in those versions of gcc that miscompile some of our perfectly > legitimate code. See my TAKE message from yesterday, for example. > After sending off my last mail I found myself wishing I'd written that I've been running an -xfs kernel (with XFS on /) for over a month now that was built with the 2.95.4-prerelease in Debian unstable, and have had absolutely no problems for over a month now. 2.96 never worked for me. I'm a bit out of my league, since I'm not capable myself of doing what I'm suggesting, but I would guess that if anyone wants to look into the problems with the 2.95.x compilers (2.96 is a probably a red herring), you might want to take a look at 2.95.4. Really, wherever the problem lies, it *will* keep XFS out of the official kernels. -- Joseph Fannin jhf@rivenstone.net "Bull in pure form is rare; there is usually some contamination by data." -- William Graves Perry Jr. From owner-linux-xfs@oss.sgi.com Thu Oct 11 12:31:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9BJVP530101 for linux-xfs-outgoing; Thu, 11 Oct 2001 12:31:25 -0700 Received: from haddock.cd.chalmers.se (haddock.cd.chalmers.se [129.16.79.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9BJVMD30078 for ; Thu, 11 Oct 2001 12:31:22 -0700 Received: from haddock.cd.chalmers.se (localhost [127.0.0.1]) by haddock.cd.chalmers.se (8.9.3+Sun/8.8.7) with ESMTP id VAA25865; Thu, 11 Oct 2001 21:30:41 +0200 (MET DST) Message-Id: <200110111930.VAA25865@haddock.cd.chalmers.se> X-Face: ^"+mumOlNwo;yI>`\39\txuVze?eiR9uqpo2*mE!9MWXgXI0v(3ArwymNWe'.q:eLl!=guD x{jGFEWN6,#HoN%2qRW;7.CL]9%Ap,067"u1%!NUqS.MhV'+,6$Fj-;W2Z}Y,JUZ'L+f)|B@3k3n;gLl*#i[(J-os#fNnDJ8m["|JWNwpORh|_.MGkR#|a~QS!"4hEQ{O{[Ii14{xD PU/:5wuv7m1=TK=.>G8wdfpY~]{H(Qa\1`%|Hz:!)c3f9UOW|WgE"4d\E7?oDu9. Content-Type: text/plain; charset=iso-8859-1 To: Sean Neakums cc: Linux XFS Subject: Re: Oops on recovery with Linux-2.4.11-xfs on SPARC In-Reply-To: Message from Sean Neakums of "Thu, 11 Oct 2001 10:48:50 BST." <6ulmii5wxp.fsf@zork.zork.net> References: <6ulmii5wxp.fsf@zork.zork.net> Date: Thu, 11 Oct 2001 21:30:41 +0200 From: Anders Hammarquist Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I'm also trying to get XFS going on sparc64, with some luck at least... > xfs_repair got to phase three before dying with a Bus Error, but > whatever it managed to do was enough the let the filesystems be mounted > again, until the next reboot. I traced this to an apparent alignment error. Setting BMBT_USE_64 in include/xfs_bmap_btree.h to 0 cures it, and xfs_repair runs fine (or at least appears to). I suspect that there are more issues with reading stuff from odd addresses in the XFS code, though I haven't been able to pinpoint any others. It seems kind of odd, since they say it runs on IA64 and I would guess that it too would break from unaligned accesses... /Anders -- -- Of course I'm crazy, but that doesn't mean I'm wrong. Anders Hammarquist | iko@cd.chalmers.se Physics student, Chalmers University of Technology, | Hem: +46 31 88 48 50 G|teborg, Sweden. RADIO: SM6XMM and N2JGL | Mob: +46 707 27 86 87 From owner-linux-xfs@oss.sgi.com Thu Oct 11 13:07:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9BK7Kq31267 for linux-xfs-outgoing; Thu, 11 Oct 2001 13:07:20 -0700 Received: from smtpgate.pcquote.com (smtpgate.hyperfeed.com [206.217.179.196]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9BK7GD31244 for ; Thu, 11 Oct 2001 13:07:16 -0700 Received: by smtpgate.hyperfeed.com with Internet Mail Service (5.5.2653.19) id <4TN38B7V>; Thu, 11 Oct 2001 15:07:10 -0500 Received: from coredump.pcqt.com (198.206.236.19 [198.206.236.19]) by smtpgate.pcquote.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 4TN38B74; Thu, 11 Oct 2001 15:07:06 -0500 Received: (qmail 1616 invoked by uid 1006); 11 Oct 2001 20:07:02 -0000 From: John Palkovic To: linux-xfs@oss.sgi.com Subject: Re: [Fwd: Re: Uhhuh.. 2.4.12] References: <63601.212.247.172.29.1002789922.squirrel@webmail.stesmi.com> Date: Thu, 11 Oct 2001 15:07:01 -0500 Message-ID: <81bsjeszyy.fsf@coredump.pcqt.com> Lines: 28 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk FWIW, I did a cvsup of my xfs kernel tree from ftp.thebarn.com this morning and then succesfully applied ftp://ftp.kernel.org/pub/linux/kernel/v2.4/patch-2.4.12.bz2 The only hunk which failed was the patch to the top level Makefile. I edited linux/Makefile: VERSION = 2 PATCHLEVEL = 4 SUBLEVEL = 12 EXTRAVERSION =-xfs and built a kernel with no problems. This is a debian system. There is a compilation bug in 2.4.12, which involves linux/drivers/parport/ieee1284_ops.c. If that file fails to compile then s/EEE1284_PH_DIR_UNKNOWN/IEEE1284_PH_ECP_DIR_UNKNOWN/ (2 places). -John -- HyperFeed Technologies Unix Development From owner-linux-xfs@oss.sgi.com Thu Oct 11 13:21:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9BKLwW31675 for linux-xfs-outgoing; Thu, 11 Oct 2001 13:21:58 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9BKLsD31651 for ; Thu, 11 Oct 2001 13:21:54 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9BKLnW08078 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Thu, 11 Oct 2001 13:21:49 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id NAA35447 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Thu, 11 Oct 2001 13:21:48 -0700 (PDT) Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id WAA3121167 for ; Thu, 11 Oct 2001 22:20:39 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA3287893; Thu, 11 Oct 2001 15:20:29 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA40402; Thu, 11 Oct 2001 15:20:29 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9BKIxi31691; Thu, 11 Oct 2001 15:18:59 -0500 Message-Id: <200110112018.f9BKIxi31691@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: John Palkovic cc: linux-xfs@oss.sgi.com Subject: Re: [Fwd: Re: Uhhuh.. 2.4.12] In-Reply-To: Message from John Palkovic of "Thu, 11 Oct 2001 15:07:01 CDT." <81bsjeszyy.fsf@coredump.pcqt.com> Date: Thu, 11 Oct 2001 15:18:59 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > FWIW, I did a cvsup of my xfs kernel tree from ftp.thebarn.com this > morning and then succesfully applied > > ftp://ftp.kernel.org/pub/linux/kernel/v2.4/patch-2.4.12.bz2 > > The only hunk which failed was the patch to the top level > Makefile. I edited linux/Makefile: > > VERSION = 2 > PATCHLEVEL = 4 > SUBLEVEL = 12 > EXTRAVERSION =-xfs > > and built a kernel with no problems. This is a debian system. > > There is a compilation bug in 2.4.12, which involves > linux/drivers/parport/ieee1284_ops.c. If that file fails to compile > then > > s/EEE1284_PH_DIR_UNKNOWN/IEEE1284_PH_ECP_DIR_UNKNOWN/ Yes, I have exactly this waiting to go here - I was holding off waiting for Al Viro to fix the partition code, but since that is broken in 2.4.11 anyway I am not really sure why I am holding it back anymore. Steve > > (2 places). > > -John > > -- > HyperFeed Technologies > Unix Development From owner-linux-xfs@oss.sgi.com Thu Oct 11 13:33:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9BKXdr32011 for linux-xfs-outgoing; Thu, 11 Oct 2001 13:33:39 -0700 Received: from habenero.cnde.iastate.edu (habenero.cnde.iastate.edu [129.186.200.207]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9BKWnD31973 for ; Thu, 11 Oct 2001 13:32:49 -0700 Received: (qmail 5735 invoked by uid 54); 11 Oct 2001 20:32:49 -0000 Received: from ormanpc.cnde.iastate.edu (HELO ormanpc) (129.186.200.24) by habenero.cnde.iastate.edu with SMTP; 11 Oct 2001 20:32:48 -0000 From: "David Orman" To: Subject: inheriting group ID working? Date: Thu, 11 Oct 2001 15:32:13 -0500 Message-ID: <00f301c15293$cf6a87e0$017e10ac@ormanpc> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F4_01C15269.E6947FE0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00F4_01C15269.E6947FE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I've been trying to use the inherit GID functionality and it only seems to work in a vmware machine.. Very Odd. Heres my test script: [root@habenero orman]# cat tester.sh mkdir test chgrp ftp test chmod 2775 test cd test touch test1 mkdir test2 ls -la heres the output on a vmware machine: [root@toys-rh7 /mnt]# ~/tester.sh total 3 drwxrwsr-x 3 root ftp 1024 Oct 11 15:17 . drwxr-xr-x 6 root root 1024 Oct 11 15:17 .. -rw-r--r-- 1 root ftp 0 Oct 11 15:17 test1 drwxr-sr-x 2 root ftp 1024 Oct 11 15:17 test2 worked perfectly! Now heres the output from one of the machines that actually matters: [root@habenero orman]# ./tester.sh total 4 drwxrwsr-x 3 root ftp 37 Oct 11 15:20 . drwxr-xr-x 11 orman root 4096 Oct 11 15:20 .. -rw-r--r-- 1 root ftp 0 Oct 11 15:20 test1 drwxr-xr-x 2 root ftp 9 Oct 11 15:20 test2 Notice that in this case the Set GID bit did not get set in the subdirectory. I've tried this on 2 different machines with the same results. I've even moved the kernel from the real machines to the vmware machine and it still works. That probably means it's not the kernel itself but something to do with hardware? Other details I'm sure you want to know: Base install Redhat 7.1 Kernel upgraded to 2.4.10 via base sources from kernel.org and 2.4.10 patch from oss.sgi.com, all xfs code compiled in, no modules. Vmware version 3.0BETA Hardware: Machine 1: Dual PIII 600, XFS fs on a CMD CRD4110 RAID controller (Seagate 18G's under that) Machine 2: Celeron 700, XFS fs on a 20G IDE Maxtor 98196H8 Any advice? David Orman Network Administrator ISU Center for NDE ------=_NextPart_000_00F4_01C15269.E6947FE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve been trying to use the inherit GID = functionality and it only seems to work in a vmware machine…. Very Odd.

 

Heres my test script:

 

[root@habenero orman]# cat tester.sh

mkdir = test

chgrp ftp = test

chmod 2775 = test

cd = test

touch = test1

mkdir = test2

ls = -la

 

 

heres the output on a vmware machine:

 

[root@toys-rh7 /mnt]# ~/tester.sh =

total = 3

drwxrwsr-x    3 root     ftp       &nbs= p;  1024 Oct 11 15:17 = .

drwxr-xr-x    6 root     root       &nbs= p; 1024 Oct 11 15:17 = ..

-rw-r--r--    1 root     ftp       &nbs= p;     0 Oct 11 15:17 = test1

drwxr-sr-x    2 root     ftp       &nbs= p;  1024 Oct 11 15:17 = test2

 

worked<= font size=3D2 face=3DArial> = perfectly!

 

 

Now heres the output from one of the machines that = actually matters:

 

[root@habenero orman]# = ./tester.sh

total = 4

drwxrwsr-x    3 root     ftp       &nbs= p;    37 Oct 11 15:20 = .

drwxr-xr-x   11 orman    root       &nbs= p; 4096 Oct 11 15:20 = ..

-rw-r--r--    1 root     ftp       &nbs= p;     0 Oct 11 15:20 = test1

drwxr-xr-x    2 root     ftp       &nbs= p;     9 Oct 11 15:20 test2      =

 

Notice that in this case the Set GID bit did not get = set in the subdirectory.

 

I’ve tried this on 2 different machines with = the same results. I’ve even moved the kernel from the real machines to the = vmware machine and it still works.  = That probably means it’s not the kernel itself but something to do with hardware?

 

Other details I’m sure you want to = know:

Base = install Redhat = 7.1

Kernel upgraded to 2.4.10 via base sources from = kernel.org and 2.4.10 patch from oss.sgi.com, all xfs code compiled in, no = modules.

Vmware version 3.0BETA

 

Hardware:

Machine 1:

Dual PIII 600, XFS fs on a CMD CRD4110 RAID = controller (Seagate 18G’s under that)

 

Machine 2:

Celeron 700, XFS fs on a 20G IDE Maxtor = 98196H8

 

Any = advice?

 

 

David Orman

Network = Administrator

ISU Center for NDE

 

------=_NextPart_000_00F4_01C15269.E6947FE0-- From owner-linux-xfs@oss.sgi.com Thu Oct 11 13:51:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9BKpiF32562 for linux-xfs-outgoing; Thu, 11 Oct 2001 13:51:44 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9BKpaD32539 for ; Thu, 11 Oct 2001 13:51:36 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9BKpUW11117 for ; Thu, 11 Oct 2001 13:51:30 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA3290197 for ; Thu, 11 Oct 2001 15:50:15 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA40714 for ; Thu, 11 Oct 2001 15:50:14 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id f9BKmiX31845; Thu, 11 Oct 2001 15:48:44 -0500 Message-Id: <200110112048.f9BKmiX31845@jen.americas.sgi.com> Date: Thu, 11 Oct 2001 15:48:44 -0500 Subject: TAKE - merge up to 2.4.12 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Warts and all - well at least the parport fix is in here. We will throw in a partition table fix once there is a definative one. Date: Thu Oct 11 13:47:01 PDT 2001 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:104628a linux/net/ipv4/tcp.c - 1.34 linux/include/linux/sched.h - 1.45 linux/include/linux/parport.h - 1.20 linux/include/linux/netdevice.h - 1.29 linux/include/linux/fs.h - 1.127 linux/include/linux/ext2_fs.h - 1.17 linux/include/asm-sparc64/unistd.h - 1.14 linux/include/asm-sparc64/processor.h - 1.21 linux/include/asm-sparc/unistd.h - 1.12 linux/include/asm-sparc/processor.h - 1.17 linux/include/asm-i386/smp.h - 1.13 linux/fs/super.c - 1.62 linux/fs/proc/base.c - 1.30 linux/fs/namei.c - 1.40 linux/fs/ext2/inode.c - 1.32 linux/drivers/video/fbmem.c - 1.39 linux/drivers/usb/uhci.c - 1.50 linux/drivers/sbus/char/sab82532.c - 1.21 linux/drivers/sbus/char/rtc.c - 1.13 linux/drivers/sbus/char/openprom.c - 1.11 linux/drivers/sbus/char/flash.c - 1.13 linux/drivers/sbus/char/envctrl.c - 1.14 linux/drivers/sbus/char/bpp.c - 1.16 linux/drivers/sbus/audio/dmy.c - 1.9 linux/drivers/sbus/audio/dbri.c - 1.13 linux/drivers/sbus/audio/cs4231.c - 1.12 linux/drivers/sbus/audio/audio.c - 1.16 linux/drivers/net/sonic.h - 1.8 linux/drivers/net/sonic.c - 1.7 linux/drivers/net/at1700.c - 1.15 linux/drivers/net/acenic.h - 1.15 linux/drivers/net/acenic.c - 1.32 linux/arch/sparc64/kernel/systbls.S - 1.20 linux/arch/sparc64/kernel/process.c - 1.23 linux/arch/sparc64/kernel/dtlb_base.S - 1.10 linux/arch/sparc64/kernel/dtlb_backend.S - 1.10 linux/arch/sparc64/defconfig - 1.51 linux/arch/sparc/kernel/systbls.S - 1.17 linux/arch/sparc/kernel/process.c - 1.20 linux/Makefile - 1.133 linux/drivers/sbus/char/aurora.c - 1.12 linux/drivers/parport/parport_pc.c - 1.39 linux/drivers/parport/ieee1284_ops.c - 1.12 linux/drivers/net/macsonic.c - 1.9 linux/arch/sparc64/kernel/pci.c - 1.22 linux/drivers/sbus/char/uctrl.c - 1.12 linux/include/linux/pci_ids.h - 1.47 linux/drivers/net/sk98lin/skge.c - 1.17 linux/drivers/net/aironet4500.h - 1.9 linux/drivers/sbus/char/jsflash.c - 1.10 linux/Documentation/filesystems/devfs/README - 1.9 linux/Documentation/filesystems/devfs/ChangeLog - 1.13 linux/fs/devfs/base.c - 1.22 linux/drivers/usb/serial/usb-serial.h - 1.15 linux/drivers/parport/ChangeLog - 1.20 linux/drivers/usb/serial/keyspan_pda.c - 1.17 linux/drivers/usb/serial/ftdi_sio.c - 1.22 linux/drivers/usb/serial/usbserial.c - 1.24 linux/drivers/usb/serial/visor.c - 1.24 linux/drivers/usb/serial/omninet.c - 1.16 linux/drivers/usb/serial/digi_acceleport.c - 1.18 linux/drivers/usb/serial/keyspan.c - 1.15 linux/drivers/sbus/char/display7seg.c - 1.3 linux/drivers/usb/serial/belkin_sa.c - 1.12 linux/drivers/usb/serial/mct_u232.c - 1.10 linux/drivers/usb/serial/empeg.c - 1.14 linux/include/linux/shmem_fs.h - 1.3 linux/mm/shmem.c - 1.17 cmd/xfstests/common.config - 1.10 linux/drivers/sbus/char/cpwatchdog.c - 1.4 linux/drivers/usb/serial/io_edgeport.c - 1.12 linux/drivers/scsi/aic7xxx_old.c - 1.9 linux/drivers/sbus/char/riowatchdog.c - 1.3 linux/drivers/usb/serial/cyberjack.c - 1.5 linux/drivers/usb/serial/pl2303.c - 1.6 linux/drivers/usb/usbvideo.h - 1.3 linux/drivers/usb/usbvideo.c - 1.3 linux/fs/namespace.c - 1.3 linux/drivers/usb/serial/ir-usb.c - 1.2 From owner-linux-xfs@oss.sgi.com Thu Oct 11 15:32:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9BMWhH02522 for linux-xfs-outgoing; Thu, 11 Oct 2001 15:32:43 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9BMWeD02497 for ; Thu, 11 Oct 2001 15:32:40 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9BMWZK12834 for ; Thu, 11 Oct 2001 15:32:35 -0700 Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA3292625; Thu, 11 Oct 2001 17:31:19 -0500 (CDT) Received: from sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id RAA55647; Thu, 11 Oct 2001 17:31:19 -0500 (CDT) Message-ID: <3BC61D98.68397606@sgi.com> Date: Thu, 11 Oct 2001 17:30:48 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.8-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: David Orman CC: linux-xfs@oss.sgi.com Subject: Re: inheriting group ID working? References: <00f301c15293$cf6a87e0$017e10ac@ormanpc> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I've been trying to use the inherit GID functionality and it > only seems to work in a vmware machine.... Very Odd. If you add yourself to the ftp group, it will inherit this bit. Down in the guts of XFS, the bit gets set, but then it checks to see if you're in the group that the new directory will inherit... if you're not, it clears that bit again. Anyone know where this behavior is defined for Linux? This _is_ different behavior from ext2, for example... -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Oct 11 16:22:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9BNM4g03452 for linux-xfs-outgoing; Thu, 11 Oct 2001 16:22:04 -0700 Received: from www.fortuitous.com (cs6625133-131.austin.rr.com [66.25.133.131]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9BNM2D03430 for ; Thu, 11 Oct 2001 16:22:02 -0700 Received: by www.fortuitous.com (Postfix, from userid 500) id 45BFF7E8; Thu, 11 Oct 2001 18:21:34 -0500 (CDT) Date: Thu, 11 Oct 2001 18:21:34 -0500 From: pac@fortuitous.com To: linux-xfs@oss.sgi.com Subject: vmware compatiblity Message-ID: <20011011182134.A5027@bistro.marx> Reply-To: pac@fortuitous.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Does anyone know if the later version of the xfs kernel works with vmware 2.x ? Someone said that vmware only was working up to the 2.4.5 kernels. Thankx, -pac -- .--------------------------------------------------------. | Dr. Philip A. Carinhas | pac@fortuitous.com | | Fortuitous Technologies Inc. | http://fortuitous.com | | Linux Consulting & Training | Tel : 1-512-467-2154 | `--------------------------------------------------------' From owner-linux-xfs@oss.sgi.com Thu Oct 11 16:40:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9BNepE03885 for linux-xfs-outgoing; Thu, 11 Oct 2001 16:40:51 -0700 Received: from trillium-hollow.org (IDENT:root@trillium-hollow.org [209.180.166.89]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9BNemD03863 for ; Thu, 11 Oct 2001 16:40:48 -0700 Received: from erich (helo=trillium) by trillium-hollow.org with local-esmtp (Exim 3.20 #1) id 15rpRL-0005GD-00; Thu, 11 Oct 2001 16:40:35 -0700 To: pac@fortuitous.com cc: linux-xfs@oss.sgi.com Subject: Re: vmware compatiblity In-Reply-To: Your message of "Thu, 11 Oct 2001 18:21:34 CDT." <20011011182134.A5027@bistro.marx> Date: Thu, 11 Oct 2001 16:40:35 -0700 From: erich@uruk.org Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk pac@fortuitous.com wrote: > Does anyone know if the later version of the xfs kernel works with > vmware 2.x ? Someone said that vmware only was working up to the > 2.4.5 kernels. Thankx, VMWare 2.0.x has that limitation, yes. The VMWare 3.0 Beta works just fine with the 2.4.10-pre8 xfs kernel I've been running. -- Erich Stefan Boleyn http://www.uruk.org/ "Reality is truly stranger than fiction; Probably why fiction is so popular" From owner-linux-xfs@oss.sgi.com Thu Oct 11 17:15:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9C0Fe004609 for linux-xfs-outgoing; Thu, 11 Oct 2001 17:15:40 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9C0FZD04587 for ; Thu, 11 Oct 2001 17:15:35 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.6/8.11.6) id f9C0Ewx03218; Thu, 11 Oct 2001 20:14:58 -0400 Date: Thu, 11 Oct 2001 20:14:58 -0400 From: Alan Eldridge To: pac@fortuitous.com Cc: SGI XFS Dev List Subject: Re: vmware compatiblity Message-ID: <20011011201458.A2899@wwweasel.geeksrus.net> References: <20011011182134.A5027@bistro.marx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011011182134.A5027@bistro.marx>; from pac@fortuitous.com on Thu, Oct 11, 2001 at 06:21:34PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hey, Eric and Steve, I think this link is a FAQ candidate. On Thu, Oct 11, 2001 at 06:21:34PM -0500, pac@fortuitous.com wrote: > Does anyone know if the later version of the xfs kernel works with > vmware 2.x ? Someone said that vmware only was working up to the > 2.4.5 kernels. Thankx, You need a patch for the kernel modules. But it works. VMWare 3.0 works out of the box on everything I tried it on up to 2.4.10. I'm now happily running VMWare 2.0.4 under Linux 2.4.7. So, to make this work first download the patch: ftp://platan.vc.cvut.cz/pub/vmware/vmmon-for-2.4.7-only.tar.gz Then copy it to the '/usr/local/lib/vmware/modules/source' directory. Next, run: cd /usr/local/lib/vmware/modules/source gunzip vmmon-for-2.4.7-only.tar.gz After that, make a backup of the existing 'vmmon.tar' file and copy the new one into its place: cp vmmon.tar vmmon.tar.backup mv vmmon-for-2.4.7-only.tar vmmon.tar Finally, run: vmware-config.pl -- Alan Eldridge from std_disclaimer import * From owner-linux-xfs@oss.sgi.com Thu Oct 11 17:34:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9C0YjM05119 for linux-xfs-outgoing; Thu, 11 Oct 2001 17:34:45 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9C0YdD05097 for ; Thu, 11 Oct 2001 17:34:39 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id RAA23083 for ; Thu, 11 Oct 2001 17:34:35 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) 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 KAA17575; Fri, 12 Oct 2001 10:33:19 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA44412; Fri, 12 Oct 2001 11:33:07 +1100 (AEDT) Date: Fri, 12 Oct 2001 11:33:07 +1100 From: Nathan Scott To: Robert Sander Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.11 and large files Message-ID: <20011012113306.A454164@wobbly.melbourne.sgi.com> References: <3BC46867.3895800C@illusionary.com> <3BC48047.5959D636@illusionary.com> <20011011122630.C486887@wobbly.melbourne.sgi.com> <20011011095412.A9418@epigenomics.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011011095412.A9418@epigenomics.de>; from robert.sander@epigenomics.com on Thu, Oct 11, 2001 at 09:54:12AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Thu, Oct 11, 2001 at 09:54:12AM +0200, Robert Sander wrote: > On Thu, Oct 11, 2001 at 12:26:31PM +1100, Nathan Scott wrote: > > > Could you try switching OFF XFS quota support > > (but leaving the normal Quota support ON), and see if the problem > > persists? > > When switching off only XFS quotas it works! Seems to be nailed down: > Uhrm. Well, thats very odd. Let me see if we're on the same page - you have a system with no XFS filesystems, and no filesystems of any type with any form of quota at all. And then you dd one >2Gb partition to another, same size. This fails with CONFIG_XFS_QUOTA set, but works without it. It works also before 2.4.10, independent of any quota config options. Your failure is seen in dd(1), copying at the 2Gb mark, it prints out something like "File size limit exceeded" (ie. it receives a SIGXFSZ signal), and exits. Is that all correct? Some points of interest, may or may not be relevent in helping find the problem: - So far, I haven't been able to reproduce the problem, eg. when dd'ing one 3Gb partition to another on my local machine, all quota switched on, with an XFS CVS kernel; - There is no possibility that any XFS quota code is being exectued in your setup (no XFS code at all), other than at bootup - where we don't do much, mainly just some global initialization (locks, memory allocation, etc) - so, I'm a bit amazed that switching off XFS quota can change the outcome at all here; - I'm not sure how even the VFS quota can be involved here, since that quota code should only come into play for a filesystem where we have quota enabled; - SIGXFSZ has nothing to do with filesystem quota, it is sent to a process from truncate/write when the file offset reaches certain limits (in contrast, quota being exceeded would fail the write with errno set to EDQUOT, not by sending a signal). Its all very, very strange... I'm a little inclined to suspect the recent block device changes in 2.4.10/11 - the only XFS quota change recently was some minor changes to the quotactl interface, and this code wouldn't be executed at all in your setup. Do you see any system console messages when you get the error? cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Oct 11 17:51:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9C0pJV05476 for linux-xfs-outgoing; Thu, 11 Oct 2001 17:51:19 -0700 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9C0pFD05453 for ; Thu, 11 Oct 2001 17:51:16 -0700 Received: (qmail 32062 invoked from network); 12 Oct 2001 00:51:12 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 12 Oct 2001 00:51:12 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id EAD5D300090; Fri, 12 Oct 2001 10:51:09 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id DE1FC98; Fri, 12 Oct 2001 10:51:09 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Anders Hammarquist Cc: Sean Neakums , Linux XFS Subject: Re: Oops on recovery with Linux-2.4.11-xfs on SPARC In-reply-to: Your message of "Thu, 11 Oct 2001 21:30:41 +0200." <200110111930.VAA25865@haddock.cd.chalmers.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 12 Oct 2001 10:51:04 +1000 Message-ID: <732.1002847864@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 11 Oct 2001 21:30:41 +0200, Anders Hammarquist wrote: >I suspect that there are more issues with reading stuff from odd addresses >in the XFS code, though I haven't been able to pinpoint any others. >It seems kind of odd, since they say it runs on IA64 and I would guess >that it too would break from unaligned accesses... IA64 recovers from many (but not all) unaligned accesses and logs them. XFS on IA64 definitely works in normal usage. Having said that, XFS recovery on IA64 breaks spectacularly, to the extent that it corrupts the file system. Booting from an XFS root on IA64 is giving me headaches, I'm trying to track it down. From owner-linux-xfs@oss.sgi.com Thu Oct 11 18:58:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9C1wZ506742 for linux-xfs-outgoing; Thu, 11 Oct 2001 18:58:35 -0700 Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9C1wVD06720 for ; Thu, 11 Oct 2001 18:58:31 -0700 Received: from brocade.com (amitc-linux [192.168.198.232]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id SAA22493; Thu, 11 Oct 2001 18:58:24 -0700 (PDT) Message-ID: <3BC64F8A.60608@brocade.com> Date: Thu, 11 Oct 2001 19:03:54 -0700 From: Amit D Chaudhary User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801 X-Accept-Language: en-us MIME-Version: 1.0 To: Steve Lord CC: linux-xfs list Subject: Re:TAKE - fix ABBA deadlock under heavy load Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, This has been posted sometime back, I have a rather simple query, should this change be applied to xfs 1.0.1 on 2.4.2? Since it is mentioned that it was needed for an earlier version and we happen to be at an earlier version, it is prudent to check. Thanks and Regards Amit The diff http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_vnodeops.c.diff?r1=1.507&r2=1.508 The original email ------------------------------------------------------------ This may be what Andrew Tridgell hit, I hit it running dbench 140 and deadlocked between kswapd reclaiming inodes and kupdated flushing inodes. 160 stack traces later...... Date: Tue Aug 14 14:58:24 PDT 2001 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:100765a linux/fs/xfs/xfs_vnodeops.c - 1.508 - Remove ABBA deadlock between ilock and ihash lock, the ihash lock in xfs_finish_reclaim is a hang over from an earlier implementation on Linux, we do not need it anymore, and at some point this deadlock got introduced. From owner-linux-xfs@oss.sgi.com Thu Oct 11 20:24:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9C3OhV08145 for linux-xfs-outgoing; Thu, 11 Oct 2001 20:24:43 -0700 Received: from afara-gw.afara.com (mx1.afara.com [63.113.218.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9C3OcD08119 for ; Thu, 11 Oct 2001 20:24:39 -0700 Received: from tduffy-lnx.afara.com ([10.2.4.191]) by afara-gw.afara.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 11 Oct 2001 20:23:59 -0700 Subject: XFS on RAID 10 From: Thomas Duffy To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15.99+cvs.2001.10.09.08.08 (Preview Release) Date: 11 Oct 2001 20:24:19 -0700 Message-Id: <1002857059.5390.11.camel@tduffy-lnx.afara.com> Mime-Version: 1.0 X-OriginalArrivalTime: 12 Oct 2001 03:23:59.0699 (UTC) FILETIME=[555C9A30:01C152CD] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have setup a little (280G) xfs on RAID 10 (RAID 1 on RAID 0). This has 8 SCSI drives (4 per card). Everything seems to work fine, expect the RAID resync craaaawwwllllsss. It goes at the minimum of 100k/s which should take a few months to finish syncing :) It sometimes bumps up to 250 k/s, but never higher even with no system activity. First off, does anyone know of a way to bump the sync rate up? Could this be some sorta weirdness between XFS and MD that is causing the slow resync? On a simple RAID 1 setup (2 disks) w/ XFS on the device, the resync is as speedy as the SCSI card allows when there is no other I/O which is what I would expect from MD. Other info, I am using 64k chunk sizes on both the RAID 1 and RAID 0 with 4k block sizes on XFS (obiviously because it on i386). These are 10000 rpm ultra SCSI 3 drives, so they should scream. I was able to dd a blank 200G file relatively fast using bs=64k on this device, so it seems to be ok with creating/copying files. Thanks for any help, -tduffy From owner-linux-xfs@oss.sgi.com Thu Oct 11 20:35:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9C3ZUh08455 for linux-xfs-outgoing; Thu, 11 Oct 2001 20:35:30 -0700 Received: from bogon.blenke.com (653224hfc205.tampabay.rr.com [65.32.24.205]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9C3ZMD08432 for ; Thu, 11 Oct 2001 20:35:22 -0700 Received: (from icblenke@localhost) by bogon.blenke.com (8.9.3/8.9.3/Debian 8.9.3-21) id XAA28867; Thu, 11 Oct 2001 23:34:39 -0400 From: "Ian C. Blenke" Date: Thu, 11 Oct 2001 23:34:39 -0400 To: Nathan Scott Cc: Robert Sander , linux-xfs@oss.sgi.com Subject: Re: 2.4.11 and large files Message-ID: <20011011233439.A28717@blenke.com> References: <3BC46867.3895800C@illusionary.com> <3BC48047.5959D636@illusionary.com> <20011011122630.C486887@wobbly.melbourne.sgi.com> <20011011095412.A9418@epigenomics.de> <20011012113306.A454164@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011012113306.A454164@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.3.18i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Oct 12, 2001 at 11:33:07AM +1100, Nathan Scott wrote: > hi, > > On Thu, Oct 11, 2001 at 09:54:12AM +0200, Robert Sander wrote: > > On Thu, Oct 11, 2001 at 12:26:31PM +1100, Nathan Scott wrote: > > > > > Could you try switching OFF XFS quota support > > > (but leaving the normal Quota support ON), and see if the problem > > > persists? > > > > When switching off only XFS quotas it works! Seems to be nailed down: > > > > Uhrm. Well, thats very odd. Indeed. I've just experienced this problem as well. On a 2.4.10 kernel patched with the xfs 2.4.10-9/25 patch, I too experience the "File size limit exceeded" error. At first, I did have Quotas enabled. Following suggestions to the list, I've disabled quota support and built a new kernel... but the problem persists. I am still unable to mkfs.xfs without getting this error. > Let me see if we're on the same page - you have a system with no XFS My system is *entirely* XFS based (even root) with a small 500Mb "rescue" install on ext2 that I can boot to that holds /boot as well. > Your failure is seen in dd(1), copying at the 2Gb mark, it prints out > something like "File size limit exceeded" (ie. it receives a SIGXFSZ > signal), and exits. This is what happens when I do the same (XFS and lvm though): # lvcreate -L3G -ntest vg # dd if=/dev/zero of=/dev/vg/testlv bs=1M count=3000 File size limit exceeded ++ungood > - So far, I haven't been able to reproduce the problem, eg. when > dd'ing one 3Gb partition to another on my local machine, all quota > switched on, with an XFS CVS kernel; So far, it seems to break for me as well. > - There is no possibility that any XFS quota code is being exectued > in your setup (no XFS code at all), other than at bootup - where we > don't do much, mainly just some global initialization (locks, memory > allocation, etc) - so, I'm a bit amazed that switching off XFS quota > can change the outcome at all here; It doesn't fix me. I'm still broken. > Its all very, very strange... I'm a little inclined to suspect the > recent block device changes in 2.4.10/11 - the only XFS quota change > recently was some minor changes to the quotactl interface, and this > code wouldn't be executed at all in your setup. I'm willing to give anything a try at this point... The box in question is one of a pair of machines that were built similarly (99.9% identically). Both machines are running the same 2.4.10 kernel and are exhibiting the same problem. Oddly enough, the "rescue" 2.4.7-xfs kernel that they were built with work fine... one box was able to create and format a large 40G xfs volume yesterday with the "rescue" 2.4.7-xfs boot kernel, and I've been fighting with the other machine to do the same under the "normal" 2.4.10-xfs boot kernel. No dice. > Do you see any system console messages when you get the error? None. - Ian C. Blenke From owner-linux-xfs@oss.sgi.com Thu Oct 11 20:36:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9C3apT08596 for linux-xfs-outgoing; Thu, 11 Oct 2001 20:36:51 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9C3aID08571 for ; Thu, 11 Oct 2001 20:36:18 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA08962 for ; Thu, 11 Oct 2001 20:35:20 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id NAA14345; Fri, 12 Oct 2001 13:36:14 +1000 Date: Fri, 12 Oct 2001 13:36:14 +1000 From: Keith Owens Message-Id: <200110120336.NAA14345@sherman.melbourne.sgi.com> Subject: TAKE - Upgrade XFS to 2.4.13-pre1 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk 2.4.13-pre1 fixes parport and is supposed to fix the missing partition problem. However, if you still get partition problems, report it to linux-kernel, not XFS. I strongly suggest a good backup before using this pre-release. Date: Thu Oct 11 20:31:28 PDT 2001 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:104647a linux/drivers/pcmcia/sa1100_graphicsclient.c - 1.1 linux/drivers/pcmcia/sa1100_generic.c - 1.1 linux/Documentation/arm/SA1100/ADSBitsy - 1.1 linux/Documentation/arm/SA1100/GraphicsMaster - 1.1 linux/drivers/pcmcia/sa1100_freebird.c - 1.1 linux/drivers/pcmcia/sa1100_flexanet.c - 1.1 linux/drivers/pcmcia/sa1100_cerf.c - 1.1 linux/drivers/pcmcia/sa1100_assabet.c - 1.1 linux/drivers/pcmcia/sa1100_adsbitsy.c - 1.1 linux/drivers/pcmcia/sa1100.h - 1.1 linux/drivers/pcmcia/sa1100_graphicsmaster.c - 1.1 linux/drivers/pcmcia/sa1100_h3600.c - 1.1 linux/drivers/pcmcia/sa1100_jornada720.c - 1.1 linux/drivers/pcmcia/sa1100_neponset.c - 1.1 linux/drivers/pcmcia/sa1100_pangolin.c - 1.1 linux/drivers/pcmcia/sa1100_pfs168.c - 1.1 linux/drivers/pcmcia/sa1100_simpad.c - 1.1 linux/drivers/pcmcia/sa1100_stork.c - 1.1 linux/drivers/pcmcia/sa1100_xp860.c - 1.1 linux/drivers/pcmcia/sa1100_yopy.c - 1.1 linux/drivers/i2c/i2c-proc.c - 1.1 linux/drivers/char/ib700wdt.c - 1.1 linux/include/asm-arm/arch-sa1100/adsbitsy.h - 1.1 linux/include/asm-arm/arch-sa1100/graphicsmaster.h - 1.1 linux/include/asm-arm/arch-sa1100/h3600.h - 1.1 linux/arch/arm/mm/mm-ftvpci.c - 1.1 linux/arch/arm/mach-sa1100/leds-graphicsmaster.c - 1.1 linux/arch/arm/mach-sa1100/h3600.c - 1.1 linux/arch/arm/mach-sa1100/graphicsmaster.c - 1.1 linux/arch/arm/mach-sa1100/adsbitsy.c - 1.1 linux/include/linux/i2c-proc.h - 1.1 linux/arch/arm/lib/udivdi3.c - 1.1 linux/arch/arm/lib/ucmpdi2.c - 1.1 linux/arch/arm/lib/putuser.S - 1.1 linux/arch/arm/lib/muldi3.c - 1.1 linux/arch/arm/lib/lshrdi3.c - 1.1 linux/arch/arm/lib/longlong.h - 1.1 linux/arch/arm/lib/lib1funcs.S - 1.1 linux/arch/arm/lib/kbd.c - 1.1 linux/arch/arm/lib/getuser.S - 1.1 linux/arch/arm/lib/ashldi3.c - 1.1 linux/arch/arm/lib/ashrdi3.c - 1.1 linux/arch/arm/lib/gcclib.h - 1.1 linux/net/sunrpc/stats.c - 1.7 linux/net/sunrpc/sched.c - 1.21 linux/net/ipv4/ipconfig.c - 1.19 linux/mm/filemap.c - 1.91 linux/lib/vsprintf.c - 1.14 linux/kernel/ksyms.c - 1.113 linux/include/linux/videodev.h - 1.18 linux/include/linux/i2c.h - 1.13 linux/include/linux/fs.h - 1.128 linux/include/linux/ext2_fs.h - 1.18 linux/include/linux/console_struct.h - 1.4 linux/include/linux/blkdev.h - 1.40 linux/include/linux/b1lli.h - 1.6 linux/include/asm-i386/system.h - 1.20 linux/include/asm-arm/uaccess.h - 1.8 linux/include/asm-arm/signal.h - 1.4 linux/include/asm-arm/setup.h - 1.11 linux/include/asm-arm/processor.h - 1.20 linux/include/asm-arm/pgtable.h - 1.20 linux/include/asm-arm/param.h - 1.6 linux/include/asm-arm/io.h - 1.17 linux/include/asm-arm/hardirq.h - 1.10 linux/include/asm-arm/atomic.h - 1.9 linux/include/asm-arm/a.out.h - 1.5 linux/fs/proc/array.c - 1.32 linux/fs/nfsd/nfsxdr.c - 1.11 linux/fs/nfs/write.c - 1.29 linux/fs/nfs/read.c - 1.23 linux/fs/locks.c - 1.20 linux/fs/lockd/svcproc.c - 1.8 linux/fs/lockd/svclock.c - 1.12 linux/fs/lockd/clntproc.c - 1.15 linux/fs/ext2/inode.c - 1.33 linux/fs/ext2/file.c - 1.17 linux/fs/ext2/acl.c - 1.6 linux/fs/ext2/Makefile - 1.5 linux/fs/block_dev.c - 1.30 linux/fs/attr.c - 1.12 linux/drivers/video/acornfb.c - 1.19 linux/drivers/usb/uhci.c - 1.51 linux/drivers/sound/vidc.c - 1.11 linux/drivers/sound/sb_card.c - 1.29 linux/drivers/sound/opl3sa2.c - 1.11 linux/drivers/sgi/char/graphics.c - 1.16 linux/drivers/scsi/sd.c - 1.46 linux/drivers/scsi/inia100.h - 1.8 linux/drivers/scsi/ini9100u.h - 1.9 linux/drivers/scsi/i91uscsi.h - 1.4 linux/drivers/scsi/i60uscsi.h - 1.6 linux/drivers/scsi/aha152x.c - 1.24 linux/drivers/scsi/Config.in - 1.25 linux/drivers/sbus/char/bpp.c - 1.17 linux/drivers/sbus/audio/amd7930.c - 1.9 linux/drivers/net/Config.in - 1.48 linux/drivers/fc4/socal.c - 1.10 linux/drivers/fc4/soc.c - 1.10 linux/drivers/char/istallion.c - 1.17 linux/drivers/char/adbmouse.c - 1.15 linux/drivers/char/Makefile - 1.50 linux/drivers/char/Config.in - 1.51 linux/drivers/block/paride/pt.c - 1.12 linux/drivers/block/paride/pg.c - 1.11 linux/drivers/block/paride/pf.c - 1.14 linux/drivers/block/paride/pd.c - 1.18 linux/drivers/block/paride/pcd.c - 1.11 linux/drivers/block/paride/paride.c - 1.10 linux/drivers/block/paride/on26.c - 1.6 linux/drivers/block/paride/on20.c - 1.5 linux/drivers/block/paride/ktti.c - 1.5 linux/drivers/block/paride/kbic.c - 1.5 linux/drivers/block/paride/frpw.c - 1.5 linux/drivers/block/paride/friq.c - 1.5 linux/drivers/block/paride/fit3.c - 1.5 linux/drivers/block/paride/fit2.c - 1.5 linux/drivers/block/paride/epia.c - 1.5 linux/drivers/block/paride/epat.c - 1.5 linux/drivers/block/paride/dstr.c - 1.5 linux/drivers/block/paride/comm.c - 1.5 linux/drivers/block/paride/bpck.c - 1.5 linux/drivers/block/paride/aten.c - 1.5 linux/drivers/block/nbd.c - 1.22 linux/drivers/acorn/scsi/queue.c - 1.6 linux/drivers/acorn/scsi/powertec.c - 1.10 linux/drivers/acorn/scsi/oak.c - 1.6 linux/drivers/acorn/scsi/msgqueue.c - 1.6 linux/drivers/acorn/scsi/fas216.c - 1.11 linux/drivers/acorn/scsi/eesox.c - 1.9 linux/drivers/acorn/scsi/ecoscsi.c - 1.6 linux/drivers/acorn/scsi/cumana_2.c - 1.9 linux/drivers/acorn/scsi/acornscsi.c - 1.11 linux/drivers/acorn/char/mouse_rpc.c - 1.8 linux/arch/ppc/amiga/config.c - 1.13 linux/arch/ppc/Makefile - 1.22 linux/arch/i386/kernel/mtrr.c - 1.29 linux/arch/i386/kernel/i386_ksyms.c - 1.42 linux/arch/arm/mm/mm-nexuspci.c - 1.7 linux/arch/arm/mm/init.c - 1.24 linux/arch/arm/mm/fault-common.c - 1.17 linux/arch/arm/mm/fault-armv.c - 1.18 linux/arch/arm/mm/extable.c - 1.4 linux/arch/arm/lib/Makefile - 1.19 linux/arch/arm/kernel/traps.c - 1.22 linux/arch/arm/kernel/time.c - 1.12 linux/arch/arm/kernel/signal.c - 1.16 linux/arch/arm/kernel/setup.c - 1.22 linux/arch/arm/kernel/init_task.c - 1.7 linux/arch/arm/kernel/head-armv.S - 1.17 linux/arch/arm/kernel/entry-common.S - 1.16 linux/arch/arm/kernel/entry-armv.S - 1.21 linux/arch/arm/kernel/dma-isa.c - 1.7 linux/arch/arm/kernel/armksyms.c - 1.20 linux/arch/arm/kernel/Makefile - 1.18 linux/arch/arm/config.in - 1.27 linux/arch/arm/boot/compressed/Makefile - 1.19 linux/arch/arm/boot/Makefile - 1.9 linux/arch/arm/Makefile - 1.23 linux/Makefile - 1.134 linux/MAINTAINERS - 1.76 linux/Documentation/arm/README - 1.7 linux/include/linux/i2o.h - 1.15 linux/drivers/video/cyber2000fb.h - 1.12 linux/drivers/video/cyber2000fb.c - 1.26 linux/drivers/sound/cmpci.c - 1.27 linux/drivers/acorn/scsi/arxescsi.c - 1.9 linux/drivers/tc/tc.c - 1.6 linux/Documentation/video4linux/README.buz - 1.3 linux/drivers/parport/parport_pc.c - 1.40 linux/drivers/parport/parport_atari.c - 1.4 linux/drivers/parport/parport_amiga.c - 1.8 linux/drivers/parport/ieee1284_ops.c - 1.13 linux/drivers/net/ppp_generic.c - 1.24 linux/include/linux/b1pcmcia.h - 1.3 linux/fs/partitions/msdos.c - 1.16 linux/fs/partitions/check.c - 1.33 linux/drivers/pnp/isapnp.c - 1.22 linux/drivers/char/ip2main.c - 1.12 linux/arch/arm/kernel/bios32.c - 1.24 linux/include/asm-arm/cpu-single.h - 1.7 linux/include/asm-arm/cpu-multi32.h - 1.7 linux/drivers/pcmcia/cs.c - 1.29 linux/include/pcmcia/ss.h - 1.9 linux/drivers/pcmcia/Makefile - 1.10 linux/drivers/nubus/nubus_syms.c - 1.2 linux/include/pcmcia/cs_types.h - 1.7 linux/fs/udf/ialloc.c - 1.12 linux/include/linux/udf_fs_sb.h - 1.6 linux/fs/udf/file.c - 1.24 linux/fs/udf/dir.c - 1.15 linux/fs/udf/inode.c - 1.22 linux/fs/udf/balloc.c - 1.10 linux/include/linux/udf_fs.h - 1.12 linux/fs/udf/namei.c - 1.17 linux/fs/udf/super.c - 1.20 linux/fs/udf/truncate.c - 1.9 linux/fs/udf/udfdecl.h - 1.15 linux/include/linux/spinlock.h - 1.11 linux/include/linux/pci_ids.h - 1.48 linux/include/asm-arm/pci.h - 1.13 linux/include/asm-arm/arch-sa1100/keyboard.h - 1.6 linux/include/asm-arm/arch-sa1100/irqs.h - 1.5 linux/include/asm-arm/arch-sa1100/hardware.h - 1.9 linux/include/asm-arm/arch-sa1100/dma.h - 1.5 linux/drivers/net/ppp_synctty.c - 1.10 linux/fs/proc/proc_misc.c - 1.22 linux/drivers/pci/gen-devlist.c - 1.7 linux/drivers/pci/pci.ids - 1.34 linux/drivers/sound/trident.c - 1.27 linux/include/linux/i2c-id.h - 1.10 linux/include/linux/i2c-elektor.h - 1.4 linux/Documentation/i2c/summary - 1.2 linux/drivers/i2c/i2c-velleman.c - 1.5 linux/drivers/i2c/i2c-elv.c - 1.6 linux/drivers/i2c/i2c-elektor.c - 1.9 linux/drivers/i2c/i2c-algo-pcf.c - 1.10 linux/drivers/i2c/i2c-dev.c - 1.13 linux/drivers/i2c/i2c-core.c - 1.12 linux/drivers/i2c/i2c-algo-bit.c - 1.9 linux/drivers/i2c/Makefile - 1.5 linux/drivers/i2c/Config.in - 1.5 linux/Documentation/i2c/dev-interface - 1.4 linux/include/linux/i2c-dev.h - 1.7 linux/Documentation/i2c/writing-clients - 1.5 linux/arch/arm/boot/compressed/head-sa1100.S - 1.8 linux/include/asm-arm/arch-sa1100/uncompress.h - 1.7 linux/drivers/scsi/scsi_scan.c - 1.19 linux/arch/i386/kernel/microcode.c - 1.11 linux/fs/devfs/util.c - 1.8 linux/drivers/ide/rapide.c - 1.6 linux/drivers/ide/ide.c - 1.32 linux/drivers/ide/ide-probe.c - 1.17 linux/drivers/ide/ide-floppy.c - 1.10 linux/drivers/ide/ide-disk.c - 1.16 linux/include/linux/i2o-dev.h - 1.2 linux/arch/s390/kernel/process.c - 1.9 linux/arch/s390/Makefile - 1.5 linux/include/asm-s390/unistd.h - 1.7 linux/include/asm-s390/ucontext.h - 1.3 linux/include/asm-s390/uaccess.h - 1.6 linux/include/asm-s390/lowcore.h - 1.6 linux/arch/s390/kernel/Makefile - 1.4 linux/include/asm-s390/gdb-stub.h - 1.2 linux/include/asm-s390/chandev.h - 1.5 linux/include/asm-s390/spinlock.h - 1.4 linux/include/asm-s390/softirq.h - 1.6 linux/include/asm-s390/smp.h - 1.4 linux/include/asm-s390/sigp.h - 1.4 linux/arch/s390/kernel/gdb-stub.c - 1.2 linux/arch/s390/kernel/entry.S - 1.13 linux/arch/s390/kernel/head.S - 1.6 linux/drivers/s390/net/iucv.c - 1.8 linux/drivers/s390/char/Makefile - 1.5 linux/drivers/s390/block/dasd.c - 1.14 linux/include/asm-s390/ptrace.h - 1.5 linux/include/asm-s390/pgtable.h - 1.8 linux/include/asm-s390/current.h - 1.4 linux/arch/s390/kernel/time.c - 1.4 linux/arch/s390/kernel/lowcore.S - 1.2 linux/include/asm-s390/pgalloc.h - 1.4 linux/arch/s390/kernel/traps.c - 1.7 linux/arch/s390/kernel/s390_ksyms.c - 1.5 linux/arch/s390/kernel/setup.c - 1.5 linux/arch/s390/kernel/signal.c - 1.7 linux/arch/s390/kernel/smp.c - 1.8 linux/arch/s390/mm/extable.c - 1.2 linux/arch/s390/mm/fault.c - 1.7 linux/arch/s390/mm/init.c - 1.8 linux/arch/i386/kernel/msr.c - 1.12 linux/arch/i386/kernel/cpuid.c - 1.5 linux/drivers/char/i810_rng.c - 1.7 linux/arch/arm/boot/compressed/setup-sa1100.S - 1.7 linux/arch/arm/mm/proc-arm720.S - 1.8 linux/include/asm-arm/arch-sa1100/bitsy.h - 1.5 linux/include/asm-arm/arch-sa1100/assabet.h - 1.5 linux/include/asm-arm/arch-sa1100/SA-1111.h - 1.4 linux/drivers/mtd/Config.in - 1.8 linux/include/asm-arm/mach/arch.h - 1.5 linux/drivers/media/video/videodev.c - 1.9 linux/drivers/media/video/saa7110.c - 1.4 linux/drivers/media/video/planb.c - 1.8 linux/drivers/media/video/bw-qcam.c - 1.8 linux/arch/arm/boot/bootp/Makefile - 1.3 linux/arch/arm/boot/bootp/init.S - 1.4 linux/drivers/input/keybdev.c - 1.7 linux/arch/arm/tools/mach-types - 1.9 linux/Documentation/cciss.txt - 1.3 linux/arch/arm/mach-sa1100/Makefile - 1.5 linux/arch/arm/mach-sa1100/leds.c - 1.3 linux/arch/i386/kernel/bluesmoke.c - 1.13 linux/drivers/char/toshiba.c - 1.4 linux/include/asm-arm/hardware/pci_v3.h - 1.4 linux/kernel/context.c - 1.5 linux/Documentation/arm/SA1100/Pangolin - 1.3 linux/arch/i386/kernel/dmi_scan.c - 1.8 linux/include/asm-s390/dasd.h - 1.6 linux/arch/s390x/kernel/traps.c - 1.3 linux/arch/s390x/kernel/time.c - 1.3 linux/arch/s390x/kernel/smp.c - 1.5 linux/arch/s390x/kernel/signal32.c - 1.3 linux/include/asm-s390x/pgtable.h - 1.4 linux/include/asm-s390x/param.h - 1.2 linux/arch/s390x/kernel/signal.c - 1.4 linux/arch/s390x/kernel/setup.c - 1.4 linux/include/asm-s390x/page.h - 1.4 linux/Documentation/s390/chandev.8 - 1.4 linux/include/asm-s390x/mathemu.h - 1.2 linux/include/asm-s390x/lowcore.h - 1.4 linux/include/asm-s390x/debug.h - 1.4 linux/arch/s390x/kernel/s390_ksyms.c - 1.4 linux/include/asm-s390x/dasd.h - 1.7 linux/include/asm-s390x/current.h - 1.3 linux/include/asm-s390x/chandev.h - 1.4 linux/drivers/sound/maestro3.c - 1.7 linux/arch/s390x/kernel/process.c - 1.6 linux/arch/s390x/kernel/mathemu.c - 1.2 linux/arch/s390x/kernel/lowcore.S - 1.2 linux/arch/s390x/kernel/linux32.h - 1.2 linux/arch/s390x/kernel/linux32.c - 1.7 linux/arch/s390x/kernel/ioctl32.c - 1.3 linux/arch/s390x/kernel/head.S - 1.5 linux/include/asm-s390x/sigp.h - 1.3 linux/drivers/s390/net/netiucv.c - 1.8 linux/include/asm-s390x/smp.h - 1.3 linux/drivers/s390/net/ctcmain.c - 1.5 linux/drivers/s390/char/tapechar.c - 1.4 linux/arch/s390x/kernel/entry.S - 1.8 linux/drivers/s390/char/tape34xx.c - 1.5 linux/arch/s390x/kernel/debug.c - 1.4 linux/arch/s390x/kernel/cpcmd.c - 1.3 linux/arch/s390x/kernel/Makefile - 1.4 linux/arch/s390x/defconfig - 1.6 linux/arch/s390x/config.in - 1.4 linux/arch/s390x/mm/init.c - 1.4 linux/arch/s390x/mm/fault.c - 1.5 linux/arch/s390x/mm/extable.c - 1.2 linux/include/asm-s390x/softirq.h - 1.5 linux/include/asm-s390x/spinlock.h - 1.3 linux/include/asm-s390x/ucontext.h - 1.2 linux/arch/s390x/kernel/wrapper32.S - 1.2 linux/drivers/s390/block/dasd_3990_erp.c - 1.6 linux/include/asm-s390x/unistd.h - 1.4 linux/include/asm-arm/arch-sa1100/pangolin.h - 1.2 linux/include/asm-s390/debug.h - 1.4 linux/arch/s390/kernel/debug.c - 1.4 linux/arch/s390x/Makefile - 1.4 linux/drivers/scsi/aic7xxx_old.c - 1.10 linux/arch/arm/mach-integrator/dma.c - 1.2 linux/arch/arm/mach-integrator/pci_v3.c - 1.3 linux/arch/arm/tools/Makefile - 1.4 linux/arch/arm/tools/getconstants.c - 1.4 linux/drivers/s390/char/tuball.c - 1.4 linux/drivers/s390/char/tubtty.c - 1.4 linux/Documentation/s390/s390dbf.txt - 1.2 linux/drivers/block/paride/ppc6lnx.c - 1.3 linux/arch/s390/math-emu/math.c - 1.2 linux/arch/arm/mach-ebsa110/io.c - 1.5 linux/arch/arm/mach-sa1100/dma-sa1100.c - 1.3 linux/arch/arm/mach-sa1100/dma-sa1111.c - 1.3 linux/include/asm-s390/vtoc.h - 1.4 linux/fs/freevxfs/vxfs_super.c - 1.5 linux/drivers/acpi/ospm/thermal/tz_osl.c - 1.4 linux/Documentation/README.nsp_cs.eng - 1.2 linux/drivers/scsi/pcmcia/nsp_cs.c - 1.7 linux/drivers/scsi/pcmcia/nsp_cs.h - 1.5 linux/drivers/scsi/pcmcia/nsp_debug.c - 1.6 linux/drivers/scsi/pcmcia/nsp_io.h - 1.5 linux/Documentation/sonypi.txt - 1.3 linux/Documentation/video4linux/meye.txt - 1.2 linux/drivers/char/sonypi.h - 1.3 linux/include/linux/sonypi.h - 1.3 linux/drivers/char/sonypi.c - 1.3 linux/drivers/message/fusion/isense.c - 1.4 linux/Documentation/s390/CommonIO - 1.2 linux/drivers/s390/char/hwc_cpi.c - 1.3 linux/drivers/scsi/pcmcia/nsp_message.c - 1.3 linux/arch/arm/mach-sa1100/xp860.c - 1.2 linux/arch/arm/mach-sa1100/sa1111.h - 1.2 linux/arch/arm/mach-sa1100/sa1111.c - 1.2 linux/arch/arm/mach-sa1100/sa1111-pcibuf.c - 1.2 linux/arch/arm/kernel/compat.c - 1.2 linux/arch/arm/kernel/entry-header.S - 1.2 linux/arch/arm/mach-sa1100/pfs168.c - 1.2 linux/arch/arm/mach-sa1100/pangolin.c - 1.2 linux/arch/arm/mach-sa1100/neponset.c - 1.2 linux/arch/arm/mach-sa1100/leds.h - 1.2 linux/arch/arm/mach-sa1100/jornada720.c - 1.2 linux/arch/arm/mach-integrator/cpu.c - 1.2 linux/arch/arm/mach-sa1100/graphicsclient.c - 1.2 linux/arch/arm/mach-sa1100/assabet.c - 1.2 linux/arch/arm/mach-sa1100/bitsy.c - 1.2 linux/arch/arm/mach-sa1100/cpu-sa1110.c - 1.2 linux/arch/arm/mach-sa1100/generic.c - 1.2 linux/drivers/sound/nec_vrc5477.c - 1.2 linux/drivers/sound/ite8172.c - 1.2 linux/drivers/scsi/dpt_i2o.c - 1.4 linux/drivers/scsi/README.53c700 - 1.2 linux/drivers/scsi/53c700.c - 1.3 linux/drivers/scsi/53c700.h - 1.3 linux/drivers/i2c/i2c-adap-ite.c - 1.3 linux/drivers/i2c/i2c-algo-ite.c - 1.3 linux/drivers/ide/hptraid.h - 1.2 linux/drivers/ide/hptraid.c - 1.4 linux/drivers/char/mwave/mwavedd.c - 1.2 From owner-linux-xfs@oss.sgi.com Thu Oct 11 20:41:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9C3fcc08793 for linux-xfs-outgoing; Thu, 11 Oct 2001 20:41:38 -0700 Received: from dryline-fw.wireless-sys.com (ssh-yyz.somanetworks.com [216.126.67.45]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9C3fYD08770 for ; Thu, 11 Oct 2001 20:41:34 -0700 Received: from rancor.yyz.somanetworks.com (rancor.yyz.somanetworks.com [10.11.10.87]) by dryline-fw.wireless-sys.com (8.8.7/8.8.7) with ESMTP id XAA18314; Thu, 11 Oct 2001 23:41:31 -0400 Date: Thu, 11 Oct 2001 23:41:31 -0400 (EDT) From: Scott Murray X-X-Sender: To: Thomas Duffy cc: Subject: Re: XFS on RAID 10 In-Reply-To: <1002857059.5390.11.camel@tduffy-lnx.afara.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 11 Oct 2001, Thomas Duffy wrote: > I have setup a little (280G) xfs on RAID 10 (RAID 1 on RAID 0). This > has 8 SCSI drives (4 per card). > > Everything seems to work fine, expect the RAID resync craaaawwwllllsss. > It goes at the minimum of 100k/s which should take a few months to > finish syncing :) It sometimes bumps up to 250 k/s, but never higher > even with no system activity. > > First off, does anyone know of a way to bump the sync rate up? Could > this be some sorta weirdness between XFS and MD that is causing the slow > resync? On a simple RAID 1 setup (2 disks) w/ XFS on the device, the > resync is as speedy as the SCSI card allows when there is no other I/O > which is what I would expect from MD. [snip] echo N > /proc/sys/dev/raid/speed_limit_min where N is how many KB per second you want the raid driver to attempt to resync at. There is a speed_limit_max, which you'd think would be the controlling factor, but I've several times seen what you describe, and setting speed_limit_min to something like 25000 or 50000 greatly decreases the resync time. Scott -- Scott Murray SOMA Networks, Inc. Toronto, Ontario e-mail: scottm@somanetworks.com From owner-linux-xfs@oss.sgi.com Thu Oct 11 21:16:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9C4G6u09433 for linux-xfs-outgoing; Thu, 11 Oct 2001 21:16:06 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9C4FxD09411 for ; Thu, 11 Oct 2001 21:15:59 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9C4FrW04077 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Thu, 11 Oct 2001 21:15:53 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id GAA3088498 for ; Fri, 12 Oct 2001 06:15:28 +0200 (CEST) mail_from (nathans@wobbly.melbourne.sgi.com) 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 OAA18869; Fri, 12 Oct 2001 14:14:33 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA07743; Fri, 12 Oct 2001 15:14:32 +1100 (AEDT) Date: Fri, 12 Oct 2001 15:14:32 +1100 From: Nathan Scott To: "Ian C. Blenke" Cc: Robert Sander , linux-xfs@oss.sgi.com Subject: Re: 2.4.11 and large files Message-ID: <20011012151432.B454164@wobbly.melbourne.sgi.com> References: <3BC46867.3895800C@illusionary.com> <3BC48047.5959D636@illusionary.com> <20011011122630.C486887@wobbly.melbourne.sgi.com> <20011011095412.A9418@epigenomics.de> <20011012113306.A454164@wobbly.melbourne.sgi.com> <20011011233439.A28717@blenke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011011233439.A28717@blenke.com>; from ian@blenke.com on Thu, Oct 11, 2001 at 11:34:39PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Thu, Oct 11, 2001 at 11:34:39PM -0400, Ian C. Blenke wrote: > On Fri, Oct 12, 2001 at 11:33:07AM +1100, Nathan Scott wrote: > > Indeed. I've just experienced this problem as well. On a 2.4.10 kernel > patched with the xfs 2.4.10-9/25 patch, I too experience the "File size > limit exceeded" error. At first, I did have Quotas enabled. Following > suggestions to the list, I've disabled quota support and built a new > kernel... but the problem persists. I am still unable to mkfs.xfs > without getting this error. > > > Let me see if we're on the same page - you have a system with no XFS > > My system is *entirely* XFS based (even root) with a small 500Mb "rescue" > install on ext2 that I can boot to that holds /boot as well. Yes, I didn't mean to imply that XFS wasn't affected - I was just trying to reduce the set of possible sources of the problem. > > > - There is no possibility that any XFS quota code is being exectued > > in your setup (no XFS code at all), other than at bootup - where we > > don't do much, mainly just some global initialization (locks, memory > > allocation, etc) - so, I'm a bit amazed that switching off XFS quota > > can change the outcome at all here; > > It doesn't fix me. I'm still broken. > That makes some sense, at least (i.e. that switching off quota doesn't fix the problem). > > Its all very, very strange... I'm a little inclined to suspect the > > recent block device changes in 2.4.10/11 - the only XFS quota change > > recently was some minor changes to the quotactl interface, and this > > code wouldn't be executed at all in your setup. > > I'm willing to give anything a try at this point... The box in question I would suggest trying the CVS code if you can - that is now at 2.4.13-something and there's plenty of changes in there. Maybe this problem has been diagnosed & fixed in the base kernel - the fact that earlier versions work OK suggests (but doesn't prove) that the problem is coming from outside XFS. > > Oddly enough, the "rescue" 2.4.7-xfs kernel that they were built with work > fine... one box was able to create and format a large 40G xfs volume > yesterday with the "rescue" 2.4.7-xfs boot kernel, and I've been fighting > with the other machine to do the same under the "normal" 2.4.10-xfs boot > kernel. No dice. > I'd suggest booting the 2.4.7-xfs kernel on both machines for now, until this issue is resolved. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Oct 11 22:29:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9C5TcW10506 for linux-xfs-outgoing; Thu, 11 Oct 2001 22:29:38 -0700 Received: from gk.hm.epigenomics.net (qmailr@gk.hm.epigenomics.net [212.121.137.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9C5TVD10484 for ; Thu, 11 Oct 2001 22:29:31 -0700 Received: (qmail 11927 invoked from network); 12 Oct 2001 05:29:32 -0000 Received: from raman.epigenomics.epi (qmailr@192.168.2.2) by salam.epigenomics.epi with SMTP; 12 Oct 2001 05:29:32 -0000 Received: (qmail 13793 invoked by uid 515); 12 Oct 2001 05:29:29 -0000 Date: Fri, 12 Oct 2001 07:29:29 +0200 From: Robert Sander To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.11 and large files Message-ID: <20011012072929.A12857@epigenomics.com> References: <3BC46867.3895800C@illusionary.com> <3BC48047.5959D636@illusionary.com> <20011011122630.C486887@wobbly.melbourne.sgi.com> <20011011095412.A9418@epigenomics.de> <20011012113306.A454164@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20011012113306.A454164@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.3.22i X-Operating-System: Linux raman 2.4.5-xfs-jfs-ngroups Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Oct 12, 2001 at 11:33:07AM +1100, Nathan Scott wrote: > > > > When switching off only XFS quotas it works! Seems to be nailed down: > > > > Uhrm. Well, thats very odd. > > Let me see if we're on the same page - you have a system with no XFS > filesystems, and no filesystems of any type with any form of quota > at all. And then you dd one >2Gb partition to another, same size. > This fails with CONFIG_XFS_QUOTA set, but works without it. It works > also before 2.4.10, independent of any quota config options. > > Your failure is seen in dd(1), copying at the 2Gb mark, it prints out > something like "File size limit exceeded" (ie. it receives a SIGXFSZ > signal), and exits. > > Is that all correct? Yes. It receives a SIGXFSZ. > - There is no possibility that any XFS quota code is being exectued > in your setup (no XFS code at all), other than at bootup - where we > don't do much, mainly just some global initialization (locks, memory > allocation, etc) - so, I'm a bit amazed that switching off XFS quota > can change the outcome at all here; There is no XFS filesystem active at that point of time. > - I'm not sure how even the VFS quota can be involved here, since > that quota code should only come into play for a filesystem where we > have quota enabled; > - SIGXFSZ has nothing to do with filesystem quota, it is sent to a > process from truncate/write when the file offset reaches certain > limits (in contrast, quota being exceeded would fail the write with > errno set to EDQUOT, not by sending a signal). I know. I have looked into the kernel code from where the SIGXFSZ is produced, and there is even an if that handles block devices so that writing to them should never be interrupted by SIGXFSZ. (If I read the code correct, that is ;-) > Do you see any system console messages when you get the error? No. I will try your latest CVS code today and give reports. Greetings -- Robert Sander Computer Scientist Epigenomics AG Bioinformatics R&D www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Thu Oct 11 22:35:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9C5ZgJ10731 for linux-xfs-outgoing; Thu, 11 Oct 2001 22:35:42 -0700 Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9C5ZbD10709 for ; Thu, 11 Oct 2001 22:35:37 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9C5Zsb1002714; Fri, 12 Oct 2001 07:35:55 +0200 (CEST) Message-Id: <4.3.2.7.2.20011012073050.03147d38@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 12 Oct 2001 07:34:21 +0200 To: Thomas Duffy , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: XFS on RAID 10 In-Reply-To: <1002857059.5390.11.camel@tduffy-lnx.afara.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 20:24 11-10-2001 -0700, Thomas Duffy wrote: >I have setup a little (280G) xfs on RAID 10 (RAID 1 on RAID 0). This >has 8 SCSI drives (4 per card). Hardware, software or something in the middle? >Everything seems to work fine, expect the RAID resync craaaawwwllllsss. >It goes at the minimum of 100k/s which should take a few months to >finish syncing :) It sometimes bumps up to 250 k/s, but never higher >even with no system activity. There is something about resyncing in the manpages of the raid tools IIRC. What kernel are you using, any special options and compiled with what compiler. IIRC there were some IO stalls fixed somewhere around 2.4.6. >First off, does anyone know of a way to bump the sync rate up? Could >this be some sorta weirdness between XFS and MD that is causing the slow >resync? On a simple RAID 1 setup (2 disks) w/ XFS on the device, the >resync is as speedy as the SCSI card allows when there is no other I/O >which is what I would expect from MD. What version of md are you using and what scsi card is it. >Other info, I am using 64k chunk sizes on both the RAID 1 and RAID 0 >with 4k block sizes on XFS (obiviously because it on i386). These are >10000 rpm ultra SCSI 3 drives, so they should scream. I was able to dd >a blank 200G file relatively fast using bs=64k on this device, so it >seems to be ok with creating/copying files. That should be fine. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Thu Oct 11 23:01:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9C61WX11230 for linux-xfs-outgoing; Thu, 11 Oct 2001 23:01:32 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9C61PD11208 for ; Thu, 11 Oct 2001 23:01:26 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id IAA04048; Fri, 12 Oct 2001 08:01:23 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id IAA01564; Fri, 12 Oct 2001 08:01:23 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 4F70157306; Fri, 12 Oct 2001 08:00:45 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 0468A25835; Fri, 12 Oct 2001 08:00:45 +0200 (CEST) Message-ID: <3BC6870C.42033674@ch.sauter-bc.com> Date: Fri, 12 Oct 2001 08:00:44 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Thomas Duffy Cc: linux-xfs@oss.sgi.com Subject: Re: XFS on RAID 10 References: <1002857059.5390.11.camel@tduffy-lnx.afara.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thomas Duffy schrieb: > > I have setup a little (280G) xfs on RAID 10 (RAID 1 on RAID 0). This Some time ago I was playing with similar setup. IIRC I saw the same slow resync speed. I then turned my RAID upside down and everything was okay. I dont know how but since you said 'RAID 10 (RAID 1 on RAID 0)' I guess you could just make it (RAID 0 on RAID 1) and it should be okay. In may case sync speed was then ~10000-40000 w/o tuning. I'm interested to hear what came out after. > has 8 SCSI drives (4 per card). > > Everything seems to work fine, expect the RAID resync craaaawwwllllsss. > It goes at the minimum of 100k/s which should take a few months to > finish syncing :) It sometimes bumps up to 250 k/s, but never higher > even with no system activity. > > First off, does anyone know of a way to bump the sync rate up? Could I put this in my /etc/sysctl.conf # Force RAID reconstruction to run with high priority dev.raid.speed_limit_min = 5000 Usually you should not need this. If it does not sync fast while there is no load on the box, something else is not good. But if you have constant load on the box you really need the higher value than the default (100). > this be some sorta weirdness between XFS and MD that is causing the slow > resync? On a simple RAID 1 setup (2 disks) w/ XFS on the device, the > resync is as speedy as the SCSI card allows when there is no other I/O > which is what I would expect from MD. > > Other info, I am using 64k chunk sizes on both the RAID 1 and RAID 0 > with 4k block sizes on XFS (obiviously because it on i386). These are > 10000 rpm ultra SCSI 3 drives, so they should scream. I was able to dd > a blank 200G file relatively fast using bs=64k on this device, so it > seems to be ok with creating/copying files. > > Thanks for any help, > > -tduffy -- Simon Matter Tel: +41 61 695 57 35 Fr.Sauter AG / CIT Fax: +41 61 695 53 30 Im Surinam 55 CH-4016 Basel [mailto:simon.matter@ch.sauter-bc.com] From owner-linux-xfs@oss.sgi.com Thu Oct 11 23:47:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9C6lo212307 for linux-xfs-outgoing; Thu, 11 Oct 2001 23:47:50 -0700 Received: from maul.jdc.home (Nm@c999639-a.carneg1.pa.home.com [24.180.243.111]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9C6ljD12283 for ; Thu, 11 Oct 2001 23:47:45 -0700 Received: from warblade.jdc.home (warblade.jdc.home [10.1.1.2]) by noth.is.eleet.ca with ESMTP id f9C6lK8q001335; Fri, 12 Oct 2001 01:47:20 -0500 Subject: Re: Oops on recovery with Linux-2.4.11-xfs on SPARC From: Jim Crilly To: Anders Hammarquist Cc: Sean Neakums , Linux XFS In-Reply-To: <200110111930.VAA25865@haddock.cd.chalmers.se> References: <6ulmii5wxp.fsf@zork.zork.net> <200110111930.VAA25865@haddock.cd.chalmers.se> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 12 Oct 2001 02:45:45 -0400 Message-Id: <1002869146.796.3.camel@warblade> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Also on sparc64 the kernel is 64-bit but the userspace is only 32-bit, so there's a conversion for anything passed from userspace to kernel via ioctls. I had the filesystem working ok on an Ultra1 but most of the userspace utils were broke (SIGBUS all over the place) and I'm far from competent enough to begin thinking about fixing them. Jim On Thu, 2001-10-11 at 15:30, Anders Hammarquist wrote: > Hi, > > I'm also trying to get XFS going on sparc64, with some luck at least... > > > xfs_repair got to phase three before dying with a Bus Error, but > > whatever it managed to do was enough the let the filesystems be mounted > > again, until the next reboot. > > I traced this to an apparent alignment error. Setting BMBT_USE_64 in > include/xfs_bmap_btree.h to 0 cures it, and xfs_repair runs fine (or > at least appears to). > > I suspect that there are more issues with reading stuff from odd addresses > in the XFS code, though I haven't been able to pinpoint any others. > It seems kind of odd, since they say it runs on IA64 and I would guess > that it too would break from unaligned accesses... > > /Anders > > -- > -- Of course I'm crazy, but that doesn't mean I'm wrong. > Anders Hammarquist | iko@cd.chalmers.se > Physics student, Chalmers University of Technology, | Hem: +46 31 88 48 50 > G|teborg, Sweden. RADIO: SM6XMM and N2JGL | Mob: +46 707 27 86 87 -- Help protect your rights on-line. Join the Electronic Frontiers Foundation today: http://www.eff.org/join ----------------------------------------------------------------------- Security: Antonyms: See Microsoft ----------------------------------------------------------------------- "We are coming after you. God may have mercy on you, but we won't," declared Sen. John McCain, R-Arizona. From owner-linux-xfs@oss.sgi.com Fri Oct 12 00:59:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9C7xUx13675 for linux-xfs-outgoing; Fri, 12 Oct 2001 00:59:30 -0700 Received: from trillium-hollow.org (IDENT:root@trillium-hollow.org [209.180.166.89]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9C7xKD13653 for ; Fri, 12 Oct 2001 00:59:20 -0700 Received: from erich (helo=trillium) by trillium-hollow.org with local-esmtp (Exim 3.20 #1) id 15rxDk-0005tf-00; Fri, 12 Oct 2001 00:59:04 -0700 To: Eric Sandeen cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: RH 7.1 gcc 2.96 bug (was Re: TAKE - work around gcc bug during xfs_growfs ) In-Reply-To: Your message of "Thu, 11 Oct 2001 11:59:20 CDT." <3BC5CFE8.84FDB6FC@sgi.com> Date: Fri, 12 Oct 2001 00:59:04 -0700 From: erich@uruk.org Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: > > You may want to check it against the rawhide -99 version, since you know > > exactly what to test for. If you'd like I could try that tonight for > > you. > > Sure, if you'd like to test it that would be great. I was going to > install that compiler RPM, but it needs a new binutils which needs a > new glibc which needs... :) > > Take a look at that URL for the diff I posted, and back it out. > > To test for the error, ...[example creating an XFS filesystem about 1/2 the partition size, then growing it to the full partition size]... > If you see any errors, it didn't work. :) Well, I wasn't able to reproduce with your test case at all. I suspect that maybe it's the fact that I only had a 2GB spare partition to try it on. On the positive (??!?) side, I looked at the disassembly and found what the compiler is doing wrong in the case you worked around (ok, so you probably already know this, but I'm putting this here so that someone can fix the bug or convince RedHat to move to away from 2.96, maybe to 3.x). In the second one of the 5 cases of where you added a temporary rather than a putting the macro in the function parameter sequence directly, there are some operations done to what appear to be spill locations, but the spill and reload are never performed... so it seems these locations were allocated for spill/reload, but then wires got crossed somewhere. In the "fixed" version, the exact same operations are performed on the same stack locations, but the spill happens before and a reload happens afterward, hence my suspicions. Here is the assembly output difference (from the original and recently "fixed" version of "linux/fs/xfs/xfs_fsops.c" in the linux-xfs CVS tree): "original version": sall %cl, %eax testb $32, %cl cmovne %eax, %edx cmovne %edi, %eax [no spill?!?] --> addl $2, 16(%esp) --> adcl $0, 20(%esp) [no reload!?!] shldl $9, %eax, %edx sall $9, %eax pushl %edx pushl %eax "fixed version": sall %cl, %eax testb $32, %cl cmovne %eax, %edx cmovne %ebx, %eax S-> movl %eax, 8(%esp) --> addl $2, 8(%esp) S-> movl %edx, 12(%esp) --> adcl $0, 12(%esp) pushl $8708 movl 80(%esp), %ecx sall $9, %ecx pushl %ecx R-> movl 16(%esp), %eax R-> movl 20(%esp), %edx shldl $9, %eax, %edx sall $9, %eax pushl %edx pushl %eax Note the ending code sequence to push the parameters on the stack are the same, but in the first sequence, the operations are done on memory locations that have no connection with the rest of the code. Ack. It is very reproducable and happens in all the RedHat 7.1 gcc 2.96 series compiler versions I tried: -81 (the one in the base release), -85 (the one in RedHat's update set), -88, and -99 (the most recent currently in RawHide). Personally, this problem is weird enough to kind of spook me... seems they've had busted register spill/reload logic for a while. The RawHide GCC 3.0.1 compiler I grabbed doesn't have this problem, and the rest of the code in that file appears to be correct regardless of your workaround. Same with "kgcc". Do you want me to send this to RedHat? ...or have you got as good/ better explanation to hand to them already? -- Erich Stefan Boleyn http://www.uruk.org/ "Reality is truly stranger than fiction; Probably why fiction is so popular" From owner-linux-xfs@oss.sgi.com Fri Oct 12 01:37:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9C8bTF14498 for linux-xfs-outgoing; Fri, 12 Oct 2001 01:37:29 -0700 Received: from zork.zork.net (zork.zork.net [64.81.65.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9C8bND14475 for ; Fri, 12 Oct 2001 01:37:23 -0700 Received: from sneakums by zork.zork.net with local (Exim 3.32 #1 (Debian)) id 15rxoo-0004p8-00; Fri, 12 Oct 2001 01:37:22 -0700 To: Enterprise filesystem for this millennium and the next Subject: Re: Oops on recovery with Linux-2.4.11-xfs on SPARC References: <6ulmii5wxp.fsf@zork.zork.net> <1002818079.4388.9.camel@localhost.localdomain> From: Sean Neakums X-Message-Flag: Message text advisory: SALACIOUS IMAGININGS, DISCLOSURE OF TRADE SECRET(S) X-Mailer: Norman Date: Fri, 12 Oct 2001 09:37:22 +0100 In-Reply-To: <1002818079.4388.9.camel@localhost.localdomain> (Thomas Duffy's message of "11 Oct 2001 09:34:38 -0700") Message-ID: <6uvghl45kt.fsf@zork.zork.net> Lines: 44 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk begin Thomas Duffy quotation: > On Thu, 2001-10-11 at 02:48, Sean Neakums wrote: >> I was feeling kinda adventurous and had been having excellent >> results with XFS on an IA-32 box running Debian unstable, so I >> moved a SPARC Debian unstable install over to 2.4.11 from the CVS >> tree. I built the kernel with the sparc64 cross-compiler from >> Debian's gcc-3.0-sparc64 package, version 3.0.2. > > Just so you know, sparc64 kernel is only tested and working with > 2.92.something version of the compiler. gcc 3.0.2 is untested in > it's own realm, I selected gcc-3.0-sparc64 because I mistakenly thought that the egcs64 package Debian supplies for building kernels had been replaced by gcc-3.0-sparc64. Debian's egcs64 package reports a version number of 2.92.11; what I can't seem to find is a gcc 2.95 package that will emit sparc64 code. > so you are introducing two unknowns here: 1) gcc 3.0.2 and 2) xfs on > sparc64. lets start with one and then move to the other... > that said, have you had luck with a cvs kernel from vger.samba.org > (dave miller's tree for sparc64) with gcc-3.0.2? At the moment I'm running Linus' 2.4.12 built with GCC 3.0.2, and everything seems good so far. Not that that proves anything, of course; compiler bugs are elusive at best. I have yet to try the vger tree; does it differ significantly from the mainline? > or using gcc-3.0.2 on ia32 w/ xfs? No, I've been using GCC 2.95.4 on IA-32 to build my XFS kernels. > hmm...and you are introducing cross compiling into the fray, but I > don't think that should be much of an issue. Well, the userspace on Debian SPARC is currently 32-bit, so you have to use a cross-compiler. -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Fri Oct 12 02:18:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9C9I6915383 for linux-xfs-outgoing; Fri, 12 Oct 2001 02:18:06 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9C9HxD15360 for ; Fri, 12 Oct 2001 02:17:59 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id LAA15921; Fri, 12 Oct 2001 11:17:57 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id LAA18497; Fri, 12 Oct 2001 11:17:56 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 0A2E757306; Fri, 12 Oct 2001 11:16:23 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id B368C25835; Fri, 12 Oct 2001 11:16:22 +0200 (CEST) Message-ID: <3BC6B4E6.8E4E84A8@ch.sauter-bc.com> Date: Fri, 12 Oct 2001 11:16:22 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Thomas Duffy , linux-xfs@oss.sgi.com Subject: Re: XFS on RAID 10 References: <1002857059.5390.11.camel@tduffy-lnx.afara.com> <3BC6870C.42033674@ch.sauter-bc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I just tried it again. I create two raid1 devices and build a raid0 with them. This way it is syncing both raid1 siumltaneous with ~4000k/s which is then ~23min in my situation. If I build two raid0 and then raid1 on them, I get just one sync with the minimum 100k/s and estimated 2240 minutes. So this seems to be the wrong way. -Simon Simon Matter schrieb: > > Thomas Duffy schrieb: > > > > I have setup a little (280G) xfs on RAID 10 (RAID 1 on RAID 0). This > > Some time ago I was playing with similar setup. IIRC I saw the same slow > resync speed. I then turned my RAID upside down and everything was okay. > I dont know how but since you said 'RAID 10 (RAID 1 on RAID 0)' I guess > you could just make it (RAID 0 on RAID 1) and it should be okay. In may > case sync speed was then ~10000-40000 w/o tuning. I'm interested to hear > what came out after. > > > has 8 SCSI drives (4 per card). > > > > Everything seems to work fine, expect the RAID resync craaaawwwllllsss. > > It goes at the minimum of 100k/s which should take a few months to > > finish syncing :) It sometimes bumps up to 250 k/s, but never higher > > even with no system activity. > > > > First off, does anyone know of a way to bump the sync rate up? Could > > I put this in my /etc/sysctl.conf > # Force RAID reconstruction to run with high priority > dev.raid.speed_limit_min = 5000 > > Usually you should not need this. If it does not sync fast while there > is no load on the box, something else is not good. But if you have > constant load on the box you really need the higher value than the > default (100). > > > this be some sorta weirdness between XFS and MD that is causing the slow > > resync? On a simple RAID 1 setup (2 disks) w/ XFS on the device, the > > resync is as speedy as the SCSI card allows when there is no other I/O > > which is what I would expect from MD. > > > > Other info, I am using 64k chunk sizes on both the RAID 1 and RAID 0 > > with 4k block sizes on XFS (obiviously because it on i386). These are > > 10000 rpm ultra SCSI 3 drives, so they should scream. I was able to dd > > a blank 200G file relatively fast using bs=64k on this device, so it > > seems to be ok with creating/copying files. > > > > Thanks for any help, > > > > -tduffy > From owner-linux-xfs@oss.sgi.com Fri Oct 12 03:52:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9CAq9G17477 for linux-xfs-outgoing; Fri, 12 Oct 2001 03:52:09 -0700 Received: from gk.hm.epigenomics.net (qmailr@gk.hm.epigenomics.net [212.121.137.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9CAq4D17448 for ; Fri, 12 Oct 2001 03:52:05 -0700 Received: (qmail 13607 invoked from network); 12 Oct 2001 10:52:07 -0000 Received: from raman.epigenomics.epi (qmailr@192.168.2.2) by salam.epigenomics.epi with SMTP; 12 Oct 2001 10:52:07 -0000 Received: (qmail 8505 invoked by uid 515); 12 Oct 2001 10:52:02 -0000 Date: Fri, 12 Oct 2001 12:52:02 +0200 From: Robert Sander To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.11 and large files Message-ID: <20011012125202.A8228@epigenomics.com> References: <3BC46867.3895800C@illusionary.com> <3BC48047.5959D636@illusionary.com> <20011011122630.C486887@wobbly.melbourne.sgi.com> <20011011095412.A9418@epigenomics.de> <20011012113306.A454164@wobbly.melbourne.sgi.com> <20011011233439.A28717@blenke.com> <20011012151432.B454164@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20011012151432.B454164@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.3.22i X-Operating-System: Linux raman 2.4.5-xfs-jfs-ngroups Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Oct 12, 2001 at 03:14:32PM +1100, Nathan Scott wrote: > I would suggest trying the CVS code if you can - that is now at > 2.4.13-something and there's plenty of changes in there. Maybe > this problem has been diagnosed & fixed in the base kernel - the > fact that earlier versions work OK suggests (but doesn't prove) > that the problem is coming from outside XFS. I just booted 2.4.13-pre1-xfs with both quota options enabled, and it works! I am able to create files of 4.5GB on the XFS disk. Greetings -- Robert Sander Computer Scientist Epigenomics AG Bioinformatics R&D www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Fri Oct 12 05:15:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9CCFCF19291 for linux-xfs-outgoing; Fri, 12 Oct 2001 05:15:12 -0700 Received: from haddock.cd.chalmers.se (haddock.cd.chalmers.se [129.16.79.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9CCF5D19268 for ; Fri, 12 Oct 2001 05:15:06 -0700 Received: from haddock.cd.chalmers.se (localhost [127.0.0.1]) by haddock.cd.chalmers.se (8.9.3+Sun/8.8.7) with ESMTP id OAA09889; Fri, 12 Oct 2001 14:13:34 +0200 (MET DST) Message-Id: <200110121213.OAA09889@haddock.cd.chalmers.se> X-Face: ^"+mumOlNwo;yI>`\39\txuVze?eiR9uqpo2*mE!9MWXgXI0v(3ArwymNWe'.q:eLl!=guD x{jGFEWN6,#HoN%2qRW;7.CL]9%Ap,067"u1%!NUqS.MhV'+,6$Fj-;W2Z}Y,JUZ'L+f)|B@3k3n;gLl*#i[(J-os#fNnDJ8m["|JWNwpORh|_.MGkR#|a~QS!"4hEQ{O{[Ii14{xD PU/:5wuv7m1=TK=.>G8wdfpY~]{H(Qa\1`%|Hz:!)c3f9UOW|WgE"4d\E7?oDu9. Content-Type: text/plain; charset=iso-8859-1 To: Jim Crilly cc: Sean Neakums , Linux XFS Subject: Re: Oops on recovery with Linux-2.4.11-xfs on SPARC In-Reply-To: Message from Jim Crilly of "12 Oct 2001 02:45:45 EDT." <1002869146.796.3.camel@warblade> References: <6ulmii5wxp.fsf@zork.zork.net> <200110111930.VAA25865@haddock.cd.chalmers.se> <1002869146.796.3.camel@warblade> Date: Fri, 12 Oct 2001 14:13:34 +0200 From: Anders Hammarquist Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Also on sparc64 the kernel is 64-bit but the userspace is only 32-bit, > so there's a conversion for anything passed from userspace to kernel via > ioctls. Actually, these days there is a 64-bit libc, so you can compile 64-bit userland stuff (not that there are many 64-bit binaries around). However, compiling them for 64-bit mode made no difference for xfs_repair, it still died of SIGBUS in approximately the same place. I haven't looked at any of the other userspace utilites yet (apart from mkfs). /Anders -- -- Of course I'm crazy, but that doesn't mean I'm wrong. Anders Hammarquist | iko@cd.chalmers.se Physics student, Chalmers University of Technology, | Hem: +46 31 88 48 50 G|teborg, Sweden. RADIO: SM6XMM and N2JGL | Mob: +46 707 27 86 87 From owner-linux-xfs@oss.sgi.com Fri Oct 12 05:30:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9CCUf119651 for linux-xfs-outgoing; Fri, 12 Oct 2001 05:30:41 -0700 Received: from haddock.cd.chalmers.se (haddock.cd.chalmers.se [129.16.79.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9CCU6D19625 for ; Fri, 12 Oct 2001 05:30:24 -0700 Received: from haddock.cd.chalmers.se (localhost [127.0.0.1]) by haddock.cd.chalmers.se (8.9.3+Sun/8.8.7) with ESMTP id OAA10357; Fri, 12 Oct 2001 14:28:50 +0200 (MET DST) Message-Id: <200110121228.OAA10357@haddock.cd.chalmers.se> X-Face: ^"+mumOlNwo;yI>`\39\txuVze?eiR9uqpo2*mE!9MWXgXI0v(3ArwymNWe'.q:eLl!=guD x{jGFEWN6,#HoN%2qRW;7.CL]9%Ap,067"u1%!NUqS.MhV'+,6$Fj-;W2Z}Y,JUZ'L+f)|B@3k3n;gLl*#i[(J-os#fNnDJ8m["|JWNwpORh|_.MGkR#|a~QS!"4hEQ{O{[Ii14{xD PU/:5wuv7m1=TK=.>G8wdfpY~]{H(Qa\1`%|Hz:!)c3f9UOW|WgE"4d\E7?oDu9. Content-Type: text/plain; charset=iso-8859-1 To: Keith Owens cc: Sean Neakums , Linux XFS Subject: Re: Oops on recovery with Linux-2.4.11-xfs on SPARC In-Reply-To: Message from Keith Owens of "Fri, 12 Oct 2001 10:51:04 +1000." <732.1002847864@ocs3.intra.ocs.com.au> References: <732.1002847864@ocs3.intra.ocs.com.au> Date: Fri, 12 Oct 2001 14:28:50 +0200 From: Anders Hammarquist Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > IA64 recovers from many (but not all) unaligned accesses and logs them. OK, I haven't seen any log messages on sparc64, however I have seen it oops in code that looks like it's trying to deal with an unaligned access, so it may well be that the kernel tries to deal with some of them, but that code path is broken... > XFS on IA64 definitely works in normal usage. As on sparc64 then, for some values of normal. > Having said that, XFS recovery on IA64 breaks spectacularly, to the > extent that it corrupts the file system. This seems very familiar, halfway through recovery it oopses and that filesystem dies. I can't say whether the filesystem gets corrupted or not, especially since I'm not certain that xfs_repair is healty. After xfs_repair it's mountable but I've seen it complain about in-memory corruption (though I don't remember if that was before or after I got xfs_repair to stop dumping core halfway through). > Booting from an XFS root on IA64 is giving me headaches, I'm trying > to track it down. On my machine it worked fine until it needed recovery. Incidentally, when I first tried XFS on sparc64 (CVS version from before the 1.0 release) recovery was working, so it's something that has been broken... It would probably be worthwhile to try and figure out when it broke, though I don't think I have the time to run through it now (perhaps in a few weeks though). /Anders -- -- Of course I'm crazy, but that doesn't mean I'm wrong. Anders Hammarquist | iko@cd.chalmers.se Physics student, Chalmers University of Technology, | Hem: +46 31 88 48 50 G|teborg, Sweden. RADIO: SM6XMM and N2JGL | Mob: +46 707 27 86 87 From owner-linux-xfs@oss.sgi.com Fri Oct 12 06:44:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9CDiKn21033 for linux-xfs-outgoing; Fri, 12 Oct 2001 06:44:20 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9CDi9D21010 for ; Fri, 12 Oct 2001 06:44:09 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id GAA04385 for ; Fri, 12 Oct 2001 06:43:13 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA3078025; Fri, 12 Oct 2001 08:42:52 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA66368; Fri, 12 Oct 2001 08:42:52 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9CDfF800589; Fri, 12 Oct 2001 08:41:15 -0500 Message-Id: <200110121341.f9CDfF800589@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: erich@uruk.org cc: Eric Sandeen , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: RH 7.1 gcc 2.96 bug (was Re: TAKE - work around gcc bug during xfs_growfs ) In-Reply-To: Message from erich@uruk.org of "Fri, 12 Oct 2001 00:59:04 PDT." Date: Fri, 12 Oct 2001 08:41:14 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks for the diagnosis - we need help when it comes to reading intel assembler in depth. Please pass this on to redhat. Steve > > Eric Sandeen wrote: > > > > You may want to check it against the rawhide -99 version, since you know > > > exactly what to test for. If you'd like I could try that tonight for > > > you. > > > > Sure, if you'd like to test it that would be great. I was going to > > install that compiler RPM, but it needs a new binutils which needs a > > new glibc which needs... :) > > > > Take a look at that URL for the diff I posted, and back it out. > > > > To test for the error, > ...[example creating an XFS filesystem about 1/2 the partition size, > then growing it to the full partition size]... > > If you see any errors, it didn't work. :) > > Well, I wasn't able to reproduce with your test case at all. I suspect > that maybe it's the fact that I only had a 2GB spare partition to try it > on. > > On the positive (??!?) side, I looked at the disassembly and found > what the compiler is doing wrong in the case you worked around > (ok, so you probably already know this, but I'm putting this here > so that someone can fix the bug or convince RedHat to move to > away from 2.96, maybe to 3.x). > > In the second one of the 5 cases of where you added a temporary rather > than a putting the macro in the function parameter sequence directly, > there are some operations done to what appear to be spill locations, > but the spill and reload are never performed... so it seems these > locations were allocated for spill/reload, but then wires got crossed > somewhere. > > In the "fixed" version, the exact same operations are performed > on the same stack locations, but the spill happens before and a reload > happens afterward, hence my suspicions. > > Here is the assembly output difference (from the original and recently > "fixed" version of "linux/fs/xfs/xfs_fsops.c" in the linux-xfs CVS > tree): > > "original version": > > sall %cl, %eax > testb $32, %cl > cmovne %eax, %edx > cmovne %edi, %eax > > [no spill?!?] > > --> addl $2, 16(%esp) > --> adcl $0, 20(%esp) > > [no reload!?!] > > shldl $9, %eax, %edx > sall $9, %eax > pushl %edx > pushl %eax > > > "fixed version": > > sall %cl, %eax > testb $32, %cl > cmovne %eax, %edx > cmovne %ebx, %eax > S-> movl %eax, 8(%esp) > --> addl $2, 8(%esp) > S-> movl %edx, 12(%esp) > --> adcl $0, 12(%esp) > pushl $8708 > movl 80(%esp), %ecx > sall $9, %ecx > pushl %ecx > R-> movl 16(%esp), %eax > R-> movl 20(%esp), %edx > shldl $9, %eax, %edx > sall $9, %eax > pushl %edx > pushl %eax > > > Note the ending code sequence to push the parameters on the stack > are the same, but in the first sequence, the operations are done > on memory locations that have no connection with the rest of the > code. Ack. > > It is very reproducable and happens in all the RedHat 7.1 gcc 2.96 > series compiler versions I tried: -81 (the one in the base release), > -85 (the one in RedHat's update set), -88, and -99 (the most recent > currently in RawHide). Personally, this problem is weird enough to > kind of spook me... seems they've had busted register spill/reload > logic for a while. > > The RawHide GCC 3.0.1 compiler I grabbed doesn't have this problem, > and the rest of the code in that file appears to be correct regardless > of your workaround. Same with "kgcc". > > > Do you want me to send this to RedHat? ...or have you got as good/ > better explanation to hand to them already? > > > -- > Erich Stefan Boleyn http://www.uruk.org/ > "Reality is truly stranger than fiction; Probably why fiction is so popular" From owner-linux-xfs@oss.sgi.com Fri Oct 12 08:20:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9CFKdD23069 for linux-xfs-outgoing; Fri, 12 Oct 2001 08:20:39 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9CFKYD23047 for ; Fri, 12 Oct 2001 08:20:34 -0700 Received: from ledzep.americas.sgi.com (relay.sgi.com [137.38.226.97] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA08919 for ; Fri, 12 Oct 2001 08:19:06 -0700 (PDT) mail_from (nstraz@sgi.com) Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.191.42]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA76042; Fri, 12 Oct 2001 10:19:17 -0500 (CDT) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.32 #1 (Debian)) id 15s45k-0001JF-00; Fri, 12 Oct 2001 10:19:16 -0500 Date: Fri, 12 Oct 2001 10:19:11 -0500 From: Nathan Straz To: linux-xfs@oss.sgi.com, linux-ia64@linuxia64.org Subject: SGI XFS 1.0.1-IA64 Preview Release 1 available for testing Message-ID: <20011012101911.P5692@sgi.com> Mail-Followup-To: linux-xfs@oss.sgi.com, linux-ia64@linuxia64.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.22i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The first preview release of SGI XFS 1.0.1-IA64 is available at: ftp://oss.sgi.com/projects/xfs/download/testing/Release-1.0.1-IA64-PR1/ These files are currently undergoing BETA testing. RPMS/ Kernel RPMs based on: - Linux 2.4.9 (Linus's tree) - Trillian 2.4.9-010820 - XFS 2.4.9 010826 - kdb-v1.8a-2.4.9-ia64-010820 cmd_rpms/ Command RPMs built for IA64, including lvm tools cmd_tars/ Command tarballs built for IA64. The lvm tarball is source. configs/ The config file from the kernel RPMs. Please check these over to see if anything important is missing. patches/ A patch against Linux-2.4.9-ia64-010820. Separate patches are available in the source RPM. This kernel is built with 16k pages. An installer is not available at this time. We're still working on it. -- 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 Fri Oct 12 08:27:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9CFR6e23305 for linux-xfs-outgoing; Fri, 12 Oct 2001 08:27:06 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9CFR1D23283 for ; Fri, 12 Oct 2001 08:27:02 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA01489 for ; Fri, 12 Oct 2001 08:26:05 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA3288337; Fri, 12 Oct 2001 10:25:44 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA60680; Fri, 12 Oct 2001 10:25:44 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9CFO6w05257; Fri, 12 Oct 2001 10:24:06 -0500 Message-Id: <200110121524.f9CFO6w05257@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Nathan Straz cc: linux-xfs@oss.sgi.com, linux-ia64@linuxia64.org Subject: Re: SGI XFS 1.0.1-IA64 Preview Release 1 available for testing In-Reply-To: Message from Nathan Straz of "Fri, 12 Oct 2001 10:19:11 CDT." <20011012101911.P5692@sgi.com> Date: Fri, 12 Oct 2001 10:24:06 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Nate, have you tried recovery testing - see PV 838706 from Keith Owens. Steve > The first preview release of SGI XFS 1.0.1-IA64 is available at: > > ftp://oss.sgi.com/projects/xfs/download/testing/Release-1.0.1-IA64-PR1/ > > These files are currently undergoing BETA testing. > > RPMS/ Kernel RPMs based on: > - Linux 2.4.9 (Linus's tree) > - Trillian 2.4.9-010820 > - XFS 2.4.9 010826 > - kdb-v1.8a-2.4.9-ia64-010820 > > cmd_rpms/ Command RPMs built for IA64, including lvm tools > cmd_tars/ Command tarballs built for IA64. The lvm tarball is source. > > configs/ The config file from the kernel RPMs. Please check these > over to see if anything important is missing. > > patches/ A patch against Linux-2.4.9-ia64-010820. Separate patches are > available in the source RPM. > > This kernel is built with 16k pages. > > An installer is not available at this time. We're still working on it. > > -- > 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 Fri Oct 12 09:03:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9CG3Bf24183 for linux-xfs-outgoing; Fri, 12 Oct 2001 09:03:11 -0700 Received: from zephyr.host4u.net (zephyr.host4u.net [216.71.64.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9CG38D24160 for ; Fri, 12 Oct 2001 09:03:08 -0700 Received: from imyourhandiman.com (c1347127-a.bllvu1.wa.home.com [65.4.166.51]) by zephyr.host4u.net (8.11.6/8.11.6) with ESMTP id f9CG2KP08495 for ; Fri, 12 Oct 2001 11:02:20 -0500 Message-ID: <3BC7B776.978DF709@imyourhandiman.com> Date: Fri, 12 Oct 2001 20:39:34 -0700 From: Lee Johnson X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: making modules Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi.. using Redhat 7.1 and installed XFS/redhat with the new ISO file from freshmeat.net and I seem to be having some trouble compiling my kernel when coming to "make modules"....normallly things I've done in the past that worked fine are producing errors now....is this an issue with XFS somehow that I've overlooked in the documentation if so can you point me to it....if not what is the sollution :) thx :) lee -==== From owner-linux-xfs@oss.sgi.com Fri Oct 12 09:10:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9CGANS24388 for linux-xfs-outgoing; Fri, 12 Oct 2001 09:10:23 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9CGAKD24366 for ; Fri, 12 Oct 2001 09:10:20 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9CGAEK13853 for ; Fri, 12 Oct 2001 09:10:14 -0700 Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA3195587 for ; Fri, 12 Oct 2001 11:08:59 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id LAA86371 for ; Fri, 12 Oct 2001 11:08:58 -0500 (CDT) Subject: Re: making modules From: Eric Sandeen Cc: linux-xfs@oss.sgi.com In-Reply-To: <3BC7B776.978DF709@imyourhandiman.com> References: <3BC7B776.978DF709@imyourhandiman.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 12 Oct 2001 11:08:22 -0500 Message-Id: <1002902902.1355.19.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Lee - Let me hold your email up to my forehead and guess what your specific errors are... :-) I see... unresolved symbols? Try a "make mrproper" in the tree, and start over again.... -Eric On Fri, 2001-10-12 at 22:39, Lee Johnson wrote: > hi.. > > using Redhat 7.1 and installed XFS/redhat with the new ISO file from > freshmeat.net and I seem to be having some trouble compiling my kernel > when coming to "make modules"....normallly things I've done in the past > that worked fine are producing errors now....is this an issue with XFS > somehow that I've overlooked in the documentation if so can you point me > to it....if not what is the sollution :) -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Oct 12 09:56:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9CGueG25315 for linux-xfs-outgoing; Fri, 12 Oct 2001 09:56:40 -0700 Received: from s1.uklinux.net (ns1.uklinux.net [212.1.130.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9CGuZD25293 for ; Fri, 12 Oct 2001 09:56:36 -0700 Received: from pyewacket.nic.uklinux.net (ppp-6a-207.3com.telinco.net [212.159.138.207]) by s1.uklinux.net (8.11.6/8.11.6) with ESMTP id f9CGuQ808475 for ; Fri, 12 Oct 2001 17:56:27 +0100 Envelope-To: Received: from [127.0.0.1] (helo=there) by pyewacket.nic.uklinux.net with smtp (Exim 3.22 #1) id 15s54X-0000Po-00 for linux-xfs@oss.sgi.com; Fri, 12 Oct 2001 17:22:05 +0100 Content-Type: text/plain; charset="iso-8859-1" From: nic Reply-To: nic@uklinux.net Organization: Quixotic Hackers To: linux-xfs@oss.sgi.com Subject: Re: Compilers (was Re: 2.4.11 don't work yet.) Date: Fri, 12 Oct 2001 17:22:05 +0100 X-Mailer: KMail [version 1.3.1] References: <200110111447.f9BElpZ30733@jen.americas.sgi.com> <3BC5B5EE.731353D4@sgi.com> In-Reply-To: <3BC5B5EE.731353D4@sgi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > but 2.4.11 seems to get to the > > stage between 'Mounting local filesystems' and before 'Enabling swap > > space' in rc.sysinit. OK 2.4.11 with gcc-2.96-85, kgcc and gcc 3.0.0 all exhibit this behaviour. I updated to 2.4.13-pre1 and (with gcc-2.96-85, which I always use because I'm too forgetful to edit the Makefile :-) it still does the same. 2.4.9 is fine. Now this isn't some supa-dupa weirdo non-standard machine. It's an IDE workstation/toy server with an Asus K7V motherboard. I can't seem to get the machine to drop into KDB. Pressing what I think is pause on my keyboard prints ^]]P. (I've put kdb=on in the append section. Pointers to dumb idiots guide to installing KDB and using it appreciated :-) If I comment out (!) the mount -a -t nonfs,smbfs,ncpfs line in rc.sysinit, the machine carries on past where it would have hung (albeit without var ...). If I add a line like 'action $"Echo pointless crap: " /bin/true' straight after the mount point it gets echo'd. But somewhere (either the mount itself) or one of the trivial 'rm' s that happen afterwards cause the machine to sit there quietly doing nothing, so the second swapon never gets reached. (I don't have quotacheck, quotaon, accton, .unconfigured, etc). I've read the Changes file, and everything seems to be the right version, or newer. The only thing I can think is that I've hit a stupid cvs bug and I'm not getting the right version of one of the files (Like I'm really going to check that..) since others can run and build fine. From owner-linux-xfs@oss.sgi.com Fri Oct 12 10:06:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9CH6CI25576 for linux-xfs-outgoing; Fri, 12 Oct 2001 10:06:12 -0700 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9CH69D25554 for ; Fri, 12 Oct 2001 10:06:09 -0700 Received: (qmail 5762 invoked from network); 12 Oct 2001 17:06:06 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 12 Oct 2001 17:06:05 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id B90D4300090; Sat, 13 Oct 2001 03:05:57 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 60E7298; Sat, 13 Oct 2001 03:05:57 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: nic@uklinux.net Cc: linux-xfs@oss.sgi.com Subject: Re: Compilers (was Re: 2.4.11 don't work yet.) In-reply-to: Your message of "Fri, 12 Oct 2001 17:22:05 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 13 Oct 2001 03:05:52 +1000 Message-ID: <12144.1002906352@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 12 Oct 2001 17:22:05 +0100, nic wrote: >I can't seem to get the machine to drop into KDB. Pressing what I think is >pause on my keyboard prints ^]]P. (I've put kdb=on in the append section. >Pointers to dumb idiots guide to installing KDB and using it appreciated :-) Did you compile your kernel with kdb? grep kdb_main System.map or look for the kdb v1.9 startup line, near the start, after the Memory line. From owner-linux-xfs@oss.sgi.com Fri Oct 12 10:31:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9CHVTA26036 for linux-xfs-outgoing; Fri, 12 Oct 2001 10:31:29 -0700 Received: from bogon.blenke.com (653224hfc205.tampabay.rr.com [65.32.24.205]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9CHVND26012 for ; Fri, 12 Oct 2001 10:31:24 -0700 Received: (from icblenke@localhost) by bogon.blenke.com (8.9.3/8.9.3/Debian 8.9.3-21) id NAA13156; Fri, 12 Oct 2001 13:30:30 -0400 From: "Ian C. Blenke" Date: Fri, 12 Oct 2001 13:30:30 -0400 To: Nathan Scott Cc: "Ian C. Blenke" , Robert Sander , linux-xfs@oss.sgi.com Subject: Re: 2.4.11 and large files Message-ID: <20011012133030.A13099@blenke.com> References: <3BC46867.3895800C@illusionary.com> <3BC48047.5959D636@illusionary.com> <20011011122630.C486887@wobbly.melbourne.sgi.com> <20011011095412.A9418@epigenomics.de> <20011012113306.A454164@wobbly.melbourne.sgi.com> <20011011233439.A28717@blenke.com> <20011012151432.B454164@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011012151432.B454164@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.3.18i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Oct 12, 2001 at 03:14:32PM +1100, Nathan Scott wrote: > hi, Hello, > > It doesn't fix me. I'm still broken. > > That makes some sense, at least (i.e. that switching off quota > doesn't fix the problem). Switching off quota did not fix my problem. It did work for Derek though. Oddness. > > I'm willing to give anything a try at this point... The box in question > > I would suggest trying the CVS code if you can - that is now at > 2.4.13-something and there's plenty of changes in there. Maybe > this problem has been diagnosed & fixed in the base kernel - the > fact that earlier versions work OK suggests (but doesn't prove) > that the problem is coming from outside XFS. That fixes it. The box is now running 2.4.13-pre1-xfs with no problems, and Quota (and XFS Quota) are both enabled. Another oddity, the "other" box is running 2.4.10 with an identical 40G lvm/XFS filesystem and is experiencing no problems at all. I'm still unable to create new lvm volumes and mkfs.xfs them, but the existing filesystem built under 2.4.7 is working flawlessly. I guess the question is: "should I trust it"? Or should I rsync the filesystem now to the 2.4.13-pre1 box to be safe? (remember, identical boxes) > > Oddly enough, the "rescue" 2.4.7-xfs kernel that they were built with work > > fine... one box was able to create and format a large 40G xfs volume > > yesterday with the "rescue" 2.4.7-xfs boot kernel, and I've been fighting > > with the other machine to do the same under the "normal" 2.4.10-xfs boot > > kernel. No dice. > > > > I'd suggest booting the 2.4.7-xfs kernel on both machines for now, > until this issue is resolved. As these machines aren't really "production", but more of a personal playground, I'd actually prefer to run the latest CVS snapshot. > cheers. No worries :) - Ian C. Blenke From owner-linux-xfs@oss.sgi.com Fri Oct 12 10:51:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9CHpta26693 for linux-xfs-outgoing; Fri, 12 Oct 2001 10:51:55 -0700 Received: from falka.mfa.kfki.hu (falka.mfa.kfki.hu [148.6.72.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9CHpqD26669 for ; Fri, 12 Oct 2001 10:51:53 -0700 Received: (from root@localhost) by falka.mfa.kfki.hu (8.9.3/8.9.3/Debian 8.9.3-21) id TAA23296; Fri, 12 Oct 2001 19:51:25 +0200 Received: from falka.mfa.kfki.hu (falka.mfa.kfki.hu [148.6.72.6]) by falka.mfa.kfki.hu (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id TAA23287; Fri, 12 Oct 2001 19:51:24 +0200 Date: Fri, 12 Oct 2001 19:51:23 +0200 (CEST) From: Gergely Tamas To: Subject: LVM 1.0.1-rc4 with XFS(CVS) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! Is it safe to use XFS-kernel from CVS and patch it with LVM 1.0.1-rc4 ? I've got my partitions on top of LVM (created with 1.0) and would like to try XFS. But I'm not sure if it is safe... (Just ask because as far as I can see XFS-tree uses LVM 0.9.1b6) Thanks in advance, Gergely From owner-linux-xfs@oss.sgi.com Fri Oct 12 11:31:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9CIVpX27640 for linux-xfs-outgoing; Fri, 12 Oct 2001 11:31:51 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9CIVmD27618 for ; Fri, 12 Oct 2001 11:31:48 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9CIVgW09649 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Fri, 12 Oct 2001 11:31:42 -0700 Received: from clink-eth.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id UAA3193189 for ; Fri, 12 Oct 2001 20:30:27 +0200 (CEST) mail_from (roehrich@clink-eth.americas.sgi.com) Received: (from roehrich@localhost) by clink-eth.americas.sgi.com (SGI-8.9.3/8.9.3) id NAA68640 for linux-xfs@oss.sgi.com; Fri, 12 Oct 2001 13:30:20 -0500 (CDT) Date: Fri, 12 Oct 2001 13:30:20 -0500 (CDT) From: Dean Roehrich Message-Id: <200110121830.NAA68640@clink-eth.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - cleanup the dmapi mount event in namespace.c and super.c Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Fri Oct 12 11:28:08 PDT 2001 Workarea: clink-eth.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:104709a linux/fs/super.c - 1.63 - undo any effect that the dmapi mount event had on this file. Don't carry around the dirname, and don't call the event from here. linux/fs/xfs/linux/xfs_super.c - 1.140 - If dmapi decided to fail the mount, then it was removing the VFS_DMI flag from the vfs--that's not a good thing to do if the filesystem is already mounted in other places. linux/fs/namespace.c - 1.4 - do_add_mount and do_kern_mount do not need to carry around the dirname parameter for the dmapi mount event. Now we use d_path to get the dirname. Now call the mount event from do_add_mount. From owner-linux-xfs@oss.sgi.com Fri Oct 12 12:35:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9CJZPS29008 for linux-xfs-outgoing; Fri, 12 Oct 2001 12:35:25 -0700 Received: from afara-gw.afara.com (mx1.afara.com [63.113.218.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9CJZJD28960 for ; Fri, 12 Oct 2001 12:35:20 -0700 Received: from tduffy-lnx.afara.com ([10.2.4.191]) by afara-gw.afara.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 12 Oct 2001 12:34:37 -0700 Subject: Re: XFS on RAID 10 From: Thomas Duffy To: Seth Mos Cc: linux-xfs@oss.sgi.com X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 In-Reply-To: <1002857059.5390.11.camel@tduffy-lnx.afara.com> X-OriginalArrivalTime: 12 Oct 2001 05:35:03.0192 (UTC) FILETIME=[A45E6980:01C152DF] In-Reply-To: <4.3.2.7.2.20011012073050.03147d38@pop.xs4all.nl> References: <4.3.2.7.2.20011012073050.03147d38@pop.xs4all.nl> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15.99+cvs.2001.10.09.08.08 (Preview Release) Date: 12 Oct 2001 12:34:55 -0700 Message-Id: <1002915296.7002.2.camel@tduffy-lnx.afara.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2001-10-11 at 22:34, Seth Mos wrote: > At 20:24 11-10-2001 -0700, Thomas Duffy wrote: > >I have setup a little (280G) xfs on RAID 10 (RAID 1 on RAID 0). This > >has 8 SCSI drives (4 per card). > > Hardware, software or something in the middle? all software > >Everything seems to work fine, expect the RAID resync craaaawwwllllsss. > >It goes at the minimum of 100k/s which should take a few months to > >finish syncing :) It sometimes bumps up to 250 k/s, but never higher > >even with no system activity. > > There is something about resyncing in the manpages of the raid tools IIRC. > What kernel are you using, any special options and compiled with what compiler. > IIRC there were some IO stalls fixed somewhere around 2.4.6. 2.4.11 now...will move up to 2.4.13-pre1 shortly...compiled with redhat's 2.96-85 (i think I have the minor right here)...I know this is not the "supported" compiler, but it seems to work fine. > >First off, does anyone know of a way to bump the sync rate up? Could > >this be some sorta weirdness between XFS and MD that is causing the slow > >resync? On a simple RAID 1 setup (2 disks) w/ XFS on the device, the > >resync is as speedy as the SCSI card allows when there is no other I/O > >which is what I would expect from MD. > > What version of md are you using and what scsi card is it. they are adaptec scsi cards. not sure what version of md...whatever is in the 2.4.11 kernel. -tduffy From owner-linux-xfs@oss.sgi.com Fri Oct 12 18:09:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9D19Jq02093 for linux-xfs-outgoing; Fri, 12 Oct 2001 18:09:19 -0700 Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9D197D02069 for ; Fri, 12 Oct 2001 18:09:07 -0700 Received: from brocade.com (amitc-linux [192.168.198.232]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id SAA24435 for ; Fri, 12 Oct 2001 18:09:00 -0700 (PDT) Message-ID: <3BC79572.1000308@brocade.com> Date: Fri, 12 Oct 2001 18:14:26 -0700 From: Amit D Chaudhary User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010913 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs list Subject: process hang with xfs 1.0.1 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, We run into a process hang, ps -elf shows the status as 'D'. The stack trace shows it might be xfs_read. We are running xfs 1.0.1 with a few more patches from the TAKES, see list below on powerpc linux kernel 2.4.2 by MontaVista. This is reproducable though the duration to make it happen varies, took around an hour last time and the process can vary and has included insmod and rpm. Any comments or directions are welcome. I can email the System.map or other files as required. Thanks Amit ------------------------------------------------------ ps -elf cp1:root> ps -elf F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD 100 S root 1 0 1 68 0 - 312 4a630 14:41 ? 00:00:04 init 040 S root 2 1 0 69 0 - 0 22140 14:41 ? 00:00:00 [keventd] 040 S root 3 1 0 69 0 - 0 2fe10 14:41 ? 00:00:00 [kswapd] 040 S root 4 1 0 69 0 - 0 2ff04 14:41 ? 00:00:00 [kreclaimd] 040 S root 5 1 0 69 0 - 0 3c358 14:41 ? 00:00:00 [bdflush] 040 S root 6 1 0 69 0 - 0 3c450 14:41 ? 00:00:00 [kupdate] 040 S root 7 1 0 69 0 - 0 83664 14:41 ? 00:00:00 [pagebuf_daemon] 000 S root 93 1 0 69 0 - 700 16bf0 14:41 ? 00:00:00 /bin/sh /etc/rc.d/rc 3 140 S bin 126 1 0 69 0 - 310 4a630 14:41 ? 00:00:00 /sbin/portmap 140 S root 136 1 0 69 0 - 342 4a630 14:41 ? 00:00:00 /usr/sbin/inetd 040 S root 166 1 0 69 0 - 341 4a630 14:41 ? 00:00:00 /usr/sbin/syslogd -m 0 140 S root 167 1 0 69 0 - 307 1286c 14:41 ? 00:00:00 /usr/sbin/klogd -x 000 S root 175 93 0 69 0 - 569 16bf0 14:41 ? 00:00:00 /bin/sh /etc/rc.d/rc3.d/S80fstest start 000 D root 309 175 0 69 0 - 598 26be4 14:42 ? 00:00:01 rpm -V apache-1.3.14-2 000 S root 310 175 0 69 0 - 340 42f14 14:42 ? 00:00:00 grep /lib 000 S root 311 136 1 73 0 - 520 4a630 14:45 ? 00:00:00 in.telnetd: 192.168.198.232 100 S root 312 311 1 72 0 - 743 16bf0 14:45 pts/0 00:00:00 -sh 000 R root 329 312 0 74 0 - 651 - 14:46 pts/0 00:00:00 ps -elf >> >> ps ADDR UID PID PPID STATE FLAGS NAME =============================================================================== c01bd020 0 0 0 0 0 swapper c0454000 0 1 0 1 100 init c7e02000 0 2 1 1 40 keventd c04fe000 0 3 1 1 840 kswapd c04fc000 0 4 1 1 840 kreclaimd c04fa000 0 5 1 1 40 bdflush c04f8000 0 6 1 1 40 kupdate c7e46000 0 7 1 1 840 pagebuf_daemon c778a000 0 93 1 1 0 rc c781e000 1 126 1 1 140 portmap c7fb0000 0 136 1 1 140 inetd c7f6e000 0 166 1 1 40 syslogd c7f00000 0 167 1 1 140 klogd c7358000 0 175 93 1 0 S80fstest c67b0000 0 309 175 2 0 rpm c6f7e000 0 310 175 1 0 grep c6164000 0 311 136 1 0 in.telnetd c6148000 0 312 311 1 100 sh c5efa000 0 330 312 0 100 gdbserver =============================================================================== 19 active task structs found >> bt 0xc67b0000 ===================================================================== STACK TRACE FOR TASK: 0xc67b0000 (rpm) 0 _switch_to+104 [0xc00052e0] 1 schedule+792 [0xc000f86c] 2 __lock_page+144 [0xc0026be4] 3 lock_page+32 [0xc0026c5c] 4 do_generic_file_read+628 [0xc0027524] 5 generic_file_read+64 [0xc0027920] 6 xfs_read+380 [0xc00e48dc] 7 linvfs_read+100 [0xc00e02a0] 8 sys_read+132 [0xc0036f70] 9 ret_from_syscall_1 [0xc00026b4] 10 + [0x0] ===================================================================== >> TAKE - work around gcc bug during xfs_growfs http://marc.theaimsgroup.com/?l=linux-xfs&m=100274698924296&w=2 URL: Re: Busy inodes after umount http://marc.theaimsgroup.com/?l=linux-xfs&m=99558966006128&w=2 http://marc.theaimsgroup.com/?l=linux-xfs&m=99670088622262&w=2 TAKE - fix hang with mmap writes to a full filesystem http://marc.theaimsgroup.com/?l=linux-xfs&m=100206169000709&w=2 TAKE - fix a hang in parallel copies & dbench http://marc.theaimsgroup.com/?l=linux-xfs&m=100196296016505&w=2 From owner-linux-xfs@oss.sgi.com Fri Oct 12 18:12:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9D1Cls02257 for linux-xfs-outgoing; Fri, 12 Oct 2001 18:12:47 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9D1CbD02234 for ; Fri, 12 Oct 2001 18:12:37 -0700 Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA02815 for ; Fri, 12 Oct 2001 18:12:38 -0700 (PDT) mail_from (amitc@mail.brocade.com) Received: from brocade.com (amitc-linux [192.168.198.232]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id SAA24388 for ; Fri, 12 Oct 2001 18:07:19 -0700 (PDT) Message-ID: <3BC7950E.8030807@brocade.com> Date: Fri, 12 Oct 2001 18:12:46 -0700 From: Amit D Chaudhary User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010913 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs list Subject: process hang with xfs 1.0.1 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, We run into a process hang, ps -elf shows the status as 'D'. The stack trace shows it might be xfs_read. We are running xfs 1.0.1 with a few more patches from the TAKES, see list below on powerpc linux kernel 2.4.2 by MontaVista. This is reproducable though the duration to make it happen varies, took around an hour last time and the process can vary and has included insmod and rpm. Any comments or directions are welcome. I can email the System.map or other files as required. Thanks Amit ------------------------------------------------------ ps -elf cp1:root> ps -elf F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD 100 S root 1 0 1 68 0 - 312 4a630 14:41 ? 00:00:04 init 040 S root 2 1 0 69 0 - 0 22140 14:41 ? 00:00:00 [keventd] 040 S root 3 1 0 69 0 - 0 2fe10 14:41 ? 00:00:00 [kswapd] 040 S root 4 1 0 69 0 - 0 2ff04 14:41 ? 00:00:00 [kreclaimd] 040 S root 5 1 0 69 0 - 0 3c358 14:41 ? 00:00:00 [bdflush] 040 S root 6 1 0 69 0 - 0 3c450 14:41 ? 00:00:00 [kupdate] 040 S root 7 1 0 69 0 - 0 83664 14:41 ? 00:00:00 [pagebuf_daemon] 000 S root 93 1 0 69 0 - 700 16bf0 14:41 ? 00:00:00 /bin/sh /etc/rc.d/rc 3 140 S bin 126 1 0 69 0 - 310 4a630 14:41 ? 00:00:00 /sbin/portmap 140 S root 136 1 0 69 0 - 342 4a630 14:41 ? 00:00:00 /usr/sbin/inetd 040 S root 166 1 0 69 0 - 341 4a630 14:41 ? 00:00:00 /usr/sbin/syslogd -m 0 140 S root 167 1 0 69 0 - 307 1286c 14:41 ? 00:00:00 /usr/sbin/klogd -x 000 S root 175 93 0 69 0 - 569 16bf0 14:41 ? 00:00:00 /bin/sh /etc/rc.d/rc3.d/S80fstest start 000 D root 309 175 0 69 0 - 598 26be4 14:42 ? 00:00:01 rpm -V apache-1.3.14-2 000 S root 310 175 0 69 0 - 340 42f14 14:42 ? 00:00:00 grep /lib 000 S root 311 136 1 73 0 - 520 4a630 14:45 ? 00:00:00 in.telnetd: 192.168.198.232 100 S root 312 311 1 72 0 - 743 16bf0 14:45 pts/0 00:00:00 -sh 000 R root 329 312 0 74 0 - 651 - 14:46 pts/0 00:00:00 ps -elf >> >> ps ADDR UID PID PPID STATE FLAGS NAME =============================================================================== c01bd020 0 0 0 0 0 swapper c0454000 0 1 0 1 100 init c7e02000 0 2 1 1 40 keventd c04fe000 0 3 1 1 840 kswapd c04fc000 0 4 1 1 840 kreclaimd c04fa000 0 5 1 1 40 bdflush c04f8000 0 6 1 1 40 kupdate c7e46000 0 7 1 1 840 pagebuf_daemon c778a000 0 93 1 1 0 rc c781e000 1 126 1 1 140 portmap c7fb0000 0 136 1 1 140 inetd c7f6e000 0 166 1 1 40 syslogd c7f00000 0 167 1 1 140 klogd c7358000 0 175 93 1 0 S80fstest c67b0000 0 309 175 2 0 rpm c6f7e000 0 310 175 1 0 grep c6164000 0 311 136 1 0 in.telnetd c6148000 0 312 311 1 100 sh c5efa000 0 330 312 0 100 gdbserver =============================================================================== 19 active task structs found >> bt 0xc67b0000 ===================================================================== STACK TRACE FOR TASK: 0xc67b0000 (rpm) 0 _switch_to+104 [0xc00052e0] 1 schedule+792 [0xc000f86c] 2 __lock_page+144 [0xc0026be4] 3 lock_page+32 [0xc0026c5c] 4 do_generic_file_read+628 [0xc0027524] 5 generic_file_read+64 [0xc0027920] 6 xfs_read+380 [0xc00e48dc] 7 linvfs_read+100 [0xc00e02a0] 8 sys_read+132 [0xc0036f70] 9 ret_from_syscall_1 [0xc00026b4] 10 + [0x0] ===================================================================== >> From owner-linux-xfs@oss.sgi.com Fri Oct 12 19:04:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9D24J702992 for linux-xfs-outgoing; Fri, 12 Oct 2001 19:04:19 -0700 Received: from johnson.mail.mindspring.net (johnson.mail.mindspring.net [207.69.200.177]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9D24DD02970 for ; Fri, 12 Oct 2001 19:04:13 -0700 Received: from walt400.localhost (user-uini6tj.dsl.mindspring.com [165.121.27.179]) by johnson.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id WAA05129 for ; Fri, 12 Oct 2001 22:04:12 -0400 (EDT) Received: from mindspring.com (localhost.localdomain [127.0.0.1]) by walt400.localhost (Postfix) with ESMTP id 76B44817360 for ; Fri, 12 Oct 2001 19:02:40 -0700 (PDT) Message-ID: <3BC7A0C0.9020307@mindspring.com> Date: Fri, 12 Oct 2001 19:02:40 -0700 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010914 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Patch for 2.4.12 borked? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I downloaded the cvs patch for 2.4.12 and attempted to apply it. It mostly went without a hitch, however, every now and again it would stop and not be able to find the file to patch. I used patch -p1 from within the root of where I unpacked 2.4.12 into. Is there something different I should've done? Excerpt of patch messages follows: patching file kernel/Makefile patching file linux/kernel/Makefile.in.append patching file linux/kernel/kallsyms.c can't find file to patch at input line 553522 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff -Nur /export/xfs1/snapshots/linus-tree/linux/kernel/ksyms.c ./linux/kernel/ksyms.c |--- /export/xfs1/snapshots/linus-tree/linux/kernel/ksyms.c Tue Oct 9 23:39:57 2001 |+++ ./linux/kernel/ksyms.c Wed Oct 3 16:08:38 2001 -------------------------- File to patch: kernel/ksyms.c patching file kernel/ksyms.c can't find file to patch at input line 553630 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff -Nur /export/xfs1/snapshots/linus-tree/linux/kernel/sysctl.c ./linux/kernel/sysctl.c |--- /export/xfs1/snapshots/linus-tree/linux/kernel/sysctl.c Tue Oct 9 23:39:57 2001 |+++ ./linux/kernel/sysctl.c Tue Oct 9 23:32:18 2001 -------------------------- File to patch: kernel/sysctl.c patching file kernel/sysctl.c patching file linux/lib/CVS/Entries patching file linux/lib/CVS/Repository patching file linux/lib/CVS/Root patching file linux/mm/CVS/Entries patching file linux/mm/CVS/Repository patching file linux/mm/CVS/Root can't find file to patch at input line 553715 Perhaps you used the wrong -p or --strip option? The text leading up to this was: All patches applied successfully without rejects, I just had to manually type in the filenames to be patched. Thanks, -Walt From owner-linux-xfs@oss.sgi.com Fri Oct 12 19:13:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9D2DNL03206 for linux-xfs-outgoing; Fri, 12 Oct 2001 19:13:23 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9D2DKD03184 for ; Fri, 12 Oct 2001 19:13:20 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9D2DFW02552 for ; Fri, 12 Oct 2001 19:13:15 -0700 Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id TAA33726; Fri, 12 Oct 2001 19:12:44 -0700 (PDT) Message-ID: <3BC7A256.7A23440C@sgi.com> Date: Fri, 12 Oct 2001 21:09:26 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: Walt H CC: linux-xfs@oss.sgi.com Subject: Re: Patch for 2.4.12 borked? References: <3BC7A0C0.9020307@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk It could be "borked" - I didn't test it, it's generated with an automatic script. Let me try to re-gen it... -Eric Walt H wrote: > > Hello, > > I downloaded the cvs patch for 2.4.12 and attempted to apply it. It > mostly went without a hitch, however, every now and again it would stop > and not be able to find the file to patch. I used patch -p1 from within > the root of where I unpacked 2.4.12 into. Is there something different I > should've done? -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Oct 12 19:59:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9D2xUM03850 for linux-xfs-outgoing; Fri, 12 Oct 2001 19:59:30 -0700 Received: from barry.mail.mindspring.net (barry.mail.mindspring.net [207.69.200.25]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9D2xQD03827 for ; Fri, 12 Oct 2001 19:59:26 -0700 Received: from walt400.localhost (user-uini6tj.dsl.mindspring.com [165.121.27.179]) by barry.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id WAA09652 for ; Fri, 12 Oct 2001 22:59:25 -0400 (EDT) Received: from mindspring.com (localhost.localdomain [127.0.0.1]) by walt400.localhost (Postfix) with ESMTP id 94813817360; Fri, 12 Oct 2001 19:57:53 -0700 (PDT) Message-ID: <3BC7ADB1.7000608@mindspring.com> Date: Fri, 12 Oct 2001 19:57:53 -0700 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010914 X-Accept-Language: en-us MIME-Version: 1.0 To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: Patch for 2.4.12 borked? References: <3BC7A0C0.9020307@mindspring.com> <3BC7A256.7A23440C@sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ooops... Upon further review, after viewing the patch and re-applying a couple different times, I found that by applying the patch from the parent directory with -p0 fixed it. It all applies cleanly. Not too borked I guess :) -Walt Eric Sandeen wrote: > It could be "borked" - I didn't test it, it's generated with an > automatic script. Let me try to re-gen it... > > -Eric > > Walt H wrote: > >>Hello, >> >>I downloaded the cvs patch for 2.4.12 and attempted to apply it. It >>mostly went without a hitch, however, every now and again it would stop >>and not be able to find the file to patch. I used patch -p1 from within >>the root of where I unpacked 2.4.12 into. Is there something different I >>should've done? >> > > From owner-linux-xfs@oss.sgi.com Fri Oct 12 19:59:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9D2xj503903 for linux-xfs-outgoing; Fri, 12 Oct 2001 19:59:45 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9D2xgD03881 for ; Fri, 12 Oct 2001 19:59:42 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9D2xbK05634 for ; Fri, 12 Oct 2001 19:59:37 -0700 Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id TAA58685; Fri, 12 Oct 2001 19:59:05 -0700 (PDT) Message-ID: <3BC7AD33.D5660FF0@sgi.com> Date: Fri, 12 Oct 2001 21:55:47 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: Walt H , linux-xfs@oss.sgi.com Subject: Re: Patch for 2.4.12 borked? References: <3BC7A0C0.9020307@mindspring.com> <3BC7A256.7A23440C@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Actually, it seems to work fine for me. Strange that it works for you on some files, and not on others...? You did something like this? cd /path/to/top/of/linux-2.4.12 bzcat /path/to/2.4.12-xfs-patch.bz2 | patch -p1 -Eric Eric Sandeen wrote: > > It could be "borked" - I didn't test it, it's generated with an > automatic script. Let me try to re-gen it... > > -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Oct 12 20:12:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9D3Ctg04337 for linux-xfs-outgoing; Fri, 12 Oct 2001 20:12:55 -0700 Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9D3CpD04311 for ; Fri, 12 Oct 2001 20:12:52 -0700 Received: from walt400.localhost (user-uini6tj.dsl.mindspring.com [165.121.27.179]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id XAA09220 for ; Fri, 12 Oct 2001 23:12:50 -0400 (EDT) Received: from mindspring.com (localhost.localdomain [127.0.0.1]) by walt400.localhost (Postfix) with ESMTP id EAFA0817360; Fri, 12 Oct 2001 20:11:18 -0700 (PDT) Message-ID: <3BC7B0D6.50108@mindspring.com> Date: Fri, 12 Oct 2001 20:11:18 -0700 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010914 X-Accept-Language: en-us MIME-Version: 1.0 To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: Patch for 2.4.12 borked? References: <3BC7A0C0.9020307@mindspring.com> <3BC7A256.7A23440C@sgi.com> <3BC7AD33.D5660FF0@sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Yes. Except I was patching using the xfs-cvs patch to allow future updating from CVS. That must be the difference. Not sure why, as I assume that the standard xfs patches include the stuff in cmd/ as well? Anyway, thanks for checking and sorry for the wild goose chase. I did get it patched just fine from the parent dir with -p0. Thanks again for the great FS. -Walt Eric Sandeen wrote: > Actually, it seems to work fine for me. Strange that it works for you > on some files, and not on others...? > > You did something like this? > > cd /path/to/top/of/linux-2.4.12 > bzcat /path/to/2.4.12-xfs-patch.bz2 | patch -p1 > > -Eric > > Eric Sandeen wrote: > >>It could be "borked" - I didn't test it, it's generated with an >>automatic script. Let me try to re-gen it... >> >>-Eric >> > From owner-linux-xfs@oss.sgi.com Fri Oct 12 20:59:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9D3xRx05070 for linux-xfs-outgoing; Fri, 12 Oct 2001 20:59:27 -0700 Received: from femail17.sdc1.sfba.home.com (femail17.sdc1.sfba.home.com [24.0.95.144]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9D3xHD05047 for ; Fri, 12 Oct 2001 20:59:24 -0700 Received: from cr598116-a.wlfdle1.on.wave.home.com ([24.112.74.120]) by femail17.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20011013035905.UVVS6696.femail17.sdc1.sfba.home.com@cr598116-a.wlfdle1.on.wave.home.com> for ; Fri, 12 Oct 2001 20:59:05 -0700 From: Gerald Henriksen To: linux-xfs@oss.sgi.com Subject: Re: RH 7.1 gcc 2.96 bug (was Re: TAKE - work around gcc bug during xfs_growfs ) Date: Fri, 12 Oct 2001 23:59:12 -0400 Message-ID: References: <3BC5CFE8.84FDB6FC@sgi.com> In-Reply-To: X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f9D3xPD05049 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 12 Oct 2001 00:59:04 -0700, you wrote: >On the positive (??!?) side, I looked at the disassembly and found >what the compiler is doing wrong in the case you worked around >(ok, so you probably already know this, but I'm putting this here >so that someone can fix the bug or convince RedHat to move to >away from 2.96, maybe to 3.x). Red Hat 7.2 will continue with 2.96 Red Hat will not move to gcc 3.x until they move to Red Hat 8, and only Red Hat knows when that will happen. Based on past patterns a good guess would be about 6 months from now, but only time will tell on that. From owner-linux-xfs@oss.sgi.com Sat Oct 13 00:06:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9D76Dd07494 for linux-xfs-outgoing; Sat, 13 Oct 2001 00:06:13 -0700 Received: from zion.rivenstone.net (dhcp065-024-121-117.columbus.rr.com [65.24.121.117]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9D768D07471 for ; Sat, 13 Oct 2001 00:06:08 -0700 Received: from there (gibraltar.rivenstone.net [192.168.1.1]) by zion.rivenstone.net (Postfix) with SMTP id 440D11F9C3 for ; Fri, 12 Oct 2001 22:10:24 -0400 (EDT) Content-Type: text/plain; charset="iso-8859-1" From: Joseph Fannin To: linux-xfs@oss.sgi.com Subject: gcc 2.95.4-prerelease RPMS Date: Sat, 13 Oct 2001 03:05:51 -0400 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011013021024.440D11F9C3@zion.rivenstone.net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Now that I've thrown my two bits in, I'll contribute what I can. I've been running an -xfs kernel built with the 2.95.4-prerelease compiler in Debian unstable for about a month now with no problems. Others have reported pretty much the same, but the compiler needs further testing than we few. So I've rolled some 2.95.4-prerelease rpms -- well, actually, I just converted them from .debs with alien. I've tested them on RedHat 7.1 and they seem to work fine, both in install and for building an -xfs kernel. I don't see any benefit in making new ones from scratch. Please, anyone with the opportunity, build an -xfs kernel with this instead of kgcc/egcs/gcc-2.91.66 and use it, then report how things are doing in a few weeks. There's two rpms you'll need -- gcc-2.95-2.95.4-1.011006.i386.rpm and cpp-2.95-2.95.4-1.011006.i386.rpm . Both are up at http://home.columbus.rr.com/jfannin/gcc/ . After installing it, you invoke the new compiler as gcc-2.95 . If this compiler works where 2.95.2 doesn't, it may help track down just where the problem lies with building the XFS code. At the least, it'll provide an interesting datapoint (and AMD users will get k6 and/or athlon optimizations!) It would also be interesting to see if the 2.95.3 release works. Anyone who wants to build their own compiler should just pull the source from gcc's 2.95 CVS -- this version, specifically, is dated 20010522. -- Joseph Fannin jhf@rivenstone.net "Bull in pure form is rare; there is usually some contamination by data." -- William Graves Perry Jr. From owner-linux-xfs@oss.sgi.com Sat Oct 13 06:55:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9DDtLi13087 for linux-xfs-outgoing; Sat, 13 Oct 2001 06:55:21 -0700 Received: from gk.hm.epigenomics.net (qmailr@gk.hm.epigenomics.net [212.121.137.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9DDtGD13065 for ; Sat, 13 Oct 2001 06:55:17 -0700 Received: (qmail 19441 invoked from network); 13 Oct 2001 13:55:18 -0000 Received: from raman.epigenomics.epi (qmailr@192.168.2.2) by salam.epigenomics.epi with SMTP; 13 Oct 2001 13:55:18 -0000 Received: (qmail 15933 invoked from network); 13 Oct 2001 13:55:14 -0000 Received: from broglie.epigenomics.epi (qmailr@192.168.1.5) by raman.epigenomics.epi with SMTP; 13 Oct 2001 13:55:14 -0000 Received: (qmail 30218 invoked by uid 9); 13 Oct 2001 13:55:14 -0000 From: Robert Sander Reply-To: Robert Sander X-Newsgroups: epi.ml.linux.xfs Subject: Re: process hang with xfs 1.0.1 Date: Sat, 13 Oct 2001 13:55:13 +0000 (UTC) Organization: Epigenomics AG Lines: 25 Message-ID: References: <3BC7950E.8030807@brocade.com> X-Complaints-To: usenet@epigenomics.com User-Agent: slrn/0.9.7.2 (Linux) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! Currently we see similar problems, reproducable. We run linux 2.4.5 with XFS 1.0.1 on a Dell P2550 SMP machine. Samba 2.2.1a acts as the Windows file server. The error (smbd in "D" state) occurs when creating a new directory with Windows Explorer (called "New Folder") then changing to that directory and creating another directory with the same name and then trying to move that one level up. Expected is an error message like "Directory already exists" but instead smbd hangs. And quickly other processes to that want to access the directory where the first "New Folder" was created in. Any hints? Is this XFS related? Greetings -- Robert Sander Computer Scientist Epigenomics AG Bioinformatics R&D www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Sat Oct 13 07:02:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9DE2mv13332 for linux-xfs-outgoing; Sat, 13 Oct 2001 07:02:48 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9DE2jD13310 for ; Sat, 13 Oct 2001 07:02:45 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA12339 for ; Sat, 13 Oct 2001 07:02:42 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA19272; Sat, 13 Oct 2001 07:02:12 -0700 (PDT) Message-ID: <3BC8489C.A6DBDB4F@sgi.com> Date: Sat, 13 Oct 2001 08:58:52 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: Joseph Fannin CC: linux-xfs@oss.sgi.com Subject: Re: gcc 2.95.4-prerelease RPMS References: <20011013021024.440D11F9C3@zion.rivenstone.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Joseph - can you put up a src.rpm as well, if alien can do this? I'm curious about how much this version is patched, or is it "vanilla" from gcc.gnu.org? Thanks, -Eric Joseph Fannin wrote: > So I've rolled some 2.95.4-prerelease rpms -- well, actually, I just > converted them from .debs with alien. I've tested them on RedHat 7.1 and > they seem to work fine, both in install and for building an -xfs kernel. I > don't see any benefit in making new ones from scratch. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Sat Oct 13 07:06:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9DE6dF13501 for linux-xfs-outgoing; Sat, 13 Oct 2001 07:06:39 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9DE6ZD13479 for ; Sat, 13 Oct 2001 07:06:35 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9DE6TK11079 for ; Sat, 13 Oct 2001 07:06:30 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA3277236; Sat, 13 Oct 2001 09:05:13 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA73665; Sat, 13 Oct 2001 09:05:13 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9DE3QJ01897; Sat, 13 Oct 2001 09:03:26 -0500 Message-Id: <200110131403.f9DE3QJ01897@jen.americas.sgi.com> To: Robert Sander cc: linux-xfs@oss.sgi.com Subject: Re: process hang with xfs 1.0.1 References: <3BC7950E.8030807@brocade.com> Comments: In-reply-to Robert Sander message dated "Sat, 13 Oct 2001 13:55:13 -0000." Date: Sat, 13 Oct 2001 09:03:26 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hi! > > Currently we see similar problems, reproducable. > > We run linux 2.4.5 with XFS 1.0.1 on a Dell P2550 SMP machine. > Samba 2.2.1a acts as the Windows file server. > > The error (smbd in "D" state) occurs when creating a > new directory with Windows Explorer (called "New Folder") > then changing to that directory and creating another directory > with the same name and then trying to move that one level up. > > Expected is an error message like "Directory already exists" > but instead smbd hangs. And quickly other processes to that > want to access the directory where the first "New Folder" > was created in. > > Any hints? Is this XFS related? In general I would recommend trying a newer kernel in situations like this. There are plenty of bugfixes in both the mainline kernel and the xfs code itself - we do not have the resources to backport the fixes to an earlier kernel and repackage it. There are kernel patches on the ftp site oss.sgi.com:/projects/xfs/download/patches Steve > > Greetings > -- > Robert Sander > Computer Scientist Epigenomics AG > Bioinformatics R&D www.epigenomics.com Kastanienallee 24 > +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Sat Oct 13 07:12:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9DECYP13715 for linux-xfs-outgoing; Sat, 13 Oct 2001 07:12:34 -0700 Received: from gk.hm.epigenomics.net (qmailr@gk.hm.epigenomics.net [212.121.137.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9DECUD13693 for ; Sat, 13 Oct 2001 07:12:31 -0700 Received: (qmail 19494 invoked from network); 13 Oct 2001 14:12:31 -0000 Received: from raman.epigenomics.epi (qmailr@192.168.2.2) by salam.epigenomics.epi with SMTP; 13 Oct 2001 14:12:31 -0000 Received: (qmail 1321 invoked from network); 13 Oct 2001 14:12:29 -0000 Received: from broglie.epigenomics.epi (qmailr@192.168.1.5) by raman.epigenomics.epi with SMTP; 13 Oct 2001 14:12:29 -0000 Received: (qmail 30615 invoked by uid 9); 13 Oct 2001 14:12:28 -0000 From: Robert Sander Reply-To: Robert Sander X-Newsgroups: epi.ml.linux.xfs Subject: Re: process hang with xfs 1.0.1 Date: Sat, 13 Oct 2001 14:12:27 +0000 (UTC) Organization: Epigenomics AG Lines: 18 Message-ID: References: <3BC7950E.8030807@brocade.com> <200110131403.f9DE3QJ01897@jen.americas.sgi.com> X-Complaints-To: usenet@epigenomics.com User-Agent: slrn/0.9.7.2 (Linux) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 13 Oct 2001 14:08:02 +0000 (UTC), Steve Lord wrote: > In general I would recommend trying a newer kernel in situations like > this. There are plenty of bugfixes in both the mainline kernel and > the xfs code itself - we do not have the resources to backport the > fixes to an earlier kernel and repackage it. I know, I tried 2.4.12 but the aacraid patch for the Dell RAID controller didn't work. :-( So I had to stick with 2.4.5, and XFS 1.0.1 and 2.4.5 is the official XFS release by SGI, so it should work, shouldn't it? Greetings -- Robert Sander Computer Scientist Epigenomics AG Bioinformatics R&D www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Sat Oct 13 07:30:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9DEU4S14022 for linux-xfs-outgoing; Sat, 13 Oct 2001 07:30:04 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9DETxD13988 for ; Sat, 13 Oct 2001 07:29:59 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA04957 for ; Sat, 13 Oct 2001 07:29:58 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA3087046; Sat, 13 Oct 2001 09:28:41 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA39794; Sat, 13 Oct 2001 09:28:41 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9DEQsx01980; Sat, 13 Oct 2001 09:26:54 -0500 Message-Id: <200110131426.f9DEQsx01980@jen.americas.sgi.com> To: Robert Sander cc: linux-xfs@oss.sgi.com Subject: Re: process hang with xfs 1.0.1 References: <3BC7950E.8030807@brocade.com> <200110131403.f9DE3QJ01897@jen.americas.sgi.com> Comments: In-reply-to Robert Sander message dated "Sat, 13 Oct 2001 14:12:27 -0000." Date: Sat, 13 Oct 2001 09:26:54 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Sat, 13 Oct 2001 14:08:02 +0000 (UTC), > Steve Lord wrote: > > In general I would recommend trying a newer kernel in situations like > > this. There are plenty of bugfixes in both the mainline kernel and > > the xfs code itself - we do not have the resources to backport the > > fixes to an earlier kernel and repackage it. > > I know, I tried 2.4.12 but the aacraid patch for the Dell RAID > controller didn't work. :-( So I had to stick with 2.4.5, and > XFS 1.0.1 and 2.4.5 is the official XFS release by SGI, so it should > work, shouldn't it? Well, the only things we touch in the kernel are XFS and some small changes to the mainline kernel to make the interfaces we need available to user space and some extensions in the buffer cache and vm for delayed allocation writes. Anything below the block layer, or in any device driver is purely off the shelf (from Linus's tree or from Redhat depending on the pachage). The point of us packaging a release was to make XFS available in an easier to swallow form, not to provide a complete linux distribution. The 2.4.3 kernel rpm in 1.0.1 is a modification of the redhat 7.1 kernel, the 2.4.5 kernel is a vanilla linux kernel. We are working on getting things going in the redhat 7.2 kernel (due out real soon now). This may offer a new package, I am not sure if we will be packaging things as we have done in the past yet though. The new mandrake (8.1) release also includes xfs, I cannot speak for their driver support as I have not looked and tend not to use much beyond the basics myself. Hopefully other people on the list can suggest other kernel versions which will work with your hardware. Steve > Greetings > -- > Robert Sander > Computer Scientist Epigenomics AG > Bioinformatics R&D www.epigenomics.com Kastanienallee 24 > +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Sat Oct 13 08:01:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9DF1ol14636 for linux-xfs-outgoing; Sat, 13 Oct 2001 08:01:50 -0700 Received: from gk.hm.epigenomics.net (qmailr@gk.hm.epigenomics.net [212.121.137.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9DF1lD14613 for ; Sat, 13 Oct 2001 08:01:47 -0700 Received: (qmail 19727 invoked from network); 13 Oct 2001 15:01:48 -0000 Received: from raman.epigenomics.epi (qmailr@192.168.2.2) by salam.epigenomics.epi with SMTP; 13 Oct 2001 15:01:48 -0000 Received: (qmail 11844 invoked by uid 515); 13 Oct 2001 15:01:45 -0000 Date: Sat, 13 Oct 2001 17:01:45 +0200 From: Robert Sander To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: process hang with xfs 1.0.1 Message-ID: <20011013170145.A9510@epigenomics.com> References: <3BC7950E.8030807@brocade.com> <200110131403.f9DE3QJ01897@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <200110131403.f9DE3QJ01897@jen.americas.sgi.com> User-Agent: Mutt/1.3.22i X-Operating-System: Linux raman 2.4.5-p2550-xfs-ngroups Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, Oct 13, 2001 at 09:03:26AM -0500, Steve Lord wrote: > In general I would recommend trying a newer kernel in situations like > this. There are plenty of bugfixes in both the mainline kernel and > the xfs code itself - we do not have the resources to backport the > fixes to an earlier kernel and repackage it. OK, it doesn't seem to be XFS related, as the problem also occurs on a Samba share with an underlying ext2fs. Crazy, crazy... Greetings -- Robert Sander Computer Scientist Epigenomics AG Bioinformatics R&D www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Sat Oct 13 10:58:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9DHwGV16460 for linux-xfs-outgoing; Sat, 13 Oct 2001 10:58:16 -0700 Received: from gk.hm.epigenomics.net (qmailr@gk.hm.epigenomics.net [212.121.137.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9DHwBD16434 for ; Sat, 13 Oct 2001 10:58:11 -0700 Received: (qmail 20232 invoked from network); 13 Oct 2001 17:58:11 -0000 Received: from raman.epigenomics.epi (qmailr@192.168.2.2) by salam.epigenomics.epi with SMTP; 13 Oct 2001 17:58:11 -0000 Received: (qmail 2209 invoked by uid 515); 13 Oct 2001 17:58:09 -0000 Date: Sat, 13 Oct 2001 19:58:09 +0200 From: Robert Sander To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: process hang with xfs 1.0.1 Message-ID: <20011013195809.A1617@epigenomics.com> References: <3BC7950E.8030807@brocade.com> <200110131403.f9DE3QJ01897@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <200110131403.f9DE3QJ01897@jen.americas.sgi.com> User-Agent: Mutt/1.3.22i X-Operating-System: Linux raman 2.4.7-aacraid-xfs-ngroups Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, Oct 13, 2001 at 09:03:26AM -0500, Steve Lord wrote: > > Hi! > > > > Currently we see similar problems, reproducable. > > > > We run linux 2.4.5 with XFS 1.0.1 on a Dell P2550 SMP machine. > > Samba 2.2.1a acts as the Windows file server. > > > > The error (smbd in "D" state) occurs when creating a > > new directory with Windows Explorer (called "New Folder") > > then changing to that directory and creating another directory > > with the same name and then trying to move that one level up. > > > > Expected is an error message like "Directory already exists" > > but instead smbd hangs. And quickly other processes to that > > want to access the directory where the first "New Folder" > > was created in. OK, using 2.4.12 or later was not an option because the aacraid patch for the Dell RAID controller was not working. But with 2.4.7 this particular problem went away now. Greetings -- Robert Sander Computer Scientist Epigenomics AG Bioinformatics R&D www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Sat Oct 13 11:25:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9DIPxG16976 for linux-xfs-outgoing; Sat, 13 Oct 2001 11:25:59 -0700 Received: from roujin.gargoylecc.com (mail@roujin.gargoylecc.com [65.100.85.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9DIPsD16953 for ; Sat, 13 Oct 2001 11:25:54 -0700 Received: from ringram by roujin.gargoylecc.com with local (Exim 3.32 #1) id 15sTTt-0004DT-00 for linux-xfs@oss.sgi.com; Sat, 13 Oct 2001 12:25:53 -0600 Date: Sat, 13 Oct 2001 12:25:53 -0600 To: linux-xfs@oss.sgi.com Subject: Debian journaling fs installation disks Message-ID: <20011013122553.A16200@roujin.gargoylecc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.22i From: Russel Ingram Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have finally managed to get some working debian installation disks made that allow you to install on top of xfs or reiserfs thanks to changes made in the latest boot-floppies package. I used a 2.4.7 vanilla kernel with the xfs patch added. The disk set is far from perfect but it will work as far as "Install Base System" without problems and the problems that it has past that are recoverable. The problems I encountered are as follows: 1. The "Install Base System" section of the installation exited with errors that were unrecoverable enough to disallow normal installation to proceed. I had to manually select the steps that are supposed to follow "Install Base System". 2. No fstab was written. This resulted in a system that would boot but leave the root filesystem mounted as read-only. Executing a shell from the installation program and running "nano-tiny /target/etc/fstab" to enter an fstab by hand before rebooting the new system will fix this problem. 3. The system was left with a non-functional /etc/apt/sources.list file. This will effectively make it impossible to finish installing the system past the base system. To fix this you should delete the non-functional entry in /etc/apt/sources.list and add the following: deb http://http.us.debian.org/debian woody main contrib non-free deb http://non-us.debian.org/debian-non-US woody/non-US main contrib non-free I have not had time to test the installer's ability to create filesystems of different types within the same installation yet but I have tested a completely xfs installation and a completely reiserfs installation and both work with the above caveats. You can pick the disks up at http://www.lwfug.org/debian. Enjoy! Russ -- Russel H. Ingram Gargoyle Computer Consulting (307)742-1361 or (307)760-1317 www.gargoylecc.com From owner-linux-xfs@oss.sgi.com Sat Oct 13 12:33:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9DJXkO18046 for linux-xfs-outgoing; Sat, 13 Oct 2001 12:33:46 -0700 Received: from bug.ucw.cz (cisco7500-mainGW.gts.cz [194.213.32.131]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9DJXdD18019 for ; Sat, 13 Oct 2001 12:33:40 -0700 Received: (from root@localhost) by bug.ucw.cz (8.9.3/8.8.5) id VAA05638; Sat, 13 Oct 2001 21:31:40 +0200 Date: Mon, 8 Oct 2001 16:44:37 +0000 From: Pavel Machek To: Alan Cox Cc: Mikulas Patocka , Rik van Riel , Krzysztof Rusocki , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: %u-order allocation failed Message-ID: <20011008164436.D79@toy.ucw.cz> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from alan@lxorguk.ukuu.org.uk on Sun, Oct 07, 2001 at 11:01:45PM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! > > The difference between memory and vmalloc space is this: you fill up the > > whole memory with cache => memory fragments. You don't fill up the whole > > vmalloc space with anything => vmalloc space doesn't fragment. > > vmalloc space fragments. You fragment address space rather than pages thats > all. Same problem vmalloc space tends to be empty while ram tends to be full. That might be important. Pavel -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. From owner-linux-xfs@oss.sgi.com Sat Oct 13 12:38:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9DJcS218406 for linux-xfs-outgoing; Sat, 13 Oct 2001 12:38:28 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9DJcQD18384 for ; Sat, 13 Oct 2001 12:38:26 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.6/8.11.6) id f9DJcKB26329 for linux-xfs@oss.sgi.com; Sat, 13 Oct 2001 15:38:20 -0400 Date: Sat, 13 Oct 2001 15:38:20 -0400 From: Alan Eldridge To: SGI XFS Dev List Subject: CONFIG_KDB_MODULES Message-ID: <20011013153820.A24659@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I just noticed a (relatively) new symbol in the config called CONFIG_KDB_MODULES. I didn't see anything in the archives about this beastie, and no info in the kernel tree. Can you enlighten us, Keith? -- Alan Eldridge from std_disclaimer import * From owner-linux-xfs@oss.sgi.com Sat Oct 13 13:02:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9DK2qs18832 for linux-xfs-outgoing; Sat, 13 Oct 2001 13:02:52 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9DK2oD18810 for ; Sat, 13 Oct 2001 13:02:50 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.6/8.11.6) id f9DK2i728160 for linux-xfs@oss.sgi.com; Sat, 13 Oct 2001 16:02:44 -0400 Date: Sat, 13 Oct 2001 16:02:44 -0400 From: Alan Eldridge To: SGI XFS Dev List Subject: RE: CONFIG_KDB_MODULES Message-ID: <20011013160244.A28150@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Never mind. I was looking through a slightly trashed source tree. Found it. -- Alan Eldridge from std_disclaimer import * From owner-linux-xfs@oss.sgi.com Sat Oct 13 15:16:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9DMG4520769 for linux-xfs-outgoing; Sat, 13 Oct 2001 15:16:04 -0700 Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9DMFxD20746 for ; Sat, 13 Oct 2001 15:15:59 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9DMGDau096138; Sun, 14 Oct 2001 00:16:13 +0200 (CEST) Message-Id: <4.3.2.7.2.20011014001108.03e4d150@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 14 Oct 2001 00:14:34 +0200 To: Steve Lord , Robert Sander From: Seth Mos Subject: Re: process hang with xfs 1.0.1 Cc: linux-xfs@oss.sgi.com In-Reply-To: <200110131426.f9DEQsx01980@jen.americas.sgi.com> References: <3BC7950E.8030807@brocade.com> <200110131403.f9DE3QJ01897@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 09:26 13-10-2001 -0500, Steve Lord wrote: >The 2.4.3 kernel rpm in 1.0.1 is a modification of the redhat 7.1 kernel, >the 2.4.5 kernel is a vanilla linux kernel. We are working on getting >things going in the redhat 7.2 kernel (due out real soon now). This may >offer a new package, I am not sure if we will be packaging things as we >have done in the past yet though. I have the system for another week before it needs to go into production. And then I have a week vacation to spain :-) I can stress test and run QA on it if you want to. It's dual processor it has highmem and I can make it crash a lot ;-) >The new mandrake (8.1) release also includes xfs, I cannot speak for >their driver support as I have not looked and tend not to use much >beyond the basics myself. It supports aacraid as well as most other drivers found in the redhat kernels. >Hopefully other people on the list can suggest other kernel versions which >will work with your hardware. The mandrake kernel should work fine. Fetch a tarbal of that specific release tree here. http://iserv.nl/files/xfs/ Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Sat Oct 13 16:17:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9DNHvC21801 for linux-xfs-outgoing; Sat, 13 Oct 2001 16:17:57 -0700 Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9DNHsD21779 for ; Sat, 13 Oct 2001 16:17:54 -0700 Received: from brocade.com (amitc-linux [192.168.198.232]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id QAA07294; Sat, 13 Oct 2001 16:17:15 -0700 (PDT) Message-ID: <3BC8CCBE.50903@brocade.com> Date: Sat, 13 Oct 2001 16:22:38 -0700 From: Amit D Chaudhary User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010913 X-Accept-Language: en-us MIME-Version: 1.0 To: Robert Sander CC: linux-xfs@oss.sgi.com Subject: Re: process hang with xfs 1.0.1 References: <3BC7950E.8030807@brocade.com> <200110131403.f9DE3QJ01897@jen.americas.sgi.com> <20011013195809.A1617@epigenomics.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Robert Sander wrote: > OK, using 2.4.12 or later was not an option because the aacraid > patch for the Dell RAID controller was not working. > > But with 2.4.7 this particular problem went away now. Robert, Did you use xfs 1.0.1 with kernel 2.4.7? Thanks Amit From owner-linux-xfs@oss.sgi.com Sat Oct 13 16:37:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9DNbU822148 for linux-xfs-outgoing; Sat, 13 Oct 2001 16:37:30 -0700 Received: from ctgw.lbsd.net (ctgw.lbsd.net [196.25.111.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9DNbLD22123 for ; Sat, 13 Oct 2001 16:37:22 -0700 Received: from localhost (nkukard@localhost) by ctgw.lbsd.net (8.9.3/8.8.7) with ESMTP id BAA06058 for ; Sun, 14 Oct 2001 01:37:19 +0200 Date: Sun, 14 Oct 2001 01:37:19 +0200 (SAST) From: Nigel Kukard To: linux-xfs@oss.sgi.com Subject: total/partial fs corruption Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, ok, firstly i'm NOT joking! i'm the designer of our companies linux distribution, based on vanilla source of just over 220 packages. we strongly support XFS, but one thing scares me, we running vanilla 2.4.12 (and 2.4.10) with the latest XFS patches along with the latest xfsprogs...etc. i installed our distro for the 10th time or summin yesterday and rebooted a few times, after about 3 reboots the entire / partition was blank... so i thought ok, i must of done summin wrong... so i re-installed & rebooted a few times over, SAME thing!! i then tried on another server, used a diff harddrive and totally diff hardware. rebooted about 12 times, did a halt (got a few 990 errors?), and the harddrive was BLANK! (by blank i mean when i boot with a rescue cd and mount it there is no files, no dirs nothing... blank). sum times after i find its blank i reboot again & some files are on it, sometimes not. if i run xfs_check or xfs_repair it seems to find alot of errors. but what really gets me is next to NO changes are made during a reboot & all FS's are unmounted. i thought i'd fixed the problem when i compiled 2.4.12 (from 2.4.10), but i enabled quota support & rebooted... BLANK! as i said before i have been getting error 990's and once an in-memory data corruption. i must have you know the ram is 100% ok, even tried different cpu's, ram modules, motherboards, hdd's everything. this error is 100% reproducable. how you guys can reproduce it i'm not entirely sure. i could understand it if i just turned off the pc while it was working, but this is doing a proper reboot. :( i just ran xfs_check on it now, clean after i rebooted to find the hdd blank and i get the following... hda1 = /boot, hda2 = 128Mb swap, hda3 = / [root@localhost root]# xfs_check /dev/hda3 bad directory data magic # 0x44510101 for dir ino 128 block 0 no . entry for direcotry 128 no .. entry for directory 128 block 0/220 expected type unknown got dir block 0/220 claimed by inode 131, previous inum 128 link count mismatch for inode 128 (name ?), nlink 15, counted 13 disconnected inode 132, nlink 1 link count mismatch for inode 4194432 (name ?), nlink 2, counted 1 link count mismatch for inode 4212876 (name ?), nlink 4, counted 3 . . . i would very very greatly appreciate any input as i have some very very important servers running XFS on 1Tb+ raid arrays, and i'm very scared for them! by the way, i'm running an SMP kernel on the test box which has one cpu, all the high end servers we have running XFS are dual+ cpu. could this maybe be it? Kind regards & tia Nigel Kukard -- ================================================================================ Contact Details --------------- Name: Nigel Kukard GSM Mobile: (+27) 082 564 2120 GSM Fax: (+27) 082 131 564 2120 Email: nkukard@linuxrulz.za.net Organizations ------------- - LinuxRulz Url: http://www.linuxrulz.za.net Position: Owner - Linux Based Systems Design Url: http://www.lbsd.net Position: Systems Designer, Programmer - Lando Technologies Url: http://www.lando.co.za Position: Linux Systems/Network Administrator From owner-linux-xfs@oss.sgi.com Sat Oct 13 16:47:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9DNlnT22412 for linux-xfs-outgoing; Sat, 13 Oct 2001 16:47:49 -0700 Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9DNlfD22390 for ; Sat, 13 Oct 2001 16:47:41 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9DNllau008779; Sun, 14 Oct 2001 01:47:47 +0200 (CEST) Message-Id: <4.3.2.7.2.20011014014116.0304b538@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 14 Oct 2001 01:46:13 +0200 To: Nigel Kukard , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: total/partial fs corruption In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 01:37 14-10-2001 +0200, Nigel Kukard wrote: >Hi, > >ok, firstly i'm NOT joking! > >i'm the designer of our companies linux distribution, based on vanilla source >of just over 220 packages. we strongly support XFS, but one thing scares me, >we running vanilla 2.4.12 (and 2.4.10) with the latest XFS patches along with >the latest xfsprogs...etc. Sounds good. >i installed our distro for the 10th time or summin yesterday and rebooted >a few >times, after about 3 reboots the entire / partition was blank... so i thought >ok, i must of done summin wrong... so i re-installed & rebooted a few >times over, >SAME thing!! i then tried on another server, used a diff harddrive and totally >diff hardware. rebooted about 12 times, did a halt (got a few 990 >errors?), and >the harddrive was BLANK! (by blank i mean when i boot with a rescue cd and >mount >it there is no files, no dirs nothing... blank). sum times after i find its >blank i reboot again & some files are on it, sometimes not. if i run xfs_check >or xfs_repair it seems to find alot of errors. but what really gets me is next >to NO changes are made during a reboot & all FS's are unmounted. error 990 means that it detected corruption. Something is horribly wrong in this case if it happens a lot. What compiler did you use. (Use egcs-1.1.2 == 2.91.66 for production systems) >i thought i'd fixed the problem when i compiled 2.4.12 (from 2.4.10), but i >enabled quota support & rebooted... BLANK! as i said before i have been >getting >error 990's and once an in-memory data corruption. i must have you know the >ram is 100% ok, even tried different cpu's, ram modules, motherboards, hdd's >everything. this error is 100% reproducable. how you guys can reproduce it >i'm not entirely sure. i could understand it if i just turned off the pc while >it was working, but this is doing a proper reboot. :( If it detects fs corruption the fs is disabled to prevent further corruption. This is why you don't see it. It is there to protect you from making the mess larger then it is. >i just ran xfs_check on it now, clean after i rebooted to find the hdd >blank and >i get the following... hda1 = /boot, hda2 = 128Mb swap, hda3 = / > > >[root@localhost root]# xfs_check /dev/hda3 >bad directory data magic # 0x44510101 for dir ino 128 block 0 >no . entry for direcotry 128 >no .. entry for directory 128 >block 0/220 expected type unknown got dir >block 0/220 claimed by inode 131, previous inum 128 >link count mismatch for inode 128 (name ?), nlink 15, counted 13 >disconnected inode 132, nlink 1 >link count mismatch for inode 4194432 (name ?), nlink 2, counted 1 >link count mismatch for inode 4212876 (name ?), nlink 4, counted 3 >. >. >. > > >i would very very greatly appreciate any input as i have some very very >important >servers running XFS on 1Tb+ raid arrays, and i'm very scared for them! You should not need to be since a lot of people are running XFS on production systems and are not seeing these problems. They do see the ocassional 990 with some less tested kernel releases but that's that. >by the way, i'm running an SMP kernel on the test box which has one cpu, >all the >high end servers we have running XFS are dual+ cpu. could this maybe be it? Yes, athlon systems react very badly to this and equals suicide. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Sat Oct 13 16:53:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9DNr5D22583 for linux-xfs-outgoing; Sat, 13 Oct 2001 16:53:05 -0700 Received: from ctgw.lbsd.net (ctgw.lbsd.net [196.25.111.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9DNqpD22561 for ; Sat, 13 Oct 2001 16:52:51 -0700 Received: from localhost (nkukard@localhost) by ctgw.lbsd.net (8.9.3/8.8.7) with ESMTP id BAA06104; Sun, 14 Oct 2001 01:52:43 +0200 Date: Sun, 14 Oct 2001 01:52:43 +0200 (SAST) From: Nigel Kukard To: Seth Mos cc: linux-xfs@oss.sgi.com Subject: Re: total/partial fs corruption In-Reply-To: <4.3.2.7.2.20011014014116.0304b538@pop.xs4all.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk wow, i'm impressed by the response time!!! faster than the alarm company! hehe On Sun, 14 Oct 2001, Seth Mos wrote: > At 01:37 14-10-2001 +0200, Nigel Kukard wrote: > >Hi, > > > >ok, firstly i'm NOT joking! > > > >i'm the designer of our companies linux distribution, based on vanilla source > >of just over 220 packages. we strongly support XFS, but one thing scares me, > >we running vanilla 2.4.12 (and 2.4.10) with the latest XFS patches along with > >the latest xfsprogs...etc. > > Sounds good. > yea, thats what scares me > >i installed our distro for the 10th time or summin yesterday and rebooted > >a few > >times, after about 3 reboots the entire / partition was blank... so i thought > >ok, i must of done summin wrong... so i re-installed & rebooted a few > >times over, > >SAME thing!! i then tried on another server, used a diff harddrive and totally > >diff hardware. rebooted about 12 times, did a halt (got a few 990 > >errors?), and > >the harddrive was BLANK! (by blank i mean when i boot with a rescue cd and > >mount > >it there is no files, no dirs nothing... blank). sum times after i find its > >blank i reboot again & some files are on it, sometimes not. if i run xfs_check > >or xfs_repair it seems to find alot of errors. but what really gets me is next > >to NO changes are made during a reboot & all FS's are unmounted. > > error 990 means that it detected corruption. Something is horribly wrong in > this case if it happens a lot. What compiler did you use. (Use egcs-1.1.2 > == 2.91.66 for production systems) [nkukard@devel source]$ gcc -v Reading specs from /usr/lib/gcc-lib/i586-pc-linux/2.96/specs gcc version 2.96 20000731 (IDMS Linux 2.96-5) that is basically the same "strain" of gcc that redhat use as i pulled it out their srpm a few months ago. could it really be this that is the problem? > > >i thought i'd fixed the problem when i compiled 2.4.12 (from 2.4.10), but i > >enabled quota support & rebooted... BLANK! as i said before i have been > >getting > >error 990's and once an in-memory data corruption. i must have you know the > >ram is 100% ok, even tried different cpu's, ram modules, motherboards, hdd's > >everything. this error is 100% reproducable. how you guys can reproduce it > >i'm not entirely sure. i could understand it if i just turned off the pc while > >it was working, but this is doing a proper reboot. :( > > If it detects fs corruption the fs is disabled to prevent further > corruption. This is why you don't see it. It is there to protect you from > making the mess larger then it is. > aha, anything i can do to help to find the source of the corruption? i'm not goint to touch the test box incase u guys want me to try anything out. > >i just ran xfs_check on it now, clean after i rebooted to find the hdd > >blank and > >i get the following... hda1 = /boot, hda2 = 128Mb swap, hda3 = / > > > > > >[root@localhost root]# xfs_check /dev/hda3 > >bad directory data magic # 0x44510101 for dir ino 128 block 0 > >no . entry for direcotry 128 > >no .. entry for directory 128 > >block 0/220 expected type unknown got dir > >block 0/220 claimed by inode 131, previous inum 128 > >link count mismatch for inode 128 (name ?), nlink 15, counted 13 > >disconnected inode 132, nlink 1 > >link count mismatch for inode 4194432 (name ?), nlink 2, counted 1 > >link count mismatch for inode 4212876 (name ?), nlink 4, counted 3 > >. > >. > >. > > > > > >i would very very greatly appreciate any input as i have some very very > >important > >servers running XFS on 1Tb+ raid arrays, and i'm very scared for them! > > You should not need to be since a lot of people are running XFS on > production systems and are not seeing these problems. They do see the > ocassional 990 with some less tested kernel releases but that's that. > ok, so 990 not THAT bad.... 99% chance it will happen here before i get a blank / though > >by the way, i'm running an SMP kernel on the test box which has one cpu, > >all the > >high end servers we have running XFS are dual+ cpu. could this maybe be it? > > Yes, athlon systems react very badly to this and equals suicide. > i wouldn't touch athlon even if it was free! our systems are intel based, celerly's & pIII's :) > Cheers > > -- > Seth > Every program has two purposes one for which > it was written and another for which it wasn't > I use the last kind. > -- ================================================================================ Contact Details --------------- Name: Nigel Kukard GSM Mobile: (+27) 082 564 2120 GSM Fax: (+27) 082 131 564 2120 Email: nkukard@linuxrulz.za.net Organizations ------------- - LinuxRulz Url: http://www.linuxrulz.za.net Position: Owner - Linux Based Systems Design Url: http://www.lbsd.net Position: Systems Designer, Programmer - Lando Technologies Url: http://www.lando.co.za Position: Linux Systems/Network Administrator From owner-linux-xfs@oss.sgi.com Sat Oct 13 17:38:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9E0coe23271 for linux-xfs-outgoing; Sat, 13 Oct 2001 17:38:50 -0700 Received: from zork.zork.net (zork.zork.net [64.81.65.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9E0ckD23249 for ; Sat, 13 Oct 2001 17:38:46 -0700 Received: from sneakums by zork.zork.net with local (Exim 3.32 #1 (Debian)) id 15sZIj-0006qJ-00; Sat, 13 Oct 2001 17:38:45 -0700 To: Enterprise filesystem for this millennium and the next Subject: Re: total/partial fs corruption References: From: Sean Neakums X-Message-Flag: Message text advisory: HACKING, PRURIENT SUBTEXT X-Mailer: Norman Mail-Followup-To: Enterprise filesystem for this millennium and the next Date: Sun, 14 Oct 2001 01:38:45 +0100 In-Reply-To: (Nigel Kukard's message of "Sun, 14 Oct 2001 01:52:43 +0200 (SAST)") Message-ID: <6u8zef12ei.fsf@zork.zork.net> Lines: 26 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk begin Nigel Kukard quotation: > On Sun, 14 Oct 2001, Seth Mos wrote: >> error 990 means that it detected corruption. Something is horribly >> wrong in this case if it happens a lot. What compiler did you >> use. (Use egcs-1.1.2 == 2.91.66 for production systems) > > [nkukard@devel source]$ gcc -v > Reading specs from /usr/lib/gcc-lib/i586-pc-linux/2.96/specs > gcc version 2.96 20000731 (IDMS Linux 2.96-5) > > that is basically the same "strain" of gcc that redhat use as i > pulled it out their srpm a few months ago. Try using an offical official GCC release. I've been using GCC 2.95 for a month or so with no problems. Before that I used the release of GCC suggested above by Seth. GCC 2.96 as shipped by Red Hat is an unofficial release of the GCC-3.0 CVS development branch. The ONLY grief I have had with XFS from CVS is on an untried platform with an untried compiler. GCC 2.95 on IA-32 should be trouble-free. -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Sat Oct 13 18:26:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9E1QJe23882 for linux-xfs-outgoing; Sat, 13 Oct 2001 18:26:19 -0700 Received: from reefedge.reefedge.com (IDENT:root@reefedge.com [216.10.14.212]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9E1QED23860 for ; Sat, 13 Oct 2001 18:26:15 -0700 Received: (from tls@localhost) by reefedge.reefedge.com (8.9.3/8.9.3) id VAA03192; Sat, 13 Oct 2001 21:25:50 -0400 Date: Sat, 13 Oct 2001 21:25:50 -0400 From: tls@reefedge.com To: Sean Neakums , linux-xfs@oss.sgi.com Subject: Re: total/partial fs corruption Message-ID: <20011013212550.A3160@reefedge.com> References: <6u8zef12ei.fsf@zork.zork.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <6u8zef12ei.fsf@zork.zork.net>; from sneakums@zork.net on Sun, Oct 14, 2001 at 01:38:45AM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Oct 14, 2001 at 01:38:45AM +0100, Sean Neakums wrote: > begin Nigel Kukard quotation: > > > On Sun, 14 Oct 2001, Seth Mos wrote: > >> error 990 means that it detected corruption. Something is horribly > >> wrong in this case if it happens a lot. What compiler did you > >> use. (Use egcs-1.1.2 == 2.91.66 for production systems) > > > > [nkukard@devel source]$ gcc -v > > Reading specs from /usr/lib/gcc-lib/i586-pc-linux/2.96/specs > > gcc version 2.96 20000731 (IDMS Linux 2.96-5) > > > > that is basically the same "strain" of gcc that redhat use as i > > pulled it out their srpm a few months ago. > > Try using an offical official GCC release. I've been using GCC 2.95 > for a month or so with no problems. Before that I used the release of > GCC suggested above by Seth. GCC 2.96 as shipped by Red Hat is an > unofficial release of the GCC-3.0 CVS development branch. > > The ONLY grief I have had with XFS from CVS is on an untried platform > with an untried compiler. GCC 2.95 on IA-32 should be trouble-free. Except that it's not. With gcc 2.95 and -mcpu=pentiumpro -march=pentiumpro, I have seen instructions from asm statements reordered around those generated from C by the compiler. The consequences of this in kernel code can be quite dire! Also, didn't the SGI folks just strongly advise, once again, the use of 2.91 and 2.91 *only*? Thor From owner-linux-xfs@oss.sgi.com Sat Oct 13 18:40:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9E1ebm24160 for linux-xfs-outgoing; Sat, 13 Oct 2001 18:40:37 -0700 Received: from ctgw.lbsd.net (ctgw.lbsd.net [196.25.111.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9E1eWD24138 for ; Sat, 13 Oct 2001 18:40:33 -0700 Received: from localhost (nkukard@localhost) by ctgw.lbsd.net (8.9.3/8.8.7) with ESMTP id DAA06316 for ; Sun, 14 Oct 2001 03:40:29 +0200 Date: Sun, 14 Oct 2001 03:40:29 +0200 (SAST) From: Nigel Kukard To: linux-xfs@oss.sgi.com Subject: Re: Total/Partial corruption Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hrmmm, ok, i'm currently trying with egcs & also gcc 3.0.1, if they don't work i can safely assume that the problem isn't with the compiler? Kind Regards (thanks for all the help so far!!) Nigel -- ================================================================================ Contact Details --------------- Name: Nigel Kukard GSM Mobile: (+27) 082 564 2120 GSM Fax: (+27) 082 131 564 2120 Email: nkukard@linuxrulz.za.net Organizations ------------- - LinuxRulz Url: http://www.linuxrulz.za.net Position: Owner - Linux Based Systems Design Url: http://www.lbsd.net Position: Systems Designer, Programmer - Lando Technologies Url: http://www.lando.co.za Position: Linux Systems/Network Administrator From owner-linux-xfs@oss.sgi.com Sat Oct 13 18:41:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9E1fBZ24206 for linux-xfs-outgoing; Sat, 13 Oct 2001 18:41:11 -0700 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9E1f7D24184 for ; Sat, 13 Oct 2001 18:41:07 -0700 Received: (qmail 17468 invoked from network); 14 Oct 2001 01:41:03 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 14 Oct 2001 01:41:03 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id B4B8E300090; Sun, 14 Oct 2001 11:40:53 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 7EBDC98; Sun, 14 Oct 2001 11:40:53 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Nigel Kukard Cc: linux-xfs@oss.sgi.com Subject: Re: total/partial fs corruption In-reply-to: Your message of "Sun, 14 Oct 2001 01:37:19 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Oct 2001 11:40:48 +1000 Message-ID: <26532.1003023648@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 14 Oct 2001 01:37:19 +0200 (SAST), Nigel Kukard wrote: >i thought i'd fixed the problem when i compiled 2.4.12 (from 2.4.10), but i >enabled quota support & rebooted... BLANK! as i said before i have been getting >error 990's and once an in-memory data corruption. One possibility is the corrupt partition handling in the base 2.4.12 kernel. AFAICT the bug has been there for a while but other changes in 2.4.1[12] made the bug more prevelant. It resulted in missing partitions or incorrect size data for partitions that were found. 2.4.13-pre1 is supposed to fix the bug. The XFS CVS tree is up to 2.4.13-pre1. From owner-linux-xfs@oss.sgi.com Sat Oct 13 19:11:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9E2Bt824944 for linux-xfs-outgoing; Sat, 13 Oct 2001 19:11:55 -0700 Received: from ctgw.lbsd.net (ctgw.lbsd.net [196.25.111.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9E2BnD24921 for ; Sat, 13 Oct 2001 19:11:49 -0700 Received: from localhost (nkukard@localhost) by ctgw.lbsd.net (8.9.3/8.8.7) with ESMTP id EAA06662 for ; Sun, 14 Oct 2001 04:11:46 +0200 Date: Sun, 14 Oct 2001 04:11:45 +0200 (SAST) From: Nigel Kukard To: linux-xfs@oss.sgi.com Subject: Re: Total/Partial corruption Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, just an update, i get exactly the same results if i compile with egcs or even gcc 3.0.1. :( i've looked at the partition patch, it seems to be fixing a bug for extended partitions (as far as i can see), i don't use extended partitions. hda1 - 8Mb /boot (XFS) hda2 - 128Mb swap hda3 - 19Gb / (XFS) only the 3rd partition gets corrupt, not actualy the partition, its the FS. just like it looses the first item in a linked list... *shrug* any ideas? Nigel -- ================================================================================ Contact Details --------------- Name: Nigel Kukard GSM Mobile: (+27) 082 564 2120 GSM Fax: (+27) 082 131 564 2120 Email: nkukard@linuxrulz.za.net Organizations ------------- - LinuxRulz Url: http://www.linuxrulz.za.net Position: Owner - Linux Based Systems Design Url: http://www.lbsd.net Position: Systems Designer, Programmer - Lando Technologies Url: http://www.lando.co.za Position: Linux Systems/Network Administrator From owner-linux-xfs@oss.sgi.com Sat Oct 13 20:27:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9E3R0u25837 for linux-xfs-outgoing; Sat, 13 Oct 2001 20:27:00 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9E3QuD25815 for ; Sat, 13 Oct 2001 20:26:56 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.6/8.11.6) id f9E3Qmf32729 for linux-xfs@oss.sgi.com; Sat, 13 Oct 2001 23:26:48 -0400 Date: Sat, 13 Oct 2001 23:26:31 -0400 From: Alan Eldridge To: Nigel Kukard Subject: Re: Total/Partial corruption Message-ID: <20011013232631.A32323@wwweasel.geeksrus.net> 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 nkukard@lbsd.net on Sun, Oct 14, 2001 at 04:11:45AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Oct 14, 2001 at 04:11:45AM +0200, Nigel Kukard wrote: >Hi, > >just an update, i get exactly the same results if i compile with egcs or even >gcc 3.0.1. :( i've looked at the partition patch, it seems to be fixing a bug >for extended partitions (as far as i can see), i don't use extended partitions. Are you still running an SMP kernel kernel on a uniproc box? Seth said that's a bad idea, and especially so with Athlon CPUs. Related Q: Seth, how about SMP on Athlon MP 2xSMP? Andy Kwong seems to be happy, and I'm thinking of getting the Tyan board + CPUs I've seen on special at a number of web order outlets. Have you, or anyone else, got any comments on that setup? I'm still using kgcc. BTW, with RH 8.0 I believe kgcc is history. -- Alan Eldridge from std_disclaimer import * From owner-linux-xfs@oss.sgi.com Sat Oct 13 20:29:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9E3TdO25958 for linux-xfs-outgoing; Sat, 13 Oct 2001 20:29:39 -0700 Received: from zion.rivenstone.net (dhcp065-024-121-117.columbus.rr.com [65.24.121.117]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9E3TZD25933 for ; Sat, 13 Oct 2001 20:29:35 -0700 Received: from there (gibraltar.rivenstone.net [192.168.1.1]) by zion.rivenstone.net (Postfix) with SMTP id D94EB1F9C3; Sat, 13 Oct 2001 18:33:56 -0400 (EDT) Content-Type: text/plain; charset="iso-8859-1" From: Joseph Fannin To: Eric Sandeen Subject: Re: gcc 2.95.4-prerelease RPMS Date: Sat, 13 Oct 2001 23:29:32 -0400 X-Mailer: KMail [version 1.3.2] Cc: linux-xfs@oss.sgi.com References: <20011013021024.440D11F9C3@zion.rivenstone.net> <3BC8489C.A6DBDB4F@sgi.com> In-Reply-To: <3BC8489C.A6DBDB4F@sgi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011013223356.D94EB1F9C3@zion.rivenstone.net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Saturday 13 October 2001 09:58, Eric Sandeen wrote: > Hi Joseph - can you put up a src.rpm as well, if alien can do this? I'm > curious about how much this version is patched, or is it "vanilla" from > gcc.gnu.org? > > Joseph Fannin wrote: > > So I've rolled some 2.95.4-prerelease rpms -- well, actually, I just > > converted them from .debs with alien. I've tested them on RedHat 7.1 and > > they seem to work fine, both in install and for building an -xfs kernel. > > I don't see any benefit in making new ones from scratch. Hmmm, I didn't think of that until after I went to bed last night. Thanks. No, alien can't repackage source packages. I'll look through the debian source package to see if I can find any patches. Also, I may create "real" 2.95.4-prerelease RPMS, if I think I can do it *correctly* (The 2.96 .spec file, at least, is scary -- over 100 patches!) I can certainly understand people who might not trust alien or trust rpms where they can't see the source, especially for building kernels. -- Joseph Fannin jhf@rivenstone.net "Bull in pure form is rare; there is usually some contamination by data." -- William Graves Perry Jr. From owner-linux-xfs@oss.sgi.com Sat Oct 13 20:43:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9E3hrM26232 for linux-xfs-outgoing; Sat, 13 Oct 2001 20:43:53 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9E3hmD26209 for ; Sat, 13 Oct 2001 20:43:48 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.6/8.11.6) id f9E3hhH00395 for linux-xfs@oss.sgi.com; Sat, 13 Oct 2001 23:43:43 -0400 Date: Sat, 13 Oct 2001 23:43:42 -0400 From: Alan Eldridge To: SGI XFS Dev List Subject: Linux 2.5 or now 2.6 targeted Message-ID: <20011013234342.B32323@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk A question for the guys at SGI that are working so hard on this beast: With the fundamental differences regarding implementation, in particular the invasiveness of the XFS patches, and the talk now of possibly targeting 2.6 rather than 2.5, what's the general take on (1) capitulation to the Linus and AC viewpoint about reducing the invasiveness by taking out some of the code that dupes functionality in the kernel but does it differently and (2) longevity of the XFS project in light of the industry's less than stellar financial condition as a whole? I'd certainly be bummed out serverely is the XFS project were to become a victim of the tech industry depression, mostly because I just don't feel right with ReiserFS (it's too new, and it's developers too egotistical for my taste), reports on JFS are less than stellar (I certainly wouldn't trust it for anything other than /tmp), reports on ext3 seem to indicate that it may have some, err, performance issues (well, it's a retrofit), and what does all that leave? It's XFS or 6-12+ hour boot times (or just always restore from tape) in case of a failure of power *and* UPS *and* auto-shutdown. Either way, without XFS, a triple failure means you're down for most of a day. I've got 120 Gig of disk on this box now, and it's only gonna get bigger. XFS is the only choice in a situation like that, really. And BSD doesn't really have any options for journaling that I'm aware of, so switching to BSD isn't really an option. Nor is Solaris, 'cause I know I'm not wealthy enough to buy Veritas, if it's even available for IA-32 architecture. For those of us with big disk space systems (and that group is growing), Linux + XFS is the only real game in town right now AFAIK. So, looking down the road a piece, after consulting your tarot cards, calling your personal certified psychotic adviser, or reading the latest chicken innards, what do you see? -- Alan Eldridge from std_disclaimer import * From owner-linux-xfs@oss.sgi.com Sat Oct 13 21:36:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9E4a6a26885 for linux-xfs-outgoing; Sat, 13 Oct 2001 21:36:06 -0700 Received: from monk.verbum.org (postfix@[216.185.54.61]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9E4a2D26863 for ; Sat, 13 Oct 2001 21:36:02 -0700 Received: from space-ghost.verbum.private (dhcp065-024-011-149.columbus.rr.com [65.24.11.149]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "space-ghost.verbum.org", Issuer CN "monk.verbum.org" (verified OK)) by monk.verbum.org (Postfix (Debian/GNU)) with ESMTP id 9F76474004EE for ; Sun, 14 Oct 2001 00:34:38 -0400 (EDT) Received: by space-ghost.verbum.private (Postfix (Debian/GNU), from userid 1000) id D703F90F5BF; Sun, 14 Oct 2001 00:35:33 -0400 (EDT) From: Colin Walters To: linux-xfs@oss.sgi.com Subject: Re: gcc 2.95.4-prerelease RPMS References: <20011013021024.440D11F9C3@zion.rivenstone.net> <3BC8489C.A6DBDB4F@sgi.com> <20011013223356.D94EB1F9C3@zion.rivenstone.net> X-Attribution: Colin X-Face: %'w-_>8Mj2_'=;I$myE#]G"'D>x3CY_rk,K06:mXFUvWy>;3I"BW3_-MAiUby{O(mn"wV@m dd`)Vk[27^^Sa (Joseph Fannin's message of "Sat, 13 Oct 2001 23:29:32 -0400") Message-ID: <87u1x2bzze.church.of.emacs@space-ghost.verbum.private> Lines: 21 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Joseph Fannin writes: > No, alien can't repackage source packages. I'll look through the > debian source package to see if I can find any patches. Check debian/patches. Most of them look to be architecture-dependent or for other parts of GCC like GCJ and the C++ runtime. [ from previous message ] > Both are up at http://home.columbus.rr.com/jfannin/gcc/ . After > installing it, you invoke the new compiler as gcc-2.95 . By the way, are you in Columbus then? You should come to the OSU Open Source Club meetings :) We're giving a talk on GTK+ programming on Monday, and lots more interesting things are lined up. Our home page is at: http://www.cis.ohio-state.edu/opensource From owner-linux-xfs@oss.sgi.com Sat Oct 13 22:22:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9E5Miv27527 for linux-xfs-outgoing; Sat, 13 Oct 2001 22:22:44 -0700 Received: from c1880033-a.chmpgn1.il.home.com (c1880033-a.chmpgn1.il.home.com [24.36.232.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9E5MfD27505 for ; Sat, 13 Oct 2001 22:22:41 -0700 Received: from jesse by c1880033-a.chmpgn1.il.home.com with local (Exim 3.32 #1 (Debian)) id 15sdg8-0003rT-00; Sun, 14 Oct 2001 00:19:12 -0500 Subject: Re: Total/Partial corruption From: Jesse Hall To: Alan Eldridge Cc: linux-xfs@oss.sgi.com In-Reply-To: <20011013232631.A32323@wwweasel.geeksrus.net> References: <20011013232631.A32323@wwweasel.geeksrus.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 14 Oct 2001 00:19:12 -0500 Message-Id: <1003036752.9988.22.camel@espresso> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 2001-10-13 at 22:26, Alan Eldridge wrote: > Related Q: Seth, how about SMP on Athlon MP 2xSMP? Andy Kwong seems to be > happy, and I'm thinking of getting the Tyan board + CPUs I've seen on > special at a number of web order outlets. Have you, or anyone else, got any > comments on that setup? I'm still using kgcc. BTW, with RH 8.0 I believe > kgcc is history. After updating the BIOS and the NVIDIA drivers, my dual-AthlonMP system (Tyan MB) has been rock solid and very fast for a couple months now. I'm currently running 2.4.10-xfs (haven't had the guts to try anything newer yet). I've compiled all my kernels with Debian's gcc 2.95.4, and I've got a completely XFS+LVM system except /var, which is reiserfs. Haven't had a single problem with XFS so far, and it made life before the above mentioned updates tolerable :-). Jesse Hall jdhall@uiuc.edu From owner-linux-xfs@oss.sgi.com Sat Oct 13 22:27:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9E5RX527694 for linux-xfs-outgoing; Sat, 13 Oct 2001 22:27:33 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9E5RVD27670 for ; Sat, 13 Oct 2001 22:27:31 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA28453 for ; Sat, 13 Oct 2001 22:27:27 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id PAA29162; Sun, 14 Oct 2001 15:27:25 +1000 Date: Sun, 14 Oct 2001 15:27:25 +1000 From: Keith Owens Message-Id: <200110140527.PAA29162@sherman.melbourne.sgi.com> Subject: TAKE - Sync with latest kdb Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk More use of TMPPREFIX to speed up compiles over NFS. Correct repeat count calculations in md/mds. Date: Sat Oct 13 22:24:08 PDT 2001 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:104759a linux/Makefile - 1.136 linux/kdb/kdbmain.c - 1.23 From owner-linux-xfs@oss.sgi.com Sat Oct 13 22:29:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9E5TP727797 for linux-xfs-outgoing; Sat, 13 Oct 2001 22:29:25 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9E5TND27775 for ; Sat, 13 Oct 2001 22:29:23 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA00186 for ; Sat, 13 Oct 2001 22:28:28 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id PAA29229; Sun, 14 Oct 2001 15:28:57 +1000 Date: Sun, 14 Oct 2001 15:28:57 +1000 From: Keith Owens Message-Id: <200110140528.PAA29229@sherman.melbourne.sgi.com> Subject: TAKE - Avoid oops in kdb for XFS vnode command Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Avoid oops in kdb for XFS vnode command Date: Sat Oct 13 22:26:50 PDT 2001 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:104760a linux/fs/xfs/xfsidbg.c - 1.164 From owner-linux-xfs@oss.sgi.com Sat Oct 13 23:02:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9E62lO28286 for linux-xfs-outgoing; Sat, 13 Oct 2001 23:02:47 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9E62YD28263 for ; Sat, 13 Oct 2001 23:02:34 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA03041 for ; Sat, 13 Oct 2001 23:01:03 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id QAA30178; Sun, 14 Oct 2001 16:02:31 +1000 Date: Sun, 14 Oct 2001 16:02:31 +1000 From: Keith Owens Message-Id: <200110140602.QAA30178@sherman.melbourne.sgi.com> Subject: TAKE - Upgrade XFS to 2.4.13-pre2 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Upgrade XFS to 2.4.13-pre2. Interesting that 2.4.13-pre2 contains yet another partition fix, it is not listed in Linus's changelog. Date: Sat Oct 13 22:58:26 PDT 2001 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:104761a linux/net/core/dev.c - 1.46 linux/net/ax25/ax25_ip.c - 1.8 linux/init/main.c - 1.63 linux/include/linux/wireless.h - 1.7 linux/include/linux/pci.h - 1.49 linux/include/linux/msdos_fs_sb.h - 1.8 linux/include/linux/msdos_fs.h - 1.11 linux/include/asm-sparc64/types.h - 1.5 linux/include/asm-sparc64/scatterlist.h - 1.5 linux/include/asm-sparc/scatterlist.h - 1.6 linux/include/asm-ppc/scatterlist.h - 1.5 linux/include/asm-mips/scatterlist.h - 1.3 linux/include/asm-mips/pci.h - 1.12 linux/include/asm-m68k/scatterlist.h - 1.3 linux/include/asm-i386/types.h - 1.4 linux/include/asm-i386/smp.h - 1.14 linux/include/asm-i386/scatterlist.h - 1.3 linux/include/asm-i386/page.h - 1.20 linux/include/asm-arm/scatterlist.h - 1.4 linux/include/asm-alpha/types.h - 1.4 linux/include/asm-alpha/scatterlist.h - 1.4 linux/include/asm-alpha/pci.h - 1.14 linux/include/asm-alpha/machvec.h - 1.13 linux/include/asm-alpha/core_tsunami.h - 1.13 linux/include/asm-alpha/core_mcpcia.h - 1.10 linux/include/asm-alpha/core_cia.h - 1.10 linux/include/asm-alpha/bitops.h - 1.10 linux/fs/vfat/vfatfs_syms.c - 1.5 linux/fs/vfat/namei.c - 1.20 linux/fs/open.c - 1.33 linux/fs/msdos/namei.c - 1.20 linux/fs/isofs/inode.c - 1.25 linux/fs/fat/tables.h - 1.3 linux/fs/fat/tables.c - 1.3 linux/fs/fat/msbuffer.h - 1.4 linux/fs/fat/misc.c - 1.9 linux/fs/fat/inode.c - 1.27 linux/fs/fat/fatfs_syms.c - 1.10 linux/fs/fat/dir.c - 1.13 linux/fs/fat/cache.c - 1.13 linux/fs/buffer.c - 1.85 linux/drivers/scsi/sym53c8xx_defs.h - 1.11 linux/drivers/scsi/sym53c8xx.c - 1.27 linux/drivers/scsi/st.c - 1.34 linux/drivers/scsi/sr.c - 1.29 linux/drivers/scsi/scsi_debug.c - 1.15 linux/drivers/scsi/scsi.h - 1.20 linux/drivers/scsi/qlogicfc.c - 1.23 linux/drivers/scsi/aha1542.c - 1.19 linux/drivers/pci/pci.c - 1.44 linux/drivers/net/wavelan.p.h - 1.13 linux/drivers/net/wavelan.c - 1.23 linux/drivers/net/hamradio/scc.c - 1.22 linux/drivers/net/acenic.h - 1.16 linux/drivers/net/acenic.c - 1.33 linux/drivers/char/epca.c - 1.18 linux/arch/alpha/kernel/sys_sx164.c - 1.10 linux/arch/alpha/kernel/sys_ruffian.c - 1.12 linux/arch/alpha/kernel/sys_rawhide.c - 1.12 linux/arch/alpha/kernel/sys_miata.c - 1.11 linux/arch/alpha/kernel/sys_dp264.c - 1.17 linux/arch/alpha/kernel/sys_cabriolet.c - 1.13 linux/arch/alpha/kernel/core_tsunami.c - 1.19 linux/arch/alpha/kernel/core_mcpcia.c - 1.17 linux/arch/alpha/kernel/core_cia.c - 1.20 linux/arch/alpha/kernel/alpha_ksyms.c - 1.27 linux/Makefile - 1.137 linux/fs/partitions/check.c - 1.34 linux/arch/alpha/kernel/pci_impl.h - 1.10 linux/arch/sparc64/kernel/pci_sabre.c - 1.25 linux/arch/sparc64/kernel/pci_psycho.c - 1.22 linux/arch/sparc64/kernel/pci_iommu.c - 1.12 linux/include/asm-i386/pci.h - 1.11 linux/Documentation/filesystems/udf.txt - 1.5 linux/fs/udf/inode.c - 1.23 linux/include/asm-sparc64/pci.h - 1.9 linux/include/asm-sparc/pci.h - 1.8 linux/include/asm-ppc/pci.h - 1.12 linux/drivers/net/pcmcia/ray_cs.c - 1.22 linux/drivers/net/pcmcia/netwave_cs.c - 1.16 linux/drivers/net/pcmcia/wavelan_cs.h - 1.9 linux/drivers/net/pcmcia/wavelan_cs.c - 1.11 linux/include/asm-arm/pci.h - 1.14 linux/drivers/net/sk98lin/skge.c - 1.18 linux/arch/alpha/kernel/sys_eiger.c - 1.6 linux/drivers/scsi/scsi_merge.c - 1.29 linux/drivers/scsi/scsi_lib.c - 1.35 linux/arch/sparc64/kernel/sbus.c - 1.12 linux/arch/sparc64/kernel/iommu_common.h - 1.3 linux/arch/sparc64/kernel/iommu_common.c - 1.6 linux/Documentation/DMA-mapping.txt - 1.11 linux/arch/alpha/kernel/pci_iommu.c - 1.15 linux/include/asm-ia64/scatterlist.h - 1.3 linux/include/asm-ia64/pci.h - 1.9 linux/drivers/char/nwflash.c - 1.9 linux/include/asm-mips64/scatterlist.h - 1.2 linux/include/asm-mips64/pci.h - 1.8 linux/include/asm-sh/scatterlist.h - 1.2 linux/include/asm-sh/pci.h - 1.10 linux/drivers/video/hgafb.c - 1.9 linux/drivers/scsi/sym53c8xx_comm.h - 1.9 linux/arch/alpha/kernel/core_titan.c - 1.3 linux/arch/alpha/kernel/sys_titan.c - 1.3 linux/net/ipv6/netfilter/ip6t_mac.c - 1.2 linux/include/asm-alpha/core_titan.h - 1.3 linux/include/asm-parisc/pci.h - 1.3 linux/arch/parisc/kernel/sba_iommu.c - 1.3 linux/include/asm-parisc/scatterlist.h - 1.2 linux/arch/parisc/kernel/pci-dma.c - 1.3 linux/arch/parisc/kernel/ccio-rm-dma.c - 1.2 linux/arch/parisc/kernel/ccio-dma.c - 1.3 linux/drivers/scsi/osst.c - 1.8 linux/arch/ia64/sn/io/pci_dma.c - 1.3 linux/fs/reiserfs/stree.c - 1.9 linux/fs/reiserfs/super.c - 1.8 linux/fs/reiserfs/tail_conversion.c - 1.7 linux/fs/reiserfs/prints.c - 1.5 linux/fs/reiserfs/objectid.c - 1.5 linux/fs/reiserfs/namei.c - 1.10 linux/fs/reiserfs/lbalance.c - 1.4 linux/arch/sparc64/kernel/pci_schizo.c - 1.10 linux/fs/reiserfs/journal.c - 1.10 linux/fs/reiserfs/item_ops.c - 1.4 linux/fs/reiserfs/inode.c - 1.15 linux/fs/reiserfs/ibalance.c - 1.4 linux/fs/reiserfs/hashes.c - 1.3 linux/fs/reiserfs/fix_node.c - 1.9 linux/fs/reiserfs/file.c - 1.5 linux/fs/reiserfs/do_balan.c - 1.5 linux/fs/reiserfs/dir.c - 1.7 linux/include/linux/reiserfs_fs.h - 1.10 linux/include/linux/reiserfs_fs_i.h - 1.4 linux/include/linux/reiserfs_fs_sb.h - 1.4 linux/fs/reiserfs/bitmap.c - 1.6 linux/fs/reiserfs/README - 1.2 linux/fs/reiserfs/Makefile - 1.2 linux/include/asm-s390x/scatterlist.h - 1.2 linux/include/asm-s390/scatterlist.h - 1.2 linux/drivers/net/sungem.c - 1.10 linux/drivers/char/drm/drm_proc.h - 1.2 From owner-linux-xfs@oss.sgi.com Sat Oct 13 23:14:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9E6Eta28587 for linux-xfs-outgoing; Sat, 13 Oct 2001 23:14:55 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9E6ErD28565 for ; Sat, 13 Oct 2001 23:14:53 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id XAA00489 for ; Sat, 13 Oct 2001 23:14:49 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA86851 for linux-xfs@oss.sgi.com; Sun, 14 Oct 2001 16:13:35 +1000 (EST) Date: Sun, 14 Oct 2001 16:13:35 +1000 (EST) From: Nathan Scott Message-Id: <200110140613.QAA86851@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - QA test 005 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Sat Oct 13 23:11:21 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:104762a cmd/xfstests/005.out - 1.2 - fs/namei.c::do_follow_link() has recently changed the maximum symlink link count from 8 down to 5 - changed the test output accordingly. From owner-linux-xfs@oss.sgi.com Sun Oct 14 00:29:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9E7TXD29556 for linux-xfs-outgoing; Sun, 14 Oct 2001 00:29:33 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9E7TPD29534 for ; Sun, 14 Oct 2001 00:29:25 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id AAA04094 for ; Sun, 14 Oct 2001 00:29:21 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA87709 for linux-xfs@oss.sgi.com; Sun, 14 Oct 2001 17:28:07 +1000 (EST) Date: Sun, 14 Oct 2001 17:28:07 +1000 (EST) From: Nathan Scott Message-Id: <200110140728.RAA87709@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - ioctl/EA planning Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This syncs up the zero-impact changes I have had sitting in my extended attributes workarea for awhile now. These don't change any of the existing interfaces, but do define the "new" xfsdump (by-handle) interfaces which will someday replace the existing attrctl interface. xfs_ioctl.c got a good working over, and is much healthier. While I was there, I stitched the imap code back in (was commented out), and added the imap tool in for anyone (any developer) who was looking for it. cheers. Date: Sun Oct 14 00:09:57 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/base-linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:104763a cmd/xfstests/group - 1.15 - add a group for those tests which exercise the ioctl interfaces. cmd/xfsprogs/debian/rules - 1.12 - cleanup debian bootfloppies build process so as to not rebuild stuff quite so much (we were doing lots of unnecessary work). cmd/xfsprogs/debian/changelog - 1.30 cmd/xfsprogs/doc/CHANGES - 1.40 cmd/xfsprogs/VERSION - 1.31 - bump to 1.3.10, document changes. cmd/xfsprogs/Makefile - 1.7 - add imap subdir, cleanup debian bootfloppies build process extras. cmd/xfsprogs/imap/Makefile - 1.1 cmd/xfsprogs/imap/xfs_imap.c - 1.1 - tool for dumping the inode map - dev tool only, not installed. linux/fs/xfs/xfs_itable.c - 1.101 linux/fs/xfs/xfs_itable.h - 1.34 - stitch the inumbers interface back in (was commented out) for xfs_imap. linux/fs/xfs/xfs_error.h - 1.23 - add macros for xfs_errortag_add/xfs_errortag_clearall for if we are not enabling error injection (gives ENOSYS) ... results in cleaner ioctl interface and exported headers. linux/include/linux/xfs_fs.h - 1.28 cmd/xfsprogs/include/xfs_fs.h - 1.9 - cleanup comments refering to syssgi/fcntl specifics from IRIX. add in the two new calls for EAs (basically will revert to IRIX mechanism), and add comments to the affect that attrctl interface will go away in the future. tidy io error calls - these have no need to be conditional here - should be done elsewhere (now are). linux/fs/xfs/linux/xfs_ioctl.c - 1.49 - took to this file with a mop and bucket. numerous inconsistencies in layout of the source fixed up. created a _shared_ (hello!) routine - xfs_vget_fsop_handlereq - abstracting the oft-repeated code for converting a handle to an inode, so that it is no longer cut&pasted for each command. add the two new extended attribute operations, and add comments to note that attrctl will become deprecated in the future. fix the io error code to be conditional elsewhere, so we have fewer inline cpp macros for conditional features. tidied up the xfs_ioctl routine in several ways also. linux/fs/xfs/linux/xfs_cred.h - 1.10 cmd/xfsprogs/include/xfs_cred.h - 1.3 cmd/xfsprogs/repair/attr_repair.h - 1.3 - minor reorg to fit in better with planned ea/acl interfaces. linux/fs/xfs/xfs_acl.c - 1.7 - add some definitions which are only used locally now. linux/fs/xfs/linux/xfs_linux.h - 1.56 - acl.h no longer exists, so don't include it. linux/fs/xfs/linux/acl.h - 1.4 - no longer used, removed. From owner-linux-xfs@oss.sgi.com Sun Oct 14 01:03:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9E83mr30080 for linux-xfs-outgoing; Sun, 14 Oct 2001 01:03:48 -0700 Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9E83jD30057 for ; Sun, 14 Oct 2001 01:03:45 -0700 Received: from there ([62.248.190.175]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20011014080343.SMFB18920.fep01-app.kolumbus.fi@there> for ; Sun, 14 Oct 2001 11:03:43 +0300 Content-Type: text/plain; charset="iso-8859-1" From: Hristo Grigorov To: linux-xfs@oss.sgi.com Subject: patching CVS tree Date: Sun, 14 Oct 2001 11:03:53 +0300 X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011014080343.SMFB18920.fep01-app.kolumbus.fi@there> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I want to patch the xfs CVS tree with the kernel preemptive patch. But, what happens on the next cvs update? Does it remove it automatically ? And, is it in general recommended to do that or I have to clone the CVS tree every time and do my "nasty" expreriments there ? What's your opinion on that ? -- Regards, Hristo. From owner-linux-xfs@oss.sgi.com Sun Oct 14 01:12:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9E8CNr30309 for linux-xfs-outgoing; Sun, 14 Oct 2001 01:12:23 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9E8CJD30287 for ; Sun, 14 Oct 2001 01:12:19 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.6/8.11.6) id f9E8BoO28135; Sun, 14 Oct 2001 04:11:50 -0400 Date: Sun, 14 Oct 2001 04:11:50 -0400 From: Alan Eldridge To: Chris Siebenmann Cc: SGI XFS Dev List Subject: Re: Linux 2.5 or now 2.6 targeted Message-ID: <20011014041150.A27713@wwweasel.geeksrus.net> References: <01Oct14.033426edt.62369@gpu.utcc.utoronto.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01Oct14.033426edt.62369@gpu.utcc.utoronto.ca>; from cks@utcc.utoronto.ca on Sun, Oct 14, 2001 at 03:34:25AM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Oct 14, 2001 at 03:34:25AM -0400, Chris Siebenmann wrote: >You write: >| It's XFS or 6-12+ hour boot times (or just always restore from tape) in case >| of a failure of power *and* UPS *and* auto-shutdown. Either way, without >| XFS, a triple failure means you're down for most of a day. > > Is it really that slow? Although I haven't played with fsck'ing a full >filesystem on our setup, I know that software RAID-5 resyncs ~500G in I think it (ext2) could do my 120 Gigs on 2 drives in around 3 hours. But that's still way too fscking long. ;) What's a good Linux supported ATA-100 card? > Not that I would not really love XFS in an official kernel. (That it >is not, and that it requires so much work to put into one, is the major Yup. that's the troublesome part, all right. >reason I'm not even considering it here. And I like it, since we've been >happy with it on our old SGI servers, but yoking ourselves to whatever >kernels SGI is willing to release isn't something I can go with.) I can understand that. For home use, I can do it. But I'd rather be getting it in an official kernel. If SGI blows up, or implodes, or fires Eric and Steve and Keith, then XFS is pretty much doomed. And that's not a good long term position. -- Alan Eldridge from std_disclaimer import * From owner-linux-xfs@oss.sgi.com Sun Oct 14 01:15:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9E8F0R30453 for linux-xfs-outgoing; Sun, 14 Oct 2001 01:15:00 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9E8EvD30431 for ; Sun, 14 Oct 2001 01:14:57 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.6/8.11.6) id f9E8Epr28206 for linux-xfs@oss.sgi.com; Sun, 14 Oct 2001 04:14:51 -0400 Date: Sun, 14 Oct 2001 04:14:26 -0400 From: Alan Eldridge To: Hristo Grigorov Subject: Re: patching CVS tree Message-ID: <20011014041426.B27713@wwweasel.geeksrus.net> References: <20011014080343.SMFB18920.fep01-app.kolumbus.fi@there> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011014080343.SMFB18920.fep01-app.kolumbus.fi@there>; from Hristo.Grigorov@Kolumbus.FI on Sun, Oct 14, 2001 at 11:03:53AM +0300 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Oct 14, 2001 at 11:03:53AM +0300, Hristo Grigorov wrote: >I want to patch the xfs CVS tree with the kernel preemptive patch. >But, what happens on the next cvs update? Does it remove it automatically ? Umm, what happens is that you confuse the crap out of CVS. It would be an ill-advised thing to do. >And, is it in general recommended to do that or I have to clone the CVS tree >every time and do my "nasty" expreriments there ? What's your opinion on >that ? Apply your patches each time to a separate build copy. You don't want to build out of the CVS tree, anyway. Keep it untouched so you can do 'cvs update' to just pick up the deltas. -- Alan Eldridge from std_disclaimer import * From owner-linux-xfs@oss.sgi.com Sun Oct 14 02:11:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9E9BGO31168 for linux-xfs-outgoing; Sun, 14 Oct 2001 02:11:16 -0700 Received: from ctgw.lbsd.net (ctgw.lbsd.net [196.25.111.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9E9B9D31144 for ; Sun, 14 Oct 2001 02:11:09 -0700 Received: from localhost (nkukard@localhost) by ctgw.lbsd.net (8.9.3/8.8.7) with ESMTP id LAA13701 for ; Sun, 14 Oct 2001 11:11:04 +0200 Date: Sun, 14 Oct 2001 11:11:04 +0200 (SAST) From: Nigel Kukard To: linux-xfs@oss.sgi.com Subject: Re: Total/Partial corruption In-Reply-To: <1003036752.9988.22.camel@espresso> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 14 Oct 2001, Jesse Hall wrote: > On Sat, 2001-10-13 at 22:26, Alan Eldridge wrote: > > Related Q: Seth, how about SMP on Athlon MP 2xSMP? Andy Kwong seems to be > > happy, and I'm thinking of getting the Tyan board + CPUs I've seen on > > special at a number of web order outlets. Have you, or anyone else, got any > > comments on that setup? I'm still using kgcc. BTW, with RH 8.0 I believe > > kgcc is history. > > After updating the BIOS and the NVIDIA drivers, my dual-AthlonMP system > (Tyan MB) has been rock solid and very fast for a couple months now. I'm > currently running 2.4.10-xfs (haven't had the guts to try anything newer > yet). I've compiled all my kernels with Debian's gcc 2.95.4, and I've > got a completely XFS+LVM system except /var, which is reiserfs. Haven't > had a single problem with XFS so far, and it made life before the above > mentioned updates tolerable :-). Ok, i'm going to try compile the kernel for uniproc as i haven't see any problems on our dual production servers, which leads me to think SMP might be the culprit. Nigel -- ================================================================================ Contact Details --------------- Name: Nigel Kukard GSM Mobile: (+27) 082 564 2120 GSM Fax: (+27) 082 131 564 2120 Email: nkukard@linuxrulz.za.net Organizations ------------- - LinuxRulz Url: http://www.linuxrulz.za.net Position: Owner - Linux Based Systems Design Url: http://www.lbsd.net Position: Systems Designer, Programmer - Lando Technologies Url: http://www.lando.co.za Position: Linux Systems/Network Administrator From owner-linux-xfs@oss.sgi.com Sun Oct 14 03:40:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9EAeX732401 for linux-xfs-outgoing; Sun, 14 Oct 2001 03:40:33 -0700 Received: from ente.berdmann.de (frnk-d514e186.dsl.mediaWays.net [213.20.225.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9EAeUD32379 for ; Sun, 14 Oct 2001 03:40:30 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 15sigx-0006D7-00 for linux-xfs@oss.sgi.com; Sun, 14 Oct 2001 12:40:23 +0200 Message-ID: <3BC96B97.A2270286@berdmann.de> Date: Sun, 14 Oct 2001 12:40:23 +0200 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.13-pre1-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Linux XFS Mailing List Subject: Re: acl.h (was: TAKE - Upgrade XFS to 2.4.13-pre2) References: <200110140602.QAA30178@sherman.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Upgrade XFS to 2.4.13-pre2. What has happened to linux/acl.h? make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/fs' gcc -D__KERNEL__ -I/usr/src/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -march=i586 -I xfs -c -o noposix_acl.o noposix_acl.c noposix_acl.c:39: linux/acl.h: No such file or directory make[2]: *** [noposix_acl.o] Error 1 make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs' make[1]: *** [first_rule] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs' make: *** [_dir_fs] Error 2 From owner-linux-xfs@oss.sgi.com Sun Oct 14 04:01:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9EB1H100323 for linux-xfs-outgoing; Sun, 14 Oct 2001 04:01:17 -0700 Received: from ente.berdmann.de (frnk-d514e186.dsl.mediaWays.net [213.20.225.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9EB1CD00301 for ; Sun, 14 Oct 2001 04:01:12 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 15sj0z-0006Kb-00; Sun, 14 Oct 2001 13:01:05 +0200 Message-ID: <3BC97070.5CADD56E@berdmann.de> Date: Sun, 14 Oct 2001 13:01:04 +0200 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.13-pre1-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Timothy Shimmin CC: linux-xfs@oss.sgi.com Subject: Re: TAKE - xfsdump/restore changes for ia64 References: <200109280950.TAA36050@snort.melbourne.sgi.com> <3BB5ED09.FAF43F6E@berdmann.de> <20011001002809.I10761@boing.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Timothy Shimmin wrote: > > Damn. > I tested this on ia32, found the problem and made the change > but forgot to copy it back to my ia64 workarea. Hi, I'm still not able to compile xfsdump on my RH 6.1/6.2 boxes: [root@apollo xfsdump]# ./Makepkgs rpm == clean, log is Logs/clean == configure, log is Logs/configure == default, log is Logs/default "make default" failed, see log in Logs/default gcc -O1 -g -DDEBUG -funsigned-char -Wall -DDUMP -DRMT -DBASED -DDOSOCKS -DINVCONVFIX -DSIZEEST -DPIPEINVFIX -DEXTATTR -DDMEXTATTR -I/usr/include/xfs -I/usr/include/attr '-DVERSION="1.1.6"' -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 -I/usr/include/xfs -I/usr/include/attr -c drive_simple.c -o drive_simple.o gcc -O1 -g -DDEBUG -funsigned-char -Wall -DDUMP -DRMT -DBASED -DDOSOCKS -DINVCONVFIX -DSIZEEST -DPIPEINVFIX -DEXTATTR -DDMEXTATTR -I/usr/include/xfs -I/usr/include/attr '-DVERSION="1.1.6"' -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 -I/usr/include/xfs -I/usr/include/attr -c drive_minrmt.c -o drive_minrmt.o gcc -O1 -g -DDEBUG -funsigned-char -Wall -DDUMP -DRMT -DBASED -DDOSOCKS -DINVCONVFIX -DSIZEEST -DPIPEINVFIX -DEXTATTR -DDMEXTATTR -I/usr/include/xfs -I/usr/include/attr '-DVERSION="1.1.6"' -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 -I/usr/include/xfs -I/usr/include/attr -c fs.c -o fs.o gcc -O1 -g -DDEBUG -funsigned-char -Wall -DDUMP -DRMT -DBASED -DDOSOCKS -DINVCONVFIX -DSIZEEST -DPIPEINVFIX -DEXTATTR -DDMEXTATTR -I/usr/include/xfs -I/usr/include/attr '-DVERSION="1.1.6"' -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 -I/usr/include/xfs -I/usr/include/attr -c getdents.c -o getdents.o getdents.c: In function `getdents_wrap': getdents.c:152: `SYS_getdents64' undeclared (first use in this function) getdents.c:152: (Each undeclared identifier is reported only once getdents.c:152: for each function it appears in.) make[1]: *** [getdents.o] Error 1 make: *** [default] Error 2 From owner-linux-xfs@oss.sgi.com Sun Oct 14 04:29:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9EBTnG05900 for linux-xfs-outgoing; Sun, 14 Oct 2001 04:29:49 -0700 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9EBTiD05878 for ; Sun, 14 Oct 2001 04:29:45 -0700 Received: (qmail 20598 invoked from network); 14 Oct 2001 11:29:40 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 14 Oct 2001 11:29:40 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 59F35300090; Sun, 14 Oct 2001 21:29:38 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 4809498; Sun, 14 Oct 2001 21:29:38 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: "Bernhard R. Erdmann" Cc: Linux XFS Mailing List Subject: Re: acl.h (was: TAKE - Upgrade XFS to 2.4.13-pre2) In-reply-to: Your message of "Sun, 14 Oct 2001 12:40:23 +0200." <3BC96B97.A2270286@berdmann.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Oct 2001 21:29:33 +1000 Message-ID: <1610.1003058973@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 14 Oct 2001 12:40:23 +0200, "Bernhard R. Erdmann" wrote: >> Upgrade XFS to 2.4.13-pre2. > >What has happened to linux/acl.h? Nathan Scott removed acl.h as part of another change, unrelated to 2.4.13-pre2. I will let Nathan chase up the obsolete reference. Try removing include/acl.h from any files that fail to compile. From owner-linux-xfs@oss.sgi.com Sun Oct 14 04:30:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9EBUpk05965 for linux-xfs-outgoing; Sun, 14 Oct 2001 04:30:51 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9EBUeD05926 for ; Sun, 14 Oct 2001 04:30:40 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id EAA03609 for ; Sun, 14 Oct 2001 04:29:18 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id GAA3302871; Sun, 14 Oct 2001 06:29:23 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id GAA73223; Sun, 14 Oct 2001 06:29:23 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9EBRRn09685; Sun, 14 Oct 2001 06:27:27 -0500 Message-Id: <200110141127.f9EBRRn09685@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Nigel Kukard cc: linux-xfs@oss.sgi.com Subject: Re: total/partial fs corruption In-Reply-To: Message from Nigel Kukard of "Sun, 14 Oct 2001 01:37:19 +0200." Date: Sun, 14 Oct 2001 06:27:27 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk There was some wierd stuff in this kernel range, people lost partitions from their partition table, and turning on xfs quota broke some binary disk access (we never did understand why). These problems appear to go away in 2.4.13-pre1 (we are now at pre2 I see). Can you try this and report back? Thanks Steve > Hi, > > ok, firstly i'm NOT joking! > > i'm the designer of our companies linux distribution, based on vanilla source > of just over 220 packages. we strongly support XFS, but one thing scares me, > we running vanilla 2.4.12 (and 2.4.10) with the latest XFS patches along with > the latest xfsprogs...etc. > > i installed our distro for the 10th time or summin yesterday and rebooted a f > ew > times, after about 3 reboots the entire / partition was blank... so i thought > ok, i must of done summin wrong... so i re-installed & rebooted a few times o > ver, > SAME thing!! i then tried on another server, used a diff harddrive and totall > y > diff hardware. rebooted about 12 times, did a halt (got a few 990 errors?), > and > the harddrive was BLANK! (by blank i mean when i boot with a rescue cd and mo > unt > it there is no files, no dirs nothing... blank). sum times after i find its > blank i reboot again & some files are on it, sometimes not. if i run xfs_chec > k > or xfs_repair it seems to find alot of errors. but what really gets me is nex > t > to NO changes are made during a reboot & all FS's are unmounted. > > i thought i'd fixed the problem when i compiled 2.4.12 (from 2.4.10), but i > enabled quota support & rebooted... BLANK! as i said before i have been getti > ng > error 990's and once an in-memory data corruption. i must have you know the > ram is 100% ok, even tried different cpu's, ram modules, motherboards, hdd's > everything. this error is 100% reproducable. how you guys can reproduce it > i'm not entirely sure. i could understand it if i just turned off the pc whil > e > it was working, but this is doing a proper reboot. :( > > i just ran xfs_check on it now, clean after i rebooted to find the hdd blank > and > i get the following... hda1 = /boot, hda2 = 128Mb swap, hda3 = / > > > [root@localhost root]# xfs_check /dev/hda3 > bad directory data magic # 0x44510101 for dir ino 128 block 0 > no . entry for direcotry 128 > no .. entry for directory 128 > block 0/220 expected type unknown got dir > block 0/220 claimed by inode 131, previous inum 128 > link count mismatch for inode 128 (name ?), nlink 15, counted 13 > disconnected inode 132, nlink 1 > link count mismatch for inode 4194432 (name ?), nlink 2, counted 1 > link count mismatch for inode 4212876 (name ?), nlink 4, counted 3 > . > . > . > > > i would very very greatly appreciate any input as i have some very very impor > tant > servers running XFS on 1Tb+ raid arrays, and i'm very scared for them! > > by the way, i'm running an SMP kernel on the test box which has one cpu, all > the > high end servers we have running XFS are dual+ cpu. could this maybe be it? > > > > Kind regards & tia > Nigel Kukard > -- > > > ============================================================================= > === > > Contact Details > --------------- > Name: Nigel Kukard > GSM Mobile: (+27) 082 564 2120 > GSM Fax: (+27) 082 131 564 2120 > Email: nkukard@linuxrulz.za.net > > Organizations > ------------- > - LinuxRulz > Url: http://www.linuxrulz.za.net > Position: Owner > - Linux Based Systems Design > Url: http://www.lbsd.net > Position: Systems Designer, Programmer > - Lando Technologies > Url: http://www.lando.co.za > Position: Linux Systems/Network Administrator From owner-linux-xfs@oss.sgi.com Sun Oct 14 04:43:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9EBhZp06319 for linux-xfs-outgoing; Sun, 14 Oct 2001 04:43:35 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9EBhWD06292 for ; Sun, 14 Oct 2001 04:43:32 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id EAA15702 for ; Sun, 14 Oct 2001 04:43:29 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id GAA3168639; Sun, 14 Oct 2001 06:42:15 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id GAA08028; Sun, 14 Oct 2001 06:42:15 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9EBeJt15227; Sun, 14 Oct 2001 06:40:19 -0500 Message-Id: <200110141140.f9EBeJt15227@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Alan Eldridge cc: SGI XFS Dev List Subject: Re: Linux 2.5 or now 2.6 targeted In-Reply-To: Message from Alan Eldridge of "Sat, 13 Oct 2001 23:43:42 EDT." <20011013234342.B32323@wwweasel.geeksrus.net> Date: Sun, 14 Oct 2001 06:40:19 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > A question for the guys at SGI that are working so hard on this beast: > With the fundamental differences regarding implementation, in particular the > invasiveness of the XFS patches, and the talk now of possibly targeting 2.6 > rather than 2.5, what's the general take on (1) capitulation to the Linus > and AC viewpoint about reducing the invasiveness by taking out some of the > code that dupes functionality in the kernel but does it differently and (2) > longevity of the XFS project in light of the industry's less than stellar > financial condition as a whole? So where is this discussion going on? Because it is happening in a forum I don't see. As for code duplication - there is maybe one operation which has major overlap - xfs_rename. If we take out code in the mainline kernel then we loose about half of what XFS can do and might as well go home anyway. Steve From owner-linux-xfs@oss.sgi.com Sun Oct 14 04:45:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9EBjTO06392 for linux-xfs-outgoing; Sun, 14 Oct 2001 04:45:29 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9EBjQD06369 for ; Sun, 14 Oct 2001 04:45:26 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.6/8.11.6) id f9EBjLt09105 for linux-xfs@oss.sgi.com; Sun, 14 Oct 2001 07:45:21 -0400 Date: Sun, 14 Oct 2001 07:45:20 -0400 From: Alan Eldridge To: SGI XFS Dev List Subject: Re: Linux 2.5 or now 2.6 targeted Message-ID: <20011014074520.A8416@wwweasel.geeksrus.net> References: <200110141140.f9EBeJt15227@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200110141140.f9EBeJt15227@jen.americas.sgi.com>; from lord@sgi.com on Sun, Oct 14, 2001 at 06:40:19AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Oct 14, 2001 at 06:40:19AM -0500, Steve Lord wrote: >> A question for the guys at SGI that are working so hard on this beast: >> With the fundamental differences regarding implementation, in particular the >> invasiveness of the XFS patches, and the talk now of possibly targeting 2.6 >> rather than 2.5, what's the general take on (1) capitulation to the Linus >> and AC viewpoint about reducing the invasiveness by taking out some of the >> code that dupes functionality in the kernel but does it differently and (2) >> longevity of the XFS project in light of the industry's less than stellar >> financial condition as a whole? > >So where is this discussion going on? Because it is happening in a forum >I don't see. Sorry Steve. I wrote this question to the list just a while ago. I got one response privately which didn't get copied to the list. My reply to that I copied. And that's all the discussion there's been. I'm mostly interested in views from you and your fellow XFS kernel hackers. -- Alan Eldridge from std_disclaimer import * From owner-linux-xfs@oss.sgi.com Sun Oct 14 04:49:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9EBnm706624 for linux-xfs-outgoing; Sun, 14 Oct 2001 04:49:48 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9EBnkD06602 for ; Sun, 14 Oct 2001 04:49:46 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.6/8.11.6) id f9EBneu09285 for linux-xfs@oss.sgi.com; Sun, 14 Oct 2001 07:49:40 -0400 Date: Sun, 14 Oct 2001 07:49:40 -0400 From: Alan Eldridge To: SGI XFS Dev List Subject: Re: Linux 2.5 or now 2.6 targeted Message-ID: <20011014074940.A9220@wwweasel.geeksrus.net> References: <200110141140.f9EBeJt15227@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200110141140.f9EBeJt15227@jen.americas.sgi.com>; from lord@sgi.com on Sun, Oct 14, 2001 at 06:40:19AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Oct 14, 2001 at 06:40:19AM -0500, Steve Lord wrote: > >As for code duplication - there is maybe one operation which has major >overlap - xfs_rename. If we take out code in the mainline kernel then we >loose about half of what XFS can do and might as well go home anyway. Did I misunderstand earlier discussions (the nudge Alan Cox thread) then? I inferred it meant that XFS was doing the same things, in different ways, than the mainline kernel. By what you just said, I think I erred. Is the issue really that the code is not confined to the FS layer, but that XFS needs additional, mainline, code to function? -- Alan Eldridge from std_disclaimer import * From owner-linux-xfs@oss.sgi.com Sun Oct 14 04:59:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9EBxBQ06840 for linux-xfs-outgoing; Sun, 14 Oct 2001 04:59:11 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9EBx9D06818 for ; Sun, 14 Oct 2001 04:59:09 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id EAA01269 for ; Sun, 14 Oct 2001 04:58:15 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id GAA3213914 for ; Sun, 14 Oct 2001 06:57:53 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id GAA62525 for ; Sun, 14 Oct 2001 06:57:52 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9EBtu618994; Sun, 14 Oct 2001 06:55:56 -0500 Message-Id: <200110141155.f9EBtu618994@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: linux-xfs@oss.sgi.com Subject: Re: include/acl.h in 2.4.13-pre2 Date: Sun, 14 Oct 2001 06:55:56 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Try running make dep, it all builds for me. Steve From owner-linux-xfs@oss.sgi.com Sun Oct 14 05:09:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9EC9JI07115 for linux-xfs-outgoing; Sun, 14 Oct 2001 05:09:19 -0700 Received: from ctgw.lbsd.net (ctgw.lbsd.net [196.25.111.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9EC9DD07087 for ; Sun, 14 Oct 2001 05:09:13 -0700 Received: from localhost (nkukard@localhost) by ctgw.lbsd.net (8.9.3/8.8.7) with ESMTP id OAA14055; Sun, 14 Oct 2001 14:08:54 +0200 Date: Sun, 14 Oct 2001 14:08:54 +0200 (SAST) From: Nigel Kukard To: Steve Lord cc: linux-xfs@oss.sgi.com Subject: Re: total/partial fs corruption In-Reply-To: <200110141127.f9EBRRn09685@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 14 Oct 2001, Steve Lord wrote: > > > There was some wierd stuff in this kernel range, people lost partitions > from their partition table, and turning on xfs quota broke some binary > disk access (we never did understand why). These problems appear to go > away in 2.4.13-pre1 (we are now at pre2 I see). Can you try this and > report back? eish, ok... gimme about 1hr and i'll have sum results > > Thanks > > Steve > > -- ================================================================================ Contact Details --------------- Name: Nigel Kukard GSM Mobile: (+27) 082 564 2120 GSM Fax: (+27) 082 131 564 2120 Email: nkukard@linuxrulz.za.net Organizations ------------- - LinuxRulz Url: http://www.linuxrulz.za.net Position: Owner - Linux Based Systems Design Url: http://www.lbsd.net Position: Systems Designer, Programmer - Lando Technologies Url: http://www.lando.co.za Position: Linux Systems/Network Administrator From owner-linux-xfs@oss.sgi.com Sun Oct 14 05:10:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ECA0d07157 for linux-xfs-outgoing; Sun, 14 Oct 2001 05:10:00 -0700 Received: from ente.berdmann.de (frnk-d514e186.dsl.mediaWays.net [213.20.225.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9EC9wD07131 for ; Sun, 14 Oct 2001 05:09:58 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 15sk5Y-0006iG-00 for linux-xfs@oss.sgi.com; Sun, 14 Oct 2001 14:09:52 +0200 Message-ID: <3BC98090.BA78FC5A@berdmann.de> Date: Sun, 14 Oct 2001 14:09:52 +0200 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.13-pre1-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: include/acl.h in 2.4.13-pre2 References: <200110141155.f9EBtu618994@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: > > Try running make dep, it all builds for me. I did (make mrproper, cp some/where/.config ., make oldconfig, make dep clean bzImage modules modules_install), but it fails to compile on RH 6.1/6.2. On RH 7.1 all is ok as you reported. From owner-linux-xfs@oss.sgi.com Sun Oct 14 05:17:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ECHtP07468 for linux-xfs-outgoing; Sun, 14 Oct 2001 05:17:55 -0700 Received: from ente.berdmann.de (frnk-d514e186.dsl.mediaWays.net [213.20.225.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ECHrD07446 for ; Sun, 14 Oct 2001 05:17:53 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 15skDD-0006lg-00; Sun, 14 Oct 2001 14:17:47 +0200 Message-ID: <3BC9826B.6A1793B@berdmann.de> Date: Sun, 14 Oct 2001 14:17:47 +0200 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.13-pre1-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Nathan Scott CC: linux-xfs@oss.sgi.com Subject: Re: TAKE - ioctl/EA planning References: <200110140728.RAA87709@snort.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Nathan Scott wrote: [...] > linux/fs/xfs/linux/acl.h - 1.4 > - no longer used, removed. There's still an #include in fs/noposix_acl.c. It caused compilation on my RH 6.1/6.2 boxes to fail. After deleting that line everything is fine. From owner-linux-xfs@oss.sgi.com Sun Oct 14 05:19:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ECJDQ07532 for linux-xfs-outgoing; Sun, 14 Oct 2001 05:19:13 -0700 Received: from ente.berdmann.de (frnk-d514e186.dsl.mediaWays.net [213.20.225.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ECJBD07509 for ; Sun, 14 Oct 2001 05:19:11 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 15skET-0006lk-00; Sun, 14 Oct 2001 14:19:05 +0200 Message-ID: <3BC982B9.9BAB5479@berdmann.de> Date: Sun, 14 Oct 2001 14:19:05 +0200 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.13-pre1-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Keith Owens CC: Linux XFS Mailing List Subject: Re: acl.h (was: TAKE - Upgrade XFS to 2.4.13-pre2) References: <1610.1003058973@ocs3.intra.ocs.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > >What has happened to linux/acl.h? > > Nathan Scott removed acl.h as part of another change, unrelated to > 2.4.13-pre2. I will let Nathan chase up the obsolete reference. Try > removing include/acl.h from any files that fail to compile. Thanks! That did the trick. From owner-linux-xfs@oss.sgi.com Sun Oct 14 05:20:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ECKxS07675 for linux-xfs-outgoing; Sun, 14 Oct 2001 05:20:59 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ECKvD07653 for ; Sun, 14 Oct 2001 05:20:57 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.6/8.11.6) id f9ECKpM10084 for linux-xfs@oss.sgi.com; Sun, 14 Oct 2001 08:20:51 -0400 Date: Sun, 14 Oct 2001 08:20:51 -0400 From: Alan Eldridge To: SGI XFS Dev List Subject: 2.5 or 2.6 rephrased Message-ID: <20011014082051.A9895@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve, lemme try again. For production (business/academic/???) users, people for whom a change in filesystem is a flag day that costs $$, a choice to switch to a kernel that is only provided by SGI is a tough one. I don't know how I'd justify such a thing. The old question of support/maintainance/longevity is a real tough one to wave away in that case. What would you say to such a user in making the case to use an XFS kernel, when technical arguments alone won't do? -- Alan Eldridge from std_disclaimer import * From owner-linux-xfs@oss.sgi.com Sun Oct 14 05:23:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ECNud07916 for linux-xfs-outgoing; Sun, 14 Oct 2001 05:23:56 -0700 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ECNnD07873 for ; Sun, 14 Oct 2001 05:23:50 -0700 Received: (qmail 21120 invoked from network); 14 Oct 2001 12:23:46 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 14 Oct 2001 12:23:46 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 70F25300090; Sun, 14 Oct 2001 22:23:45 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 5B59298; Sun, 14 Oct 2001 22:23:45 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: "Bernhard R. Erdmann" Cc: linux-xfs@oss.sgi.com Subject: Re: include/acl.h in 2.4.13-pre2 In-reply-to: Your message of "Sun, 14 Oct 2001 14:09:52 +0200." <3BC98090.BA78FC5A@berdmann.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Oct 2001 22:23:40 +1000 Message-ID: <2217.1003062220@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 14 Oct 2001 14:09:52 +0200, "Bernhard R. Erdmann" wrote: >Steve Lord wrote: >> >> Try running make dep, it all builds for me. > >I did (make mrproper, cp some/where/.config ., make oldconfig, make dep >clean bzImage modules modules_install), but it fails to compile on RH >6.1/6.2. >On RH 7.1 all is ok as you reported. Arrgh! RH 7.1 is picking up /usr/include/linux/acl.h which is a real file. On RH 6 usr/include/linux is normally a symlink to /usr/src/linux so you get different files depending on which kernel you have installed. Linus has fought against this for ages because it generated wierd kernels, most distributions now ship a copy of the files in /usr/include/linux instead of symlinking to some random kernel. I guess that Nathan's build was on a system which had a real file for /usr/include/linux/acl.h so he did not get a compile error. Kernel 2.5 will refuse to include files from outside the kernel to prevent this feature. In the meantime, add these liness CFLAGS += -nostdinc $(shell $(CC) -print-search-dirs | \ sed -ne 's/install: \(.*\)/-I \1include/gp') to the top of these files. fs/xfs/dmapi/Makefile fs/xfs/linux/Makefile fs/xfs/Makefile fs/xfs_support/Makefile fs/pagebuf/Makefile That will prevent XFS from reading include files from outside the kernel. When you find references to acl.h, remove the include line and see if it still builds. From owner-linux-xfs@oss.sgi.com Sun Oct 14 05:23:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ECNxk07927 for linux-xfs-outgoing; Sun, 14 Oct 2001 05:23:59 -0700 Received: from ctgw.lbsd.net (ctgw.lbsd.net [196.25.111.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ECNrD07897 for ; Sun, 14 Oct 2001 05:23:54 -0700 Received: from localhost (nkukard@localhost) by ctgw.lbsd.net (8.9.3/8.8.7) with ESMTP id OAA14107; Sun, 14 Oct 2001 14:23:43 +0200 Date: Sun, 14 Oct 2001 14:23:43 +0200 (SAST) From: Nigel Kukard To: Steve Lord cc: linux-xfs@oss.sgi.com Subject: Re: total/partial fs corruption In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk i have a really stupid question, could sumone plz send me a diff to 13pre2 that i must apply for this testing? i don't want to download the entire cvs (not that i'm 100% sure how)... hehehe. :) attatch mime'd .patch.bz2 would be very very appreciated! -Nigel -- ================================================================================ Contact Details --------------- Name: Nigel Kukard GSM Mobile: (+27) 082 564 2120 GSM Fax: (+27) 082 131 564 2120 Email: nkukard@linuxrulz.za.net Organizations ------------- - LinuxRulz Url: http://www.linuxrulz.za.net Position: Owner - Linux Based Systems Design Url: http://www.lbsd.net Position: Systems Designer, Programmer - Lando Technologies Url: http://www.lando.co.za Position: Linux Systems/Network Administrator From owner-linux-xfs@oss.sgi.com Sun Oct 14 05:37:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ECbE308265 for linux-xfs-outgoing; Sun, 14 Oct 2001 05:37:14 -0700 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ECbBD08243 for ; Sun, 14 Oct 2001 05:37:11 -0700 Received: (qmail 21223 invoked from network); 14 Oct 2001 12:37:09 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 14 Oct 2001 12:37:09 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 2F541300090; Sun, 14 Oct 2001 22:37:08 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 1956F98; Sun, 14 Oct 2001 22:37:08 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Nigel Kukard Cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: total/partial fs corruption In-reply-to: Your message of "Sun, 14 Oct 2001 14:23:43 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Oct 2001 22:37:02 +1000 Message-ID: <2359.1003063022@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 14 Oct 2001 14:23:43 +0200 (SAST), Nigel Kukard wrote: >i have a really stupid question, could sumone plz send me a diff to 13pre2 >that i must apply for this testing? i don't want to download the entire >cvs (not that i'm 100% sure how)... hehehe. :) On its way. There was a patch reject on one driver due to RCS id differences, just delete the first two lines of the offending driver. From owner-linux-xfs@oss.sgi.com Sun Oct 14 06:18:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9EDIK008847 for linux-xfs-outgoing; Sun, 14 Oct 2001 06:18:20 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9EDIFD08825 for ; Sun, 14 Oct 2001 06:18:15 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9EDI8W08378 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Sun, 14 Oct 2001 06:18:08 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id PAA3266052 for ; Sun, 14 Oct 2001 15:17:06 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA3306286; Sun, 14 Oct 2001 08:16:49 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA97397; Sun, 14 Oct 2001 08:16:48 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9EDEqh00473; Sun, 14 Oct 2001 08:14:52 -0500 Message-Id: <200110141314.f9EDEqh00473@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Alan Eldridge cc: SGI XFS Dev List Subject: Re: 2.5 or 2.6 rephrased In-Reply-To: Message from Alan Eldridge of "Sun, 14 Oct 2001 08:20:51 EDT." <20011014082051.A9895@wwweasel.geeksrus.net> Date: Sun, 14 Oct 2001 08:14:52 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Steve, lemme try again. > > For production (business/academic/???) users, people for whom a change in > filesystem is a flag day that costs $$, a choice to switch to a kernel that > is only provided by SGI is a tough one. I don't know how I'd justify such a > thing. The old question of support/maintainance/longevity is a real tough > one to wave away in that case. > > What would you say to such a user in making the case to use an XFS kernel, > when technical arguments alone won't do? Yes, you definitely need a support scenario, which means a major distribution carrying xfs is a must. Mandrake has just started doing so in their 8.1 release. We are working on system call issues before another major distrib will consider us, others probably depend on being in Alan or Linus's kernel (although RedHat has some large chunks of kernel code in their tree which is not in Linus's kernel). I am still confident we will get to this stage, but I really have no way of predicting when, and we are absolutely pegged out around here with all sorts of other work, I personally do not have the required bandwidth now to wage campaigns to get xfs into kernels and distributions, that would be a pretty much full time job. As you state, 'given the current financial state of the industry', I sort of feel compelled to work on these other projects which have a much higher potential for a financial return for SGI within the forseeable future than Linux XFS does (plus my management pretty much insists I make then my priority). Steve > > -- > Alan Eldridge > from std_disclaimer import * From owner-linux-xfs@oss.sgi.com Sun Oct 14 06:35:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9EDZsm09164 for linux-xfs-outgoing; Sun, 14 Oct 2001 06:35:54 -0700 Received: from gk.hm.epigenomics.net (qmailr@gk.hm.epigenomics.net [212.121.137.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9EDZpD09142 for ; Sun, 14 Oct 2001 06:35:51 -0700 Received: (qmail 23786 invoked from network); 14 Oct 2001 13:35:50 -0000 Received: from raman.epigenomics.epi (qmailr@192.168.2.2) by salam.epigenomics.epi with SMTP; 14 Oct 2001 13:35:50 -0000 Received: (qmail 6924 invoked by uid 515); 14 Oct 2001 13:35:48 -0000 Date: Sun, 14 Oct 2001 15:35:48 +0200 From: Robert Sander To: Amit D Chaudhary Cc: linux-xfs@oss.sgi.com Subject: Re: process hang with xfs 1.0.1 Message-ID: <20011014153548.A6910@epigenomics.com> References: <3BC7950E.8030807@brocade.com> <200110131403.f9DE3QJ01897@jen.americas.sgi.com> <20011013195809.A1617@epigenomics.com> <3BC8CCBE.50903@brocade.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <3BC8CCBE.50903@brocade.com> User-Agent: Mutt/1.3.22i X-Operating-System: Linux raman 2.4.7-aacraid-xfs-ngroups Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, Oct 13, 2001 at 04:22:38PM -0700, Amit D Chaudhary wrote: > > > Robert Sander wrote: > > >OK, using 2.4.12 or later was not an option because the aacraid > >patch for the Dell RAID controller was not working. > > > >But with 2.4.7 this particular problem went away now. > > Did you use xfs 1.0.1 with kernel 2.4.7? No, I took the patch for 2.4.7 from oss.sgi.com, I think all these patches are "just" minor changes from 1.0.1 to match the current kernel and have some bug fixes in them. Greetings -- Robert Sander Computer Scientist Epigenomics AG Bioinformatics R&D www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Sun Oct 14 06:45:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9EDj2p09418 for linux-xfs-outgoing; Sun, 14 Oct 2001 06:45:02 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9EDitD09385 for ; Sun, 14 Oct 2001 06:44:55 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 394D8C00B62 for ; Sun, 14 Oct 2001 21:44:51 +0800 (PHT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 40905C00B60 for ; Sun, 14 Oct 2001 21:44:48 +0800 (PHT) Date: Sun, 14 Oct 2001 21:44:48 +0800 (PHT) From: Federico Sevilla III To: Linux XFS Mailing List Subject: Re: 2.5 or 2.6 rephrased In-Reply-To: <20011014082051.A9895@wwweasel.geeksrus.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 14 Oct 2001 at 08:20, Alan Eldridge wrote: > Steve, lemme try again. I'm not Steve (Lord, that is, there are other Steves of filesystem fame, like Steve Best, for instance), but I'll give it a shot anyway. :) > For production (business/academic/???) users, people for whom a change > in filesystem is a flag day that costs $$, a choice to switch to a > kernel that is only provided by SGI is a tough one. I tend to agree with you, although the fact that XFS on Linux is GPL'd should mean at least something (ie: should SGI ever decide to drop support for it, people can continue as of the latest source code released under GPL). Perhaps the CVS server provided by SGI can be considered something like, say, a "donation" (in some ways it may be, in some ways not)? > I don't know how I'd justify such a thing. The old question of > support/maintainance/longevity is a real tough one to wave away in > that case. I don't know if Seth Mos ever was with SGI, but I don't think he's with SGI anymore. I'm not really sure. What I'm positive about, though, is that Seth is still very active in the list and handles the upkeep of the FAQ, which is hosted in SGI. There were also those SGI layoffs that even got Slashdotted, specifically because a number of XFS developers had to go. I do believe they're somehow still active. Not quite as much as when they were paid to be given that they have other day jobs to attend to, but still... > What would you say to such a user in making the case to use an XFS > kernel, when technical arguments alone won't do? It's GPL'd. Worst case scenario we can all pitch in and try to understand the code from wherever it left off. And it's not like the XFS code is in its infancy. It's quite mature (very well tested on IRIX, and the Linux port is awesome), so we won't have to reinvent things anyway, just understand and maintain. This doesn't say that XFS won't or shouldn't be pushed to the mainstream kernel. But it's a hell of a lot of work, and I don't think the SGI guys are being paid to focus their lives on cutting out all the duplication. They _can_, but we all only have so much time. If there's something the community can do it's probably pitch in. And I know for a fact that the SGI guys listen. We've already seen help from that guy from NEC who was listened to when he some stuff for xfsdump, I think it was (one of the userland tools). And I do believe getting XFS to 2.5 and then 2.6 is on the top priority todo list of Steve Lord and company. :) --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Sun Oct 14 08:09:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9EF9vR10654 for linux-xfs-outgoing; Sun, 14 Oct 2001 08:09:57 -0700 Received: from bbaer.muenster.de (bbaer.muenster.de [195.202.32.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9EF9rD10631 for ; Sun, 14 Oct 2001 08:09:54 -0700 Received: from server.nick.de (mueasb-wan024.citykom.de [195.202.39.24]) by bbaer.muenster.de (8.9.3/8.9.3) with ESMTP id RAA15339 for ; Sun, 14 Oct 2001 17:09:50 +0200 X-Authentication-Warning: bbaer.muenster.de: Host mueasb-wan024.citykom.de [195.202.39.24] claimed to be server.nick.de Received: from there (linux.nick.de [192.168.1.1]) by server.nick.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id NAA05448 for ; Sun, 14 Oct 2001 13:59:08 +0200 Message-Id: <200110141159.NAA05448@server.nick.de> Content-Type: text/plain; charset="iso-8859-1" From: Nick (Gunnar) Bluth To: linux-xfs@oss.sgi.com Subject: Re: Total/Partial corruption Date: Sun, 14 Oct 2001 15:22:41 +0200 X-Mailer: KMail [version 1.3.1] References: <20011013232631.A32323@wwweasel.geeksrus.net> In-Reply-To: <20011013232631.A32323@wwweasel.geeksrus.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Am Sonntag, 14. Oktober 2001 05:26 schriebst Du: > comments on that setup? I'm still using kgcc. BTW, with RH 8.0 I believe > kgcc is history. (Double) Nope. It'll be 7.2, and I just compiled a kernel with kgcc. #> rpm -qf $(which kgcc) compat-egcs-6.2-1.1.2.16 (7.2 final) -- Nick (Gunnar) Bluth Muenster/Germany bluth@muenster.de RHCE/RHCX +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ In 1984 mainstream users were choosing VMS over UNIX. Ten years later they are choosing Windows over UNIX. What part of that message aren't you getting? - Tom Payne From owner-linux-xfs@oss.sgi.com Sun Oct 14 08:25:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9EFPQx11021 for linux-xfs-outgoing; Sun, 14 Oct 2001 08:25:26 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9EFPND10999 for ; Sun, 14 Oct 2001 08:25:23 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9EFPIW10515 for ; Sun, 14 Oct 2001 08:25:18 -0700 Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id IAA89857; Sun, 14 Oct 2001 08:24:37 -0700 (PDT) Message-ID: <3BC9AD68.F5615EF6@sgi.com> Date: Sun, 14 Oct 2001 10:21:12 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: Federico Sevilla III CC: Linux XFS Mailing List Subject: Re: 2.5 or 2.6 rephrased References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Federico Sevilla III wrote: > I don't know if Seth Mos ever was with SGI, but I don't think he's with > SGI anymore. I'm not really sure. He's not from SGI, but he's a tireless volunteer and XFS advocate. :) (cue round of applause....) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Sun Oct 14 09:10:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9EGAOK11652 for linux-xfs-outgoing; Sun, 14 Oct 2001 09:10:24 -0700 Received: from ctgw.lbsd.net (ctgw.lbsd.net [196.25.111.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9EGAGD11627 for ; Sun, 14 Oct 2001 09:10:17 -0700 Received: from localhost (nkukard@localhost) by ctgw.lbsd.net (8.9.3/8.8.7) with ESMTP id SAA14631 for ; Sun, 14 Oct 2001 18:10:10 +0200 Date: Sun, 14 Oct 2001 18:10:10 +0200 (SAST) From: Nigel Kukard To: Linux XFS Mailing List Subject: Total / Partial XFS corruption Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ok, kernel 2.4.12 + XFS test case 1: SMP kernel, resulted in total fs corruption test case 2: UNIPROC kernel, resulted in total fs corruption conclusion so far: SMP is not the culprit tests still to preform... kernel 2.4.13pre2 + XFS will keep you guys updated on what i find out, as far as i can see it corruption occurs with 100% probability after i enable quotas and halt the box. if i do a reboot without quotas, it takes about 10 reboots before corruption. -Nigel -- ================================================================================ Contact Details --------------- Name: Nigel Kukard GSM Mobile: (+27) 082 564 2120 GSM Fax: (+27) 082 131 564 2120 Email: nkukard@linuxrulz.za.net Organizations ------------- - LinuxRulz Url: http://www.linuxrulz.za.net Position: Owner - Linux Based Systems Design Url: http://www.lbsd.net Position: Systems Designer, Programmer - Lando Technologies Url: http://www.lando.co.za Position: Linux Systems/Network Administrator From owner-linux-xfs@oss.sgi.com Sun Oct 14 09:57:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9EGv7712091 for linux-xfs-outgoing; Sun, 14 Oct 2001 09:57:07 -0700 Received: from ente.berdmann.de (frnk-d514e186.dsl.mediaWays.net [213.20.225.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9EGv1D12069 for ; Sun, 14 Oct 2001 09:57:01 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 15soZK-0008KV-00; Sun, 14 Oct 2001 18:56:54 +0200 Message-ID: <3BC9C3D5.B1202DFE@berdmann.de> Date: Sun, 14 Oct 2001 18:56:53 +0200 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.13-pre2-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Keith Owens CC: linux-xfs@oss.sgi.com Subject: Re: include/acl.h in 2.4.13-pre2 References: <2217.1003062220@ocs3.intra.ocs.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Arrgh! RH 7.1 is picking up /usr/include/linux/acl.h which is a real > file. On RH 6 usr/include/linux is normally a symlink to > /usr/src/linux so you get different files depending on which kernel you > have installed. Linus has fought against this for ages because it > generated wierd kernels, most distributions now ship a copy of the > files in /usr/include/linux instead of symlinking to some random > kernel. Does it have something to do with my getdents.c problem? [root@apollo xfsdump]# ./Makepkgs rpm == clean, log is Logs/clean == configure, log is Logs/configure == default, log is Logs/default "make default" failed, see log in Logs/default gcc -O1 -g -DDEBUG -funsigned-char -Wall -DDUMP -DRMT -DBASED -DDOSOCKS -DINVCONVFIX -DSIZEEST -DPIPEINVFIX -DEXTATTR -DDMEXTATTR -I/usr/include/xfs -I/usr/include/attr '-DVERSION="1.1.6"' -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 -I/usr/include/xfs -I/usr/include/attr -c drive_simple.c -o drive_simple.o gcc -O1 -g -DDEBUG -funsigned-char -Wall -DDUMP -DRMT -DBASED -DDOSOCKS -DINVCONVFIX -DSIZEEST -DPIPEINVFIX -DEXTATTR -DDMEXTATTR -I/usr/include/xfs -I/usr/include/attr '-DVERSION="1.1.6"' -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 -I/usr/include/xfs -I/usr/include/attr -c drive_minrmt.c -o drive_minrmt.o gcc -O1 -g -DDEBUG -funsigned-char -Wall -DDUMP -DRMT -DBASED -DDOSOCKS -DINVCONVFIX -DSIZEEST -DPIPEINVFIX -DEXTATTR -DDMEXTATTR -I/usr/include/xfs -I/usr/include/attr '-DVERSION="1.1.6"' -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 -I/usr/include/xfs -I/usr/include/attr -c fs.c -o fs.o gcc -O1 -g -DDEBUG -funsigned-char -Wall -DDUMP -DRMT -DBASED -DDOSOCKS -DINVCONVFIX -DSIZEEST -DPIPEINVFIX -DEXTATTR -DDMEXTATTR -I/usr/include/xfs -I/usr/include/attr '-DVERSION="1.1.6"' -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 -I/usr/include/xfs -I/usr/include/attr -c getdents.c -o getdents.o getdents.c: In function `getdents_wrap': getdents.c:152: `SYS_getdents64' undeclared (first use in this function) getdents.c:152: (Each undeclared identifier is reported only once getdents.c:152: for each function it appears in.) make[1]: *** [getdents.o] Error 1 make: *** [default] Error 2 From owner-linux-xfs@oss.sgi.com Sun Oct 14 10:22:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9EHMB312508 for linux-xfs-outgoing; Sun, 14 Oct 2001 10:22:11 -0700 Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9EHM1D12486 for ; Sun, 14 Oct 2001 10:22:02 -0700 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 f9EHMNb1038072; Sun, 14 Oct 2001 19:22:24 +0200 (CEST) Message-Id: <4.3.2.7.2.20011014190418.02cf65f0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 14 Oct 2001 19:20:37 +0200 To: Federico Sevilla III , Linux XFS Mailing List From: Seth Mos Subject: Re: 2.5 or 2.6 rephrased In-Reply-To: References: <20011014082051.A9895@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 21:44 14-10-2001 +0800, Federico Sevilla III wrote: >On Sun, 14 Oct 2001 at 08:20, Alan Eldridge wrote: > > Steve, lemme try again. > >I'm not Steve (Lord, that is, there are other Steves of filesystem fame, >like Steve Best, for instance), but I'll give it a shot anyway. :) Not forget there are other Steves posting question _and_ answers to the list to confuse us. > > For production (business/academic/???) users, people for whom a change > > in filesystem is a flag day that costs $$, a choice to switch to a > > kernel that is only provided by SGI is a tough one. > >I tend to agree with you, although the fact that XFS on Linux is GPL'd >should mean at least something (ie: should SGI ever decide to drop support >for it, people can continue as of the latest source code released under >GPL). That is the main point in which I could switch management. You can always call up a support company and pay them to keep it going say for a few thousand euro per month (it's not always full time work). If five company's do this you have probably all the bases covered. >Perhaps the CVS server provided by SGI can be considered something like, >say, a "donation" (in some ways it may be, in some ways not)? The paid for the server, they pay for the bandwidth (as Steve L once mentioned it was around 300GB in a few days). > > I don't know how I'd justify such a thing. The old question of > > support/maintainance/longevity is a real tough one to wave away in > > that case. > >I don't know if Seth Mos ever was with SGI, but I don't think he's with >SGI anymore. I'm not really sure. What I'm positive about, though, is that >Seth is still very active in the list and handles the upkeep of the FAQ, >which is hosted in SGI. There were also those SGI layoffs that even got >Slashdotted, specifically because a number of XFS developers had to go. I >do believe they're somehow still active. Not quite as much as when they >were paid to be given that they have other day jobs to attend to, but >still... I have never worked with SGI, it does not seem likely that I ever will work for SGI (offers per private mail ;-), and I do this entire voluntary. I work for Coltex Retail Group BV in the netherlands as a system administrator and we use XFS at work in production systems and thus I need support. Half of that support is giving back to the community. The other half is supporting the systems myself. I feel confident enough that if something ever comes up we can just call a company like StoneIT in the netherlands and ask them for support if we need it. For a price ofcourse, but then again support never comes free. > > What would you say to such a user in making the case to use an XFS > > kernel, when technical arguments alone won't do? > >It's GPL'd. Worst case scenario we can all pitch in and try to understand >the code from wherever it left off. And it's not like the XFS code is in >its infancy. It's quite mature (very well tested on IRIX, and the Linux >port is awesome), so we won't have to reinvent things anyway, just >understand and maintain. Remember, there are a lot of companies like Linuxcare that do just that. Offer support on stuff that otherwise would be lost. Since XFS has great value I don't see this happening. >This doesn't say that XFS won't or shouldn't be pushed to the mainstream >kernel. But it's a hell of a lot of work, and I don't think the SGI guys >are being paid to focus their lives on cutting out all the duplication. >They _can_, but we all only have so much time. If there's something the >community can do it's probably pitch in. And I know for a fact that the >SGI guys listen. We've already seen help from that guy from NEC who was >listened to when he some stuff for xfsdump, I think it was (one of the >userland tools). It just takes time and a bit of help from everyone. It is not really that difficult. I answer questions on this mailing list in my free time and some of them at work in between moments of peace and quiet. However due to a new server at work and the stampeding/impeding Euro conversion tricks I have less time but I already see other people stepping in and answering questions. Things that make you feel warm and fuzzy inside :-) >And I do believe getting XFS to 2.5 and then 2.6 is on the top priority >todo list of Steve Lord and company. :) We are not forgotten, Alan is actually testing and feeling about XFS every know and then. He just does not tell us. We are being noticed, don't worry. Cheerio, off to the coffee -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Sun Oct 14 10:30:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9EHURX12682 for linux-xfs-outgoing; Sun, 14 Oct 2001 10:30:27 -0700 Received: from zorak.illusionary.lan (653230hfc08.tampabay.rr.com [65.32.30.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9EHUID12660 for ; Sun, 14 Oct 2001 10:30:19 -0700 Received: from illusionary.com (wraith [192.168.10.10]) by zorak.illusionary.lan (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id NAA07788 for ; Sun, 14 Oct 2001 13:30:03 -0400 X-Authentication-Warning: zorak.illusionary.lan: Host wraith [192.168.10.10] claimed to be illusionary.com Message-ID: <3BC9CB98.FE16F50F@illusionary.com> Date: Sun, 14 Oct 2001 13:30:00 -0400 From: Derek Glidden X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.12-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Linux 2.5 or now 2.6 targeted References: <20011013234342.B32323@wwweasel.geeksrus.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Alan Eldridge wrote: > > And BSD doesn't really have any options for journaling that I'm aware of, so > switching to BSD isn't really an option. Nor is Solaris, 'cause I know I'm > not wealthy enough to buy Veritas, if it's even available for IA-32 > architecture. For those of us with big disk space systems (and that group is > growing), Linux + XFS is the only real game in town right now AFAIK. Hi, I'd like to take a moment and be pedantic a bit, prefacing it by saying I've got XFS on just about every machine I run and several I'm only responsible for sysadmining and have been utterly happy with it. (Barring one occasional problem that Eric Sandeen was more than willing to get down-n-dirty with but has never popped back up to allow me to get deeper into...) FreeBSD has Kirk McCusick's "Softupdates" code pretty well established. It's not exactly "journaling " but if I understand iit technically, it reminds me of the experimental "tux" filesystem, the two seem to have some similarity in that Softupdates tries to delay and order writes in a fashion so that the on-disk structures are never left in an inconsistent state. There's no journal or log per-se, but the filesystem should never be stuck in a situation where a full fsck is really necessary on a system failure. I've used it myself and, while not completely avoiding reboot fileystem checks, does a very good job of reducing them to virtually nothing. Not coincidentally also speeds up most filesystem writes since the inherent delays for ordering makes writes more efficient. (Of course, as far as comparisons with "tux" I should mention that Softupdates came first and technically internally, the two are not really very related.) As far as Solaris, at least as of Solaris 7, which I have on my Ultra 5 at home (yeah I'm a little weird), has a "logging" option you can pass to the mount command which will enable some basic log/journaling functionality on the standard UFS fileystem type that Solaris uses. Veritas allows all sorts of other options than just journaling/logging, so if you just want that capability, you don't need to spring for Veritas. So there you go. :) (And netscape is being strange so the formatting of this email might be really messed up...) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- With Microsoft products, failure is not an option -- it's a standard component. Choose your life. Choose your future. Derek Glidden Choose Linux. http://www.illusionary.com/ From owner-linux-xfs@oss.sgi.com Sun Oct 14 10:37:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9EHbeo12855 for linux-xfs-outgoing; Sun, 14 Oct 2001 10:37:40 -0700 Received: from zorak.illusionary.lan (653230hfc08.tampabay.rr.com [65.32.30.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9EHbPD12828 for ; Sun, 14 Oct 2001 10:37:25 -0700 Received: from illusionary.com (wraith [192.168.10.10]) by zorak.illusionary.lan (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id NAA07795 for ; Sun, 14 Oct 2001 13:37:11 -0400 X-Authentication-Warning: zorak.illusionary.lan: Host wraith [192.168.10.10] claimed to be illusionary.com Message-ID: <3BC9CD44.6CDB2B40@illusionary.com> Date: Sun, 14 Oct 2001 13:37:08 -0400 From: Derek Glidden X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.12-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Linux XFS Mailing List Subject: FS Steves [Totally OT] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Federico Sevilla III wrote: > > On Sun, 14 Oct 2001 at 08:20, Alan Eldridge wrote: > > Steve, lemme try again. > > I'm not Steve (Lord, that is, there are other Steves of filesystem fame, > like Steve Best, for instance), but I'll give it a shot anyway. :) So who's the best filesystem Steve, Best or Lord? Best implies being the best, but it's hard to be better than a Lord I would imagine. I know it's just coincidence but I always get a chuckle about the implications of these two Steves' names. :) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- With Microsoft products, failure is not an option -- it's a standard component. Choose your life. Choose your future. Derek Glidden Choose Linux. http://www.illusionary.com/ From owner-linux-xfs@oss.sgi.com Sun Oct 14 10:44:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9EHipo13065 for linux-xfs-outgoing; Sun, 14 Oct 2001 10:44:51 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9EHimD13042 for ; Sun, 14 Oct 2001 10:44:48 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9EHigW13023 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Sun, 14 Oct 2001 10:44:42 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id TAA3269012 for ; Sun, 14 Oct 2001 19:43:59 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA2083846; Sun, 14 Oct 2001 12:43:22 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA91961; Sun, 14 Oct 2001 12:43:22 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9EHfNc01025; Sun, 14 Oct 2001 12:41:23 -0500 Message-Id: <200110141741.f9EHfNc01025@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Derek Glidden cc: Linux XFS Mailing List Subject: Re: FS Steves [Totally OT] In-Reply-To: Message from Derek Glidden of "Sun, 14 Oct 2001 13:37:08 EDT." <3BC9CD44.6CDB2B40@illusionary.com> Date: Sun, 14 Oct 2001 12:41:23 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Federico Sevilla III wrote: > > > > On Sun, 14 Oct 2001 at 08:20, Alan Eldridge wrote: > > > Steve, lemme try again. > > > > I'm not Steve (Lord, that is, there are other Steves of filesystem fame, > > like Steve Best, for instance), but I'll give it a shot anyway. :) > > So who's the best filesystem Steve, Best or Lord? Best implies being > the best, but it's hard to be better than a Lord I would imagine. > > I know it's just coincidence but I always get a chuckle about the > implications of these two Steves' names. :) But no one escapes from Tweedies chicken farm! Lets see if someone can get that reference ;-) Steve From owner-linux-xfs@oss.sgi.com Sun Oct 14 10:48:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9EHmvQ13243 for linux-xfs-outgoing; Sun, 14 Oct 2001 10:48:57 -0700 Received: from trillium-hollow.org (IDENT:root@trillium-hollow.org [209.180.166.89]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9EHmsD13221 for ; Sun, 14 Oct 2001 10:48:54 -0700 Received: from erich (helo=trillium) by trillium-hollow.org with local-esmtp (Exim 3.20 #1) id 15spN5-0003jj-00; Sun, 14 Oct 2001 10:48:19 -0700 To: Keith Owens cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - Upgrade XFS to 2.4.13-pre2 In-Reply-To: Your message of "Sun, 14 Oct 2001 16:02:31 +1000." <200110140602.QAA30178@sherman.melbourne.sgi.com> Date: Sun, 14 Oct 2001 10:48:19 -0700 From: erich@uruk.org Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Keith Owens wrote: > Upgrade XFS to 2.4.13-pre2. > Interesting that 2.4.13-pre2 contains yet another partition fix, it is > not listed in Linus's changelog. I had grabbed this particular partition fix from the linux-kernel, since it seemed to fix the last critical issue noticed by those having troubles. There have been no reported issues on that thread after that fix. I'm glad they got it in. -- Erich Stefan Boleyn http://www.uruk.org/ "Reality is truly stranger than fiction; Probably why fiction is so popular" From owner-linux-xfs@oss.sgi.com Sun Oct 14 11:01:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9EI19m13640 for linux-xfs-outgoing; Sun, 14 Oct 2001 11:01:09 -0700 Received: from rover (rover.mkp.net [209.217.122.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9EI12D13606 for ; Sun, 14 Oct 2001 11:01:02 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=jaguar.mkp.net) by rover with esmtp (Exim 3.33 #1) id 15spZL-0006B2-00; Sun, 14 Oct 2001 14:01:00 -0400 Received: (from mkp@localhost) by jaguar.mkp.net (8.11.2/8.9.3) id f9EI0uS04799; Sun, 14 Oct 2001 14:00:56 -0400 X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f To: Steve Lord Cc: Linux XFS Mailing List Subject: Re: FS Steves [Totally OT] References: <200110141741.f9EHfNc01025@jen.americas.sgi.com> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 14 Oct 2001 14:00:54 -0400 In-Reply-To: <200110141741.f9EHfNc01025@jen.americas.sgi.com> Message-ID: Lines: 10 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>>>> "Steve" == Steve Lord writes: Steve> But no one escapes from Tweedies chicken farm! Chicken Run -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Sun Oct 14 10:59:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9EHxQC13521 for linux-xfs-outgoing; Sun, 14 Oct 2001 10:59:26 -0700 Received: from trillium-hollow.org (IDENT:root@trillium-hollow.org [209.180.166.89]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9EHxND13499 for ; Sun, 14 Oct 2001 10:59:24 -0700 Received: from erich (helo=trillium) by trillium-hollow.org with local-esmtp (Exim 3.20 #1) id 15spWh-0003lQ-00; Sun, 14 Oct 2001 10:58:15 -0700 To: Steve Lord cc: linux-xfs@oss.sgi.com Subject: Re: FS Steves [Totally OT] In-Reply-To: Your message of "Sun, 14 Oct 2001 12:41:23 CDT." <200110141741.f9EHfNc01025@jen.americas.sgi.com> Date: Sun, 14 Oct 2001 10:58:15 -0700 From: erich@uruk.org Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: > > So who's the best filesystem Steve, Best or Lord? Best implies being > > the best, but it's hard to be better than a Lord I would imagine. > > > > I know it's just coincidence but I always get a chuckle about the > > implications of these two Steves' names. :) > > But no one escapes from Tweedies chicken farm! > > Lets see if someone can get that reference ;-) Stephen Tweedie and of course Chicken Run (awesome movie! if you want obscure you should try for something hackers wouldn't have seen... ;-) -- Erich Stefan Boleyn http://www.uruk.org/ "Reality is truly stranger than fiction; Probably why fiction is so popular" From owner-linux-xfs@oss.sgi.com Sun Oct 14 11:20:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9EIKJv14073 for linux-xfs-outgoing; Sun, 14 Oct 2001 11:20:19 -0700 Received: from zorak.illusionary.lan (653230hfc08.tampabay.rr.com [65.32.30.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9EIKFD14051 for ; Sun, 14 Oct 2001 11:20:15 -0700 Received: from illusionary.com (wraith [192.168.10.10]) by zorak.illusionary.lan (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id OAA07823 for ; Sun, 14 Oct 2001 14:20:09 -0400 X-Authentication-Warning: zorak.illusionary.lan: Host wraith [192.168.10.10] claimed to be illusionary.com Message-ID: <3BC9D74E.A2F61952@illusionary.com> Date: Sun, 14 Oct 2001 14:19:58 -0400 From: Derek Glidden X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.12-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Linux XFS Mailing List Subject: Re: FS Steves [Totally OT] References: <200110141741.f9EHfNc01025@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: > > > So who's the best filesystem Steve, Best or Lord? Best implies being > > the best, but it's hard to be better than a Lord I would imagine. > > > > I know it's just coincidence but I always get a chuckle about the > > implications of these two Steves' names. :) > > But no one escapes from Tweedies chicken farm! > > Lets see if someone can get that reference ;-) I might have had to think about that except our local public TV station just played a fantastic mini-documentary about Nick Park and Aardman Animation. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- With Microsoft products, failure is not an option -- it's a standard component. Choose your life. Choose your future. Derek Glidden Choose Linux. http://www.illusionary.com/ From owner-linux-xfs@oss.sgi.com Sun Oct 14 13:43:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9EKh2r16322 for linux-xfs-outgoing; Sun, 14 Oct 2001 13:43:02 -0700 Received: from ctgw.lbsd.net (ctgw.lbsd.net [196.25.111.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9EKgqD16297 for ; Sun, 14 Oct 2001 13:42:53 -0700 Received: from localhost (nkukard@localhost) by ctgw.lbsd.net (8.9.3/8.8.7) with ESMTP id WAA15130 for ; Sun, 14 Oct 2001 22:42:45 +0200 Date: Sun, 14 Oct 2001 22:42:45 +0200 (SAST) From: Nigel Kukard To: Linux XFS Mailing List Subject: total / partial fs corruption Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, ok, i'm 100% stumped now... i've tried the following... 1. 2.4.12 + XFS (2001-10-11) SMP - egcs 2. 2.4.12 + XFS (2001-10-11) SMP - gcc 2.96 3. 2.4.12 + XFS (2001-10-11) SMP - gcc 3.0.1 4. 2.4.12 + XFS (2001-10-11) - egcs 5. 2.4.12 + XFS (2001-10-11) - gcc 2.96 6. 2.4.12 + XFS (2001-10-11) - gcc 3.0.1 all with the same result, total root fs corruption on rebooting (random number reboots), Keith Owens pointed out it could be the partition problem the kernel was having & sent me a 2.4.12 => 2.4.13pre2+XFS patch, i applied it and tried the following.... 7. 2.4.13pre2 + XFS (?) SMP - egcs 8. 2.4.13pre2 + XFS (?) SMP - gcc 2.96 9. 2.4.13pre2 + XFS (?) SMP - gcc 3.0.1 10. 2.4.13pre2 + XFS (?) - egcs 11. 2.4.13pre2 + XFS (?) - gcc 2.96 12. 2.4.13pre2 + XFS (?) - gcc 3.0.1 still all to no avail, i've also tried using the 2.4.12 XFS patch on 2.4.13pre2 with a few modifications... still same result. ext2fs works fine aswell as reiserfs, so i'm 100% certain the bug is in XFS. all the above 12 test cases i preformed on multiple different servers, amd aswell as intel, diff motherboards , different ram, different harddrives. here is a list of software installed.... mount-2.11g xfsdump-1.1.3 xfsprogs-1.3.7 quota-3.01 acl-1.1.3 attr-1.1.3 dmapi-0.2.2 there are 3 partitions on the harddrive apon install... /dev/hda1 - 8Mb /boot (XFS) /dev/hda2 - 128Mb swap (SWAP2) /dev/hda3 - / (XFS) fstab has the following entries... /dev/hda1 /boot xfs defaults 2 0 /dev/hda2 none swap defaults 0 0 /dev/hda3 / xfs defaults 1 0 none /proc proc defaults 0 0 i'm using devfs, with automount enabled... fstab wouldn't matter cause nothing reads it before the error happens, 99% of the time devfs won't even mount cause there is no more directory structure on the hdd due to corruption. any help whatsoever would be very greatly appreciated! Nigel -- ================================================================================ Contact Details --------------- Name: Nigel Kukard GSM Mobile: (+27) 082 564 2120 GSM Fax: (+27) 082 131 564 2120 Email: nkukard@linuxrulz.za.net Organizations ------------- - LinuxRulz Url: http://www.linuxrulz.za.net Position: Owner - Linux Based Systems Design Url: http://www.lbsd.net Position: Systems Designer, Programmer - Lando Technologies Url: http://www.lando.co.za Position: Linux Systems/Network Administrator From owner-linux-xfs@oss.sgi.com Sun Oct 14 14:14:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ELEXl16926 for linux-xfs-outgoing; Sun, 14 Oct 2001 14:14:33 -0700 Received: from ctgw.lbsd.net (ctgw.lbsd.net [196.25.111.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ELEND16904 for ; Sun, 14 Oct 2001 14:14:23 -0700 Received: from localhost (nkukard@localhost) by ctgw.lbsd.net (8.9.3/8.8.7) with ESMTP id XAA15209; Sun, 14 Oct 2001 23:14:08 +0200 Date: Sun, 14 Oct 2001 23:14:08 +0200 (SAST) From: Nigel Kukard To: Seth Mos cc: Linux XFS Mailing List Subject: Re: total / partial fs corruption In-Reply-To: <4.3.2.7.2.20011014225217.02d4f460@pop.xs4all.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 14 Oct 2001, Seth Mos wrote: > At 22:42 14-10-2001 +0200, you wrote: > >Hi, > > > >ok, i'm 100% stumped now... i've tried the following... > > And so are we. ok.... /root/bin/panic --now > > Can you possibly try the tarball from the mandrake kernel to which I gave a > link earlier on the list. > sorry to sound stupid once again, could u resend the link? > >fstab has the following entries... > >/dev/hda1 /boot xfs defaults 2 0 > >/dev/hda2 none swap defaults 0 0 > >/dev/hda3 / xfs defaults 1 0 > >none /proc proc defaults 0 0 > > Please use defaults 0 0 > Can you try this it might work better, no guarantee though. We are waving > our hands in the air. We have not seen this before, you are the first with > this kind of corruption. We are absolutely baffled. > sure, i'll do the test now :) > > i'm using devfs, with automount enabled... fstab wouldn't matter > >cause nothing reads it before the error happens, 99% of the time > >devfs won't even mount cause there is no more directory structure > >on the hdd due to corruption. > > Have you tried without devfs as well??? > nope... that could pose a bit of a problem though, there is alot of stuff which depends on it apon boot. i've done a diff from 2.4.9 (as i don't think the bug was around then) and i've seen very little change in the devfs structure... i'll try it as a last resort. :) > >any help whatsoever would be very greatly appreciated! > >Nigel > > We are trying but we have no clue as of yet. Can you set one of them up for > remote access if possible? Or if you want to that is. I could help you > diagnose if you want me too or possibly ask one of the SGI people if you > trust them more. > urmmm, i can easily set the box up for remote access, BUT the problem only occurs on reboot and at that time it doesn't even hit INIT... let me know what u need and u got it :) ok, i'm just thinking.... maybe i can send u an ISO of the install cd for the distro, its about 320Mb though & i'm only on a 64kbps line. (very last resort) i'm out of town for a day (leaving in about 8 or 9 hrs) Nigel -- ================================================================================ Contact Details --------------- Name: Nigel Kukard GSM Mobile: (+27) 082 564 2120 GSM Fax: (+27) 082 131 564 2120 Email: nkukard@linuxrulz.za.net Organizations ------------- - LinuxRulz Url: http://www.linuxrulz.za.net Position: Owner - Linux Based Systems Design Url: http://www.lbsd.net Position: Systems Designer, Programmer - Lando Technologies Url: http://www.lando.co.za Position: Linux Systems/Network Administrator From owner-linux-xfs@oss.sgi.com Sun Oct 14 14:25:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ELPP717173 for linux-xfs-outgoing; Sun, 14 Oct 2001 14:25:25 -0700 Received: from ctgw.lbsd.net (ctgw.lbsd.net [196.25.111.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ELPJD17151 for ; Sun, 14 Oct 2001 14:25:19 -0700 Received: from localhost (nkukard@localhost) by ctgw.lbsd.net (8.9.3/8.8.7) with ESMTP id XAA15230 for ; Sun, 14 Oct 2001 23:25:12 +0200 Date: Sun, 14 Oct 2001 23:25:11 +0200 (SAST) From: Nigel Kukard To: Linux XFS Mailing List Subject: Total fs corruption Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, could sumone plz install XFS as a root filesystem on a testbox, and reboot about 7 times, add quotas & reboot again... try doing a few halts inbetween. (kernel 2.4.12 + XFS) as far as i know u won't get past 5 reboots Kind Regards Nigel -- ================================================================================ Contact Details --------------- Name: Nigel Kukard GSM Mobile: (+27) 082 564 2120 GSM Fax: (+27) 082 131 564 2120 Email: nkukard@linuxrulz.za.net Organizations ------------- - LinuxRulz Url: http://www.linuxrulz.za.net Position: Owner - Linux Based Systems Design Url: http://www.lbsd.net Position: Systems Designer, Programmer - Lando Technologies Url: http://www.lando.co.za Position: Linux Systems/Network Administrator From owner-linux-xfs@oss.sgi.com Sun Oct 14 14:58:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ELwBE17694 for linux-xfs-outgoing; Sun, 14 Oct 2001 14:58:11 -0700 Received: from ctgw.lbsd.net (ctgw.lbsd.net [196.25.111.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ELvqD17671 for ; Sun, 14 Oct 2001 14:57:52 -0700 Received: from localhost (nkukard@localhost) by ctgw.lbsd.net (8.9.3/8.8.7) with ESMTP id XAA15294 for ; Sun, 14 Oct 2001 23:57:40 +0200 Date: Sun, 14 Oct 2001 23:57:40 +0200 (SAST) From: Nigel Kukard To: Linux XFS Mailing List Subject: most stable kernel + XFS version? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, which would the developers choose as being the most stable kernel version to use on a production server? let me try that and see if i have the same problem and work from there. -Nigel -- ================================================================================ Contact Details --------------- Name: Nigel Kukard GSM Mobile: (+27) 082 564 2120 GSM Fax: (+27) 082 131 564 2120 Email: nkukard@linuxrulz.za.net Organizations ------------- - LinuxRulz Url: http://www.linuxrulz.za.net Position: Owner - Linux Based Systems Design Url: http://www.lbsd.net Position: Systems Designer, Programmer - Lando Technologies Url: http://www.lando.co.za Position: Linux Systems/Network Administrator From owner-linux-xfs@oss.sgi.com Sun Oct 14 15:05:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9EM5AB17944 for linux-xfs-outgoing; Sun, 14 Oct 2001 15:05:10 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9EM56D17921 for ; Sun, 14 Oct 2001 15:05:06 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id PAA05084 for ; Sun, 14 Oct 2001 15:04:11 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) 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 IAA01561; Mon, 15 Oct 2001 08:03:47 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA67289; Mon, 15 Oct 2001 09:03:47 +1100 (AEDT) Date: Mon, 15 Oct 2001 09:03:46 +1100 From: Nathan Scott To: Keith Owens Cc: "Bernhard R. Erdmann" , linux-xfs@oss.sgi.com Subject: Re: include/acl.h in 2.4.13-pre2 Message-ID: <20011015090346.A506869@wobbly.melbourne.sgi.com> References: <3BC98090.BA78FC5A@berdmann.de> <2217.1003062220@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <2217.1003062220@ocs3.intra.ocs.com.au>; from kaos@melbourne.sgi.com on Sun, Oct 14, 2001 at 10:23:40PM +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Oct 14, 2001 at 10:23:40PM +1000, Keith Owens wrote: > On Sun, 14 Oct 2001 14:09:52 +0200, > >Steve Lord wrote: > >> > >> Try running make dep, it all builds for me. > > > >I did (make mrproper, cp some/where/.config ., make oldconfig, make dep > >clean bzImage modules modules_install), but it fails to compile on RH > >6.1/6.2. > >On RH 7.1 all is ok as you reported. > > Arrgh! RH 7.1 is picking up /usr/include/linux/acl.h which is a real > file. On RH 6 usr/include/linux is normally a symlink to > /usr/src/linux so you get different files depending on which kernel you > have installed. Linus has fought against this for ages because it > generated wierd kernels, most distributions now ship a copy of the > files in /usr/include/linux instead of symlinking to some random > kernel. > > I guess that Nathan's build was on a system which had a real file for > /usr/include/linux/acl.h so he did not get a compile error. No, the problem was that I only did builds with CONFIG_POSIX_ACL enabled, so for me this file (noposix_acl.c) was never built, so was not updated. The correct fix, as Bernhard suggested, is to simply remove the include line. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Oct 14 15:19:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9EMJmA18318 for linux-xfs-outgoing; Sun, 14 Oct 2001 15:19:48 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9EMJkD18296 for ; Sun, 14 Oct 2001 15:19:46 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA06342 for ; Sun, 14 Oct 2001 15:18:51 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id IAA01006 for linux-xfs@oss.sgi.com; Mon, 15 Oct 2001 08:18:27 +1000 (EST) Date: Mon, 15 Oct 2001 08:18:27 +1000 (EST) From: Nathan Scott Message-Id: <200110142218.IAA01006@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - acl.h Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Sun Oct 14 15:15:25 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:104766a linux/fs/noposix_acl.c - 1.2 cmd/xfstests/src/acl_get.c - 1.3 cmd/xfstests/src/acl_test.c - 1.5 - fix problems with includes now that our previous linux/acl.h has gone away. From owner-linux-xfs@oss.sgi.com Sun Oct 14 16:53:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ENrkW19713 for linux-xfs-outgoing; Sun, 14 Oct 2001 16:53:46 -0700 Received: from ente.berdmann.de (frnk-d514e1d6.dsl.mediaWays.net [213.20.225.214]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ENrcD19688 for ; Sun, 14 Oct 2001 16:53:39 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 15sv4U-0002Om-00; Mon, 15 Oct 2001 01:53:30 +0200 Message-ID: <3BCA2578.AEB7E47D@berdmann.de> Date: Mon, 15 Oct 2001 01:53:28 +0200 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.13-pre2-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Nigel Kukard CC: Linux XFS Mailing List Subject: Re: Total fs corruption References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > could sumone plz install XFS as a root filesystem on a testbox, and reboot > about 7 times, add quotas & reboot again... try doing a few halts inbetween. > (kernel 2.4.12 + XFS) > > as far as i know u won't get past 5 reboots I'd very like to perform this procedure but I'm afraid not to have any results before tomorrow evening. Please tell me how to add quotas. In one of your posting you told us about a 20 MB /boot and a 19 GB / filesystem. I wouldn't be happy with this setup. Just a Root-FS and if it's gone - you know best... ;-) Every server system I set up for the last several years had a small (200-500 MB) / fs and everything else was divided up into separate filesystems (/var, /tmp, /usr, /usr/local, /var/spool/news, /var/spool/squid, /home, /scratch, /tftp, etc.). I've always installed a Linux+XFS server system with ext2fs on /. Well, I really trust XFS and it's a great contribution of SGI to the Linux community and it's really pushing Linux near the line where commercial Unixes like AIX tend to begin. But I wouldn't hire XFS as a babysitter for my (nonexisting) children in it's current state of Linux development. Too much is a moving target. I've been bitten twice by it: a) a corruption of access modes when XFS fs were mounted via NFS and b) a kernel panic when trying to mount XFS with a corrupted log. One problem with several hardlinks in Cyrus' IMAP spool and incremental xfsdumps is still unresolved. But all my recently installed servers have XFS (and most of them LVM) except for the / fs. No, not for the / fs. This is my holy filesystem. ext2fs has done with Linux for years. If everything crashes, I still want to be able to boot off a floppy disc like Tom's Root Boot, mount the former / fs and to do "vi etc/passwd" or "vi etc/rc.d/rc.sysinit". And I want to be able to copy a new initrd image onto it and do "chroot . sbin/lilo" or to mkfs the / fs in case everything went hell or the hardware changed or to use ifconfig/netcat/dd/amrestore/restore to get it quickly off my Amanda tapes. (Same applies to LVM - great, but not for my holy / fs.) You spent a whole weekend with something trashing your 19 GB / fs after ten reboots and didn't find any answer. It's time to use a different solution. Maybe you want to take the pragmatic approach and reduce / to 200 MB on ext2fs. From owner-linux-xfs@oss.sgi.com Sun Oct 14 17:04:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9F04qf20023 for linux-xfs-outgoing; Sun, 14 Oct 2001 17:04:52 -0700 Received: from ctgw.lbsd.net (ctgw.lbsd.net [196.25.111.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9F04cD19992 for ; Sun, 14 Oct 2001 17:04:39 -0700 Received: from localhost (nkukard@localhost) by ctgw.lbsd.net (8.9.3/8.8.7) with ESMTP id CAA15553; Mon, 15 Oct 2001 02:04:26 +0200 Date: Mon, 15 Oct 2001 02:04:26 +0200 (SAST) From: Nigel Kukard To: "Bernhard R. Erdmann" cc: Linux XFS Mailing List Subject: Re: Total fs corruption In-Reply-To: <3BCA2578.AEB7E47D@berdmann.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 15 Oct 2001, Bernhard R. Erdmann wrote: > > could sumone plz install XFS as a root filesystem on a testbox, and reboot > > about 7 times, add quotas & reboot again... try doing a few halts inbetween. > > (kernel 2.4.12 + XFS) > > > > as far as i know u won't get past 5 reboots > > I'd very like to perform this procedure but I'm afraid not to have any > results before tomorrow evening. Please tell me how to add quotas. > man quota; man setquota > In one of your posting you told us about a 20 MB /boot and a 19 GB / > filesystem. I wouldn't be happy with this setup. Just a Root-FS and if > it's gone - you know best... ;-) > > Every server system I set up for the last several years had a small > (200-500 MB) / fs and everything else was divided up into separate > filesystems (/var, /tmp, /usr, /usr/local, /var/spool/news, > /var/spool/squid, /home, /scratch, /tftp, etc.). > out of the question, our servers space requirements change drastically, very much easier for us to have /boot small & / with the rest on. guess everyone has their own views. lets not argue :) > I've always installed a Linux+XFS server system with ext2fs on /. Well, > I really trust XFS and it's a great contribution of SGI to the Linux > community and it's really pushing Linux near the line where commercial > Unixes like AIX tend to begin. But I wouldn't hire XFS as a babysitter > for my (nonexisting) children in it's current state of Linux > development. Too much is a moving target. I've been bitten twice by it: > a) a corruption of access modes when XFS fs were mounted via NFS and b) > a kernel panic when trying to mount XFS with a corrupted log. One > problem with several hardlinks in Cyrus' IMAP spool and incremental > xfsdumps is still unresolved. > > But all my recently installed servers have XFS (and most of them LVM) > except for the / fs. > i actually want to switch to lvm, still researching it on the installer side. > No, not for the / fs. This is my holy filesystem. ext2fs has done with > Linux for years. If everything crashes, I still want to be able to boot > off a floppy disc like Tom's Root Boot, mount the former / fs and to do > "vi etc/passwd" or "vi etc/rc.d/rc.sysinit". And I want to be able to > copy a new initrd image onto it and do "chroot . sbin/lilo" or to mkfs > the / fs in case everything went hell or the hardware changed or to use > ifconfig/netcat/dd/amrestore/restore to get it quickly off my Amanda > tapes. (Same applies to LVM - great, but not for my holy / fs.) > > You spent a whole weekend with something trashing your 19 GB / fs after > ten reboots and didn't find any answer. It's time to use a different > solution. i have to find the problem, we have multi million $$ servers running with pure XFS filesystems. i've already released a notice to all our clients not to reboot the servers we have installed for them till we can track the problem down & release a fix. > > Maybe you want to take the pragmatic approach and reduce / to 200 MB on > ext2fs. can't use ext2fs, filesize limits. reiser is cr4p, i'll stick with XFS even if it takes me a month to find the bug (going over the sourcecode line by line). XFS has served me & my company well and i'm not gonna abandon it! :) Kind Regards Nigel -- ================================================================================ Contact Details --------------- Name: Nigel Kukard GSM Mobile: (+27) 082 564 2120 GSM Fax: (+27) 082 131 564 2120 Email: nkukard@linuxrulz.za.net Organizations ------------- - LinuxRulz Url: http://www.linuxrulz.za.net Position: Owner - Linux Based Systems Design Url: http://www.lbsd.net Position: Systems Designer, Programmer - Lando Technologies Url: http://www.lando.co.za Position: Linux Systems/Network Administrator From owner-linux-xfs@oss.sgi.com Sun Oct 14 17:05:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9F05UY20065 for linux-xfs-outgoing; Sun, 14 Oct 2001 17:05:30 -0700 Received: from ente.berdmann.de (frnk-d514e1d6.dsl.mediaWays.net [213.20.225.214]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9F05SD20043 for ; Sun, 14 Oct 2001 17:05:28 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 15svFx-0002U0-00; Mon, 15 Oct 2001 02:05:21 +0200 Message-ID: <3BCA2840.B50D9F72@berdmann.de> Date: Mon, 15 Oct 2001 02:05:20 +0200 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.13-pre2-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Nigel Kukard CC: Linux XFS Mailing List Subject: Re: most stable kernel + XFS version? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > which would the developers choose as being the most stable kernel version to > use on a production server? let me try that and see if i have the same > problem and work from there. I've several systems running well with 2.4.10-xfs. .11 and .12 didn't last long enough, so stay away. 2.4.7-xfs was ok as I remember. I'm just testing with 2.4.13-pre2-xfs. From owner-linux-xfs@oss.sgi.com Sun Oct 14 17:15:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9F0Fja20447 for linux-xfs-outgoing; Sun, 14 Oct 2001 17:15:45 -0700 Received: from ente.berdmann.de (frnk-d514e1d6.dsl.mediaWays.net [213.20.225.214]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9F0FeD20425 for ; Sun, 14 Oct 2001 17:15:40 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 15svPp-0002Y8-00; Mon, 15 Oct 2001 02:15:33 +0200 Message-ID: <3BCA2AA4.5A4E8DAF@berdmann.de> Date: Mon, 15 Oct 2001 02:15:32 +0200 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.13-pre2-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Nigel Kukard CC: Linux XFS Mailing List Subject: Re: Total fs corruption References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > out of the question, our servers space requirements change drastically, > very much easier for us to have /boot small & / with the rest on. guess > everyone has their own views. lets not argue :) it's time to use LVM... > i actually want to switch to lvm, still researching it on the installer > side. AFAIK there is only sucking SuSE (2/3 of installations in Germany) with LVM onboard. I always installed it by hand with several dump|restore parties. > can't use ext2fs, filesize limits. reiser is cr4p, i'll stick with XFS > even if it takes me a month to find the bug (going over the sourcecode > line by line). XFS has served me & my company well and i'm not gonna abandon > it! :) Someone told me about 100,000 lines - that's around 3,300 lines a day. From owner-linux-xfs@oss.sgi.com Sun Oct 14 17:22:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9F0MdN20639 for linux-xfs-outgoing; Sun, 14 Oct 2001 17:22:39 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9F0MZD20615 for ; Sun, 14 Oct 2001 17:22:35 -0700 Received: from ctgw.lbsd.net (ctgw.lbsd.net [196.25.111.97]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id RAA07339 for ; Sun, 14 Oct 2001 17:22:32 -0700 (PDT) mail_from (nkukard@lbsd.net) Received: from localhost (nkukard@localhost) by ctgw.lbsd.net (8.9.3/8.8.7) with ESMTP id CAA15579 for ; Mon, 15 Oct 2001 02:12:21 +0200 Date: Mon, 15 Oct 2001 02:12:21 +0200 (SAST) From: Nigel Kukard To: Linux XFS Mailing List Subject: Total fs corruption Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hrmmmm, i just read on the mailing list archive that doing this.... # mount -o remount,ro / is a very bad idea on XFS. could this possible cause corruption? -Nigel -- ================================================================================ Contact Details --------------- Name: Nigel Kukard GSM Mobile: (+27) 082 564 2120 GSM Fax: (+27) 082 131 564 2120 Email: nkukard@linuxrulz.za.net Organizations ------------- - LinuxRulz Url: http://www.linuxrulz.za.net Position: Owner - Linux Based Systems Design Url: http://www.lbsd.net Position: Systems Designer, Programmer - Lando Technologies Url: http://www.lando.co.za Position: Linux Systems/Network Administrator From owner-linux-xfs@oss.sgi.com Sun Oct 14 17:24:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9F0OPh20790 for linux-xfs-outgoing; Sun, 14 Oct 2001 17:24:25 -0700 Received: from trillium-hollow.org (IDENT:root@trillium-hollow.org [209.180.166.89]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9F0OLD20768 for ; Sun, 14 Oct 2001 17:24:21 -0700 Received: from erich (helo=trillium) by trillium-hollow.org with local-esmtp (Exim 3.20 #1) id 15svXY-0004Ja-00; Sun, 14 Oct 2001 17:23:32 -0700 To: Nigel Kukard cc: Linux XFS Mailing List Subject: Re: most stable kernel + XFS version? In-Reply-To: Your message of "Mon, 15 Oct 2001 02:05:20 +0200." <3BCA2840.B50D9F72@berdmann.de> Date: Sun, 14 Oct 2001 17:23:31 -0700 From: erich@uruk.org Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "Bernhard R. Erdmann" wrote: > > which would the developers choose as being the most stable kernel > > version to use on a production server? let me try that and see if > > i have the same problem and work from there. > > I've several systems running well with 2.4.10-xfs. .11 and .12 didn't > last long enough, so stay away. 2.4.7-xfs was ok as I remember. I'm just > testing with 2.4.13-pre2-xfs. I've been testing with 2.4.13-pre1-xfs (with the addition of the final partition patch off of the Linux Kernel list) and just now (since early morning) vanilla 2.4.13-pre2-xfs (that already has the final patch). My tests are simple, on my SMP box, do my normal work, but have a kernel build (" make clean; make -j 3 bzImage ") going 24/7 for some time. So far, everything is stable except for a possible very slow memory leak... (not sure about it, I'll report more later when I have some better numbers). -- Erich Stefan Boleyn http://www.uruk.org/ "Reality is truly stranger than fiction; Probably why fiction is so popular" From owner-linux-xfs@oss.sgi.com Sun Oct 14 17:29:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9F0T7A20964 for linux-xfs-outgoing; Sun, 14 Oct 2001 17:29:07 -0700 Received: from ctgw.lbsd.net (ctgw.lbsd.net [196.25.111.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9F0T0D20938 for ; Sun, 14 Oct 2001 17:29:01 -0700 Received: from localhost (nkukard@localhost) by ctgw.lbsd.net (8.9.3/8.8.7) with ESMTP id CAA15631 for ; Mon, 15 Oct 2001 02:28:58 +0200 Date: Mon, 15 Oct 2001 02:28:58 +0200 (SAST) From: Nigel Kukard To: Linux XFS Mailing List Subject: Re: Total fs corruption (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 15 Oct 2001, Bernhard R. Erdmann wrote: > > out of the question, our servers space requirements change drastically, > > very much easier for us to have /boot small & / with the rest on. guess > > everyone has their own views. lets not argue :) > > it's time to use LVM... yep, i've been wanting to switch for ages, just gotta see what files in /etc it needs ... etc, then i can add it into my very basic installer. :) > > can't use ext2fs, filesize limits. reiser is cr4p, i'll stick with XFS > > even if it takes me a month to find the bug (going over the sourcecode > > line by line). XFS has served me & my company well and i'm not gonna abandon > > it! :) > > Someone told me about 100,000 lines - that's around 3,300 lines a day. > oh well, its summin i have to do... can only improve XFS, maybe i'll get lucky (very unlikely) and fix summin... lol -Nigel -- ================================================================================ Contact Details --------------- Name: Nigel Kukard GSM Mobile: (+27) 082 564 2120 GSM Fax: (+27) 082 131 564 2120 Email: nkukard@linuxrulz.za.net Organizations ------------- - LinuxRulz Url: http://www.linuxrulz.za.net Position: Owner - Linux Based Systems Design Url: http://www.lbsd.net Position: Systems Designer, Programmer - Lando Technologies Url: http://www.lando.co.za Position: Linux Systems/Network Administrator From owner-linux-xfs@oss.sgi.com Sun Oct 14 18:37:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9F1bEb22174 for linux-xfs-outgoing; Sun, 14 Oct 2001 18:37:14 -0700 Received: from ctgw.lbsd.net (ctgw.lbsd.net [196.25.111.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9F1b7D22152 for ; Sun, 14 Oct 2001 18:37:08 -0700 Received: from localhost (nkukard@localhost) by ctgw.lbsd.net (8.9.3/8.8.7) with ESMTP id DAA15752 for ; Mon, 15 Oct 2001 03:37:04 +0200 Date: Mon, 15 Oct 2001 03:37:03 +0200 (SAST) From: Nigel Kukard To: Linux XFS Mailing List Subject: Total FS corruption - More info Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, here is the first tell-tail sign i get on the reboot before the "blank" hdd. (that is from the output of dmesg btw) . . xfs_create looping, dir ino 0x80, ino 0x6d09, ide0(3,3) . . the ONLY thing i did was this... a few shutdown -r now 's and shutdown -h now 's the thing which seemed to trigger it was... find / > /tmp/test and then a shutdown -r now after that command it b0rked out!! Nigel -- ================================================================================ Contact Details --------------- Name: Nigel Kukard GSM Mobile: (+27) 082 564 2120 GSM Fax: (+27) 082 131 564 2120 Email: nkukard@linuxrulz.za.net Organizations ------------- - LinuxRulz Url: http://www.linuxrulz.za.net Position: Owner - Linux Based Systems Design Url: http://www.lbsd.net Position: Systems Designer, Programmer - Lando Technologies Url: http://www.lando.co.za Position: Linux Systems/Network Administrator From owner-linux-xfs@oss.sgi.com Sun Oct 14 18:58:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9F1w5U22607 for linux-xfs-outgoing; Sun, 14 Oct 2001 18:58:05 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9F1vsD22584 for ; Sun, 14 Oct 2001 18:57:54 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id SAA22921 for ; Sun, 14 Oct 2001 18:57:50 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) 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 LAA02755; Mon, 15 Oct 2001 11:56:36 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA28923; Mon, 15 Oct 2001 12:56:35 +1100 (AEDT) Date: Mon, 15 Oct 2001 12:56:35 +1100 From: Nathan Scott To: Nigel Kukard Cc: linux-xfs@oss.sgi.com Subject: Re: total/partial fs corruption Message-ID: <20011015125635.F506869@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 nkukard@lbsd.net on Sun, Oct 14, 2001 at 01:37:19AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, This thread is all over the show - its hard to find somewhere to start trying to help, after all the suggestions and various experiments. Anyway, here goes... Some general notes - following from the large amount of success others have with XFS and the lack of any corruption showing up on developers boxes, you want to look very closely at "outside" influences, esp. the compiler version used to build the kernel and your hardware... as a starting point. You also want to do lots of cross checking to ensure the running kernel is the one you think it is and is built with the compiler you think it is. On Sun, Oct 14, 2001 at 01:37:19AM +0200, Nigel Kukard wrote: > Hi, > > i installed our distro for the 10th time or summin yesterday and rebooted a few > times, after about 3 reboots the entire / partition was blank... so i thought > ok, i must of done summin wrong... At this first point of corruption, you need to stop and take stock. Trying to mount this again, when known corrupted is a bad plan. There would have been a console message to the effect: "Structure XYZ is corrupt. Unmount and run xfs_repair." from XFS, and would have gone into forced shutdown mode for that filesystem. I think the unmount will still write out the unmount record, so the log doesn't need to be replayed (I haven't look at that code for awhile though, so not 100% there) and you must repair before attempting to mount again. > so i re-installed & rebooted a few times over, SAME thing!! > i then tried on another server, used a diff harddrive and totally > diff hardware. rebooted about 12 times, did a halt (got a few 990 errors?), and Again, you would have had console/syslog messages, and XFS has gone into forced shutdown for that filesystem. The (extremely useful!) "990" message really means "Filesystem is corrupted". > the harddrive was BLANK! (by blank i mean when i boot with a rescue cd and mount > it there is no files, no dirs nothing... blank). sum times after i find its > blank i reboot again & some files are on it, sometimes not. if i run xfs_check > or xfs_repair it seems to find alot of errors. > but what really gets me is next > to NO changes are made during a reboot & all FS's are unmounted. Hmm - small changes are made during reboot - an unmount log record is written for one, and the shutdown scripts themselves are possibly writing to / as you go through the shutdown phase too (creating or removing temporary files, creating/removing lock files, etc, etc). So, theres an opportunity for corruption at least. > i thought i'd fixed the problem when i compiled 2.4.12 (from 2.4.10), but i > enabled quota support & rebooted... BLANK! as i said before i have been getting > error 990's and once an in-memory data corruption. i must have you know the These will be accompanied by a console message, and Eric recently added additional diagnostics in here - I'm sure he'd be interested in seeing the exact error messages (cut&pasted) that you see. > ram is 100% ok, even tried different cpu's, ram modules, motherboards, hdd's > everything. this error is 100% reproducable. how you guys can reproduce it > i'm not entirely sure. i could understand it if i just turned off the pc while > it was working, but this is doing a proper reboot. :( > > i just ran xfs_check on it now, clean after i rebooted to find the hdd blank and > i get the following... hda1 = /boot, hda2 = 128Mb swap, hda3 = / > > > [root@localhost root]# xfs_check /dev/hda3 > bad directory data magic # 0x44510101 for dir ino 128 block 0 > no . entry for direcotry 128 > no .. entry for directory 128 [Should cut and paste the output - less typos that way. ;-)] The root inode is corrupt - this is certainly why you don't see any files after next mount. xfs_repair should be able to fix this, but sounds like your kernel will just do it again, so fixing the kernel is the major issue here. A few additional notes, might help here... For each of your experiments with new gcc versions, did you update the top level kernel Makefile every time? (seems obvious, but gotta ask - ensure you're definately building with the gcc version you expect). Double-check lilo.conf entries too. As to a known stable release of XFS - use the 1.0.1 installer if you can. It has binary kernels built and extensively tested with known good compiler versions. At 2.4.5(?) its a bit older now, but is a known-sane starting point, and removes the subtle issues involved with compiling your own kernel. For notes on enabling quota, read README.quota in xfsprogs also. The man pages you referenced are less extensive. As another data point, I have run XFS quota on my / and /build for many months now, without any corruption (and this is a development box, so it crashes in bizarre and wonderful ways, spends lots of time in kdb, and does lots of XFS recovery), so its more likely to be a symptom than an actual problem. Hope this helps. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Oct 14 19:08:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9F28VU22870 for linux-xfs-outgoing; Sun, 14 Oct 2001 19:08:31 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9F28RD22848 for ; Sun, 14 Oct 2001 19:08:27 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id TAA08060 for ; Sun, 14 Oct 2001 19:07:33 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) 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 MAA02828; Mon, 15 Oct 2001 12:07:09 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA31905; Mon, 15 Oct 2001 13:07:09 +1100 (AEDT) Date: Mon, 15 Oct 2001 13:07:08 +1100 From: Nathan Scott To: Nigel Kukard Cc: Linux XFS Mailing List Subject: Re: Total FS corruption - More info Message-ID: <20011015130708.H506869@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 nkukard@lbsd.net on Mon, Oct 15, 2001 at 03:37:03AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Oct 15, 2001 at 03:37:03AM +0200, Nigel Kukard wrote: > Hi, > > here is the first tell-tail sign i get on the reboot before the "blank" hdd. > (that is from the output of dmesg btw) > > . > . > xfs_create looping, dir ino 0x80, ino 0x6d09, ide0(3,3) 0x80 == 128, which is usally the root inode number. Could you dump out the inodes with xfs_db after you see this - something like: # xfs_db -r /dev/root xfs_db: sb xfs_db: print ... xfs_db: inode 0x80 xfs_db: print ... xfs_db: inode 0x6d09 xfs_db: print ... and send the full xfs_repair output after this too. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Oct 14 19:17:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9F2HjD23174 for linux-xfs-outgoing; Sun, 14 Oct 2001 19:17:45 -0700 Received: from ctgw.lbsd.net (ctgw.lbsd.net [196.25.111.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9F2HYD23146 for ; Sun, 14 Oct 2001 19:17:34 -0700 Received: from localhost (nkukard@localhost) by ctgw.lbsd.net (8.9.3/8.8.7) with ESMTP id EAA16103; Mon, 15 Oct 2001 04:17:23 +0200 Date: Mon, 15 Oct 2001 04:17:23 +0200 (SAST) From: Nigel Kukard To: Nathan Scott cc: Linux XFS Mailing List Subject: Re: Total FS corruption - More info In-Reply-To: <20011015130708.H506869@wobbly.melbourne.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-872635561-1003112243=:1797" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --8323328-872635561-1003112243=:1797 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 15 Oct 2001, Nathan Scott wrote: > On Mon, Oct 15, 2001 at 03:37:03AM +0200, Nigel Kukard wrote: > > Hi, > > > > here is the first tell-tail sign i get on the reboot before the "blank" hdd. > > (that is from the output of dmesg btw) > > > > . > > . > > xfs_create looping, dir ino 0x80, ino 0x6d09, ide0(3,3) > > 0x80 == 128, which is usally the root inode number. > > Could you dump out the inodes with xfs_db after you see this - > something like: > > # xfs_db -r /dev/root > xfs_db: sb > xfs_db: print > ... > xfs_db: inode 0x80 > xfs_db: print > ... > xfs_db: inode 0x6d09 > xfs_db: print > ... > > attatched in .tar.gz file of 3 outputs > and send the full xfs_repair output after this too. > if this is VERY VERY important let me know, i'll try sumone get it, i know it reports alot of problems so it might be hard for me to capture it. also taking into account the fs is mounted. > thanks. > > -- ================================================================================ Contact Details --------------- Name: Nigel Kukard GSM Mobile: (+27) 082 564 2120 GSM Fax: (+27) 082 131 564 2120 Email: nkukard@linuxrulz.za.net Organizations ------------- - LinuxRulz Url: http://www.linuxrulz.za.net Position: Owner - Linux Based Systems Design Url: http://www.lbsd.net Position: Systems Designer, Programmer - Lando Technologies Url: http://www.lando.co.za Position: Linux Systems/Network Administrator --8323328-872635561-1003112243=:1797 Content-Type: APPLICATION/x-gzip; name="xfs_db.tar.gz" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="xfs_db.tar.gz" H4sIANuayjsAA+1W226bQBD1834FylMq2dFeZjFY6idU/YA0sjAsBJmLw8Wh /fruBQJ26thN5VSR9kiJd4b1zNmZ9Rm6uF5Hm0ValJFwI+zPrgBMMHYBZtjg +JMQTmZ4yVzK5YrJNaEAfObga5A5Rls3QeU4s6osm7f2nXv+SdHp/q+c4TMs K3GXB0kaOl8d3IEPAhmfvCDKZay9qOq0LKSDGEdcVnnQSJs6t6JrRNHUX8yT IkuL7Z6M323TaDSSqRE0aS7uaqFyf5PRv4eNQ7iD2YrBijGHyssy3VmYrRSW HgV5k3qmF0fJD6LQgyjhxVHCN7jU6S9VNbcvxSYrw209HlhWqt/RO4q+dhNP 8Mola70t43hSt9PVj3Kxz4N6O26Ocnnjm4Ocz1WzyUfHrhJBJpmOHuVQp5z0 Tajme0gRXre6x0J1smizDLVycSvyXfPzCxou1v++6BZ/RDfRf+9KgntO/ymH Uf8xVfpPCVj9/wj8tf4DXnL+D0OA8PdOAVhhuqKnp4B34RSgsAJ8agr4lDDm XTAFjqOEb0TpNR6w/2oQkPODgHyCQYBPDIK7Td7d4wdp36vfWSPZzvVCF2Cu /4dlWzRzwzbOguTBwat7PCfeEuZkjh/sCLkiev2vN1fMcVb/YdR/rGYBIYwv rf5/BI71X0t/0WoR6LgHLmdAkZGriYpFLwIGHvguJaiavNtWU6VqjdLTCFMM QbTYUNdbAOZ04Qs3XtCQupxuMIliQFmZaHVQ+xn3mRRQVXf5dqJ0kHoySz4Y PqrqdrCYSdpTJC4Kkhc+VNIDkB4tNOqxr+JM+Mq0oyBLSUf9ZBvqQLEHSCr7 EJ8TivQbU29T7ip7p4OY/HERaJW8Ufx/yFv+1t+NKbCkoQnoVMbwTR5jeEMS ZYA+4vAdzxzfWFju21VlUonanC/Ng269C3VZOUqHOjDZERkzroRiuqQYxZO+ LmW9GaD4sJlP7dAOjJKp8aSk22waV/VjUIlovS96VmWQpUmRayKoLdJG+5/T qHnUqyitXs6Ere5bWFhYWFhYWFhYWFhYWFhYWFhYWFhYvBO/AYXH1LcAKAAA --8323328-872635561-1003112243=:1797-- From owner-linux-xfs@oss.sgi.com Sun Oct 14 19:22:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9F2MsL23354 for linux-xfs-outgoing; Sun, 14 Oct 2001 19:22:54 -0700 Received: from ctgw.lbsd.net (ctgw.lbsd.net [196.25.111.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9F2MkD23331 for ; Sun, 14 Oct 2001 19:22:47 -0700 Received: from localhost (nkukard@localhost) by ctgw.lbsd.net (8.9.3/8.8.7) with ESMTP id EAA16123; Mon, 15 Oct 2001 04:22:37 +0200 Date: Mon, 15 Oct 2001 04:22:37 +0200 (SAST) From: Nigel Kukard To: Nathan Scott cc: Linux XFS Mailing List Subject: Re: Total FS corruption - More info In-Reply-To: <20011015130708.H506869@wobbly.melbourne.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-860045397-1003112557=:1797" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --8323328-860045397-1003112557=:1797 Content-Type: TEXT/PLAIN; charset=US-ASCII > and send the full xfs_repair output after this too. > attatched, i used xfs_repair -nf /dev/hda3 on a readonly remount > thanks. > > -- ================================================================================ Contact Details --------------- Name: Nigel Kukard GSM Mobile: (+27) 082 564 2120 GSM Fax: (+27) 082 131 564 2120 Email: nkukard@linuxrulz.za.net Organizations ------------- - LinuxRulz Url: http://www.linuxrulz.za.net Position: Owner - Linux Based Systems Design Url: http://www.lbsd.net Position: Systems Designer, Programmer - Lando Technologies Url: http://www.lando.co.za Position: Linux Systems/Network Administrator --8323328-860045397-1003112557=:1797 Content-Type: APPLICATION/x-bzip2; name="xfs_repair.log.bz2" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="xfs_repair.log.bz2" QlpoOTFBWSZTWRw7zd0AAbJfgAQwUO//4iCBQAA//9/gQALc7uY1cSgNTU9T T1MJhIANAABoASQjRGUTak8hDENNAB6Tagk0qhqAyaaADQ0A0NABJFNPVT0x pkmk9QANAABpYIFZXEzbUqZm0gg0NxxkEEEEEEGpeYs7b24SHJMebXb8od3S BSQwIFUQK49pzrSuff+U6/rsNCeaTZShMSXGIUUUUUUKCQfjx+QkHticYp4c cSrpre69abuRrpSsc+bWte0wTnXuHpiy7UVC1cs0K3tFggJLYaIVAiT2VnGx TiBiCU6kWy1AR0AwXIQpe1oKoB97DCMVIaxMpxUNM93gSBgsZBO8hlQJo4eX dprcbmduHOOoZqpQmVFkGllSUjHUliMxlLPEpZ1YwpiLGjkCyQNfkBm7tN0m EkBM3RiuwofCxbySovGVfuPANJHY9Pzk8l56eY9kzOdSkdQFiJiJkETO0Uql K6MIBgUZMOAUGR1W2KJnHP8TqdawHAcun74cUJmnI3Plr6O5DInMyYdzJURT AtqOhZfSdFhM0B+IDQYZJBhf+BVixWDHhkqGRithMHuzz5ZyGkWl5xICmpil UtOGOy62owxRgeZKwobJlhzAxouCtoxfsQ4Pfp2m5q41dDWZM0+y02ZVlO2o XoCozM1gfkJAyS43dgas2SQbB6mDZFElqQQSz10C7aiCFXaEgi8YbCe5pkx0 9BjTA2d23hFRsqGmAka5DhaQqQG/L4Kv16Q7RwNTBlGUnIW6hUeCVuVY+idy iuw3ra3Cm9SM+XdbJ13TunM5DA44dtkaNri9MhWzh39Ihq9q7IxglQODmuH6 VUHAL8Rxhtsr/i7kinChIDh3m7o= --8323328-860045397-1003112557=:1797-- From owner-linux-xfs@oss.sgi.com Sun Oct 14 19:30:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9F2UwW23557 for linux-xfs-outgoing; Sun, 14 Oct 2001 19:30:58 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9F2UrD23535 for ; Sun, 14 Oct 2001 19:30:53 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9F2UkK26447 for ; Sun, 14 Oct 2001 19:30:46 -0700 Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA31722; Mon, 15 Oct 2001 12:29:29 +1000 (AEST) Date: Mon, 15 Oct 2001 12:29:29 +1000 From: Timothy Shimmin To: Steve Lord Cc: Nathan Straz , linux-xfs@oss.sgi.com, linux-ia64@linuxia64.org Subject: Re: SGI XFS 1.0.1-IA64 Preview Release 1 available for testing Message-ID: <20011015122928.I23760@boing.melbourne.sgi.com> References: <200110121524.f9CFO6w05257@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <200110121524.f9CFO6w05257@jen.americas.sgi.com>; from lord@sgi.com on Fri, Oct 12, 2001 at 10:24:06AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Nate, And did you not notice warnings on xfs_check .... pv# 837609. --Tim On Fri, Oct 12, 2001 at 10:24:06AM -0500, Steve Lord wrote: > > Nate, have you tried recovery testing - see PV 838706 from Keith > Owens. > > Steve > > > The first preview release of SGI XFS 1.0.1-IA64 is available at: > > > > ftp://oss.sgi.com/projects/xfs/download/testing/Release-1.0.1-IA64-PR1/ > > > > These files are currently undergoing BETA testing. > > > > RPMS/ Kernel RPMs based on: > > - Linux 2.4.9 (Linus's tree) > > - Trillian 2.4.9-010820 > > - XFS 2.4.9 010826 > > - kdb-v1.8a-2.4.9-ia64-010820 > > > > cmd_rpms/ Command RPMs built for IA64, including lvm tools > > cmd_tars/ Command tarballs built for IA64. The lvm tarball is source. > > > > configs/ The config file from the kernel RPMs. Please check these > > over to see if anything important is missing. > > > > patches/ A patch against Linux-2.4.9-ia64-010820. Separate patches are > > available in the source RPM. > > > > This kernel is built with 16k pages. > > > > An installer is not available at this time. We're still working on it. > > > > -- > > 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 Sun Oct 14 20:05:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9F35Io24223 for linux-xfs-outgoing; Sun, 14 Oct 2001 20:05:18 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9F35ED24200 for ; Sun, 14 Oct 2001 20:05:14 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9F359K26926 for ; Sun, 14 Oct 2001 20:05:09 -0700 Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id UAA17843; Sun, 14 Oct 2001 20:04:32 -0700 (PDT) Message-ID: <3BCA5170.8E42E346@sgi.com> Date: Sun, 14 Oct 2001 22:01:04 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: Nigel Kukard CC: Linux XFS Mailing List Subject: Re: most stable kernel + XFS version? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Nigel Kukard wrote: > > Hi, > > which would the developers choose as being the most stable kernel version to > use on a production server? let me try that and see if i have the same > problem and work from there. Well, 2.4.5 was the latest heavily tested formal release from us, look at the 1.0.1 release. Mandrake has also just released a 2.4.8-ac4-based kernel, and tested it heavily as well. You're playing with bleeding edge kernels... can you back up a version or two and see how it goes? How are you creating these systems, with what install method? (from other thread...) > i have to find the problem, we have multi million $$ servers running with > pure XFS filesystems. i've already released a notice to all our clients > not to reboot the servers we have installed for them till we can track the > problem down & release a fix. You have multi-million $$ filesystems running on linux-2.4.12? You're a brave(?) soul... -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Sun Oct 14 20:06:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9F361P24258 for linux-xfs-outgoing; Sun, 14 Oct 2001 20:06:01 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9F35wD24235 for ; Sun, 14 Oct 2001 20:05:58 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9F35qW23750 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Sun, 14 Oct 2001 20:05:52 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id FAA3261727 for ; Mon, 15 Oct 2001 05:05:13 +0200 (CEST) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id NAA00679; Mon, 15 Oct 2001 13:05:38 +1000 Date: Mon, 15 Oct 2001 13:05:38 +1000 From: Keith Owens Message-Id: <200110150305.NAA00679@sherman.melbourne.sgi.com> Subject: TAKE - Prevent XFS kernel code including files from outside the kernel Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Including files from outside the kernel is a bad idea, the same build gets different results depending on which files the distribution has in /usr/include. kbuild 2.5 globally prevents the kernel from including external files, in 2.4 it is optional and must be manually selected. Date: Sun Oct 14 19:59:21 PDT 2001 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:104769a linux/fs/Makefile - 1.37 linux/Makefile - 1.138 linux/fs/xfs/Makefile - 1.124 linux/fs/xfs/linux/Makefile - 1.44 linux/fs/pagebuf/Makefile - 1.5 linux/fs/xfs/dmapi/Makefile - 1.11 linux/fs/xfs_support/Makefile - 1.3 From owner-linux-xfs@oss.sgi.com Sun Oct 14 20:12:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9F3CFQ24532 for linux-xfs-outgoing; Sun, 14 Oct 2001 20:12:15 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9F3CBD24509 for ; Sun, 14 Oct 2001 20:12:11 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9F3C6K27033 for ; Sun, 14 Oct 2001 20:12:06 -0700 Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id UAA63835; Sun, 14 Oct 2001 20:11:33 -0700 (PDT) Message-ID: <3BCA5316.556CD4B9@sgi.com> Date: Sun, 14 Oct 2001 22:08:06 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: Nigel Kukard CC: Linux XFS Mailing List Subject: Re: Total FS corruption - More info References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Last time I saw this, it was on a >1TB filesystem, and the inode numbers had exceeded 32 bits (bad thing...) - mkfs.xfs has since changed to try to avoid this by choosing bigger inode sizes on large filesystems, which limits inode numbers (note: explanation of tricky XFS internals deleted) . This should only matter, though, on ~>1TB filesystems. If you can send the output of mkfs.xfs (or xfs_info on a mounted filesystem), I can make sure the automatic inode sizing hasn't gone awry on your 19G filesystem.... And I'll stress again that moving back to pre-2.4.10 would also be a big help in figuring out where the problem is. My confidence in 2.4.11/12 is not so great, there's just been no exposure yet. -Eric Nigel Kukard wrote: > xfs_create looping, dir ino 0x80, ino 0x6d09, ide0(3,3) -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Sun Oct 14 20:37:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9F3bkW24937 for linux-xfs-outgoing; Sun, 14 Oct 2001 20:37:46 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9F3bdD24915 for ; Sun, 14 Oct 2001 20:37:40 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with SMTP id f9F3bXW24461 for ; Sun, 14 Oct 2001 20:37:33 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA03227; Mon, 15 Oct 2001 13:36:17 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA34976; Mon, 15 Oct 2001 14:36:16 +1100 (AEDT) Date: Mon, 15 Oct 2001 14:36:16 +1100 From: Nathan Scott To: Nigel Kukard , Eric Sandeen Cc: Linux XFS Mailing List Subject: Re: Total FS corruption - More info Message-ID: <20011015143616.J506869@wobbly.melbourne.sgi.com> References: <20011015130708.H506869@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nkukard@lbsd.net on Mon, Oct 15, 2001 at 04:22:37AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Mon, Oct 15, 2001 at 04:22:37AM +0200, Nigel Kukard wrote: > > and send the full xfs_repair output after this too. > > attatched, i used xfs_repair -nf /dev/hda3 on a readonly remount This seems to confirm the root inode of this partition is indeed corrupt - there is a directory entry to an inode which has been marked as freed. > if this is VERY VERY important let me know, i'll try sumone get it, i know it > reports alot of problems so it might be hard for me to capture it. also taking > into account the fs is mounted. That's bad (that its mounted), since its also corrupted. Before you mount these filesystems, if they're corrupted, you _must_ first run xfs_repair (though you should also capture all the console output when the corruption first occurs and send it our way - we still haven't seen this). You also need a kernel which isn't going to corrupt them again straight away. So, what version of gcc was used to build this particular kernel? If not kgcc, you should install that, change the top level kernel Makefile to ensure kgcc is used (there is a big comment there), then boot from your rescue disk (eg. the XFS 1.0.1 CD) and run xfs_repair on the corrupt filesystems (saving the output somewhere). Without knowing exactly which kernel versions and which compiler was used to build the kernels which cause the initial corruption, we aren't going to make much progress here. On Sun, Oct 14, 2001 at 10:08:06PM -0500, Eric Sandeen wrote: > Last time I saw this, it was on a >1TB filesystem, and the inode numbers >From the xfs_db output it seems this is not the case: xfs_db: xfs_db: magicnum = 0x58465342 blocksize = 4096 dblocks = 4849621 cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Oct 14 20:41:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9F3fYp25099 for linux-xfs-outgoing; Sun, 14 Oct 2001 20:41:34 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9F3fVD25077 for ; Sun, 14 Oct 2001 20:41:31 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.6/8.11.6) id f9F3emQ17756; Sun, 14 Oct 2001 23:40:48 -0400 Date: Sun, 14 Oct 2001 23:40:47 -0400 From: Alan Eldridge To: pac@fortuitous.com Cc: SGI XFS Dev List Subject: Re: vmware compatiblity (slightly OT) Message-ID: <20011014234047.A17620@wwweasel.geeksrus.net> References: <20011011182134.A5027@bistro.marx> <20011011201458.A2899@wwweasel.geeksrus.net> <20011014143442.A25701@bistro.marx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011014143442.A25701@bistro.marx>; from pac@fortuitous.com on Sun, Oct 14, 2001 at 02:34:42PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >> You need a patch for the kernel modules. But it works. VMWare 3.0 works out >> of the box on everything I tried it on up to 2.4.10. > > Great! Speaking of the 3.0 beta, I couldnt find any plain english on their > pages about expiration dates: Does VMware 3.0 have a time-limitation? > How stable is te 3.0 product? 1. Beta expires in November. 2. Release version should ship RSN. 3. Extremely stable. 4. Larger memory requirements for guest OS (win2000 => 96M). 5. NAT networking added. 6. Big virtual disks (>2G). 7. Most annoying glitches are fixed. I alpha-tested for them. It's been a great evolution of the product, and I strongly recommend anyone who can afford to upgrade (dunno $$, I get the release free) to do so. It's quite a good product. FWIW VMWare is the ONLY commercial software package on Linux that I own or reccomend. -- Alan Eldridge from std_disclaimer import * From owner-linux-xfs@oss.sgi.com Sun Oct 14 22:17:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9F5Hov26667 for linux-xfs-outgoing; Sun, 14 Oct 2001 22:17:50 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9F5HlD26645 for ; Sun, 14 Oct 2001 22:17:47 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA03498 for ; Sun, 14 Oct 2001 22:17:44 -0700 (PDT) mail_from (kaos@melbourne.sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by nodin.corp.sgi.com (8.11.4/8.11.2/nodin-1.0) with ESMTP id f9F5GjC5031031; Sun, 14 Oct 2001 22:16:45 -0700 (PDT) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id F3703300095; Mon, 15 Oct 2001 15:16:43 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 8274298; Mon, 15 Oct 2001 15:16:43 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: sgi.bugs.xfs@engr.sgi.com Cc: linux-xfs@oss.sgi.com Subject: TAKE - Add MODULE_LICENSE() to XFS Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Oct 2001 15:16:37 +1000 Message-ID: <10808.1003122997@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Add MODULE_LICENSE("GPL") to XFS, also AUTHOR and DESCRIPTION where necessary. Date: Sun Oct 14 22:09:39 PDT 2001 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:104771a linux/fs/xfs/linux/xfs_super.c - 1.141 linux/fs/xfs_support/support.c - 1.5 From owner-linux-xfs@oss.sgi.com Mon Oct 15 00:12:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9F7Ctf29876 for linux-xfs-outgoing; Mon, 15 Oct 2001 00:12:55 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9F7CpD29854 for ; Mon, 15 Oct 2001 00:12:51 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id AAA09934 for ; Mon, 15 Oct 2001 00:12:47 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id RAA23021; Mon, 15 Oct 2001 17:12:45 +1000 Date: Mon, 15 Oct 2001 17:12:45 +1000 From: Keith Owens Message-Id: <200110150712.RAA23021@sherman.melbourne.sgi.com> Subject: TAKE - Remove IA64 unaligned accesses in xfs_repair Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Remove IA64 unaligned accesses in xfs_repair Date: Mon Oct 15 00:10:41 PDT 2001 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:104774a cmd/xfsprogs/include/libxfs.h - 1.4 cmd/xfsprogs/repair/dinode.c - 1.5 cmd/xfsprogs/libxfs/xfs_bmap_btree.c - 1.5 From owner-linux-xfs@oss.sgi.com Mon Oct 15 00:22:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9F7M2g30173 for linux-xfs-outgoing; Mon, 15 Oct 2001 00:22:02 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9F7LxD30151 for ; Mon, 15 Oct 2001 00:21:59 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id AAA08704 for ; Mon, 15 Oct 2001 00:21:05 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) 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 RAA04340; Mon, 15 Oct 2001 17:20:41 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA16451; Mon, 15 Oct 2001 18:20:40 +1100 (AEDT) Date: Mon, 15 Oct 2001 18:20:39 +1100 From: Nathan Scott To: Matthias Klose Cc: linux-xfs@oss.sgi.com Subject: Re: xfs & boot floppies Message-ID: <20011015182039.K506869@wobbly.melbourne.sgi.com> References: <15306.33903.824301.255024@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15306.33903.824301.255024@gargle.gargle.HOWL>; from doko@cs.tu-berlin.de on Mon, Oct 15, 2001 at 08:38:39AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Oct 15, 2001 at 08:38:39AM +0200, Matthias Klose wrote: > Hi, > > in the xfsprogs 1.3.10 changelog I see you can build xfs-enabled boot > floppies. Is this correct? yes. > Do you have some boot floppies around? > I don't, but others do - ask on the linux-xfs list for some pointers, or just search the XFS mail archive on oss.sgi.com. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Oct 15 00:34:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9F7YQx30502 for linux-xfs-outgoing; Mon, 15 Oct 2001 00:34:26 -0700 Received: from mailbox4.ucsd.edu (mailbox.ucsd.edu [132.239.1.56]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9F7YLD30480 for ; Mon, 15 Oct 2001 00:34:21 -0700 Received: from smtp.ucsd.edu (smtp.ucsd.edu [132.239.1.49]) by mailbox4.ucsd.edu (8.11.5/8.11.0) with ESMTP id f9F7YLV15992 for ; Mon, 15 Oct 2001 00:34:21 -0700 (PDT) Received: from there (dyn128-54-156-11.ucsd.edu [128.54.156.11]) by smtp.ucsd.edu (8.9.3/8.9.3) with SMTP id AAA18786 for ; Mon, 15 Oct 2001 00:34:21 -0700 (PDT) Message-Id: <200110150734.AAA18786@smtp.ucsd.edu> Content-Type: text/plain; charset="iso-8859-1" From: Jeff Davis To: linux-xfs@oss.sgi.com Subject: umount Segmentation fault Date: Mon, 15 Oct 2001 00:31:36 -0700 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I recently started using XFS on my linux computer for the root filesystem under 2.4.12 (I started using XFS on kernel 2.4.10). Let me say first that I like the filesystem very much and I really appreciate the great software. However, occasionally an unnerving message appears upon rebooting my system. There is no way for me to directly retrieve the message since it didn't appear in the logs, so I actually copied it by hand using pen/paper and typed it back out, so there might be slight typos. I included the error message at the end of this email. I am using linux-2.4.12-xfs-2001-10-11.patch on kernel 2.4.12. I would like to know where the problem exists (does it have to do directly with xfs code or utilities?), and if there is any more useful information I can provide. The subsequent remounting upon reboot causes XFS to go into recovery mode. I don't notice any problems afterward. Regards, Jeff Davis ---- My error message ---- Umounting local filesystems... invalid operand 0000 CPU: 0 EIP: 0100:[] Not tainted EFLAGS: 00010202 eax: 00000001 ebx: c1308c00 ecx: c1308c00 edx: 00000000 esi: 00000000 edi: 00000000 ebp: cb6d5330 esp: cd5b9aa8 ds: 0018 es: 0018 ss: 0018 Process umount (pid: 4644, stackpage=cd5b9000) Stack: c1308c00 00000000 00000000 cb6d5330 c1308c00 00000000 00000000 c1308c00 c0121316 c012892b c0121484 c1308c00 c1308c00 c0121596 c1308c00 00000000 cd5b9b1c 00000000 cb6d5330 00000000 00000001 c1308c00 cd5b9b1c 00000000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 8b 43 18 a8 20 74 02 0f 0b 8b 43 18 a8 40 74 02 0f 0b /etc/rc6.d/S40umountfs: line39 4644 Segmentation fault umount $FORCE -a -r done. From owner-linux-xfs@oss.sgi.com Mon Oct 15 00:47:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9F7l2330788 for linux-xfs-outgoing; Mon, 15 Oct 2001 00:47:02 -0700 Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9F7kwD30764 for ; Mon, 15 Oct 2001 00:46:58 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9F7lWNe064389; Mon, 15 Oct 2001 09:47:32 +0200 (CEST) Message-Id: <4.3.2.7.2.20011015094334.02d4e8a0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 15 Oct 2001 09:45:32 +0200 To: Jeff Davis , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: umount Segmentation fault In-Reply-To: <200110150734.AAA18786@smtp.ucsd.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 00:31 15-10-2001 -0700, Jeff Davis wrote: > I recently started using XFS on my linux computer for the root > filesystem >under 2.4.12 (I started using XFS on kernel 2.4.10). Let me say first that I >like the filesystem very much and I really appreciate the great software. >However, occasionally an unnerving message appears upon rebooting my system. >There is no way for me to directly retrieve the message since it didn't >appear in the logs, so I actually copied it by hand using pen/paper and typed >it back out, so there might be slight typos. I included the error message at >the end of this email. Can you run this output through ksymoops please? This will produce readable (for developers) output. > I am using linux-2.4.12-xfs-2001-10-11.patch on kernel 2.4.12. I > would like >to know where the problem exists (does it have to do directly with xfs code >or utilities?), and if there is any more useful information I can provide. What compiler did you use? If you are using redhat 7.x please use kgcc (gcc 2.91.66) > The subsequent remounting upon reboot causes XFS to go into > recovery mode. I >don't notice any problems afterward. Because it was not cleanly unmounted this is standard behaviour. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Mon Oct 15 02:01:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9F91Op32147 for linux-xfs-outgoing; Mon, 15 Oct 2001 02:01:24 -0700 Received: from s1.uklinux.net (ns1.uklinux.net [212.1.130.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9F91KD32119 for ; Mon, 15 Oct 2001 02:01:20 -0700 Received: from pyewacket.nic.uklinux.net (ppp-6a-196.3com.telinco.net [212.159.138.196]) by s1.uklinux.net (8.11.6/8.11.6) with ESMTP id f9F919909128; Mon, 15 Oct 2001 10:01:09 +0100 Envelope-To: linux-xfs@oss.sgi.com Received: from [127.0.0.1] (helo=there) by pyewacket.nic.uklinux.net with smtp (Exim 3.22 #1) id 15t3Pi-0001Sc-00; Mon, 15 Oct 2001 09:47:58 +0100 Content-Type: text/plain; charset="iso-8859-1" From: nic Reply-To: nic@uklinux.net Organization: Quixotic Hackers To: Keith Owens Subject: Re: Compilers (was Re: 2.4.11 don't work yet.) Date: Mon, 15 Oct 2001 09:47:58 +0100 X-Mailer: KMail [version 1.3.1] Cc: linux-xfs@oss.sgi.com References: <12144.1002906352@ocs3.intra.ocs.com.au> In-Reply-To: <12144.1002906352@ocs3.intra.ocs.com.au> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Friday 12 October 2001 18:05, Keith Owens wrote: > Did you compile your kernel with kdb? grep kdb_main System.map or look > for the kdb v1.9 startup line, near the start, after the Memory line. Apparently not. What a dork! ;-0 nic (updating to 2.4.13-pre2 and actually compiling kdb in...) From owner-linux-xfs@oss.sgi.com Mon Oct 15 02:13:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9F9DAN32400 for linux-xfs-outgoing; Mon, 15 Oct 2001 02:13:10 -0700 Received: from s1.uklinux.net (ns1.uklinux.net [212.1.130.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9F9D1D32376 for ; Mon, 15 Oct 2001 02:13:02 -0700 Received: from pyewacket.nic.uklinux.net (ppp-6a-196.3com.telinco.net [212.159.138.196]) by s1.uklinux.net (8.11.6/8.11.6) with ESMTP id f9F9BgF10161; Mon, 15 Oct 2001 10:11:42 +0100 Envelope-To: linux-xfs@oss.sgi.com Received: from [127.0.0.1] (helo=there) by pyewacket.nic.uklinux.net with smtp (Exim 3.22 #1) id 15t3nJ-0002kl-00; Mon, 15 Oct 2001 10:12:21 +0100 Content-Type: text/plain; charset="iso-8859-1" From: nic Reply-To: nic@uklinux.net Organization: Quixotic Hackers To: Nathan Scott , Nigel Kukard , Eric Sandeen Subject: Re: Total FS corruption - More info Date: Mon, 15 Oct 2001 10:12:21 +0100 X-Mailer: KMail [version 1.3.1] Cc: Linux XFS Mailing List References: <20011015130708.H506869@wobbly.melbourne.sgi.com> <20011015143616.J506869@wobbly.melbourne.sgi.com> In-Reply-To: <20011015143616.J506869@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Monday 15 October 2001 04:36, Nathan Scott wrote: > hi, > > On Mon, Oct 15, 2001 at 04:22:37AM +0200, Nigel Kukard wrote: > > > and send the full xfs_repair output after this too. > > > > attatched, i used xfs_repair -nf /dev/hda3 on a readonly remount > > This seems to confirm the root inode of this partition is indeed > corrupt - there is a directory entry to an inode which has been > marked as freed. > > > if this is VERY VERY important let me know, i'll try sumone get it, i > > know it reports alot of problems so it might be hard for me to capture > > it. also taking into account the fs is mounted. > > That's bad (that its mounted), since its also corrupted. > > Before you mount these filesystems, if they're corrupted, you > _must_ first run xfs_repair (though you should also capture all > the console output when the corruption first occurs and send it > our way - we still haven't seen this). You also need a kernel > which isn't going to corrupt them again straight away. Just for reference I've seen this (xfs_create looping) on /var on a small SMP box on about the 7th reboot after install (with stock SGI 1.0.1 release). boot -s; umount /var; xfs_repair repaired it fine though. Here's what was in /v/l/messaeges (line wrapping courtesy of kmail...) Sep 21 01:37:08 eeyore kernel: xfs_create looping, dir ino 0x800081, ino 0x80008a, ide0(3,8) Sep 21 01:37:08 eeyore kernel: Sep 21 01:37:08 eeyore kernel: ip_conntrack (4095 buckets, 32760 max) Sep 21 01:37:08 eeyore kernel: xfs_create looping, dir ino 0x800081, ino 0x80008b, ide0(3,8) Sep 21 01:37:08 eeyore kernel: [...] Sep 21 01:37:08 eeyore kernel: xfs_create looping, dir ino 0x800081, ino 0x80008c, ide0(3,8) Sep 21 01:37:08 eeyore kernel: Sep 21 01:37:08 eeyore kernel: xfs_create looping, dir ino 0x800081, ino 0x80008d, ide0(3,8) Sep 21 01:37:08 eeyore kernel: Sep 21 01:37:08 eeyore kernel: xfs_create looping, dir ino 0x800081, ino 0x80008e, ide0(3,8) Sep 21 01:37:08 eeyore kernel: Sep 21 01:37:08 eeyore rpc.statd[625]: Version 0.3.1 Starting Sep 21 01:37:08 eeyore nfslock: rpc.statd startup succeeded Sep 21 01:37:09 eeyore kernel: xfs_create looping, dir ino 0x800081, ino 0x80008f, ide0(3,8) Sep 21 01:37:09 eeyore kernel: Sep 21 01:37:09 eeyore keytable: Loading keymap: Sep 21 01:37:09 eeyore keytable: ^[[60G[ Sep 21 01:37:09 eeyore keytable: Sep 21 01:37:09 eeyore keytable: Loading system font: Sep 21 01:37:09 eeyore keytable: ^[[60G[ Sep 21 01:37:09 eeyore kernel: xfs_create looping, dir ino 0x800081, ino 0x800090, ide0(3,8) Sep 21 01:37:09 eeyore kernel: Sep 21 01:37:09 eeyore keytable: Sep 21 01:37:09 eeyore keytable: touch: creating `/var/lock/subsys/keytable': Unknown error 990 Sep 21 01:37:09 eeyore rc: Starting keytable: succeeded Sep 21 01:37:09 eeyore random: Initializing random number generator: succeeded Sep 21 01:37:10 eeyore kernel: xfs_create looping, dir ino 0x800081, ino 0x800092, ide0(3,8) Sep 21 01:37:10 eeyore kernel: Sep 21 01:37:10 eeyore kernel: xfs_create looping, dir ino 0x800081, ino 0x800093, ide0(3,8) Sep 21 01:37:10 eeyore kernel: [...] Sep 21 01:37:10 eeyore kernel: xfs_create looping, dir ino 0x800081, ino 0x800094, ide0(3,8) Sep 21 01:37:10 eeyore kernel: Sep 21 01:37:11 eeyore atd: atd startup succeeded Sep 21 01:37:11 eeyore kernel: xfs_create looping, dir ino 0x800081, ino 0x800095, ide0(3,8) Sep 21 01:37:11 eeyore kernel: Sep 21 01:37:11 eeyore automount[746]: using kernel protocol version 3 Sep 21 01:37:11 eeyore sshd: Starting sshd: Sep 21 01:37:11 eeyore sshd: succeeded Sep 21 01:37:11 eeyore sshd: ^[[60G[ Sep 21 01:37:11 eeyore kernel: xfs_create looping, dir ino 0x800081, ino 0x800096, ide0(3,8) Sep 21 01:37:11 eeyore kernel: nic From owner-linux-xfs@oss.sgi.com Mon Oct 15 03:40:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9FAe3101542 for linux-xfs-outgoing; Mon, 15 Oct 2001 03:40:03 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9FAdwD01516 for ; Mon, 15 Oct 2001 03:39:58 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9FAdqK01626 for ; Mon, 15 Oct 2001 03:39:52 -0700 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id UAA25819 for linux-xfs@oss.sgi.com; Mon, 15 Oct 2001 20:38:35 +1000 (EST) Date: Mon, 15 Oct 2001 20:38:35 +1000 (EST) From: Nathan Scott Message-Id: <200110151038.UAA25819@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - more xfsprogs unaligned accesses Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Should fix xfs_db/check unaligned access in addition to repair. Reworked Keiths earlier solution for xfs_repair slightly to be more friendly to the kernel/user code sharing regime. Tim, let me know if this doesn't fix the problems you were seeing earlier with xfs_check -- thanks. cheers. Date: Mon Oct 15 02:03:17 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:104779a cmd/xfsprogs/imap/xfs_imap.c - 1.2 - fix compiler warnings on 64 bit machines. Date: Mon Oct 15 03:34:04 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:104781a cmd/xfsprogs/include/libxfs.h - 1.5 - revert Keiths earlier change - have a lower impact fix. cmd/xfsprogs/repair/dinode.c - 1.6 - fix pointer alignment issues on IA64 in handling block map structures. almost exactly the same as Keiths earlier fix, but in a slightly different location, allowing the kernel-code-sharing mechanism to remain in place for xfs_bmbt_get_all. cmd/xfsprogs/libxfs/xfs_bmap_btree.c - 1.6 - revert Keiths earlier change - have a lower impact fix. cmd/xfsprogs/db/bmap.c - 1.2 - fix pointer alignment issues on IA64 in handling block map structures. From owner-linux-xfs@oss.sgi.com Mon Oct 15 03:46:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9FAkfJ01746 for linux-xfs-outgoing; Mon, 15 Oct 2001 03:46:41 -0700 Received: from gk.hm.epigenomics.net (qmailr@gk.hm.epigenomics.net [212.121.137.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9FAkcD01724 for ; Mon, 15 Oct 2001 03:46:38 -0700 Received: (qmail 31076 invoked from network); 15 Oct 2001 10:46:41 -0000 Received: from raman.epigenomics.epi (qmailr@192.168.2.2) by salam.epigenomics.epi with SMTP; 15 Oct 2001 10:46:41 -0000 Received: (qmail 5763 invoked from network); 15 Oct 2001 10:46:36 -0000 Received: from broglie.epigenomics.epi (qmailr@192.168.1.5) by raman.epigenomics.epi with SMTP; 15 Oct 2001 10:46:36 -0000 Received: (qmail 20929 invoked by uid 9); 15 Oct 2001 10:46:35 -0000 From: Robert Sander Reply-To: Robert Sander X-Newsgroups: epi.ml.linux.xfs Subject: backport to 2.2 Date: Mon, 15 Oct 2001 10:46:35 +0000 (UTC) Organization: Epigenomics AG Lines: 16 Message-ID: X-Complaints-To: usenet@epigenomics.com User-Agent: slrn/0.9.7.2 (Linux) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! Are there any thoughts about backporting XFS to the Linux kernel 2.2.19? The current non-stability of the 2.4 series makes it nearly impossible to run that great filesystem on production machines. Would it be very hard to do? Else we would have to switch back to ext2 losing the journaling option. Greetings -- Robert Sander Computer Scientist Epigenomics AG Bioinformatics R&D www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Mon Oct 15 04:10:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9FBAeX02459 for linux-xfs-outgoing; Mon, 15 Oct 2001 04:10:40 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9FBAYD02437 for ; Mon, 15 Oct 2001 04:10:34 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id NAA13377; Mon, 15 Oct 2001 13:10:30 +0200 (CEST) Message-Id: <4.3.2.7.2.20011015130838.02bca728@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 15 Oct 2001 13:09:09 +0200 To: Robert Sander , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: backport to 2.2 In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 10:46 15-10-2001 +0000, Robert Sander wrote: >Hi! > >Are there any thoughts about backporting XFS to the Linux kernel 2.2.19? No. >The current non-stability of the 2.4 series makes it nearly impossible >to run that great filesystem on production machines. At least difficult at times. >Would it be very hard to do? Else we would have to switch back to ext2 >losing the journaling option. Yes. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Mon Oct 15 04:48:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9FBmaX03280 for linux-xfs-outgoing; Mon, 15 Oct 2001 04:48:36 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9FBmWD03258 for ; Mon, 15 Oct 2001 04:48:33 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 32A761E535; Mon, 15 Oct 2001 13:48:18 +0200 (MEST) Date: Mon, 15 Oct 2001 13:48:16 +0200 From: Andi Kleen To: Robert Sander Cc: linux-xfs@oss.sgi.com Subject: Re: backport to 2.2 Message-ID: <20011015134816.A20094@gruyere.muc.suse.de> 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 ml-linux-xfs@epigenomics.com on Mon, Oct 15, 2001 at 10:46:35AM +0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Oct 15, 2001 at 10:46:35AM +0000, Robert Sander wrote: > Hi! > > Are there any thoughts about backporting XFS to the Linux kernel 2.2.19? > > The current non-stability of the 2.4 series makes it nearly impossible > to run that great filesystem on production machines. > > Would it be very hard to do? Else we would have to switch back to ext2 > losing the journaling option. It would be very hard, nearly like a new port of XFS. XFS and its pagebuf layer is heavily tied to the 2.4+ VM system and uses infrastructure that wasn't there in 2.2. -Andi From owner-linux-xfs@oss.sgi.com Mon Oct 15 04:52:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9FBqt503502 for linux-xfs-outgoing; Mon, 15 Oct 2001 04:52:55 -0700 Received: from gk.hm.epigenomics.net (qmailr@gk.hm.epigenomics.net [212.121.137.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9FBqqD03480 for ; Mon, 15 Oct 2001 04:52:52 -0700 Received: (qmail 31376 invoked from network); 15 Oct 2001 11:52:55 -0000 Received: from raman.epigenomics.epi (qmailr@192.168.2.2) by salam.epigenomics.epi with SMTP; 15 Oct 2001 11:52:55 -0000 Received: (qmail 1699 invoked from network); 15 Oct 2001 11:52:50 -0000 Received: from broglie.epigenomics.epi (qmailr@192.168.1.5) by raman.epigenomics.epi with SMTP; 15 Oct 2001 11:52:50 -0000 Received: (qmail 23533 invoked by uid 9); 15 Oct 2001 11:52:49 -0000 From: Robert Sander Reply-To: Robert Sander X-Newsgroups: epi.ml.linux.xfs Subject: Re: backport to 2.2 Date: Mon, 15 Oct 2001 11:52:49 +0000 (UTC) Organization: Epigenomics AG Lines: 19 Message-ID: References: <20011015134816.A20094@gruyere.muc.suse.de> X-Complaints-To: usenet@epigenomics.com User-Agent: slrn/0.9.7.2 (Linux) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 15 Oct 2001 11:50:44 +0000 (UTC), Andi Kleen wrote: > It would be very hard, nearly like a new port of XFS. XFS and its pagebuf > layer is heavily tied to the 2.4+ VM system and uses infrastructure that wasn't > there in 2.2. I see. And as the VM is causing most of the trouble in 2.4, how stable would you rate XFS? Tonight I will try the Mandrake 2.4.8 kernel (which already has the needed aacraid patch included), but when that one also fails, we have to revert to 2.2.19 and ext2. Greetings -- Robert Sander Computer Scientist Epigenomics AG Bioinformatics R&D www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Mon Oct 15 06:47:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9FDlnt05481 for linux-xfs-outgoing; Mon, 15 Oct 2001 06:47:49 -0700 Received: from musuko.uchicago.edu (musuko.uchicago.edu [128.135.39.147]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9FDlkD05457 for ; Mon, 15 Oct 2001 06:47:46 -0700 Received: (from sl70@localhost) by musuko.uchicago.edu (8.11.6/8.11.2) id f9FDljY23614 for linux-xfs@oss.sgi.com; Mon, 15 Oct 2001 08:47:45 -0500 Message-ID: X-Mailer: XFMail 1.5.1 on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Mon, 15 Oct 2001 08:47:45 -0500 (CDT) X-Face: &Uky;wivSfT_h6'<6F@p&7]0z";s~axe..-:6:`LzPD'SR:r<)-JK21yU$nl;AzQ#I2$.7' u-f5<2%'b`J3?k%s6[06tr"~;=I{55PYt9,(9dWmhR?0GQxAZSqc6c5@P/fCwpS]1gj<^6>"0{5_91 }w0qn/:dM}9SLlsZYv7JW_hGSk>2Z=&A9.AOX^Y\Qqu#D(H:+yv26dqcvi0l]r]/c){s0_')Wu;?[J ltVl;(?7*L_I$evHiHy%[FmUq#1y-hWg7^/ZQjl_S4lC.AvbyS`G5;M*fzYl+"_TJqw,"X;%XLbkHJ (k Reply-To: s-luppescu@uchicago.edu Organization: Univ of Chicago From: s-luppescu@uchicago.edu To: linux-xfs@oss.sgi.com Subject: A question about upgrading Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk In light of the immenent release of RedHat 7.2, will there be a release of the 7.2 installer modified for xfs as before? If not (and for those of us too impatient to wait for it), is there another way to upgrade our xfs systems? The standard RH install CDs will not work, will they? Is there anything to do besides update all the RPMs by hand (yuchh)? Thanks. ______________________________________________________________________ Stuart Luppescu -=-=- University of Chicago $(B:MJ8$HCRF`H~$NIc(B -=-=- s-luppescu@uchicago.edu http://www.consortium-chicago.org/people/sl.html http://musuko.uchicago.edu/pubkey.asc for PGP Public Key ICQ #21172047 AIM: psycho7070 Let me do my TRIBUTE to FISHNET STOCKINGS ... >> Sent on 15-Oct-2001 at 08:43:10 with xfmail From owner-linux-xfs@oss.sgi.com Mon Oct 15 07:11:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9FEBQM06100 for linux-xfs-outgoing; Mon, 15 Oct 2001 07:11:26 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9FEBLD06078 for ; Mon, 15 Oct 2001 07:11:21 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9FEBGK07550 for ; Mon, 15 Oct 2001 07:11:16 -0700 Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA76087; Mon, 15 Oct 2001 07:10:44 -0700 (PDT) Message-ID: <3BCAED91.65585AD1@sgi.com> Date: Mon, 15 Oct 2001 09:07:13 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: s-luppescu@uchicago.edu CC: linux-xfs@oss.sgi.com Subject: Re: A question about upgrading References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk s-luppescu@uchicago.edu wrote: > > In light of the immenent release of RedHat 7.2, will there be a release of the > 7.2 installer modified for xfs as before? A couple people inside & outside the company are working on that... no formal release date available. > If not (and for those of us too > impatient to wait for it), is there another way to upgrade our xfs systems? The > standard RH install CDs will not work, will they? No, probably not. > Is there anything to do > besides update all the RPMs by hand (yuchh)? If you spin your own boot floppy with everything you need in the kernel, perhaps the installer would proceed (as long as anaconda doesn't check filesystem types before mounting - if so, you'd also need to create an updates disk with tweaked anacona files). This is probably the only option besides doing a complete installer, and that's just off the top of my head. The devil's in the details, of course... Just hang on a while; we'll take care of you. :) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Oct 15 07:12:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9FECnX06245 for linux-xfs-outgoing; Mon, 15 Oct 2001 07:12:49 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9FEClD06222 for ; Mon, 15 Oct 2001 07:12:47 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9FECfK07604 for ; Mon, 15 Oct 2001 07:12:41 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA3310620; Mon, 15 Oct 2001 09:11:25 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA36884; Mon, 15 Oct 2001 09:11:25 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9FE9IH28491; Mon, 15 Oct 2001 09:09:18 -0500 Message-Id: <200110151409.f9FE9IH28491@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: s-luppescu@uchicago.edu cc: linux-xfs@oss.sgi.com Subject: Re: A question about upgrading In-Reply-To: Message from s-luppescu@uchicago.edu of "Mon, 15 Oct 2001 08:47:45 CDT." Date: Mon, 15 Oct 2001 09:09:18 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > In light of the immenent release of RedHat 7.2, will there be a release of th > e > 7.2 installer modified for xfs as before? If not (and for those of us too > impatient to wait for it), is there another way to upgrade our xfs systems? T > he > standard RH install CDs will not work, will they? Is there anything to do > besides update all the RPMs by hand (yuchh)? > > Thanks. > ______________________________________________________________________ There is installer work ongoing, Martin Peterson was taking a crack at this, I will have to let him fill you in on his progress. Steve From owner-linux-xfs@oss.sgi.com Mon Oct 15 07:26:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9FEQv506664 for linux-xfs-outgoing; Mon, 15 Oct 2001 07:26:57 -0700 Received: from musuko.uchicago.edu (musuko.uchicago.edu [128.135.39.147]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9FEQsD06642 for ; Mon, 15 Oct 2001 07:26:54 -0700 Received: (from sl70@localhost) by musuko.uchicago.edu (8.11.6/8.11.2) id f9FEQoj23758; Mon, 15 Oct 2001 09:26:50 -0500 Message-ID: X-Mailer: XFMail 1.5.1 on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3BCAED91.65585AD1@sgi.com> Date: Mon, 15 Oct 2001 09:26:50 -0500 (CDT) X-Face: &Uky;wivSfT_h6'<6F@p&7]0z";s~axe..-:6:`LzPD'SR:r<)-JK21yU$nl;AzQ#I2$.7' u-f5<2%'b`J3?k%s6[06tr"~;=I{55PYt9,(9dWmhR?0GQxAZSqc6c5@P/fCwpS]1gj<^6>"0{5_91 }w0qn/:dM}9SLlsZYv7JW_hGSk>2Z=&A9.AOX^Y\Qqu#D(H:+yv26dqcvi0l]r]/c){s0_')Wu;?[J ltVl;(?7*L_I$evHiHy%[FmUq#1y-hWg7^/ZQjl_S4lC.AvbyS`G5;M*fzYl+"_TJqw,"X;%XLbkHJ (k Reply-To: s-luppescu@uchicago.edu Organization: Univ of Chicago From: s-luppescu@uchicago.edu To: Eric Sandeen Subject: Re: A question about upgrading Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 15-Oct-2001 Eric Sandeen wrote: > s-luppescu@uchicago.edu wrote: >> >> In light of the immenent release of RedHat 7.2, will there be a release of >> the >> 7.2 installer modified for xfs as before? [snip] > Just hang on a while; we'll take care of you. :) OK! Just as long as I know it's coming, I can wait. ______________________________________________________________________ Stuart Luppescu -=-=- University of Chicago $(B:MJ8$HCRF`H~$NIc(B -=-=- s-luppescu@uchicago.edu http://www.consortium-chicago.org/people/sl.html http://musuko.uchicago.edu/pubkey.asc for PGP Public Key ICQ #21172047 AIM: psycho7070 Bounders get bound when they are caught bounding. -- Ralph Lewin >> Sent on 15-Oct-2001 at 09:25:42 with xfmail From owner-linux-xfs@oss.sgi.com Mon Oct 15 07:44:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9FEi1t07185 for linux-xfs-outgoing; Mon, 15 Oct 2001 07:44:01 -0700 Received: from rover (rover.mkp.net [209.217.122.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9FEhuD07161 for ; Mon, 15 Oct 2001 07:43:56 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=jaguar.mkp.net) by rover with esmtp (Exim 3.33 #1) id 15t8yA-0001AU-00; Mon, 15 Oct 2001 10:43:55 -0400 Received: (from mkp@localhost) by jaguar.mkp.net (8.11.2/8.9.3) id f9FEhpo05407; Mon, 15 Oct 2001 10:43:51 -0400 X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f To: s-luppescu@uchicago.edu Cc: linux-xfs@oss.sgi.com Subject: Re: A question about upgrading References: <200110151409.f9FE9IH28491@jen.americas.sgi.com> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 15 Oct 2001 10:43:50 -0400 In-Reply-To: <200110151409.f9FE9IH28491@jen.americas.sgi.com> Message-ID: Lines: 25 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>>>> "Steve" == Steve Lord writes: >> In light of the immenent release of RedHat 7.2, will there be a >> release of th e 7.2 installer modified for xfs as before? Steve> There is installer work ongoing, Martin Peterson was taking a Steve> crack at this, I will have to let him fill you in on his Steve> progress. Yep, I've been modifying anaconda 7.2 (the Red Hat installer) to support XFS. The code has changed a lot since 7.1 - anaconda actually supports other filesystems than ext2 natively now (due to RH shipping ext3). However, the many changes in this area also means that most of the hacks we did for the 7.1 release are now null and void. So it has essentially been adding XFS support from scratch. I still have a few bootloader issues to sort out and I'm waiting for Eric to finish some kernel changes. Plus we want to do some QA, of course... In any case a 7.2 XFS installer is happenening, so stay tuned. -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Mon Oct 15 07:46:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9FEko207348 for linux-xfs-outgoing; Mon, 15 Oct 2001 07:46:50 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9FEklD07326 for ; Mon, 15 Oct 2001 07:46:47 -0700 Received: from ledzep.americas.sgi.com (relay.sgi.com [137.38.226.97] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA03349 for ; Mon, 15 Oct 2001 07:46:47 -0700 (PDT) mail_from (nstraz@sgi.com) Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.191.42]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA26593 for ; Mon, 15 Oct 2001 09:45:28 -0500 (CDT) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.32 #1 (Debian)) id 15t8zf-0005bk-00 for ; Mon, 15 Oct 2001 09:45:28 -0500 Date: Mon, 15 Oct 2001 09:45:27 -0500 From: Nathan Straz To: linux-xfs@oss.sgi.com Subject: Re: A question about upgrading Message-ID: <20011015094527.Z5692@sgi.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Oct 15, 2001 at 08:47:45AM -0500, s-luppescu@uchicago.edu wrote: > If not (and for those of us too impatient to wait for it), is there > another way to upgrade our xfs systems? Unless the Redhat installer does something special during the system upgrade, you should be able to just install the new packages over your current installation. 1. Download the new distro or get the new CDs 2. rpm --freshen -vh /path/to/redhat/7.2/RPMS/* I haven't needed to upgrade a RedHat system in quite some time (I'm a Debian user), so I don't know if this really works. In theory, it should. As always, backup your system before performing any upgrades. -- 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 Oct 15 08:11:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9FFBjR07906 for linux-xfs-outgoing; Mon, 15 Oct 2001 08:11:45 -0700 Received: from gumby.uwyo.edu (gumby.uwyo.edu [129.72.5.18]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9FFBcD07884 for ; Mon, 15 Oct 2001 08:11:40 -0700 Received: from uwyo.edu (localhost [127.0.0.1]) by gumby.uwyo.edu (8.11.6/8.11.6) with ESMTP id f9FFJbK09733 for ; Mon, 15 Oct 2001 09:19:37 -0600 Message-ID: <3BCAFE88.E8F55AAC@uwyo.edu> Date: Mon, 15 Oct 2001 09:19:36 -0600 From: Russ Ingram Reply-To: ringram@uwyo.edu Organization: UW Math Dept/Institute for Scientific Computation X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.10-pre10-xfs-091701 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: xfs & boot floppies References: <15306.33903.824301.255024@gargle.gargle.HOWL> <20011015182039.K506869@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Nathan Scott wrote: > > On Mon, Oct 15, 2001 at 08:38:39AM +0200, Matthias Klose wrote: > > Hi, > > > > in the xfsprogs 1.3.10 changelog I see you can build xfs-enabled boot > > floppies. Is this correct? > > yes. > > > Do you have some boot floppies around? > > > > I don't, but others do - ask on the linux-xfs list for some > pointers, or just search the XFS mail archive on oss.sgi.com. > > cheers. > > -- > Nathan Look at http://www.lwfug.org/debian -- Russel H. Ingram Unix Systems Administrator Institute for Scientific Computation University of Wyoming/Math Dept. Phone: (307)766-6546 E-Mail: ringram@uwyo.edu From owner-linux-xfs@oss.sgi.com Mon Oct 15 10:49:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9FHnRH10365 for linux-xfs-outgoing; Mon, 15 Oct 2001 10:49:27 -0700 Received: from localhost.localdomain (wet-pants.ximian.com [141.154.95.105]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9FHnND10342 for ; Mon, 15 Oct 2001 10:49:23 -0700 Received: (from jacob@localhost) by localhost.localdomain (8.11.6/8.11.6) id f9FHnDD14461; Mon, 15 Oct 2001 13:49:13 -0400 X-Authentication-Warning: localhost.localdomain: jacob set sender to jacob@ximian.com using -f Subject: Re: patching CVS tree From: jacob berkman To: Hristo Grigorov Cc: linux-xfs@oss.sgi.com In-Reply-To: <20011014080343.SMFB18920.fep01-app.kolumbus.fi@there> References: <20011014080343.SMFB18920.fep01-app.kolumbus.fi@there> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16.99 (Preview Release) Date: 15 Oct 2001 13:49:13 -0400 Message-Id: <1003168153.3451.11.camel@wet-pants> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 2001-10-14 at 04:03, Hristo Grigorov wrote: > Hello, > > I want to patch the xfs CVS tree with the kernel preemptive patch. > But, what happens on the next cvs update? Does it remove it automatically ? > And, is it in general recommended to do that or I have to clone the CVS tree > every time and do my "nasty" expreriments there ? What's your opinion on > that ? for some time i've been merging various things into my xfs tree - ext3 (useful after installing 7.2 beta) and patches for acpi. if changes in cvs are not to code you've patched, cvs will merge them in fine. however, there is no guarantee that the code works or builds. if the changes in cvs conflict with your patches, cvs will tell you this, but you will need to resolve these conflicts. so - if you feel comfortable resolving conflicts in the code (most of the time (for me) they haven't been complicated), then it's definitely an option. i find that having the linux tree in cvs makes this kind of thing much much easier compared with applying patches to a non-cvs tree. jacob -- From owner-linux-xfs@oss.sgi.com Mon Oct 15 12:01:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9FJ1ld11989 for linux-xfs-outgoing; Mon, 15 Oct 2001 12:01:47 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9FJ1iD11966 for ; Mon, 15 Oct 2001 12:01:44 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA00748 for ; Mon, 15 Oct 2001 12:00:52 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA3313799; Mon, 15 Oct 2001 14:00:28 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA48910; Mon, 15 Oct 2001 14:00:25 -0500 (CDT) Subject: Re: Total FS corruption - More info From: Eric Sandeen To: Nigel Kukard Cc: Linux XFS Mailing List In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 15 Oct 2001 13:59:57 -0500 Message-Id: <1003172400.4680.2.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Nigel - I tried this on 2.4.10 (last night you said 2.4.10 exhibited this as well) and it works fine, I can't make it break. You said you have your own distribution - what else is in your kernel? Anything unique about your distro? Is it available somewhere? -Eric On Sun, 2001-10-14 at 20:37, Nigel Kukard wrote: > the ONLY thing i did was this... > > a few shutdown -r now 's and shutdown -h now 's the thing which seemed to > trigger it was... find / > /tmp/test and then a shutdown -r now > > after that command it b0rked out!! -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Oct 15 12:04:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9FJ4tp12147 for linux-xfs-outgoing; Mon, 15 Oct 2001 12:04:55 -0700 Received: from musuko.uchicago.edu (musuko.uchicago.edu [128.135.39.147]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9FJ4pD12125 for ; Mon, 15 Oct 2001 12:04:51 -0700 Received: (from sl70@localhost) by musuko.uchicago.edu (8.11.6/8.11.2) id f9FJ4mt26923; Mon, 15 Oct 2001 14:04:48 -0500 Message-ID: X-Mailer: XFMail 1.5.1 on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20011015094527.Z5692@sgi.com> Date: Mon, 15 Oct 2001 14:04:48 -0500 (CDT) X-Face: &Uky;wivSfT_h6'<6F@p&7]0z";s~axe..-:6:`LzPD'SR:r<)-JK21yU$nl;AzQ#I2$.7' u-f5<2%'b`J3?k%s6[06tr"~;=I{55PYt9,(9dWmhR?0GQxAZSqc6c5@P/fCwpS]1gj<^6>"0{5_91 }w0qn/:dM}9SLlsZYv7JW_hGSk>2Z=&A9.AOX^Y\Qqu#D(H:+yv26dqcvi0l]r]/c){s0_')Wu;?[J ltVl;(?7*L_I$evHiHy%[FmUq#1y-hWg7^/ZQjl_S4lC.AvbyS`G5;M*fzYl+"_TJqw,"X;%XLbkHJ (k Reply-To: s-luppescu@uchicago.edu Organization: Univ of Chicago From: s-luppescu@uchicago.edu To: Nathan Straz Subject: Re: A question about upgrading Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 15-Oct-2001 Nathan Straz wrote: > On Mon, Oct 15, 2001 at 08:47:45AM -0500, s-luppescu@uchicago.edu wrote: >> If not (and for those of us too impatient to wait for it), is there >> another way to upgrade our xfs systems? > > Unless the Redhat installer does something special during the system > upgrade, you should be able to just install the new packages over your > current installation. > > 1. Download the new distro or get the new CDs > 2. rpm --freshen -vh /path/to/redhat/7.2/RPMS/* > > I haven't needed to upgrade a RedHat system in quite some time (I'm a > Debian user), so I don't know if this really works. In theory, it > should. As always, backup your system before performing any upgrades. The problem with this is that the distribution now comes on 2 CDs, so you have to copy all the RPMs from both CDs into a spare directory and do the upgrade from there. If you don't have a spare piece of 1.2 GB disk space to do this in, you get into all kinds of ugly dependency problems. ______________________________________________________________________ Stuart Luppescu -=-=- University of Chicago $(B:MJ8$HCRF`H~$NIc(B -=-=- s-luppescu@uchicago.edu http://www.consortium-chicago.org/people/sl.html http://musuko.uchicago.edu/pubkey.asc for PGP Public Key ICQ #21172047 AIM: psycho7070 If one studies too zealously, one easily loses his pants. -- A. Einstein. >> Sent on 15-Oct-2001 at 14:02:29 with xfmail From owner-linux-xfs@oss.sgi.com Mon Oct 15 12:11:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9FJBWi12380 for linux-xfs-outgoing; Mon, 15 Oct 2001 12:11:32 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9FJBTD12358 for ; Mon, 15 Oct 2001 12:11:29 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9FJBOW29185 for ; Mon, 15 Oct 2001 12:11:24 -0700 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.191.42]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA36132; Mon, 15 Oct 2001 14:10:07 -0500 (CDT) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.32 #1 (Debian)) id 15tD7n-00063W-00; Mon, 15 Oct 2001 14:10:07 -0500 Date: Mon, 15 Oct 2001 14:10:07 -0500 From: Nathan Straz To: s-luppescu@uchicago.edu Cc: linux-xfs@oss.sgi.com Subject: Re: A question about upgrading Message-ID: <20011015141006.B5692@sgi.com> Mail-Followup-To: s-luppescu@uchicago.edu, linux-xfs@oss.sgi.com References: <20011015094527.Z5692@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Oct 15, 2001 at 02:04:48PM -0500, s-luppescu@uchicago.edu wrote: > On 15-Oct-2001 Nathan Straz wrote: > > 1. Download the new distro or get the new CDs > > 2. rpm --freshen -vh /path/to/redhat/7.2/RPMS/* > > > > I haven't needed to upgrade a RedHat system in quite some time (I'm a > > Debian user), so I don't know if this really works. In theory, it > > should. As always, backup your system before performing any upgrades. > > The problem with this is that the distribution now comes on 2 CDs, so > you have to copy all the RPMs from both CDs into a spare directory and > do the upgrade from there. If you don't have a spare piece of 1.2 GB > disk space to do this in, you get into all kinds of ugly dependency > problems. No one ever said that upgrading a RedHat system was easy or convenient. Did I mention I was a Debian user? -- 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 Oct 15 13:38:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9FKcYb14279 for linux-xfs-outgoing; Mon, 15 Oct 2001 13:38:34 -0700 Received: from chef.cc.absoval.com (cpe-66-1-218-101.fl.sprintbbd.net [66.1.218.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9FKcJD14251 for ; Mon, 15 Oct 2001 13:38:20 -0700 Received: from ieee.org (IDENT:bs@thebs.cc.absoval.com [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id QAA08986; Mon, 15 Oct 2001 16:38:13 -0400 Message-ID: <3BCB4935.A073D1E0@ieee.org> Date: Mon, 15 Oct 2001 16:38:13 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts/AbsoluteValueSystems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Advocacy -- Fwd: Letter to Editor: "Red Hat Makes Itself More Available" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Just doing my part to get some XFS advocacy out there as well as introduce the solutions people are looking for. -- TheBS -------- Original Message -------- From: Bryan-TheBS-Smith Subject: Letter to Editor: "Red Hat Makes Itself More Available" To: timothy_dyck@ziffdavis.com Letter to Editor regarding: "RedHat Makes Itself More Available" by Timothy Dyck http://www.eweek.com/article/0,3658,s%253D1884%2526a%253D16413,00.asp Dear Sirs -- As always, it's nice to see the media keeping up with the latest releases. I think you pegged it on the nose with the fact that RedHat 7.2 doesn't have a lot of changes. Such is typical of a RedHat ".2" release, which is the final in a major version that offers the most stability of the lot. But I wanted to clarify and discuss a paragraph, and I comment on it piece-meal. Especially regarding access control lists (ACLs) as there are various filesystem support issues that won't be fully addressed until the next kernel version (2.5 experimental, probably 3.0 release). 1. On RedHat's lack of official/installer support for ReiserFS "However, we were disappointed that there wasn't at least the option to use three features available for Linux: the ReiserFS file system (supported in the operating system but not the installer), ..." This is an obvious vendor support issue. RedHat has not spent time testing the ReiserFS filesystem, unlike other vendors SuSE. So RedHat would be poorly equipped to offer support for it officially. Users who want ReiserFS support should stick with SuSE, or possibly adopt Mandrake if they want a [largely] RedHat-compatible distribution. Instead of testing ReiserFS, RedHat has spent almost two years testing the Ext3 implementation -- along with VALinux as well, who has released modified RedHat distros with it for over a year now in end-user products (most notably their NAS appliances). Unlike the more revolutionary ReiserFS, evolutionary Ext3 doesn't have all the issues with various kernel interfaces, like NFS (especially for non-Linux clients), which is the reason why RedHat supports it instead of ReiserFS. It is because of the complete NFS compatibility and its basis on Ext2 that keeps many of us using RedHat and Ext3. It should also be noted that Stephen Tweedie, the current maintainer of not only Ext3, but Ext2, is a RedHat employee. I would not be surprised if Ext3 is eventually integrated into the official kernel shortly. 2. Lack of installer support for LVM > "... logical volume management ..." I think everyone agrees with that one. Of course, there are additional filesystem support issues that have not been addressed. I have seen numerous issues crop up on both the Ext3 and XFS support lists regarding LVM. Many have to do with continually nagging issues with the virtual memory (VM) implementation in 2.4.x in even the latest releases (especially RAID-5 support). 3. Lack of support for access control lists (ACL) > "... and file access control lists." ReiserFS nor Ext3 support ACLs yet, so I don't understand your point here. And the Ext2 support is far from complete, which means that Ext3 will take some time as well. Lastly, ACLs are not going to be "standard" in the 2.4.x kernel. We'll have to wait for 2.5/3.0 for them. For now, SGI's XFS filesystem offers complete ACL support, including Samba 2.2 integration, as well as official Linux quota support as well (unlike any other JFS). SGI official XFS filesystem releases are designed to install right alongside the RedHat CDs or installation tree (for those installing over a network). Because XFS is just a port of the XFS filesystem from Irix, and is a very traditional UNIX FS design (and very compatible with kernel interfaces), it is most likely that the XFS ACL implementation will become the _standard_ for 2.5/3.0 -- along with other key XFS technologies at the virtual filesystem, VFS, layer so all filesystems will have a single standard. In the same light, because of its tight integration with the virtual memory (VM) subsystem of the Linux kernel, as well as all its other advanced features, XFS will not be integrated into the official kernel until 2.5/3.0. For 2.4, any ACL implementations to this point are going to be FS-specific, with both ReiserFS and IBM's JFS lack any implementation to date. XFS is the only filesystem that offers production-quality ones today (and can even share them with Irix disks and network clients), and the Ext2/Ext3 ACL implementation is clearly "beta" at this stage -- as well as not integrated with major services like Samba 2.2. 4. Conclusions on lack of LVM and ACL > "The latter two are important for the enterprise, and we'd > encourage Red Hat to move forward quickly in these areas." Again, there is no choice regarding ACLs, RedHat or SuSE. Anyone who wants a JFS with full ACL support will either need to move to SGI's XFS support, or wait for kernel 2.5/3.0-based distributions which are still a long way off -- being that the 2.5 tree is just now being created by Linus. > SuSE Linux AG's SuSE Linux is a good choice for those wanting > a mainstream Linux distribution with a more aggressive > development approach. Again, unless I'm missing something, I have not seen ACLs, let alone quota support for any ReiserFS release yet. There are many things planned in ReiserFS 4.x, and it is the future of filesystem design. Unfortunately, its radical approaches affect UNIX/Linux compatibility today. So many of us are still stuck running Ext3 and/or XFS. But XFS does offer all the features you desire and more. 64-bit JFS, ACLs (incluing Samba 2.2 integration), LVM compatibility (no installer support though on the last one), as well as official quota support. Using RedHat Linux + SGI XFS is a powerful combination, one that can be installed very easily by simply adding the single SGI XFS release CD to your RedHat set. Powerful enough that many of us consider it "important for the enterprise." SGI XFS homepage: http://oss.sgi.com/projects/xfs/ -- Bryan "TheBS" Smith Contributing Author, "Samba Unleashed" ReiserFS tester since November 1999 (never adopted) Ext3 production use since February 2000 XFS production use since February 2001 -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ---------------------------------------------------------------- The US recording and software industries have choosen to "honor" the victims of 9/11 by pushing their political agendas even fur- ther through so-called "anti-terrorism" legislation in Congress. From owner-linux-xfs@oss.sgi.com Mon Oct 15 13:54:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9FKsiE14795 for linux-xfs-outgoing; Mon, 15 Oct 2001 13:54:44 -0700 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9FKsfD14773 for ; Mon, 15 Oct 2001 13:54:41 -0700 Received: from www.transvirtual.com (muggles@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f9FKsZE1003469 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NOT) for ; Mon, 15 Oct 2001 13:54:36 -0700 Received: (from muggles@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) id f9FKsZh0003465 for linux-xfs@oss.sgi.com; Mon, 15 Oct 2001 13:54:35 -0700 Date: Mon, 15 Oct 2001 13:54:35 -0700 From: Mark To: linux-xfs@oss.sgi.com Subject: version tags Message-ID: <20011015135435.A24088@transvirtual.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.18i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hello. just wondering if there are version tags in the repos so i could get oh let's say a checkout of a 2.4.10 tree. tia! -- Mark Garey Tel: (415) 243-4055 x1023 Transvirtual Technologies, Inc., Fax: (415) 243-4056 San Francisco, CA. USA Email: mark@transvirtual.com From owner-linux-xfs@oss.sgi.com Mon Oct 15 13:58:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9FKwBK14953 for linux-xfs-outgoing; Mon, 15 Oct 2001 13:58:11 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9FKw8D14931 for ; Mon, 15 Oct 2001 13:58:08 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA07061 for ; Mon, 15 Oct 2001 13:58:04 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA3314387; Mon, 15 Oct 2001 15:56:50 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA23308; Mon, 15 Oct 2001 15:56:50 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9FKsfB31319; Mon, 15 Oct 2001 15:54:41 -0500 Message-Id: <200110152054.f9FKsfB31319@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Mark cc: linux-xfs@oss.sgi.com Subject: Re: version tags In-Reply-To: Message from Mark of "Mon, 15 Oct 2001 13:54:35 PDT." <20011015135435.A24088@transvirtual.com> Date: Mon, 15 Oct 2001 15:54:41 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > hello. > just wondering if there are version tags in the repos so i could get oh let's > say > a checkout of a 2.4.10 tree. > No, but there is a kernel patch against a vanilla 2.4.10 on the oss.sgi.com ftp site in /projects/xfs/download/patches Steve > tia! > > > > -- > Mark Garey Tel: (415) 243-4055 x1023 > Transvirtual Technologies, Inc., Fax: (415) 243-4056 > San Francisco, CA. USA Email: mark@transvirtual.com From owner-linux-xfs@oss.sgi.com Mon Oct 15 14:01:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9FL1el15190 for linux-xfs-outgoing; Mon, 15 Oct 2001 14:01:40 -0700 Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9FL1TD15167 for ; Mon, 15 Oct 2001 14:01:29 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9FL1uau077376 for ; Mon, 15 Oct 2001 23:01:56 +0200 (CEST) Message-Id: <4.3.2.7.2.20011015225911.02d510d8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 15 Oct 2001 23:00:05 +0200 To: linux-xfs@oss.sgi.com From: Seth Mos Subject: Fwd: Re: umount Segmentation fault Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Forwarding, this was compiled with gcc-2.95.4 >From: Seth Mos >Subject: Fwd: Re: umount Segmentation fault > > >>X-XS4ALL-To: >>From: Jeff Davis >>To: Seth Mos >>Subject: Re: umount Segmentation fault >>Date: Mon, 15 Oct 2001 13:31:06 -0700 >>X-Mailer: KMail [version 1.3.2] >> >>I apologize for missing that FAQ item. I included the required info below. >> >>On Monday 15 October 2001 12:45 am, you wrote: >> > At 00:31 15-10-2001 -0700, Jeff Davis wrote: >> > > I recently started using XFS on my linux computer for the root >> > > filesystem >> > >under 2.4.12 (I started using XFS on kernel 2.4.10). Let me say first >> that >> > > I like the filesystem very much and I really appreciate the great >> > > software. However, occasionally an unnerving message appears upon >> > > rebooting my system. There is no way for me to directly retrieve the >> > > message since it didn't appear in the logs, so I actually copied it by >> > > hand using pen/paper and typed it back out, so there might be slight >> > > typos. I included the error message at the end of this email. >> > >> > Can you run this output through ksymoops please? This will produce >> readable >> > (for developers) output. >> >>Forgive me if this is not more helpful, I don't really know anything about >>ksymoops. I just fed it my output and entered it here >> >>------ output ----------- >>ksymoops 2.4.3 on i686 2.4.12-xfs. Options used >> -V (default) >> -k /proc/ksyms (default) >> -l /proc/modules (default) >> -o /lib/modules/2.4.12-xfs/ (default) >> -m /boot/System.map-2.4.12-xfs (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. >> >>No modules in ksyms, skipping objects >>Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod >>file? >>Error (regular_file): read_system_map stat /boot/System.map-2.4.12-xfs failed >>ksymoops: No such file or directory >>CPU: 0 >>EIP: 0100:[] Not tainted >>Using defaults from ksymoops -t elf32-i386 -a i386 >>EFLAGS: 00010202 >>eax: 00000001 ebx: c1308c00 ecx: c1308c00 edx: 00000000 >>esi: 00000000 edi: 00000000 ebp: cb6d5330 esp: cd5b9aa8 >>ds: 0018 es: 0018 ss: 0018 >>Process umount (pid: 4644, stackpage=cd5b9000) >>Stack: c1308c00 00000000 00000000 cb6d5330 c1308c00 00000000 00000000 >>c1308c00 >> c0121316 c012892b c0121484 c1308c00 c1308c00 c0121596 c1308c00 >>00000000 >> cd5b9b1c 00000000 cb6d5330 00000000 00000001 c1308c00 cd5b9b1c >>00000000 >>Call Trace: [] [] [] [] [] >> [] [] [] [] [] >>[] >> [] [] [] [] >>Code: 0f 0b 8b 43 18 a8 20 74 02 0f 0b 8b 43 18 a8 40 74 02 0f 0b >> >> >>EIP; c0128202 <===== >>Trace; c0121316 >>Trace; c012892a <__free_pages+1a/20> >>Trace; c0121484 >>Trace; c0121596 >>Trace; c0121670 >>Trace; c01b9d1a >>Trace; c0226c9c >>Trace; c021d35c >>Trace; c01b9a26 >>Trace; c021cf24 >>Trace; c022e9b2 >>Trace; c013284e >>Trace; c014184e >>Trace; c014196c >>Trace; c0106e6a <__up_wakeup+109a/23f0> >>Code; c0128202 >>00000000 <_EIP>: >>Code; c0128202 <===== >> 0: 0f 0b ud2a <===== >>Code; c0128204 >> 2: 8b 43 18 mov 0x18(%ebx),%eax >>Code; c0128206 >> 5: a8 20 test $0x20,%al >>Code; c0128208 >> 7: 74 02 je b <_EIP+0xb> c012820c >> >>Code; c012820a >> 9: 0f 0b ud2a >>Code; c012820c >> b: 8b 43 18 mov 0x18(%ebx),%eax >>Code; c0128210 >> e: a8 40 test $0x40,%al >>Code; c0128212 >> 10: 74 02 je 14 <_EIP+0x14> c0128216 >> >>Code; c0128214 >> 12: 0f 0b ud2a >> >>2 warnings and 1 error issued. Results may not be reliable. >>-------- end of output ---------- -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Mon Oct 15 14:04:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9FL4H115358 for linux-xfs-outgoing; Mon, 15 Oct 2001 14:04:17 -0700 Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9FL4FD15331 for ; Mon, 15 Oct 2001 14:04:15 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9FL4dau077726; Mon, 15 Oct 2001 23:04:39 +0200 (CEST) Message-Id: <4.3.2.7.2.20011015230159.03058918@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 15 Oct 2001 23:02:49 +0200 To: Mark , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: version tags In-Reply-To: <20011015135435.A24088@transvirtual.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 13:54 15-10-2001 -0700, Mark wrote: >hello. >just wondering if there are version tags in the repos so i could get oh >let's say >a checkout of a 2.4.10 tree. No, sorry. The CVS tree is automatically generated from an internal RCS tree so they would be lost on each update. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Mon Oct 15 14:19:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9FLJXa15750 for linux-xfs-outgoing; Mon, 15 Oct 2001 14:19:33 -0700 Received: from www.fortuitous.com (cs6625133-131.austin.rr.com [66.25.133.131]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9FLJUD15728 for ; Mon, 15 Oct 2001 14:19:31 -0700 Received: by www.fortuitous.com (Postfix, from userid 500) id 4AD84BED; Mon, 15 Oct 2001 16:19:00 -0500 (CDT) Date: Mon, 15 Oct 2001 16:19:00 -0500 From: pac@fortuitous.com To: linux-xfs@oss.sgi.com Subject: questions about http://oss.sgi.com/projects/xfs/irix-linux.html Message-ID: <20011015161900.A3432@bistro.marx> Reply-To: pac@fortuitous.com References: <1003172400.4680.2.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <1003172400.4680.2.camel@stout.americas.sgi.com>; from sandeen@sgi.com on Mon, Oct 15, 2001 at 01:59:57PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk In http://oss.sgi.com/projects/xfs/irix-linux.html it states: * Linux XFS filesystems are limited to 2 Terabytes in size due to limitations in the Linux block device I/O layers. * The maximum accessible file offset of a Linux XFS file is 16 Terabytes on 4K page size and 64 Terabytes on 16K page size. Question: if the max filesystem is 2T, what is the point of discussing a 16T file offset? What did i miss? -pac -- .--------------------------------------------------------. | Dr. Philip A. Carinhas | pac@fortuitous.com | | Fortuitous Technologies Inc. | http://fortuitous.com | | Linux Consulting & Training | Tel : 1-512-467-2154 | `--------------------------------------------------------' From owner-linux-xfs@oss.sgi.com Mon Oct 15 14:33:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9FLXGx16061 for linux-xfs-outgoing; Mon, 15 Oct 2001 14:33:16 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9FLXCD16039 for ; Mon, 15 Oct 2001 14:33:12 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA03546 for ; Mon, 15 Oct 2001 14:32:19 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA3162001; Mon, 15 Oct 2001 16:31:55 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id QAA42598; Mon, 15 Oct 2001 16:31:54 -0500 (CDT) Subject: Re: questions about http://oss.sgi.com/projects/xfs/irix-linux.html From: Eric Sandeen To: pac@fortuitous.com Cc: linux-xfs@oss.sgi.com In-Reply-To: <20011015161900.A3432@bistro.marx> References: <1003172400.4680.2.camel@stout.americas.sgi.com> <20011015161900.A3432@bistro.marx> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 15 Oct 2001 16:31:25 -0500 Message-Id: <1003181485.1808.20.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The point is that if/when Linux scales to those sizes of files, XFS is ready. Outside of the Linux limitation, the maximum size of an XFS filesystem is something unbelievably huge!* :) -Eric * ~18 Million terabytes, I believe. On Mon, 2001-10-15 at 16:19, pac@fortuitous.com wrote: > In http://oss.sgi.com/projects/xfs/irix-linux.html > it states: > > * Linux XFS filesystems are limited to 2 Terabytes in size due to > limitations in the Linux block device I/O layers. > > * The maximum accessible file offset of a Linux XFS file is 16 Terabytes on 4K > page size and 64 Terabytes on 16K page size. > > Question: if the max filesystem is 2T, what is the point of discussing a 16T > file offset? What did i miss? -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Oct 15 14:36:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9FLaXN16228 for linux-xfs-outgoing; Mon, 15 Oct 2001 14:36:33 -0700 Received: from sol.rune.org (IDENT:sarwer@sol.rune.org [207.201.197.191]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9FLaTD16205 for ; Mon, 15 Oct 2001 14:36:29 -0700 Received: from localhost (sarwer@localhost) by sol.rune.org (8.9.1/8.9.1) with ESMTP id RAA01398 for ; Mon, 15 Oct 2001 17:36:26 -0400 Date: Mon, 15 Oct 2001 17:36:26 -0400 (EDT) From: Sarwer Zafiruddin To: linux-xfs@oss.sgi.com Subject: Directory File Size [Slightly OT] Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I appologize for the slightly OT nature of the e-mail. But I figure this is a good place to ask, since there is alot of filesystems experts in this list. I am curious exactly what the file size for a directory file listing means? What makes the file size of a directory file larger? hotdog_$ ls -ld gas_mech_assy drwxrwxrwt 5 sarwer dba 10493952 Oct 15 17:26 loaded_pkgs ^^^^^^^^ What is makes this number get bigger? Just curious...appreciate any information on this. Thanks, Sarwer Zafiruddin -- -------------------------- System Administrator Rune Information Services http://www.rune.org e-mail: sarwer@rune.org -------------------------- From owner-linux-xfs@oss.sgi.com Mon Oct 15 14:40:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9FLeFL16393 for linux-xfs-outgoing; Mon, 15 Oct 2001 14:40:15 -0700 Received: from chef.cc.absoval.com (cpe-66-1-218-101.fl.sprintbbd.net [66.1.218.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9FLeBD16370 for ; Mon, 15 Oct 2001 14:40:11 -0700 Received: from ieee.org (IDENT:bs@thebs.cc.absoval.com [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id RAA09167; Mon, 15 Oct 2001 17:39:28 -0400 Message-ID: <3BCB5790.8DA87CE5@ieee.org> Date: Mon, 15 Oct 2001 17:39:28 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts/AbsoluteValueSystems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: pac@fortuitous.com CC: linux-xfs@oss.sgi.com Subject: Re: questions about http://oss.sgi.com/projects/xfs/irix-linux.html References: <1003172400.4680.2.camel@stout.americas.sgi.com> <20011015161900.A3432@bistro.marx> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk pac@fortuitous.com wrote: > Question: if the max filesystem is 2T, what is the point of > discussing a 16T file offset? What did i miss? Linux[/x86] and well as the PC BIOS' "absolute CHS addressing" (which affects any add-on cards as well, like SCSI) have limits at the 2TB barrier. XFS' original platform, MIPS/Irix does not have this limitation. [ Correct me if I'm wrong on this though ] -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ---------------------------------------------------------------- The US recording and software industries have choosen to "honor" the victims of 9/11 by pushing their political agendas even fur- ther through so-called "anti-terrorism" legislation in Congress. From owner-linux-xfs@oss.sgi.com Mon Oct 15 14:48:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9FLmJf16693 for linux-xfs-outgoing; Mon, 15 Oct 2001 14:48:19 -0700 Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9FLlxD16651 for ; Mon, 15 Oct 2001 14:48:03 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id E6C37C00B62 for ; Tue, 16 Oct 2001 05:47:25 +0800 (PHT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 20DFAC00B60 for ; Tue, 16 Oct 2001 05:47:23 +0800 (PHT) Date: Tue, 16 Oct 2001 05:47:22 +0800 (PHT) From: Federico Sevilla III To: Linux XFS Mailing List Subject: Re: Directory File Size [Slightly OT] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 15 Oct 2001 at 17:36, Sarwer Zafiruddin wrote: > I appologize for the slightly OT nature of the e-mail. But I figure > this is a good place to ask, since there is alot of filesystems > experts in this list. And I think I can help make this more on-topic by asking: > hotdog_$ ls -ld gas_mech_assy > drwxrwxrwt 5 sarwer dba 10493952 Oct 15 17:26 loaded_pkgs > ^^^^^^^^ > What is makes this number get bigger? Why does the size of this number vary not only with the directory, but with the filesystem as well? In particular on XFS, what dictates the size of a directory? It doesn't seem to be directly correlated with the total size of the contents. I did some tests and it looks like it has something to do with the length of the filenames in it, and perhaps the name of the directory itself. Is this it? --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Mon Oct 15 15:34:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9FMYc217740 for linux-xfs-outgoing; Mon, 15 Oct 2001 15:34:38 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9FMYWD17718 for ; Mon, 15 Oct 2001 15:34:32 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA09155 for ; Mon, 15 Oct 2001 15:33:02 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA3316760; Mon, 15 Oct 2001 17:33:08 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA28086; Mon, 15 Oct 2001 17:33:07 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9FMUvA31431; Mon, 15 Oct 2001 17:30:57 -0500 Message-Id: <200110152230.f9FMUvA31431@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Federico Sevilla III cc: Linux XFS Mailing List Subject: Re: Directory File Size [Slightly OT] In-Reply-To: Message from Federico Sevilla III of "Tue, 16 Oct 2001 05:47:22 +0800." Date: Mon, 15 Oct 2001 17:30:57 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Mon, 15 Oct 2001 at 17:36, Sarwer Zafiruddin wrote: > > I appologize for the slightly OT nature of the e-mail. But I figure > > this is a good place to ask, since there is alot of filesystems > > experts in this list. > > And I think I can help make this more on-topic by asking: > > > hotdog_$ ls -ld gas_mech_assy > > drwxrwxrwt 5 sarwer dba 10493952 Oct 15 17:26 loaded_pkgs > > ^^^^^^^^ > > What is makes this number get bigger? > > Why does the size of this number vary not only with the directory, but > with the filesystem as well? > > In particular on XFS, what dictates the size of a directory? It doesn't > seem to be directly correlated with the total size of the contents. I did > some tests and it looks like it has something to do with the length of the > filenames in it, and perhaps the name of the directory itself. Is this it? A directory entry contains the name of the file, and the inode number - which is 8 bytes on XFS. A small XFS directory lives within the inode, and the size you see is the amount of space in the inode being used by these entries plus some space management data structures. Once the directory does not fit in the inode it grows to one filesystem block - or 4Kbytes, it will sit at this size until it no longer fits into one block, at which point we turn the directory into a btree of blocks - the leaf blocks contain the entries and the node blocks contain the index pointers to the entries. The smallest btree is 3 blocks, so the next size you would see is 12K. After this it will go up a block at a time as it grows. If you remove stuff from the directory it will shrink again - all the way back into the inode. Other filesystems do this differently. Steve > > --> Jijo > > -- > Federico Sevilla III :: jijo@leathercollection.ph > Network Administrator :: The Leather Collection, Inc. > GnuPG Key: > > From owner-linux-xfs@oss.sgi.com Mon Oct 15 17:48:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9G0mOf19867 for linux-xfs-outgoing; Mon, 15 Oct 2001 17:48:24 -0700 Received: from mailhost.Mathematik.Uni-Marburg.de (pc12418.Mathematik.Uni-Marburg.DE [137.248.123.44]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9G0lcD19833 for ; Mon, 15 Oct 2001 17:47:38 -0700 Received: from pc12419.Mathematik.uni-marburg.de (lagos [137.248.123.45]) by mailhost.Mathematik.Uni-Marburg.de (8.11.6/8.11.0) with ESMTP id f9G0lak21439; Tue, 16 Oct 2001 02:47:36 +0200 Received: from localhost (posern@localhost) by pc12419.Mathematik.uni-marburg.de (8.11.6/8.11.0) with ESMTP id f9G0laL04807; Tue, 16 Oct 2001 02:47:36 +0200 X-Authentication-Warning: pc12419.Mathematik.Uni-Marburg.DE: posern owned process doing -bs Date: Tue, 16 Oct 2001 02:47:36 +0200 (CEST) From: Knuth Posern X-X-Sender: To: cc: Subject: HELP!!! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi. I have (or had?!) a sotware RAID-5 with the following /etc/raidtab raiddev /dev/md0 raid-level 5 nr-raid-disks 4 nr-spare-disks 0 persistent-superblock 1 chunk-size 128 ####### RAID-devices device /dev/hde1 raid-disk 0 device /dev/hdg1 raid-disk 1 device /dev/hdi1 raid-disk 2 device /dev/hdk1 raid-disk 3 I built the raid half a year ago. Formatted it with XFS (and a 2.4.5er kernel). At the moment I use 2.4.10-xfs. The machine is a debian-unstable linux-server. The following happened to me: While I was playing an mp3-file on a console I got the following kernel message(s) bumped into the console: ___________________________________________________________________________ hde: dma_intr: status=0x51 { DriveReady SeekComplete Error } hde: dma_intr: error=0x40 { UncorrectableError }, LBAsect=56410433, sector=56410368 end_request: I/O error, dev 21:01 (hde), sector 56410368 raid5: Disk failure on hde1, disabling device. Operation continuing on 2 devices md: recovery thread got woken up ... md0: no spare disk to reconstruct array! -- continuing in degraded mode md: recovery thread finished ... md: updating md0 RAID superblock on device md: hdi1 [events: 000000de](write) hdi1's sb offset: 45034816 md: hdg1 [events: 000000de](write) hdg1's sb offset: 45034816 md: (skipping faulty hde1 ) XFS: device 0x900- XFS write error in file system meta-data block 0x40 in md(9,0) XFS: device 0x900- XFS write error in file system meta-data block 0x40 in md(9,0) XFS: device 0x900- XFS write error in file system meta-data block 0x40 in md(9,0) XFS: device 0x900- XFS write error in file system meta-data block 0x40 in md(9,0) XFS: device 0x900- XFS write error in file system meta-data block 0x40 in md(9,0) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I then switched to runlevel 0: ____________________________________________________________________________ Give root password for maintenance (or type Control-D for normal startup): jolie:~# umount /raid xfs_unmount: xfs_ibusy says error/16 XFS unmount got error 16 linvfs_put_super: vfsp/0xdf467520 left dangling! VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day... jolie:~# mount /dev/hda3 on / type ext2 (rw,errors=remount-ro,errors=remount-ro) proc on /proc type proc (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) /dev/md0 on /mnt/raid type xfs (rw) jolie:~# lsof ... ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The lsof did NOT show any open files on /mnt/raid. So I tried again to unuount /mnt/raid: _____________________________________________________________________________ jolie:~# jolie:~# umount /mnt/raid umount: /mnt/raid: not mounted ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ But now it was unmounted already?! So I tried to mount it... ____________________________________________________________________________ jolie:~# jolie:~# mount /mnt/raid XFS: SB read failed I/O error in filesystem ("md(9,0)") meta-data dev 0x900 block 0x0 ("xfs_readsb") error 5 buf count 512 mount: wrong fs type, bad option, bad superblock on /dev/md0, or too many mounted file systems ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I rebooted the computer - and got the following during bootup: ____________________________________________________________________________ Starting raid devices: (read) hde1's sb offset: 45034816 [events: 000000dd] (read) hdg1's sb offset: 45034816 [events: 000000df] (read) hdi1's sb offset: 45034816 [events: 000000df] md: autorun ... md: considering hdi1 ... md: adding hdi1 ... md: adding hdg1 ... md: adding hde1 ... md: created md0 md: bind md: bind md: bind md: running: md: hdi1's event counter: 000000df md: hdg1's event counter: 000000df md: hde1's event counter: 000000dd md: superblock update time inconsistency -- using the most recent one md: freshest: hdi1 md: kicking non-fresh hde1 from array! md: unbind md: export_rdev(hde1) md0: removing former faulty hde1! md0: max total readahead window set to 1536k md0: 3 data-disks, max readahead per data-disk: 512k raid5: device hdi1 operational as raid disk 2 raid5: device hdg1 operational as raid disk 1 raid5: not enough operational devices for md0 (2/4 failed) RAID5 conf printout: --- rd:4 wd:2 fd:2 disk 0, s:0, o:0, n:0 rd:0 us:1 dev:[dev 00:00] disk 1, s:0, o:1, n:1 rd:1 us:1 dev:hdg1 disk 2, s:0, o:1, n:2 rd:2 us:1 dev:hdi1 disk 3, s:0, o:0, n:3 rd:3 us:1 dev:[dev 00:00] raid5: failed to run raid set md0 md: pers->run() failed ... md :do_md_run() returned -22 md: md0 stopped. md: unbind md: export_rdev(hdi1) md: unbind md: export_rdev(hdg1) md: ... autorun DONE. done. Checking all file systems... fsck 1.25 (20-Sep-2001) Setting kernel variables. Loading the saved-state of the serial devices... Mounting local filesystems... XFS: SB read failed I/O error in filesystem ("md(9,0)") meta-data dev 0x900 block 0x0 ("xfs_readsb") error 5 buf count 512 mount: wrong fs type, bad option, bad superblock on /dev/md0, or too many mounted file systems (could this be the IDE device where you in fact use ide-scsi so that sr0 or sda or so is needed?) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I logged in and I edited the /etc/raidtab to have a SPARE-DISC: ______________________________________________________________________________ raiddev /dev/md0 raid-level 5 nr-raid-disks 4 nr-spare-disks 1 persistent-superblock 1 chunk-size 128 ####### RAID-devices device /dev/hde1 raid-disk 0 device /dev/hdg1 raid-disk 1 device /dev/hdi1 raid-disk 2 device /dev/hdk1 raid-disk 3 ####### Spare disks: device /dev/hdc1 spare-disk 1 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I connected an identical harddrive (like the other raid-harddiscs) as /dev/hdc. And rebooted again. - without any changes. I then read in the Software-RAID-Howto (from January 2000) to just remove the faulty drive and instead connect a new drive. So I connected the harddisc from /dev/hdc on /dev/hde (and edited the /etc/raidtab to be as it was before (without spare-disks)!). And rebooted. md0 didn't start the array - because /dev/hde is 0K big (or something like that). That was because I had forgotten to built a partion on /dev/hde - so I built the one partition (as on the other raid-drives too). And rebooted again - But md0 had an "Failed autostart of /dev/md0" again. And the Software-RAID-Howto told me to "raidhotadd /dev/md0 /dev/hde1". Which I tried but it said somehting like: "/dev/md0 - no such raid is running". So I tried to get /dev/md0 RUNNING again. In 6.1 of the Software-Raid-Howto there was something with "mkraid /dev/md0 --force". So I tried: ___________________________________________________________________________ jolie:~# mkraid /dev/md0 --force --force and the new RAID 0.90 hot-add/hot-remove functionality should be used with extreme care! If /etc/raidtab is not in sync with the real array configuration, then a --force will DESTROY ALL YOUR DATA. It's especially dangerous to use -f if the array is in degraded mode. PLEASE dont mention the --really-force flag in any email, documentation or HOWTO, just suggest the --force flag instead. Thus everybody will read this warning at least once :) It really sucks to LOSE DATA. If you are confident that everything will go ok then you can use the --really-force flag. Also, if you are unsure what this is all about, dont hesitate to ask questions on linux-raid@vger.rutgers.edu ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ And because I thought the raid needs a valid SUPERBLOCK on /dev/hde1 AND the raid-configuration and /etc/raidtab ARE in SYNC - I then TRIED (and hopefully NOT destroyed all my data?!?!?!). ___________________________________________________________________________ jolie:~# mkraid /dev/md0 --really-force DESTROYING the contents of /dev/md0 in 5 seconds, Ctrl-C if unsure! handling MD device /dev/md0 analyzing super-block disk 0: /dev/hde1, 45034888kB, raid superblock at 45034816kB disk 1: /dev/hdg1, 45034888kB, raid superblock at 45034816kB disk 2: /dev/hdi1, 45034888kB, raid superblock at 45034816kB disk 3: /dev/hdk1, 45034888kB, raid superblock at 45034816kB md: bind md: bind md: bind md: bind md: hdk1's event counter: 00000000 md: hdi1's event counter: 00000000 md: hdg1's event counter: 00000000 md: hde1's event counter: 00000000 md: md0: raid array is not clean -- starting background reconstruction md0: max total readahead window set to 1536k md0: 3 data-disks, max readahead per data-disk: 512k raid5: allocated 4339kB for md0 raid5: raid level 5 set md0 active with 4 out of 4 devices, algorithm 0 raid5: raid set md0 not clean; reconstructing parity RAID5 conf printout: --- rd:4 wd:4 fd:0 disk 0, s:0, o:1, n:0 rd:0 us:1 dev:hde1 disk 1, s:0, o:1, n:1 rd:1 us:1 dev:hdg1 disk 2, s:0, o:1, n:2 rd:2 us:1 dev:hdi1 disk 3, s:0, o:1, n:3 rd:3 us:1 dev:hdk1 RAID5 conf printout: --- rd:4 wd:4 fd:0 disk 0, s:0, o:1, n:0 rd:0 us:1 dev:hde1 disk 1, s:0, o:1, n:1 rd:1 us:1 dev:hdg1 disk 2, s:0, o:1, n:2 rd:2 us:1 dev:hdi1 disk 3, s:0, o:1, n:3 rd:3 us:1 dev:hdk1 md: updating md0 RAID superblock on device md: hdk1 [events: 00000001](write) hdk1's sb offset: 45034816 md: syncing RAID array md0 md: minimum _guaranteed_ reconstruction speed: 100 KB/sec/disc. md: using maximum available idle IO bandwith (but not more than 100000 KB/sec) for reconstruction. md: using 124k window, over a total of 45034752 blocks. md: hdi1 [events: 00000001](write) hdi1's sb offset: 45034816 md: hdg1 [events: 00000001](write) hdg1's sb offset: 45034816 md: hde1 [events: 00000001](write) hde1's sb offset: 45034816 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ And tried again to hotadd the /dev/hde1: ___________________________________________________________________________ jolie:~# raidhotadd /dev/md0 /dev/hde1 md: trying to hot-add hde1 to md0 ... /dev/md0: can not hot-add disk: disk busy! ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then I checked /proc/mdstat. Where it said about reconstructing - which sounds hopefully good... ?! But: ___________________________________________________________________________ jolie:~# mount /mnt/raid XFS: bad magic number XFS: SB validate failed mount: wrong fs type, bad option, bad superblock on /dev/md0, or too many mounted file systems ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ So I just rebooted again - in the hope that the raid-autostart during boot time would bring some new/other results. But a mount /mnt/raid gives still the same results!!!??? What can I do? - Is my data lost? - if so: Is there ANY CHANCE to get at least SOME of it BACK SOMEHOW (it doesnt matter how difficult)!? ??? Help would be VERY, VERY, VERY apreciated!!! :-| Greetings, Knuth Posern. And just if this CAN help I add to things: 0.) an "cat /proc/mdstat" from the situation right now! 1.) the actual raid-5 startup-messages (which appear during boot-up) 2.) the kernel syslog-entries from the moment of the "RAID-CRASH" 3.) the raid-5 startup-messages from BEFORE this all happened!!!! 1.-3. - as you will probably note - are out of the /var/log/messages logfile. 0.) ______________________________________________________________________________ jolie:/var/log# cat /proc/mdstat Personalities : [raid5] read_ahead 1024 sectors md0 : active raid5 hdk1[3] hdi1[2] hdg1[1] hde1[0] 135104256 blocks level 5, 128k chunk, algorithm 0 [4/4] [UUUU] unused devices: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1.) ______________________________________________________________________________ Oct 16 01:31:35 jolie kernel: md: raid5 personality registered as nr 4 Oct 16 01:31:35 jolie kernel: raid5: measuring checksumming speed Oct 16 01:31:35 jolie kernel: 8regs : 1614.400 MB/sec Oct 16 01:31:35 jolie kernel: 32regs : 1146.000 MB/sec Oct 16 01:31:35 jolie kernel: pIII_sse : 1907.200 MB/sec Oct 16 01:31:35 jolie kernel: pII_mmx : 2094.800 MB/sec Oct 16 01:31:35 jolie kernel: p5_mmx : 2204.800 MB/sec Oct 16 01:31:35 jolie kernel: raid5: using function: pIII_sse (1907.200 MB/sec) Oct 16 01:31:35 jolie kernel: md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 Oct 16 01:31:35 jolie kernel: md: Autodetecting RAID arrays. Oct 16 01:31:35 jolie kernel: md: autorun ... Oct 16 01:31:35 jolie kernel: md: ... autorun DONE. Oct 16 01:31:35 jolie kernel: NET4: Linux TCP/IP 1.0 for NET4.0 Oct 16 01:31:35 jolie kernel: IP Protocols: ICMP, UDP, TCP, IGMP Oct 16 01:31:35 jolie kernel: IP: routing cache hash table of 4096 buckets, 32Kbytes Oct 16 01:31:35 jolie kernel: TCP: Hash tables configured (established 32768 bind 32768) Oct 16 01:31:35 jolie kernel: klips_info:ipsec_init: KLIPS startup, FreeS/WAN IPSec version: snap2001sep30b Oct 16 01:31:35 jolie kernel: NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. Oct 16 01:31:35 jolie kernel: VFS: Mounted root (ext2 filesystem) readonly. Oct 16 01:31:35 jolie kernel: Freeing unused kernel memory: 212k freed Oct 16 01:31:35 jolie kernel: Adding Swap: 489940k swap-space (priority -1) Oct 16 01:31:35 jolie kernel: Adding Swap: 104384k swap-space (priority -2) Oct 16 01:31:35 jolie kernel: ISDN subsystem Rev: 1.114.6.14/1.94.6.7/1.140.6.8/1.85.6.6/1.21.6.1/1.5.6.3 loaded Oct 16 01:31:35 jolie kernel: (read) hde1's sb offset: 45034816 [events: 00000002] Oct 16 01:31:35 jolie kernel: (read) hdg1's sb offset: 45034816 [events: 00000002] Oct 16 01:31:35 jolie kernel: (read) hdi1's sb offset: 45034816 [events: 00000002] Oct 16 01:31:35 jolie kernel: (read) hdk1's sb offset: 45034816 [events: 00000002] Oct 16 01:31:35 jolie kernel: md: autorun ... Oct 16 01:31:35 jolie kernel: md: considering hdk1 ... Oct 16 01:31:35 jolie kernel: md: adding hdk1 ... Oct 16 01:31:35 jolie kernel: md: adding hdi1 ... Oct 16 01:31:35 jolie kernel: md: adding hdg1 ... Oct 16 01:31:35 jolie kernel: md: adding hde1 ... Oct 16 01:31:35 jolie kernel: md: created md0 Oct 16 01:31:35 jolie kernel: md: bind Oct 16 01:31:35 jolie kernel: md: bind Oct 16 01:31:35 jolie kernel: md: bind Oct 16 01:31:35 jolie kernel: md: bind Oct 16 01:31:35 jolie kernel: md: running: Oct 16 01:31:35 jolie kernel: md: hdk1's event counter: 00000002 Oct 16 01:31:35 jolie kernel: md: hdi1's event counter: 00000002 Oct 16 01:31:35 jolie kernel: md: hdg1's event counter: 00000002 Oct 16 01:31:35 jolie kernel: md: hde1's event counter: 00000002 Oct 16 01:31:35 jolie kernel: md0: max total readahead window set to 1536k Oct 16 01:31:35 jolie kernel: md0: 3 data-disks, max readahead per data-disk: 512k Oct 16 01:31:35 jolie kernel: raid5: device hdk1 operational as raid disk 3 Oct 16 01:31:35 jolie kernel: raid5: device hdi1 operational as raid disk 2 Oct 16 01:31:35 jolie kernel: raid5: device hdg1 operational as raid disk 1 Oct 16 01:31:35 jolie kernel: raid5: device hde1 operational as raid disk 0 Oct 16 01:31:35 jolie kernel: raid5: allocated 4339kB for md0 Oct 16 01:31:35 jolie kernel: raid5: raid level 5 set md0 active with 4 out of 4 devices, algorithm 0 Oct 16 01:31:35 jolie kernel: RAID5 conf printout: Oct 16 01:31:35 jolie kernel: --- rd:4 wd:4 fd:0 Oct 16 01:31:35 jolie kernel: disk 0, s:0, o:1, n:0 rd:0 us:1 dev:hde1 Oct 16 01:31:35 jolie kernel: disk 1, s:0, o:1, n:1 rd:1 us:1 dev:hdg1 Oct 16 01:31:35 jolie kernel: disk 2, s:0, o:1, n:2 rd:2 us:1 dev:hdi1 Oct 16 01:31:35 jolie kernel: disk 3, s:0, o:1, n:3 rd:3 us:1 dev:hdk1 Oct 16 01:31:35 jolie kernel: RAID5 conf printout: Oct 16 01:31:35 jolie kernel: --- rd:4 wd:4 fd:0 Oct 16 01:31:35 jolie kernel: disk 0, s:0, o:1, n:0 rd:0 us:1 dev:hde1 Oct 16 01:31:35 jolie kernel: disk 1, s:0, o:1, n:1 rd:1 us:1 dev:hdg1 Oct 16 01:31:35 jolie kernel: disk 2, s:0, o:1, n:2 rd:2 us:1 dev:hdi1 Oct 16 01:31:35 jolie kernel: disk 3, s:0, o:1, n:3 rd:3 us:1 dev:hdk1 Oct 16 01:31:35 jolie kernel: md: updating md0 RAID superblock on device Oct 16 01:31:35 jolie kernel: md: hdk1 [events: 00000003](write) hdk1's sb offset: 45034816 Oct 16 01:31:35 jolie kernel: md: hdi1 [events: 00000003](write) hdi1's sb offset: 45034816 Oct 16 01:31:35 jolie kernel: md: hdg1 [events: 00000003](write) hdg1's sb offset: 45034816 Oct 16 01:31:35 jolie kernel: md: hde1 [events: 00000003](write) hde1's sb offset: 45034816 Oct 16 01:31:35 jolie kernel: md: ... autorun DONE. Oct 16 01:31:35 jolie kernel: XFS: bad magic number Oct 16 01:31:35 jolie kernel: XFS: SB validate failed ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2.) ________________________________________________________________________________ Oct 14 10:36:26 jolie kernel: hde: dma_intr: status=0x51 { DriveReady SeekComplete Error } Oct 14 10:36:26 jolie kernel: hde: dma_intr: error=0x40 { UncorrectableError }, LBAsect=56410433, sector=56410368 Oct 14 10:36:26 jolie kernel: end_request: I/O error, dev 21:01 (hde), sector 56410368 Oct 14 10:36:26 jolie kernel: md: recovery thread got woken up ... Oct 14 10:36:26 jolie kernel: md: recovery thread finished ... Oct 14 10:36:26 jolie kernel: md: updating md0 RAID superblock on device Oct 14 10:36:26 jolie kernel: md: hdi1 [events: 000000de](write) hdi1's sb offset: 45034816 Oct 14 10:36:26 jolie kernel: md: hdg1 [events: 000000de](write) hdg1's sb offset: 45034816 Oct 14 10:36:26 jolie kernel: md: (skipping faulty hde1 ) Oct 14 10:36:26 jolie kernel: XFS: device 0x900- XFS write error in file system meta-data block 0x40 in md(9,0) Oct 14 10:36:56 jolie last message repeated 2 times Oct 14 10:37:41 jolie last message repeated 3 times Oct 14 10:37:49 jolie kernel: I/O error in filesystem ("md(9,0)") meta-data dev 0x900 block 0x2000002 Oct 14 10:37:49 jolie kernel: ("xfs_trans_read_buf") error 5 buf count 512 Oct 14 10:37:49 jolie kernel: I/O error in filesystem ("md(9,0)") meta-data dev 0x900 block 0x2a91b00 Oct 14 10:37:49 jolie kernel: ("xfs_trans_read_buf") error 5 buf count 8192 Oct 14 10:37:49 jolie kernel: xfs_force_shutdown(md(9,0),0x1) called from line 408 of file xfs_trans_buf.c. Return address = 0xc01d9779 Oct 14 10:37:49 jolie kernel: I/O Error Detected. Shutting down filesystem: md(9,0) Oct 14 10:37:49 jolie kernel: Please umount the filesystem, and rectify the problem(s) Oct 14 10:48:31 jolie -- MARK -- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 3.) _________________________________________________________________________________ Oct 3 02:10:20 jolie kernel: md: raid5 personality registered as nr 4 Oct 3 02:10:20 jolie kernel: raid5: measuring checksumming speed Oct 3 02:10:20 jolie kernel: 8regs : 1614.800 MB/sec Oct 3 02:10:20 jolie kernel: 32regs : 1145.600 MB/sec Oct 3 02:10:20 jolie kernel: pIII_sse : 1922.800 MB/sec Oct 3 02:10:20 jolie kernel: pII_mmx : 2094.400 MB/sec Oct 3 02:10:20 jolie kernel: p5_mmx : 2204.800 MB/sec Oct 3 02:10:20 jolie kernel: raid5: using function: pIII_sse (1922.800 MB/sec) Oct 3 02:10:20 jolie kernel: md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 Oct 3 02:10:20 jolie kernel: md: Autodetecting RAID arrays. Oct 3 02:10:20 jolie kernel: md: autorun ... Oct 3 02:10:20 jolie kernel: md: ... autorun DONE. Oct 3 02:10:20 jolie kernel: NET4: Linux TCP/IP 1.0 for NET4.0 Oct 3 02:10:20 jolie kernel: IP Protocols: ICMP, UDP, TCP, IGMP Oct 3 02:10:20 jolie kernel: IP: routing cache hash table of 4096 buckets, 32Kbytes Oct 3 02:10:20 jolie kernel: TCP: Hash tables configured (established 32768 bind 32768) Oct 3 02:10:20 jolie kernel: klips_info:ipsec_init: KLIPS startup, FreeS/WAN IPSec version: snap2001sep30b Oct 3 02:10:20 jolie kernel: NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. Oct 3 02:10:20 jolie kernel: VFS: Mounted root (ext2 filesystem) readonly. Oct 3 02:10:20 jolie kernel: Freeing unused kernel memory: 208k freed Oct 3 02:10:20 jolie kernel: Adding Swap: 489940k swap-space (priority -1) Oct 3 02:10:20 jolie kernel: Adding Swap: 104384k swap-space (priority -2) Oct 3 02:10:20 jolie kernel: (read) hde1's sb offset: 45034816 [events: 000000d6] Oct 3 02:10:20 jolie kernel: (read) hdg1's sb offset: 45034816 [events: 000000d6] Oct 3 02:10:20 jolie kernel: (read) hdi1's sb offset: 45034816 [events: 000000d6] Oct 3 02:10:20 jolie kernel: md: autorun ... Oct 3 02:10:20 jolie kernel: md: considering hdi1 ... Oct 3 02:10:20 jolie kernel: md: adding hdi1 ... Oct 3 02:10:20 jolie kernel: md: adding hdg1 ... Oct 3 02:10:20 jolie kernel: md: adding hde1 ... Oct 3 02:10:20 jolie kernel: md: created md0 Oct 3 02:10:20 jolie kernel: md: bind Oct 3 02:10:20 jolie kernel: md: bind Oct 3 02:10:20 jolie kernel: md: bind Oct 3 02:10:20 jolie kernel: md: running: Oct 3 02:10:20 jolie kernel: md: hdi1's event counter: 000000d6 Oct 3 02:10:20 jolie kernel: md: hdg1's event counter: 000000d6 Oct 3 02:10:20 jolie kernel: md: hde1's event counter: 000000d6 Oct 3 02:10:20 jolie kernel: md0: max total readahead window set to 1536k Oct 3 02:10:20 jolie kernel: md0: 3 data-disks, max readahead per data-disk: 512k Oct 3 02:10:20 jolie kernel: raid5: device hdi1 operational as raid disk 2 Oct 3 02:10:20 jolie kernel: raid5: device hdg1 operational as raid disk 1 Oct 3 02:10:20 jolie kernel: raid5: device hde1 operational as raid disk 0 Oct 3 02:10:20 jolie kernel: raid5: allocated 4339kB for md0 Oct 3 02:10:20 jolie kernel: RAID5 conf printout: Oct 3 02:10:20 jolie kernel: --- rd:4 wd:3 fd:1 Oct 3 02:10:20 jolie kernel: disk 0, s:0, o:1, n:0 rd:0 us:1 dev:hde1 Oct 3 02:10:20 jolie kernel: disk 1, s:0, o:1, n:1 rd:1 us:1 dev:hdg1 Oct 3 02:10:20 jolie kernel: disk 2, s:0, o:1, n:2 rd:2 us:1 dev:hdi1 Oct 3 02:10:20 jolie kernel: disk 3, s:0, o:0, n:3 rd:3 us:1 dev:[dev 00:00] Oct 3 02:10:20 jolie kernel: RAID5 conf printout: Oct 3 02:10:20 jolie kernel: --- rd:4 wd:3 fd:1 Oct 3 02:10:20 jolie kernel: disk 0, s:0, o:1, n:0 rd:0 us:1 dev:hde1 Oct 3 02:10:20 jolie kernel: disk 1, s:0, o:1, n:1 rd:1 us:1 dev:hdg1 Oct 3 02:10:20 jolie kernel: disk 2, s:0, o:1, n:2 rd:2 us:1 dev:hdi1 Oct 3 02:10:20 jolie kernel: disk 3, s:0, o:0, n:3 rd:3 us:1 dev:[dev 00:00] Oct 3 02:10:20 jolie kernel: md: updating md0 RAID superblock on device Oct 3 02:10:20 jolie kernel: md: hdi1 [events: 000000d7](write) hdi1's sb offset: 45034816 Oct 3 02:10:20 jolie kernel: md: recovery thread got woken up ... Oct 3 02:10:20 jolie kernel: md: recovery thread finished ... Oct 3 02:10:20 jolie kernel: md: hdg1 [events: 000000d7](write) hdg1's sb offset: 45034816 Oct 3 02:10:20 jolie kernel: md: hde1 [events: 000000d7](write) hde1's sb offset: 45034816 Oct 3 02:10:20 jolie kernel: md: ... autorun DONE. Oct 3 02:10:20 jolie kernel: XFS mounting filesystem md(9,0) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ From owner-linux-xfs@oss.sgi.com Mon Oct 15 17:54:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9G0slw20142 for linux-xfs-outgoing; Mon, 15 Oct 2001 17:54:47 -0700 Received: from haddock.cd.chalmers.se (haddock.cd.chalmers.se [129.16.79.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9G0shD20105 for ; Mon, 15 Oct 2001 17:54:44 -0700 Received: from haddock.cd.chalmers.se (localhost [127.0.0.1]) by haddock.cd.chalmers.se (8.9.3+Sun/8.8.7) with ESMTP id CAA05169; Tue, 16 Oct 2001 02:54:25 +0200 (MET DST) Message-Id: <200110160054.CAA05169@haddock.cd.chalmers.se> X-Face: ^"+mumOlNwo;yI>`\39\txuVze?eiR9uqpo2*mE!9MWXgXI0v(3ArwymNWe'.q:eLl!=guD x{jGFEWN6,#HoN%2qRW;7.CL]9%Ap,067"u1%!NUqS.MhV'+,6$Fj-;W2Z}Y,JUZ'L+f)|B@3k3n;gLl*#i[(J-os#fNnDJ8m["|JWNwpORh|_.MGkR#|a~QS!"4hEQ{O{[Ii14{xD PU/:5wuv7m1=TK=.>G8wdfpY~]{H(Qa\1`%|Hz:!)c3f9UOW|WgE"4d\E7?oDu9. Content-Type: text/plain; charset=iso-8859-1 To: Nathan Scott cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - more xfsprogs unaligned accesses In-Reply-To: Message from Nathan Scott of "Mon, 15 Oct 2001 20:38:35 +1000." <200110151038.UAA25819@snort.melbourne.sgi.com> References: <200110151038.UAA25819@snort.melbourne.sgi.com> Date: Tue, 16 Oct 2001 02:54:25 +0200 From: Anders Hammarquist Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Should fix xfs_db/check unaligned access in addition to repair. > Reworked Keiths earlier solution for xfs_repair slightly to be > more friendly to the kernel/user code sharing regime. This seems to have cured the bus error in xfs_repair on sparc as well. (I've just done a quick smoketest on a clean filesystem, but the old xfs_repair broke on that too.) /Anders -- -- Of course I'm crazy, but that doesn't mean I'm wrong. Anders Hammarquist | iko@cd.chalmers.se Physics student, Chalmers University of Technology, | Hem: +46 31 88 48 50 G|teborg, Sweden. RADIO: SM6XMM and N2JGL | Mob: +46 707 27 86 87 From owner-linux-xfs@oss.sgi.com Mon Oct 15 18:02:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9G120N20382 for linux-xfs-outgoing; Mon, 15 Oct 2001 18:02:00 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9G11sD20360 for ; Mon, 15 Oct 2001 18:01:55 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 9BAD3C00B62 for ; Tue, 16 Oct 2001 07:38:23 +0800 (PHT) Received: from mail.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 24817C00B60 for ; Tue, 16 Oct 2001 07:38:19 +0800 (PHT) Date: Tue, 16 Oct 2001 07:38:18 +0800 (PHT) From: Federico Sevilla III To: Linux XFS Mailing List Subject: Re: Directory File Size [Slightly OT] In-Reply-To: <200110152230.f9FMUvA31431@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 15 Oct 2001 at 17:30, Steve Lord wrote: > A directory entry contains the name of the file, and the inode number > - which is 8 bytes on XFS. A small XFS directory lives within the > inode, and the size you see is the amount of space in the inode being > used by these entries plus some space management data structures. Once > the directory does not fit in the inode it grows to one filesystem > block - or 4Kbytes, it will sit at this size until it no longer fits > into one block, at which point we turn the directory into a btree of > blocks - the leaf blocks contain the entries and the node blocks > contain the index pointers to the entries. The smallest btree is 3 > blocks, so the next size you would see is 12K. > > After this it will go up a block at a time as it grows. If you remove > stuff from the directory it will shrink again - all the way back into > the inode. Wow. Nice comprehensive answer, and one that I believe can be understood by most would-be (and current) XFS system administrators as well. Seth, maybe this can be added to the FAQ? Do you think it's worth putting there? I expect that a number of people wonder what makes up a directory's size (ie: is the the total size of all contents?), and this answer by Steve is (as expected) great. :) --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Mon Oct 15 18:15:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9G1F1u20685 for linux-xfs-outgoing; Mon, 15 Oct 2001 18:15:01 -0700 Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9G1EqD20642 for ; Mon, 15 Oct 2001 18:14:53 -0700 Received: from [195.20.224.204] (helo=mrvdom00.schlund.de) by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 15tIol-0005nM-00 for linux-xfs@oss.sgi.com; Tue, 16 Oct 2001 03:14:51 +0200 Received: from pd958d6ce.dip.t-dialin.net ([217.88.214.206] helo=kernelpanix.aura.of.mankind) by mrvdom00.schlund.de with esmtp (Exim 2.12 #2) id 15tIok-0005Gj-00 for linux-xfs@oss.sgi.com; Tue, 16 Oct 2001 03:14:50 +0200 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.11.2/8.11.2) id f9G1Eot32360 for linux-xfs@oss.sgi.com; Tue, 16 Oct 2001 03:14:50 +0200 X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f Date: Tue, 16 Oct 2001 03:14:50 +0200 From: utz lehmann To: linux-xfs@oss.sgi.com Subject: FS corruption with 8 exabyte sized file. Message-ID: <20011016031450.A31823@s2y4n2c.de> References: <1003172400.4680.2.camel@stout.americas.sgi.com> <20011015161900.A3432@bistro.marx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011015161900.A3432@bistro.marx> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi pac@fortuitous.com [pac@fortuitous.com] wrote: > * The maximum accessible file offset of a Linux XFS file is 16 Terabytes on 4K > page size and 64 Terabytes on 16K page size. Is this true? I was able to create up to 8 exabyte sized files (with a big hole). But it produces fs corruption. [root@segv /root]# mkfs.xfs -f /dev/hda4 meta-data=/dev/hda4 isize=256 agcount=8, agsize=63256 blks data = bsize=4096 blocks=506047, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200 realtime =none extsz=65536 blocks=0, rtextents=0 [root@segv /root]# mount /dev/hda4 /mnt/ [root@segv /root]# cd /mnt/ [root@segv /mnt]# seq 1 100 | dd of=BIG1 bs=1024 seek=9007199254740991 0+1 records in 0+1 records out [root@segv /mnt]# ls -l total 4 -rw-r--r-- 1 root root 9223372036854775076 Oct 16 02:26 BIG1 [root@segv /mnt]# ls -lh total 4.0k -rw-r--r-- 1 root root 8.0E Oct 16 02:26 BIG1 [root@segv /mnt]# tail BIG1 91 92 93 94 95 96 97 98 99 100 [root@segv /mnt]# looks good so far. [root@segv /mnt]# cd [root@segv /root]# umount /mnt/ [root@segv /root]# xfs_check /dev/hda4 bad agf magic # 0 in ag 0 bad agf version # 0 in ag 0 block 0/0 expected type unknown got sb bad agi magic # 0 in ag 0 bad agi version # 0 in ag 0 bad magic # 0x58465342 in btbno block 0/0 bad magic # 0x58465342 in btcnt block 0/0 bad magic # 0x58465342 in inobt block 0/0 agi unlinked bucket 0 is 0 in ag 0 (inode=0) agi unlinked bucket 1 is 0 in ag 0 (inode=0) agi unlinked bucket 2 is 0 in ag 0 (inode=0) [...] agi unlinked bucket 61 is 0 in ag 0 (inode=0) agi unlinked bucket 62 is 0 in ag 0 (inode=0) agi unlinked bucket 63 is 0 in ag 0 (inode=0) I first tried it on my system partition. It trap in kdb (X running and no serial console). recovery crashed. xfs_repair from the 1.0.1 installer repaired it. 465 files from 221237 were in lost+found, most from kernel sources and a few from tuxracer. I verify the system with rpm -Va, looks good so far. A good working repair tool is great! Then i tried this with some kernel versions on a spare partition (hda4). 2.4.10 till todays CVS had this fs corruption. 2.4.2 till 2.4.10-pre13 had "Bad write on page 0xc13110cc0" (address varies) errors on umount but no corruption. All kernels were compiled with kgcc. System is a K6-500 256MB RAM. utz From owner-linux-xfs@oss.sgi.com Mon Oct 15 18:52:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9G1qXQ21286 for linux-xfs-outgoing; Mon, 15 Oct 2001 18:52:33 -0700 Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9G1qOD21257 for ; Mon, 15 Oct 2001 18:52:24 -0700 Received: from aegis.cs.princeton.edu (HELO divine) (128.112.152.6) by smtp.mail.vip.sc5.yahoo.com with SMTP; 16 Oct 2001 01:52:22 -0000 X-Apparently-From: Message-ID: <00f501c155e5$36a80fa0$6401a8c0@divine> From: "Zhifeng F. Chen" To: References: <1003172400.4680.2.camel@stout.americas.sgi.com> <20011015161900.A3432@bistro.marx> <20011016031450.A31823@s2y4n2c.de> Subject: Re: FS corruption with 8 exabyte sized file. Date: Mon, 15 Oct 2001 21:52:28 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I tried ur experiment. But my system doesn't crash when xfs_check. ----- Original Message ----- From: "utz lehmann" To: Sent: Monday, October 15, 2001 9:14 PM Subject: FS corruption with 8 exabyte sized file. > Hi > > pac@fortuitous.com [pac@fortuitous.com] wrote: > > * The maximum accessible file offset of a Linux XFS file is 16 Terabytes on 4K > > page size and 64 Terabytes on 16K page size. > > Is this true? > I was able to create up to 8 exabyte sized files (with a big hole). But it > produces fs corruption. > > > [root@segv /root]# mkfs.xfs -f /dev/hda4 > meta-data=/dev/hda4 isize=256 agcount=8, agsize=63256 blks > data = bsize=4096 blocks=506047, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=0 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=1200 > realtime =none extsz=65536 blocks=0, rtextents=0 > [root@segv /root]# mount /dev/hda4 /mnt/ > [root@segv /root]# cd /mnt/ > [root@segv /mnt]# seq 1 100 | dd of=BIG1 bs=1024 seek=9007199254740991 > 0+1 records in > 0+1 records out > [root@segv /mnt]# ls -l > total 4 > -rw-r--r-- 1 root root 9223372036854775076 Oct 16 02:26 BIG1 > [root@segv /mnt]# ls -lh > total 4.0k > -rw-r--r-- 1 root root 8.0E Oct 16 02:26 BIG1 > [root@segv /mnt]# tail BIG1 > 91 > 92 > 93 > 94 > 95 > 96 > 97 > 98 > 99 > 100 > [root@segv /mnt]# > > looks good so far. > > > [root@segv /mnt]# cd > [root@segv /root]# umount /mnt/ > [root@segv /root]# xfs_check /dev/hda4 > bad agf magic # 0 in ag 0 > bad agf version # 0 in ag 0 > block 0/0 expected type unknown got sb > bad agi magic # 0 in ag 0 > bad agi version # 0 in ag 0 > bad magic # 0x58465342 in btbno block 0/0 > bad magic # 0x58465342 in btcnt block 0/0 > bad magic # 0x58465342 in inobt block 0/0 > agi unlinked bucket 0 is 0 in ag 0 (inode=0) > agi unlinked bucket 1 is 0 in ag 0 (inode=0) > agi unlinked bucket 2 is 0 in ag 0 (inode=0) > [...] > agi unlinked bucket 61 is 0 in ag 0 (inode=0) > agi unlinked bucket 62 is 0 in ag 0 (inode=0) > agi unlinked bucket 63 is 0 in ag 0 (inode=0) > > > I first tried it on my system partition. It trap in kdb (X running and no > serial console). recovery crashed. xfs_repair from the 1.0.1 installer > repaired it. 465 files from 221237 were in lost+found, most from kernel > sources and a few from tuxracer. I verify the system with rpm -Va, looks > good so far. A good working repair tool is great! > > > Then i tried this with some kernel versions on a spare partition (hda4). > > 2.4.10 till todays CVS had this fs corruption. > > 2.4.2 till 2.4.10-pre13 had "Bad write on page 0xc13110cc0" (address varies) > errors on umount but no corruption. > > All kernels were compiled with kgcc. System is a K6-500 256MB RAM. > > > utz > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-linux-xfs@oss.sgi.com Mon Oct 15 22:24:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9G5OXl23447 for linux-xfs-outgoing; Mon, 15 Oct 2001 22:24:33 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9G5OUD23425 for ; Mon, 15 Oct 2001 22:24:30 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id WAA07913 for ; Mon, 15 Oct 2001 22:23:09 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id PAA19126; Tue, 16 Oct 2001 15:24:12 +1000 Date: Tue, 16 Oct 2001 15:24:12 +1000 From: Keith Owens Message-Id: <200110160524.PAA19126@sherman.melbourne.sgi.com> Subject: TAKE - Correct mount of NFS XFS root Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Correct mount of NFS XFS root. Date: Mon Oct 15 22:22:31 PDT 2001 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:104838a linux/fs/super.c - 1.64 From owner-linux-xfs@oss.sgi.com Mon Oct 15 22:29:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9G5TZX23601 for linux-xfs-outgoing; Mon, 15 Oct 2001 22:29:35 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9G5TVD23579 for ; Mon, 15 Oct 2001 22:29:31 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id HAA16013; Tue, 16 Oct 2001 07:29:29 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id HAA00548; Tue, 16 Oct 2001 07:29:28 +0200 (CEST) Date: Tue, 16 Oct 2001 07:29:28 +0200 (CEST) From: Seth Mos To: Federico Sevilla III cc: Linux XFS Mailing List Subject: Re: Directory File Size [Slightly OT] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 16 Oct 2001, Federico Sevilla III wrote: > On Mon, 15 Oct 2001 at 17:30, Steve Lord wrote: > > A directory entry contains the name of the file, and the inode number > > - which is 8 bytes on XFS. A small XFS directory lives within the > > inode, and the size you see is the amount of space in the inode being > > used by these entries plus some space management data structures. Once > > the directory does not fit in the inode it grows to one filesystem > > block - or 4Kbytes, it will sit at this size until it no longer fits > > into one block, at which point we turn the directory into a btree of > > blocks - the leaf blocks contain the entries and the node blocks > > contain the index pointers to the entries. The smallest btree is 3 > > blocks, so the next size you would see is 12K. > > > > After this it will go up a block at a time as it grows. If you remove > > stuff from the directory it will shrink again - all the way back into > > the inode. > > Wow. Nice comprehensive answer, and one that I believe can be understood > by most would-be (and current) XFS system administrators as well. Seth, > maybe this can be added to the FAQ? Do you think it's worth putting there? > I expect that a number of people wonder what makes up a directory's size > (ie: is the the total size of all contents?), and this answer by Steve is > (as expected) great. :) It's busy at work at the moment since I will be a week off to spain in a week. I will see if I can fit it in. Cheers From owner-linux-xfs@oss.sgi.com Tue Oct 16 00:51:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9G7pj325099 for linux-xfs-outgoing; Tue, 16 Oct 2001 00:51:45 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9G7pVD25077 for ; Tue, 16 Oct 2001 00:51:31 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id AAA20221 for ; Tue, 16 Oct 2001 00:51:26 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id RAA28933; Tue, 16 Oct 2001 17:50:28 +1000 Date: Tue, 16 Oct 2001 17:50:28 +1000 From: Keith Owens Message-Id: <200110160750.RAA28933@sherman.melbourne.sgi.com> Subject: TAKE - Upgrade XFS to 2.4.13-pre3 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Upgrade XFS to 2.4.13-pre3. Date: Tue Oct 16 00:45:36 PDT 2001 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:104843a linux/drivers/message/i2o/Config.in - 1.1 linux/drivers/message/i2o/i2o_scsi.h - 1.1 linux/drivers/message/i2o/i2o_scsi.c - 1.1 linux/drivers/message/i2o/i2o_proc.c - 1.1 linux/drivers/message/i2o/i2o_pci.c - 1.1 linux/drivers/message/i2o/i2o_lan.h - 1.1 linux/drivers/message/i2o/i2o_lan.c - 1.1 linux/drivers/message/i2o/i2o_core.c - 1.1 linux/drivers/message/i2o/i2o_config.c - 1.1 linux/drivers/message/i2o/i2o_block.c - 1.1 linux/drivers/message/i2o/README.ioctl - 1.1 linux/drivers/message/i2o/README - 1.1 linux/drivers/message/i2o/Makefile - 1.1 linux/drivers/char/shwdt.c - 1.1 linux/mm/swapfile.c - 1.41 linux/mm/swap.c - 1.14 linux/mm/memory.c - 1.64 linux/mm/filemap.c - 1.92 linux/include/linux/vt_buffer.h - 1.5 linux/include/linux/genhd.h - 1.17 linux/include/linux/blkdev.h - 1.41 linux/include/asm-alpha/vga.h - 1.7 linux/fs/super.c - 1.65 linux/fs/buffer.c - 1.86 linux/drivers/video/vgacon.c - 1.17 linux/drivers/video/promcon.c - 1.8 linux/drivers/video/newport_con.c - 1.9 linux/drivers/video/leofb.c - 1.9 linux/drivers/video/fbcon.c - 1.23 linux/drivers/video/fbcon-mfb.c - 1.6 linux/drivers/video/fbcon-iplan2p8.c - 1.7 linux/drivers/video/fbcon-iplan2p4.c - 1.7 linux/drivers/video/fbcon-iplan2p2.c - 1.7 linux/drivers/video/fbcon-ilbm.c - 1.6 linux/drivers/video/fbcon-cfb8.c - 1.6 linux/drivers/video/fbcon-cfb4.c - 1.6 linux/drivers/video/fbcon-cfb32.c - 1.6 linux/drivers/video/fbcon-cfb24.c - 1.6 linux/drivers/video/fbcon-cfb2.c - 1.6 linux/drivers/video/fbcon-cfb16.c - 1.6 linux/drivers/video/fbcon-afb.c - 1.6 linux/drivers/video/creatorfb.c - 1.12 linux/drivers/video/cgsixfb.c - 1.11 linux/drivers/video/Config.in - 1.29 linux/drivers/scsi/sr_ioctl.c - 1.19 linux/drivers/scsi/sd.c - 1.47 linux/drivers/net/via-rhine.c - 1.29 linux/drivers/macintosh/nvram.c - 1.10 linux/drivers/macintosh/macserial.c - 1.19 linux/drivers/char/console.c - 1.25 linux/drivers/char/Makefile - 1.51 linux/drivers/char/Config.in - 1.52 linux/drivers/cdrom/cdrom.c - 1.34 linux/drivers/block/xd.c - 1.24 linux/drivers/block/rd.c - 1.38 linux/drivers/block/ps2esdi.c - 1.23 linux/drivers/block/paride/pd.c - 1.19 linux/drivers/block/nbd.c - 1.23 linux/drivers/block/loop.c - 1.38 linux/drivers/block/ll_rw_blk.c - 1.77 linux/drivers/block/floppy.c - 1.28 linux/drivers/block/ataflop.c - 1.15 linux/drivers/block/amiflop.c - 1.17 linux/drivers/block/acsi.c - 1.18 linux/drivers/acorn/block/mfmhd.c - 1.15 linux/drivers/Makefile - 1.24 linux/arch/ppc/kernel/prep_setup.c - 1.25 linux/arch/ppc/kernel/prep_pci.c - 1.14 linux/arch/mips/config.in - 1.24 linux/arch/i386/kernel/setup.c - 1.57 linux/arch/i386/kernel/mtrr.c - 1.30 linux/arch/i386/defconfig - 1.75 linux/arch/i386/config.in - 1.65 linux/Makefile - 1.139 linux/Documentation/Configure.help - 1.108 linux/drivers/video/fbcon-vga-planes.c - 1.5 linux/drivers/i2o/i2o_scsi.h - 1.5 linux/drivers/i2o/i2o_scsi.c - 1.13 linux/drivers/i2o/i2o_proc.c - 1.16 linux/drivers/i2o/i2o_pci.c - 1.18 linux/drivers/i2o/i2o_lan.h - 1.10 linux/drivers/i2o/i2o_lan.c - 1.21 linux/drivers/i2o/i2o_core.c - 1.28 linux/drivers/i2o/i2o_config.c - 1.18 linux/drivers/i2o/i2o_block.c - 1.30 linux/drivers/i2o/README.ioctl - 1.6 linux/drivers/i2o/README - 1.7 linux/drivers/i2o/Makefile - 1.5 linux/drivers/i2o/Config.in - 1.5 linux/drivers/block/blkpg.c - 1.12 linux/drivers/block/cpqarray.c - 1.30 linux/arch/sh/mm/fault.c - 1.17 linux/arch/sh/kernel/sys_sh.c - 1.9 linux/arch/sh/kernel/signal.c - 1.12 linux/arch/sh/defconfig - 1.17 linux/arch/sh/config.in - 1.19 linux/arch/sh/Makefile - 1.8 linux/include/asm-sh/uaccess.h - 1.10 linux/fs/udf/lowlevel.c - 1.9 linux/arch/ppc/8xx_io/Config.in - 1.6 linux/drivers/video/tdfxfb.c - 1.14 linux/drivers/sbus/char/jsflash.c - 1.11 linux/drivers/video/dn_cfb8.c - 1.6 linux/arch/ia64/config.in - 1.19 linux/Documentation/filesystems/devfs/ToDo - 1.4 linux/drivers/video/matrox/matroxfb_accel.c - 1.6 linux/drivers/video/fbcon-hga.c - 1.4 linux/drivers/char/sh-sci.c - 1.15 linux/drivers/ide/ide.c - 1.33 linux/drivers/ide/ide-cd.c - 1.18 linux/drivers/ide/hd.c - 1.13 linux/drivers/s390/block/dasd.c - 1.15 linux/drivers/mtd/ftl.c - 1.9 linux/drivers/mtd/mtdblock.c - 1.8 linux/drivers/md/lvm.c - 1.21 linux/drivers/block/cciss.c - 1.17 linux/drivers/macintosh/rtc.c - 1.5 linux/drivers/md/md.c - 1.28 linux/drivers/video/fbcon-sti.c - 1.4 linux/drivers/video/sticon-bmode.c - 1.5 linux/drivers/video/sticon.c - 1.2 linux/mm/shmem.c - 1.18 linux/fs/reiserfs/prints.c - 1.6 linux/fs/reiserfs/inode.c - 1.16 linux/fs/reiserfs/bitmap.c - 1.7 linux/drivers/video/riva/accel.c - 1.2 linux/arch/cris/config.in - 1.7 linux/drivers/s390/block/xpram.c - 1.6 linux/arch/ppc/boot/prep/misc.c - 1.5 linux/drivers/mtd/nftlcore.c - 1.6 linux/drivers/mtd/mtdblock_ro.c - 1.4 linux/Documentation/sonypi.txt - 1.4 linux/drivers/char/sonypi.h - 1.4 linux/drivers/char/sonypi.c - 1.4 linux/drivers/video/pvr2fb.c - 1.3 linux/arch/sh/mm/cache-sh3.c - 1.2 linux/arch/sh/mm/cache-sh4.c - 1.2 linux/include/asm-ppc/ppcboot.h - 1.2 linux/drivers/ide/pdcraid.c - 1.4 linux/drivers/ide/hptraid.c - 1.5 From owner-linux-xfs@oss.sgi.com Tue Oct 16 01:54:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9G8sLq26127 for linux-xfs-outgoing; Tue, 16 Oct 2001 01:54:21 -0700 Received: from quasar.sif.it (IDENT:root@quasar.sif.it [131.154.110.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9G8rmD26040 for ; Tue, 16 Oct 2001 01:53:48 -0700 Received: from localhost (matteo@localhost) by quasar.sif.it (8.11.6/8.11.6) with ESMTP id f9G8s2R03446; Tue, 16 Oct 2001 10:54:02 +0200 Date: Tue, 16 Oct 2001 10:54:02 +0200 (CEST) From: Matteo Centonza To: Knuth Posern cc: , Subject: Re: HELP!!! In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Knuth, > I have (or had?!) a sotware RAID-5 with the following /etc/raidtab > raiddev /dev/md0 > raid-level 5 > nr-raid-disks 4 > nr-spare-disks 0 > persistent-superblock 1 > chunk-size 128 > > ####### RAID-devices > device /dev/hde1 > raid-disk 0 > > device /dev/hdg1 > raid-disk 1 > > device /dev/hdi1 > raid-disk 2 > > device /dev/hdk1 > raid-disk 3 > > I built the raid half a year ago. Formatted it with XFS (and a 2.4.5er > kernel). At the moment I use 2.4.10-xfs. > > The machine is a debian-unstable linux-server. > > The following happened to me: > > While I was playing an mp3-file on a console I got the following kernel > message(s) bumped into the console: > ___________________________________________________________________________ > hde: dma_intr: status=0x51 { DriveReady SeekComplete Error } > hde: dma_intr: error=0x40 { UncorrectableError }, LBAsect=56410433, > sector=56410368 > end_request: I/O error, dev 21:01 (hde), sector 56410368 > raid5: Disk failure on hde1, disabling device. Operation continuing on 2 > devices > md: recovery thread got woken up ... > md0: no spare disk to reconstruct array! -- continuing in degraded mode > md: recovery thread finished ... > md: updating md0 RAID superblock on device > md: hdi1 [events: 000000de](write) hdi1's sb offset: 45034816 > md: hdg1 [events: 000000de](write) hdg1's sb offset: 45034816 > md: (skipping faulty hde1 ) It seems that, when hde1 trashed, the raid was still in degraded mode (operational with 3 disks, without hdk1) so can't continue further. RAID5 protects against 1 disk failure (and unfortunately that's the second disk trashed). I've had the same problem with 2 IBM-DTLA-307045 that trashed in the last 2 weeks (leaving me the time to hot add a spare). Unfortunately, unless you have a cron job that periodically checks /proc/mdstat for raid health, or inspect periodically system logs, raid subsystem won't help you to detect disk failure. > XFS: device 0x900- XFS write error in file system meta-data block 0x40 in > md(9,0) > XFS: device 0x900- XFS write error in file system meta-data block 0x40 in > md(9,0) > XFS: device 0x900- XFS write error in file system meta-data block 0x40 in > md(9,0) > XFS: device 0x900- XFS write error in file system meta-data block 0x40 in > md(9,0) > XFS: device 0x900- XFS write error in file system meta-data block 0x40 in > md(9,0) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > I then switched to runlevel 0: > ____________________________________________________________________________ > Give root password for maintenance > (or type Control-D for normal startup): > jolie:~# umount /raid > xfs_unmount: xfs_ibusy says error/16 > XFS unmount got error 16 > linvfs_put_super: vfsp/0xdf467520 left dangling! > VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice > day... I've seen this message (busy inode) only when the RAID5 operates in degraded mode (e.g. after a disk failure) and you try to unmount the filesystem. But your case is substantially different (corrupt RAID layer). Maybe developers can shed light on this. > jolie:~# mount > /dev/hda3 on / type ext2 (rw,errors=remount-ro,errors=remount-ro) > proc on /proc type proc (rw) > devpts on /dev/pts type devpts (rw,gid=5,mode=620) > /dev/md0 on /mnt/raid type xfs (rw) > jolie:~# lsof > ... > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > The lsof did NOT show any open files on /mnt/raid. > So I tried again to unuount /mnt/raid: > _____________________________________________________________________________ > jolie:~# > jolie:~# umount /mnt/raid > umount: /mnt/raid: not mounted > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > But now it was unmounted already?! > > So I tried to mount it... > ____________________________________________________________________________ > jolie:~# > jolie:~# mount /mnt/raid > XFS: SB read failed > I/O error in filesystem ("md(9,0)") meta-data dev 0x900 block 0x0 > ("xfs_readsb") error 5 buf count 512 > mount: wrong fs type, bad option, bad superblock on /dev/md0, > or too many mounted file systems > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > I rebooted the computer - and got the following during bootup: > ____________________________________________________________________________ > Starting raid devices: (read) hde1's sb offset: 45034816 [events: > 000000dd] > (read) hdg1's sb offset: 45034816 [events: 000000df] > (read) hdi1's sb offset: 45034816 [events: 000000df] > md: autorun ... > md: considering hdi1 ... > md: adding hdi1 ... > md: adding hdg1 ... > md: adding hde1 ... > md: created md0 > md: bind > md: bind > md: bind > md: running: > md: hdi1's event counter: 000000df > md: hdg1's event counter: 000000df > md: hde1's event counter: 000000dd > md: superblock update time inconsistency -- using the most recent one > md: freshest: hdi1 > md: kicking non-fresh hde1 from array! > md: unbind > md: export_rdev(hde1) > md0: removing former faulty hde1! > md0: max total readahead window set to 1536k > md0: 3 data-disks, max readahead per data-disk: 512k > raid5: device hdi1 operational as raid disk 2 > raid5: device hdg1 operational as raid disk 1 > raid5: not enough operational devices for md0 (2/4 failed) > RAID5 conf printout: > --- rd:4 wd:2 fd:2 > disk 0, s:0, o:0, n:0 rd:0 us:1 dev:[dev 00:00] > disk 1, s:0, o:1, n:1 rd:1 us:1 dev:hdg1 > disk 2, s:0, o:1, n:2 rd:2 us:1 dev:hdi1 > disk 3, s:0, o:0, n:3 rd:3 us:1 dev:[dev 00:00] > raid5: failed to run raid set md0 > md: pers->run() failed ... > md :do_md_run() returned -22 > md: md0 stopped. > md: unbind > md: export_rdev(hdi1) > md: unbind > md: export_rdev(hdg1) > md: ... autorun DONE. > done. > Checking all file systems... > fsck 1.25 (20-Sep-2001) > Setting kernel variables. > Loading the saved-state of the serial devices... > Mounting local filesystems... > XFS: SB read failed > I/O error in filesystem ("md(9,0)") meta-data dev 0x900 block 0x0 > ("xfs_readsb") error 5 buf count 512 > mount: wrong fs type, bad option, bad superblock on /dev/md0, > or too many mounted file systems > (could this be the IDE device where you in fact use > ide-scsi so that sr0 or sda or so is needed?) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > I logged in and I edited the /etc/raidtab to have a SPARE-DISC: > ______________________________________________________________________________ > raiddev /dev/md0 > raid-level 5 > nr-raid-disks 4 > nr-spare-disks 1 > persistent-superblock 1 > chunk-size 128 > > ####### RAID-devices > device /dev/hde1 > raid-disk 0 > > device /dev/hdg1 > raid-disk 1 > > device /dev/hdi1 > raid-disk 2 > > device /dev/hdk1 > raid-disk 3 > > ####### Spare disks: > device /dev/hdc1 > spare-disk 1 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > I connected an identical harddrive (like the other raid-harddiscs) as > /dev/hdc. > > And rebooted again. - without any changes. > > I then read in the Software-RAID-Howto (from January 2000) to just remove > the faulty drive and instead connect a new drive. > So I connected the harddisc from /dev/hdc on /dev/hde (and edited the > /etc/raidtab to be as it was before (without spare-disks)!). > > And rebooted. > > md0 didn't start the array - because /dev/hde is 0K big (or something like > that). > That was because I had forgotten to built a partion on /dev/hde - so I > built the one partition (as on the other raid-drives too). > > And rebooted again - But md0 had an "Failed autostart of /dev/md0" again. > > And the Software-RAID-Howto told me to "raidhotadd /dev/md0 /dev/hde1". > Which I tried but it said somehting like: "/dev/md0 - no such raid is > running". > > So I tried to get /dev/md0 RUNNING again. > > In 6.1 of the Software-Raid-Howto there was something with "mkraid > /dev/md0 --force". > > So I tried: > ___________________________________________________________________________ > jolie:~# mkraid /dev/md0 --force > --force and the new RAID 0.90 hot-add/hot-remove functionality should be > used with extreme care! If /etc/raidtab is not in sync with the real > array > configuration, then a --force will DESTROY ALL YOUR DATA. It's especially > dangerous to use -f if the array is in degraded mode. > > PLEASE dont mention the --really-force flag in any email, documentation > or > HOWTO, just suggest the --force flag instead. Thus everybody will read > this warning at least once :) It really sucks to LOSE DATA. If you are > confident that everything will go ok then you can use the --really-force > flag. Also, if you are unsure what this is all about, dont hesitate to > ask questions on linux-raid@vger.rutgers.edu > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > And because I thought the raid needs a valid SUPERBLOCK on /dev/hde1 AND > the raid-configuration and /etc/raidtab ARE in SYNC - I then TRIED (and > hopefully NOT destroyed all my data?!?!?!). > ___________________________________________________________________________ > jolie:~# mkraid /dev/md0 --really-force > DESTROYING the contents of /dev/md0 in 5 seconds, Ctrl-C if unsure! > handling MD device /dev/md0 > analyzing super-block > disk 0: /dev/hde1, 45034888kB, raid superblock at 45034816kB > disk 1: /dev/hdg1, 45034888kB, raid superblock at 45034816kB > disk 2: /dev/hdi1, 45034888kB, raid superblock at 45034816kB > disk 3: /dev/hdk1, 45034888kB, raid superblock at 45034816kB > md: bind > md: bind > md: bind > md: bind > md: hdk1's event counter: 00000000 > md: hdi1's event counter: 00000000 > md: hdg1's event counter: 00000000 > md: hde1's event counter: 00000000 > md: md0: raid array is not clean -- starting background reconstruction > md0: max total readahead window set to 1536k > md0: 3 data-disks, max readahead per data-disk: 512k > > raid5: allocated 4339kB for md0 > raid5: raid level 5 set md0 active with 4 out of 4 devices, algorithm 0 > raid5: raid set md0 not clean; reconstructing parity > RAID5 conf printout: > --- rd:4 wd:4 fd:0 > disk 0, s:0, o:1, n:0 rd:0 us:1 dev:hde1 > disk 1, s:0, o:1, n:1 rd:1 us:1 dev:hdg1 > disk 2, s:0, o:1, n:2 rd:2 us:1 dev:hdi1 > disk 3, s:0, o:1, n:3 rd:3 us:1 dev:hdk1 > RAID5 conf printout: > --- rd:4 wd:4 fd:0 > disk 0, s:0, o:1, n:0 rd:0 us:1 dev:hde1 > disk 1, s:0, o:1, n:1 rd:1 us:1 dev:hdg1 > disk 2, s:0, o:1, n:2 rd:2 us:1 dev:hdi1 > disk 3, s:0, o:1, n:3 rd:3 us:1 dev:hdk1 > md: updating md0 RAID superblock on device > md: hdk1 [events: 00000001](write) hdk1's sb offset: 45034816 > md: syncing RAID array md0 > md: minimum _guaranteed_ reconstruction speed: 100 KB/sec/disc. > md: using maximum available idle IO bandwith (but not more than 100000 > KB/sec) for reconstruction. > md: using 124k window, over a total of 45034752 blocks. > md: hdi1 [events: 00000001](write) hdi1's sb offset: 45034816 > md: hdg1 [events: 00000001](write) hdg1's sb offset: 45034816 > md: hde1 [events: 00000001](write) hde1's sb offset: 45034816 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > And tried again to hotadd the /dev/hde1: > ___________________________________________________________________________ > jolie:~# raidhotadd /dev/md0 /dev/hde1 > md: trying to hot-add hde1 to md0 ... > /dev/md0: can not hot-add disk: disk busy! > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Then I checked /proc/mdstat. > Where it said about reconstructing - which sounds hopefully good... ?! > > But: > ___________________________________________________________________________ > jolie:~# mount /mnt/raid > XFS: bad magic number > XFS: SB validate failed > mount: wrong fs type, bad option, bad superblock on /dev/md0, > or too many mounted file systems > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > So I just rebooted again - in the hope that the raid-autostart during boot > time would bring some new/other results. But a mount /mnt/raid gives still > the same results!!!??? > > What can I do? - Is my data lost? - if so: Is there ANY CHANCE to get at > least SOME of it BACK SOMEHOW (it doesnt matter how difficult)!? > > ??? At this point it's _very_ __very__ hard to take something back :(. Good Luck! -m From owner-linux-xfs@oss.sgi.com Tue Oct 16 02:07:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9G97DC26550 for linux-xfs-outgoing; Tue, 16 Oct 2001 02:07:13 -0700 Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9G96rD26528 for ; Tue, 16 Oct 2001 02:06:53 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9G97TNe049762; Tue, 16 Oct 2001 11:07:29 +0200 (CEST) Message-Id: <4.3.2.7.2.20011016100533.03169b88@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Oct 2001 11:05:21 +0200 To: Knuth Posern , From: Seth Mos Subject: Re: HELP!!! Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 02:47 16-10-2001 +0200, Knuth Posern wrote: >Hi. > >I have (or had?!) a sotware RAID-5 with the following /etc/raidtab Short answer: You had. >I built the raid half a year ago. Formatted it with XFS (and a 2.4.5er >kernel). At the moment I use 2.4.10-xfs. > >The machine is a debian-unstable linux-server. > >The following happened to me: > >While I was playing an mp3-file on a console I got the following kernel >message(s) bumped into the console: >___________________________________________________________________________ >hde: dma_intr: status=0x51 { DriveReady SeekComplete Error } >hde: dma_intr: error=0x40 { UncorrectableError }, LBAsect=56410433, >sector=56410368 >end_request: I/O error, dev 21:01 (hde), sector 56410368 >raid5: Disk failure on hde1, disabling device. Operation continuing on 2 >devices >md: recovery thread got woken up ... >md0: no spare disk to reconstruct array! -- continuing in degraded mode >md: recovery thread finished ... >md: updating md0 RAID superblock on device >md: hdi1 [events: 000000de](write) hdi1's sb offset: 45034816 >md: hdg1 [events: 000000de](write) hdg1's sb offset: 45034816 >md: (skipping faulty hde1 ) >XFS: device 0x900- XFS write error in file system meta-data block 0x40 in >md(9,0) >XFS: device 0x900- XFS write error in file system meta-data block 0x40 in >md(9,0) >XFS: device 0x900- XFS write error in file system meta-data block 0x40 in >md(9,0) >XFS: device 0x900- XFS write error in file system meta-data block 0x40 in >md(9,0) >XFS: device 0x900- XFS write error in file system meta-data block 0x40 in >md(9,0) This should not happen with a md raid5. This means corruption. Normally when a disk fails in a md raid 1/5 set the OS is unaffected. XFS or not. This is the first alarming sign. >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >I then switched to runlevel 0: >____________________________________________________________________________ >Give root password for maintenance >(or type Control-D for normal startup): >jolie:~# umount /raid You should have had errors in your log before unmounting is what my intuition says. >xfs_unmount: xfs_ibusy says error/16 >XFS unmount got error 16 >linvfs_put_super: vfsp/0xdf467520 left dangling! >VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice >day... >jolie:~# mount >/dev/hda3 on / type ext2 (rw,errors=remount-ro,errors=remount-ro) >proc on /proc type proc (rw) >devpts on /dev/pts type devpts (rw,gid=5,mode=620) >/dev/md0 on /mnt/raid type xfs (rw) >jolie:~# lsof >... >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >The lsof did NOT show any open files on /mnt/raid. >So I tried again to unuount /mnt/raid: >_____________________________________________________________________________ >jolie:~# >jolie:~# umount /mnt/raid >umount: /mnt/raid: not mounted >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >But now it was unmounted already?! It was unmounted, with errors that is. That message you got with inodes left dangling was the result from a unclean unmount. >So I tried to mount it... Bad idea, i would have run xfs_repair first. >jolie:~# >jolie:~# mount /mnt/raid >XFS: SB read failed >I/O error in filesystem ("md(9,0)") meta-data dev 0x900 block 0x0 > ("xfs_readsb") error 5 buf count 512 >mount: wrong fs type, bad option, bad superblock on /dev/md0, > or too many mounted file systems >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >I rebooted the computer - and got the following during bootup: XFS: SB read failed >I/O error in filesystem ("md(9,0)") meta-data dev 0x900 block 0x0 > ("xfs_readsb") error 5 buf count 512 >mount: wrong fs type, bad option, bad superblock on /dev/md0, > or too many mounted file systems > (could this be the IDE device where you in fact use > ide-scsi so that sr0 or sda or so is needed?) >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This means it at least needs repair. Sometimes xfs_repair can recover a secondary superblock. >I logged in and I edited the /etc/raidtab to have a SPARE-DISC: Don't do that. >I connected an identical harddrive (like the other raid-harddiscs) as >/dev/hdc. Course of action on a failed disk. Power off the box. Remove the disk from hde. Insert the new disk to hde. Power on the box. raidhotadd hde. >And rebooted again. - without any changes. > >I then read in the Software-RAID-Howto (from January 2000) to just remove >the faulty drive and instead connect a new drive. Correct. >So I connected the harddisc from /dev/hdc on /dev/hde (and edited the >/etc/raidtab to be as it was before (without spare-disks)!). Don't touch the raidtab file when something goes wrong. Unless you really know what you are doing it will make things worse then it was. >And rebooted. > >md0 didn't start the array - because /dev/hde is 0K big (or something like >that). >That was because I had forgotten to built a partion on /dev/hde - so I >built the one partition (as on the other raid-drives too). That is not fatal, it happened to me once as well. >And rebooted again - But md0 had an "Failed autostart of /dev/md0" again. That is normal. It does note rebuild fully automatically. You have to instruct it yourself. >And the Software-RAID-Howto told me to "raidhotadd /dev/md0 /dev/hde1". correct. >Which I tried but it said somehting like: "/dev/md0 - no such raid is >running". what did /proc/mdstat tell? >So I tried to get /dev/md0 RUNNING again. > >In 6.1 of the Software-Raid-Howto there was something with "mkraid >/dev/md0 --force". DON'T DO THIS UNLESS YOU ARE BUILDING THE ARRAY! >So I tried: >And tried again to hotadd the /dev/hde1: You just remade the md0 array which means the disks will be syncing. >___________________________________________________________________________ >jolie:~# raidhotadd /dev/md0 /dev/hde1 >md: trying to hot-add hde1 to md0 ... >/dev/md0: can not hot-add disk: disk busy! >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >Then I checked /proc/mdstat. >Where it said about reconstructing - which sounds hopefully good... ?! It means you're data is gone. >But: >___________________________________________________________________________ >jolie:~# mount /mnt/raid >XFS: bad magic number >XFS: SB validate failed >mount: wrong fs type, bad option, bad superblock on /dev/md0, > or too many mounted file systems >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >So I just rebooted again - in the hope that the raid-autostart during boot >time would bring some new/other results. But a mount /mnt/raid gives still >the same results!!!??? It just synced random parts of the other disks and constructed parity out of that. >What can I do? - Is my data lost? - if so: Is there ANY CHANCE to get at >least SOME of it BACK SOMEHOW (it doesnt matter how difficult)!? No. :-( >??? > >Help would be VERY, VERY, VERY apreciated!!! I am very afraid that I can not help you anymore. You can try xfs_repair and see if it shows up anything or repair anything at all but I don't have high hopes. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Tue Oct 16 03:48:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GAmc128208 for linux-xfs-outgoing; Tue, 16 Oct 2001 03:48:38 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GAmPD28179 for ; Tue, 16 Oct 2001 03:48:25 -0700 Received: from dmz.tecosim.de ([194.24.222.241]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id DAA01525 for ; Tue, 16 Oct 2001 03:47:12 -0700 (PDT) mail_from (leh@mail.tecosim.de) Received: (from uucp@localhost) by dmz.tecosim.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) id f9GAPpZ26339; Tue, 16 Oct 2001 12:25:51 +0200 Received: from ns.tecosim.de(194.24.222.9) via SMTP by dmz.tecosim.de, id smtpdsHtIQz; Tue Oct 16 12:25:49 2001 Received: from donner.tecosim.de (donner.tecosim.de [194.24.222.109]) by ns.tecosim.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id f9GAPmp18170; Tue, 16 Oct 2001 12:25:48 +0200 Received: (from leh@localhost) by donner.tecosim.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) id f9GAPmZ13119; Tue, 16 Oct 2001 12:25:48 +0200 Date: Tue, 16 Oct 2001 12:25:48 +0200 From: Utz Lehmann To: "Zhifeng F. Chen" Cc: linux-xfs@oss.sgi.com Subject: Re: FS corruption with 8 exabyte sized file. Message-ID: <20011016122547.C28127@de.tecosim.com> References: <1003172400.4680.2.camel@stout.americas.sgi.com> <20011015161900.A3432@bistro.marx> <20011016031450.A31823@s2y4n2c.de> <00f501c155e5$36a80fa0$6401a8c0@divine> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <00f501c155e5$36a80fa0$6401a8c0@divine>; from mlrecv@yahoo.com on Mon, Oct 15, 2001 at 09:52:28PM -0400 X-Scanned-By: MIMEDefang 1.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi My system don't crash when i run xfs_check. It crashed after playing with such big files on my system partition and recovery after reboot fails. Then i made tests on a spare partition without crashes, but with fs corruptions. Sorry for confusion. I verified this here at work with a 2GB LVM volume on a SCSI disk. Same corruptions occured. utz Zhifeng F. Chen [mlrecv@yahoo.com] wrote: > I tried ur experiment. But my system doesn't crash when xfs_check. > > > ----- Original Message ----- > From: "utz lehmann" > To: > Sent: Monday, October 15, 2001 9:14 PM > Subject: FS corruption with 8 exabyte sized file. > > > > Hi > > > > pac@fortuitous.com [pac@fortuitous.com] wrote: > > > * The maximum accessible file offset of a Linux XFS file is 16 Terabytes > on 4K > > > page size and 64 Terabytes on 16K page size. > > > > Is this true? > > I was able to create up to 8 exabyte sized files (with a big hole). But it > > produces fs corruption. > > > > > > [root@segv /root]# mkfs.xfs -f /dev/hda4 > > meta-data=/dev/hda4 isize=256 agcount=8, agsize=63256 blks > > data = bsize=4096 blocks=506047, imaxpct=25 > > = sunit=0 swidth=0 blks, unwritten=0 > > naming =version 2 bsize=4096 > > log =internal log bsize=4096 blocks=1200 > > realtime =none extsz=65536 blocks=0, rtextents=0 > > [root@segv /root]# mount /dev/hda4 /mnt/ > > [root@segv /root]# cd /mnt/ > > [root@segv /mnt]# seq 1 100 | dd of=BIG1 bs=1024 seek=9007199254740991 > > 0+1 records in > > 0+1 records out > > [root@segv /mnt]# ls -l > > total 4 > > -rw-r--r-- 1 root root 9223372036854775076 Oct 16 02:26 BIG1 > > [root@segv /mnt]# ls -lh > > total 4.0k > > -rw-r--r-- 1 root root 8.0E Oct 16 02:26 BIG1 > > [root@segv /mnt]# tail BIG1 > > 91 > > 92 > > 93 > > 94 > > 95 > > 96 > > 97 > > 98 > > 99 > > 100 > > [root@segv /mnt]# > > > > looks good so far. > > > > > > [root@segv /mnt]# cd > > [root@segv /root]# umount /mnt/ > > [root@segv /root]# xfs_check /dev/hda4 > > bad agf magic # 0 in ag 0 > > bad agf version # 0 in ag 0 > > block 0/0 expected type unknown got sb > > bad agi magic # 0 in ag 0 > > bad agi version # 0 in ag 0 > > bad magic # 0x58465342 in btbno block 0/0 > > bad magic # 0x58465342 in btcnt block 0/0 > > bad magic # 0x58465342 in inobt block 0/0 > > agi unlinked bucket 0 is 0 in ag 0 (inode=0) > > agi unlinked bucket 1 is 0 in ag 0 (inode=0) > > agi unlinked bucket 2 is 0 in ag 0 (inode=0) > > [...] > > agi unlinked bucket 61 is 0 in ag 0 (inode=0) > > agi unlinked bucket 62 is 0 in ag 0 (inode=0) > > agi unlinked bucket 63 is 0 in ag 0 (inode=0) > > > > > > I first tried it on my system partition. It trap in kdb (X running and no > > serial console). recovery crashed. xfs_repair from the 1.0.1 installer > > repaired it. 465 files from 221237 were in lost+found, most from kernel > > sources and a few from tuxracer. I verify the system with rpm -Va, looks > > good so far. A good working repair tool is great! > > > > > > Then i tried this with some kernel versions on a spare partition (hda4). > > > > 2.4.10 till todays CVS had this fs corruption. > > > > 2.4.2 till 2.4.10-pre13 had "Bad write on page 0xc13110cc0" (address > varies) > > errors on umount but no corruption. > > > > All kernels were compiled with kgcc. System is a K6-500 256MB RAM. > > > > > > utz > > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com From owner-linux-xfs@oss.sgi.com Tue Oct 16 04:02:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GB2ZZ28786 for linux-xfs-outgoing; Tue, 16 Oct 2001 04:02:35 -0700 Received: from gk.hm.epigenomics.net (qmailr@gk.hm.epigenomics.net [212.121.137.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GB2VD28764 for ; Tue, 16 Oct 2001 04:02:31 -0700 Received: (qmail 5602 invoked from network); 16 Oct 2001 11:02:30 -0000 Received: from raman.epigenomics.epi (qmailr@192.168.2.2) by salam.epigenomics.epi with SMTP; 16 Oct 2001 11:02:30 -0000 Received: (qmail 25722 invoked from network); 16 Oct 2001 11:02:29 -0000 Received: from eigen.epigenomics.epi (qmailr@192.168.2.36) by raman.epigenomics.epi with SMTP; 16 Oct 2001 11:02:29 -0000 Received: (qmail 3590 invoked by uid 515); 16 Oct 2001 11:02:29 -0000 Date: Tue, 16 Oct 2001 13:02:29 +0200 From: Robert Sander To: linux-xfs@oss.sgi.com Subject: XFS patches for 2.4.12-ac3 Message-ID: <20011016130229.A3205@epigenomics.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.3.22i X-Operating-System: Linux eigen 2.2.19.client-piii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! Are there any XFS patches for the ac-series of 2.4? Greetings -- Robert Sander Computer Scientist Epigenomics AG Bioinformatics R&D www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Tue Oct 16 04:18:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GBIdn29042 for linux-xfs-outgoing; Tue, 16 Oct 2001 04:18:39 -0700 Received: from gk.hm.epigenomics.net (qmailr@gk.hm.epigenomics.net [212.121.137.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GBIZD29020 for ; Tue, 16 Oct 2001 04:18:35 -0700 Received: (qmail 5632 invoked from network); 16 Oct 2001 11:18:37 -0000 Received: from raman.epigenomics.epi (qmailr@192.168.2.2) by salam.epigenomics.epi with SMTP; 16 Oct 2001 11:18:37 -0000 Received: (qmail 30593 invoked from network); 16 Oct 2001 11:18:33 -0000 Received: from eigen.epigenomics.epi (qmailr@192.168.2.36) by raman.epigenomics.epi with SMTP; 16 Oct 2001 11:18:33 -0000 Received: (qmail 3817 invoked by uid 515); 16 Oct 2001 11:18:32 -0000 Date: Tue, 16 Oct 2001 13:18:32 +0200 From: Robert Sander To: linux-xfs@oss.sgi.com Subject: gcc 2.91.66 for debian Message-ID: <20011016131832.A3804@epigenomics.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.3.22i X-Operating-System: Linux eigen 2.2.19.client-piii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! I just found the FAQ stating that one should compile an XFS kernel with gcc 2.91.66. Even Debian potato has 2.95.2 onboard. Does anyone know a debian source for 2.91.66 that is installable on woody or potato? As I see many processes hanging in "D" state I want to give that option a try. Greetings -- Robert Sander Computer Scientist Epigenomics AG Bioinformatics R&D www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Tue Oct 16 04:20:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GBKRn29180 for linux-xfs-outgoing; Tue, 16 Oct 2001 04:20:27 -0700 Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GBKOD29157 for ; Tue, 16 Oct 2001 04:20:24 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9GBKrvI023686; Tue, 16 Oct 2001 13:20:53 +0200 (CEST) Message-Id: <4.3.2.7.2.20011016131841.036e7638@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Oct 2001 13:18:55 +0200 To: Robert Sander , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: XFS patches for 2.4.12-ac3 In-Reply-To: <20011016130229.A3205@epigenomics.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 13:02 16-10-2001 +0200, Robert Sander wrote: >Hi! > >Are there any XFS patches for the ac-series of 2.4? See FAQ. -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Tue Oct 16 04:37:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GBbA129461 for linux-xfs-outgoing; Tue, 16 Oct 2001 04:37:10 -0700 Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GBb7D29439 for ; Tue, 16 Oct 2001 04:37:07 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9GBbcb1078647; Tue, 16 Oct 2001 13:37:38 +0200 (CEST) Message-Id: <4.3.2.7.2.20011016133444.0376df50@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Oct 2001 13:35:38 +0200 To: Robert Sander , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: gcc 2.91.66 for debian In-Reply-To: <20011016131832.A3804@epigenomics.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 13:18 16-10-2001 +0200, Robert Sander wrote: >Hi! > >I just found the FAQ stating that one should compile an XFS kernel >with gcc 2.91.66. Even Debian potato has 2.95.2 onboard. >Does anyone know a debian source for 2.91.66 that is installable >on woody or potato? Use alien to convert the compat-egcs rpm fropm redhat and install that. People have reported success with that. The newer gcc from debian unstable seems to do reasonable as well. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Tue Oct 16 04:39:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GBdwn29625 for linux-xfs-outgoing; Tue, 16 Oct 2001 04:39:58 -0700 Received: from gk.hm.epigenomics.net (qmailr@gk.hm.epigenomics.net [212.121.137.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GBdsD29603 for ; Tue, 16 Oct 2001 04:39:55 -0700 Received: (qmail 5783 invoked from network); 16 Oct 2001 11:39:57 -0000 Received: from raman.epigenomics.epi (qmailr@192.168.2.2) by salam.epigenomics.epi with SMTP; 16 Oct 2001 11:39:57 -0000 Received: (qmail 6525 invoked from network); 16 Oct 2001 11:39:52 -0000 Received: from eigen.epigenomics.epi (qmailr@192.168.2.36) by raman.epigenomics.epi with SMTP; 16 Oct 2001 11:39:52 -0000 Received: (qmail 4062 invoked by uid 515); 16 Oct 2001 11:39:52 -0000 Date: Tue, 16 Oct 2001 13:39:52 +0200 From: Robert Sander To: Seth Mos Cc: linux-xfs@oss.sgi.com Subject: Re: gcc 2.91.66 for debian Message-ID: <20011016133952.B3895@epigenomics.de> References: <20011016131832.A3804@epigenomics.de> <4.3.2.7.2.20011016133444.0376df50@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20011016133444.0376df50@pop.xs4all.nl> User-Agent: Mutt/1.3.22i X-Operating-System: Linux eigen 2.2.19.client-piii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Oct 16, 2001 at 01:35:38PM +0200, Seth Mos wrote: > Use alien to convert the compat-egcs rpm fropm redhat and install that. > People have reported success with that. The newer gcc from debian unstable > seems to do reasonable as well. I compiled the Madrake 2.4.8 XFS kernel with gcc 2.95.4 and had no luck, so I want to give 2.91.66 a try. Greetings -- Robert Sander Computer Scientist Epigenomics AG Bioinformatics R&D www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Tue Oct 16 04:45:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GBj1j29852 for linux-xfs-outgoing; Tue, 16 Oct 2001 04:45:01 -0700 Received: from malik.slb.nwc.acsalaska.net (malik.slb.nwc.acsalaska.net [209.112.155.41]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GBivD29826 for ; Tue, 16 Oct 2001 04:44:57 -0700 Received: from erbenson.alaska.net (71-pm6.nwc.alaska.net [209.112.139.71]) by malik.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id f9GBit408255 for ; Tue, 16 Oct 2001 03:44:55 -0800 (AKDT) (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 259E2394D for ; Tue, 16 Oct 2001 03:44:54 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 0CD6A10260; Tue, 16 Oct 2001 03:44:54 -0800 (AKDT) Date: Tue, 16 Oct 2001 03:44:53 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: gcc 2.91.66 for debian Message-ID: <20011016034453.B7816@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20011016131832.A3804@epigenomics.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rS8CxjVDS/+yyDmU" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011016131832.A3804@epigenomics.de>; from robert.sander@epigenomics.com on Tue, Oct 16, 2001 at 01:18:32PM +0200 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --rS8CxjVDS/+yyDmU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 16, 2001 at 01:18:32PM +0200, Robert Sander wrote: > Hi! >=20 > I just found the FAQ stating that one should compile an XFS kernel > with gcc 2.91.66. Even Debian potato has 2.95.2 onboard. > Does anyone know a debian source for 2.91.66 that is installable > on woody or potato? it also mentions that 2.95.4 in woody seems to be OK. i have had no problems with that version on i386. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --rS8CxjVDS/+yyDmU 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 iEYEARECAAYFAjvMHbUACgkQJKx7GixEevxAmACeL4nSAAt2MMW05xQF0Fsy0pZY /84An3FCfDf7f5vGJ1QvIdG6BIg1fi2J =QGfH -----END PGP SIGNATURE----- --rS8CxjVDS/+yyDmU-- From owner-linux-xfs@oss.sgi.com Tue Oct 16 05:07:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GC7fa30265 for linux-xfs-outgoing; Tue, 16 Oct 2001 05:07:41 -0700 Received: from pcrz10.HRZ.Uni-Marburg.DE (root@pcrz10.HRZ.Uni-Marburg.DE [137.248.9.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GC7ID30236 for ; Tue, 16 Oct 2001 05:07:18 -0700 Received: from localhost (Posern@localhost) by pcrz10.HRZ.Uni-Marburg.DE (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id OAA27693; Tue, 16 Oct 2001 14:07:13 +0200 X-Authentication-Warning: pcrz10.HRZ.Uni-Marburg.DE: Posern owned process doing -bs Date: Tue, 16 Oct 2001 14:07:13 +0200 (CEST) From: Posern X-X-Sender: To: Seth Mos cc: Knuth Posern , Subject: Re: HELP!!! In-Reply-To: <4.3.2.7.2.20011016100533.03169b88@pop.xs4all.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi. First thanks for your answers so far! Yippie... And I know, that I did the rest in forcing the mkraid command! But just for the future - cause I still like RAIDs - only this IBM harddisc modell "DTLA 307045" (or something like this)... Is total crap - In half a year I now have 5 broken harddiscs from this serie! Just for the future: 1.) I have to check the /proc/mdstats to always see if all harddiscs are running or if the raid is in degraded mode (means that one harddisc is not in use - because of errors, or???) ??? 2.) What schould I had done at the point of the failure of the second disc to rescue my data??? Because the raidhotadd thing is only possible if one harddisc fails! 3.) To backup my raid-data nevertheless it is a raid5 - but what is a good, safe and fast method to backup 130GB of data??? And - because it is my private raid and I am a poor student - a most likely a cheap method to backup...??! Greetings, Knuth Posern. --- On Tue, 16 Oct 2001, Seth Mos wrote: > At 02:47 16-10-2001 +0200, Knuth Posern wrote: > >Hi. > > > >I have (or had?!) a sotware RAID-5 with the following /etc/raidtab > > Short answer: You had. > > >I built the raid half a year ago. Formatted it with XFS (and a 2.4.5er > >kernel). At the moment I use 2.4.10-xfs. > > > >The machine is a debian-unstable linux-server. > > > >The following happened to me: > > > >While I was playing an mp3-file on a console I got the following kernel > >message(s) bumped into the console: > >___________________________________________________________________________ > >hde: dma_intr: status=0x51 { DriveReady SeekComplete Error } > >hde: dma_intr: error=0x40 { UncorrectableError }, LBAsect=56410433, > >sector=56410368 > >end_request: I/O error, dev 21:01 (hde), sector 56410368 > >raid5: Disk failure on hde1, disabling device. Operation continuing on 2 > >devices > >md: recovery thread got woken up ... > >md0: no spare disk to reconstruct array! -- continuing in degraded mode > >md: recovery thread finished ... > >md: updating md0 RAID superblock on device > >md: hdi1 [events: 000000de](write) hdi1's sb offset: 45034816 > >md: hdg1 [events: 000000de](write) hdg1's sb offset: 45034816 > >md: (skipping faulty hde1 ) > >XFS: device 0x900- XFS write error in file system meta-data block 0x40 in > >md(9,0) > >XFS: device 0x900- XFS write error in file system meta-data block 0x40 in > >md(9,0) > >XFS: device 0x900- XFS write error in file system meta-data block 0x40 in > >md(9,0) > >XFS: device 0x900- XFS write error in file system meta-data block 0x40 in > >md(9,0) > >XFS: device 0x900- XFS write error in file system meta-data block 0x40 in > >md(9,0) > > This should not happen with a md raid5. This means corruption. Normally > when a disk fails in a md raid 1/5 set the OS is unaffected. XFS or not. > > This is the first alarming sign. > > >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >I then switched to runlevel 0: > >____________________________________________________________________________ > >Give root password for maintenance > >(or type Control-D for normal startup): > >jolie:~# umount /raid > > You should have had errors in your log before unmounting is what my > intuition says. > > >xfs_unmount: xfs_ibusy says error/16 > >XFS unmount got error 16 > >linvfs_put_super: vfsp/0xdf467520 left dangling! > >VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice > >day... > >jolie:~# mount > >/dev/hda3 on / type ext2 (rw,errors=remount-ro,errors=remount-ro) > >proc on /proc type proc (rw) > >devpts on /dev/pts type devpts (rw,gid=5,mode=620) > >/dev/md0 on /mnt/raid type xfs (rw) > >jolie:~# lsof > >... > >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >The lsof did NOT show any open files on /mnt/raid. > >So I tried again to unuount /mnt/raid: > >_____________________________________________________________________________ > >jolie:~# > >jolie:~# umount /mnt/raid > >umount: /mnt/raid: not mounted > >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >But now it was unmounted already?! > > It was unmounted, with errors that is. That message you got with inodes > left dangling was the result from a unclean unmount. > > >So I tried to mount it... > > Bad idea, i would have run xfs_repair first. > > >jolie:~# > >jolie:~# mount /mnt/raid > >XFS: SB read failed > >I/O error in filesystem ("md(9,0)") meta-data dev 0x900 block 0x0 > > ("xfs_readsb") error 5 buf count 512 > >mount: wrong fs type, bad option, bad superblock on /dev/md0, > > or too many mounted file systems > >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >I rebooted the computer - and got the following during bootup: > > > >XFS: SB read failed > >I/O error in filesystem ("md(9,0)") meta-data dev 0x900 block 0x0 > > ("xfs_readsb") error 5 buf count 512 > >mount: wrong fs type, bad option, bad superblock on /dev/md0, > > or too many mounted file systems > > (could this be the IDE device where you in fact use > > ide-scsi so that sr0 or sda or so is needed?) > >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > This means it at least needs repair. Sometimes xfs_repair can recover a > secondary superblock. > > >I logged in and I edited the /etc/raidtab to have a SPARE-DISC: > > Don't do that. > > >I connected an identical harddrive (like the other raid-harddiscs) as > >/dev/hdc. > > Course of action on a failed disk. > Power off the box. > Remove the disk from hde. > Insert the new disk to hde. > Power on the box. > raidhotadd hde. > > >And rebooted again. - without any changes. > > > >I then read in the Software-RAID-Howto (from January 2000) to just remove > >the faulty drive and instead connect a new drive. > > Correct. > > >So I connected the harddisc from /dev/hdc on /dev/hde (and edited the > >/etc/raidtab to be as it was before (without spare-disks)!). > > Don't touch the raidtab file when something goes wrong. Unless you really > know what you are doing it will make things worse then it was. > > >And rebooted. > > > >md0 didn't start the array - because /dev/hde is 0K big (or something like > >that). > >That was because I had forgotten to built a partion on /dev/hde - so I > >built the one partition (as on the other raid-drives too). > > That is not fatal, it happened to me once as well. > > >And rebooted again - But md0 had an "Failed autostart of /dev/md0" again. > > That is normal. It does note rebuild fully automatically. You have to > instruct it yourself. > > >And the Software-RAID-Howto told me to "raidhotadd /dev/md0 /dev/hde1". > > correct. > > >Which I tried but it said somehting like: "/dev/md0 - no such raid is > >running". > > what did /proc/mdstat tell? > > >So I tried to get /dev/md0 RUNNING again. > > > >In 6.1 of the Software-Raid-Howto there was something with "mkraid > >/dev/md0 --force". > > DON'T DO THIS UNLESS YOU ARE BUILDING THE ARRAY! > > >So I tried: > > > > >And tried again to hotadd the /dev/hde1: > > You just remade the md0 array which means the disks will be syncing. > > >___________________________________________________________________________ > >jolie:~# raidhotadd /dev/md0 /dev/hde1 > >md: trying to hot-add hde1 to md0 ... > >/dev/md0: can not hot-add disk: disk busy! > >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >Then I checked /proc/mdstat. > >Where it said about reconstructing - which sounds hopefully good... ?! > > It means you're data is gone. > > >But: > >___________________________________________________________________________ > >jolie:~# mount /mnt/raid > >XFS: bad magic number > >XFS: SB validate failed > >mount: wrong fs type, bad option, bad superblock on /dev/md0, > > or too many mounted file systems > >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >So I just rebooted again - in the hope that the raid-autostart during boot > >time would bring some new/other results. But a mount /mnt/raid gives still > >the same results!!!??? > > It just synced random parts of the other disks and constructed parity out > of that. > > >What can I do? - Is my data lost? - if so: Is there ANY CHANCE to get at > >least SOME of it BACK SOMEHOW (it doesnt matter how difficult)!? > > No. :-( > > >??? > > > >Help would be VERY, VERY, VERY apreciated!!! > > I am very afraid that I can not help you anymore. > > You can try xfs_repair and see if it shows up anything or repair anything > at all but I don't have high hopes. > > Cheers > -- > Seth > Every program has two purposes one for which > it was written and another for which it wasn't > I use the last kind. > From owner-linux-xfs@oss.sgi.com Tue Oct 16 06:53:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GDr7q31569 for linux-xfs-outgoing; Tue, 16 Oct 2001 06:53:07 -0700 Received: from mx.linux.net.cn ([210.52.24.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GDqvD31546 for ; Tue, 16 Oct 2001 06:52:58 -0700 Received: from dfbbb.cn.mvd (unknown [211.99.247.66]) by mx.linux.net.cn (Postfix) with ESMTP id BDD45DB0 for ; Tue, 16 Oct 2001 21:53:35 +0800 (CST) Received: (from dfbb@localhost) by dfbbb.cn.mvd (8.11.2/8.11.2) id f9GDppD02693 for linux-xfs@oss.sgi.com; Tue, 16 Oct 2001 21:51:51 +0800 Date: Tue, 16 Oct 2001 21:51:51 +0800 From: Fang Han To: linux-xfs Subject: LVM bug. Message-ID: <20011016215151.D1274@dfbbb.cn.mvd> Mail-Followup-To: linux-xfs Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk My XFS version was 1.0.1, on an machine with one PIII 750 on an dual processor motherboard 2x50G scsi disk on aic7xxx lvm version 0.9.1beta6 When I create xfs over lvm. and mount it. the mount speed is real slow, some time it success, some times it tell me XFS: failed to read root inode When I create xfs over lvm again, It will oops. oops out put is here. BTW: 1. When I make e2gs over lvm on this machine, It works fine. 2. With the same kernel and same operation running on other machine, ( 1 IDE machine, 1 SCSI+Raid+SMP machine) It works fine, And the time of mount running very fast. >>EIP; d084daa2 <[xfs_support]mrupdatef+6/3c> <===== Trace; d089a2df <[xfs]xfs_iget+c3/110> Trace; d089a745 <[xfs]xfs_ilock_ra+71/9c> Trace; d089a783 <[xfs]xfs_ilock+13/18> Trace; d089a2df <[xfs]xfs_iget+c3/110> Trace; d089a2df <[xfs]xfs_iget+c3/110> Trace; d08a9362 <[xfs]xfs_mountfs+d8e/11e8> Trace; d082d9d7 <[aic7xxx]aic7xxx_queue+173/180> Trace; d08856f0 <[xfs]xfs_dir2_mount+0/124> Trace; c0105b99 <__down+a1/ac> Trace; d08a822b <[xfs]xfs_readsb+b7/d0> Trace; d08b1bee <[xfs]xfs_cmountfs+512/5bc> Trace; d08c06c7 <[xfs]linvfs_read+a7/d4> Trace; d08b1e09 <[xfs]xfs_mount+a9/b4> Trace; d08d4500 <[xfs]__module_kernel_version+0/20> Trace; d08d4500 <[xfs]__module_kernel_version+0/20> Trace; d08b1e37 <[xfs]xfs_vfsmount+23/38> Trace; d08d4500 <[xfs]__module_kernel_version+0/20> Trace; d08cd1d9 <[xfs]linvfs_read_super+1b9/380> Trace; d08d4500 <[xfs]__module_kernel_version+0/20> Trace; d08d4280 <[xfs]xfs_fs_type+0/20> Trace; d085ec7c <[xfs]xfs_acl_iaccess+2c/94> Trace; d08ceb40 <[xfs].rodata.start+420/5c4> Trace; d085ec7c <[xfs]xfs_acl_iaccess+2c/94> Trace; d08ceb40 <[xfs].rodata.start+420/5c4> Trace; c0143d8a Trace; c014532f Trace; c01385c4 Trace; c013628b Trace; c0136480 Trace; d08d4280 <[xfs]xfs_fs_type+0/20> Trace; c0136eca Trace; d08d4280 <[xfs]xfs_fs_type+0/20> Trace; d08d4280 <[xfs]xfs_fs_type+0/20> Trace; c0136d0c Trace; c01370cc Trace; c0106d9b Code; d084daa2 <[xfs_support]mrupdatef+6/3c> 00000000 <_EIP>: Code; d084daa2 <[xfs_support]mrupdatef+6/3c> <===== 0: 83 3b 00 cmpl $0x0,(%ebx) <===== Code; d084daa5 <[xfs_support]mrupdatef+9/3c> 3: 74 1d je 22 <_EIP+0x22> d084dac4 <[xfs_support]mrupdatef+28/3c> Code; d084daa7 <[xfs_support]mrupdatef+b/3c> 5: ff 43 08 incl 0x8(%ebx) Code; d084daaa <[xfs_support]mrupdatef+e/3c> 8: 6a 01 push $0x1 Code; d084daac <[xfs_support]mrupdatef+10/3c> a: 8d 43 28 lea 0x28(%ebx),%eax Code; d084daaf <[xfs_support]mrupdatef+13/3c> d: 50 push %eax Code; d084dab0 <[xfs_support]mrupdatef+14/3c> e: 8d 43 1c lea 0x1c(%ebx),%eax Code; d084dab3 <[xfs_support]mrupdatef+17/3c> 11: 50 push %eax Code; d084dab4 <[xfs_support]mrupdatef+18/3c> 12: e8 d7 00 00 00 call ee <_EIP+0xee> d084db90 <[xfs_su From owner-linux-xfs@oss.sgi.com Tue Oct 16 06:59:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GDxn031770 for linux-xfs-outgoing; Tue, 16 Oct 2001 06:59:49 -0700 Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GDxkD31747 for ; Tue, 16 Oct 2001 06:59:46 -0700 Received: from club-internet.fr (bas15-114.idf.w.club-internet.fr [213.44.255.114]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 998D516A4 for ; Tue, 16 Oct 2001 15:59:44 +0200 (CEST) Message-ID: <3BCC417E.5C56E61D@club-internet.fr> Date: Tue, 16 Oct 2001 16:17:34 +0200 From: Jean Francois Martinez X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.5-SGI_XFS_1.0.1_Indy i586) X-Accept-Language: en MIME-Version: 1.0 Cc: Linux XFS Mailing List Subject: Dynamic resizing References: <1003172400.4680.2.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Does XFS support dynamic resizing? Are there plans to implement it? -- Jean Francois Martinez The Independence project: because Linux should be for everyone http://independence.seul.org From owner-linux-xfs@oss.sgi.com Tue Oct 16 07:07:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GE7YI32058 for linux-xfs-outgoing; Tue, 16 Oct 2001 07:07:34 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GE7TD32036 for ; Tue, 16 Oct 2001 07:07:29 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9GE7LW02097 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Tue, 16 Oct 2001 07:07:21 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id QAA3353026 for ; Tue, 16 Oct 2001 16:06:13 +0200 (CEST) mail_from (sandeen@sgi.com) Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA86870; Tue, 16 Oct 2001 07:06:47 -0700 (PDT) Message-ID: <3BCC3E36.C64F8878@sgi.com> Date: Tue, 16 Oct 2001 09:03:34 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: Utz Lehmann CC: "Zhifeng F. Chen" , linux-xfs@oss.sgi.com Subject: Re: FS corruption with 8 exabyte sized file. References: <1003172400.4680.2.camel@stout.americas.sgi.com> <20011015161900.A3432@bistro.marx> <20011016031450.A31823@s2y4n2c.de> <00f501c155e5$36a80fa0$6401a8c0@divine> <20011016122547.C28127@de.tecosim.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Utz - I verified this here as well... in fact it happens before 8 exabytes. :) Also, for some sizes, the full sequence of 1-100 was not in the file. Looks like something is wrapping around and obliterating parts of the superblock? Looks like an interesting problem, but one I might not get to immediately, working on other more pressing things - just stay away from those 8 exabyte files for a little while! :) -Eric Utz Lehmann wrote: > > Hi > > My system don't crash when i run xfs_check. It crashed after playing with > such big files on my system partition and recovery after reboot fails. Then > i made tests on a spare partition without crashes, but with fs corruptions. > Sorry for confusion. > > I verified this here at work with a 2GB LVM volume on a SCSI disk. Same > corruptions occured. > > utz -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Oct 16 07:11:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GEBDA32227 for linux-xfs-outgoing; Tue, 16 Oct 2001 07:11:13 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GEBBD32205 for ; Tue, 16 Oct 2001 07:11:11 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA11147 for ; Tue, 16 Oct 2001 07:11:07 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA3318917; Tue, 16 Oct 2001 09:09:54 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA94690; Tue, 16 Oct 2001 09:09:54 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9GE7bM32438; Tue, 16 Oct 2001 09:07:37 -0500 Message-Id: <200110161407.f9GE7bM32438@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Jean Francois Martinez cc: Linux XFS Mailing List Subject: Re: Dynamic resizing In-Reply-To: Message from Jean Francois Martinez of "Tue, 16 Oct 2001 16:17:34 +0200." <3BCC417E.5C56E61D@club-internet.fr> Date: Tue, 16 Oct 2001 09:07:37 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Does XFS support dynamic resizing? Are there plans to implement it? > > -- > Jean Francois Martinez > > The Independence project: because Linux should be for everyone > http://independence.seul.org read the man page on xfs_growfs - this can expand the filesystem, there is no way to shrink it - nor are there plans to add this. Shrinking a filesystem as complex as XFS is not a small task. Steve From owner-linux-xfs@oss.sgi.com Tue Oct 16 07:18:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GEIRE32447 for linux-xfs-outgoing; Tue, 16 Oct 2001 07:18:27 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GEIOD32424 for ; Tue, 16 Oct 2001 07:18:24 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9GEIJW03025 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Tue, 16 Oct 2001 07:18:19 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA07726 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Tue, 16 Oct 2001 07:18:18 -0700 (PDT) Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id QAA3384963 for ; Tue, 16 Oct 2001 16:17:09 +0200 (CEST) mail_from (sandeen@sgi.com) Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA73207; Tue, 16 Oct 2001 07:17:44 -0700 (PDT) Message-ID: <3BCC40C6.D23D0284@sgi.com> Date: Tue, 16 Oct 2001 09:14:30 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: Jean Francois Martinez CC: Linux XFS Mailing List Subject: Re: Dynamic resizing References: <1003172400.4680.2.camel@stout.americas.sgi.com> <3BCC417E.5C56E61D@club-internet.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Jean Francois Martinez wrote: > > Does XFS support dynamic resizing? Are there plans to implement it? Only in one direction (growing) - see the man pages for xfs_growfs, and either be sure to use the recommended compiler, or a very recent kernel - we recently unearthed a compiler bug that exhibited itself in the growfs code. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Oct 16 07:22:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GEMI132683 for linux-xfs-outgoing; Tue, 16 Oct 2001 07:22:18 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GEMFD32661 for ; Tue, 16 Oct 2001 07:22:15 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9GEM9W03415 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Tue, 16 Oct 2001 07:22:09 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA83915 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Tue, 16 Oct 2001 07:21:56 -0700 (PDT) Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id QAA3362262 for ; Tue, 16 Oct 2001 16:20:47 +0200 (CEST) mail_from (sandeen@sgi.com) Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA20775; Tue, 16 Oct 2001 07:21:21 -0700 (PDT) Message-ID: <3BCC41A0.5D819E80@sgi.com> Date: Tue, 16 Oct 2001 09:18:08 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: Utz Lehmann , "Zhifeng F. Chen" , linux-xfs@oss.sgi.com Subject: Re: FS corruption with 8 exabyte sized file. References: <1003172400.4680.2.camel@stout.americas.sgi.com> <20011015161900.A3432@bistro.marx> <20011016031450.A31823@s2y4n2c.de> <00f501c155e5$36a80fa0$6401a8c0@divine> <20011016122547.C28127@de.tecosim.com> <3BCC3E36.C64F8878@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: > > Looks like something is wrapping around and obliterating > parts of the superblock? Err... maybe not the superblock, but various parts of the on-disk formatting for xfs. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Oct 16 08:11:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GFBce01297 for linux-xfs-outgoing; Tue, 16 Oct 2001 08:11:38 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GFBaD01275 for ; Tue, 16 Oct 2001 08:11:36 -0700 Received: from due.stud.ntnu.no (due.stud.ntnu.no [129.241.56.71]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA06684 for ; Tue, 16 Oct 2001 08:10:27 -0700 (PDT) mail_from (sebastid@stud.ntnu.no) Received: from tiger.stud.ntnu.no (tiger.stud.ntnu.no [129.241.56.180]) by due.stud.ntnu.no (Postfix) with ESMTP id DE51617ACA; Tue, 16 Oct 2001 17:10:53 +0200 (CEST) Received: from localhost (sebastid@localhost) by tiger.stud.ntnu.no (8.11.6/8.10.0.Beta12) with ESMTP id f9GFAqC28912; Tue, 16 Oct 2001 17:10:52 +0200 X-Authentication-Warning: tiger.stud.ntnu.no: sebastid owned process doing -bs Date: Tue, 16 Oct 2001 17:10:52 +0200 (CEST) From: Sebastian Dransfeld To: Seth Mos Cc: Robert Sander , Subject: Re: XFS patches for 2.4.12-ac3 In-Reply-To: <4.3.2.7.2.20011016131841.036e7638@pop.xs4all.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 16 Oct 2001, Seth Mos wrote: > At 13:02 16-10-2001 +0200, Robert Sander wrote: > >Hi! > > > >Are there any XFS patches for the ac-series of 2.4? > > See FAQ. > And check with mandrake, the cooker kernel is 2.4.12-ac with xfs patch included (last time I checked). seb From owner-linux-xfs@oss.sgi.com Tue Oct 16 08:21:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GFLbp01501 for linux-xfs-outgoing; Tue, 16 Oct 2001 08:21:37 -0700 Received: from mta5-rme.xtra.co.nz (mta5-rme.xtra.co.nz [210.86.15.138]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GFLYD01479 for ; Tue, 16 Oct 2001 08:21:34 -0700 Received: from mdew ([210.54.225.222]) by mta5-rme.xtra.co.nz with ESMTP id <20011016152128.ZSSQ28493.mta5-rme.xtra.co.nz@mdew>; Wed, 17 Oct 2001 04:21:28 +1300 Subject: Re: XFS patches for 2.4.12-ac3 From: mdew To: Robert Sander Cc: linux-xfs@oss.sgi.com In-Reply-To: <20011016130229.A3205@epigenomics.de> References: <20011016130229.A3205@epigenomics.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 17 Oct 2001 15:34:09 +1300 Message-Id: <1003286050.5725.9.camel@mdew> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2001-10-17 at 00:02, Robert Sander wrote: > Hi! > > Are there any XFS patches for the ac-series of 2.4? wouldnt it be possible to make an inter-diff between -ac and XFS? From owner-linux-xfs@oss.sgi.com Tue Oct 16 10:29:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GHTFP03527 for linux-xfs-outgoing; Tue, 16 Oct 2001 10:29:15 -0700 Received: from legba.tvnet.hu (legba.tvnet.hu [195.38.96.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GHT6D03504 for ; Tue, 16 Oct 2001 10:29:12 -0700 Received: from dumballah.tvnet.hu (zeus.city.tvnet.hu [195.38.100.182]) by legba.tvnet.hu (8.9.3+Sun/8.9.3) with ESMTP id TAA11412 for ; Tue, 16 Oct 2001 19:28:50 +0200 (MEST) Message-ID: <3BCC6E4E.4040800@dumballah.tvnet.hu> Date: Tue, 16 Oct 2001 19:28:46 +0200 From: Sipos Ferenc User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: udf is broken Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! If you haven't made your fresh kernel yet, be warned, in 2.4.13-pre3 udf is broken. Paco From owner-linux-xfs@oss.sgi.com Tue Oct 16 10:38:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GHcrK03834 for linux-xfs-outgoing; Tue, 16 Oct 2001 10:38:53 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GHcmD03812 for ; Tue, 16 Oct 2001 10:38:49 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA02147 for ; Tue, 16 Oct 2001 10:37:57 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA3320449; Tue, 16 Oct 2001 12:37:30 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA82002; Tue, 16 Oct 2001 12:37:30 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9GHZCm05951; Tue, 16 Oct 2001 12:35:12 -0500 Message-Id: <200110161735.f9GHZCm05951@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Sipos Ferenc cc: linux-xfs@oss.sgi.com Subject: Re: udf is broken In-Reply-To: Message from Sipos Ferenc of "Tue, 16 Oct 2001 19:28:46 +0200." <3BCC6E4E.4040800@dumballah.tvnet.hu> Date: Tue, 16 Oct 2001 12:35:12 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hi! > > If you haven't made your fresh kernel yet, be warned, in 2.4.13-pre3 udf > is broken. > > Paco Broken at build time or run time? Try this (from linux-kernel) if it is build time: --- linux/fs/udf/udfdecl.h.orig Tue Oct 16 20:24:01 2001 +++ linux/fs/udf/udfdecl.h Tue Oct 16 20:24:42 2001 @@ -150,7 +150,7 @@ /* lowlevel.c */ extern unsigned int udf_get_last_session(struct super_block *); -extern unsigned int udf_get_last_block(struct super_block *); +extern unsigned long udf_get_last_block(struct super_block *); /* partition.c */ extern Uint32 udf_get_pblock(struct super_block *, Uint32, Uint16, Uint32); Steve From owner-linux-xfs@oss.sgi.com Tue Oct 16 10:57:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GHvaQ04324 for linux-xfs-outgoing; Tue, 16 Oct 2001 10:57:36 -0700 Received: from legba.tvnet.hu (legba.tvnet.hu [195.38.96.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GHvWD04301 for ; Tue, 16 Oct 2001 10:57:32 -0700 Received: from dumballah.tvnet.hu (zeus.city.tvnet.hu [195.38.100.182]) by legba.tvnet.hu (8.9.3+Sun/8.9.3) with ESMTP id TAA12149 for ; Tue, 16 Oct 2001 19:57:20 +0200 (MEST) Message-ID: <3BCC74FB.1020302@dumballah.tvnet.hu> Date: Tue, 16 Oct 2001 19:57:15 +0200 From: Sipos Ferenc User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfs into base kernel Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi There are a lot of rumors about xfs and 2.5, it is also said, that the largest obstacle of xfs integration into the devel kernel that there is a lot of code duplication between xfs and the base. Nowadays xfs is the best fs for linux, i personally use it for 6 month. Would anybody of the main developers clear the facts, where the integration stands nowadays? Paco From owner-linux-xfs@oss.sgi.com Tue Oct 16 11:01:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GI1me04562 for linux-xfs-outgoing; Tue, 16 Oct 2001 11:01:48 -0700 Received: from popo.san.rr.com (24-25-207-74.san.rr.com [24.25.207.74]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GI1fD04540 for ; Tue, 16 Oct 2001 11:01:42 -0700 Received: by popo.san.rr.com (Postfix, from userid 500) id CB9E76007356; Tue, 16 Oct 2001 11:01:17 -0700 (PDT) Date: Tue, 16 Oct 2001 11:01:17 -0700 From: Joshua Penix To: linux-xfs@oss.sgi.com Subject: Re: HELP!!! Message-ID: <20011016110117.A1975@projectdesign.com> References: <4.3.2.7.2.20011016100533.03169b88@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Posern@stud-mailer.uni-marburg.de on Tue, Oct 16, 2001 at 02:07:13PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Oct 16, 2001 at 02:07:13PM +0200, Posern wrote: > But just for the future - cause I still like RAIDs - only this IBM > harddisc modell "DTLA 307045" (or something like this)... > > Is total crap - In half a year I now have 5 broken harddiscs from this > serie! These drives are known to be quite unreliable. See here for further links and discussion: http://slashdot.org/article.pl?sid=01/10/04/0050238&mode=thread > I have to check the /proc/mdstats to always see if all harddiscs are > running or if the raid is in degraded mode (means that one harddisc > is not in use - because of errors, or???) ??? Even better would be to have some sort of logwatching utility, or other script which keeps an eye on it and emails you if something goes awry. Alternately, you could have a hot spare drive sitting in the machine, waiting to take over, without operator intervention, in case one of the live drives goes south. > What schould I had done at the point of the failure of the second disc > to rescue my data??? > Because the raidhotadd thing is only possible if one harddisc fails! If you have a standard RAID-5 setup, and you lose TWO drives, you're out of luck. Nothing to do to rescue... > To backup my raid-data nevertheless it is a raid5 - but what is a good, > safe and fast method to backup 130GB of data??? > And - because it is my private raid and I am a poor student - a most > likely a cheap method to backup...??! Good, safe AND fast? You'd do fine with a DLT drive and a couple tapes. But not on a student's budget. :^) 130GB is an awful lot of data, and it's not cheap to backup easily. Is all 130GB actually *data* that can't be reloaded off a CD somewhere, or recreated through some other method? Also depends on what you need the backup for. Your RAID5 system should protect you from drive failure (assuming you're aware of it when one drive starts to go). But it's not going to protect you from an errant 'rm -rf' command executed on the wrong directory. Hope that helps... --Josh From owner-linux-xfs@oss.sgi.com Tue Oct 16 11:07:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GI74504810 for linux-xfs-outgoing; Tue, 16 Oct 2001 11:07:04 -0700 Received: from legba.tvnet.hu (legba.tvnet.hu [195.38.96.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GI6xD04787 for ; Tue, 16 Oct 2001 11:06:59 -0700 Received: from dumballah.tvnet.hu (zeus.city.tvnet.hu [195.38.100.182]) by legba.tvnet.hu (8.9.3+Sun/8.9.3) with ESMTP id UAA12327; Tue, 16 Oct 2001 20:06:41 +0200 (MEST) Message-ID: <3BCC772C.3050003@dumballah.tvnet.hu> Date: Tue, 16 Oct 2001 20:06:36 +0200 From: Sipos Ferenc User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012 X-Accept-Language: en-us MIME-Version: 1.0 To: Steve Lord CC: linux-xfs@oss.sgi.com Subject: Re: udf is broken References: <200110161735.f9GHZCm05951@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: >>Hi! >> >>If you haven't made your fresh kernel yet, be warned, in 2.4.13-pre3 udf >>is broken. >> >>Paco >> > >Broken at build time or run time? Try this (from linux-kernel) >if it is build time: > >--- linux/fs/udf/udfdecl.h.orig Tue Oct 16 20:24:01 2001 >+++ linux/fs/udf/udfdecl.h Tue Oct 16 20:24:42 2001 >@@ -150,7 +150,7 @@ > > /* lowlevel.c */ > extern unsigned int udf_get_last_session(struct super_block *); >-extern unsigned int udf_get_last_block(struct super_block *); >+extern unsigned long udf_get_last_block(struct super_block *); > > /* partition.c */ > extern Uint32 udf_get_pblock(struct super_block *, Uint32, Uint16, Uint32); > > >Steve > > > Thx the help, it compiles fine. Paco From owner-linux-xfs@oss.sgi.com Tue Oct 16 11:43:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GIhaw05524 for linux-xfs-outgoing; Tue, 16 Oct 2001 11:43:36 -0700 Received: from ente.berdmann.de (frnk-d514e1e3.dsl.mediaWays.net [213.20.225.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GIhYD05501 for ; Tue, 16 Oct 2001 11:43:34 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 15tZBX-0001y6-00; Tue, 16 Oct 2001 20:43:27 +0200 Message-ID: <3BCC7FCC.BFC0ABC4@berdmann.de> Date: Tue, 16 Oct 2001 20:43:24 +0200 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.13-pre2-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Posern CC: Seth Mos , Knuth Posern , linux-xfs@oss.sgi.com Subject: Re: HELP!!! References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > 3.) > To backup my raid-data nevertheless it is a raid5 - but what is a good, > safe and fast method to backup 130GB of data??? > And - because it is my private raid and I am a poor student - a most > likely a cheap method to backup...??! You learned the hard way: RAID is no backup. Good, safe, fast? DLT, AIT, LTO If your data is not worth the money? Be prepared to lose it. From owner-linux-xfs@oss.sgi.com Tue Oct 16 13:11:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GKBTa07456 for linux-xfs-outgoing; Tue, 16 Oct 2001 13:11:29 -0700 Received: from smtp-20v.tesionmail.de (smtp-20v.tesionmail.de [213.182.133.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GKBOD07433 for ; Tue, 16 Oct 2001 13:11:25 -0700 Received: from tesionmail.de ([195.226.102.12]) by smtp-20v.tesionmail.de (Netscape Messaging Server 4.15) with ESMTP id GLBEK000.IML for ; Tue, 16 Oct 2001 22:07:12 +0200 Message-ID: <3BCC9464.2060601@tesionmail.de> Date: Tue, 16 Oct 2001 22:11:16 +0200 From: Gerd Bitzer User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Patch handling Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, may be that are stupid questions, but anyway. What is the correct way to handle your kernel patches ? Can I download a linux 2.4.5 source tree and your 1.0.1 patch and apply it, and after this only apply the official kernelpatches against the kernel sources, to patch up to newer kernel releases ? Or do I have to maintain a clean kernelsource tree, which I can patch up to the newest kernel release, and after this procedure can patch in your appropriate kernel patch ? Is there a way (when using xfs as module) not to patch it into the original kernel source, but only to compile it ? I do not want to maintain an original kernel source tree which I am able to patch up to newer kernel versions and an additional version, where I have patched an appropriate version of xfs into, I only want to have original kernel sources which I can use as I need, I do not want to have extra work with an extra xfs kernel. I think xfs is the most advanced filesystem around, when will it be in the official kernel source tree ? keep up the good work best regards, Gerd From owner-linux-xfs@oss.sgi.com Tue Oct 16 13:20:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GKKqk07787 for linux-xfs-outgoing; Tue, 16 Oct 2001 13:20:52 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GKKlD07765 for ; Tue, 16 Oct 2001 13:20:47 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA05477 for ; Tue, 16 Oct 2001 13:19:55 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA2530454; Tue, 16 Oct 2001 15:19:30 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id PAA67287; Tue, 16 Oct 2001 15:19:29 -0500 (CDT) Subject: Re: Patch handling From: Eric Sandeen To: Gerd Bitzer Cc: linux-xfs@oss.sgi.com In-Reply-To: <3BCC9464.2060601@tesionmail.de> References: <3BCC9464.2060601@tesionmail.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 16 Oct 2001 15:18:51 -0500 Message-Id: <1003263531.18085.22.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Gerd - On Tue, 2001-10-16 at 15:11, Gerd Bitzer wrote: > Can I download a linux 2.4.5 source tree and your 1.0.1 patch and apply > it, and after this only apply the official kernelpatches against the > kernel sources, to patch up to newer kernel releases ? You can try this, but you will have conflicts to resolve. > Or do I have to maintain a clean kernelsource tree, which I can patch up > to the newest kernel release, and after this procedure can patch in your > appropriate kernel patch ? That's the the best way to do it... a little more disk space, a lot less time. :) > Is there a way (when using xfs as module) not to patch it into the > original kernel source, but only to compile it ? There are hooks in the kernel itself that are needed, so a stand-alone "xfs" package won't work. > I do not want to maintain an original kernel source tree which I am able > to patch up to newer kernel versions and an additional version, where I > have patched an appropriate version of xfs into, I only want to have > original kernel sources which I can use as I need, I do not want to have > extra work with an extra xfs kernel. Talk to Linus and Alan. ;-) > I think xfs is the most advanced filesystem around, when will it be in > the official kernel source tree ? See previous answer. :) Seriously, this is a goal, but there is no timetable for this... as in most things Linux-related. > keep up the good work Thanks, -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Oct 16 14:43:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GLhaD09129 for linux-xfs-outgoing; Tue, 16 Oct 2001 14:43:36 -0700 Received: from clubphoto.com (mail-gw.clubphoto.com [64.124.34.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GLhXD09107 for ; Tue, 16 Oct 2001 14:43:33 -0700 Received: from wicked (wicked.clubphoto.local [192.168.168.26]) by clubphoto.com (8.9.3/8.9.3) with SMTP id OAA24570 for ; Tue, 16 Oct 2001 14:43:33 -0700 From: "Gabe E. Nydick" To: Subject: NFS with XFS Date: Tue, 16 Oct 2001 14:42:02 -0700 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.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I run a 2.4.5 XFS 1.0.1 kernel with all of the patches and updates user-land programs from SGI and I am experiencing a problem with NFS. My web servers are nfs clients of my XFS 1.0.1 file server and when at least mildly loaded, the web servers write uploaded files corruptly. These files are between 512K and 1MB in size and being uploaded through CGI where they are read 4k at a time and written. Since the web servers are at least slightly loaded, the reading of the buffer and writing of the file are not continuous and I get corrupt files. If I change my scheme to read all of the buffer into memory and then write all of the file at once, I do not get corruption. This leads me to believe that XFS over NFS is having issues. I have also seen posts in the internet with similar problems. I can recreate this corruption at will. Thanks ------------------------- Gabe E. Nydick Systems Lead ClubPhoto, Inc. P - 408.423.6611 F - 408.557.6799 ------------------------- From owner-linux-xfs@oss.sgi.com Tue Oct 16 14:56:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GLu0M09433 for linux-xfs-outgoing; Tue, 16 Oct 2001 14:56:00 -0700 Received: from ente.berdmann.de (frnk-d514e1e3.dsl.mediaWays.net [213.20.225.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GLtvD09411 for ; Tue, 16 Oct 2001 14:55:58 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 15tcBj-0004Iq-00 for linux-xfs@oss.sgi.com; Tue, 16 Oct 2001 23:55:52 +0200 Message-ID: <3BCCACE7.47F671A6@berdmann.de> Date: Tue, 16 Oct 2001 23:55:51 +0200 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.13-pre2-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Linux XFS Mailing List Subject: i2o gone? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk What has happened to linux/drivers/i2o? $ cvs -z3 update -d cvs server: Updating linux/drivers/i2o cvs server: cannot open directory /cvs/linux-2.4-xfs/linux/drivers/i2o: No such file or directory cvs server: skipping directory linux/drivers/i2o From owner-linux-xfs@oss.sgi.com Tue Oct 16 15:09:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GM9r309838 for linux-xfs-outgoing; Tue, 16 Oct 2001 15:09:53 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GM9nD09816 for ; Tue, 16 Oct 2001 15:09:49 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9GM9iW15222 for ; Tue, 16 Oct 2001 15:09:44 -0700 Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA3327772; Tue, 16 Oct 2001 17:08:28 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id RAA24953; Tue, 16 Oct 2001 17:08:27 -0500 (CDT) Subject: Re: NFS with XFS From: Eric Sandeen To: "Gabe E. Nydick" Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 16 Oct 2001 17:07:49 -0500 Message-Id: <1003270069.9676.28.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Gabe - A couple things - would it be possible to share a code snippet that represents what you are doing on the client side? It's always easier to track these things down if we can recreate it locally. Also, in what manner are the files corrupted? Finally, what other posts have you seen referring to this? That might help pull it all together... Thanks, -Eric On Tue, 2001-10-16 at 16:42, Gabe E. Nydick wrote: > I run a 2.4.5 XFS 1.0.1 kernel with all of the patches and updates user-land > programs from SGI and I am experiencing a problem with NFS. My web servers > are nfs clients of my XFS 1.0.1 file server and when at least mildly loaded, > the web servers write uploaded files corruptly. These files are between 512K > and 1MB in size and being uploaded through CGI where they are read 4k at a > time and written. Since the web servers are at least slightly loaded, the > reading of the buffer and writing of the file are not continuous and I get > corrupt files. If I change my scheme to read all of the buffer into memory > and then write all of the file at once, I do not get corruption. This leads > me to believe that XFS over NFS is having issues. I have also seen posts in > the internet with similar problems. I can recreate this corruption at will. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Oct 16 15:37:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GMbnc10298 for linux-xfs-outgoing; Tue, 16 Oct 2001 15:37:49 -0700 Received: from desh.cse.iitd.ernet.in (IDENT:root@mailer.cse.iitd.ac.in [202.141.68.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GMbiD10266 for ; Tue, 16 Oct 2001 15:37:44 -0700 Received: from poorvi.cse.iitd.ernet.in (IDENT:root@poorvi [10.20.3.12]) by desh.cse.iitd.ernet.in (8.11.0/8.11.0) with ESMTP id f9GMj8c30492 for ; Wed, 17 Oct 2001 04:15:09 +0530 Received: from localhost (csu98164@localhost) by poorvi.cse.iitd.ernet.in (8.11.2/8.11.2) with ESMTP id f9GMjnc12077 for ; Wed, 17 Oct 2001 04:15:50 +0530 X-Authentication-Warning: poorvi.cse.iitd.ernet.in: csu98164 owned process doing -bs Date: Wed, 17 Oct 2001 04:15:49 +0530 (IST) From: Vivek Malik X-X-Sender: To: Subject: boot.img can't read iso on local drive Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I have got a system running Redhat 7.0 and using xfs filesystem for all its partitions (namely /dev/hda1 /dev/hda3 /dev/hda4) I have got the xfs 1.0.1 and redhat 7.1 iso's on /dev/hda4. /dev/hda4 is mounted as /local so the iso's are /local/RH7.1-SGI-XFS-1.0.1.iso /local/seawolf-i386-disc1.iso /local/seawolf-i386-disc2.iso Now i am trying to upgrade this machine using the iso's stored in its hard disk. I made a boot floppy using boot.img image and told the installation process to look for iso's in /dev/hda4 i tried with directory = / or leaving it empty but it always gives an error saying that "Device /dev/hda4 does not appear to contain Redhat CDROM images" but the images are there on /dev/hda4 (please note that /dev/hda4 has got xfs filesystem) Please suggest what can i do to upgrade machine using iso's stored on its hard disk in a partition using xfs filesystem. (please also note that boot.img was taken from xfs 1.0.1) Thanx, vivek From owner-linux-xfs@oss.sgi.com Tue Oct 16 15:39:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GMdNO10472 for linux-xfs-outgoing; Tue, 16 Oct 2001 15:39:23 -0700 Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GMdKD10450 for ; Tue, 16 Oct 2001 15:39:20 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9GMe5Ne022413; Wed, 17 Oct 2001 00:40:05 +0200 (CEST) Message-Id: <4.3.2.7.2.20011017003715.036d4310@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 17 Oct 2001 00:37:51 +0200 To: "Bernhard R. Erdmann" , Linux XFS Mailing List From: Seth Mos Subject: Re: i2o gone? In-Reply-To: <3BCCACE7.47F671A6@berdmann.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 23:55 16-10-2001 +0200, Bernhard R. Erdmann wrote: >What has happened to linux/drivers/i2o? > >$ cvs -z3 update -d >cvs server: Updating linux/drivers/i2o >cvs server: cannot open directory /cvs/linux-2.4-xfs/linux/drivers/i2o: >No such file or directory >cvs server: skipping directory linux/drivers/i2o it's now in drivers/message/i2o See linus changelog (link un linuxtoday.com) -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Tue Oct 16 15:41:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GMfQY10633 for linux-xfs-outgoing; Tue, 16 Oct 2001 15:41:26 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GMfLD10611 for ; Tue, 16 Oct 2001 15:41:21 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9GMfGK17810 for ; Tue, 16 Oct 2001 15:41:16 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA3073427; Tue, 16 Oct 2001 17:40:00 -0500 (CDT) Received: from fsgi158.americas.sgi.com (fsgi158.americas.sgi.com [128.162.191.39]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA18749; Tue, 16 Oct 2001 17:39:59 -0500 (CDT) From: Tad Dolphay Received: by fsgi158.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) id RAA73012; Tue, 16 Oct 2001 17:39:58 -0500 (CDT) Message-Id: <200110162239.RAA73012@fsgi158.americas.sgi.com> Subject: Re: NFS with XFS To: sandeen@sgi.com (Eric Sandeen) Date: Tue, 16 Oct 2001 17:39:58 -0500 (CDT) Cc: gnydick@clubphoto.com (Gabe E. Nydick), linux-xfs@oss.sgi.com In-Reply-To: <1003270069.9676.28.camel@stout.americas.sgi.com> from "Eric Sandeen" at Oct 16, 2001 05:07:49 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > Hi Gabe - > > A couple things - would it be possible to share a code snippet that > represents what you are doing on the client side? It's always easier to > track these things down if we can recreate it locally. > > Also, in what manner are the files corrupted? > > Finally, what other posts have you seen referring to this? That might > help pull it all together... > > Thanks, > > -Eric > Also what type of machines are the clients? Does the problem still occur if you mount with sync option? When you say you work around the problem by reading all the buffer into memory and writing it at once, is this done on the client? If so, I think it sounds more like a cache consistency problem on the clients. Thanks, Tad > On Tue, 2001-10-16 at 16:42, Gabe E. Nydick wrote: > > I run a 2.4.5 XFS 1.0.1 kernel with all of the patches and updates user-land > > programs from SGI and I am experiencing a problem with NFS. My web servers > > are nfs clients of my XFS 1.0.1 file server and when at least mildly loaded, > > the web servers write uploaded files corruptly. These files are between 512K > > and 1MB in size and being uploaded through CGI where they are read 4k at a > > time and written. Since the web servers are at least slightly loaded, the > > reading of the buffer and writing of the file are not continuous and I get > > corrupt files. If I change my scheme to read all of the buffer into memory > > and then write all of the file at once, I do not get corruption. This leads > > me to believe that XFS over NFS is having issues. I have also seen posts in > > the internet with similar problems. I can recreate this corruption at will. > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. > From owner-linux-xfs@oss.sgi.com Tue Oct 16 15:41:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GMfqH10713 for linux-xfs-outgoing; Tue, 16 Oct 2001 15:41:52 -0700 Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GMflD10690 for ; Tue, 16 Oct 2001 15:41:47 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9GMgVNd022505; Wed, 17 Oct 2001 00:42:31 +0200 (CEST) Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id AAA13637; Wed, 17 Oct 2001 00:41:43 +0200 (CEST) Message-Id: <4.3.2.7.2.20011017003818.036ec1f0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 17 Oct 2001 00:40:16 +0200 To: "Gabe E. Nydick" , From: Seth Mos Subject: Re: NFS with XFS In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 14:42 16-10-2001 -0700, Gabe E. Nydick wrote: >I run a 2.4.5 XFS 1.0.1 kernel with all of the patches and updates user-land >programs from SGI and I am experiencing a problem with NFS. My web servers >are nfs clients of my XFS 1.0.1 file server and when at least mildly loaded, >the web servers write uploaded files corruptly. These files are between 512K >and 1MB in size and being uploaded through CGI where they are read 4k at a >time and written. Since the web servers are at least slightly loaded, the >reading of the buffer and writing of the file are not continuous and I get >corrupt files. If I change my scheme to read all of the buffer into memory >and then write all of the file at once, I do not get corruption. This leads >me to believe that XFS over NFS is having issues. I have also seen posts in >the internet with similar problems. I can recreate this corruption at will. Please use something after 2.4.6 which had a lot of NFS testing and fixing. Follow the hints from Eric for debugging the exact workaround. For production you might update you're kernel and the problem might vanish. Cheers >Thanks >------------------------- >Gabe E. Nydick >Systems Lead >ClubPhoto, Inc. >P - 408.423.6611 >F - 408.557.6799 >------------------------- -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Tue Oct 16 15:57:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GMv2B11182 for linux-xfs-outgoing; Tue, 16 Oct 2001 15:57:02 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GMuxD11160 for ; Tue, 16 Oct 2001 15:56:59 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA08835 for ; Tue, 16 Oct 2001 15:55:55 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA3319409; Tue, 16 Oct 2001 17:55:38 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id RAA22443; Tue, 16 Oct 2001 17:55:38 -0500 (CDT) Subject: Re: boot.img can't read iso on local drive From: Eric Sandeen To: Vivek Malik Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 16 Oct 2001 17:54:59 -0500 Message-Id: <1003272899.23054.39.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Vivek - This is not an installation method that we tested... it probably does not work, and would take a bit of coding to make it work. Perhaps just putting all the RPMs in a dir, and using rpm's "freshen" command might work for you? Or find someone with a CD burner? :) Sorry, -Eric On Tue, 2001-10-16 at 17:45, Vivek Malik wrote: > Now i am trying to upgrade this machine using the iso's stored in its hard > disk. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Oct 16 16:03:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GN3O511500 for linux-xfs-outgoing; Tue, 16 Oct 2001 16:03:24 -0700 Received: from e4.eyal.emu.id.au (CPE-61-9-149-34.vic.bigpond.net.au [61.9.149.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GN3JD11478 for ; Tue, 16 Oct 2001 16:03:19 -0700 Received: from eyal.emu.id.au (eyal.emu.id.au [192.168.2.7]) by e4.eyal.emu.id.au (8.11.6/8.11.2) with ESMTP id f9GN32O27020; Wed, 17 Oct 2001 09:03:03 +1000 Received: from eyal.emu.id.au (really [127.0.0.1]) by eyal.emu.id.au via in.smtpd with esmtp id (Debian Smail3.2.0.102) for ; Wed, 17 Oct 2001 08:53:19 +1000 (EST) Message-ID: <3BCCBA5F.813987CF@eyal.emu.id.au> Date: Wed, 17 Oct 2001 08:53:19 +1000 From: Eyal Lebedinsky Organization: Eyal at Home X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.12 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Bernhard R. Erdmann" CC: Linux XFS Mailing List Subject: Re: i2o gone? References: <3BCCACE7.47F671A6@berdmann.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "Bernhard R. Erdmann" wrote: > > What has happened to linux/drivers/i2o? You probably already fount it...at linux/drivers/message/i2o I just removed my old dir, which cleared the cvs error. And BTW, this move makes it not build as of pre3. -- Eyal Lebedinsky (eyal@eyal.emu.id.au) From owner-linux-xfs@oss.sgi.com Tue Oct 16 16:29:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GNTmJ11980 for linux-xfs-outgoing; Tue, 16 Oct 2001 16:29:48 -0700 Received: from afara-gw.afara.com (mx1.afara.com [63.113.218.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GNTiD11958 for ; Tue, 16 Oct 2001 16:29:44 -0700 Received: from tduffy-lnx.afara.com ([10.2.4.191]) by afara-gw.afara.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 16 Oct 2001 16:28:53 -0700 Subject: Re: boot.img can't read iso on local drive From: Thomas Duffy To: Vivek Malik Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16.99+cvs.2001.10.15.08.08 (Preview Release) Date: 16 Oct 2001 16:29:02 -0700 Message-Id: <1003274942.24746.4.camel@tduffy-lnx.afara.com> Mime-Version: 1.0 X-OriginalArrivalTime: 16 Oct 2001 23:28:53.0256 (UTC) FILETIME=[5154F880:01C1569A] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2001-10-16 at 15:45, Vivek Malik wrote: > Please suggest what can i do to upgrade machine using iso's stored on its > hard disk in a partition using xfs filesystem. is this even supported by the redhat installer? I don't think that it is. when you install from harddrive, it expects the exploded images to be in a directory. what I would try (if you cannot burn to CD) is mount each CD in order, RH disk 1, then RH disk 2, then SGI...each time cp -r the contents into a directory. then try to install off of that partition... -tduffy From owner-linux-xfs@oss.sgi.com Tue Oct 16 17:29:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9H0TEj13037 for linux-xfs-outgoing; Tue, 16 Oct 2001 17:29:14 -0700 Received: from afara-gw.afara.com (mx1.afara.com [63.113.218.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9H0TAD13015 for ; Tue, 16 Oct 2001 17:29:10 -0700 Received: from tduffy-lnx.afara.com ([10.2.4.191]) by afara-gw.afara.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 16 Oct 2001 17:28:22 -0700 Subject: [slightly OT] replicated installs of XFS From: Thomas Duffy To: XFS Mailing List Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16.99+cvs.2001.10.15.08.08 (Preview Release) Date: 16 Oct 2001 17:28:31 -0700 Message-Id: <1003278511.24746.37.camel@tduffy-lnx.afara.com> Mime-Version: 1.0 X-OriginalArrivalTime: 17 Oct 2001 00:28:22.0664 (UTC) FILETIME=[A0DD6880:01C156A2] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I was wondering if anybody had any luck with tools to do automated custom installs of systems with XFS filesystems. The choices I have seen all don't meet all of our needs... 1) Norton Ghost - does not support XFS 2) Systemimager - does not support XFS out of box. apparently Austin Gonyou has got it to work (http://systemimager.org/pub/unofficial/XFS-Support_by_Austin_Gonyou/), so I might be able to replicate this... 3) RedHat kickstart - does not allow customization of installed disk (ie, Ximian, extra software, config files). 4) some hack with tftpboot, nfsroot, xfsdump/restore - ugly and hard to automate any others? any successes? thanks! -tduffy From owner-linux-xfs@oss.sgi.com Tue Oct 16 17:41:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9H0fuS13334 for linux-xfs-outgoing; Tue, 16 Oct 2001 17:41:56 -0700 Received: from barry.mail.mindspring.net (barry.mail.mindspring.net [207.69.200.25]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9H0fpD13312 for ; Tue, 16 Oct 2001 17:41:52 -0700 Received: from walt400.localhost (user-uini6aq.dsl.mindspring.com [165.121.25.90]) by barry.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id UAA24725 for ; Tue, 16 Oct 2001 20:41:51 -0400 (EDT) Received: from mindspring.com (localhost.localdomain [127.0.0.1]) by walt400.localhost (Postfix) with ESMTP id 85A498108BB; Tue, 16 Oct 2001 17:40:18 -0700 (PDT) Message-ID: <3BCCD372.3060402@mindspring.com> Date: Tue, 16 Oct 2001 17:40:18 -0700 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010914 X-Accept-Language: en-us MIME-Version: 1.0 To: Thomas Duffy Cc: XFS Mailing List Subject: Re: [slightly OT] replicated installs of XFS References: <1003278511.24746.37.camel@tduffy-lnx.afara.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I haven't tried it personally, though will soon enough, but you might want to check out Partition Image for linux - http://www.partimage.org Seems to be like a Norton Ghost type program for linux that supports many filesystems including XFS. Sounds pretty neat. -Walt Thomas Duffy wrote: > I was wondering if anybody had any luck with tools to do automated > custom installs of systems with XFS filesystems. The choices I have > seen all don't meet all of our needs... > > 1) Norton Ghost - does not support XFS > > 2) Systemimager - does not support XFS out of box. apparently Austin > Gonyou has got it to work > (http://systemimager.org/pub/unofficial/XFS-Support_by_Austin_Gonyou/), > so I might be able to replicate this... > > 3) RedHat kickstart - does not allow customization of installed disk > (ie, Ximian, extra software, config files). > > 4) some hack with tftpboot, nfsroot, xfsdump/restore - ugly and hard to > automate > > any others? any successes? > > thanks! > > -tduffy > > > > > From owner-linux-xfs@oss.sgi.com Tue Oct 16 17:51:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9H0p6G13599 for linux-xfs-outgoing; Tue, 16 Oct 2001 17:51:06 -0700 Received: from mail15b.boca15-verio.com (mail15b.boca15-verio.com [208.55.91.59]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9H0p4D13577 for ; Tue, 16 Oct 2001 17:51:04 -0700 Received: from www.sigmastorage.com (128.241.173.170) by mail15b.boca15-verio.com (RS ver 1.0.60s) with SMTP id 034760164; Tue, 16 Oct 2001 20:50:14 -0400 (EDT) Message-ID: <3BCCD588.8B9F6512@sigmastorage.com> Date: Tue, 16 Oct 2001 17:49:12 -0700 From: Matt Ryan X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-0.5 i686) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Duffy CC: XFS Mailing List Subject: Re: [slightly OT] replicated installs of XFS References: <1003278511.24746.37.camel@tduffy-lnx.afara.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thomas Duffy wrote: > 3) RedHat kickstart - does not allow customization of installed disk > (ie, Ximian, extra software, config files). kickstart files have a %post section, which you can use to copy from the install media to the hard disk, then chroot run a script that you've copied over. if you're installing over the network (ie no cdrom space limitations) you can do pretty much whatever post-install customization you want this way. Matt From owner-linux-xfs@oss.sgi.com Tue Oct 16 17:52:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9H0q9b13701 for linux-xfs-outgoing; Tue, 16 Oct 2001 17:52:09 -0700 Received: from rebel.net.au (IDENT:root@ftp.rebel.net.au [203.20.69.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9H0q4D13661 for ; Tue, 16 Oct 2001 17:52:04 -0700 Received: from rebel.net.au (dialup-7.rebel.net.au [203.20.69.77]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id KAA22215; Wed, 17 Oct 2001 10:21:34 +0930 Message-ID: <3BCCD7CF.FF0A866D@rebel.net.au> Date: Wed, 17 Oct 2001 10:28:55 +0930 From: DSL X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1_PR3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Sipos Ferenc CC: linux-xfs@oss.sgi.com Subject: Re: xfs into base kernel References: <3BCC74FB.1020302@dumballah.tvnet.hu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi there! > best fs for linux, i personally use it for 6 month. Would anybody of the > main developers clear the facts, where the integration stands nowadays? This question crops up all the time; from what I can tell you have already stated the reason that XFS is not part of the stable kernel series at the moment. Both sides of this debate have totally valid reasons for their particular stance. (i.e. SGI: "It's easier and more efficient from our point of view to keep the Irix and Linux implementation similar, hence we need to duplicate some Linux code" Linus: "Having duplicated code, from my point of view, is not the easiest way to maintain what is already quite complex" ) DSL -- If we could extract all the evil from each of us, Think of the world that we could create! A world without anger, or violence or strife... (From the Musical, Jekyll and Hyde) From owner-linux-xfs@oss.sgi.com Tue Oct 16 18:11:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9H1BGX14197 for linux-xfs-outgoing; Tue, 16 Oct 2001 18:11:16 -0700 Received: from home.smithconcepts.com (ubr-34.25.157.oviedo.cfl.rr.com [65.34.25.157]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9H1BCD14175 for ; Tue, 16 Oct 2001 18:11:13 -0700 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id VAA14432; Tue, 16 Oct 2001 21:04:34 -0400 Message-ID: <3BCCDB17.7D1567A2@ieee.org> Date: Tue, 16 Oct 2001 21:12:55 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts, Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS101_K7mp i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Mandrake 8.1 with XFS??? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Kernel 2.4.8 with all JFS' supported: http://www.linux-mandrake.com/en/81.php3 Anyone know much about this? I usually shy away from Mandrake, because I have found many packages (as well as the installer) broken in places. -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ------------------------------------------------------------------ Those living in the US who consider the American flag to be a sym- bol of oppression obviously fail to understand what the word means From owner-linux-xfs@oss.sgi.com Tue Oct 16 18:19:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9H1J5X14414 for linux-xfs-outgoing; Tue, 16 Oct 2001 18:19:05 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9H1J0D14392 for ; Tue, 16 Oct 2001 18:19:00 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id SAA03069 for ; Tue, 16 Oct 2001 18:17:57 -0700 (PDT) mail_from (mg@smack.melbourne.sgi.com) Received: from smack.melbourne.sgi.com (smack.melbourne.sgi.com [134.14.55.210]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA15901; Wed, 17 Oct 2001 11:17:38 +1000 Received: from localhost (mg@localhost) by smack.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id LAA02297; Wed, 17 Oct 2001 11:17:38 +1000 (EST) Date: Wed, 17 Oct 2001 11:17:38 +1000 From: Mike Gigante To: Bryan-TheBS-Smith cc: linux-xfs@oss.sgi.com Subject: Re: Mandrake 8.1 with XFS??? In-Reply-To: <3BCCDB17.7D1567A2@ieee.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Yep, I have installed it here on my work desktop linux machine. The install went flawlessly and I haven't had any dramas in the 2 weeks or so I have been unsing it.... I installed a heap of optional packages without any problems so maybe the broken packages problems has been addressed. Mike ----------------------------------------------------------------------- Michael Gigante R&D Software Engineer mg@melbourne.sgi.com SGI Performance Tools Group, +61 3 9834 8233 Melbourne Australia V-Net: 524-8233 On Tue, 16 Oct 2001, Bryan-TheBS-Smith wrote: > Kernel 2.4.8 with all JFS' supported: > http://www.linux-mandrake.com/en/81.php3 > > Anyone know much about this? > > I usually shy away from Mandrake, because I have found many packages > (as well as the installer) broken in places. > > -- TheBS > > -- > Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 > Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org > President SmithConcepts, Inc. http://www.SmithConcepts.com > ------------------------------------------------------------------ > Those living in the US who consider the American flag to be a sym- > bol of oppression obviously fail to understand what the word means > > From owner-linux-xfs@oss.sgi.com Tue Oct 16 18:34:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9H1Yec14742 for linux-xfs-outgoing; Tue, 16 Oct 2001 18:34:40 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9H1YXD14720 for ; Tue, 16 Oct 2001 18:34:33 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id SAA13073 for ; Tue, 16 Oct 2001 18:34:28 -0700 (PDT) mail_from (ivanr@sgi.com) From: ivanr@sgi.com Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA16017; Wed, 17 Oct 2001 11:33:15 +1000 Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id LAA35029; Wed, 17 Oct 2001 11:33:15 +1000 (EST) X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs Date: Wed, 17 Oct 2001 11:33:14 +1000 X-X-Sender: ivanr@omen.melbourne.sgi.com To: Bryan-TheBS-Smith cc: linux-xfs@oss.sgi.com Subject: Re: Mandrake 8.1 with XFS??? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've had it installed on my home machine for the last couple of weeks, and also had no real problems with it. 'Course, it being my main home machine, I've not really tried to stress the kernel at all... As for the installer, it seems very nice. I did have one problem when my 3rd CD was corrupt, the installer didn't really recover very well, but I reburnt the CD and tried again and it all went well. I must say, I think the software manager gui (swmgr equivalent) could be improved a bit, but that's just an annoyance. Overall, I'm very pleased with it. Ivan On Wed, 17 Oct 2001, Mike Gigante wrote: > > Yep, I have installed it here on my work desktop linux machine. The > install went flawlessly and I haven't had any dramas in the 2 weeks or so > I have been unsing it.... > > I installed a heap of optional packages without any problems so maybe the > broken packages problems has been addressed. > > Mike > > ----------------------------------------------------------------------- > Michael Gigante R&D Software Engineer mg@melbourne.sgi.com > SGI Performance Tools Group, +61 3 9834 8233 > Melbourne Australia V-Net: 524-8233 > > On Tue, 16 Oct 2001, Bryan-TheBS-Smith wrote: > > > Kernel 2.4.8 with all JFS' supported: > > http://www.linux-mandrake.com/en/81.php3 > > > > Anyone know much about this? > > > > I usually shy away from Mandrake, because I have found many packages > > (as well as the installer) broken in places. > > > > -- TheBS > > > > -- > > Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 > > Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org > > President SmithConcepts, Inc. http://www.SmithConcepts.com > > ------------------------------------------------------------------ > > Those living in the US who consider the American flag to be a sym- > > bol of oppression obviously fail to understand what the word means > > > > > -- Ivan Rayner ivanr@sgi.com From owner-linux-xfs@oss.sgi.com Tue Oct 16 18:51:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9H1ph315073 for linux-xfs-outgoing; Tue, 16 Oct 2001 18:51:43 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9H1pfD15050 for ; Tue, 16 Oct 2001 18:51:41 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9H1paK23022 for ; Tue, 16 Oct 2001 18:51:36 -0700 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by nodin.corp.sgi.com (8.11.4/8.11.2/nodin-1.0) with ESMTP id f9H1oZC5647816 for ; Tue, 16 Oct 2001 18:50:35 -0700 (PDT) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 06D51300095; Wed, 17 Oct 2001 11:50:33 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id A6E7798 for ; Wed, 17 Oct 2001 11:50:33 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Linux XFS Mailing List Subject: Re: i2o gone? In-reply-to: Your message of "Wed, 17 Oct 2001 08:53:19 +1000." <3BCCBA5F.813987CF@eyal.emu.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Oct 2001 11:50:28 +1000 Message-ID: <29983.1003283428@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 17 Oct 2001 08:53:19 +1000, Eyal Lebedinsky wrote: >"Bernhard R. Erdmann" wrote: >> >> What has happened to linux/drivers/i2o? >I just removed my old dir, which cleared the cvs error. >And BTW, this move makes it not build as of pre3. drivers/message/ in the XFS tree is identical to drivers/message/ in Linus's 2.4.13-pre3. drivers/Makefile is also identical. The top level Makefile has XFS changes but the i2o reference is the same in both trees. IOW, not an XFS problem. From owner-linux-xfs@oss.sgi.com Tue Oct 16 21:07:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9H474a17097 for linux-xfs-outgoing; Tue, 16 Oct 2001 21:07:04 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9H46xD17075 for ; Tue, 16 Oct 2001 21:07:00 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id VAA21598 for ; Tue, 16 Oct 2001 21:06:56 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id VAA58233; Tue, 16 Oct 2001 21:06:27 -0700 (PDT) Message-ID: <3BCD02FF.17ABDD74@sgi.com> Date: Tue, 16 Oct 2001 23:03:11 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Duffy CC: Vivek Malik , linux-xfs@oss.sgi.com Subject: Re: boot.img can't read iso on local drive References: <1003274942.24746.4.camel@tduffy-lnx.afara.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thomas Duffy wrote: > is this even supported by the redhat installer? I don't think that it > is. when you install from harddrive, it expects the exploded images to > be in a directory. Not any more... as of 7.1: "Hard drive installations now require the use of the ISO (or CD-ROM) images instead of just copying an entire installation tree. After placing the required ISO images in a directory, choose to install from the hard drive. You will then point the installation program at that directory to perform the installation." HOWEVER.... I found this gem in anaconda... elif (method[0:8] == "oldhd://"): So, I think if you tell the installer to use the "oldhd" method*, you can copy the isos out into a directory, and use it the old way... perhaps this would work. If you try it, copy the SGI CD last. -Eric *not quite sure how to do this, probably "linux method=oldhd" at the installer boot prompt...? -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Oct 16 22:28:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9H5SWJ18166 for linux-xfs-outgoing; Tue, 16 Oct 2001 22:28:32 -0700 Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9H5SQD18143 for ; Tue, 16 Oct 2001 22:28:26 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9H5Sxau005552; Wed, 17 Oct 2001 07:28:59 +0200 (CEST) Message-Id: <4.3.2.7.2.20011017072557.02bcbbd8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 17 Oct 2001 07:26:51 +0200 To: Walt H , Thomas Duffy From: Seth Mos Subject: Re: [slightly OT] replicated installs of XFS Cc: XFS Mailing List In-Reply-To: <3BCCD372.3060402@mindspring.com> References: <1003278511.24746.37.camel@tduffy-lnx.afara.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 17:40 16-10-2001 -0700, Walt H wrote: >Hi, > >I haven't tried it personally, though will soon enough, but you might want >to check out Partition Image for linux - http://www.partimage.org > >Seems to be like a Norton Ghost type program for linux that supports many >filesystems including XFS. Sounds pretty neat. It works OK but it lacks drivers like raid and some scsi controllers. >-Walt > > >Thomas Duffy wrote: > >>I was wondering if anybody had any luck with tools to do automated >>custom installs of systems with XFS filesystems. The choices I have >>seen all don't meet all of our needs... >>1) Norton Ghost - does not support XFS >>2) Systemimager - does not support XFS out of box. apparently Austin >>Gonyou has got it to work >>(http://systemimager.org/pub/unofficial/XFS-Support_by_Austin_Gonyou/), >>so I might be able to replicate this... >>3) RedHat kickstart - does not allow customization of installed disk >>(ie, Ximian, extra software, config files). >>4) some hack with tftpboot, nfsroot, xfsdump/restore - ugly and hard to >>automate >>any others? any successes? >>thanks! >>-tduffy >> >> > -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Tue Oct 16 22:40:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9H5eES18399 for linux-xfs-outgoing; Tue, 16 Oct 2001 22:40:14 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9H5eBD18376 for ; Tue, 16 Oct 2001 22:40:12 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9H5e6W04199 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Tue, 16 Oct 2001 22:40:06 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id HAA3440484 for ; Wed, 17 Oct 2001 07:38:57 +0200 (CEST) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id PAA25754; Wed, 17 Oct 2001 15:39:51 +1000 Date: Wed, 17 Oct 2001 15:39:51 +1000 From: Keith Owens Message-Id: <200110170539.PAA25754@sherman.melbourne.sgi.com> Subject: TAKE - Allow xfsidbg to be built in Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk If XFS is built in then xfsidbg is controlled by the state of CONFIG_KDB_MODULES. xfsidbg can be omitted (CONFIG_KDB_MODULES == n), built in (CONFIG_KDB_MODULES == y) or a module (CONFIG_KDB_MODULES == m). If XFS is a module then xfsidbg can be omitted (CONFIG_KDB_MODULES == n) or a module (CONFIG_KDB_MODULES == y or m). Date: Tue Oct 16 22:35:01 PDT 2001 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:104915a linux/fs/xfs/Makefile - 1.125 From owner-linux-xfs@oss.sgi.com Wed Oct 17 00:34:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9H7YPZ20334 for linux-xfs-outgoing; Wed, 17 Oct 2001 00:34:25 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9H7YMD20312 for ; Wed, 17 Oct 2001 00:34:22 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9H7YFW10378 for ; Wed, 17 Oct 2001 00:34:16 -0700 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA66467 for linux-xfs@oss.sgi.com; Wed, 17 Oct 2001 17:32:58 +1000 (EST) Date: Wed, 17 Oct 2001 17:32:58 +1000 (EST) From: Nathan Scott Message-Id: <200110170732.RAA66467@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - logprint Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk For you, Keith. ;-) Date: Wed Oct 17 00:30:46 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:104919a cmd/xfsprogs/logprint/logprint.c - 1.4 - add in the -f (file) option - man page claims this is supported, but in reality it was not. From owner-linux-xfs@oss.sgi.com Wed Oct 17 03:54:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9HAsVc24483 for linux-xfs-outgoing; Wed, 17 Oct 2001 03:54:31 -0700 Received: from mx0.gmx.net (mx0.gmx.de [213.165.64.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9HAsPD24457 for ; Wed, 17 Oct 2001 03:54:26 -0700 Received: (qmail 29318 invoked by uid 0); 17 Oct 2001 10:54:18 -0000 Date: Wed, 17 Oct 2001 12:54:18 +0200 (MEST) From: christian mueller To: linux-xfs@oss.sgi.com Cc: Thomas.Duffy.99@alumni.brown.edu, waltabbyh@mindspring.com, matt@sigmastorage.com, knuffie@xs4all.nl MIME-Version: 1.0 Subject: Re: [slightly OT] replicated installs of XFS X-Authenticated-Sender: #0002001279@gmx.net X-Authenticated-IP: [149.201.101.60] Message-ID: <16755.1003316058@www35.gmx.net> X-Mailer: WWW-Mail 1.5 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi all, i'm using SuSE Linux 7.x Pro here. it comes with a tool named ALICE. (Advanced Linux Installation and Configuration Environment) take a look at these links below http://www.suseportal.de/en/content.php?3occccccccccccccccccccmcccccccmccocccccccococcccccccccccccccc&content/business/alice1.html http://www.suse.de/~nashif/autoyast1/html/index.html http://lists2.suse.com/archive/alice/ i had set it up once, but this was befor i used SGI's XFS. SuSE's installer YaST1 (which i prefer for my installations) only knows ext2 and reiserfs for the install. i tried once to modify YaST1 so that it mount with 'auto' instead of '-t vfstype' with no success (compilation problems and possibly my skills in C and C++ programing). i did an own iso-image of CD1 with the needed tools and kernel to run an installation from scratch (with manually run mkfs.xfs on the created partitions and cheat on YaST1 with a the creation of a known fstype so that it continues to the packages section). the recently released SuSE 7.3 Pro comes with the complete set of SGI's XFS userspace tools (xfs_progs, acl, ...). i don't know yet why these are included because the kernel which comes with the distro doesn't support XFS. perhaps SuSE release a kernel update with XFS support in ther near future? i'm running more out of topic here? yes. i think so too. chris -- Sent through GMX FreeMail - http://www.gmx.net From owner-linux-xfs@oss.sgi.com Wed Oct 17 04:02:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9HB24P25095 for linux-xfs-outgoing; Wed, 17 Oct 2001 04:02:04 -0700 Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9HB20D24984 for ; Wed, 17 Oct 2001 04:02:00 -0700 Received: from sweeney.demon.co.uk ([158.152.71.87] helo=pereskia.sweeney.demon.co.uk) by anchor-post-34.mail.demon.net with esmtp (Exim 2.12 #1) id 15toSR-000BVh-0Y for linux-xfs@oss.sgi.com; Wed, 17 Oct 2001 12:01:56 +0100 Received: from rebutia.sweeney.demon.co.uk (rebutia.sweeney.demon.co.uk [10.0.0.3]) by pereskia.sweeney.demon.co.uk (Postfix) with ESMTP id 4515F27EF for ; Wed, 17 Oct 2001 08:16:18 +0100 (BST) Received: by rebutia.sweeney.demon.co.uk (Postfix, from userid 1001) id 4CE10125E6; Wed, 17 Oct 2001 08:16:18 +0100 (BST) Date: Wed, 17 Oct 2001 08:16:18 +0100 (BST) From: Keith Matthews Subject: Re: Mandrake 8.1 with XFS??? To: linux-xfs@oss.sgi.com In-Reply-To: <3BCCDB17.7D1567A2@ieee.org> References: <3BCCDB17.7D1567A2@ieee.org> X-Mailer: Mahogany, 0.60 'Redmond', compiled for Linux 2.2.13 i686 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Disposition: INLINE Message-Id: <20011017071618.4CE10125E6@rebutia.sweeney.demon.co.uk> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id f9HB21D25018 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 16 Oct 2001 21:12:55 -0400 Bryan-TheBS-Smith > wrote: > Kernel 2.4.8 with all JFS' supported: > http://www.linux-mandrake.com/en/81.php3 > Anyone know much about this? > I usually shy away from Mandrake, because I have found many packages > (as well as the installer) broken in places. Despite the encouragement from Mike and Ivan it needs to be said that there is a fair sized thread on uk.comp.os.linux about people having trouble with the installer. I suspect they have slightly unusual hardware, but that shouldn't really cause trouble (says he who has never managed to get a RH install to all-SCSI to work properly). I'll be playing with it myself on the test machine when I finish a download. Can't see me ever going to it as a main install though. -- Keith Matthews Spam trap - my real account at this node is keith_m Frequentous Consultants - Linux Services, Oracle development & database administration From owner-linux-xfs@oss.sgi.com Wed Oct 17 04:24:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9HBOil25931 for linux-xfs-outgoing; Wed, 17 Oct 2001 04:24:44 -0700 Received: from gk.hm.epigenomics.net (gk.hm.epigenomics.net [212.121.137.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9HBOeD25909 for ; Wed, 17 Oct 2001 04:24:40 -0700 Received: (qmail 15520 invoked from network); 17 Oct 2001 11:24:43 -0000 Received: from raman.epigenomics.epi (qmailr@192.168.2.2) by salam.epigenomics.epi with SMTP; 17 Oct 2001 11:24:43 -0000 Received: (qmail 18709 invoked from network); 17 Oct 2001 11:24:38 -0000 Received: from eigen.epigenomics.epi (qmailr@192.168.2.36) by raman.epigenomics.epi with SMTP; 17 Oct 2001 11:24:38 -0000 Received: (qmail 17751 invoked by uid 515); 17 Oct 2001 11:24:37 -0000 Date: Wed, 17 Oct 2001 13:24:37 +0200 From: Robert Sander To: linux-xfs@oss.sgi.com Subject: reenabling quota after xfs_repair Message-ID: <20011017132437.A17663@epigenomics.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.3.22i X-Operating-System: Linux eigen 2.2.19.client-piii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! I had an xfs_repair run on a filesystem with quota enabled and now all quota info is lost. Thi case is stated in the manual page, and it says that this info is restored when checking manually for it. But how is this done? quotacheck just skips the XFS filesystems. The manual page also says that after remounting the filesystem the usage info will be recalculated, but that was also without effect. quota tools are of version 3.00pre01 Greetings -- Robert Sander Computer Scientist Epigenomics AG Bioinformatics R&D www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Wed Oct 17 04:25:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9HBPmD26085 for linux-xfs-outgoing; Wed, 17 Oct 2001 04:25:48 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9HBPeD26039 for ; Wed, 17 Oct 2001 04:25:40 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9HBPYK01070 for ; Wed, 17 Oct 2001 04:25:34 -0700 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id VAA01922 for linux-xfs@oss.sgi.com; Wed, 17 Oct 2001 21:24:18 +1000 (EST) Date: Wed, 17 Oct 2001 21:24:18 +1000 (EST) From: Nathan Scott Message-Id: <200110171124.VAA01922@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfs_repair Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Merge Glen's change from IRIX - xfs_repair will no longer zero a dirty transaction log. The -L option overrides this behaviour. You'll likely need to do a "make realclean" before recompiling. Had to jump through a few hoops here to allow the xfs_log_recover code, previously used only by logprint, to be shared by repair and logprint (and anybody else down the track). At the same time need to be aware that mkfs.xfs has size constraints for boot floppies, so don't just toss stuff into libxfs if we can help it (mkfs does not make use any of the xlog_* routines). cheers. Date: Wed Oct 17 04:00:32 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:104924a cmd/xfsprogs/libxlog/util.c - 1.1 - derived largely from old log_print code, now shared by logprint and repair. cmd/xfsprogs/libxlog/Makefile - 1.1 - add libxlog files. cmd/xfsprogs/include/libxlog.h - 1.1 - derived largely from old logprint.h, now shared by logprint and repair. cmd/xfstests/040.out - 1.2 cmd/xfstests/tools/srcdiff - 1.9 - update to reflect the xfs_log_recover.c code moving into libxlog. cmd/xfsprogs/repair/xfs_repair.c - 1.3 - add -L option for forced log zeroing. cmd/xfsprogs/include/builddefs.in - 1.18 - add libxlog library. cmd/xfsprogs/include/Makefile - 1.6 - add libxlog header. cmd/xfsprogs/repair/phase2.c - 1.2 cmd/xfsprogs/repair/globals.h - 1.3 - add -L option for forced log zeroing. cmd/xfsprogs/repair/Makefile - 1.5 - new build dependency on libxlog. cmd/xfsprogs/man/man8/xfs_repair.8 - 1.3 - document the new -L option for forced log zeroing. cmd/xfsprogs/logprint/xfs_log_recover.c 1.6 renamed to cmd/xfsprogs/libxlog/xfs_log_recover.c 1.1 - move into libxlog for sharing between logprint and repair. cmd/xfsprogs/logprint/logprint.h - 1.6 cmd/xfsprogs/logprint/logprint.c - 1.5 - global data structure moved into libxlog. cmd/xfsprogs/logprint/log_print_trans.c - 1.4 - move a chunk of code into libxlog for sharing between logprint and repair. cmd/xfsprogs/logprint/Makefile - 1.6 - xfs_log_recover moved to libxlog, add new build dependency. cmd/xfsprogs/Makefile - 1.8 - add libxlog directory. cmd/xfsprogs/VERSION - 1.33 cmd/xfsprogs/doc/CHANGES - 1.42 - bump version to 1.3.12, document changes. From owner-linux-xfs@oss.sgi.com Wed Oct 17 06:32:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9HDWqR31180 for linux-xfs-outgoing; Wed, 17 Oct 2001 06:32:52 -0700 Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9HDWmD31158 for ; Wed, 17 Oct 2001 06:32:48 -0700 Received: from squash.mw.mediaone.net (nic-30-c48-217.mw.mediaone.net [24.30.48.217]) by demai05.mw.mediaone.net (8.11.1/8.11.1) with ESMTP id f9HDWr901604 for ; Wed, 17 Oct 2001 09:32:53 -0400 (EDT) Date: Wed, 17 Oct 2001 09:32:38 -0400 (EDT) From: J Landman X-X-Sender: To: Subject: Re: Mandrake 8.1 with XFS??? In-Reply-To: <20011017071618.4CE10125E6@rebutia.sweeney.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 17 Oct 2001, Keith Matthews wrote: > Despite the encouragement from Mike and Ivan it needs to be said that > there is a fair sized thread on uk.comp.os.linux about people having > trouble with the installer. I had trouble that wound up being a corrupt .iso. Re-downloading, checking md5sum's, and burning new CD's made all issues go away. The only negative I can point to in this distro is the use of devfs. It is almost completely hidden from the end user, but every now and then it rears its ugly head. MSC.Linux also gives an option for XFS on install (with a 2.4.6 kernel). As do a few others. -- Joe Landman, landman@mediaone.net From owner-linux-xfs@oss.sgi.com Wed Oct 17 07:32:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9HEW4Y32542 for linux-xfs-outgoing; Wed, 17 Oct 2001 07:32:04 -0700 Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9HEVvD32516 for ; Wed, 17 Oct 2001 07:31:57 -0700 Received: from walt400.localhost (user-uini60r.dsl.mindspring.com [165.121.24.27]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id KAB23525 for ; Wed, 17 Oct 2001 10:31:56 -0400 (EDT) Received: from mindspring.com (localhost.localdomain [127.0.0.1]) by walt400.localhost (Postfix) with ESMTP id E48628108A8; Wed, 17 Oct 2001 07:30:24 -0700 (PDT) Message-ID: <3BCD9600.3040303@mindspring.com> Date: Wed, 17 Oct 2001 07:30:24 -0700 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010914 X-Accept-Language: en-us MIME-Version: 1.0 To: Seth Mos Cc: Thomas Duffy , XFS Mailing List Subject: Re: [slightly OT] replicated installs of XFS References: <1003278511.24746.37.camel@tduffy-lnx.afara.com> <4.3.2.7.2.20011017072557.02bcbbd8@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk If it does a decent enough job of making (basic) images, it should work on disk replication for workstation installs no? I'm thinking of using it to setup a workstation as we would completely for a desktop and then image it off for dupes to additional stations. These will be fairly basic setups so I'm hoping it can do the job for me. One plus, is where I work, we use a mix of Macs, Windows 2000 and some Linux boxes (thanks to yours truly) for some server tasks. Again, haven't tried it, but from the web page it sounds like it's just what I need. -Walt Seth Mos wrote: > At 17:40 16-10-2001 -0700, Walt H wrote: > >> Hi, >> >> I haven't tried it personally, though will soon enough, but you might >> want to check out Partition Image for linux - http://www.partimage.org >> >> Seems to be like a Norton Ghost type program for linux that supports >> many filesystems including XFS. Sounds pretty neat. > > > It works OK but it lacks drivers like raid and some scsi controllers. > > >> -Walt >> >> >> Thomas Duffy wrote: >> >>> I was wondering if anybody had any luck with tools to do automated >>> custom installs of systems with XFS filesystems. The choices I have >>> seen all don't meet all of our needs... >>> 1) Norton Ghost - does not support XFS >>> 2) Systemimager - does not support XFS out of box. apparently Austin >>> Gonyou has got it to work >>> (http://systemimager.org/pub/unofficial/XFS-Support_by_Austin_Gonyou/), >>> so I might be able to replicate this... >>> 3) RedHat kickstart - does not allow customization of installed disk >>> (ie, Ximian, extra software, config files). >>> 4) some hack with tftpboot, nfsroot, xfsdump/restore - ugly and hard to >>> automate >>> any others? any successes? >>> thanks! >>> -tduffy >>> >>> >> > > -- > Seth > Every program has two purposes one for which > it was written and another for which it wasn't > I use the last kind. > From owner-linux-xfs@oss.sgi.com Wed Oct 17 07:33:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9HEXmB32687 for linux-xfs-outgoing; Wed, 17 Oct 2001 07:33:48 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9HEXiD32665 for ; Wed, 17 Oct 2001 07:33:44 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA25632 for ; Wed, 17 Oct 2001 07:33:40 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA3332334; Wed, 17 Oct 2001 09:32:27 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA90344; Wed, 17 Oct 2001 09:32:27 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9HEU0n08049; Wed, 17 Oct 2001 09:30:00 -0500 Message-Id: <200110171430.f9HEU0n08049@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Robert Sander cc: linux-xfs@oss.sgi.com Subject: Re: reenabling quota after xfs_repair In-Reply-To: Message from Robert Sander of "Wed, 17 Oct 2001 13:24:37 +0200." <20011017132437.A17663@epigenomics.de> Date: Wed, 17 Oct 2001 09:30:00 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hi! > > I had an xfs_repair run on a filesystem with quota enabled and now > all quota info is lost. Thi case is stated in the manual page, and > it says that this info is restored when checking manually for it. > But how is this done? quotacheck just skips the XFS filesystems. > The manual page also says that after remounting the filesystem > the usage info will be recalculated, but that was also without > effect. > quota tools are of version 3.00pre01 XFS quota works differently, if you mount with quota options and the on disk data says quotas were not used during the last mount then the kernel code inside xfs will scan the filesystem and rebuild the quota information automatically - there should be a log message to this effect. Steve p.s. does this mean you are over your problem with the root inode going missing? > > Greetings > -- > Robert Sander > Computer Scientist Epigenomics AG > Bioinformatics R&D www.epigenomics.com Kastanienallee 24 > +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Wed Oct 17 07:36:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9HEaAi00365 for linux-xfs-outgoing; Wed, 17 Oct 2001 07:36:10 -0700 Received: from johnson.mail.mindspring.net (johnson.mail.mindspring.net [207.69.200.177]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9HEa5D00343 for ; Wed, 17 Oct 2001 07:36:05 -0700 Received: from walt400.localhost (user-uini60r.dsl.mindspring.com [165.121.24.27]) by johnson.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id KAA30396 for ; Wed, 17 Oct 2001 10:36:04 -0400 (EDT) Received: from mindspring.com (localhost.localdomain [127.0.0.1]) by walt400.localhost (Postfix) with ESMTP id 9F60F8108A8; Wed, 17 Oct 2001 07:34:32 -0700 (PDT) Message-ID: <3BCD96F8.4020707@mindspring.com> Date: Wed, 17 Oct 2001 07:34:32 -0700 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010914 X-Accept-Language: en-us MIME-Version: 1.0 To: Keith Matthews Cc: linux-xfs@oss.sgi.com Subject: Re: Mandrake 8.1 with XFS??? References: <3BCCDB17.7D1567A2@ieee.org> <20011017071618.4CE10125E6@rebutia.sweeney.demon.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk ...better late than never I suppose :) I've been using 8.1 since it first was available. It detected all my hardware fine and setup went without a hitch. I've since upgraded my kernel to 2.2.12 w/ preempt patches and it seems a bit snappier than the default kernel Mdk ships with. Other than that, it was no more broken after install than Redhat etc... for me. YMMV, but it works for me :) -Walt P.S. I've got fairly basic hardware: P2 400 384MB Ram, 2 IDE HD, Int DVD, Ext. USB CD-Writer, TNT vid card - All detected and working after install. Keith Matthews wrote: > On Tue, 16 Oct 2001 21:12:55 -0400 Bryan-TheBS-Smith > wrote: > > >>Kernel 2.4.8 with all JFS' supported: >> http://www.linux-mandrake.com/en/81.php3 >> > >>Anyone know much about this? >> > >>I usually shy away from Mandrake, because I have found many packages >>(as well as the installer) broken in places. >> > > Despite the encouragement from Mike and Ivan it needs to be said that > there is a fair sized thread on uk.comp.os.linux about people having > trouble with the installer. > > I suspect they have slightly unusual hardware, but that shouldn't > really cause trouble (says he who has never managed to get a RH > install to all-SCSI to work properly). > > I'll be playing with it myself on the test machine when I finish a > download. Can't see me ever going to it as a main install though. > > -- > Keith Matthews Spam trap - my real account at this > node is keith_m > Frequentous Consultants - Linux Services, > Oracle development & database administration > > > From owner-linux-xfs@oss.sgi.com Wed Oct 17 07:38:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9HEcjT00506 for linux-xfs-outgoing; Wed, 17 Oct 2001 07:38:45 -0700 Received: from gk.hm.epigenomics.net (gk.hm.epigenomics.net [212.121.137.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9HEceD00480 for ; Wed, 17 Oct 2001 07:38:40 -0700 Received: (qmail 17073 invoked from network); 17 Oct 2001 14:38:40 -0000 Received: from raman.epigenomics.epi (qmailr@192.168.2.2) by salam.epigenomics.epi with SMTP; 17 Oct 2001 14:38:40 -0000 Received: (qmail 26662 invoked from network); 17 Oct 2001 14:38:37 -0000 Received: from eigen.epigenomics.epi (qmailr@192.168.2.36) by raman.epigenomics.epi with SMTP; 17 Oct 2001 14:38:37 -0000 Received: (qmail 20176 invoked by uid 515); 17 Oct 2001 14:38:37 -0000 Date: Wed, 17 Oct 2001 16:38:37 +0200 From: Robert Sander To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: reenabling quota after xfs_repair Message-ID: <20011017163837.A20127@epigenomics.de> References: <20011017132437.A17663@epigenomics.de> <200110171430.f9HEU0n08049@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <200110171430.f9HEU0n08049@jen.americas.sgi.com> User-Agent: Mutt/1.3.22i X-Operating-System: Linux eigen 2.2.19.client-piii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Oct 17, 2001 at 09:30:00AM -0500, Steve Lord wrote: > XFS quota works differently, if you mount with quota options and the > on disk data says quotas were not used during the last mount then the > kernel code inside xfs will scan the filesystem and rebuild the quota > information automatically - there should be a log message to this > effect. I have read about XFS holding quota as matadata info in the journal, but the rebuild did not work I think. I just rebooted the machine because of nfsd going crazy (but this is another issue...) and no quotas were found: raman:~# mount /dev/sda5 on / type ext2 (rw,errors=remount-ro,errors=remount-ro) /dev/sdb1 on /mnt/raid/0 type xfs (rw,usrquota) /dev/sdb2 on /mnt/raid/1 type xfs (rw) raman:~# quota gurubert Disk quotas for user gurubert (uid 515): none raman:~# edquota gurubert No filesystems with quota detected. Kernel is 2.4.8 from mandrake _with_ quota enabled and compiled with gcc 2.91.66 > p.s. does this mean you are over your problem with the root inode going > missing? I did not have _that_ problem, but others... Greetings -- Robert Sander Computer Scientist Epigenomics AG Bioinformatics R&D www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Wed Oct 17 07:46:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9HEk8t00751 for linux-xfs-outgoing; Wed, 17 Oct 2001 07:46:08 -0700 Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9HEk4D00729 for ; Wed, 17 Oct 2001 07:46:04 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9HEkTb1028742; Wed, 17 Oct 2001 16:46:29 +0200 (CEST) Message-Id: <4.3.2.7.2.20011017163931.02c24738@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 17 Oct 2001 16:44:20 +0200 To: Walt H From: Seth Mos Subject: Re: [slightly OT] replicated installs of XFS Cc: Thomas Duffy , XFS Mailing List In-Reply-To: <3BCD9600.3040303@mindspring.com> References: <1003278511.24746.37.camel@tduffy-lnx.afara.com> <4.3.2.7.2.20011017072557.02bcbbd8@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 07:30 17-10-2001 -0700, Walt H wrote: >If it does a decent enough job of making (basic) images, it should work on >disk replication for workstation installs no? I'm thinking of using it to >setup a workstation as we would completely for a desktop and then image it >off for dupes to additional stations. These will be fairly basic setups so >I'm hoping it can do the job for me. One plus, is where I work, we use a >mix of Macs, Windows 2000 and some Linux boxes (thanks to yours truly) for >some server tasks. Again, haven't tried it, but from the web page it >sounds like it's just what I need. IDE workstations and the odd aic7xxx should work just fine. Network is limited to the eepro100 and a few ne2000 clones I believe. Maybe using the LBT 2.0 [1](Linuxcare Bootable Toolbox) which has XFS support in combination with xfsdump might do the trick as well but you would need to run lilo afterwards. Although it is nothing a chroot /mnt/somedrive lilo won't correct. It's a standalone workspace. Hmmmm. include partimage onto the LBT... Martin? Is there space enough left on the LBT disc? The LBT already has network, lot's of drivers, XFS support, and a browser..err xfsdump and restore. It seems to be perfectly suited for this type of operation [1] http://lbt.linuxcare.com/ Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Wed Oct 17 08:04:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9HF48j01215 for linux-xfs-outgoing; Wed, 17 Oct 2001 08:04:08 -0700 Received: from chef.cc.absoval.com (cpe-66-1-218-101.fl.sprintbbd.net [66.1.218.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9HF43D01190 for ; Wed, 17 Oct 2001 08:04:03 -0700 Received: from ieee.org (IDENT:bs@thebs.cc.absoval.com [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id LAA15727; Wed, 17 Oct 2001 11:02:21 -0400 Message-ID: <3BCD9D7F.2B67A6FC@ieee.org> Date: Wed, 17 Oct 2001 11:02:23 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts/AbsoluteValueSystems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Walt H CC: Keith Matthews , linux-xfs@oss.sgi.com Subject: Re: Mandrake 8.1 with XFS??? References: <3BCCDB17.7D1567A2@ieee.org> <20011017071618.4CE10125E6@rebutia.sweeney.demon.co.uk> <3BCD96F8.4020707@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Walt H wrote: > P.S. I've got fairly basic hardware: P2 400 384MB Ram, 2 IDE HD, Int > DVD, Ext. USB CD-Writer, TNT vid card - All detected and working after > install. On mainstream hardware, I've had no real problems with Mandrake. Start adding SCSI, multiple NICs and other things to the equation and things changes. One thing I couldn't stand about 6.x and 7.x is booting the installer off of a SCSI CD-ROM. It would get into a chicken/egg thing where it would load the SCSI module twice, and not let you choose the correct CD-ROM. -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ---------------------------------------------------------------- The US recording and software industries have choosen to "honor" the victims of 9/11 by pushing their political agendas even fur- ther through so-called "anti-terrorism" legislation in Congress. From owner-linux-xfs@oss.sgi.com Wed Oct 17 08:10:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9HFAlA01556 for linux-xfs-outgoing; Wed, 17 Oct 2001 08:10:47 -0700 Received: from giants.mandrakesoft.com (office.mandrakesoft.com [195.68.114.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9HFAjD01534 for ; Wed, 17 Oct 2001 08:10:45 -0700 Received: by giants.mandrakesoft.com (Postfix, from userid 500) id 0D4CAC743; Wed, 17 Oct 2001 17:09:31 +0200 (CEST) To: Bryan-TheBS-Smith Cc: Walt H , Keith Matthews , linux-xfs@oss.sgi.com Subject: Re: Mandrake 8.1 with XFS??? References: <3BCCDB17.7D1567A2@ieee.org> <20011017071618.4CE10125E6@rebutia.sweeney.demon.co.uk> <3BCD96F8.4020707@mindspring.com> <3BCD9D7F.2B67A6FC@ieee.org> From: Chmouel Boudjnah Date: 17 Oct 2001 17:09:30 +0200 In-Reply-To: <3BCD9D7F.2B67A6FC@ieee.org> (Bryan-TheBS-Smith's message of "Wed, 17 Oct 2001 11:02:23 -0400") Message-ID: Lines: 10 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) Emacs/21.0.104 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Bryan-TheBS-Smith writes: > One thing I couldn't stand about 6.x and 7.x is booting the > installer off of a SCSI CD-ROM. It would get into a chicken/egg > thing where it would load the SCSI module twice, and not let you > choose the correct CD-ROM. that should be fixed in latest 8.1, please report bugs to : From owner-linux-xfs@oss.sgi.com Wed Oct 17 08:23:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9HFNd401844 for linux-xfs-outgoing; Wed, 17 Oct 2001 08:23:39 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9HFNSD01821 for ; Wed, 17 Oct 2001 08:23:28 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA09739 for ; Wed, 17 Oct 2001 08:22:38 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA3308140; Wed, 17 Oct 2001 10:22:11 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA37915; Wed, 17 Oct 2001 10:22:11 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9HFJiD17562; Wed, 17 Oct 2001 10:19:44 -0500 Message-Id: <200110171519.f9HFJiD17562@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Robert Sander cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: reenabling quota after xfs_repair In-Reply-To: Message from Robert Sander of "Wed, 17 Oct 2001 16:38:37 +0200." <20011017163837.A20127@epigenomics.de> Content-Transfer-Encoding: 8bit Date: Wed, 17 Oct 2001 10:19:44 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I should have waited for a quota expert to get here ;-) I just tried this here, however our quota tools and kernels do not match versions (I know the kernels don't I bet the commands don't either). mount -o usrquota /dev/sda6 /xfs1 setquota -u lord 10000 20000 2000 3000 /xfs1 quota -F xfs -v -u lord Disk quotas for user lord (uid 858): Filesystem blocks quota limit grace files quota limit grace /dev/sda6 0 10000 20000 0 2000 3000 I created a couple of files: lord{lord}: quota Disk quotas for user lord (uid 858): Filesystem blocks quota limit grace files quota limit grace /dev/sda6 1432 10000 20000 3 2000 3000 I unmounted and ran repair: [root@lord /]# umount /xfs1 [root@lord /]# xfs_repair /dev/sda6 [root@lord /]# mount -o usrquota /dev/sda6 /xfs1 XFS mounting filesystem sd(8,6) lord{lord}: quota Disk quotas for user lord (uid 858): Filesystem blocks quota limit grace files quota limit grace /dev/sda6 1432 10000 20000 3 2000 3000 I unmounted and remounted again without quotas enabled and created some more files. I then remounted with quota again: [root@lord /]# mount -o usrquota /dev/sda6 /xfs1 XFS mounting filesystem sd(8,6) XFS quotacheck sd(8,6): Please wait. XFS quotacheck sd(8,6): Done. [root@lord /]# lord{lord}: quota Disk quotas for user lord (uid 858): Filesystem blocks quota limit grace files quota limit grace /dev/sda6 2148 10000 20000 4 2000 3000 Note that if you do not use the -v option on quota it will not report quota info if there is no space used by an account. So the basics appear to be working for me, the xfs_repair man page section on quotas does appear to suggest it can completely blow away the quota info though: Quotas If quotas are in use, it is possible that xfs_repair will clear some or all of the filesystem quota information. If so, the program issues a warning just before it termi- nates. If all quota information is lost, quotas are dis- abled and the program issues a warning to that effect. Note that xfs_repair does not check the validity of quota limits. It is recommended that you check the quota limit information manually after xfs_repair. Also, space usage information is automatically regenerated the next time the filesystem is mounted with quotas turned on, so the next quota mount of the filesystem may take some time. What did repair tell you exactly? Steve > On Wed, Oct 17, 2001 at 09:30:00AM -0500, Steve Lord wrote: > > > XFS quota works differently, if you mount with quota options and the > > on disk data says quotas were not used during the last mount then the > > kernel code inside xfs will scan the filesystem and rebuild the quota > > information automatically - there should be a log message to this > > effect. > > I have read about XFS holding quota as matadata info in the journal, > but the rebuild did not work I think. I just rebooted the machine > because of nfsd going crazy (but this is another issue...) and no > quotas were found: > > raman:~# mount > /dev/sda5 on / type ext2 (rw,errors=remount-ro,errors=remount-ro) > /dev/sdb1 on /mnt/raid/0 type xfs (rw,usrquota) > /dev/sdb2 on /mnt/raid/1 type xfs (rw) > > raman:~# quota gurubert > Disk quotas for user gurubert (uid 515): none > > raman:~# edquota gurubert > No filesystems with quota detected. > > Kernel is 2.4.8 from mandrake _with_ quota enabled and compiled with > gcc 2.91.66 > > > p.s. does this mean you are over your problem with the root inode going > > missing? > > I did not have _that_ problem, but others... > > Greetings > -- > Robert Sander > Computer Scientist Epigenomics AG > Bioinformatics R&D www.epigenomics.com Kastanienallee 24 > +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Wed Oct 17 08:27:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9HFRsN02070 for linux-xfs-outgoing; Wed, 17 Oct 2001 08:27:54 -0700 Received: from gk.hm.epigenomics.net (qmailr@gk.hm.epigenomics.net [212.121.137.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9HFRoD02042 for ; Wed, 17 Oct 2001 08:27:51 -0700 Received: (qmail 17482 invoked from network); 17 Oct 2001 15:27:52 -0000 Received: from raman.epigenomics.epi (qmailr@192.168.2.2) by salam.epigenomics.epi with SMTP; 17 Oct 2001 15:27:52 -0000 Received: (qmail 23912 invoked from network); 17 Oct 2001 15:27:48 -0000 Received: from eigen.epigenomics.epi (qmailr@192.168.2.36) by raman.epigenomics.epi with SMTP; 17 Oct 2001 15:27:48 -0000 Received: (qmail 20888 invoked by uid 515); 17 Oct 2001 15:27:48 -0000 Date: Wed, 17 Oct 2001 17:27:48 +0200 From: Robert Sander To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: reenabling quota after xfs_repair Message-ID: <20011017172748.A20824@epigenomics.de> References: <20011017163837.A20127@epigenomics.de> <200110171519.f9HFJiD17562@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <200110171519.f9HFJiD17562@jen.americas.sgi.com> User-Agent: Mutt/1.3.22i X-Operating-System: Linux eigen 2.2.19.client-piii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Oct 17, 2001 at 10:19:44AM -0500, Steve Lord wrote: > > I should have waited for a quota expert to get here ;-) > > I just tried this here, however our quota tools and kernels do not match > versions (I know the kernels don't I bet the commands don't either). > > mount -o usrquota /dev/sda6 /xfs1 > setquota -u lord 10000 20000 2000 3000 /xfs1 raman:~# setquota -u gurubert 512000 1024000 0 0 /mnt/raid/0 setquota: Not all specified mountpoints are using quota. raman:~# mount |grep mnt/raid/0 /dev/sdb1 on /mnt/raid/0 type xfs (rw,usrquota) The XFS filesystem is mounted with the usrquota option, so at least it should be able to build new quota info, shouldn't it? Greetings -- Robert Sander Computer Scientist Epigenomics AG Bioinformatics R&D www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Wed Oct 17 08:42:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9HFg1k02450 for linux-xfs-outgoing; Wed, 17 Oct 2001 08:42:01 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9HFfuD02427 for ; Wed, 17 Oct 2001 08:41:56 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA01641 for ; Wed, 17 Oct 2001 08:41:52 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA3327125; Wed, 17 Oct 2001 10:40:40 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA04775; Wed, 17 Oct 2001 10:40:39 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9HFcC417627; Wed, 17 Oct 2001 10:38:12 -0500 Message-Id: <200110171538.f9HFcC417627@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Robert Sander cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: reenabling quota after xfs_repair In-Reply-To: Message from Robert Sander of "Wed, 17 Oct 2001 17:27:48 +0200." <20011017172748.A20824@epigenomics.de> Date: Wed, 17 Oct 2001 10:38:12 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Wed, Oct 17, 2001 at 10:19:44AM -0500, Steve Lord wrote: > > > > I should have waited for a quota expert to get here ;-) > > > > I just tried this here, however our quota tools and kernels do not match > > versions (I know the kernels don't I bet the commands don't either). > > > > mount -o usrquota /dev/sda6 /xfs1 > > setquota -u lord 10000 20000 2000 3000 /xfs1 > > raman:~# setquota -u gurubert 512000 1024000 0 0 /mnt/raid/0 > setquota: Not all specified mountpoints are using quota. > > raman:~# mount |grep mnt/raid/0 > /dev/sdb1 on /mnt/raid/0 type xfs (rw,usrquota) > > The XFS filesystem is mounted with the usrquota option, so at least > it should be able to build new quota info, shouldn't it? Hmm this may be that quota tools version thing, I am running: quota-3.01-pre7 One of the options for the quota command is this: -F format-name Show quota for specified format (ie. don't perform format autodetection). Possible format names are: vfsold (version 1 quota), vfsv0 (version 2 quota), rpc (quota over NFS), xfs (quota on XFS filesystem) Autodetection seems to work for me so I do not need it. Check your quota command has this option. If not you may need newer quota tools. Steve > > Greetings > -- > Robert Sander > Computer Scientist Epigenomics AG > Bioinformatics R&D www.epigenomics.com Kastanienallee 24 > +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Wed Oct 17 09:08:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9HG89k03025 for linux-xfs-outgoing; Wed, 17 Oct 2001 09:08:09 -0700 Received: from gk.hm.epigenomics.net (qmailr@gk.hm.epigenomics.net [212.121.137.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9HG85D03002 for ; Wed, 17 Oct 2001 09:08:05 -0700 Received: (qmail 17743 invoked from network); 17 Oct 2001 16:08:06 -0000 Received: from raman.epigenomics.epi (qmailr@192.168.2.2) by salam.epigenomics.epi with SMTP; 17 Oct 2001 16:08:06 -0000 Received: (qmail 19649 invoked from network); 17 Oct 2001 16:08:03 -0000 Received: from eigen.epigenomics.epi (qmailr@192.168.2.36) by raman.epigenomics.epi with SMTP; 17 Oct 2001 16:08:03 -0000 Received: (qmail 21506 invoked by uid 515); 17 Oct 2001 16:08:02 -0000 Date: Wed, 17 Oct 2001 18:08:02 +0200 From: Robert Sander To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: reenabling quota after xfs_repair Message-ID: <20011017180802.A21471@epigenomics.de> References: <20011017172748.A20824@epigenomics.de> <200110171538.f9HFcC417627@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <200110171538.f9HFcC417627@jen.americas.sgi.com> User-Agent: Mutt/1.3.22i X-Operating-System: Linux eigen 2.2.19.client-piii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Oct 17, 2001 at 10:38:12AM -0500, Steve Lord wrote: > Hmm this may be that quota tools version thing, I am running: > > quota-3.01-pre7 I am running 3.00-pre1 and I was able to create quota info and request that info. Just after running xfs_repair everything was gone. Greetings -- Robert Sander Computer Scientist Epigenomics AG Bioinformatics R&D www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Wed Oct 17 09:17:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9HGHe803313 for linux-xfs-outgoing; Wed, 17 Oct 2001 09:17:40 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9HGHbD03291 for ; Wed, 17 Oct 2001 09:17:37 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9HGHVW24897 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Wed, 17 Oct 2001 09:17:31 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id SAA3458243 for ; Wed, 17 Oct 2001 18:16:17 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA3330129; Wed, 17 Oct 2001 11:16:11 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA55967; Wed, 17 Oct 2001 11:16:11 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9HGDhW17816; Wed, 17 Oct 2001 11:13:43 -0500 Message-Id: <200110171613.f9HGDhW17816@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Robert Sander cc: linux-xfs@oss.sgi.com Subject: Re: reenabling quota after xfs_repair In-Reply-To: Message from Robert Sander of "Wed, 17 Oct 2001 18:08:02 +0200." <20011017180802.A21471@epigenomics.de> Date: Wed, 17 Oct 2001 11:13:43 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Wed, Oct 17, 2001 at 10:38:12AM -0500, Steve Lord wrote: > > Hmm this may be that quota tools version thing, I am running: > > > > quota-3.01-pre7 > > I am running 3.00-pre1 and I was able to create quota info > and request that info. Just after running xfs_repair everything > was gone. That's the problem - I think you need to move forwards from this version, 3.01-pre2 is the first with XFS support. There is a 3.01-final available here: http://sourceforge.net/projects/linuxquota/ Steve > > Greetings > -- > Robert Sander > Computer Scientist Epigenomics AG > Bioinformatics R&D www.epigenomics.com Kastanienallee 24 > +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Wed Oct 17 09:57:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9HGv7Z04160 for linux-xfs-outgoing; Wed, 17 Oct 2001 09:57:07 -0700 Received: from camelot.virtualavalon.net (127bus50.tampabay.rr.com [24.94.127.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9HGv5D04138 for ; Wed, 17 Oct 2001 09:57:05 -0700 Received: from arthur.virtualavalon.net (arthur.virtualavalon.net [172.20.1.10]) by camelot.virtualavalon.net (8.12.0/8.12.0) with ESMTP id f9HGv4j8011020 for ; Wed, 17 Oct 2001 12:57:04 -0400 Received: from tampabay.rr.com (wayfarer.virtualavalon.net [172.20.1.15]) by arthur.virtualavalon.net (8.12.0/8.12.0) with ESMTP id f9HGuxVn001318 for ; Wed, 17 Oct 2001 12:56:59 -0400 (EDT) Message-ID: <3BCDB805.40205@tampabay.rr.com> Date: Wed, 17 Oct 2001 12:55:33 -0400 From: "Jesse W. Asher" User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS and Oracle 8i. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Has anyone had any problems with running Oracle 8i on top of XFS? I'm looking at such a configuration and want to know if there are any problems with it. Thanks for any information on this!! -- Jesse W. Asher "They that can give up essential liberty to purchase a little temporary safety, deserve neither liberty or safety." - Benjamin Franklin From owner-linux-xfs@oss.sgi.com Wed Oct 17 10:03:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9HH3f804459 for linux-xfs-outgoing; Wed, 17 Oct 2001 10:03:41 -0700 Received: from www1.echomine.com (virtual.idream.net [63.101.49.149] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9HH3cD04437 for ; Wed, 17 Oct 2001 10:03:38 -0700 Received: from localhost (ckchris@localhost) by www1.echomine.com (8.11.2/8.11.2) with ESMTP id f9HH3KO12556; Wed, 17 Oct 2001 10:03:20 -0700 X-Authentication-Warning: www1.echomine.com: ckchris owned process doing -bs Date: Wed, 17 Oct 2001 10:03:20 -0700 (PDT) From: X-X-Sender: To: "Jesse W. Asher" cc: "linux-xfs@oss.sgi.com" Subject: Re: XFS and Oracle 8i. In-Reply-To: <3BCDB805.40205@tampabay.rr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I am currently running Oracle 9i on XFS and it seems to be ok. I haven't had any problems yet.. Running 2.4.10 with the 2.4.10 xfs patch. But to be on the safe side, my datafiles are still under 2 gigs and it hasn't been under stress testing yet. THanks, Chris On Wed, 17 Oct 2001, Jesse W. Asher wrote: > > Has anyone had any problems with running Oracle 8i on top of XFS? I'm > looking at such a configuration and want to know if there are any > problems with it. Thanks for any information on this!! > > From owner-linux-xfs@oss.sgi.com Wed Oct 17 10:07:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9HH7KA04616 for linux-xfs-outgoing; Wed, 17 Oct 2001 10:07:20 -0700 Received: from mail.starkmedia.com (mail.starkmedia.com [63.237.54.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9HH7GD04594 for ; Wed, 17 Oct 2001 10:07:17 -0700 Received: from members.evolt.org (gate.starkmedia.com [63.237.54.3]) by mail.starkmedia.com (8.10.1/8.10.1) with ESMTP id f9HH8O524794; Wed, 17 Oct 2001 12:08:24 -0500 Message-ID: <3BCDB71E.2080802@members.evolt.org> Date: Wed, 17 Oct 2001 11:51:42 -0500 From: "Daniel J. Cody" User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.5) Gecko/20011011 X-Accept-Language: en-us MIME-Version: 1.0 To: "Jesse W. Asher" CC: linux-xfs@oss.sgi.com Subject: Re: XFS and Oracle 8i. References: <3BCDB805.40205@tampabay.rr.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Jesse - Been running 8.1.6(120GB) and 8.1.7(35GB) on two different XFS 1.0 systems for a couple months now and have been pleased with performance so far.. You're going to have a couple 'issues' installing 8i on a 2.4 kernel, but thats got nothing to do with XFS and is spelled out pretty well on technet.oracle.com Shout offlist if you have an specific questions :) .djc. Jesse W. Asher wrote: > > Has anyone had any problems with running Oracle 8i on top of XFS? I'm > looking at such a configuration and want to know if there are any > problems with it. Thanks for any information on this!! > From owner-linux-xfs@oss.sgi.com Wed Oct 17 10:22:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9HHMwg04882 for linux-xfs-outgoing; Wed, 17 Oct 2001 10:22:58 -0700 Received: from rover (rover.mkp.net [209.217.122.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9HHMtD04860 for ; Wed, 17 Oct 2001 10:22:55 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=jaguar.mkp.net) by rover with esmtp (Exim 3.33 #1) id 15tuP3-0002gJ-00; Wed, 17 Oct 2001 13:22:49 -0400 Received: (from mkp@localhost) by jaguar.mkp.net (8.11.2/8.9.3) id f9HHMjc07313; Wed, 17 Oct 2001 13:22:45 -0400 X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f To: Seth Mos Cc: Walt H , Thomas Duffy , XFS Mailing List Subject: Re: [slightly OT] replicated installs of XFS References: <1003278511.24746.37.camel@tduffy-lnx.afara.com> <4.3.2.7.2.20011017072557.02bcbbd8@pop.xs4all.nl> <4.3.2.7.2.20011017163931.02c24738@pop.xs4all.nl> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 17 Oct 2001 13:22:44 -0400 In-Reply-To: <4.3.2.7.2.20011017163931.02c24738@pop.xs4all.nl> Message-ID: Lines: 11 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>>>> "Seth" == Seth Mos writes: Seth> It's a standalone workspace. Hmmmm. include partimage onto the Seth> LBT... Martin? Is there space enough left on the LBT disc? Sure. I'll put it on the todo list for the next release. -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Wed Oct 17 13:08:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9HK8F607868 for linux-xfs-outgoing; Wed, 17 Oct 2001 13:08:15 -0700 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9HK8BD07846 for ; Wed, 17 Oct 2001 13:08:11 -0700 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id f9HK5xq03250; Wed, 17 Oct 2001 15:05:59 -0500 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: XFS and Oracle 8i. From: Austin Gonyou To: "Jesse W. Asher" Cc: linux-xfs@oss.sgi.com In-Reply-To: <3BCDB805.40205@tampabay.rr.com> References: <3BCDB805.40205@tampabay.rr.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16.99+cvs.2001.10.15.08.08 (Preview Release) Date: 17 Oct 2001 15:05:59 -0500 Message-Id: <1003349159.2782.31.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I run Oracle8i on Linux + XFS + 2.4.10 on about 30 systems, all get slammed all day. No issues regarding XFS to report from this camp!!! On Wed, 2001-10-17 at 11:55, Jesse W. Asher wrote: > > Has anyone had any problems with running Oracle 8i on top of XFS? I'm > looking at such a configuration and want to know if there are any > problems with it. Thanks for any information on this!! > > -- > Jesse W. Asher > > "They that can give up essential liberty to purchase a little temporary > safety, deserve neither liberty or safety." - Benjamin Franklin > -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com From owner-linux-xfs@oss.sgi.com Wed Oct 17 15:14:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9HMEwS09925 for linux-xfs-outgoing; Wed, 17 Oct 2001 15:14:58 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9HMErD09903 for ; Wed, 17 Oct 2001 15:14:53 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA08211 for ; Wed, 17 Oct 2001 15:14:02 -0700 (PDT) mail_from (nstraz@sgi.com) Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.191.42]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA01260; Wed, 17 Oct 2001 17:13:36 -0500 (CDT) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.32 #1 (Debian)) id 15tywF-0001gn-00; Wed, 17 Oct 2001 17:13:23 -0500 Date: Wed, 17 Oct 2001 17:13:23 -0500 From: Nathan Straz To: linux-xfs@oss.sgi.com, linux-ia64@linuxia64.org Subject: SGI XFS 1.0.1-IA64 Preview Release 2 available for testing Message-ID: <20011017171322.B4625@sgi.com> Mail-Followup-To: linux-xfs@oss.sgi.com, linux-ia64@linuxia64.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The second preview release of SGI XFS 1.0.1-IA64 is available at: ftp://oss.sgi.com/projects/xfs/download/testing/Release-1.0.1-IA64-PR2/ These files are currently undergoing BETA testing. RPMS/ Kernel RPMs based on: - Linux 2.4.9 (Linus's tree) - Trillian 2.4.9-010820 - XFS 2.4.9 010826 - kdb-v1.8a-2.4.9-ia64-010820 cmd_rpms/ Command RPMs built for IA64, including lvm tools cmd_tars/ Command tarballs built for IA64. The lvm tarball is source. configs/ The config file from the kernel RPMs. Please check these over to see if anything important is missing. patches/ A patch against Linux-2.4.9-ia64-010820. Separate patches are available in the source RPM. This kernel is built with 16k pages. An installer is not available at this time. We're still working on it. Changes since last release: - Updated commands This should fix the unaligned access warnings - Updated KDB Moved to KDB 1.9 to keep up with current development -- 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 Wed Oct 17 17:31:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9I0V2R12005 for linux-xfs-outgoing; Wed, 17 Oct 2001 17:31:02 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9I0UtD11982 for ; Wed, 17 Oct 2001 17:30:55 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with SMTP id f9I0UmK04458 for ; Wed, 17 Oct 2001 17:30:49 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA22517; Thu, 18 Oct 2001 10:29:30 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA13163; Thu, 18 Oct 2001 11:29:28 +1100 (AEDT) Date: Thu, 18 Oct 2001 11:29:28 +1100 From: Nathan Scott To: Robert Sander Cc: linux-xfs@oss.sgi.com, Michael Meskes Subject: Re: reenabling quota after xfs_repair Message-ID: <20011018112928.B522717@wobbly.melbourne.sgi.com> References: <200110171613.f9HGDhW17816@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200110171613.f9HGDhW17816@jen.americas.sgi.com>; from lord@sgi.com on Wed, Oct 17, 2001 at 11:13:43AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Wed, Oct 17, 2001 at 11:13:43AM -0500, Steve Lord wrote: > > On Wed, Oct 17, 2001 at 10:38:12AM -0500, Steve Lord wrote: > > That's the problem - I think you need to move forwards from this version, > 3.01-pre2 is the first with XFS support. There is a 3.01-final available > here: > > http://sourceforge.net/projects/linuxquota/ > I think Steve's answered everything here and I agree that a more recent version of the quota tools could resolve the problems you are seeing. If not, let me know. Are you using Debian? The versioning scheme used there is a bit different - 3.00pre01-15 is fairly recent, but not quite the same as 3.01-final from sourceforge. I've forwarded Michael's explanation of his numbering scheme, below. I have successfully used the 3.00pre01-15 Debian package with XFS for quite some time now. I have never investigated the circumstances under which xfs_repair decides XFS quotas are cactus and resets them (I haven't needed to yet)... walk through the code if you need to know more. This might also be useful to you - xfsdump will automatically detect a filesystem with quota enabled and backs up the limit information at the time of the dump (stores it in a new file in the dump) - see the xfsdump man page. cheers. -- Nathan ----- Forwarded message from Michael Meskes ----- Date: Wed, 26 Sep 2001 09:00:39 +0200 To: Nathan Scott Cc: Jan Kara , mvw@planets.elm.net User-Agent: Mutt/1.3.20i From: Michael Meskes Subject: Re: CVS-linuxquota: 'quota-tools quotaio.h,1.5,1.6 quotaio_v1.c,1.8,1.9 quotaio_v2.c,1.6,1.7 quotasys.c,1.11,1.12 repquota.c,1.10,1.11' On Wed, Sep 26, 2001 at 03:53:37PM +1100, Nathan Scott wrote: > Also, the Debian packages (which I use too) are numbered along the > lines "3.00pre01-15" (with the "15" being the part which gets > updated each time) - this leaves me no clue as to which version > from sourceforge.net this lines up with - if we had a different > numbering scheme, perhaps these could all be made to line up...? It's based on the 3.00 release which was the latest stable release on sourceforge. Then I added the latest CVS changes which makes it pre01. The Debian version number has nothign to do with the CVS updates. At least no necessarily. Sometimes a new update is made just to change some Debian stuff. > I'd prefer to see something like: 3.0.9, 3.0.10, 3.0.11, - 3.1.0, > etc, as the increments we use (no "pre")... thoughts? For the Debian package? As soon as 3.01 is released I will create a new package named quota_3.01-1. Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ----- End forwarded message ----- From owner-linux-xfs@oss.sgi.com Wed Oct 17 17:41:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9I0f1Z12221 for linux-xfs-outgoing; Wed, 17 Oct 2001 17:41:01 -0700 Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.121.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9I0ewD12199 for ; Wed, 17 Oct 2001 17:40:58 -0700 Received: from dhcp10 (static031-81-151-24.nm01-c3.cpe.charter-ne.com [24.151.81.31]) by harrier.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id RAA17860 for ; Wed, 17 Oct 2001 17:40:56 -0700 (PDT) Message-ID: <003701c1576d$656871c0$0a00a8c0@intranet.mp3s.com> Reply-To: "Sean Elble" From: "Sean Elble" To: Subject: Quota Support Date: Wed, 17 Oct 2001 20:39:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I recently upgraded my home server to the XFS CVS tree, in addition to upgrading all of the corresponding XFS utilities. I also got the latest quota SRPM from SGI, and compiled that as well. When I try to use quotaon /dev/hda5, it says enable XFS user quota at mount, but defaults,usrquota is given as the options in my /etc/fstab file. Could it be that mount is fsck'ing up? Should I try to upgrade that? Any ideas at all? :-) I'm throughly stumped on this one, and any help would be greatly appreciated. Thanks, in advance. -------------------------------------------- Sean P. Elble Editor, Writer, Co-Webmaster MaximumLinux.org http://www.maximumlinux.org/ elbles@maximumlinux.org -------------------------------------------- From owner-linux-xfs@oss.sgi.com Wed Oct 17 18:00:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9I10Kd12552 for linux-xfs-outgoing; Wed, 17 Oct 2001 18:00:20 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9I10FD12530 for ; Wed, 17 Oct 2001 18:00:16 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id RAA06170 for ; Wed, 17 Oct 2001 17:58:47 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) 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 KAA22742; Thu, 18 Oct 2001 10:58:34 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA78926; Thu, 18 Oct 2001 11:58:33 +1100 (AEDT) Date: Thu, 18 Oct 2001 11:58:33 +1100 From: Nathan Scott To: Sean Elble Cc: linux-xfs@oss.sgi.com Subject: Re: Quota Support Message-ID: <20011018115833.C522717@wobbly.melbourne.sgi.com> References: <003701c1576d$656871c0$0a00a8c0@intranet.mp3s.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <003701c1576d$656871c0$0a00a8c0@intranet.mp3s.com>; from S_Elble@yahoo.com on Wed, Oct 17, 2001 at 08:39:47PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Wed, Oct 17, 2001 at 08:39:47PM -0400, Sean Elble wrote: > Hello, > > I recently upgraded my home server to the XFS CVS tree, in addition to > upgrading all of the corresponding XFS utilities. I also got the latest > quota SRPM from SGI, and compiled that as well. When I try to use quotaon Ah, yes - you probably don't want to do that anymore. Now that all of the quota changes to support XFS are in the base quota tools (have been for awhile - download from sourceforge) and in Debian, Mandrake, RedHat, Suse and several other distributions, we will no longer be doing "special" versions of quota tools for XFS. > /dev/hda5, it says enable XFS user quota at mount, but defaults,usrquota is > given as the options in my /etc/fstab file. Perhaps your kernel has not been built with XFS quota support? Other than that, not sure what else it could be. You will see a console message during mount if quota is built in and you are using one of the quota mount options for the first time, along the lines: XFS mounting filesystem ide0(3,8) XFS quotacheck ide0(3,8): Please wait. XFS quotacheck ide0(3,8): Done. > Could it be that mount is fsck'ing up? Should I try to upgrade that? No, that wont help. If its not a kernel build issue, then the examples and extra information in README.quota in the xfsprogs information might also help you out here. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Oct 17 18:04:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9I144a12729 for linux-xfs-outgoing; Wed, 17 Oct 2001 18:04:04 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9I141D12707 for ; Wed, 17 Oct 2001 18:04:01 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id SAA13392 for ; Wed, 17 Oct 2001 18:03:56 -0700 (PDT) mail_from (mg@smack.melbourne.sgi.com) Received: from smack.melbourne.sgi.com (smack.melbourne.sgi.com [134.14.55.210]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA22795; Thu, 18 Oct 2001 11:02:43 +1000 Received: from localhost (mg@localhost) by smack.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id LAA96113; Thu, 18 Oct 2001 11:02:42 +1000 (EST) Date: Thu, 18 Oct 2001 11:02:42 +1000 From: Mike Gigante To: Keith Matthews cc: linux-xfs@oss.sgi.com Subject: Re: Mandrake 8.1 with XFS??? In-Reply-To: <20011017071618.4CE10125E6@rebutia.sweeney.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Keith Matthews sez: > Despite the encouragement from Mike and Ivan it needs to be said that > there is a fair sized thread on uk.comp.os.linux about people having > trouble with the installer. > > I suspect they have slightly unusual hardware, but that shouldn't > really cause trouble Quite possibly, my desktop linux box is a PIII on Intel 810 with Matrox G400 and IDE disks - as vanilla as they come. Mike From owner-linux-xfs@oss.sgi.com Wed Oct 17 18:23:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9I1NM913077 for linux-xfs-outgoing; Wed, 17 Oct 2001 18:23:22 -0700 Received: from deimos.hpl.hp.com (deimos.hpl.hp.com [192.6.19.190]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9I1NKD13054 for ; Wed, 17 Oct 2001 18:23:20 -0700 Received: from hplms2.hpl.hp.com (hplms2.hpl.hp.com [15.0.152.33]) by deimos.hpl.hp.com (8.9.3 (PHNE_18546)/HPL-PA Relay) with ESMTP id SAA10877; Wed, 17 Oct 2001 18:22:52 -0700 (PDT) Received: from napali.hpl.hp.com (napali.hpl.hp.com [15.4.89.123]) by hplms2.hpl.hp.com (8.10.2/8.10.2 HPL-PA Hub) with ESMTP id f9I1Mu910531; Wed, 17 Oct 2001 18:22:56 -0700 (PDT) Received: (from davidm@localhost) by napali.hpl.hp.com (8.9.3/8.9.3) id SAA09096; Wed, 17 Oct 2001 18:22:56 -0700 X-Authentication-Warning: napali.hpl.hp.com: davidm set sender to davidm@hpl.hp.com using -f From: David Mosberger MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15310.12016.75527.864434@napali.hpl.hp.com> Date: Wed, 17 Oct 2001 18:22:56 -0700 To: Nathan Straz Cc: linux-xfs@oss.sgi.com, linux-ia64@linuxia64.org Subject: Re: [Linux-ia64] SGI XFS 1.0.1-IA64 Preview Release 2 available for testing In-Reply-To: <20011017171322.B4625@sgi.com> References: <20011017171322.B4625@sgi.com> X-Mailer: VM 6.76 under Emacs 20.4.1 Reply-To: davidm@hpl.hp.com X-URL: http://www.hpl.hp.com/personal/David_Mosberger/ Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>>>> On Wed, 17 Oct 2001 17:13:23 -0500, Nathan Straz said: Nathan> Trillian 2.4.9-010820 Please stop using this name. There is no such thing anymore. --david From owner-linux-xfs@oss.sgi.com Wed Oct 17 18:36:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9I1aTP13343 for linux-xfs-outgoing; Wed, 17 Oct 2001 18:36:29 -0700 Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.121.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9I1aMD13321 for ; Wed, 17 Oct 2001 18:36:22 -0700 Received: from dhcp10 (static031-81-151-24.nm01-c3.cpe.charter-ne.com [24.151.81.31]) by harrier.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id SAA26702; Wed, 17 Oct 2001 18:36:18 -0700 (PDT) Message-ID: <006e01c15775$21f7c280$0a00a8c0@intranet.mp3s.com> Reply-To: "Sean Elble" From: "Sean Elble" To: "Nathan Scott" Cc: References: <003701c1576d$656871c0$0a00a8c0@intranet.mp3s.com> <20011018115833.C522717@wobbly.melbourne.sgi.com> Subject: Re: Quota Support Date: Wed, 17 Oct 2001 21:33:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk So I should try to grab the SourceForge package instead? The SGI version is fairly current (pre-4 I think), but I'll give anything a shot at this point. I enabled XFS quotas _and_ the other quota thing in the kernel . . . here is a snippet of my start-up: VFS: Diskquotas version dquot_6.4.0 initialized SGI XFS with ACLs, EAs, DMAPI, quota, no debug enabled [ . . . ] XFS mounting filesystem ide0(3,5) XFS quotacheck ide0(3,5): Please wait. XFS quotacheck ide0(3,5): Done. It looks like everything is working correctly, until I try to do quota on. :-( I think the SGI quota tools isn't "special", but you just provide it as a "nice thing" . . . you know better than I do though. :-) Thanks again, and have a good one; I'll try to build tommorow. -------------------------------------------- Sean P. Elble Editor, Writer, Co-Webmaster MaximumLinux.org http://www.maximumlinux.org/ elbles@maximumlinux.org -------------------------------------------- ----- Original Message ----- From: "Nathan Scott" To: "Sean Elble" Cc: Sent: Wednesday, October 17, 2001 8:58 PM Subject: Re: Quota Support > hi, > > On Wed, Oct 17, 2001 at 08:39:47PM -0400, Sean Elble wrote: > > Hello, > > > > I recently upgraded my home server to the XFS CVS tree, in addition to > > upgrading all of the corresponding XFS utilities. I also got the latest > > quota SRPM from SGI, and compiled that as well. When I try to use quotaon > > Ah, yes - you probably don't want to do that anymore. Now that > all of the quota changes to support XFS are in the base quota > tools (have been for awhile - download from sourceforge) and in > Debian, Mandrake, RedHat, Suse and several other distributions, > we will no longer be doing "special" versions of quota tools for > XFS. > > > /dev/hda5, it says enable XFS user quota at mount, but defaults,usrquota is > > given as the options in my /etc/fstab file. > > Perhaps your kernel has not been built with XFS quota support? > Other than that, not sure what else it could be. You will see > a console message during mount if quota is built in and you are > using one of the quota mount options for the first time, along > the lines: > XFS mounting filesystem ide0(3,8) > XFS quotacheck ide0(3,8): Please wait. > XFS quotacheck ide0(3,8): Done. > > > Could it be that mount is fsck'ing up? Should I try to upgrade that? > > No, that wont help. If its not a kernel build issue, then the > examples and extra information in README.quota in the xfsprogs > information might also help you out here. > > cheers. > > -- > Nathan From owner-linux-xfs@oss.sgi.com Wed Oct 17 18:59:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9I1x7s13693 for linux-xfs-outgoing; Wed, 17 Oct 2001 18:59:07 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9I1x3D13671 for ; Wed, 17 Oct 2001 18:59:03 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9I1wuW08307 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Wed, 17 Oct 2001 18:58:56 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id DAA3493329 for ; Thu, 18 Oct 2001 03:57:36 +0200 (CEST) mail_from (nathans@wobbly.melbourne.sgi.com) 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 LAA23145; Thu, 18 Oct 2001 11:57:35 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA89083; Thu, 18 Oct 2001 12:57:34 +1100 (AEDT) Date: Thu, 18 Oct 2001 12:57:34 +1100 From: Nathan Scott To: Sean Elble Cc: linux-xfs@oss.sgi.com Subject: Re: Quota Support Message-ID: <20011018125734.D522717@wobbly.melbourne.sgi.com> References: <003701c1576d$656871c0$0a00a8c0@intranet.mp3s.com> <20011018115833.C522717@wobbly.melbourne.sgi.com> <006e01c15775$21f7c280$0a00a8c0@intranet.mp3s.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <006e01c15775$21f7c280$0a00a8c0@intranet.mp3s.com>; from S_Elble@yahoo.com on Wed, Oct 17, 2001 at 09:33:44PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Sean, On Wed, Oct 17, 2001 at 09:33:44PM -0400, Sean Elble wrote: > So I should try to grab the SourceForge package instead? The SGI version is > fairly current (pre-4 I think), but I'll give anything a shot at this point. > I enabled XFS quotas _and_ the other quota thing in the kernel . . . here is > a snippet of my start-up: Aha, very useful information. > SGI XFS with ACLs, EAs, DMAPI, quota, no debug enabled > [ . . . ] > XFS mounting filesystem ide0(3,5) > XFS quotacheck ide0(3,5): Please wait. > XFS quotacheck ide0(3,5): Done. > > It looks like everything is working correctly, until I try to do quota on. Cool - so quota are on already! What was the problem again? ;-) You don't need to use quotaon(8) for XFS quota here - XFS quota are enabled at mount time. This is one of the areas where XFS quota differs quite a bit to other implementations of quota. In XFS the quotaon, quotacheck, and mount operations are one operation - the time window between these operations which exists for other quota implementations (wherein it is possible to write to the filesystem before quota are enabled) has been removed, so it is impossible to "corrupt" the quota accounting [meta]data in this way. Check out README.quota... it'll fill in the missing pieces for you. > :-( I think the SGI quota tools isn't "special", but you just provide it as > a "nice thing" . . . you know better than I do though. :-) Thanks again, and > have a good one; I'll try to build tommorow. You don't need to rebuild - from the XFS kernel initialization line above we can see that quotas have indeed been compiled in. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Oct 17 19:22:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9I2MPB14366 for linux-xfs-outgoing; Wed, 17 Oct 2001 19:22:25 -0700 Received: from web11702.mail.yahoo.com (web11702.mail.yahoo.com [216.136.172.68]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9I2MID14343 for ; Wed, 17 Oct 2001 19:22:18 -0700 Message-ID: <20011018022218.62942.qmail@web11702.mail.yahoo.com> Received: from [24.151.81.31] by web11702.mail.yahoo.com via HTTP; Wed, 17 Oct 2001 19:22:18 PDT Date: Wed, 17 Oct 2001 19:22:18 -0700 (PDT) From: Sean Elble Subject: Re: Quota Support To: Nathan Scott Cc: linux-xfs@oss.sgi.com In-Reply-To: <20011018125734.D522717@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Nathan, Thanks for the quick replies. I'll be sure to check out the README on the quotas, as well as try to grasp a basic understanding of how to use the command-line quota tools (Webmin doesn't work well with XFS Quotas . . . maybe I should hack it). Thanks again for all your help . . . I really appreciate it. Sean Elble --- Nathan Scott wrote: > hi Sean, > > On Wed, Oct 17, 2001 at 09:33:44PM -0400, Sean Elble > wrote: > > So I should try to grab the SourceForge package > instead? The SGI version is > > fairly current (pre-4 I think), but I'll give > anything a shot at this point. > > I enabled XFS quotas _and_ the other quota thing > in the kernel . . . here is > > a snippet of my start-up: > > Aha, very useful information. > > > SGI XFS with ACLs, EAs, DMAPI, quota, no debug > enabled > > [ . . . ] > > XFS mounting filesystem ide0(3,5) > > XFS quotacheck ide0(3,5): Please wait. > > XFS quotacheck ide0(3,5): Done. > > > > It looks like everything is working correctly, > until I try to do quota on. > > Cool - so quota are on already! What was the > problem again? ;-) > > You don't need to use quotaon(8) for XFS quota here > - XFS quota are > enabled at mount time. This is one of the areas > where XFS quota > differs quite a bit to other implementations of > quota. In XFS the > quotaon, quotacheck, and mount operations are one > operation - the > time window between these operations which exists > for other quota > implementations (wherein it is possible to write to > the filesystem > before quota are enabled) has been removed, so it is > impossible to > "corrupt" the quota accounting [meta]data in this > way. > > Check out README.quota... it'll fill in the missing > pieces for you. > > > :-( I think the SGI quota tools isn't "special", > but you just provide it as > > a "nice thing" . . . you know better than I do > though. :-) Thanks again, and > > have a good one; I'll try to build tommorow. > > You don't need to rebuild - from the XFS kernel > initialization line > above we can see that quotas have indeed been > compiled in. > > cheers. > > -- > Nathan > __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com From owner-linux-xfs@oss.sgi.com Wed Oct 17 19:29:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9I2Ttu14633 for linux-xfs-outgoing; Wed, 17 Oct 2001 19:29:55 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9I2TqD14611 for ; Wed, 17 Oct 2001 19:29:52 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with SMTP id f9I2ThW09896 for ; Wed, 17 Oct 2001 19:29:43 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA23352; Thu, 18 Oct 2001 12:28:26 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA15602; Thu, 18 Oct 2001 13:28:24 +1100 (AEDT) Date: Thu, 18 Oct 2001 13:28:24 +1100 From: Nathan Scott To: Sean Elble Cc: linux-xfs@oss.sgi.com Subject: Re: Quota Support Message-ID: <20011018132824.E522717@wobbly.melbourne.sgi.com> References: <20011018125734.D522717@wobbly.melbourne.sgi.com> <20011018022218.62942.qmail@web11702.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: <20011018022218.62942.qmail@web11702.mail.yahoo.com>; from s_elble@yahoo.com on Wed, Oct 17, 2001 at 07:22:18PM -0700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Oct 17, 2001 at 07:22:18PM -0700, Sean Elble wrote: > Nathan, > > Thanks for the quick replies. I'll be sure to check > out the README on the quotas, as well as try to grasp > a basic understanding of how to use the command-line > quota tools (Webmin doesn't work well with XFS Quotas > . . . maybe I should hack it). That would be great - there's been other people asking for that too. Bit of perl hacking involved there. > Thanks again for all your help . . . I really appreciate it. No worries. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Oct 17 21:01:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9I41D216345 for linux-xfs-outgoing; Wed, 17 Oct 2001 21:01:13 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9I418D16317 for ; Wed, 17 Oct 2001 21:01:08 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id VAA07566 for ; Wed, 17 Oct 2001 21:00:17 -0700 (PDT) mail_from (ivanr@omen.melbourne.sgi.com) Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA23718 for ; Thu, 18 Oct 2001 13:59:50 +1000 Received: (from ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA40702 for linux-xfs@oss.sgi.com; Thu, 18 Oct 2001 13:59:49 +1000 (EST) Date: Thu, 18 Oct 2001 13:59:49 +1000 (EST) From: Ivan Rayner Message-Id: <200110180359.NAA40702@omen.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 820267 - enable xfsrestore to run on non-xfs filesystem Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This removes the restriction that xfsrestore -t must be run on an xfs filesystem (which seemed to adversely affect amanda users). It also removes the (harmless) space pre-allocation warnings if restore is writing to a non-xfs filesystem. Ivan Date: Wed Oct 17 20:54:34 PDT 2001 Workarea: omen.melbourne.sgi.com:/hosts/snort/diskb/build6/ivanr/isms/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:104985a cmd/xfsdump/restore/namreg.c - 1.2 cmd/xfsdump/restore/dirattr.c - 1.3 - dont issue a warning if space pre-allocation failed for mmap file if the operation is not supported cmd/xfsdump/restore/content.c - 1.16 - dont check whether housekeeping directory is on xfs filesystem From owner-linux-xfs@oss.sgi.com Wed Oct 17 23:01:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9I61PK17982 for linux-xfs-outgoing; Wed, 17 Oct 2001 23:01:25 -0700 Received: from ente.berdmann.de (frnk-d514e1ac.dsl.mediaWays.net [213.20.225.172]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9I61GD17956 for ; Wed, 17 Oct 2001 23:01:17 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 15u6Ew-0000Il-00; Thu, 18 Oct 2001 08:01:10 +0200 Message-ID: <3BCE7025.66B7DDC8@berdmann.de> Date: Thu, 18 Oct 2001 08:01:09 +0200 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.13-pre2-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: "amanda-users@amanda.org" , Linux XFS Mailing List Subject: xfsdump: "WARNING: failed to get valid bulkstat information for inode 758724" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, every night Amanda emails me these warnings from xfsdump. This seems to be perfectly normal for more or less active filesystems. Where can we tell Amanda to ignore these warnings? FAILED AND STRANGE DUMP DETAILS: /-- ente /var lev 2 STRANGE sendbackup: start [ente:/var level 2] sendbackup: info BACKUP=/usr/sbin/xfsdump sendbackup: info RECOVER_CMD=/usr/sbin/xfsrestore -f... - sendbackup: info end | xfsdump: version 3.0 - Running single-threaded | xfsdump: level 2 incremental dump of ente:/var based on level 1 dump begun Mon Oct 15 01:48:51 2001 | xfsdump: dump date: Thu Oct 18 01:55:31 2001 | xfsdump: session id: 7da36377-00bd-48f4-afd8-76593ef9b467 | xfsdump: session label: "" | xfsdump: ino map phase 1: skipping (no subtrees specified) | xfsdump: ino map phase 2: constructing initial dump list ? xfsdump: WARNING: failed to get valid bulkstat information for inode 758724 | xfsdump: ino map phase 3: pruning unneeded subtrees ? xfsdump: WARNING: failed to get valid bulkstat information for inode 758724 | xfsdump: ino map phase 4: estimating dump size ? xfsdump: WARNING: failed to get valid bulkstat information for inode 758724 | xfsdump: ino map phase 5: skipping (only one dump stream) | xfsdump: ino map construction complete | xfsdump: estimated dump size: 76693376 bytes | xfsdump: creating dump session media file 0 (media 0, file 0) | xfsdump: dumping ino map | xfsdump: dumping directories ? xfsdump: WARNING: failed to get valid bulkstat information for inode 758724 | xfsdump: dumping non-directory files ? xfsdump: WARNING: failed to get valid bulkstat information for inode 758724 | xfsdump: ending media file | xfsdump: media file size 78355232 bytes | xfsdump: dump size (non-dir files) : 77925384 bytes | xfsdump: dump complete: 42 seconds elapsed | xfsdump: Dump Status: SUCCESS sendbackup: size 76519 sendbackup: end \-------- From owner-linux-xfs@oss.sgi.com Wed Oct 17 23:12:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9I6CTK18213 for linux-xfs-outgoing; Wed, 17 Oct 2001 23:12:29 -0700 Received: from ente.berdmann.de (frnk-d514e1ac.dsl.mediaWays.net [213.20.225.172]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9I6CRD18191 for ; Wed, 17 Oct 2001 23:12:28 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 15u6Pl-0000ML-00; Thu, 18 Oct 2001 08:12:22 +0200 Message-ID: <3BCE72C5.9C140CBB@berdmann.de> Date: Thu, 18 Oct 2001 08:12:21 +0200 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.13-pre2-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Ivan Rayner CC: linux-xfs@oss.sgi.com Subject: Re: TAKE 820267 - enable xfsrestore to run on non-xfs filesystem References: <200110180359.NAA40702@omen.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > This removes the restriction that xfsrestore -t must be run on an xfs > filesystem (which seemed to adversely affect amanda users). Great! Thanks! From owner-linux-xfs@oss.sgi.com Thu Oct 18 00:58:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9I7wWg19812 for linux-xfs-outgoing; Thu, 18 Oct 2001 00:58:32 -0700 Received: from ns.procomp.net (ns.procomp.net [195.109.47.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9I7wLD19758 for ; Thu, 18 Oct 2001 00:58:21 -0700 Received: from port001 (floink.xs4all.nl [213.84.65.168]) by ns.procomp.net (8.10.0/8.10.0) with SMTP id f9I7w6H12580 for ; Thu, 18 Oct 2001 09:58:07 +0200 Reply-To: From: "Joost van der Locht" To: Subject: Installation 'manual' for LVM+XFS+Linux Distribution(Redhat) Date: Thu, 18 Oct 2001 09:58:18 +0200 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) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, Does anyone has a step-to-step handson manual for installing LVM + XFS + Linux Distribution like RedHat 7.1? Especialy for newbe's like myself. Thanks in advance Joost van der Locht Technisch Directeur E*Cube BV Toernooiveld 214 - 6525 EC Nijmegen T: 024-3500437 - F: 024-3500613 http://www.e-cube.nl e-mail: joost@e-cube.nl ICQ UIN: 494145 From owner-linux-xfs@oss.sgi.com Thu Oct 18 00:58:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9I7wS319784 for linux-xfs-outgoing; Thu, 18 Oct 2001 00:58:28 -0700 Received: from quasar.sif.it (IDENT:root@quasar.sif.it [131.154.110.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9I7wJD19756 for ; Thu, 18 Oct 2001 00:58:20 -0700 Received: from localhost (matteo@localhost) by quasar.sif.it (8.11.6/8.11.6) with ESMTP id f9I7woG28003; Thu, 18 Oct 2001 09:58:50 +0200 Date: Thu, 18 Oct 2001 09:58:50 +0200 (CEST) From: Matteo Centonza To: cc: Subject: NFS and xfsdump oops Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Steve, looking over LK, i've found an interesting thread i'm concerned with (NFS related Oops in 2.4.[39]-xfs). Last weekend our main file server oopsed during the weekly run of amanda (doing xfsdump): embeh [09:39am] (0.12) ~> uname -a Linux embeh.sif.it 2.4.9-xfs-1 #1 Tue Aug 28 11:18:44 CEST 2001 i686 compiled with kgcc. That's the oops: Oct 13 00:50:38 embeh kernel: Unable to handle kernel NULL pointer dereference at virtual add Oct 13 00:50:38 embeh kernel: 00000000 Oct 13 00:50:38 embeh kernel: *pde = 00000000 Oct 13 00:50:38 embeh kernel: Oops: 0000 Oct 13 00:50:38 embeh kernel: CPU: 0 Oct 13 00:50:38 embeh kernel: EIP: 0010:[agp_frontend_cleanup+0/96] Oct 13 00:50:38 embeh kernel: EIP: 0010:[<00000000>] Using defaults from ksymoops -t elf32-i386 -a i386 Oct 13 00:50:38 embeh kernel: EFLAGS: 00010286 Oct 13 00:50:38 embeh kernel: eax: 00000000 ebx: de666540 ecx: de666f1c edx: c04c6700 Oct 13 00:50:38 embeh kernel: esi: de666ec0 edi: de666540 ebp: de666540 esp: ddcfbe58 Oct 13 00:50:38 embeh kernel: ds: 0018 es: 0018 ss: 0018 Oct 13 00:50:38 embeh kernel: Process nfsd (pid: 734, stackpage=ddcfb000) Oct 13 00:50:38 embeh kernel: Stack: c0187284 d42b8cc0 de666ec0 00000002 decf3c00 c0187696 de 666540 00000002 Oct 13 00:50:38 embeh kernel: ddd06400 ddd06804 ddd49800 00000000 decf3de8 ddd06400 c0 1879d2 decf3c00 Oct 13 00:50:38 embeh kernel: ddd06814 00000002 00000001 00000001 00000007 00000007 cc ffad28 ddd06400 Oct 13 00:50:38 embeh kernel: Call Trace: [nfsd_findparent+52/224] [find_fh_dentry+534/816] [ Oct 13 00:50:38 embeh kernel: Call Trace: [] [] [] [] [] Oct 13 00:50:38 embeh kernel: [] [] [] [] [>EIP; 00000000 Before first symbol Trace; c0187284 Trace; c0187696 Trace; c01879d2 Trace; c0188332 Trace; c010ec49 Trace; c018e34e Trace; c0190130 Trace; c0185863 Trace; c0329328 Athlon 1.33 Ghz, LVM over RAID5, userland and kernel from CVS as of 2001-08-28, xfsdump-1.1.3-0 hope this helps, -m From owner-linux-xfs@oss.sgi.com Thu Oct 18 01:24:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9I8Ose20435 for linux-xfs-outgoing; Thu, 18 Oct 2001 01:24:54 -0700 Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9I8OpD20412 for ; Thu, 18 Oct 2001 01:24:51 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9I8PVvI090537; Thu, 18 Oct 2001 10:25:32 +0200 (CEST) Message-Id: <4.3.2.7.2.20011018101845.037f5ec0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 18 Oct 2001 10:23:20 +0200 To: , From: Seth Mos Subject: Re: Installation 'manual' for LVM+XFS+Linux Distribution(Redhat) In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 09:58 18-10-2001 +0200, Joost van der Locht wrote: >Hello, > >Does anyone has a step-to-step handson manual for installing LVM + XFS + >Linux Distribution like RedHat 7.1? Especialy for newbe's like myself. None that I know off. What you could do is at least get the SGI XFS installer and install the redhat 7.1 system with that and build a LVM volume after installation. AFAIK the redhat 7.1/SGI XFS installer does not permit LVM configuration at install time. Have you tried finding some LVM information over at linuxdoc.org. The LVM parts probably costs more time to figure out then getting XFS going. Getting XFS on your LVM volume is just a mkfs away. Cheers/Groeten -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Thu Oct 18 01:41:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9I8fDO21163 for linux-xfs-outgoing; Thu, 18 Oct 2001 01:41:13 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9I8f9D21140 for ; Thu, 18 Oct 2001 01:41:10 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 98A38C00B61 for ; Thu, 18 Oct 2001 16:41:03 +0800 (PHT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 4779DC00B60 for ; Thu, 18 Oct 2001 16:41:01 +0800 (PHT) Date: Thu, 18 Oct 2001 16:41:01 +0800 (PHT) From: Federico Sevilla III To: Linux XFS Mailing List Subject: Re: Dynamic resizing In-Reply-To: <3BCC417E.5C56E61D@club-internet.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 16 Oct 2001 at 16:17, Jean Francois Martinez wrote: > Does XFS support dynamic resizing? Are there plans to implement it? I am not so sure about what you mean by "dynamic" but this might (hopefully) answer your question: --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Thu Oct 18 01:45:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9I8jJC21333 for linux-xfs-outgoing; Thu, 18 Oct 2001 01:45:19 -0700 Received: from feivel.credativ.de (cdt1.tz-juelich.de [195.37.52.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9I8jED21310 for ; Thu, 18 Oct 2001 01:45:15 -0700 Received: by feivel.credativ.de (Postfix, from userid 1000) id BE105A6017; Thu, 18 Oct 2001 10:48:07 +0200 (CEST) Date: Thu, 18 Oct 2001 10:48:07 +0200 From: Michael Meskes To: Nathan Scott Cc: Robert Sander , linux-xfs@oss.sgi.com, Michael Meskes Subject: Re: reenabling quota after xfs_repair Message-ID: <20011018104807.A19705@feivel.credativ.de> References: <200110171613.f9HGDhW17816@jen.americas.sgi.com> <20011018112928.B522717@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011018112928.B522717@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.3.22i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Oct 18, 2001 at 11:29:28AM +1100, Nathan Scott wrote: > Are you using Debian? The versioning scheme used there > is a bit different - 3.00pre01-15 is fairly recent, but > not quite the same as 3.01-final from sourceforge. I've I just uploaded 3.01. It should be in unstable tomorrow, i.e. sometime later today, so it depends on your time zone. Unless there is any grave bug in the package it should move into testing next week. Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! From owner-linux-xfs@oss.sgi.com Thu Oct 18 02:19:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9I9JiW22210 for linux-xfs-outgoing; Thu, 18 Oct 2001 02:19:44 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9I9JeD22188 for ; Thu, 18 Oct 2001 02:19:40 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id A3300C00B61 for ; Thu, 18 Oct 2001 17:19:37 +0800 (PHT) Received: from cache.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 52B1FC00B60 for ; Thu, 18 Oct 2001 17:19:36 +0800 (PHT) Date: Thu, 18 Oct 2001 17:19:36 +0800 (PHT) From: Federico Sevilla III To: Linux XFS Mailing List Subject: Preemptible Kernel Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi everyone, I remember a TAKE before that announced that the XFS kernel was officially preemptible ready. What did this mean? I've been reading about Robert Love's preemptible patches, and am very interested. Does the XFS kernel's being preemptible ready mean that I can cleanly apply Robert Love's patch for the correct kernel version on the XFS kernel, and configure the kernel to use this feature? I wonder: would it be too much to ask that Robert Love's preemptible patches be incorporated into the XFS kernel already? I've been reading about them and it looks like they're fairly stable. I know the XFS tree has some other stuff in aside from the XFS code that is not in the mainline kernel. I was hoping that maybe Robert Love's preemptible patches could be one of them. But of course this is just a mini suggestion. :) Thanks a lot in advance! :) --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Thu Oct 18 02:29:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9I9Tab22545 for linux-xfs-outgoing; Thu, 18 Oct 2001 02:29:36 -0700 Received: from mx.linux.net.cn ([210.52.24.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9I9TTD22523 for ; Thu, 18 Oct 2001 02:29:30 -0700 Received: from dfbbb.cn.mvd (unknown [211.99.247.66]) by mx.linux.net.cn (Postfix) with ESMTP id 6BB4BE79 for ; Thu, 18 Oct 2001 17:29:36 +0800 (CST) Received: (from dfbb@localhost) by dfbbb.cn.mvd (8.11.2/8.11.2) id f9I9WB104112 for linux-xfs@oss.sgi.com; Thu, 18 Oct 2001 17:32:12 +0800 Date: Thu, 18 Oct 2001 17:32:11 +0800 From: Fang Han To: linux-xfs@oss.sgi.com Subject: [BUG]XFS at CONFIG_SCSI_MULTI_LUN Message-ID: <20011018173211.C1476@dfbbb.cn.mvd> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I find an very strange bug, And it is reproduce-able. I have an machine with Adaptec 7899p card, And two scsi harddisk on one scsi ID. It means I need use CONFIG_SCSI_MULTI_LUN options on kernel. My kernel is SGI_XFS_1.0.1, I just enable the options, And recompile it using RedHat 7.1 default gcc-2.9.6-85. My scsi harddisk shows to be sda sdb When I run this script: mkfs.xfs /dev/sdb1 time mount -t xfs /dev/sdb1 /mnt I got this output real 0m9.340s user 0m0.000s sys 0m0.000s The mount speed is real slow. Using ext2xfs mkfs /dev/sdb1 time mount /dev/sdb1 /mnt output is : real 0m0.392s user 0m0.000s sys 0m0.000s Using resiserfs also very fast. lvol1 can be from 500M - 10 G , And the result is same. In the same time I run mkfs.xfs /dev/sda5 time mount -t xfs /dev/sda5 /mnt result is: real 0m0.523s user 0m0.000s sys 0m0.000s sda5 size is same with sdb1 So the question is very clear, mount an XFS on the MULTI_LUN scsi device is very slow. Who know the reason? Dan From owner-linux-xfs@oss.sgi.com Thu Oct 18 02:42:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9I9gXP22873 for linux-xfs-outgoing; Thu, 18 Oct 2001 02:42:33 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9I9gUD22851 for ; Thu, 18 Oct 2001 02:42:30 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 3D05AC00B61 for ; Thu, 18 Oct 2001 17:42:28 +0800 (PHT) Received: from mail.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 193EDC00B60 for ; Thu, 18 Oct 2001 17:42:27 +0800 (PHT) Date: Thu, 18 Oct 2001 17:42:27 +0800 (PHT) From: Federico Sevilla III To: Linux XFS Mailing List Subject: Re: Preemptible Kernel In-Reply-To: <200110180937.f9I9b1Z19669@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 18 Oct 2001 at 04:37, Steve Lord wrote: > They should apply cleanly - all needed xfs changes are in xfs already. > I don't want to put them into our tree - we have enough baggage > already. The only non XFS things we have now are, a different LVM > version and kdb. Okay. Thanks a lot! :) --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Thu Oct 18 02:55:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9I9t9R23227 for linux-xfs-outgoing; Thu, 18 Oct 2001 02:55:09 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9I9t6D23204 for ; Thu, 18 Oct 2001 02:55:06 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id CAA16981 for ; Thu, 18 Oct 2001 02:55:01 -0700 (PDT) mail_from (kaos@melbourne.sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by nodin.corp.sgi.com (8.11.4/8.11.2/nodin-1.0) with ESMTP id f9I9s3C5907404; Thu, 18 Oct 2001 02:54:04 -0700 (PDT) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id A9041300090; Thu, 18 Oct 2001 19:54:02 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 9C6A098; Thu, 18 Oct 2001 19:54:02 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Federico Sevilla III Cc: Linux XFS Mailing List Subject: Re: Preemptible Kernel In-reply-to: Your message of "Thu, 18 Oct 2001 17:19:36 +0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 18 Oct 2001 19:53:57 +1000 Message-ID: <11124.1003398837@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 18 Oct 2001 17:19:36 +0800 (PHT), Federico Sevilla III wrote: >I remember a TAKE before that announced that the XFS kernel was officially >preemptible ready. What did this mean? A #include line was added to two XFS files to compile with the preemtible patch. >I've been reading about Robert Love's preemptible patches, and am very >interested. Does the XFS kernel's being preemptible ready mean that I can >cleanly apply Robert Love's patch for the correct kernel version on the >XFS kernel, and configure the kernel to use this feature? Yes. >I wonder: would it be too much to ask that Robert Love's preemptible >patches be incorporated into the XFS kernel already? No chance! XFS has to run on multiple architectures, most of which have not been tested against the preemptible patches. From owner-linux-xfs@oss.sgi.com Thu Oct 18 02:57:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9I9vl023368 for linux-xfs-outgoing; Thu, 18 Oct 2001 02:57:47 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9I9veD23346 for ; Thu, 18 Oct 2001 02:57:41 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 534CDC00B61 for ; Thu, 18 Oct 2001 17:57:34 +0800 (PHT) Received: from mrtg.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 39129C00B60 for ; Thu, 18 Oct 2001 17:57:32 +0800 (PHT) Date: Thu, 18 Oct 2001 17:57:32 +0800 (PHT) From: Federico Sevilla III To: Linux XFS Mailing List Subject: Re: Preemptible Kernel In-Reply-To: <11124.1003398837@kao2.melbourne.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 18 Oct 2001 at 19:53, Keith Owens wrote: > No chance! XFS has to run on multiple architectures, most of which > have not been tested against the preemptible patches. Oops! D*mn. Forgot all about that (the multiple architectures, I mean). Sorry. And thanks for your patient replies. :) --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Thu Oct 18 03:03:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9IA3WP23610 for linux-xfs-outgoing; Thu, 18 Oct 2001 03:03:32 -0700 Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9IA3RD23588 for ; Thu, 18 Oct 2001 03:03:27 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9IA3sau081098; Thu, 18 Oct 2001 12:03:55 +0200 (CEST) Message-Id: <4.3.2.7.2.20011018114511.03712c38@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 18 Oct 2001 12:01:41 +0200 To: Fang Han , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: [BUG]XFS at CONFIG_SCSI_MULTI_LUN In-Reply-To: <20011018173211.C1476@dfbbb.cn.mvd> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 17:32 18-10-2001 +0800, Fang Han wrote: >Hi, I find an very strange bug, And it is reproduce-able. > >I have an machine with Adaptec 7899p card, And two scsi harddisk on one >scsi ID. It means I need use CONFIG_SCSI_MULTI_LUN options on >kernel. My kernel is SGI_XFS_1.0.1, I just enable the options, And >recompile it using RedHat 7.1 default gcc-2.9.6-85. Can you recompile with gcc-2.91.66 (kgcc) >My scsi harddisk shows to be sda sdb > >When I run this script: >mkfs.xfs /dev/sdb1 >time mount -t xfs /dev/sdb1 /mnt > >I got this output > >real 0m9.340s >user 0m0.000s >sys 0m0.000s Is the read an write speed also very slow? Why do you want two harddisks on one scsi ID perse? >So the question is very clear, mount an XFS on the MULTI_LUN scsi >device is very slow. Who know the reason? > >Dan -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Thu Oct 18 05:22:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ICMjL26768 for linux-xfs-outgoing; Thu, 18 Oct 2001 05:22:45 -0700 Received: from home.smithconcepts.com (65.34.25.157.oviedo-ubr-a.cfl.rr.com [65.34.25.157]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ICMdD26746 for ; Thu, 18 Oct 2001 05:22:39 -0700 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id IAA16860; Thu, 18 Oct 2001 08:15:31 -0400 Message-ID: <3BCEC9BA.C0526422@ieee.org> Date: Thu, 18 Oct 2001 08:23:22 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts, Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS101_K7mp i686) X-Accept-Language: en MIME-Version: 1.0 To: Robert Sander CC: linux-xfs@oss.sgi.com Subject: Re: backport to 2.2 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Robert Sander wrote: > Would it be very hard to do? Else we would have to switch back to ext2 > losing the journaling option. If you want journaling on 2.2, go Ext3. I ran the older, full data journaling-only releases for over a year without issues. It's essentially "double buffering." Try this kernels: http://smithconcepts.com/files/ext3/redhat-6.2/2.2.16-21.7.1/ They have the NFS v3 patches and the USB backport. If you need Hendrick's IDE backport, then try this one: http://smithconcepts.com/files/ext3/redhat-6.2/2.2.18-0.13/ Note that kernel includes a newer Ext3 version that defaults to meta-data journaling. I don't trust meta-data on 2.2 and prefer full data (although it is better than full data journaling under 2.4). You'll need a recent version of e2sfprogs (so it is "Ext3 aware"). You can grab them here: http://e2fsprogs.sourceforge.net/ All those kernels are from VALinux and packaged by H. J. Lu. -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ------------------------------------------------------------------ Those living in the US who consider the American flag to be a sym- bol of oppression obviously fail to understand what the word means From owner-linux-xfs@oss.sgi.com Thu Oct 18 08:21:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9IFLqJ30328 for linux-xfs-outgoing; Thu, 18 Oct 2001 08:21:52 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9IFLiD30302 for ; Thu, 18 Oct 2001 08:21:44 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA01157 for ; Thu, 18 Oct 2001 08:20:54 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA3328069; Thu, 18 Oct 2001 10:20:27 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA34684; Thu, 18 Oct 2001 10:20:27 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9IFHo720905; Thu, 18 Oct 2001 10:17:50 -0500 Message-Id: <200110181517.f9IFHo720905@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Matteo Centonza cc: lord@sgi.com, linux-xfs@oss.sgi.com Subject: Re: NFS and xfsdump oops In-Reply-To: Message from Matteo Centonza of "Thu, 18 Oct 2001 09:58:50 +0200." Date: Thu, 18 Oct 2001 10:17:50 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hi Steve, > > looking over LK, i've found an interesting thread i'm concerned > with (NFS related Oops in 2.4.[39]-xfs). > > Last weekend our main file server oopsed during the weekly run of > amanda (doing xfsdump): > > embeh [09:39am] (0.12) ~> uname -a > Linux embeh.sif.it 2.4.9-xfs-1 #1 Tue Aug 28 11:18:44 CEST 2001 i686 > > compiled with kgcc. > > That's the oops: > > Oct 13 00:50:38 embeh kernel: Unable to handle kernel NULL pointer > dereference at virtual add > Oct 13 00:50:38 embeh kernel: 00000000 > Oct 13 00:50:38 embeh kernel: *pde = 00000000 > Oct 13 00:50:38 embeh kernel: Oops: 0000 > Oct 13 00:50:38 embeh kernel: CPU: 0 > Oct 13 00:50:38 embeh kernel: EIP: 0010:[agp_frontend_cleanup+0/96] > Oct 13 00:50:38 embeh kernel: EIP: 0010:[<00000000>] > Using defaults from ksymoops -t elf32-i386 -a i386 > Oct 13 00:50:38 embeh kernel: EFLAGS: 00010286 > Oct 13 00:50:38 embeh kernel: eax: 00000000 ebx: de666540 ecx: > de666f1c edx: c04c6700 > Oct 13 00:50:38 embeh kernel: esi: de666ec0 edi: de666540 ebp: > de666540 esp: ddcfbe58 > Oct 13 00:50:38 embeh kernel: ds: 0018 es: 0018 ss: 0018 > Oct 13 00:50:38 embeh kernel: Process nfsd (pid: 734, stackpage=ddcfb000) > Oct 13 00:50:38 embeh kernel: Stack: c0187284 d42b8cc0 de666ec0 00000002 > decf3c00 c0187696 de > 666540 00000002 > Oct 13 00:50:38 embeh kernel: ddd06400 ddd06804 ddd49800 00000000 > decf3de8 ddd06400 c0 > 1879d2 decf3c00 > Oct 13 00:50:38 embeh kernel: ddd06814 00000002 00000001 00000001 > 00000007 00000007 cc > ffad28 ddd06400 > Oct 13 00:50:38 embeh kernel: Call Trace: [nfsd_findparent+52/224] > [find_fh_dentry+534/816] [ > Oct 13 00:50:38 embeh kernel: Call Trace: [] [] > [] [] > [] > Oct 13 00:50:38 embeh kernel: [] [] [] > [] [ Oct 13 00:50:38 embeh kernel: Code: Bad EIP value. > > >>EIP; 00000000 Before first symbol > Trace; c0187284 > Trace; c0187696 > Trace; c01879d2 > Trace; c0188332 > Trace; c010ec49 > Trace; c018e34e > Trace; c0190130 > Trace; c0185863 > Trace; c0329328 > > > Athlon 1.33 Ghz, LVM over RAID5, userland and kernel from CVS as of > 2001-08-28, xfsdump-1.1.3-0 > > hope this helps, Well, it lands the ball pretty much in our court I guess, so yes it helps. I am starting to form a theory on what is going on here, but there is certainly a problem which means xfsdump and an nfs server can stamp on each other if NFS happens to go for an inode which xfsdump recently accessed. Steve > > -m > From owner-linux-xfs@oss.sgi.com Thu Oct 18 08:29:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9IFTHU30591 for linux-xfs-outgoing; Thu, 18 Oct 2001 08:29:17 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9IFTED30569 for ; Thu, 18 Oct 2001 08:29:14 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.6/8.11.6) id f9IFT8B27788 for linux-xfs@oss.sgi.com; Thu, 18 Oct 2001 11:29:08 -0400 Date: Thu, 18 Oct 2001 11:29:07 -0400 From: Alan Eldridge To: SGI XFS Dev List Subject: Goodbye and thanks for all the fish Message-ID: <20011018112907.A7573@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Gentlemen and Ladies, I bid you farewell for now. Partly due to the current Linus vs XFS situation, the lack of any other viable journaling FS for Linux, and partly due to outside factors, I am converting to the camp of the Daemon. Thanks for everything, especially all the good kernel bits I've been running. I'll attempt to still fulfill my goal of producing daily XFS RPMS and put them on Andy Kwong's site, once the new system has settled down. A special thanks to Eric, Steve, Russell, Seth, and Keith: you guys are fantastic. TTFN -- Alan Eldridge from std_disclaimer import * From owner-linux-xfs@oss.sgi.com Thu Oct 18 08:52:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9IFqv231100 for linux-xfs-outgoing; Thu, 18 Oct 2001 08:52:57 -0700 Received: from chef.cc.absoval.com (cpe-66-1-218-101.fl.sprintbbd.net [66.1.218.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9IFqqD31078 for ; Thu, 18 Oct 2001 08:52:52 -0700 Received: from ieee.org (IDENT:bs@thebs.cc.absoval.com [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id LAA21790; Thu, 18 Oct 2001 11:52:43 -0400 Message-ID: <3BCEFACE.51E1A3FE@ieee.org> Date: Thu, 18 Oct 2001 11:52:46 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts/AbsoluteValueSystems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Alan Eldridge CC: SGI XFS Dev List Subject: Re: Goodbye and thanks for all the fish References: <20011018112907.A7573@wwweasel.geeksrus.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Alan Eldridge wrote: > I bid you farewell for now. Partly due to the current Linus vs XFS > situation, the lack of any other viable journaling FS for Linux, and partly > due to outside factors, I am converting to the camp of the Daemon. ??? That makes absolute no sense ??? What "Linux vs. XFS" situation are you talking about? It's more of a "distro vs. XFS" situation. Linus/Alan seem to be pretty "gung-ho" on XFS for 2.5/3.0. Besides, some of us have been running Ext3 for 20 months, and XFS now for close to 8, on production networks. I have a notebook computer with a pre-mix of RedHat 7.1 + SGI XFS 1.0.1 + Updates + Ximian Gnome that I use to install all my systems (home, work, consulting) in <30 minutes. I don't know how easier it could be! I'd say the "outside factors" are just using some of the FUD you mentioned to con you. People can argue any position they want to. The "choice" we have in Linux is the same thing Windows bigots use to say Linux is "fragmented." Again, FUD. -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ---------------------------------------------------------------- The US National ID is an enhanced Social Security Number. It will give those who abuse it more information than ever before. And just like the SSN, they will ignore all the regulations. From owner-linux-xfs@oss.sgi.com Thu Oct 18 08:55:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9IFt0i31229 for linux-xfs-outgoing; Thu, 18 Oct 2001 08:55:00 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9IFsuD31192 for ; Thu, 18 Oct 2001 08:54:56 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.6/8.11.6) id f9IFso830694; Thu, 18 Oct 2001 11:54:50 -0400 Date: Thu, 18 Oct 2001 11:54:49 -0400 From: Alan Eldridge To: Bryan-TheBS-Smith Cc: SGI XFS Dev List Subject: Re: Goodbye and thanks for all the fish Message-ID: <20011018115449.A26033@wwweasel.geeksrus.net> References: <20011018112907.A7573@wwweasel.geeksrus.net> <3BCEFACE.51E1A3FE@ieee.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BCEFACE.51E1A3FE@ieee.org>; from b.j.smith@ieee.org on Thu, Oct 18, 2001 at 11:52:46AM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Oct 18, 2001 at 11:52:46AM -0400, Bryan-TheBS-Smith wrote: >Alan Eldridge wrote: >> I bid you farewell for now. Partly due to the current Linus vs XFS >> situation, the lack of any other viable journaling FS for Linux, and partly >> due to outside factors, I am converting to the camp of the Daemon. > >??? That makes absolute no sense ??? > >What "Linux vs. XFS" situation are you talking about? It's more of >a "distro vs. XFS" situation. Linus/Alan seem to be pretty >"gung-ho" on XFS for 2.5/3.0. That's not the major thing. > >I'd say the "outside factors" are just using some of the FUD you >mentioned to con you. People can argue any position they want to. The outside factors are that a new project at work I'm heading is using FreeBSD servers and I want the same environment. -- Alan Eldridge from std_disclaimer import * From owner-linux-xfs@oss.sgi.com Thu Oct 18 08:55:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9IFthO31291 for linux-xfs-outgoing; Thu, 18 Oct 2001 08:55:43 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9IFteD31268 for ; Thu, 18 Oct 2001 08:55:40 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.6/8.11.6) id f9IFtXS32675; Thu, 18 Oct 2001 11:55:33 -0400 Date: Thu, 18 Oct 2001 11:55:33 -0400 From: Alan Eldridge To: Bryan-TheBS-Smith Cc: SGI XFS Dev List Subject: Re: Goodbye and thanks for all the fish Message-ID: <20011018115533.B26033@wwweasel.geeksrus.net> References: <20011018112907.A7573@wwweasel.geeksrus.net> <3BCEFACE.51E1A3FE@ieee.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BCEFACE.51E1A3FE@ieee.org>; from b.j.smith@ieee.org on Thu, Oct 18, 2001 at 11:52:46AM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Oct 18, 2001 at 11:52:46AM -0400, Bryan-TheBS-Smith wrote: >Alan Eldridge wrote: >> I bid you farewell for now. Partly due to the current Linus vs XFS >> situation, the lack of any other viable journaling FS for Linux, and partly >> due to outside factors, I am converting to the camp of the Daemon. > >??? That makes absolute no sense ??? > >What "Linux vs. XFS" situation are you talking about? It's more of >a "distro vs. XFS" situation. Linus/Alan seem to be pretty You're right, I made a thinko. -- Alan Eldridge from std_disclaimer import * From owner-linux-xfs@oss.sgi.com Thu Oct 18 09:00:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9IG05w31661 for linux-xfs-outgoing; Thu, 18 Oct 2001 09:00:05 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9IG02D31639 for ; Thu, 18 Oct 2001 09:00:02 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.6/8.11.6) id f9IFxv213123 for linux-xfs@oss.sgi.com; Thu, 18 Oct 2001 11:59:57 -0400 Date: Thu, 18 Oct 2001 11:59:56 -0400 From: Alan Eldridge To: SGI XFS Dev List Subject: Clarification before I get flamed too much Message-ID: <20011018115956.C26033@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Major factors for leaving are that a project I'm leading is using FreeBSD. Until XFS becomes part of a distro I can't afford the time to maintain two different OS boxes, especially when I have to build up kernels from CVS for the Linux one. There. No FUD involved. Plain, pragmatic, business decision. In the previous questions I was asking, the "manager" I wanted to know how to convince was me. I think XFS is the salvation for the Linux FS needs, but I have to bow out of development stuff right now. -- Alan Eldridge from std_disclaimer import * From owner-linux-xfs@oss.sgi.com Thu Oct 18 09:03:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9IG3CS31843 for linux-xfs-outgoing; Thu, 18 Oct 2001 09:03:12 -0700 Received: from chef.cc.absoval.com (cpe-66-1-218-101.fl.sprintbbd.net [66.1.218.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9IG39D31821 for ; Thu, 18 Oct 2001 09:03:09 -0700 Received: from ieee.org (IDENT:bs@thebs.cc.absoval.com [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id MAA21862; Thu, 18 Oct 2001 12:03:02 -0400 Message-ID: <3BCEFD39.9E3C0D6D@ieee.org> Date: Thu, 18 Oct 2001 12:03:05 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts/AbsoluteValueSystems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Alan Eldridge CC: SGI XFS Dev List Subject: Re: Goodbye and thanks for all the fish (*DOH!!!*) References: <20011018112907.A7573@wwweasel.geeksrus.net> <3BCEFACE.51E1A3FE@ieee.org> <20011018115449.A26033@wwweasel.geeksrus.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Alan Eldridge wrote: > The outside factors are that a new project at work I'm heading is using > FreeBSD servers and I want the same environment. DOH!!! I wasn't thinking when you said "daemon". Again, DOH!!! I wish you the best of luck then. -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ---------------------------------------------------------------- The US National ID is an enhanced Social Security Number. It will give those who abuse it more information than ever before. And just like the SSN, they will ignore all the regulations. From owner-linux-xfs@oss.sgi.com Thu Oct 18 09:08:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9IG8cE32048 for linux-xfs-outgoing; Thu, 18 Oct 2001 09:08:38 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9IG8YD32026 for ; Thu, 18 Oct 2001 09:08:34 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9IG8TW04111 for ; Thu, 18 Oct 2001 09:08:29 -0700 Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA3344964 for ; Thu, 18 Oct 2001 11:07:14 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id LAA86617 for ; Thu, 18 Oct 2001 11:07:13 -0500 (CDT) Subject: New RH+XFS kernels for testing From: Eric Sandeen To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 18 Oct 2001 11:06:20 -0500 Message-Id: <1003421180.19596.11.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi all - There are some new kernel RPMs available for testing at ftp://oss.sgi.com/projects/xfs/download/testing/RH2.4.7-10/ These are based on the 2.4.7-10 Red Hat kernel RPM from rawhide, rumored to be the version that will ship with their next distro release. These kernels pass my sanity tests, they run (mostly) successfully through the xfs QA suite, with an occasional hang on test 013, which I have not yet found the reason for. (The only RPM that I have actually installed & tested is kernel-smp-2.4.7-10SGI_XFS_PR1.i686.rpm). But if you'd like to help take a look at them, there they are! KDB is not enabled by default, you'll have to turn it on if you want it. Note that it landed in the wrong place for some reason, so echo 1 > /proc/sys/fs/kdb to enable it (next build will have it back in /proc/sys/kernel/kdb) The "ikd" debugger patch that Red Hat ships is not included, it was dropped in favor of a "vanilla" kdb from Keith, just to make the merge go more smoothly. Have fun, -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Oct 18 09:10:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9IGANR32145 for linux-xfs-outgoing; Thu, 18 Oct 2001 09:10:23 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9IGAKD32123 for ; Thu, 18 Oct 2001 09:10:20 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.6/8.11.6) id f9IGABF06909; Thu, 18 Oct 2001 12:10:11 -0400 Date: Thu, 18 Oct 2001 12:10:11 -0400 From: Alan Eldridge To: Bryan-TheBS-Smith Cc: SGI XFS Dev List Subject: Re: Goodbye and thanks [OT] Message-ID: <20011018121011.A18111@wwweasel.geeksrus.net> References: <20011018112907.A7573@wwweasel.geeksrus.net> <3BCEFACE.51E1A3FE@ieee.org> <20011018115449.A26033@wwweasel.geeksrus.net> <3BCEFD39.9E3C0D6D@ieee.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BCEFD39.9E3C0D6D@ieee.org>; from b.j.smith@ieee.org on Thu, Oct 18, 2001 at 12:03:05PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Oct 18, 2001 at 12:03:05PM -0400, Bryan-TheBS-Smith wrote: >Alan Eldridge wrote: >> The outside factors are that a new project at work I'm heading is using >> FreeBSD servers and I want the same environment. > >DOH!!! I wasn't thinking when you said "daemon". Again, DOH!!! > >I wish you the best of luck then. Thanks. I wondered ... The only way I would "go over" to M$ is if I got a job there so I could spy for us good guys. Fat chance. M$ is evil. I was asked why I thought the terrorists didn't blow up M$, and I thought for a moment, and realized this: 1. Terrorists want to make people angry and afraid. 2. Blowing up M$ will not make people angry. Corporate IT mgrs will shit their pants, but hey, they get paid to "deal with it". 3. Can you imagine a TV newscaster reporting the "tragedy" of M$ being destroyed? They'd have to be tranquilized to keep from laughing on air. 4. Oddly enough, what has happened is good for M$. OK, conspiracy theorists, step right up .... -- Alan Eldridge from std_disclaimer import * From owner-linux-xfs@oss.sgi.com Thu Oct 18 09:10:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9IGAZv32222 for linux-xfs-outgoing; Thu, 18 Oct 2001 09:10:35 -0700 Received: from chef.cc.absoval.com (cpe-66-1-218-101.fl.sprintbbd.net [66.1.218.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9IGAWD32200 for ; Thu, 18 Oct 2001 09:10:32 -0700 Received: from ieee.org (IDENT:bs@thebs.cc.absoval.com [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id MAA21892; Thu, 18 Oct 2001 12:10:25 -0400 Message-ID: <3BCEFEF4.BF39E382@ieee.org> Date: Thu, 18 Oct 2001 12:10:28 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts/AbsoluteValueSystems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Alan Eldridge CC: SGI XFS Dev List Subject: Re: Clarification before I get flamed too much (my appologies) References: <20011018115956.C26033@wwweasel.geeksrus.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Alan Eldridge wrote: > Major factors for leaving are that a project ... cut ... Again, I read it _wrong_. Please excuse my ignorance in my original response. I fight FUD all day and read it just totally wrong. Heck, I love to use FreeBSD as an example to Windows bigots. -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ---------------------------------------------------------------- The US National ID is an enhanced Social Security Number. It will give those who abuse it more information than ever before. And just like the SSN, they will ignore all the regulations. From owner-linux-xfs@oss.sgi.com Thu Oct 18 09:15:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9IGF8t32487 for linux-xfs-outgoing; Thu, 18 Oct 2001 09:15:08 -0700 Received: from chef.cc.absoval.com (cpe-66-1-218-101.fl.sprintbbd.net [66.1.218.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9IGF4D32465 for ; Thu, 18 Oct 2001 09:15:04 -0700 Received: from ieee.org (IDENT:bs@thebs.cc.absoval.com [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id MAA21905; Thu, 18 Oct 2001 12:14:51 -0400 Message-ID: <3BCEFFFE.C14346C2@ieee.org> Date: Thu, 18 Oct 2001 12:14:54 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts/AbsoluteValueSystems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: linux-xfs@oss.sgi.com Subject: Re: New RH+XFS kernels for testing (request) References: <1003421180.19596.11.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: > Hi all - > There are some new kernel RPMs available for testing at > ftp://oss.sgi.com/projects/xfs/download/testing/RH2.4.7-10/ > These are based on the 2.4.7-10 Red Hat kernel RPM from rawhide, rumored > to be the version that will ship with their next distro release. Big-time kudos to the SGI team! I truly appreciate your continue efforts and sing your praises everywhere I go (in addition to installing it everywhere I go). I have one suggestion though: Please consider releasing pre-built K7/Athlon binaries. RedHat includes the spec-file in the SRPM, and even pre-built ones on Rawhide. Athlon is far too popular to ignore nowdays IMHO. Again, just a suggestion. -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ---------------------------------------------------------------- The US National ID is an enhanced Social Security Number. It will give those who abuse it more information than ever before. And just like the SSN, they will ignore all the regulations. From owner-linux-xfs@oss.sgi.com Thu Oct 18 09:47:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9IGlmP00463 for linux-xfs-outgoing; Thu, 18 Oct 2001 09:47:48 -0700 Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9IGlhD00439 for ; Thu, 18 Oct 2001 09:47:43 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9IGmDau075967; Thu, 18 Oct 2001 18:48:18 +0200 (CEST) Message-Id: <4.3.2.7.2.20011018184333.0362ad98@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 18 Oct 2001 18:46:00 +0200 To: Eric Sandeen , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: New RH+XFS kernels for testing In-Reply-To: <1003421180.19596.11.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 11:06 18-10-2001 -0500, Eric Sandeen wrote: >Hi all - > >There are some new kernel RPMs available for testing at > >ftp://oss.sgi.com/projects/xfs/download/testing/RH2.4.7-10/ > >These are based on the 2.4.7-10 Red Hat kernel RPM from rawhide, rumored >to be the version that will ship with their next distro release. I have one day left before going off to spain for a week. I will give it my best shot. I have a headache which means I won't fudge with my homebox just for vacation (bad voodoo). >But if you'd like to help take a look at them, there they are! I will! Thank you. -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Thu Oct 18 09:50:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9IGoxU00605 for linux-xfs-outgoing; Thu, 18 Oct 2001 09:50:59 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9IGouD00582 for ; Thu, 18 Oct 2001 09:50:56 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9IGopW08215 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Thu, 18 Oct 2001 09:50:51 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id JAA09935 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Thu, 18 Oct 2001 09:50:47 -0700 (PDT) Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id SAA3572144 for ; Thu, 18 Oct 2001 18:49:16 +0200 (CEST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA3346121 for ; Thu, 18 Oct 2001 11:49:26 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id LAA17588 for ; Thu, 18 Oct 2001 11:49:26 -0500 (CDT) Subject: Re: New RH+XFS kernels for testing (request) From: Eric Sandeen Cc: linux-xfs@oss.sgi.com In-Reply-To: <3BCEFFFE.C14346C2@ieee.org> References: <1003421180.19596.11.camel@stout.americas.sgi.com> <3BCEFFFE.C14346C2@ieee.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 18 Oct 2001 11:48:32 -0500 Message-Id: <1003423712.19833.16.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I actually meant to build these... forgot to include the --target=athlon I'll toss them on OSS when they're done. -Eric On Thu, 2001-10-18 at 11:14, Bryan-TheBS-Smith wrote: > Please consider releasing pre-built K7/Athlon binaries. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Oct 18 09:54:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9IGsSi00806 for linux-xfs-outgoing; Thu, 18 Oct 2001 09:54:28 -0700 Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9IGsOD00783 for ; Thu, 18 Oct 2001 09:54:24 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9IGt1b1057731; Thu, 18 Oct 2001 18:55:02 +0200 (CEST) Message-Id: <4.3.2.7.2.20011018184607.0362a408@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 18 Oct 2001 18:52:52 +0200 To: Alan Eldridge , SGI XFS Dev List From: Seth Mos Subject: Re: Goodbye and thanks for all the fish In-Reply-To: <20011018112907.A7573@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 11:29 18-10-2001 -0400, Alan Eldridge wrote: >Gentlemen and Ladies, > >I bid you farewell for now. Partly due to the current Linus vs XFS >situation, the lack of any other viable journaling FS for Linux, and partly >due to outside factors, I am converting to the camp of the Daemon. Lucky bastard ;-) >Thanks for everything, especially all the good kernel bits I've been >running. I'll attempt to still fulfill my goal of producing daily XFS RPMS >and put them on Andy Kwong's site, once the new system has settled down. It might just happen that in a few months time redhat-7.2 gets out and there might just be a XFS supporting installer as well. But those are 2 "mights" already. I have production systems with XFS that are up to level with what I want so I am satisfied. Mandrake 8.1 is first "large" distribution that made it out with XFS as an installer option. SuSE has all the userland packages but lacks a kernel the installer knows more then one fs already. RedHat lacks both userland (although maintained by SGI) and the kernel (done by SGI) as well as a installer (Again done by SGI). >A special thanks to Eric, Steve, Russell, Seth, and Keith: you guys are >fantastic. *touched* Good luck in your new project. -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Thu Oct 18 09:55:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9IGtcw00893 for linux-xfs-outgoing; Thu, 18 Oct 2001 09:55:38 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9IGtYD00868 for ; Thu, 18 Oct 2001 09:55:34 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9IGtSW08663 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Thu, 18 Oct 2001 09:55:28 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id JAA02343 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Thu, 18 Oct 2001 09:55:17 -0700 (PDT) Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id SAA3542863 for ; Thu, 18 Oct 2001 18:53:46 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA3343926; Thu, 18 Oct 2001 11:53:55 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA04945; Thu, 18 Oct 2001 11:53:55 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9IGpHZ22171; Thu, 18 Oct 2001 11:51:17 -0500 Message-Id: <200110181651.f9IGpHZ22171@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Alan Eldridge cc: SGI XFS Dev List Subject: Re: Clarification before I get flamed too much In-Reply-To: Message from Alan Eldridge of "Thu, 18 Oct 2001 11:59:56 EDT." <20011018115956.C26033@wwweasel.geeksrus.net> Date: Thu, 18 Oct 2001 11:51:17 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Major factors for leaving are that a project I'm leading is using FreeBSD. > Until XFS becomes part of a distro I can't afford the time to maintain two > different OS boxes, especially when I have to build up kernels from CVS for > the Linux one. > > There. No FUD involved. Plain, pragmatic, business decision. In the previous > questions I was asking, the "manager" I wanted to know how to convince was me > . > > I think XFS is the salvation for the Linux FS needs, but I have to bow out > of development stuff right now. > > -- > Alan Eldridge > from std_disclaimer import * I knew there was a reason I kept out of threads for a while.... Alan, best of luck with FreeBSD, you might want to touch base with Russell Cattelan, I have heard mention he had been making progress on an XFS port to FreeBSD (then there was the NT port I heard about) what was it Linus said about world dominiation? OK, enough rumors for today ;-) Steve From owner-linux-xfs@oss.sgi.com Thu Oct 18 10:16:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9IHGax01455 for linux-xfs-outgoing; Thu, 18 Oct 2001 10:16:36 -0700 Received: from ned.crphq.org (fwuser@host194.crp.org [64.242.225.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9IHGXD01433 for ; Thu, 18 Oct 2001 10:16:33 -0700 Received: from W30-GX150 (64.242.225.217) by ned.crphq.org (Worldmail 1.3.167); 18 Oct 2001 13:16:30 -0400 Message-Id: <4.2.0.58.20011018131345.01edccd0@mail> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 18 Oct 2001 13:16:14 -0400 To: Eric Sandeen From: Ryan Casey Subject: Re: New RH+XFS kernels for testing Cc: linux-xfs@oss.sgi.com In-Reply-To: <1003421180.19596.11.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 11:06 AM 10/18/2001 -0500, Eric Sandeen wrote: >There are some new kernel RPMs available for testing at > >ftp://oss.sgi.com/projects/xfs/download/testing/RH2.4.7-10/ > >These are based on the 2.4.7-10 Red Hat kernel RPM from rawhide, rumored >to be the version that will ship with their next distro release. This came across on another list: ftp://linux-speakup.org/pub/linux/speakup/disks/redhat/7.2/ "This is a version especially patched with speakup, the GPL screen reader used by a lot of us screen access via synthetic speech types. But, it's still the same RH, and all anyone who doesn't have a speech synthesizer would need to do is to just say "no" to speech." If you grab the ISO, I imagine that you could at least confirm that you've gotten the correct kernel version. HTH, -Ryan Casey From owner-linux-xfs@oss.sgi.com Thu Oct 18 12:21:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9IJL1C03834 for linux-xfs-outgoing; Thu, 18 Oct 2001 12:21:01 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9IJKwD03812 for ; Thu, 18 Oct 2001 12:20:58 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA25400 for ; Thu, 18 Oct 2001 12:20:53 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA3331206; Thu, 18 Oct 2001 14:19:41 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA98129; Thu, 18 Oct 2001 14:19:40 -0500 (CDT) Subject: Error message when creating filesystems. From: Eric Sandeen To: jasher1@tampabay.rr.com Cc: linux-xfs@oss.sgi.com In-Reply-To: <200110181912.f9IJCvV03673@oss.sgi.com> References: <200110181912.f9IJCvV03673@oss.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 18 Oct 2001 14:18:46 -0500 Message-Id: <1003432726.19631.25.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Jesse - First off, please don't send HTML mail to the list. It's actually causing messages to bounce off the list, now. > #> mkfs -t xfs -d unwritten=0 /dev/sda1 > mkfs.xfs: warning - cannot set blocksize on block device /dev/sda1: > Invalid argument The short answer is to upgrade your xfsprogs, and all will be well. There used to be an added ioctl that mkfs used in the kernel, but it went away. your (old) mkfs is complaining that it can't find it - but it's not needed in any case. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Oct 18 14:09:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9IL9a906097 for linux-xfs-outgoing; Thu, 18 Oct 2001 14:09:36 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9IL9SD06075 for ; Thu, 18 Oct 2001 14:09:28 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9IL9MK11995 for ; Thu, 18 Oct 2001 14:09:22 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA3344587; Thu, 18 Oct 2001 16:08:05 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA51087; Thu, 18 Oct 2001 16:08:04 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9IL5Pn01679; Thu, 18 Oct 2001 16:05:25 -0500 Message-Id: <200110182105.f9IL5Pn01679@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Fang Han cc: linux-xfs@oss.sgi.com Subject: Re: [BUG]XFS at CONFIG_SCSI_MULTI_LUN In-Reply-To: Message from Fang Han of "Thu, 18 Oct 2001 17:32:11 +0800." <20011018173211.C1476@dfbbb.cn.mvd> Date: Thu, 18 Oct 2001 16:05:25 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hi, I find an very strange bug, And it is reproduce-able. > > I have an machine with Adaptec 7899p card, And two scsi harddisk on one > scsi ID. It means I need use CONFIG_SCSI_MULTI_LUN options on > kernel. My kernel is SGI_XFS_1.0.1, I just enable the options, And > recompile it using RedHat 7.1 default gcc-2.9.6-85. > > My scsi harddisk shows to be sda sdb > > When I run this script: > mkfs.xfs /dev/sdb1 > time mount -t xfs /dev/sdb1 /mnt > > I got this output > > real 0m9.340s > user 0m0.000s > sys 0m0.000s > > The mount speed is real slow. > Using ext2xfs > > mkfs /dev/sdb1 > time mount /dev/sdb1 /mnt > output is : > > real 0m0.392s > user 0m0.000s > sys 0m0.000s > > Using resiserfs also very fast. > > lvol1 can be from 500M - 10 G , And the result is same. > > In the same time I run > > mkfs.xfs /dev/sda5 > time mount -t xfs /dev/sda5 /mnt > > result is: > > real 0m0.523s > user 0m0.000s > sys 0m0.000s > > sda5 size is same with sdb1 > > So the question is very clear, mount an XFS on the MULTI_LUN scsi > device is very slow. Who know the reason? > > Dan > Well, first you have to explain what the MULTI_LUN thing does, because I have no idea. However, from XFS's point of view, a device is a device is a device - unless it is LVM. There are some differences there in terms of how we do disk I/O to the log. I would ask that you try a later kernel, there have been changes in all sorts of things since the 1.0.1 release, there is every chance it is fixed by some other kernel change. If not, there is probably not a lot we can do about it, the disk I/O involved in mount is pretty fixed (a binary chop scan of the log blocks looking for the head and tail of the log). Steve From owner-linux-xfs@oss.sgi.com Thu Oct 18 14:10:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ILAqa06234 for linux-xfs-outgoing; Thu, 18 Oct 2001 14:10:52 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ILAiD06193 for ; Thu, 18 Oct 2001 14:10:44 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9ILAdK12109 for ; Thu, 18 Oct 2001 14:10:39 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA3340266; Thu, 18 Oct 2001 16:09:23 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA01189; Thu, 18 Oct 2001 16:09:23 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9IL6iZ01691; Thu, 18 Oct 2001 16:06:44 -0500 Message-Id: <200110182106.f9IL6iZ01691@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Matteo Centonza cc: lord@sgi.com, linux-xfs@oss.sgi.com Subject: Re: NFS and xfsdump oops In-Reply-To: Message from Matteo Centonza of "Thu, 18 Oct 2001 09:58:50 +0200." Date: Thu, 18 Oct 2001 16:06:44 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hi Steve, > > looking over LK, i've found an interesting thread i'm concerned > with (NFS related Oops in 2.4.[39]-xfs). > > Last weekend our main file server oopsed during the weekly run of > amanda (doing xfsdump): > > embeh [09:39am] (0.12) ~> uname -a > Linux embeh.sif.it 2.4.9-xfs-1 #1 Tue Aug 28 11:18:44 CEST 2001 i686 > > compiled with kgcc. > > That's the oops: > > Oct 13 00:50:38 embeh kernel: Unable to handle kernel NULL pointer > dereference at virtual add > Oct 13 00:50:38 embeh kernel: 00000000 > Oct 13 00:50:38 embeh kernel: *pde = 00000000 > Oct 13 00:50:38 embeh kernel: Oops: 0000 > Oct 13 00:50:38 embeh kernel: CPU: 0 > Oct 13 00:50:38 embeh kernel: EIP: 0010:[agp_frontend_cleanup+0/96] > Oct 13 00:50:38 embeh kernel: EIP: 0010:[<00000000>] > Using defaults from ksymoops -t elf32-i386 -a i386 > Oct 13 00:50:38 embeh kernel: EFLAGS: 00010286 > Oct 13 00:50:38 embeh kernel: eax: 00000000 ebx: de666540 ecx: > de666f1c edx: c04c6700 > Oct 13 00:50:38 embeh kernel: esi: de666ec0 edi: de666540 ebp: > de666540 esp: ddcfbe58 > Oct 13 00:50:38 embeh kernel: ds: 0018 es: 0018 ss: 0018 > Oct 13 00:50:38 embeh kernel: Process nfsd (pid: 734, stackpage=ddcfb000) > Oct 13 00:50:38 embeh kernel: Stack: c0187284 d42b8cc0 de666ec0 00000002 > decf3c00 c0187696 de > 666540 00000002 > Oct 13 00:50:38 embeh kernel: ddd06400 ddd06804 ddd49800 00000000 > decf3de8 ddd06400 c0 > 1879d2 decf3c00 > Oct 13 00:50:38 embeh kernel: ddd06814 00000002 00000001 00000001 > 00000007 00000007 cc > ffad28 ddd06400 > Oct 13 00:50:38 embeh kernel: Call Trace: [nfsd_findparent+52/224] > [find_fh_dentry+534/816] [ > Oct 13 00:50:38 embeh kernel: Call Trace: [] [] > [] [] > [] > Oct 13 00:50:38 embeh kernel: [] [] [] > [] [ Oct 13 00:50:38 embeh kernel: Code: Bad EIP value. > > >>EIP; 00000000 Before first symbol > Trace; c0187284 > Trace; c0187696 > Trace; c01879d2 > Trace; c0188332 > Trace; c010ec49 > Trace; c018e34e > Trace; c0190130 > Trace; c0185863 > Trace; c0329328 > > > Athlon 1.33 Ghz, LVM over RAID5, userland and kernel from CVS as of > 2001-08-28, xfsdump-1.1.3-0 > > hope this helps, I have had a kernel pounding away with heavy nfs client access and repeated level zero dumps ongoing in parallel. So far it is all working just fine. I will leave it overnight and see if I cannot catch something. Steve > > -m > From owner-linux-xfs@oss.sgi.com Thu Oct 18 14:17:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ILHAt06521 for linux-xfs-outgoing; Thu, 18 Oct 2001 14:17:10 -0700 Received: from chef.cc.absoval.com (cpe-66-1-218-101.fl.sprintbbd.net [66.1.218.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ILH7D06498 for ; Thu, 18 Oct 2001 14:17:07 -0700 Received: from ieee.org (IDENT:bs@thebs.cc.absoval.com [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id RAA23732; Thu, 18 Oct 2001 17:17:00 -0400 Message-ID: <3BCF46D0.57E6510@ieee.org> Date: Thu, 18 Oct 2001 17:17:04 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts/AbsoluteValueSystems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Shipping kernel package on RedHat 7.2 is 2.4.7-10 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Independent confirmation (at least as much as you can trust ZD). Let's get testing that pre-release!!! -- TheBS -------- Original Message -------- From: Timothy_Dyck@ziffdavis.com To: Bryan-TheBS-Smith I can confirm the shipping kernel package on RedHat 7.2 is kernel-2.4.7-10. From owner-linux-xfs@oss.sgi.com Thu Oct 18 14:22:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ILMfB06703 for linux-xfs-outgoing; Thu, 18 Oct 2001 14:22:41 -0700 Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ILMcD06681 for ; Thu, 18 Oct 2001 14:22:38 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9ILNUNd021158; Thu, 18 Oct 2001 23:23:30 +0200 (CEST) Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id XAA10026; Thu, 18 Oct 2001 23:22:32 +0200 (CEST) Message-Id: <4.3.2.7.2.20011018231950.03683530@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 18 Oct 2001 23:21:05 +0200 To: Bryan-TheBS-Smith , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Shipping kernel package on RedHat 7.2 is 2.4.7-10 In-Reply-To: <3BCF46D0.57E6510@ieee.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 17:17 18-10-2001 -0400, Bryan-TheBS-Smith wrote: >Independent confirmation (at least as much as you can trust ZD). I also have a positive from Gunnar who got to see the final version on a course he went to. >Let's get testing that pre-release!!! Tomorrow for me. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Thu Oct 18 15:08:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9IM84V07486 for linux-xfs-outgoing; Thu, 18 Oct 2001 15:08:04 -0700 Received: from pipt.oz.cc.utah.edu (jdr1529@pipt.oz.cc.utah.edu [155.99.2.7]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9IM82D07464 for ; Thu, 18 Oct 2001 15:08:02 -0700 Received: from localhost (jdr1529@localhost) by pipt.oz.cc.utah.edu (8.9.2/8.9.2) with ESMTP id QAA09972; Thu, 18 Oct 2001 16:07:39 -0600 (MDT) Date: Thu, 18 Oct 2001 16:07:38 -0600 (MDT) From: james rich To: Federico Sevilla III cc: Linux XFS Mailing List Subject: Re: Preemptible Kernel In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 18 Oct 2001, Federico Sevilla III wrote: > I wonder: would it be too much to ask that Robert Love's preemptible > patches be incorporated into the XFS kernel already? I've been reading Please no. Let's get xfs into linus' tree first. Let the xfs project concentrate on xfs and only xfs. There already exist projects to include every project possible into the kernel. James Rich From owner-linux-xfs@oss.sgi.com Thu Oct 18 16:40:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9INeGc09161 for linux-xfs-outgoing; Thu, 18 Oct 2001 16:40:16 -0700 Received: from antares.cedar.buffalo.edu (antares.cedar.Buffalo.EDU [128.205.33.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9INeCD09136 for ; Thu, 18 Oct 2001 16:40:12 -0700 Received: (qmail 18932 invoked from network); 18 Oct 2001 23:40:12 -0000 Received: from mekbuda.cedar.buffalo.edu (HELO cedar.buffalo.edu) (128.205.33.210) by antares.cedar.buffalo.edu with SMTP; 18 Oct 2001 23:40:12 -0000 Received: (from ajay@localhost) by cedar.buffalo.edu (8.11.2/8.11.2) id f9INdAB09720 for linux-xfs@oss.sgi.com; Thu, 18 Oct 2001 19:39:10 -0400 Date: Thu, 18 Oct 2001 19:39:10 -0400 From: Ajay Shekhawat To: linux-xfs@oss.sgi.com Subject: Re: xfsrestore assertion failure Message-ID: <20011018193910.A9199@mekbuda.cedar.Buffalo.EDU> References: <3B698AEA.5A40D3D6@lehigh.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B698AEA.5A40D3D6@lehigh.edu>; from sgr0@lehigh.edu on Thu, Aug 02, 2001 at 01:16:26PM -0400 Organization: Center for Document Analysis and Recognition X-OfficePhone: +1 (716)-645-6164 ext. 101 X-Fax-Number: +1 (716)-645-6176 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Aug 02, 2001 at 01:16:26PM -0400, Steve Roseman wrote: > > xfsrestore: seeking past media file directory dump > > xfsrestore: drive_scsitape.c:1461: do_next_mark: Assertion > > `rechdrp->first_mark_offset - rechdrp->file_offset <= ( off64_t ) > > ( contextp->dc_recsz )' failed. > > Aborted (core dumped) > > The following fix seems to resolve the problem. xfsrestore -t works, at > least. (I'll try a real restore later.) I suspect the problem is in > endian-converting first_mark_offset, maybe when it contains the value > -1. We just encountered this assertion failure, in xfsdump v1.1.6. Steve's fix does fix the problem and the restore proceeds, but I'm wondering if the patch breaks other things. If not, should the patch be in the official xfsdump distribution? Ajay From owner-linux-xfs@oss.sgi.com Thu Oct 18 19:19:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9J2J9812700 for linux-xfs-outgoing; Thu, 18 Oct 2001 19:19:09 -0700 Received: from mx.linux.net.cn ([210.52.24.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9J2J3D12675 for ; Thu, 18 Oct 2001 19:19:04 -0700 Received: from dfbbb.cn.mvd (unknown [211.99.247.66]) by mx.linux.net.cn (Postfix) with ESMTP id 315066BB for ; Fri, 19 Oct 2001 10:19:12 +0800 (CST) Received: (from dfbb@localhost) by dfbbb.cn.mvd (8.11.2/8.11.2) id f9J2LsL03104 for linux-xfs@oss.sgi.com; Fri, 19 Oct 2001 10:21:54 +0800 Date: Fri, 19 Oct 2001 10:21:54 +0800 From: Fang Han To: linux-xfs@oss.sgi.com Subject: Re: [BUG]XFS at CONFIG_SCSI_MULTI_LUN Message-ID: <20011019102153.A2825@dfbbb.cn.mvd> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20011018173211.C1476@dfbbb.cn.mvd> <4.3.2.7.2.20011018114511.03712c38@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20011018114511.03712c38@pop.xs4all.nl>; from knuffie@xs4all.nl on Thu, Oct 18, 2001 at 12:01:41PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Oct 18, 2001 at 12:01:41PM +0200, Seth Mos wrote: > At 17:32 18-10-2001 +0800, Fang Han wrote: > >Hi, I find an very strange bug, And it is reproduce-able. > > > >I have an machine with Adaptec 7899p card, And two scsi harddisk on one > >scsi ID. It means I need use CONFIG_SCSI_MULTI_LUN options on > >kernel. My kernel is SGI_XFS_1.0.1, I just enable the options, And > >recompile it using RedHat 7.1 default gcc-2.9.6-85. > > Can you recompile with gcc-2.91.66 (kgcc) > After recompile with kgcc, The mount cause kernel oops. And complain "XFS: fail to read root inode" > >My scsi harddisk shows to be sda sdb > > > >When I run this script: > >mkfs.xfs /dev/sdb1 > >time mount -t xfs /dev/sdb1 /mnt > > > >I got this output > > > >real 0m9.340s > >user 0m0.000s > >sys 0m0.000s > > Is the read an write speed also very slow? > > Why do you want two harddisks on one scsi ID perse? > > >So the question is very clear, mount an XFS on the MULTI_LUN scsi > >device is very slow. Who know the reason? > > > >Dan > > -- > Seth > Every program has two purposes one for which > it was written and another for which it wasn't > I use the last kind. > From owner-linux-xfs@oss.sgi.com Thu Oct 18 19:22:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9J2M2312836 for linux-xfs-outgoing; Thu, 18 Oct 2001 19:22:02 -0700 Received: from mx.linux.net.cn ([210.52.24.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9J2LvD12814 for ; Thu, 18 Oct 2001 19:21:58 -0700 Received: from dfbbb.cn.mvd (unknown [211.99.247.66]) by mx.linux.net.cn (Postfix) with ESMTP id 31EC46BB for ; Fri, 19 Oct 2001 10:22:07 +0800 (CST) Received: (from dfbb@localhost) by dfbbb.cn.mvd (8.11.2/8.11.2) id f9J2Ons03223 for linux-xfs@oss.sgi.com; Fri, 19 Oct 2001 10:24:49 +0800 Date: Fri, 19 Oct 2001 10:24:49 +0800 From: Fang Han To: linux-xfs@oss.sgi.com Subject: Re: [BUG]XFS at CONFIG_SCSI_MULTI_LUN Message-ID: <20011019102449.B2825@dfbbb.cn.mvd> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200110182105.f9IL5Pn01679@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200110182105.f9IL5Pn01679@jen.americas.sgi.com>; from lord@sgi.com on Thu, Oct 18, 2001 at 04:05:25PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > Well, first you have to explain what the MULTI_LUN thing does, because I > have no idea. However, from XFS's point of view, a device is a device > is a device - unless it is LVM. There are some differences there in > terms of how we do disk I/O to the log. >From kernel help "If you have a SCSI device that supports more than one LUN (Logical Unit Number), e.g. a CD jukebox, and only one LUN is detected, you can say Y here to force the SCSI driver to probe for multiple LUNs. A SCSI device with multiple LUNs acts logically like multiple SCSI devices. The vast majority of SCSI devices have only one LUN, and so most people can say N here and should in fact do so, because it is safer. " MULTI_LUN is using to probe multi device on one scsi channel. > > I would ask that you try a later kernel, there have been changes in > all sorts of things since the 1.0.1 release, there is every chance it > is fixed by some other kernel change. If not, there is probably not a > lot we can do about it, the disk I/O involved in mount is pretty > fixed (a binary chop scan of the log blocks looking for the head and > tail of the log). I will test it an report it later. > > Steve > > > > From owner-linux-xfs@oss.sgi.com Thu Oct 18 20:16:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9J3G1O13838 for linux-xfs-outgoing; Thu, 18 Oct 2001 20:16:01 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9J3FvD13815 for ; Thu, 18 Oct 2001 20:15:57 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA05934 for ; Thu, 18 Oct 2001 20:15:08 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id NAA07880; Fri, 19 Oct 2001 13:15:51 +1000 Date: Fri, 19 Oct 2001 13:15:51 +1000 From: Keith Owens Message-Id: <200110190315.NAA07880@sherman.melbourne.sgi.com> Subject: TAKE - Remove debugging variables from Makefiles Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk When kbuild_2_4_nostdinc was added, some debugging statements were left in the Makefiles. Remove them. Date: Thu Oct 18 20:13:04 PDT 2001 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:105073a linux/fs/Makefile - 1.38 linux/Makefile - 1.140 From owner-linux-xfs@oss.sgi.com Thu Oct 18 20:58:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9J3wHn14430 for linux-xfs-outgoing; Thu, 18 Oct 2001 20:58:17 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9J3w2D14408 for ; Thu, 18 Oct 2001 20:58:02 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9J3vuW19307 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Thu, 18 Oct 2001 20:57:56 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id FAA3612363 for ; Fri, 19 Oct 2001 05:56:20 +0200 (CEST) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id NAA16051; Fri, 19 Oct 2001 13:57:52 +1000 Date: Fri, 19 Oct 2001 13:57:52 +1000 From: Keith Owens Message-Id: <200110190357.NAA16051@sherman.melbourne.sgi.com> Subject: TAKE - Upgrade XFS to 2.4.13-pre4 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Upgrade XFS to 2.4.13-pre4. NOTE: This compiles but has not been QAd. Use with caution. Date: Thu Oct 18 20:53:48 PDT 2001 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:105074a linux/Documentation/video4linux/bttv/README.quirks - 1.1 linux/Documentation/video4linux/bttv/Tuners - 1.1 linux/Documentation/video4linux/bttv/Cards - 1.1 linux/net/socket.c - 1.26 linux/net/ipv6/tcp_ipv6.c - 1.28 linux/net/ipv4/udp.c - 1.26 linux/net/ipv4/tcp_ipv4.c - 1.36 linux/net/ipv4/syncookies.c - 1.11 linux/net/ipv4/route.c - 1.27 linux/net/ipv4/ip_output.c - 1.28 linux/mm/vmscan.c - 1.81 linux/mm/swap.c - 1.15 linux/mm/page_alloc.c - 1.60 linux/mm/filemap.c - 1.93 linux/kernel/sched.c - 1.43 linux/kernel/ksyms.c - 1.114 linux/ipc/shm.c - 1.50 linux/include/net/route.h - 1.13 linux/include/linux/swap.h - 1.44 linux/include/asm-sparc64/hardirq.h - 1.13 linux/include/asm-sparc64/cache.h - 1.4 linux/include/asm-i386/unistd.h - 1.18 linux/include/asm-i386/system.h - 1.21 linux/fs/nfsd/nfsxdr.c - 1.12 linux/fs/nfsd/nfssvc.c - 1.16 linux/fs/nfsd/nfsproc.c - 1.18 linux/fs/namei.c - 1.41 linux/fs/hfs/catalog.c - 1.5 linux/fs/buffer.c - 1.87 linux/drivers/usb/uhci.h - 1.25 linux/drivers/usb/uhci.c - 1.52 linux/drivers/usb/Config.in - 1.48 linux/drivers/scsi/sym53c8xx.c - 1.28 linux/drivers/scsi/sd.c - 1.48 linux/drivers/scsi/scsi.c - 1.41 linux/drivers/sbus/char/zs.c - 1.18 linux/drivers/sbus/char/su.c - 1.18 linux/drivers/sbus/char/sab82532.c - 1.22 linux/drivers/net/sunqe.c - 1.18 linux/drivers/net/smc9194.c - 1.17 linux/drivers/net/smc-mca.c - 1.14 linux/drivers/net/sk_g16.c - 1.14 linux/drivers/net/seeq8005.c - 1.14 linux/drivers/net/ne2.c - 1.16 linux/drivers/net/mace.c - 1.15 linux/drivers/net/hydra.c - 1.14 linux/drivers/net/hplance.c - 1.10 linux/drivers/net/fmv18x.c - 1.16 linux/drivers/net/bmac.c - 1.16 linux/drivers/net/atarilance.c - 1.10 linux/drivers/net/atari_pamsnet.c - 1.11 linux/drivers/net/atari_bionet.c - 1.11 linux/drivers/net/a2065.c - 1.14 linux/drivers/block/loop.c - 1.39 linux/drivers/block/genhd.c - 1.20 linux/arch/sparc64/kernel/setup.c - 1.22 linux/arch/sparc64/kernel/rtrap.S - 1.9 linux/arch/sparc64/kernel/entry.S - 1.16 linux/arch/sparc64/kernel/dtlb_base.S - 1.11 linux/arch/sparc64/Makefile - 1.13 linux/arch/ppc/8xx_io/fec.c - 1.16 linux/arch/ppc/8xx_io/enet.c - 1.16 linux/arch/i386/kernel/ldt.c - 1.10 linux/arch/i386/kernel/entry.S - 1.41 linux/arch/i386/defconfig - 1.76 linux/Makefile - 1.141 linux/MAINTAINERS - 1.77 linux/Documentation/Configure.help - 1.109 linux/CREDITS - 1.63 linux/drivers/sbus/char/aurora.c - 1.13 linux/drivers/net/sk_mca.c - 1.13 linux/drivers/net/bagetlance.c - 1.11 linux/drivers/net/mvme147.c - 1.8 linux/drivers/net/macsonic.c - 1.10 linux/Documentation/README.DAC960 - 1.4 linux/drivers/block/DAC960.h - 1.10 linux/drivers/block/DAC960.c - 1.37 linux/drivers/net/sun3lance.c - 1.10 linux/fs/udf/udfdecl.h - 1.16 linux/arch/ppc/kernel/m8xx_setup.c - 1.18 linux/include/linux/pci_ids.h - 1.49 linux/Documentation/video4linux/bttv/Sound-FAQ - 1.8 linux/Documentation/video4linux/bttv/CARDLIST - 1.12 linux/Documentation/video4linux/bttv/Insmod-options - 1.11 linux/Documentation/usb/error-codes.txt - 1.4 linux/drivers/net/oaknet.c - 1.8 linux/drivers/ieee1394/ieee1394_core.c - 1.16 linux/drivers/ieee1394/ieee1394_types.h - 1.10 linux/drivers/ieee1394/ieee1394.h - 1.3 linux/drivers/ieee1394/Makefile - 1.9 linux/drivers/usb/usb-uhci.c - 1.32 linux/drivers/net/mac89x0.c - 1.8 linux/drivers/net/gmac.c - 1.11 linux/drivers/net/tulip/tulip_core.c - 1.32 linux/drivers/net/tulip/interrupt.c - 1.13 linux/drivers/net/ioc3-eth.c - 1.15 linux/drivers/net/pcmcia/xircom_tulip_cb.c - 1.16 linux/arch/i386/kernel/pci-irq.c - 1.17 linux/drivers/net/stnic.c - 1.8 linux/drivers/net/ibmlana.c - 1.6 linux/include/asm-sparc/highmem.h - 1.4 linux/drivers/media/video/tvmixer.c - 1.6 linux/drivers/media/video/tuner.h - 1.6 linux/drivers/media/video/tuner.c - 1.8 linux/drivers/media/video/tda9875.c - 1.7 linux/drivers/media/video/tda7432.c - 1.8 linux/drivers/media/video/msp3400.c - 1.9 linux/drivers/media/video/bttv.h - 1.10 linux/drivers/media/video/bttv-if.c - 1.5 linux/drivers/media/video/bttv-driver.c - 1.14 linux/drivers/media/video/bttv-cards.c - 1.10 linux/drivers/md/raid1.c - 1.14 linux/drivers/md/raid5.c - 1.20 linux/drivers/md/md.c - 1.29 linux/drivers/net/isa-skeleton.c - 1.6 linux/drivers/usb/pegasus.h - 1.5 linux/drivers/media/video/tvaudio.h - 1.2 linux/drivers/media/video/tvaudio.c - 1.8 linux/drivers/media/video/id.h - 1.2 linux/drivers/media/video/bttvp.h - 1.6 linux/include/linux/ethtool.h - 1.6 linux/drivers/net/lasi_82596.c - 1.7 linux/drivers/usb/serial/Config.in - 1.10 linux/mm/shmem.c - 1.19 linux/drivers/net/pci-skeleton.c - 1.8 linux/drivers/net/saa9730.c - 1.4 linux/drivers/net/gt96100eth.c - 1.3 linux/drivers/net/fealnx.c - 1.6 linux/drivers/net/wireless/airport.c - 1.5 linux/Documentation/usb/philips.txt - 1.4 linux/drivers/usb/pwc.h - 1.6 linux/drivers/usb/pwc-ioctl.h - 1.3 linux/drivers/usb/pwc-if.c - 1.6 linux/drivers/usb/pwc-ctrl.c - 1.5 linux/drivers/acpi/include/platform/acgcc.h - 1.4 linux/drivers/ieee1394/sbp2.c - 1.5 linux/drivers/ieee1394/sbp2.h - 1.4 linux/drivers/ieee1394/nodemgr.c - 1.7 linux/drivers/char/drm/drm_vm.h - 1.4 linux/drivers/sound/btaudio.c - 1.5 linux/fs/namespace.c - 1.5 linux/drivers/usb/ultracam.c - 1.2 From owner-linux-xfs@oss.sgi.com Thu Oct 18 21:14:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9J4Ee514797 for linux-xfs-outgoing; Thu, 18 Oct 2001 21:14:40 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9J4EbD14772 for ; Thu, 18 Oct 2001 21:14:37 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9J4EVW20011 for ; Thu, 18 Oct 2001 21:14:32 -0700 Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id OAA22853; Fri, 19 Oct 2001 14:14:27 +1000 Date: Fri, 19 Oct 2001 14:14:27 +1000 From: Keith Owens Message-Id: <200110190414.OAA22853@sherman.melbourne.sgi.com> Subject: TAKE - Upgrade XFS to 2.4.13-pre5 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Upgrade XFS to 2.4.13-pre5. NOTE: This compiles but has not been QAd. Use with caution. Date: Thu Oct 18 21:12:13 PDT 2001 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:105075a linux/mm/vmscan.c - 1.82 linux/mm/page_alloc.c - 1.61 linux/fs/buffer.c - 1.88 linux/drivers/usb/uhci.h - 1.26 linux/drivers/usb/uhci.c - 1.53 linux/Makefile - 1.142 linux/drivers/char/joystick/analog.c - 1.6 linux/drivers/usb/usbnet.c - 1.3 From owner-linux-xfs@oss.sgi.com Thu Oct 18 21:33:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9J4XCM15253 for linux-xfs-outgoing; Thu, 18 Oct 2001 21:33:12 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9J4X9D15229 for ; Thu, 18 Oct 2001 21:33:09 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9J4X2K23818 for ; Thu, 18 Oct 2001 21:33:03 -0700 Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id OAA23201; Fri, 19 Oct 2001 14:32:56 +1000 Date: Fri, 19 Oct 2001 14:32:56 +1000 From: Keith Owens Message-Id: <200110190432.OAA23201@sherman.melbourne.sgi.com> Subject: TAKE - Correct extra cflags for xfsidbg.o Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk EXTRA_CFLAGS and CFLAGS_foo.o must come before Rules.make, otherwise the two pass variable evaluation used by make can yield inconsistent results. Roll on kbuild 2.5, that's all I can say :). Date: Thu Oct 18 21:29:19 PDT 2001 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:105076a linux/fs/xfs/Makefile - 1.126 From owner-linux-xfs@oss.sgi.com Thu Oct 18 21:35:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9J4Zl115412 for linux-xfs-outgoing; Thu, 18 Oct 2001 21:35:47 -0700 Received: from gk.hm.epigenomics.net (qmailr@gk.hm.epigenomics.net [212.121.137.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9J4ZgD15386 for ; Thu, 18 Oct 2001 21:35:42 -0700 Received: (qmail 27896 invoked from network); 19 Oct 2001 04:35:41 -0000 Received: from raman.epigenomics.epi (qmailr@192.168.2.2) by salam.epigenomics.epi with SMTP; 19 Oct 2001 04:35:41 -0000 Received: (qmail 17108 invoked by uid 515); 19 Oct 2001 04:35:40 -0000 Date: Fri, 19 Oct 2001 06:35:40 +0200 From: Robert Sander To: Nathan Scott Cc: linux-xfs@oss.sgi.com, Michael Meskes Subject: Re: reenabling quota after xfs_repair Message-ID: <20011019063540.A16377@epigenomics.com> References: <200110171613.f9HGDhW17816@jen.americas.sgi.com> <20011018112928.B522717@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20011018112928.B522717@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.3.22i X-Operating-System: Linux raman 2.4.8-mdk-xfs-ngroups-kgcc Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Oct 18, 2001 at 11:29:28AM +1100, Nathan Scott wrote: > Are you using Debian? The versioning scheme used there > is a bit different - 3.00pre01-15 is fairly recent, but > not quite the same as 3.01-final from sourceforge. I've > forwarded Michael's explanation of his numbering scheme, > below. I have successfully used the 3.00pre01-15 Debian > package with XFS for quite some time now. Me too. And then I did run xfs_repair on that filesystem. xfs_repair did not rport anything about quotas, they just went away. So I did several things. First I got the newest quotatools from sourceforge. Did not matter (really!). Then I umounted the filesystem, deleted "usrquota" from /etc/fstab and mounted it again: no quotas, that's ok. Then I umounted the filesystem again, put "usrquota" back into /etc/fstab, mounted the filesystem, /var/log/kern.log says: Oct 19 06:14:25 raman kernel: Start mounting filesystem: sd(8,17) Oct 19 06:14:25 raman kernel: Ending clean XFS mount for filesystem: sd(8,17) Oct 19 06:14:25 raman kernel: XFS quotacheck sd(8,17): Please wait. Oct 19 06:15:01 raman kernel: XFS quotacheck sd(8,17): Done. I thought: "yes", but: raman:/usr/src/quota-tools# mount |grep quota /dev/sdb1 on /mnt/raid/0 type xfs (rw,usrquota) raman:/usr/src/quota-tools# ./edquota gurubert No filesystems with quota detected. raman:/usr/src/quota-tools# ./edquota -V Quota utilities version 3.01. Compiled with RPC and EXT2_DIRECT Bugs to mvw@planets.elm.net, jack@suse.cz hm... -- Robert Sander Computer Scientist Epigenomics AG Bioinformatics R&D www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Thu Oct 18 22:35:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9J5Z7l16371 for linux-xfs-outgoing; Thu, 18 Oct 2001 22:35:07 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9J5YwD16349 for ; Thu, 18 Oct 2001 22:34:58 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id WAA03022 for ; Thu, 18 Oct 2001 22:33:21 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) 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 PAA01718; Fri, 19 Oct 2001 15:33:35 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA21033; Fri, 19 Oct 2001 16:33:34 +1100 (AEDT) Date: Fri, 19 Oct 2001 16:33:34 +1100 From: Nathan Scott To: Robert Sander Cc: linux-xfs@oss.sgi.com Subject: Re: reenabling quota after xfs_repair Message-ID: <20011019163334.E457588@wobbly.melbourne.sgi.com> References: <200110171613.f9HGDhW17816@jen.americas.sgi.com> <20011018112928.B522717@wobbly.melbourne.sgi.com> <20011019063540.A16377@epigenomics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011019063540.A16377@epigenomics.com>; from robert.sander@epigenomics.com on Fri, Oct 19, 2001 at 06:35:40AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Robert, On Fri, Oct 19, 2001 at 06:35:40AM +0200, Robert Sander wrote: > On Thu, Oct 18, 2001 at 11:29:28AM +1100, Nathan Scott wrote: > > Are you using Debian? The versioning scheme used there > > is a bit different - 3.00pre01-15 is fairly recent, but > > not quite the same as 3.01-final from sourceforge. I've > > forwarded Michael's explanation of his numbering scheme, > > below. I have successfully used the 3.00pre01-15 Debian > > package with XFS for quite some time now. > > Me too. And then I did run xfs_repair on that filesystem. > xfs_repair did not rport anything about quotas, they just > went away. > So I did several things. > First I got the newest quotatools from sourceforge. Did not > matter (really!). OK, so we can cross that off the list of potential problems. Good to know. > Then I umounted the filesystem, deleted "usrquota" from /etc/fstab > and mounted it again: no quotas, that's ok. > Then I umounted the filesystem again, put "usrquota" back into > /etc/fstab, mounted the filesystem, /var/log/kern.log says: > > Oct 19 06:14:25 raman kernel: Start mounting filesystem: sd(8,17) > Oct 19 06:14:25 raman kernel: Ending clean XFS mount for filesystem: sd(8,17) > Oct 19 06:14:25 raman kernel: XFS quotacheck sd(8,17): Please wait. > Oct 19 06:15:01 raman kernel: XFS quotacheck sd(8,17): Done. > That's looking really good. So we definately have a kernel with XFS quota enabled.. good, good. > I thought: "yes", but: > > raman:/usr/src/quota-tools# mount |grep quota > /dev/sdb1 on /mnt/raid/0 type xfs (rw,usrquota) > raman:/usr/src/quota-tools# ./edquota gurubert > No filesystems with quota detected. OK - so a quick sanity test on my system suggests that there isn't something fundamentally wrong in the current user tools (edquota works fine for me). I see Michael's new quota package is now in unstable ... apt-get ... yup, this works fine too (thanks for the quick packaging work, Michael). So, the way the quota tools work for XFS is to issue a system call (quotactl) which asks XFS for the quota status for the specified filesystem. edquota asks this for all mounted XFS filesystems, and then stitches together a table of quota info from all filesystems for the given user or group. The error message you're seeing suggests no filesystems are claiming to support quota at all. We could be seeing a problem with the system call getting into XFS (this would be a kernel problem) - has happened before with some incorrect patches and one of our initial releases was even botched this way actually. Which kernel version are you using (CVS?, a release kernel?, patch? - which patch)? One way for you to test out this theory is to: # cd cmd/xfstests # make ... # ls -l src/feature -rwxr-xr-x 1 fsgqa ptg 77758 Oct 16 01:34 src/feature # src/feature -Uv /dev/hda8 # echo $? 0 # src/feature -Uv /dev/hda9 quota type (1) not available # echo $? 1 # So, on my system /dev/hda9 does not hold a filesystem with quota enabled, but /dev/hda8 does. How does that look for the devices which you expect to hold filesystems with quota enabled? (esp. for /dev/sdb1). If "feature" fails, then it seems we are not getting into XFS for your kernel & we'd need to investigate why exactly... if this is the case, could you mail me the fs/dquot.c file and fs/quota.c (if there is one) from your currently running kernel? thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Oct 18 23:01:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9J61BI16903 for linux-xfs-outgoing; Thu, 18 Oct 2001 23:01:11 -0700 Received: from gk.hm.epigenomics.net (qmailr@gk.hm.epigenomics.net [212.121.137.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9J616D16880 for ; Thu, 18 Oct 2001 23:01:06 -0700 Received: (qmail 28366 invoked from network); 19 Oct 2001 06:01:08 -0000 Received: from raman.epigenomics.epi (qmailr@192.168.2.2) by salam.epigenomics.epi with SMTP; 19 Oct 2001 06:01:08 -0000 Received: (qmail 1463 invoked by uid 515); 19 Oct 2001 06:01:04 -0000 Date: Fri, 19 Oct 2001 08:01:04 +0200 From: Robert Sander To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: reenabling quota after xfs_repair Message-ID: <20011019080104.A31567@epigenomics.com> References: <200110171613.f9HGDhW17816@jen.americas.sgi.com> <20011018112928.B522717@wobbly.melbourne.sgi.com> <20011019063540.A16377@epigenomics.com> <20011019163334.E457588@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20011019163334.E457588@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.3.22i X-Operating-System: Linux raman 2.4.8-mdk-xfs-ngroups-kgcc Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Oct 19, 2001 at 04:33:34PM +1100, Nathan Scott wrote: > We could be seeing a problem with the system call getting into > XFS (this would be a kernel problem) - has happened before with > some incorrect patches and one of our initial releases was even > botched this way actually. Which kernel version are you using > (CVS?, a release kernel?, patch? - which patch)? Currently I am using the Mandrake 2.4.8 kernel from http://iserv.nl/files/xfs/ compiled with gcc 2.91.66 perl:/mnt/raid/1/src/cvs/linux-2.4-xfs/cmd/xfstests# ls -l src/feature -rwxr-xr-x 1 root root 76230 Oct 19 07:54 src/feature* raman:~# /tmp/feature -Uv /dev/sdb1 quotactl: Invalid argument raman:~# echo $? 1 raman:~# mount | grep dev/sdb1 /dev/sdb1 on /mnt/raid/0 type xfs (rw,usrquota) raman:~# /tmp/feature -Uv /dev/sdb2 quotactl: Invalid argument raman:~# echo $? 1 raman:~# mount | grep dev/sdb2 /dev/sdb2 on /mnt/raid/1 type xfs (rw) perl is the host were I compile everything on (4x SMP ;-) and then I copied feature over to raman. > If "feature" fails, then it seems we are not getting into XFS for > your kernel & we'd need to investigate why exactly... if this is > the case, could you mail me the fs/dquot.c file and fs/quota.c (if > there is one) from your currently running kernel? I'll send them to you by private email. Greetings -- Robert Sander Computer Scientist Epigenomics AG Bioinformatics R&D www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Thu Oct 18 23:16:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9J6GWE17316 for linux-xfs-outgoing; Thu, 18 Oct 2001 23:16:32 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9J6GSD17294 for ; Thu, 18 Oct 2001 23:16:28 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id XAA09261 for ; Thu, 18 Oct 2001 23:16:22 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) 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 QAA01939; Fri, 19 Oct 2001 16:15:09 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA28658; Fri, 19 Oct 2001 17:15:08 +1100 (AEDT) Date: Fri, 19 Oct 2001 17:15:08 +1100 From: Nathan Scott To: Robert Sander , Chmouel Boudjnah Cc: linux-xfs@oss.sgi.com Subject: Re: reenabling quota after xfs_repair Message-ID: <20011019171508.F457588@wobbly.melbourne.sgi.com> References: <200110171613.f9HGDhW17816@jen.americas.sgi.com> <20011018112928.B522717@wobbly.melbourne.sgi.com> <20011019063540.A16377@epigenomics.com> <20011019163334.E457588@wobbly.melbourne.sgi.com> <20011019080104.A31567@epigenomics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011019080104.A31567@epigenomics.com>; from robert.sander@epigenomics.com on Fri, Oct 19, 2001 at 08:01:04AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Robert, On Fri, Oct 19, 2001 at 08:01:04AM +0200, Robert Sander wrote: > On Fri, Oct 19, 2001 at 04:33:34PM +1100, Nathan Scott wrote: > > We could be seeing a problem with the system call getting into > > XFS (this would be a kernel problem) - has happened before with > > some incorrect patches and one of our initial releases was even > > botched this way actually. Which kernel version are you using > > (CVS?, a release kernel?, patch? - which patch)? > Yup, its the exact same problem - fs/dquot.c has been merged incorrectly. So close, but one subtle issue was missed. > Currently I am using the Mandrake 2.4.8 kernel from > http://iserv.nl/files/xfs/ compiled with gcc 2.91.66 > > I'll send them to you by private email. > Thanks for that. Hopefully the Mandrake folk can pick up this fix before their final release. The patch to the fs/dquot.c you sent me is below. Many thanks for reporting this! cheers. -- Nathan --- dquot.c.orig Fri Oct 19 16:06:13 2001 +++ dquot.c Fri Oct 19 16:06:45 2001 @@ -2012,7 +2012,7 @@ type = cmd & SUBCMDMASK; - if ((uint) type >= MAXQUOTAS || cmds > 0x1100 || cmds < 0x100 || cmds == 0x0300 || + if ((uint) type >= MAXQUOTAS || cmds < 0x100 || cmds == 0x0300 || cmds == 0x0400 || cmds == 0x0500 || cmds == 0x1000) goto out; From owner-linux-xfs@oss.sgi.com Thu Oct 18 23:43:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9J6h5K17919 for linux-xfs-outgoing; Thu, 18 Oct 2001 23:43:05 -0700 Received: from gk.hm.epigenomics.net (qmailr@gk.hm.epigenomics.net [212.121.137.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9J6h1D17897 for ; Thu, 18 Oct 2001 23:43:02 -0700 Received: (qmail 28575 invoked from network); 19 Oct 2001 06:43:03 -0000 Received: from raman.epigenomics.epi (qmailr@192.168.2.2) by salam.epigenomics.epi with SMTP; 19 Oct 2001 06:43:03 -0000 Received: (qmail 16566 invoked by uid 515); 19 Oct 2001 06:42:59 -0000 Date: Fri, 19 Oct 2001 08:42:59 +0200 From: Robert Sander To: Nathan Scott Cc: Chmouel Boudjnah , linux-xfs@oss.sgi.com Subject: Re: reenabling quota after xfs_repair Message-ID: <20011019084259.A15965@epigenomics.com> References: <200110171613.f9HGDhW17816@jen.americas.sgi.com> <20011018112928.B522717@wobbly.melbourne.sgi.com> <20011019063540.A16377@epigenomics.com> <20011019163334.E457588@wobbly.melbourne.sgi.com> <20011019080104.A31567@epigenomics.com> <20011019171508.F457588@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20011019171508.F457588@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.3.22i X-Operating-System: Linux raman 2.4.8-mdk-xfs-ngroups-kgcc Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Oct 19, 2001 at 05:15:08PM +1100, Nathan Scott wrote: > > Thanks for that. Hopefully the Mandrake folk can pick up this > fix before their final release. The patch to the fs/dquot.c > you sent me is below. Ah, see, I was a bit confused. I tried 5-6 different kernels the last days and blamed the disappearance of quota info to xfs_repair, but it was the kernel. Hm, so I need to reboot the machine once again. Apart from the quota issue this kernel runs surprisingly stable. Greetings -- Robert Sander Computer Scientist Epigenomics AG Bioinformatics R&D www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Fri Oct 19 00:10:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9J7Abe18644 for linux-xfs-outgoing; Fri, 19 Oct 2001 00:10:37 -0700 Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9J7AYD18622 for ; Fri, 19 Oct 2001 00:10:34 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9J7BWNe063344 for ; Fri, 19 Oct 2001 09:11:32 +0200 (CEST) Message-Id: <4.3.2.7.2.20011019090632.02b83680@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 19 Oct 2001 09:09:02 +0200 To: linux-xfs@oss.sgi.com From: Seth Mos Subject: Redhat kernel errata Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk It is true. They just released packages of 2.4.9 kernels. These are errata for 7.1 I have no idea of what they are gonna do with the 7.2 cds that probably already went to mastering. Btw. During the 7.1 release they had the exact same problem and they had 2 errata updates already waiting for anyone that downloaded the ISO or bought the package. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Fri Oct 19 00:31:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9J7V3519122 for linux-xfs-outgoing; Fri, 19 Oct 2001 00:31:03 -0700 Received: from linux.nameip.net ([211.187.6.46]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9J7UxD19098 for ; Fri, 19 Oct 2001 00:31:00 -0700 Received: (qmail 1373 invoked from network); 19 Oct 2001 07:34:56 -0000 Received: from unknown (HELO orgio.net) (211.187.6.46) by 0 with SMTP; 19 Oct 2001 07:34:56 -0000 Message-ID: <3BCFD7A0.3060000@orgio.net> Date: Fri, 19 Oct 2001 16:34:56 +0900 From: Seung-young Oh User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011017 X-Accept-Language: ko MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: kernel update for RH7.1 users? Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, RedHat released kernel updates for RedHat7.1; http://www.redhat.com/support/errata/RHSA-2001-129.html any guide, news, or info for users of RedHat7.1+SGI XFS 1.0.1? -- ICQ#: 103231199 From owner-linux-xfs@oss.sgi.com Fri Oct 19 03:32:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JAWvA23433 for linux-xfs-outgoing; Fri, 19 Oct 2001 03:32:57 -0700 Received: from mail.cc.kuleuven.ac.be (mail.cc.kuleuven.ac.be [134.58.10.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JAWrD23411 for ; Fri, 19 Oct 2001 03:32:54 -0700 Received: from pclab.cc.kuleuven.ac.be (pc-10-33-6-229.cc.kuleuven.ac.be [10.33.6.229]) by mail.cc.kuleuven.ac.be (8.9.3/8.9.0) with ESMTP id MAA426506 for ; Fri, 19 Oct 2001 12:32:51 +0200 Message-Id: <5.1.0.14.2.20011019122919.00a43810@pb429905.kuleuven.be> X-Sender: pb429905@pb429905.kuleuven.be X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 19 Oct 2001 12:32:47 +0200 To: linux-xfs@oss.sgi.com From: werner maes Subject: Re: kernel update for RH7.1 users? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I have the same question. When will there be kernel-2.4.9-6 (new redhat kernel for 7.1) and XFS 1.0.1? Or does anybody intend to make them? I'll give it a try (if I find some time). Werner From owner-linux-xfs@oss.sgi.com Fri Oct 19 04:18:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JBIpP24513 for linux-xfs-outgoing; Fri, 19 Oct 2001 04:18:51 -0700 Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JBIlD24490 for ; Fri, 19 Oct 2001 04:18:47 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9JBJkNe038183; Fri, 19 Oct 2001 13:19:46 +0200 (CEST) Message-Id: <4.3.2.7.2.20011019131608.036e3708@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 19 Oct 2001 13:17:14 +0200 To: werner maes , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: kernel update for RH7.1 users? In-Reply-To: <5.1.0.14.2.20011019122919.00a43810@pb429905.kuleuven.be> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 12:32 19-10-2001 +0200, werner maes wrote: >Hello, > >I have the same question. When will there be kernel-2.4.9-6 (new redhat >kernel for 7.1) and XFS 1.0.1? >Or does anybody intend to make them? I think they will make them but the work that was done on the 2.4.7 kernel is probably lost. This will mean it will cost them a bit more time and it needs to be tested. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Fri Oct 19 05:59:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JCxjo26281 for linux-xfs-outgoing; Fri, 19 Oct 2001 05:59:45 -0700 Received: from hazard.jcu.cz (hazard.jcu.cz [160.217.1.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JCwTD26247 for ; Fri, 19 Oct 2001 05:58:29 -0700 Received: (qmail 11305 invoked by uid 1000); 19 Oct 2001 12:57:41 -0000 Date: Fri, 19 Oct 2001 14:57:41 +0200 From: Jan Marek To: linux-xfs@oss.sgi.com Subject: Problem with compilation of your CVS linux-2.4-xfs Message-ID: <20011019145741.D8996@hazard.jcu.cz> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline User-Agent: Mutt/1.3.23i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hallo, I have had problem with compilation your CVS linux-2.4-xfs kernel in the current release in CVS... System is Debian in the sid (unstable) release... I attach my .config file... BTW: directory drivers/i2o/ is in you CVS missing??? If you will need any information, please, send me e-mail... Tahnk you for help... Sincerely Jan Marek -- Ing. Jan Marek University of South Bohemia Academic Computer Centre Phone: +420-38-7772080 --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=".config" # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # 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_MPENTIUMIII=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 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_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_TOSHIBA is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_SMP is not set CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y # # General setup # CONFIG_NET=y 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_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # CONFIG_PCMCIA=m CONFIG_CARDBUS=y CONFIG_I82365=y CONFIG_TCIC=y CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m CONFIG_PM=y CONFIG_ACPI=y # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_BUSMGR=m # CONFIG_ACPI_SYS is not set # CONFIG_ACPI_CPU is not set # CONFIG_ACPI_BUTTON is not set # CONFIG_ACPI_AC is not set # CONFIG_ACPI_EC is not set # CONFIG_ACPI_CMBATT is not set # CONFIG_ACPI_THERMAL is not set CONFIG_APM=m # CONFIG_APM_IGNORE_USER_SUSPEND is not set CONFIG_APM_DO_ENABLE=y CONFIG_APM_CPU_IDLE=y CONFIG_APM_DISPLAY_BLANK=y CONFIG_APM_RTC_IS_GMT=y # CONFIG_APM_ALLOW_INTS is not set # CONFIG_APM_REAL_MODE_POWER_OFF is not set # # 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=m CONFIG_PARPORT_PC_FIFO=y CONFIG_PARPORT_PC_SUPERIO=y # CONFIG_PARPORT_PC_PCMCIA is not set # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_SUNBPP is not set # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play configuration # CONFIG_PNP=y CONFIG_ISAPNP=y CONFIG_PNPBIOS=y # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # 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_LOOP=m # CONFIG_BLK_DEV_NBD is not set CONFIG_BLK_DEV_RAM=m CONFIG_BLK_DEV_RAM_SIZE=4096 # CONFIG_BLK_DEV_INITRD is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set # CONFIG_MD_RAID1 is not set # CONFIG_MD_RAID5 is not set # CONFIG_MD_MULTIPATH is not set # CONFIG_BLK_DEV_LVM is not set # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_NETLINK=y CONFIG_RTNETLINK=y # CONFIG_NETLINK_DEV is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set # CONFIG_FILTER is not set CONFIG_UNIX=m CONFIG_INET=y CONFIG_IP_MULTICAST=y # 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_IP_MROUTE is not set # CONFIG_ARPD is not set # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_FTP=m # CONFIG_IP_NF_QUEUE is not set CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_LIMIT=m CONFIG_IP_NF_MATCH_MAC=m CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_TCPMSS=m CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_UNCLEAN=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_MIRROR=m CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_NAT_FTP=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_MARK=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_TCPMSS=m # CONFIG_IP_NF_COMPAT_IPCHAINS is not set # CONFIG_IP_NF_COMPAT_IPFWADM is not set # CONFIG_IPV6 is not set # CONFIG_KHTTPD is not set # CONFIG_ATM is not set # # # # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_LLC 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 # # Telephony Support # # CONFIG_PHONE is not set # CONFIG_PHONE_IXJ is not set # CONFIG_PHONE_IXJ_PCMCIA is not set # # ATA/IDE/MFM/RLL 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=y # CONFIG_BLK_DEV_IDEDISK_VENDOR is not set # CONFIG_BLK_DEV_IDEDISK_FUJITSU is not set # CONFIG_BLK_DEV_IDEDISK_IBM is not set # CONFIG_BLK_DEV_IDEDISK_MAXTOR is not set # CONFIG_BLK_DEV_IDEDISK_QUANTUM is not set # CONFIG_BLK_DEV_IDEDISK_SEAGATE is not set # CONFIG_BLK_DEV_IDEDISK_WD is not set # CONFIG_BLK_DEV_COMMERIAL is not set # CONFIG_BLK_DEV_TIVO is not set CONFIG_BLK_DEV_IDECS=m CONFIG_BLK_DEV_IDECD=m # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set # # IDE chipset support/bugfixes # # CONFIG_BLK_DEV_CMD640 is not set # CONFIG_BLK_DEV_CMD640_ENHANCED is not set # CONFIG_BLK_DEV_ISAPNP is not set # CONFIG_BLK_DEV_RZ1000 is not set CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_IDEDMA_PCI=y CONFIG_BLK_DEV_ADMA=y # CONFIG_BLK_DEV_OFFBOARD is not set CONFIG_IDEDMA_PCI_AUTO=y CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_PCI_WIP is not set # CONFIG_IDEDMA_NEW_DRIVE_LISTINGS is not set # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_AEC62XX_TUNING is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_WDC_ALI15X3 is not set # CONFIG_BLK_DEV_AMD74XX is not set # CONFIG_AMD74XX_OVERRIDE is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_HPT34X_AUTODMA is not set # CONFIG_BLK_DEV_HPT366 is not set CONFIG_BLK_DEV_PIIX=y CONFIG_PIIX_TUNING=y # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_PDC202XX is not set # CONFIG_PDC202XX_BURST is not set # CONFIG_PDC202XX_FORCE is not set # CONFIG_BLK_DEV_SVWKS 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_IDE_CHIPSETS is not set CONFIG_IDEDMA_AUTO=y # CONFIG_IDEDMA_IVB is not set # CONFIG_DMA_NONPCI is not set CONFIG_BLK_DEV_IDE_MODES=y # CONFIG_BLK_DEV_ATARAID is not set # CONFIG_BLK_DEV_ATARAID_PDC is not set # CONFIG_BLK_DEV_ATARAID_HPT is not set # # SCSI support # # CONFIG_SCSI is not set # # Fusion MPT device support # # CONFIG_FUSION is not set # CONFIG_FUSION_BOOT is not set # CONFIG_FUSION_ISENSE is not set # CONFIG_FUSION_CTL is not set # CONFIG_FUSION_LAN is not set # # IEEE 1394 (FireWire) support (EXPERIMENTAL) # # CONFIG_IEEE1394 is not set # # I2O device support # CONFIG_I2O=m CONFIG_I2O_PCI=m CONFIG_I2O_BLOCK=m CONFIG_I2O_LAN=m # CONFIG_I2O_SCSI is not set CONFIG_I2O_PROC=m # # Network device support # 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 # CONFIG_NET_SB1000 is not set # # Ethernet (10 or 100Mbit) # # CONFIG_NET_ETHERNET is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_MYRI_SBUS is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_SK98LIN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PLIP is not set # CONFIG_PPP is not set # CONFIG_SLIP is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Token Ring devices # # CONFIG_TR is not set # 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=y # CONFIG_PCMCIA_3C589 is not set # CONFIG_PCMCIA_3C574 is not set # CONFIG_PCMCIA_FMVJ18X is not set CONFIG_PCMCIA_PCNET=m # CONFIG_PCMCIA_NMCLAN is not set # CONFIG_PCMCIA_SMC91C92 is not set # CONFIG_PCMCIA_XIRC2PS is not set # CONFIG_ARCNET_COM20020_CS is not set # CONFIG_PCMCIA_IBMTR is not set # CONFIG_PCMCIA_XIRCOM is not set # CONFIG_PCMCIA_XIRTULIP is not set # CONFIG_NET_PCMCIA_RADIO is not set # # Amateur Radio support # # CONFIG_HAMRADIO is not set # # IrDA (infrared) support # CONFIG_IRDA=y # # IrDA protocols # # CONFIG_IRLAN is not set # CONFIG_IRNET is not set CONFIG_IRCOMM=m CONFIG_IRDA_ULTRA=y CONFIG_IRDA_OPTIONS=y # # 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 CONFIG_IRPORT_SIR=m # # Dongle support # # CONFIG_DONGLE is not set # # FIR device drivers # # CONFIG_USB_IRDA is not set CONFIG_NSC_FIR=m CONFIG_WINBOND_FIR=m CONFIG_TOSHIBA_FIR=m CONFIG_SMC_IRCC_FIR=m CONFIG_ALI_FIR=m CONFIG_VLSI_FIR=m # # ISDN subsystem # # CONFIG_ISDN is not set # # Old CD-ROM drivers (not SCSI, not IDE) # # CONFIG_CD_NO_IDESCSI is not set # # Input core support # # CONFIG_INPUT is not set # CONFIG_INPUT_KEYBDEV is not set # CONFIG_INPUT_MOUSEDEV is not set # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_EVDEV is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_SERIAL=y # CONFIG_SERIAL_CONSOLE is not set # CONFIG_SERIAL_EXTENDED is not set # CONFIG_SERIAL_NONSTANDARD is not set CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 CONFIG_PRINTER=m # CONFIG_LP_CONSOLE is not set # CONFIG_PPDEV is not set # # I2C support # # CONFIG_I2C is not set # # Mice # # CONFIG_BUSMOUSE is not set CONFIG_MOUSE=y CONFIG_PSMOUSE=y # CONFIG_82C710_MOUSE is not set # CONFIG_PC110_PAD is not set # # Joysticks # # CONFIG_INPUT_GAMEPORT is not set # # Input core support is needed for gameports # # # Input core support is needed for joysticks # # CONFIG_QIC02_TAPE is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set # CONFIG_INTEL_RNG is not set # CONFIG_NVRAM is not set # CONFIG_RTC is not set # 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=y CONFIG_AGP_INTEL=y # CONFIG_AGP_I810 is not set # 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_DRM=y # CONFIG_DRM_TDFX is not set # CONFIG_DRM_GAMMA is not set CONFIG_DRM_R128=m CONFIG_DRM_RADEON=m # CONFIG_DRM_I810 is not set # CONFIG_DRM_MGA is not set # # PCMCIA character devices # # CONFIG_PCMCIA_SERIAL_CS is not set # CONFIG_MWAVE is not set # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # # File systems # CONFIG_QUOTA=y # CONFIG_FS_POSIX_ACL is not set # CONFIG_AUTOFS_FS is not set CONFIG_AUTOFS4_FS=y # CONFIG_REISERFS_FS is not set # CONFIG_REISERFS_CHECK is not set # CONFIG_ADFS_FS is not set # CONFIG_ADFS_FS_RW is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_BFS_FS is not set CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m # CONFIG_UMSDOS_FS is not set CONFIG_VFAT_FS=m # CONFIG_EFS_FS is not set # CONFIG_JFFS_FS is not set # CONFIG_JFFS2_FS is not set # CONFIG_CRAMFS is not set CONFIG_TMPFS=y # CONFIG_RAMFS is not set CONFIG_ISO9660_FS=m CONFIG_JOLIET=y # CONFIG_MINIX_FS is not set # CONFIG_VXFS_FS is not set # CONFIG_NTFS_FS is not set # CONFIG_NTFS_RW is not set # CONFIG_HPFS_FS is not set CONFIG_PROC_FS=y # CONFIG_DEVFS_FS is not set # CONFIG_DEVFS_MOUNT is not set # CONFIG_DEVFS_DEBUG is not set CONFIG_DEVPTS_FS=y # CONFIG_QNX4FS_FS is not set # CONFIG_QNX4FS_RW is not set # CONFIG_ROMFS_FS is not set CONFIG_EXT2_FS=y # CONFIG_SYSV_FS is not set # CONFIG_UDF_FS is not set # CONFIG_UDF_RW is not set # CONFIG_UFS_FS is not set # CONFIG_UFS_FS_WRITE is not set CONFIG_PAGE_BUF=y CONFIG_XFS_FS=y # CONFIG_XFS_RT is not set CONFIG_HAVE_ATTRCTL=y # CONFIG_XFS_DMAPI is not set CONFIG_XFS_QUOTA=y # # Network File Systems # # CONFIG_CODA_FS is not set # CONFIG_NFS_FS is not set # CONFIG_NFS_V3 is not set # CONFIG_ROOT_NFS is not set # CONFIG_NFSD is not set # CONFIG_NFSD_V3 is not set # CONFIG_SUNRPC is not set # CONFIG_LOCKD is not set # CONFIG_SMB_FS is not set # CONFIG_NCP_FS is not set # CONFIG_NCPFS_PACKET_SIGNING is not set # CONFIG_NCPFS_IOCTL_LOCKING is not set # CONFIG_NCPFS_STRONG is not set # CONFIG_NCPFS_NFS_NS is not set # CONFIG_NCPFS_OS2_NS is not set # CONFIG_NCPFS_SMALLDOS is not set # CONFIG_NCPFS_NLS is not set # CONFIG_NCPFS_EXTRAS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y # CONFIG_SMB_NLS is not set CONFIG_NLS=y # # Native Language Support # CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_CODEPAGE_437=m # 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=m # 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_1251 is not set CONFIG_NLS_ISO8859_1=m CONFIG_NLS_ISO8859_2=m # 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=m # # Console drivers # CONFIG_VGA_CONSOLE=y # CONFIG_VIDEO_SELECT is not set # CONFIG_MDA_CONSOLE is not set # # Frame-buffer support # # CONFIG_FB is not set # # Sound # CONFIG_SOUND=m # CONFIG_SOUND_BT878 is not set # CONFIG_SOUND_CMPCI is not set # CONFIG_SOUND_EMU10K1 is not set # CONFIG_MIDI_EMU10K1 is not set # CONFIG_SOUND_FUSION is not set # CONFIG_SOUND_CS4281 is not set # CONFIG_SOUND_ES1370 is not set # CONFIG_SOUND_ES1371 is not set # CONFIG_SOUND_ESSSOLO1 is not set # CONFIG_SOUND_MAESTRO is not set # CONFIG_SOUND_MAESTRO3 is not set # CONFIG_SOUND_ICH is not set # CONFIG_SOUND_RME96XX is not set # CONFIG_SOUND_SONICVIBES is not set # CONFIG_SOUND_TRIDENT is not set # CONFIG_SOUND_MSNDCLAS is not set # CONFIG_SOUND_MSNDPIN is not set # CONFIG_SOUND_VIA82CXXX is not set # CONFIG_MIDI_VIA82CXXX is not set # CONFIG_SOUND_OSS is not set # CONFIG_SOUND_TVMIXER is not set # # USB support # # CONFIG_USB is not set # # USB Controllers # # CONFIG_USB_UHCI is not set # CONFIG_USB_UHCI_ALT is not set # CONFIG_USB_OHCI is not set # # USB Device Class drivers # # CONFIG_USB_AUDIO is not set # CONFIG_USB_BLUETOOTH is not set # CONFIG_USB_STORAGE is not set # CONFIG_USB_STORAGE_DEBUG is not set # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set # CONFIG_USB_STORAGE_DPCM is not set # CONFIG_USB_STORAGE_HP8200e is not set # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set # CONFIG_USB_ACM is not set # CONFIG_USB_PRINTER is not set # # USB Human Interface Devices (HID) # # # Input core support is needed for USB HID # # # USB Imaging devices # # CONFIG_USB_DC2XX is not set # 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 # # # Video4Linux support is needed for USB Multimedia device support # # # USB Network adaptors # # CONFIG_USB_PEGASUS is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_CATC is not set # CONFIG_USB_CDCETHER 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 # CONFIG_USB_SERIAL_GENERIC is not set # CONFIG_USB_SERIAL_BELKIN is not set # CONFIG_USB_SERIAL_WHITEHEAT is not set # CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set # CONFIG_USB_SERIAL_EMPEG is not set # CONFIG_USB_SERIAL_FTDI_SIO is not set # CONFIG_USB_SERIAL_VISOR is not set # CONFIG_USB_SERIAL_IR is not set # CONFIG_USB_SERIAL_EDGEPORT is not set # CONFIG_USB_SERIAL_KEYSPAN_PDA is not set # CONFIG_USB_SERIAL_KEYSPAN is not set # CONFIG_USB_SERIAL_KEYSPAN_USA28 is not set # CONFIG_USB_SERIAL_KEYSPAN_USA28X is not set # CONFIG_USB_SERIAL_KEYSPAN_USA28XA is not set # CONFIG_USB_SERIAL_KEYSPAN_USA28XB is not set # CONFIG_USB_SERIAL_KEYSPAN_USA19 is not set # CONFIG_USB_SERIAL_KEYSPAN_USA18X is not set # CONFIG_USB_SERIAL_KEYSPAN_USA19W is not set # CONFIG_USB_SERIAL_KEYSPAN_USA49W is not set # CONFIG_USB_SERIAL_MCT_U232 is not set # CONFIG_USB_SERIAL_PL2303 is not set # CONFIG_USB_SERIAL_CYBERJACK is not set # CONFIG_USB_SERIAL_XIRCOM is not set # CONFIG_USB_SERIAL_OMNINET is not set # # USB Miscellaneous drivers # # CONFIG_USB_RIO500 is not set # # Bluetooth support # # CONFIG_BLUEZ is not set # # Kernel hacking # CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_SLAB is not set # CONFIG_DEBUG_IOVIRT is not set CONFIG_MAGIC_SYSRQ=y # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_BUGVERBOSE is not set # CONFIG_KDB is not set # CONFIG_KDB_MODULES is not set # CONFIG_KALLSYMS is not set # CONFIG_FRAME_POINTER is not set --fdj2RfSjLxBAspz7-- From owner-linux-xfs@oss.sgi.com Fri Oct 19 07:32:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JEWNi28473 for linux-xfs-outgoing; Fri, 19 Oct 2001 07:32:23 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JEWJD28451 for ; Fri, 19 Oct 2001 07:32:19 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9JEWDW27138 for ; Fri, 19 Oct 2001 07:32:13 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA3349590; Fri, 19 Oct 2001 09:30:57 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA19806; Fri, 19 Oct 2001 09:30:57 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9JESB910464; Fri, 19 Oct 2001 09:28:11 -0500 Message-Id: <200110191428.f9JESB910464@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Jan Marek cc: linux-xfs@oss.sgi.com Subject: Re: Problem with compilation of your CVS linux-2.4-xfs In-Reply-To: Message from Jan Marek of "Fri, 19 Oct 2001 14:57:41 +0200." <20011019145741.D8996@hazard.jcu.cz> Date: Fri, 19 Oct 2001 09:28:11 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > --fdj2RfSjLxBAspz7 > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > Hallo, > > I have had problem with compilation your CVS linux-2.4-xfs kernel > in the current release in CVS... > > System is Debian in the sid (unstable) release... > > I attach my .config file... > > BTW: directory drivers/i2o/ is in you CVS missing??? i20 is on the move - this is part of an on going merge from Alan Cox's tree to Linus's tree. i20 may be broken in Linus's tree due to this merge right now. It moved to drivers/message/i2o. Steve From owner-linux-xfs@oss.sgi.com Fri Oct 19 07:36:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JEaWk28744 for linux-xfs-outgoing; Fri, 19 Oct 2001 07:36:32 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JEaTD28722 for ; Fri, 19 Oct 2001 07:36:29 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9JEaOW27629 for ; Fri, 19 Oct 2001 07:36:24 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA3345027; Fri, 19 Oct 2001 09:35:08 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA67617; Fri, 19 Oct 2001 09:35:07 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9JEWLt10484; Fri, 19 Oct 2001 09:32:21 -0500 Message-Id: <200110191432.f9JEWLt10484@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Seth Mos cc: werner maes , linux-xfs@oss.sgi.com Subject: Re: kernel update for RH7.1 users? In-Reply-To: Message from Seth Mos of "Fri, 19 Oct 2001 13:17:14 +0200." <4.3.2.7.2.20011019131608.036e3708@pop.xs4all.nl> Date: Fri, 19 Oct 2001 09:32:21 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > At 12:32 19-10-2001 +0200, werner maes wrote: > >Hello, > > > >I have the same question. When will there be kernel-2.4.9-6 (new redhat > >kernel for 7.1) and XFS 1.0.1? > >Or does anybody intend to make them? > > I think they will make them but the work that was done on the 2.4.7 kernel > is probably lost. This will mean it will cost them a bit more time and it > needs to be tested. It is all a cunning ploy by Redhat, they always sneak things up on us. Given that this is a security update I suspect there will be an update to 7.2 when it comes out - but to what I don't know. If you are worried about security then you could download a later patch from our ftp site and build your own kernel until we have something in a more packaged form - 2.4.10 should do it. Steve From owner-linux-xfs@oss.sgi.com Fri Oct 19 07:39:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JEdRi28915 for linux-xfs-outgoing; Fri, 19 Oct 2001 07:39:27 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JEdND28882 for ; Fri, 19 Oct 2001 07:39:23 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9JEdIK05248 for ; Fri, 19 Oct 2001 07:39:18 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA3352754; Fri, 19 Oct 2001 09:38:02 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA78496; Fri, 19 Oct 2001 09:38:01 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9JEZF510505; Fri, 19 Oct 2001 09:35:15 -0500 Message-Id: <200110191435.f9JEZF510505@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Fang Han cc: linux-xfs@oss.sgi.com Subject: Re: [BUG]XFS at CONFIG_SCSI_MULTI_LUN In-Reply-To: Message from Fang Han of "Fri, 19 Oct 2001 10:21:54 +0800." <20011019102153.A2825@dfbbb.cn.mvd> Date: Fri, 19 Oct 2001 09:35:15 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Thu, Oct 18, 2001 at 12:01:41PM +0200, Seth Mos wrote: > > At 17:32 18-10-2001 +0800, Fang Han wrote: > > >Hi, I find an very strange bug, And it is reproduce-able. > > > > > >I have an machine with Adaptec 7899p card, And two scsi harddisk on one > > >scsi ID. It means I need use CONFIG_SCSI_MULTI_LUN options on > > >kernel. My kernel is SGI_XFS_1.0.1, I just enable the options, And > > >recompile it using RedHat 7.1 default gcc-2.9.6-85. > > > > Can you recompile with gcc-2.91.66 (kgcc) > > > > After recompile with kgcc, The mount cause kernel oops. > > And complain "XFS: fail to read root inode" OK, something else is very wrong here - there is no reason this compiler should not work. Did you do a complete kernel rebuild, you must if you switch between redhat and other compilers. Steve From owner-linux-xfs@oss.sgi.com Fri Oct 19 07:41:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JEf3e29044 for linux-xfs-outgoing; Fri, 19 Oct 2001 07:41:03 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JEf0D29021 for ; Fri, 19 Oct 2001 07:41:00 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9JEetK05358 for ; Fri, 19 Oct 2001 07:40:55 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA3348350; Fri, 19 Oct 2001 09:39:38 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA63006; Fri, 19 Oct 2001 09:39:38 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9JEaqC10516; Fri, 19 Oct 2001 09:36:52 -0500 Message-Id: <200110191436.f9JEaqC10516@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Fang Han cc: linux-xfs@oss.sgi.com Subject: Re: [BUG]XFS at CONFIG_SCSI_MULTI_LUN In-Reply-To: Message from Fang Han of "Fri, 19 Oct 2001 10:24:49 +0800." <20011019102449.B2825@dfbbb.cn.mvd> Date: Fri, 19 Oct 2001 09:36:52 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > > > Well, first you have to explain what the MULTI_LUN thing does, because I > > have no idea. However, from XFS's point of view, a device is a device > > is a device - unless it is LVM. There are some differences there in > > terms of how we do disk I/O to the log. > > > >From kernel help > "If you have a SCSI device that supports more than one LUN (Logical > Unit Number), e.g. a CD jukebox, and only one LUN is detected, you > can say Y here to force the SCSI driver to probe for multiple LUNs. > A SCSI device with multiple LUNs acts logically like multiple SCSI > devices. The vast majority of SCSI devices have only one LUN, and > so most people can say N here and should in fact do so, because it > is safer. " > > MULTI_LUN is using to probe multi device on one scsi channel. Ah, OK, so this is a total red herring then because there is nothing special about the devices themselves, or how they are accessed once you find them. Can you describe the exact configuration of the volume you are making the filesystem on when you get the slow performance. Steve From owner-linux-xfs@oss.sgi.com Fri Oct 19 07:53:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JEroh29423 for linux-xfs-outgoing; Fri, 19 Oct 2001 07:53:50 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JErlD29398 for ; Fri, 19 Oct 2001 07:53:47 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9JErgW29496 for ; Fri, 19 Oct 2001 07:53:42 -0700 Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA19366; Fri, 19 Oct 2001 07:53:10 -0700 (PDT) Message-ID: <3BD03D84.9C7E0311@sgi.com> Date: Fri, 19 Oct 2001 09:49:40 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: Seung-young Oh CC: linux-xfs@oss.sgi.com Subject: Re: kernel update for RH7.1 users? References: <3BCFD7A0.3060000@orgio.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Grr... so 7.1 now has a 2.4.9 kernel, but the upcoming release (7.2?) only has 2.4.7? *sigh* I try to keep up... -Eric Seung-young Oh wrote: > > Hello, > RedHat released kernel updates for RedHat7.1; > > http://www.redhat.com/support/errata/RHSA-2001-129.html > > any guide, news, or info for users of RedHat7.1+SGI XFS 1.0.1? > > -- > ICQ#: 103231199 -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Oct 19 08:17:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JFH1C30280 for linux-xfs-outgoing; Fri, 19 Oct 2001 08:17:01 -0700 Received: from trillium-hollow.org (IDENT:root@trillium-hollow.org [209.180.166.89]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JFGuD30258 for ; Fri, 19 Oct 2001 08:16:56 -0700 Received: from erich (helo=trillium) by trillium-hollow.org with local-esmtp (Exim 3.20 #1) id 15ubOC-00009D-00; Fri, 19 Oct 2001 08:16:48 -0700 To: Steve Lord , Seth Mos cc: werner maes , linux-xfs@oss.sgi.com Subject: Re: kernel update for RH7.1 users? In-Reply-To: Your message of "Fri, 19 Oct 2001 09:32:21 CDT." <200110191432.f9JEWLt10484@jen.americas.sgi.com> Date: Fri, 19 Oct 2001 08:16:47 -0700 From: erich@uruk.org Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: > It is all a cunning ploy by Redhat, they always sneak things up on us. > Given that this is a security update I suspect there will be an update > to 7.2 when it comes out - but to what I don't know. > > If you are worried about security then you could download a later patch > from our ftp site and build your own kernel until we have something in > a more packaged form - 2.4.10 should do it. Uhh, I would be very careful about using any Linus kernel in the 2.4.10 - 2.4.12 range. That was right in the middle of the radical VM changes that went in, and several things were broken (HIGHMEM was certainly broken in many of those kernels, for example). I still worry about some things being broken, since there seems rather sloppy testing going on before each kernel is put out, and other things always slip in after something is known to work. (can you tell I disapprove?) I've been trying to find a newer than 2.4.6-ish kernel to settle on (2.4.7 would be ok, the redhat patch you guys have seems interesting!), and some of the XFS snapshots have had leaks, and just by running a kernel compile loop (make clean ; make bzImage) for a few days I could eat up much of the available memory on my 768MB machine. On the other hand, the recent XFS CVS of 2.4.13-pre3 seems both to work fine through several days of testing (I have no machine big enough to test HIGHMEM, though I have SMP) and several build issues were resolved for various modules... the common complaint about the i2o move and other things seem resolved. I was going to try out 2.4.13-pre5 today. BTW, is the patched new RH kernel based on 1.0.1, or some XFS "snapshot"? -- Erich Stefan Boleyn http://www.uruk.org/ "Reality is truly stranger than fiction; Probably why fiction is so popular" From owner-linux-xfs@oss.sgi.com Fri Oct 19 08:29:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JFTnC30744 for linux-xfs-outgoing; Fri, 19 Oct 2001 08:29:49 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JFTgD30722 for ; Fri, 19 Oct 2001 08:29:42 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9JFTbW00681 for ; Fri, 19 Oct 2001 08:29:37 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA3138118; Fri, 19 Oct 2001 10:28:21 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA60464; Fri, 19 Oct 2001 10:28:20 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9JFPX911794; Fri, 19 Oct 2001 10:25:33 -0500 Message-Id: <200110191525.f9JFPX911794@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: erich@uruk.org cc: Steve Lord , Seth Mos , werner maes , linux-xfs@oss.sgi.com Subject: Re: kernel update for RH7.1 users? In-Reply-To: Message from erich@uruk.org of "Fri, 19 Oct 2001 08:16:47 PDT." Date: Fri, 19 Oct 2001 10:25:33 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > Steve Lord wrote: > > > It is all a cunning ploy by Redhat, they always sneak things up on us. > > Given that this is a security update I suspect there will be an update > > to 7.2 when it comes out - but to what I don't know. > > > > If you are worried about security then you could download a later patch > > from our ftp site and build your own kernel until we have something in > > a more packaged form - 2.4.10 should do it. > > Uhh, I would be very careful about using any Linus kernel in the > 2.4.10 - 2.4.12 range. That was right in the middle of the radical VM > changes that went in, and several things were broken (HIGHMEM was > certainly broken in many of those kernels, for example). 2.4.10 seems to hold up OK under non-esoteric loads, yes I realize it is the new VM. We have an internal development team on another project using several highmem XFS systems with this kernel. So far they are happy - I do want to move them on again once there is another good kernel, the partition problems in 11/12 + the symlink thing are all a pain in the neck. > > I still worry about some things being broken, since there seems rather > sloppy testing going on before each kernel is put out, and other things > always slip in after something is known to work. > > (can you tell I disapprove?) > > > I've been trying to find a newer than 2.4.6-ish kernel to settle on > (2.4.7 would be ok, the redhat patch you guys have seems interesting!), > and some of the XFS snapshots have had leaks, and just by running a > kernel compile loop (make clean ; make bzImage) for a few days I could > eat up much of the available memory on my 768MB machine. > The 2.4.7 rpm is based on rawhide - so it is an ac kernel + the usual thousand and one patches. Up until the arrival of the new kernel from Redhat this was believed to be what would ship in 7.2, it may still be, along with an instant update on their ftp site. The package is built with kgcc by the way, still waiting for a fix from redhat on the compiler bug. > > On the other hand, the recent XFS CVS of 2.4.13-pre3 seems both to work > fine through several days of testing (I have no machine big enough to > test HIGHMEM, though I have SMP) and several build issues were resolved > for various modules... the common complaint about the i2o move and > other things seem resolved. > > I was going to try out 2.4.13-pre5 today. > > > BTW, is the patched new RH kernel based on 1.0.1, or some XFS "snapshot"? See above. Steve > > > -- > Erich Stefan Boleyn http://www.uruk.org/ > "Reality is truly stranger than fiction; Probably why fiction is so popular" From owner-linux-xfs@oss.sgi.com Fri Oct 19 08:36:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JFaUk31003 for linux-xfs-outgoing; Fri, 19 Oct 2001 08:36:30 -0700 Received: from trillium-hollow.org (IDENT:root@trillium-hollow.org [209.180.166.89]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JFaRD30979 for ; Fri, 19 Oct 2001 08:36:27 -0700 Received: from erich (helo=trillium) by trillium-hollow.org with local-esmtp (Exim 3.20 #1) id 15ubhN-0000Cf-00; Fri, 19 Oct 2001 08:36:37 -0700 To: Steve Lord cc: linux-xfs@oss.sgi.com Subject: Re: kernel update for RH7.1 users? In-Reply-To: Your message of "Fri, 19 Oct 2001 10:25:33 CDT." <200110191525.f9JFPX911794@jen.americas.sgi.com> Date: Fri, 19 Oct 2001 08:36:37 -0700 From: erich@uruk.org Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: > The 2.4.7 rpm is based on rawhide - so it is an ac kernel + the usual > thousand and one patches. Up until the arrival of the new kernel from > Redhat this was believed to be what would ship in 7.2, it may still be, > along with an instant update on their ftp site. The package is built > with kgcc by the way, still waiting for a fix from redhat on the > compiler bug. ... > > BTW, is the patched new RH kernel based on 1.0.1, or some XFS "snapshot"? > > See above. No, the kernel version was obvious, what is the XFS version? -- Erich Stefan Boleyn http://www.uruk.org/ "Reality is truly stranger than fiction; Probably why fiction is so popular" From owner-linux-xfs@oss.sgi.com Fri Oct 19 08:51:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JFpmr31517 for linux-xfs-outgoing; Fri, 19 Oct 2001 08:51:48 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JFpjD31492 for ; Fri, 19 Oct 2001 08:51:45 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA18671 for ; Fri, 19 Oct 2001 08:51:40 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA3354680; Fri, 19 Oct 2001 10:50:28 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA16387; Fri, 19 Oct 2001 10:50:28 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9JFlfW11948; Fri, 19 Oct 2001 10:47:41 -0500 Message-Id: <200110191547.f9JFlfW11948@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: erich@uruk.org cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: kernel update for RH7.1 users? In-Reply-To: Message from erich@uruk.org of "Fri, 19 Oct 2001 08:36:37 PDT." Date: Fri, 19 Oct 2001 10:47:41 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > Steve Lord wrote: > > > The 2.4.7 rpm is based on rawhide - so it is an ac kernel + the usual > > thousand and one patches. Up until the arrival of the new kernel from > > Redhat this was believed to be what would ship in 7.2, it may still be, > > along with an instant update on their ftp site. The package is built > > with kgcc by the way, still waiting for a fix from redhat on the > > compiler bug. > ... > > > BTW, is the patched new RH kernel based on 1.0.1, or some XFS "snapshot"? > > > > See above. > > No, the kernel version was obvious, what is the XFS version? Pretty close to the cvs tree - we took a 2.4.7 xfs patch as the starting point and then then added in xfs fixes which postdated that. Steve From owner-linux-xfs@oss.sgi.com Fri Oct 19 09:02:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JG25r31998 for linux-xfs-outgoing; Fri, 19 Oct 2001 09:02:05 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JG20D31975 for ; Fri, 19 Oct 2001 09:02:00 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA02042 for ; Fri, 19 Oct 2001 09:01:12 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA3350445; Fri, 19 Oct 2001 11:00:43 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA03636; Fri, 19 Oct 2001 11:00:43 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9JFvuo17283; Fri, 19 Oct 2001 10:57:56 -0500 Message-Id: <200110191557.f9JFvuo17283@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Ajay Shekhawat cc: linux-xfs@oss.sgi.com Subject: Re: xfsrestore assertion failure In-Reply-To: Message from Ajay Shekhawat of "Thu, 18 Oct 2001 19:39:10 EDT." <20011018193910.A9199@mekbuda.cedar.Buffalo.EDU> Date: Fri, 19 Oct 2001 10:57:56 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Thu, Aug 02, 2001 at 01:16:26PM -0400, Steve Roseman wrote: > > > xfsrestore: seeking past media file directory dump > > > xfsrestore: drive_scsitape.c:1461: do_next_mark: Assertion > > > `rechdrp->first_mark_offset - rechdrp->file_offset <= ( off64_t ) > > > ( contextp->dc_recsz )' failed. > > > Aborted (core dumped) > > > > The following fix seems to resolve the problem. xfsrestore -t works, at > > least. (I'll try a real restore later.) I suspect the problem is in > > endian-converting first_mark_offset, maybe when it contains the value > > -1. > > We just encountered this assertion failure, in xfsdump v1.1.6. > Steve's fix does fix the problem and the restore proceeds, but > I'm wondering if the patch breaks other things. If not, should > the patch be in the official xfsdump distribution? I attempted to work out if this fix is in the latest code, but it has changed radically, someone with some more experience with the dump code would have to say if this fix is now present or not. I suspect not since we are only at 1.1.7: xfsdump-1.1.7 (18 October 2001) - xfsrestore -t will no longer fail if the current working directory is not xfs - xfsrestore will no longer issue (harmless) warnings related to space pre-allocation if it is writing to a non-xfs filesystem Steve > > Ajay From owner-linux-xfs@oss.sgi.com Fri Oct 19 09:28:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JGSIW32548 for linux-xfs-outgoing; Fri, 19 Oct 2001 09:28:18 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JGSED32526 for ; Fri, 19 Oct 2001 09:28:14 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 7A1D71E220; Fri, 19 Oct 2001 18:28:08 +0200 (MEST) Date: Fri, 19 Oct 2001 18:28:03 +0200 From: Andi Kleen To: erich@uruk.org Cc: Steve Lord , Seth Mos , werner maes , linux-xfs@oss.sgi.com Subject: Re: kernel update for RH7.1 users? Message-ID: <20011019182803.A18495@wotan.suse.de> References: <200110191432.f9JEWLt10484@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.16i In-Reply-To: ; from erich@uruk.org on Fri, Oct 19, 2001 at 08:16:47AM -0700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I still worry about some things being broken, since there seems rather > sloppy testing going on before each kernel is put out, and other things > always slip in after something is known to work. > > (can you tell I disapprove?) The problem in Linux is that broad testing only works on "releases" (ie there is no way to distribute something to test to a bigger testing audience without a release) Normally that would be 2.x, x uneven kernels where everybody expects occasional brokenness. Unfortunately no non-even tree exists ATM. People that just want kernels that are tested and work currently need another testing "filter"; e.g. a distributor. -Andi From owner-linux-xfs@oss.sgi.com Fri Oct 19 09:42:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JGgLn00461 for linux-xfs-outgoing; Fri, 19 Oct 2001 09:42:21 -0700 Received: from ims.hub.nih.gov (ims.hub.nih.gov [128.231.90.111]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JGfBD00426; Fri, 19 Oct 2001 09:41:11 -0700 Received: by ims.hub.nih.gov with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Oct 2001 12:41:05 -0400 Message-ID: <59445348FF4CD41182CF00508B6F779C02D73DC5@nihexchange11.nih.gov> From: "Ngan, Michael (NCI)" To: "'tes@engr.sgi.com'" Cc: "'owner-linux-xfs@oss.sgi.com'" , "'linux-xfs@oss.sgi.com'" , "'pv@relay.sgi.com'" , "'owner-linux-xfs@oss.sgi.com'" Subject: xfsdump: WARNING: unable to backspace tape: assuming media error Date: Fri, 19 Oct 2001 12:41:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I am try to setup a IBM LTO Ultrium-td1 tape with a SGI Orign 2000 running IRIX 6.5.9. I encounter this error message when I tried to do test dump xfsdump: WARNING: unable to backspace tape: assuming media error What is the problem? Is there are fix to this? The tar command works. thanks, Mike Ngan National Cancer Institute 301-402-0324 root@msb:/hw/tape> xfsdump -f /dev/nrtape -L "Test" -M "Tape" / xfsdump: version 3.0 - type ^C for status and control xfsdump: WARNING: most recent level 0 dump was interrupted, but not resuming tha t dump since resume (-R) option not specified xfsdump: level 0 dump of msb:/ xfsdump: dump date: Fri Oct 19 12:34:48 2001 xfsdump: session id: 0476787b-5909-1025-879a-0800690d46f5 xfsdump: session label: "Test" xfsdump: ino map phase 1: skipping (no subtrees specified) xfsdump: ino map phase 2: constructing initial dump list xfsdump: ino map phase 3: skipping (no pruning necessary) xfsdump: ino map phase 4: skipping (size estimated in phase 2) xfsdump: ino map phase 5: skipping (only one dump stream) xfsdump: ino map construction complete xfsdump: estimated dump size: 5721094016 bytes xfsdump: preparing drive xfsdump: WARNING: unable to backspace tape: assuming media error ============================ change media dialog ============================= please change media in drive 0 1: media change declined (timeout in 3600 sec) 2: media changed (default) -> Here is some more info: root@msb:/hw/tape> hinv 4 250 MHZ IP27 Processors CPU: MIPS R10000 Processor Chip Revision: 3.4 FPU: MIPS R10010 Floating Point Chip Revision: 0.0 Main memory size: 4608 Mbytes Instruction cache size: 32 Kbytes Data cache size: 32 Kbytes Secondary unified instruction/data cache size: 4 Mbytes Integral SCSI controller 0: Version QL1040B (rev. 2), single ended Disk drive: unit 1 on SCSI controller 0 Disk drive: unit 2 on SCSI controller 0 Disk drive: unit 3 on SCSI controller 0 Disk drive: unit 4 on SCSI controller 0 Disk drive: unit 5 on SCSI controller 0 CDROM: unit 6 on SCSI controller 0 Integral SCSI controller 1: Version QL1040B (rev. 2), single ended Tape drive: unit 3 on SCSI controller 1: unknown IOC3 serial port: tty1 IOC3 serial port: tty2 Integral Fast Ethernet: ef0, version 1, module 1, slot io1, pci 2 Origin BASEIO board, module 1 slot 1: Revision 4 IOC3 external interrupts: 1 root@msb:/hw/tape> mt -f /dev/mt/tps1d3nr status Controller: SCSI Device: IBM: ULTRIUM-TD1 1550 Status: 0x24260 Drive type: unknown Media : READY, writable, at EOD, block 3 From owner-linux-xfs@oss.sgi.com Fri Oct 19 10:03:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JH33I01009 for linux-xfs-outgoing; Fri, 19 Oct 2001 10:03:03 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JH2xD00984 for ; Fri, 19 Oct 2001 10:02:59 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA24763 for ; Fri, 19 Oct 2001 10:02:54 -0700 (PDT) mail_from (eric@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA3356427 for ; Fri, 19 Oct 2001 12:01:43 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA38114; Fri, 19 Oct 2001 12:01:42 -0500 (CDT) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id f9JH0qR13300; Fri, 19 Oct 2001 12:00:52 -0500 Message-Id: <200110191700.f9JH0qR13300@stout.americas.sgi.com> Date: Fri, 19 Oct 2001 12:00:52 -0500 From: Eric Sandeen Subject: TAKE - Merge irix6.5f:irix:104607a Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Fri Oct 19 09:59:07 PDT 2001 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:105089a linux/fs/xfs/xfs_trans_dquot.c - 1.33 - Merge irix6.5f:irix:104607a Change an ASSERT in xfs_trans_reserve_quota_nblks() to mask out XFS_QMOPT_FORCE_RES. Fix for bug 833507. linux/fs/xfs/xfs_bmap.c - 1.276 - Merge irix6.5f:irix:104607a Don't enforce quotas when reserving blocks for root extended attributes. Fix for bug 833507. linux/fs/xfs/xfs_quota.h - 1.25 - Merge irix6.5f:irix:104607a Create new xfs_trans_reserve_blkquota_force() macro. Fix for bug 833507. linux/fs/xfs/xfs_attr.c - 1.85 - Merge irix6.5f:irix:104607a Don't enforce quotas when reserving blocks for root extended attributes. Fix for bug 833507. From owner-linux-xfs@oss.sgi.com Fri Oct 19 10:09:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JH9Qe01309 for linux-xfs-outgoing; Fri, 19 Oct 2001 10:09:26 -0700 Received: from fep06-app.kolumbus.fi (fep06-0.kolumbus.fi [193.229.0.57]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JH8KD01260; Fri, 19 Oct 2001 10:08:20 -0700 Received: from there ([62.248.190.100]) by fep06-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20011019170808.BECE1726.fep06-app.kolumbus.fi@there>; Fri, 19 Oct 2001 20:08:08 +0300 Content-Type: text/plain; charset="iso-8859-1" From: Hristo Grigorov To: "Ngan, Michael (NCI)" , "'tes@engr.sgi.com'" Subject: Re: xfsdump: WARNING: unable to backspace tape: assuming media error Date: Fri, 19 Oct 2001 20:08:17 +0300 X-Mailer: KMail [version 1.3.1] Cc: "'owner-linux-xfs@oss.sgi.com'" , "'linux-xfs@oss.sgi.com'" , "'pv@relay.sgi.com'" , "'owner-linux-xfs@oss.sgi.com'" References: <59445348FF4CD41182CF00508B6F779C02D73DC5@nihexchange11.nih.gov> In-Reply-To: <59445348FF4CD41182CF00508B6F779C02D73DC5@nihexchange11.nih.gov> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011019170808.BECE1726.fep06-app.kolumbus.fi@there> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Friday 19 October 2001 19:41, Ngan, Michael (NCI) wrote: > Hi, > > I am try to setup a IBM LTO Ultrium-td1 tape with a SGI Orign 2000 running > IRIX 6.5.9. I encounter this error message when I tried to do test dump > > xfsdump: WARNING: unable to backspace tape: assuming media error > > What is the problem? Is there are fix to this? The tar command works. > > thanks, > > Mike Ngan > National Cancer Institute > 301-402-0324 > Eh, please check... You should have official support from SGI for that... :) Not that here is not official but it is Linux related. Regards, Hristo. From owner-linux-xfs@oss.sgi.com Fri Oct 19 10:26:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JHQcS01700 for linux-xfs-outgoing; Fri, 19 Oct 2001 10:26:38 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JHQZD01678 for ; Fri, 19 Oct 2001 10:26:35 -0700 Received: from crom.corp.sgi.com (crom.corp.sgi.com [130.62.63.32]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9JHQUW09420 for ; Fri, 19 Oct 2001 10:26:30 -0700 Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.175.86]) by crom.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA28748 for ; Fri, 19 Oct 2001 10:32:14 -0700 (PDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id A9EC915A4CA for ; Fri, 19 Oct 2001 10:25:14 -0700 (PDT) Subject: Re: Redhat kernel errata From: Florin Andrei To: linux-xfs In-Reply-To: <4.3.2.7.2.20011019090632.02b83680@pop.xs4all.nl> References: <4.3.2.7.2.20011019090632.02b83680@pop.xs4all.nl> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 19 Oct 2001 10:25:14 -0700 Message-Id: <1003512314.28390.21.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2001-10-19 at 00:09, Seth Mos wrote: > It is true. They just released packages of 2.4.9 kernels. These are errata > for 7.1 I have no idea of what they are gonna do with the 7.2 cds that > probably already went to mastering. Do you guys plan to upgrade the XFS packages to get rid of this security bug? Maybe based on the new Red Hat 2.4.9 RPMs? -- Florin Andrei Bloated software is not about being big. Bloated software is about being slow and stupid and not realizing that it's because of design mistakes. (Linus Torvalds) From owner-linux-xfs@oss.sgi.com Fri Oct 19 10:30:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JHUV401934 for linux-xfs-outgoing; Fri, 19 Oct 2001 10:30:31 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JHUTD01912 for ; Fri, 19 Oct 2001 10:30:29 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA05796 for ; Fri, 19 Oct 2001 10:29:40 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA2724937; Fri, 19 Oct 2001 12:29:11 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA88428; Fri, 19 Oct 2001 12:29:11 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9JHQOH17598; Fri, 19 Oct 2001 12:26:24 -0500 Message-Id: <200110191726.f9JHQOH17598@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Florin Andrei cc: linux-xfs Subject: Re: Redhat kernel errata In-Reply-To: Message from Florin Andrei of "19 Oct 2001 10:25:14 PDT." <1003512314.28390.21.camel@stantz.corp.sgi.com> Date: Fri, 19 Oct 2001 12:26:24 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Fri, 2001-10-19 at 00:09, Seth Mos wrote: > > It is true. They just released packages of 2.4.9 kernels. These are errata > > for 7.1 I have no idea of what they are gonna do with the 7.2 cds that > > probably already went to mastering. > > Do you guys plan to upgrade the XFS packages to get rid of this security > bug? Maybe based on the new Red Hat 2.4.9 RPMs? > > -- > Florin Andrei Keep reading the list, the answer is in your inbox. Steve From owner-linux-xfs@oss.sgi.com Fri Oct 19 10:50:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JHoIf02533 for linux-xfs-outgoing; Fri, 19 Oct 2001 10:50:18 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JHoFD02511 for ; Fri, 19 Oct 2001 10:50:16 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA03618 for ; Fri, 19 Oct 2001 09:55:27 -0700 (PDT) mail_from (eric@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA3353703 for ; Fri, 19 Oct 2001 11:55:49 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA94046 for ; Fri, 19 Oct 2001 11:55:49 -0500 (CDT) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id f9JGsx013228; Fri, 19 Oct 2001 11:54:59 -0500 Message-Id: <200110191654.f9JGsx013228@stout.americas.sgi.com> Date: Fri, 19 Oct 2001 11:54:59 -0500 From: Eric Sandeen Subject: TAKE - Merge irix6.5f:irix:104225a Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Fri Oct 19 09:53:21 PDT 2001 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:105088a linux/fs/xfs/xfs_dmapi.c - 1.39 - Merge irix6.5f:irix:104225a Break out of the loop in xfs_dm_send_data_event() on an error. Fix for Bug 831666/838314. From owner-linux-xfs@oss.sgi.com Fri Oct 19 11:30:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JIUD203734 for linux-xfs-outgoing; Fri, 19 Oct 2001 11:30:13 -0700 Received: from phobos.pop-star.net (phobos.pop-star.net [64.85.83.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JIUAD03711 for ; Fri, 19 Oct 2001 11:30:10 -0700 Received: from zerowing.pop-star.net ([208.181.22.52]) by phobos.pop-star.net with asmtp (Exim 3.167 #4) id 15ueRG-0000wd-00 for linux-xfs@oss.sgi.com; Fri, 19 Oct 2001 11:32:10 -0700 Subject: Daily XFS CVS RPMS From: Andy Kwong To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16.99+cvs.2001.10.18.15.19 (Preview Release) Date: 19 Oct 2001 11:31:16 -0700 Message-Id: <1003516281.10441.9.camel@zerowing.pop-star.net> Mime-Version: 1.0 X-Authenticated-Sender: andy.kwong@pop-star.net Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Since Alan Eldridge has left Linux for FreeBSD, he has left behind a great RPM CVS kit that I have been playing around with for the last few weeks. Right now I am building CVS RPMS regularly with preemptive and lm_sensors patches. Is anybody on the list interested in daily RPM builds? If there is enough interest, I'd sync those RPMS up with an FTP site so that they could be enjoyed by everybody. Cheers, Andy From owner-linux-xfs@oss.sgi.com Fri Oct 19 11:38:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JIciJ04072 for linux-xfs-outgoing; Fri, 19 Oct 2001 11:38:44 -0700 Received: from chef.cc.absoval.com (cpe-66-1-218-101.fl.sprintbbd.net [66.1.218.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JIcfD04048 for ; Fri, 19 Oct 2001 11:38:41 -0700 Received: from ieee.org (IDENT:bs@thebs.cc.absoval.com [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id OAA27670; Fri, 19 Oct 2001 14:38:32 -0400 Message-ID: <3BD0732C.5CB09267@ieee.org> Date: Fri, 19 Oct 2001 14:38:36 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts/AbsoluteValueSystems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Andy Kwong CC: linux-xfs@oss.sgi.com Subject: Re: Daily XFS CVS RPMS References: <1003516281.10441.9.camel@zerowing.pop-star.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Andy Kwong wrote: > Is anybody on the list interested in daily RPM builds? If there is > enough interest, I'd sync those RPMS up with an FTP site so that they > could be enjoyed by everybody. Weekly check-out and builds of the "beta" tree would probably be best for most of us. -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ---------------------------------------------------------------- The US National ID is an enhanced Social Security Number. It will give those who abuse it more information than ever before. And just like the SSN, they will ignore all the regulations. From owner-linux-xfs@oss.sgi.com Fri Oct 19 12:30:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JJUJo05353 for linux-xfs-outgoing; Fri, 19 Oct 2001 12:30:19 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JJUGD05331 for ; Fri, 19 Oct 2001 12:30:16 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9JJUBW16861 for ; Fri, 19 Oct 2001 12:30:11 -0700 Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA17404; Fri, 19 Oct 2001 12:29:39 -0700 (PDT) Message-ID: <3BD07E50.535E7B1E@sgi.com> Date: Fri, 19 Oct 2001 14:26:08 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: erich@uruk.org CC: linux-xfs@oss.sgi.com Subject: Re: kernel update for RH7.1 users? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk erich@uruk.org wrote: > BTW, is the patched new RH kernel based on 1.0.1, or some XFS "snapshot"? The RH/XFS 2.4.7 kernel in the testing dir is: State of the XFS CVS tree on 7/27, merged with the RH tree, then all XFS-related changes through last Monday were merged into that. "1.0.1" is a thing of the past. :) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Oct 19 12:43:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JJh0c05627 for linux-xfs-outgoing; Fri, 19 Oct 2001 12:43:00 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JJguD05605 for ; Fri, 19 Oct 2001 12:42:56 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA05789 for ; Fri, 19 Oct 2001 12:42:08 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA81565; Fri, 19 Oct 2001 12:42:23 -0700 (PDT) Message-ID: <3BD0814C.4CDACA9@sgi.com> Date: Fri, 19 Oct 2001 14:38:52 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: Bryan-TheBS-Smith CC: Andy Kwong , linux-xfs@oss.sgi.com Subject: Re: Daily XFS CVS RPMS References: <1003516281.10441.9.camel@zerowing.pop-star.net> <3BD0732C.5CB09267@ieee.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Bryan - What's "the 'beta' tree?" :) -Eric Bryan-TheBS-Smith wrote: > Weekly check-out and builds of the "beta" tree would probably be > best for most of us. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Oct 19 13:22:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JKMPI06237 for linux-xfs-outgoing; Fri, 19 Oct 2001 13:22:25 -0700 Received: from chef.cc.absoval.com (cpe-66-1-218-101.fl.sprintbbd.net [66.1.218.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JKMKD06215 for ; Fri, 19 Oct 2001 13:22:20 -0700 Received: from ieee.org (IDENT:bs@thebs.cc.absoval.com [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id QAA28180; Fri, 19 Oct 2001 16:22:05 -0400 Message-ID: <3BD08B71.BBDC6271@ieee.org> Date: Fri, 19 Oct 2001 16:22:09 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts/AbsoluteValueSystems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: Andy Kwong , linux-xfs@oss.sgi.com Subject: Re: Daily XFS CVS RPMS References: <1003516281.10441.9.camel@zerowing.pop-star.net> <3BD0732C.5CB09267@ieee.org> <3BD0814C.4CDACA9@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: > Hi Bryan - > What's "the 'beta' tree?" According to Russel Ingram in the Linux+XFS HOWTO (dated 2001-10-18): "two distinct trees are available: o linux-2.4-xfs: fast moving development tree o linux-2.4-xfs-beta: stable bug fix only tree" URL (Section 2.1. top of page): http://www.linuxdoc.org/HOWTO/Linux+XFS-HOWTO/x41.html Please correct me (as well as let him know) if this is wrong. -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ---------------------------------------------------------------- The US National ID is an enhanced Social Security Number. It will give those who abuse it more information than ever before. And just like the SSN, they will ignore all the regulations. From owner-linux-xfs@oss.sgi.com Fri Oct 19 13:27:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JKRaq06455 for linux-xfs-outgoing; Fri, 19 Oct 2001 13:27:36 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JKRXD06432 for ; Fri, 19 Oct 2001 13:27:33 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id WAA07242 for ; Fri, 19 Oct 2001 22:25:46 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA3355320; Fri, 19 Oct 2001 15:26:10 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA29871; Fri, 19 Oct 2001 15:26:10 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9JKNLM18367; Fri, 19 Oct 2001 15:23:21 -0500 Message-Id: <200110192023.f9JKNLM18367@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Bryan-TheBS-Smith cc: Eric Sandeen , Andy Kwong , linux-xfs@oss.sgi.com Subject: Re: Daily XFS CVS RPMS In-Reply-To: Message from Bryan-TheBS-Smith of "Fri, 19 Oct 2001 16:22:09 EDT." <3BD08B71.BBDC6271@ieee.org> Date: Fri, 19 Oct 2001 15:23:21 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Eric Sandeen wrote: > > Hi Bryan - > > What's "the 'beta' tree?" > > According to Russel Ingram in the Linux+XFS HOWTO (dated > 2001-10-18): > > "two distinct trees are available: > o linux-2.4-xfs: fast moving development tree > o linux-2.4-xfs-beta: stable bug fix only tree" I think the beta tree is really stable - it never moves! Steve From owner-linux-xfs@oss.sgi.com Fri Oct 19 13:27:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JKRtv06533 for linux-xfs-outgoing; Fri, 19 Oct 2001 13:27:55 -0700 Received: from mg02.austin.ibm.com (mg02.austin.ibm.com [192.35.232.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JKRrD06510 for ; Fri, 19 Oct 2001 13:27:53 -0700 Received: from austin.ibm.com (netmail2.austin.ibm.com [9.3.7.139]) by mg02.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA48396 for ; Fri, 19 Oct 2001 15:35:13 -0500 Received: from popmail.austin.ibm.com (popmail.austin.ibm.com [9.53.247.178]) by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA38534 for ; Fri, 19 Oct 2001 15:27:52 -0500 Received: from there (crashandburn.austin.ibm.com [9.53.216.41]) by popmail.austin.ibm.com (AIX4.3/8.9.3/8.7-client1.01) with SMTP id PAA29066 for ; Fri, 19 Oct 2001 15:27:48 -0500 Message-Id: <200110192027.PAA29066@popmail.austin.ibm.com> Content-Type: text/plain; charset="iso-8859-1" From: Andrew Theurer To: linux-xfs@oss.sgi.com Subject: xfs with 2.4.10 anb kernprof Date: Fri, 19 Oct 2001 13:18:55 -0700 X-Mailer: KMail [version 1.3] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Has anyone been able to patch xfs with kernprof for 2.4.10? The kernprof patch fails, and I'm afraid my attempts to hand apply arch/i386/kernel/semaphore.c have failed. I get a oops on boot. Anyone have any pointers? Thanks, Andrew Theurer From owner-linux-xfs@oss.sgi.com Fri Oct 19 13:28:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JKS0M06609 for linux-xfs-outgoing; Fri, 19 Oct 2001 13:28:00 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JKRuD06545 for ; Fri, 19 Oct 2001 13:27:56 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9JKRpW19515 for ; Fri, 19 Oct 2001 13:27:51 -0700 Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id NAA87812; Fri, 19 Oct 2001 13:27:19 -0700 (PDT) Message-ID: <3BD08BD4.F044DB49@sgi.com> Date: Fri, 19 Oct 2001 15:23:48 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: Bryan-TheBS-Smith CC: Andy Kwong , linux-xfs@oss.sgi.com Subject: Re: Daily XFS CVS RPMS References: <1003516281.10441.9.camel@zerowing.pop-star.net> <3BD0732C.5CB09267@ieee.org> <3BD0814C.4CDACA9@sgi.com> <3BD08B71.BBDC6271@ieee.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ah, I hope not many people are using that, it hasn't been touched in months. :) That was a stopping-off place prior to 1.0, I think. I'll ask Russel to remove it from the HOWTO... Thanks, -Eric Bryan-TheBS-Smith wrote: > > According to Russel Ingram in the Linux+XFS HOWTO (dated > 2001-10-18): > > "two distinct trees are available: > o linux-2.4-xfs: fast moving development tree > o linux-2.4-xfs-beta: stable bug fix only tree" > > URL (Section 2.1. top of page): > http://www.linuxdoc.org/HOWTO/Linux+XFS-HOWTO/x41.html > > Please correct me (as well as let him know) if this is wrong. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Oct 19 13:29:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JKT9Q06823 for linux-xfs-outgoing; Fri, 19 Oct 2001 13:29:09 -0700 Received: from chef.cc.absoval.com (cpe-66-1-218-101.fl.sprintbbd.net [66.1.218.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JKT5D06798 for ; Fri, 19 Oct 2001 13:29:05 -0700 Received: from ieee.org (IDENT:bs@thebs.cc.absoval.com [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id QAA28192; Fri, 19 Oct 2001 16:28:55 -0400 Message-ID: <3BD08D0C.64414366@ieee.org> Date: Fri, 19 Oct 2001 16:29:00 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts/AbsoluteValueSystems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: Andy Kwong , linux-xfs@oss.sgi.com Subject: Re: Daily XFS CVS RPMS References: <1003516281.10441.9.camel@zerowing.pop-star.net> <3BD0732C.5CB09267@ieee.org> <3BD0814C.4CDACA9@sgi.com> <3BD08B71.BBDC6271@ieee.org> <3BD08BD4.F044DB49@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: > I'll ask Russel to remove it from the HOWTO... > Thanks, No, thank you for clarifying. -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ---------------------------------------------------------------- The US National ID is an enhanced Social Security Number. It will give those who abuse it more information than ever before. And just like the SSN, they will ignore all the regulations. From owner-linux-xfs@oss.sgi.com Fri Oct 19 13:32:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JKWZ407019 for linux-xfs-outgoing; Fri, 19 Oct 2001 13:32:35 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JKWWD06996 for ; Fri, 19 Oct 2001 13:32:32 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9JKWRW19729 for ; Fri, 19 Oct 2001 13:32:27 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA3352199; Fri, 19 Oct 2001 15:31:11 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA84230; Fri, 19 Oct 2001 15:31:11 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9JKSMZ18423; Fri, 19 Oct 2001 15:28:22 -0500 Message-Id: <200110192028.f9JKSMZ18423@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Andrew Theurer cc: linux-xfs@oss.sgi.com Subject: Re: xfs with 2.4.10 anb kernprof In-Reply-To: Message from Andrew Theurer of "Fri, 19 Oct 2001 13:18:55 PDT." <200110192027.PAA29066@popmail.austin.ibm.com> Date: Fri, 19 Oct 2001 15:28:22 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Has anyone been able to patch xfs with kernprof for 2.4.10? The kernprof > patch fails, and I'm afraid my attempts to hand apply > arch/i386/kernel/semaphore.c have failed. I get a oops on boot. Anyone have > any pointers? > > Thanks, > > Andrew Theurer Try reverse applying a 2.4.10 kdb patch from the oss kdb site first, then apply the kernprof patch. The two land fairly hard on top of one another. I would be interested in seeing results, hmm IBM profiling an SGI filesystem..... ;-) Steve From owner-linux-xfs@oss.sgi.com Fri Oct 19 14:04:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JL4TI07597 for linux-xfs-outgoing; Fri, 19 Oct 2001 14:04:29 -0700 Received: from mg03.austin.ibm.com (mg03.austin.ibm.com [192.35.232.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JL4LD07573 for ; Fri, 19 Oct 2001 14:04:21 -0700 Received: from austin.ibm.com (netmail1.austin.ibm.com [9.3.7.138]) by mg03.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA22936 for ; Fri, 19 Oct 2001 16:03:14 -0500 Received: from popmail.austin.ibm.com (popmail.austin.ibm.com [9.53.247.178]) by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA29294 for ; Fri, 19 Oct 2001 16:04:19 -0500 Received: from there (crashandburn.austin.ibm.com [9.53.216.41]) by popmail.austin.ibm.com (AIX4.3/8.9.3/8.7-client1.01) with SMTP id QAA24556 for ; Fri, 19 Oct 2001 16:04:16 -0500 Message-Id: <200110192104.QAA24556@popmail.austin.ibm.com> Content-Type: text/plain; charset="iso-8859-1" From: Andrew Theurer To: linux-xfs@oss.sgi.com Subject: Re: xfs with 2.4.10 anb kernprof Date: Fri, 19 Oct 2001 13:55:21 -0700 X-Mailer: KMail [version 1.3] References: <200110192028.f9JKSMZ18423@jen.americas.sgi.com> In-Reply-To: <200110192028.f9JKSMZ18423@jen.americas.sgi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks, I will try that. I'll soon have lockmeter, acg, and kernel profile on up and 4p, running Netbench, and maybe some other workloads. I'll also have jfs, ext2, reiserfs, and ext3 to compare against. If there are any other things you would like logged, let me know... -Andrew On Friday 19 October 2001 01:28 pm, you wrote: > > Has anyone been able to patch xfs with kernprof for 2.4.10? The kernprof > > patch fails, and I'm afraid my attempts to hand apply > > arch/i386/kernel/semaphore.c have failed. I get a oops on boot. Anyone > > have any pointers? > > > > Thanks, > > > > Andrew Theurer > > Try reverse applying a 2.4.10 kdb patch from the oss kdb site first, > then apply the kernprof patch. The two land fairly hard on top of one > another. > > I would be interested in seeing results, hmm IBM profiling an SGI > filesystem..... ;-) > > Steve From owner-linux-xfs@oss.sgi.com Fri Oct 19 15:14:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JMELJ08897 for linux-xfs-outgoing; Fri, 19 Oct 2001 15:14:21 -0700 Received: from groucho.maths.monash.edu.au (groucho.maths.monash.edu.au [130.194.160.211]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JMEID08870 for ; Fri, 19 Oct 2001 15:14:18 -0700 Received: (from rjh@localhost) by groucho.maths.monash.edu.au (8.8.8/8.8.8) id WAA29155 for linux-xfs@oss.sgi.com; Fri, 19 Oct 2001 22:14:16 GMT From: Robin Humble Message-Id: <200110192214.WAA29155@groucho.maths.monash.edu.au> Subject: Re: Daily XFS CVS RPMS To: linux-xfs@oss.sgi.com Date: Sat, 20 Oct 2001 08:14:15 +1000 (EST) In-Reply-To: <1003516281.10441.9.camel@zerowing.pop-star.net> from "Andy Kwong" at Oct 19, 2001 11:31:16 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Andy writes: >weeks. Right now I am building CVS RPMS regularly with preemptive and >lm_sensors patches. Whilst we're talking patches: I have a drm/agpgart patch that restores accelerated OpenGL to the XFree that comes with RedHat7.1. Somewhere along the line (>2.4.7?) the Linus kernel moved to too-new DRM version and (at least on my G400Max) XFree then turned all hardware acceleration off :-/ This patch was distilled from 2.4.12-ac1 and gives you a config option of a XFree 4.0.* (RedHat 7.1) or XFree 4.1.* style DRM. The patch applies fine to 2.4.12-xfs and 2.4.13-pre*-xfs. http://www.cita.utoronto.ca/~rjh/drm/ Works for me - YMMV. cheers, robin From owner-linux-xfs@oss.sgi.com Fri Oct 19 15:28:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JMSg909212 for linux-xfs-outgoing; Fri, 19 Oct 2001 15:28:42 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JMSbD09189 for ; Fri, 19 Oct 2001 15:28:37 -0700 Received: from idcomm.com (IDENT:5e95cZv9EjZzuvt9i4yKSXtnyIxYy/vA@x2-pip55.idcomm.com [209.60.72.66]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f9JMSsL28441 for ; Fri, 19 Oct 2001 16:28:55 -0600 Message-ID: <3BD0A937.F9CAB7C6@idcomm.com> Date: Fri, 19 Oct 2001 16:29:11 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: Daily XFS CVS RPMS References: <200110192214.WAA29155@groucho.maths.monash.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Robin Humble wrote: > > Andy writes: > >weeks. Right now I am building CVS RPMS regularly with preemptive and > >lm_sensors patches. > > Whilst we're talking patches: > > I have a drm/agpgart patch that restores accelerated OpenGL to > the XFree that comes with RedHat7.1. Somewhere along the line (>2.4.7?) > the Linus kernel moved to too-new DRM version and (at least on my > G400Max) XFree then turned all hardware acceleration off :-/ > > This patch was distilled from 2.4.12-ac1 and gives you a config option > of a XFree 4.0.* (RedHat 7.1) or XFree 4.1.* style DRM. The patch > applies fine to 2.4.12-xfs and 2.4.13-pre*-xfs. > > http://www.cita.utoronto.ca/~rjh/drm/ > > Works for me - YMMV. > > cheers, > robin I haven't tried the newer kernels, but I was under the impression that instead of altering the DRM, a choice was going to be presented to use either the 4.0.x XFree86 version or the 4.1.x XFree86 version, making them a choice. Is this patch somehow different? D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Fri Oct 19 16:16:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JNGfT10169 for linux-xfs-outgoing; Fri, 19 Oct 2001 16:16:41 -0700 Received: from groucho.maths.monash.edu.au (groucho.maths.monash.edu.au [130.194.160.211]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JNGbD10147 for ; Fri, 19 Oct 2001 16:16:37 -0700 Received: (from rjh@localhost) by groucho.maths.monash.edu.au (8.8.8/8.8.8) id XAA00329 for linux-xfs@oss.sgi.com; Fri, 19 Oct 2001 23:16:36 GMT From: Robin Humble Message-Id: <200110192316.XAA00329@groucho.maths.monash.edu.au> Subject: Re: Daily XFS CVS RPMS To: linux-xfs@oss.sgi.com Date: Sat, 20 Oct 2001 09:16:36 +1000 (EST) In-Reply-To: <3BD0A937.F9CAB7C6@idcomm.com> from "D. Stimits" at Oct 19, 2001 04:29:11 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk D. Stimits writes: >I haven't tried the newer kernels, but I was under the impression that >instead of altering the DRM, a choice was going to be presented to use >either the 4.0.x XFree86 version or the 4.1.x XFree86 version, making The -ac kernels give you a choice, but the Linus kernels only give you the new DRM (agpgart) version which doesn't work with XFree 4.0.* and hence your tuxracer goes slow. At least mine certainly did :) If your distro has XF 4.1.* (any yet?) then a newer kernel isn't a problem. >them a choice. Is this patch somehow different? This patch is pulled from the -ac series and lets you choose to build an agpgart kernel module (+ drivers for specific cards) as a version suitable for XFree 4.0.* or for XFree 4.1.* ... the idea being that it's WAY hard to upgrade your X 'cos of all the dependancies, and instead it's easier to downgrade the agpgart in newer kernels to match the old XFree4.0.* ie. it lets the mainstream (and XFS) kernel have the same choices as the Alan Cox kernels. cheers, robin From owner-linux-xfs@oss.sgi.com Fri Oct 19 16:53:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JNrVm10994 for linux-xfs-outgoing; Fri, 19 Oct 2001 16:53:31 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JNrQD10972 for ; Fri, 19 Oct 2001 16:53:26 -0700 Received: from idcomm.com (IDENT:LDHN8ZbMpvSFKuy1A947u4lV1WS7b5Ef@x2-pip68.idcomm.com [209.60.72.79]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f9JNrhL11476 for ; Fri, 19 Oct 2001 17:53:43 -0600 Message-ID: <3BD0BD18.2272B325@idcomm.com> Date: Fri, 19 Oct 2001 17:54:00 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: Daily XFS CVS RPMS References: <200110192316.XAA00329@groucho.maths.monash.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Robin Humble wrote: > > D. Stimits writes: > >I haven't tried the newer kernels, but I was under the impression that > >instead of altering the DRM, a choice was going to be presented to use > >either the 4.0.x XFree86 version or the 4.1.x XFree86 version, making > > The -ac kernels give you a choice, but the Linus kernels only give you > the new DRM (agpgart) version which doesn't work with XFree 4.0.* and > hence your tuxracer goes slow. At least mine certainly did :) > If your distro has XF 4.1.* (any yet?) then a newer kernel isn't a problem. That sucks, I don't want to lose DRM if I multiboot between kernels that have 4.1.x and 4.0.x. Somehow I doubt running both versions is easy or reasonable. I wonder if NVidia has its DRM out yet for 4.1.x (I guess SGI is a big participant in DRM area). > > >them a choice. Is this patch somehow different? > > This patch is pulled from the -ac series and lets you choose to build > an agpgart kernel module (+ drivers for specific cards) as a version > suitable for XFree 4.0.* or for XFree 4.1.* ... the idea being that > it's WAY hard to upgrade your X 'cos of all the dependancies, and > instead it's easier to downgrade the agpgart in newer kernels to > match the old XFree4.0.* > ie. it lets the mainstream (and XFS) kernel have the same choices as > the Alan Cox kernels. I've heard there are difficulties in having a kernel that simultaneously supports both DRM models, though part of it is a matter of naming. I certainly can't upgrade to any kernel that doesn't have 4.0.x DRM ability (at least not if NVidia drivers are not available). Since I'm using XFS, whatever I use has to be XFS as well. D. Stimits, stimits@idcomm.com > > cheers, > robin From owner-linux-xfs@oss.sgi.com Fri Oct 19 18:19:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9K1JUo12468 for linux-xfs-outgoing; Fri, 19 Oct 2001 18:19:30 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9K1JRD12446 for ; Fri, 19 Oct 2001 18:19:27 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9K1JLW28145 for ; Fri, 19 Oct 2001 18:19:22 -0700 Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id LAA11309; Sat, 20 Oct 2001 11:19:20 +1000 Date: Sat, 20 Oct 2001 11:19:20 +1000 From: Keith Owens Message-Id: <200110200119.LAA11309@sherman.melbourne.sgi.com> Subject: TAKE - Correct CONFIG typo Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Correct CONFIG_XFS to CONFIG_XFS_FS for xfsidbg. Date: Fri Oct 19 18:16:33 PDT 2001 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:105130a linux/fs/xfs/Makefile - 1.127 From owner-linux-xfs@oss.sgi.com Fri Oct 19 18:54:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9K1sLu13105 for linux-xfs-outgoing; Fri, 19 Oct 2001 18:54:21 -0700 Received: from afara-gw.afara.com (mx1.afara.com [63.113.218.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9K1sED13083 for ; Fri, 19 Oct 2001 18:54:14 -0700 Received: from tduffy-lnx.afara.com ([10.2.4.191]) by afara-gw.afara.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 19 Oct 2001 18:53:19 -0700 Subject: bonnie hangs on 2.4.7-10SGI_XFS_PR1 From: Thomas Duffy To: XFS Mailing List Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16.99+cvs.2001.10.18.15.19 (Preview Release) Date: 19 Oct 2001 18:53:22 -0700 Message-Id: <1003542802.16337.32.camel@tduffy-lnx.afara.com> Mime-Version: 1.0 X-OriginalArrivalTime: 20 Oct 2001 01:53:19.0640 (UTC) FILETIME=[FE237980:01C15909] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have a MD RAID 10 device hooked up to a 2 p 2G machine (running enterprise version of the kernel), basically setup like this: < ----------------- > stripe (RAID 0) [ d1 | d2 | d3 | d4 ] ^ ^ ^ ^ | | | | mirrors (RAID 1) [ d5 d6 d7 d8 ] both the RAID 1's and RAID 0's have 64k chunks. when I run bonnie on this, very soon (like 5 minutes into the test), the process hangs on D. it is of course unkillable and unhappy. here is the btp from kdb of the bonnie++ process: 0xeaa45e10 0xc01180a1 schedule+0x485 (0xc1fc9a78) kernel .text 0xc0100000 0xc0117c1c 0xc01182ac 0xc012d022 ___wait_on_page+0x66 (0xc1fc9a78, 0x0) kernel .text 0xc0100000 0xc012cfbc 0xc012d06c 0xc012c471 truncate_list_pages+0xd5 (0xeaa45e94) kernel .text 0xc0100000 0xc012c39c 0xc012c6ac 0xc012c719 truncate_inode_pages+0x6d (0xeafb7118, 0x0, 0x0) kernel .text 0xc0100000 0xc012c6ac 0xc012c76c 0xc017116e pagebuf_inval+0x1a (0xeafb7060, 0x0, 0x0, 0x0) kernel .text 0xc0100000 0xc0171154 0xc0171174 0xc01e3b61 fs_tosspages+0x29 (0xf5a51bb0, 0x0, 0x0, 0xffffffff, 0xffffffff) kernel .text 0xc0100000 0xc01e3b38 0xc01e3b68 0xc01c36af xfs_itruncate_start+0x8f (0xf5a51b98, 0x1, 0x0, 0x0, 0xf5a51b98) kernel .text 0xc0100000 0xc01c3620 0xc01c36b8 0xc01dcac9 xfs_inactive+0x1b9 (0xf5a51bb0, 0x0) kernel .text 0xc0100000 0xc01dc910 0xc01dcd90 0xc01ec7bf vn_put+0x4b (0xeafb7184) kernel .text 0xc0100000 0xc01ec774 0xc01ec838 0xc01eb9ab linvfs_put_inode+0x17 (0xeafb7060) kernel .text 0xc0100000 0xc01eb994 0xc01eb9b0 0xc0154f2d iput_free+0x2d (0xeafb7060) kernel .text 0xc0100000 0xc0154f00 0xc015510c 0xc0152dc6 d_delete+0x62 (0xeac42560) kernel .text 0xc0100000 0xc0152d64 0xc0152e04 0xc014b81d vfs_unlink+0x1e9 (0xecc287a0, 0xeac42560) kernel .text 0xc0100000 0xc014b634 0xc014b854 0xc014b8fa sys_unlink+0xa6 (0x80529b0, 0x0, 0xbffff4e0, 0x3, 0x80529b0) kernel .text 0xc0100000 0xc014b854 0xc014b978 0xc0107073 system_call+0x33 kernel .text 0xc0100000 0xc0107040 0xc0107078 the system is still usable, but anything that tries to hit that array hangs. any other info I can gather to help debug this? -tduffy From owner-linux-xfs@oss.sgi.com Fri Oct 19 23:26:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9K6QI916505 for linux-xfs-outgoing; Fri, 19 Oct 2001 23:26:18 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9K6QGD16482 for ; Fri, 19 Oct 2001 23:26:16 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9K6Q9K03375 for ; Fri, 19 Oct 2001 23:26:10 -0700 Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id QAA17870; Sat, 20 Oct 2001 16:26:08 +1000 Date: Sat, 20 Oct 2001 16:26:08 +1000 From: Keith Owens Message-Id: <200110200626.QAA17870@sherman.melbourne.sgi.com> Subject: TAKE - Initialise xfsidbg after the main xfs code Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk When xfsidbg is built into the kernel, it must initialise after xfs, not before. Date: Fri Oct 19 23:18:58 PDT 2001 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:105134a linux/fs/xfs/xfsidbg.c - 1.165 linux/fs/xfs/Makefile - 1.128 From owner-linux-xfs@oss.sgi.com Sat Oct 20 03:31:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9KAVT219464 for linux-xfs-outgoing; Sat, 20 Oct 2001 03:31:29 -0700 Received: from bbaer.muenster.de (bbaer.muenster.de [195.202.32.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9KAVOD19442 for ; Sat, 20 Oct 2001 03:31:24 -0700 Received: from server.nick.de (mueasc-wan182.citykom.de [195.202.40.182]) by bbaer.muenster.de (8.9.3/8.9.3) with ESMTP id MAA00954 for ; Sat, 20 Oct 2001 12:31:21 +0200 X-Authentication-Warning: bbaer.muenster.de: Host mueasc-wan182.citykom.de [195.202.40.182] claimed to be server.nick.de Received: from there (linux.nick.de [192.168.1.1]) by server.nick.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id KAA03160 for ; Sat, 20 Oct 2001 10:49:02 +0200 Message-Id: <200110200849.KAA03160@server.nick.de> Content-Type: text/plain; charset="iso-8859-1" From: Nick (Gunnar) Bluth To: linux-xfs@oss.sgi.com Subject: Re: Daily XFS CVS RPMS Date: Sat, 20 Oct 2001 12:13:10 +0200 X-Mailer: KMail [version 1.3.1] References: <200110192316.XAA00329@groucho.maths.monash.edu.au> In-Reply-To: <200110192316.XAA00329@groucho.maths.monash.edu.au> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Am Samstag, 20. Oktober 2001 01:16 schrieb Robin Humble: > If your distro has XF 4.1.* (any yet?) then a newer kernel isn't a problem. [bluth@linux bluth]$ cat /etc/redhat-release Red Hat Linux release 7.2 (Enigma) [bluth@linux bluth]$ xdpyinfo | head name of display: :0.0 version number: 11.0 vendor string: The XFree86 Project, Inc vendor release number: 40100000 XFree86 version: 4.1.0 maximum request size: 4194300 bytes motion buffer size: 256 bitmap unit, bit order, padding: 32, LSBFirst, 32 image byte order: LSBFirst number of supported pixmap formats: 7 [bluth@linux bluth]$ Regards, Nick -- Nick (Gunnar) Bluth Muenster/Germany bluth@muenster.de RHCE/RHCX +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ In 1984 mainstream users were choosing VMS over UNIX. Ten years later they are choosing Windows over UNIX. What part of that message aren't you getting? - Tom Payne From owner-linux-xfs@oss.sgi.com Sat Oct 20 03:49:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9KAnw819799 for linux-xfs-outgoing; Sat, 20 Oct 2001 03:49:58 -0700 Received: from flaske.stud.ntnu.no (flaske.stud.ntnu.no [129.241.56.72]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9KAnrD19777 for ; Sat, 20 Oct 2001 03:49:54 -0700 Received: from jaguar.stud.ntnu.no (jaguar.stud.ntnu.no [129.241.56.181]) by flaske.stud.ntnu.no (Postfix) with ESMTP id 99712FF0CC; Sat, 20 Oct 2001 12:48:51 +0200 (CEST) Received: from localhost (sebastid@localhost) by jaguar.stud.ntnu.no (8.11.6/8.10.0.Beta12) with ESMTP id f9KAnoq26538; Sat, 20 Oct 2001 12:49:50 +0200 X-Authentication-Warning: jaguar.stud.ntnu.no: sebastid owned process doing -bs Date: Sat, 20 Oct 2001 12:49:50 +0200 (CEST) From: Sebastian Dransfeld To: "Nick (Gunnar) Bluth" Cc: Subject: Re: Daily XFS CVS RPMS In-Reply-To: <200110200849.KAA03160@server.nick.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 20 Oct 2001, Nick (Gunnar) Bluth wrote: > Am Samstag, 20. Oktober 2001 01:16 schrieb Robin Humble: > > > If your distro has XF 4.1.* (any yet?) then a newer kernel isn't a problem. > > [bluth@linux bluth]$ cat /etc/redhat-release > Red Hat Linux release 7.2 (Enigma) > [bluth@linux bluth]$ xdpyinfo | head > name of display: :0.0 > version number: 11.0 > vendor string: The XFree86 Project, Inc > vendor release number: 40100000 > XFree86 version: 4.1.0 And Mandrake 8.1 seb From owner-linux-xfs@oss.sgi.com Sat Oct 20 11:25:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9KIPfj26000 for linux-xfs-outgoing; Sat, 20 Oct 2001 11:25:41 -0700 Received: from ente.berdmann.de (frnk-d514e1bb.dsl.mediaWays.net [213.20.225.187]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9KIPTD25975 for ; Sat, 20 Oct 2001 11:25:29 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 15v0oE-0001Ft-00; Sat, 20 Oct 2001 20:25:22 +0200 Message-ID: <3BD1C192.BE0D47C@berdmann.de> Date: Sat, 20 Oct 2001 20:25:22 +0200 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.13-pre3-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: "amanda-users@amanda.org" , Linux XFS Mailing List Subject: Re: xfsdump: "WARNING: failed to get valid bulkstat information for inode 758724" References: <3BCE7025.66B7DDC8@berdmann.de> Content-Type: multipart/mixed; boundary="------------3518FC9634495F4845EF45BC" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------3518FC9634495F4845EF45BC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Bernhard R. Erdmann" wrote: > > Hi, > > every night Amanda emails me these warnings from xfsdump. This seems to > be perfectly normal for more or less active filesystems. > > Where can we tell Amanda to ignore these warnings? > > FAILED AND STRANGE DUMP DETAILS: > > /-- ente /var lev 2 STRANGE > sendbackup: start [ente:/var level 2] > sendbackup: info BACKUP=/usr/sbin/xfsdump > sendbackup: info RECOVER_CMD=/usr/sbin/xfsrestore -f... - > sendbackup: info end > | xfsdump: version 3.0 - Running single-threaded > | xfsdump: level 2 incremental dump of ente:/var based on level 1 dump > begun Mon Oct 15 01:48:51 2001 > | xfsdump: dump date: Thu Oct 18 01:55:31 2001 > | xfsdump: session id: 7da36377-00bd-48f4-afd8-76593ef9b467 > | xfsdump: session label: "" > | xfsdump: ino map phase 1: skipping (no subtrees specified) > | xfsdump: ino map phase 2: constructing initial dump list > ? xfsdump: WARNING: failed to get valid bulkstat information for inode > 758724 > | xfsdump: ino map phase 3: pruning unneeded subtrees > ? xfsdump: WARNING: failed to get valid bulkstat information for inode > 758724 > | xfsdump: ino map phase 4: estimating dump size > ? xfsdump: WARNING: failed to get valid bulkstat information for inode > 758724 > | xfsdump: ino map phase 5: skipping (only one dump stream) > | xfsdump: ino map construction complete > | xfsdump: estimated dump size: 76693376 bytes > | xfsdump: creating dump session media file 0 (media 0, file 0) > | xfsdump: dumping ino map > | xfsdump: dumping directories > ? xfsdump: WARNING: failed to get valid bulkstat information for inode > 758724 > | xfsdump: dumping non-directory files > ? xfsdump: WARNING: failed to get valid bulkstat information for inode > 758724 > | xfsdump: ending media file > | xfsdump: media file size 78355232 bytes > | xfsdump: dump size (non-dir files) : 77925384 bytes > | xfsdump: dump complete: 42 seconds elapsed > | xfsdump: Dump Status: SUCCESS > sendbackup: size 76519 > sendbackup: end > \-------- Now I hacked up Amanda's source code to ignore these WARNINGs. The patch is attached. It's a diff against the current CVS tree of 2.4.2p2 but it works for plain 2.4.2p2, too. The patch introduces a new category DMP_WARNING to the array of regex in client-src/sendbackup-dump.c xfsdump's output is checked against. Adding the "failed to get valid bulkstat" line to DMP_NORMAL didn't help because the regex for DMP_STRANGE containing "[Ff]ail" are checked first in client-src/sendbackup.c. So dmpline_t parse_dumpline(str) would return DMP_STRANGE instead of DMP_NORMAL. Now it returns DMP_WARNING which is handled by void process_dumpline(str) in the same way as DMP_NORMAL and DMP_SIZE. --------------3518FC9634495F4845EF45BC Content-Type: text/plain; charset=us-ascii; name="amanda-sendbackup-xfs-bulkstat.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="amanda-sendbackup-xfs-bulkstat.diff" --- amanda-2.4.2p2-20011020.orig/client-src/sendbackup-dump.c Sat Oct 20 15:59:20 2001 +++ amanda-2.4.2p2-20011020/client-src/sendbackup-dump.c Sat Oct 20 20:12:35 2001 @@ -97,6 +97,9 @@ { DMP_SIZE, "xfsdump: media file size [0-9][0-9]* bytes", 1}, /* Irix 6.2 xfs dump */ + /* warnings to be ignored */ + { DMP_WARNING, "^xfsdump: WARNING: failed to get valid bulkstat information for inode" }, /* Linux xfsdump */ + /* strange dump lines */ { DMP_STRANGE, "should not happen" }, { DMP_STRANGE, "Cannot open" }, --- amanda-2.4.2p2-20011020.orig/client-src/sendbackup.c Sat Oct 20 15:59:20 2001 +++ amanda-2.4.2p2-20011020/client-src/sendbackup.c Sat Oct 20 20:03:05 2001 @@ -755,6 +755,7 @@ switch(typ) { case DMP_NORMAL: case DMP_SIZE: + case DMP_WARNING: startchr = '|'; break; default: --- amanda-2.4.2p2-20011020.orig/client-src/sendbackup.h Sat May 27 23:20:32 2000 +++ amanda-2.4.2p2-20011020/client-src/sendbackup.h Sat Oct 20 20:03:05 2001 @@ -53,7 +53,7 @@ */ typedef enum { - DMP_NORMAL, DMP_STRANGE, DMP_SIZE, DMP_ERROR + DMP_NORMAL, DMP_WARNING, DMP_STRANGE, DMP_SIZE, DMP_ERROR } dmpline_t; typedef struct regex_s { --------------3518FC9634495F4845EF45BC-- From owner-linux-xfs@oss.sgi.com Sat Oct 20 15:41:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9KMfN929463 for linux-xfs-outgoing; Sat, 20 Oct 2001 15:41:23 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9KMfHD29440 for ; Sat, 20 Oct 2001 15:41:17 -0700 Received: from idcomm.com (IDENT:KvJSRL7qQ/vhtj2ZgNZ2mfnQCQ4UbiC5@x2-pip15.idcomm.com [209.60.72.26]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f9KMfeL06843 for ; Sat, 20 Oct 2001 16:41:40 -0600 Message-ID: <3BD1FDB1.4ED31DF5@idcomm.com> Date: Sat, 20 Oct 2001 16:41:53 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Daily XFS CVS RPMS References: <200110192316.XAA00329@groucho.maths.monash.edu.au> <3BD0BD18.2272B325@idcomm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "D. Stimits" wrote: > > Robin Humble wrote: > > > > D. Stimits writes: > > >I haven't tried the newer kernels, but I was under the impression that > > >instead of altering the DRM, a choice was going to be presented to use > > >either the 4.0.x XFree86 version or the 4.1.x XFree86 version, making > > > > The -ac kernels give you a choice, but the Linus kernels only give you > > the new DRM (agpgart) version which doesn't work with XFree 4.0.* and > > hence your tuxracer goes slow. At least mine certainly did :) > > If your distro has XF 4.1.* (any yet?) then a newer kernel isn't a problem. > > That sucks, I don't want to lose DRM if I multiboot between kernels that > have 4.1.x and 4.0.x. Somehow I doubt running both versions is easy or > reasonable. I wonder if NVidia has its DRM out yet for 4.1.x (I guess > SGI is a big participant in DRM area). I should rephrase things. I'm am so dependent on OpenGL that without it, I would have to abandon all future software that breaks it. If this means XFS, or Redhat, or 2.4.x kernels over a certain release, then that is the way it goes. Hardware OpenGL is not an option, it is a requirement. D. Stimits, stimits@idcomm.com > > > > > >them a choice. Is this patch somehow different? > > > > This patch is pulled from the -ac series and lets you choose to build > > an agpgart kernel module (+ drivers for specific cards) as a version > > suitable for XFree 4.0.* or for XFree 4.1.* ... the idea being that > > it's WAY hard to upgrade your X 'cos of all the dependancies, and > > instead it's easier to downgrade the agpgart in newer kernels to > > match the old XFree4.0.* > > ie. it lets the mainstream (and XFS) kernel have the same choices as > > the Alan Cox kernels. > > I've heard there are difficulties in having a kernel that simultaneously > supports both DRM models, though part of it is a matter of naming. I > certainly can't upgrade to any kernel that doesn't have 4.0.x DRM > ability (at least not if NVidia drivers are not available). Since I'm > using XFS, whatever I use has to be XFS as well. > > D. Stimits, stimits@idcomm.com > > > > > cheers, > > robin From owner-linux-xfs@oss.sgi.com Sat Oct 20 17:50:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9L0o8731297 for linux-xfs-outgoing; Sat, 20 Oct 2001 17:50:08 -0700 Received: from home.smithconcepts.com (65.34.25.157.oviedo-ubr-a.cfl.rr.com [65.34.25.157]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9L0o4D31275 for ; Sat, 20 Oct 2001 17:50:05 -0700 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id UAA20253; Sat, 20 Oct 2001 20:42:45 -0400 Message-ID: <3BD21BAC.B79965AF@ieee.org> Date: Sat, 20 Oct 2001 20:49:48 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts, Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS101_K7mp i686) X-Accept-Language: en MIME-Version: 1.0 To: stimits@idcomm.com CC: linux-xfs@oss.sgi.com Subject: Re: Daily XFS CVS RPMS References: <200110192316.XAA00329@groucho.maths.monash.edu.au> <3BD0BD18.2272B325@idcomm.com> <3BD1FDB1.4ED31DF5@idcomm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "D. Stimits" wrote: > I should rephrase things. I'm am so dependent on OpenGL that without it, > I would have to abandon all future software that breaks it. If this > means XFS, or Redhat, or 2.4.x kernels over a certain release, then that > is the way it goes. Hardware OpenGL is not an option, it is a > requirement. Why not go nVidia then??? You can use both the kernel AGPgart as well as try the built-in one in the driver itself. I've run with it both ways on Intel, ViA, AMD _and_ SiS chips for both Intel and AMD processors. -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ------------------------------------------------------------------ Those living in the US who consider the American flag to be a sym- bol of oppression obviously fail to understand what the word means From owner-linux-xfs@oss.sgi.com Sat Oct 20 19:40:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9L2enQ00346 for linux-xfs-outgoing; Sat, 20 Oct 2001 19:40:49 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9L2eiD00323 for ; Sat, 20 Oct 2001 19:40:44 -0700 Received: from idcomm.com (IDENT:g3Cng4EAu4aL2QiS89sGhq2JouZtqo72@x2-pip23.idcomm.com [209.60.72.34]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f9L2f8L31072 for ; Sat, 20 Oct 2001 20:41:08 -0600 Message-ID: <3BD235D0.F8014762@idcomm.com> Date: Sat, 20 Oct 2001 20:41:20 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: Daily XFS CVS RPMS References: <200110192316.XAA00329@groucho.maths.monash.edu.au> <3BD0BD18.2272B325@idcomm.com> <3BD1FDB1.4ED31DF5@idcomm.com> <3BD21BAC.B79965AF@ieee.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Bryan-TheBS-Smith wrote: > > "D. Stimits" wrote: > > I should rephrase things. I'm am so dependent on OpenGL that without it, > > I would have to abandon all future software that breaks it. If this > > means XFS, or Redhat, or 2.4.x kernels over a certain release, then that > > is the way it goes. Hardware OpenGL is not an option, it is a > > requirement. > > Why not go nVidia then??? You can use both the kernel AGPgart as > well as try the built-in one in the driver itself. I've run with it > both ways on Intel, ViA, AMD _and_ SiS chips for both Intel and AMD > processors. I do use it. But I use it with XFree86 4.0.3. I was not aware of 4.1.x versions being available. And if available, it requires me to upgrade X11 4.1.x, which is not an easy task. This would also cause me to dedicate to kernels with 4.1.x support, and no longer be able to boot my "trusted/tested" versions. It is a dangerous one-way path to 4.1.x...if it goes badly, downgrading to 4.0.3 isn't much of an option, I would guess that at that point one would be better off fdisk and clean reinstall. I can't even *test* a kernel that doesn't work with 4.0.3 and hardware OpenGL support, so until both are supported, it isn't an option. According to reports, the Linus kernels (which are what SGI XFS kernels merge with) do not allow me to use both 4.1.x and 4.0.x, only the -ac versions do. From my point of view, this makes Linus kernels inferior. D. Stimits, stimits@idcomm.com > > -- TheBS > > -- > Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 > Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org > President SmithConcepts, Inc. http://www.SmithConcepts.com > ------------------------------------------------------------------ > Those living in the US who consider the American flag to be a sym- > bol of oppression obviously fail to understand what the word means From owner-linux-xfs@oss.sgi.com Sat Oct 20 20:09:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9L39xg00804 for linux-xfs-outgoing; Sat, 20 Oct 2001 20:09:59 -0700 Received: from groucho.maths.monash.edu.au (groucho.maths.monash.edu.au [130.194.160.211]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9L39sD00779 for ; Sat, 20 Oct 2001 20:09:54 -0700 Received: (from rjh@localhost) by groucho.maths.monash.edu.au (8.8.8/8.8.8) id DAA04579 for linux-xfs@oss.sgi.com; Sun, 21 Oct 2001 03:09:52 GMT From: Robin Humble Message-Id: <200110210309.DAA04579@groucho.maths.monash.edu.au> Subject: OpenGL + Alpha XFS question (was Re: Daily XFS CVS RPMS) To: linux-xfs@oss.sgi.com Date: Sun, 21 Oct 2001 13:09:52 +1000 (EST) In-Reply-To: <3BD235D0.F8014762@idcomm.com> from "D. Stimits" at Oct 20, 2001 08:41:20 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk D. Stimits wrote: >Bryan-TheBS-Smith wrote: >> Why not go nVidia then??? You can use both the kernel AGPgart as >> well as try the built-in one in the driver itself. I've run with it >> both ways on Intel, ViA, AMD _and_ SiS chips for both Intel and AMD >> processors. >"trusted/tested" versions. It is a dangerous one-way path to 4.1.x...if >it goes badly, downgrading to 4.0.3 isn't much of an option, I would it's not so hard. before upgrading 'rpm -qa | grep XF > oldX' ; init 3 and save your XF86Confg-4. then try to update X rpms and keep track of the other rpms you have to update too... then if it doesn't work you can just rpm -e all the new crap and put back the orig rpms (or try rpm --downgrade). A bit a pain but no lossage... >option. According to reports, the Linus kernels (which are what SGI XFS >kernels merge with) do not allow me to use both 4.1.x and 4.0.x, only >the -ac versions do. From my point of view, this makes Linus kernels >inferior. Just to clarify the -ac kernels support an either/or model. So if you want both 4.1.x and 4.0.x to work at the same time you're out of luck - you'll at least have to play with module names (if you compiled twice and renamed agp modules appropriately), or reboot to a kernel with the other flavour of AGP support. I have no idea what the NVidia agp support is like - perhaps that doesn't care what kernel agpgart version you have... Just to drag this topic back to XFS - a friend is installing on Alphas and gets a kernel panic when xfs_check or xfs_repair is run... is this a known problem? He's using the XFS for Alpha RH7.1 installer I presume that's the Release 1.0.1 Alpha-XFS-Installer-PR1.iso ... Would a cvs kernel and xfsprogs help any? cheers, robin From owner-linux-xfs@oss.sgi.com Sat Oct 20 20:21:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9L3LkX01085 for linux-xfs-outgoing; Sat, 20 Oct 2001 20:21:46 -0700 Received: from bbaer.muenster.de (bbaer.muenster.de [195.202.32.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9L3LgD01062 for ; Sat, 20 Oct 2001 20:21:42 -0700 Received: from server.nick.de (mueasb-wan087.citykom.de [195.202.39.87]) by bbaer.muenster.de (8.9.3/8.9.3) with ESMTP id FAA31489; Sun, 21 Oct 2001 05:21:40 +0200 X-Authentication-Warning: bbaer.muenster.de: Host mueasb-wan087.citykom.de [195.202.39.87] claimed to be server.nick.de Received: from there (linux.nick.de [192.168.1.1]) by server.nick.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id AAA02493; Sun, 21 Oct 2001 00:20:59 +0200 Message-Id: <200110202220.AAA02493@server.nick.de> Content-Type: text/plain; charset="iso-8859-1" From: Nick (Gunnar) Bluth To: stimits@idcomm.com, linux-xfs@oss.sgi.com Subject: Re: Daily XFS CVS RPMS Date: Sun, 21 Oct 2001 01:44:07 +0200 X-Mailer: KMail [version 1.3.1] References: <200110192316.XAA00329@groucho.maths.monash.edu.au> <3BD0BD18.2272B325@idcomm.com> <3BD1FDB1.4ED31DF5@idcomm.com> In-Reply-To: <3BD1FDB1.4ED31DF5@idcomm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Am Sonntag, 21. Oktober 2001 00:41 schrieb D. Stimits: > > That sucks, I don't want to lose DRM if I multiboot between kernels that > > have 4.1.x and 4.0.x. Somehow I doubt running both versions is easy or > > reasonable. I wonder if NVidia has its DRM out yet for 4.1.x (I guess > > SGI is a big participant in DRM area). > > I should rephrase things. I'm am so dependent on OpenGL that without it, > I would have to abandon all future software that breaks it. If this > means XFS, or Redhat, or 2.4.x kernels over a certain release, then that > is the way it goes. Hardware OpenGL is not an option, it is a > requirement. Don't see your problem... NVidia doesn't use DRM at all, they use their own kernel driver (which I compiled yesterday for 2.4.12-ac3)... Nick -- Nick (Gunnar) Bluth Muenster/Germany bluth@muenster.de RHCE/RHCX +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ In 1984 mainstream users were choosing VMS over UNIX. Ten years later they are choosing Windows over UNIX. What part of that message aren't you getting? - Tom Payne From owner-linux-xfs@oss.sgi.com Sat Oct 20 20:40:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9L3eZW01546 for linux-xfs-outgoing; Sat, 20 Oct 2001 20:40:35 -0700 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9L3eVD01520 for ; Sat, 20 Oct 2001 20:40:32 -0700 Received: (qmail 25350 invoked from network); 21 Oct 2001 03:40:26 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 21 Oct 2001 03:40:26 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id BE770300090; Sun, 21 Oct 2001 13:40:23 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id B175598; Sun, 21 Oct 2001 13:40:23 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Robin Humble Cc: linux-xfs@oss.sgi.com Subject: Re: OpenGL + Alpha XFS question (was Re: Daily XFS CVS RPMS) In-reply-to: Your message of "Sun, 21 Oct 2001 13:09:52 +1000." <200110210309.DAA04579@groucho.maths.monash.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 21 Oct 2001 13:40:18 +1000 Message-ID: <5481.1003635618@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 21 Oct 2001 13:09:52 +1000 (EST), Robin Humble wrote: >Just to drag this topic back to XFS - a friend is installing on Alphas >and gets a kernel panic when xfs_check or xfs_repair is run... is this a >known problem? He's using the XFS for Alpha RH7.1 installer I presume >that's the Release 1.0.1 Alpha-XFS-Installer-PR1.iso ... Would a cvs kernel >and xfsprogs help any? Sounds like the unaligned access problems in xfs_repair that Nathan Scott fixed last week. Grab the cmd directory from the CVS tree and build your own xfsprogs. From owner-linux-xfs@oss.sgi.com Sat Oct 20 20:49:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9L3nxs01762 for linux-xfs-outgoing; Sat, 20 Oct 2001 20:49:59 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9L3nsD01740 for ; Sat, 20 Oct 2001 20:49:54 -0700 Received: from idcomm.com (IDENT:yVk1YhaLQ3EokMYOGZYPhafnS0miEPCy@x2-pip11.idcomm.com [209.60.72.22]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f9L3oJL04396 for ; Sat, 20 Oct 2001 21:50:19 -0600 Message-ID: <3BD24607.2BFAB6E@idcomm.com> Date: Sat, 20 Oct 2001 21:50:31 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: Daily XFS CVS RPMS References: <200110192316.XAA00329@groucho.maths.monash.edu.au> <3BD0BD18.2272B325@idcomm.com> <3BD1FDB1.4ED31DF5@idcomm.com> <200110202220.AAA02493@server.nick.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "Nick (Gunnar) Bluth" wrote: > > Am Sonntag, 21. Oktober 2001 00:41 schrieb D. Stimits: > > > > That sucks, I don't want to lose DRM if I multiboot between kernels that > > > have 4.1.x and 4.0.x. Somehow I doubt running both versions is easy or > > > reasonable. I wonder if NVidia has its DRM out yet for 4.1.x (I guess > > > SGI is a big participant in DRM area). > > > > I should rephrase things. I'm am so dependent on OpenGL that without it, > > I would have to abandon all future software that breaks it. If this > > means XFS, or Redhat, or 2.4.x kernels over a certain release, then that > > is the way it goes. Hardware OpenGL is not an option, it is a > > requirement. > > Don't see your problem... NVidia doesn't use DRM at all, they use their own > kernel driver (which I compiled yesterday for 2.4.12-ac3)... I don't know if the NVidia stuff is merely binary-only, and follows DRM specs, or if it is both binary-only AND uses its own DRM infrastructure. >From what has been said, it *appears* that a kernel configured for 4.1.x DRM will not work with NVidia...I don't know, this is part of the confusion. As for any other video card (non-NVidia), the problem still persists, I have another machine with a non-NVidia card in it (which incidentally seems to be flaking out). D. Stimits, stimits@idcomm.com > > Nick > > -- > Nick (Gunnar) Bluth Muenster/Germany bluth@muenster.de RHCE/RHCX > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > In 1984 mainstream users were choosing VMS over UNIX. Ten years later > they are choosing Windows over UNIX. What part of that message aren't you > getting? - Tom Payne From owner-linux-xfs@oss.sgi.com Sun Oct 21 05:07:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9LC7ZM12681 for linux-xfs-outgoing; Sun, 21 Oct 2001 05:07:35 -0700 Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9LC7WD12658 for ; Sun, 21 Oct 2001 05:07:32 -0700 Received: from [195.20.224.208] (helo=mrvdom01.schlund.de) by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 15vHO5-00087a-00; Sun, 21 Oct 2001 14:07:29 +0200 Received: from pd9e49d3c.dip.t-dialin.net ([217.228.157.60] helo=kernelpanix.aura.of.mankind) by mrvdom01.schlund.de with esmtp (Exim 2.12 #2) id 15vHO4-0008Pt-00; Sun, 21 Oct 2001 14:07:29 +0200 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.11.2/8.11.2) id f9LC7R403020; Sun, 21 Oct 2001 14:07:27 +0200 X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f Date: Sun, 21 Oct 2001 14:07:27 +0200 From: utz lehmann To: "D. Stimits" Cc: linux-xfs@oss.sgi.com Subject: Re: Daily XFS CVS RPMS Message-ID: <20011021140727.A2809@s2y4n2c.de> References: <200110192316.XAA00329@groucho.maths.monash.edu.au> <3BD0BD18.2272B325@idcomm.com> <3BD1FDB1.4ED31DF5@idcomm.com> <200110202220.AAA02493@server.nick.de> <3BD24607.2BFAB6E@idcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BD24607.2BFAB6E@idcomm.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi D. Stimits [stimits@idcomm.com] wrote: > I don't know if the NVidia stuff is merely binary-only, and follows DRM > specs, or if it is both binary-only AND uses its own DRM infrastructure. Its (mostly) binary only and has its own kernelinterface (/dev/nvidia*). > >From what has been said, it *appears* that a kernel configured for 4.1.x > DRM will not work with NVidia...I don't know, this is part of the > confusion. That is not true. You _dont_ need DRM support at all for the nvidia driver. utz From owner-linux-xfs@oss.sgi.com Sun Oct 21 07:20:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9LEKmo14387 for linux-xfs-outgoing; Sun, 21 Oct 2001 07:20:48 -0700 Received: from pavidus.matematik.su.se (pavidus.matematik.su.se [130.237.198.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9LEKgD14362 for ; Sun, 21 Oct 2001 07:20:43 -0700 Received: from te.matematik.su.se (te.matematik.su.se [130.237.198.69]) by pavidus.matematik.su.se (8.9.3/8.9.3) with ESMTP id QAA16716 for ; Sun, 21 Oct 2001 16:20:40 +0200 Date: Sun, 21 Oct 2001 16:20:40 +0200 (CEST) From: Tomas Ericsson To: Subject: Request for XFS kernel rpms for the newly released RedHat 7.1 Linux kernel update Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, First, thank you very much for providing the opensource community with the XFS filesystem. I have been using it in a production environment for some time now and I have had no problems at all, only increased performance! :-) As you may now RedHat has now released updated kernel rpm's for their latest RedHat 7.1 Linux distribution. The updated Linux kernel is now 2.4.9-6 . Check for yourself: ftp://ftp.redhat.com/pub/redhat/linux/updates/7.1/en/os/i386/ kernel-2.4.9-6.i386.rpm kernel-BOOT-2.4.9-6.i386.rpm kernel-doc-2.4.9-6.i386.rpm kernel-headers-2.4.9-6.i386.rpm kernel-source-2.4.9-6.i386.rpm Could you please patch this one with XFS support and provide it at you ftp-site like this (or something other appropriate): ftp://oss.sgi.com/projects/xfs/download/Release-1.0.1/kernel_rpms/RHlinux-2.4.9/ Thanks in advance, it would be really nice if you did that quite soon because there are some security flaws in the current 2.4.3-kernel. Best regards, Tomas Ericsson From owner-linux-xfs@oss.sgi.com Sun Oct 21 07:29:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9LETRA14581 for linux-xfs-outgoing; Sun, 21 Oct 2001 07:29:27 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9LETMD14558 for ; Sun, 21 Oct 2001 07:29:22 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA15626 for ; Sun, 21 Oct 2001 07:29:17 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA3338373; Sun, 21 Oct 2001 09:28:05 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA24492; Sun, 21 Oct 2001 09:28:05 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9LEOx027749; Sun, 21 Oct 2001 09:24:59 -0500 Message-Id: <200110211424.f9LEOx027749@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Tomas Ericsson cc: linux-xfs@oss.sgi.com Subject: Re: Request for XFS kernel rpms for the newly released RedHat 7.1 Linux kernel update In-Reply-To: Message from Tomas Ericsson of "Sun, 21 Oct 2001 16:20:40 +0200." Date: Sun, 21 Oct 2001 09:24:59 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Working on it - see messages on the list, kernel rpms are not created overnight. We need to intergrate xfs into the specific revision of the kernel (which in redhat's case includes a large number of patches), do a fair amount of testing, and build the actual packages - oh and do all the other work we were doing too. In the meantime if you are concerned about the security exploits you can build your own kernel using the cvs tree or patches on the xfs ftp site. 2.4.12 or later fixes the problems. Steve > Hello, > > First, thank you very much for providing the opensource community with the > XFS filesystem. I have been using it in a production environment for > some time now and I have had no problems at all, only increased > performance! :-) > > As you may now RedHat has now released updated kernel rpm's for their > latest RedHat 7.1 Linux distribution. The updated Linux kernel is now > 2.4.9-6 . Check for yourself: > > ftp://ftp.redhat.com/pub/redhat/linux/updates/7.1/en/os/i386/ > kernel-2.4.9-6.i386.rpm > kernel-BOOT-2.4.9-6.i386.rpm > kernel-doc-2.4.9-6.i386.rpm > kernel-headers-2.4.9-6.i386.rpm > kernel-source-2.4.9-6.i386.rpm > > Could you please patch this one with XFS support and provide it at you > ftp-site like this (or something other appropriate): > > ftp://oss.sgi.com/projects/xfs/download/Release-1.0.1/kernel_rpms/RHlinux-2.4 > .9/ > > Thanks in advance, it would be really nice if you did that quite soon > because there are some security flaws in the current 2.4.3-kernel. > > > Best regards, > > Tomas Ericsson From owner-linux-xfs@oss.sgi.com Sun Oct 21 10:39:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9LHdDa16959 for linux-xfs-outgoing; Sun, 21 Oct 2001 10:39:13 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9LHd9D16937 for ; Sun, 21 Oct 2001 10:39:09 -0700 Received: from idcomm.com (IDENT:JHsYIkT30tMxUjLzINyCv0ARZlg+ryb8@x2-pip31.idcomm.com [209.60.72.42]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f9LHdbL29850 for ; Sun, 21 Oct 2001 11:39:37 -0600 Message-ID: <3BD30862.7955A0A3@idcomm.com> Date: Sun, 21 Oct 2001 11:39:46 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: Daily XFS CVS RPMS References: <200110192316.XAA00329@groucho.maths.monash.edu.au> <3BD0BD18.2272B325@idcomm.com> <3BD1FDB1.4ED31DF5@idcomm.com> <200110202220.AAA02493@server.nick.de> <3BD24607.2BFAB6E@idcomm.com> <20011021140727.A2809@s2y4n2c.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk utz lehmann wrote: > > Hi > > D. Stimits [stimits@idcomm.com] wrote: > > I don't know if the NVidia stuff is merely binary-only, and follows DRM > > specs, or if it is both binary-only AND uses its own DRM infrastructure. > > Its (mostly) binary only and has its own kernelinterface (/dev/nvidia*). > > > >From what has been said, it *appears* that a kernel configured for 4.1.x > > DRM will not work with NVidia...I don't know, this is part of the > > confusion. > > That is not true. You _dont_ need DRM support at all for the nvidia driver. > > utz This would be welcome news for my machine with NVidia. I assume it is still possible to get hardware accel? On the other hand, how will this work on the machine with non-NVidia hardware...will it be able to run 4.0.3 on all kernels it boots? Or will I need to run 4.1.x? And if I run 4.1.x, will I have at least as good of a quality (rephrased, stable and reasonable frame rate) OpenGL hardware accel as with 4.0.3? D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Sun Oct 21 11:12:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9LICwQ17416 for linux-xfs-outgoing; Sun, 21 Oct 2001 11:12:58 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9LICrD17393 for ; Sun, 21 Oct 2001 11:12:54 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 0EA98C00B61 for ; Mon, 22 Oct 2001 02:12:51 +0800 (PHT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id BDB1FC00B60 for ; Mon, 22 Oct 2001 02:12:49 +0800 (PHT) Date: Mon, 22 Oct 2001 02:12:49 +0800 (PHT) From: Federico Sevilla III To: Linux XFS Mailing List Subject: Re: VIA 686b Bug - once again :( In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 21 Oct 2001 at 19:11, Alan Cox wrote: > > Eh? This is interesting. I haven't heard of anything like this before, and > > can't find anything in their website. Maybe you can point me to where you > > got this bit of information? Rather alarming because I've got a 3ware > > controller myself. > > I heard this straight from a 3ware representative Ack! :( Thanks for validating Stefan's news. I presume (hope) support via the open-source driver already with the Linux community will continue as usual, even in the worst case scenario where 3ware decides to drop support completely? :) --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Sun Oct 21 17:40:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9M0eZB22668 for linux-xfs-outgoing; Sun, 21 Oct 2001 17:40:35 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9M0eTD22646 for ; Sun, 21 Oct 2001 17:40:29 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9M0eMK20713 for ; Sun, 21 Oct 2001 17:40:22 -0700 Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA46947; Mon, 22 Oct 2001 10:39:04 +1000 (AEST) Date: Mon, 22 Oct 2001 10:39:03 +1000 From: Timothy Shimmin To: "Ngan, Michael (NCI)" Cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump: WARNING: unable to backspace tape: assuming media error Message-ID: <20011022103903.H23760@boing.melbourne.sgi.com> References: <59445348FF4CD41182CF00508B6F779C02D73DC5@nihexchange11.nih.gov> <20011019170808.BECE1726.fep06-app.kolumbus.fi@there> <59445348FF4CD41182CF00508B6F779C02D73DC5@nihexchange11.nih.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <59445348FF4CD41182CF00508B6F779C02D73DC5@nihexchange11.nih.gov>; from nganm@mail.nih.gov on Fri, Oct 19, 2001 at 12:41:03PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Mike, As Hristo kindly points out, since this is an SGI IRIX box, you should contact your local SGI support for this problem. Thanks. It _may_ be the case that the tape drive is not fully supported by the IRIX scsi tape driver. Xfsdump uses more mt commands and status tests than what tar uses. --Tim On Fri, Oct 19, 2001 at 12:41:03PM -0400, Ngan, Michael (NCI) wrote: > Hi, > > I am try to setup a IBM LTO Ultrium-td1 tape with a SGI Orign 2000 running > IRIX 6.5.9. I encounter this error message when I tried to do test dump > > xfsdump: WARNING: unable to backspace tape: assuming media error > > What is the problem? Is there are fix to this? The tar command works. > > thanks, > > Mike Ngan > National Cancer Institute > 301-402-0324 > > root@msb:/hw/tape> xfsdump -f /dev/nrtape -L "Test" -M "Tape" / > xfsdump: version 3.0 - type ^C for status and control ... > xfsdump: estimated dump size: 5721094016 bytes > xfsdump: preparing drive > xfsdump: WARNING: unable to backspace tape: assuming media error > > > root@msb:/hw/tape> mt -f /dev/mt/tps1d3nr status > Controller: SCSI > Device: IBM: ULTRIUM-TD1 1550 > Status: 0x24260 > Drive type: unknown > Media : READY, writable, at EOD, block 3 On Fri, Oct 19, 2001 at 08:08:17PM +0300, Hristo Grigorov wrote: > > Eh, please check... You should have official support from SGI for that... :) > Not that here is not official but it is Linux related. > > Regards, Hristo. > From owner-linux-xfs@oss.sgi.com Mon Oct 22 02:42:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9M9gE129904 for linux-xfs-outgoing; Mon, 22 Oct 2001 02:42:14 -0700 Received: from mail.cc.kuleuven.ac.be (mail.cc.kuleuven.ac.be [134.58.10.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9M9gAD29882 for ; Mon, 22 Oct 2001 02:42:10 -0700 Received: from pclab.cc.kuleuven.ac.be (pc-10-33-6-229.cc.kuleuven.ac.be [10.33.6.229]) by mail.cc.kuleuven.ac.be (8.9.3/8.9.0) with ESMTP id LAA1187450; Mon, 22 Oct 2001 11:41:43 +0200 Message-Id: <5.1.0.14.2.20011022114011.00a5d3d0@pb429905.kuleuven.be> X-Sender: pb429905@pb429905.kuleuven.be X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 22 Oct 2001 11:42:17 +0200 To: Steve Lord , erich@uruk.org From: werner maes Subject: Re: kernel update for RH7.1 users? Cc: Seth Mos , linux-xfs@oss.sgi.com In-Reply-To: <200110191525.f9JFPX911794@jen.americas.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Another thing I was thinking about: What about when RedHat releases 7.2 with ext3 as a choice for a JFS. Will SGI provide an upgrade path to 7.2 with XFS instead of ext3. I can imagine that the default RedHat installer will not recognize a XFS partition. Or am I wrong? Werner From owner-linux-xfs@oss.sgi.com Mon Oct 22 03:02:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MA2HD30434 for linux-xfs-outgoing; Mon, 22 Oct 2001 03:02:17 -0700 Received: from maties2.sun.ac.za (maties2.sun.ac.za [146.232.128.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MA2BD30412 for ; Mon, 22 Oct 2001 03:02:12 -0700 Received: from www.cae.sun.ac.za ([146.232.145.5] helo=mail.cae.co.za) by maties2.sun.ac.za with esmtp (Exim 3.33 #3) id 15vbty-0007RU-00; Mon, 22 Oct 2001 12:01:46 +0200 Received: by mail.cae.co.za (Postfix, from userid 239) id E8DB71C323; Mon, 22 Oct 2001 11:54:29 +0200 (SAST) Received: from cae.co.za (bgmilne.cae.co.za [146.232.174.36]) by mail.cae.sun.ac.za (Postfix) with ESMTP id B7F7A1C2C7; Mon, 22 Oct 2001 11:54:24 +0200 (SAST) Message-ID: <3BD3EDF8.6090607@cae.co.za> Date: Mon, 22 Oct 2001 11:59:20 +0200 From: Buchan Milne User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Cc: Sylvestre Taburet Subject: Samba 2.2.2 and XFS quotas Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: scanned for viruses at mail.cae.co.za by AMaViS 0.2.1 (http://amavis.org/) X-Scanner: exiscan *15vbty-0007RU-00*grN9DTtqTOA* http://duncanthrax.net/exiscan/ Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sylvestre Taburet and I are working on updates to samba-2.2.2 for Mandrake 8.1. Since Mandrake 8.1 shipped with XFS, we would like to keep working samba/XFS/quotas. In the package of samba-2.2.1a, we applied the patch by Nathan Scott: (http://marc.theaimsgroup.com/?l=linux-xfs&m=100002981924172&w=2). We have forwarded the patch to samba developers, but they would prefer a patch against current CVS tag SAMBA_2_2. Is there someone on this list who can take a look at this? If a working patch is available, I will ensure that it makes it into samba cvs. (unofortunately, that's all I can offer, since I am no hacker ...) Here is a link to the quota.c in samba's cvsweb: http://pserver.samba.org/cgi-bin/cvsweb/samba/source/smbd/quotas.c?only_with_tag=SAMBA_2_2 Regards, Buchan -- |----------------Registered Linux User #182071-----------------| Buchan Milne Mechanical Engineer, Network Manager Cellphone * Work +27 82 472 2231 * +27 21 808 2497 ext 202 Stellenbosch Automotive Engineering http://www.cae.co.za From owner-linux-xfs@oss.sgi.com Mon Oct 22 04:40:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MBeBC31928 for linux-xfs-outgoing; Mon, 22 Oct 2001 04:40:11 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MBe8D31905 for ; Mon, 22 Oct 2001 04:40:09 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id NAA19694 for ; Mon, 22 Oct 2001 13:40:07 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id NAA25007 for linux-xfs@oss.sgi.com; Mon, 22 Oct 2001 13:40:07 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id B4A7357306 for ; Mon, 22 Oct 2001 13:39:51 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 9D94525835 for ; Mon, 22 Oct 2001 13:39:51 +0200 (CEST) Message-ID: <3BD40587.BAF4A871@ch.sauter-bc.com> Date: Mon, 22 Oct 2001 13:39:51 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: linux-xfs Subject: RedHat 7.2 has 2.4.9 Kernel as update Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I just found the RedHat 7.2 updates and they include 2.4.9 like with RedHat 7.1. Interesting to see a distro where you can download updates before the product is available. -Simon From owner-linux-xfs@oss.sgi.com Mon Oct 22 05:23:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MCNq432755 for linux-xfs-outgoing; Mon, 22 Oct 2001 05:23:52 -0700 Received: from graendal.lightconsulting.com (c498624-a.frmt1.sfba.home.com [24.15.81.65]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MCNkD32732 for ; Mon, 22 Oct 2001 05:23:46 -0700 Received: (from thalakan@localhost) by graendal.lightconsulting.com (8.11.6/8.11.3) id f9MCNkZ60959 for linux-xfs@oss.sgi.com; Mon, 22 Oct 2001 05:23:46 -0700 (PDT) (envelope-from thalakan) Date: Mon, 22 Oct 2001 05:23:46 -0700 From: Jason Spence To: linux-xfs@oss.sgi.com Subject: Cannot mount IRIX cdroms using XFS on Linux Message-ID: <20011022052346.A60926@graendal.lightconsulting.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD graendal.lightconsulting.com 4.4-RELEASE FreeBSD 4.4-RELEASE Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk So I just got an Indy and an Indigo 2 as payment for some work I did. What fun! They're nice hardware, I really like them. I like them so much that I want to get IRIX installed on the Indigo 2 so I can play around with OpenGL some. IRIX already works great on the Indy :) So I get XFS working on my Linux machine[1], and try to mount the IRIX dist cdroms. Hmm, they don't mount. The kernel doesn't even recognize /dev/hdd1 as a device (fdisk can parse the partition table, though). The kernel has SGI partition table support, right? Yeah, I can mount the IRIX drive from the Indy. So lessee here, the sgi partition tables are read by a function called sgi_partition in fs/partitions/sgi.c, and that's... hmm, what's this?: fs/partitions/check.c: 215 /* 216 * This is a kludge to allow the partition check to be 217 * skipped for specific drives (e.g. IDE CD-ROM drives) 218 */ 219 if ((int)first_sector == -1) { 220 hd->part[MINOR(dev)].start_sect = 0; 221 return; 222 } Well, if I comment that out, it still doesn't read the partition table on the IRIX cdrom. Does anyone have any ideas? [1] Hint to Debian users: the xfs patches from SGI don't apply to the kernel-source Debian packages cleanly. But the official kernel tarballs can't boot from cramfs initrds. You need to get the cramfs initrd patch for your system to boot. And don't forget ramdisk_blocksize=4096 in your kernel parameters. -- - Jason A journey of a thousand miles begins with a cash advance. From owner-linux-xfs@oss.sgi.com Mon Oct 22 05:30:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MCUM400597 for linux-xfs-outgoing; Mon, 22 Oct 2001 05:30:22 -0700 Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MCUJD00569 for ; Mon, 22 Oct 2001 05:30:19 -0700 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.6/8.11.6) with ESMTP id f9MCUG516320; Mon, 22 Oct 2001 08:30:16 -0400 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Mon, 22 Oct 2001 08:30:16 -0400 (EDT) From: Joshua Baker-LePain X-X-Sender: To: Jason Spence cc: Subject: Re: Cannot mount IRIX cdroms using XFS on Linux In-Reply-To: <20011022052346.A60926@graendal.lightconsulting.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 22 Oct 2001 at 5:23am, Jason Spence wrote > So I get XFS working on my Linux machine[1], and try to mount the IRIX > dist cdroms. Hmm, they don't mount. The kernel doesn't even > recognize /dev/hdd1 as a device (fdisk can parse the partition table, > though). The kernel has SGI partition table support, right? Yeah, I > can mount the IRIX drive from the Indy. So lessee here, the sgi IIRC, IRIX distro CDs are EFS, not XFS... -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Mon Oct 22 05:34:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MCYrv00840 for linux-xfs-outgoing; Mon, 22 Oct 2001 05:34:53 -0700 Received: from ns.caldera.de (ns.caldera.de [212.34.180.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MCYoD00816 for ; Mon, 22 Oct 2001 05:34:50 -0700 Received: (from hch@localhost) by ns.caldera.de (8.11.1/8.11.1) id f9MCYRa14785; Mon, 22 Oct 2001 14:34:27 +0200 Date: Mon, 22 Oct 2001 14:34:27 +0200 From: Christoph Hellwig To: Joshua Baker-LePain Cc: Jason Spence , linux-xfs@oss.sgi.com Subject: Re: Cannot mount IRIX cdroms using XFS on Linux Message-ID: <20011022143427.A14386@caldera.de> References: <20011022052346.A60926@graendal.lightconsulting.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jlb17@duke.edu on Mon, Oct 22, 2001 at 08:30:16AM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Oct 22, 2001 at 08:30:16AM -0400, Joshua Baker-LePain wrote: > On Mon, 22 Oct 2001 at 5:23am, Jason Spence wrote > > > So I get XFS working on my Linux machine[1], and try to mount the IRIX > > dist cdroms. Hmm, they don't mount. The kernel doesn't even > > recognize /dev/hdd1 as a device (fdisk can parse the partition table, > > though). The kernel has SGI partition table support, right? Yeah, I > > can mount the IRIX drive from the Indy. So lessee here, the sgi > > IIRC, IRIX distro CDs are EFS, not XFS... *nod* But EFs is supported (read-only) by Linux 2.2.1+. So try mount -t efs. Christoph -- Of course it doesn't work. We've performed a software upgrade. From owner-linux-xfs@oss.sgi.com Mon Oct 22 05:39:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MCdZN00997 for linux-xfs-outgoing; Mon, 22 Oct 2001 05:39:35 -0700 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MCdQD00974 for ; Mon, 22 Oct 2001 05:39:26 -0700 Received: from inf.ethz.ch (IDENT:schmitt@ikarus.inf.ethz.ch [129.132.10.58]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id OAA00170; Mon, 22 Oct 2001 14:39:20 +0200 (MET DST) Message-ID: <3BD4137A.8040406@inf.ethz.ch> Date: Mon, 22 Oct 2001 14:39:22 +0200 From: Marc Schmitt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com CC: florin@sgi.com Subject: Corruption of in-memory data detected. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello all, I`m currently setting up a 1.2TB file server and consider using XFS. The configuration is: - STL2 MB with 512MB RAM, 2 CPUs (866MHz) - 3 x 3ware RAID Controller - 20 x 80GB disks attached in blocks of 4 with RAID 5 (5x240GB) - md0 is a RAID 0 over the 5 RAID 5 devices I tested a couple of XFS-enabled kernels and got the following results when using mongo.pl: Output of mongo.pl (same for all tests): reiser_fract_tree is up to date ... mongo_slinks is up to date ... mongo_read is up to date ... map5 is up to date ... summ is up to date ... umount: /local: not mounted meta-data=/dev/md0 isize=512 agcount=280, agsize=1048576 blks data = bsize=4096 blocks=293055600, imaxpct=25 = sunit=8 swidth=40 blks, unwritten=0 = imaxbits=32 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=32768 realtime =none extsz=163840 blocks=0, rtextents=0 mongo_single_process, the_set_of_param.N=0 of 3 Results in file : /root/mongo_pl/results/bla 1.Create files of median size 100 bytes (1 processes)... Create : open: Invalid argument real 0.34 user 0.04 sys 0.28 Create : open: No such file or directory real 0.04 user 0.04 sys 0.00 Create : open: No such file or directory real 0.04 user 0.04 sys 0.00 total Create time: 0 sec. Used disk space (df) : 480 KB Total dirs: 1 Total files: 0 Illegal division by zero at ./mongo.pl line 377. Console outputs: Test 1: 2.4.12-xfs #2 SMP (linux-2.4.12-xfs-2001-10-11.patch) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) XFS mounting filesystem md(9,0) xfs_force_shutdown(md(9,0),0x8) called from line 1020 of file xfs_trans.c. Return address = 0xc01f4409 Corruption of in-memory data detected. Shutting down filesystem: md(9,0) Please umount the filesystem, and rectify the problem(s) Test 2 : 2.4.8-mdk-xfs #10 SMP xfs_force_shutdown(md(9,0),0x8) called from line 1013 of file xfs_trans.c. Return address = 0xc01f78b9 Corruption of in-memory data detected. Shutting down filesystem: md(9,0) Please umount the filesystem, and rectify the problem(s) Test 3: 2.4.7-10SGI_XFS_PR1smp #1 SMP XFS mounting filesystem md(9,0) xfs_force_shutdown(md(9,0),0x8) called from line 1020 of file xfs_trans.c. Return address = 0xc01d53f9 Corruption of in-memory data detected. Shutting down filesystem: md(9,0) Please umount the filesystem, and rectify the problem(s) If I use any of those kernels with only a single partition (240GB) instead of running RAID 0 over the 5 partitions, everything works fine. The "2.4.9 is bad" (by Florin Andrei) thread mentions the same "Corruption of in-memory data detected"-type error, but refers to xfs_bmap.c, not xfs_trans.c. Please let me know if you want me to run any other tests. Regards, Marc From owner-linux-xfs@oss.sgi.com Mon Oct 22 05:40:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MCeFI01077 for linux-xfs-outgoing; Mon, 22 Oct 2001 05:40:15 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MCeCD01055 for ; Mon, 22 Oct 2001 05:40:12 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id OAA01340 for ; Mon, 22 Oct 2001 14:40:10 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id OAA00229 for linux-xfs@oss.sgi.com; Mon, 22 Oct 2001 14:40:10 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 7AEEC57306 for ; Mon, 22 Oct 2001 14:39:24 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 3DA6225835 for ; Mon, 22 Oct 2001 14:39:24 +0200 (CEST) Message-ID: <3BD4137C.E64F9101@ch.sauter-bc.com> Date: Mon, 22 Oct 2001 14:39:24 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: linux-xfs Subject: Re: RedHat 7.2 has 2.4.9 Kernel as update References: <3BD40587.BAF4A871@ch.sauter-bc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Simon Matter schrieb: > > I just found the RedHat 7.2 updates and they include 2.4.9 like with > RedHat 7.1. Interesting to see a distro where you can download updates > before the product is available. Okay, RedHat 7.2 is officially released today. Now if we only could upgrade our 7.1-XFS machines... I know we will do it soon. > > -Simon From owner-linux-xfs@oss.sgi.com Mon Oct 22 05:51:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MCpnI01455 for linux-xfs-outgoing; Mon, 22 Oct 2001 05:51:49 -0700 Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MCpiD01433 for ; Mon, 22 Oct 2001 05:51:44 -0700 Received: from mailgate4.nec.co.jp ([10.7.69.195]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id f9MCpZO25145 for ; Mon, 22 Oct 2001 21:51:35 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.190]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id f9MCpZv26215 for ; Mon, 22 Oct 2001 21:51:35 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (THKTNES98740.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id f9MCpYX22244 for ; Mon, 22 Oct 2001 21:51:34 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA140 for ; Mon, 22 Oct 2001 21:51:33 +0900 Received: FROM mailsv.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Mon Oct 22 21:51:32 2001 +0900 Received: from rifu.bsd.tnes.nec.co.jp (IDENT:root@rifu.bsd.tnes.nec.co.jp [10.1.101.142]) by mailsv.tnes.nec.co.jp (8.9.3/3.7W01031510) with ESMTP id VAA27014 for ; Mon, 22 Oct 2001 21:51:32 +0900 (JST) Received: from tagajo.bsd.tnes.nec.co.jp (tagajo.bsd.tnes.nec.co.jp [10.1.101.146]) by rifu.bsd.tnes.nec.co.jp (8.10.2+3.3W/3.7W/BSD-TNES-MX01) with ESMTP id f9MCpWi15247 for ; Mon, 22 Oct 2001 21:51:32 +0900 Received: (from sasaki@localhost) by tagajo.bsd.tnes.nec.co.jp (8.8.5+2.7Wbeta5/3.5Wpl1-97090809) id VAA07094; Mon, 22 Oct 2001 21:51:32 +0900 (JST) Message-Id: <200110221251.VAA07094@tagajo.bsd.tnes.nec.co.jp> To: linux-xfs@oss.sgi.com Subject: QA suite 040 failed Date: Mon, 22 Oct 2001 21:51:32 +0900 From: Takayuki Sasaki Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, QA suite 040 with the latest cvs tree reports the following error: > ./check 040 make: Nothing to be done for `default'. 040 - output mismatch (see 040.out.bad) 3a4 > xfs_quota.h ... FAILED 5a7,22 > > === xfs_alloc.c routines === > xfs_alloc_read_agf ... FAILED > > === xfs_bmap.c routines === > xfs_bmap_read_extents ... FAILED > xfs_bmapi ... FAILED > xfs_bmapi_single ... FAILED > xfs_bunmapi ... FAILED > > === xfs_btree.c routines === > xfs_btree_check_lblock ... FAILED > xfs_btree_check_sblock ... FAILED > > === xfs_ialloc.c routines === > xfs_ialloc_read_agi ... FAILED Failures: 040 Failed 1 of 1 tests Exit 1 Cheers, ---- Takayuki From owner-linux-xfs@oss.sgi.com Mon Oct 22 06:48:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MDmhC02261 for linux-xfs-outgoing; Mon, 22 Oct 2001 06:48:43 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MDmeD02239 for ; Mon, 22 Oct 2001 06:48:40 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9MDmZK04436 for ; Mon, 22 Oct 2001 06:48:35 -0700 Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id GAA62495; Mon, 22 Oct 2001 06:48:03 -0700 (PDT) Message-ID: <3BD422C7.9141C7EB@sgi.com> Date: Mon, 22 Oct 2001 08:44:39 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: Simon Matter CC: linux-xfs Subject: Re: RedHat 7.2 has 2.4.9 Kernel as update References: <3BD40587.BAF4A871@ch.sauter-bc.com> <3BD4137C.E64F9101@ch.sauter-bc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Patience, please... good things come to those who wait... :) -Eric Simon Matter wrote: > Okay, RedHat 7.2 is officially released today. Now if we only could > upgrade our 7.1-XFS machines... I know we will do it soon. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Oct 22 06:48:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MDmsi02301 for linux-xfs-outgoing; Mon, 22 Oct 2001 06:48:54 -0700 Received: from burgers (IDENT:postfix@burgers.bubbanfriends.org [216.140.122.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MDmpD02270 for ; Mon, 22 Oct 2001 06:48:51 -0700 Received: by burgers (Postfix, from userid 500) id 8E448400E07; Mon, 22 Oct 2001 09:48:52 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by burgers (Postfix) with ESMTP id 8CA0D2400216; Mon, 22 Oct 2001 09:48:52 -0400 (EDT) Date: Mon, 22 Oct 2001 09:48:52 -0400 (EDT) From: Mike Burger To: werner maes Cc: Steve Lord , , Seth Mos , Subject: Re: kernel update for RH7.1 users? In-Reply-To: <5.1.0.14.2.20011022114011.00a5d3d0@pb429905.kuleuven.be> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk 7.2 has been released. SGI is working on it. On Mon, 22 Oct 2001, werner maes wrote: > Another thing I was thinking about: > > What about when RedHat releases 7.2 with ext3 as a choice for a JFS. Will > SGI provide an upgrade path to 7.2 with XFS instead of ext3. I can imagine > that the default RedHat installer will not recognize a XFS partition. Or am > I wrong? > > Werner > > From owner-linux-xfs@oss.sgi.com Mon Oct 22 06:53:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MDrC602579 for linux-xfs-outgoing; Mon, 22 Oct 2001 06:53:12 -0700 Received: from c000.snv.cp.net (c000-h000.c000.snv.cp.net [209.228.32.64]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MDr8D02556 for ; Mon, 22 Oct 2001 06:53:08 -0700 Received: (cpmta 2688 invoked from network); 22 Oct 2001 06:53:03 -0700 Received: from amoa.org (HELO ?192.168.1.50?) (207.207.51.226) by smtp.tooley.com (209.228.32.64) with SMTP; 22 Oct 2001 06:53:03 -0700 X-Sent: 22 Oct 2001 13:53:03 GMT Subject: Re: RedHat 7.2 has 2.4.9 Kernel as update From: Chris Tooley To: linux-xfs In-Reply-To: <3BD422C7.9141C7EB@sgi.com> References: <3BD40587.BAF4A871@ch.sauter-bc.com> <3BD4137C.E64F9101@ch.sauter-bc.com> <3BD422C7.9141C7EB@sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16.99+cvs.2001.10.12.08.08 (Preview Release) Date: 22 Oct 2001 03:07:57 -0500 Message-Id: <1003738078.11792.37.camel@itspec.amoa.org> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Patience is not an acceptable option. I want it RIGHT NOW! :) Sulking, Chris Tooley On Mon, 2001-10-22 at 08:44, owner-linux-xfs@oss.sgi.com wrote: > Patience, please... good things come to those who wait... :) > > -Eric > > Simon Matter wrote: > > > Okay, RedHat 7.2 is officially released today. Now if we only could > > upgrade our 7.1-XFS machines... I know we will do it soon. > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. > From owner-linux-xfs@oss.sgi.com Mon Oct 22 06:54:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MDslc02681 for linux-xfs-outgoing; Mon, 22 Oct 2001 06:54:47 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MDsgD02659 for ; Mon, 22 Oct 2001 06:54:42 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA03774 for ; Mon, 22 Oct 2001 06:54:36 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA3362077; Mon, 22 Oct 2001 08:53:25 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA46017; Mon, 22 Oct 2001 08:53:25 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9MDo9029902; Mon, 22 Oct 2001 08:50:09 -0500 Message-Id: <200110221350.f9MDo9029902@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Takayuki Sasaki cc: linux-xfs@oss.sgi.com Subject: Re: QA suite 040 failed In-Reply-To: Message from Takayuki Sasaki of "Mon, 22 Oct 2001 21:51:32 +0900." <200110221251.VAA07094@tagajo.bsd.tnes.nec.co.jp> Date: Mon, 22 Oct 2001 08:50:09 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, This test is just there to catch code changes which have gone into one of user space or the kernel, but not the other. A quick code merge will fix it, but there is no practical implication of this, the changes which went into the kernel are in code paths which user space will never execute (evaluating quotas for extended attributes on files). Steve > Hi, > > QA suite 040 with the latest cvs tree reports the following error: > > > ./check 040 > make: Nothing to be done for `default'. > 040 - output mismatch (see 040.out.bad) > 3a4 > > xfs_quota.h ... FAILED > 5a7,22 > > > > === xfs_alloc.c routines === > > xfs_alloc_read_agf ... FAILED > > > > === xfs_bmap.c routines === > > xfs_bmap_read_extents ... FAILED > > xfs_bmapi ... FAILED > > xfs_bmapi_single ... FAILED > > xfs_bunmapi ... FAILED > > > > === xfs_btree.c routines === > > xfs_btree_check_lblock ... FAILED > > xfs_btree_check_sblock ... FAILED > > > > === xfs_ialloc.c routines === > > xfs_ialloc_read_agi ... FAILED > Failures: 040 > Failed 1 of 1 tests > Exit 1 > > Cheers, > ---- > Takayuki From owner-linux-xfs@oss.sgi.com Mon Oct 22 07:03:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ME3Gl03001 for linux-xfs-outgoing; Mon, 22 Oct 2001 07:03:16 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ME3DD02979 for ; Mon, 22 Oct 2001 07:03:13 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA04251 for ; Mon, 22 Oct 2001 07:03:08 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA19966; Mon, 22 Oct 2001 07:02:41 -0700 (PDT) Message-ID: <3BD42636.A4FE5EC6@sgi.com> Date: Mon, 22 Oct 2001 08:59:18 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: Chris Tooley CC: linux-xfs Subject: Re: RedHat 7.2 has 2.4.9 Kernel as update References: <3BD40587.BAF4A871@ch.sauter-bc.com> <3BD4137C.E64F9101@ch.sauter-bc.com> <3BD422C7.9141C7EB@sgi.com> <1003738078.11792.37.camel@itspec.amoa.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hey, it's all open source... anyone with a deadline is free to meet that deadline with their own resources... -Eric Chris Tooley wrote: > > Patience is not an acceptable option. I want it RIGHT NOW! :) > > Sulking, > > Chris Tooley -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Oct 22 07:05:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ME5Cd03121 for linux-xfs-outgoing; Mon, 22 Oct 2001 07:05:12 -0700 Received: from c000.snv.cp.net (c000-h008.c000.snv.cp.net [209.228.32.72]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ME59D03099 for ; Mon, 22 Oct 2001 07:05:09 -0700 Received: (cpmta 16135 invoked from network); 22 Oct 2001 07:05:03 -0700 Received: from amoa.org (HELO ?192.168.1.50?) (207.207.51.226) by smtp.tooley.com (209.228.32.72) with SMTP; 22 Oct 2001 07:05:03 -0700 X-Sent: 22 Oct 2001 14:05:03 GMT Subject: Re: RedHat 7.2 has 2.4.9 Kernel as update From: Chris Tooley To: sandeen@sgi.com Cc: linux-xfs In-Reply-To: <3BD42636.A4FE5EC6@sgi.com> References: <3BD40587.BAF4A871@ch.sauter-bc.com> <3BD4137C.E64F9101@ch.sauter-bc.com> <3BD422C7.9141C7EB@sgi.com> <1003738078.11792.37.camel@itspec.amoa.org> <3BD42636.A4FE5EC6@sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16.99+cvs.2001.10.12.08.08 (Preview Release) Date: 22 Oct 2001 09:04:43 -0500 Message-Id: <1003759484.11792.40.camel@itspec.amoa.org> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I never said anything about a deadline or a need, I said I WANTED it right now. That's what my kids always tell me. :) Chris On Mon, 2001-10-22 at 08:59, sandeen@sgi.com wrote: > Hey, it's all open source... anyone with a deadline is free to meet that > deadline with their own resources... > > -Eric > > Chris Tooley wrote: > > > > Patience is not an acceptable option. I want it RIGHT NOW! :) > > > > Sulking, > > > > Chris Tooley > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Oct 22 07:08:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ME8OG03313 for linux-xfs-outgoing; Mon, 22 Oct 2001 07:08:24 -0700 Received: from maties2.sun.ac.za (maties2.sun.ac.za [146.232.128.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ME8HD03291 for ; Mon, 22 Oct 2001 07:08:18 -0700 Received: from www.cae.sun.ac.za ([146.232.145.5] helo=mail.cae.co.za) by maties2.sun.ac.za with esmtp (Exim 3.33 #3) id 15vfkS-0008Ao-00 for linux-xfs@oss.sgi.com; Mon, 22 Oct 2001 16:08:12 +0200 Received: by mail.cae.co.za (Postfix, from userid 239) id A2C0B1C646; Mon, 22 Oct 2001 16:00:59 +0200 (SAST) Received: from cae.co.za (bgmilne.cae.co.za [146.232.174.36]) by mail.cae.sun.ac.za (Postfix) with ESMTP id 9C3491B7E4 for ; Mon, 22 Oct 2001 16:00:58 +0200 (SAST) Message-ID: <3BD427C3.2080507@cae.co.za> Date: Mon, 22 Oct 2001 16:05:55 +0200 From: Buchan Milne User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs Subject: Re: RedHat 7.2 has 2.4.9 Kernel as update References: <3BD40587.BAF4A871@ch.sauter-bc.com> <3BD4137C.E64F9101@ch.sauter-bc.com> <3BD422C7.9141C7EB@sgi.com> <1003738078.11792.37.camel@itspec.amoa.org> <3BD42636.A4FE5EC6@sgi.com> <1003759484.11792.40.camel@itspec.amoa.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: scanned for viruses at mail.cae.co.za by AMaViS 0.2.1 (http://amavis.org/) X-Scanner: exiscan *15vfkS-0008Ao-00*vwFE.ySB/bc* http://duncanthrax.net/exiscan/ Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Otherwise, you can just upgrade to Mandrake 8.1, and choose from XFS,JFS,ReiserFS,ext3. I see Redhat does not claim to support XFS at : http://www.redhat.com/software/linux/rhl_new_features.html (Redhat also has mozilla 0.9.2, which is almost 4 months old ....!) Buchan Chris Tooley wrote: >I never said anything about a deadline or a need, I said I WANTED it >right now. That's what my kids always tell me. :) > >Chris >On Mon, 2001-10-22 at 08:59, sandeen@sgi.com wrote: > >>Hey, it's all open source... anyone with a deadline is free to meet that >>deadline with their own resources... >> >>-Eric >> >>Chris Tooley wrote: >> >>>Patience is not an acceptable option. I want it RIGHT NOW! :) >>> >>>Sulking, >>> >>>Chris Tooley >>> >>-- >>Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs >>sandeen@sgi.com SGI, Inc. >> > -- |----------------Registered Linux User #182071-----------------| Buchan Milne Mechanical Engineer, Network Manager Cellphone * Work +27 82 472 2231 * +27 21 808 2497 ext 202 Stellenbosch Automotive Engineering http://www.cae.co.za From owner-linux-xfs@oss.sgi.com Mon Oct 22 07:09:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ME9tO03424 for linux-xfs-outgoing; Mon, 22 Oct 2001 07:09:55 -0700 Received: from s1.uklinux.net (ns1.uklinux.net [212.1.130.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ME9oD03402 for ; Mon, 22 Oct 2001 07:09:51 -0700 Received: from pyewacket.nic.uklinux.net (ppp-5a-210.3com.telinco.net [212.159.136.210]) (authenticated) by s1.uklinux.net (8.11.6/8.11.6) with ESMTP id f9ME9gL31826 for ; Mon, 22 Oct 2001 15:09:43 +0100 Envelope-To: Received: from [127.0.0.1] (helo=there) by pyewacket.nic.uklinux.net with smtp (Exim 3.22 #1) id 15vfly-0000PA-00 for linux-xfs@oss.sgi.com; Mon, 22 Oct 2001 15:09:46 +0100 Content-Type: text/plain; charset="iso-8859-1" From: nic Reply-To: nic@uklinux.net Organization: Quixotic Hackers To: linux-xfs@oss.sgi.com Subject: devfs (was Re: Compilers (was Re: 2.4.11 don't work yet.)) Date: Mon, 22 Oct 2001 15:09:46 +0100 X-Mailer: KMail [version 1.3.1] References: <12144.1002906352@ocs3.intra.ocs.com.au> In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Monday 15 October 2001 09:47, nic wrote: > On Friday 12 October 2001 18:05, Keith Owens wrote: > > Did you compile your kernel with kdb? grep kdb_main System.map or look > > for the kdb v1.9 startup line, near the start, after the Memory line. > > Apparently not. What a dork! ;-0 > > nic (updating to 2.4.13-pre2 and actually compiling kdb in...) OK, using kgcc and the CVS version of this morning (2.4.13-pre5, 11:39am 22.10.2001 British Summer Time) it still happens. Now I have kdb, I can see what's happening, I think, and it doesn't look like an XFS problem. It looks as though devfs is forking an 'ln' process which is failing forever at the unlink stage. An odd thing to note was that when I tried this after a boot -s, and ss-ing about 10 times, an hlt instruction was sent, so now I'm super confused! Anyhow this doesn't appear to be XFS related, so you folks can all forget about it now. :-) I rather suspect, that I need a different version of devfsd to go with the 2.4.10+ kernels. If anyone else is running a recent kernel and using devfsd can they e-mail me off list to say what version they're using. ('strings /sbin/devfsd | grep ^1\.3' should work). I'll build a 1.3.18 rpm and see what happens. nic From owner-linux-xfs@oss.sgi.com Mon Oct 22 07:12:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MECLd03613 for linux-xfs-outgoing; Mon, 22 Oct 2001 07:12:21 -0700 Received: from c000.snv.cp.net (c000-h007.c000.snv.cp.net [209.228.32.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MECFD03590 for ; Mon, 22 Oct 2001 07:12:15 -0700 Received: (cpmta 8874 invoked from network); 22 Oct 2001 07:12:09 -0700 Received: from amoa.org (HELO ?192.168.1.50?) (207.207.51.226) by smtp.tooley.com (209.228.32.71) with SMTP; 22 Oct 2001 07:12:09 -0700 X-Sent: 22 Oct 2001 14:12:09 GMT Subject: Re: RedHat 7.2 has 2.4.9 Kernel as update From: Chris Tooley To: owner-linux-xfs@oss.sgi.com Cc: linux-xfs In-Reply-To: <3BD427C3.2080507@cae.co.za> References: <3BD40587.BAF4A871@ch.sauter-bc.com> <3BD4137C.E64F9101@ch.sauter-bc.com> <3BD422C7.9141C7EB@sgi.com> <1003738078.11792.37.camel@itspec.amoa.org> <3BD42636.A4FE5EC6@sgi.com> <1003759484.11792.40.camel@itspec.amoa.org> <3BD427C3.2080507@cae.co.za> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16.99+cvs.2001.10.12.08.08 (Preview Release) Date: 22 Oct 2001 09:11:49 -0500 Message-Id: <1003759910.11737.45.camel@itspec.amoa.org> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I think we can steer clear of the religious distro wars. I'll check it out, but it's not likely. Thanks, Chris On Mon, 2001-10-22 at 09:05, owner-linux-xfs@oss.sgi.com wrote: > Otherwise, you can just upgrade to Mandrake 8.1, and choose from > XFS,JFS,ReiserFS,ext3. I see Redhat does not claim to support XFS at : > http://www.redhat.com/software/linux/rhl_new_features.html > > (Redhat also has mozilla 0.9.2, which is almost 4 months old ....!) > > Buchan > > Chris Tooley wrote: > > >I never said anything about a deadline or a need, I said I WANTED it > >right now. That's what my kids always tell me. :) > > > >Chris > >On Mon, 2001-10-22 at 08:59, sandeen@sgi.com wrote: > > > >>Hey, it's all open source... anyone with a deadline is free to meet that > >>deadline with their own resources... > >> > >>-Eric > >> > >>Chris Tooley wrote: > >> > >>>Patience is not an acceptable option. I want it RIGHT NOW! :) > >>> > >>>Sulking, > >>> > >>>Chris Tooley > >>> > >>-- > >>Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > >>sandeen@sgi.com SGI, Inc. > >> > > > > > -- > |----------------Registered Linux User #182071-----------------| > Buchan Milne Mechanical Engineer, Network Manager > Cellphone * Work +27 82 472 2231 * +27 21 808 2497 ext 202 > Stellenbosch Automotive Engineering http://www.cae.co.za > > > From owner-linux-xfs@oss.sgi.com Mon Oct 22 07:20:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MEKwo03879 for linux-xfs-outgoing; Mon, 22 Oct 2001 07:20:58 -0700 Received: from chef.cc.absoval.com (cpe-66-1-218-101.fl.sprintbbd.net [66.1.218.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MEKqD03834 for ; Mon, 22 Oct 2001 07:20:53 -0700 Received: from ieee.org (IDENT:bs@thebs.cc.absoval.com [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id KAA13051; Mon, 22 Oct 2001 10:20:39 -0400 Message-ID: <3BD42B3E.C7CB44D2@ieee.org> Date: Mon, 22 Oct 2001 10:20:46 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts/AbsoluteValueSystems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: Chris Tooley , linux-xfs Subject: Re: RedHat 7.2 has 2.4.9 Kernel as update References: <3BD40587.BAF4A871@ch.sauter-bc.com> <3BD4137C.E64F9101@ch.sauter-bc.com> <3BD422C7.9141C7EB@sgi.com> <1003738078.11792.37.camel@itspec.amoa.org> <3BD42636.A4FE5EC6@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: > Hey, it's all open source... anyone with a deadline is free to > meet that deadline with their own resources... Oh, we know how you feel ... http://www.linux-wlan.org -- TheBS, AVS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ---------------------------------------------------------------- The US National ID is an enhanced Social Security Number. It will give those who abuse it more information than ever before. And just like the SSN, they will ignore all the regulations. From owner-linux-xfs@oss.sgi.com Mon Oct 22 07:21:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MEL1P03920 for linux-xfs-outgoing; Mon, 22 Oct 2001 07:21:01 -0700 Received: from chef.cc.absoval.com (cpe-66-1-218-101.fl.sprintbbd.net [66.1.218.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MEKuD03858 for ; Mon, 22 Oct 2001 07:20:57 -0700 Received: from ieee.org (IDENT:bs@thebs.cc.absoval.com [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id KAA13023; Mon, 22 Oct 2001 10:19:30 -0400 Message-ID: <3BD42AF9.6B47F56A@ieee.org> Date: Mon, 22 Oct 2001 10:19:37 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts/AbsoluteValueSystems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Buchan Milne CC: linux-xfs Subject: Re: RedHat 7.2 has 2.4.9 Kernel as update References: <3BD40587.BAF4A871@ch.sauter-bc.com> <3BD4137C.E64F9101@ch.sauter-bc.com> <3BD422C7.9141C7EB@sgi.com> <1003738078.11792.37.camel@itspec.amoa.org> <3BD42636.A4FE5EC6@sgi.com> <1003759484.11792.40.camel@itspec.amoa.org> <3BD427C3.2080507@cae.co.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Buchan Milne wrote: > Otherwise, you can just upgrade to Mandrake 8.1, and choose from > XFS,JFS,ReiserFS,ext3. Mandrake also seems to miss a number of important patches to kernels and various other programs. > I see Redhat does not claim to support XFS at : > http://www.redhat.com/software/linux/rhl_new_features.html Of course not! That's where SGI comes in. > (Redhat also has mozilla 0.9.2, which is almost 4 months old ....!) And many of us continue to have "issues" with Mandrake package "maturity." -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ---------------------------------------------------------------- The US National ID is an enhanced Social Security Number. It will give those who abuse it more information than ever before. And just like the SSN, they will ignore all the regulations. From owner-linux-xfs@oss.sgi.com Mon Oct 22 07:25:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MEPfH04169 for linux-xfs-outgoing; Mon, 22 Oct 2001 07:25:41 -0700 Received: from chef.cc.absoval.com (cpe-66-1-218-101.fl.sprintbbd.net [66.1.218.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MEPaD04144 for ; Mon, 22 Oct 2001 07:25:36 -0700 Received: from ieee.org (IDENT:bs@thebs.cc.absoval.com [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id KAA13065; Mon, 22 Oct 2001 10:25:27 -0400 Message-ID: <3BD42C5E.B8EE6E8A@ieee.org> Date: Mon, 22 Oct 2001 10:25:34 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts/AbsoluteValueSystems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Simon Matter CC: linux-xfs Subject: Re: RedHat 7.2 has 2.4.9 Kernel as update References: <3BD40587.BAF4A871@ch.sauter-bc.com> <3BD4137C.E64F9101@ch.sauter-bc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Simon Matter wrote: > Okay, RedHat 7.2 is officially released today. Now if we only could > upgrade our 7.1-XFS machines... I know we will do it soon. I do "live" updates of minor RedHat version changes all the time using RPM. In fact, I _prefer_ to do this for my production servers and critical workstations. Grab the 2.4.7 XFS pre-release and install it alongside the RedHat 7.2 RPMs manually. BTW, H. J. Lu just reported over on the NFS list that RedHat's 2.4.9 kernel update just _failed_ the NFS connect-a-thon tests. So you might want to stick with 2.4.7 anyway. ;-PPP -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ---------------------------------------------------------------- The US National ID is an enhanced Social Security Number. It will give those who abuse it more information than ever before. And just like the SSN, they will ignore all the regulations. From owner-linux-xfs@oss.sgi.com Mon Oct 22 07:44:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MEiB904470 for linux-xfs-outgoing; Mon, 22 Oct 2001 07:44:11 -0700 Received: from fep06-app.kolumbus.fi (fep06-0.kolumbus.fi [193.229.0.57]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MEi7D04448 for ; Mon, 22 Oct 2001 07:44:07 -0700 Received: from there ([62.248.183.228]) by fep06-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20011022144405.IKSA1726.fep06-app.kolumbus.fi@there>; Mon, 22 Oct 2001 17:44:05 +0300 Content-Type: text/plain; charset="iso-8859-1" From: Hristo Grigorov To: Buchan Milne , linux-xfs Subject: Re: RedHat 7.2 has 2.4.9 Kernel as update Date: Mon, 22 Oct 2001 17:44:30 +0300 X-Mailer: KMail [version 1.3.1] References: <3BD40587.BAF4A871@ch.sauter-bc.com> <1003759484.11792.40.camel@itspec.amoa.org> <3BD427C3.2080507@cae.co.za> In-Reply-To: <3BD427C3.2080507@cae.co.za> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011022144405.IKSA1726.fep06-app.kolumbus.fi@there> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Monday 22 October 2001 17:05, Buchan Milne wrote: > Otherwise, you can just upgrade to Mandrake 8.1, and choose from > XFS,JFS,ReiserFS,ext3. I see Redhat does not claim to support XFS at : > http://www.redhat.com/software/linux/rhl_new_features.html Well, you could complain for that to RedHat... If enough of us do it, they may review that and include support for XFS also ?! > > (Redhat also has mozilla 0.9.2, which is almost 4 months old ....!) The latest doesn't necessarily means the best :) -- Regards, Hristo. From owner-linux-xfs@oss.sgi.com Mon Oct 22 07:56:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MEuSZ04736 for linux-xfs-outgoing; Mon, 22 Oct 2001 07:56:28 -0700 Received: from c000.snv.cp.net (c000-h007.c000.snv.cp.net [209.228.32.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MEuOD04714 for ; Mon, 22 Oct 2001 07:56:24 -0700 Received: (cpmta 14555 invoked from network); 22 Oct 2001 07:56:19 -0700 Received: from amoa.org (HELO ?192.168.1.50?) (207.207.51.226) by smtp.tooley.com (209.228.32.71) with SMTP; 22 Oct 2001 07:56:19 -0700 X-Sent: 22 Oct 2001 14:56:19 GMT Subject: Re: RedHat 7.2 has 2.4.9 Kernel as update From: Chris Tooley To: linux-xfs In-Reply-To: <20011022144405.IKSA1726.fep06-app.kolumbus.fi@there> References: <3BD40587.BAF4A871@ch.sauter-bc.com> <1003759484.11792.40.camel@itspec.amoa.org> <3BD427C3.2080507@cae.co.za> <20011022144405.IKSA1726.fep06-app.kolumbus.fi@there> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16.99+cvs.2001.10.12.08.08 (Preview Release) Date: 22 Oct 2001 09:55:59 -0500 Message-Id: <1003762559.11792.47.camel@itspec.amoa.org> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2001-10-22 at 09:44, owner-linux-xfs@oss.sgi.com wrote: > On Monday 22 October 2001 17:05, Buchan Milne wrote: > > Otherwise, you can just upgrade to Mandrake 8.1, and choose from > > XFS,JFS,ReiserFS,ext3. I see Redhat does not claim to support XFS at : > > http://www.redhat.com/software/linux/rhl_new_features.html > > Well, you could complain for that to RedHat... If enough of us do it, they may > review that and include support for XFS also ?! > > > > > (Redhat also has mozilla 0.9.2, which is almost 4 months old ....!) > > The latest doesn't necessarily means the best :) Unfortunately, in this case the latest IS the best release. 0.9.2 is slow as a dog compared 0.9.5 or even 0.9.4 releases. Chris Tooley > > -- > Regards, Hristo. > From owner-linux-xfs@oss.sgi.com Mon Oct 22 08:05:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MF5HD05109 for linux-xfs-outgoing; Mon, 22 Oct 2001 08:05:17 -0700 Received: from chef.cc.absoval.com (cpe-66-1-218-101.fl.sprintbbd.net [66.1.218.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MF5CD05087 for ; Mon, 22 Oct 2001 08:05:13 -0700 Received: from ieee.org (IDENT:bs@thebs.cc.absoval.com [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id LAA13237; Mon, 22 Oct 2001 11:05:05 -0400 Message-ID: <3BD435A9.2D4791F2@ieee.org> Date: Mon, 22 Oct 2001 11:05:13 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts/AbsoluteValueSystems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Chris Tooley CC: linux-xfs Subject: Re: RedHat 7.2 has 2.4.9 Kernel as update References: <3BD40587.BAF4A871@ch.sauter-bc.com> <1003759484.11792.40.camel@itspec.amoa.org> <3BD427C3.2080507@cae.co.za> <20011022144405.IKSA1726.fep06-app.kolumbus.fi@there> <1003762559.11792.47.camel@itspec.amoa.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Chris Tooley wrote: > Unfortunately, in this case the latest IS the best release. 0.9.2 is > slow as a dog compared 0.9.5 or even 0.9.4 releases. This is _really_ getting "off-topic", so let me add ... I just upgraded to the latest Ximian with Mozilla 0.9.3 last week, as well as added-in Galeon 0.11.5. I surfed, played intensive OpenGL games and burnt CD-Rs on my dual-Athlon for 5 days straight and Galeon _never_ crashed. All on my 2.4.3-XFS kernel rebuilt for dual-Athlon. -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ---------------------------------------------------------------- The US National ID is an enhanced Social Security Number. It will give those who abuse it more information than ever before. And just like the SSN, they will ignore all the regulations. From owner-linux-xfs@oss.sgi.com Mon Oct 22 08:25:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MFPQE05611 for linux-xfs-outgoing; Mon, 22 Oct 2001 08:25:26 -0700 Received: from s1.uklinux.net (ns1.uklinux.net [212.1.130.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MFPLD05589 for ; Mon, 22 Oct 2001 08:25:21 -0700 Received: from pyewacket.nic.uklinux.net (ppp-3b-38.3com.telinco.net [212.159.133.38]) (authenticated) by s1.uklinux.net (8.11.6/8.11.6) with ESMTP id f9MFPIk13001 for ; Mon, 22 Oct 2001 16:25:18 +0100 Envelope-To: Received: from [127.0.0.1] (helo=there) by pyewacket.nic.uklinux.net with smtp (Exim 3.22 #1) id 15vgtF-0000Jb-00 for linux-xfs@oss.sgi.com; Mon, 22 Oct 2001 16:21:21 +0100 Content-Type: text/plain; charset="iso-8859-1" From: nic Reply-To: nic@uklinux.net Organization: Quixotic Hackers To: linux-xfs@oss.sgi.com Subject: Re: devfs (was Re: Compilers (was Re: 2.4.11 don't work yet.)) Date: Mon, 22 Oct 2001 16:21:21 +0100 X-Mailer: KMail [version 1.3.1] References: <12144.1002906352@ocs3.intra.ocs.com.au> In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Monday 22 October 2001 15:09, nic wrote: > I'll build a 1.3.18 rpm and see what happens. OK, I built 1.3.18 and more importantly altered the following three lines (calling the duff 'ln') from: # ...and /dev/cdrom # In case no cdrom modules loaded, point link over to /dev/cdroms/cdrom0 LOOKUP cdrom EXECUTE /bin/ln -sf cdroms/cdrom0 cdrom # Similarly, if the module loaded, create the /dev/cdrom link REGISTER cdroms/cdrom0 EXECUTE /bin/ln -sf cdroms/cdrom0 cdrom # Remove link when cdrom modules are unloaded UNREGISTER cdroms/cdrom0 EXECUTE /bin/rm -f cdrom to: # ...and /dev/cdrom # In case no cdrom modules loaded, point link over to /dev/cdroms/cdrom0 LOOKUP ^cdrom$ CFUNCTION GLOBAL symlink cdroms/cdrom0 $devpath # Similarly, if the module loaded, create the /dev/cdrom link REGISTER ^cdroms/cdrom0$ CFUNCTION GLOBAL symlink cdroms/cdrom0 cdrom # Remove link when cdrom modules are unloaded UNREGISTER ^cdroms/cdrom0$ CFUNCTION GLOBAL unlink cdrom So it wasn't xfs related. It never was xfs related. It was a devfs config issue. Still kdb rocks - thanks to SGI for yet another great piece of code for Linux, nic PS. I'll put the devfs RPM up on www.nic.uklinux.net/src/rpms in a mo. From owner-linux-xfs@oss.sgi.com Mon Oct 22 08:38:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MFco605870 for linux-xfs-outgoing; Mon, 22 Oct 2001 08:38:50 -0700 Received: from sqf1373.britain.agilent.com ([192.25.22.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MFckD05848 for ; Mon, 22 Oct 2001 08:38:46 -0700 Received: from agilent.com (IDENT:mcowe@localhost [127.0.0.1]) by sqf1373.britain.agilent.com (8.9.3/8.9.3) with ESMTP id QAA02285 for ; Mon, 22 Oct 2001 16:38:39 +0100 Message-ID: <3BD43D7E.C04536EE@agilent.com> Date: Mon, 22 Oct 2001 16:38:38 +0100 From: Malcolm Cowe Organization: Agilent Technologies UK Ltd. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.18-mosix i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Support Infrastructure Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, We are looking at deploying an increasing number of linux based file servers within our enterprise, based on HP's NetServer platform. One of the aspects we are investigating relates to journalled file systems, and we are looking at project activity and so on to try and ascertain longevity and stability. I have a good deal of previous experience with SGI hardware and the IRIX OS platform, and so I have a natural tendency towards recommending XFS for Linux, since I have good experiences with this file system, and a great deal of respect for the engineering talent at SGI. How actively is the project being maintained? Is is straightforward to forward revise the kernel and apply the XFS patches to it? Will there be long term support for XFS on linux? Is it going to work with RH 7.2? If any of these questions appear to be rude or pointed, then I apologise. It is not my intention to cause any offence. I really want to push for XFS versus any of the competitors -- in fact it appears that the only other viable contender would be JFS from IBM, and I just can't bring myself to side with the people who brought the world so much misery with AIX. Regards, -- Malcolm Cowe. IT | Technical Computing, Telephone: +44 131 331 6466 Agilent Technologies Ltd. Telnet: 313-3466 From owner-linux-xfs@oss.sgi.com Mon Oct 22 08:57:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MFvbO06292 for linux-xfs-outgoing; Mon, 22 Oct 2001 08:57:37 -0700 Received: from msw.infraserv-wi.de (msw.infraserv-wi.de [195.126.5.203]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MFvVD06269 for ; Mon, 22 Oct 2001 08:57:32 -0700 Received: from prisn007.primedisc.com (unverified) by msw.infraserv-wi.de (Content Technologies SMTPRS 4.1.5) with SMTP id for ; Mon, 22 Oct 2001 17:57:26 +0200 Received: by prisn007.primedisc.com(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998)) id C1256AED.00584E1F ; Mon, 22 Oct 2001 18:04:31 +0200 X-Lotus-FromDomain: PRIMEDISC From: juergen.bruestle@primedisc.com To: linux-xfs@oss.sgi.com Message-ID: Date: Mon, 22 Oct 2001 18:04:27 +0200 Subject: Linux 2.4.12, xfs-patch Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f9MFvWD06271 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hallo, Little Fix in File fs/super.c Compiler ERROR: too few arguments to function `do_kern_mount' Function: void __init mount_root(void) . . . . #ifdef CONFIG_ROOT_NFS if (MAJOR(ROOT_DEV) != UNNAMED_MAJOR) goto skip_nfs; data = nfs_root_data(); if (!data) goto no_nfs; === old >>> vfsmnt = do_kern_mount("nfs", root_mountflags, "/dev/root", data); === new >>> vfsmnt = do_kern_mount("nfs", root_mountflags, "nfs", "/dev/root", data); if (!IS_ERR(vfsmnt)) { printk ("VFS: Mounted root (%s filesystem).\n", "nfs"); ROOT_DEV = vfsmnt->mnt_sb->s_dev; goto attach_it; } no_nfs: . . . . . Best Regards Jürgen Brüstle From owner-linux-xfs@oss.sgi.com Mon Oct 22 09:05:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MG5WG06586 for linux-xfs-outgoing; Mon, 22 Oct 2001 09:05:32 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MG5KD06561 for ; Mon, 22 Oct 2001 09:05:20 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA04266 for ; Mon, 22 Oct 2001 09:05:16 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA3369376; Mon, 22 Oct 2001 11:03:58 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA32544; Mon, 22 Oct 2001 11:03:58 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9MG0fj02754; Mon, 22 Oct 2001 11:00:41 -0500 Message-Id: <200110221600.f9MG0fj02754@jen.americas.sgi.com> To: juergen.bruestle@primedisc.com cc: linux-xfs@oss.sgi.com Subject: Re: Linux 2.4.12, xfs-patch References: Comments: In-reply-to juergen.bruestle@primedisc.com message dated "Mon, 22 Oct 2001 18:04:27 +0200." Date: Mon, 22 Oct 2001 11:00:41 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks, I will ensuse this chunk of code is correct in the 2.4.13-pre6 code which should show up this morning. Steve > > Hallo, > > Little Fix in File fs/super.c > > Compiler ERROR: too few arguments to function `do_kern_mount' > > > > Function: void __init mount_root(void) > . > . > . > . > #ifdef CONFIG_ROOT_NFS > if (MAJOR(ROOT_DEV) != UNNAMED_MAJOR) > goto skip_nfs; > data = nfs_root_data(); > if (!data) > goto no_nfs; > > === old >>> vfsmnt = do_kern_mount("nfs", root_mountflags, > "/dev/root", data); > === new >>> vfsmnt = do_kern_mount("nfs", root_mountflags, "nfs", > "/dev/root", data); > > if (!IS_ERR(vfsmnt)) { > printk ("VFS: Mounted root (%s filesystem).\n", "nfs"); > ROOT_DEV = vfsmnt->mnt_sb->s_dev; > goto attach_it; > } > no_nfs: > . > . > . > . > . > > > Best Regards > J|rgen Br|stle > From owner-linux-xfs@oss.sgi.com Mon Oct 22 09:19:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MGJ3F07158 for linux-xfs-outgoing; Mon, 22 Oct 2001 09:19:03 -0700 Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MGIwD07136 for ; Mon, 22 Oct 2001 09:18:58 -0700 Received: from scare ([63.231.179.33]) by lips.thebarn.com (8.12.0/8.12.0) with ESMTP id f9MGIcbw012718; Mon, 22 Oct 2001 11:18:39 -0500 (CDT) Subject: Re: RedHat 7.2 has 2.4.9 Kernel as update From: Russell Cattelan To: Bryan-TheBS-Smith Cc: linux-xfs In-Reply-To: <3BD42AF9.6B47F56A@ieee.org> References: <3BD40587.BAF4A871@ch.sauter-bc.com> <3BD4137C.E64F9101@ch.sauter-bc.com> <3BD422C7.9141C7EB@sgi.com> <1003738078.11792.37.camel@itspec.amoa.org> <3BD42636.A4FE5EC6@sgi.com> <1003759484.11792.40.camel@itspec.amoa.org> <3BD427C3.2080507@cae.co.za> <3BD42AF9.6B47F56A@ieee.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.14 (Preview Release) Date: 22 Oct 2001 11:18:22 -0500 Message-Id: <1003767504.22256.20.camel@scare> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2001-10-22 at 09:19, Bryan-TheBS-Smith wrote: > Buchan Milne wrote: > > Otherwise, you can just upgrade to Mandrake 8.1, and choose from > > XFS,JFS,ReiserFS,ext3. > > Mandrake also seems to miss a number of important patches to kernels > and various other programs. > > > I see Redhat does not claim to support XFS at : > > http://www.redhat.com/software/linux/rhl_new_features.html > > Of course not! That's where SGI comes in. > > > (Redhat also has mozilla 0.9.2, which is almost 4 months old ....!) > > And many of us continue to have "issues" with Mandrake package > "maturity." Suppose you could be a little less vague so that just maybe IF there are problems the mandrake folks can address them! The Mandrake folks have been very helpful and happy to continue taking on the task of keeping XFS integrated into their kernels, which is a lot more than can be said about RedHat. > > -- > Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 > Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org > President SmithConcepts, Inc. http://www.SmithConcepts.com > ---------------------------------------------------------------- > The US National ID is an enhanced Social Security Number. It > will give those who abuse it more information than ever before. > And just like the SSN, they will ignore all the regulations. From owner-linux-xfs@oss.sgi.com Mon Oct 22 09:27:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MGRZn07446 for linux-xfs-outgoing; Mon, 22 Oct 2001 09:27:35 -0700 Received: from chef.cc.absoval.com (cpe-66-1-218-101.fl.sprintbbd.net [66.1.218.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MGRUD07416 for ; Mon, 22 Oct 2001 09:27:30 -0700 Received: from ieee.org (IDENT:bs@thebs.cc.absoval.com [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id MAA13626; Mon, 22 Oct 2001 12:27:18 -0400 Message-ID: <3BD448ED.6DC17BE8@ieee.org> Date: Mon, 22 Oct 2001 12:27:25 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts/AbsoluteValueSystems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Russell Cattelan CC: linux-xfs Subject: Re: RedHat 7.2 has 2.4.9 Kernel as update References: <3BD40587.BAF4A871@ch.sauter-bc.com> <3BD4137C.E64F9101@ch.sauter-bc.com> <3BD422C7.9141C7EB@sgi.com> <1003738078.11792.37.camel@itspec.amoa.org> <3BD42636.A4FE5EC6@sgi.com> <1003759484.11792.40.camel@itspec.amoa.org> <3BD427C3.2080507@cae.co.za> <3BD42AF9.6B47F56A@ieee.org> <1003767504.22256.20.camel@scare> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Russell Cattelan wrote: > Suppose you could be a little less vague so that just maybe IF > there are problems the mandrake folks can address them! I have know a number of VALinux guys who ran into the same issues as I did time and time again, despite things being in Mandrake's bug DB. After seeing the same issue release in and out (like SCSI CD-ROM issues in the installer, broken components in the control panel, etc...), I finally "gave up" after Mandrake 7.1. It is obvious to me that Mandrake has three goals: 1. Always include latest packages 2. Test only on mainstream systems 3. Beat RedHat to market Now I'm not saying that that is nessarily "bad." In fact, #1 and #2 are what people only care about. But they have been pretty consistent at all three, and they all conflict with my needs for Linux -- which is 24x7 operation, both server and desktop. > The Mandrake folks have been very helpful and happy to continue taking > on the task of keeping XFS integrated into their kernels, which is a lot > more than can be said about RedHat. Well, I've been lobbying RedHat to "wake up and smell the reality." As much as I like Ext3, there are definately some limitations in its capabilities versus XFS. RedHat will, sooner or later, realize that Ext3 is NOT going to address all their customers. Not even for server installs. -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ---------------------------------------------------------------- The US National ID is an enhanced Social Security Number. It will give those who abuse it more information than ever before. And just like the SSN, they will ignore all the regulations. From owner-linux-xfs@oss.sgi.com Mon Oct 22 10:18:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MHI8Y08396 for linux-xfs-outgoing; Mon, 22 Oct 2001 10:18:08 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MHI3D08374 for ; Mon, 22 Oct 2001 10:18:03 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9MHHwW12500 for ; Mon, 22 Oct 2001 10:17:58 -0700 Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA3164292; Mon, 22 Oct 2001 12:15:25 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id MAA43983; Mon, 22 Oct 2001 12:15:25 -0500 (CDT) Subject: Re: Corruption of in-memory data detected. From: Eric Sandeen To: Marc Schmitt Cc: linux-xfs@oss.sgi.com, florin@sgi.com In-Reply-To: <3BD4137A.8040406@inf.ethz.ch> References: <3BD4137A.8040406@inf.ethz.ch> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 22 Oct 2001 12:14:07 -0500 Message-Id: <1003770847.13566.36.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Please let me know if you want me to run any other tests. Hi Marc - If you don't mind tinkering a bit, the first thing to do is enable kdb and set a breakpoint, so we can see how we're getting to this point.. Enter KDB by pressing the pause key (or ctrl-a on serial console) Then do this: kdb> bp _xfs_force_shutdown kdb> go next time you hit this bug, it will drop you into kdb. Type kdb> bt to get a backtrace, and that will be a start to getting useful info. you cant type kdb> go at that point to get the system running again. If you don't have a serial console, it will be tough to capture the output, but if you can just give us function names that will be a start... Thanks, -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Oct 22 10:22:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MHM1j08551 for linux-xfs-outgoing; Mon, 22 Oct 2001 10:22:01 -0700 Received: from www.fortuitous.com (cs6625128-203.austin.rr.com [66.25.128.203]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MHLxD08526 for ; Mon, 22 Oct 2001 10:21:59 -0700 Received: by www.fortuitous.com (Postfix, from userid 500) id 3757EBE2; Mon, 22 Oct 2001 12:21:06 -0500 (CDT) Date: Mon, 22 Oct 2001 12:21:06 -0500 From: pac@fortuitous.com To: linux-xfs@oss.sgi.com Subject: ext3 + xfs + jfs + reiser Message-ID: <20011022122106.A12279@bistro.marx> Reply-To: pac@fortuitous.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Anyone know of a super-duper-all-in-one patch for xfs+ext3+jfs+ (reiser is already in the kernel) ? -pac -- .--------------------------------------------------------. | Dr. Philip A. Carinhas | pac@fortuitous.com | | Fortuitous Technologies Inc. | http://fortuitous.com | | Linux Consulting & Training | Tel : 1-512-467-2154 | `--------------------------------------------------------' From owner-linux-xfs@oss.sgi.com Mon Oct 22 10:33:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MHXBR08872 for linux-xfs-outgoing; Mon, 22 Oct 2001 10:33:11 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MHX9D08850 for ; Mon, 22 Oct 2001 10:33:09 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9MHX3K18164 for ; Mon, 22 Oct 2001 10:33:03 -0700 Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA3251729; Mon, 22 Oct 2001 12:31:47 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id MAA46101; Mon, 22 Oct 2001 12:31:47 -0500 (CDT) Subject: Re: ext3 + xfs + jfs + reiser From: Eric Sandeen To: pac@fortuitous.com Cc: linux-xfs@oss.sgi.com In-Reply-To: <20011022122106.A12279@bistro.marx> References: <20011022122106.A12279@bistro.marx> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 22 Oct 2001 12:30:29 -0500 Message-Id: <1003771829.13566.38.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dunno about a single patch, but the latest Mandrake has all of those filesystems co-existing. -Eric On Mon, 2001-10-22 at 12:21, pac@fortuitous.com wrote: > Anyone know of a super-duper-all-in-one patch for > xfs+ext3+jfs+ (reiser is already in the kernel) ? > > -pac -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Oct 22 10:43:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MHhJc09209 for linux-xfs-outgoing; Mon, 22 Oct 2001 10:43:19 -0700 Received: from hoju-ext.nks.net (hoju-ext.nks.net [216.139.204.180]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MHhDD09183 for ; Mon, 22 Oct 2001 10:43:13 -0700 Received: from illusionary.com (two.nks.net [192.168.1.22]) by hoju-ext.nks.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id NAA11866 for ; Mon, 22 Oct 2001 13:43:07 -0400 Message-ID: <3BD45AAB.2D75ACAC@illusionary.com> Date: Mon, 22 Oct 2001 13:43:07 -0400 From: Derek Glidden X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.10-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: ext3 + xfs + jfs + reiser References: <20011022122106.A12279@bistro.marx> <1003771829.13566.38.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: > > Dunno about a single patch, but the latest Mandrake has all of those > filesystems co-existing. On a slight tangent, I was at an expo last week and a SuSE guy was also there. A brief discussion popped up about journaling filesystems and we determined that XFS was *not* going to be in SuSE 7.3 while Reiser, ext3 and JFS were. His explanation was that XFS was not stable enough but had no more technical information. Can any SuSE guys around here comment more on that? (My suspicions are really less that it's unstable and more that it touches pretty deeply into the rest of the VFS layer that made them unhappy and not want to use it for whatever reason. Some of the same stuff I've seen Alan Cox mention here.) > On Mon, 2001-10-22 at 12:21, pac@fortuitous.com wrote: > > Anyone know of a super-duper-all-in-one patch for > > xfs+ext3+jfs+ (reiser is already in the kernel) ? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- #!/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/ http://www.sciencemag.org/cgi/content/full/293/5537/2028 From owner-linux-xfs@oss.sgi.com Mon Oct 22 10:56:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MHul009480 for linux-xfs-outgoing; Mon, 22 Oct 2001 10:56:47 -0700 Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MHuhD09458 for ; Mon, 22 Oct 2001 10:56:43 -0700 Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.8.8/8.8.8) with ESMTP id NAA12350 for ; Mon, 22 Oct 2001 13:56:42 -0400 (EDT) Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-33 #38888) id <0GLM00C01CE4EB@lmco.com> for linux-xfs@oss.sgi.com; Mon, 22 Oct 2001 13:55:32 -0400 (EDT) Received: from lmco.com ([134.5.85.243]) by lmco.com (PMDF V5.2-33 #38888) with ESMTP id <0GLM00CK7CD9OD@lmco.com> for linux-xfs@oss.sgi.com; Mon, 22 Oct 2001 13:53:34 -0400 (EDT) Date: Mon, 22 Oct 2001 14:03:31 -0400 From: Jeff Layton Subject: Re: ext3 + xfs + jfs + reiser To: linux-xfs@oss.sgi.com Message-id: <3BD45F73.7ED3E6B6@lmco.com> MIME-version: 1.0 X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.2-2smp i686) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <20011022122106.A12279@bistro.marx> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk pac@fortuitous.com wrote: > Anyone know of a super-duper-all-in-one patch for > xfs+ext3+jfs+ (reiser is already in the kernel) ? A friend of mine moded the XFS patch for 2.4.10. He then built a 2.4.10 kernel with of the above in it. I can pass along the XFS patch if anyone is interested (plus links to the appropriate patches for everything else). Note: I built the kernel as well, but I have not tried any other "stuff" such as Reiser patches, LVM, LVM patches, EVMS, etc. (I'd like to try, but I don't have time right now). Jeff Layton > > > -pac > -- > .--------------------------------------------------------. > | Dr. Philip A. Carinhas | pac@fortuitous.com | > | Fortuitous Technologies Inc. | http://fortuitous.com | > | Linux Consulting & Training | Tel : 1-512-467-2154 | > `--------------------------------------------------------' From owner-linux-xfs@oss.sgi.com Mon Oct 22 11:07:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MI7Dn09800 for linux-xfs-outgoing; Mon, 22 Oct 2001 11:07:13 -0700 Received: from fep07-app.kolumbus.fi (fep07-0.kolumbus.fi [193.229.0.51]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MI78D09774 for ; Mon, 22 Oct 2001 11:07:08 -0700 Received: from there ([62.248.190.92]) by fep07-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20011022180706.JKWP5453.fep07-app.kolumbus.fi@there> for ; Mon, 22 Oct 2001 21:07:06 +0300 Content-Type: text/plain; charset="iso-8859-1" From: Hristo Grigorov To: linux-xfs@oss.sgi.com Subject: Re: ext3 + xfs + jfs + reiser Date: Mon, 22 Oct 2001 21:07:32 +0300 X-Mailer: KMail [version 1.3.1] References: <20011022122106.A12279@bistro.marx> <1003771829.13566.38.camel@stout.americas.sgi.com> <3BD45AAB.2D75ACAC@illusionary.com> In-Reply-To: <3BD45AAB.2D75ACAC@illusionary.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011022180706.JKWP5453.fep07-app.kolumbus.fi@there> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Monday 22 October 2001 20:43, Derek Glidden wrote: > Eric Sandeen wrote: > > Dunno about a single patch, but the latest Mandrake has all of those > > filesystems co-existing. > > On a slight tangent, I was at an expo last week and a SuSE guy was also > there. A brief discussion popped up about journaling filesystems and we > determined that XFS was *not* going to be in SuSE 7.3 while Reiser, ext3 > and JFS were. His explanation was that XFS was not stable enough but > had no more technical information. > > Can any SuSE guys around here comment more on that? > > (My suspicions are really less that it's unstable and more that it > touches pretty deeply into the rest of the VFS layer that made them > unhappy and not want to use it for whatever reason. Some of the same > stuff I've seen Alan Cox mention here.) > Weird... Both SuSe and RedHat pretend to aim enterprise market and at the same time they don't want to support _real_ enterprise filesystems like XFS and JFS. I would bet that most mission critical servers out there run either JFS or XFS as they are long-time tested, well documented and has some kind of official support. The only idea that comes to my mind is that they don't like the idea that commercial companies controls the sources for those FS even that they are opened to the public community. Not-stable is obviously not the reason here... Kudos for Mandrake anyway! :) -- Regards, Hristo. From owner-linux-xfs@oss.sgi.com Mon Oct 22 11:13:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MIDJZ10029 for linux-xfs-outgoing; Mon, 22 Oct 2001 11:13:19 -0700 Received: from paperboy.websocietyinc.com (paperboy.websocietyinc.com [209.20.64.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MIDDD10007 for ; Mon, 22 Oct 2001 11:13:13 -0700 Received: (qmail 3133 invoked by uid 100); 22 Oct 2001 17:56:14 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 22 Oct 2001 17:56:14 -0000 Date: Mon, 22 Oct 2001 10:56:14 -0700 (PDT) From: Justin Coffey To: Hristo Grigorov cc: linux-xfs@oss.sgi.com Subject: Re: ext3 + xfs + jfs + reiser In-Reply-To: <20011022180706.JKWP5453.fep07-app.kolumbus.fi@there> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Monday 22 October 2001 20:43, Derek Glidden wrote: > > Eric Sandeen wrote: > > > Dunno about a single patch, but the latest Mandrake has all of those > > > filesystems co-existing. > > > > On a slight tangent, I was at an expo last week and a SuSE guy was also > > there. A brief discussion popped up about journaling filesystems and we > > determined that XFS was *not* going to be in SuSE 7.3 while Reiser, ext3 > > and JFS were. His explanation was that XFS was not stable enough but > > had no more technical information. > > > > Can any SuSE guys around here comment more on that? > > > > (My suspicions are really less that it's unstable and more that it > > touches pretty deeply into the rest of the VFS layer that made them > > unhappy and not want to use it for whatever reason. Some of the same > > stuff I've seen Alan Cox mention here.) > > > > Weird... Both SuSe and RedHat pretend to aim enterprise market and at the > same time they don't want to support _real_ enterprise filesystems like XFS > and JFS. I would bet that most mission critical servers out there run either > JFS or XFS as they are long-time tested, well documented and has some > kind of official support. The only idea that comes to my mind is that they > don't like the idea that commercial companies controls the sources for those > FS even that they are opened to the public community. Not-stable is obviously > not the reason here... Kudos for Mandrake anyway! :) I'm not sure I agree. We tested smallish sized hardware raids with XFS (albeit about 3 months ago) and had a devil of a time trying to get it work correctly. Generally, we just ran into the OS not being able to mount the array, seizing and having to perform a hard reboot. Now, I'm all about fiddling and getting things to work, but for production, mission critical data? No thank you. ReiserFS has worked flawlessly for us in XFS's stead. Now, I'm trying to start a flame, and I'm not bashing XFS in anyway, this was just my last experience with it. ------------------------------------------------------------------------ Justin Coffey coffeyj@homes.com Technical Advisor http://www.homes.com ------------------------------------------------------------------------ From owner-linux-xfs@oss.sgi.com Mon Oct 22 11:17:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MIHwp10267 for linux-xfs-outgoing; Mon, 22 Oct 2001 11:17:58 -0700 Received: from paperboy.websocietyinc.com (paperboy.websocietyinc.com [209.20.64.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MIHqD10245 for ; Mon, 22 Oct 2001 11:17:52 -0700 Received: (qmail 3179 invoked by uid 100); 22 Oct 2001 18:00:53 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 22 Oct 2001 18:00:53 -0000 Date: Mon, 22 Oct 2001 11:00:53 -0700 (PDT) From: Justin Coffey To: Hristo Grigorov cc: linux-xfs@oss.sgi.com Subject: Re: ext3 + xfs + jfs + reiser In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Er, that was "Now, I'm NOT trying to start a flame." The subconscious speaks, no? > > On Monday 22 October 2001 20:43, Derek Glidden wrote: > > > Eric Sandeen wrote: > > > > Dunno about a single patch, but the latest Mandrake has all of those > > > > filesystems co-existing. > > > > > > On a slight tangent, I was at an expo last week and a SuSE guy was also > > > there. A brief discussion popped up about journaling filesystems and we > > > determined that XFS was *not* going to be in SuSE 7.3 while Reiser, ext3 > > > and JFS were. His explanation was that XFS was not stable enough but > > > had no more technical information. > > > > > > Can any SuSE guys around here comment more on that? > > > > > > (My suspicions are really less that it's unstable and more that it > > > touches pretty deeply into the rest of the VFS layer that made them > > > unhappy and not want to use it for whatever reason. Some of the same > > > stuff I've seen Alan Cox mention here.) > > > > > > > Weird... Both SuSe and RedHat pretend to aim enterprise market and at the > > same time they don't want to support _real_ enterprise filesystems like XFS > > and JFS. I would bet that most mission critical servers out there run either > > JFS or XFS as they are long-time tested, well documented and has some > > kind of official support. The only idea that comes to my mind is that they > > don't like the idea that commercial companies controls the sources for those > > FS even that they are opened to the public community. Not-stable is obviously > > not the reason here... Kudos for Mandrake anyway! :) > > I'm not sure I agree. We tested smallish sized hardware raids with XFS > (albeit about 3 months ago) and had a devil of a time trying to get it > work correctly. Generally, we just ran into the OS not being able to > mount the array, seizing and having to perform a hard reboot. Now, I'm > all about fiddling and getting things to work, but for production, mission > critical data? No thank you. ReiserFS has worked flawlessly for us in > XFS's stead. > > Now, I'm trying to start a flame, and I'm not bashing XFS in anyway, this > was just my last experience with it. > > ------------------------------------------------------------------------ > Justin Coffey coffeyj@homes.com > Technical Advisor http://www.homes.com > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------ Justin Coffey coffeyj@homes.com Technical Advisor http://www.homes.com ------------------------------------------------------------------------ From owner-linux-xfs@oss.sgi.com Mon Oct 22 11:19:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MIJF010405 for linux-xfs-outgoing; Mon, 22 Oct 2001 11:19:15 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MIJBD10366 for ; Mon, 22 Oct 2001 11:19:12 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA07110 for ; Mon, 22 Oct 2001 11:19:12 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA3375667; Mon, 22 Oct 2001 13:17:53 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA61864; Mon, 22 Oct 2001 13:17:52 -0500 (CDT) Subject: Re: ext3 + xfs + jfs + reiser From: Eric Sandeen To: Justin Coffey Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 22 Oct 2001 13:16:34 -0500 Message-Id: <1003774595.13566.42.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Justin - Did you report any of these problems? I don't see any other messages from you or your domain... I'd be interested to know the details, as several people have been using XFS+RAID successfully. We can't fix problems if we don't know about them. :) -Eric On Mon, 2001-10-22 at 12:56, Justin Coffey wrote: > I'm not sure I agree. We tested smallish sized hardware raids with XFS > (albeit about 3 months ago) and had a devil of a time trying to get it > work correctly. Generally, we just ran into the OS not being able to > mount the array, seizing and having to perform a hard reboot. Now, I'm > all about fiddling and getting things to work, but for production, mission > critical data? No thank you. ReiserFS has worked flawlessly for us in > XFS's stead. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Oct 22 11:33:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MIX8f10701 for linux-xfs-outgoing; Mon, 22 Oct 2001 11:33:08 -0700 Received: from paperboy.websocietyinc.com (paperboy.websocietyinc.com [209.20.64.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MIX3D10679 for ; Mon, 22 Oct 2001 11:33:03 -0700 Received: (qmail 3320 invoked by uid 100); 22 Oct 2001 18:16:04 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 22 Oct 2001 18:16:04 -0000 Date: Mon, 22 Oct 2001 11:16:04 -0700 (PDT) From: Justin Coffey To: Eric Sandeen cc: linux-xfs@oss.sgi.com Subject: Re: ext3 + xfs + jfs + reiser In-Reply-To: <1003774595.13566.42.camel@stout.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Very true. I'll tell you what, we've actually just freed up similar hardware to what we were using and I'll do a fresh install on it and take another look. The basic setup (though I can't remember driver versions) was an IBM Netfinity 5500 using ServeRAID drivers running RedHat 7.0 with kernel 2.4.5. We had it setup as RAID 0+1. After successfully getting the array up the first time, subsequent reboots resulted in the entire box seizing after trying to mount the array. And yes, we were bright enough to update RedHat 7.0 to a non broken compiler. I also think we updated glibc, but can't remember. BTW the purpose of it all was to test a NAS-type solution for data storage. > Did you report any of these problems? I don't see any other messages > from you or your domain... I'd be interested to know the details, as > several people have been using XFS+RAID successfully. > > We can't fix problems if we don't know about them. :) > > -Eric > > On Mon, 2001-10-22 at 12:56, Justin Coffey wrote: > > > I'm not sure I agree. We tested smallish sized hardware raids with XFS > > (albeit about 3 months ago) and had a devil of a time trying to get it > > work correctly. Generally, we just ran into the OS not being able to > > mount the array, seizing and having to perform a hard reboot. Now, I'm > > all about fiddling and getting things to work, but for production, mission > > critical data? No thank you. ReiserFS has worked flawlessly for us in > > XFS's stead. > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. > > ------------------------------------------------------------------------ Justin Coffey coffeyj@homes.com Technical Advisor http://www.homes.com ------------------------------------------------------------------------ From owner-linux-xfs@oss.sgi.com Mon Oct 22 11:39:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MIdJ710906 for linux-xfs-outgoing; Mon, 22 Oct 2001 11:39:19 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MId7D10880 for ; Mon, 22 Oct 2001 11:39:07 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA24078 for ; Mon, 22 Oct 2001 11:39:02 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA3353597 for ; Mon, 22 Oct 2001 13:37:50 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA14877 for ; Mon, 22 Oct 2001 13:37:50 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id f9MIYWL03411; Mon, 22 Oct 2001 13:34:32 -0500 Message-Id: <200110221834.f9MIYWL03411@jen.americas.sgi.com> Date: Mon, 22 Oct 2001 13:34:32 -0500 Subject: TAKE - merge up to 2.4.13-pre6 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The one filesystem related thing in here is a rootflags= boot option which could be used to pass things like noatime into an xfs root filesystem from lilo - useful for laptops. Steve Date: Mon Oct 22 11:33:30 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:105207a linux/drivers/net/8139cp.c - 1.1 linux/net/ipv4/tcp_ipv4.c - 1.37 linux/include/linux/ufs_fs.h - 1.11 linux/include/asm-sparc64/unistd.h - 1.15 linux/include/asm-sparc64/pgtable.h - 1.25 linux/include/asm-sparc/unistd.h - 1.13 linux/include/asm-ppc/types.h - 1.11 linux/include/asm-ppc/scatterlist.h - 1.6 linux/fs/ufs/namei.c - 1.11 linux/fs/ufs/inode.c - 1.15 linux/fs/ufs/ialloc.c - 1.10 linux/fs/ufs/dir.c - 1.12 linux/fs/super.c - 1.66 linux/fs/proc/root.c - 1.24 linux/fs/nfsd/nfsproc.c - 1.19 linux/fs/nfsd/nfsctl.c - 1.22 linux/fs/lockd/svc.c - 1.13 linux/fs/buffer.c - 1.89 linux/fs/binfmt_misc.c - 1.16 linux/fs/binfmt_elf.c - 1.35 linux/drivers/video/virgefb.c - 1.13 linux/drivers/video/vfb.c - 1.11 linux/drivers/video/vesafb.c - 1.15 linux/drivers/video/valkyriefb.c - 1.13 linux/drivers/video/tgafb.c - 1.16 linux/drivers/video/sgivwfb.c - 1.10 linux/drivers/video/retz3fb.c - 1.13 linux/drivers/video/platinumfb.c - 1.12 linux/drivers/video/macfb.c - 1.11 linux/drivers/video/imsttfb.c - 1.17 linux/drivers/video/igafb.c - 1.14 linux/drivers/video/fm2fb.c - 1.10 linux/drivers/video/cyberfb.c - 1.13 linux/drivers/video/controlfb.c - 1.17 linux/drivers/video/amifb.c - 1.19 linux/drivers/video/acornfb.c - 1.20 linux/drivers/usb/usb.c - 1.57 linux/drivers/usb/uhci.c - 1.54 linux/drivers/scsi/qlogicfc.h - 1.8 linux/drivers/net/yellowfin.c - 1.27 linux/drivers/net/sunqe.c - 1.19 linux/drivers/net/sunlance.c - 1.23 linux/drivers/net/sunbmac.c - 1.19 linux/drivers/net/pcnet32.c - 1.27 linux/drivers/net/myri_sbus.c - 1.13 linux/drivers/net/Makefile - 1.48 linux/drivers/net/Config.in - 1.49 linux/drivers/char/random.c - 1.19 linux/drivers/Makefile - 1.25 linux/arch/sparc64/prom/p1275.c - 1.7 linux/arch/sparc64/mm/ultra.S - 1.20 linux/arch/sparc64/mm/init.c - 1.34 linux/arch/sparc64/kernel/systbls.S - 1.21 linux/arch/sparc64/kernel/sys_sparc32.c - 1.40 linux/arch/sparc64/kernel/sparc64_ksyms.c - 1.35 linux/arch/sparc64/kernel/smp.c - 1.29 linux/arch/sparc64/kernel/setup.c - 1.23 linux/arch/sparc64/kernel/process.c - 1.24 linux/arch/sparc64/kernel/ioctl32.c - 1.44 linux/arch/sparc64/kernel/entry.S - 1.17 linux/arch/sparc64/defconfig - 1.52 linux/arch/sparc64/Makefile - 1.14 linux/arch/sparc/kernel/systbls.S - 1.18 linux/arch/i386/kernel/apm.c - 1.35 linux/arch/i386/defconfig - 1.77 linux/arch/i386/config.in - 1.66 linux/arch/alpha/kernel/core_tsunami.c - 1.20 linux/arch/alpha/kernel/core_cia.c - 1.21 linux/Makefile - 1.143 linux/MAINTAINERS - 1.78 linux/Documentation/Configure.help - 1.110 linux/CREDITS - 1.64 linux/include/linux/i2o.h - 1.16 linux/drivers/video/vga16fb.c - 1.12 linux/drivers/usb/uss720.c - 1.21 linux/arch/alpha/kernel/pci.c - 1.17 linux/include/asm-ppc/pci.h - 1.13 linux/drivers/video/tdfxfb.c - 1.15 linux/drivers/video/aty128fb.c - 1.22 linux/drivers/pci/pci.ids - 1.35 linux/include/asm-sparc64/pgalloc.h - 1.14 linux/drivers/usb/scanner.c - 1.24 linux/include/asm-sparc/pgalloc.h - 1.11 linux/Documentation/usb/scanner.txt - 1.6 linux/drivers/usb/devices.c - 1.13 linux/drivers/usb/inode.c - 1.16 linux/drivers/usb/usb-ohci.c - 1.29 linux/drivers/usb/scanner.h - 1.17 linux/drivers/net/8139too.c - 1.29 linux/Documentation/networking/8139too.txt - 1.13 linux/drivers/video/matrox/matroxfb_base.c - 1.12 linux/drivers/video/riva/fbdev.c - 1.14 linux/drivers/video/hgafb.c - 1.10 linux/include/linux/usb.h - 1.20 linux/drivers/video/sa1100fb.c - 1.9 linux/drivers/usb/serial/ftdi_sio.c - 1.23 linux/drivers/char/drm/ffb_drv.c - 1.10 linux/arch/alpha/kernel/core_titan.c - 1.4 linux/Documentation/cachetlb.txt - 1.7 linux/drivers/net/sundance.c - 1.11 linux/drivers/video/sis/sis_main.c - 1.6 linux/drivers/net/sungem.h - 1.3 linux/drivers/net/sungem.c - 1.11 linux/drivers/net/wireless/airo.c - 1.9 linux/drivers/video/aty/atyfb_base.c - 1.5 linux/drivers/char/drm/drm_vm.h - 1.5 linux/drivers/char/drm/drm_drv.h - 1.3 linux/drivers/usb/kaweth.c - 1.6 linux/arch/alpha/kernel/srm_env.c - 1.2 linux/drivers/usb/usbnet.c - 1.4 linux/drivers/video/sstfb.c - 1.3 linux/drivers/video/radeonfb.c - 1.3 linux/drivers/usb/hiddev.c - 1.2 linux/drivers/message/i2o/i2o_scsi.c - 1.2 linux/drivers/message/i2o/i2o_pci.c - 1.2 linux/drivers/message/i2o/i2o_core.c - 1.2 From owner-linux-xfs@oss.sgi.com Mon Oct 22 11:44:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MIipV11147 for linux-xfs-outgoing; Mon, 22 Oct 2001 11:44:51 -0700 Received: from smtp8.163.com ([202.108.44.249]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MIifD11124 for ; Mon, 22 Oct 2001 11:44:42 -0700 Received: from lnfk.net (fn-39-26.sssnet.com [216.28.39.26]) by smtp8.163.com (Postfix) with SMTP id DE2B11CA2D2C4; Tue, 23 Oct 2001 02:49:45 +0800 (CST) From: To: Subject: Anthrax! What's next? MIME-Version: 1.0 Content-Type: multipart/mixed;boundary= "----=_NextPart_000_0083_E296E4C5.EAD879BE" 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 Message-Id: <20011022184945.DE2B11CA2D2C4@smtp8.163.com> Date: Tue, 23 Oct 2001 02:49:45 +0800 (CST) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk ------=_NextPart_000_0083_E296E4C5.EAD879BE Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMC8vRU4iPg0KPEhU TUw+DQo8SEVBRD4NCjxNRVRBIG5hbWU9IkdFTkVSQVRPUiIgY29udGVudD0iSUJNIE5ldE9i amVjdHMgVG9wUGFnZSBWNC4wLjMgIGZvciBXaW5kb3dzIj4NCjxUSVRMRT48L1RJVExFPg0K PC9IRUFEPg0KPEJPRFkgYmdjb2xvcj0iIzAwMDAwMCI+DQo8RElWIGFsaWduPSJsZWZ0Ij4N CjxUQUJMRSB3aWR0aD0iODAlIiBiZ2NvbG9yPSIjZmZmZmZmIj4NCiAgPFRCT0RZPg0KICAg IDxUUj4NCiAgICAgIDxURD4NCiAgICAgIDxQPjxGT05UIGZhY2U9IkFyaWFsIiBzaXplPSIy Ij48Qj5GYWN0cyBhYm91dCBBbnRocmF4PC9CPjwvRk9OVD48QlI+DQogICAgICA8Rk9OVCBm YWNlPSJBcmlhbCIgc2l6ZT0iMiI+QW50aHJheCBpcyBhbiBhY3V0ZSBpbmZlY3Rpb3VzIGRp c2Vhc2UgY2F1c2VkDQogICAgICBieSB0aGUgc3BvcmUtZm9ybWluZyBiYWN0ZXJpdW0gQmFj aWxsdXMNCiAgICAgIGFudGhyYWNpcy4NCiAgICAgIFRoZSBzcG9yZSBwcm9kdWNlcyBhIHRv eGluIHRoYXQgY2FuDQogICAgICBiZSBmYXRhbC4NCiAgICAgIEhvdyBpdCBzcHJlYWRzOiBU aGUgc3BvcmVzIGNhbiBzcHJlYWQNCiAgICAgIGJ5DQogICAgICBpbmhhbGF0aW9uIG9yIGlu Z2VzdGlvbi4gU3ltcHRvbXM6DQogICAgICBTeW1wdG9tcw0KICAgICAgdXN1YWxseSBhcHBl YXIgd2l0aGluIHNldmVuIGRheXMuIEluaGFsYXRpb24NCiAgICAgIGFudGhyYXggaW5mZWN0 aW9uIGNhbiBzdGFydCBvdXQgbGlrZQ0KICAgICAgYSBjb21tb24NCiAgICAgIGNvbGQgYmVm b3JlIGFjdXRlIHN5bXB0b21zIHN1Y2ggYXMNCiAgICAgIHNldmVyZQ0KICAgICAgYnJlYXRo aW5nIHByb2JsZW1zIGFuZCBzaG9jay4gSW5mZWN0aW9uDQogICAgICBieQ0KICAgICAgY29u c3VtaW5nIGNvbnRhbWluYXRlZCBmb29kIGlzIGNoYXJhY3Rlcml6ZWQNCiAgICAgIGJ5IGlu ZmxhbW1hdGlvbiBvZiB0aGUgaW50ZXN0aW5hbCB0cmFjdCwNCiAgICAgIGxlYWRpbmcgdG8g dm9taXRpbmcgb2YgYmxvb2QgYW5kIHNldmVyZQ0KICAgICAgZGlhcnJoZWEuDQogICAgICBE ZWF0aCBjYW4gb2NjdXIgd2l0aGluIDI0IGhvdXJzIG9mDQogICAgICB0aGUgb25zZXQNCiAg ICAgIG9mIGFjdXRlIHN5bXB0b21zLiBUcmVhdG1lbnQ6IEFudGliaW90aWNzLA0KICAgICAg aW5jbHVkaW5nIHBlbmljaWxsaW4uIEEgZGVsYXkgaW4gdGhlDQogICAgICB1c2UNCiAgICAg IG9mIGFudGliaW90aWNzIC0tIGV2ZW4gaW4gdGVybXMgb2YNCiAgICAgIGhvdXJzDQogICAg ICAtLSBtYXkgbGVzc2VuIGNoYW5jZXMgZm9yIHN1cnZpdmFsPC9GT05UPjxGT05UIGZhY2U9 IkFyaWFsIiBzaXplPSIyIj4gRm9yIG1vcmUgaW5mb3JtYXRpb24gb24gY2hlbWljYWwgd2Fy ZmFyZQ0KICAgICAgb3I8QSBocmVmPSJodHRwOi8vd3d3Lmdlb2NpdGllcy5jb20vUGVudGFn b24vUXVhcnRlcnMvNDM4OS8iIHRhcmdldD0iX2JsYW5rIj4gdmlzaXQgdGhpcyB3ZWJzaXRl PC9BPiBvciA8QSBocmVmPSJodHRwOi8vdHJhdmVsLnN0YXRlLmdvdi9jYncuaHRtbCIgdGFy Z2V0PSJfYmxhbmsiPnZpc2l0IHRoaXMgd2Vic2l0ZTwvQT4gPC9GT05UPjxCUj4NCiAgICAg IDxCUj4NCiAgICAgIDxGT05UIGZhY2U9IkFyaWFsIiBzaXplPSIyIj48Qj5XaGF0IG90aGVy IEJpb2xvZ2ljYWwgV2FyZmFyZSBpcyBuZXh0PzwvQj4gU21hbGwgUG94LCBFYm9sYSwgTXVz dGFyZCBHYXM/IEV0Yy4uLi4/PC9GT05UPjxCUj4NCiAgICAgIDxCUj4NCiAgICAgIDxGT05U IGZhY2U9IkFyaWFsIiBzaXplPSIyIj48Qj5XZSBoYXZlIGZ1bGwgZmFpdGggaW4gb3VyIEdv dmVybm1lbnQgdG8gcHJvdGVjdA0KICAgICAgdXM8L0I+LiBUaGV5J3JlIHRlbGxpbmcgdXMg bm90IHRvIHdvcnJ5LCB0byBsaXZlDQogICAgICBvdXIgbGl2ZXMgYXMgdXN1YWwgYW5kIHRo YXQgaXMgZXhhY3RseQ0KICAgICAgd2hhdA0KICAgICAgd2UgYXJlIGRvaW5nIHdpdGggdGhl IGV4ZWNwdGlvbiBvZg0KICAgICAgYSBsaXR0bGUNCiAgICAgIHNlbGYgcHJvdGVjdGlvbi4g SnVzdCBpbiBjYXNlLi48L0ZPTlQ+PEJSPg0KICAgICAgPEZPTlQgY29sb3I9IiNjYzAwMDAi IGZhY2U9IkFyaWFsIiBzaXplPSIyIj48Qj48QlI+DQogICAgICBIZXJlIGlzIHdoYXQgd2Ug bmVlZCB0byBkbyBBU0FQPC9CPiE8L0ZPTlQ+PEJSPg0KICAgICAgPEJSPg0KICAgICAgPEZP TlQgZmFjZT0iQXJpYWwiIHNpemU9IjIiPjxCPjEpIDxGT05UIGNvbG9yPSIjY2MwMDAwIj5C dXkgYSBHQVMgTUFTSyE8L0ZPTlQ+IC0gQSBHQVMgTUFTSzwvQj4gbWF5IG9uZSBkYXkgc2F2 ZSB5b3VyIGxpZmUuIFRoZXkgaGF2ZSBhDQogICAgICBzaGVsZiBsaWZlIG9mIDE1IHllYXJz IGFuZCBjb21lIGluDQogICAgICBjaGlsZHJlbnMNCiAgICAgIHNpemVzLiBXZSBtYXkgbmV2 ZXIgbmVlZCB0aGVtIGFuZCB3ZQ0KICAgICAgcHJheQ0KICAgICAgdG8gR29kIGl0IG5ldmVy IGNvbWVzIGRvd24gdG8gaXQgYnV0DQogICAgICBpZiBpdA0KICAgICAgZG9lcyB5b3UgYW5k IHRoZSByZXN0IG9mIHRoZSB3b3JsZA0KICAgICAgc2hvdWxkDQogICAgICBiZSBwcmVwYXJl ZC4gWW91ciBudW1iZXIgb25lIGJlc3QgcHJvdGVjdGlvbg0KICAgICAgaXMgR2FzIE1hc2tz IGFuZCBjaGVtaWNhbCBzdWl0cy4gV2UNCiAgICAgIHN1Z2dlc3QNCiAgICAgIHlvdSBCVVkg T05FIFRPREFZLiBXZSBoYXZlIGZvdW5kIHRoZQ0KICAgICAgYmVzdA0KICAgICAgcXVhbGl0 eSBhbmQgbG93ZXN0IHByaWNlZCA8QSBocmVmPSJodHRwOi8vbWVtYmVycy50cmlwb2QuY28u dWsvc3RldmV6bWlsbGVyP2FmZmlsaWF0ZTQ1MDkyMSI+R0FTIE1BU0tTIEhFUkU8L0E+IG9y IGNhbGwgMS04NjYtOTMyLTI4Nzg8L0ZPTlQ+PEZPTlQgZmFjZT0iQXJpYWwiIHNpemU9IjIi PiBmb3IgbW9yZSBpbmZvLjwvRk9OVD48QlI+DQogICAgICA8QlI+DQogICAgICA8Rk9OVCBm YWNlPSJBcmlhbCIgc2l6ZT0iMiI+PEI+Mi4pPC9CPiA8L0ZPTlQ+PEZPTlQgZmFjZT0iQXJp YWwiIHNpemU9IjIiIGNvbG9yPSIjY2MwMDAwIj48Qj5FbWVyZ2VuY3kgRm9vZDwvQj48L0ZP TlQ+PEZPTlQgZmFjZT0iQXJpYWwiIHNpemU9IjIiPiAtIDxCPkVtZXJnZW5jeSBGb29kPC9C PiBpcyBpbXBvcnRhbnQgaXMgZm9yIHNvbWUgcmVhc29uIG91ciBmb29kDQogICAgICBzb3Vy Y2UgY2FuJ3QgYmUgdHJ1c3RlZCBmb3IgYSBmZXcgZGF5cy4NCiAgICAgIElmDQogICAgICBm b3Igc29tZSByZWFzb24gb3VyIGZvb2Qgc291cmNlIGdldCdzDQogICAgICBjb250YW1pbmF0 ZWQNCiAgICAgIGFuZCBpdCBuZWVkcyB0byBiZSB0ZXN0ZWQgaGF2ZSBzb21ldGhpbmcNCiAg ICAgIGVsc2UgcmVhZHkuIEpVU1QgSU4gQ0FTRS4gSWYgeW91IG5ldmVyDQogICAgICBuZWVk DQogICAgICBpdCBHcmVhdCEgQnV0IGlmIHlvdSBkbyB5b3Ugd2lsbCBiZQ0KICAgICAgZ2xh ZA0KICAgICAgeW91IGhhdmUgYSBzb3VyY2UuIFdlIGhhdmUgZm91bmQgdGhhdA0KICAgICAg dGhpcw0KICAgICAgd2Vic2l0ZSBoYXMgYSB2YXJpZXR5IG9mIEFybXkgU3VycGx1cw0KICAg ICAgZm9vZA0KICAgICAgYW5kIG1pbGl0YXJ5IGdlYXIuIDxBIGhyZWY9Imh0dHA6Ly93d3cy LnJhbmdlcnN1cnBsdXMuY29tLz9hZmZpbGlhdGUzNDA1bWlsIiB0YXJnZXQ9Il9ibGFuayI+ VmlzaXQgdGhpcyB3ZWJzaXRlPC9BPiBvciBjYWxsIDMwMS05NDctODAyNiBmb3IgbW9yZSBp bmZvLjwvRk9OVD48QlI+DQogICAgICA8QlI+DQogICAgICA8Rk9OVCBzaXplPSIyIiBmYWNl PSJBcmlhbCI+PEI+My4pPC9CPiA8Qj48Rk9OVCBjb2xvcj0iI2NjMDAwMCI+UGxhbjwvRk9O VD48L0I+IDxCPjxGT05UIGNvbG9yPSIjY2MwMDAwIj5hbmQgVW5kZXJzdGFuZDwvRk9OVD48 L0I+LSBQbGVhc2UgZG9uJ3QgbWlzdW5kZXJzdGFuZC4uLiB3ZSBhcmUgYXNraW5nDQogICAg ICB5b3UgdG8gYmUgY2FsbSBhbmQgdG8gdHJ1c3Qgb3VyIGdvdmVybm1lbnQuDQogICAgICBB bGwgd2UgYXJlIHNheWluZyBpcyB0byBoYXZlIGEgJnF1b3Q7anVzdA0KICAgICAgaW4gY2Fz ZSBwbGFuJnF1b3Q7LiBUcnkgdG8gZmluZCBhIHJlbW90ZQ0KICAgICAgcGxhY2UgYXdheSBm cm9tIGFueSBtYWpvciBwb3B1bGF0aW9uDQogICAgICBvciBpbXBvcnRhbnQNCiAgICAgIGlu ZHVzdHJpZXMgdGhhdCBtYXkgYmUgYSB0YXJnZXQgSUYNCiAgICAgIFlPVSBORUVEDQogICAg ICBUTyBMRUFWRS4uIFN0YXkgYXdheSBmcm9tIHVudXN1YWwgcGVvcGxlDQogICAgICBvciB2 ZWhpY2xlcy4gU3RheSBpbiB0dW5lIHdpdGggdGhlDQogICAgICBuZXdzLg0KICAgICAgRG9u J3QgYmVsaWV2ZSBhbnkgcnVtb3JzIG9yIGNoYWluIGxldHRlcnMNCiAgICAgIHlvdSBtYXkg cmVhZC4gQSBnb29kIHNvdXJjZSBmb3IgV2hhdCdzDQogICAgICByZWFsDQogICAgICBvciB3 aGF0J3Mgbm90IGlzIDxBIGhyZWY9Imh0dHA6Ly93d3cuc25vcGVzMi5jb20vICIgdGFyZ2V0 PSJfYmxhbmsiPlZpc2l0IHRoaXMgd2Vic2l0ZTwvQT48L0ZPTlQ+PEJSPg0KICAgICAgPEJS Pg0KICAgICAgPEJSPg0KICAgICAgPEZPTlQgZmFjZT0iQXJpYWwiIHNpemU9IjIiPlRvIGJl IHJlbW92ZWQgZnJvbSB0aGlzIGVtYWlsIGxpc3QgcGxlYXNlDQogICAgICByZXBseSB0byA8 QSBocmVmPSJtYWlsdG86cmVtb3ZlMjAwMkBleGNpdGUuY29tP1N1YmplY3Q9UkVNT1ZFIj5y ZW1vdmUyMDAyQGV4Y2l0ZS5jb208L0E+PC9GT05UPjxCUj4NCiAgICAgIDxCUj4NCiAgICAg IDxCUj4NCiAgICAgIDxCUj4NCiAgICAgIDwvUD4NCiAgICAgIDxQPjxCUj4NCiAgICAgIDwv UD4NCiAgICAgIDwvVEQ+DQogICAgPC9UUj4NCiAgPC9UQk9EWT4NCjwvVEFCTEU+DQo8L0RJ Vj4NCjwvQk9EWT4NCjwvSFRNTD4NCiAgICA= ------=_NextPart_000_0083_E296E4C5.EAD879BE-- From owner-linux-xfs@oss.sgi.com Mon Oct 22 11:54:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MIsmv11411 for linux-xfs-outgoing; Mon, 22 Oct 2001 11:54:48 -0700 Received: from chef.cc.absoval.com (cpe-66-1-218-101.fl.sprintbbd.net [66.1.218.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MIsiD11389 for ; Mon, 22 Oct 2001 11:54:44 -0700 Received: from ieee.org (IDENT:bs@thebs.cc.absoval.com [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id OAA14115; Mon, 22 Oct 2001 14:54:29 -0400 Message-ID: <3BD46B6C.A0266E1B@ieee.org> Date: Mon, 22 Oct 2001 14:54:36 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts/AbsoluteValueSystems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Justin Coffey CC: Hristo Grigorov , linux-xfs@oss.sgi.com Subject: Re: ext3 + xfs + jfs + reiser References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Justin Coffey wrote: > Generally, we just ran into the OS not being able to mount the > array, seizing and having to perform a hard reboot. That's odd. You couldn't even get it to mount the volume??? What hardware? I have used the stock 2.4.3-XFS kernel with a variety of hardware RAID controllers now, using initrds to load the necessary controller, scsi/disk and XFS modules. The only time I had "issues" is when I didn't load them in the right order (and that was just a SCSI issue). -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ---------------------------------------------------------------- The US National ID is an enhanced Social Security Number. It will give those who abuse it more information than ever before. And just like the SSN, they will ignore all the regulations. From owner-linux-xfs@oss.sgi.com Mon Oct 22 11:57:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MIvAW11550 for linux-xfs-outgoing; Mon, 22 Oct 2001 11:57:10 -0700 Received: from paperboy.websocietyinc.com (paperboy.websocietyinc.com [209.20.64.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MIv5D11527 for ; Mon, 22 Oct 2001 11:57:05 -0700 Received: (qmail 3502 invoked by uid 100); 22 Oct 2001 18:40:06 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 22 Oct 2001 18:40:06 -0000 Date: Mon, 22 Oct 2001 11:40:06 -0700 (PDT) From: Justin Coffey To: Bryan-TheBS-Smith cc: Hristo Grigorov , linux-xfs@oss.sgi.com Subject: Re: ext3 + xfs + jfs + reiser In-Reply-To: <3BD46B6C.A0266E1B@ieee.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk IBM Netfinity 5500 w/ServeRAID II, RedHat 7.0 w/2.4.5+xfs compiled with an updated compiler and I *think* updated libraries. We were running RAID 0+1. > Justin Coffey wrote: > > Generally, we just ran into the OS not being able to mount the > > array, seizing and having to perform a hard reboot. > > That's odd. You couldn't even get it to mount the volume??? > What hardware? > > I have used the stock 2.4.3-XFS kernel with a variety of hardware > RAID controllers now, using initrds to load the necessary > controller, scsi/disk and XFS modules. The only time I had "issues" > is when I didn't load them in the right order (and that was just a > SCSI issue). > > -- TheBS > > -- > Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 > Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org > President SmithConcepts, Inc. http://www.SmithConcepts.com > ---------------------------------------------------------------- > The US National ID is an enhanced Social Security Number. It > will give those who abuse it more information than ever before. > And just like the SSN, they will ignore all the regulations. > ------------------------------------------------------------------------ Justin Coffey coffeyj@homes.com Technical Advisor http://www.homes.com ------------------------------------------------------------------------ From owner-linux-xfs@oss.sgi.com Mon Oct 22 12:00:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MJ0jq11750 for linux-xfs-outgoing; Mon, 22 Oct 2001 12:00:45 -0700 Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MJ0eD11727 for ; Mon, 22 Oct 2001 12:00:40 -0700 Received: from club-internet.fr (bas4-55.idf.w.club-internet.fr [213.44.244.55]) by relay-1v.club-internet.fr (Postfix) with ESMTP id E816B16C5; Mon, 22 Oct 2001 21:00:36 +0200 (CEST) Message-ID: <3BD46D25.110095E0@club-internet.fr> Date: Mon, 22 Oct 2001 21:01:57 +0200 From: Jean Francois Martinez X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.5-SGI_XFS_1.0.1_Indy i586) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Cc: Eric Sandeen , pac@fortuitous.com Subject: Re: ext3 + xfs + jfs + reiser References: <20011022122106.A12279@bistro.marx> <1003771829.13566.38.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen a écrit : > > Dunno about a single patch, but the latest Mandrake has all of those > filesystems co-existing. > I think this is silly and demagogic. There are reasons to include ext3 due to the easy transition but for the other three I am a man of simple tastes: I only want the best one. And I think it is XFS. :-) > -Eric > > On Mon, 2001-10-22 at 12:21, pac@fortuitous.com wrote: > > Anyone know of a super-duper-all-in-one patch for > > xfs+ext3+jfs+ (reiser is already in the kernel) ? > > > > -pac > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. -- Jean Francois Martinez The Independence project: because Linux should be for everyone http://independence.seul.org From owner-linux-xfs@oss.sgi.com Mon Oct 22 12:01:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MJ1jt11892 for linux-xfs-outgoing; Mon, 22 Oct 2001 12:01:45 -0700 Received: from chef.cc.absoval.com (cpe-66-1-218-101.fl.sprintbbd.net [66.1.218.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MJ1eD11865 for ; Mon, 22 Oct 2001 12:01:40 -0700 Received: from ieee.org (IDENT:bs@thebs.cc.absoval.com [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id PAA14180; Mon, 22 Oct 2001 15:01:29 -0400 Message-ID: <3BD46D11.567DB68D@ieee.org> Date: Mon, 22 Oct 2001 15:01:37 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts/AbsoluteValueSystems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Justin Coffey CC: Hristo Grigorov , linux-xfs@oss.sgi.com Subject: Re: ext3 + xfs + jfs + reiser References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Justin Coffey wrote: > IBM Netfinity 5500 w/ServeRAID II, RedHat 7.0 w/2.4.5+xfs > compiled with an updated compiler and I *think* updated libraries. Even if you update the RedHat compiler, do *NOT* use RedHat 7.0's GCC "2.96" at all for kernel compiles. You want to make sure the kernel Makefile (in /usr/src/linux) is changed to "kgcc" on RedHat 7.x, which uses 2.91.66 for kernel compiles. "kgcc" is the issue. I had big time mount issues when compiling with 2.96. BTW, why did you go to stock kernel 2.4.5 + XFS rather than RedHat 2.4.3 + XFS? I've been humming with the heavily RedHat patched 2.4.3 release + XFS with 0 issues on a number of systems. > We were running RAID 0+1. Again, the fact that you couldn't mount volumes tells me you either didn't have the correct modules/drivers support in your kernel or used GCC 2.96. -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ---------------------------------------------------------------- The US National ID is an enhanced Social Security Number. It will give those who abuse it more information than ever before. And just like the SSN, they will ignore all the regulations. From owner-linux-xfs@oss.sgi.com Mon Oct 22 12:07:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MJ74012196 for linux-xfs-outgoing; Mon, 22 Oct 2001 12:07:04 -0700 Received: from graendal.lightconsulting.com (c498624-a.frmt1.sfba.home.com [24.15.81.65]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MJ6xD12169 for ; Mon, 22 Oct 2001 12:07:01 -0700 Received: (from thalakan@localhost) by graendal.lightconsulting.com (8.11.6/8.11.3) id f9MJ6wr62250 for linux-xfs@oss.sgi.com; Mon, 22 Oct 2001 12:06:58 -0700 (PDT) (envelope-from thalakan) Date: Mon, 22 Oct 2001 12:06:58 -0700 From: Jason Spence To: linux-xfs@oss.sgi.com Subject: Re: Cannot mount IRIX cdroms using XFS on Linux Message-ID: <20011022120658.A62220@graendal.lightconsulting.com> References: <20011022052346.A60926@graendal.lightconsulting.com> <20011022143427.A14386@caldera.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011022143427.A14386@caldera.de>; from hch@ns.caldera.de on Mon, Oct 22, 2001 at 02:34:27PM +0200 X-Operating-System: FreeBSD graendal.lightconsulting.com 4.4-RELEASE FreeBSD 4.4-RELEASE Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Oct 22, 2001 at 02:34:27PM +0200, Christoph Hellwig developed a new theory of relativity and: > On Mon, Oct 22, 2001 at 08:30:16AM -0400, Joshua Baker-LePain wrote: > > On Mon, 22 Oct 2001 at 5:23am, Jason Spence wrote > > > > > So I get XFS working on my Linux machine[1], and try to mount the IRIX > > > dist cdroms. Hmm, they don't mount. The kernel doesn't even > > > recognize /dev/hdd1 as a device (fdisk can parse the partition table, > > > though). The kernel has SGI partition table support, right? Yeah, I > > > can mount the IRIX drive from the Indy. So lessee here, the sgi > > > > IIRC, IRIX distro CDs are EFS, not XFS... > > *nod* > > But EFs is supported (read-only) by Linux 2.2.1+. > So try mount -t efs. Ah, that works. Thanks :) -- - Jason Sex is a natural bodily process, like a stroke. From owner-linux-xfs@oss.sgi.com Mon Oct 22 12:09:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MJ9IA12409 for linux-xfs-outgoing; Mon, 22 Oct 2001 12:09:18 -0700 Received: from paperboy.websocietyinc.com (paperboy.websocietyinc.com [209.20.64.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MJ9ED12387 for ; Mon, 22 Oct 2001 12:09:14 -0700 Received: (qmail 3576 invoked by uid 100); 22 Oct 2001 18:52:16 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 22 Oct 2001 18:52:16 -0000 Date: Mon, 22 Oct 2001 11:52:16 -0700 (PDT) From: Justin Coffey To: Bryan-TheBS-Smith cc: Hristo Grigorov , linux-xfs@oss.sgi.com Subject: Re: ext3 + xfs + jfs + reiser In-Reply-To: <3BD46D11.567DB68D@ieee.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Even if you update the RedHat compiler, do *NOT* use RedHat 7.0's > GCC "2.96" at all for kernel compiles. You want to make sure the > kernel Makefile (in /usr/src/linux) is changed to "kgcc" on RedHat > 7.x, which uses 2.91.66 for kernel compiles. "kgcc" is the issue. > I had big time mount issues when compiling with 2.96. I definitely made the change to kgcc. I couldn't even get the kernel to compile without that. > BTW, why did you go to stock kernel 2.4.5 + XFS rather than RedHat > 2.4.3 + XFS? I've been humming with the heavily RedHat patched > 2.4.3 release + XFS with 0 issues on a number of systems. Ya know, I've just never trusted things like this unless I compile them myself. I dunno, I'm just strange that way. > > We were running RAID 0+1. > > Again, the fact that you couldn't mount volumes tells me you either > didn't have the correct modules/drivers support in your kernel or > used GCC 2.96. Well, here's the issue with that. The same kernel mounted non-RAIDed volumes just dandy. ------------------------------------------------------------------------ Justin Coffey coffeyj@homes.com Technical Advisor http://www.homes.com ------------------------------------------------------------------------ From owner-linux-xfs@oss.sgi.com Mon Oct 22 12:14:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MJEs412695 for linux-xfs-outgoing; Mon, 22 Oct 2001 12:14:54 -0700 Received: from ctgw.lbsd.net (ctgw.lbsd.net [196.25.111.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MJEmD12673 for ; Mon, 22 Oct 2001 12:14:48 -0700 Received: from localhost (nkukard@localhost) by ctgw.lbsd.net (8.12.1/8.12.1) with ESMTP id f9MLFJSm007817; Mon, 22 Oct 2001 21:15:20 GMT Date: Mon, 22 Oct 2001 21:15:19 +0000 (UTC) From: Nigel Kukard To: Jean Francois Martinez cc: , Eric Sandeen , Subject: Re: ext3 + xfs + jfs + reiser In-Reply-To: <3BD46D25.110095E0@club-internet.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > Dunno about a single patch, but the latest Mandrake has all of those > > filesystems co-existing. > > > > > I think this is silly and demagogic. There are reasons to include ext3 > due to the easy transition but for the other three I am a man of simple > tastes: I only want the best one. And I think it is XFS. :-) > you think? hahahah, its a FACT!!!!! X F S I S T H E B E S T ! -Nigel -- ================================================================================ Contact Details --------------- Name: Nigel Kukard GSM Mobile: (+27) 082 564 2120 GSM Fax: (+27) 082 131 564 2120 Email: nkukard@linuxrulz.za.net Organizations ------------- - LinuxRulz Url: http://www.linuxrulz.za.net Position: Owner - Linux Based Systems Design Url: http://www.lbsd.net Position: Systems Designer, Programmer - Lando Technologies Url: http://www.lando.co.za Position: Linux Systems/Network Administrator From owner-linux-xfs@oss.sgi.com Mon Oct 22 12:24:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MJO5e13124 for linux-xfs-outgoing; Mon, 22 Oct 2001 12:24:05 -0700 Received: from chef.cc.absoval.com (cpe-66-1-218-101.fl.sprintbbd.net [66.1.218.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MJO1D13096 for ; Mon, 22 Oct 2001 12:24:01 -0700 Received: from ieee.org (IDENT:bs@thebs.cc.absoval.com [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id PAA14361; Mon, 22 Oct 2001 15:23:46 -0400 Message-ID: <3BD4724A.13A07C32@ieee.org> Date: Mon, 22 Oct 2001 15:23:54 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts/AbsoluteValueSystems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Justin Coffey CC: Hristo Grigorov , linux-xfs@oss.sgi.com Subject: Re: ext3 + xfs + jfs + reiser References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Justin Coffey wrote: > Well, here's the issue with that. The same kernel mounted non-RAIDed > volumes just dandy. Sounds like a hardware driver issue. The OS shouldn't see any difference with hardware RAID. What kernel were you using for ReiserFS? -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ---------------------------------------------------------------- The US National ID is an enhanced Social Security Number. It will give those who abuse it more information than ever before. And just like the SSN, they will ignore all the regulations. From owner-linux-xfs@oss.sgi.com Mon Oct 22 12:25:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MJPIp13268 for linux-xfs-outgoing; Mon, 22 Oct 2001 12:25:18 -0700 Received: from paperboy.websocietyinc.com (paperboy.websocietyinc.com [209.20.64.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MJPFD13244 for ; Mon, 22 Oct 2001 12:25:15 -0700 Received: (qmail 3645 invoked by uid 100); 22 Oct 2001 19:08:16 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 22 Oct 2001 19:08:16 -0000 Date: Mon, 22 Oct 2001 12:08:16 -0700 (PDT) From: Justin Coffey To: Bryan-TheBS-Smith cc: Hristo Grigorov , linux-xfs@oss.sgi.com Subject: Re: ext3 + xfs + jfs + reiser In-Reply-To: <3BD4724A.13A07C32@ieee.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Sounds like a hardware driver issue. The OS shouldn't see any > difference with hardware RAID. What kernel were you using for > ReiserFS? 2.4.5 I believe, but we've since upgraded it. ------------------------------------------------------------------------ Justin Coffey coffeyj@homes.com Technical Advisor http://www.homes.com ------------------------------------------------------------------------ From owner-linux-xfs@oss.sgi.com Mon Oct 22 12:26:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MJQ5H13423 for linux-xfs-outgoing; Mon, 22 Oct 2001 12:26:05 -0700 Received: from paperboy.websocietyinc.com (paperboy.websocietyinc.com [209.20.64.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MJQ2D13397 for ; Mon, 22 Oct 2001 12:26:02 -0700 Received: (qmail 3666 invoked by uid 100); 22 Oct 2001 19:09:03 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 22 Oct 2001 19:09:03 -0000 Date: Mon, 22 Oct 2001 12:09:03 -0700 (PDT) From: Justin Coffey To: Bryan-TheBS-Smith cc: Hristo Grigorov , linux-xfs@oss.sgi.com Subject: Re: ext3 + xfs + jfs + reiser In-Reply-To: <3BD4724A.13A07C32@ieee.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Sounds like a hardware driver issue. The OS shouldn't see any > difference with hardware RAID. What kernel were you using for > ReiserFS? That was my conclusion as well, which is why I moved to Reiser. I just assumed there was some issue with the driver and XFS. ------------------------------------------------------------------------ Justin Coffey coffeyj@homes.com Technical Advisor http://www.homes.com ------------------------------------------------------------------------ From owner-linux-xfs@oss.sgi.com Mon Oct 22 12:31:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MJV8u13799 for linux-xfs-outgoing; Mon, 22 Oct 2001 12:31:08 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MJV4D13777 for ; Mon, 22 Oct 2001 12:31:04 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id VAA371324 for ; Mon, 22 Oct 2001 21:31:04 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA3371224; Mon, 22 Oct 2001 14:29:39 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA85589; Mon, 22 Oct 2001 14:29:38 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9MJQJ403642; Mon, 22 Oct 2001 14:26:19 -0500 Message-Id: <200110221926.f9MJQJ403642@jen.americas.sgi.com> To: Justin Coffey cc: Bryan-TheBS-Smith , Hristo Grigorov , linux-xfs@oss.sgi.com Subject: Re: ext3 + xfs + jfs + reiser References: Comments: In-reply-to Justin Coffey message dated "Mon, 22 Oct 2001 12:08:16 -0700." Date: Mon, 22 Oct 2001 14:26:19 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > > Sounds like a hardware driver issue. The OS shouldn't see any > > difference with hardware RAID. What kernel were you using for > > ReiserFS? > > 2.4.5 I believe, but we've since upgraded it. > Two differences between XFS and other filesystems on Linux is that XFS will: a) Access the first and last block on the volume during mount b) Do some 512 byte reads and writes and some larger 512 byte aligned writes. However, there should be nothing in what XFS does that any self respecting disk driver/hardware combo should not support - provided it provides 512 byte sector aligned access. Steve > ------------------------------------------------------------------------ > Justin Coffey coffeyj@homes.com > Technical Advisor http://www.homes.com > ------------------------------------------------------------------------ From owner-linux-xfs@oss.sgi.com Mon Oct 22 13:05:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MK5rH15042 for linux-xfs-outgoing; Mon, 22 Oct 2001 13:05:53 -0700 Received: from pipt.oz.cc.utah.edu (jdr1529@pipt.oz.cc.utah.edu [155.99.2.7]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MK5pD15020 for ; Mon, 22 Oct 2001 13:05:51 -0700 Received: from localhost (jdr1529@localhost) by pipt.oz.cc.utah.edu (8.9.2/8.9.2) with ESMTP id OAA03575; Mon, 22 Oct 2001 14:04:07 -0600 (MDT) Date: Mon, 22 Oct 2001 14:04:07 -0600 (MDT) From: james rich To: Robin Humble cc: linux-xfs@oss.sgi.com Subject: Re: Daily XFS CVS RPMS In-Reply-To: <200110192316.XAA00329@groucho.maths.monash.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 20 Oct 2001, Robin Humble wrote: > If your distro has XF 4.1.* (any yet?) then a newer kernel isn't a problem. Slackware 8.0 has XFree86 4.1.0 James Rich From owner-linux-xfs@oss.sgi.com Mon Oct 22 15:18:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MMIAq17452 for linux-xfs-outgoing; Mon, 22 Oct 2001 15:18:10 -0700 Received: from mailgate.salzburg.co.at (mail.salzburg.co.at [195.70.97.72]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MMI6D17423 for ; Mon, 22 Oct 2001 15:18:07 -0700 Received: from athlon (sbg-200.salzburg.co.at [195.70.109.75]) by mailgate.salzburg.co.at (8.9.3/8.9.3) with SMTP id XAA12953 for ; Mon, 22 Oct 2001 23:22:45 GMT (envelope-from cortiel@salzburg.co.at) Message-Id: <200110222322.XAA12953@mailgate.salzburg.co.at> Date: Tue, 23 Oct 2001 00:18:29 +0200 To: linux-xfs@oss.sgi.com From: cortiel Subject: XFS on a Red hat 7.1 System? Reply-To: cortiel@salzburg.co.at X-Mailer: Opera 5.12 build 932 X-Priority: 3 (Normal) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello everybody! my name is peter cortiel. i'm heard that there is a cdrom availabel to install xfs on a red hat installation.so i have a hird disc (like the anaconda-patch for reiserfs on a red hat 71 system) is this correctly wat i heard? PS: excuse me for my bad english. :-) From owner-linux-xfs@oss.sgi.com Mon Oct 22 15:19:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MMJMi17543 for linux-xfs-outgoing; Mon, 22 Oct 2001 15:19:22 -0700 Received: from mailgate.salzburg.co.at (mail.salzburg.co.at [195.70.97.72]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MMJJD17519 for ; Mon, 22 Oct 2001 15:19:19 -0700 Received: from athlon (sbg-200.salzburg.co.at [195.70.109.75]) by mailgate.salzburg.co.at (8.9.3/8.9.3) with SMTP id XAA12981 for ; Mon, 22 Oct 2001 23:23:58 GMT (envelope-from cortiel@salzburg.co.at) Message-Id: <200110222323.XAA12981@mailgate.salzburg.co.at> Date: Tue, 23 Oct 2001 00:19:42 +0200 To: linux-xfs@oss.sgi.com From: cortiel Subject: XFS on a Red hat 7.1 System? Reply-To: cortiel@salzburg.co.at X-Mailer: Opera 5.12 build 932 X-Priority: 3 (Normal) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello everybody! my name is peter cortiel. i'm heard that there is a cdrom availabel to install xfs on a red hat installation.so i have a third disc (like the anaconda-patch for reiserfs on a red hat 71 system) is this correctly wat i heard? PS: excuse me for my bad english. :-) From owner-linux-xfs@oss.sgi.com Mon Oct 22 15:26:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MMQo517876 for linux-xfs-outgoing; Mon, 22 Oct 2001 15:26:50 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MMQlD17854 for ; Mon, 22 Oct 2001 15:26:47 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA00722 for ; Mon, 22 Oct 2001 15:26:02 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA3378873; Mon, 22 Oct 2001 17:25:30 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id RAA17588; Mon, 22 Oct 2001 17:25:18 -0500 (CDT) Subject: Re: XFS on a Red hat 7.1 System? From: Eric Sandeen To: cortiel@salzburg.co.at Cc: linux-xfs@oss.sgi.com In-Reply-To: <200110222323.XAA12981@mailgate.salzburg.co.at> References: <200110222323.XAA12981@mailgate.salzburg.co.at> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 22 Oct 2001 17:23:58 -0500 Message-Id: <1003789439.13550.67.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Peter - Yes, it's at ftp://oss.sgi.com/projects/xfs/download/Release-1.0.1/installer And thank you for not asking about 7.2! :-) -Eric On Mon, 2001-10-22 at 17:19, cortiel wrote: > Hello everybody! > > my name is peter cortiel. i'm heard that there is a cdrom availabel to install xfs on a red hat installation.so i have a third disc (like the anaconda-patch for reiserfs on a red > hat 71 system) > > is this correctly wat i heard? > > > PS: excuse me for my bad english. :-) > > > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Oct 22 15:28:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MMSYT18011 for linux-xfs-outgoing; Mon, 22 Oct 2001 15:28:34 -0700 Received: from chef.cc.absoval.com (cpe-66-1-218-101.fl.sprintbbd.net [66.1.218.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MMSTD17982 for ; Mon, 22 Oct 2001 15:28:29 -0700 Received: from ieee.org (IDENT:bs@thebs.cc.absoval.com [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id SAA15096; Mon, 22 Oct 2001 18:28:19 -0400 Message-ID: <3BD49D8B.8C9AADCF@ieee.org> Date: Mon, 22 Oct 2001 18:28:27 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts/AbsoluteValueSystems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: cortiel@salzburg.co.at CC: linux-xfs@oss.sgi.com Subject: Re: XFS on a Red hat 7.1 System? References: <200110222323.XAA12981@mailgate.salzburg.co.at> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk cortiel wrote: > Hello everybody! > my name is peter cortiel. i'm heard that there is a cdrom > availabel to install xfs on a red hat installation.so i have > a third disc (like the anaconda-patch for reiserfs on a red > hat 71 system) > is this correctly wat i heard? Yes. The "third disc" for XFS is the disk you actually boot, and it will automatically handle setting up XFS and installing the correct kernel/utilities for you -- in conjuction with RedHat 7.1. Grab it here: ftp://oss.sgi.com/projects/xfs/download/Release-1.0.1/installer/ > PS: excuse me for my bad english. :-) No problem. Just excuse me as I'm YAIA who doesn't know anything but poor English. ;-PPP -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ---------------------------------------------------------------- Web site defacements are as much of a national security risk as inner city kids spray painting. There is nothing of value, and nothing that can't be fixed with a little re-paint. You'd have to have the equivalent stupidity of someone parking an F-18 in downtown LA. Even then, the only damage would be a new scheme! The US government wants life imprisonment for such "terrorism." From owner-linux-xfs@oss.sgi.com Mon Oct 22 15:53:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MMrR618441 for linux-xfs-outgoing; Mon, 22 Oct 2001 15:53:27 -0700 Received: from k-7.stesmi.com (IDENT:root@as4-1-7.has.s.bonet.se [217.215.31.238]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MMrND18419 for ; Mon, 22 Oct 2001 15:53:23 -0700 Received: from stesmi.com (voyager.stesmi.com [192.168.1.11]) by k-7.stesmi.com (8.11.2/8.8.7) with ESMTP id f9MMq1S08627; Tue, 23 Oct 2001 00:52:01 +0200 Message-ID: <3BD4A343.9060905@stesmi.com> Date: Tue, 23 Oct 2001 00:52:51 +0200 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20010913 X-Accept-Language: en-us MIME-Version: 1.0 To: james rich CC: Robin Humble , linux-xfs@oss.sgi.com Subject: Re: Daily XFS CVS RPMS References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi. >>If your distro has XF 4.1.* (any yet?) then a newer kernel isn't a problem. >> > > Slackware 8.0 has XFree86 4.1.0 And Mandrake 8.1 and RedHat 7.2. // Stefan PS. I just BET there'll be an XFS installer soon from SGI for RH7.2, :) From owner-linux-xfs@oss.sgi.com Mon Oct 22 17:20:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9N0Kt519495 for linux-xfs-outgoing; Mon, 22 Oct 2001 17:20:55 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9N0KpD19470 for ; Mon, 22 Oct 2001 17:20:51 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id RAA19758 for ; Mon, 22 Oct 2001 17:20:45 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) 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 KAA20838; Tue, 23 Oct 2001 10:19:31 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA54045; Tue, 23 Oct 2001 11:19:30 +1100 (AEDT) Date: Tue, 23 Oct 2001 11:19:30 +1100 From: Nathan Scott To: Robin Humble , Keith Owens Cc: linux-xfs@oss.sgi.com Subject: Re: OpenGL + Alpha XFS question (was Re: Daily XFS CVS RPMS) Message-ID: <20011023111930.B450614@wobbly.melbourne.sgi.com> References: <200110210309.DAA04579@groucho.maths.monash.edu.au> <5481.1003635618@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5481.1003635618@ocs3.intra.ocs.com.au>; from kaos@melbourne.sgi.com on Sun, Oct 21, 2001 at 01:40:18PM +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Sun, Oct 21, 2001 at 01:40:18PM +1000, Keith Owens wrote: > On Sun, 21 Oct 2001 13:09:52 +1000 (EST), > Robin Humble wrote: > >Just to drag this topic back to XFS - a friend is installing on Alphas > >and gets a kernel panic when xfs_check or xfs_repair is run... is this a > >known problem? He's using the XFS for Alpha RH7.1 installer I presume > >that's the Release 1.0.1 Alpha-XFS-Installer-PR1.iso ... Would a cvs kernel > >and xfsprogs help any? Possibly. When running xfs_check/xfs_repair there is no XFS interaction involved - these access the block device directly. So, XFS kernel changes since 1.0.1 are unlikely to help, but the numerous underlying kernel changes might. > > Sounds like the unaligned access problems in xfs_repair that Nathan > Scott fixed last week. Grab the cmd directory from the CVS tree and > build your own xfsprogs. > Hmm... that wouldn't cause a panic though, at worst you might see SIGBUS in the user tools. Do you have ksymoops output? (assuming there's no kdb for Alpha) cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Oct 22 18:04:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9N14S420530 for linux-xfs-outgoing; Mon, 22 Oct 2001 18:04:28 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9N142D20508 for ; Mon, 22 Oct 2001 18:04:02 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id SAA04334 for ; Mon, 22 Oct 2001 18:03:16 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) 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 LAA21052; Tue, 23 Oct 2001 11:02:22 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA78718; Tue, 23 Oct 2001 12:02:00 +1100 (AEDT) Date: Tue, 23 Oct 2001 12:02:00 +1100 From: Nathan Scott To: Buchan Milne Cc: linux-xfs@oss.sgi.com, Sylvestre Taburet Subject: Re: Samba 2.2.2 and XFS quotas Message-ID: <20011023120200.C450614@wobbly.melbourne.sgi.com> References: <3BD3EDF8.6090607@cae.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BD3EDF8.6090607@cae.co.za>; from bgmilne@cae.co.za on Mon, Oct 22, 2001 at 11:59:20AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Mon, Oct 22, 2001 at 11:59:20AM +0200, Buchan Milne wrote: > Sylvestre Taburet and I are working on updates to samba-2.2.2 for > Mandrake 8.1. Since Mandrake 8.1 shipped with XFS, we would like to keep > working samba/XFS/quotas. Excellent. This really needs someone with a vested interest to follow it up and push the changes to the Samba folk. > In the package of samba-2.2.1a, we applied > the patch by Nathan Scott: > (http://marc.theaimsgroup.com/?l=linux-xfs&m=100002981924172&w=2). Caveat - I have had one report that this patch does not work. As I said originally, it is a patch which shows the sort of changes that are needed, but it is untested as I know very little about Samba & how to go about testing this. > We have forwarded the patch to samba developers, but they would prefer a > patch against current CVS tag SAMBA_2_2. It will need to be tested and fixed first, by the sound of it. > Is there someone on this list who can take a look at this? If a working > patch is available, I will ensure that it makes it into samba cvs. > (unofortunately, that's all I can offer, since I am no hacker ...) I will see if I can find some time to figure out how to set up Samba and test this ... I can't promise anything though as I'm busy on other stuff right now, and Windows machines are quite scarce around here. > Here is a link to the quota.c in samba's cvsweb: > http://pserver.samba.org/cgi-bin/cvsweb/samba/source/smbd/quotas.c?only_with_tag=SAMBA_2_2 > Thanks for pushing this - if some other developer out there can take a shot at fixing the original patch, I could certainly look over their new patch and cross-check the XFS quota side of things for them. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Oct 22 18:38:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9N1cDs21323 for linux-xfs-outgoing; Mon, 22 Oct 2001 18:38:13 -0700 Received: from rebel.net.au (news.rebel.net.au [203.20.69.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9N1ZjD21250; Mon, 22 Oct 2001 18:37:17 -0700 Received: from rebel.net.au (dialup-1.rebel.net.au [203.20.69.71]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id LAA20882; Tue, 23 Oct 2001 11:04:11 +0930 Message-ID: <3BD4CABA.A5B539D4@rebel.net.au> Date: Tue, 23 Oct 2001 11:11:14 +0930 From: David Lloyd X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1_PR3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Chris Tooley CC: owner-linux-xfs@oss.sgi.com, linux-xfs Subject: Re: RedHat 7.2 has 2.4.9 Kernel as update References: <3BD40587.BAF4A871@ch.sauter-bc.com> <3BD4137C.E64F9101@ch.sauter-bc.com> <3BD422C7.9141C7EB@sgi.com> <1003738078.11792.37.camel@itspec.amoa.org> <3BD42636.A4FE5EC6@sgi.com> <1003759484.11792.40.camel@itspec.amoa.org> <3BD427C3.2080507@cae.co.za> <1003759910.11737.45.camel@itspec.amoa.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hmm... > I think we can steer clear of the religious distro wars. I'll check it > out, but it's not likely. I can just imagine the "RC Linux: It's Never Wrong!" where RC stands for Roman Catholic... ;-P -- If we could extract all the evil from each of us, Think of the world that we could create! A world without anger, or violence or strife... (From the Musical, Jekyll and Hyde) From owner-linux-xfs@oss.sgi.com Mon Oct 22 19:21:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9N2Lim22279 for linux-xfs-outgoing; Mon, 22 Oct 2001 19:21:44 -0700 Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9N2LeD22253 for ; Mon, 22 Oct 2001 19:21:40 -0700 Received: from [209.86.133.66] (user-38ld1a2.dialup.mindspring.com [209.86.133.66]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id WAA19210; Mon, 22 Oct 2001 22:21:36 -0400 (EDT) From: John Trostel Message-ID: <2.1-439792-249-D-OEWW@mail.mindspring.com> To: nathans@sgi.com Cc: linux-xfs@oss.sgi.com Date: Mon, 22 Oct 2001 22:21:44 -0500 Subject: Re: Samba 2.2.2 and XFS quotas X-Mailer: Eudora 2.1 for PalmOS Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I took a quick look at the patch today. There seem to be some reasonably large changes between quota.c in 2.2.1a & 2.2.2. I'll probably be able to work a bit at it but will likely be asking about for helpful hints. Nathan Scott wrote: >> Sylvestre Taburet and I are working on updates to samba-2.2.2 for >> Mandrake 8.1. Since Mandrake 8.1 shipped with XFS, we would like to keep >> working samba/XFS/quotas. > > Excellent. This really needs someone with a vested interest > to follow it up and push the changes to the Samba folk. > >> In the package of samba-2.2.1a, we applied >> the patch by Nathan Scott: >> (http://marc.theaimsgroup.com/?l=linux-xfs&m=100002981924172&w=2). > > Caveat - I have had one report that this patch does not work. > As I said originally, it is a patch which shows the sort of > changes that are needed, but it is untested as I know very > little about Samba & how to go about testing this. > >> We have forwarded the patch to samba developers, but they would prefer a >> patch against current CVS tag SAMBA_2_2. > > It will need to be tested and fixed first, by the sound of it. > ... Snip... > Thanks for pushing this - if some other developer out there can > take a shot at fixing the original patch, I could certainly look > over their new patch and cross-check the XFS quota side of things > for them. John M. Trostel jtrostel@mindspring.com Mail from my Visor - cool ! From owner-linux-xfs@oss.sgi.com Mon Oct 22 19:42:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9N2gVe22837 for linux-xfs-outgoing; Mon, 22 Oct 2001 19:42:31 -0700 Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9N2gQD22814 for ; Mon, 22 Oct 2001 19:42:27 -0700 Received: from there (nic-c41-069.mw.mediaone.net [24.131.41.69]) by demai05.mw.mediaone.net (8.11.1/8.11.1) with SMTP id f9N2gYw26149 for ; Mon, 22 Oct 2001 22:42:34 -0400 (EDT) Message-Id: <200110230242.f9N2gYw26149@demai05.mw.mediaone.net> Content-Type: text/plain; charset="iso-8859-1" From: Peter Hiltz To: linux-xfs@oss.sgi.com Subject: Can't compile xfsdump Date: Mon, 22 Oct 2001 22:49:56 -0400 X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi all, Newbie here. Working my way through compiling the cvs tree and everything seems to compile except xfsdump. I'm picking up the following errors: gcc -O1 -g -DDEBUG -funsigned-char -Wall -DDUMP -DRMT -DBASED -DDOSOCKS -DINVCONVFIX -DSIZEEST -DPIP EINVFIX -DEXTATTR -DDMEXTATTR -I/usr/include/xfs -I/usr/include/attr '-DVERSION="1.1.7"' -D_FILE_OFF SET_BITS=64 -D_GNU_SOURCE -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 -I/usr/include/xfs -I/usr/includ e/attr -c -o attr.o attr.c attr.c: In function `attr_multi_by_handle': attr.c:57: `attr_op_t' undeclared (first use in this function) attr.c:57: (Each undeclared identifier is reported only once attr.c:57: for each function it appears in.) attr.c:57: `ops' undeclared (first use in this function) attr.c:57: warning: statement with no effect attr.c:58: parse error before `int' attr.c:75: `i' undeclared (first use in this function) attr.c:83: `fsfd' undeclared (first use in this function) attr.c:88: `hreq' undeclared (first use in this function) attr.c:96: `attr_hreq' undeclared (first use in this function) attr.c: In function `attr_list_by_handle': attr.c:123: `attr_op_t' undeclared (first use in this function) attr.c:123: parse error before `op' attr.c:128: `op' undeclared (first use in this function) attr.c:129: `ATTR_OP_IRIX_LIST' undeclared (first use in this function) make[2]: *** [attr.o] Error 1 make[1]: *** [default] Error 2 System is running updated SuSE 7.2, kernel 2.4-9-4GB. Any suggestions as to what I am missing? TIA Peter From owner-linux-xfs@oss.sgi.com Mon Oct 22 19:54:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9N2sIU23144 for linux-xfs-outgoing; Mon, 22 Oct 2001 19:54:18 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9N2sCD23119 for ; Mon, 22 Oct 2001 19:54:12 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id TAA29812 for ; Mon, 22 Oct 2001 19:54:06 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) 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 MAA21793; Tue, 23 Oct 2001 12:52:52 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA39436; Tue, 23 Oct 2001 13:52:51 +1100 (AEDT) Date: Tue, 23 Oct 2001 13:52:51 +1100 From: Nathan Scott To: Peter Hiltz Cc: linux-xfs@oss.sgi.com Subject: Re: Can't compile xfsdump Message-ID: <20011023135251.F450614@wobbly.melbourne.sgi.com> References: <200110230242.f9N2gYw26149@demai05.mw.mediaone.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200110230242.f9N2gYw26149@demai05.mw.mediaone.net>; from philtz@mediaone.net on Mon, Oct 22, 2001 at 10:49:56PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Mon, Oct 22, 2001 at 10:49:56PM -0400, Peter Hiltz wrote: > Hi all, > Newbie here. Working my way through compiling the cvs tree and everything > seems to compile except xfsdump. I'm picking up the following errors: > You have installed cmd/attr2 instead of cmd/attr - read the file cmd/attr2/BIG.FAT.WARNING, then use cmd/attr instead. cheers. > gcc -O1 -g -DDEBUG -funsigned-char -Wall -DDUMP -DRMT -DBASED -DDOSOCKS > -DINVCONVFIX -DSIZEEST -DPIP > EINVFIX -DEXTATTR -DDMEXTATTR -I/usr/include/xfs -I/usr/include/attr > '-DVERSION="1.1.7"' -D_FILE_OFF > SET_BITS=64 -D_GNU_SOURCE -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 > -I/usr/include/xfs -I/usr/includ > e/attr -c -o attr.o attr.c > attr.c: In function `attr_multi_by_handle': > attr.c:57: `attr_op_t' undeclared (first use in this function) > attr.c:57: (Each undeclared identifier is reported only once > attr.c:57: for each function it appears in.) > attr.c:57: `ops' undeclared (first use in this function) > attr.c:57: warning: statement with no effect > attr.c:58: parse error before `int' > attr.c:75: `i' undeclared (first use in this function) > attr.c:83: `fsfd' undeclared (first use in this function) > attr.c:88: `hreq' undeclared (first use in this function) > attr.c:96: `attr_hreq' undeclared (first use in this function) > attr.c: In function `attr_list_by_handle': > attr.c:123: `attr_op_t' undeclared (first use in this function) > attr.c:123: parse error before `op' > attr.c:128: `op' undeclared (first use in this function) > attr.c:129: `ATTR_OP_IRIX_LIST' undeclared (first use in this function) > make[2]: *** [attr.o] Error 1 > make[1]: *** [default] Error 2 > > System is running updated SuSE 7.2, kernel 2.4-9-4GB. Any suggestions as to > what I am missing? > > TIA > > Peter > -- Nathan From owner-linux-xfs@oss.sgi.com Mon Oct 22 19:57:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9N2vw423296 for linux-xfs-outgoing; Mon, 22 Oct 2001 19:57:58 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9N2vtD23274 for ; Mon, 22 Oct 2001 19:57:55 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9N2voK09962 for ; Mon, 22 Oct 2001 19:57:50 -0700 Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id TAA42517; Mon, 22 Oct 2001 19:57:18 -0700 (PDT) Message-ID: <3BD4DBBF.C3615540@sgi.com> Date: Mon, 22 Oct 2001 21:53:51 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com CC: jgoodwin@chriskaine.com.au Subject: Re: Relesing the installer for RH7.2 References: <200110230126.f9N1QqS20977@oss.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Julian - Please don't send HTML to the list, it bounces on the filters, and then I have to jump through hoops to reply... > Are you going to be releasing a new version of the XFS installer for RedHat > 7.2, Yes. > and if so when? When it's ready; hopefully "soon" - depending on your version of soon. :) > Also is there a way that I could obtain the installer CD without having to > download it? I am on a modem connection mainly, and all of the broadband > connections I use charge per MB. Cheapbytes will sell you the RH7.1 cd - hopefully they'll do the same for the 7.2 installer when it's ready. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Oct 22 20:28:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9N3Scs23940 for linux-xfs-outgoing; Mon, 22 Oct 2001 20:28:38 -0700 Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9N3SYD23918 for ; Mon, 22 Oct 2001 20:28:34 -0700 Received: from there (nic-c41-069.mw.mediaone.net [24.131.41.69]) by demai05.mw.mediaone.net (8.11.1/8.11.1) with SMTP id f9N3Sew16667; Mon, 22 Oct 2001 23:28:40 -0400 (EDT) Message-Id: <200110230328.f9N3Sew16667@demai05.mw.mediaone.net> Content-Type: text/plain; charset="iso-8859-1" From: Peter Hiltz To: Nathan Scott Subject: Re: Can't compile xfsdump Date: Mon, 22 Oct 2001 23:36:02 -0400 X-Mailer: KMail [version 1.3.1] Cc: linux-xfs@oss.sgi.com References: <200110230242.f9N2gYw26149@demai05.mw.mediaone.net> <20011023135251.F450614@wobbly.melbourne.sgi.com> In-Reply-To: <20011023135251.F450614@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks, Boy, do I feel stupid. Peter On Monday 22 October 2001 22:52, Nathan Scott wrote: > hi, > > On Mon, Oct 22, 2001 at 10:49:56PM -0400, Peter Hiltz wrote: > > Hi all, > > Newbie here. Working my way through compiling the cvs tree and everything > > seems to compile except xfsdump. I'm picking up the following errors: > > You have installed cmd/attr2 instead of cmd/attr - read the > file cmd/attr2/BIG.FAT.WARNING, then use cmd/attr instead. > > cheers. > From owner-linux-xfs@oss.sgi.com Mon Oct 22 21:17:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9N4H0I24767 for linux-xfs-outgoing; Mon, 22 Oct 2001 21:17:00 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9N4GsD24744 for ; Mon, 22 Oct 2001 21:16:54 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id SAA09919 for ; Mon, 22 Oct 2001 18:52:30 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) 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 LAA21517; Tue, 23 Oct 2001 11:51:07 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA30781; Tue, 23 Oct 2001 12:51:06 +1100 (AEDT) Date: Tue, 23 Oct 2001 12:51:05 +1100 From: Nathan Scott To: Malcolm Cowe Cc: linux-xfs@oss.sgi.com Subject: Re: Support Infrastructure Message-ID: <20011023125105.D450614@wobbly.melbourne.sgi.com> References: <3BD43D7E.C04536EE@agilent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BD43D7E.C04536EE@agilent.com>; from malcolm_cowe@agilent.com on Mon, Oct 22, 2001 at 04:38:38PM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Mon, Oct 22, 2001 at 04:38:38PM +0100, Malcolm Cowe wrote: > Hi, > > We are looking at deploying an increasing number of linux based file > servers within our enterprise, based on HP's NetServer platform. One of > the aspects we are investigating relates to journalled file systems, and > we are looking at project activity and so on to try and ascertain > longevity and stability. > > I have a good deal of previous experience with SGI hardware and the IRIX > OS platform, and so I have a natural tendency towards recommending XFS > for Linux, since I have good experiences with this file system, and a > great deal of respect for the engineering talent at SGI. How actively is > the project being maintained? One good indicator you could use here is activity on the projects mailing list - have a read through the mail archives, this should give you a good idea on the level of activity on each project. http://oss.sgi.com/projects/xfs/ml.html > Is is straightforward to forward revise > the kernel and apply the XFS patches to it? Fairly straightforward, yes. > Will there be long term support for XFS on linux? Yes, obviously XFS is a key part of SGIs Linux server product plans (as it has been on IRIX for years) and so SGI has a vested interest in making XFS on Linux a success. > Is it going to work with RH 7.2? See the list archive for discussion on the state of this work item. > If any of these questions appear to be rude or pointed, then I > apologise. It is not my intention to cause any offence. I really want to > ... No offence taken, these are all valid questions. Hope this helps. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Oct 23 01:18:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9N8IoT28997 for linux-xfs-outgoing; Tue, 23 Oct 2001 01:18:50 -0700 Received: from mx0.break.net (root@mx0.break.net [194.134.79.76]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9N8IkD28975 for ; Tue, 23 Oct 2001 01:18:46 -0700 Received: from lowlands.euronet.nl (lowlands.euronet.nl [194.134.32.225]) by mx0.break.net (8.11.4/8.11.4) with ESMTP id f9N8MFu13867 for ; Tue, 23 Oct 2001 10:22:15 +0200 X-NCC-RegID: nl.euronet Message-Id: <5.1.0.14.2.20011022113021.02721150@pop.euronet.nl> X-Sender: sengaia@pop.euronet.nl X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 23 Oct 2001 10:18:42 +0200 To: linux-xfs@oss.sgi.com From: Arjen Wolfs Subject: write errors on secondary scsi LUNs Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I have two hardware raid partitions, on an identical SCSI ID; one with LUN 0, one with LUN 1. The partition on LUN 1, which consists of brand new hard disks, is generating random write errors of the kind: SCSI disk error : host 2 channel 0 id 0 lun 1 return code = 8 I/O error: dev 08:21, sector 310378498 XFS: device 0x821- XFS write error in file system meta-data block 0x12800002 in sd(8,33) SCSI disk error : host 2 channel 0 id 0 lun 1 return code = 8 I/O error: dev 08:21, sector 310397560 Oddly enough, xfs_check and xfs_repair can't find anything wrong with it after this happens. Considering kernels before 2.4.10 would not even recognize SCSI devices on LUNs other than 0, I am not entirely sure wether this is an XFS or a SCSI issue. Anybody have any ideas? TIA, Arjen Wolfs From owner-linux-xfs@oss.sgi.com Tue Oct 23 01:41:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9N8fkf29743 for linux-xfs-outgoing; Tue, 23 Oct 2001 01:41:46 -0700 Received: from mta01-srv.alltel.net (mta01.alltel.net [166.102.165.143]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9N8fgD29721 for ; Tue, 23 Oct 2001 01:41:43 -0700 Received: from there ([166.102.93.44]) by mta01-srv.alltel.net with SMTP id <20011023084141.HDLX17333.mta01-srv.alltel.net@there> for ; Tue, 23 Oct 2001 03:41:41 -0500 Content-Type: text/plain; charset="iso-8859-1" From: Roger Organization: na To: linux-xfs@oss.sgi.com Subject: Benchmarks Date: Tue, 23 Oct 2001 04:41:14 -0400 X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011023084141.HDLX17333.mta01-srv.alltel.net@there> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 i'm using 2x750 P3 (smp) with 2 hdd's of 20GB & a 40GB. i've done a thorough search for some benchmarks of the ext2/rieser/xfs filesystems but they all seem to conflict with each other. some state that xfs is blattently slow. other's boost that both journalling system's are faster then ext2, and some even go as far to state that XFS (at times) is faster then Rieser. Where can i find reliable info/benchmarks??? - -- - ----- My pulic GnuPG key (in armor format) can be found at: http://www.alltel.net/~rogerx/index.html My ICQ UIN# = 21252173 Created with Linux Mandrake 8.0! http://www.linux-mandrake.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjvVLTAACgkQZA/JYxAFHWENQgCeIVjFhznltO4LmuVFXJwXcNAt gaIAnRXRaEZcSbwhBCRPo/3qG1mtyktl =Ud5t -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Tue Oct 23 02:20:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9N9Kq831181 for linux-xfs-outgoing; Tue, 23 Oct 2001 02:20:52 -0700 Received: from home.smithconcepts.com (65.34.25.157.oviedo-ubr-a.cfl.rr.com [65.34.25.157]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9N9KmD31159 for ; Tue, 23 Oct 2001 02:20:48 -0700 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id FAA02479; Tue, 23 Oct 2001 05:14:09 -0400 Message-ID: <3BD536F3.A88C8E0A@ieee.org> Date: Tue, 23 Oct 2001 05:22:59 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts, Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS101_K7mp i686) X-Accept-Language: en MIME-Version: 1.0 To: Roger CC: linux-xfs@oss.sgi.com Subject: Re: Benchmarks References: <20011023084141.HDLX17333.mta01-srv.alltel.net@there> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Roger wrote: > i'm using 2x750 P3 (smp) with 2 hdd's of 20GB & a 40GB. > i've done a thorough search for some benchmarks of the ext2/rieser/xfs > filesystems but they all seem to conflict with each other. > some state that xfs is blattently slow. other's boost that both journalling > system's are faster then ext2, and some even go as far to state that XFS (at > times) is faster then Rieser. You should focus less on performance, because there is a _lot_ of overlap, and more on figuring out what you need. E.g., ReiserFS is fine and dandy for Windows servers, but you'll have problems with non-Linux NFS clients. XFS doesn't, and brings a lot of added functionality to the Windows server arena at the same time. > Where can i find reliable info/benchmarks??? Depends on the application benchmark! ;-PPP E.g., bonnie is typically used for NFS testing. There are various SMB benchmarks like Ziff-Davis' testing suite, etc... -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ------------------------------------------------------------------ Those living in the US who consider the American flag to be a sym- bol of oppression obviously fail to understand what the word means From owner-linux-xfs@oss.sgi.com Tue Oct 23 02:50:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9N9oSb31818 for linux-xfs-outgoing; Tue, 23 Oct 2001 02:50:28 -0700 Received: from quasar.sif.it (IDENT:root@quasar.sif.it [131.154.110.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9N9oMD31796 for ; Tue, 23 Oct 2001 02:50:22 -0700 Received: from localhost (matteo@localhost) by quasar.sif.it (8.11.6/8.11.6) with ESMTP id f9N9oWS24326; Tue, 23 Oct 2001 11:50:32 +0200 Date: Tue, 23 Oct 2001 11:50:32 +0200 (CEST) From: Matteo Centonza To: Arjen Wolfs cc: Subject: Re: write errors on secondary scsi LUNs In-Reply-To: <5.1.0.14.2.20011022113021.02721150@pop.euronet.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Arjen, > I have two hardware raid partitions, on an identical SCSI ID; one with LUN > 0, one with LUN 1. The partition on LUN 1, which consists of brand new hard > disks, is generating random write errors of the kind: > > SCSI disk error : host 2 channel 0 id 0 lun 1 return code = 8 > I/O error: dev 08:21, sector 310378498 > XFS: device 0x821- XFS write error in file system meta-data block > 0x12800002 in sd(8,33) > > SCSI disk error : host 2 channel 0 id 0 lun 1 return code = 8 > I/O error: dev 08:21, sector 310397560 > > Oddly enough, xfs_check and xfs_repair can't find anything wrong with it > after this happens. Considering kernels before 2.4.10 would not even > recognize SCSI devices on LUNs other than 0, I am not entirely sure wether > this is an XFS or a SCSI issue. Anybody have any ideas? I'm not an HW-RAID expert but i've seen this message before: http://marc.theaimsgroup.com/?l=linux-xfs&m=100319330327289&w=2 indicating a raid layer level corruption. XFS notify this way that something is going wrong with you array. Do sanity check of your hardware (disks, controller, scsi terminations). It's likely that's a hardware based problem. Which controller are you using? -m From owner-linux-xfs@oss.sgi.com Tue Oct 23 03:00:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9NA0DP32147 for linux-xfs-outgoing; Tue, 23 Oct 2001 03:00:13 -0700 Received: from mx0.break.net (root@mx0.break.net [194.134.79.76]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9NA08D32122 for ; Tue, 23 Oct 2001 03:00:08 -0700 Received: from lowlands.euronet.nl (lowlands.euronet.nl [194.134.32.225]) by mx0.break.net (8.11.4/8.11.4) with ESMTP id f9NA3Uu14228; Tue, 23 Oct 2001 12:03:30 +0200 X-NCC-RegID: nl.euronet Message-Id: <5.1.0.14.2.20011023115733.02677420@pop.euronet.nl> X-Sender: sengaia@pop.euronet.nl X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 23 Oct 2001 11:59:58 +0200 To: Matteo Centonza From: Arjen Wolfs Subject: Re: write errors on secondary scsi LUNs Cc: In-Reply-To: References: <5.1.0.14.2.20011022113021.02721150@pop.euronet.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 11:50 23-10-2001, Matteo Centonza wrote: >Hi Arjen, > > > I have two hardware raid partitions, on an identical SCSI ID; one with LUN > > 0, one with LUN 1. The partition on LUN 1, which consists of brand new hard > > disks, is generating random write errors of the kind: > > > > SCSI disk error : host 2 channel 0 id 0 lun 1 return code = 8 > > I/O error: dev 08:21, sector 310378498 > > XFS: device 0x821- XFS write error in file system meta-data block > > 0x12800002 in sd(8,33) > > > > SCSI disk error : host 2 channel 0 id 0 lun 1 return code = 8 > > I/O error: dev 08:21, sector 310397560 > > > > Oddly enough, xfs_check and xfs_repair can't find anything wrong with it > > after this happens. Considering kernels before 2.4.10 would not even > > recognize SCSI devices on LUNs other than 0, I am not entirely sure wether > > this is an XFS or a SCSI issue. Anybody have any ideas? > >I'm not an HW-RAID expert but i've seen this message before: > >http://marc.theaimsgroup.com/?l=linux-xfs&m=100319330327289&w=2 > >indicating a raid layer level corruption. XFS notify this way that >something is going wrong with you array. Do sanity check of your >hardware (disks, controller, scsi terminations). It's likely that's > >a hardware based problem. It's definately not a cabling issue; the partition on LUN 0 goes over the exact same cable/controllers and has no errors whatsoever. The HW RAID is external (i.e. in the disk cabinet), and shows no errors. >Which controller are you using? a Seek RAID unit connected to an Adaptec 2940U2W controller. /A From owner-linux-xfs@oss.sgi.com Tue Oct 23 03:10:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9NAA0U32426 for linux-xfs-outgoing; Tue, 23 Oct 2001 03:10:00 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9NA9tD32401 for ; Tue, 23 Oct 2001 03:09:55 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id MAA454024 for ; Tue, 23 Oct 2001 12:09:54 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id FAA3381189; Tue, 23 Oct 2001 05:08:35 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id FAA60549; Tue, 23 Oct 2001 05:08:35 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9NA56i11536; Tue, 23 Oct 2001 05:05:06 -0500 Message-Id: <200110231005.f9NA56i11536@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Arjen Wolfs cc: linux-xfs@oss.sgi.com Subject: Re: write errors on secondary scsi LUNs In-Reply-To: Message from Arjen Wolfs of "Tue, 23 Oct 2001 10:18:42 +0200." <5.1.0.14.2.20011022113021.02721150@pop.euronet.nl> Date: Tue, 23 Oct 2001 05:05:05 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Arjen, I suspect you are being hit by the scsi layer here - you are seeing two error reports, the first one is the scsi layer reporting an error, the second is xfs reporting it got an I/O error from the scsi layer. Apart from hex vs decimal, they are both complaining about the same disk block. Have you tried some raw I/O tests to the same device without a filesystem on it? Steve > > Hi, > > I have two hardware raid partitions, on an identical SCSI ID; one with LUN > 0, one with LUN 1. The partition on LUN 1, which consists of brand new hard > disks, is generating random write errors of the kind: > > SCSI disk error : host 2 channel 0 id 0 lun 1 return code = 8 > I/O error: dev 08:21, sector 310378498 > XFS: device 0x821- XFS write error in file system meta-data block > 0x12800002 in sd(8,33) > > SCSI disk error : host 2 channel 0 id 0 lun 1 return code = 8 > I/O error: dev 08:21, sector 310397560 > > Oddly enough, xfs_check and xfs_repair can't find anything wrong with it > after this happens. Considering kernels before 2.4.10 would not even > recognize SCSI devices on LUNs other than 0, I am not entirely sure wether > this is an XFS or a SCSI issue. Anybody have any ideas? > > TIA, > Arjen Wolfs From owner-linux-xfs@oss.sgi.com Tue Oct 23 03:20:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9NAKvI32724 for linux-xfs-outgoing; Tue, 23 Oct 2001 03:20:57 -0700 Received: from mx0.break.net (root@mx0.break.net [194.134.79.76]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9NAKrD32702 for ; Tue, 23 Oct 2001 03:20:53 -0700 Received: from lowlands.euronet.nl (lowlands.euronet.nl [194.134.32.225]) by mx0.break.net (8.11.4/8.11.4) with ESMTP id f9NAOLu14293; Tue, 23 Oct 2001 12:24:21 +0200 X-NCC-RegID: nl.euronet Message-Id: <5.1.0.14.2.20011023121801.02734928@pop.euronet.nl> X-Sender: sengaia@pop.euronet.nl X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 23 Oct 2001 12:20:48 +0200 To: Steve Lord From: Arjen Wolfs Subject: Re: write errors on secondary scsi LUNs Cc: linux-xfs@oss.sgi.com In-Reply-To: <200110231005.f9NA56i11536@jen.americas.sgi.com> References: <5.1.0.14.2.20011022113021.02721150@pop.euronet.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 12:05 23-10-2001, Steve Lord wrote: >Hi Arjen, > >I suspect you are being hit by the scsi layer here - you are seeing two >error reports, the first one is the scsi layer reporting an error, the >second is xfs reporting it got an I/O error from the scsi layer. >Apart from hex vs decimal, they are both complaining about the same >disk block. > >Have you tried some raw I/O tests to the same device without a filesystem >on it? I'll try and do some testing (specific suggestions are welcome); I am pretty sure this is a SCSI layer issue, especially since any kernel before 2.4.10 will not even see the partition on LUN 1; I was hoping maybe somebody had encountered the same problem. What In do find strange however, is that xfs_check/xfs_repair see no errors on the filesystem, considering the error message about errors writing metadata. /Arjen From owner-linux-xfs@oss.sgi.com Tue Oct 23 03:39:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9NAd8a00636 for linux-xfs-outgoing; Tue, 23 Oct 2001 03:39:08 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9NAd4D00608 for ; Tue, 23 Oct 2001 03:39:04 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9NAcxW14220 for ; Tue, 23 Oct 2001 03:38:59 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id FAA3379241; Tue, 23 Oct 2001 05:37:43 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id FAA78623; Tue, 23 Oct 2001 05:37:42 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9NAYDJ11731; Tue, 23 Oct 2001 05:34:13 -0500 Message-Id: <200110231034.f9NAYDJ11731@jen.americas.sgi.com> To: Arjen Wolfs cc: linux-xfs@oss.sgi.com Subject: Re: write errors on secondary scsi LUNs References: <5.1.0.14.2.20011022113021.02721150@pop.euronet.nl> <5.1.0.14.2.20011023121801.02734928@pop.euronet.nl> Comments: In-reply-to Arjen Wolfs message dated "Tue, 23 Oct 2001 12:20:48 +0200." Date: Tue, 23 Oct 2001 05:34:13 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > At 12:05 23-10-2001, Steve Lord wrote: > > >Hi Arjen, > > > >I suspect you are being hit by the scsi layer here - you are seeing two > >error reports, the first one is the scsi layer reporting an error, the > >second is xfs reporting it got an I/O error from the scsi layer. > >Apart from hex vs decimal, they are both complaining about the same > >disk block. > > > >Have you tried some raw I/O tests to the same device without a filesystem > >on it? > > I'll try and do some testing (specific suggestions are welcome); I am > pretty sure this is a SCSI layer issue, especially since any kernel before > 2.4.10 will not even see the partition on LUN 1; I was hoping maybe > somebody had encountered the same problem. > > What In do find strange however, is that xfs_check/xfs_repair see no errors > on the filesystem, considering the error message about errors writing metadat > a. Well, they are read only unless they find and error and the error you got was a write. And just because the write returned and error it does not mean it did not work..... As for a test, try doing a dd down to the same disk addresses from user space for starters. Steve > > /Arjen From owner-linux-xfs@oss.sgi.com Tue Oct 23 04:19:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9NBJPR01794 for linux-xfs-outgoing; Tue, 23 Oct 2001 04:19:25 -0700 Received: from mail.fisek.com.tr (fisek2.ada.net.tr [195.112.153.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9NBJLD01772 for ; Tue, 23 Oct 2001 04:19:21 -0700 Received: (qmail 29913 invoked from network); 23 Oct 2001 11:16:16 -0000 Received: from isdn04233.ada.net.tr (HELO fisek.com.tr) (195.112.156.233) by passiflora.fisek.com.tr with SMTP; 23 Oct 2001 11:16:16 -0000 Date: Tue, 23 Oct 2001 13:14:02 +0300 From: Doruk Fisek To: linux-xfs@oss.sgi.com Subject: Re: ext3 + xfs + jfs + reiser Message-Id: <20011023131402.19e13a0c.dfisek@fisek.com.tr> Organization: Fisek Enstitusu X-Mailer: Sylpheed version 0.6.4 (GTK+ 1.2.10; i686-pc-linux-gnu) X-GPG-Key: http://linux.fisek.com.tr/dfisek/dfisek.gpg Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 22 Oct 2001 15:01:37 -0400 Bryan-TheBS-Smith wrote: > BTW, why did you go to stock kernel 2.4.5 + XFS rather than RedHat > 2.4.3 + XFS? I've been humming with the heavily RedHat patched > 2.4.3 release + XFS with 0 issues on a number of systems. everybody's talking about older kernels. aren't new kernels and xfs patches stable? the development team seem pretty quick on releasing new patches as soon as the new kernel is available. Doruk -- FISEK INSTITUTE - http://www.fisek.org From owner-linux-xfs@oss.sgi.com Tue Oct 23 06:30:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9NDUto04341 for linux-xfs-outgoing; Tue, 23 Oct 2001 06:30:55 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9NDUpD04319 for ; Tue, 23 Oct 2001 06:30:51 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9NDUkW19066 for ; Tue, 23 Oct 2001 06:30:46 -0700 Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id GAA05741 for ; Tue, 23 Oct 2001 06:30:10 -0700 (PDT) Message-ID: <3BD57010.7C8EF680@sgi.com> Date: Tue, 23 Oct 2001 08:26:40 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: For Testing - updated RH7.1 XFS 2.4.9-6 kernels Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Due to popular demand, I have made available a test release of XFS-capable versions of the Red Hat Linux 7.1 updates kernel v2.4.9-6. Available soon at: ftp://oss.sgi.com/projects/xfs/download/testing/RH2.4.9-6 There are a couple known issues with undefined symbols in the intermezzo.o and bcm5820.o modules; I'll get those sorted out on the next release, but since this kernel is a security update, I wanted to get it out there for testing. They have not yet been rigorously tested by SGI - but they do compile, boot, and pass the xfs QA suite. :) Enjoy, -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Oct 23 07:29:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9NETbf05591 for linux-xfs-outgoing; Tue, 23 Oct 2001 07:29:37 -0700 Received: from pete.uri.edu (PETE.URI.EDU [131.128.1.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9NETVD05566 for ; Tue, 23 Oct 2001 07:29:31 -0700 Received: from terms.uri.edu (TERMS.URI.EDU [131.128.1.132]) by pete.uri.edu (8.9.1/8.9.1) with ESMTP id KAA02960 for ; Tue, 23 Oct 2001 10:29:29 -0400 (EDT) Received: from postoffice.uri.edu ([131.128.144.86]) by terms.uri.edu (8.11.4/8.11.4) with ESMTP id f9NEStQ18455 for ; Tue, 23 Oct 2001 10:28:55 -0400 Message-ID: <3BD57E32.90908@postoffice.uri.edu> Date: Tue, 23 Oct 2001 10:26:58 -0400 From: Nicholas DePetrillo User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS 1.01 installaton over Mandrake 8.1 XFS 1.0 installation??? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk First of all, Imust say XFS is the best performing file system I have used for Linux thus far. I have been using Jounalising Reiser FS, but that gave me some issues after crashes, XFS has been through alot in its short introduction to my system but it hasnt failed ever. I was wondering if it is worth it to upgrade to 1.01 from 1.0. and if so how would one go about doing that, I am an experienced linux user, but not experienced in installing or upgrading a new file system over an allready implimented one. Thank you Nicholas DePetrillo ndep8515@postoffice.uri.edu From owner-linux-xfs@oss.sgi.com Tue Oct 23 07:55:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9NEt0d06182 for linux-xfs-outgoing; Tue, 23 Oct 2001 07:55:00 -0700 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9NEsqD06156 for ; Tue, 23 Oct 2001 07:54:52 -0700 Received: from inf.ethz.ch (IDENT:schmitt@ikarus.inf.ethz.ch [129.132.10.58]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id QAA15698; Tue, 23 Oct 2001 16:54:30 +0200 (MET DST) Message-ID: <3BD584A8.1060505@inf.ethz.ch> Date: Tue, 23 Oct 2001 16:54:32 +0200 From: Marc Schmitt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Eric Sandeen CC: linux-xfs@oss.sgi.com, florin@sgi.com Subject: Re: Corruption of in-memory data detected. References: <3BD4137A.8040406@inf.ethz.ch> <1003770847.13566.36.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Eric, Eric Sandeen wrote: > > If you don't mind tinkering a bit, the first thing to do is enable kdb > and set a breakpoint, so we can see how we're getting to this point.. Here the console output: Entering kdb (current=0xc039c000, pid 0) on processor 0 due to Keyboard Entry [0]kdb> bp _xfs_force_shutdown Instruction(i) BP #0 at 0xc01f7208 (_xfs_force_shutdown) is enabled globally adjust 1 [0]kdb> go XFS mounting filesystem md(9,0) Instruction(i) breakpoint #0 at 0xc01f7208 (adjusted) 0xc01f7208 _xfs_force_shutdown: int3 Entering kdb (current=0xd9f06000, pid 2459) on processor 0 due to Breakpoint @ 0xc01f7208 [0]kdb> bt EBP EIP Function(args) 0xd9f07c3c 0xc01f7208 _xfs_force_shutdown (0xdab55400, 0x8, 0xc02cadc3, 0x3fc) kernel .text 0xc0100000 0xc01f7208 0xc01f7338 0xc01ec31e xfs_trans_cancel+0x46 (0xd9263980, 0xc) kernel .text 0xc0100000 0xc01ec2d8 0xc01ec37c 0xd9f07cf0 0xc01f2d56 xfs_create+0x9ca (0xd9397d44, 0xd9282d7c, 0xd9f07e74, 0x0, 0x0) kernel .text 0xc0100000 0xc01f238c 0xc01f2dd0 0xd9f07ee4 0xc01fb02f linvfs_common_cr+0x123 (0xda00abc0, 0xd9282d20, 0x81ff, 0x1, 0x0) kernel .text 0xc0100000 0xc01faf0c 0xc01fb174 0xd9f07f00 0xc01fb18c linvfs_create+0x18 (0xda00abc0, 0xd9282d20, 0x81ff) kernel .text 0xc0100000 0xc01fb174 0xc01fb190 0xd9f07f28 0xc0140cef vfs_create+0x127 (0xda00abc0, 0xd9282d20, 0x1ff, 0x1ff) kernel .text 0xc0100000 0xc0140bc8 0xc0140d40 0xd9f07f60 0xc0140eac open_namei+0x16c (0xdec13000, 0xc3, 0x1ff, 0xd9f07f84) kernel .text 0xc0100000 0xc0140d40 0xc01413dc 0xd9f07fa0 0xc0135fb2 filp_open+0x3a (0xdec13000, 0xc2, 0x1ff) kernel .text 0xc0100000 0xc0135f78 0xc0135fd4 0xd9f07fbc 0xc0136302 sys_open+0x36 (0xbffff718, 0xc2, 0x1ff, 0x40016b4c, 0xbffff89c) kernel .text 0xc0100000 0xc01362cc 0xc013639c 0xc01070cb system_call+0x33 kernel .text 0xc0100000 0xc0107098 0xc01070d0 [0]kdb> HTH. Regards, Marc From owner-linux-xfs@oss.sgi.com Tue Oct 23 07:57:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9NEvVS06298 for linux-xfs-outgoing; Tue, 23 Oct 2001 07:57:31 -0700 Received: from k-7.stesmi.com (IDENT:root@as4-1-7.has.s.bonet.se [217.215.31.238]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9NEvRD06276 for ; Tue, 23 Oct 2001 07:57:27 -0700 Received: (from apache@localhost) by k-7.stesmi.com (8.11.2/8.8.7) id f9NEvuW01885; Tue, 23 Oct 2001 16:57:56 +0200 X-Authentication-Warning: k-7.stesmi.com: apache set sender to mbox001@stesmi.com using -f Received: from 212.247.172.29 (SquirrelMail authenticated user mbox001) by webmail.stesmi.com with HTTP; Tue, 23 Oct 2001 16:57:56 +0200 (CEST) Message-ID: <65049.212.247.172.29.1003849076.squirrel@webmail.stesmi.com> Date: Tue, 23 Oct 2001 16:57:56 +0200 (CEST) Subject: =?iso-8859-1?Q?Re:_XFS_1.01_installaton_over_Mandrake_8.1_XFS_1.0_installation=3F=3F=3F?= From: "=?iso-8859-1?Q?Stefan_Smietanowski?=" To: In-Reply-To: <3BD57E32.90908@postoffice.uri.edu> References: <3BD57E32.90908@postoffice.uri.edu> Cc: Reply-To: stesmi@stesmi.com X-Mailer: SquirrelMail (version 1.2.0 [rc1]) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > First of all, Imust say XFS is the best performing file system I > have used for Linux thus far. I have been using Jounalising Reiser FS, > but that gave me some issues after crashes, XFS has been through alot > in its short introduction to my system but it hasnt failed ever. > > I was wondering if it is worth it to upgrade to 1.01 from 1.0. How exactly did you install the system? Mandrake has it's own kernel, it has nothing to do with the 1.0 or 1.01 version numbering scheme. XFS 1.0.1 is the latest for RedHat based systems, your kernel in MDK 8.1 is even newer than that. So in effect, if you're runnning MDK 8.1 you're running a post-1.0.1 kernel. Except that it's not built by SGI. > and if so how would one go about doing that, I am an experienced linux > user, but not experienced in installing or upgrading a new file system > over an allready implimented one. Basically, if you're running MDK 8.1, you don't need to do much except perhaps if you want to grab a newer one to squash a few bugs. // Stefan From owner-linux-xfs@oss.sgi.com Tue Oct 23 08:18:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9NFIrB06924 for linux-xfs-outgoing; Tue, 23 Oct 2001 08:18:53 -0700 Received: from mclean.mail.mindspring.net (mclean.mail.mindspring.net [207.69.200.57]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9NFImD06899 for ; Tue, 23 Oct 2001 08:18:48 -0700 Received: from walt400.localhost (user-uini6dg.dsl.mindspring.com [165.121.25.176]) by mclean.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id LAA10793 for ; Tue, 23 Oct 2001 11:18:48 -0400 (EDT) Received: from mindspring.com (localhost.localdomain [127.0.0.1]) by walt400.localhost (Postfix) with ESMTP id 4D7938194C6; Tue, 23 Oct 2001 08:17:16 -0700 (PDT) Message-ID: <3BD589FB.9000204@mindspring.com> Date: Tue, 23 Oct 2001 08:17:15 -0700 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5+) Gecko/20011018 X-Accept-Language: en-us MIME-Version: 1.0 To: Nicholas DePetrillo Cc: linux-xfs@oss.sgi.com Subject: Re: XFS 1.01 installaton over Mandrake 8.1 XFS 1.0 installation??? References: <3BD57E32.90908@postoffice.uri.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, According to your subject line, you are using Mandrake 8.1? If I'm not mistaken, Mandrake 8.1 ships with a newer kernel than what XFS 1.01 was targeted at. I think you're better off staying with the Mdk 8.1 kernel, or if you *must* upgrade, consider the kernel packages on Cooker. I believe someone on the list mentioned that they've updated to 2.4.12 on Cooker. -Walt Nicholas DePetrillo wrote: > First of all, Imust say XFS is the best performing file system I have > used for Linux thus far. I have been using Jounalising Reiser FS, but > that gave me some issues after crashes, XFS has been through alot in its > short introduction to my system but it hasnt failed ever. > > I was wondering if it is worth it to upgrade to 1.01 from 1.0. > > and if so how would one go about doing that, I am an experienced linux > user, but not experienced in installing or upgrading a new file system > over an allready implimented one. > > Thank you > Nicholas DePetrillo > ndep8515@postoffice.uri.edu > From owner-linux-xfs@oss.sgi.com Tue Oct 23 08:50:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9NFo3T07773 for linux-xfs-outgoing; Tue, 23 Oct 2001 08:50:03 -0700 Received: from sqf1373.britain.agilent.com ([192.25.22.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9NFnvD07749 for ; Tue, 23 Oct 2001 08:49:58 -0700 Received: from agilent.com (IDENT:mcowe@localhost [127.0.0.1]) by sqf1373.britain.agilent.com (8.9.3/8.9.3) with ESMTP id QAA22358 for ; Tue, 23 Oct 2001 16:49:49 +0100 Message-ID: <3BD5919D.9EF74294@agilent.com> Date: Tue, 23 Oct 2001 16:49:49 +0100 From: Malcolm Cowe Organization: Agilent Technologies UK Ltd. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.18-mosix i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS 1.0.1 Install Problems Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I've spent part of today trying to install an XFS enabled RH 7.1 distribution based on your ISO cdrom image. However, when the system reboots after the install completes, I get the following error just after the kernel uncompresses: invalid compressed format -- System halted >From searching the Web, there doesn't appear to be any conclusive discussion about what this error means. The most likely answer is that the kernel image has been corrupted, but I don't know how that could be -- I put a separate 32MB /boot partition right at the start of the disk, and use ext2 for it. I'm using a NetServer LH3000 from HP with a NetRAID 2M card configured for 2x36GB disks in RAID 1. I have tried installing a stock RH system with the same file system layout, and it succeeds. If I have to create my own kernel image, are there any fs conversion tools to help me? Also, which kernel revision would you recommend (we are sticking with 2.4.9 for the most part since it appears more stable than the newer releases)? If you can help, I'd appreciate it. -- Malcolm Cowe. IT | Technical Computing, Telephone: +44 131 331 6466 Agilent Technologies Ltd. Telnet: 313-3466 From owner-linux-xfs@oss.sgi.com Tue Oct 23 08:58:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9NFwdH08022 for linux-xfs-outgoing; Tue, 23 Oct 2001 08:58:39 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9NFwYD08000 for ; Tue, 23 Oct 2001 08:58:34 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA17932 for ; Tue, 23 Oct 2001 08:58:27 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA3379206; Tue, 23 Oct 2001 10:57:16 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA10449; Tue, 23 Oct 2001 10:57:15 -0500 (CDT) Subject: Re: XFS 1.0.1 Install Problems From: Eric Sandeen To: Malcolm Cowe Cc: linux-xfs@oss.sgi.com In-Reply-To: <3BD5919D.9EF74294@agilent.com> References: <3BD5919D.9EF74294@agilent.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 23 Oct 2001 10:55:48 -0500 Message-Id: <1003852549.13566.94.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Malcolm - For starters, you're not booting off the floppy the installer created, are you? The XFS kernel is big enough that the installer usually can't fit it on a floppy (yes, a warning would have been good...). There are no ext2<->xfs conversion tools. Backup & restore is the only migration path. Regarding 2.4.9, I just released a test version of Red Hat's 7.1 update kernel, with the latest XFS bits merged. -Eric On Tue, 2001-10-23 at 10:49, Malcolm Cowe wrote: > Hi, > > I've spent part of today trying to install an XFS enabled RH 7.1 > distribution based on your ISO cdrom image. However, when the system > reboots after the install completes, I get the following error just > after the kernel uncompresses: > > invalid compressed format > -- System halted > > >From searching the Web, there doesn't appear to be any conclusive > discussion about what this error means. The most likely answer is that > the kernel image has been corrupted, but I don't know how that could be > -- I put a separate 32MB /boot partition right at the start of the disk, > and use ext2 for it. > > I'm using a NetServer LH3000 from HP with a NetRAID 2M card configured > for 2x36GB disks in RAID 1. I have tried installing a stock RH system > with the same file system layout, and it succeeds. If I have to create > my own kernel image, are there any fs conversion tools to help me? Also, > which kernel revision would you recommend (we are sticking with 2.4.9 > for the most part since it appears more stable than the newer releases)? -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Oct 23 09:08:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9NG8BW08335 for linux-xfs-outgoing; Tue, 23 Oct 2001 09:08:11 -0700 Received: from mail.cc.kuleuven.ac.be (mail.cc.kuleuven.ac.be [134.58.10.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9NG88D08308 for ; Tue, 23 Oct 2001 09:08:08 -0700 Received: from pclab.cc.kuleuven.ac.be (pc-10-33-6-229.cc.kuleuven.ac.be [10.33.6.229]) by mail.cc.kuleuven.ac.be (8.9.3/8.9.0) with ESMTP id SAA68140 for ; Tue, 23 Oct 2001 18:08:06 +0200 Message-Id: <5.1.0.14.2.20011023180602.00a48020@pb429905.kuleuven.be> X-Sender: pb429905@pb429905.kuleuven.be X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 23 Oct 2001 18:07:35 +0200 To: linux-xfs@oss.sgi.com From: werner maes Subject: Re: Relesing the installer for RH7.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Interesting, can't wait but will have to :) Werner >> Are you going to be releasing a new version of the XFS installer for RedHat >> 7.2, >Yes. >> and if so when? >When it's ready; hopefully "soon" - depending on your version of soon. >:) From owner-linux-xfs@oss.sgi.com Tue Oct 23 09:24:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9NGOJB08637 for linux-xfs-outgoing; Tue, 23 Oct 2001 09:24:19 -0700 Received: from sqf1373.britain.agilent.com ([192.25.22.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9NGODD08615 for ; Tue, 23 Oct 2001 09:24:13 -0700 Received: from agilent.com (IDENT:mcowe@localhost [127.0.0.1]) by sqf1373.britain.agilent.com (8.9.3/8.9.3) with ESMTP id RAA22931 for ; Tue, 23 Oct 2001 17:24:06 +0100 Message-ID: <3BD599A6.508A243E@agilent.com> Date: Tue, 23 Oct 2001 17:24:06 +0100 From: Malcolm Cowe Organization: Agilent Technologies UK Ltd. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.18-mosix i686) X-Accept-Language: en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: XFS 1.0.1 Install Problems References: <3BD5919D.9EF74294@agilent.com> <1003852549.13566.94.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Not using the boot disk. Might just grab your patched kernel package and see if I can't shoehorn it in, though. Eric Sandeen wrote: > > Hi Malcolm - > > For starters, you're not booting off the floppy the installer created, > are you? The XFS kernel is big enough that the installer usually can't > fit it on a floppy (yes, a warning would have been good...). > > There are no ext2<->xfs conversion tools. Backup & restore is the only > migration path. > > Regarding 2.4.9, I just released a test version of Red Hat's 7.1 update > kernel, with the latest XFS bits merged. > > -Eric > > On Tue, 2001-10-23 at 10:49, Malcolm Cowe wrote: > > Hi, > > > > I've spent part of today trying to install an XFS enabled RH 7.1 > > distribution based on your ISO cdrom image. However, when the system > > reboots after the install completes, I get the following error just > > after the kernel uncompresses: > > > > invalid compressed format > > -- System halted > > > > >From searching the Web, there doesn't appear to be any conclusive > > discussion about what this error means. The most likely answer is that > > the kernel image has been corrupted, but I don't know how that could be > > -- I put a separate 32MB /boot partition right at the start of the disk, > > and use ext2 for it. > > > > I'm using a NetServer LH3000 from HP with a NetRAID 2M card configured > > for 2x36GB disks in RAID 1. I have tried installing a stock RH system > > with the same file system layout, and it succeeds. If I have to create > > my own kernel image, are there any fs conversion tools to help me? Also, > > which kernel revision would you recommend (we are sticking with 2.4.9 > > for the most part since it appears more stable than the newer releases)? > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Oct 23 11:43:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9NIhGh10704 for linux-xfs-outgoing; Tue, 23 Oct 2001 11:43:16 -0700 Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9NIhDD10682 for ; Tue, 23 Oct 2001 11:43:13 -0700 Received: from pc9391.physik.uni-regensburg.de (mail@pc9391.physik.uni-regensburg.de [132.199.98.219]) by rrzs2.rz.uni-regensburg.de (8.9.3/8.9.3-URRZ-Sol-2.7-01) with ESMTP id UAA20875 for ; Tue, 23 Oct 2001 20:43:11 +0200 (MET DST) Received: from guc28561 by pc9391.physik.uni-regensburg.de with local (Exim 3.32 #1 (Debian)) id 15w6W6-0008Ll-00 for ; Tue, 23 Oct 2001 20:43:10 +0200 Date: Tue, 23 Oct 2001 20:43:10 +0200 From: Christian Guggenberger To: linux-xfs@oss.sgi.com Subject: possible to reserve space for superuser ? Message-ID: <20011023204310.A31156@pc9391.uni-regensburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Balsa 1.2.0 Lines: 10 X-MIME-Autoconverted: from 8bit to quoted-printable by rrzs2.rz.uni-regensburg.de id UAA20875 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f9NIhED10683 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi there, is it possible to reserve partition space for the superuser ? ("good old" ext2 can handle this) I did´n´t find anything usefull about this in the Docs, so post to you ! Can Quota be a solution for my problem ? thank you, Christian Guggenberger From owner-linux-xfs@oss.sgi.com Tue Oct 23 11:58:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9NIwpO11513 for linux-xfs-outgoing; Tue, 23 Oct 2001 11:58:51 -0700 Received: from fsc.cpsc.ucalgary.ca (fsc.cpsc.ucalgary.ca [136.159.2.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9NIwkD11488 for ; Tue, 23 Oct 2001 11:58:46 -0700 Received: from imgw1.cpsc.ucalgary.ca (ons-imgw1 [192.168.1.66]) by fsc.cpsc.ucalgary.ca (8.11.6/8.11.6) with ESMTP id f9NIwgE04419 for ; Tue, 23 Oct 2001 12:58:42 -0600 Received: from cse (cse [136.159.5.18]) by imgw1.cpsc.ucalgary.ca (8.11.6/8.11.6) with ESMTP id f9NIwgv07314 for ; Tue, 23 Oct 2001 12:58:42 -0600 Date: Tue, 23 Oct 2001 12:58:42 -0600 (MDT) From: Michal Kozlowski X-X-Sender: To: Subject: failed to locate log tail Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi I have a small problem that I'm not sure how to solve, my entire file system is xfs, but after several umount/mount operation I get this error, XFS: failed to locate log tail XFS: log mount/recovery failed XFS: log mount failed I can easily fix this by running xfs_repair, but it's required booting from a boot disk since this happens to my root. Now it's seems like it only happens to the root, for some reason. I'm using xfsprogs 1.3.12 now since I thought maybe that would fix the error since it was also happening in 1.3.7. Kernel version 2.4.12-xfs and running with 512 Mb of RAM. The only strange thing could be the experimental hpt 370 controller software raid driver, but I've had no other problems with it. I can usually recreate the problem but running the following code for((i=0;i<100;i++)); do mount -a -t xfs umount -a -t xfs done If you need any over messages I'll be glad to send them Thanks for everything Mike From owner-linux-xfs@oss.sgi.com Tue Oct 23 12:29:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9NJToL13018 for linux-xfs-outgoing; Tue, 23 Oct 2001 12:29:50 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9NJTkD12995 for ; Tue, 23 Oct 2001 12:29:46 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9NJTaK15855 for ; Tue, 23 Oct 2001 12:29:36 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA3380808; Tue, 23 Oct 2001 14:28:19 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA92204; Tue, 23 Oct 2001 14:28:18 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9NJOjG12615; Tue, 23 Oct 2001 14:24:45 -0500 Message-Id: <200110231924.f9NJOjG12615@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Christian Guggenberger cc: linux-xfs@oss.sgi.com Subject: Re: possible to reserve space for superuser ? In-Reply-To: Message from Christian Guggenberger of "Tue, 23 Oct 2001 20:43:10 +0200." <20011023204310.A31156@pc9391.uni-regensburg.de> Content-Transfer-Encoding: 8bit Date: Tue, 23 Oct 2001 14:24:45 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hi there, > > is it possible to reserve partition space for the superuser ? ("good old" > ext2 can handle this) > I did4n4t find anything usefull about this in the Docs, so post to you ! > > Can Quota be a solution for my problem ? > > thank you, > Christian Guggenberger Not simply, it was not a concept built into the original xfs design, so it would take some surgery - and the concept of a super user is not as simple as it used to be, this would probably be based on some capability (OK, thats a minor implementation detail). Quotas could do it - but only by restricting everone else on the filesystem to a total less than the fs size. Steve From owner-linux-xfs@oss.sgi.com Tue Oct 23 12:43:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9NJhHD13423 for linux-xfs-outgoing; Tue, 23 Oct 2001 12:43:17 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9NJh0D13385 for ; Tue, 23 Oct 2001 12:43:00 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA01147 for ; Tue, 23 Oct 2001 12:42:52 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA3379739; Tue, 23 Oct 2001 14:41:29 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA10499; Tue, 23 Oct 2001 14:41:29 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9NJbuW12696; Tue, 23 Oct 2001 14:37:56 -0500 Message-Id: <200110231937.f9NJbuW12696@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Marc Schmitt cc: Eric Sandeen , linux-xfs@oss.sgi.com, florin@sgi.com Subject: Re: Corruption of in-memory data detected. In-Reply-To: Message from Marc Schmitt of "Tue, 23 Oct 2001 16:54:32 +0200." <3BD584A8.1060505@inf.ethz.ch> Date: Tue, 23 Oct 2001 14:37:56 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hmm, can you run xfs_repair -n on the filesystem (when unmounted) I suspect there is something corrupted in there. You are shutting down because xfs is cancelling a transaction which has already modified metadata - this does not happen during normal operation. Another possibility is this is yet another compiler issue - which compiler did you build with. Steve > Hi Eric, > > Eric Sandeen wrote: > > > > > If you don't mind tinkering a bit, the first thing to do is enable kdb > > and set a breakpoint, so we can see how we're getting to this point.. > > > Here the console output: > > Entering kdb (current=0xc039c000, pid 0) on processor 0 due to Keyboard > Entry > [0]kdb> bp _xfs_force_shutdown > Instruction(i) BP #0 at 0xc01f7208 (_xfs_force_shutdown) is enabled > globally adjust 1 > [0]kdb> go > XFS mounting filesystem md(9,0) > Instruction(i) breakpoint #0 at 0xc01f7208 (adjusted) > 0xc01f7208 _xfs_force_shutdown: int3 > > Entering kdb (current=0xd9f06000, pid 2459) on processor 0 due to > Breakpoint @ 0xc01f7208 > [0]kdb> bt > EBP EIP Function(args) > 0xd9f07c3c 0xc01f7208 _xfs_force_shutdown (0xdab55400, 0x8, 0xc02cadc3, > 0x3fc) > kernel .text 0xc0100000 0xc01f7208 > 0xc01f7338 > 0xc01ec31e xfs_trans_cancel+0x46 (0xd9263980, 0xc) > kernel .text 0xc0100000 0xc01ec2d8 > 0xc01ec37c > 0xd9f07cf0 0xc01f2d56 xfs_create+0x9ca (0xd9397d44, 0xd9282d7c, > 0xd9f07e74, 0x0, 0x0) > kernel .text 0xc0100000 0xc01f238c > 0xc01f2dd0 > 0xd9f07ee4 0xc01fb02f linvfs_common_cr+0x123 (0xda00abc0, 0xd9282d20, > 0x81ff, 0x1, 0x0) > kernel .text 0xc0100000 0xc01faf0c > 0xc01fb174 > 0xd9f07f00 0xc01fb18c linvfs_create+0x18 (0xda00abc0, 0xd9282d20, 0x81ff) > kernel .text 0xc0100000 0xc01fb174 > 0xc01fb190 > 0xd9f07f28 0xc0140cef vfs_create+0x127 (0xda00abc0, 0xd9282d20, 0x1ff, > 0x1ff) > kernel .text 0xc0100000 0xc0140bc8 > 0xc0140d40 > 0xd9f07f60 0xc0140eac open_namei+0x16c (0xdec13000, 0xc3, 0x1ff, 0xd9f07f84) > kernel .text 0xc0100000 0xc0140d40 > 0xc01413dc > 0xd9f07fa0 0xc0135fb2 filp_open+0x3a (0xdec13000, 0xc2, 0x1ff) > kernel .text 0xc0100000 0xc0135f78 > 0xc0135fd4 > 0xd9f07fbc 0xc0136302 sys_open+0x36 (0xbffff718, 0xc2, 0x1ff, > 0x40016b4c, 0xbffff89c) > kernel .text 0xc0100000 0xc01362cc > 0xc013639c > 0xc01070cb system_call+0x33 > kernel .text 0xc0100000 0xc0107098 > 0xc01070d0 > [0]kdb> > > > HTH. > > Regards, > Marc > From owner-linux-xfs@oss.sgi.com Tue Oct 23 14:10:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9NLA5X15170 for linux-xfs-outgoing; Tue, 23 Oct 2001 14:10:05 -0700 Received: from natura.oskuro.net ([213.96.69.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9NL9uD15134 for ; Tue, 23 Oct 2001 14:09:57 -0700 Received: from nubol.amalur.nat (nubol.amalur.nat [192.168.1.3]) by natura.oskuro.net (Postfix) with ESMTP id E614927F76 for ; Tue, 23 Oct 2001 23:09:53 +0200 (CEST) Received: by nubol.amalur.nat (Postfix, from userid 1000) id DBC6F700982; Tue, 23 Oct 2001 23:10:11 +0200 (CEST) Date: Tue, 23 Oct 2001 23:10:11 +0200 From: Jordi Mallach To: linux-xfs@oss.sgi.com Subject: About the -ac branch Message-ID: <20011023231011.A14170@nubol.oskuro.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline User-Agent: Mutt/1.3.23i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --UugvWAfsgieZRqgk Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello! First of all, thank you for the work you are doing on XFS for Linux. I've been using it for some time now and I'm very happy with it, no problems till the date. Anyway, the problem. You know Linus and Alan's trees have diverged more and more lately, and many people are prefering Alan's tree now because of some decisions taken by Linus are a bit too much for a stable branch (like the sudden change of VM core). Anyway, I'm one of them, but currently I'm stuck with Linus because there's no patches for the -ac kernels. [SYSTEM] % find ./ -name "*.rej" WC 24 Ew, a bit too much. I know this is mentioned in the faq and so on, but I guess you don't need to do patch every -ac that gets released. If you just did a few patches, say 1 every 1 or 2 weeks, and targetting what Alan calls "safe" kernels (he mentions what should be ok and what shouldn't in the changelogs), that would be more than enough for people in my situation. Thanks again for your great work, Jordi (speaking in behalf or a few more) --=20 Jordi Mallach P=E9rez || jordi@pusa.informat.uv.es || Rediscovering Freedom, aka Oskuro in || jordi@sindominio.net || Using Debian GNU/Linux Reinos de Leyenda || jordi@debian.org || http://debian.org http://sindominio.net GnuPG public information: pub 1024D/917A225E= =20 telnet pusa.uv.es 23 73ED 4244 FD43 5886 20AC 2644 2584 94BA 917A 225E --UugvWAfsgieZRqgk 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 iD8DBQE71dyzJYSUupF6Il4RAlsPAJ4o6QruOac1R95vJvhMavnfR/THugCeM9u0 fOb4DD7pmoGDC9qcObIHzWA= =GkNO -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk-- From owner-linux-xfs@oss.sgi.com Tue Oct 23 14:21:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9NLLiM15641 for linux-xfs-outgoing; Tue, 23 Oct 2001 14:21:44 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9NLLeD15618 for ; Tue, 23 Oct 2001 14:21:40 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA13802 for ; Tue, 23 Oct 2001 14:21:33 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA3368575; Tue, 23 Oct 2001 16:20:22 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id QAA55041; Tue, 23 Oct 2001 16:20:21 -0500 (CDT) Subject: Re: About the -ac branch From: Eric Sandeen To: Jordi Mallach Cc: linux-xfs@oss.sgi.com In-Reply-To: <20011023231011.A14170@nubol.oskuro.net> References: <20011023231011.A14170@nubol.oskuro.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 23 Oct 2001 16:18:52 -0500 Message-Id: <1003871932.20416.32.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Jordi - You might take a look at the recent kernels in the testing/ dir, if you extract the patches from the SRPMS it might not be a bad place to start, both of these are based on -ac kernels. (note that the lvm code in the 2.4.9 kernel is broken, if that matters to you). -Eric On Tue, 2001-10-23 at 16:10, Jordi Mallach wrote: > Hello! > > First of all, thank you for the work you are doing on XFS for Linux. > I've been using it for some time now and I'm very happy with it, no > problems till the date. > > Anyway, the problem. You know Linus and Alan's trees have diverged more > and more lately, and many people are prefering Alan's tree now because > of some decisions taken by Linus are a bit too much for a stable branch > (like the sudden change of VM core). Anyway, I'm one of them, but > currently I'm stuck with Linus because there's no patches for the -ac > kernels. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Oct 23 14:28:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9NLSVX15906 for linux-xfs-outgoing; Tue, 23 Oct 2001 14:28:31 -0700 Received: from flaske.stud.ntnu.no (flaske.stud.ntnu.no [129.241.56.72]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9NLSRD15884 for ; Tue, 23 Oct 2001 14:28:27 -0700 Received: from puma.stud.ntnu.no (puma.stud.ntnu.no [129.241.56.183]) by flaske.stud.ntnu.no (Postfix) with ESMTP id 92AE0FF0D9; Tue, 23 Oct 2001 23:27:16 +0200 (CEST) Received: from localhost (sebastid@localhost) by puma.stud.ntnu.no (8.11.6/8.10.0.Beta12) with ESMTP id f9NLSCm23591; Tue, 23 Oct 2001 23:28:12 +0200 X-Authentication-Warning: puma.stud.ntnu.no: sebastid owned process doing -bs Date: Tue, 23 Oct 2001 23:28:12 +0200 (CEST) From: Sebastian Dransfeld To: Eric Sandeen Cc: Jordi Mallach , Subject: Re: About the -ac branch In-Reply-To: <1003871932.20416.32.camel@stout.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk And, as previously mentioned, check the Mandrake cooker kernels. seb On 23 Oct 2001, Eric Sandeen wrote: > Hi Jordi - > > You might take a look at the recent kernels in the testing/ dir, if you > extract the patches from the SRPMS it might not be a bad place to start, > both of these are based on -ac kernels. > > (note that the lvm code in the 2.4.9 kernel is broken, if that matters > to you). > > -Eric > > On Tue, 2001-10-23 at 16:10, Jordi Mallach wrote: > > Hello! > > > > First of all, thank you for the work you are doing on XFS for Linux. > > I've been using it for some time now and I'm very happy with it, no > > problems till the date. > > > > Anyway, the problem. You know Linus and Alan's trees have diverged more > > and more lately, and many people are prefering Alan's tree now because > > of some decisions taken by Linus are a bit too much for a stable branch > > (like the sudden change of VM core). Anyway, I'm one of them, but > > currently I'm stuck with Linus because there's no patches for the -ac > > kernels. > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. > From owner-linux-xfs@oss.sgi.com Tue Oct 23 14:37:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9NLbQY16354 for linux-xfs-outgoing; Tue, 23 Oct 2001 14:37:26 -0700 Received: from relay01.cablecom.net (relay01.cablecom.net [62.2.33.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9NLbKD16332 for ; Tue, 23 Oct 2001 14:37:20 -0700 Received: from mail.swissonline.ch (mail.swissonline.ch [62.2.32.83]) by relay01.cablecom.net (8.11.6/8.11.4/SOL/AWF/MXRELAY/06072001) with ESMTP id f9NLbDu29951; Tue, 23 Oct 2001 23:37:13 +0200 (CEST) Received: from inf.ethz.ch (dclient217-162-214-104.hispeed.ch [217.162.214.104]) by mail.swissonline.ch (8.11.4/8.11.4/MSOL-2.30/21-Dec-2000) with ESMTP id f9NLbDQ08687; Tue, 23 Oct 2001 23:37:13 +0200 (MET DST) Message-ID: <3BD5E308.B99ACF30@inf.ethz.ch> Date: Tue, 23 Oct 2001 23:37:12 +0200 From: Marc Schmitt X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: linux-xfs@oss.sgi.com Subject: Re: Corruption of in-memory data detected. References: <3BD4137A.8040406@inf.ethz.ch> <1003770847.13566.36.camel@stout.americas.sgi .com> <3BD584A8.1060505@inf.ethz.ch> <1003851758.18882.80.camel@stout.americas.sgi.com> <3BD596AB.7030707@inf.ethz.ch> <1003854361.18882.100.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Eric, Eric Sandeen wrote: > Do you have this on a serial console? Any chance we could ssh in and > look at it? I could put an XFS guru on the line. :) I will create an account on the terminal server for your guru tomorrow, when I'm back in the office. :) I managed to get the output of xtp: ---- zip 0xc01ec31e xfs_trans_cancel+0x46 (0xde4fcce0, 0xc) kernel .text 0xc0100000 0xc01ec2d8 0xc01ec37c ---- zip [0]kdb> xtp 0xde4fcce0 tp 0xde4fcce0 type CREATE mount 0xde670000 flags xtp 0x7 callback 0xde4fcce4 forw 0x00000000 back 0x00000000 log res 158392 block res 41 block res used 0 rt res 0 rt res used 0 ticket 0xda994690 lsn [0:0] callback 0x00000000 callarg 0x00000000 icount delta 0 ifree delta -1 blocks delta 0 res blocks delta 0 rt delta 0 res rt delta 0 ag freeblks delta 0 ag flist delta 0 ag btree delta 0 dblocks delta 0 agcount delta 0 imaxpct delta 0 rextsize delta 0 rbmblocks delta 0 rblocks delta 0 rextents delta 0 rextslog delta 0 dqinfo 0x00000000 log items: chunk 0 index 0 item 0xdb516d38 size 0 flags lic 0x1 type buf mountp 0xde670000 flags log 0x0 <> ail forw 0x00000000 ail back 0x00000000 lsn [0:0] desc de4fcd98 ops 0xc0390d20 iodonefunc &0xc01c0ecc Greetz Marc From owner-linux-xfs@oss.sgi.com Tue Oct 23 14:41:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9NLf2s16530 for linux-xfs-outgoing; Tue, 23 Oct 2001 14:41:02 -0700 Received: from relay02.cablecom.net (relay02.cablecom.net [62.2.33.102]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9NLeuD16500 for ; Tue, 23 Oct 2001 14:40:57 -0700 Received: from mail.swissonline.ch (mail.swissonline.ch [62.2.32.83]) by relay02.cablecom.net (8.11.6/8.11.4/SOL/AWF/MXRELAY/06072001) with ESMTP id f9NLenc02310; Tue, 23 Oct 2001 23:40:49 +0200 (CEST) Received: from inf.ethz.ch (dclient217-162-214-104.hispeed.ch [217.162.214.104]) by mail.swissonline.ch (8.11.4/8.11.4/MSOL-2.30/21-Dec-2000) with ESMTP id f9NLenQ14040; Tue, 23 Oct 2001 23:40:49 +0200 (MET DST) Message-ID: <3BD5E3DF.D6009623@inf.ethz.ch> Date: Tue, 23 Oct 2001 23:40:47 +0200 From: Marc Schmitt X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: linux-xfs@oss.sgi.com Subject: Re: Corruption of in-memory data detected. References: <3BD4137A.8040406@inf.ethz.ch> <1003770847.13566.36.camel@stout.americas.sgi .com> <3BD584A8.1060505@inf.ethz.ch> <1003851758.18882.80.camel@stout.americas.sgi.com> <3BD596AB.7030707@inf.ethz.ch> <1003854361.18882.100.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sorry, I didn't paste all of it, here we go again: [0]kdb> xtp 0xde4fcce0 tp 0xde4fcce0 type CREATE mount 0xde670000 flags xtp 0x7 callback 0xde4fcce4 forw 0x00000000 back 0x00000000 log res 158392 block res 41 block res used 0 rt res 0 rt res used 0 ticket 0xda994690 lsn [0:0] callback 0x00000000 callarg 0x00000000 icount delta 0 ifree delta -1 blocks delta 0 res blocks delta 0 rt delta 0 res rt delta 0 ag freeblks delta 0 ag flist delta 0 ag btree delta 0 dblocks delta 0 agcount delta 0 imaxpct delta 0 rextsize delta 0 rbmblocks delta 0 rblocks delta 0 rextents delta 0 rextslog delta 0 dqinfo 0x00000000 log items: chunk 0 index 0 item 0xdb516d38 size 0 flags lic 0x1 type buf mountp 0xde670000 flags log 0x0 <> ail forw 0x00000000 ail back 0x00000000 lsn [0:0] desc de4fcd98 ops 0xc0390d20 iodonefunc &0xc01c0ecc [0]more> buf 0xdb0f6d60 recur 0 refcount 22 flags:dirty logged size 2 blkno 0x2 len 0x1 map size 1 map 0xdb516d88 blf flags: chunk 0 index 1 item 0xdb516ca4 size 0 flags lic 0x1 type buf mountp 0xde670000 flags log 0x0 <> ail forw 0x00000000 ail back 0x00000000 lsn [0:0] desc de4fcda0 ops 0xc0390d20 iodonefunc &0xc01c0ecc buf 0xdb0f6ca0 recur 0 refcount 22 flags:dirty logged size 2 blkno 0x18 len 0x8 map size 2 map 0xdb516cf4 blf flags: [0]kdb> Greetz Marc From owner-linux-xfs@oss.sgi.com Tue Oct 23 15:10:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9NMA1A17069 for linux-xfs-outgoing; Tue, 23 Oct 2001 15:10:01 -0700 Received: from natura.oskuro.net ([213.96.69.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9NM9sD17035 for ; Tue, 23 Oct 2001 15:09:54 -0700 Received: from nubol.amalur.nat (nubol.amalur.nat [192.168.1.3]) by natura.oskuro.net (Postfix) with ESMTP id BD05927F76; Wed, 24 Oct 2001 00:09:52 +0200 (CEST) Received: by nubol.amalur.nat (Postfix, from userid 1000) id A7CDB700964; Wed, 24 Oct 2001 00:10:10 +0200 (CEST) Date: Wed, 24 Oct 2001 00:10:10 +0200 From: Jordi Mallach To: Eric Sandeen , Sebastian Dransfeld Cc: linux-xfs@oss.sgi.com Subject: Re: About the -ac branch Message-ID: <20011024001010.B14709@nubol.oskuro.net> References: <20011023231011.A14170@nubol.oskuro.net> <1003871932.20416.32.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BwCQnh7xodEAoBMC" Content-Disposition: inline In-Reply-To: <1003871932.20416.32.camel@stout.americas.sgi.com> User-Agent: Mutt/1.3.23i Organization: SinDominio X-Operating-System: Debian GNU/Linux sid (Linux 2.4.12-xfs i686) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --BwCQnh7xodEAoBMC Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 23, 2001 at 04:18:52PM -0500, Eric Sandeen wrote: > You might take a look at the recent kernels in the testing/ dir, if you > extract the patches from the SRPMS it might not be a bad place to start, > both of these are based on -ac kernels. Hm, we've been looking around, but we don't know which exact dir/kernel you're refering too. No kernels looked like they were -ac kernels. > (note that the lvm code in the 2.4.9 kernel is broken, if that matters > to you). No plans to use LVM atm. On Tue, Oct 23, 2001 at 11:28:12PM +0200, Sebastian Dransfeld wrote: > And, as previously mentioned, check the Mandrake cooker kernels. Hm. We're poor Debian people. I think "cooker" is what "sid" or "unstable" is in our distribution, but browsing the web I only found RPM mirrors, not SRPM's, and then, I see "kernel" and "kernel-linus" packages. The latter I guess it's pristine Linus tree, and the first one must be Mandrake's custom kernel, which I have no clue if it's based on -ac or not. I guess the "one -ac patch every two weeks" wasn't so good? Is it a big pain for you? Jordi (speaking for a bunch of rpm-iliterates :) --=20 Jordi Mallach P=E9rez || jordi@pusa.informat.uv.es || Rediscovering Freedom, aka Oskuro in || jordi@sindominio.net || Using Debian GNU/Linux Reinos de Leyenda || jordi@debian.org || http://debian.org http://sindominio.net GnuPG public information: pub 1024D/917A225E= =20 telnet pusa.uv.es 23 73ED 4244 FD43 5886 20AC 2644 2584 94BA 917A 225E --BwCQnh7xodEAoBMC 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 iD8DBQE71erCJYSUupF6Il4RAjOvAJ9/L1dslSw6d2iZ9knQcJmtPaaPKQCgt0zB DLgyroKdBdlfBIfCNxw3nns= =jP7u -----END PGP SIGNATURE----- --BwCQnh7xodEAoBMC-- From owner-linux-xfs@oss.sgi.com Tue Oct 23 15:20:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9NMKY917323 for linux-xfs-outgoing; Tue, 23 Oct 2001 15:20:34 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9NMKTD17301 for ; Tue, 23 Oct 2001 15:20:29 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9NMKNW18674 for ; Tue, 23 Oct 2001 15:20:23 -0700 Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA3064711; Tue, 23 Oct 2001 17:19:07 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id RAA90147; Tue, 23 Oct 2001 17:19:07 -0500 (CDT) Subject: Re: About the -ac branch From: Eric Sandeen To: Jordi Mallach Cc: Sebastian Dransfeld , linux-xfs@oss.sgi.com In-Reply-To: <20011024001010.B14709@nubol.oskuro.net> References: <20011023231011.A14170@nubol.oskuro.net> <1003871932.20416.32.camel@stout.americas.sgi.com> <20011024001010.B14709@nubol.oskuro.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 23 Oct 2001 17:17:37 -0500 Message-Id: <1003875457.20357.48.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2001-10-23 at 17:10, Jordi Mallach wrote: > Hm, we've been looking around, but we don't know which exact dir/kernel > you're refering too. No kernels looked like they were -ac kernels. Sorry, they're Red Hat RPMs, but they're based on ac: ftp://oss.sgi.com/projects/xfs/download/testing/RH2.4.9-6/kernel-2.4.9-6SGI_XFS_PR1.src.rpm > Hm. We're poor Debian people. I think "cooker" is what "sid" or > "unstable" is in our distribution, but browsing the web I only found RPM > mirrors, not SRPM's, and then, I see "kernel" and "kernel-linus" > packages. The latter I guess it's pristine Linus tree, and the first one > must be Mandrake's custom kernel, which I have no clue if it's based on > -ac or not. Any recent Mandrake kernel is based on -ac, there should be SRPMS somewhere in the ftp hierarchy... > I guess the "one -ac patch every two weeks" wasn't so good? Is it a big > pain for you? It is a big pain... as it is, the weekly patches are script-generated. Doing an -ac merge is labor-intensive and time consuming... ...but not really ALL that tricky, most of the time. Any volunteers with more time than I have? :) FWIW, many of those 24 rejects are probably trivial - fcntl.h for each architecture comes to mind. Feel free to give it a shot, I'll offer encouragement and advice when I can. :) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Oct 23 15:24:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9NMO9p17503 for linux-xfs-outgoing; Tue, 23 Oct 2001 15:24:09 -0700 Received: from relay02.cablecom.net (relay02.cablecom.net [62.2.33.102]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9NMMsD17397 for ; Tue, 23 Oct 2001 15:22:54 -0700 Received: from mail.swissonline.ch (mail.swissonline.ch [62.2.32.83]) by relay02.cablecom.net (8.11.6/8.11.4/SOL/AWF/MXRELAY/06072001) with ESMTP id f9NMMjc10221; Wed, 24 Oct 2001 00:22:45 +0200 (CEST) Received: from inf.ethz.ch (dclient217-162-214-104.hispeed.ch [217.162.214.104]) by mail.swissonline.ch (8.11.4/8.11.4/MSOL-2.30/21-Dec-2000) with ESMTP id f9NMMhQ16995; Wed, 24 Oct 2001 00:22:43 +0200 (MET DST) Message-ID: <3BD5EDB0.1A238C02@inf.ethz.ch> Date: Wed, 24 Oct 2001 00:22:40 +0200 From: Marc Schmitt X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: Eric Sandeen , linux-xfs@oss.sgi.com, florin@sgi.com Subject: Re: Corruption of in-memory data detected. References: <200110231937.f9NJbuW12696@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Steve, Steve Lord wrote: > > Hmm, can you run xfs_repair -n on the filesystem (when unmounted) I > suspect there is something corrupted in there. You are shutting down > because xfs is cancelling a transaction which has already modified > metadata - this does not happen during normal operation. Just to remind, mongo.pl always recreates the file system on /dev/md0 (with 'mkfs.xfs -l size=32768b -f /dev/md0') before it starts creating files. Here is the output of 'xfs_repair -n /dev/md0': Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock... ...........--->cut<--- ..found candidate secondary superblock... verified secondary superblock... would write modified primary superblock primary superblock would have been modified. cannot proceed further in no_modify mode. exiting now. ------------------------------------------------------------------ Here is the output of 'xfs_repair /dev/md0': Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock... .............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................! .............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................! .............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................! .............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................! .............................................................................................................................found candidate secondary superblock... verified secondary superblock... writing modified primary superblock sb root inode value 18446744073709551615 inconsistent with calculated value 13835049053030711424 resetting superblock root inode pointer to 18446744069414584448 sb realtime bitmap inode 18446744073709551615 inconsistent with calculated value 13835049053030711425 resetting superblock realtime bitmap ino pointer to 18446744069414584449 sb realtime summary inode 18446744073709551615 inconsistent with calculated value 13835049053030711426 resetting superblock realtime summary ino pointer to 18446744069414584450 Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... bad magic # 0x0 for agf 0 bad version # 0 for agf 0 bad length 0 for agf 0, should be 1048576 bad magic # 0x0 for agi 0 bad version # 0 for agi 0 bad length # 0 for agi 0, should be 1048576 reset bad agf for ag 0 reset bad agi for ag 0 bad agbno 0 for btbno root, agno 0 bad agbno 0 for btbcnt root, agno 0 bad agbno 0 for inobt root, agno 0 root inode chunk not found Phase 3 - for each AG... - scan and clear agi unlinked lists... error following ag 0 unlinked list - process known inodes and perform inode discovery... - agno = 0 bad magic number 0x0 on inode 144 bad version number 0x0 on inode 144 bad magic number 0x0 on inode 145 bad version number 0x0 on inode 145 bad magic number 0x0 on inode 146 bad version number 0x0 on inode 146 bad magic number 0x0 on inode 147 bad version number 0x0 on inode 147 bad magic number 0x0 on inode 148 bad version number 0x0 on inode 148 bad magic number 0x0 on inode 149 bad version number 0x0 on inode 149 bad magic number 0x0 on inode 150 bad version number 0x0 on inode 150 bad magic number 0x0 on inode 151 bad version number 0x0 on inode 151 bad magic number 0x0 on inode 152 bad version number 0x0 on inode 152 bad magic number 0x0 on inode 153 bad version number 0x0 on inode 153 bad magic number 0x0 on inode 154 bad version number 0x0 on inode 154 bad magic number 0x0 on inode 155 bad version number 0x0 on inode 155 bad magic number 0x0 on inode 156 bad version number 0x0 on inode 156 bad magic number 0x0 on inode 157 bad version number 0x0 on inode 157 bad magic number 0x0 on inode 158 bad version number 0x0 on inode 158 bad magic number 0x0 on inode 159 bad version number 0x0 on inode 159 bad magic number 0x0 on inode 176 bad version number 0x0 on inode 176 bad magic number 0x0 on inode 177 bad version number 0x0 on inode 177 bad magic number 0x0 on inode 178 bad version number 0x0 on inode 178 bad magic number 0x0 on inode 179 bad version number 0x0 on inode 179 bad magic number 0x0 on inode 180 bad version number 0x0 on inode 180 bad magic number 0x0 on inode 181 bad version number 0x0 on inode 181 bad magic number 0x0 on inode 182 bad version number 0x0 on inode 182 bad magic number 0x0 on inode 183 bad version number 0x0 on inode 183 bad magic number 0x0 on inode 184 bad version number 0x0 on inode 184 bad magic number 0x0 on inode 185 bad version number 0x0 on inode 185 bad magic number 0x0 on inode 186 bad version number 0x0 on inode 186 bad magic number 0x0 on inode 187 bad version number 0x0 on inode 187 bad magic number 0x0 on inode 188 bad version number 0x0 on inode 188 bad magic number 0x0 on inode 189 bad version number 0x0 on inode 189 bad magic number 0x0 on inode 190 bad version number 0x0 on inode 190 bad magic number 0x0 on inode 191 bad version number 0x0 on inode 191 bad magic number 0x0 on inode 132, resetting magic number bad version number 0x0 on inode 132, resetting version number bad magic number 0x0 on inode 133, resetting magic number bad version number 0x0 on inode 133, resetting version number bad magic number 0x0 on inode 134, resetting magic number bad version number 0x0 on inode 134, resetting version number bad magic number 0x0 on inode 135, resetting magic number bad version number 0x0 on inode 135, resetting version number bad magic number 0x0 on inode 136, resetting magic number bad version number 0x0 on inode 136, resetting version number bad magic number 0x0 on inode 137, resetting magic number bad version number 0x0 on inode 137, resetting version number bad magic number 0x0 on inode 138, resetting magic number bad version number 0x0 on inode 138, resetting version number bad magic number 0x0 on inode 139, resetting magic number bad version number 0x0 on inode 139, resetting version number bad magic number 0x0 on inode 140, resetting magic number bad version number 0x0 on inode 140, resetting version number bad magic number 0x0 on inode 141, resetting magic number bad version number 0x0 on inode 141, resetting version number bad magic number 0x0 on inode 142, resetting magic number bad version number 0x0 on inode 142, resetting version number bad magic number 0x0 on inode 143, resetting magic number bad version number 0x0 on inode 143, resetting version number bad magic number 0x0 on inode 144, resetting magic number bad version number 0x0 on inode 144, resetting version number bad magic number 0x0 on inode 145, resetting magic number bad version number 0x0 on inode 145, resetting version number bad magic number 0x0 on inode 146, resetting magic number bad version number 0x0 on inode 146, resetting version number bad magic number 0x0 on inode 147, resetting magic number bad version number 0x0 on inode 147, resetting version number bad magic number 0x0 on inode 148, resetting magic number bad version number 0x0 on inode 148, resetting version number bad magic number 0x0 on inode 149, resetting magic number bad version number 0x0 on inode 149, resetting version number bad magic number 0x0 on inode 150, resetting magic number bad version number 0x0 on inode 150, resetting version number bad magic number 0x0 on inode 151, resetting magic number bad version number 0x0 on inode 151, resetting version number bad magic number 0x0 on inode 152, resetting magic number bad version number 0x0 on inode 152, resetting version number bad magic number 0x0 on inode 153, resetting magic number bad version number 0x0 on inode 153, resetting version number bad magic number 0x0 on inode 154, resetting magic number bad version number 0x0 on inode 154, resetting version number bad magic number 0x0 on inode 155, resetting magic number bad version number 0x0 on inode 155, resetting version number bad magic number 0x0 on inode 156, resetting magic number bad version number 0x0 on inode 156, resetting version number bad magic number 0x0 on inode 157, resetting magic number bad version number 0x0 on inode 157, resetting version number bad magic number 0x0 on inode 158, resetting magic number bad version number 0x0 on inode 158, resetting version number bad magic number 0x0 on inode 159, resetting magic number bad version number 0x0 on inode 159, resetting version number bad magic number 0x0 on inode 160, resetting magic number bad version number 0x0 on inode 160, resetting version number bad magic number 0x0 on inode 161, resetting magic number bad version number 0x0 on inode 161, resetting version number bad magic number 0x0 on inode 162, resetting magic number bad version number 0x0 on inode 162, resetting version number bad magic number 0x0 on inode 163, resetting magic number bad version number 0x0 on inode 163, resetting version number bad magic number 0x0 on inode 164, resetting magic number bad version number 0x0 on inode 164, resetting version number bad magic number 0x0 on inode 165, resetting magic number bad version number 0x0 on inode 165, resetting version number bad magic number 0x0 on inode 166, resetting magic number bad version number 0x0 on inode 166, resetting version number bad magic number 0x0 on inode 167, resetting magic number bad version number 0x0 on inode 167, resetting version number bad magic number 0x0 on inode 168, resetting magic number bad version number 0x0 on inode 168, resetting version number bad magic number 0x0 on inode 169, resetting magic number bad version number 0x0 on inode 169, resetting version number bad magic number 0x0 on inode 170, resetting magic number bad version number 0x0 on inode 170, resetting version number bad magic number 0x0 on inode 171, resetting magic number bad version number 0x0 on inode 171, resetting version number bad magic number 0x0 on inode 172, resetting magic number bad version number 0x0 on inode 172, resetting version number bad magic number 0x0 on inode 173, resetting magic number bad version number 0x0 on inode 173, resetting version number bad magic number 0x0 on inode 174, resetting magic number bad version number 0x0 on inode 174, resetting version number bad magic number 0x0 on inode 175, resetting magic number bad version number 0x0 on inode 175, resetting version number bad magic number 0x0 on inode 176, resetting magic number bad version number 0x0 on inode 176, resetting version number bad magic number 0x0 on inode 177, resetting magic number bad version number 0x0 on inode 177, resetting version number bad magic number 0x0 on inode 178, resetting magic number bad version number 0x0 on inode 178, resetting version number bad magic number 0x0 on inode 179, resetting magic number bad version number 0x0 on inode 179, resetting version number bad magic number 0x0 on inode 180, resetting magic number bad version number 0x0 on inode 180, resetting version number bad magic number 0x0 on inode 181, resetting magic number bad version number 0x0 on inode 181, resetting version number bad magic number 0x0 on inode 182, resetting magic number bad version number 0x0 on inode 182, resetting version number bad magic number 0x0 on inode 183, resetting magic number bad version number 0x0 on inode 183, resetting version number bad magic number 0x0 on inode 184, resetting magic number bad version number 0x0 on inode 184, resetting version number bad magic number 0x0 on inode 185, resetting magic number bad version number 0x0 on inode 185, resetting version number bad magic number 0x0 on inode 186, resetting magic number bad version number 0x0 on inode 186, resetting version number bad magic number 0x0 on inode 187, resetting magic number bad version number 0x0 on inode 187, resetting version number bad magic number 0x0 on inode 188, resetting magic number bad version number 0x0 on inode 188, resetting version number bad magic number 0x0 on inode 189, resetting magic number bad version number 0x0 on inode 189, resetting version number bad magic number 0x0 on inode 190, resetting magic number bad version number 0x0 on inode 190, resetting version number bad magic number 0x0 on inode 191, resetting magic number bad version number 0x0 on inode 191, resetting version number - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 - agno = 30 - agno = 31 - agno = 32 - agno = 33 - agno = 34 - agno = 35 - agno = 36 - agno = 37 - agno = 38 - agno = 39 - agno = 40 - agno = 41 - agno = 42 - agno = 43 - agno = 44 - agno = 45 - agno = 46 - agno = 47 - agno = 48 - agno = 49 - agno = 50 - agno = 51 - agno = 52 - agno = 53 - agno = 54 - agno = 55 - agno = 56 - agno = 57 - agno = 58 - agno = 59 - agno = 60 - agno = 61 - agno = 62 - agno = 63 - agno = 64 - agno = 65 - agno = 66 - agno = 67 - agno = 68 - agno = 69 - agno = 70 - agno = 71 - agno = 72 - agno = 73 - agno = 74 - agno = 75 - agno = 76 - agno = 77 - agno = 78 - agno = 79 - agno = 80 - agno = 81 - agno = 82 - agno = 83 - agno = 84 - agno = 85 - agno = 86 - agno = 87 - agno = 88 - agno = 89 - agno = 90 - agno = 91 - agno = 92 - agno = 93 - agno = 94 - agno = 95 - agno = 96 - agno = 97 - agno = 98 - agno = 99 - agno = 100 - agno = 101 - agno = 102 - agno = 103 - agno = 104 - agno = 105 - agno = 106 - agno = 107 - agno = 108 - agno = 109 - agno = 110 - agno = 111 - agno = 112 - agno = 113 - agno = 114 - agno = 115 - agno = 116 - agno = 117 - agno = 118 - agno = 119 - agno = 120 - agno = 121 - agno = 122 - agno = 123 - agno = 124 - agno = 125 - agno = 126 - agno = 127 - agno = 128 - agno = 129 - agno = 130 - agno = 131 - agno = 132 - agno = 133 - agno = 134 - agno = 135 - agno = 136 - agno = 137 - agno = 138 - agno = 139 - agno = 140 - agno = 141 - agno = 142 - agno = 143 - agno = 144 - agno = 145 - agno = 146 - agno = 147 - agno = 148 - agno = 149 - agno = 150 - agno = 151 - agno = 152 - agno = 153 - agno = 154 - agno = 155 - agno = 156 - agno = 157 - agno = 158 - agno = 159 - agno = 160 - agno = 161 - agno = 162 - agno = 163 - agno = 164 - agno = 165 - agno = 166 - agno = 167 - agno = 168 - agno = 169 - agno = 170 - agno = 171 - agno = 172 - agno = 173 - agno = 174 - agno = 175 - agno = 176 - agno = 177 - agno = 178 - agno = 179 - agno = 180 - agno = 181 - agno = 182 - agno = 183 - agno = 184 - agno = 185 - agno = 186 - agno = 187 - agno = 188 - agno = 189 - agno = 190 - agno = 191 - agno = 192 - agno = 193 - agno = 194 - agno = 195 - agno = 196 - agno = 197 - agno = 198 - agno = 199 - agno = 200 - agno = 201 - agno = 202 - agno = 203 - agno = 204 - agno = 205 - agno = 206 - agno = 207 - agno = 208 - agno = 209 - agno = 210 - agno = 211 - agno = 212 - agno = 213 - agno = 214 - agno = 215 - agno = 216 - agno = 217 - agno = 218 - agno = 219 - agno = 220 - agno = 221 - agno = 222 - agno = 223 - agno = 224 - agno = 225 - agno = 226 - agno = 227 - agno = 228 - agno = 229 - agno = 230 - agno = 231 - agno = 232 - agno = 233 - agno = 234 - agno = 235 - agno = 236 - agno = 237 - agno = 238 - agno = 239 - agno = 240 - agno = 241 - agno = 242 - agno = 243 - agno = 244 - agno = 245 - agno = 246 - agno = 247 - agno = 248 - agno = 249 - agno = 250 - agno = 251 - agno = 252 - agno = 253 - agno = 254 - agno = 255 - agno = 256 - agno = 257 - agno = 258 - agno = 259 - agno = 260 - agno = 261 - agno = 262 - agno = 263 - agno = 264 - agno = 265 - agno = 266 - agno = 267 - agno = 268 - agno = 269 - agno = 270 - agno = 271 - agno = 272 - agno = 273 - agno = 274 - agno = 275 - agno = 276 - agno = 277 - agno = 278 - agno = 279 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 - agno = 30 - agno = 31 - agno = 32 - agno = 33 - agno = 34 - agno = 35 - agno = 36 - agno = 37 - agno = 38 - agno = 39 - agno = 40 - agno = 41 - agno = 42 - agno = 43 - agno = 44 - agno = 45 - agno = 46 - agno = 47 - agno = 48 - agno = 49 - agno = 50 - agno = 51 - agno = 52 - agno = 53 - agno = 54 - agno = 55 - agno = 56 - agno = 57 - agno = 58 - agno = 59 - agno = 60 - agno = 61 - agno = 62 - agno = 63 - agno = 64 - agno = 65 - agno = 66 - agno = 67 - agno = 68 - agno = 69 - agno = 70 - agno = 71 - agno = 72 - agno = 73 - agno = 74 - agno = 75 - agno = 76 - agno = 77 - agno = 78 - agno = 79 - agno = 80 - agno = 81 - agno = 82 - agno = 83 - agno = 84 - agno = 85 - agno = 86 - agno = 87 - agno = 88 - agno = 89 - agno = 90 - agno = 91 - agno = 92 - agno = 93 - agno = 94 - agno = 95 - agno = 96 - agno = 97 - agno = 98 - agno = 99 - agno = 100 - agno = 101 - agno = 102 - agno = 103 - agno = 104 - agno = 105 - agno = 106 - agno = 107 - agno = 108 - agno = 109 - agno = 110 - agno = 111 - agno = 112 - agno = 113 - agno = 114 - agno = 115 - agno = 116 - agno = 117 - agno = 118 - agno = 119 - agno = 120 - agno = 121 - agno = 122 - agno = 123 - agno = 124 - agno = 125 - agno = 126 - agno = 127 - agno = 128 - agno = 129 - agno = 130 - agno = 131 - agno = 132 - agno = 133 - agno = 134 - agno = 135 - agno = 136 - agno = 137 - agno = 138 - agno = 139 - agno = 140 - agno = 141 - agno = 142 - agno = 143 - agno = 144 - agno = 145 - agno = 146 - agno = 147 - agno = 148 - agno = 149 - agno = 150 - agno = 151 - agno = 152 - agno = 153 - agno = 154 - agno = 155 - agno = 156 - agno = 157 - agno = 158 - agno = 159 - agno = 160 - agno = 161 - agno = 162 - agno = 163 - agno = 164 - agno = 165 - agno = 166 - agno = 167 - agno = 168 - agno = 169 - agno = 170 - agno = 171 - agno = 172 - agno = 173 - agno = 174 - agno = 175 - agno = 176 - agno = 177 - agno = 178 - agno = 179 - agno = 180 - agno = 181 - agno = 182 - agno = 183 - agno = 184 - agno = 185 - agno = 186 - agno = 187 - agno = 188 - agno = 189 - agno = 190 - agno = 191 - agno = 192 - agno = 193 - agno = 194 - agno = 195 - agno = 196 - agno = 197 - agno = 198 - agno = 199 - agno = 200 - agno = 201 - agno = 202 - agno = 203 - agno = 204 - agno = 205 - agno = 206 - agno = 207 - agno = 208 - agno = 209 - agno = 210 - agno = 211 - agno = 212 - agno = 213 - agno = 214 - agno = 215 - agno = 216 - agno = 217 - agno = 218 - agno = 219 - agno = 220 - agno = 221 - agno = 222 - agno = 223 - agno = 224 - agno = 225 - agno = 226 - agno = 227 - agno = 228 - agno = 229 - agno = 230 - agno = 231 - agno = 232 - agno = 233 - agno = 234 - agno = 235 - agno = 236 - agno = 237 - agno = 238 - agno = 239 - agno = 240 - agno = 241 - agno = 242 - agno = 243 - agno = 244 - agno = 245 - agno = 246 - agno = 247 - agno = 248 - agno = 249 - agno = 250 - agno = 251 - agno = 252 - agno = 253 - agno = 254 - agno = 255 - agno = 256 - agno = 257 - agno = 258 - agno = 259 - agno = 260 - agno = 261 - agno = 262 - agno = 263 - agno = 264 - agno = 265 - agno = 266 - agno = 267 - agno = 268 - agno = 269 - agno = 270 - agno = 271 - agno = 272 - agno = 273 - agno = 274 - agno = 275 - agno = 276 - agno = 277 - agno = 278 - agno = 279 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... Note - stripe unit (134217728) and width (671088640) fields have been reset. Please set with mount -o sunit=,swidth= done After running 'xfs_repair /dev/md0', I started mongo.pl again but I took out the mkfs.xfs so that it would start creating files right away. The result was identical to before: xfs_force_shutdown(md(9,0),0x8) called from line 1020 of file xfs_trans.c. Return address = 0xc01ec31e Corruption of in-memory data detected. Shutting down filesystem: md(9,0) Please umount the filesystem, and rectify the problem(s) > Another possibility is this is yet another compiler issue - which > compiler did you build with. kgcc (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) Greetz Marc From owner-linux-xfs@oss.sgi.com Tue Oct 23 15:31:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9NMVve17734 for linux-xfs-outgoing; Tue, 23 Oct 2001 15:31:57 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9NMVrD17712 for ; Tue, 23 Oct 2001 15:31:53 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9NMVlK25114 for ; Tue, 23 Oct 2001 15:31:47 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA3387566; Tue, 23 Oct 2001 17:30:30 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA20722; Tue, 23 Oct 2001 17:30:30 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9NMQtA13064; Tue, 23 Oct 2001 17:26:55 -0500 Message-Id: <200110232226.f9NMQtA13064@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Marc Schmitt cc: Steve Lord , Eric Sandeen , linux-xfs@oss.sgi.com, florin@sgi.com Subject: Re: Corruption of in-memory data detected. In-Reply-To: Message from Marc Schmitt of "Wed, 24 Oct 2001 00:22:40 +0200." <3BD5EDB0.1A238C02@inf.ethz.ch> Date: Tue, 23 Oct 2001 17:26:55 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hi Steve, > > Steve Lord wrote: > > > > Hmm, can you run xfs_repair -n on the filesystem (when unmounted) I > > suspect there is something corrupted in there. You are shutting down > > because xfs is cancelling a transaction which has already modified > > metadata - this does not happen during normal operation. > > Just to remind, mongo.pl always recreates the file system on /dev/md0 > (with 'mkfs.xfs -l size=32768b -f /dev/md0') before it starts creating > files. > Here is the output of 'xfs_repair -n /dev/md0': > OK, that looked pretty toasty - I see this is a pretty big device too, how big ? Can you also send the version of mkfs you are using, and the raid configuration file. I was not aware you were using md until now. Also, how many mongo threads are you running in parallel? The reason I ask this is that you need a recent mkfs command if you are using an fs bigger than 1 Tbyte, the xfs inode can overflow 32 bits if you do not bump the inode size, a recent mkfs will do this automatically. Steve From owner-linux-xfs@oss.sgi.com Tue Oct 23 15:42:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9NMg1a17969 for linux-xfs-outgoing; Tue, 23 Oct 2001 15:42:01 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9NMfuD17945 for ; Tue, 23 Oct 2001 15:41:56 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA09049 for ; Tue, 23 Oct 2001 15:41:57 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA3386979; Tue, 23 Oct 2001 17:40:37 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA70562; Tue, 23 Oct 2001 17:40:36 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9NMb2N13120; Tue, 23 Oct 2001 17:37:02 -0500 Message-Id: <200110232237.f9NMb2N13120@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Marc Schmitt , Eric Sandeen , linux-xfs@oss.sgi.com, florin@sgi.com Subject: Re: Corruption of in-memory data detected. In-Reply-To: Message from Steve Lord of "Tue, 23 Oct 2001 17:26:55 CDT." <200110232226.f9NMQtA13064@jen.americas.sgi.com> Date: Tue, 23 Oct 2001 17:37:02 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk OK, responding to myself, Eric showed me the mkfs output (I need threaded email!) and yes you are over 1 Tbyte, but your inode size has been bumped too, so there should not be an overflow problem behind this. I would still like to see the other info. I do not have anywhere near the amount of disk you have to replicate a similar setup, but I will try a smaller md config on mongo and see if I cannot get a similar corruption here. Steve > > Hi Steve, > > > > Steve Lord wrote: > > > > > > Hmm, can you run xfs_repair -n on the filesystem (when unmounted) I > > > suspect there is something corrupted in there. You are shutting down > > > because xfs is cancelling a transaction which has already modified > > > metadata - this does not happen during normal operation. > > > > Just to remind, mongo.pl always recreates the file system on /dev/md0 > > (with 'mkfs.xfs -l size=32768b -f /dev/md0') before it starts creating > > files. > > Here is the output of 'xfs_repair -n /dev/md0': > > > > OK, that looked pretty toasty - I see this is a pretty big device too, > how big ? Can you also send the version of mkfs you are using, and > the raid configuration file. I was not aware you were using md until > now. Also, how many mongo threads are you running in parallel? > > The reason I ask this is that you need a recent mkfs command if you are > using an fs bigger than 1 Tbyte, the xfs inode can overflow 32 bits if > you do not bump the inode size, a recent mkfs will do this automatically. > > Steve > > > From owner-linux-xfs@oss.sgi.com Tue Oct 23 16:15:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9NNFhD18771 for linux-xfs-outgoing; Tue, 23 Oct 2001 16:15:43 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9NNFbD18749 for ; Tue, 23 Oct 2001 16:15:37 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA24246 for ; Tue, 23 Oct 2001 16:15:31 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id SAA3355762; Tue, 23 Oct 2001 18:14:17 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id SAA74776; Tue, 23 Oct 2001 18:14:17 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9NNAgl14295; Tue, 23 Oct 2001 18:10:42 -0500 Message-Id: <200110232310.f9NNAgl14295@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Marc Schmitt , Eric Sandeen , linux-xfs@oss.sgi.com, florin@sgi.com Subject: Re: Corruption of in-memory data detected. In-Reply-To: Message from Steve Lord of "Tue, 23 Oct 2001 17:37:02 CDT." <200110232237.f9NMb2N13120@jen.americas.sgi.com> Date: Tue, 23 Oct 2001 18:10:42 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk And one final message for the day - having read the original message which answers most of my questions. Can we break the problem down some and see if we can isolate it to md or the 3ware controller. If you just run mongo on one of the 3ware raid5 volumes you have configured without using md at all. I am running on a raid0 config here without problems so far. Thanks Steve > > OK, responding to myself, Eric showed me the mkfs output (I need threaded > email!) and yes you are over 1 Tbyte, but your inode size has been bumped > too, so there should not be an overflow problem behind this. I would still > like to see the other info. I do not have anywhere near the amount of disk > you have to replicate a similar setup, but I will try a smaller md config > on mongo and see if I cannot get a similar corruption here. > > Steve > > > > Hi Steve, > > > > > > Steve Lord wrote: > > > > > > > > Hmm, can you run xfs_repair -n on the filesystem (when unmounted) I > > > > suspect there is something corrupted in there. You are shutting down > > > > because xfs is cancelling a transaction which has already modified > > > > metadata - this does not happen during normal operation. > > > > > > Just to remind, mongo.pl always recreates the file system on /dev/md0 > > > (with 'mkfs.xfs -l size=32768b -f /dev/md0') before it starts creating > > > files. > > > Here is the output of 'xfs_repair -n /dev/md0': > > > > > > > OK, that looked pretty toasty - I see this is a pretty big device too, > > how big ? Can you also send the version of mkfs you are using, and > > the raid configuration file. I was not aware you were using md until > > now. Also, how many mongo threads are you running in parallel? > > > > The reason I ask this is that you need a recent mkfs command if you are > > using an fs bigger than 1 Tbyte, the xfs inode can overflow 32 bits if > > you do not bump the inode size, a recent mkfs will do this automatically. > > > > Steve > > > > > > > From owner-linux-xfs@oss.sgi.com Tue Oct 23 16:47:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9NNljU19364 for linux-xfs-outgoing; Tue, 23 Oct 2001 16:47:45 -0700 Received: from iris.slb.nwc.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9NNlcD19341 for ; Tue, 23 Oct 2001 16:47:38 -0700 Received: from erbenson.alaska.net (145-pm15.nwc.alaska.net [209.112.141.145]) by iris.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id f9NNlZX69565 for ; Tue, 23 Oct 2001 15:47:35 -0800 (AKDT) (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 0FCDF3927 for ; Tue, 23 Oct 2001 15:47:34 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 1FE2F10262; Tue, 23 Oct 2001 15:47:34 -0800 (AKDT) Date: Tue, 23 Oct 2001 15:47:34 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: possible to reserve space for superuser ? Message-ID: <20011023154734.O4785@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200110231924.f9NJOjG12615@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="egxrhndXibJAPJ54" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200110231924.f9NJOjG12615@jen.americas.sgi.com>; from lord@sgi.com on Tue, Oct 23, 2001 at 02:24:45PM -0500 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --egxrhndXibJAPJ54 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 23, 2001 at 02:24:45PM -0500, Steve Lord wrote: > > Hi there, > >=20 > > is it possible to reserve partition space for the superuser ? ("good ol= d" > > ext2 can handle this) > > I did4n4t find anything usefull about this in the Docs, so post to you ! > >=20 > > Can Quota be a solution for my problem ? > >=20 > > thank you, > > Christian Guggenberger >=20 > Not simply, it was not a concept built into the original xfs design, > so it would take some surgery - and the concept of a super user is not > as simple as it used to be, this would probably be based on some > capability (OK, thats a minor implementation detail). well to clarify things. ext2 is not reserving space for the superuser at all, it simply reserves a certain number of blocks (by default 5% of the filesystem, set at mkfs time) for a certain uid and gid, the default is 0 0, which under most traditional systems happens to be the superuser. =20 under ext2 you can just as easily give this reserved space away to any user, or a group of users. man tune2fs. > Quotas could do it - but only by restricting everone else on the=20 > filesystem to a total less than the fs size. semi inconvenient, but if your adduser allows hooks (like debian's) its not that difficult to automate. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --egxrhndXibJAPJ54 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 iEYEARECAAYFAjvWAZUACgkQJKx7GixEevwRfQCcCWrJC90GSfIHegp4HbYZxwiz ruQAnRl/jukmygp8o0NMmg/N/JTrug7O =AZGc -----END PGP SIGNATURE----- --egxrhndXibJAPJ54-- From owner-linux-xfs@oss.sgi.com Tue Oct 23 18:42:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9O1ghf21907 for linux-xfs-outgoing; Tue, 23 Oct 2001 18:42:43 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9O1gdD21885 for ; Tue, 23 Oct 2001 18:42:39 -0700 Received: from relay1.corp.sgi.com (corp.sgi.com [198.29.75.13]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA06172 for ; Tue, 23 Oct 2001 18:42:35 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id SAA74152 for ; Tue, 23 Oct 2001 18:42:01 -0700 (PDT) Message-ID: <3BD61B95.84135557@sgi.com> Date: Tue, 23 Oct 2001 20:38:29 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: For Testing - updated RH7.1 XFS 2.4.9-6 kernels References: <3BD57010.7C8EF680@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk New and improved, for your testing pleasure, may I introduce the next revision of the aforementioned test kernels... ftp://oss.sgi.com/projects/xfs/download/testing/RH2.4.9-6 Changes: * LVM now compiles (!) & updated to 1.0.1rc4, module included in binary RPMs. (Thanks Martin!) * bcm5820 & intermezzo unresolved symbols fixed * kernel-source package fixed (includes linux/kdb files) Again, these are for testing - they've been sanity-checked, but back up that data! -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Oct 23 19:52:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9O2qI323452 for linux-xfs-outgoing; Tue, 23 Oct 2001 19:52:18 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9O2qFD23430 for ; Tue, 23 Oct 2001 19:52:15 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA04262 for ; Tue, 23 Oct 2001 19:51:31 -0700 (PDT) mail_from (kaos@melbourne.sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by nodin.corp.sgi.com (8.11.4/8.11.2/nodin-1.0) with ESMTP id f9O2pDC7009458 for ; Tue, 23 Oct 2001 19:51:14 -0700 (PDT) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 0B17B300095; Wed, 24 Oct 2001 12:51:11 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id CCC1598 for ; Wed, 24 Oct 2001 12:51:11 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: linux-xfs@oss.sgi.com Subject: Re: For Testing - updated RH7.1 XFS 2.4.9-6 kernels In-reply-to: Your message of "Tue, 23 Oct 2001 20:38:29 EST." <3BD61B95.84135557@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Oct 2001 12:51:06 +1000 Message-ID: <12021.1003891866@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 23 Oct 2001 20:38:29 -0500, Eric Sandeen wrote: >New and improved, for your testing pleasure, may I introduce the next >revision of the aforementioned test kernels... > >ftp://oss.sgi.com/projects/xfs/download/testing/RH2.4.9-6 > >Changes: > >* LVM now compiles (!) & updated to 1.0.1rc4, module > included in binary RPMs. (Thanks Martin!) Are there any plans to upgrade LVM in the main XFS tree? From owner-linux-xfs@oss.sgi.com Tue Oct 23 23:23:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9O6NFC28245 for linux-xfs-outgoing; Tue, 23 Oct 2001 23:23:15 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9O6NBD28223 for ; Tue, 23 Oct 2001 23:23:11 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id IAA02432 for ; Wed, 24 Oct 2001 08:23:10 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id IAA05947 for linux-xfs@oss.sgi.com; Wed, 24 Oct 2001 08:23:09 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 377A957306 for ; Wed, 24 Oct 2001 08:22:15 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id CD01625835 for ; Wed, 24 Oct 2001 08:22:14 +0200 (CEST) Message-ID: <3BD65E16.A2B56384@ch.sauter-bc.com> Date: Wed, 24 Oct 2001 08:22:14 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: linux-xfs Subject: Updated mkinitrd RPMs Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Since Redhat has released new mkinitrd packages, I have updated my 'XFS installer enabled' version. It should work with root on softraid with devfs enabled (was default with the 1.0 installer). This is something the redhat initrd is not able to do. Find it here: http://home.datacomm.ch/simix/XFS/ BTW, sorry, I was not able to test it! Will do it tonight. -Simon From owner-linux-xfs@oss.sgi.com Wed Oct 24 00:31:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9O7Vlu30398 for linux-xfs-outgoing; Wed, 24 Oct 2001 00:31:47 -0700 Received: from due.stud.ntnu.no (due.stud.ntnu.no [129.241.56.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9O7ViD30374 for ; Wed, 24 Oct 2001 00:31:44 -0700 Received: from gaupe.stud.ntnu.no (gaupe.stud.ntnu.no [129.241.56.184]) by due.stud.ntnu.no (Postfix) with ESMTP id BE7CF17AF7; Wed, 24 Oct 2001 09:31:43 +0200 (CEST) Received: from localhost (sebastid@localhost) by gaupe.stud.ntnu.no (8.11.6/8.10.0.Beta12) with ESMTP id f9O7VPf29819; Wed, 24 Oct 2001 09:31:25 +0200 X-Authentication-Warning: gaupe.stud.ntnu.no: sebastid owned process doing -bs Date: Wed, 24 Oct 2001 09:31:25 +0200 (CEST) From: Sebastian Dransfeld To: Jordi Mallach Cc: Eric Sandeen , Subject: Re: About the -ac branch In-Reply-To: <20011024001010.B14709@nubol.oskuro.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 24 Oct 2001, Jordi Mallach wrote: > On Tue, Oct 23, 2001 at 11:28:12PM +0200, Sebastian Dransfeld wrote: > > And, as previously mentioned, check the Mandrake cooker kernels. > > Hm. We're poor Debian people. I think "cooker" is what "sid" or > "unstable" is in our distribution, but browsing the web I only found RPM > mirrors, not SRPM's, and then, I see "kernel" and "kernel-linus" > packages. The latter I guess it's pristine Linus tree, and the first one > must be Mandrake's custom kernel, which I have no clue if it's based on > -ac or not. cooker is Mandrake unstable. Check ftp://sunsite.uio.no/pub/linux/Mandrake-devel/cooker/SRPMS The normal kernel-packages are based on -ac, the latest 2.4.12-ac5. seb From owner-linux-xfs@oss.sgi.com Wed Oct 24 01:08:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9O88kA31470 for linux-xfs-outgoing; Wed, 24 Oct 2001 01:08:46 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9O87gD31438 for ; Wed, 24 Oct 2001 01:07:42 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id BAA00225 for ; Wed, 24 Oct 2001 01:07:36 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) 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 SAA29816; Wed, 24 Oct 2001 18:05:43 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id TAA44576; Wed, 24 Oct 2001 19:05:21 +1100 (AEDT) Date: Wed, 24 Oct 2001 19:05:21 +1100 From: Nathan Scott To: John Trostel , Buchan Milne , Sylvestre Taburet Cc: linux-xfs@oss.sgi.com Subject: Re: Samba 2.2.2 and XFS quotas Message-ID: <20011024190521.M563765@wobbly.melbourne.sgi.com> References: <2.1-439792-249-D-OEWW@mail.mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <2.1-439792-249-D-OEWW@mail.mindspring.com>; from jtrostel@mindspring.com on Mon, Oct 22, 2001 at 10:21:44PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Mon, Oct 22, 2001 at 10:21:44PM -0500, John Trostel wrote: > > I took a quick look at the patch today. There seem to be some reasonably > large changes between quota.c in 2.2.1a & 2.2.2. I'll probably be able > to work a bit at it but will likely be asking about for helpful hints. > To try to help out, I've attached a 2.2.2 patch which is probably the sort of approach the Samba people will be looking for here. As I don't have a clue on how to exercise this code, it is completely untested. If you are lucky, it may even compile. ;-) Its actually got alot simpler this time, with those changes you've foreshadowed, John, as the 2.4.x quota snarfoo is sorted out now in smbd/quota.c (see Jeremy's comment in that file, about the spot where this change is), and it turned out that this makes things a whole lot easier for us. Hope this helps. cheers. -- Nathan > >> Sylvestre Taburet and I are working on updates to samba-2.2.2 for > >> Mandrake 8.1. Since Mandrake 8.1 shipped with XFS, we would like to keep > >> working samba/XFS/quotas. > > > > Excellent. This really needs someone with a vested interest > > to follow it up and push the changes to the Samba folk. > > > >> In the package of samba-2.2.1a, we applied > >> the patch by Nathan Scott: > >> (http://marc.theaimsgroup.com/?l=linux-xfs&m=100002981924172&w=2). > > > > Caveat - I have had one report that this patch does not work. > > As I said originally, it is a patch which shows the sort of > > changes that are needed, but it is untested as I know very > > little about Samba & how to go about testing this. > > > >> We have forwarded the patch to samba developers, but they would prefer a > >> patch against current CVS tag SAMBA_2_2. > > > > It will need to be tested and fixed first, by the sound of it. > > > ... Snip... > > Thanks for pushing this - if some other developer out there can > > take a shot at fixing the original patch, I could certainly look > > over their new patch and cross-check the XFS quota side of things > > for them. > John M. Trostel > jtrostel@mindspring.com diff -Naur samba-2.2.2/source/configure.in samba-2.2.2+ns/source/configure.in --- samba-2.2.2/source/configure.in Sun Oct 14 07:09:16 2001 +++ samba-2.2.2+ns/source/configure.in Wed Oct 24 17:43:19 2001 @@ -383,6 +383,9 @@ # For quotas on Veritas VxFS filesystems AC_CHECK_HEADERS(sys/fs/vx_quota.h) +# For quotas on Linux XFS filesystems +AC_CHECK_HEADERS(linux/xqm.h) + AC_CHECK_SIZEOF(int,cross) AC_CHECK_SIZEOF(long,cross) AC_CHECK_SIZEOF(short,cross) diff -Naur samba-2.2.2/source/include/config.h.in samba-2.2.2+ns/source/include/config.h.in --- samba-2.2.2/source/include/config.h.in Sun Oct 14 07:09:21 2001 +++ samba-2.2.2+ns/source/include/config.h.in Wed Oct 24 17:41:05 2001 @@ -903,6 +903,9 @@ /* Define if you have the header file. */ #undef HAVE_SYS_FS_VX_QUOTA_H +/* Define if you have the header file. */ +#undef HAVE_LINUX_XQM_H + /* Define if you have the header file. */ #undef HAVE_SYS_ID_H diff -Naur samba-2.2.2/source/smbd/quotas.c samba-2.2.2+ns/source/smbd/quotas.c --- samba-2.2.2/source/smbd/quotas.c Sun Oct 14 07:09:41 2001 +++ samba-2.2.2+ns/source/smbd/quotas.c Wed Oct 24 17:42:15 2001 @@ -57,6 +57,9 @@ */ #include +#ifdef HAVE_LINUX_XQM_H +#include +#endif #include #include @@ -75,10 +78,35 @@ } LINUX_SMB_DISK_QUOTA; /**************************************************************************** + Abstract out the XFS Quota Manager quota get call. +****************************************************************************/ + +static int get_smb_linux_xfs_quota(char *path, uid_t euser_id, LINUX_SMB_DISK_QUOTA *dp) +{ + int ret = -1; +#ifdef HAVE_LINUX_XQM_H + struct fs_disk_quota D; + ZERO_STRUCT(D); + + if ((ret = quotactl(QCMD(Q_XGETQUOTA,USRQUOTA), path, euser_id, (caddr_t)&D))) + return ret; + + dp->bsize = (SMB_BIG_UINT)512; + dp->softlimit = (SMB_BIG_UINT)D.d_blk_softlimit; + dp->hardlimit = (SMB_BIG_UINT)D.d_blk_hardlimit; + dp->ihardlimit = (SMB_BIG_UINT)D.d_ino_hardlimit; + dp->isoftlimit = (SMB_BIG_UINT)D.d_ino_softlimit; + dp->curinodes = (SMB_BIG_UINT)D.d_icount; + dp->curblocks = (SMB_BIG_UINT)D.d_bcount; +#endif + return ret; +} + +/**************************************************************************** Abstract out the old and new Linux quota get calls. ****************************************************************************/ -static int get_smb_linux_quota(char *path, uid_t euser_id, LINUX_SMB_DISK_QUOTA *dp) +static int get_smb_linux_vfs_quota(char *path, uid_t euser_id, LINUX_SMB_DISK_QUOTA *dp) { int ret; #ifdef LINUX_QUOTAS_1 @@ -156,7 +184,10 @@ save_re_uid(); set_effective_uid(0); - r=get_smb_linux_quota(mnt->mnt_fsname, euser_id, &D); + if (strcmp(mnt->mnt_type, "xfs") == 0) + r=get_smb_linux_xfs_quota(mnt->mnt_fsname, euser_id, &D); + else + r=get_smb_linux_vfs_quota(mnt->mnt_fsname, euser_id, &D); restore_re_uid(); /* Use softlimit to determine disk space, except when it has been exceeded */ From owner-linux-xfs@oss.sgi.com Wed Oct 24 01:43:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9O8hYM32169 for linux-xfs-outgoing; Wed, 24 Oct 2001 01:43:34 -0700 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9O8hTD32147 for ; Wed, 24 Oct 2001 01:43:29 -0700 Received: from inf.ethz.ch (IDENT:schmitt@ikarus.inf.ethz.ch [129.132.10.58]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id KAA00421; Wed, 24 Oct 2001 10:43:19 +0200 (MET DST) Message-ID: <3BD67F29.4040009@inf.ethz.ch> Date: Wed, 24 Oct 2001 10:43:21 +0200 From: Marc Schmitt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Steve Lord CC: Eric Sandeen , linux-xfs@oss.sgi.com, florin@sgi.com Subject: Re: Corruption of in-memory data detected. References: <200110232226.f9NMQtA13064@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > OK, that looked pretty toasty - I see this is a pretty big device too, > how big ? Can you also send the version of mkfs you are using, and > the raid configuration file. I was not aware you were using md until > now. Also, how many mongo threads are you running in parallel? > > The reason I ask this is that you need a recent mkfs command if you are > using an fs bigger than 1 Tbyte, the xfs inode can overflow 32 bits if > you do not bump the inode size, a recent mkfs will do this automatically. > > Steve - Size is 1.2TB (5 x (RAID 5 with 4 x 80GB disks)) - mkfs.xfs version 1.3.7 - /etc/raidtab: raiddev /dev/md0 raid-level 0 nr-raid-disks 5 nr-spare-disks 0 persistent-superblock 1 chunk-size 32 device /dev/sdb1 raid-disk 0 device /dev/sdc1 raid-disk 1 device /dev/sdd1 raid-disk 2 device /dev/sde1 raid-disk 3 device /dev/sdf1 raid-disk 4 - 1 mongo thread From owner-linux-xfs@oss.sgi.com Wed Oct 24 01:49:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9O8nau32505 for linux-xfs-outgoing; Wed, 24 Oct 2001 01:49:36 -0700 Received: from zamok.crans.org (zamok.crans.org [138.231.136.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9O8nXD32474 for ; Wed, 24 Oct 2001 01:49:33 -0700 Received: from lucas.loria (lucas.crans.org [138.231.141.26]) by zamok.crans.org (Postfix) with ESMTP id D59F3DBD for ; Wed, 24 Oct 2001 10:49:23 +0200 (CEST) Received: from neo.loria (neo.loria [10.0.0.3]) by lucas.loria (Postfix) with ESMTP id E7407A66D for ; Wed, 24 Oct 2001 10:49:41 +0200 (CEST) Received: by neo.loria (Postfix, from userid 500) id 72405A0F3F; Wed, 24 Oct 2001 10:49:42 +0200 (CEST) To: linux-xfs@oss.sgi.com Subject: Is restore FS-independant ? X-PGP-KeyID: 0xF22A794E X-PGP-Fingerprint: 5854 AF2B 65B2 0E96 2161 E32B 285B D7A1 F22A 794E From: Vincent Bernat Organization: Kabale Inc Date: Wed, 24 Oct 2001 10:49:41 +0200 Message-ID: Lines: 7 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.4 (Artificial Intelligence, i686-pc-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi ! I would like to know if xfsrestore can be issued on a file system which is not XFS and which doesn't have all the possibilities of it ? -- BOFH excuse #130: new management From owner-linux-xfs@oss.sgi.com Wed Oct 24 01:49:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9O8nhp32551 for linux-xfs-outgoing; Wed, 24 Oct 2001 01:49:43 -0700 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9O8ndD32529 for ; Wed, 24 Oct 2001 01:49:40 -0700 Received: from inf.ethz.ch (IDENT:schmitt@ikarus.inf.ethz.ch [129.132.10.58]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id KAA00854; Wed, 24 Oct 2001 10:49:31 +0200 (MET DST) Message-ID: <3BD6809E.40204@inf.ethz.ch> Date: Wed, 24 Oct 2001 10:49:34 +0200 From: Marc Schmitt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Steve Lord CC: Eric Sandeen , linux-xfs@oss.sgi.com, florin@sgi.com Subject: Re: Corruption of in-memory data detected. References: <200110232310.f9NNAgl14295@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: > If you just run mongo on one of the 3ware raid5 volumes you have configured > without using md at all. I am running on a raid0 config here without > problems so far. As I wrote at the bottom of the initial message, running mongo over /dev/sdb1 (for example) runs flawlessly. Greetz Marc From owner-linux-xfs@oss.sgi.com Wed Oct 24 01:50:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9O8oNC32604 for linux-xfs-outgoing; Wed, 24 Oct 2001 01:50:23 -0700 Received: from mandrakesoft.mandrakesoft.com (mandrakesoft.mandrakesoft.com [216.71.84.35]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9O8oJD32582 for ; Wed, 24 Oct 2001 01:50:19 -0700 Received: from there (office [195.68.114.34]) by mandrakesoft.mandrakesoft.com (8.8.5/8.8.5) with SMTP id DAA14575; Wed, 24 Oct 2001 03:39:02 -0500 Message-Id: <200110240839.DAA14575@mandrakesoft.mandrakesoft.com> Content-Type: text/plain; charset="iso-8859-1" From: Sylvestre Taburet Reply-To: staburet@mandrakesoft.com Organization: Mandrakesoft To: Nathan Scott , John Trostel , Buchan Milne Subject: Re: Samba 2.2.2 and XFS quotas Date: Wed, 24 Oct 2001 10:39:02 +0200 X-Mailer: KMail [version 1.3.1] Cc: linux-xfs@oss.sgi.com References: <2.1-439792-249-D-OEWW@mail.mindspring.com> <20011024190521.M563765@wobbly.melbourne.sgi.com> In-Reply-To: <20011024190521.M563765@wobbly.melbourne.sgi.com> MIME-Version: 1.0 X-MIME-Autoconverted: from 8bit to quoted-printable by mandrakesoft.mandrakesoft.com id DAA14575 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f9O8oJD32583 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Le Mercredi 24 Octobre 2001 10:05, Nathan Scott a écrit : > hi, > > On Mon, Oct 22, 2001 at 10:21:44PM -0500, John Trostel wrote: > > I took a quick look at the patch today. There seem to be some reasonably > > large changes between quota.c in 2.2.1a & 2.2.2. I'll probably be able > > to work a bit at it but will likely be asking about for helpful hints. > > To try to help out, I've attached a 2.2.2 patch which is probably the > sort of approach the Samba people will be looking for here. As I don't > have a clue on how to exercise this code, it is completely untested. > If you are lucky, it may even compile. ;-) > > Its actually got alot simpler this time, with those changes you've > foreshadowed, John, as the 2.4.x quota snarfoo is sorted out now in > smbd/quota.c (see Jeremy's comment in that file, about the spot where > this change is), and it turned out that this makes things a whole lot > easier for us. > > Hope this helps. > > cheers. Thanks Nathan and John, Yes the samba team rewrote quota.c a bit. I will try compilng and testing the new patch later this afternoon. Cheers, Sylvestre -- Sylvestre Taburet - MandrakeConsulting Mandrakesoft S.A. - 43, rue d'Aboukir, 75002 Paris - FRANCE +33 (1) 40 41 00 41 - http://www.linux-mandrake.com From owner-linux-xfs@oss.sgi.com Wed Oct 24 02:37:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9O9bVJ02270 for linux-xfs-outgoing; Wed, 24 Oct 2001 02:37:31 -0700 Received: from mailout03.sul.t-online.de (mailout03.sul.t-online.com [194.25.134.81]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9O9bND02241 for ; Wed, 24 Oct 2001 02:37:23 -0700 Received: from fwd04.sul.t-online.de by mailout03.sul.t-online.de with smtp id 15wKTR-0006UG-0A; Wed, 24 Oct 2001 11:37:21 +0200 Received: from ernie.sesamstrasse.de (520083570599-0001@[62.226.179.211]) by fmrl04.sul.t-online.com with esmtp id 15wKTI-13umrQC; Wed, 24 Oct 2001 11:37:12 +0200 Received: (from root@localhost) by ernie.sesamstrasse.de (8.9.3/8.9.3/Debian 8.9.3-21) id LAA21252 for linux-xfs@oss.sgi.com; Wed, 24 Oct 2001 11:33:45 +0200 Received: from kruemelmonster (kruemelmonster.sesamstrasse.de [192.168.2.104]) by ernie.sesamstrasse.de (AvMailGate-6.8.0.0) id 21247-1A37B596; Wed, 24 Oct 2001 11:33:40 +0200 From: "=?iso-8859-1?B?SvZyZyBI5G5zZWw=?=" To: Subject: Problems with samba 2.2.2 Date: Wed, 24 Oct 2001 11:33:39 +0200 Message-ID: <000101c15c6e$f69f2f70$6802a8c0@sesamstrasse.de> 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 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-AntiVirus: OK (checked by AntiVir Version 6.8.0.3) X-Sender: 520083570599-0001@t-dialin.net Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I'm running samba 2.2.2 on a Linux Debian Woody System and encountered some problems. First of all my settings: Linux 2.4.12 SMP + XFS + ACL Patch libc6 2.2.4-3 gcc-2.95 2.95.4-0.01100 acl, acl-dev 1.1.3-0 xfsprogs, xfslibs-dev 1.3.5-0 I rebuilt the packages acl, acl-dev from oss.sgi.com and samba as debian packages. The ACLs and XFS seem work fine and pretty fast. I built 4 different version of samba for testing (the filename describes the additional configure options): samba_2.2.2-1_i386.deb samba_2.2.2-acl-1_i386.deb samba_2.2.2-acl-ssl-1_i386.deb samba_2.2.2-ssl-1_i386.deb On all versions of samba the following problems occured: Groupmemberships ignored: ------------------------- The users on my server are members of different groups. The primary group is the userid itself (debian like). There is a specil group calles "smbdomadm" which decides whether a domain user has admin rights or not. When I am logging in from a Windows NT Client the following message appears in "log.smb": 4 user groups: 1001 10010 20000 22000 Group 10010 is "smbdomadm". But after logging in the user doesn't have admin rights. The "User manager for domains" says: User XXX has primary group 1001 and is member of users which has gid 100 and is not right. So samba seems to ignore the group memberships and the "domain admin group" in smb.conf. By the way I tried to reduce the membership of user XXX to 1001 (primary) and 10010 (other) but nothing changed. ACLs do not work: ----------------- When I use the ACL capable versions of samba the file security dialog under Windows NT does not show the correct ACLs. I use Default ACLs. Perhaps this causes problems under windows NT. There are more problems I encounterd. But I think they are not the reason for the ones I wrote about . Thanks a lot for your help (I hope so), Joerg P.S.: Sorry for my english. (END) From owner-linux-xfs@oss.sgi.com Wed Oct 24 02:56:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9O9uF903107 for linux-xfs-outgoing; Wed, 24 Oct 2001 02:56:15 -0700 Received: from linux.nameip.net ([211.187.6.46]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9O9uBD03082 for ; Wed, 24 Oct 2001 02:56:11 -0700 Received: (qmail 1268 invoked from network); 24 Oct 2001 10:01:01 -0000 Received: from unknown (HELO orgio.net) (211.187.6.46) by 0 with SMTP; 24 Oct 2001 10:01:01 -0000 Message-ID: <3BD6915D.6060808@orgio.net> Date: Wed, 24 Oct 2001 19:01:01 +0900 From: Seung-young Oh User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010816 X-Accept-Language: ko MIME-Version: 1.0 To: Simon Matter CC: linux-xfs Subject: Re: Updated mkinitrd RPMs References: <3BD65E16.A2B56384@ch.sauter-bc.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Simon Matter wrote: > Hi > > Since Redhat has released new mkinitrd packages, I have updated my 'XFS > installer enabled' version. It should work with root on softraid with > devfs enabled (was default with the 1.0 installer). This is something > the redhat initrd is not able to do. > Find it here: > > http://home.datacomm.ch/simix/XFS/ > > BTW, sorry, I was not able to test it! Will do it tonight. > > -Simon > > > Hello, Do I need to update the mkbootdisk and install the jftpgw as well? -- ICQ#: 103231199 From owner-linux-xfs@oss.sgi.com Wed Oct 24 02:59:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9O9x4603252 for linux-xfs-outgoing; Wed, 24 Oct 2001 02:59:04 -0700 Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9O9x1D03229 for ; Wed, 24 Oct 2001 02:59:01 -0700 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.6/8.11.6) with ESMTP id f9O9wr120565; Wed, 24 Oct 2001 05:58:53 -0400 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Wed, 24 Oct 2001 05:58:53 -0400 (EDT) From: Joshua Baker-LePain X-X-Sender: To: Eric Sandeen cc: Subject: Re: For Testing - updated RH7.1 XFS 2.4.9-6 kernels In-Reply-To: <3BD61B95.84135557@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 23 Oct 2001 at 8:38pm, Eric Sandeen wrote > Changes: > > * LVM now compiles (!) & updated to 1.0.1rc4, module > included in binary RPMs. (Thanks Martin!) > > * bcm5820 & intermezzo unresolved symbols fixed > > * kernel-source package fixed (includes linux/kdb files) Does it/will it include the fix for the NFS locking issues which have been reported? -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Wed Oct 24 04:41:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OBf9006758 for linux-xfs-outgoing; Wed, 24 Oct 2001 04:41:09 -0700 Received: from porgy.srv.nld.sonera.net (mbox-01.soneraplaza.nl [195.66.15.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OBf5D06736 for ; Wed, 24 Oct 2001 04:41:05 -0700 Received: from qn-213-73-192-55.quicknet.nl ([213.73.192.55]:61064 "EHLO et.schoenmakerstraat.org") by soneramail.nl with ESMTP id ; Wed, 24 Oct 2001 13:40:05 +0200 Received: from localhost ([127.0.0.1] helo=dds.nl) by et.schoenmakerstraat.org with esmtp (Exim 3.12 #1 (Debian)) id 15wMQv-00014W-00 for ; Wed, 24 Oct 2001 13:42:53 +0200 Message-ID: <3BD6A93D.AC5545B9@dds.nl> Date: Wed, 24 Oct 2001 13:42:53 +0200 From: Ries van twisk Reply-To: rvt@dds.nl X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9 i586) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: [OT] Disk Editor Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi All, I know this is off topic but I'm looking for a disk editor on Linux. One off my Fat32 hard drivers (dual boot) was erased while installing a anti virus scanner. I tried hexedit but that seg faults every now and then and I can't do length searches. Also I tried lde but I didn't find a search function in it. Hope one of you can help me out. Ries From owner-linux-xfs@oss.sgi.com Wed Oct 24 05:15:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OCFCt07691 for linux-xfs-outgoing; Wed, 24 Oct 2001 05:15:12 -0700 Received: from seralph5.essex.ac.uk (seralph5.essex.ac.uk [155.245.240.155]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OCF6D07661 for ; Wed, 24 Oct 2001 05:15:06 -0700 Received: from sernt14.essex.ac.uk ([155.245.240.183]) by seralph5.essex.ac.uk with esmtp (Exim 3.13 #1) id 15wMw0-0007Er-00 for linux-xfs@oss.sgi.com; Wed, 24 Oct 2001 13:15:00 +0100 Received: by sernt14.essex.ac.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Oct 2001 13:10:59 +0100 Message-ID: <7AC902A40BEDD411A3A800D0B7847B6608854B@sernt14.essex.ac.uk> From: "Giddings, Bret" To: linux-xfs@oss.sgi.com Subject: Problems with network kickstart install Date: Wed, 24 Oct 2001 13:10:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I am trying to get an XFS system installed by using a kickstart file on a floppy and an install location on an FTP server. This works fine with a vanilla RH7.1 distribution but fails when using the SGI provided ISO image. The install seems to proceed normally until it gets to the post-install phase at which point it prints the error message install exited abnormally - received signal 11 If I use essentially the same kickstart file but specify the installation mechanism as cdrom then everything is fine (bar having to swap CDs and watch the progress). If I boot into rescue mode from the XFS cd then no installation is found. However, mounting the partitions by hand from terminal 2 does work and curiously, the /boot partition doesn't have a kernel or other crucial files (although the other partitions are fine), so I am guessing that it is something here that is failing. Has anyone else come across this problem and solved it. Further details. In both cases, booting from CD using linux ks=floppy Kickstart file contains an FTP URL as the installation method. It also specifies the machines network settings. The stage1 and stage2 images are successfully loaded off the network and my custom 168 packages as specified in the kickstart file do get transferred. I built the FTP archive by a) taking a copy of my working 'standard' RH7.1 area (includes disk1 and disk2 RPMs). b) copied contents of XFS cd over the top of this area thus over-writing things like the .img files and the comps and hdlist files. Regards, Bret -- Bret Giddings, Systems Manager, Computing Service, University of Essex Tel: (01206) 872577 Email: bret@essex.ac.uk Fax: (01206) 860585 From owner-linux-xfs@oss.sgi.com Wed Oct 24 05:57:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OCvXi08713 for linux-xfs-outgoing; Wed, 24 Oct 2001 05:57:33 -0700 Received: from umbi3.umbi.umd.edu (umbi3.umbi.umd.edu [136.160.7.51]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OCvCD08681 for ; Wed, 24 Oct 2001 05:57:12 -0700 Received: from umbi.umd.edu (mystery.carb.nist.gov [129.6.113.182]) by umbi3.umbi.umd.edu (Netscape Messaging Server 4.15) with ESMTP id GLPNZA00.TG4; Wed, 24 Oct 2001 08:57:10 -0400 Message-ID: <3BD6BA99.4CAE0D71@umbi.umd.edu> Date: Wed, 24 Oct 2001 08:56:57 -0400 From: Jonathan Dill Organization: CARB X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-6SGI_XFS_PR1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Marc Schmitt CC: Steve Lord , Eric Sandeen , linux-xfs@oss.sgi.com, florin@sgi.com Subject: Re: Corruption of in-memory data detected. References: <200110232310.f9NNAgl14295@jen.americas.sgi.com> <3BD6809E.40204@inf.ethz.ch> Content-Type: multipart/mixed; boundary="------------8D5B87496141DA5BD63B7EAF" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------8D5B87496141DA5BD63B7EAF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi guys, I just managed to get this error and severe fs corruption without RAID, mongo, huge filesystem, or anything weird. (BTW I'm a bleeding edge kind of guy, so the fs wasn't critical and I've got backups :-). This was with the kernel-2.4.9-6SGI_XFS_PR1, and I'm not using any of the modules that had symbol problems. Initially, I was trying to xfsdump and gzip a whole filesystem to an xfs on another disk and I got "file size limit exceeded" and "core dumped." So I said, "OK so what's the max filesize?" I thought it was pretty high for XFS, but apparently not for Linux XFS--I was backing up a ~6 GB partition, so the file size had to be less than that. I didn't find any clues in a cursory glance at xfs.h, so I decided to test it in a not-so-nice way: dd if=/dev/zero of=test_size.img bs=10240k The process choked and this is what turned up in the system log: Oct 24 07:47:08 localhost kernel: xfs_force_shutdown(ide1(22,65),0x8) called from line 1120 of file xfs_trans.c. Return address = 0xc01ca409 Oct 24 07:47:08 localhost kernel: Corruption of in-memory data detected. Shutting down filesystem: ide1(22,65) Oct 24 07:47:08 localhost kernel: Please umount the filesystem, and rectify the problem(s) When I tried to mount the disk again, I got this error: Oct 24 07:47:30 localhost kernel: XFS: bad magic number Oct 24 07:47:30 localhost kernel: XFS: SB validate failed xfs_repair had to search for quite awhile to find a good alternate SB. I attached the log of xfs_repair so you can see I did a capital job of trashing the FS :-) Later, I'll try it again to see if I can reproduce the problem, then again with the newer 2.4.9 kernel. -- "Jonathan F. Dill" (dill@umbi.umd.edu) --------------8D5B87496141DA5BD63B7EAF Content-Type: text/plain; charset=iso-8859-1; name="xfs_repair.log" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="xfs_repair.log" [root@localhost ~]# mount /trans mount: wrong fs type, bad option, bad superblock on /dev/hdd1, or too many mounted file systems [root@localhost ~]# xfs_repair /dev/hdd1 xfs_repair: warning - cannot set blocksize on block device /dev/hdd1: Inp= ut/output error Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock... =2E......................................................................= =2E......................................................................= =2E......................................................................= =2E......................................................................= =2E......................................................................= =2E......................................................................= =2E......................................................................= =2E......................................................................= =2E......................................................................= =2E......................................................................= =2E......................................................................= =2E......................................................................= =2E......................................................................= =2E......................................................................= =2E..............found candidate secondary superblock... verified secondary superblock... writing modified primary superblock sb root inode value 18446744073709551615 inconsistent with calculated val= ue 13835049396628095104 resetting superblock root inode pointer to 18446744069414584448 sb realtime bitmap inode 18446744073709551615 inconsistent with calculate= d value 13835049396628095105 resetting superblock realtime bitmap ino pointer to 18446744069414584449 sb realtime summary inode 18446744073709551615 inconsistent with calculat= ed value 13835049396628095106 resetting superblock realtime summary ino pointer to 18446744069414584450= Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... bad magic # 0x0 for agf 0 bad version # 0 for agf 0 bad length 0 for agf 0, should be 262144 bad magic # 0x0 for agi 0 bad version # 0 for agi 0 bad length # 0 for agi 0, should be 262144 reset bad agf for ag 0 reset bad agi for ag 0 bad agbno 0 for btbno root, agno 0 bad agbno 0 for btbcnt root, agno 0 bad agbno 0 for inobt root, agno 0 root inode chunk not found Phase 3 - for each AG... - scan and clear agi unlinked lists... error following ag 0 unlinked list - process known inodes and perform inode discovery... - agno =3D 0 imap claims in-use inode 131 is free, correcting imap imap claims in-use inode 132 is free, correcting imap imap claims in-use inode 133 is free, correcting imap imap claims in-use inode 134 is free, correcting imap imap claims in-use inode 135 is free, correcting imap imap claims in-use inode 136 is free, correcting imap imap claims in-use inode 137 is free, correcting imap imap claims in-use inode 141 is free, correcting imap - agno =3D 1 - agno =3D 2 - agno =3D 3 - agno =3D 4 - agno =3D 5 - agno =3D 6 - agno =3D 7 - agno =3D 8 - agno =3D 9 - agno =3D 10 - agno =3D 11 - agno =3D 12 - agno =3D 13 - agno =3D 14 - agno =3D 15 - agno =3D 16 - agno =3D 17 - agno =3D 18 - agno =3D 19 - agno =3D 20 - agno =3D 21 - agno =3D 22 - agno =3D 23 - agno =3D 24 - agno =3D 25 - agno =3D 26 - agno =3D 27 - agno =3D 28 - agno =3D 29 - agno =3D 30 - agno =3D 31 - agno =3D 32 - agno =3D 33 - agno =3D 34 - agno =3D 35 - agno =3D 36 - agno =3D 37 - process newly discovered inodes... imap claims in-use inode 929 is free, correcting imap =2E..snip... imap claims in-use inode 991 is free, correcting imap imap claims in-use inode 4176897 is free, correcting imap =2E..snip... imap claims in-use inode 4176959 is free, correcting imap found inodes not in the inode allocation tree Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - check for inodes claiming duplicate blocks... - agno =3D 0 entry "test_size.img" at block 0 offset 1024 in directory inode 136 refer= ences free inode 138 clearing inode number in entry at offset 1024... - agno =3D 1 - agno =3D 2 - agno =3D 3 - agno =3D 4 - agno =3D 5 - agno =3D 6 - agno =3D 7 - agno =3D 8 - agno =3D 9 - agno =3D 10 - agno =3D 11 - agno =3D 12 - agno =3D 13 - agno =3D 14 - agno =3D 15 - agno =3D 16 - agno =3D 17 - agno =3D 18 - agno =3D 19 - agno =3D 20 - agno =3D 21 - agno =3D 22 - agno =3D 23 - agno =3D 24 - agno =3D 25 - agno =3D 26 - agno =3D 27 - agno =3D 28 - agno =3D 29 - agno =3D 30 - agno =3D 31 - agno =3D 32 - agno =3D 33 - agno =3D 34 - agno =3D 35 - agno =3D 36 - agno =3D 37 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... = rebuilding directory inode 136 - traversal finished ... = - traversing all unattached subtrees ... = - traversals finished ... = - moving disconnected inodes to lost+found ... = Phase 7 - verify and correct link counts... Note - stripe unit (0) and width (0) fields have been reset. Please set with mount -o sunit=3D,swidth=3D done --------------8D5B87496141DA5BD63B7EAF-- From owner-linux-xfs@oss.sgi.com Wed Oct 24 06:02:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OD2bi09091 for linux-xfs-outgoing; Wed, 24 Oct 2001 06:02:37 -0700 Received: from umbi3.umbi.umd.edu (umbi3.umbi.umd.edu [136.160.7.51]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OD2ZD09059 for ; Wed, 24 Oct 2001 06:02:35 -0700 Received: from umbi.umd.edu (mystery.carb.nist.gov [129.6.113.182]) by umbi3.umbi.umd.edu (Netscape Messaging Server 4.15) with ESMTP id GLPO8B00.5G8; Wed, 24 Oct 2001 09:02:35 -0400 Message-ID: <3BD6BBEA.D136933B@umbi.umd.edu> Date: Wed, 24 Oct 2001 09:02:34 -0400 From: Jonathan Dill Organization: CARB X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-6SGI_XFS_PR1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Marc Schmitt , Steve Lord , Eric Sandeen , linux-xfs@oss.sgi.com, florin@sgi.com Subject: Re: Corruption of in-memory data detected. References: <200110232310.f9NNAgl14295@jen.americas.sgi.com> <3BD6809E.40204@inf.ethz.ch> <3BD6BA99.4CAE0D71@umbi.umd.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk PS: amazingly, xfs_repair appears to have "found" everything intact and lost+found was empty. -- "Jonathan F. Dill" (dill@umbi.umd.edu) From owner-linux-xfs@oss.sgi.com Wed Oct 24 06:52:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ODqou10403 for linux-xfs-outgoing; Wed, 24 Oct 2001 06:52:50 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ODqlD10381 for ; Wed, 24 Oct 2001 06:52:47 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id GAA02800 for ; Wed, 24 Oct 2001 06:52:04 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA3376513; Wed, 24 Oct 2001 08:51:30 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA86213; Wed, 24 Oct 2001 08:51:30 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9ODlnI15296; Wed, 24 Oct 2001 08:47:49 -0500 Message-Id: <200110241347.f9ODlnI15296@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Vincent Bernat cc: linux-xfs@oss.sgi.com Subject: Re: Is restore FS-independant ? In-Reply-To: Message from Vincent Bernat of "Wed, 24 Oct 2001 10:49:41 +0200." Date: Wed, 24 Oct 2001 08:47:49 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hi ! > > I would like to know if xfsrestore can be issued on a file system > which is not XFS and which doesn't have all the possibilities of it ? > -- > BOFH excuse #130: > new management The latest version should not complain about missing xfs functionality in a filesystem, and does not need to sit in a directory on an xfs filesystem to run. I am not sure what happens if you attempt to restore files with quotas and extended attributes though. Apart from that it should work. Steve From owner-linux-xfs@oss.sgi.com Wed Oct 24 07:03:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OE32T10913 for linux-xfs-outgoing; Wed, 24 Oct 2001 07:03:02 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OE2qD10881 for ; Wed, 24 Oct 2001 07:02:53 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id QAA599742 for ; Wed, 24 Oct 2001 16:02:47 +0200 (CEST) mail_from (tbd@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA3387625; Wed, 24 Oct 2001 09:01:27 -0500 (CDT) Received: from fsgi158.americas.sgi.com (fsgi158.americas.sgi.com [128.162.191.39]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA02951; Wed, 24 Oct 2001 09:01:27 -0500 (CDT) From: Tad Dolphay Received: by fsgi158.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) id JAA05671; Wed, 24 Oct 2001 09:01:26 -0500 (CDT) Message-Id: <200110241401.JAA05671@fsgi158.americas.sgi.com> Subject: Re: For Testing - updated RH7.1 XFS 2.4.9-6 kernels To: jlb17@duke.edu (Joshua Baker-LePain) Date: Wed, 24 Oct 2001 09:01:25 -0500 (CDT) Cc: sandeen@sgi.com (Eric Sandeen), linux-xfs@oss.sgi.com In-Reply-To: from "Joshua Baker-LePain" at Oct 24, 2001 05:58:53 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > On Tue, 23 Oct 2001 at 8:38pm, Eric Sandeen wrote > > > Changes: > > > > * LVM now compiles (!) & updated to 1.0.1rc4, module > > included in binary RPMs. (Thanks Martin!) > > > > * bcm5820 & intermezzo unresolved symbols fixed > > > > * kernel-source package fixed (includes linux/kdb files) > > Does it/will it include the fix for the NFS locking issues which have been > reported? > I haven't checked but here's the patch. --- linux-2.4.9-6/fs/lockd/svc.c.orig Thu Oct 18 15:00:46 2001 +++ linux-2.4.9-6/fs/lockd/svc.c Mon Oct 22 10:25:21 2001 @@ -122,6 +122,15 @@ if (nlmsvc_ops) { nlmsvc_ops->detach(); grace_period_expire = nlmsvc_grace_period + jiffies; +#ifdef RPC_DEBUG + nlmsvc_grace_period = 10 * HZ; +#else + if (nlm_grace_period) + nlmsvc_grace_period = ((nlm_grace_period + nlm_timeout - 1) + / nlm_timeout) * nlm_timeout * HZ; + else + nlmsvc_grace_period = 5 * nlm_timeout * HZ; +#endif } } @@ -133,8 +142,10 @@ */ if (!grace_period_expire) { timeout = nlmsvc_retry_blocked(); - } else if (time_before(grace_period_expire, jiffies)) + } else if (time_before(grace_period_expire, jiffies)) { grace_period_expire = 0; + nlmsvc_grace_period = 0; + } /* * Find a socket with data available and call its From owner-linux-xfs@oss.sgi.com Wed Oct 24 08:04:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OF4Ox12666 for linux-xfs-outgoing; Wed, 24 Oct 2001 08:04:24 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OF42D12547 for ; Wed, 24 Oct 2001 08:04:02 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9OF3uW13193 for ; Wed, 24 Oct 2001 08:03:56 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA3330220; Wed, 24 Oct 2001 10:02:40 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA09745; Wed, 24 Oct 2001 10:02:40 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9OEwwo07245; Wed, 24 Oct 2001 09:58:58 -0500 Message-Id: <200110241458.f9OEwwo07245@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Jonathan Dill cc: Marc Schmitt , Steve Lord , Eric Sandeen , linux-xfs@oss.sgi.com, florin@sgi.com Subject: Re: Corruption of in-memory data detected. In-Reply-To: Message from Jonathan Dill of "Wed, 24 Oct 2001 08:56:57 EDT." <3BD6BA99.4CAE0D71@umbi.umd.edu> Date: Wed, 24 Oct 2001 09:58:58 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk In this case it looks very like the start of the filesystem got wacked with a bunch of zeros somehow. The file size limit is somewhat odd, there is nothing in xfs which will prevent a file from being extremely large - 2^44 is about where issues would start for buffered I/O. Possibly the size issue is is an interaction between the vfs in the ac kernel and xfs - we will run some tests on this. Your second email about xfs_repair finding everything does not tie in with this output at all, you lost the root inode in this case. So far I have been unable to make things fall over here at all - which is frustrating. Steve > This is a multi-part message in MIME format. > --------------8D5B87496141DA5BD63B7EAF > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > Hi guys, > > I just managed to get this error and severe fs corruption without RAID, > mongo, huge filesystem, or anything weird. (BTW I'm a bleeding edge > kind of guy, so the fs wasn't critical and I've got backups :-). This > was with the kernel-2.4.9-6SGI_XFS_PR1, and I'm not using any of the > modules that had symbol problems. > > Initially, I was trying to xfsdump and gzip a whole filesystem to an xfs > on another disk and I got "file size limit exceeded" and "core dumped." > So I said, "OK so what's the max filesize?" I thought it was pretty > high for XFS, but apparently not for Linux XFS--I was backing up a ~6 GB > partition, so the file size had to be less than that. I didn't find any > clues in a cursory glance at xfs.h, so I decided to test it in a > not-so-nice way: > > dd if=/dev/zero of=test_size.img bs=10240k > > The process choked and this is what turned up in the system log: > > Oct 24 07:47:08 localhost kernel: xfs_force_shutdown(ide1(22,65),0x8) > called from line 1120 of file xfs_trans.c. Return address = 0xc01ca409 > Oct 24 07:47:08 localhost kernel: Corruption of in-memory data > detected. Shutting down filesystem: ide1(22,65) > Oct 24 07:47:08 localhost kernel: Please umount the filesystem, and > rectify the problem(s) > > When I tried to mount the disk again, I got this error: > > Oct 24 07:47:30 localhost kernel: XFS: bad magic number > Oct 24 07:47:30 localhost kernel: XFS: SB validate failed > > xfs_repair had to search for quite awhile to find a good alternate SB. > I attached the log of xfs_repair so you can see I did a capital job of > trashing the FS :-) Later, I'll try it again to see if I can reproduce > the problem, then again with the newer 2.4.9 kernel. > > -- > "Jonathan F. Dill" (dill@umbi.umd.edu) > --------------8D5B87496141DA5BD63B7EAF > Content-Type: text/plain; charset=iso-8859-1; > name="xfs_repair.log" > Content-Transfer-Encoding: quoted-printable > Content-Disposition: inline; > filename="xfs_repair.log" > > [root@localhost ~]# mount /trans > mount: wrong fs type, bad option, bad superblock on /dev/hdd1, > or too many mounted file systems > [root@localhost ~]# xfs_repair /dev/hdd1 > xfs_repair: warning - cannot set blocksize on block device /dev/hdd1: Inp= > ut/output error > Phase 1 - find and verify superblock... > bad primary superblock - bad magic number !!! > > attempting to find secondary superblock... > =2E......................................................................= > =2E......................................................................= > =2E......................................................................= > =2E......................................................................= > =2E......................................................................= > =2E......................................................................= > =2E......................................................................= > =2E......................................................................= > =2E......................................................................= > =2E......................................................................= > =2E......................................................................= > =2E......................................................................= > =2E......................................................................= > =2E......................................................................= > =2E..............found candidate secondary superblock... > verified secondary superblock... > writing modified primary superblock > sb root inode value 18446744073709551615 inconsistent with calculated val= > ue 13835049396628095104 > resetting superblock root inode pointer to 18446744069414584448 > sb realtime bitmap inode 18446744073709551615 inconsistent with calculate= > d value 13835049396628095105 > resetting superblock realtime bitmap ino pointer to 18446744069414584449 > sb realtime summary inode 18446744073709551615 inconsistent with calculat= > ed value 13835049396628095106 > resetting superblock realtime summary ino pointer to 18446744069414584450= > > Phase 2 - using internal log > - zero log... > - scan filesystem freespace and inode maps... > bad magic # 0x0 for agf 0 > bad version # 0 for agf 0 > bad length 0 for agf 0, should be 262144 > bad magic # 0x0 for agi 0 > bad version # 0 for agi 0 > bad length # 0 for agi 0, should be 262144 > reset bad agf for ag 0 > reset bad agi for ag 0 > bad agbno 0 for btbno root, agno 0 > bad agbno 0 for btbcnt root, agno 0 > bad agbno 0 for inobt root, agno 0 > root inode chunk not found > Phase 3 - for each AG... > - scan and clear agi unlinked lists... > error following ag 0 unlinked list > - process known inodes and perform inode discovery... > - agno =3D 0 > imap claims in-use inode 131 is free, correcting imap > imap claims in-use inode 132 is free, correcting imap > imap claims in-use inode 133 is free, correcting imap > imap claims in-use inode 134 is free, correcting imap > imap claims in-use inode 135 is free, correcting imap > imap claims in-use inode 136 is free, correcting imap > imap claims in-use inode 137 is free, correcting imap > imap claims in-use inode 141 is free, correcting imap > - agno =3D 1 > - agno =3D 2 > - agno =3D 3 > - agno =3D 4 > - agno =3D 5 > - agno =3D 6 > - agno =3D 7 > - agno =3D 8 > - agno =3D 9 > - agno =3D 10 > - agno =3D 11 > - agno =3D 12 > - agno =3D 13 > - agno =3D 14 > - agno =3D 15 > - agno =3D 16 > - agno =3D 17 > - agno =3D 18 > - agno =3D 19 > - agno =3D 20 > - agno =3D 21 > - agno =3D 22 > - agno =3D 23 > - agno =3D 24 > - agno =3D 25 > - agno =3D 26 > - agno =3D 27 > - agno =3D 28 > - agno =3D 29 > - agno =3D 30 > - agno =3D 31 > - agno =3D 32 > - agno =3D 33 > - agno =3D 34 > - agno =3D 35 > - agno =3D 36 > - agno =3D 37 > - process newly discovered inodes... > imap claims in-use inode 929 is free, correcting imap > =2E..snip... > imap claims in-use inode 991 is free, correcting imap > imap claims in-use inode 4176897 is free, correcting imap > =2E..snip... > imap claims in-use inode 4176959 is free, correcting imap > found inodes not in the inode allocation tree > Phase 4 - check for duplicate blocks... > - setting up duplicate extent list... > - clear lost+found (if it exists) ... > - check for inodes claiming duplicate blocks... > - agno =3D 0 > entry "test_size.img" at block 0 offset 1024 in directory inode 136 refer= > ences free inode 138 > clearing inode number in entry at offset 1024... > - agno =3D 1 > - agno =3D 2 > - agno =3D 3 > - agno =3D 4 > - agno =3D 5 > - agno =3D 6 > - agno =3D 7 > - agno =3D 8 > - agno =3D 9 > - agno =3D 10 > - agno =3D 11 > - agno =3D 12 > - agno =3D 13 > - agno =3D 14 > - agno =3D 15 > - agno =3D 16 > - agno =3D 17 > - agno =3D 18 > - agno =3D 19 > - agno =3D 20 > - agno =3D 21 > - agno =3D 22 > - agno =3D 23 > - agno =3D 24 > - agno =3D 25 > - agno =3D 26 > - agno =3D 27 > - agno =3D 28 > - agno =3D 29 > - agno =3D 30 > - agno =3D 31 > - agno =3D 32 > - agno =3D 33 > - agno =3D 34 > - agno =3D 35 > - agno =3D 36 > - agno =3D 37 > Phase 5 - rebuild AG headers and trees... > - reset superblock... > Phase 6 - check inode connectivity... > - resetting contents of realtime bitmap and summary inodes > - ensuring existence of lost+found directory > - traversing filesystem starting at / ... = > > rebuilding directory inode 136 > - traversal finished ... = > > - traversing all unattached subtrees ... = > > - traversals finished ... = > > - moving disconnected inodes to lost+found ... = > > Phase 7 - verify and correct link counts... > Note - stripe unit (0) and width (0) fields have been reset. > Please set with mount -o sunit=3D,swidth=3D > done > > --------------8D5B87496141DA5BD63B7EAF-- From owner-linux-xfs@oss.sgi.com Wed Oct 24 08:15:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OFFuN13111 for linux-xfs-outgoing; Wed, 24 Oct 2001 08:15:56 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OFFUD13087 for ; Wed, 24 Oct 2001 08:15:31 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9OFFPK20553 for ; Wed, 24 Oct 2001 08:15:25 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA3386046; Wed, 24 Oct 2001 10:14:09 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA23889; Wed, 24 Oct 2001 10:14:09 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9OFAR707303; Wed, 24 Oct 2001 10:10:27 -0500 Message-Id: <200110241510.f9OFAR707303@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Jonathan Dill , Marc Schmitt , Eric Sandeen , linux-xfs@oss.sgi.com, florin@sgi.com Subject: Re: Corruption of in-memory data detected. In-Reply-To: Message from Steve Lord of "Wed, 24 Oct 2001 09:58:58 CDT." <200110241458.f9OEwwo07245@jen.americas.sgi.com> Date: Wed, 24 Oct 2001 10:10:27 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > In this case it looks very like the start of the filesystem got wacked > with a bunch of zeros somehow. The file size limit is somewhat odd, > there is nothing in xfs which will prevent a file from being extremely > large - 2^44 is about where issues would start for buffered I/O. Possibly > the size issue is is an interaction between the vfs in the ac kernel > and xfs - we will run some tests on this. And the answer is: [root@Lite sda3]# dd if=/dev/zero of=test_size.img bs=10240k dd: writing `test_size.img': No space left on device 747+0 records in 746+0 records out [root@Lite sda3]# ls -lh total 7.3G drwxr-xr-x 7 root root 4.0k Oct 23 16:57 dumpdir drwxr-xr-x 3 root root 20 Oct 23 16:57 restoredir -rw-r--r-- 1 root root 7.3G Oct 24 10:01 test_size.img [root@Lite sda3]# uname -a Linux Lite 2.4.9-6SGI_XFS_PR2 #1 Tue Oct 23 15:34:18 CDT 2001 i686 unknown [root@Lite sda3]# So the size issue is something else - either a system problem on your end - do you have user limits set to other than the default? Steve > > Your second email about xfs_repair finding everything does not tie in > with this output at all, you lost the root inode in this case. > > So far I have been unable to make things fall over here at all - which > is frustrating. > > Steve > > > This is a multi-part message in MIME format. > > --------------8D5B87496141DA5BD63B7EAF > > Content-Type: text/plain; charset=us-ascii > > Content-Transfer-Encoding: 7bit > > > > Hi guys, > > > > I just managed to get this error and severe fs corruption without RAID, > > mongo, huge filesystem, or anything weird. (BTW I'm a bleeding edge > > kind of guy, so the fs wasn't critical and I've got backups :-). This > > was with the kernel-2.4.9-6SGI_XFS_PR1, and I'm not using any of the > > modules that had symbol problems. > > > > Initially, I was trying to xfsdump and gzip a whole filesystem to an xfs > > on another disk and I got "file size limit exceeded" and "core dumped." > > So I said, "OK so what's the max filesize?" I thought it was pretty > > high for XFS, but apparently not for Linux XFS--I was backing up a ~6 GB > > partition, so the file size had to be less than that. I didn't find any > > clues in a cursory glance at xfs.h, so I decided to test it in a > > not-so-nice way: > > > > dd if=/dev/zero of=test_size.img bs=10240k > > > > The process choked and this is what turned up in the system log: > > > > Oct 24 07:47:08 localhost kernel: xfs_force_shutdown(ide1(22,65),0x8) > > called from line 1120 of file xfs_trans.c. Return address = 0xc01ca409 > > Oct 24 07:47:08 localhost kernel: Corruption of in-memory data > > detected. Shutting down filesystem: ide1(22,65) > > Oct 24 07:47:08 localhost kernel: Please umount the filesystem, and > > rectify the problem(s) > > > > When I tried to mount the disk again, I got this error: > > > > Oct 24 07:47:30 localhost kernel: XFS: bad magic number > > Oct 24 07:47:30 localhost kernel: XFS: SB validate failed > > > > xfs_repair had to search for quite awhile to find a good alternate SB. > > I attached the log of xfs_repair so you can see I did a capital job of > > trashing the FS :-) Later, I'll try it again to see if I can reproduce > > the problem, then again with the newer 2.4.9 kernel. > > > > -- > > "Jonathan F. Dill" (dill@umbi.umd.edu) > > --------------8D5B87496141DA5BD63B7EAF > > Content-Type: text/plain; charset=iso-8859-1; > > name="xfs_repair.log" > > Content-Transfer-Encoding: quoted-printable > > Content-Disposition: inline; > > filename="xfs_repair.log" > > > > [root@localhost ~]# mount /trans > > mount: wrong fs type, bad option, bad superblock on /dev/hdd1, > > or too many mounted file systems > > [root@localhost ~]# xfs_repair /dev/hdd1 > > xfs_repair: warning - cannot set blocksize on block device /dev/hdd1: Inp= > > ut/output error > > Phase 1 - find and verify superblock... > > bad primary superblock - bad magic number !!! > > > > attempting to find secondary superblock... > > =2E......................................................................= > > =2E......................................................................= > > =2E......................................................................= > > =2E......................................................................= > > =2E......................................................................= > > =2E......................................................................= > > =2E......................................................................= > > =2E......................................................................= > > =2E......................................................................= > > =2E......................................................................= > > =2E......................................................................= > > =2E......................................................................= > > =2E......................................................................= > > =2E......................................................................= > > =2E..............found candidate secondary superblock... > > verified secondary superblock... > > writing modified primary superblock > > sb root inode value 18446744073709551615 inconsistent with calculated val= > > ue 13835049396628095104 > > resetting superblock root inode pointer to 18446744069414584448 > > sb realtime bitmap inode 18446744073709551615 inconsistent with calculate= > > d value 13835049396628095105 > > resetting superblock realtime bitmap ino pointer to 18446744069414584449 > > sb realtime summary inode 18446744073709551615 inconsistent with calculat= > > ed value 13835049396628095106 > > resetting superblock realtime summary ino pointer to 18446744069414584450= > > > > Phase 2 - using internal log > > - zero log... > > - scan filesystem freespace and inode maps... > > bad magic # 0x0 for agf 0 > > bad version # 0 for agf 0 > > bad length 0 for agf 0, should be 262144 > > bad magic # 0x0 for agi 0 > > bad version # 0 for agi 0 > > bad length # 0 for agi 0, should be 262144 > > reset bad agf for ag 0 > > reset bad agi for ag 0 > > bad agbno 0 for btbno root, agno 0 > > bad agbno 0 for btbcnt root, agno 0 > > bad agbno 0 for inobt root, agno 0 > > root inode chunk not found > > Phase 3 - for each AG... > > - scan and clear agi unlinked lists... > > error following ag 0 unlinked list > > - process known inodes and perform inode discovery... > > - agno =3D 0 > > imap claims in-use inode 131 is free, correcting imap > > imap claims in-use inode 132 is free, correcting imap > > imap claims in-use inode 133 is free, correcting imap > > imap claims in-use inode 134 is free, correcting imap > > imap claims in-use inode 135 is free, correcting imap > > imap claims in-use inode 136 is free, correcting imap > > imap claims in-use inode 137 is free, correcting imap > > imap claims in-use inode 141 is free, correcting imap > > - agno =3D 1 > > - agno =3D 2 > > - agno =3D 3 > > - agno =3D 4 > > - agno =3D 5 > > - agno =3D 6 > > - agno =3D 7 > > - agno =3D 8 > > - agno =3D 9 > > - agno =3D 10 > > - agno =3D 11 > > - agno =3D 12 > > - agno =3D 13 > > - agno =3D 14 > > - agno =3D 15 > > - agno =3D 16 > > - agno =3D 17 > > - agno =3D 18 > > - agno =3D 19 > > - agno =3D 20 > > - agno =3D 21 > > - agno =3D 22 > > - agno =3D 23 > > - agno =3D 24 > > - agno =3D 25 > > - agno =3D 26 > > - agno =3D 27 > > - agno =3D 28 > > - agno =3D 29 > > - agno =3D 30 > > - agno =3D 31 > > - agno =3D 32 > > - agno =3D 33 > > - agno =3D 34 > > - agno =3D 35 > > - agno =3D 36 > > - agno =3D 37 > > - process newly discovered inodes... > > imap claims in-use inode 929 is free, correcting imap > > =2E..snip... > > imap claims in-use inode 991 is free, correcting imap > > imap claims in-use inode 4176897 is free, correcting imap > > =2E..snip... > > imap claims in-use inode 4176959 is free, correcting imap > > found inodes not in the inode allocation tree > > Phase 4 - check for duplicate blocks... > > - setting up duplicate extent list... > > - clear lost+found (if it exists) ... > > - check for inodes claiming duplicate blocks... > > - agno =3D 0 > > entry "test_size.img" at block 0 offset 1024 in directory inode 136 refer= > > ences free inode 138 > > clearing inode number in entry at offset 1024... > > - agno =3D 1 > > - agno =3D 2 > > - agno =3D 3 > > - agno =3D 4 > > - agno =3D 5 > > - agno =3D 6 > > - agno =3D 7 > > - agno =3D 8 > > - agno =3D 9 > > - agno =3D 10 > > - agno =3D 11 > > - agno =3D 12 > > - agno =3D 13 > > - agno =3D 14 > > - agno =3D 15 > > - agno =3D 16 > > - agno =3D 17 > > - agno =3D 18 > > - agno =3D 19 > > - agno =3D 20 > > - agno =3D 21 > > - agno =3D 22 > > - agno =3D 23 > > - agno =3D 24 > > - agno =3D 25 > > - agno =3D 26 > > - agno =3D 27 > > - agno =3D 28 > > - agno =3D 29 > > - agno =3D 30 > > - agno =3D 31 > > - agno =3D 32 > > - agno =3D 33 > > - agno =3D 34 > > - agno =3D 35 > > - agno =3D 36 > > - agno =3D 37 > > Phase 5 - rebuild AG headers and trees... > > - reset superblock... > > Phase 6 - check inode connectivity... > > - resetting contents of realtime bitmap and summary inodes > > - ensuring existence of lost+found directory > > - traversing filesystem starting at / ... = > > > > rebuilding directory inode 136 > > - traversal finished ... = > > > > - traversing all unattached subtrees ... = > > > > - traversals finished ... = > > > > - moving disconnected inodes to lost+found ... = > > > > Phase 7 - verify and correct link counts... > > Note - stripe unit (0) and width (0) fields have been reset. > > Please set with mount -o sunit=3D,swidth=3D > > done > > > > --------------8D5B87496141DA5BD63B7EAF-- > From owner-linux-xfs@oss.sgi.com Wed Oct 24 08:23:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OFN6a13488 for linux-xfs-outgoing; Wed, 24 Oct 2001 08:23:06 -0700 Received: from chimta02 (chimta02.algx.net [216.99.233.77]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OFMwD13466 for ; Wed, 24 Oct 2001 08:22:58 -0700 Received: from jtsdell (66-2-81-28.customer.algx.net [66.2.81.28]) by chimmx02.algx.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GLP00F0RUQ80L@chimmx02.algx.net> for linux-xfs@oss.sgi.com; Wed, 24 Oct 2001 10:22:57 -0500 (CDT) Date: Wed, 24 Oct 2001 11:23:15 -0400 (EDT) From: jtrostel@snapserver.com Subject: Re: Problems with samba 2.2.2 In-reply-to: <000101c15c6e$f69f2f70$6802a8c0@sesamstrasse.de> To: =?iso-8859-1?B?SvZyZyBI5G5zZWw=?= To: =?iso-8859-1?B?SvZyZyBI5G5zZWw=?= , samba-technical@samba.org Cc: linux-xfs@oss.sgi.com Reply-to: jtrostel@snapserver.com Message-id: Organization: Quantum Corp. / NASD MIME-version: 1.0 X-Mailer: XFMail 1.5.1 on Linux Content-type: text/plain; charset=us-ascii X-Priority: 3 (Normal) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id f9OFMwD13467 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk 1. I'm tossing this over to the samba-technical list too. On 24-Oct-2001 Jörg Hänsel wrote: > Hello, > I'm running samba 2.2.2 on a Linux Debian Woody System and encountered some > problems. > > First of all my settings: > Linux 2.4.12 SMP + XFS + ACL Patch > libc6 2.2.4-3 > gcc-2.95 2.95.4-0.01100 > acl, acl-dev 1.1.3-0 > xfsprogs, xfslibs-dev 1.3.5-0 > > I rebuilt the packages acl, acl-dev from oss.sgi.com and samba as debian > packages. > The ACLs and XFS seem work fine and pretty fast. This means that you can use 'chacl', 'getfacl', and 'setfacl' correctly on an XFS filesystem? > > I built 4 different version of samba for testing (the filename describes the > additional configure options): > > samba_2.2.2-1_i386.deb > samba_2.2.2-acl-1_i386.deb > samba_2.2.2-acl-ssl-1_i386.deb > samba_2.2.2-ssl-1_i386.deb > > On all versions of samba the following problems occured: > > Groupmemberships ignored: > ------------------------- > The users on my server are members of different groups. The primary group is > the userid itself (debian like). There is a specil group calles "smbdomadm" > which decides whether a domain user has admin rights or not. > When I am logging in from a Windows NT Client the following message appears > in "log.smb": > 4 user groups: > 1001 10010 20000 22000 > > Group 10010 is "smbdomadm". But after logging in the user doesn't have admin > rights. The "User manager for domains" says: User XXX has primary group 1001 > and is member of users which has gid 100 and is not right. > So samba seems to ignore the group memberships and the "domain admin group" > in smb.conf. User manager for domains is running on the NT server. I'm not sure how it is supposed to know about the groups you have assigned on the Samba server. Does 'getent group' show this user in your LOCAl 'smbdomadm' group? > By the way I tried to reduce the membership of user XXX to 1001 (primary) > and 10010 (other) but nothing changed. > > ACLs do not work: > ----------------- > When I use the ACL capable versions of samba the file security dialog under > Windows NT does not show the correct ACLs. > I use Default ACLs. Perhaps this causes problems under windows NT. Please be more specific in how this is failing. Are you setting ACLs in Samba that are not reflected when you try 'getfacl'? Are you setting ACLs under Linux that are not reflected when you look at them through the NT security dialog? What is the ACL set for your directory? What is the umask set as? > > There are more problems I encounterd. But I think they are not the reason > for the ones I wrote about . > > Thanks a lot for your help (I hope so), > > Joerg > > P.S.: Sorry for my english. > (END) -- John M. Trostel Senior Software Engineer Quantum Corp. / NASD jtrostel@snapserver.com From owner-linux-xfs@oss.sgi.com Wed Oct 24 08:47:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OFlBR14261 for linux-xfs-outgoing; Wed, 24 Oct 2001 08:47:11 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OFl8D14236 for ; Wed, 24 Oct 2001 08:47:08 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA06910 for ; Wed, 24 Oct 2001 08:46:25 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA3379892; Wed, 24 Oct 2001 10:45:51 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA99403; Wed, 24 Oct 2001 10:45:50 -0500 (CDT) Subject: Re: Corruption of in-memory data detected. From: Eric Sandeen To: Marc Schmitt Cc: linux-xfs@oss.sgi.com, florin@sgi.com In-Reply-To: <3BD4137A.8040406@inf.ethz.ch> References: <3BD4137A.8040406@inf.ethz.ch> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 24 Oct 2001 10:44:14 -0500 Message-Id: <1003938254.20357.76.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi again Marc - Can you try chopping this down to under 1TB? Martin suggested that there may be a sign problem in the 3ware driver; perhaps >1TB is causing the trouble... -Eric On Mon, 2001-10-22 at 07:39, Marc Schmitt wrote: > Hello all, > > I`m currently setting up a 1.2TB file server and consider using XFS. The > configuration is: -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Oct 24 08:54:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OFsVX14526 for linux-xfs-outgoing; Wed, 24 Oct 2001 08:54:31 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OFsPD14504 for ; Wed, 24 Oct 2001 08:54:25 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id RAA19764; Wed, 24 Oct 2001 17:54:23 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id RAA01065; Wed, 24 Oct 2001 17:54:22 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 2A14757306; Wed, 24 Oct 2001 17:53:14 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id ED33225835; Wed, 24 Oct 2001 17:53:13 +0200 (CEST) Message-ID: <3BD6E3E9.6CB278D7@ch.sauter-bc.com> Date: Wed, 24 Oct 2001 17:53:13 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Seung-young Oh Cc: linux-xfs Subject: Re: Updated mkinitrd RPMs References: <3BD65E16.A2B56384@ch.sauter-bc.com> <3BD6915D.6060808@orgio.net> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seung-young Oh schrieb: > > Simon Matter wrote: > > Hi > > > > Since Redhat has released new mkinitrd packages, I have updated my 'XFS > > installer enabled' version. It should work with root on softraid with > > devfs enabled (was default with the 1.0 installer). This is something > > the redhat initrd is not able to do. > > Find it here: > > > > http://home.datacomm.ch/simix/XFS/ > > > > BTW, sorry, I was not able to test it! Will do it tonight. > > > > -Simon > > > > > > > > Hello, > > Do I need to update the mkbootdisk and install the jftpgw as well? jftpgw has nothing to do in the XFS dir. Removed it. mkbootdisk is a modified version which will let you create 'overformatted' boot floppies. You may need this because XFS bootdisks won't fit on a standard 1.4M floppy. To create a bootdisk do something like mkbootdisk --device /dev/fd01722 2.4.xxx Simon > > -- > ICQ#: 103231199 From owner-linux-xfs@oss.sgi.com Wed Oct 24 09:14:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OGEx315409 for linux-xfs-outgoing; Wed, 24 Oct 2001 09:14:59 -0700 Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OGEtD15386 for ; Wed, 24 Oct 2001 09:14:55 -0700 Received: from squash.mw.mediaone.net (nic-30-c48-217.mw.mediaone.net [24.30.48.217]) by demai05.mw.mediaone.net (8.11.1/8.11.1) with ESMTP id f9OGF2w02916 for ; Wed, 24 Oct 2001 12:15:02 -0400 (EDT) Date: Wed, 24 Oct 2001 12:14:43 -0400 (EDT) From: J Landman X-X-Sender: To: Subject: question on include files for building from CVS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Folks: While building the CVS tree updated from this morning, I ran into this problem for the NCR controllers. 53c7,8xx.c:1579:22: 53c8xx_d.h: No such file or directory and then a cascade of errors after that, for all the symbols that were declared in this header. Is this pilot error (me)? Is this something missing in the tree? I did a find on this file, and it is no where to be found in the kernel tree. [landman@protein.dtw.macsch.com:~/linux-2.4-xfs/linux] 14 >find ./ -print | grep -i 53c8xx_d.h [landman@protein.dtw.macsch.com:~/linux-2.4-xfs/linux] 15 > I have it sitting in my 2.4.8 tree. Any ideas? Joe -- Joe Landman, landman@mediaone.net From owner-linux-xfs@oss.sgi.com Wed Oct 24 09:32:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OGWpm16243 for linux-xfs-outgoing; Wed, 24 Oct 2001 09:32:51 -0700 Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OGWjD16219 for ; Wed, 24 Oct 2001 09:32:45 -0700 Received: from squash.mw.mediaone.net (nic-30-c48-217.mw.mediaone.net [24.30.48.217]) by demai05.mw.mediaone.net (8.11.1/8.11.1) with ESMTP id f9OGWrw19414 for ; Wed, 24 Oct 2001 12:32:53 -0400 (EDT) Date: Wed, 24 Oct 2001 12:32:33 -0400 (EDT) From: J Landman X-X-Sender: To: Subject: Re: question on include files for building from CVS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ok, so making progress. Copied from 2.4.13 tree 53c8xx_d.h 53c8xx_u.h Now running into problems with the compaq FC stuff... might just disable it. On Wed, 24 Oct 2001, J Landman wrote: > Folks: > > While building the CVS tree updated from this morning, I ran into this > problem for the NCR controllers. > > 53c7,8xx.c:1579:22: 53c8xx_d.h: No such file or directory > > and then a cascade of errors after that, for all the symbols that were > declared in this header. > > Is this pilot error (me)? Is this something missing in the tree? I did > a find on this file, and it is no where to be found in the kernel tree. > > [landman@protein.dtw.macsch.com:~/linux-2.4-xfs/linux] > 14 >find ./ -print | grep -i 53c8xx_d.h > [landman@protein.dtw.macsch.com:~/linux-2.4-xfs/linux] > 15 > > > I have it sitting in my 2.4.8 tree. Any ideas? > > Joe > > -- Joe Landman, landman@mediaone.net From owner-linux-xfs@oss.sgi.com Wed Oct 24 09:40:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OGe5H16609 for linux-xfs-outgoing; Wed, 24 Oct 2001 09:40:05 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OGdwD16580 for ; Wed, 24 Oct 2001 09:39:58 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id SAA624718 for ; Wed, 24 Oct 2001 18:39:55 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA3393207; Wed, 24 Oct 2001 11:38:33 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA80475; Wed, 24 Oct 2001 11:38:32 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9OGYo027388; Wed, 24 Oct 2001 11:34:50 -0500 Message-Id: <200110241634.f9OGYo027388@jen.americas.sgi.com> To: J Landman cc: linux-xfs@oss.sgi.com Subject: Re: question on include files for building from CVS References: Comments: In-reply-to J Landman message dated "Wed, 24 Oct 2001 12:32:33 -0400." Date: Wed, 24 Oct 2001 11:34:50 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Ok, so making progress. Copied from 2.4.13 tree > > 53c8xx_d.h > 53c8xx_u.h I think Keith Owens removed these as they are automatically generated from somewhere - but I cannot honestly tell you how to create them. > > Now running into problems with the compaq FC stuff... might just disable > it. There was a pointer to a fix on linux kernel I think, but the topic line was not about FC drivers, maybe the thread about 2.4.13 itself. Steve > > On Wed, 24 Oct 2001, J Landman wrote: > > > Folks: > > > > While building the CVS tree updated from this morning, I ran into this > > problem for the NCR controllers. > > > > 53c7,8xx.c:1579:22: 53c8xx_d.h: No such file or directory > > > > and then a cascade of errors after that, for all the symbols that were > > declared in this header. > > > > Is this pilot error (me)? Is this something missing in the tree? I did > > a find on this file, and it is no where to be found in the kernel tree. > > > > [landman@protein.dtw.macsch.com:~/linux-2.4-xfs/linux] > > 14 >find ./ -print | grep -i 53c8xx_d.h > > [landman@protein.dtw.macsch.com:~/linux-2.4-xfs/linux] > > 15 > > > > > I have it sitting in my 2.4.8 tree. Any ideas? > > > > Joe > > > > > > -- > Joe Landman, > landman@mediaone.net > From owner-linux-xfs@oss.sgi.com Wed Oct 24 09:40:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OGeA316633 for linux-xfs-outgoing; Wed, 24 Oct 2001 09:40:10 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OGdwD16581 for ; Wed, 24 Oct 2001 09:39:58 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id SAA611683 for ; Wed, 24 Oct 2001 18:39:55 +0200 (CEST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA3390612; Wed, 24 Oct 2001 11:38:30 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id LAA83486; Wed, 24 Oct 2001 11:38:29 -0500 (CDT) Subject: Re: For Testing - updated RH7.1 XFS 2.4.9-6 kernels From: Eric Sandeen To: Joshua Baker-LePain Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 24 Oct 2001 11:36:53 -0500 Message-Id: <1003941413.20738.83.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Joshua - The next spin will, building now. Thanks, -Eric On Wed, 2001-10-24 at 04:58, Joshua Baker-LePain wrote: > Does it/will it include the fix for the NFS locking issues which have been > reported? -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Oct 24 10:11:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OHBDi17954 for linux-xfs-outgoing; Wed, 24 Oct 2001 10:11:13 -0700 Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OHB9D17929 for ; Wed, 24 Oct 2001 10:11:09 -0700 Received: from there ([62.248.167.201]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20011024171104.YSBM13228.fep01-app.kolumbus.fi@there> for ; Wed, 24 Oct 2001 20:11:04 +0300 Content-Type: text/plain; charset="iso-8859-1" From: Hristo Grigorov To: linux-xfs@oss.sgi.com Subject: Makefile Date: Wed, 24 Oct 2001 20:11:33 +0300 X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011024171104.YSBM13228.fep01-app.kolumbus.fi@there> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I just updated from CVS and the Makefile points to -pre6-xfs Is that correct ? I think there is official 2.4.13 already... -- Cheers, Hristo. From owner-linux-xfs@oss.sgi.com Wed Oct 24 10:25:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OHPDP18475 for linux-xfs-outgoing; Wed, 24 Oct 2001 10:25:13 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OHPAD18453 for ; Wed, 24 Oct 2001 10:25:10 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9OHP4W21732 for ; Wed, 24 Oct 2001 10:25:05 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA3392643; Wed, 24 Oct 2001 12:23:48 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA46343; Wed, 24 Oct 2001 12:23:48 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9OHK4q29893; Wed, 24 Oct 2001 12:20:04 -0500 Message-Id: <200110241720.f9OHK4q29893@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Hristo Grigorov cc: linux-xfs@oss.sgi.com Subject: Re: Makefile In-Reply-To: Message from Hristo Grigorov of "Wed, 24 Oct 2001 20:11:33 +0300." <20011024171104.YSBM13228.fep01-app.kolumbus.fi@there> Date: Wed, 24 Oct 2001 12:20:04 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hi, > > I just updated from CVS and the Makefile points to -pre6-xfs > Is that correct ? I think there is official 2.4.13 already... > > -- > Cheers, Hristo. Yes there is, and you have an option, one which does not work now, or one which works later. i.e. wait for it. Linus hit the vm code again - small but significant change. Steve From owner-linux-xfs@oss.sgi.com Wed Oct 24 10:27:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OHRQd18626 for linux-xfs-outgoing; Wed, 24 Oct 2001 10:27:26 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OHRND18604 for ; Wed, 24 Oct 2001 10:27:23 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9OHRIW21845 for ; Wed, 24 Oct 2001 10:27:18 -0700 Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA3394766; Wed, 24 Oct 2001 12:26:03 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id MAA28542; Wed, 24 Oct 2001 12:26:02 -0500 (CDT) Subject: Re: Makefile From: Eric Sandeen To: Hristo Grigorov Cc: linux-xfs@oss.sgi.com In-Reply-To: <20011024171104.YSBM13228.fep01-app.kolumbus.fi@there> References: <20011024171104.YSBM13228.fep01-app.kolumbus.fi@there> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 24 Oct 2001 12:24:25 -0500 Message-Id: <1003944266.21961.88.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Hristo - 2.4.13 is out, but it's not merged into the ZFS tree yet... -Eric On Wed, 2001-10-24 at 12:11, Hristo Grigorov wrote: > Hi, > > I just updated from CVS and the Makefile points to -pre6-xfs > Is that correct ? I think there is official 2.4.13 already... > > -- > Cheers, Hristo. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Oct 24 10:42:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OHghR20436 for linux-xfs-outgoing; Wed, 24 Oct 2001 10:42:43 -0700 Received: from msg.ecetra.com (dollar.ecetra.com [193.164.224.209]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OHgbD20414 for ; Wed, 24 Oct 2001 10:42:37 -0700 Received: from vie-ac.office.ecetra.com (vie-ac.office.ecetra.com [10.251.148.148] (may be forged)) by msg.ecetra.com (8.9.3/8.9.3) with ESMTP id TAA14834; Wed, 24 Oct 2001 19:42:30 +0200 Received: from localhost (localhost [127.0.0.1]) by vie-ac.office.ecetra.com (8.12.1/8.12.1) with ESMTP id f9OHgUfa031941; Wed, 24 Oct 2001 19:42:30 +0200 Date: Wed, 24 Oct 2001 19:42:30 +0200 (CEST) From: Adam Cioccarelli To: Eric Sandeen cc: Hristo Grigorov , Subject: Re: Makefile In-Reply-To: <1003944266.21961.88.camel@stout.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Damm that ZFS, and I'd just converted all my servers to XFS! ------------------------------------------------------------------------------- Adam Cioccarelli (B.E Mechanical) Adam.Cioccarelli@ecetra.com Database Administrator Phone: +43 1 536 89 17725 Fax: +43 1 536 89 17719 ecetra Central European e-Finance AG Mobile:+43 664 181 4195 ------------------------------------------------------------------------------- On 24 Oct 2001, Eric Sandeen wrote: > Hi Hristo - > > 2.4.13 is out, but it's not merged into the ZFS tree yet... > > -Eric > > On Wed, 2001-10-24 at 12:11, Hristo Grigorov wrote: > > Hi, > > > > I just updated from CVS and the Makefile points to -pre6-xfs > > Is that correct ? I think there is official 2.4.13 already... > > > > -- > > Cheers, Hristo. > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. > From owner-linux-xfs@oss.sgi.com Wed Oct 24 11:06:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OI6ZO22592 for linux-xfs-outgoing; Wed, 24 Oct 2001 11:06:35 -0700 Received: from linux.nameip.net ([211.187.6.46]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OI6TD22570 for ; Wed, 24 Oct 2001 11:06:29 -0700 Received: (qmail 32629 invoked from network); 24 Oct 2001 18:11:24 -0000 Received: from unknown (HELO orgio.net) (211.187.6.46) by 0 with SMTP; 24 Oct 2001 18:11:24 -0000 Message-ID: <3BD7044B.5080209@orgio.net> Date: Thu, 25 Oct 2001 03:11:23 +0900 From: Seung-young Oh User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011013 X-Accept-Language: ko MIME-Version: 1.0 To: Adam Cioccarelli CC: Eric Sandeen , Hristo Grigorov , linux-xfs@oss.sgi.com Subject: Re: Makefile References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Adam Cioccarelli wrote: > Damm that ZFS, and I'd just converted all my servers to XFS! > > ------------------------------------------------------------------------------- > Adam Cioccarelli (B.E Mechanical) Adam.Cioccarelli@ecetra.com > Database Administrator Phone: +43 1 536 89 17725 > Fax: +43 1 536 89 17719 > ecetra Central European e-Finance AG Mobile:+43 664 181 4195 > ------------------------------------------------------------------------------- > > > On 24 Oct 2001, Eric Sandeen wrote: > > >>Hi Hristo - >> >>2.4.13 is out, but it's not merged into the ZFS tree yet... >> >>-Eric >> >>On Wed, 2001-10-24 at 12:11, Hristo Grigorov wrote: >> >>>Hi, >>> >>>I just updated from CVS and the Makefile points to -pre6-xfs >>>Is that correct ? I think there is official 2.4.13 already... >>> >>>-- >>>Cheers, Hristo. >>> >>-- >>Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs >>sandeen@sgi.com SGI, Inc. >> >> > You just couldn't resist, could you? :-) I was very tempted, but have tried hard to look the other way! -- ICQ#: 103231199 From owner-linux-xfs@oss.sgi.com Wed Oct 24 11:12:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OIC9S22867 for linux-xfs-outgoing; Wed, 24 Oct 2001 11:12:09 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OIC7D22845 for ; Wed, 24 Oct 2001 11:12:07 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9OIC2K30905 for ; Wed, 24 Oct 2001 11:12:02 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA3398041; Wed, 24 Oct 2001 13:10:45 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA56007; Wed, 24 Oct 2001 13:10:45 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9OI72w30628; Wed, 24 Oct 2001 13:07:02 -0500 Message-Id: <200110241807.f9OI72w30628@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Seung-young Oh cc: Adam Cioccarelli , Eric Sandeen , Hristo Grigorov , linux-xfs@oss.sgi.com Subject: Re: Makefile In-Reply-To: Message from Seung-young Oh of "Thu, 25 Oct 2001 03:11:23 +0900." <3BD7044B.5080209@orgio.net> Date: Wed, 24 Oct 2001 13:07:02 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Adam Cioccarelli wrote: > > > Damm that ZFS, and I'd just converted all my servers to XFS! > > It's a follow on project - the one after YFS..... ;-) Steve From owner-linux-xfs@oss.sgi.com Wed Oct 24 11:31:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OIVub25661 for linux-xfs-outgoing; Wed, 24 Oct 2001 11:31:56 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OIVqD25637 for ; Wed, 24 Oct 2001 11:31:53 -0700 Received: from idcomm.com (IDENT:JguaA7YNSusW0GetGzI5DkXeb8QJpw5q@k56-pip12.idcomm.com [209.60.72.139]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f9OIWeL12462 for ; Wed, 24 Oct 2001 12:32:40 -0600 Message-ID: <3BD70946.57D21F75@idcomm.com> Date: Wed, 24 Oct 2001 12:32:38 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "XFS: linux-xfs@oss.sgi.com" Subject: Re: Makefile References: <200110241807.f9OI72w30628@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: > > > Adam Cioccarelli wrote: > > > > > Damm that ZFS, and I'd just converted all my servers to XFS! > > > > > It's a follow on project - the one after YFS..... ;-) > > Steve Eventually it'll work its way around, and we can all join the AA group. Assuming we aren't already members. :> D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Wed Oct 24 11:37:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OIbOL27993 for linux-xfs-outgoing; Wed, 24 Oct 2001 11:37:24 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OIbLD27970 for ; Wed, 24 Oct 2001 11:37:21 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA03763 for ; Wed, 24 Oct 2001 11:37:14 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA3387070; Wed, 24 Oct 2001 13:35:51 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA11388; Wed, 24 Oct 2001 13:35:51 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9OIW8E30764; Wed, 24 Oct 2001 13:32:08 -0500 Message-Id: <200110241832.f9OIW8E30764@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: stimits@idcomm.com cc: "XFS: linux-xfs@oss.sgi.com" Subject: Re: Makefile In-Reply-To: Message from "D. Stimits" of "Wed, 24 Oct 2001 12:32:38 MDT." <3BD70946.57D21F75@idcomm.com> Date: Wed, 24 Oct 2001 13:32:08 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Steve Lord wrote: > > > > > Adam Cioccarelli wrote: > > > > > > > Damm that ZFS, and I'd just converted all my servers to XFS! > > > > > > > > It's a follow on project - the one after YFS..... ;-) > > > > Steve > > Eventually it'll work its way around, and we can all join the AA group. > Assuming we aren't already members. :> Well, given the gyrations in the linux VM, I suspect a number of kernel developers have been driven to drink! Steve > > D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Wed Oct 24 11:45:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OIjZl30630 for linux-xfs-outgoing; Wed, 24 Oct 2001 11:45:35 -0700 Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OIjUD30598 for ; Wed, 24 Oct 2001 11:45:30 -0700 Received: from there ([62.248.183.188]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20011024184528.YZVR13228.fep01-app.kolumbus.fi@there>; Wed, 24 Oct 2001 21:45:28 +0300 Content-Type: text/plain; charset="iso-8859-1" From: Hristo Grigorov To: Steve Lord Subject: Re: Makefile Date: Wed, 24 Oct 2001 21:46:02 +0300 X-Mailer: KMail [version 1.3.1] Cc: linux-xfs@oss.sgi.com References: <200110241720.f9OHK4q29893@jen.americas.sgi.com> In-Reply-To: <200110241720.f9OHK4q29893@jen.americas.sgi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011024184528.YZVR13228.fep01-app.kolumbus.fi@there> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wednesday 24 October 2001 20:20, Steve Lord wrote: > > Hi, > > > > I just updated from CVS and the Makefile points to -pre6-xfs > > Is that correct ? I think there is official 2.4.13 already... > > > > -- > > Cheers, Hristo. > > Yes there is, and you have an option, one which does not work now, or > one which works later. > > i.e. wait for it. Linus hit the vm code again - small but significant > change. > > Steve Indeed, how can XFS save us from memory corruption, especially if those are the XFS structures ?! :) In that sense XFS is as much stable as ext2 or any other file system. Or I am wrong ? -- Cheers, Hristo. From owner-linux-xfs@oss.sgi.com Wed Oct 24 11:48:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OImpf30873 for linux-xfs-outgoing; Wed, 24 Oct 2001 11:48:51 -0700 Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OImkD30837 for ; Wed, 24 Oct 2001 11:48:46 -0700 Received: from sweeney.demon.co.uk ([158.152.71.87] helo=pereskia.sweeney.demon.co.uk) by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1) id 15wT51-0002JS-0A for linux-xfs@oss.sgi.com; Wed, 24 Oct 2001 18:48:44 +0000 Received: from rebutia.sweeney.demon.co.uk (rebutia.sweeney.demon.co.uk [10.0.0.3]) by pereskia.sweeney.demon.co.uk (Postfix) with ESMTP id EABAD27EF for ; Wed, 24 Oct 2001 19:48:40 +0100 (BST) Received: by rebutia.sweeney.demon.co.uk (Postfix, from userid 1001) id B73CA125E6; Wed, 24 Oct 2001 19:48:39 +0100 (BST) Date: Wed, 24 Oct 2001 19:48:39 +0100 (BST) From: Keith Matthews Subject: Re[2]: Makefile To: linux-xfs@oss.sgi.com In-Reply-To: <3BD7044B.5080209@orgio.net> References: , <3BD7044B.5080209@orgio.net> X-Mailer: Mahogany, 0.60 'Redmond', compiled for Linux 2.2.13 i686 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Disposition: INLINE Message-Id: <20011024184839.B73CA125E6@rebutia.sweeney.demon.co.uk> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id f9OImkD30838 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 25 Oct 2001 03:11:23 +0900 Seung-young Oh > wrote: > Adam Cioccarelli wrote: > You just couldn't resist, could you? :-) > I was very tempted, but have tried hard to look the other way! You know what Oscar Wilde said about temptation. -- Keith Matthews Spam trap - my real account at this node is keith_m Frequentous Consultants - Linux Services, Oracle development & database administration From owner-linux-xfs@oss.sgi.com Wed Oct 24 13:09:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OK9fa01941 for linux-xfs-outgoing; Wed, 24 Oct 2001 13:09:41 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OK9cD01918 for ; Wed, 24 Oct 2001 13:09:38 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA07228 for ; Wed, 24 Oct 2001 13:08:55 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA3368974; Wed, 24 Oct 2001 15:08:21 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id PAA32176; Wed, 24 Oct 2001 15:08:21 -0500 (CDT) Subject: Re: For Testing - updated RH7.1 XFS 2.4.9-6 kernels From: Eric Sandeen To: Joshua Baker-LePain Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 24 Oct 2001 15:06:43 -0500 Message-Id: <1003954003.20357.92.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ok, a "PR3" version is out there, with the nfs lockd fixes. -Eric On Wed, 2001-10-24 at 04:58, Joshua Baker-LePain wrote: > Does it/will it include the fix for the NFS locking issues which have been > reported? -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Oct 24 13:26:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OKQex02760 for linux-xfs-outgoing; Wed, 24 Oct 2001 13:26:40 -0700 Received: from cis.ohio-state.edu (root@mail.cis.ohio-state.edu [164.107.115.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OKQaD02736 for ; Wed, 24 Oct 2001 13:26:36 -0700 Received: from cis.ohio-state.edu (blitz.cis.ohio-state.edu [164.107.60.170]) by cis.ohio-state.edu (8.9.1/8.9.1) with ESMTP id QAA09280 for ; Wed, 24 Oct 2001 16:26:35 -0400 (EDT) Message-ID: <3BD723F9.5060805@cis.ohio-state.edu> Date: Wed, 24 Oct 2001 16:26:33 -0400 From: Arun Ramakrishnan Organization: Cluster I/O Lab,CIS Dept, The Ohio State Univ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Linux page cache doubt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi All, I recently read that all fs codes actually do I/O to and from the pagecache and then the dirty pages are synced to the disk later using the bdflush daemon.This approach has some performance problems when I/O is done thru write calls rather than mmap. I was just curious whether this path was modified when XFS was written ( ie how cud such a approach even work in case of jounalled file system when log operations are needed bfore the data gets written out). I am kinda newbie into kernel hacking and so i am sorry if my question sounds dumb. Cheers, Arun. -- Arun Ramakrishnan Graduate Research Assistant / Sys Admin Linux Cluster I/O Lab The Ohio State University Ph : (614)-294-5523 (H) (614)-292-4634 (O) From owner-linux-xfs@oss.sgi.com Wed Oct 24 13:27:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OKRTD02900 for linux-xfs-outgoing; Wed, 24 Oct 2001 13:27:29 -0700 Received: from relay01.cablecom.net (relay01.cablecom.net [62.2.33.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OKROD02850 for ; Wed, 24 Oct 2001 13:27:24 -0700 Received: from mail.swissonline.ch (mail.swissonline.ch [62.2.32.83]) by relay01.cablecom.net (8.11.6/8.11.4/SOL/AWF/MXRELAY/06072001) with ESMTP id f9OKRFu95200; Wed, 24 Oct 2001 22:27:15 +0200 (CEST) Received: from inf.ethz.ch (dclient217-162-214-137.hispeed.ch [217.162.214.137]) by mail.swissonline.ch (8.11.4/8.11.4/MSOL-2.30/21-Dec-2000) with ESMTP id f9OKRE327442; Wed, 24 Oct 2001 22:27:14 +0200 (MET DST) Message-ID: <3BD72420.3E2B80B@inf.ethz.ch> Date: Wed, 24 Oct 2001 22:27:12 +0200 From: Marc Schmitt X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: linux-xfs@oss.sgi.com, florin@sgi.com Subject: Re: Corruption of in-memory data detected. References: <3BD4137A.8040406@inf.ethz.ch> <1003938254.20357.76.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Eric, I took out one RAID 5 array, remains 894GB. mongo runs w/o any problems so far. That >1TB is causing the problem seem to be more and more likely. Once it's finished, I'll run mongo with ext2 instead of xfs over the 1.2TB md0 device. If the 3ware driver has a problem with file systems over 1TB, it *should* show faulty behavior with ext2fs, too. Or am I wrong? Greetz Marc Eric Sandeen wrote: > > Hi again Marc - > > Can you try chopping this down to under 1TB? Martin suggested that > there may be a sign problem in the 3ware driver; perhaps >1TB is causing > the trouble... > > -Eric > > On Mon, 2001-10-22 at 07:39, Marc Schmitt wrote: > > Hello all, > > > > I`m currently setting up a 1.2TB file server and consider using XFS. The > > configuration is: > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Oct 24 13:37:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OKbZc03506 for linux-xfs-outgoing; Wed, 24 Oct 2001 13:37:35 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OKbSD03445 for ; Wed, 24 Oct 2001 13:37:28 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id WAA638509 for ; Wed, 24 Oct 2001 22:37:28 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA3372484; Wed, 24 Oct 2001 15:36:09 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA59034; Wed, 24 Oct 2001 15:36:09 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9OKWPk32359; Wed, 24 Oct 2001 15:32:25 -0500 Message-Id: <200110242032.f9OKWPk32359@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Marc Schmitt cc: Eric Sandeen , linux-xfs@oss.sgi.com, florin@sgi.com Subject: Re: Corruption of in-memory data detected. In-Reply-To: Message from Marc Schmitt of "Wed, 24 Oct 2001 22:27:12 +0200." <3BD72420.3E2B80B@inf.ethz.ch> Date: Wed, 24 Oct 2001 15:32:25 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hi Eric, > > I took out one RAID 5 array, remains 894GB. mongo runs w/o any problems > so far. That >1TB is causing the problem seem to be more and more > likely. Since Eric is sat 2 feet from me at the moment, I will reply for him... This is good (from the point of view of xfs, not from the point of view of the 3ware drivers). Although come to think of it, the only thing which is bigger than 1 Tbyte in your configuration is the md device - perhaps md actually has some issues with 1 Tbyte. In any case, it may be worth describing the scenario on linux kernel and seeing what people think. > > Once it's finished, I'll run mongo with ext2 instead of xfs over the > 1.2TB md0 device. If the 3ware driver has a problem with file systems > over 1TB, it *should* show faulty behavior with ext2fs, too. Or am I > wrong? Yes, but the detection process may need some work - ext2 will probably have radically different behavior on an error. It may throw up on the filesystem, or you may have to run fsck afterwards to see what happened to the fs. Steve > > Greetz > Marc > > Eric Sandeen wrote: > > > > Hi again Marc - > > > > Can you try chopping this down to under 1TB? Martin suggested that > > there may be a sign problem in the 3ware driver; perhaps >1TB is causing > > the trouble... > > > > -Eric > > > > On Mon, 2001-10-22 at 07:39, Marc Schmitt wrote: > > > Hello all, > > > > > > I`m currently setting up a 1.2TB file server and consider using XFS. The > > > configuration is: > > > > -- > > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > > sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Oct 24 13:41:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OKfnk03732 for linux-xfs-outgoing; Wed, 24 Oct 2001 13:41:49 -0700 Received: from email01.aon.at (WARSL401PIP6.highway.telekom.at [195.3.96.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OKfiD03710 for ; Wed, 24 Oct 2001 13:41:45 -0700 Received: (qmail 90922 invoked from network); 24 Oct 2001 20:41:37 -0000 Received: from n860p016.dipool.highway.telekom.at (HELO ws) ([212.183.117.112]) (envelope-sender ) by qmail1.highway.telekom.at (qmail-ldap-1.03) with SMTP for ; 24 Oct 2001 20:41:37 -0000 From: "Erich Liebmann" To: Subject: compilation/revision questions Date: Wed, 24 Oct 2001 22:41:56 +0200 Message-ID: <000b01c15ccc$551444c0$0600a8c0@ws> 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.3311 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk dear technical support, first of all i want to thank all of you for porting this great filesystem to linux, it performs great on my linux box. i used the special redhat 7.1 installer supplied on the webpage to install my system with xfs. since the kernel that ships with redhat 7.1 is pretty old i downloaded the newest kernel (2.4.12) from kernel.org and applied the sgi patched supplied on the xfs webpage. everything went fine and my system boots with the new kernel but i have some questions i couldn't find on the website: 1. if i update to a new kernel is it necessary/advised to recompile the userspace tools as well. i couldn't find any relation between the userspace tool versions and the kernel versions. when is it necessary to recompile the userspace tools against a newly installed kernel? 2. there are general kernel patches available for the 2.4.12 kernel from ftp://ftp.kernel.org/pub/linux/kernel/v2.4 as well as the xfs patches available from ftp://oss.sgi.com/projects/xfs/download/patches/linux-2.4.12-xfs-2001-10 -11.patch.bz2 to enable xfs support. do those patches conflict in any way? is the order of patching important? are the sgi patches ment to be installed against the plain 2.4.12 kernel or against the 2.4.12 kernel including all the latest patches available from ftp.kernel.org? 3. is a special installer supporting xfs installation planed for the redhat 7.2 release available since a few days? when will this installer be available? [sorry for my english but i am not a native speaker] best regards and thanks in advice erich liebmann From owner-linux-xfs@oss.sgi.com Wed Oct 24 13:45:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OKjX303998 for linux-xfs-outgoing; Wed, 24 Oct 2001 13:45:33 -0700 Received: from rover (rover.mkp.net [209.217.122.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OKjTD03973 for ; Wed, 24 Oct 2001 13:45:29 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=jaguar.mkp.net) by rover with esmtp (Exim 3.33 #1) id 15wUto-0003HC-00; Wed, 24 Oct 2001 16:45:17 -0400 Received: (from mkp@localhost) by jaguar.mkp.net (8.11.2/8.9.3) id f9OKjCt13605; Wed, 24 Oct 2001 16:45:12 -0400 X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f To: Steve Lord Cc: Marc Schmitt , Eric Sandeen , linux-xfs@oss.sgi.com, florin@sgi.com Subject: Re: Corruption of in-memory data detected. References: <200110242032.f9OKWPk32359@jen.americas.sgi.com> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 24 Oct 2001 16:45:10 -0400 In-Reply-To: <200110242032.f9OKWPk32359@jen.americas.sgi.com> Message-ID: Lines: 20 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>>>> "Steve" == Steve Lord writes: Steve> Since Eric is sat 2 feet from me at the moment, I will reply Steve> for him... This is good (from the point of view of xfs, not Steve> from the point of view of the 3ware drivers). Although come to Steve> think of it, the only thing which is bigger than 1 Tbyte in Steve> your configuration is the md device *nod* Steve> - perhaps md actually has some issues with 1 Tbyte. Yeah, as I just told Eric I'm going to take a look at MD and see if I can spot obvious signedness errors. -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Wed Oct 24 13:47:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OKlbD04161 for linux-xfs-outgoing; Wed, 24 Oct 2001 13:47:37 -0700 Received: from chef.cc.absoval.com (cpe-66-1-218-101.fl.sprintbbd.net [66.1.218.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OKlXD04139 for ; Wed, 24 Oct 2001 13:47:33 -0700 Received: from ieee.org (IDENT:bs@thebs.cc.absoval.com [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id QAA24070; Wed, 24 Oct 2001 16:47:20 -0400 Message-ID: <3BD728E2.905F38FD@ieee.org> Date: Wed, 24 Oct 2001 16:47:30 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts/AbsoluteValueSystems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Marc Schmitt CC: Eric Sandeen , linux-xfs@oss.sgi.com, florin@sgi.com Subject: Re: Corruption of in-memory data detected. References: <3BD4137A.8040406@inf.ethz.ch> <1003938254.20357.76.camel@stout.americas.sgi.com> <3BD72420.3E2B80B@inf.ethz.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Marc Schmitt wrote: > Once it's finished, I'll run mongo with ext2 instead of xfs over the > 1.2TB md0 device. If the 3ware driver has a problem with file systems > over 1TB, it *should* show faulty behavior with ext2fs, too. Or am I > wrong? Dumb question: Why are you using the md0 device? 3Ware uses the sdX0 devices, right? Or are you appending/striping/mirroring across multiple 3Ware devices? If so, then your issue is probably not the 3Ware drivers. -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ---------------------------------------------------------------- Web site defacements are as much of a national security risk as inner city kids spray painting. There is nothing of value, and nothing that can't be fixed with a little re-paint. You'd have to have the equivalent stupidity of someone parking an F-18 in downtown LA. Even then, the only damage would be a new scheme! The US government wants life imprisonment for such "terrorism." From owner-linux-xfs@oss.sgi.com Wed Oct 24 13:51:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OKpcW04450 for linux-xfs-outgoing; Wed, 24 Oct 2001 13:51:38 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OKpXD04425 for ; Wed, 24 Oct 2001 13:51:33 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9OKpSW00533 for ; Wed, 24 Oct 2001 13:51:28 -0700 Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA3395207; Wed, 24 Oct 2001 15:50:12 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id PAA39014; Wed, 24 Oct 2001 15:50:12 -0500 (CDT) Subject: Re: compilation/revision questions From: Eric Sandeen To: Erich Liebmann Cc: linux-xfs@oss.sgi.com In-Reply-To: <000b01c15ccc$551444c0$0600a8c0@ws> References: <000b01c15ccc$551444c0$0600a8c0@ws> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 24 Oct 2001 15:48:34 -0500 Message-Id: <1003956514.21961.100.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2001-10-24 at 15:41, Erich Liebmann wrote: > dear technical support, :) > 1. if i update to a new kernel is it necessary/advised to recompile the > userspace tools as well. i couldn't find any relation between the > userspace tool versions and the kernel versions. when is it necessary to > recompile the userspace tools against a newly installed kernel? In general, there are not dependencies between the kernel version and the userspace tools. Tools from 1.0.1 should work fine, later revisions have more features & bugfixes. > 2. there are general kernel patches available for the 2.4.12 kernel from > ftp://ftp.kernel.org/pub/linux/kernel/v2.4 as well as the xfs patches > available from > ftp://oss.sgi.com/projects/xfs/download/patches/linux-2.4.12-xfs-2001-10 > -11.patch.bz2 to enable xfs support. do those patches conflict in any > way? is the order of patching important? are the sgi patches ment to be > installed against the plain 2.4.12 kernel or against the 2.4.12 kernel > including all the latest patches available from ftp.kernel.org? Hm... the patches we generate for 2.4.X are meant to be applied against a clean 2.4.X kernel.. .not sure what you mean about the other patches on kernel.org? i.e. if you get linux-2.4.12.tar.bz2 and unpack it, our linux-2.4.12-xfs-2001-10-11.patch.bz2 patch will apply cleanly against it. > 3. is a special installer supporting xfs installation planed for the > redhat 7.2 release available since a few days? when will this installer > be available? This is quite a faq these days, but yes, and sometime fairly soon I hope. :) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Oct 24 14:08:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OL8W205146 for linux-xfs-outgoing; Wed, 24 Oct 2001 14:08:32 -0700 Received: from email04.aon.at (WARSL401PIP6.highway.telekom.at [195.3.96.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OL8QD05116 for ; Wed, 24 Oct 2001 14:08:26 -0700 Received: (qmail 194662 invoked from network); 24 Oct 2001 21:08:20 -0000 Received: from n860p016.dipool.highway.telekom.at (HELO ws) ([212.183.117.112]) (envelope-sender ) by qmail4.highway.telekom.at (qmail-ldap-1.03) with SMTP for ; 24 Oct 2001 21:08:20 -0000 From: "Erich Liebmann" To: "'Eric Sandeen'" Cc: Subject: RE: compilation/revision questions Date: Wed, 24 Oct 2001 23:08:38 +0200 Message-ID: <000c01c15cd0$1049ceb0$0600a8c0@ws> 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.3311 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <1003956514.21961.100.camel@stout.americas.sgi.com> Importance: Normal Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi eric, first of all thanks for you quick reply... > > 2. there are general kernel patches available for the 2.4.12 kernel > > from ftp://ftp.kernel.org/pub/linux/kernel/v2.4 as well as the xfs > > patches available from > > > ftp://oss.sgi.com/projects/xfs/download/patche> s/linux-2.4.12-xfs-2001- > > 10 > > -11.patch.bz2 to enable xfs support. do those patches > conflict in any > > way? is the order of patching important? are the sgi > patches ment to be > > installed against the plain 2.4.12 kernel or against the > 2.4.12 kernel > > including all the latest patches available from ftp.kernel.org? > > Hm... the patches we generate for 2.4.X are meant to be > applied against a clean 2.4.X kernel.. .not sure what you > mean about the other patches on kernel.org? > > i.e. if you get linux-2.4.12.tar.bz2 and unpack it, our > linux-2.4.12-xfs-2001-10-11.patch.bz2 patch will apply > cleanly against it. well as far as i know if they find a bug in the kernel they release a patchfile for it which can be found on the ftp.kernel.org host. for example if you download the kernel from ftp://ftp.kernel.org/pub/linux/kernel/v2.4/patch-2.4.12.bz2 you can download the latest patches for it from ftp://ftp.kernel.org/pub/linux/kernel/v2.4/patch-2.4.12.gz. (maybe i am completely wrong with this, if though please point me in the right direction, but thats the way i always thought it works). so we now have two patches to apply to the 2.4.12 kernel let's call the first "original patch" and the second "sgi patch": ftp://ftp.kernel.org/pub/linux/kernel/v2.4/patch-2.4.12.bz2 ftp://oss.sgi.com/projects/xfs/download/patches/linux-2.4.12-xfs-2001-10 -11.patch.bz2 are the "sgi patches" meant to be installed against the plain 2.4.12 kernel or against the 2.4.12 kernel + "original patch"? is the order important in which "original patch" and "sgi patch" are applied? do they conflict in any way? best regards and thanks in advice erich liebmann From owner-linux-xfs@oss.sgi.com Wed Oct 24 14:11:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OLB8305281 for linux-xfs-outgoing; Wed, 24 Oct 2001 14:11:08 -0700 Received: from relay02.cablecom.net (relay02.cablecom.net [62.2.33.102]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OLB5D05259 for ; Wed, 24 Oct 2001 14:11:05 -0700 Received: from mail.swissonline.ch (mail.swissonline.ch [62.2.32.83]) by relay02.cablecom.net (8.11.6/8.11.4/SOL/AWF/MXRELAY/06072001) with ESMTP id f9OLAwc71380; Wed, 24 Oct 2001 23:10:58 +0200 (CEST) Received: from inf.ethz.ch (dclient217-162-214-137.hispeed.ch [217.162.214.137]) by mail.swissonline.ch (8.11.4/8.11.4/MSOL-2.30/21-Dec-2000) with ESMTP id f9OLAw320027; Wed, 24 Oct 2001 23:10:58 +0200 (MET DST) Message-ID: <3BD72E5F.7C86D21@inf.ethz.ch> Date: Wed, 24 Oct 2001 23:10:55 +0200 From: Marc Schmitt X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bryan-TheBS-Smith CC: linux-xfs@oss.sgi.com Subject: Re: Corruption of in-memory data detected. References: <3BD4137A.8040406@inf.ethz.ch> <1003938254.20357.76.camel@stout.americas.sgi.com> <3BD72420.3E2B80B@inf.ethz.ch> <3BD728E2.905F38FD@ieee.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Bryan, Please check the initial post: Quoted: - STL2 MB with 512MB RAM, 2 CPUs (866MHz) - 3 x 3ware RAID Controller - 20 x 80GB disks attached in blocks of 4 with RAID 5 (5x240GB) - md0 is a RAID 0 over the 5 RAID 5 devices Greetz Marc Bryan-TheBS-Smith wrote: > Dumb question: > Why are you using the md0 device? 3Ware uses the sdX0 devices, > right? Or are you appending/striping/mirroring across multiple > 3Ware devices? If so, then your issue is probably not the 3Ware > drivers. > > -- TheBS From owner-linux-xfs@oss.sgi.com Wed Oct 24 14:16:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OLGPs05649 for linux-xfs-outgoing; Wed, 24 Oct 2001 14:16:25 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OLGLD05627 for ; Wed, 24 Oct 2001 14:16:21 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9OLGGW02015 for ; Wed, 24 Oct 2001 14:16:16 -0700 Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA3393637; Wed, 24 Oct 2001 16:15:00 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id QAA25046; Wed, 24 Oct 2001 16:14:59 -0500 (CDT) Subject: RE: compilation/revision questions From: Eric Sandeen To: Erich Liebmann Cc: linux-xfs@oss.sgi.com In-Reply-To: <000c01c15cd0$1049ceb0$0600a8c0@ws> References: <000c01c15cd0$1049ceb0$0600a8c0@ws> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 24 Oct 2001 16:13:21 -0500 Message-Id: <1003958001.21961.104.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Erich - On Wed, 2001-10-24 at 16:08, Erich Liebmann wrote: > well as far as i know if they find a bug in the kernel they release a > patchfile for it which can be found on the ftp.kernel.org host. for > example if you download the kernel from > ftp://ftp.kernel.org/pub/linux/kernel/v2.4/patch-2.4.12.bz2 you can > download the latest patches for it from > ftp://ftp.kernel.org/pub/linux/kernel/v2.4/patch-2.4.12.gz. > (maybe i am completely wrong with this, if though please point me in the > right direction, but thats the way i always thought it works). You are a bit wrong... :) patch-2.4.12.gz is a patch that will bring a 2.4.11 kernel up to 2.4.12 - in a sense, yes, they're bugfixes (or bug additions!) but the patch-2.4.12 is _not_ against a 2.4.12 kernel. > so we now have two patches to apply to the 2.4.12 kernel nope, you can't apply the patch-2.4.12.gz patch to a 2.4.12 kernel, it's already in there. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Oct 24 14:23:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OLNXS05976 for linux-xfs-outgoing; Wed, 24 Oct 2001 14:23:33 -0700 Received: from chef.cc.absoval.com (cpe-66-1-218-101.fl.sprintbbd.net [66.1.218.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OLNSD05947 for ; Wed, 24 Oct 2001 14:23:28 -0700 Received: from ieee.org (IDENT:bs@thebs.cc.absoval.com [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id RAA24299; Wed, 24 Oct 2001 17:23:19 -0400 Message-ID: <3BD73151.B7309128@ieee.org> Date: Wed, 24 Oct 2001 17:23:29 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts/AbsoluteValueSystems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Marc Schmitt CC: linux-xfs@oss.sgi.com Subject: Re: Corruption of in-memory data detected. References: <3BD4137A.8040406@inf.ethz.ch> <1003938254.20357.76.camel@stout.americas.sgi.com> <3BD72420.3E2B80B@inf.ethz.ch> <3BD728E2.905F38FD@ieee.org> <3BD72E5F.7C86D21@inf.ethz.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Marc Schmitt wrote: > Hi Bryan, > Please check the initial post: > Quoted: > - STL2 MB with 512MB RAM, 2 CPUs (866MHz) > - 3 x 3ware RAID Controller > - 20 x 80GB disks attached in blocks of 4 with RAID 5 (5x240GB) > - md0 is a RAID 0 over the 5 RAID 5 devices My appologize since I missed it. I hope you are mainly reading from those RAID-5 arrays, because 3Ware stinks at RAID-5 write performance. Just not enough RAM (since they use SRAM, instead of SDRAM). Reading is phenominal though, as well as read/write performace for RAID-0, 1 and 0+1. -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ---------------------------------------------------------------- Web site defacements are as much of a national security risk as inner city kids spray painting. There is nothing of value, and nothing that can't be fixed with a little re-paint. You'd have to have the equivalent stupidity of someone parking an F-18 in downtown LA. Even then, the only damage would be a new scheme! The US government wants life imprisonment for such "terrorism." From owner-linux-xfs@oss.sgi.com Wed Oct 24 14:25:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OLPkA06200 for linux-xfs-outgoing; Wed, 24 Oct 2001 14:25:46 -0700 Received: from email03.aon.at (WARSL401PIP6.highway.telekom.at [195.3.96.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OLPfD06178 for ; Wed, 24 Oct 2001 14:25:42 -0700 Received: (qmail 328624 invoked from network); 24 Oct 2001 21:25:30 -0000 Received: from n860p016.dipool.highway.telekom.at (HELO ws) ([212.183.117.112]) (envelope-sender ) by qmail3.highway.telekom.at (qmail-ldap-1.03) with SMTP for ; 24 Oct 2001 21:25:30 -0000 From: "Erich Liebmann" To: "'Eric Sandeen'" Cc: Subject: RE: compilation/revision questions Date: Wed, 24 Oct 2001 23:25:48 +0200 Message-ID: <000d01c15cd2$761d6510$0600a8c0@ws> 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.3311 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <1003958001.21961.104.camel@stout.americas.sgi.com> Importance: Normal Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi eric, > > well as far as i know if they find a bug in the kernel they > release a > > patchfile for it which can be found on the ftp.kernel.org host. for > > example if you download the kernel from > > ftp://ftp.kernel.org/pub/linux/kernel/v2.4/patch-2.4.12.bz2 you can > > download the latest patches for it from > > ftp://ftp.kernel.org/pub/linux/kernel/v2.4/patch-2.4.12.gz. > > (maybe i am completely wrong with this, if though please > point me in > > the right direction, but thats the way i always thought it works). > > You are a bit wrong... :) patch-2.4.12.gz is a patch that > will bring a 2.4.11 kernel up to 2.4.12 - in a sense, yes, > they're bugfixes (or bug > additions!) but the patch-2.4.12 is _not_ against a 2.4.12 kernel. > > > so we now have two patches to apply to the 2.4.12 kernel > > nope, you can't apply the patch-2.4.12.gz patch to a 2.4.12 > kernel, it's already in there. oh i see, well this answers why i couldn't apply it to the 2.4.12 kernel :-> thanks for all your valuable input... best regards erich liebmann From owner-linux-xfs@oss.sgi.com Wed Oct 24 15:41:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OMfrl08057 for linux-xfs-outgoing; Wed, 24 Oct 2001 15:41:53 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OMfmD08035 for ; Wed, 24 Oct 2001 15:41:48 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9OMfhW06093 for ; Wed, 24 Oct 2001 15:41:43 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA3394102; Wed, 24 Oct 2001 17:40:27 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA63845; Wed, 24 Oct 2001 17:40:26 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9OMagj06647; Wed, 24 Oct 2001 17:36:42 -0500 Message-Id: <200110242236.f9OMagj06647@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Arun Ramakrishnan cc: linux-xfs@oss.sgi.com Subject: Re: Linux page cache doubt In-Reply-To: Message from Arun Ramakrishnan of "Wed, 24 Oct 2001 16:26:33 EDT." <3BD723F9.5060805@cis.ohio-state.edu> Date: Wed, 24 Oct 2001 17:36:41 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hi All, > I recently read that all fs codes actually do I/O to and from the > pagecache and then the dirty pages are synced to the disk later using > the bdflush daemon.This approach has some performance problems when I/O > is done thru write calls rather than mmap. I was just curious whether > this path was modified when XFS was written ( ie how cud such a approach > even work in case of jounalled file system when log operations are > needed bfore the data gets written out). > I am kinda newbie into kernel hacking and so i am sorry if my question > sounds dumb. Hi Arun, well filesystem I/O is divided into two chunks - file data which is definitely page cache based, and metadata which is done through various means depending on: o which kernel you are running o which filesystem All filesystems that I am aware of except for XFS use buffer heads and the block cache for metadata I/O. bdflush is responsible for flushing the data unless the filesystem makes explicit requests. XFS does its own thing using pagebufs because we came from a totally different buffer cache architecture, and because we got a little ambitous with our implementation. XFS needs to lock variable sized objects, everyone else uses fixed sizes for the most part. XFS also wants some other behaviors from its buffer cache. This is where pagebuf came from. Having said that, recent linux kernels have the buffer cache layered on top of an address space in a similar manner to how pagebuf does it. I am working on making the two address spaces the same one because 2.4.13 seems to have changed things sufficiently to break some tests on xfs - our user space utilities and the kernel are not agreeing on the state of the filesystem. Steve > Cheers, > Arun. > > -- > Arun Ramakrishnan > Graduate Research Assistant / Sys Admin > Linux Cluster I/O Lab > The Ohio State University > > Ph : (614)-294-5523 (H) > (614)-292-4634 (O) > From owner-linux-xfs@oss.sgi.com Wed Oct 24 16:20:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ONK4p12321 for linux-xfs-outgoing; Wed, 24 Oct 2001 16:20:04 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ONJxD12295 for ; Wed, 24 Oct 2001 16:19:59 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id D911A1E822; Thu, 25 Oct 2001 01:19:53 +0200 (MEST) Date: Thu, 25 Oct 2001 01:19:51 +0200 From: Andi Kleen To: Steve Lord Cc: Arun Ramakrishnan , linux-xfs@oss.sgi.com Subject: Re: Linux page cache doubt Message-ID: <20011025011951.A11541@wotan.suse.de> References: <200110242236.f9OMagj06647@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.16i In-Reply-To: <200110242236.f9OMagj06647@jen.americas.sgi.com>; from lord@sgi.com on Wed, Oct 24, 2001 at 05:36:41PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Oct 24, 2001 at 05:36:41PM -0500, Steve Lord wrote: > various means depending on: > > o which kernel you are running > o which filesystem > > All filesystems that I am aware of except for XFS use buffer heads and the > block cache for metadata I/O. bdflush is responsible for flushing the data (minor nit) Newer 2.4 ext2 uses pagecache metadata too (since somewhere in early 2.5^W2.4) > Having said that, recent linux kernels have the buffer cache layered on top > of an address space in a similar manner to how pagebuf does it. I am working > on making the two address spaces the same one because 2.4.13 seems to have > changed things sufficiently to break some tests on xfs - our user space > utilities and the kernel are not agreeing on the state of the filesystem. It'll only work for metadata of course because the inodes have their own address space... so dump remains somewhat problematic :/ -Andi From owner-linux-xfs@oss.sgi.com Wed Oct 24 16:38:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ONc7E12897 for linux-xfs-outgoing; Wed, 24 Oct 2001 16:38:07 -0700 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ONc2D12873 for ; Wed, 24 Oct 2001 16:38:03 -0700 Received: (qmail 22154 invoked from network); 24 Oct 2001 23:37:59 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 24 Oct 2001 23:37:59 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 04C40300090; Thu, 25 Oct 2001 09:37:57 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id BBF6298; Thu, 25 Oct 2001 09:37:57 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: J Landman Cc: linux-xfs@oss.sgi.com Subject: Re: question on include files for building from CVS In-reply-to: Your message of "Wed, 24 Oct 2001 12:32:33 -0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Oct 2001 09:37:52 +1000 Message-ID: <21049.1003966672@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 24 Oct 2001 12:32:33 -0400 (EDT), J Landman wrote: >Ok, so making progress. Copied from 2.4.13 tree > > 53c8xx_d.h > 53c8xx_u.h > >Now running into problems with the compaq FC stuff... might just disable >it. The compaq FC stuff has not compiled in Linus's tree since it went in. AC has patches that Linus has not accepted yet, not an XFS problem. I removed the generated drivers/scsi/*_[ud].h files from the XFS tree, files should not be both generated and shipped, that practice causes problems for source repositories. Alas there is a dependency missing from the Makefile. Add this line to drivers/scsi/Makefile 53c7,8xx.o: 53c8xx_u.h 53c8xx_d.h From owner-linux-xfs@oss.sgi.com Wed Oct 24 17:12:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9P0CpN14929 for linux-xfs-outgoing; Wed, 24 Oct 2001 17:12:51 -0700 Received: from relay02.cablecom.net (relay02.cablecom.net [62.2.33.102]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9P0CmD14904 for ; Wed, 24 Oct 2001 17:12:49 -0700 Received: from mail.swissonline.ch (mail.swissonline.ch [62.2.32.83]) by relay02.cablecom.net (8.11.6/8.11.4/SOL/AWF/MXRELAY/06072001) with ESMTP id f9P0Cfc00514 for ; Thu, 25 Oct 2001 02:12:41 +0200 (CEST) Received: from unspecified.host (dclient217-162-144-101.hispeed.ch [217.162.144.101]) by mail.swissonline.ch (8.11.4/8.11.4/MSOL-2.30/21-Dec-2000) with SMTP id f9P0Cf313119 for ; Thu, 25 Oct 2001 02:12:41 +0200 (MET DST) Received: from 192.168.0.15 ([192.168.0.15]) by 192.168.0.1 (WinRoute Pro 4.1) with SMTP; Thu, 25 Oct 2001 02:23:06 +0200 Message-ID: <200110250213370058.255D0A31@192.168.0.1> X-Mailer: Calypso Version 3.30.00.00 (4) Date: Thu, 25 Oct 2001 02:13:37 +0200 From: "Stevan Bajic" To: linux-xfs@oss.sgi.com Subject: XFS for RedHat Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f9P0CnD14908 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi I'am using RedHat 7.1 with SGI XFS and I'am very happy with it. Now I see, that RedHat has a new version (7.2) out. Are there any plans to produca a RedHat 7.2 installation CDROM (like te one for RedHat 7.1)? Kind Regards Stevan Bajic From owner-linux-xfs@oss.sgi.com Wed Oct 24 17:38:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9P0cqP16026 for linux-xfs-outgoing; Wed, 24 Oct 2001 17:38:52 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9P0clD16004 for ; Wed, 24 Oct 2001 17:38:47 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id RAA12287 for ; Wed, 24 Oct 2001 17:38:41 -0700 (PDT) mail_from (ivanr@sgi.com) From: ivanr@sgi.com Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA04392; Thu, 25 Oct 2001 10:37:29 +1000 Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id KAA81026; Thu, 25 Oct 2001 10:37:29 +1000 (EST) X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs Date: Thu, 25 Oct 2001 10:37:28 +1000 X-X-Sender: ivanr@omen.melbourne.sgi.com To: Vincent Bernat cc: linux-xfs@oss.sgi.com Subject: Re: Is restore FS-independant ? In-Reply-To: <200110241347.f9ODlnI15296@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 24 Oct 2001, Steve Lord wrote: > > I would like to know if xfsrestore can be issued on a file system > > which is not XFS and which doesn't have all the possibilities of it ? > > The latest version should not complain about missing xfs functionality > in a filesystem, and does not need to sit in a directory on an xfs > filesystem to run. I am not sure what happens if you attempt to restore > files with quotas and extended attributes though. Apart from that it should > work. xfsrestore could always restore to a non-xfs filesystem, but it would issue some harmless warnings which have recently been removed. However, it wont be able to restore extended attributes, and though I've never tried it, I expect it'll just give a warning and continue to restore files. (ACLs and DMAPI attributes are stored in extended attributes) Quota information is stored in the dump as a regular file (ie. the output of repquota in IRIX or xfsdq in Linux), and that file will get restored without a problem. It's up to the admin to reinstate the quotas if needed using edquota. Oh, and until recently, xfsrestore -t (ie. get the table of contents of a dump) would fail if the current working directory was not xfs. 'Course the real question is ... why would you want to run any other filesystem than XFS in the first place? :) Ivan -- Ivan Rayner ivanr@sgi.com From owner-linux-xfs@oss.sgi.com Wed Oct 24 17:46:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9P0kng16298 for linux-xfs-outgoing; Wed, 24 Oct 2001 17:46:49 -0700 Received: from rover (rover.mkp.net [209.217.122.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9P0kjD16276 for ; Wed, 24 Oct 2001 17:46:45 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=jaguar.mkp.net) by rover with esmtp (Exim 3.33 #1) id 15wYfR-00048S-00; Wed, 24 Oct 2001 20:46:43 -0400 Received: (from mkp@localhost) by jaguar.mkp.net (8.11.2/8.9.3) id f9P0kH313797; Wed, 24 Oct 2001 20:46:18 -0400 X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f To: "Stevan Bajic" Cc: linux-xfs@oss.sgi.com Subject: Re: XFS for RedHat References: <200110250213370058.255D0A31@192.168.0.1> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 24 Oct 2001 20:46:16 -0400 In-Reply-To: <200110250213370058.255D0A31@192.168.0.1> Message-ID: Lines: 23 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>>>> "Stevan" == Stevan Bajic writes: Stevan> Hi I'am using RedHat 7.1 with SGI XFS and I'am very happy with Stevan> it. Now I see, that RedHat has a new version (7.2) out. Are Stevan> there any plans to produca a RedHat 7.2 installation CDROM Stevan> (like te one for RedHat 7.1)? Congratulations! You are person number 1000 to ask that question this week. As a token of appreciation, contact your local SGI branch office to claim your FREE blade-less ginzu knife without handle. But wait! There's more! If you hang on for a couple of days you may find what you are looking for on oss.sgi.com. An XFS-aware Red Hat 7.2 installer preview. FREE OF CHARGE! Yes, that's right. This wonderful stream of data can be yours for only $0.00*. *) A minimum of 1 download per customer is required to participate in beta testing programme. Rough conditions may apply. -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Wed Oct 24 20:10:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9P3ApV29963 for linux-xfs-outgoing; Wed, 24 Oct 2001 20:10:51 -0700 Received: from raven.mail.pas.earthlink.net (raven.mail.pas.earthlink.net [207.217.120.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9P3AkD29941 for ; Wed, 24 Oct 2001 20:10:46 -0700 Received: from static031-81-151-24.nm01-c3.cpe.charter-ne.com ([24.151.81.31] helo=dhcp10) by raven.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 15wauq-00020o-00; Wed, 24 Oct 2001 20:10:44 -0700 Message-ID: <001901c15d02$7e498630$0a00a8c0@intranet.mp3s.com> Reply-To: "Sean Elble" From: "Sean Elble" To: "Stevan Bajic" , "Martin K. Petersen" Cc: References: <200110250213370058.255D0A31@192.168.0.1> Subject: Re: XFS for RedHat Date: Wed, 24 Oct 2001 23:09:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk You know it would've taken less time just to say there's a beta coming up, right? :-) I just love sarcasm . . . -------------------------------------------- Sean P. Elble Editor, Writer, Co-Webmaster MaximumLinux.org http://www.maximumlinux.org/ elbles@maximumlinux.org -------------------------------------------- ----- Original Message ----- From: "Martin K. Petersen" To: "Stevan Bajic" Cc: Sent: Wednesday, October 24, 2001 8:46 PM Subject: Re: XFS for RedHat > >>>>> "Stevan" == Stevan Bajic writes: > > Stevan> Hi I'am using RedHat 7.1 with SGI XFS and I'am very happy with > Stevan> it. Now I see, that RedHat has a new version (7.2) out. Are > Stevan> there any plans to produca a RedHat 7.2 installation CDROM > Stevan> (like te one for RedHat 7.1)? > > Congratulations! You are person number 1000 to ask that question this > week. As a token of appreciation, contact your local SGI branch > office to claim your FREE blade-less ginzu knife without handle. > > But wait! There's more! If you hang on for a couple of days you may > find what you are looking for on oss.sgi.com. An XFS-aware Red Hat > 7.2 installer preview. FREE OF CHARGE! Yes, that's right. This > wonderful stream of data can be yours for only $0.00*. > > *) A minimum of 1 download per customer is required to participate in > beta testing programme. Rough conditions may apply. > > -- > Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. > mkp@linuxcare.com, http://www.linuxcare.com/ > SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Wed Oct 24 20:26:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9P3QP230480 for linux-xfs-outgoing; Wed, 24 Oct 2001 20:26:25 -0700 Received: from plato.arts.usyd.edu.au (plato.arts.usyd.edu.au [129.78.16.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9P3QHD30453 for ; Wed, 24 Oct 2001 20:26:17 -0700 Received: from arts.usyd.edu.au (IDENT:matthew@whitestar.arts.usyd.edu.au [129.78.16.20]) by plato.arts.usyd.edu.au (8.9.3/8.9.3) with ESMTP id NAA13241; Thu, 25 Oct 2001 13:26:03 +1000 (EST) Message-ID: <3BD7864A.CF036FD9@arts.usyd.edu.au> Date: Thu, 25 Oct 2001 13:26:02 +1000 From: Matthew Geier Organization: Arts IT Unit, Sydney University X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.7-pre6-xfs i686) X-Accept-Language: en, pdf MIME-Version: 1.0 To: "Martin K. Petersen" CC: Stevan Bajic , linux-xfs@oss.sgi.com Subject: Re: XFS for RedHat References: <200110250213370058.255D0A31@192.168.0.1> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms6277984850F5ADB24ABF59CB" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms6277984850F5ADB24ABF59CB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Martin K. Petersen" wrote: > > But wait! There's more! If you hang on for a couple of days you may > find what you are looking for on oss.sgi.com. An XFS-aware Red Hat > 7.2 installer preview. FREE OF CHARGE! Yes, that's right. This > wonderful stream of data can be yours for only $0.00*. > > *) A minimum of 1 download per customer is required to participate in > beta testing programme. Rough conditions may apply. Not including any charges levied by your ISP for data transfer. (I'm volume charged, so the 'free' download is not free). We have a fun time here trying to explain to people how downloading MP3s (and other stuff) is not 'free' and how we noticed their downloading of MP3s by the $200 volume charge bill against their workstation for the previous month.... -- Matthew Geier matthew@arts.usyd.edu.au Arts IT Unit +61 2 9351 4713 Sydney University --------------ms6277984850F5ADB24ABF59CB Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIH0AYJKoZIhvcNAQcCoIIHwTCCB70CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BbswggKKMIIB86ADAgECAgMFMYswDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMTA3MDkxOTEyNThaFw0wMjA3MDkxOTEyNTha MEoxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxJzAlBgkqhkiG9w0BCQEWGG1h dHRoZXdAYXJ0cy51c3lkLmVkdS5hdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA1H+o MQ4xn5lDS/7p9rYboPW7grw13lXOj7Xisip37QttkX7Ga3ITBXnsAKnuFK3Z7GtILACBXil1 BngLBOd0AlW9zqQBXEOP9aODNJzBsTb3+tOHwQo6shcORKQArKEinG00SuwBdzxALU3KWT6E yIUSvoz7q0PN4C8qUF3t00sCAwEAAaM1MDMwIwYDVR0RBBwwGoEYbWF0dGhld0BhcnRzLnVz eWQuZWR1LmF1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAiJu7SNBXsW7I+ZH9 e2+0M47BmR3DxV31VbW9mKcwuamusWSJJEy5MAKZc8b0snRX/XDkCpM+av3VxDJX8T3rxOE0 siyCC6Tclu6wjwjw0goXK4N6Xhsz+qwIfdoclNZkqK5yInEZtc5ijKr0IPRgch79f35WP82C SNHVYApmjzgwggMpMIICkqADAgECAgEMMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJa QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoT EVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERp dmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG 9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMwMDAwMDAwWhcN MDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES MBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmlj YXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNE KYpjNSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu 2HL5ugL217CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQAB o04wTDApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0T AQH/BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0 S1liiu1EvknH6A27j7kNaiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHC CafvS65y3QZn9VBvLli4tgvBUFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+p lrgFPFL83eliA0gxggHdMIIB2QIBATCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNV BAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBS U0EgMjAwMC44LjMwAgMFMYswCQYFKw4DAhoFAKCBmTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wMTEwMjUwMzI2MDNaMCMGCSqGSIb3DQEJBDEWBBREptlL tLDRq1YDlqjP6Yd4AmXCtTA6BgkqhkiG9w0BCQ8xLTArMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDANBgkqhkiG9w0BAQEFAASBgKvUb1GT9510I09pPexM vHk2/OT9f2IzRSlxoM3HUAKW5nlFrHeSqLGUh7uVKZhGRf27ru7E8stbtjOhMe7vVME94+9J zrCK6+lkHLawVF8S+ck0b76DdTijFtG+sRk7GQEylfws80MfXK/9NxrLCBsC7G1g8jQCaR76 4LCrLtSE --------------ms6277984850F5ADB24ABF59CB-- From owner-linux-xfs@oss.sgi.com Wed Oct 24 20:39:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9P3d8W31061 for linux-xfs-outgoing; Wed, 24 Oct 2001 20:39:08 -0700 Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com [132.233.247.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9P3d1D31039 for ; Wed, 24 Oct 2001 20:39:06 -0700 Received: from fmsmsxvs043.fm.intel.com (fmsmsxv043-1.fm.intel.com [132.233.48.128]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.44 2001/10/01 19:10:43 root Exp $) with SMTP id DAA25742 for ; Thu, 25 Oct 2001 03:39:01 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001102420381629309 for ; Wed, 24 Oct 2001 20:38:16 -0700 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Oct 2001 20:39:19 -0700 Received: from fmsmsxfw01.fm.intel.com ([10.1.199.21]) by fmsmsx27.fm.intel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VBNDVP72; Wed, 24 Oct 2001 20:39:40 -0700 Received: by fmsmsxfw01.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Oct 2001 11:40:29 +0800 Message-ID: <957BD1C2BF3CD411B6C500A0C944CA260A0FC3@pdsmsx32.pd.intel.com> From: "Xie, May" To: "'linux-xfs@oss.sgi.com.'" Subject: Where is the xfs patch for kernel 2.4.2? Date: Thu, 25 Oct 2001 11:37:29 +0800 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, Could you tell me where I can find xfs patch for linux kernel 2.4.2? For some reason, I should try to patch xfs on the certain kernel 2.4.2. Where can I get them? Is there a stable patch for 2.4.2? Any testing suites for it? Thanks, May From owner-linux-xfs@oss.sgi.com Wed Oct 24 23:39:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9P6d0N15479 for linux-xfs-outgoing; Wed, 24 Oct 2001 23:39:00 -0700 Received: from ns.caldera.de (ns.caldera.de [212.34.180.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9P6cuD15457 for ; Wed, 24 Oct 2001 23:38:56 -0700 Received: (from hch@localhost) by ns.caldera.de (8.11.1/8.11.1) id f9P6bf203294; Thu, 25 Oct 2001 08:37:41 +0200 Date: Thu, 25 Oct 2001 08:37:41 +0200 From: Christoph Hellwig To: Steve Lord Cc: Arun Ramakrishnan , linux-xfs@oss.sgi.com Subject: Re: Linux page cache doubt Message-ID: <20011025083741.A3180@caldera.de> References: <200110242236.f9OMagj06647@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200110242236.f9OMagj06647@jen.americas.sgi.com>; from lord@sgi.com on Wed, Oct 24, 2001 at 05:36:41PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Oct 24, 2001 at 05:36:41PM -0500, Steve Lord wrote: > Hi Arun, well filesystem I/O is divided into two chunks - file data > which is definitely page cache based, and metadata which is done through > various means depending on: > > o which kernel you are running > o which filesystem > > All filesystems that I am aware of except for XFS use buffer heads and the > block cache for metadata I/O. JFS uses the pagecache for all I/O - for metadata they have an additional 'metapage' abstraction. Christoph -- Of course it doesn't work. We've performed a software upgrade. From owner-linux-xfs@oss.sgi.com Thu Oct 25 03:12:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PACSP31395 for linux-xfs-outgoing; Thu, 25 Oct 2001 03:12:28 -0700 Received: from mailgate.rz.uni-karlsruhe.de (exim@mailgate.rz.uni-karlsruhe.de [129.13.64.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PABbD31368 for ; Thu, 25 Oct 2001 03:11:37 -0700 Received: from ukav95.verwaltung.uni-karlsruhe.de (ukav95.verwaltung.uni-karlsruhe.de [129.13.155.95]) by mailgate.rz.uni-karlsruhe.de with esmtp (Exim 3.16 #1) id 15whU7-0001sF-00; Thu, 25 Oct 2001 12:11:35 +0200 Received: from ukav133.verwaltung.uni-karlsruhe.de (verwaltung.uni-karlsruhe.de) [129.13.155.133] (root) by ukav95.verwaltung.uni-karlsruhe.de with esmtp (Exim 3.20 #1 (Debian)) id 15whU7-00039u-00; Thu, 25 Oct 2001 12:11:35 +0200 Message-ID: <3BD7E604.1FE3F2A2@verwaltung.uni-karlsruhe.de> Date: Thu, 25 Oct 2001 12:14:28 +0200 From: root Organization: =?iso-8859-1?Q?Universit=E4t?= Karlsruhe (TH) X-Mailer: Mozilla 4.78 [de] (X11; U; Linux 2.4.10-4GB i586) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS with SuSE Linux 7.3, Kernel 2.4.10 Content-Type: multipart/mixed; boundary="------------A7EE0A45C8CCB7D4C1C1EB55" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dies ist eine mehrteilige Nachricht im MIME-Format. --------------A7EE0A45C8CCB7D4C1C1EB55 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, i really need your help. I have to set up a SAMBA-Server on a XFS-Filesystem because compatibility to SGI-IRIX is needed. I' m using SuSE Linux 7.3 with kernel 2.4.10. glibc is 2.2.4-21, GNU gcc is 2.95.3-124, make is 3.79.1-166. I tried to patch and compile the kernel with your linux-2.4.10-xfs-2001-10-03.patch.bz2 patchfile. Everything worked fine up to pagebuf.c (see my logfile). It seems that VM_PAGEBUF in line 2279 isn' t declared correctly. But as i don' t know enough about developing in C i' m again urgently asking for your support and therefore for a solution for this problem. I hopefully await your answer. Thank you very much in advance for your support. Greetings and best wishes to the XFS-SGI team Robert --------------A7EE0A45C8CCB7D4C1C1EB55 Content-Type: text/plain; charset=us-ascii; name="krnl_comp.log" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="krnl_comp.log" gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o init/main.o init/main.c . scripts/mkversion > .version gzip -9 < .config | scripts/bin2c kernel_config_data > include/linux/config_data.h gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DUTS_MACHINE='"i386"' -c -o init/version.o init/version.c make CFLAGS="-D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 " -C kernel make[1]: Entering directory `/usr/src/linux/kernel' make all_targets make[2]: Entering directory `/usr/src/linux/kernel' gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -fno-omit-frame-pointer -c -o sched.o sched.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o dma.o dma.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o fork.o fork.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c exec_domain.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o panic.o panic.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c printk.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o module.o module.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o exit.o exit.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o itimer.o itimer.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o info.o info.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o time.o time.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o softirq.o softirq.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o resource.o resource.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o sysctl.o sysctl.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o acct.o acct.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o capability.o capability.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o ptrace.o ptrace.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o timer.o timer.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o user.o user.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c signal.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c sys.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c kmod.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c context.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o uid16.o uid16.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c ksyms.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c pm.c rm -f kernel.o ld -m elf_i386 -r -o kernel.o sched.o dma.o fork.o exec_domain.o panic.o printk.o module.o exit.o itimer.o info.o time.o softirq.o resource.o sysctl.o acct.o capability.o ptrace.o timer.o user.o signal.o sys.o kmod.o context.o uid16.o ksyms.o pm.o make[2]: Leaving directory `/usr/src/linux/kernel' make[1]: Leaving directory `/usr/src/linux/kernel' make CFLAGS="-D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 " -C drivers make[1]: Entering directory `/usr/src/linux/drivers' make -C atm make[2]: Entering directory `/usr/src/linux/drivers/atm' make all_targets make[3]: Entering directory `/usr/src/linux/drivers/atm' gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -g -c -o atmdev_init.o atmdev_init.c rm -f atm.o ld -m elf_i386 -r -o atm.o atmdev_init.o make[3]: Leaving directory `/usr/src/linux/drivers/atm' make[2]: Leaving directory `/usr/src/linux/drivers/atm' make -C block make[2]: Entering directory `/usr/src/linux/drivers/block' make all_targets make[3]: Entering directory `/usr/src/linux/drivers/block' gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c ll_rw_blk.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c blkpg.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c genhd.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o elevator.o elevator.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o floppy.o floppy.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o rd.o rd.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c loop.c rm -f block.o ld -m elf_i386 -r -o block.o ll_rw_blk.o blkpg.o genhd.o elevator.o floppy.o rd.o loop.o make[3]: Leaving directory `/usr/src/linux/drivers/block' make[2]: Leaving directory `/usr/src/linux/drivers/block' make -C cdrom make[2]: Entering directory `/usr/src/linux/drivers/cdrom' make all_targets make[3]: Entering directory `/usr/src/linux/drivers/cdrom' gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c cdrom.c rm -f driver.o ld -m elf_i386 -r -o driver.o cdrom.o make[3]: Leaving directory `/usr/src/linux/drivers/cdrom' make[2]: Leaving directory `/usr/src/linux/drivers/cdrom' make -C char make[2]: Entering directory `/usr/src/linux/drivers/char' make -C drm make[3]: Entering directory `/usr/src/linux/drivers/char/drm' make all_targets make[4]: Entering directory `/usr/src/linux/drivers/char/drm' rm -f drm.o ar rcs drm.o make[4]: Leaving directory `/usr/src/linux/drivers/char/drm' make[3]: Leaving directory `/usr/src/linux/drivers/char/drm' make all_targets make[3]: Entering directory `/usr/src/linux/drivers/char' gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o mem.o mem.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c tty_io.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o n_tty.o n_tty.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c tty_ioctl.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o raw.o raw.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c pty.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c misc.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c random.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o vt.o vt.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o vc_screen.o vc_screen.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o consolemap.o consolemap.c gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o conmakehash conmakehash.c ./conmakehash cp437.uni > consolemap_deftbl.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o consolemap_deftbl.o consolemap_deftbl.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c console.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c selection.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c serial.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c keyboard.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o defkeymap.o defkeymap.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o pc_keyb.o pc_keyb.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c sysrq.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o qpmouse.o qpmouse.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o rtc.o rtc.c rm -f char.o ld -m elf_i386 -r -o char.o mem.o tty_io.o n_tty.o tty_ioctl.o raw.o pty.o misc.o random.o vt.o vc_screen.o consolemap.o consolemap_deftbl.o console.o selection.o serial.o keyboard.o defkeymap.o pc_keyb.o sysrq.o qpmouse.o rtc.o make[3]: Leaving directory `/usr/src/linux/drivers/char' make[2]: Leaving directory `/usr/src/linux/drivers/char' make -C ide make[2]: Entering directory `/usr/src/linux/drivers/ide' make all_targets make[3]: Entering directory `/usr/src/linux/drivers/ide' gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c ide.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c ide-features.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c ide-taskfile.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o aec62xx.o aec62xx.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o ali14xx.o ali14xx.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o alim15x3.o alim15x3.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o amd74xx.o amd74xx.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o cmd640.o cmd640.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o cmd64x.o cmd64x.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o cs5530.o cs5530.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o cy82c693.o cy82c693.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o dtc2278.o dtc2278.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o hpt34x.o hpt34x.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o hpt366.o hpt366.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o ht6560b.o ht6560b.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o ide-adma.o ide-adma.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o ide-dma.o ide-dma.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o ide-pci.o ide-pci.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o ns87415.o ns87415.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o serverworks.o serverworks.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o pdc202xx.o pdc202xx.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o piix.o piix.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o qd65xx.o qd65xx.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o rz1000.o rz1000.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o sis5513.o sis5513.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o slc90e66.o slc90e66.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o umc8672.o umc8672.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o via82cxxx.o via82cxxx.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o ide-proc.o ide-proc.c ld -m elf_i386 -r -o ide-mod.o ide.o ide-features.o ide-taskfile.o aec62xx.o ali14xx.o alim15x3.o amd74xx.o cmd640.o cmd64x.o cs5530.o cy82c693.o dtc2278.o hpt34x.o hpt366.o ht6560b.o ide-adma.o ide-dma.o ide-pci.o ns87415.o serverworks.o pdc202xx.o piix.o qd65xx.o rz1000.o sis5513.o slc90e66.o umc8672.o via82cxxx.o ide-proc.o gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o ide-probe.o ide-probe.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o ide-geometry.o ide-geometry.c ld -m elf_i386 -r -o ide-probe-mod.o ide-probe.o ide-geometry.o gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o ide-disk.o ide-disk.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o ide-cd.o ide-cd.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o ide-floppy.o ide-floppy.c rm -f idedriver.o ld -m elf_i386 -r -o idedriver.o ide-mod.o ide-probe-mod.o ide-disk.o ide-cd.o ide-floppy.o make[3]: Leaving directory `/usr/src/linux/drivers/ide' make[2]: Leaving directory `/usr/src/linux/drivers/ide' make -C md make[2]: Entering directory `/usr/src/linux/drivers/md' make all_targets make[3]: Entering directory `/usr/src/linux/drivers/md' gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c md.c rm -f mddev.o ld -m elf_i386 -r -o mddev.o md.o make[3]: Leaving directory `/usr/src/linux/drivers/md' make[2]: Leaving directory `/usr/src/linux/drivers/md' make -C media make[2]: Entering directory `/usr/src/linux/drivers/media' make -C radio make[3]: Entering directory `/usr/src/linux/drivers/media/radio' make all_targets make[4]: Entering directory `/usr/src/linux/drivers/media/radio' rm -f radio.o ar rcs radio.o make[4]: Leaving directory `/usr/src/linux/drivers/media/radio' make[3]: Leaving directory `/usr/src/linux/drivers/media/radio' make -C video make[3]: Entering directory `/usr/src/linux/drivers/media/video' make all_targets make[4]: Entering directory `/usr/src/linux/drivers/media/video' rm -f video.o ar rcs video.o make[4]: Leaving directory `/usr/src/linux/drivers/media/video' make[3]: Leaving directory `/usr/src/linux/drivers/media/video' make all_targets make[3]: Entering directory `/usr/src/linux/drivers/media' rm -f media.o ld -m elf_i386 -r -o media.o video/video.o radio/radio.o make[3]: Leaving directory `/usr/src/linux/drivers/media' make[2]: Leaving directory `/usr/src/linux/drivers/media' make -C misc make[2]: Entering directory `/usr/src/linux/drivers/misc' make all_targets make[3]: Entering directory `/usr/src/linux/drivers/misc' rm -f misc.o ar rcs misc.o make[3]: Leaving directory `/usr/src/linux/drivers/misc' make[2]: Leaving directory `/usr/src/linux/drivers/misc' make -C net make[2]: Entering directory `/usr/src/linux/drivers/net' make -C appletalk make[3]: Entering directory `/usr/src/linux/drivers/net/appletalk' make all_targets make[4]: Entering directory `/usr/src/linux/drivers/net/appletalk' rm -f appletalk.o ar rcs appletalk.o make[4]: Leaving directory `/usr/src/linux/drivers/net/appletalk' make[3]: Leaving directory `/usr/src/linux/drivers/net/appletalk' make -C fc make[3]: Entering directory `/usr/src/linux/drivers/net/fc' make all_targets make[4]: Entering directory `/usr/src/linux/drivers/net/fc' rm -f fc.o ar rcs fc.o make[4]: Leaving directory `/usr/src/linux/drivers/net/fc' make[3]: Leaving directory `/usr/src/linux/drivers/net/fc' make -C pcmcia make[3]: Entering directory `/usr/src/linux/drivers/net/pcmcia' make all_targets make[4]: Entering directory `/usr/src/linux/drivers/net/pcmcia' rm -f pcmcia_net.o ar rcs pcmcia_net.o make[4]: Leaving directory `/usr/src/linux/drivers/net/pcmcia' make[3]: Leaving directory `/usr/src/linux/drivers/net/pcmcia' make -C tokenring make[3]: Entering directory `/usr/src/linux/drivers/net/tokenring' make all_targets make[4]: Entering directory `/usr/src/linux/drivers/net/tokenring' rm -f tr.o ar rcs tr.o make[4]: Leaving directory `/usr/src/linux/drivers/net/tokenring' make[3]: Leaving directory `/usr/src/linux/drivers/net/tokenring' make -C wan make[3]: Entering directory `/usr/src/linux/drivers/net/wan' make all_targets make[4]: Entering directory `/usr/src/linux/drivers/net/wan' rm -f wan.o ar rcs wan.o make[4]: Leaving directory `/usr/src/linux/drivers/net/wan' make[3]: Leaving directory `/usr/src/linux/drivers/net/wan' make -C wireless make[3]: Entering directory `/usr/src/linux/drivers/net/wireless' make all_targets make[4]: Entering directory `/usr/src/linux/drivers/net/wireless' rm -f wireless_net.o ar rcs wireless_net.o make[4]: Leaving directory `/usr/src/linux/drivers/net/wireless' make[3]: Leaving directory `/usr/src/linux/drivers/net/wireless' make all_targets make[3]: Entering directory `/usr/src/linux/drivers/net' gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o Space.o Space.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o setup.o setup.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c net_init.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o loopback.o loopback.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c auto_irq.c rm -f net.o ld -m elf_i386 -r -o net.o Space.o setup.o net_init.o loopback.o auto_irq.o make[3]: Leaving directory `/usr/src/linux/drivers/net' make[2]: Leaving directory `/usr/src/linux/drivers/net' make -C net/hamradio make[2]: Entering directory `/usr/src/linux/drivers/net/hamradio' make all_targets make[3]: Entering directory `/usr/src/linux/drivers/net/hamradio' rm -f hamradio.o ar rcs hamradio.o make[3]: Leaving directory `/usr/src/linux/drivers/net/hamradio' make[2]: Leaving directory `/usr/src/linux/drivers/net/hamradio' make -C parport make[2]: Entering directory `/usr/src/linux/drivers/parport' make all_targets make[3]: Entering directory `/usr/src/linux/drivers/parport' rm -f driver.o ar rcs driver.o make[3]: Leaving directory `/usr/src/linux/drivers/parport' make[2]: Leaving directory `/usr/src/linux/drivers/parport' make -C pci make[2]: Entering directory `/usr/src/linux/drivers/pci' make all_targets make[3]: Entering directory `/usr/src/linux/drivers/pci' gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c pci.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o quirks.o quirks.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o compat.o compat.c gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o gen-devlist gen-devlist.c ./gen-devlist 53c700-mem.c echo "#define MEM_MAPPED" >> 53c700-mem.c cat 53c700.c >> 53c700-mem.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c scsi_syms.c ld -m elf_i386 -r -o scsi_mod.o scsi.o hosts.o scsi_ioctl.o constants.o scsicam.o scsi_proc.o scsi_error.o scsi_obsolete.o scsi_queue.o scsi_lib.o scsi_merge.o scsi_dma.o scsi_scan.o scsi_syms.o gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o sd.o sd.c ld -m elf_i386 -r -o sd_mod.o sd.o gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o sr.o sr.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o sr_ioctl.o sr_ioctl.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o sr_vendor.o sr_vendor.c ld -m elf_i386 -r -o sr_mod.o sr.o sr_ioctl.o sr_vendor.o rm -f scsidrv.o ld -m elf_i386 -r -o scsidrv.o scsi_mod.o sd_mod.o sr_mod.o make[3]: Leaving directory `/usr/src/linux/drivers/scsi' make[2]: Leaving directory `/usr/src/linux/drivers/scsi' make -C sound make[2]: Entering directory `/usr/src/linux/drivers/sound' make all_targets make[3]: Entering directory `/usr/src/linux/drivers/sound' rm -f sounddrivers.o ar rcs sounddrivers.o make[3]: Leaving directory `/usr/src/linux/drivers/sound' make[2]: Leaving directory `/usr/src/linux/drivers/sound' make -C video make[2]: Entering directory `/usr/src/linux/drivers/video' make all_targets make[3]: Entering directory `/usr/src/linux/drivers/video' gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o dummycon.o dummycon.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o vgacon.o vgacon.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o font_8x8.o font_8x8.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o font_8x16.o font_8x16.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c fbmem.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c fbcmap.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c modedb.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c fbcon.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o fonts.o fonts.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o vesafb.o vesafb.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c fbcon-cfb8.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c fbcon-cfb16.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c fbcon-cfb24.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c fbcon-cfb32.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o fbcon-splash.o fbcon-splash.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o fbcon-jpegdec.o fbcon-jpegdec.c rm -f video.o ld -m elf_i386 -r -o video.o dummycon.o vgacon.o font_8x8.o font_8x16.o fbmem.o fbcmap.o modedb.o fbcon.o fonts.o vesafb.o fbcon-cfb8.o fbcon-cfb16.o fbcon-cfb24.o fbcon-cfb32.o fbcon-splash.o fbcon-jpegdec.o make[3]: Leaving directory `/usr/src/linux/drivers/video' make[2]: Leaving directory `/usr/src/linux/drivers/video' make all_targets make[2]: Entering directory `/usr/src/linux/drivers' make[2]: Nothing to be done for `all_targets'. make[2]: Leaving directory `/usr/src/linux/drivers' make[1]: Leaving directory `/usr/src/linux/drivers' make CFLAGS="-D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 " -C mm make[1]: Entering directory `/usr/src/linux/mm' make all_targets make[2]: Entering directory `/usr/src/linux/mm' gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o memory.o memory.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o mmap.o mmap.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o filemap.o filemap.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o mprotect.o mprotect.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o mlock.o mlock.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o mremap.o mremap.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o vmalloc.o vmalloc.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o slab.o slab.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o bootmem.o bootmem.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o swap.o swap.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o vmscan.o vmscan.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o page_io.o page_io.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o page_alloc.o page_alloc.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o swap_state.o swap_state.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o swapfile.o swapfile.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o numa.o numa.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o oom_kill.o oom_kill.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c shmem.c rm -f mm.o ld -m elf_i386 -r -o mm.o memory.o mmap.o filemap.o mprotect.o mlock.o mremap.o vmalloc.o slab.o bootmem.o swap.o vmscan.o page_io.o page_alloc.o swap_state.o swapfile.o numa.o oom_kill.o shmem.o make[2]: Leaving directory `/usr/src/linux/mm' make[1]: Leaving directory `/usr/src/linux/mm' make CFLAGS="-D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 " -C fs make[1]: Entering directory `/usr/src/linux/fs' make -C devpts make[2]: Entering directory `/usr/src/linux/fs/devpts' make all_targets make[3]: Entering directory `/usr/src/linux/fs/devpts' gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o root.o root.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o inode.o inode.c rm -f devpts.o ld -m elf_i386 -r -o devpts.o root.o inode.o make[3]: Leaving directory `/usr/src/linux/fs/devpts' make[2]: Leaving directory `/usr/src/linux/fs/devpts' make -C ext2 make[2]: Entering directory `/usr/src/linux/fs/ext2' make all_targets make[3]: Entering directory `/usr/src/linux/fs/ext2' gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o acl.o acl.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o balloc.o balloc.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o bitmap.o bitmap.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o dir.o dir.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o file.o file.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o fsync.o fsync.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o ialloc.o ialloc.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o inode.o inode.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o ioctl.o ioctl.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o namei.o namei.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o super.o super.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o symlink.o symlink.c rm -f ext2.o ld -m elf_i386 -r -o ext2.o acl.o balloc.o bitmap.o dir.o file.o fsync.o ialloc.o inode.o ioctl.o namei.o super.o symlink.o make[3]: Leaving directory `/usr/src/linux/fs/ext2' make[2]: Leaving directory `/usr/src/linux/fs/ext2' make -C fat make[2]: Entering directory `/usr/src/linux/fs/fat' make all_targets make[3]: Entering directory `/usr/src/linux/fs/fat' gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o buffer.o buffer.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o cache.o cache.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o dir.o dir.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o file.o file.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o inode.o inode.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o misc.o misc.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o cvf.o cvf.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c fatfs_syms.c rm -f fat.o ld -m elf_i386 -r -o fat.o buffer.o cache.o dir.o file.o inode.o misc.o cvf.o fatfs_syms.o make[3]: Leaving directory `/usr/src/linux/fs/fat' make[2]: Leaving directory `/usr/src/linux/fs/fat' make -C isofs make[2]: Entering directory `/usr/src/linux/fs/isofs' make all_targets make[3]: Entering directory `/usr/src/linux/fs/isofs' gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o namei.o namei.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o inode.o inode.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o dir.o dir.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o util.o util.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o rock.o rock.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o joliet.o joliet.c rm -f isofs.o ld -m elf_i386 -r -o isofs.o namei.o inode.o dir.o util.o rock.o joliet.o make[3]: Leaving directory `/usr/src/linux/fs/isofs' make[2]: Leaving directory `/usr/src/linux/fs/isofs' make -C lockd make[2]: Entering directory `/usr/src/linux/fs/lockd' make all_targets make[3]: Entering directory `/usr/src/linux/fs/lockd' gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o clntlock.o clntlock.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o clntproc.o clntproc.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o host.o host.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o svc.o svc.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o svclock.o svclock.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o svcshare.o svcshare.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o svcproc.o svcproc.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o svcsubs.o svcsubs.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o mon.o mon.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o xdr.o xdr.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c lockd_syms.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o xdr4.o xdr4.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o svc4proc.o svc4proc.c rm -f lockd.o ld -m elf_i386 -r -o lockd.o clntlock.o clntproc.o host.o svc.o svclock.o svcshare.o svcproc.o svcsubs.o mon.o xdr.o lockd_syms.o xdr4.o svc4proc.o make[3]: Leaving directory `/usr/src/linux/fs/lockd' make[2]: Leaving directory `/usr/src/linux/fs/lockd' make -C minix make[2]: Entering directory `/usr/src/linux/fs/minix' make all_targets make[3]: Entering directory `/usr/src/linux/fs/minix' gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o bitmap.o bitmap.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o itree_v1.o itree_v1.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o itree_v2.o itree_v2.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o namei.o namei.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o inode.o inode.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o file.o file.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o dir.o dir.c rm -f minix.o ld -m elf_i386 -r -o minix.o bitmap.o itree_v1.o itree_v2.o namei.o inode.o file.o dir.o make[3]: Leaving directory `/usr/src/linux/fs/minix' make[2]: Leaving directory `/usr/src/linux/fs/minix' make -C msdos make[2]: Entering directory `/usr/src/linux/fs/msdos' make all_targets make[3]: Entering directory `/usr/src/linux/fs/msdos' gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o namei.o namei.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c msdosfs_syms.c rm -f msdos.o ld -m elf_i386 -r -o msdos.o namei.o msdosfs_syms.o make[3]: Leaving directory `/usr/src/linux/fs/msdos' make[2]: Leaving directory `/usr/src/linux/fs/msdos' make -C nfs make[2]: Entering directory `/usr/src/linux/fs/nfs' make all_targets make[3]: Entering directory `/usr/src/linux/fs/nfs' gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o inode.o inode.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o file.o file.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o read.o read.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o write.o write.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o dir.o dir.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o symlink.o symlink.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o proc.o proc.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o nfs2xdr.o nfs2xdr.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o flushd.o flushd.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o unlink.o unlink.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o nfs3proc.o nfs3proc.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o nfs3xdr.o nfs3xdr.c rm -f nfs.o ld -m elf_i386 -r -o nfs.o inode.o file.o read.o write.o dir.o symlink.o proc.o nfs2xdr.o flushd.o unlink.o nfs3proc.o nfs3xdr.o make[3]: Leaving directory `/usr/src/linux/fs/nfs' make[2]: Leaving directory `/usr/src/linux/fs/nfs' make -C nls make[2]: Entering directory `/usr/src/linux/fs/nls' make all_targets make[3]: Entering directory `/usr/src/linux/fs/nls' gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c nls_base.c rm -f nls.o ld -m elf_i386 -r -o nls.o nls_base.o make[3]: Leaving directory `/usr/src/linux/fs/nls' make[2]: Leaving directory `/usr/src/linux/fs/nls' make -C pagebuf make[2]: Entering directory `/usr/src/linux/fs/pagebuf' make all_targets make[3]: Entering directory `/usr/src/linux/fs/pagebuf' gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -c -o avl.o avl.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c page_buf.c page_buf.c:2279: `VM_PAGEBUF' undeclared here (not in a function) page_buf.c:2279: initializer element is not constant page_buf.c:2279: (near initialization for `pagebuf_dir_table[0].ctl_name') make[3]: *** [page_buf.o] Error 1 make[2]: *** [first_rule] Error 2 make[1]: *** [_subdir_pagebuf] Error 2 make: *** [_dir_fs] Error 2 make[3]: Leaving directory `/usr/src/linux/fs/pagebuf' make[2]: Leaving directory `/usr/src/linux/fs/pagebuf' make[1]: Leaving directory `/usr/src/linux/fs' --------------A7EE0A45C8CCB7D4C1C1EB55-- From owner-linux-xfs@oss.sgi.com Thu Oct 25 05:03:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PC3P904291 for linux-xfs-outgoing; Thu, 25 Oct 2001 05:03:25 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PC3LD04269 for ; Thu, 25 Oct 2001 05:03:21 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id FAA21921 for ; Thu, 25 Oct 2001 05:03:14 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id HAA3399902; Thu, 25 Oct 2001 07:02:03 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id HAA24432; Thu, 25 Oct 2001 07:02:03 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9PBwDo08376; Thu, 25 Oct 2001 06:58:13 -0500 Message-Id: <200110251158.f9PBwDo08376@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Christoph Hellwig cc: Steve Lord , Arun Ramakrishnan , linux-xfs@oss.sgi.com Subject: Re: Linux page cache doubt In-Reply-To: Message from Christoph Hellwig of "Thu, 25 Oct 2001 08:37:41 +0200." <20011025083741.A3180@caldera.de> Date: Thu, 25 Oct 2001 06:58:12 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Wed, Oct 24, 2001 at 05:36:41PM -0500, Steve Lord wrote: > > Hi Arun, well filesystem I/O is divided into two chunks - file data > > which is definitely page cache based, and metadata which is done through > > various means depending on: > > > > o which kernel you are running > > o which filesystem > > > > All filesystems that I am aware of except for XFS use buffer heads and the > > block cache for metadata I/O. > > JFS uses the pagecache for all I/O - for metadata they have an additional > 'metapage' abstraction. Ah ha, Steve Best and co were asking about pagebuf a year or so back. I should take a look sometime. Steve > > Christoph > > -- > Of course it doesn't work. We've performed a software upgrade. From owner-linux-xfs@oss.sgi.com Thu Oct 25 05:09:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PC9iW04523 for linux-xfs-outgoing; Thu, 25 Oct 2001 05:09:44 -0700 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PC9eD04501 for ; Thu, 25 Oct 2001 05:09:41 -0700 Received: from inf.ethz.ch (IDENT:schmitt@ikarus.inf.ethz.ch [129.132.10.58]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id OAA22304; Thu, 25 Oct 2001 14:09:30 +0200 (MET DST) Message-ID: <3BD800FC.6020005@inf.ethz.ch> Date: Thu, 25 Oct 2001 14:09:32 +0200 From: Marc Schmitt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Steve Lord CC: Eric Sandeen , linux-xfs@oss.sgi.com, florin@sgi.com Subject: Re: Corruption of in-memory data detected. References: <200110242032.f9OKWPk32359@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: > Yes, but the detection process may need some work - ext2 will probably > have radically different behavior on an error. It may throw up on the > filesystem, or you may have to run fsck afterwards to see what happened > to the fs. Hmm, using mke2fs 1.25 (with m set to 1), mongo runs a complete benchmark over the 1.2TB: Filesystem 1k-blocks Used Available Use% Mounted on /dev/md0 1135510828 20 1123788584 1% /local After unmounting, I ran e2fsck:e2fsck 1.25 (20-Sep-2001) /dev/md0: clean, 11/293076992 files, 9177898/293055600 blocks Same steps as above with the current version of e2fsprogs on a RedHat 7.1 system showed no different result (e2fsck 1.23, 15-Aug-2001 for EXT2 FS 0.5b, 95/08/09) Greetz Marc From owner-linux-xfs@oss.sgi.com Thu Oct 25 05:17:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PCHHh04779 for linux-xfs-outgoing; Thu, 25 Oct 2001 05:17:17 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PCHCD04754 for ; Thu, 25 Oct 2001 05:17:12 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id FAA09657 for ; Thu, 25 Oct 2001 05:16:30 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id HAA3402500; Thu, 25 Oct 2001 07:15:55 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id HAA28745; Thu, 25 Oct 2001 07:15:55 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9PCC5e08949; Thu, 25 Oct 2001 07:12:05 -0500 Message-Id: <200110251212.f9PCC5e08949@jen.americas.sgi.com> To: Marc Schmitt cc: Steve Lord , Eric Sandeen , linux-xfs@oss.sgi.com, florin@sgi.com Subject: Re: Corruption of in-memory data detected. References: <200110242032.f9OKWPk32359@jen.americas.sgi.com> <3BD800FC.6020005@inf.ethz.ch> Comments: In-reply-to Marc Schmitt message dated "Thu, 25 Oct 2001 14:09:32 +0200." Date: Thu, 25 Oct 2001 07:12:05 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk OK, so the next possibility is the fact that xfs is setting the block size of the device to 512 bytes and that pushes some calculations over. I am experimenting with some new code in 2.4.13 which removes this chunk of code, the next thing to try may be this, I am running md tests on it this morning and so far it looks good, but I do not have access to enough disk to test for the size overflow. I hope to have a 2.4.13 xfs patch out today, maybe we will have to get you to try it. Thanks for your patience on this one. Steve > Steve Lord wrote: > > > Yes, but the detection process may need some work - ext2 will probably > > have radically different behavior on an error. It may throw up on the > > filesystem, or you may have to run fsck afterwards to see what happened > > to the fs. > > > Hmm, using mke2fs 1.25 (with m set to 1), mongo runs a complete > benchmark over the 1.2TB: > Filesystem 1k-blocks Used Available Use% Mounted on > /dev/md0 1135510828 20 1123788584 1% /local > > After unmounting, I ran e2fsck:e2fsck 1.25 (20-Sep-2001) > /dev/md0: clean, 11/293076992 files, 9177898/293055600 blocks > > Same steps as above with the current version of e2fsprogs on a RedHat > 7.1 system showed no different result (e2fsck 1.23, 15-Aug-2001 for EXT2 > FS 0.5b, 95/08/09) > > > Greetz > Marc > From owner-linux-xfs@oss.sgi.com Thu Oct 25 05:56:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PCuTq05656 for linux-xfs-outgoing; Thu, 25 Oct 2001 05:56:29 -0700 Received: from lightning.aem.umn.edu (lightning.aem.umn.edu [128.101.143.49]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PCuMD05630 for ; Thu, 25 Oct 2001 05:56:22 -0700 Received: (from muno@localhost) by lightning.aem.umn.edu (8.11.6/8.11.6) id f9PCtw503117; Thu, 25 Oct 2001 07:55:58 -0500 Date: Thu, 25 Oct 2001 07:55:58 -0500 From: Ray Muno To: "Martin K. Petersen" Cc: Stevan Bajic , linux-xfs@oss.sgi.com Subject: Re: XFS for RedHat Message-ID: <20011025075557.B3020@aem.umn.edu> References: <200110250213370058.255D0A31@192.168.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.19-current-20010622i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk There may be a reason why things like this end up on the list. I fell in to the trap the first time as well. At the bottom of the Linux XFS project page, there is a link for an email address for questions. ----- Questions and Problems If you have any questions or problems with the installation or administration of XFS for Linux, you can send email to linux-xfs@oss.sgi.com. ----- No where does it mention that you are posting to a mailing list, it looks like you are just sending mail to the development team. It does not indicate there is anyplace to look at previous postings to the list, either. On Wed, Oct 24, 2001 at 08:46:16PM -0400, Martin K. Petersen wrote: > >>>>> "Stevan" == Stevan Bajic writes: > > Stevan> Hi I'am using RedHat 7.1 with SGI XFS and I'am very happy with > Stevan> it. Now I see, that RedHat has a new version (7.2) out. Are > Stevan> there any plans to produca a RedHat 7.2 installation CDROM > Stevan> (like te one for RedHat 7.1)? > > Congratulations! You are person number 1000 to ask that question this > week. As a token of appreciation, contact your local SGI branch > office to claim your FREE blade-less ginzu knife without handle. > > But wait! There's more! If you hang on for a couple of days you may > find what you are looking for on oss.sgi.com. An XFS-aware Red Hat > 7.2 installer preview. FREE OF CHARGE! Yes, that's right. This > wonderful stream of data can be yours for only $0.00*. > > *) A minimum of 1 download per customer is required to participate in > beta testing programme. Rough conditions may apply. > > -- > Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. > mkp@linuxcare.com, http://www.linuxcare.com/ > SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ > ============================================================================= 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 Thu Oct 25 06:39:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PDd9606930 for linux-xfs-outgoing; Thu, 25 Oct 2001 06:39:09 -0700 Received: from dmz.tecosim.de ([194.24.222.241]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PDd3D06907 for ; Thu, 25 Oct 2001 06:39:04 -0700 Received: (from uucp@localhost) by dmz.tecosim.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) id f9PDaZJ03391; Thu, 25 Oct 2001 15:36:35 +0200 Received: from ns.tecosim.de(194.24.222.9) via SMTP by dmz.tecosim.de, id smtpd3n71aY; Thu Oct 25 15:36:28 2001 Received: from donner.tecosim.de (donner.tecosim.de [194.24.222.109]) by ns.tecosim.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id f9PDaRJ23982; Thu, 25 Oct 2001 15:36:27 +0200 Received: (from leh@localhost) by donner.tecosim.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) id f9PDaR304508; Thu, 25 Oct 2001 15:36:27 +0200 Date: Thu, 25 Oct 2001 15:36:27 +0200 From: Utz Lehmann To: Steve Lord Cc: Marc Schmitt , Eric Sandeen , linux-xfs@oss.sgi.com, florin@sgi.com Subject: Re: Corruption of in-memory data detected. Message-ID: <20011025153627.B1915@de.tecosim.com> References: <200110242032.f9OKWPk32359@jen.americas.sgi.com> <3BD800FC.6020005@inf.ethz.ch> <200110251212.f9PCC5e08949@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <200110251212.f9PCC5e08949@jen.americas.sgi.com>; from lord@sgi.com on Thu, Oct 25, 2001 at 07:12:05AM -0500 X-Scanned-By: MIMEDefang 1.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Steve Steve Lord [lord@sgi.com] wrote: > > OK, so the next possibility is the fact that xfs is setting the block > size of the device to 512 bytes and that pushes some calculations over. > I am experimenting with some new code in 2.4.13 which removes this > chunk of code, the next thing to try may be this, I am running md > tests on it this morning and so far it looks good, but I do not > have access to enough disk to test for the size overflow. Maybe you can use a 1.2TB hole loop mounted. dd if=/dev/null of=loopfile bs=1024 seek=1288490188 mkfs.xfs loopfile mount -o loop loopfile /xxx/ I made this, and copy the kernel sources into /xxx/ and got the same errors like Marc: Oct 25 14:54:18 donner kernel: xfs_force_shutdown(loop(7,0),0x8) called from line 1020 of file xfs_trans.c. Return address = 0xc01b4d15 Oct 25 14:54:18 donner kernel: Corruption of in-memory data detected. Shutting down filesystem: loop(7,0) With 0.98TB no errors occured except one time my machine run out of memory. Kernel is 2.4.13-pre6-xfs-20011023 + preempt patch. utz From owner-linux-xfs@oss.sgi.com Thu Oct 25 06:51:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PDpUi07723 for linux-xfs-outgoing; Thu, 25 Oct 2001 06:51:30 -0700 Received: from musuko.uchicago.edu (musuko.uchicago.edu [128.135.39.147]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PDpQD07700 for ; Thu, 25 Oct 2001 06:51:26 -0700 Received: from localhost (localhost [127.0.0.1]) by musuko.uchicago.edu (8.11.6/8.11.2) with ESMTP id f9PDpO110427 for ; Thu, 25 Oct 2001 08:51:25 -0500 Subject: GRUB in RedHat 7.2 xfs From: Stuart Luppescu To: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ZAoeGqTGzpBnnOIHZg4I" X-Mailer: Evolution/0.15 (Preview Release) Date: 25 Oct 2001 08:51:24 -0500 Message-Id: <1004017885.10400.2.camel@musuko.uchicago.edu> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-ZAoeGqTGzpBnnOIHZg4I Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I remember hearing something about GRUB not being xfs aware, or something like that. Are we limited to LILO, or will the XFS RedHat 7.2 installer properly handle GRUB? Just a little curiousity. --=20 ______________________________________________________________________ Stuart Luppescu -=3D-=3D- University of Chicago =1B$(B:MJ8$HCRF`H~$NIc=1B(B -=3D-=3D- s-luppescu@uchicago.edu http://www.consortium-chicago.org/people/sl.html http://musuko.uchicago.edu/pubkey.asc for PGP Public Key ICQ #21172047 AIM: psycho7070 --=-ZAoeGqTGzpBnnOIHZg4I Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEABECAAYFAjvYGNsACgkQDBHcBS0tWxOOfQCdEYWpLc++eWQuIl0y77H3ZcA5 sD0AnRoCuxrnJNjGMqtJve3b2k+roX0n =0vYk -----END PGP SIGNATURE----- --=-ZAoeGqTGzpBnnOIHZg4I-- From owner-linux-xfs@oss.sgi.com Thu Oct 25 07:22:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PEMPu09412 for linux-xfs-outgoing; Thu, 25 Oct 2001 07:22:25 -0700 Received: from rover (rover.mkp.net [209.217.122.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PEMLD09388 for ; Thu, 25 Oct 2001 07:22:21 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=jaguar.mkp.net) by rover with esmtp (Exim 3.33 #1) id 15wlOl-0006da-00; Thu, 25 Oct 2001 10:22:19 -0400 Received: (from mkp@localhost) by jaguar.mkp.net (8.11.2/8.9.3) id f9PEMCn14235; Thu, 25 Oct 2001 10:22:12 -0400 X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f To: Stuart Luppescu Cc: linux-xfs@oss.sgi.com Subject: Re: GRUB in RedHat 7.2 xfs References: <1004017885.10400.2.camel@musuko.uchicago.edu> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 25 Oct 2001 10:22:09 -0400 In-Reply-To: <1004017885.10400.2.camel@musuko.uchicago.edu> Message-ID: Lines: 21 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>>>> "Stuart" == Stuart Luppescu writes: Stuart> I remember hearing something about GRUB not being xfs aware, Stuart> or something like that. Are we limited to LILO, or will the Stuart> XFS RedHat 7.2 installer properly handle GRUB? Just a little Stuart> curiousity. Answer is that I don't know yet. There is an XFS patch for grub available. Whether it is included in the Red Hat shipped version I don't know. It's on my list of things to investigate. For the time being, however, grub is disabled in the XFS installer. If anyone feels like checking the grub source RPM and/or send me a patch I can roll in, feel free. -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Thu Oct 25 07:24:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PEOuC09598 for linux-xfs-outgoing; Thu, 25 Oct 2001 07:24:56 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PEOqD09576 for ; Thu, 25 Oct 2001 07:24:52 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA29791 for ; Thu, 25 Oct 2001 07:24:46 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA29778; Thu, 25 Oct 2001 07:24:20 -0700 (PDT) Message-ID: <3BD81FBB.E95980DE@sgi.com> Date: Thu, 25 Oct 2001 09:20:43 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: "Xie, May" CC: "'linux-xfs@oss.sgi.com.'" Subject: Re: Where is the xfs patch for kernel 2.4.2? References: <957BD1C2BF3CD411B6C500A0C944CA260A0FC3@pdsmsx32.pd.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi May - Unfortunately, 2.4.2 was so long ago, the only patch you will find is from the XFS 1.0 release at ftp://oss.sgi.com/projects/xfs/download/Release-1.0/patches/ However, there have been many bugs fixed & features added to XFS since then, so I would hesitate to use that release for production use... For obvious reasons, I'm afraid that we cannot continue to support _every_ kernel since 2.4.0 with the latest XFS... -Eric "Xie, May" wrote: > > Hello, > > Could you tell me where I can find xfs patch for linux kernel 2.4.2? For some reason, I should try to patch xfs on the certain kernel 2.4.2. Where can I get them? Is there a stable patch for 2.4.2? Any testing suites for it? > > Thanks, > May -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Oct 25 07:26:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PEQKX09741 for linux-xfs-outgoing; Thu, 25 Oct 2001 07:26:20 -0700 Received: from linux.nameip.net ([211.187.6.46]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PEQGD09719 for ; Thu, 25 Oct 2001 07:26:16 -0700 Received: (qmail 10646 invoked from network); 25 Oct 2001 14:31:11 -0000 Received: from unknown (HELO orgio.net) (211.187.6.46) by 0 with SMTP; 25 Oct 2001 14:31:11 -0000 Message-ID: <3BD8222E.6050601@orgio.net> Date: Thu, 25 Oct 2001 23:31:10 +0900 From: Seung-young Oh User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011013 X-Accept-Language: ko MIME-Version: 1.0 To: linux-xfs Subject: Let me see... Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Well, the RH2.4.9 test versions for RedHat7.1 seem to work flawlessly, at least for me. Compiling the test ver. 3 now... In the meantime let me have a look at the XFS-related RPM's on my system. ftp://oss.sgi.com/projects/xfs/download/cmd_rpms/acl-1.1.3-0.i386.rpm ftp://oss.sgi.com/projects/xfs/download/cmd_rpms/acl-devel-1.1.3-0.i386.rpm ftp://oss.sgi.com/projects/xfs/download/cmd_rpms/attr-1.1.3-0.i386.rpm ftp://oss.sgi.com/projects/xfs/download/cmd_rpms/attr-devel-1.1.3-0.i386.rpm ftp://oss.sgi.com/projects/xfs/download/cmd_rpms/dmapi-0.2.2-0.i386.rpm ftp://oss.sgi.com/projects/xfs/download/cmd_rpms/dmapi-devel-0.2.2-0.i386.rpm ftp://oss.sgi.com/projects/xfs/download/cmd_rpms/xfsdump-1.1.3-0.i386.rpm ftp://oss.sgi.com/projects/xfs/download/cmd_rpms/xfsprogs-1.3.7-0.i386.rpm ftp://oss.sgi.com/projects/xfs/download/cmd_rpms/xfsprogs-devel-1.3.7-0.i386.rpm ftp://oss.sgi.com/projects/xfs/download/Release-1.0.1/installer/RH7.1-SGI-XFS-1.0.1/RedHat/RPMS/anaconda-7.1-7XFS.i386.rpm ftp://oss.sgi.com/projects/xfs/download/Release-1.0.1/installer/RH7.1-SGI-XFS-1.0.1/RedHat/RPMS/anaconda-runtime-7.1-7XFS.i386.rpm ftp://oss.sgi.com/projects/xfs/download/Release-1.0.1/installer/RH7.1-SGI-XFS-1.0.1/RedHat/RPMS/devfsd-1.3.11-sgi.i386.rpm ftp://oss.sgi.com/projects/xfs/download/Release-1.0.1/installer/RH7.1-SGI-XFS-1.0.1/RedHat/RPMS/quota-3.01-pre7.i386.rpm ftp://oss.sgi.com/projects/xfs/download/testing/RH2.4.9-6/kernel-2.4.9-6SGI_XFS_PR3.i686.rpm ftp://oss.sgi.com/projects/xfs/download/testing/RH2.4.9-6/kernel-doc-2.4.9-6SGI_XFS_PR3.i386.rpm ftp://oss.sgi.com/projects/xfs/download/testing/RH2.4.9-6/kernel-headers-2.4.9-6SGI_XFS_PR3.i386.rpm ftp://oss.sgi.com/projects/xfs/download/testing/RH2.4.9-6/kernel-source-2.4.9-6SGI_XFS_PR3.i386.rpm http://home.datacomm.ch/simix/XFS/mkbootdisk-1.4.2-1XFS.i386.rpm http://home.datacomm.ch/simix/XFS/mkinitrd-3.2.6-1XFS.i386.rpm Correct me if i'm wrong or missing something, please? :-) -- ICQ#: 103231199 From owner-linux-xfs@oss.sgi.com Thu Oct 25 07:34:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PEYAl10299 for linux-xfs-outgoing; Thu, 25 Oct 2001 07:34:10 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PEY5D10273 for ; Thu, 25 Oct 2001 07:34:05 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9PEY0K02745 for ; Thu, 25 Oct 2001 07:34:00 -0700 Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA73776; Thu, 25 Oct 2001 07:33:28 -0700 (PDT) Message-ID: <3BD821DE.4488AA77@sgi.com> Date: Thu, 25 Oct 2001 09:29:50 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: root CC: linux-xfs@oss.sgi.com Subject: Re: XFS with SuSE Linux 7.3, Kernel 2.4.10 References: <3BD7E604.1FE3F2A2@verwaltung.uni-karlsruhe.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Robert - Did you use this patch on SuSE's kernel source tree? Merging XFS into a tree such as SuSE's, Red Hat's, Mandrake's, or Alan Cox's is a non-trivial exercise... I'd suggest using a "vanilla" Linux kernel with an XFS patch, unless there is something in the SuSE kernel that you really need... -Eric root wrote: > > Hello, > > i really need your help. I have to set up a SAMBA-Server on a > XFS-Filesystem because compatibility to SGI-IRIX is needed. > I' m using SuSE Linux 7.3 with kernel 2.4.10. glibc is 2.2.4-21, > GNU gcc is 2.95.3-124, make is 3.79.1-166. I tried to patch and compile > the kernel with your linux-2.4.10-xfs-2001-10-03.patch.bz2 patchfile. > Everything worked fine up to pagebuf.c (see my logfile). It seems that > VM_PAGEBUF in line 2279 isn' t declared correctly. But as i don' t know > enough about developing in C i' m again urgently asking for your support > and therefore for a solution for this problem. I hopefully await your > answer. Thank you very much in advance for your support. > > Greetings and best wishes to the XFS-SGI team > > Robert -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Oct 25 07:41:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PEfGo10821 for linux-xfs-outgoing; Thu, 25 Oct 2001 07:41:16 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PEfBD10799 for ; Thu, 25 Oct 2001 07:41:11 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA09412 for ; Thu, 25 Oct 2001 07:41:11 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA3192462; Thu, 25 Oct 2001 09:39:52 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA26825; Thu, 25 Oct 2001 09:39:52 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9PEa1F09054; Thu, 25 Oct 2001 09:36:01 -0500 Message-Id: <200110251436.f9PEa1F09054@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Martin K. Petersen" cc: Stuart Luppescu , linux-xfs@oss.sgi.com Subject: Re: GRUB in RedHat 7.2 xfs In-Reply-To: Message from "Martin K. Petersen" of "25 Oct 2001 10:22:09 EDT." Date: Thu, 25 Oct 2001 09:36:01 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I got the xfs patch for grub and built an rpm with it installed - the redhat version does not have it in there. I have not had time to test it yet, but we could put it up on the ftp site for some brave souls witj disposable machines to try out. Steve > >>>>> "Stuart" == Stuart Luppescu writes: > > Stuart> I remember hearing something about GRUB not being xfs aware, > Stuart> or something like that. Are we limited to LILO, or will the > Stuart> XFS RedHat 7.2 installer properly handle GRUB? Just a little > Stuart> curiousity. > > Answer is that I don't know yet. > > There is an XFS patch for grub available. Whether it is included in > the Red Hat shipped version I don't know. It's on my list of things > to investigate. For the time being, however, grub is disabled in the > XFS installer. > > If anyone feels like checking the grub source RPM and/or send me a > patch I can roll in, feel free. > > -- > Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. > mkp@linuxcare.com, http://www.linuxcare.com/ > SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Thu Oct 25 07:42:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PEgOv10909 for linux-xfs-outgoing; Thu, 25 Oct 2001 07:42:24 -0700 Received: from malik.slb.nwc.acsalaska.net (malik.slb.nwc.acsalaska.net [209.112.155.41]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PEgKD10878 for ; Thu, 25 Oct 2001 07:42:20 -0700 Received: from erbenson.alaska.net (240-pm16.nwc.alaska.net [209.112.141.240]) by malik.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id f9PEgIv79011 for ; Thu, 25 Oct 2001 06:42:18 -0800 (AKDT) (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 7F9233924 for ; Thu, 25 Oct 2001 06:42:17 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 89EDC10262; Thu, 25 Oct 2001 06:42:17 -0800 (AKDT) Date: Thu, 25 Oct 2001 06:42:17 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: GRUB in RedHat 7.2 xfs Message-ID: <20011025064217.B18788@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <1004017885.10400.2.camel@musuko.uchicago.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kORqDWCi7qDJ0mEj" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1004017885.10400.2.camel@musuko.uchicago.edu>; from s-luppescu@uchicago.edu on Thu, Oct 25, 2001 at 08:51:24AM -0500 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --kORqDWCi7qDJ0mEj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 25, 2001 at 08:51:24AM -0500, Stuart Luppescu wrote: > I remember hearing something about GRUB not being xfs aware, or > something like that. Are we limited to LILO, or will the XFS RedHat 7.2 > installer properly handle GRUB? Just a little curiousity. there are XFS patches for grub available, they have not been merged upstream, but debian has applied them in thier grub packages. my testing indicates that the patch works. I also adapted the grub XFS code to yaboot (a PowerPC bootloader akin to SILO) and have had good success with it so far (on the powerpc arch of course). --=20 Ethan Benson http://www.alaska.net/~erbenson/ --kORqDWCi7qDJ0mEj 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 iEYEARECAAYFAjvYJMkACgkQJKx7GixEevzM2gCgis0W5Oza1AtrlodPL6RsG0Wq C+EAn1cOBDmGsIEOwE1ymEgABt0+M9wB =bDtO -----END PGP SIGNATURE----- --kORqDWCi7qDJ0mEj-- From owner-linux-xfs@oss.sgi.com Thu Oct 25 07:49:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PEnpn12450 for linux-xfs-outgoing; Thu, 25 Oct 2001 07:49:51 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PEnkD12428 for ; Thu, 25 Oct 2001 07:49:46 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA01450 for ; Thu, 25 Oct 2001 07:49:40 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA3402803; Thu, 25 Oct 2001 09:48:29 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA04040; Thu, 25 Oct 2001 09:48:29 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9PEibR09073; Thu, 25 Oct 2001 09:44:37 -0500 Message-Id: <200110251444.f9PEibR09073@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Utz Lehmann cc: Steve Lord , Marc Schmitt , Eric Sandeen , linux-xfs@oss.sgi.com, florin@sgi.com Subject: Re: Corruption of in-memory data detected. In-Reply-To: Message from Utz Lehmann of "Thu, 25 Oct 2001 15:36:27 +0200." <20011025153627.B1915@de.tecosim.com> Date: Thu, 25 Oct 2001 09:44:37 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ah ha, now thats a good idea - of course I still think its the md code, but at least we have a chance of catching it now. Thanks Steve > Hi Steve > > Steve Lord [lord@sgi.com] wrote: > > > > OK, so the next possibility is the fact that xfs is setting the block > > size of the device to 512 bytes and that pushes some calculations over. > > I am experimenting with some new code in 2.4.13 which removes this > > chunk of code, the next thing to try may be this, I am running md > > tests on it this morning and so far it looks good, but I do not > > have access to enough disk to test for the size overflow. > > Maybe you can use a 1.2TB hole loop mounted. > > > dd if=/dev/null of=loopfile bs=1024 seek=1288490188 > mkfs.xfs loopfile > mount -o loop loopfile /xxx/ > > > I made this, and copy the kernel sources into /xxx/ and got the same errors > like Marc: > > Oct 25 14:54:18 donner kernel: xfs_force_shutdown(loop(7,0),0x8) called from > line 1020 of file xfs_trans.c. Return address = 0xc01b4d15 > Oct 25 14:54:18 donner kernel: Corruption of in-memory data detected. Shutti > ng down filesystem: loop(7,0) > > > With 0.98TB no errors occured except one time my machine run out of memory. > > Kernel is 2.4.13-pre6-xfs-20011023 + preempt patch. > > > utz From owner-linux-xfs@oss.sgi.com Thu Oct 25 07:55:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PEtWo12819 for linux-xfs-outgoing; Thu, 25 Oct 2001 07:55:32 -0700 Received: from rover (rover.mkp.net [209.217.122.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PEtTD12797 for ; Thu, 25 Oct 2001 07:55:29 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=jaguar.mkp.net) by rover with esmtp (Exim 3.33 #1) id 15wlug-0006mN-00; Thu, 25 Oct 2001 10:55:18 -0400 Received: (from mkp@localhost) by jaguar.mkp.net (8.11.2/8.9.3) id f9PEtAi14261; Thu, 25 Oct 2001 10:55:10 -0400 X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f To: Steve Lord Cc: Utz Lehmann , Marc Schmitt , Eric Sandeen , linux-xfs@oss.sgi.com, florin@sgi.com Subject: Re: Corruption of in-memory data detected. References: <200110251444.f9PEibR09073@jen.americas.sgi.com> From: "Martin K. Petersen" Organization: mkp.net Date: 25 Oct 2001 10:55:09 -0400 In-Reply-To: <200110251444.f9PEibR09073@jen.americas.sgi.com> Message-ID: Lines: 13 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>>>> "Steve" == Steve Lord writes: Steve> Ah ha, now thats a good idea - of course I still think its the Steve> md code, but at least we have a chance of catching it now. I took a look at MD last night and didn't see anything obvious sticking out. Will do a second pass in a bit... -- Martin K. Petersen Cereal Bowl Engineer, Linuxcare, Inc. http://mkp.net/ SGI XFS, Linux/PA-RISC, GNOME From owner-linux-xfs@oss.sgi.com Thu Oct 25 08:10:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PFAPn14061 for linux-xfs-outgoing; Thu, 25 Oct 2001 08:10:25 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PFAMD14037 for ; Thu, 25 Oct 2001 08:10:22 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA04425 for ; Thu, 25 Oct 2001 08:09:40 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA3406301; Thu, 25 Oct 2001 10:09:05 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA93483; Thu, 25 Oct 2001 10:09:05 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9PF5De15624; Thu, 25 Oct 2001 10:05:13 -0500 Message-Id: <200110251505.f9PF5De15624@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Martin K. Petersen" cc: Utz Lehmann , Marc Schmitt , Eric Sandeen , linux-xfs@oss.sgi.com, florin@sgi.com Subject: Re: Corruption of in-memory data detected. In-Reply-To: Message from "Martin K. Petersen" of "25 Oct 2001 10:55:09 EDT." Date: Thu, 25 Oct 2001 10:05:13 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > >>>>> "Steve" == Steve Lord writes: > > Steve> Ah ha, now thats a good idea - of course I still think its the > Steve> md code, but at least we have a chance of catching it now. > > I took a look at MD last night and didn't see anything obvious > sticking out. > > Will do a second pass in a bit... > > -- > Martin K. Petersen Cereal Bowl Engineer, Linuxcare, Inc. > http://mkp.net/ SGI XFS, Linux/PA-RISC, GNOME Martin, forget md, you can make this happen without it, looks like we introduced a sign bug ourselves somewhere.... I just toasted the loop based filesystem in about 10 seconds. Hopefully with a case this simple to reproduce it should not take long now. Steve From owner-linux-xfs@oss.sgi.com Thu Oct 25 08:12:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PFCfR14230 for linux-xfs-outgoing; Thu, 25 Oct 2001 08:12:41 -0700 Received: from rover (rover.mkp.net [209.217.122.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PFCbD14208 for ; Thu, 25 Oct 2001 08:12:38 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=jaguar.mkp.net) by rover with esmtp (Exim 3.33 #1) id 15wmBB-0006qk-00; Thu, 25 Oct 2001 11:12:21 -0400 Received: (from mkp@localhost) by jaguar.mkp.net (8.11.2/8.9.3) id f9PFCI814270; Thu, 25 Oct 2001 11:12:18 -0400 X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f To: Steve Lord Cc: Utz Lehmann , Marc Schmitt , Eric Sandeen , linux-xfs@oss.sgi.com, florin@sgi.com Subject: Re: Corruption of in-memory data detected. References: <200110251505.f9PF5De15624@jen.americas.sgi.com> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 25 Oct 2001 11:12:17 -0400 In-Reply-To: <200110251505.f9PF5De15624@jen.americas.sgi.com> Message-ID: Lines: 13 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>>>> "Steve" == Steve Lord writes: Steve> forget md, you can make this happen without it, looks like we Steve> introduced a sign bug ourselves somewhere.... Oh, bugger. Back to the snake pit, then. -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Thu Oct 25 08:21:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PFLlt15318 for linux-xfs-outgoing; Thu, 25 Oct 2001 08:21:47 -0700 Received: from chef.cc.absoval.com (cpe-66-1-218-101.fl.sprintbbd.net [66.1.218.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PFLhD15294 for ; Thu, 25 Oct 2001 08:21:43 -0700 Received: from ieee.org (IDENT:bs@thebs.cc.absoval.com [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id LAA27683; Thu, 25 Oct 2001 11:18:52 -0400 Message-ID: <3BD82D66.8E4A64E7@ieee.org> Date: Thu, 25 Oct 2001 11:19:03 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts/AbsoluteValueSystems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ethan Benson CC: linux-xfs@oss.sgi.com Subject: Re: GRUB in RedHat 7.2 xfs References: <1004017885.10400.2.camel@musuko.uchicago.edu> <20011025064217.B18788@plato.local.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ethan Benson wrote: > there are XFS patches for grub available, they have not been merged > upstream, but debian has applied them in thier grub packages. my > testing indicates that the patch works. I also adapted the grub XFS > code to yaboot (a PowerPC bootloader akin to SILO) and have had good > success with it so far (on the powerpc arch of course). RedHat 7.2 comes with both GRUB and LILO. I installed both and was still able to use LILO with no issues. -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ---------------------------------------------------------------- Web site defacements are as much of a national security risk as inner city kids spray painting. There is nothing of value, and nothing that can't be fixed with a little re-paint. You'd have to have the equivalent stupidity of someone parking an F-18 in downtown LA. Even then, the only damage would be a new scheme! The US government wants life imprisonment for such "terrorism." From owner-linux-xfs@oss.sgi.com Thu Oct 25 08:42:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PFg6I15927 for linux-xfs-outgoing; Thu, 25 Oct 2001 08:42:06 -0700 Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PFg0D15905 for ; Thu, 25 Oct 2001 08:42:00 -0700 Received: from bingsun2 (bf20761@bingsun2.cc.binghamton.edu [128.226.6.4]) by bingnet2.cc.binghamton.edu (8.11.6/8.11.6) with ESMTP id f9PFfdm02435; Thu, 25 Oct 2001 11:41:39 -0400 (EDT) Date: Thu, 25 Oct 2001 11:41:39 -0400 (EDT) From: Zhihui Zhang X-Sender: bf20761@bingsun2 To: Steve Lord cc: Arun Ramakrishnan , linux-xfs@oss.sgi.com Subject: Re: Linux page cache doubt In-Reply-To: <200110242236.f9OMagj06647@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 24 Oct 2001, Steve Lord wrote: > > Hi All, > > I recently read that all fs codes actually do I/O to and from the > > pagecache and then the dirty pages are synced to the disk later using > > the bdflush daemon.This approach has some performance problems when I/O > > is done thru write calls rather than mmap. I was just curious whether > > this path was modified when XFS was written ( ie how cud such a approach > > even work in case of jounalled file system when log operations are > > needed bfore the data gets written out). > > I am kinda newbie into kernel hacking and so i am sorry if my question > > sounds dumb. > > Hi Arun, well filesystem I/O is divided into two chunks - file data > which is definitely page cache based, and metadata which is done through > various means depending on: > > o which kernel you are running > o which filesystem > > All filesystems that I am aware of except for XFS use buffer heads and the > block cache for metadata I/O. bdflush is responsible for flushing the data > unless the filesystem makes explicit requests. XFS does its own thing > using pagebufs because we came from a totally different buffer cache > architecture, and because we got a little ambitous with our implementation. > > XFS needs to lock variable sized objects, everyone else uses fixed sizes > for the most part. XFS also wants some other behaviors from its buffer > cache. This is where pagebuf came from. Does this have anything to do with the fact that Linux's buffers are fixed sized? In BSD, the buffers can be of variable sizes. I guess if Linux's buffers could be of variable sizes, there would be no need to use pagebuf stuff. Please correct me if I am wrong. Thanks. -Zhihui From owner-linux-xfs@oss.sgi.com Thu Oct 25 08:43:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PFhHu16134 for linux-xfs-outgoing; Thu, 25 Oct 2001 08:43:17 -0700 Received: from dmz.tecosim.de ([194.24.222.241]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PFhDD16112 for ; Thu, 25 Oct 2001 08:43:13 -0700 Received: (from uucp@localhost) by dmz.tecosim.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) id f9PFdDG03965; Thu, 25 Oct 2001 17:39:13 +0200 Received: from ns.tecosim.de(194.24.222.9) via SMTP by dmz.tecosim.de, id smtpdcL990F; Thu Oct 25 17:39:11 2001 Received: from donner.tecosim.de (donner.tecosim.de [194.24.222.109]) by ns.tecosim.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id f9PFdAJ29551; Thu, 25 Oct 2001 17:39:10 +0200 Received: (from leh@localhost) by donner.tecosim.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) id f9PFd9n01835; Thu, 25 Oct 2001 17:39:09 +0200 Date: Thu, 25 Oct 2001 17:39:09 +0200 From: Utz Lehmann To: Steve Lord Cc: "Martin K. Petersen" , Utz Lehmann , Marc Schmitt , Eric Sandeen , linux-xfs@oss.sgi.com, florin@sgi.com Subject: Re: Corruption of in-memory data detected. Message-ID: <20011025173909.A1336@de.tecosim.com> References: <200110251505.f9PF5De15624@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <200110251505.f9PF5De15624@jen.americas.sgi.com>; from lord@sgi.com on Thu, Oct 25, 2001 at 10:05:13AM -0500 X-Scanned-By: MIMEDefang 1.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord [lord@sgi.com] wrote: > > >>>>> "Steve" == Steve Lord writes: > > > > Steve> Ah ha, now thats a good idea - of course I still think its the > > Steve> md code, but at least we have a chance of catching it now. > > > > I took a look at MD last night and didn't see anything obvious > > sticking out. > > > > Will do a second pass in a bit... > > > > -- > > Martin K. Petersen Cereal Bowl Engineer, Linuxcare, Inc. > > http://mkp.net/ SGI XFS, Linux/PA-RISC, GNOME > > Martin, forget md, you can make this happen without it, looks like we > introduced a sign bug ourselves somewhere.... I just toasted the loop > based filesystem in about 10 seconds. Hopefully with a case this > simple to reproduce it should not take long now. Is the loop device unsign safe? utz From owner-linux-xfs@oss.sgi.com Thu Oct 25 08:43:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PFhXL16190 for linux-xfs-outgoing; Thu, 25 Oct 2001 08:43:33 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PFhUD16167 for ; Thu, 25 Oct 2001 08:43:30 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9PFhPK06466 for ; Thu, 25 Oct 2001 08:43:25 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA3400949; Thu, 25 Oct 2001 10:42:09 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA94459; Thu, 25 Oct 2001 10:42:08 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9PFcHh16594; Thu, 25 Oct 2001 10:38:17 -0500 Message-Id: <200110251538.f9PFcHh16594@jen.americas.sgi.com> To: Utz Lehmann cc: Steve Lord , "Martin K. Petersen" , Marc Schmitt , Eric Sandeen , linux-xfs@oss.sgi.com, florin@sgi.com Subject: Re: Corruption of in-memory data detected. References: <200110251505.f9PF5De15624@jen.americas.sgi.com> <20011025173909.A1336@de.tecosim.com> Comments: In-reply-to Utz Lehmann message dated "Thu, 25 Oct 2001 17:39:09 +0200." Date: Thu, 25 Oct 2001 10:38:16 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Utz Lehmann wrote: > > Is the loop device unsign safe? Damn, there you go complicating things again.... I am at least going to dig down into xfs and capture the original error which is shutting us down, from there maybe I can work out where this is coming from. Steve > > > utz From owner-linux-xfs@oss.sgi.com Thu Oct 25 09:21:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PGLF317535 for linux-xfs-outgoing; Thu, 25 Oct 2001 09:21:15 -0700 Received: from dmz.tecosim.de ([194.24.222.241]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PGL8D17510 for ; Thu, 25 Oct 2001 09:21:08 -0700 Received: (from uucp@localhost) by dmz.tecosim.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) id f9PGHGL04120; Thu, 25 Oct 2001 18:17:16 +0200 Received: from ns.tecosim.de(194.24.222.9) via SMTP by dmz.tecosim.de, id smtpdgI0iYh; Thu Oct 25 18:17:08 2001 Received: from donner.tecosim.de (donner.tecosim.de [194.24.222.109]) by ns.tecosim.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id f9PGH6J30505; Thu, 25 Oct 2001 18:17:06 +0200 Received: (from leh@localhost) by donner.tecosim.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) id f9PGH6H03201; Thu, 25 Oct 2001 18:17:06 +0200 Date: Thu, 25 Oct 2001 18:17:06 +0200 From: Utz Lehmann To: Steve Lord Cc: Utz Lehmann , "Martin K. Petersen" , Marc Schmitt , Eric Sandeen , linux-xfs@oss.sgi.com, florin@sgi.com Subject: Re: Corruption of in-memory data detected. Message-ID: <20011025181706.B1336@de.tecosim.com> References: <200110251505.f9PF5De15624@jen.americas.sgi.com> <20011025173909.A1336@de.tecosim.com> <200110251538.f9PFcHh16594@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <200110251538.f9PFcHh16594@jen.americas.sgi.com>; from lord@sgi.com on Thu, Oct 25, 2001 at 10:38:16AM -0500 X-Scanned-By: MIMEDefang 1.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Steve Steve Lord [lord@sgi.com] wrote: > > Utz Lehmann wrote: > > > > Is the loop device unsign safe? > > Damn, there you go complicating things again.... > > I am at least going to dig down into xfs and capture the original > error which is shutting us down, from there maybe I can work out > where this is coming from. loop is NOT unsign safe: donner:/mnt # dd if=/dev/null of=loopfile bs=1024 seek=2247483648 0+0 records in 0+0 records out donner:/mnt # ls -lh loopfile -rw-r--r-- 1 root root 2.1T Oct 25 18:06 loopfile donner:/mnt # losetup /dev/loop0 loopfile donner:/mnt # dd if=/dev/loop0 bs=1024 count=1 skip=2147483648 | head -c10 | cat -v 1+0 records in 1+0 records out ^@^@^@^@^@^@^@^@^@^@ This is ok. donner:/mnt # seq 1 1000 | dd of=/dev/loop0 bs=1024 3+1 records in 3+1 records out donner:/mnt # dd if=/dev/loop0 bs=1024 count=1 skip=2147483648 | head -c10 | cat -v 1+0 records in 1+0 records out 1 2 3 4 5 Look just warping around. Perhaps Marc could make this test with his md device. utz From owner-linux-xfs@oss.sgi.com Thu Oct 25 09:24:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PGObe17901 for linux-xfs-outgoing; Thu, 25 Oct 2001 09:24:37 -0700 Received: from dmz.tecosim.de ([194.24.222.241]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PGOYD17879 for ; Thu, 25 Oct 2001 09:24:34 -0700 Received: (from uucp@localhost) by dmz.tecosim.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) id f9PGL6Z04137; Thu, 25 Oct 2001 18:21:06 +0200 Received: from ns.tecosim.de(194.24.222.9) via SMTP by dmz.tecosim.de, id smtpd6OZjIg; Thu Oct 25 18:20:59 2001 Received: from donner.tecosim.de (donner.tecosim.de [194.24.222.109]) by ns.tecosim.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id f9PGKvJ30585; Thu, 25 Oct 2001 18:20:57 +0200 Received: (from leh@localhost) by donner.tecosim.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) id f9PGKvx03309; Thu, 25 Oct 2001 18:20:57 +0200 Date: Thu, 25 Oct 2001 18:20:57 +0200 From: Utz Lehmann To: Utz Lehmann Cc: Steve Lord , "Martin K. Petersen" , Marc Schmitt , Eric Sandeen , linux-xfs@oss.sgi.com, florin@sgi.com Subject: Re: Corruption of in-memory data detected. Message-ID: <20011025182057.C1336@de.tecosim.com> References: <200110251505.f9PF5De15624@jen.americas.sgi.com> <20011025173909.A1336@de.tecosim.com> <200110251538.f9PFcHh16594@jen.americas.sgi.com> <20011025181706.B1336@de.tecosim.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <20011025181706.B1336@de.tecosim.com>; from ulehmann@de.tecosim.com on Thu, Oct 25, 2001 at 06:17:06PM +0200 X-Scanned-By: MIMEDefang 1.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Utz Lehmann [ulehmann@de.tecosim.com] wrote: > Perhaps Marc could make this test with his md device. ok, i'm stupid. He has only 1.2TB and the default blocksize is 1k. The test doesn't work until he can set his md device to 512 byte blocksize from userspace. utz From owner-linux-xfs@oss.sgi.com Thu Oct 25 09:33:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PGXKL18178 for linux-xfs-outgoing; Thu, 25 Oct 2001 09:33:20 -0700 Received: from chef.cc.absoval.com (cpe-66-1-218-101.fl.sprintbbd.net [66.1.218.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PGXGD18151 for ; Thu, 25 Oct 2001 09:33:16 -0700 Received: from ieee.org (IDENT:bs@thebs.cc.absoval.com [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id MAA27976; Thu, 25 Oct 2001 12:32:16 -0400 Message-ID: <3BD83E9B.E9EEFD4F@ieee.org> Date: Thu, 25 Oct 2001 12:32:27 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts/AbsoluteValueSystems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Utz Lehmann CC: Steve Lord , "Martin K. Petersen" , Marc Schmitt , Eric Sandeen , linux-xfs@oss.sgi.com, florin@sgi.com Subject: Re: Corruption of in-memory data detected. References: <200110251505.f9PF5De15624@jen.americas.sgi.com> <20011025173909.A1336@de.tecosim.com> <200110251538.f9PFcHh16594@jen.americas.sgi.com> <20011025181706.B1336@de.tecosim.com> <20011025182057.C1336@de.tecosim.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Utz Lehmann wrote: > ok, i'm stupid. He has only 1.2TB and the default blocksize is > 1k. The test doesn't work until he can set his md device to > 512 byte blocksize from userspace. I don't know if this has any relevance, but don't the underlying 3Ware cards use a much bigger blocksize??? If this isn't an issue from a compatibility standpoint, how about a performance one? Or am I totally missing the mark here? Are there any other limitations with using such small blocksizes? Even at 512bytes, we should be able to get 2TB (4Gblocks x 512 bytes), right? -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ---------------------------------------------------------------- Web site defacements are as much of a national security risk as inner city kids spray painting. There is nothing of value, and nothing that can't be fixed with a little re-paint. You'd have to have the equivalent stupidity of someone parking an F-18 in downtown LA. Even then, the only damage would be a new scheme! The US government wants life imprisonment for such "terrorism." From owner-linux-xfs@oss.sgi.com Thu Oct 25 09:37:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PGbhC18363 for linux-xfs-outgoing; Thu, 25 Oct 2001 09:37:43 -0700 Received: from cvo-exchange.cvo.roguewave.com (cvo-ext.roguewave.com [12.22.36.198]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PGbbD18341 for ; Thu, 25 Oct 2001 09:37:37 -0700 Received: by cvo-exchange.roguewave.com with Internet Mail Service (5.5.2650.21) id ; Thu, 25 Oct 2001 09:37:30 -0700 Message-ID: From: Poul Petersen To: "'Steve Lord'" , Matteo Centonza Cc: linux-xfs@oss.sgi.com Subject: RE: NFS and xfsdump oops Date: Thu, 25 Oct 2001 09:37:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I thought I had seen this problem before, and indeed I have. Our NFS server has been running for months with no problems, but I recently added the xfs volume into amanda and: Unable to handle kernel NULL pointer dereference at virtual address 00000000 00000000 *pde = 00000000 Oops: 0000 CPU: 1 EIP: 0010:[agp_frontend_cleanup+0/304] EIP: 0010:[<00000000>] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010282 eax: c038a360 ebx: da6a1aa0 ecx: e57910a0 esi: d32bb940 edi: da6a1aa0 ebp: da6a1aa0 ds: 0018 es: 0018 ss: 0018 Process nfsd (pid: 693, stackpage=eb701000) Stack: c016fb94 e57910a0 d32bb940 0a0a67b7 00000020 c0170006 da6a1aa0 f7c41080 ffffff8c 00000000 0a0a67b7 00000020 f5d4d204 eb56c800 c01703e1 ec3a5200 0a0a67b7 00000020 00000000 00000001 000002b5 f5d4d214 11270000 f5d4d204 Call Trace: [nfsd_findparent+52/256] [find_fh_ Call Trace: [] [] [] [] [] [] [] [] [] [] Code: Bad EIP value. >>EIP; 00000000 Before first symbol Trace; c016fb94 Trace; c0170006 Trace; c01703e1 Trace; c0170a40 Trace; c01766a1 Trace; c016e221 Trace; c02addd3 Trace; c016e039 Trace; c0105546 Trace; c016de40 > I have had a kernel pounding away with heavy nfs client access and > repeated level zero dumps ongoing in parallel. So far it is > all working > just fine. I will leave it overnight and see if I cannot > catch something. > > Steve I noticed that the level 0 worked fine, but the Oops occurred the second night when amanda tried to run a level 1. I don't know if that has any bearing on the problem, but I've got a test server I am going to try and duplicate these results on. Our configuration is a Dell server (dual P-II 400) running RedHat 7.1 with 2.4.5 and XFS 1.0.1. Thanks for any insight, -poul From owner-linux-xfs@oss.sgi.com Thu Oct 25 09:41:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PGfXf18547 for linux-xfs-outgoing; Thu, 25 Oct 2001 09:41:33 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PGfTD18523 for ; Thu, 25 Oct 2001 09:41:29 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA08600 for ; Thu, 25 Oct 2001 09:40:46 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA3291833; Thu, 25 Oct 2001 11:40:10 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA16180; Thu, 25 Oct 2001 11:40:09 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9PGaIJ17662; Thu, 25 Oct 2001 11:36:18 -0500 Message-Id: <200110251636.f9PGaIJ17662@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Bryan-TheBS-Smith cc: Utz Lehmann , Steve Lord , "Martin K. Petersen" , Marc Schmitt , Eric Sandeen , linux-xfs@oss.sgi.com, florin@sgi.com Subject: Re: Corruption of in-memory data detected. In-Reply-To: Message from Bryan-TheBS-Smith of "Thu, 25 Oct 2001 12:32:27 EDT." <3BD83E9B.E9EEFD4F@ieee.org> Date: Thu, 25 Oct 2001 11:36:17 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Utz Lehmann wrote: > > ok, i'm stupid. He has only 1.2TB and the default blocksize is > > 1k. The test doesn't work until he can set his md device to > > 512 byte blocksize from userspace. > > I don't know if this has any relevance, but don't the underlying > 3Ware cards use a much bigger blocksize??? If this isn't an issue > from a compatibility standpoint, how about a performance one? > > Or am I totally missing the mark here? > > Are there any other limitations with using such small blocksizes? > Even at 512bytes, we should be able to get 2TB (4Gblocks x 512 > bytes), right? > > -- TheBS > Disk addresses always get converted to 512 byte sectors in the block layer anyway - the 2 Tbyte limit is pretty firmly wedged in the block layer right now. Steve p.s. I am pretty sure I have a fix - and it is not in the kernel! mkfs with the automatic inode sizing is broken above the 1 Tbyte boundary, fix coming shortly. From owner-linux-xfs@oss.sgi.com Thu Oct 25 09:43:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PGhUF18713 for linux-xfs-outgoing; Thu, 25 Oct 2001 09:43:30 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PGhND18691 for ; Thu, 25 Oct 2001 09:43:23 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA04222 for ; Thu, 25 Oct 2001 09:42:41 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA3404660; Thu, 25 Oct 2001 11:42:05 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA15891; Thu, 25 Oct 2001 11:42:05 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9PGcDv17673; Thu, 25 Oct 2001 11:38:13 -0500 Message-Id: <200110251638.f9PGcDv17673@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Poul Petersen cc: "'Steve Lord'" , Matteo Centonza , linux-xfs@oss.sgi.com Subject: Re: NFS and xfsdump oops In-Reply-To: Message from Poul Petersen of "Thu, 25 Oct 2001 09:37:22 PDT." Date: Thu, 25 Oct 2001 11:38:13 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Yes, this is still on my list (somewhere), I just have too much going on right now. There is some funky dcache stuff going on in the interface which xfsdump uses. No workaround or anything as of yet, basically xfsdump and nfs can stamp on each other and produce this result. Steve > I thought I had seen this problem before, and indeed I have. Our NFS > server has been running for months with no problems, but I recently added > the xfs volume into amanda and: > > Unable to handle kernel NULL pointer dereference at virtual address 00000000 > 00000000 > *pde = 00000000 > Oops: 0000 > CPU: 1 > EIP: 0010:[agp_frontend_cleanup+0/304] > EIP: 0010:[<00000000>] > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010282 > eax: c038a360 ebx: da6a1aa0 ecx: e57910a0 > esi: d32bb940 edi: da6a1aa0 ebp: da6a1aa0 > ds: 0018 es: 0018 ss: 0018 > Process nfsd (pid: 693, stackpage=eb701000) > Stack: c016fb94 e57910a0 d32bb940 0a0a67b7 00000020 c0170006 da6a1aa0 > f7c41080 > ffffff8c 00000000 0a0a67b7 00000020 f5d4d204 eb56c800 c01703e1 > ec3a5200 > 0a0a67b7 00000020 00000000 00000001 000002b5 f5d4d214 11270000 > f5d4d204 > Call Trace: [nfsd_findparent+52/256] [find_fh_ > Call Trace: [] [] [] [] [] > [] [] > [] [] [] > Code: Bad EIP value. > > >>EIP; 00000000 Before first symbol > Trace; c016fb94 > Trace; c0170006 > Trace; c01703e1 > Trace; c0170a40 > Trace; c01766a1 > Trace; c016e221 > Trace; c02addd3 > Trace; c016e039 > Trace; c0105546 > Trace; c016de40 > > > I have had a kernel pounding away with heavy nfs client access and > > repeated level zero dumps ongoing in parallel. So far it is > > all working > > just fine. I will leave it overnight and see if I cannot > > catch something. > > > > Steve > > I noticed that the level 0 worked fine, but the Oops occurred the > second night when amanda tried to run a level 1. I don't know if that has > any bearing on the problem, but I've got a test server I am going to try and > duplicate these results on. Our configuration is a Dell server (dual P-II > 400) running RedHat 7.1 with 2.4.5 and XFS 1.0.1. > > Thanks for any insight, > > > -poul From owner-linux-xfs@oss.sgi.com Thu Oct 25 09:44:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PGiiw18778 for linux-xfs-outgoing; Thu, 25 Oct 2001 09:44:44 -0700 Received: from trillium-hollow.org (IDENT:root@trillium-hollow.org [209.180.166.89]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PGieD18750 for ; Thu, 25 Oct 2001 09:44:40 -0700 Received: from erich (helo=trillium) by trillium-hollow.org with local-esmtp (Exim 3.20 #1) id 15wncH-0000Ny-00; Thu, 25 Oct 2001 09:44:25 -0700 To: Steve Lord cc: linux-xfs@oss.sgi.com, Stuart Luppescu Subject: Re: GRUB in RedHat 7.2 xfs In-Reply-To: Your message of "Thu, 25 Oct 2001 09:36:01 CDT." <200110251436.f9PEa1F09054@jen.americas.sgi.com> Date: Thu, 25 Oct 2001 09:44:25 -0700 From: erich@uruk.org Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: > I got the xfs patch for grub and built an rpm with it installed - the > redhat version does not have it in there. > > I have not had time to test it yet, but we could put it up > on the ftp site for some brave souls witj disposable machines > to try out. I tried the 0.90 version w/the XFS/JFS patch ver 1.0 (which was the most recent one as of a few days ago, still dated Aug 29th). It appears to work fine, though I haven't sniffed through the source in detail to see if it does stuff like replay the logs... but that's probably ok since when you use it in general it's read-only (only writes if you run the install command), so I initially tested it running off of a floppy. I'm glad that guy made the patch, since I only got time again recently (which I spent first on tracking down the RH compiler 2.96 bug). FYI, I'm active again in GRUB development, and am going to get this patch into the main CVS tree ASAP. -- Erich Stefan Boleyn http://www.uruk.org/ "Reality is truly stranger than fiction; Probably why fiction is so popular" -- Erich Stefan Boleyn http://www.uruk.org/ "Reality is truly stranger than fiction; Probably why fiction is so popular" From owner-linux-xfs@oss.sgi.com Thu Oct 25 09:46:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PGkDh19013 for linux-xfs-outgoing; Thu, 25 Oct 2001 09:46:13 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PGkAD18989 for ; Thu, 25 Oct 2001 09:46:10 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA06567 for ; Thu, 25 Oct 2001 09:45:28 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA3400118 for ; Thu, 25 Oct 2001 11:44:53 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA72805 for ; Thu, 25 Oct 2001 11:44:53 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id f9PGf1Y17742; Thu, 25 Oct 2001 11:41:01 -0500 Message-Id: <200110251641.f9PGf1Y17742@jen.americas.sgi.com> Date: Thu, 25 Oct 2001 11:41:01 -0500 Subject: TAKE - fix mkfs for 1Tbyte plus filesystems Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk mkfs was automatically resizing inodes for filesystems larger than 1 Tbyte, but was not fixing up another superblock field. End result was some pretty quick toasting of the filesystem. I have tested this on a loop device and stuff that used to crash now works again. I will get some updated rpms onto the ftp site today. Steve Date: Thu Oct 25 09:42:56 PDT 2001 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:105445a cmd/xfsprogs/mkfs/xfs_mkfs.c - 1.16 - If we change the inode size, change the inode size log as well. From owner-linux-xfs@oss.sgi.com Thu Oct 25 09:47:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PGlbl19170 for linux-xfs-outgoing; Thu, 25 Oct 2001 09:47:37 -0700 Received: from mx02.uni-tuebingen.de (mx02.uni-tuebingen.de [134.2.3.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PGlPD19141 for ; Thu, 25 Oct 2001 09:47:25 -0700 Received: from mailserv05.uni-tuebingen.de (mailserv05.uni-tuebingen.de [192.168.3.15]) by mx02.uni-tuebingen.de (8.9.3/8.9.3) with ESMTP id SAA03981 for ; Thu, 25 Oct 2001 18:47:23 +0200 Received: from chimaera (pool2200.studentenheim.uni-tuebingen.de [134.2.212.200]) by mailserv05.uni-tuebingen.de (8.9.3/8.9.3) with SMTP id SAA00367 for ; Thu, 25 Oct 2001 18:47:23 +0200 Message-ID: <001901c15d74$b219f680$0a42a8c0@chimaera> From: "Simon Pabst" To: Subject: 2.4.9-PR3 kernel message Date: Thu, 25 Oct 2001 18:47:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi everybody, I have a question about a kernel message that appears in my /var/log/messages: ---------- Oct 25 11:01:00 judicator kernel: blk: queue c03746a4, I/O limit 4095Mb (mask 0xffffffff) ---------- I'm getting this since I installed Eric's RH7.1 XFS 2.4.9-6PR3 on my roswell system, recompiled (kgcc) from sources with lvm enabled. It occurs several times per hour when I'm writing to my xfs-lvm-stripeset, two maxtor 80gb drives, but I did not notice any problems - Is this message xfs related or lvm? or something completely different? I'm on a Athlon system, VIA kt133 board, the harddrives are both attached to a Promise PDC20268. thx -simon ----- Original Message ----- From: "Eric Sandeen" To: "Simon Pabst" Sent: Thursday, October 25, 2001 4:16 PM Subject: Re: For Testing - updated RH7.1 XFS 2.4.9-6 kernels > Not sure about gcc... 3.0 maybe. > > I also don't know about the error message... perhaps this is one for the > list? > > -Eric > > Simon Pabst wrote: > > > > Hi Eric, > > thx again, ntfs compiles fine now. I don't need ntfs on my > > server box, but compiled it to test if it works at all, > > cause I'll need it on my desktop when the installer for 7.2 > > is released ;-) > > What do you think is a _new_ version of gcc? > > Doesn't roswell's gcc 2.96-96 do the trick? > > BTW my lvm-xfs volume seems to work fine > > I'm using two 80gb maxtor drives striped to a > > raid0 - but I'm getting kernel messages in /var/log/messages > > like this one: > > ---- > > Oct 25 11:01:00 judicator kernel: blk: queue c03746a4, I/O limit 4095Mb > > (mask 0xffffffff) > > ---- > > > > is this related to lvm/xfs? I searched through the list and the web and > > found nothing appropriate. > > > > thx > > -simon > > > > ----- Original Message ----- > > From: "Eric Sandeen" > > To: "Simon Pabst" > > Sent: Thursday, October 25, 2001 4:23 AM > > Subject: Re: For Testing - updated RH7.1 XFS 2.4.9-6 kernels > > > > > Hi Simon - > > > > > > Try changing the "..." on line 25 of fs/ntfs/support.h to "ARGS..." - > > > i.e. > > > > > > #define ntfs_debug(mask, fmt, ARGS...) do {} while (0) > > > > > > Apparently _newer_ versions of gcc/cpp can handle it the way it is in > > > the original code... > > > > > > FWIW, we never _touched_ this file. :) > > > > > > -Eric > > > > > > Simon Pabst wrote: > > > > > > > > Hi Eric, > > > > just compiled a PR3-kernel, checked my old (reiser) lvm drives and > > changed > > > > them to xfs without even a hint of a problem. > > > > Great work, thanks! > > > > I'll let you now if anything goes wrong. > > > > But I have another small problem - the NTFS module. > > > > Once again one of those RH doesn't compile by default. > > > > I get : > > > > ----------------------------- > > > > .... > > > > > > kgcc -D__KERNEL__ -I/usr/src/linux-2.4.9-6SGI_XFS_PR3/include -Wall -Wstri > > > > > > ct-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -Wno-unuse > > > > > > d -fomit-frame-pointer -pipe -march=i686 -malign-functions=4 -DMODULE -DNT > > > > FS_VERSION=\"1.1.18\" -c -o fs.o fs.c > > > > In file included from fs.c:21: > > > > support.h:25: badly punctuated parameter list in `#define' > > > > fs.c: In function `ntfs_read': > > > > fs.c:75: warning: implicit declaration of function `ntfs_debug' > > > > make[2]: *** [fs.o] Error 1 > > > > make[2]: Leaving directory `/usr/src/linux-2.4.9-6SGI_XFS_PR3/fs/ntfs' > > > > make[1]: *** [_modsubdir_ntfs] Error 2 > > > > make[1]: Leaving directory `/usr/src/linux-2.4.9-6SGI_XFS_PR3/fs' > > > > make: *** [_mod_fs] Error 2 > > > > ---------------------------------- > > > > (both kgcc and gcc) > > > > > > > > -simon > > > > > From owner-linux-xfs@oss.sgi.com Thu Oct 25 10:20:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PHK9D19968 for linux-xfs-outgoing; Thu, 25 Oct 2001 10:20:09 -0700 Received: from rhenium (rhenium.btinternet.com [194.73.73.93]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PHK1D19944 for ; Thu, 25 Oct 2001 10:20:01 -0700 Received: from [217.35.14.232] (helo=scooby) by rhenium with esmtp (Exim 3.22 #6) id 15woAg-00001P-00; Thu, 25 Oct 2001 18:19:58 +0100 From: "Neil Johnson" To: "'root'" , Subject: RE: XFS with SuSE Linux 7.3, Kernel 2.4.10 Date: Thu, 25 Oct 2001 18:19:52 +0100 Message-ID: <000a01c15d79$430a2990$3200a8c0@subspin.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.2627 In-Reply-To: <3BD7E604.1FE3F2A2@verwaltung.uni-karlsruhe.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The patches are usually made against a `clean` kernel. Were there any errors when you applied the patch? Also did you download a clean copy of 2.4.10 from kernel.org or have you used the SuSE supplied kernel source? - I would always recommend applying any "3rd Party" patches against a clean kernel and not vendor supplied. Also it sometimes helps to make a copy of /usr/src/linux/.config and then running a "make mrproper". Once this is complete, copy the .config file back and re-run "make menuconfig" verify that the configuration is correct and then try re-compiling. I would also suggest that you don't use 2.4.10 since it was pretty unstable in my test environment, never mind a production machine. The most stable recent kernel I can think of was 2.4.9, although 2.4.12 seems OK on my system, I have heard reports of it being `un-suitable` for production machines. Hope this helps. Neil. -----Original Message----- From: owner-linux-xfs@oss.sgi.com [mailto:owner-linux-xfs@oss.sgi.com] On Behalf Of root Sent: 25 October 2001 11:14 To: linux-xfs@oss.sgi.com Subject: XFS with SuSE Linux 7.3, Kernel 2.4.10 Hello, i really need your help. I have to set up a SAMBA-Server on a XFS-Filesystem because compatibility to SGI-IRIX is needed. I' m using SuSE Linux 7.3 with kernel 2.4.10. glibc is 2.2.4-21, GNU gcc is 2.95.3-124, make is 3.79.1-166. I tried to patch and compile the kernel with your linux-2.4.10-xfs-2001-10-03.patch.bz2 patchfile. Everything worked fine up to pagebuf.c (see my logfile). It seems that VM_PAGEBUF in line 2279 isn' t declared correctly. But as i don' t know enough about developing in C i' m again urgently asking for your support and therefore for a solution for this problem. I hopefully await your answer. Thank you very much in advance for your support. Greetings and best wishes to the XFS-SGI team Robert From owner-linux-xfs@oss.sgi.com Thu Oct 25 10:29:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PHT7d20289 for linux-xfs-outgoing; Thu, 25 Oct 2001 10:29:07 -0700 Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PHT3D20267 for ; Thu, 25 Oct 2001 10:29:03 -0700 Received: from scare ([63.231.179.33]) by lips.thebarn.com (8.12.0/8.12.0) with ESMTP id f9PHTBbw046993; Thu, 25 Oct 2001 12:29:12 -0500 (CDT) Subject: Re: GRUB in RedHat 7.2 xfs From: Russell Cattelan To: Stuart Luppescu Cc: linux-xfs@oss.sgi.com In-Reply-To: <1004017885.10400.2.camel@musuko.uchicago.edu> References: <1004017885.10400.2.camel@musuko.uchicago.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 25 Oct 2001 12:24:57 -0500 Message-Id: <1004030699.3201.20.camel@scare> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2001-10-25 at 08:51, Stuart Luppescu wrote: > I remember hearing something about GRUB not being xfs aware, or > something like that. Are we limited to LILO, or will the XFS RedHat 7.2 > installer properly handle GRUB? Just a little curiousity. The version of grub shipped with Mandrake 8.1 is XFS aware and has worked flawlessly for me so far. I do not know about RH but obviously it shouldn't be to hard to grab the mandrake srpm, compile it for a RH install... or maybe even just install the Mandrake rpm. > -- > ______________________________________________________________________ > Stuart Luppescu -=-=- University of Chicago > $(B:MJ8$HCRF`H~$NIc(B -=-=- s-luppescu@uchicago.edu > http://www.consortium-chicago.org/people/sl.html > http://musuko.uchicago.edu/pubkey.asc for PGP Public Key > ICQ #21172047 AIM: psycho7070 From owner-linux-xfs@oss.sgi.com Thu Oct 25 10:44:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PHida21153 for linux-xfs-outgoing; Thu, 25 Oct 2001 10:44:39 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PHiXD21130 for ; Thu, 25 Oct 2001 10:44:33 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA14358 for ; Thu, 25 Oct 2001 10:44:27 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA3398145; Thu, 25 Oct 2001 12:43:15 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA28494; Thu, 25 Oct 2001 12:43:15 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9PHdNI02151; Thu, 25 Oct 2001 12:39:23 -0500 Message-Id: <200110251739.f9PHdNI02151@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: erich@uruk.org cc: Steve Lord , linux-xfs@oss.sgi.com, Stuart Luppescu Subject: Re: GRUB in RedHat 7.2 xfs In-Reply-To: Message from erich@uruk.org of "Thu, 25 Oct 2001 09:44:25 PDT." Date: Thu, 25 Oct 2001 12:39:22 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > Steve Lord wrote: > > > I got the xfs patch for grub and built an rpm with it installed - the > > redhat version does not have it in there. > > > > I have not had time to test it yet, but we could put it up > > on the ftp site for some brave souls witj disposable machines > > to try out. > > I tried the 0.90 version w/the XFS/JFS patch ver 1.0 (which was the most > recent one as of a few days ago, still dated Aug 29th). > > It appears to work fine, though I haven't sniffed through the source in > detail to see if it does stuff like replay the logs... but that's > probably ok since when you use it in general it's read-only (only writes > if you run the install command), so I initially tested it running off of > a floppy. I have looked briefly at the code - and built a redhat based rpm with the patch in there. It does not do log replay, but that is a really complex task which nothing except the kernel does right now. My only other concern with the code from a quick read was what would happen in a really large directory, or in a really small one which fit inside the inode. The number of filesystem combinations which xfs could generate is large, and I am not sure all the directory options are covered. I could be wrong, I spent all of 15 minutes on the code. > > I'm glad that guy made the patch, since I only got time again recently > (which I spent first on tracking down the RH compiler 2.96 bug). > > FYI, I'm active again in GRUB development, and am going to get this > patch into the main CVS tree ASAP. This would be good to have in there, thanks. Steve > > -- > Erich Stefan Boleyn http://www.uruk.org/ > "Reality is truly stranger than fiction; Probably why fiction is so popular" > -- > Erich Stefan Boleyn http://www.uruk.org/ > "Reality is truly stranger than fiction; Probably why fiction is so popular" From owner-linux-xfs@oss.sgi.com Thu Oct 25 10:52:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PHqxp21728 for linux-xfs-outgoing; Thu, 25 Oct 2001 10:52:59 -0700 Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PHquD21706 for ; Thu, 25 Oct 2001 10:52:56 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA20726 for ; Thu, 25 Oct 2001 13:50:23 -0400 Received: from d03nm800.boulder.ibm.com (d03nm800.boulder.ibm.com [9.99.140.145]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f9PHqs076028 for ; Thu, 25 Oct 2001 11:52:54 -0600 Subject: DMAPI header licensing To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "James A Goodwin" Date: Thu, 25 Oct 2001 12:52:52 -0500 X-MIMETrack: Serialize by Router on D03NM800/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/25/2001 11:52:54 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk About six weeks ago the source files for the libdm and libhandle libraries were updated to be under the LGPL so that clients wishing to use the DMAPI would be able to do so. However, dmapi.h is still under GPL. Could this (and any other header files necessary to compile a DMAPI client) file be placed under the LGPL as well? Thanks, -James Goodwin Software Engineer IBM Global Services - Federal jagoodwi@us.ibm.com From owner-linux-xfs@oss.sgi.com Thu Oct 25 11:14:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PIEdI26598 for linux-xfs-outgoing; Thu, 25 Oct 2001 11:14:39 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PIEaD26575 for ; Thu, 25 Oct 2001 11:14:36 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA00109 for ; Thu, 25 Oct 2001 11:13:54 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA3396222 for ; Thu, 25 Oct 2001 13:13:19 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA54502 for ; Thu, 25 Oct 2001 13:13:19 -0500 (CDT) Subject: Updated userspace packages available From: Eric Sandeen To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 25 Oct 2001 13:11:33 -0500 Message-Id: <1004033493.23897.21.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Updated userspace packages are now available on the ftp site, including a crucial fix for xfsprogs/mkfs over 1 TB. acl-1.1.3 attr-1.1.3 dmapi-0.2.2 xfsdump-1.1.7 xfsprogs-1.3.13 -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Oct 25 11:30:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PIUI127198 for linux-xfs-outgoing; Thu, 25 Oct 2001 11:30:18 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PIUBD27171 for ; Thu, 25 Oct 2001 11:30:11 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id UAA762574 for ; Thu, 25 Oct 2001 20:30:05 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA3406507; Thu, 25 Oct 2001 13:28:45 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA95965; Thu, 25 Oct 2001 13:28:45 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9PIOqE08390; Thu, 25 Oct 2001 13:24:52 -0500 Message-Id: <200110251824.f9PIOqE08390@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Marc Schmitt cc: Steve Lord , Eric Sandeen , linux-xfs@oss.sgi.com, florin@sgi.com Subject: Re: Corruption of in-memory data detected. In-Reply-To: Message from Marc Schmitt of "Thu, 25 Oct 2001 14:09:32 +0200." <3BD800FC.6020005@inf.ethz.ch> Date: Thu, 25 Oct 2001 13:24:52 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Just in case I did not make it obvious, we think the fix for this is a new mkfs. The old one was generating inconsistent superblocks for filesystems above 1 Tbyte. The only folks affected by this probably had filesystems which would take down the machine if you used them anyway. So if your filesystem is working for you using the old mkfs then there is no need to do anything except upgrade the commands. If you made a filesystem of greater than 1 Tbyte using mkfs -t xfs -i size=512 ..... then you should also not be affected. Steve > Steve Lord wrote: > > > Yes, but the detection process may need some work - ext2 will probably > > have radically different behavior on an error. It may throw up on the > > filesystem, or you may have to run fsck afterwards to see what happened > > to the fs. > > > Hmm, using mke2fs 1.25 (with m set to 1), mongo runs a complete > benchmark over the 1.2TB: > Filesystem 1k-blocks Used Available Use% Mounted on > /dev/md0 1135510828 20 1123788584 1% /local > > After unmounting, I ran e2fsck:e2fsck 1.25 (20-Sep-2001) > /dev/md0: clean, 11/293076992 files, 9177898/293055600 blocks > > Same steps as above with the current version of e2fsprogs on a RedHat > 7.1 system showed no different result (e2fsck 1.23, 15-Aug-2001 for EXT2 > FS 0.5b, 95/08/09) > > > Greetz > Marc > From owner-linux-xfs@oss.sgi.com Thu Oct 25 12:19:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PJJAP28342 for linux-xfs-outgoing; Thu, 25 Oct 2001 12:19:10 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PJJ7D28319 for ; Thu, 25 Oct 2001 12:19:07 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9PJJ2K20597 for ; Thu, 25 Oct 2001 12:19:02 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA3407575 for ; Thu, 25 Oct 2001 14:17:46 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA35893 for ; Thu, 25 Oct 2001 14:17:46 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id f9PJDrU12668; Thu, 25 Oct 2001 14:13:53 -0500 Message-Id: <200110251913.f9PJDrU12668@jen.americas.sgi.com> Date: Thu, 25 Oct 2001 14:13:53 -0500 Subject: TAKE - fix xfs remount readonly Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk There was a window in the remount readonly path which would lead to a corrupted filesystem - an inode change would not make it out to disk, but everything else related to it would. This was triggered by some shutdown scripts which put a file into the root filesystem as the very last action performed. Date: Thu Oct 25 12:15:10 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:105457a linux/fs/xfs/linux/xfs_lrw.c - 1.114 linux/fs/xfs/linux/xfs_super.c - 1.142 From owner-linux-xfs@oss.sgi.com Thu Oct 25 12:26:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PJQZV28694 for linux-xfs-outgoing; Thu, 25 Oct 2001 12:26:35 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PJQOD28660 for ; Thu, 25 Oct 2001 12:26:24 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA07151 for ; Thu, 25 Oct 2001 12:26:21 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA3382753 for ; Thu, 25 Oct 2001 14:25:02 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA57715 for ; Thu, 25 Oct 2001 14:25:02 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id f9PJL9Y12773; Thu, 25 Oct 2001 14:21:09 -0500 Message-Id: <200110251921.f9PJL9Y12773@jen.americas.sgi.com> Date: Thu, 25 Oct 2001 14:21:09 -0500 Subject: TAKE - merge up to 2.4.13 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a combination of merging up to 2.4.13 and cleaning up some mismatched rcs ids which had crept into the tree. It also makes the block device cache and the xfs metadata cache coherent - well almost coherent. The xfs super block and the log are written from special purpose buffers which are not part of the regular cache. Since unmount flushes and removes all cached data, the only time the inconsistency shows up is if you look at the block device while the fs is mounted. A consequence of this is that regression test number 17 in the test suite will now fail - since it does precisely this. I hope to fix the super block one at least at some point, this will make xfs_db on a running fs more useful, but the log may never be fully coherent with the block device interface... Steve Date: Thu Oct 25 12:19:10 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:105458a linux/net/ipv6/tcp_ipv6.c - 1.29 linux/net/ipv6/af_inet6.c - 1.19 linux/net/ipv4/udp.c - 1.27 linux/net/ipv4/syncookies.c - 1.12 linux/net/ipv4/route.c - 1.28 linux/net/ipv4/ipip.c - 1.20 linux/net/ipv4/ipconfig.c - 1.20 linux/net/ipv4/ip_output.c - 1.29 linux/net/bridge/br.c - 1.20 linux/mm/vmscan.c - 1.83 linux/mm/swap.c - 1.16 linux/mm/page_alloc.c - 1.62 linux/kernel/exit.c - 1.31 linux/include/linux/swap.h - 1.45 linux/include/linux/slab.h - 1.19 linux/include/linux/mm.h - 1.68 linux/include/linux/locks.h - 1.7 linux/include/linux/fs.h - 1.129 linux/include/asm-sparc64/types.h - 1.6 linux/include/asm-sparc64/scatterlist.h - 1.6 linux/include/asm-sparc/scatterlist.h - 1.7 linux/fs/ntfs/fs.c - 1.33 linux/fs/buffer.c - 1.90 linux/drivers/video/leofb.c - 1.10 linux/drivers/video/creatorfb.c - 1.13 linux/drivers/video/cgsixfb.c - 1.12 linux/drivers/sbus/char/zs.c - 1.19 linux/drivers/sbus/char/su.c - 1.19 linux/drivers/sbus/char/sab82532.c - 1.23 linux/drivers/sbus/audio/amd7930.c - 1.10 linux/drivers/net/sunhme.c - 1.32 linux/arch/sparc64/kernel/rtrap.S - 1.10 linux/arch/sparc64/kernel/head.S - 1.13 linux/arch/sparc64/kernel/dtlb_base.S - 1.12 linux/arch/i386/kernel/smp.c - 1.36 linux/Makefile - 1.144 linux/MAINTAINERS - 1.79 linux/drivers/sbus/char/aurora.c - 1.14 linux/arch/sparc64/kernel/pci_sabre.c - 1.26 linux/arch/sparc64/kernel/pci_psycho.c - 1.23 linux/arch/sparc64/kernel/pci_iommu.c - 1.13 linux/arch/sh/mm/init.c - 1.17 linux/arch/sh/mm/fault.c - 1.18 linux/arch/sh/lib/memset.S - 1.3 linux/arch/sh/lib/memmove.S - 1.3 linux/arch/sh/lib/memcpy.S - 1.3 linux/arch/sh/kernel/ptrace.c - 1.12 linux/arch/sh/kernel/process.c - 1.16 linux/include/asm-sh/uaccess.h - 1.11 linux/include/asm-sh/namei.h - 1.4 linux/mm/highmem.c - 1.27 linux/arch/sh/lib/memchr.S - 1.2 linux/arch/sparc64/kernel/sbus.c - 1.13 linux/arch/sparc64/kernel/iommu_common.h - 1.4 linux/arch/sparc64/kernel/iommu_common.c - 1.7 linux/arch/sh/kernel/io_se.c - 1.5 linux/arch/sh/kernel/io_generic.c - 1.5 linux/fs/xfs/linux/xfs_super.c - 1.143 linux/include/linux/page_buf.h - 1.99 linux/kdb/modules/kdbm_pg.c - 1.41 linux/fs/pagebuf/page_buf_locking.c - 1.15 linux/drivers/mtd/Config.in - 1.9 linux/arch/sh/kernel/io_hd64461.c - 1.4 linux/kdb/ChangeLog - 1.9 linux/drivers/sound/ymfpci.c - 1.12 linux/arch/sparc64/kernel/pci_schizo.c - 1.11 linux/arch/cris/Makefile - 1.8 linux/arch/cris/drivers/ethernet.c - 1.7 linux/arch/cris/drivers/serial.c - 1.8 linux/arch/cris/kernel/Makefile - 1.7 linux/arch/cris/kernel/entry.S - 1.9 linux/arch/cris/kernel/head.S - 1.8 linux/arch/cris/kernel/process.c - 1.9 linux/arch/cris/kernel/setup.c - 1.8 linux/arch/cris/lib/checksum.S - 1.6 linux/arch/cris/lib/checksumcopy.S - 1.7 linux/arch/cris/boot/rescue/head.S - 1.4 linux/arch/cris/boot/rescue/kimagerescue.S - 1.4 linux/arch/cris/boot/rescue/testrescue.S - 1.4 linux/arch/cris/drivers/usb-host.c - 1.8 linux/arch/cris/lib/dram_init.S - 1.6 linux/arch/cris/drivers/parport.c - 1.6 linux/drivers/mtd/chips/Makefile - 1.4 linux/arch/cris/drivers/lpslave/bintocarr.pl - 1.4 linux/drivers/scsi/dpt_i2o.c - 1.5 linux/arch/sh/mm/cache-sh3.c - 1.3 linux/arch/sh/mm/cache-sh4.c - 1.3 linux/drivers/message/i2o/i2o_scsi.c - 1.3 linux/drivers/message/i2o/i2o_proc.c - 1.2 linux/drivers/message/i2o/i2o_pci.c - 1.3 linux/drivers/message/i2o/i2o_lan.c - 1.2 linux/drivers/message/i2o/i2o_core.c - 1.3 linux/drivers/message/i2o/i2o_config.c - 1.2 linux/drivers/message/i2o/i2o_block.c - 1.2 From owner-linux-xfs@oss.sgi.com Thu Oct 25 12:28:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PJS3128847 for linux-xfs-outgoing; Thu, 25 Oct 2001 12:28:03 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PJS1D28825 for ; Thu, 25 Oct 2001 12:28:01 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA09490 for ; Thu, 25 Oct 2001 12:28:02 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA3406771 for ; Thu, 25 Oct 2001 14:26:45 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA72419 for ; Thu, 25 Oct 2001 14:26:44 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id f9PJMpi12887; Thu, 25 Oct 2001 14:22:51 -0500 Message-Id: <200110251922.f9PJMpi12887@jen.americas.sgi.com> Date: Thu, 25 Oct 2001 14:22:51 -0500 Subject: TAKE - Bump xfsprogs version number Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu Oct 25 12:26:37 PDT 2001 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:105459a cmd/xfsprogs/doc/CHANGES - 1.44 cmd/xfsprogs/VERSION - 1.34 From owner-linux-xfs@oss.sgi.com Thu Oct 25 12:37:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PJbm729188 for linux-xfs-outgoing; Thu, 25 Oct 2001 12:37:48 -0700 Received: from localhost.localdomain (h218-19.afara.com [63.113.218.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PJbeD29156 for ; Thu, 25 Oct 2001 12:37:40 -0700 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id f9PJcZ602783; Thu, 25 Oct 2001 12:38:36 -0700 Subject: Re: bonnie hangs on 2.4.7-10SGI_XFS_PR1 From: Thomas Duffy To: Thomas Duffy Cc: XFS Mailing List In-Reply-To: <1003542802.16337.32.camel@tduffy-lnx.afara.com> References: <1003542802.16337.32.camel@tduffy-lnx.afara.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16 (Preview Release) Date: 25 Oct 2001 12:38:35 -0700 Message-Id: <1004038716.2705.9.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I am happy to report that after upgrading to 2.4.9-7SGI_XFS_PR3, this bug no longer happens. I am able to complete bonnie++ runs on both sync'd and unsync'd MD. I still don't know what was causing the original problem, but it seems to be fixed w/ later XFS/RH kernel. Cross your fingers. -tduffy On Fri, 2001-10-19 at 18:53, Thomas Duffy wrote: > I have a MD RAID 10 device hooked up to a 2 p 2G machine (running > enterprise version of the kernel), basically setup like this: > > < ----------------- > stripe (RAID 0) > > [ d1 | d2 | d3 | d4 ] > ^ ^ ^ ^ > | | | | mirrors (RAID 1) > > [ d5 d6 d7 d8 ] > > both the RAID 1's and RAID 0's have 64k chunks. > > when I run bonnie on this, very soon (like 5 minutes into the test), the > process hangs on D. it is of course unkillable and unhappy. here is the > btp from kdb of the bonnie++ process: > > 0xeaa45e10 0xc01180a1 schedule+0x485 (0xc1fc9a78) > kernel .text 0xc0100000 0xc0117c1c > 0xc01182ac > 0xc012d022 ___wait_on_page+0x66 (0xc1fc9a78, 0x0) > kernel .text 0xc0100000 0xc012cfbc > 0xc012d06c > 0xc012c471 truncate_list_pages+0xd5 (0xeaa45e94) > kernel .text 0xc0100000 0xc012c39c > 0xc012c6ac > 0xc012c719 truncate_inode_pages+0x6d (0xeafb7118, 0x0, 0x0) > kernel .text 0xc0100000 0xc012c6ac > 0xc012c76c > 0xc017116e pagebuf_inval+0x1a (0xeafb7060, 0x0, 0x0, 0x0) > kernel .text 0xc0100000 0xc0171154 > 0xc0171174 > 0xc01e3b61 fs_tosspages+0x29 (0xf5a51bb0, 0x0, 0x0, > 0xffffffff, 0xffffffff) > kernel .text 0xc0100000 0xc01e3b38 > 0xc01e3b68 > 0xc01c36af xfs_itruncate_start+0x8f (0xf5a51b98, 0x1, 0x0, > 0x0, 0xf5a51b98) > kernel .text 0xc0100000 0xc01c3620 > 0xc01c36b8 > 0xc01dcac9 xfs_inactive+0x1b9 (0xf5a51bb0, 0x0) > kernel .text 0xc0100000 0xc01dc910 > 0xc01dcd90 > 0xc01ec7bf vn_put+0x4b (0xeafb7184) > kernel .text 0xc0100000 0xc01ec774 > 0xc01ec838 > 0xc01eb9ab linvfs_put_inode+0x17 (0xeafb7060) > kernel .text 0xc0100000 0xc01eb994 > 0xc01eb9b0 > 0xc0154f2d iput_free+0x2d (0xeafb7060) > kernel .text 0xc0100000 0xc0154f00 > 0xc015510c > 0xc0152dc6 d_delete+0x62 (0xeac42560) > kernel .text 0xc0100000 0xc0152d64 > 0xc0152e04 > 0xc014b81d vfs_unlink+0x1e9 (0xecc287a0, 0xeac42560) > kernel .text 0xc0100000 0xc014b634 > 0xc014b854 > 0xc014b8fa sys_unlink+0xa6 (0x80529b0, 0x0, 0xbffff4e0, 0x3, > 0x80529b0) > kernel .text 0xc0100000 0xc014b854 > 0xc014b978 > 0xc0107073 system_call+0x33 > kernel .text 0xc0100000 0xc0107040 > 0xc0107078 > > > the system is still usable, but anything that tries to hit that array > hangs. any other info I can gather to help debug this? > > -tduffy > From owner-linux-xfs@oss.sgi.com Thu Oct 25 14:06:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PL6Ip02829 for linux-xfs-outgoing; Thu, 25 Oct 2001 14:06:18 -0700 Received: from umbi3.umbi.umd.edu (umbi3.umbi.umd.edu [136.160.7.51]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PL6ED02807 for ; Thu, 25 Oct 2001 14:06:15 -0700 Received: from umbi.umd.edu (mystery.carb.nist.gov [129.6.113.182]) by umbi3.umbi.umd.edu (Netscape Messaging Server 4.15) with ESMTP id GLS5AE00.OLZ; Thu, 25 Oct 2001 17:06:14 -0400 Message-ID: <3BD87EC3.4A1E938B@umbi.umd.edu> Date: Thu, 25 Oct 2001 17:06:11 -0400 From: Jonathan Dill Organization: CARB X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-6SGI_XFS_PR3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: Marc Schmitt , Eric Sandeen , linux-xfs@oss.sgi.com, florin@sgi.com Subject: Re: Corruption of in-memory data detected. References: <200110241510.f9OFAR707303@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk FWIW, I discovered that the Filesize limit problem that I was having is due to a bug in tcsh--From tcsh, even though the filesize limit is set to "unlimited" I cannot create a file > 2 GB. I was able to reproduce this problem by several different methods. From bash, I can create files > 2 GB with no problems. > So the size issue is something else - either a system problem on > your end - do you have user limits set to other than the > default? -- "Jonathan F. Dill" (dill@umbi.umd.edu) From owner-linux-xfs@oss.sgi.com Thu Oct 25 14:10:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PLAIC03028 for linux-xfs-outgoing; Thu, 25 Oct 2001 14:10:18 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PLAFD03006 for ; Thu, 25 Oct 2001 14:10:15 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9PLA9K25944 for ; Thu, 25 Oct 2001 14:10:09 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA3407835; Thu, 25 Oct 2001 16:08:53 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA19743; Thu, 25 Oct 2001 16:08:52 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9PL4xk19189; Thu, 25 Oct 2001 16:04:59 -0500 Message-Id: <200110252104.f9PL4xk19189@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Jonathan Dill cc: Steve Lord , Marc Schmitt , Eric Sandeen , linux-xfs@oss.sgi.com, florin@sgi.com Subject: Re: Corruption of in-memory data detected. In-Reply-To: Message from Jonathan Dill of "Thu, 25 Oct 2001 17:06:11 EDT." <3BD87EC3.4A1E938B@umbi.umd.edu> Date: Thu, 25 Oct 2001 16:04:58 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > FWIW, I discovered that the Filesize limit problem that I was having is > due to a bug in tcsh--From tcsh, even though the filesize limit is set > to "unlimited" I cannot create a file > 2 GB. I was able to reproduce > this problem by several different methods. From bash, I can create > files > 2 GB with no problems. > > > So the size issue is something else - either a system problem on > > your end - do you have user limits set to other than the > > default? > > -- > "Jonathan F. Dill" (dill@umbi.umd.edu) You know, I seem to remember this from a long time back, tcsh is not built as an LSF aware binary, you need O_LARGEFILE on open now to be allowed to access beyond the 2Tbyte limit. I did at one point get a tcsh source rpm, add the correct glibc -D option and rebuild, it all started working at this point. Thanks, Steve From owner-linux-xfs@oss.sgi.com Thu Oct 25 14:14:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PLEKH03228 for linux-xfs-outgoing; Thu, 25 Oct 2001 14:14:20 -0700 Received: from rover (rover.mkp.net [209.217.122.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PLEHD03206 for ; Thu, 25 Oct 2001 14:14:17 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=jaguar.mkp.net) by rover with esmtp (Exim 3.33 #1) id 15wrp3-0008Qh-00; Thu, 25 Oct 2001 17:13:54 -0400 Received: (from mkp@localhost) by jaguar.mkp.net (8.11.2/8.9.3) id f9PLDo914447; Thu, 25 Oct 2001 17:13:50 -0400 X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f To: Jonathan Dill Cc: Steve Lord , Marc Schmitt , Eric Sandeen , linux-xfs@oss.sgi.com, florin@sgi.com Subject: Re: Corruption of in-memory data detected. References: <200110241510.f9OFAR707303@jen.americas.sgi.com> <3BD87EC3.4A1E938B@umbi.umd.edu> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 25 Oct 2001 17:13:48 -0400 In-Reply-To: <3BD87EC3.4A1E938B@umbi.umd.edu> Message-ID: Lines: 18 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>>>> "Jonathan" == Jonathan Dill writes: Jonathan> FWIW, I discovered that the Filesize limit problem that I Jonathan> was having is due to a bug in tcsh--From tcsh, even though Jonathan> the filesize limit is set to "unlimited" I cannot create a Jonathan> file > 2 GB. I was able to reproduce this problem by Jonathan> several different methods. From bash, I can create files > Jonathan> 2 GB with no problems. Ayup. We've seen this a few times. tcsh is incorrectly compiled (no largefile flags). Perhaps we should add this to the FAQ? -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Thu Oct 25 14:35:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PLZ4R03752 for linux-xfs-outgoing; Thu, 25 Oct 2001 14:35:04 -0700 Received: from umbi3.umbi.umd.edu (umbi3.umbi.umd.edu [136.160.7.51]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PLZ1D03730 for ; Thu, 25 Oct 2001 14:35:01 -0700 Received: from umbi.umd.edu (mystery.carb.nist.gov [129.6.113.182]) by umbi3.umbi.umd.edu (Netscape Messaging Server 4.15) with ESMTP id GLS6MD00.KMW; Thu, 25 Oct 2001 17:35:01 -0400 Message-ID: <3BD8857F.C2106C99@umbi.umd.edu> Date: Thu, 25 Oct 2001 17:34:55 -0400 From: Jonathan Dill Organization: CARB X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-6SGI_XFS_PR3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: Marc Schmitt , Eric Sandeen , linux-xfs@oss.sgi.com, florin@sgi.com Subject: Re: tcsh incorrectly compiled References: <200110252104.f9PL4xk19189@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: You know, I seem to remember this from a long time back, tcsh is not > built as an LSF aware binary, you need O_LARGEFILE on open now to be > allowed to access beyond the 2Tbyte limit. I did at one point get > a tcsh source rpm, add the correct glibc -D option and rebuild, it > all started working at this point. OK so exactly what flags do I need to compile it correctly? I presume that I can make the changes to the spec file or Makefile and it should work. I want to check the src.rpm from RH 7.2 and see if that one is corrected. -- "Jonathan F. Dill" (dill@umbi.umd.edu) From owner-linux-xfs@oss.sgi.com Thu Oct 25 14:38:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PLcRd03916 for linux-xfs-outgoing; Thu, 25 Oct 2001 14:38:27 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PLcOD03893 for ; Thu, 25 Oct 2001 14:38:25 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA02117 for ; Thu, 25 Oct 2001 14:38:16 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA3404451 for ; Thu, 25 Oct 2001 16:36:52 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA92177 for ; Thu, 25 Oct 2001 16:36:51 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id f9PLWxi01282; Thu, 25 Oct 2001 16:32:59 -0500 Message-Id: <200110252132.f9PLWxi01282@jen.americas.sgi.com> Date: Thu, 25 Oct 2001 16:32:59 -0500 Subject: TAKE - fix something I broke in the merge Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I was a bit ambitious with some of the code - and found a box which no longer booted. Backing out some blocksize changes I made and going back to the original 512 byte blocksize code. Date: Thu Oct 25 14:35:51 PDT 2001 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:105469a linux/fs/xfs/linux/xfs_super.c - 1.144 - Back out a bit of the code - I found a box which did not like it. From owner-linux-xfs@oss.sgi.com Thu Oct 25 15:24:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PMOSw06960 for linux-xfs-outgoing; Thu, 25 Oct 2001 15:24:28 -0700 Received: from trillium-hollow.org (IDENT:root@trillium-hollow.org [209.180.166.89]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PMON006938 for ; Thu, 25 Oct 2001 15:24:23 -0700 Received: from erich (helo=trillium) by trillium-hollow.org with local-esmtp (Exim 3.20 #1) id 15wsv1-00011L-00; Thu, 25 Oct 2001 15:24:07 -0700 To: Steve Lord cc: linux-xfs@oss.sgi.com, Stuart Luppescu Subject: Re: GRUB in RedHat 7.2 xfs In-Reply-To: Your message of "Thu, 25 Oct 2001 12:39:22 CDT." <200110251739.f9PHdNI02151@jen.americas.sgi.com> Date: Thu, 25 Oct 2001 15:24:07 -0700 From: erich@uruk.org Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: > I have looked briefly at the code - and built a redhat based rpm > with the patch in there. It does not do log replay, but that is a > really complex task which nothing except the kernel does right now. Right, and arguably not necessary in a bootloader. The only time it is really worrisome is for installation of a block-list, and the log is arguably clean at that point. I'd still like to try out your hacked RedHat 7.2 installer at some point with the default setting of making GRUB the bootloader and this one being the one it installs, to test it out. > My only other concern with the code from a quick read was what would > happen in a really large directory, or in a really small one which > fit inside the inode. The number of filesystem combinations which > xfs could generate is large, and I am not sure all the directory > options are covered. I could be wrong, I spent all of 15 minutes > on the code. Well, upon some more inspection, the "first_dentry" and "next_dentry" functions in the directory traversal code have 2 separate cases for "XFS_DINOTE_FMT_LOCAL" (clearly the inside inode format) and then "XFS_DINODE_FMT_BTREE" or "XFS_DINODE_FMT_EXTENTS". The second case has some other checks and variation inside it for stuff like "XFS_DIR2_BLOCK_MAGIC" and "XFS_DIR2_LEAFN_MAGIC"... I'm starting to describe the code here ;-) There is also some code to check to see if you've run off the end of your directory size (it's called "xfs.dirmax"), and if so, it tries to go to a next directory structure (it calls it a "dablk") and recalculates everything at that point. So, it seems to handle many of the cases I've heard about on the list: contained in inode, btree, something like extents of btrees. Is there anything I should look for? I admittedly don't have a huge XFS partition, but after sniffing around some directories with lots (several thousand) files, all seems well so far. -- Erich Stefan Boleyn http://www.uruk.org/ "Reality is truly stranger than fiction; Probably why fiction is so popular" From owner-linux-xfs@oss.sgi.com Thu Oct 25 16:09:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PN92u07963 for linux-xfs-outgoing; Thu, 25 Oct 2001 16:09:02 -0700 Received: from hob.slb.nwc.acsalaska.net (hob.slb.nwc.acsalaska.net [209.112.155.42]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PN8u007941 for ; Thu, 25 Oct 2001 16:08:57 -0700 Received: from erbenson.alaska.net (137-pm3.nwc.alaska.net [209.112.138.137]) by hob.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id f9PN8pD06754 for ; Thu, 25 Oct 2001 15:08:51 -0800 (AKDT) (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 4F2A43990 for ; Thu, 25 Oct 2001 15:08:50 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id EDBFF10262; Thu, 25 Oct 2001 15:08:49 -0800 (AKDT) Date: Thu, 25 Oct 2001 15:08:49 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: GRUB in RedHat 7.2 xfs Message-ID: <20011025150849.D18788@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200110251436.f9PEa1F09054@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8w3uRX/HFJGApMzv" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from erich@uruk.org on Thu, Oct 25, 2001 at 09:44:25AM -0700 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --8w3uRX/HFJGApMzv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 25, 2001 at 09:44:25AM -0700, erich@uruk.org wrote: >=20 > It appears to work fine, though I haven't sniffed through the source in > detail to see if it does stuff like replay the logs... but that's > probably ok since when you use it in general it's read-only (only writes > if you run the install command), so I initially tested it running off of > a floppy. grub XFS filesystem code never writes to the device, its completly readonly (as it should be). as a result of couse any files which will only be visable/usable after a log recovery are not accessable by grub (note my only testing is from yaboot, but the core XFS code is not changed much). --=20 Ethan Benson http://www.alaska.net/~erbenson/ --8w3uRX/HFJGApMzv 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 iEYEARECAAYFAjvYm4EACgkQJKx7GixEevymXwCfWdRITQHBKZPmbyKhM+RVkR8A YvwAoJadInBthGu/oREb5C6Fs0Knovq0 =VYHE -----END PGP SIGNATURE----- --8w3uRX/HFJGApMzv-- From owner-linux-xfs@oss.sgi.com Thu Oct 25 16:43:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PNhdj09074 for linux-xfs-outgoing; Thu, 25 Oct 2001 16:43:39 -0700 Received: from trillium-hollow.org (IDENT:root@trillium-hollow.org [209.180.166.89]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PNhZ009052 for ; Thu, 25 Oct 2001 16:43:35 -0700 Received: from erich (helo=trillium) by trillium-hollow.org with local-esmtp (Exim 3.20 #1) id 15wu7D-00018x-00; Thu, 25 Oct 2001 16:40:47 -0700 To: Ethan Benson cc: linux-xfs@oss.sgi.com Subject: Re: GRUB in RedHat 7.2 xfs In-Reply-To: Your message of "Thu, 25 Oct 2001 15:08:49 -0800." <20011025150849.D18788@plato.local.lan> Date: Thu, 25 Oct 2001 16:40:47 -0700 From: erich@uruk.org Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ethan Benson wrote: > On Thu, Oct 25, 2001 at 09:44:25AM -0700, erich@uruk.org wrote: > > > It appears to work fine, though I haven't sniffed through the source in > > detail to see if it does stuff like replay the logs... but that's > > probably ok since when you use it in general it's read-only (only writes > > if you run the install command), so I initially tested it running off of > > a floppy. BTW, I looked a bit more and it's clear it doesn't replay the log. > grub XFS filesystem code never writes to the device, its completly > readonly (as it should be). Being the original author of GRUB (the core is still the same), I can say with some certainty that GRUB *can* write to a device if it's told to, i.e. all require explicit functions (some partition-table mangling, some requested boot parameter memory between sessions, and a special function called "install" which can build-in blocklists and other information). None of the filesystem code writes directly, but a few of those special functions use the filesystem code to find the first block of a file to change some parameters in it. -- Erich Stefan Boleyn http://www.uruk.org/ "Reality is truly stranger than fiction; Probably why fiction is so popular" From owner-linux-xfs@oss.sgi.com Thu Oct 25 17:30:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9Q0UgD10185 for linux-xfs-outgoing; Thu, 25 Oct 2001 17:30:42 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9Q0UV010162 for ; Thu, 25 Oct 2001 17:30:31 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id CAA272567 for ; Fri, 26 Oct 2001 02:30:22 +0200 (CEST) mail_from (nathans@wobbly.melbourne.sgi.com) 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 KAA10883; Fri, 26 Oct 2001 10:28:55 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA66630; Fri, 26 Oct 2001 11:28:54 +1100 (AEDT) Date: Fri, 26 Oct 2001 11:28:54 +1100 From: Nathan Scott To: Jonathan Dill Cc: linux-xfs@oss.sgi.com Subject: Re: tcsh incorrectly compiled Message-ID: <20011026112854.E557513@wobbly.melbourne.sgi.com> References: <200110252104.f9PL4xk19189@jen.americas.sgi.com> <3BD8857F.C2106C99@umbi.umd.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BD8857F.C2106C99@umbi.umd.edu>; from dill@umbi.umd.edu on Thu, Oct 25, 2001 at 05:34:55PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Thu, Oct 25, 2001 at 05:34:55PM -0400, Jonathan Dill wrote: > Steve Lord wrote: > You know, I seem to remember this from a long time back, tcsh is not > > built as an LSF aware binary, you need O_LARGEFILE on open now to be > > allowed to access beyond the 2Tbyte limit. I did at one point get > > a tcsh source rpm, add the correct glibc -D option and rebuild, it > > all started working at this point. > > OK so exactly what flags do I need to compile it correctly? I presume > that I can make the changes to the spec file or Makefile and it should > work. I want to check the src.rpm from RH 7.2 and see if that one is > corrected. Use these: "-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64". It is the 2nd part that gives you O_LARGEFILE on open, but GNU_SOURCE is a handy catch-all for several other useful things. Refer to the comment near the top of /usr/include/features.h which describes each flag. Here's a quick-fire way to test this... # strace /usr/bin/tcsh -c 'echo > /tmp/blop' |& grep 'open("/tmp/blop"' open("/tmp/blop", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3 And compiled with the above flags... # strace ./tcsh -c 'echo > /tmp/blop' |& grep 'open("/tmp/blop"' open("/tmp/blop", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3 Below is a patch for any Debian tcsh users out there - I'll submit a bug in a minute. cheers. -- Nathan --- tcsh-6.10/debian/rules Fri Oct 26 10:04:12 2001 +++ tcsh-6.10-ns/debian/rules Fri Oct 26 09:59:18 2001 @@ -13,7 +13,7 @@ # C compiler information CC = gcc -CFLAGS = -g -Wall -O2 -fomit-frame-pointer +CFLAGS = -g -Wall -O2 -fomit-frame-pointer -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 LDFLAGS = -s #export DH_VERBOSE=1 From owner-linux-xfs@oss.sgi.com Thu Oct 25 17:32:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9Q0Wfo10267 for linux-xfs-outgoing; Thu, 25 Oct 2001 17:32:41 -0700 Received: from ns.toheart.to (toheart.to [210.143.97.15]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9Q0WY010244 for ; Thu, 25 Oct 2001 17:32:35 -0700 Received: from mfiw.net (todd.jbic.com [205.133.156.45]) by ns.toheart.to (8.11.0/3.6Wbeta7) with SMTP id f9Q0jod23868; Fri, 26 Oct 2001 09:45:50 +0900 Date: Fri, 26 Oct 2001 09:45:50 +0900 Message-Id: <200110260045.f9Q0jod23868@ns.toheart.to> From: To: Subject: Unlimited Long Distance $0.00 Per Min MIME-Version: 1.0 Content-Type: multipart/mixed;boundary= "----=_NextPart_000_00EB_1691B0E1.5E621026" 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 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk ------=_NextPart_000_00EB_1691B0E1.5E621026 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjwhLS0gc2F2ZWQgZnJvbSB1cmw9KDAwMjIpaHR0cDovL2ludGVybmV0LmUt bWFpbCAtLT48SFRNTD48SEVBRD48VElUTEU+RmxhdCBSYXRlIExvbmcgRGlzdGFuY2U8L1RJ VExFPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVudD0idGV4dC9odG1s OyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1MIDUuNTAuNDIw Ny4yNjAxIiBuYW1lPUdFTkVSQVRPUj48L0hFQUQ+DQo8Qk9EWSB0ZXh0PSNmZmZmZmYgYmdD b2xvcj0jMDAwMDAwPg0KPFRBQkxFIGNlbGxTcGFjaW5nPTAgY2VsbFBhZGRpbmc9MCB3aWR0 aD01MDAgYWxpZ249bGVmdCBiZ0NvbG9yPSNmZmZmZmYgDQpib3JkZXI9MD4NCiAgPFRCT0RZ Pg0KICA8VFIgYmdDb2xvcj0jZmZmZjgwPg0KICAgIDxURCB3aWR0aD01MDEgaGVpZ2h0PTEy Mz4NCiAgICAgIDxESVYgYWxpZ249Y2VudGVyPjxGT05UIGZhY2U9IkFyaWFsLCBIZWx2ZXRp Y2EsIHNhbnMtc2VyaWYiIGNvbG9yPSMwMDAwMDAgDQogICAgICBzaXplPTM+PEI+PEZPTlQg c2l6ZT01PlVubGltaXRlZCBMb25nIERpc3RhbmNlPEJSPjwvRk9OVD48Rk9OVCANCiAgICAg IHNpemU9ND4kMzkuOTUgcGVyIG1vbnRoPC9GT05UPjxGT05UIHNpemU9NT48QlI+PC9GT05U PjwvQj48Rk9OVCANCiAgICAgIGNvbG9yPSNmZjAwMDA+PEI+PEZPTlQgc2l6ZT01PjxGT05U IHNpemU9Mz5PTkUgRkVFLCBPTkNFIEEgTU9OVEg8QlI+Tk8gDQogICAgICBNT1JFIE9VVFJB R0VPVVMgUEhPTkUgQklMTFM8L0ZPTlQ+PC9GT05UPjwvQj48L0ZPTlQ+PC9GT05UPjxCUj48 Rk9OVCANCiAgICAgIGNvbG9yPSMwMDAwMDA+PEI+PEJSPjxGT05UIGZhY2U9QXJpYWw+SXQn cyB5b3VyIE1vbmV5IFlvdSANCiAgICAgIENob29zZSE8L0ZPTlQ+PC9CPjwvRk9OVD48L0RJ Vj48L1REPjwvVFI+DQogIDxUUj4NCiAgICA8VEQgaGVpZ2h0PTIyPg0KICAgICAgPERJViBz dHlsZT0iTEVGVDogMTBweDsgVE9QOiAxMzlweCIgYWxpZ249Y2VudGVyPjxGT05UIA0KICAg ICAgZmFjZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiIgY29sb3I9IzAwMDA5OT48 QlI+UmVzaWRlbnRpYWwgYW5kIA0KICAgICAgQnVzaW5lc3MgRmxhdCBSYXRlIExvbmcgRGlz dGFuY2UgLTxCPiA8Rk9OVCBjb2xvcj0jOTkwMDAwPk9ORSBNT05USExZIA0KICAgICAgRkVF PC9GT05UPjwvQj48Qj4gPC9CPnN0YXJ0aW5nIGF0PEI+IDxGT05UIA0KICAgICAgY29sb3I9 Izk5MDAwMD4kMzkuOTU8L0ZPTlQ+PC9CPjwvRk9OVD4gPEJSPg0KICAgICAgPFA+PEZPTlQg ZmFjZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiIgY29sb3I9IzAwMDAwMCBzaXpl PTI+PEI+SWYgDQogICAgICB3b3VsZCBsaWtlIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBm aWxsIG91dCB0aGUgZm9sbG93aW5nIGZvcm0gYW5kIGEgDQogICAgICByZXByZXNlbnRhdGl2 ZSB3aWxsIHRlbGwgeW91IGFsbCBhYm91dCBpdC48L0I+PC9GT05UPjwvUD4NCiAgICAgIDxQ PjxGT05UIGZhY2U9IkFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiIGNvbG9yPSMwMDAw MDAgc2l6ZT0yPjxCPk5vIA0KICAgICAgaGFzc2xlcy4gTm8gaGFyZCBzZWxsIHRhY3RpY3Mu IEp1c3QgdGhlIA0KICAgIGZhY3RzITwvQj48L0ZPTlQ+PEJSPjxCUj48L1A+PC9ESVY+PC9U RD48L1RSPg0KICA8VFI+DQogICAgPFREPg0KICAgICAgPERJViBhbGlnbj1jZW50ZXI+PEI+ PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGNjIHNpemU9ND5DYWxsIFRvbGwgRnJlZSAN CiAgICAgIDEtODc3LTU2My0zMjI2IDwvRk9OVD48L0I+PEJSPjwvRElWPjxGT05UIGZhY2U9 QXJpYWwgY29sb3I9IzAwMDAwMD48QlI+WW91IA0KICAgICAgd2lsbCBzYXZlIGh1bmRyZWRz IG9yIGV2ZW4gdGhvdXNhbmRzIG9mIGRvbGxhcnMgZWFjaCB5ZWFyISBIb21lIGFuZCBzbWFs bCANCiAgICAgIGJ1c2luZXNzIHBsYW5zIGFyZSBoZXJlITwvRk9OVD48QlI+PEJSPjxGT05U IGZhY2U9QXJpYWwgY29sb3I9I2ZmMDAwMD5IYXZlIA0KICAgICAgYSBjb21wYW55IHdpdGgg YSBsYXJnZSBwaG9uZSBiaWxsPyBJZiB0aGUgYW5zd2VyIGlzIHllcywgd2UgYXNrIA0KICAg ICAgV2h5PzwvRk9OVD4gPC9URD48L1RSPg0KICA8VFI+DQogICAgPFREIHdpZHRoPTUwMCBo ZWlnaHQ9ODg+DQogICAgICA8RElWIGFsaWduPWNlbnRlcj4NCiAgICAgIDxQPjxGT05UIGNv bG9yPSMwMDAwMDA+PC9GT05UPiZuYnNwOzwvUD4NCiAgICAgIDxQPjxGT05UIGZhY2U9IkFy aWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiIGNvbG9yPSMwMDAwMDAgc2l6ZT0yPklmIHlv dSANCiAgICAgIHdvdWxkIGxpa2UgdG8gYmUgcmVtb3ZlZCBmcm9tIG91ciBsaXN0LCBwbGVh c2Ugc2VuZCBhbiBlbWFpbCB0byA8QSANCiAgICAgIGhyZWY9Im1haWx0bzpqYXlqYXlqdXNA eWFob28uY29tP1N1YmplY3Q9cmVtb3ZlIj5tYWlsdG86amF5amF5anVzQHlhaG9vLmNvbT9T dWJqZWN0PXJlbW92ZTwvQT4gDQogICAgICA8L0ZPTlQ+PC9QPjwvRElWPjwvVEQ+PC9UUj48 L1RCT0RZPjwvVEFCTEU+PC9CT0RZPjwvSFRNTD4NCiAgICA= ------=_NextPart_000_00EB_1691B0E1.5E621026-- From owner-linux-xfs@oss.sgi.com Thu Oct 25 21:58:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9Q4w1A30782 for linux-xfs-outgoing; Thu, 25 Oct 2001 21:58:01 -0700 Received: from home.smithconcepts.com (65.34.25.157.oviedo-ubr-a.cfl.rr.com [65.34.25.157]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9Q4vv030760 for ; Thu, 25 Oct 2001 21:57:58 -0700 Received: from ieee.org (IDENT:rEXXbgjA54ZdF4iVgNGhu+4uRcq/Ku05@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id AAA09950; Fri, 26 Oct 2001 00:51:21 -0400 Message-ID: <3BD8EDCC.A927D410@ieee.org> Date: Fri, 26 Oct 2001 00:59:56 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts, Inc. X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-6SGI_XFS_PR3smp i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Athlon binaries for 2.4.9-7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Just curious to know if you'all are building any? ftp://oss.sgi.com/projects/xfs/download/testing/RH2.4.9-7/ -- TheBS P.S. Yes, I'm building my own right now with "rpm --rebuild --target athlon". 'Dual P3 go, Single P4 stop, Dual Athlon go ... very fast.' -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ------------------------------------------------------------------ Those living in the US who consider the American flag to be a sym- bol of oppression obviously fail to understand what the word means From owner-linux-xfs@oss.sgi.com Thu Oct 25 23:57:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9Q6vbr12050 for linux-xfs-outgoing; Thu, 25 Oct 2001 23:57:37 -0700 Received: from pooh.lsc.hu (IDENT:qmailr@lsc.net23.hu [195.56.172.131]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9Q6vV012028 for ; Thu, 25 Oct 2001 23:57:31 -0700 Received: (qmail 13174 invoked by uid 547); 26 Oct 2001 07:10:20 -0000 Date: Fri, 26 Oct 2001 09:10:20 +0200 From: GCS To: linux-xfs@oss.sgi.com Subject: Bug with 2.4.13? Message-ID: <20011026091020.B13113@lsc.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! I am using XFS with kernel 2.4.13. Yesterday I realised that I can not save anything to my /home, which is on XFS. Even touch /home/test as root said input/output error. umount went ok, and as I know fsck.xfs does nothing, I tried to mount it again. I got a lot of strange messages, like bad/invalid (?) version 0x7345435... After reboot the mount crashes, and if I try it again, then it stucks in a D state. My distribution is Debian Woody. Here is a short report of the crash: Null pointer dereference at virtual address 0000152 Eip: c01a30c7 (it points to pagebuf_unlock) Oops: 000 Call trace: xlog_recover_process_iunlinks+328/644 xlog_recover_finish+53/144 xfs_log_mount_finish+31/48 xfs_mountfs+3070/3316 xfs_readsb+216/240 Code: 66 83 bb 6a 01 00 00 00 75 10 80 a3 50 01 00 00 f7 53 e8 7a What should I do? Any help is appreciated. GCS From owner-linux-xfs@oss.sgi.com Fri Oct 26 00:12:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9Q7CpO12546 for linux-xfs-outgoing; Fri, 26 Oct 2001 00:12:51 -0700 Received: from dfmail.f-secure.com (dfmail.f-secure.com [194.252.6.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9Q7Ci012522 for ; Fri, 26 Oct 2001 00:12:44 -0700 Received: (qmail 6168 invoked by uid 0); 26 Oct 2001 07:12:42 -0000 Received: from fsav4im2.f-secure.com (HELO fsav4im2) (194.197.29.47) by dfmail.f-secure.com with SMTP; 26 Oct 2001 07:12:42 -0000 Received: from [194.197.29.8]:47014 (HELO dfintra.f-secure.com) by fsav4im2 ([194.197.29.47]:25) (F-Secure Anti-Virus for Internet Mail 6.0.27 Release) with SMTP; Fri, 26 Oct 2001 07:12:21 -0000 Received: (qmail 21671 invoked from network); 26 Oct 2001 07:12:39 -0000 Received: from unknown (HELO fsfimail1.fi.f-secure.com) (10.128.128.19) by dfintra.f-secure.com with SMTP; 26 Oct 2001 07:12:39 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Bug with 2.4.13? Date: Fri, 26 Oct 2001 10:12:37 +0300 Message-ID: <30B026EA81B98D4082E2FD73B14CB8123B736F@fsfimail1.FI.F-Secure.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Bug with 2.4.13? Thread-Index: AcFd7Zj9naRT8fU8Rqe8R2AkkD4DMw== From: To: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f9Q7Cj012523 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hmm, I got that "Input/Output" error once (2.4.13-pre2) while tring to remove one tree with many subdis and files. Nothing on the XFS partition was "accessible" after that. But luckily I immediatelly rebooted and everything went fine. Didn't reported that problem because the kernel was compiled with gcc3 :) Cheers, Hristo. >-----Original Message----- >From: owner-linux-xfs@oss.sgi.com >[mailto:owner-linux-xfs@oss.sgi.com]On >Behalf Of GCS >Sent: Friday, October 26, 2001 10:10 AM >To: linux-xfs@oss.sgi.com >Subject: Bug with 2.4.13? > > >Hi! > > I am using XFS with kernel 2.4.13. Yesterday I realised that >I can not save >anything to my /home, which is on XFS. Even touch /home/test >as root said >input/output error. umount went ok, and as I know fsck.xfs >does nothing, >I tried to mount it again. I got a lot of strange messages, >like bad/invalid >(?) version 0x7345435... > After reboot the mount crashes, and if I try it again, then >it stucks in >a D state. My distribution is Debian Woody. Here is a short >report of the >crash: >Null pointer dereference at virtual address 0000152 >Eip: c01a30c7 (it points to pagebuf_unlock) >Oops: 000 >Call trace: xlog_recover_process_iunlinks+328/644 > xlog_recover_finish+53/144 > xfs_log_mount_finish+31/48 > xfs_mountfs+3070/3316 > xfs_readsb+216/240 > >Code: 66 83 bb 6a 01 00 00 00 75 10 80 a3 50 01 00 00 f7 53 e8 7a > >What should I do? Any help is appreciated. >GCS > From owner-linux-xfs@oss.sgi.com Fri Oct 26 00:33:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9Q7X1d13087 for linux-xfs-outgoing; Fri, 26 Oct 2001 00:33:01 -0700 Received: from pooh.lsc.hu (IDENT:qmailr@lsc.net23.hu [195.56.172.131]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9Q7Ww013065 for ; Fri, 26 Oct 2001 00:32:58 -0700 Received: (qmail 13270 invoked by uid 547); 26 Oct 2001 07:45:47 -0000 Date: Fri, 26 Oct 2001 09:45:47 +0200 From: GCS To: linux-xfs@oss.sgi.com Subject: Re: Bug with 2.4.13? Message-ID: <20011026094547.E13113@lsc.hu> References: <30B026EA81B98D4082E2FD73B14CB8123B736F@fsfimail1.FI.F-Secure.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <30B026EA81B98D4082E2FD73B14CB8123B736F@fsfimail1.FI.F-Secure.com>; from Hristo.Grigorov@F-Secure.com on Fri, Oct 26, 2001 at 10:12:37AM +0300 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Oct 26, 2001 at 10:12:37AM +0300, Hristo.Grigorov@F-Secure.com wrote: > Hmm, I got that "Input/Output" error once (2.4.13-pre2) while > tring to remove one tree with many subdis and files. Nothing > on the XFS partition was "accessible" after that. I did not do anything like that. I only used my sytem. > But luckily I immediatelly rebooted and everything went fine. > Didn't reported that problem because the kernel was compiled with > gcc3 :) After reboot, the things are went from bad to worst. :-( Kernel is the stable 2.4.13, and I do not even have gcc3. I have everything backed up ofcurse, but I would like to fix the partition somehow and not mkfs, and cp back everything. Thus if anyone would like to get more information, ask for tests, I would be happy to help. Thanks, GCS From owner-linux-xfs@oss.sgi.com Fri Oct 26 00:50:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9Q7o4T13713 for linux-xfs-outgoing; Fri, 26 Oct 2001 00:50:04 -0700 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9Q7o0013686 for ; Fri, 26 Oct 2001 00:50:00 -0700 Received: from inf.ethz.ch (IDENT:schmitt@ikarus.inf.ethz.ch [129.132.10.58]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id JAA21261; Fri, 26 Oct 2001 09:49:52 +0200 (MET DST) Message-ID: <3BD915A2.20703@inf.ethz.ch> Date: Fri, 26 Oct 2001 09:49:54 +0200 From: Marc Schmitt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Steve Lord CC: Eric Sandeen , linux-xfs@oss.sgi.com, florin@sgi.com Subject: Re: Corruption of in-memory data detected. References: <200110251824.f9PIOqE08390@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi all, Using the new mkfs.xfs, mongo runs smooth now. Thanks! :) Greetz Marc Steve Lord wrote: > Just in case I did not make it obvious, we think the fix for this is a > new mkfs. The old one was generating inconsistent superblocks for > filesystems above 1 Tbyte. The only folks affected by this probably > had filesystems which would take down the machine if you used them > anyway. So if your filesystem is working for you using the old mkfs > then there is no need to do anything except upgrade the commands. > > If you made a filesystem of greater than 1 Tbyte using > > mkfs -t xfs -i size=512 ..... > > then you should also not be affected. > > Steve From owner-linux-xfs@oss.sgi.com Fri Oct 26 04:13:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QBDfK25368 for linux-xfs-outgoing; Fri, 26 Oct 2001 04:13:41 -0700 Received: from cycos.com (mrs.backbone.cycos.com [194.77.158.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QBDb025346 for ; Fri, 26 Oct 2001 04:13:37 -0700 Date: Fri, 26 Oct 2001 13:13:34 +0200 From: "Eitzenberger, Holger" To: "linux-xfs@oss.sgi.com" NvsRef: PPCOM/2476524 Message-Id: <0025c9ec@cycos.com> Subject: XFS crash, reproducible X-Mailer: MRS Internet Mail APL Version 4.00.98 (WIN-NT) Release Build 2524 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f9QBDc025347 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Kernel: 2.4.10-xfs acl: 1.0.7 attr: 1.0.3 xfsdump: 1.0.9 i found a reproducible bug in acl_set(2) which oopses my system. Works from every local account. Don't know, if it's wise to publish it. Who is the person to give this information to? /Holger -- ++ Debian GNU/Linux ++ ICQ# 2882018 ++ +++ GnuPG PubKey http://www.t-online.de/~holger.eitzenberger +++ From owner-linux-xfs@oss.sgi.com Fri Oct 26 04:45:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QBjJZ26752 for linux-xfs-outgoing; Fri, 26 Oct 2001 04:45:19 -0700 Received: from mail.spylog.com (mail.spylog.com [194.67.35.220]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QBjD026728 for ; Fri, 26 Oct 2001 04:45:13 -0700 Received: from an.local (an.local [192.168.4.50]) by mail.spylog.com (Postfix) with ESMTP id E3F822D105 for ; Fri, 26 Oct 2001 15:45:06 +0400 (MSD) Received: by an.local (Postfix, from userid 1000) id 5031314429; Fri, 26 Oct 2001 15:45:06 +0400 (MSD) Date: Fri, 26 Oct 2001 15:45:06 +0400 From: Andrey Nekrasov To: "linux-xfs@oss.sgi.com" Subject: xfsdump not compile. Message-ID: <20011026154505.A30360@spylog.ru> Mail-Followup-To: "linux-xfs@oss.sgi.com" Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.3.23i Organization: SpyLOG ltd. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello. 1. xfs-kernel from cvs today. 2. debian unstable upgrade today. 3. an:/usr/src/linux-2.4-xfs/cmd/xfsdump# debian/rules binary ... gcc -O1 -g -DNDEBUG -funsigned-char -Wall -DDUMP -DRMT -DBASED -DDOSOCKS -DINVCONVFIX -DSIZEEST -DPIPEINVFIX -DEXTATTR -DDMEXTATTR -I/usr/include/xfs -I/usr/include/attr '-DVERSION="1.1.7"' -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 -I/usr/include/xfs -I/usr/include/attr -c -o attr.o attr.c attr.c: In function `attr_multi_by_handle': attr.c:57: `attr_op_t' undeclared (first use in this function) attr.c:57: (Each undeclared identifier is reported only once attr.c:57: for each function it appears in.) attr.c:57: `ops' undeclared (first use in this function) attr.c:57: warning: statement with no effect attr.c:58: parse error before `int' attr.c:75: `i' undeclared (first use in this function) attr.c:83: `fsfd' undeclared (first use in this function) attr.c:88: `hreq' undeclared (first use in this function) attr.c:96: `attr_hreq' undeclared (first use in this function) attr.c: In function `attr_list_by_handle': attr.c:123: `attr_op_t' undeclared (first use in this function) attr.c:123: parse error before `op' attr.c:128: `op' undeclared (first use in this function) attr.c:129: `ATTR_OP_IRIX_LIST' undeclared (first use in this function) make[2]: *** [attr.o] ïÛÉÂËÁ 1 make[1]: *** [default] ïÛÉÂËÁ 2 make[1]: Leaving directory `/usr/src/linux-2.4-xfs/cmd/xfsdump' make: *** [built] ïÛÉÂËÁ 2 4. an:/usr/src/linux-2.4-xfs/cmd/xfsdump# dpkg -l |grep attr ii attr 2.0.0-0 Utilities for manipulating filesystem extend ii attr-dev 2.0.0-0 Extended attribute static libraries and head an:/usr/src/linux-2.4-xfs/cmd/xfsdump# -- bye. Andrey Nekrasov, SpyLOG. From owner-linux-xfs@oss.sgi.com Fri Oct 26 05:07:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QC7II27343 for linux-xfs-outgoing; Fri, 26 Oct 2001 05:07:18 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QC7F027321 for ; Fri, 26 Oct 2001 05:07:15 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9QC79K14681 for ; Fri, 26 Oct 2001 05:07:09 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id HAA3371851; Fri, 26 Oct 2001 07:05:53 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id HAA67563; Fri, 26 Oct 2001 07:05:53 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9QC1sA02076; Fri, 26 Oct 2001 07:01:54 -0500 Message-Id: <200110261201.f9QC1sA02076@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: GCS cc: linux-xfs@oss.sgi.com Subject: Re: Bug with 2.4.13? In-Reply-To: Message from GCS of "Fri, 26 Oct 2001 09:10:20 +0200." <20011026091020.B13113@lsc.hu> Date: Fri, 26 Oct 2001 07:01:54 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hmm, please make sure you got the last change I checked into the tree yesterday, do one more cvs update and see if you get a new xfs_super.c let me know what happens either way. Steve > Hi! > > I am using XFS with kernel 2.4.13. Yesterday I realised that I can not save > anything to my /home, which is on XFS. Even touch /home/test as root said > input/output error. umount went ok, and as I know fsck.xfs does nothing, > I tried to mount it again. I got a lot of strange messages, like bad/invalid > (?) version 0x7345435... > After reboot the mount crashes, and if I try it again, then it stucks in > a D state. My distribution is Debian Woody. Here is a short report of the > crash: > Null pointer dereference at virtual address 0000152 > Eip: c01a30c7 (it points to pagebuf_unlock) > Oops: 000 > Call trace: xlog_recover_process_iunlinks+328/644 > xlog_recover_finish+53/144 > xfs_log_mount_finish+31/48 > xfs_mountfs+3070/3316 > xfs_readsb+216/240 > > Code: 66 83 bb 6a 01 00 00 00 75 10 80 a3 50 01 00 00 f7 53 e8 7a > > What should I do? Any help is appreciated. > GCS From owner-linux-xfs@oss.sgi.com Fri Oct 26 05:18:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QCIt228346 for linux-xfs-outgoing; Fri, 26 Oct 2001 05:18:55 -0700 Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QCIq028323 for ; Fri, 26 Oct 2001 05:18:52 -0700 Received: (qmail 25757 invoked by uid 0); 26 Oct 2001 12:18:45 -0000 Received: from pd904e191.dip.t-dialin.net (HELO powstat) (217.4.225.145) by mail.gmx.net (mp011-rz3) with SMTP; 26 Oct 2001 12:18:45 -0000 From: "christian mueller" To: andy@spylog.ru Date: Fri, 26 Oct 2001 14:18:45 +0200 MIME-Version: 1.0 Subject: Re: xfsdump not compile. CC: linux-xfs@oss.sgi.com Message-ID: <3BD970C5.5928.1042CE0@localhost> X-mailer: Pegasus Mail for Win32 (v4.0, beta 40) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi andrey, > .. > an:/usr/src/linux-2.4-xfs/cmd/xfsdump# dpkg -l |grep attr > ii attr 2.0.0-0 Utilities for manipulating filesystem extend > ii attr-dev 2.0.0-0 Extended attribute static libraries and head > an:/usr/src/linux-2.4-xfs/cmd/xfsdump# >.. don't use the cmd/attr2 stuff. use cmd/attr ! File: [Development] / linux-2.4-xfs / cmd / attr2 / BIG.FAT.WARNING -chris From owner-linux-xfs@oss.sgi.com Fri Oct 26 05:48:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QCmlh29087 for linux-xfs-outgoing; Fri, 26 Oct 2001 05:48:47 -0700 Received: from cycos.com (mail.cycos.com [194.77.158.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QCmh029065 for ; Fri, 26 Oct 2001 05:48:43 -0700 Date: Fri, 26 Oct 2001 14:48:40 +0200 From: "Eitzenberger, Holger" To: "linux-xfs@oss.sgi.com" NvsRef: PPCOM/2476868 Message-Id: <0025cb44@cycos.com> Subject: Oops in acl_set(2) X-Mailer: MRS Internet Mail APL Version 4.00.98 (WIN-NT) Release Build 2524 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f9QCmi029066 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Kernel 2.4.10-XFS acl: 1.07 attr: 1.0.3 xfsdump: 1.0.9 xfsprogs 1.2.8 Hi, i found a serious bug in acl_set(2) which oopses my machine. The bug is reproducible. Any local account will do. I tracked the problem down to a bug in ./fs/xfs/xfs_acl.c:xfs_set_acl() and applied a patch locally which seems to fix the problem. Before releasing the mere facts of this bug i would like to have the problem fixed. If there is someone from SGI interested in the bug (and the patch resp.), please email me. Holger Eitzenberger Cycos AG Aachen, Germany -- ++ Debian GNU/Linux ++ ICQ# 2882018 ++ +++ GnuPG PubKey http://www.t-online.de/~holger.eitzenberger +++ From owner-linux-xfs@oss.sgi.com Fri Oct 26 05:58:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QCwIU03298 for linux-xfs-outgoing; Fri, 26 Oct 2001 05:58:18 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QCwD003274 for ; Fri, 26 Oct 2001 05:58:13 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id OAA15825; Fri, 26 Oct 2001 14:58:07 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id OAA10431; Fri, 26 Oct 2001 14:58:06 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 5F33857306; Fri, 26 Oct 2001 14:57:46 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id A73B425835; Fri, 26 Oct 2001 14:57:45 +0200 (CEST) Message-ID: <3BD95DC9.352D2B05@ch.sauter-bc.com> Date: Fri, 26 Oct 2001 14:57:45 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: For Testing - updated RH7.1 XFS 2.4.9-6 kernels References: <3BD57010.7C8EF680@sgi.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen schrieb: > > Due to popular demand, I have made available a test release of > XFS-capable versions of the Red Hat Linux 7.1 updates kernel v2.4.9-6. > > Available soon at: > ftp://oss.sgi.com/projects/xfs/download/testing/RH2.4.9-6 > > There are a couple known issues with undefined symbols in the > intermezzo.o and bcm5820.o modules; I'll get those sorted out on the > next release, but since this kernel is a security update, I wanted to > get it out there for testing. > > They have not yet been rigorously tested by SGI - but they do compile, > boot, and pass the xfs QA suite. :) > > Enjoy, I just wanted to give a positive feedback regarding 2.4.9-6SGI_XFS_PR3! It's the first 2.4 kernel I try which does not crash with my stress test. I'm very happy with it. -Simon > > -Eric > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Oct 26 06:02:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QD20E03565 for linux-xfs-outgoing; Fri, 26 Oct 2001 06:02:00 -0700 Received: from seralph5.essex.ac.uk (seralph5.essex.ac.uk [155.245.240.155]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QD1s003543 for ; Fri, 26 Oct 2001 06:01:54 -0700 Received: from sernt14.essex.ac.uk ([155.245.240.183]) by seralph5.essex.ac.uk with esmtp (Exim 3.13 #1) id 15x6cJ-0006i1-00 for linux-xfs@oss.sgi.com; Fri, 26 Oct 2001 14:01:43 +0100 Received: by sernt14.essex.ac.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Oct 2001 13:57:38 +0100 Message-ID: <7AC902A40BEDD411A3A800D0B7847B66088570@sernt14.essex.ac.uk> From: "Giddings, Bret" To: "'linux-xfs@oss.sgi.com'" Subject: RE: Problems with network kickstart install Date: Fri, 26 Oct 2001 13:57:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have finally discovered the cause of the problem outlined below. The default umask on the ftp server meant that the new rpms copied from the SGI CD were readable via ftp. For some reason, the failure to copy these files via ftp didn't show up anywhere on the machine being built. However, changing the perms to 444 on all files in the RPMS directory has fixed the problem. Regards, Bret -----Original Message----- From: Giddings, Bret Sent: 24 October 2001 13:11 To: linux-xfs@oss.sgi.com Subject: Problems with network kickstart install Hello, I am trying to get an XFS system installed by using a kickstart file on a floppy and an install location on an FTP server. This works fine with a vanilla RH7.1 distribution but fails when using the SGI provided ISO image. The install seems to proceed normally until it gets to the post-install phase at which point it prints the error message install exited abnormally - received signal 11 If I use essentially the same kickstart file but specify the installation mechanism as cdrom then everything is fine (bar having to swap CDs and watch the progress). If I boot into rescue mode from the XFS cd then no installation is found. However, mounting the partitions by hand from terminal 2 does work and curiously, the /boot partition doesn't have a kernel or other crucial files (although the other partitions are fine), so I am guessing that it is something here that is failing. Has anyone else come across this problem and solved it. Further details. In both cases, booting from CD using linux ks=floppy Kickstart file contains an FTP URL as the installation method. It also specifies the machines network settings. The stage1 and stage2 images are successfully loaded off the network and my custom 168 packages as specified in the kickstart file do get transferred. I built the FTP archive by a) taking a copy of my working 'standard' RH7.1 area (includes disk1 and disk2 RPMs). b) copied contents of XFS cd over the top of this area thus over-writing things like the .img files and the comps and hdlist files. Regards, Bret -- Bret Giddings, Systems Manager, Computing Service, University of Essex Tel: (01206) 872577 Email: bret@essex.ac.uk Fax: (01206) 860585 From owner-linux-xfs@oss.sgi.com Fri Oct 26 07:50:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QEodD16794 for linux-xfs-outgoing; Fri, 26 Oct 2001 07:50:39 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QEoa016770 for ; Fri, 26 Oct 2001 07:50:36 -0700 Received: from clink-eth.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9QEoUW12492 for ; Fri, 26 Oct 2001 07:50:30 -0700 Received: (from roehrich@localhost) by clink-eth.americas.sgi.com (SGI-8.9.3/8.9.3) id JAA16748 for linux-xfs@oss.sgi.com; Fri, 26 Oct 2001 09:49:12 -0500 (CDT) Date: Fri, 26 Oct 2001 09:49:12 -0500 (CDT) From: Dean Roehrich Message-Id: <200110261449.JAA16748@clink-eth.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - port dmapi mmap test to linux Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Fri Oct 26 07:49:00 PDT 2001 Workarea: clink-eth.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:105506a cmd/xfstests/dmapi/src/suite2/src/mmap.c - 1.2 - port to linux From owner-linux-xfs@oss.sgi.com Fri Oct 26 07:55:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QEtEl18097 for linux-xfs-outgoing; Fri, 26 Oct 2001 07:55:14 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QEtB018074 for ; Fri, 26 Oct 2001 07:55:11 -0700 Received: from clink-eth.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9QEt5W12660 for ; Fri, 26 Oct 2001 07:55:06 -0700 Received: (from roehrich@localhost) by clink-eth.americas.sgi.com (SGI-8.9.3/8.9.3) id JAA80076 for linux-xfs@oss.sgi.com; Fri, 26 Oct 2001 09:53:47 -0500 (CDT) Date: Fri, 26 Oct 2001 09:53:47 -0500 (CDT) From: Dean Roehrich Message-Id: <200110261453.JAA80076@clink-eth.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - change the entry for mmap-related dmapi events Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Fri Oct 26 07:53:27 PDT 2001 Workarea: clink-eth.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:105508a linux/fs/xfs/xfs_dmapi.h - 1.17 - -add prototype for xfs_dm_mapevent linux/fs/xfs/xfs_dmapi.c - 1.40 - -make xfs_dm_mapevent accessible to linvfs layer -remove xfs_dm_testevent--not necessary on linux at this point From owner-linux-xfs@oss.sgi.com Fri Oct 26 08:16:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QFGZZ20127 for linux-xfs-outgoing; Fri, 26 Oct 2001 08:16:35 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QFGV020105 for ; Fri, 26 Oct 2001 08:16:31 -0700 Received: from clink-eth.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9QFGNW13952 for ; Fri, 26 Oct 2001 08:16:23 -0700 Received: (from roehrich@localhost) by clink-eth.americas.sgi.com (SGI-8.9.3/8.9.3) id KAA08425 for linux-xfs@oss.sgi.com; Fri, 26 Oct 2001 10:15:05 -0500 (CDT) Date: Fri, 26 Oct 2001 10:15:05 -0500 (CDT) From: Dean Roehrich Message-Id: <200110261515.KAA08425@clink-eth.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - Allow mmap activities to be seen by DMAPI Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This makes the linux dmapi match the irix dmapi behavior. We ignore whether or not the user is reading or writing the pages, and instead just look at what they're _capable_ of doing to the file and generate a dmapi event based on that. This is a brain-dead way of doing things, but maybe slightly less brain-dead than what we have on irix, and it will hold things over until I can spend more time on doing it right. Date: Fri Oct 26 08:14:10 PDT 2001 Workarea: clink-eth.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:105510a linux/mm/mprotect.c - 1.17 - If protection is being changed from read to write, send a dmapi event. linux/include/linux/fs.h - 1.130 - Add dmapi_map_event method to struct file_operations. linux/fs/xfs/linux/xfs_file.c - 1.49 - -Add linvfs_dmapi_map_event(). Decides if mmap activity requires a read or write event to dmapi, sends the event. -Make linvfs_generic_file_mmap() call the above. From owner-linux-xfs@oss.sgi.com Fri Oct 26 08:33:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QFXCA20623 for linux-xfs-outgoing; Fri, 26 Oct 2001 08:33:12 -0700 Received: from rain.CC.Lehigh.EDU (rain.CC.Lehigh.EDU [128.180.39.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QFX8020599 for ; Fri, 26 Oct 2001 08:33:08 -0700 Received: from Lehigh.EDU (hooch.CC.Lehigh.EDU [128.180.3.11]) by rain.CC.Lehigh.EDU (8.12.1/8.12.0) with ESMTP id f9QFWYiI028001; Fri, 26 Oct 2001 11:32:50 -0400 Message-ID: <3BD97DD0.EF227683@Lehigh.EDU> Date: Fri, 26 Oct 2001 11:14:24 -0400 From: Jim Eshleman X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.4-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: error compiling 2.4.9-6SGI_XFS_PR3 source Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk HI! Following occurs during "make modules" (CONFIG_XFS_FS=m) with 2.4.9-6SGI_XFS_PR3: kgcc -D__KERNEL__ -I/usr/src/linux-2.4.9-6SGI_XFS_PR3/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -Wno-unused -fomit-frame-pointer -pipe -march=i686 -DMODULE -DMODVERSIONS -include /usr/src/linux-2.4.9-6SGI_XFS_PR3/include/linux/modversions.h -I /usr/src/linux-2.4.9-6SGI_XFS_PR3/fs -DEXPORT_SYMTAB -c qsort.c In file included from ../xfs.h:47, from xfs_griostubs.c:36: ../xfs_trans.h:947: parse error before `*' ../xfs_trans.h:947: warning: type defaults to `int' in declaration of `xfs_trans_start' ../xfs_trans.h:947: warning: data definition has no type or storage class ../xfs_trans.h:948: parse error before `*' ../xfs_trans.h:948: warning: function declaration isn't a prototype make[3]: *** [xfs_griostubs.o] Error 1 make[3]: Leaving directory `/usr/src/linux-2.4.9-6SGI_XFS_PR3/fs/xfs/linux' make[2]: *** [_modsubdir_linux] Error 2 make[2]: Leaving directory `/usr/src/linux-2.4.9-6SGI_XFS_PR3/fs/xfs' make[1]: *** [_modsubdir_xfs] Error 2 Jim From owner-linux-xfs@oss.sgi.com Fri Oct 26 08:35:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QFZTo20768 for linux-xfs-outgoing; Fri, 26 Oct 2001 08:35:29 -0700 Received: from imapserverb.fnal.gov (imapserverb.fnal.gov [131.225.9.17]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QFZP020746 for ; Fri, 26 Oct 2001 08:35:25 -0700 Received: from imapserverb.fnal.gov ([131.225.9.17]) by imapserverb.fnal.gov (Netscape Messaging Server 4.15) with SMTP id GLTKN000.H9T for ; Fri, 26 Oct 2001 10:35:24 -0500 Received: from fnal.gov ([131.225.7.82]) by imapserverb.fnal.gov (NAVIEG 2.1 bld 63) with SMTP id M2001102610352428665 for ; Fri, 26 Oct 2001 10:35:24 -0500 Message-ID: <3BD982BC.84DADE10@fnal.gov> Date: Fri, 26 Oct 2001 10:35:24 -0500 From: yocum@fnal.gov X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: xfs-list Subject: mmap.c:441: mmap_avl.c: No such file or directory Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Don't kill the messenger. :-) I updated from CVS this AM, which is supposed to be 2.4.13: kgcc -D__KERNEL__ -I/usr/src/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -march=i686 -malign-functions=4 -c -o mmap.o mmap.c mmap.c:441: mmap_avl.c: No such file or directory mmap.c: In function `do_munmap': mmap.c:752: warning: implicit declaration of function `avl_remove' mmap.c: In function `build_mmap_avl': mmap.c:907: warning: implicit declaration of function `avl_insert' mmap.c: In function `__insert_vm_struct': mmap.c:967: warning: implicit declaration of function `avl_insert_neighbours' make[2]: *** [mmap.o] Error 1 make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/mm' make[1]: *** [first_rule] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux/mm' make: *** [_dir_mm] Error 2 I don't know if this is a vestige of the main tree or the merge with XFS. Cheers, Dan -- Dan Yocum Sloan Digital Sky Survey, Fermilab 630.840.6509 yocum@fnal.gov, http://www.sdss.org SDSS. Mapping the Universe. From owner-linux-xfs@oss.sgi.com Fri Oct 26 08:51:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QFpBU21182 for linux-xfs-outgoing; Fri, 26 Oct 2001 08:51:11 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QFp5021160 for ; Fri, 26 Oct 2001 08:51:05 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA03101 for ; Fri, 26 Oct 2001 08:51:03 -0700 (PDT) mail_from (roehrich@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA3378590 for ; Fri, 26 Oct 2001 10:49:32 -0500 (CDT) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.187.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA66756 for ; Fri, 26 Oct 2001 10:49:31 -0500 (CDT) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id KAA68276; Fri, 26 Oct 2001 10:49:31 -0500 (CDT) Message-Id: <200110261549.KAA68276@slobber.americas.sgi.com> To: xfs-list Subject: Re: mmap.c:441: mmap_avl.c: No such file or directory Date: Fri, 26 Oct 2001 10:49:30 -0500 From: Dean Roehrich Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This looks like some old crud. That stuff was removed from mm/mmap.c back in mid-september as part of the merge up to 2.4.10-pre12. I think your CVS update didn't go quite as expected. Dean >From: yocum@fnal.gov >Don't kill the messenger. :-) > >I updated from CVS this AM, which is supposed to be 2.4.13: > > >kgcc -D__KERNEL__ -I/usr/src/linux-2.4-xfs/linux/include -Wall >-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common >-fomit-frame-pointer -pipe -march=i686 -malign-functions=4 -c -o mmap.o >mmap.c >mmap.c:441: mmap_avl.c: No such file or directory >mmap.c: In function `do_munmap': >mmap.c:752: warning: implicit declaration of function `avl_remove' >mmap.c: In function `build_mmap_avl': >mmap.c:907: warning: implicit declaration of function `avl_insert' >mmap.c: In function `__insert_vm_struct': >mmap.c:967: warning: implicit declaration of function >`avl_insert_neighbours' >make[2]: *** [mmap.o] Error 1 >make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/mm' >make[1]: *** [first_rule] Error 2 >make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux/mm' >make: *** [_dir_mm] Error 2 > > >I don't know if this is a vestige of the main tree or the merge with XFS. > >Cheers, >Dan > >-- >Dan Yocum >Sloan Digital Sky Survey, Fermilab 630.840.6509 >yocum@fnal.gov, http://www.sdss.org >SDSS. Mapping the Universe. > From owner-linux-xfs@oss.sgi.com Fri Oct 26 08:55:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QFtYi22487 for linux-xfs-outgoing; Fri, 26 Oct 2001 08:55:34 -0700 Received: from imapserverb.fnal.gov (imapserverb.fnal.gov [131.225.9.17]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QFtV022465 for ; Fri, 26 Oct 2001 08:55:31 -0700 Received: from imapserverb.fnal.gov ([131.225.9.17]) by imapserverb.fnal.gov (Netscape Messaging Server 4.15) with SMTP id GLTLKI00.TAF for ; Fri, 26 Oct 2001 10:55:30 -0500 Received: from fnal.gov ([131.225.7.82]) by imapserverb.fnal.gov (NAVIEG 2.1 bld 63) with SMTP id M2001102610553001495 for ; Fri, 26 Oct 2001 10:55:30 -0500 Message-ID: <3BD98773.FED7B025@fnal.gov> Date: Fri, 26 Oct 2001 10:55:31 -0500 From: yocum@fnal.gov X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: xfs-list Subject: Re: mmap.c:441: mmap_avl.c: No such file or directory References: <3BD982BC.84DADE10@fnal.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Nevermind. I blew the whole tree away and re-checked the whole thing out, and it looks good now. File this one under "Error 40" Cheers, Dan -- Dan Yocum Sloan Digital Sky Survey, Fermilab 630.840.6509 yocum@fnal.gov, http://www.sdss.org SDSS. Mapping the Universe. From owner-linux-xfs@oss.sgi.com Fri Oct 26 08:55:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QFtO622441 for linux-xfs-outgoing; Fri, 26 Oct 2001 08:55:24 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QFt6022418 for ; Fri, 26 Oct 2001 08:55:06 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA05539 for ; Fri, 26 Oct 2001 08:54:36 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA3410739; Fri, 26 Oct 2001 10:53:10 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA62751; Fri, 26 Oct 2001 10:53:10 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9QFnAT03091; Fri, 26 Oct 2001 10:49:10 -0500 Message-Id: <200110261549.f9QFnAT03091@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: yocum@fnal.gov cc: xfs-list Subject: Re: mmap.c:441: mmap_avl.c: No such file or directory In-Reply-To: Message from yocum@fnal.gov of "Fri, 26 Oct 2001 10:35:24 CDT." <3BD982BC.84DADE10@fnal.gov> Date: Fri, 26 Oct 2001 10:49:10 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hmm, can you try a clean tree, the line numbers you are getting errors on do not make much sense in my version of the tree (from cvs): For instance, line 752 of mm/mmap.c in my tree looks like this: * reinserted if necessary. * * The 4 main cases are: * Unmapping the whole area * Unmapping from the start of the segment to a point in it * Unmapping from an intermediate point to the end * Unmapping between to intermediate points, making a hole. * * Case 4 involves the creation of 2 new areas, for each side of * the hole. If possible, w The middle of a large block comment. Steve > Don't kill the messenger. :-) > > I updated from CVS this AM, which is supposed to be 2.4.13: > > > kgcc -D__KERNEL__ -I/usr/src/linux-2.4-xfs/linux/include -Wall > -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common > -fomit-frame-pointer -pipe -march=i686 -malign-functions=4 -c -o mmap.o > mmap.c > mmap.c:441: mmap_avl.c: No such file or directory > mmap.c: In function `do_munmap': > mmap.c:752: warning: implicit declaration of function `avl_remove' > mmap.c: In function `build_mmap_avl': > mmap.c:907: warning: implicit declaration of function `avl_insert' > mmap.c: In function `__insert_vm_struct': > mmap.c:967: warning: implicit declaration of function > `avl_insert_neighbours' > make[2]: *** [mmap.o] Error 1 > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/mm' > make[1]: *** [first_rule] Error 2 > make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux/mm' > make: *** [_dir_mm] Error 2 > > > I don't know if this is a vestige of the main tree or the merge with XFS. > > Cheers, > Dan > > -- > Dan Yocum > Sloan Digital Sky Survey, Fermilab 630.840.6509 > yocum@fnal.gov, http://www.sdss.org > SDSS. Mapping the Universe. From owner-linux-xfs@oss.sgi.com Fri Oct 26 09:10:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QGA4l23147 for linux-xfs-outgoing; Fri, 26 Oct 2001 09:10:04 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QGA1023119 for ; Fri, 26 Oct 2001 09:10:01 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA16995 for ; Fri, 26 Oct 2001 09:09:54 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA3208002; Fri, 26 Oct 2001 11:08:43 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id LAA56227; Fri, 26 Oct 2001 11:08:43 -0500 (CDT) Subject: Re: error compiling 2.4.9-6SGI_XFS_PR3 source From: Eric Sandeen To: Jim Eshleman Cc: linux-xfs@oss.sgi.com In-Reply-To: <3BD97DD0.EF227683@Lehigh.EDU> References: <3BD97DD0.EF227683@Lehigh.EDU> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 26 Oct 2001 11:06:48 -0500 Message-Id: <1004112408.23824.41.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Whoops, looks like an intermezzo-ism, I'll take a look... Thanks, -Eric On Fri, 2001-10-26 at 10:14, Jim Eshleman wrote: > HI! > > Following occurs during "make modules" (CONFIG_XFS_FS=m) with > 2.4.9-6SGI_XFS_PR3: -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Oct 26 09:35:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QGZax23741 for linux-xfs-outgoing; Fri, 26 Oct 2001 09:35:36 -0700 Received: from linux.nameip.net ([211.187.6.46]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QGZW023719 for ; Fri, 26 Oct 2001 09:35:33 -0700 Received: (qmail 3694 invoked from network); 26 Oct 2001 16:40:43 -0000 Received: from unknown (HELO orgio.net) (211.187.6.46) by 0 with SMTP; 26 Oct 2001 16:40:43 -0000 Message-ID: <3BD9920B.3000901@orgio.net> Date: Sat, 27 Oct 2001 01:40:43 +0900 From: Seung-young Oh User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011013 X-Accept-Language: ko MIME-Version: 1.0 To: linux-xfs Subject: Is this supposed to happen wih 2.4.9-XFS kernel? Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I have fully updated RedHat7.1, used to use 2.4.3-RH-XFS_1.0.1 kernel. Now I'm using kernel-2.4.9-6SGI_XFS_PR3_PR3 updated userspace RPM's and from time to time I'm getting core dumps with names such as core.3314 that I never got before with 2.4.3-RH-XFS_1.0.1 kernel. Crossover plugin, you know, the Quicktime & Shockwave plugins emulator for Linux webbrowsers, seems to generate them while still working well in my Mozilla 0.9.5. However I used the plugin with XFS1.0.1 patched 2.4.3 RH kernel, and I didn't have this problem. Would the current test kernel cause this? Please enlighten me. :-) -- ICQ#: 103231199 From owner-linux-xfs@oss.sgi.com Fri Oct 26 10:12:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QHCK628906 for linux-xfs-outgoing; Fri, 26 Oct 2001 10:12:20 -0700 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QHCF028884 for ; Fri, 26 Oct 2001 10:12:16 -0700 Received: (qmail 8740 invoked from network); 26 Oct 2001 17:12:12 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 26 Oct 2001 17:12:12 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 7B6D9300090; Sat, 27 Oct 2001 03:12:09 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id E983E98; Sat, 27 Oct 2001 03:12:09 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Seung-young Oh Cc: linux-xfs Subject: Re: Is this supposed to happen wih 2.4.9-XFS kernel? In-reply-to: Your message of "Sat, 27 Oct 2001 01:40:43 +0900." <3BD9920B.3000901@orgio.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 27 Oct 2001 03:12:04 +1000 Message-ID: <9022.1004116324@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 27 Oct 2001 01:40:43 +0900, Seung-young Oh wrote: >I have fully updated RedHat7.1, used to use 2.4.3-RH-XFS_1.0.1 kernel. >Now I'm using kernel-2.4.9-6SGI_XFS_PR3_PR3 updated userspace RPM's and >from time to time I'm getting core dumps with names such as core.3314 >that I never got before with 2.4.3-RH-XFS_1.0.1 kernel. Recent 2.4 kernels have an option to append the process id to the core file, it is normal. Unless there is something in the syslog, it is unlikely that this is an XFS problem. Do 'file core.3314' to list which command is failing and report it to the relevant developers. From owner-linux-xfs@oss.sgi.com Fri Oct 26 11:30:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QIUIC02060 for linux-xfs-outgoing; Fri, 26 Oct 2001 11:30:18 -0700 Received: from pinga.salk.edu (pinga.salk.edu [192.31.153.187]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QIUF002037 for ; Fri, 26 Oct 2001 11:30:15 -0700 Received: from muk.dyndns.org (muk.dyndns.org [24.30.128.214]) by pinga.salk.edu (8.12.1/8.11.6) with SMTP id f9QIUF4r008212 for ; Fri, 26 Oct 2001 11:30:15 -0700 Date: Fri, 26 Oct 2001 11:30:09 -0700 From: David Chambers To: linux-xfs@oss.sgi.com Subject: undefined reference to `xfs_dm_mapevent' Message-Id: <20011026113009.4d668a58.davidc@ccmi.salk.edu> X-Mailer: Sylpheed version 0.6.2claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi all! I have just updated my cvs copy of the XFS kernel and tried to compile it... Here's what I get during the build, if I don't enable XFS DMAPI (if I *do* enable this option, all compiles fine):- 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 --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/acpi/acpi.o drivers/char/char.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o driver s/char/drm/drm.o drivers/net/appletalk/appletalk.o drivers/ide/idedriver.o drivers/cdrom/driver.o drivers/pci/driver.o drivers/pn p/pnp.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 `linvfs_dmapi_map_event': fs/fs.o(.text+0xa1cd7): undefined reference to `xfs_dm_mapevent' make[1]: *** [kallsyms] Error 1 make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux' make: *** [vmlinux] Error 2 From owner-linux-xfs@oss.sgi.com Fri Oct 26 12:16:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QJG3P04806 for linux-xfs-outgoing; Fri, 26 Oct 2001 12:16:03 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QJFx004784 for ; Fri, 26 Oct 2001 12:15:59 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA01219 for ; Fri, 26 Oct 2001 12:15:18 -0700 (PDT) mail_from (roehrich@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA3384583 for ; Fri, 26 Oct 2001 14:14:42 -0500 (CDT) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.187.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA63940 for ; Fri, 26 Oct 2001 14:14:42 -0500 (CDT) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id OAA69432; Fri, 26 Oct 2001 14:14:41 -0500 (CDT) Message-Id: <200110261914.OAA69432@slobber.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: Re: undefined reference to `xfs_dm_mapevent' Date: Fri, 26 Oct 2001 14:14:41 -0500 From: Dean Roehrich Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk argh You should be able to ifdef out linvfs_dmapi_map_event() in fs/xfs/linux/xfs_file.c. I'll check in a fix as soon as my builds complete. Dean >From: David Chambers >Hi all! > >I have just updated my cvs copy of the XFS kernel and tried to compile it... >Here's what I get during the build, if I don't enable XFS DMAPI (if I *do* ena >ble this option, all compiles fine):- > >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 --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/acpi/acpi.o drivers/char/char.o drivers/block/block.o drivers/misc/mi >sc.o drivers/net/net.o drivers/media/media.o driver >s/char/drm/drm.o drivers/net/appletalk/appletalk.o drivers/ide/idedriver.o dri >vers/cdrom/driver.o drivers/pci/driver.o drivers/pn >p/pnp.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 `linvfs_dmapi_map_event': >fs/fs.o(.text+0xa1cd7): undefined reference to `xfs_dm_mapevent' >make[1]: *** [kallsyms] Error 1 >make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux' >make: *** [vmlinux] Error 2 > From owner-linux-xfs@oss.sgi.com Fri Oct 26 12:42:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QJgwG05770 for linux-xfs-outgoing; Fri, 26 Oct 2001 12:42:58 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QJgs005747 for ; Fri, 26 Oct 2001 12:42:55 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id VAA707066 for ; Fri, 26 Oct 2001 21:42:54 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA3408517 for ; Fri, 26 Oct 2001 14:41:36 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA46636 for ; Fri, 26 Oct 2001 14:41:35 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id f9QJbYd12655; Fri, 26 Oct 2001 14:37:34 -0500 Message-Id: <200110261937.f9QJbYd12655@jen.americas.sgi.com> Date: Fri, 26 Oct 2001 14:37:34 -0500 Subject: TAKE - fix build undefined reference to `xfs_dm_mapevent' Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Fri Oct 26 12:40:59 PDT 2001 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:105549a linux/fs/xfs/linux/xfs_file.c - 1.50 - Fix build in non dmapi case From owner-linux-xfs@oss.sgi.com Fri Oct 26 12:44:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QJiYf05963 for linux-xfs-outgoing; Fri, 26 Oct 2001 12:44:34 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QJiV005934 for ; Fri, 26 Oct 2001 12:44:31 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id VAA827181 for ; Fri, 26 Oct 2001 21:44:31 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA3418241 for ; Fri, 26 Oct 2001 14:43:13 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA85035 for ; Fri, 26 Oct 2001 14:43:13 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id f9QJdBv12741; Fri, 26 Oct 2001 14:39:11 -0500 Message-Id: <200110261939.f9QJdBv12741@jen.americas.sgi.com> Date: Fri, 26 Oct 2001 14:39:11 -0500 Subject: TAKE - code cleanup Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk use i_mapping instead of i_data Date: Fri Oct 26 12:42:54 PDT 2001 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:105551a linux/fs/xfs/linux/xfs_lrw.c - 1.115 linux/fs/xfs/linux/xfs_iops.c - 1.113 linux/fs/xfs/linux/xfs_vnode.h - 1.23 From owner-linux-xfs@oss.sgi.com Fri Oct 26 13:04:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QK4MT07054 for linux-xfs-outgoing; Fri, 26 Oct 2001 13:04:22 -0700 Received: from otto.cfht.hawaii.edu (otto.colonization.com [128.171.80.37]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QK4C007029 for ; Fri, 26 Oct 2001 13:04:18 -0700 Received: (from isani@localhost) by otto.cfht.hawaii.edu (8.8.8/8.8.8) id KAA01554 for linux-xfs@oss.sgi.com; Fri, 26 Oct 2001 10:03:49 -1000 From: Sidik Isani Message-Id: <200110262003.KAA01554@otto.cfht.hawaii.edu> Subject: gcc 2.91.66, 2.95.3, 2.95.4, growfs To: linux-xfs@oss.sgi.com Date: Fri, 26 Oct 2001 10:03:49 -1000 (HST) X-Mailer: ELM [version 2.5 PL0] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello - I'd like to upgrade to the proper kernel compiler, but things are still confusing. About 10 days ago . . . Seth Mos wrote: |At 13:18 16-10-2001 +0200, Robert Sander wrote: |>Hi! |> |>I just found the FAQ stating that one should compile an XFS kernel |>with gcc 2.91.66. Even Debian potato has 2.95.2 onboard. |>Does anyone know a debian source for 2.91.66 that is installable |>on woody or potato? | |Use alien to convert the compat-egcs rpm fropm redhat and install that. Does this mean that the RedHat package is not the same as egcs.cygnus.com:/pub/egcs/releases/egcs-1.1.2/egcs-1.1.2.tar.gz ??? That's the one I was about to try, but then I read this message. |People have reported success with that. The newer gcc from debian unstable |seems to do reasonable as well. What exactly is gcc-2.95.4? An unreleased CVS version? I'm just a little surprised that there is not a single stable version of gcc on ftp.gnu.org that can compile the Linux kernel. :-( I had been using 2.95.3, but eventually I discovered the grow_fs bug which you guys apparently tracked down to that register spill/reload bug in gcc-2.96.*. So... I gues that means gcc-2.95.3 has it as well? o Does anyone know if gcc-2.95.4 is really fixed? o Where does one get gcc-2.95.4? o If egcs-1.1.2.tar.gz is not the same as gcc-2.91.66, then could someone point me to a source tar-ball? Believe me, I want to use the "right" version, but it is not easy! Thanks for your help, - Sidik From owner-linux-xfs@oss.sgi.com Fri Oct 26 14:16:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QLGe610544 for linux-xfs-outgoing; Fri, 26 Oct 2001 14:16:40 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QLGX010522 for ; Fri, 26 Oct 2001 14:16:34 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id XAA857666 for ; Fri, 26 Oct 2001 23:16:33 +0200 (CEST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA3418074; Fri, 26 Oct 2001 16:15:14 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id QAA03978; Fri, 26 Oct 2001 16:15:14 -0500 (CDT) Subject: Re: error compiling 2.4.9-6SGI_XFS_PR3 source From: Eric Sandeen To: Jim Eshleman Cc: linux-xfs@oss.sgi.com In-Reply-To: <3BD97DD0.EF227683@Lehigh.EDU> References: <3BD97DD0.EF227683@Lehigh.EDU> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 26 Oct 2001 16:13:17 -0500 Message-Id: <1004130797.23824.99.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ok, looks like intermezzo+xfs isn't ready for prime-time yet. This is going into the next spin, it should fix your compile for now... just #defines away xfs support in intermezzo. -Eric --- linux/fs/intermezzo/methods.c.orig 2001/09/07 23:21:03 1.13 +++ linux/fs/intermezzo/methods.c 2001/10/26 19:29:23 @@ -163,7 +163,8 @@ if ( strlen(cache_type) == strlen("xfs") && memcmp(cache_type, "xfs", strlen("xfs")) == 0 ) { -#if defined(CONFIG_XFS_FS) || defined (CONFIG_XFS_FS_MODULE) +#if 0 +/*#if defined(CONFIG_XFS_FS) || defined (CONFIG_XFS_FS_MODULE) */ ops->o_trops = &presto_xfs_journal_ops; #else ops->o_trops = NULL; --- linux/fs/intermezzo/journal_xfs.c.orig 2001/09/20 15:43:20 1.6 +++ linux/fs/intermezzo/journal_xfs.c 2001/10/26 19:29:23 @@ -15,6 +15,7 @@ #include #include #include +#if 0 #ifdef CONFIG_FS_XFS #include #endif @@ -139,6 +140,8 @@ tr_journal_data: presto_xfs_journal_file_data }; -#endif /* CONFIG_XFS_FS */ +#endif + +#endif /* CONFIG_XFS_FS */ -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Oct 26 14:31:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QLVlO10922 for linux-xfs-outgoing; Fri, 26 Oct 2001 14:31:47 -0700 Received: from chef.cc.absoval.com (cpe-66-1-218-101.fl.sprintbbd.net [66.1.218.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QLVh010900 for ; Fri, 26 Oct 2001 14:31:43 -0700 Received: from ieee.org (IDENT:bs@thebs.cc.absoval.com [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id RAA01279; Fri, 26 Oct 2001 17:30:48 -0400 Message-ID: <3BD9D609.38362714@ieee.org> Date: Fri, 26 Oct 2001 17:30:49 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts/AbsoluteValueSystems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: Jim Eshleman , linux-xfs@oss.sgi.com Subject: Re: error compiling 2.4.9-6SGI_XFS_PR3 source References: <3BD97DD0.EF227683@Lehigh.EDU> <1004130797.23824.99.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: > Ok, looks like intermezzo+xfs isn't ready for prime-time yet. This is > going into the next spin, it should fix your compile for now... just > #defines away xfs support in intermezzo. FYI, with 2.4.9-6PR2, 2.4.9-6PR3 and 2.4.9-7PR3, I got a module dependency error with intermezzo.o, but only when installing the kernel-BOOT RPM (which isn't a big deal). Secondly, what is Intermezzo? A URL will do (and sorry for the off-topic inquiry). -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ---------------------------------------------------------------- Web site defacements are as much of a national security risk as inner city kids spray painting. There is nothing of value, and nothing that can't be fixed with a little re-paint. You'd have to have the equivalent stupidity of someone parking an F-18 in downtown LA. Even then, the only damage would be a new scheme! The US government wants life imprisonment for such "terrorism." From owner-linux-xfs@oss.sgi.com Fri Oct 26 14:33:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QLXkM11085 for linux-xfs-outgoing; Fri, 26 Oct 2001 14:33:46 -0700 Received: from borg-cube.no-ip.com (IDENT:root@adsl-45122.turboline.skynet.be [217.136.48.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QLXe011063 for ; Fri, 26 Oct 2001 14:33:40 -0700 Received: from sun.com (IDENT:kris@borg-cube.no-ip.com [127.0.0.1]) by borg-cube.no-ip.com (8.11.2/8.11.2) with ESMTP id f9QLQkW00732 for ; Fri, 26 Oct 2001 23:26:46 +0200 Message-ID: <3BD9D516.E80DA188@sun.com> Date: Fri, 26 Oct 2001 23:26:46 +0200 From: kris buggenhout X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.10-pre10-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-xfs@oss.sgi.com" Subject: Re: gcc 2.91.66, 2.95.3, 2.95.4, growfs References: <200110262003.KAA01554@otto.cfht.hawaii.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sidik Isani wrote: > Hello - > > I'd like to upgrade to the proper kernel compiler, but things are > still confusing. About 10 days ago . . . > > Believe me, I want to use the "right" version, but it is not easy! > I find this really strange ... I have been using gcc3.1 for a few months now and I havent had the slightest problem in compiling kernels or whatsoever... My system runs a 2.4.13 kernel for days on end ... xfs and all ... have no trouble not in compiling ( unless U call some warnings about depreciated use of initing var's compile problems) not in running (system is up for days on a row, ftp serving, connected to the internet doing e-mail relays etc... not a dormant system...) not in anything else but smooth runnin. doing 3D renderings in the background ... cpu is 1000% of the time 70-99% busy runnin apps, writin and readin I know that for support and debug reasons , one recommends to use egcs, or one of the approved kernel compilers. but its not a mandatory thing ... If ya just plan on running and help test the code base... expect to get it to compile on any compiler ... as U cannot be shure of the installed compiler in this chaotic user base, linux is ... kind regards, Kris Buggenhout ------------------------------------------------------------------------------------- Kris Buggenhout Project engineer Proffesional Services SUN Microsystems Belgium ------------------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Fri Oct 26 15:01:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QM1aC11842 for linux-xfs-outgoing; Fri, 26 Oct 2001 15:01:36 -0700 Received: from chef.cc.absoval.com (cpe-66-1-218-101.fl.sprintbbd.net [66.1.218.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QM1U011818 for ; Fri, 26 Oct 2001 15:01:30 -0700 Received: from ieee.org (IDENT:bs@thebs.cc.absoval.com [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id SAA01370; Fri, 26 Oct 2001 18:01:22 -0400 Message-ID: <3BD9DD33.4A0B6EC@ieee.org> Date: Fri, 26 Oct 2001 18:01:23 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts/AbsoluteValueSystems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: kris buggenhout CC: "linux-xfs@oss.sgi.com" Subject: Re: gcc 2.91.66, 2.95.3, 2.95.4, growfs -- off-topic References: <200110262003.KAA01554@otto.cfht.hawaii.edu> <3BD9D516.E80DA188@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk [ Off-topic, but I might as well as ask here. ] kris buggenhout wrote: > I find this really strange ... I have been using gcc3.1 for a > few months now and I havent had the slightest problem in compiling > kernels or whatsoever... I'm assuming by 3.1 you mean 3.0.1 (released August 25th). I have been very curious as to the status of 3.0.x at this point. We all know about RedHat's ripping ** of the incomplete GCC 2.96 development branch from the GCC tree, for which the Cygnus guys incremented to 2.97 which eventually became the 3.0 release. I had always assumed that 3.0.x would be more stable but backward compatible with egcs 1.1.2 (isn't that aka gcc 2.91.66?) and gcc 2.95. RedHat has also included GCC 3.0.1 in the latest RedHat 7.1 release, although it still compiles stock RPMs against 2.96 ** for obvious binary compatibility in the same major version (i.e. the X in X.Y). I'm assuming the next move for RedHat in 8.0 (among other vendors) will be the adoption of 3.0.x, safely putting the 2.96 bastard ** behind them (which Mandrake has seemingly adopted for their 8.x series to maintain compatibility with RedHat). I'm curious as to know if Linus and/or major distros are going to be moving to building their kernels under 3.0.x in the near future? Or is that a move that will only be made for the new 2.5/3.0 tree that will be started shortly? BTW, 3.0.2 just came out yesterday (October 25th). The GCC steering committee is targeting a 3.1 release for April 2002. I'm not too familar with GCC revisioning, and am curious if they follow a BSD-like numbering (i.e. .0 is "test," .1+ is "release"). Or is 3.0.x considered "soup"? IMHO, the sooner that we get to 3.0.x, the better. God knows Cygnus is doing a fantastic job as the GCC maintainer. I have used their commercial products before in an aerospace development environment. -- TheBS ** Disclaimer: I do understand some of the reasons why RedHat moved to GCC 2.96 in 7.0, so don't consider this a "bash." And once they did it for 7.0, they had to for 7.1 and 7.2, to maintain binary compatibility. -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ---------------------------------------------------------------- Web site defacements are as much of a national security risk as inner city kids spray painting. There is nothing of value, and nothing that can't be fixed with a little re-paint. You'd have to have the equivalent stupidity of someone parking an F-18 in downtown LA. Even then, the only damage would be a new scheme! The US government wants life imprisonment for such "terrorism." From owner-linux-xfs@oss.sgi.com Fri Oct 26 15:04:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QM4Ij12032 for linux-xfs-outgoing; Fri, 26 Oct 2001 15:04:18 -0700 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QM4F012010 for ; Fri, 26 Oct 2001 15:04:15 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9QM49W00604 for ; Fri, 26 Oct 2001 15:04:10 -0700 Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA3408893; Fri, 26 Oct 2001 17:02:54 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id RAA21006; Fri, 26 Oct 2001 17:02:53 -0500 (CDT) Subject: Re: error compiling 2.4.9-6SGI_XFS_PR3 source From: Eric Sandeen To: Bryan-TheBS-Smith Cc: linux-xfs@oss.sgi.com In-Reply-To: <3BD9D609.38362714@ieee.org> References: <3BD97DD0.EF227683@Lehigh.EDU> <1004130797.23824.99.camel@stout.americas.sgi.com> <3BD9D609.38362714@ieee.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 26 Oct 2001 17:00:56 -0500 Message-Id: <1004133656.23824.101.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2001-10-26 at 16:30, Bryan-TheBS-Smith wrote: > Eric Sandeen wrote: > > Ok, looks like intermezzo+xfs isn't ready for prime-time yet. This is > > going into the next spin, it should fix your compile for now... just > > #defines away xfs support in intermezzo. > > FYI, with 2.4.9-6PR2, 2.4.9-6PR3 and 2.4.9-7PR3, I got a module > dependency error with intermezzo.o, but only when installing the > kernel-BOOT RPM (which isn't a big deal). Yep, I just hit this too. Next spin will have this fixed. > Secondly, what is Intermezzo? A URL will do (and sorry for the > off-topic inquiry). www.inter-mezzo.org -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Oct 26 15:20:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QMKsu12492 for linux-xfs-outgoing; Fri, 26 Oct 2001 15:20:54 -0700 Received: from otto.cfht.hawaii.edu (otto.colonization.com [128.171.80.37]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QMKk012470 for ; Fri, 26 Oct 2001 15:20:51 -0700 Received: (from isani@localhost) by otto.cfht.hawaii.edu (8.8.8/8.8.8) id MAA02030; Fri, 26 Oct 2001 12:20:36 -1000 From: Sidik Isani Message-Id: <200110262220.MAA02030@otto.cfht.hawaii.edu> Subject: Re: gcc 2.91.66, 2.95.3, 2.95.4, growfs -- off-topic To: b.j.smith@ieee.org (Bryan-TheBS-Smith) Date: Fri, 26 Oct 2001 12:20:36 -1000 (HST) Cc: kris.buggenhout@sun.com (kris buggenhout), linux-xfs@oss.sgi.com (linux-xfs@oss.sgi.com) In-Reply-To: <3BD9DD33.4A0B6EC@ieee.org> from "Bryan-TheBS-Smith" at Oct 26, 2001 06:01:23 PM X-Mailer: ELM [version 2.5 PL0] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk |We all know about RedHat's ripping ** of the incomplete GCC 2.96 |development branch from the GCC tree, for which the Cygnus guys |incremented to 2.97 which eventually became the 3.0 release. I had Doesn't RedHat OWN Cygnus? - Sidik From owner-linux-xfs@oss.sgi.com Fri Oct 26 15:26:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QMQTH13028 for linux-xfs-outgoing; Fri, 26 Oct 2001 15:26:29 -0700 Received: from chef.cc.absoval.com (cpe-66-1-218-101.fl.sprintbbd.net [66.1.218.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QMQL013005 for ; Fri, 26 Oct 2001 15:26:21 -0700 Received: from ieee.org (IDENT:bs@thebs.cc.absoval.com [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id SAA01447; Fri, 26 Oct 2001 18:26:12 -0400 Message-ID: <3BD9E305.FBB96A41@ieee.org> Date: Fri, 26 Oct 2001 18:26:13 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts/AbsoluteValueSystems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: linux-xfs@oss.sgi.com, leaplist@lists.leap-cf.org Subject: Re: error compiling 2.4.9-6SGI_XFS_PR3 source References: <3BD97DD0.EF227683@Lehigh.EDU> <1004130797.23824.99.camel@stout.americas.sgi.com> <3BD9D609.38362714@ieee.org> <1004133656.23824.101.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk [ Now I'm getting _really_ off-topic. Typical of end-user "leeches" like myself on a developer list. ;-PPP ] Eric Sandeen wrote: > www.inter-mezzo.org Okay, now we're talking high availability. First off, I see it is "inspired" by CODA. That's cool. And CODA is [virtually] a fork of AFS 2 (if I remember correctly). And I just read about another "failover" filesystem in SysAdmin (or was it UNIX Review? possibly even Linux Journal?) recently that began with a "M". If anyone wants to give me the "quick lowdown" on all these emerging high availability / failover filesystems, platform availability, their compatibility with or complete replacement of (i.e. if they provide both HA/failover as well as sharing services) NFS and/or Samba, etc... I'd greatly appreciated it. Better yet, if you could post it to my local LUG (LEAP, cc'ed above, probably want to remove the XFS list), I'd greatly appreciate it. Thanx in advance ... -- The "only know NFS/Samba and too lazy to try AFS (let alone anything else)" BS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ---------------------------------------------------------------- Web site defacements are as much of a national security risk as inner city kids spray painting. There is nothing of value, and nothing that can't be fixed with a little re-paint. You'd have to have the equivalent stupidity of someone parking an F-18 in downtown LA. Even then, the only damage would be a new scheme! The US government wants life imprisonment for such "terrorism." From owner-linux-xfs@oss.sgi.com Fri Oct 26 15:29:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QMTH313181 for linux-xfs-outgoing; Fri, 26 Oct 2001 15:29:17 -0700 Received: from chef.cc.absoval.com (cpe-66-1-218-101.fl.sprintbbd.net [66.1.218.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QMTD013159 for ; Fri, 26 Oct 2001 15:29:13 -0700 Received: from ieee.org (IDENT:bs@thebs.cc.absoval.com [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id SAA01455; Fri, 26 Oct 2001 18:29:00 -0400 Message-ID: <3BD9E3AD.B123B775@ieee.org> Date: Fri, 26 Oct 2001 18:29:01 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts/AbsoluteValueSystems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Sidik Isani CC: kris buggenhout , "linux-xfs@oss.sgi.com" Subject: Re: gcc 2.91.66, 2.95.3, 2.95.4, growfs -- off-topic References: <200110262220.MAA02030@otto.cfht.hawaii.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sidik Isani wrote: > Doesn't RedHat OWN Cygnus? Yes. But that doesn't necessarily mean that the GCC maintainers and GNU Pro guys (i.e. Cygnus) agree with the acts of the distro assemblers and testers (i.e. RedHat Linux). ;-PPP This is not Microsoft where NT developers end up being "Chicago"'s (i.e. MS-DOS 7.x + Windows 4.x -- i.e. Windows 95) "bitch" without any say. ;-PPP OSS developers and teams speak their mind, _before_ things get out of hand. -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ---------------------------------------------------------------- Web site defacements are as much of a national security risk as inner city kids spray painting. There is nothing of value, and nothing that can't be fixed with a little re-paint. You'd have to have the equivalent stupidity of someone parking an F-18 in downtown LA. Even then, the only damage would be a new scheme! The US government wants life imprisonment for such "terrorism." From owner-linux-xfs@oss.sgi.com Fri Oct 26 16:47:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QNl5Q16542 for linux-xfs-outgoing; Fri, 26 Oct 2001 16:47:05 -0700 Received: from ausmail.coremetrics.com ([209.184.141.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QNkx016516 for ; Fri, 26 Oct 2001 16:46:59 -0700 Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Oct 2001 18:46:28 -0500 Message-ID: <85063BBE668FD411944400D0B744267A888696@AUSMAIL> From: "Gonyou, Austin" To: "'Sidik Isani'" , linux-xfs@oss.sgi.com Subject: RE: gcc 2.91.66, 2.95.3, 2.95.4, growfs Date: Fri, 26 Oct 2001 18:46:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've been using gcc 3.0, 3.0.1, 3.0.2, and gcc-cvs versions at home and have compiled kernels with no further effort than that. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com > -----Original Message----- > From: Sidik Isani [mailto:isani@cfht.hawaii.edu] > Sent: Friday, October 26, 2001 3:04 PM > To: linux-xfs@oss.sgi.com > Subject: gcc 2.91.66, 2.95.3, 2.95.4, growfs > > > Hello - > > I'd like to upgrade to the proper kernel compiler, but things are > still confusing. About 10 days ago . . . > > Seth Mos wrote: > |At 13:18 16-10-2001 +0200, Robert Sander wrote: > |>Hi! > |> > |>I just found the FAQ stating that one should compile an XFS kernel > |>with gcc 2.91.66. Even Debian potato has 2.95.2 onboard. > |>Does anyone know a debian source for 2.91.66 that is installable > |>on woody or potato? > | > |Use alien to convert the compat-egcs rpm fropm redhat and > install that. > > Does this mean that the RedHat package is not the same as > egcs.cygnus.com:/pub/egcs/releases/egcs-1.1.2/egcs-1.1.2.tar.gz ??? > That's the one I was about to try, but then I read this message. > > |People have reported success with that. The newer gcc from > debian unstable > |seems to do reasonable as well. > > What exactly is gcc-2.95.4? An unreleased CVS version? I'm just > a little surprised that there is not a single stable version of > gcc on ftp.gnu.org that can compile the Linux kernel. :-( I had > been using 2.95.3, but eventually I discovered the grow_fs bug which > you guys apparently tracked down to that register spill/reload bug > in gcc-2.96.*. So... I gues that means gcc-2.95.3 has it as well? > > o Does anyone know if gcc-2.95.4 is really fixed? > o Where does one get gcc-2.95.4? > o If egcs-1.1.2.tar.gz is not the same as gcc-2.91.66, then could > someone point me to a source tar-ball? > > Believe me, I want to use the "right" version, but it is not easy! > > Thanks for your help, > > - Sidik > From owner-linux-xfs@oss.sgi.com Fri Oct 26 23:12:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9R6CO428235 for linux-xfs-outgoing; Fri, 26 Oct 2001 23:12:24 -0700 Received: from pooh.lsc.hu (IDENT:qmailr@lsc.net23.hu [195.56.172.131]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9R6CK028212 for ; Fri, 26 Oct 2001 23:12:20 -0700 Received: (qmail 32428 invoked by uid 547); 27 Oct 2001 06:25:19 -0000 Date: Sat, 27 Oct 2001 08:25:19 +0200 From: GCS To: linux-xfs@oss.sgi.com Subject: Re: Bug with 2.4.13? Message-ID: <20011027082519.A32377@lsc.hu> References: <200110261201.f9QC1sA02076@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200110261201.f9QC1sA02076@jen.americas.sgi.com>; from lord@sgi.com on Fri, Oct 26, 2001 at 07:01:54AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Oct 26, 2001 at 07:01:54AM -0500, Steve Lord wrote: > Hmm, please make sure you got the last change I checked into the tree > yesterday, do one more cvs update and see if you get a new xfs_super.c > let me know what happens either way. Ok, I have the version of Oct 27, 14:00 CET. It crashes at the same point. Allways at the same eip. Maybe my partition is already trashed, and it causes the trouble. Anyway, if you ever want to get part of my partition (where XFS store internal variables), just ask me. Bye, GCS From owner-linux-xfs@oss.sgi.com Fri Oct 26 23:27:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9R6Rc628543 for linux-xfs-outgoing; Fri, 26 Oct 2001 23:27:38 -0700 Received: from pooh.lsc.hu (IDENT:qmailr@lsc.net23.hu [195.56.172.131]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9R6RZ028521 for ; Fri, 26 Oct 2001 23:27:35 -0700 Received: (qmail 32492 invoked by uid 547); 27 Oct 2001 06:40:34 -0000 Date: Sat, 27 Oct 2001 08:40:34 +0200 From: GCS To: linux-xfs@oss.sgi.com Subject: Re: Bug with 2.4.13? Message-ID: <20011027084034.C32377@lsc.hu> References: <200110261201.f9QC1sA02076@jen.americas.sgi.com> <20011027082519.A32377@lsc.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011027082519.A32377@lsc.hu>; from gcs@lsc.hu on Sat, Oct 27, 2001 at 08:25:19AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, Oct 27, 2001 at 08:25:19AM +0200, GCS wrote: > Ok, I have the version of Oct 27, 14:00 CET. It crashes at the same point. > Allways at the same eip. Maybe my partition is already trashed, and it > causes the trouble. Anyway, if you ever want to get part of my partition > (where XFS store internal variables), just ask me. Forgot to add: I have seen a warning for buffer.c. It said that control reaches end of non-void function. Can it cause trouble as fe an XFS code waits for a return value, which is not sanity checked thus the 'random' return code confuses something? GCS From owner-linux-xfs@oss.sgi.com Fri Oct 26 23:30:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9R6Ufx28695 for linux-xfs-outgoing; Fri, 26 Oct 2001 23:30:41 -0700 Received: from mail.spylog.com (mail.spylog.com [194.67.35.220]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9R6Ub028672 for ; Fri, 26 Oct 2001 23:30:38 -0700 Received: from an.local (an.local [192.168.4.50]) by mail.spylog.com (Postfix) with ESMTP id DF9852C87B for ; Sat, 27 Oct 2001 10:30:31 +0400 (MSD) Received: by an.local (Postfix, from userid 1000) id B0ADC14435; Sat, 27 Oct 2001 10:30:31 +0400 (MSD) Date: Sat, 27 Oct 2001 10:30:31 +0400 From: Andrey Nekrasov To: linux-xfs@oss.sgi.com Subject: Re: xfsdump not compile. Message-ID: <20011027103031.A6969@spylog.ru> Mail-Followup-To: linux-xfs@oss.sgi.com References: <3BD970C5.5928.1042CE0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3BD970C5.5928.1042CE0@localhost> User-Agent: Mutt/1.3.23i Organization: SpyLOG ltd. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello christian mueller, Once you wrote about "Re: xfsdump not compile.": > hi andrey, > > > .. > > an:/usr/src/linux-2.4-xfs/cmd/xfsdump# dpkg -l |grep attr > > ii attr 2.0.0-0 Utilities for manipulating filesystem extend > > ii attr-dev 2.0.0-0 Extended attribute static libraries and head > > an:/usr/src/linux-2.4-xfs/cmd/xfsdump# > >.. > > don't use the cmd/attr2 stuff. use cmd/attr ! > File: [Development] / linux-2.4-xfs / cmd / attr2 / BIG.FAT.WARNING ïË, with attr-1.x.x all compile. Thanks. -- bye. Andrey Nekrasov, SpyLOG. From owner-linux-xfs@oss.sgi.com Sat Oct 27 02:06:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9R96jM30637 for linux-xfs-outgoing; Sat, 27 Oct 2001 02:06:45 -0700 Received: from otto.cfht.hawaii.edu (otto.colonization.com [128.171.80.37]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9R96a030614 for ; Sat, 27 Oct 2001 02:06:41 -0700 Received: (from isani@localhost) by otto.cfht.hawaii.edu (8.8.8/8.8.8) id XAA03185; Fri, 26 Oct 2001 23:06:27 -1000 From: Sidik Isani Message-Id: <200110270906.XAA03185@otto.cfht.hawaii.edu> Subject: Re: gcc 2.91.66, 2.95.3, 2.95.4, growfs To: austin@coremetrics.com (Gonyou, Austin) Date: Fri, 26 Oct 2001 23:06:26 -1000 (HST) Cc: isani@cfht.hawaii.edu ('Sidik Isani'), linux-xfs@oss.sgi.com In-Reply-To: <85063BBE668FD411944400D0B744267A888696@AUSMAIL> from "Gonyou, Austin" at Oct 26, 2001 06:46:28 PM X-Mailer: ELM [version 2.5 PL0] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk | |I've been using gcc 3.0, 3.0.1, 3.0.2, and gcc-cvs versions at home and have |compiled kernels with no further effort than that. Ok, thanks, that's a good data point to have. I'm not sure the issue is "compilation effort" though. I've even been able to compile 2.4 kernels with gcc-2.7.2.3, with minor mods. And it compiles just great out of the box with 2.95.3 too... but there were allegedly obscure but scary bugs in the assembly generated by this compiler that took *months* of use to discover. A suggestion for the FAQ: If the "egcs-1.1.2.tar.gz" I mentioned in my last message is *the* gcc-2.91.66, that is a useful piece of information. If the RedHat version has the same number but had last minute fixes... then the O in Open source stands for Obfuscated if you ask me. Be seeing you, - Sidik From owner-linux-xfs@oss.sgi.com Sat Oct 27 05:22:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9RCMBG01875 for linux-xfs-outgoing; Sat, 27 Oct 2001 05:22:11 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9RCM7001853 for ; Sat, 27 Oct 2001 05:22:07 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id FAA04848 for ; Sat, 27 Oct 2001 05:22:00 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id HAA3422876; Sat, 27 Oct 2001 07:20:50 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id HAA96627; Sat, 27 Oct 2001 07:20:49 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9RCGeU30200; Sat, 27 Oct 2001 07:16:40 -0500 Message-Id: <200110271216.f9RCGeU30200@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: GCS cc: linux-xfs@oss.sgi.com Subject: Re: Bug with 2.4.13? In-Reply-To: Message from GCS of "Sat, 27 Oct 2001 08:25:19 +0200." <20011027082519.A32377@lsc.hu> Date: Sat, 27 Oct 2001 07:16:40 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Fri, Oct 26, 2001 at 07:01:54AM -0500, Steve Lord wrote: > > Hmm, please make sure you got the last change I checked into the tree > > yesterday, do one more cvs update and see if you get a new xfs_super.c > > let me know what happens either way. > Ok, I have the version of Oct 27, 14:00 CET. It crashes at the same point. > Allways at the same eip. Maybe my partition is already trashed, and it > causes the trouble. Anyway, if you ever want to get part of my partition > (where XFS store internal variables), just ask me. > > Bye, GCS Hmm, the only suggestion I have right now is to do a make clean and a complete kernel rebuild. I did find a couple of instances where code was not getting rebuilt in my tree which lead to problems. Following this do an xfs_repair -n on the device and send me the output - this will not touch the disk. You could also run xfs_check on the device and send that output. Thanks Steve From owner-linux-xfs@oss.sgi.com Sat Oct 27 05:39:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9RCdea02294 for linux-xfs-outgoing; Sat, 27 Oct 2001 05:39:40 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9RCdY002271 for ; Sat, 27 Oct 2001 05:39:34 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id FAA01476 for ; Sat, 27 Oct 2001 05:38:54 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id HAA3419648; Sat, 27 Oct 2001 07:38:17 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id HAA40642; Sat, 27 Oct 2001 07:38:16 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9RCY8Z30299; Sat, 27 Oct 2001 07:34:08 -0500 Message-Id: <200110271234.f9RCY8Z30299@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Bryan-TheBS-Smith cc: Sidik Isani , kris buggenhout , "linux-xfs@oss.sgi.com" Subject: Re: gcc 2.91.66, 2.95.3, 2.95.4, growfs -- off-topic In-Reply-To: Message from Bryan-TheBS-Smith of "Fri, 26 Oct 2001 18:29:01 EDT." <3BD9E3AD.B123B775@ieee.org> Date: Sat, 27 Oct 2001 07:34:08 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Just some comments on this topic in general. I actually use redhat's compiler when working on xfs, and I very rarely see a problem, the growfs thing was the last one and the one prior to that was several months back. This code example was submitted to redhat in a bug report by a more knowledgable person than us. A bug has been identified in the compiler, and it appears to be in all versions, but other behavior in the compiler appears to bring it out differently in various gcc versions. So I would actually say that unless you are using every single byte of xfs code then you are probably OK with the compiler you have. Only if you start experiencing odd problems which are not being reported by other people should you consider switching. In the meantime, there is a compiler bugfix on its way, but I do not know when it might appear. Steve > Sidik Isani wrote: > > Doesn't RedHat OWN Cygnus? > > Yes. But that doesn't necessarily mean that the GCC maintainers and > GNU Pro guys (i.e. Cygnus) agree with the acts of the distro > assemblers and testers (i.e. RedHat Linux). ;-PPP > > This is not Microsoft where NT developers end up being "Chicago"'s > (i.e. MS-DOS 7.x + Windows 4.x -- i.e. Windows 95) "bitch" without > any say. ;-PPP > > OSS developers and teams speak their mind, _before_ things get out > of hand. > > -- TheBS > > -- > Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 > Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org > President SmithConcepts, Inc. http://www.SmithConcepts.com > ---------------------------------------------------------------- > Web site defacements are as much of a national security risk as > inner city kids spray painting. There is nothing of value, and > nothing that can't be fixed with a little re-paint. You'd have > to have the equivalent stupidity of someone parking an F-18 in > downtown LA. Even then, the only damage would be a new scheme! > The US government wants life imprisonment for such "terrorism." From owner-linux-xfs@oss.sgi.com Sat Oct 27 08:43:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9RFhIx05029 for linux-xfs-outgoing; Sat, 27 Oct 2001 08:43:18 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9RFgQ005005 for ; Sat, 27 Oct 2001 08:42:26 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA07704 for ; Sat, 27 Oct 2001 08:41:46 -0700 (PDT) mail_from (postmaster@jen.americas.sgi.com) From: postmaster@jen.americas.sgi.com.sgi.com Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA3421417 for ; Sat, 27 Oct 2001 10:41:09 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA30656 for ; Sat, 27 Oct 2001 10:41:09 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id f9RFax315423; Sat, 27 Oct 2001 10:36:59 -0500 Message-Id: <200110271536.f9RFax315423@jen.americas.sgi.com> Date: Sat, 27 Oct 2001 10:36:59 -0500 Subject: TAKE - merge up to 2.4.14-pre3 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk There is a 2.4.13 patch on oss.sgi.com in projects/xfs/download for those who still want to stay on the released kernels. The change in here which may affect people is that the lvm version has been reverted to the one in Linus's tree. A later LVM from sistina could be applied over this. Date: Sat Oct 27 08:36:43 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:105575a linux/drivers/acpi/executer/exoparg6.c - 1.1 linux/drivers/atm/lanai.c - 1.1 linux/drivers/acpi/utilities/utmath.c - 1.1 linux/drivers/char/eurotechwdt.c - 1.1 linux/drivers/net/irda/ep7211_ir.c - 1.1 linux/drivers/net/irda/sa1100_ir.c - 1.1 linux/drivers/pcmcia/i82092.c - 1.1 linux/drivers/pcmcia/i82092aa.h - 1.1 linux/fs/inflate_fs/Makefile - 1.1 linux/fs/inflate_fs/adler32.c - 1.1 linux/fs/inflate_fs/infblock.c - 1.1 linux/arch/arm/def-configs/adsbitsy - 1.1 linux/fs/inflate_fs/infblock.h - 1.1 linux/fs/inflate_fs/infcodes.c - 1.1 linux/fs/inflate_fs/infcodes.h - 1.1 linux/arch/arm/def-configs/cerfcube - 1.1 linux/arch/arm/def-configs/cerfpda - 1.1 linux/arch/arm/def-configs/cerfpod - 1.1 linux/arch/arm/def-configs/edb7211 - 1.1 linux/arch/arm/def-configs/epxa10db - 1.1 linux/fs/inflate_fs/inffast.c - 1.1 linux/arch/arm/def-configs/graphicsmaster - 1.1 linux/fs/inflate_fs/inffast.h - 1.1 linux/fs/inflate_fs/inffixed.h - 1.1 linux/fs/inflate_fs/inflate.c - 1.1 linux/fs/inflate_fs/inflate_syms.c - 1.1 linux/fs/inflate_fs/inftrees.c - 1.1 linux/fs/inflate_fs/inftrees.h - 1.1 linux/fs/inflate_fs/infutil.c - 1.1 linux/fs/inflate_fs/infutil.h - 1.1 linux/fs/inflate_fs/zconf.h - 1.1 linux/fs/inflate_fs/zutil.h - 1.1 linux/arch/arm/mach-epxa10db/Makefile - 1.1 linux/arch/arm/mach-epxa10db/arch.c - 1.1 linux/arch/arm/mach-epxa10db/dma.c - 1.1 linux/arch/arm/mach-epxa10db/irq.c - 1.1 linux/arch/arm/mach-epxa10db/mm.c - 1.1 linux/arch/arm/mach-epxa10db/time.c - 1.1 linux/fs/isofs/compress.c - 1.1 linux/drivers/acpi/executer/exoparg3.c - 1.1 linux/drivers/acpi/executer/exoparg2.c - 1.1 linux/drivers/acpi/executer/exoparg1.c - 1.1 linux/fs/isofs/zisofs.h - 1.1 linux/include/asm-arm/arch-epxa10db/dma.h - 1.1 linux/include/asm-arm/arch-epxa10db/excalibur.h - 1.1 linux/include/asm-arm/arch-epxa10db/hardware.h - 1.1 linux/include/asm-arm/arch-epxa10db/int_ctrl00.h - 1.1 linux/arch/arm/mach-sa1100/leds-adsbitsy.c - 1.1 linux/include/asm-arm/arch-epxa10db/io.h - 1.1 linux/include/asm-arm/arch-epxa10db/irq.h - 1.1 linux/include/asm-arm/arch-epxa10db/irqs.h - 1.1 linux/include/asm-arm/arch-epxa10db/memory.h - 1.1 linux/include/asm-arm/arch-epxa10db/mode_ctrl00.h - 1.1 linux/include/asm-arm/arch-epxa10db/param.h - 1.1 linux/arch/arm/mach-sa1100/pm.c - 1.1 linux/include/asm-arm/arch-epxa10db/platform.h - 1.1 linux/arch/arm/mach-sa1100/sleep.S - 1.1 linux/arch/arm/mach-sa1100/sleep.h - 1.1 linux/include/asm-arm/arch-epxa10db/pld_conf00.h - 1.1 linux/include/asm-arm/arch-epxa10db/serial.h - 1.1 linux/include/asm-arm/arch-epxa10db/system.h - 1.1 linux/include/asm-arm/arch-epxa10db/time.h - 1.1 linux/include/asm-arm/arch-epxa10db/timer00.h - 1.1 linux/include/asm-arm/arch-epxa10db/timex.h - 1.1 linux/include/asm-arm/arch-epxa10db/uart00.h - 1.1 linux/include/asm-arm/arch-epxa10db/uncompress.h - 1.1 linux/include/asm-arm/arch-epxa10db/vmalloc.h - 1.1 linux/include/asm-arm/hardware/ep7211.h - 1.1 linux/mm/vmscan.c - 1.84 linux/mm/swapfile.c - 1.42 linux/mm/swap_state.c - 1.34 linux/mm/swap.c - 1.17 linux/mm/page_alloc.c - 1.63 linux/mm/mmap.c - 1.43 linux/mm/memory.c - 1.65 linux/mm/filemap.c - 1.94 linux/mm/Makefile - 1.9 linux/kernel/exec_domain.c - 1.15 linux/include/linux/swap.h - 1.46 linux/include/linux/pagemap.h - 1.33 linux/include/linux/mm.h - 1.69 linux/include/linux/lp.h - 1.7 linux/include/linux/iso_fs_sb.h - 1.4 linux/include/linux/iso_fs_i.h - 1.3 linux/include/linux/iso_fs.h - 1.11 linux/include/linux/fs.h - 1.131 linux/include/linux/cdrom.h - 1.20 linux/include/linux/blkdev.h - 1.42 linux/include/asm-sparc64/floppy.h - 1.14 linux/include/asm-sparc/floppy.h - 1.5 linux/include/asm-ppc/floppy.h - 1.5 linux/include/asm-mips/floppy.h - 1.6 linux/include/asm-m68k/unistd.h - 1.11 linux/include/asm-m68k/uaccess.h - 1.5 linux/include/asm-m68k/system.h - 1.8 linux/include/asm-m68k/string.h - 1.5 linux/include/asm-m68k/stat.h - 1.7 linux/include/asm-m68k/softirq.h - 1.7 linux/include/asm-m68k/serial.h - 1.6 linux/include/asm-m68k/semaphore.h - 1.8 linux/include/asm-m68k/pgtable.h - 1.14 linux/include/asm-m68k/io.h - 1.7 linux/include/asm-m68k/hardirq.h - 1.8 linux/include/asm-m68k/floppy.h - 1.5 linux/include/asm-m68k/bitops.h - 1.7 linux/include/asm-m68k/atarihw.h - 1.4 linux/include/asm-i386/spinlock.h - 1.21 linux/include/asm-i386/io.h - 1.19 linux/include/asm-i386/floppy.h - 1.6 linux/include/asm-arm/uaccess.h - 1.9 linux/include/asm-arm/setup.h - 1.12 linux/include/asm-arm/proc-armv/uaccess.h - 1.10 linux/include/asm-arm/keyboard.h - 1.5 linux/include/asm-arm/arch-rpc/keyboard.h - 1.4 linux/include/asm-arm/arch-ebsa285/keyboard.h - 1.5 linux/include/asm-arm/arch-arc/keyboard.h - 1.4 linux/include/asm-alpha/pgtable.h - 1.30 linux/include/asm-alpha/floppy.h - 1.5 linux/fs/isofs/util.c - 1.6 linux/fs/isofs/rock.h - 1.3 linux/fs/isofs/rock.c - 1.15 linux/fs/isofs/inode.c - 1.26 linux/fs/isofs/Makefile - 1.6 linux/fs/exec.c - 1.48 linux/fs/buffer.c - 1.91 linux/fs/block_dev.c - 1.31 linux/fs/adfs/super.c - 1.12 linux/fs/adfs/map.c - 1.7 linux/drivers/video/clgenfb.c - 1.22 linux/drivers/video/Makefile - 1.34 linux/drivers/sound/waveartist.h - 1.4 linux/drivers/sound/waveartist.c - 1.14 linux/drivers/sound/sb_ess.c - 1.12 linux/drivers/scsi/wd33c93.h - 1.9 linux/drivers/scsi/wd33c93.c - 1.7 linux/drivers/scsi/u14-34f.c - 1.17 linux/drivers/scsi/sr.c - 1.30 linux/drivers/scsi/sd.c - 1.49 linux/drivers/scsi/qlogicpti.c - 1.15 linux/drivers/scsi/qlogicisp.c - 1.24 linux/drivers/scsi/qlogicfc.c - 1.24 linux/drivers/scsi/qlogicfas.c - 1.10 linux/drivers/scsi/mvme16x.c - 1.6 linux/drivers/scsi/megaraid.h - 1.12 linux/drivers/scsi/megaraid.c - 1.29 linux/drivers/scsi/mca_53c9x.c - 1.8 linux/drivers/scsi/mac_esp.c - 1.10 linux/drivers/scsi/jazz_esp.c - 1.6 linux/drivers/scsi/gvp11.c - 1.11 linux/drivers/scsi/gdth.c - 1.17 linux/drivers/scsi/fastlane.c - 1.9 linux/drivers/scsi/dtc.h - 1.4 linux/drivers/scsi/cyberstormII.c - 1.9 linux/drivers/scsi/cyberstorm.c - 1.9 linux/drivers/scsi/constants.c - 1.8 linux/drivers/scsi/bvme6000.c - 1.4 linux/drivers/scsi/blz2060.c - 1.9 linux/drivers/scsi/blz1230.c - 1.9 linux/drivers/scsi/amiga7xx.c - 1.8 linux/drivers/scsi/aic7xxx/aic7xxx.seq - 1.10 linux/drivers/scsi/aic7xxx/aic7xxx.reg - 1.8 linux/drivers/scsi/a3000.c - 1.10 linux/drivers/scsi/a2091.c - 1.12 linux/drivers/scsi/53c7xx.h - 1.5 linux/drivers/scsi/53c7xx.c - 1.14 linux/drivers/scsi/53c7,8xx.c - 1.15 linux/drivers/pnp/Config.in - 1.7 linux/drivers/net/irda/Makefile - 1.15 linux/drivers/net/irda/Config.in - 1.12 linux/drivers/net/hamradio/scc.c - 1.23 linux/drivers/net/acenic.c - 1.34 linux/drivers/isdn/isdn_ppp.c - 1.19 linux/drivers/isdn/hisax/niccy.c - 1.14 linux/drivers/char/vt.c - 1.22 linux/drivers/char/random.c - 1.20 linux/drivers/char/lp.c - 1.25 linux/drivers/char/istallion.c - 1.18 linux/drivers/char/Config.in - 1.53 linux/drivers/cdrom/sonycd535.c - 1.14 linux/drivers/cdrom/sjcd.c - 1.12 linux/drivers/cdrom/sbpcd.c - 1.15 linux/drivers/cdrom/optcd.c - 1.13 linux/drivers/cdrom/mcdx.c - 1.10 linux/drivers/cdrom/mcd.c - 1.13 linux/drivers/cdrom/gscd.c - 1.12 linux/drivers/cdrom/cm206.c - 1.13 linux/drivers/cdrom/cdu31a.c - 1.9 linux/drivers/cdrom/cdrom.c - 1.35 linux/drivers/cdrom/aztcd.c - 1.14 linux/drivers/block/z2ram.c - 1.13 linux/drivers/block/xd.c - 1.25 linux/drivers/block/rd.c - 1.39 linux/drivers/block/ps2esdi.c - 1.24 linux/drivers/block/paride/pf.c - 1.15 linux/drivers/block/paride/pd.c - 1.20 linux/drivers/block/paride/pcd.c - 1.12 linux/drivers/block/paride/epat.c - 1.6 linux/drivers/block/paride/Config.in - 1.5 linux/drivers/block/nbd.c - 1.24 linux/drivers/block/loop.c - 1.40 linux/drivers/block/ll_rw_blk.c - 1.78 linux/drivers/block/floppy.c - 1.29 linux/drivers/block/ataflop.c - 1.16 linux/drivers/block/amiflop.c - 1.18 linux/drivers/block/acsi.c - 1.19 linux/drivers/acorn/scsi/ecoscsi.c - 1.7 linux/drivers/acorn/char/keyb_ps2.c - 1.10 linux/drivers/acorn/block/mfmhd.c - 1.16 linux/arch/i386/kernel/setup.c - 1.58 linux/arch/i386/kernel/mtrr.c - 1.31 linux/arch/i386/kernel/irq.c - 1.37 linux/arch/i386/kernel/io_apic.c - 1.31 linux/arch/i386/defconfig - 1.78 linux/arch/arm/mm/proc-sa110.S - 1.22 linux/arch/arm/mm/fault-armv.c - 1.19 linux/arch/arm/lib/io-acorn.S - 1.7 linux/arch/arm/lib/backtrace.S - 1.7 linux/arch/arm/kernel/entry-armv.S - 1.22 linux/arch/arm/kernel/Makefile - 1.19 linux/arch/arm/config.in - 1.28 linux/arch/alpha/kernel/osf_sys.c - 1.26 linux/Makefile - 1.145 linux/MAINTAINERS - 1.80 linux/Documentation/filesystems/vfat.txt - 1.6 linux/Documentation/Configure.help - 1.111 linux/drivers/video/cyber2000fb.c - 1.27 linux/drivers/sbus/char/aurora.c - 1.15 linux/drivers/isdn/hisax/md5sums.asc - 1.15 linux/drivers/block/cpqarray.c - 1.31 linux/drivers/parport/parport_pc.c - 1.41 linux/drivers/parport/ieee1284_ops.c - 1.14 linux/drivers/parport/ieee1284.c - 1.12 linux/drivers/scsi/sun3x_esp.c - 1.5 linux/drivers/scsi/oktagon_esp.c - 1.6 linux/drivers/char/ip2main.c - 1.13 linux/drivers/char/ip2/ip2.h - 1.3 linux/drivers/char/ip2/i2lib.c - 1.5 linux/drivers/char/ip2/i2ellis.h - 1.4 linux/drivers/char/ip2/i2ellis.c - 1.4 linux/drivers/char/ip2/i2cmd.c - 1.4 linux/drivers/char/ip2.c - 1.7 linux/drivers/char/README.computone - 1.5 linux/drivers/atm/nicstar.h - 1.6 linux/drivers/atm/atmdev_init.c - 1.8 linux/drivers/atm/Makefile - 1.14 linux/drivers/atm/Config.in - 1.10 linux/Documentation/computone.txt - 1.6 linux/drivers/block/DAC960.c - 1.38 linux/drivers/char/applicom.c - 1.11 linux/drivers/pcmcia/ds.c - 1.16 linux/drivers/pcmcia/Makefile - 1.11 linux/drivers/pcmcia/Config.in - 1.9 linux/include/linux/pci_ids.h - 1.50 linux/arch/arm/kernel/debug-armv.S - 1.10 linux/include/asm-arm/proc-armv/cache.h - 1.9 linux/include/asm-arm/arch-sa1100/system.h - 1.13 linux/include/asm-arm/arch-sa1100/keyboard.h - 1.7 linux/include/asm-arm/arch-sa1100/hardware.h - 1.10 linux/drivers/scsi/sun3_scsi.c - 1.8 linux/drivers/pci/pci.ids - 1.36 linux/include/asm-arm/arch-cl7500/keyboard.h - 1.2 linux/drivers/sound/trident.c - 1.28 linux/drivers/scsi/scsi_merge.c - 1.30 linux/drivers/sbus/char/jsflash.c - 1.12 linux/fs/cramfs/uncompress.c - 1.5 linux/fs/cramfs/inode.c - 1.18 linux/fs/cramfs/inflate/zutil.h - 1.3 linux/fs/cramfs/inflate/zlib.h - 1.3 linux/fs/cramfs/inflate/zconf.h - 1.3 linux/fs/cramfs/inflate/uncompr.c - 1.3 linux/fs/cramfs/inflate/infutil.h - 1.3 linux/fs/cramfs/inflate/infutil.c - 1.3 linux/fs/cramfs/inflate/inftrees.h - 1.3 linux/fs/cramfs/inflate/inftrees.c - 1.3 linux/fs/cramfs/inflate/inflate.c - 1.4 linux/fs/cramfs/inflate/inffixed.h - 1.2 linux/fs/cramfs/inflate/inffast.h - 1.3 linux/fs/cramfs/inflate/inffast.c - 1.4 linux/fs/cramfs/inflate/infcodes.h - 1.3 linux/fs/cramfs/inflate/infcodes.c - 1.4 linux/fs/cramfs/inflate/infblock.h - 1.3 linux/fs/cramfs/inflate/infblock.c - 1.4 linux/fs/cramfs/inflate/adler32.c - 1.3 linux/fs/cramfs/inflate/Makefile - 1.4 linux/fs/cramfs/Makefile - 1.4 linux/drivers/telephony/ixj.c - 1.20 linux/drivers/char/moxa.c - 1.9 linux/drivers/char/mxser.c - 1.12 linux/include/asm-m68k/pgalloc.h - 1.6 linux/drivers/usb/usb-ohci.h - 1.14 linux/drivers/usb/usb-uhci-debug.h - 1.5 linux/drivers/scsi/sun3_NCR5380.c - 1.3 linux/include/linux/lvm.h - 1.11 linux/Documentation/networking/8139too.txt - 1.14 linux/include/asm-mips64/floppy.h - 1.4 linux/include/asm-arm/arch-nexuspci/keyboard.h - 1.2 linux/drivers/parport/ChangeLog - 1.21 linux/drivers/ide/q40ide.c - 1.4 linux/drivers/ide/piix.c - 1.13 linux/drivers/ide/pdc202xx.c - 1.11 linux/drivers/ide/ide.c - 1.34 linux/drivers/ide/ide-pci.c - 1.18 linux/drivers/ide/ide-cd.c - 1.19 linux/drivers/ide/icside.c - 1.9 linux/drivers/ide/falconide.c - 1.4 linux/drivers/ide/buddha.c - 1.8 linux/Documentation/DocBook/Makefile - 1.20 linux/drivers/net/pcmcia/xircom_tulip_cb.c - 1.17 linux/drivers/sound/dmasound/dmasound_q40.c - 1.6 linux/drivers/sound/dmasound/dmasound_paula.c - 1.6 linux/drivers/sound/dmasound/dmasound_core.c - 1.8 linux/drivers/sound/dmasound/dmasound_awacs.c - 1.9 linux/drivers/sound/dmasound/dmasound_atari.c - 1.7 linux/Documentation/DocBook/parportbook.tmpl - 1.7 linux/include/asm-arm/arch-shark/uncompress.h - 1.3 linux/include/asm-arm/arch-shark/timex.h - 1.3 linux/include/asm-arm/arch-shark/time.h - 1.6 linux/include/asm-arm/arch-shark/system.h - 1.5 linux/include/asm-arm/arch-shark/param.h - 1.3 linux/include/asm-arm/arch-shark/memory.h - 1.5 linux/include/asm-arm/arch-shark/keyboard.h - 1.5 linux/include/asm-arm/arch-shark/irqs.h - 1.3 linux/include/asm-arm/arch-shark/irq.h - 1.3 linux/include/asm-arm/arch-shark/io.h - 1.6 linux/fs/ramfs/inode.c - 1.14 linux/drivers/video/sa1100fb.c - 1.10 linux/include/asm-arm/arch-shark/dma.h - 1.4 linux/include/asm-arm/arch-shark/ide.h - 1.4 linux/include/asm-arm/arch-shark/hardware.h - 1.5 linux/drivers/sound/i810_audio.c - 1.17 linux/drivers/sound/emu10k1/hwaccess.h - 1.6 linux/drivers/char/rio/rio_linux.c - 1.11 linux/arch/arm/def-configs/lart - 1.5 linux/drivers/s390/block/dasd.c - 1.16 linux/Documentation/arm/SA1100/Assabet - 1.4 linux/arch/arm/def-configs/assabet - 1.6 linux/arch/arm/def-configs/graphicsclient - 1.5 linux/include/asm-arm/arch-l7200/param.h - 1.2 linux/kdb/modules/kdbm_pg.c - 1.42 linux/drivers/char/joystick/analog.c - 1.7 linux/drivers/acpi/tables/tbxface.c - 1.7 linux/drivers/acpi/tables/tbutils.c - 1.7 linux/drivers/acpi/tables/tbinstal.c - 1.7 linux/drivers/acpi/tables/tbget.c - 1.7 linux/drivers/acpi/resources/rsxface.c - 1.7 linux/drivers/acpi/resources/rsutils.c - 1.7 linux/drivers/acpi/parser/psxface.c - 1.7 linux/drivers/acpi/parser/pswalk.c - 1.7 linux/drivers/acpi/parser/psutils.c - 1.7 linux/drivers/acpi/parser/pstree.c - 1.7 linux/drivers/acpi/parser/psscope.c - 1.7 linux/drivers/acpi/parser/psparse.c - 1.8 linux/drivers/acpi/parser/psopcode.c - 1.7 linux/drivers/acpi/parser/psargs.c - 1.8 linux/drivers/acpi/os.c - 1.9 linux/drivers/acpi/namespace/nsxfobj.c - 1.10 linux/drivers/acpi/namespace/nsxfname.c - 1.7 linux/drivers/acpi/namespace/nswalk.c - 1.6 linux/drivers/acpi/namespace/nsutils.c - 1.7 linux/drivers/acpi/namespace/nssearch.c - 1.8 linux/drivers/acpi/namespace/nsobject.c - 1.7 linux/drivers/acpi/namespace/nsnames.c - 1.8 linux/drivers/acpi/namespace/nsload.c - 1.7 linux/drivers/acpi/namespace/nseval.c - 1.8 linux/drivers/acpi/namespace/nsalloc.c - 1.7 linux/drivers/acpi/namespace/nsaccess.c - 1.8 linux/drivers/acpi/include/amlcode.h - 1.7 linux/drivers/acpi/include/actypes.h - 1.9 linux/drivers/acpi/include/actables.h - 1.7 linux/drivers/acpi/include/acpixf.h - 1.8 linux/drivers/acpi/include/acobject.h - 1.7 linux/drivers/acpi/hardware/hwregs.c - 1.8 linux/drivers/acpi/hardware/hwgpe.c - 1.7 linux/drivers/acpi/hardware/hwacpi.c - 1.8 linux/drivers/acpi/events/evxfregn.c - 1.8 linux/drivers/acpi/events/evxfevnt.c - 1.7 linux/drivers/acpi/events/evxface.c - 1.7 linux/drivers/acpi/events/evrgnini.c - 1.7 linux/drivers/acpi/events/evregion.c - 1.9 linux/drivers/acpi/events/evmisc.c - 1.7 linux/drivers/acpi/events/evevent.c - 1.9 linux/drivers/acpi/driver.h - 1.6 linux/drivers/acpi/driver.c - 1.12 linux/drivers/acpi/dispatcher/dswstate.c - 1.8 linux/drivers/acpi/dispatcher/dswscope.c - 1.7 linux/drivers/acpi/dispatcher/dswload.c - 1.7 linux/drivers/acpi/dispatcher/dswexec.c - 1.7 linux/drivers/acpi/dispatcher/dsutils.c - 1.7 linux/drivers/acpi/dispatcher/dsopcode.c - 1.8 linux/drivers/acpi/dispatcher/dsobject.c - 1.8 linux/drivers/acpi/dispatcher/dsmethod.c - 1.7 linux/drivers/acpi/dispatcher/dsfield.c - 1.6 linux/drivers/acpi/Makefile - 1.10 linux/include/asm-arm/arch-sa1100/bitfield.h - 1.2 linux/include/asm-arm/arch-sa1100/assabet.h - 1.6 linux/include/asm-arm/arch-sa1100/SA-1111.h - 1.5 linux/include/asm-arm/arch-sa1100/SA-1100.h - 1.5 linux/drivers/mtd/ftl.c - 1.10 linux/drivers/mtd/mtdblock.c - 1.9 linux/include/asm-arm/arch-sa1100/cerf.h - 1.3 linux/drivers/net/natsemi.c - 1.15 linux/drivers/media/video/planb.c - 1.9 linux/drivers/media/video/cpia_usb.c - 1.7 linux/drivers/media/video/cpia_pp.c - 1.3 linux/drivers/media/video/cpia.h - 1.3 linux/drivers/media/video/cpia.c - 1.7 linux/arch/arm/tools/mach-types - 1.10 linux/drivers/md/lvm.c - 1.22 linux/drivers/md/raid5.c - 1.21 linux/arch/arm/def-configs/cerf - 1.3 linux/arch/arm/def-configs/shark - 1.3 linux/arch/arm/mach-sa1100/Makefile - 1.6 linux/arch/arm/mach-sa1100/leds.c - 1.4 linux/arch/arm/mach-shark/dma.c - 1.3 linux/arch/arm/mach-shark/mm.c - 1.3 linux/arch/arm/mm/proc-arm920.S - 1.5 linux/drivers/acpi/include/acconfig.h - 1.8 linux/drivers/acpi/include/acdebug.h - 1.7 linux/drivers/acpi/include/acdispat.h - 1.6 linux/drivers/acpi/include/acevents.h - 1.7 linux/drivers/acpi/include/acglobal.h - 1.6 linux/drivers/acpi/include/achware.h - 1.6 linux/drivers/acpi/include/acinterp.h - 1.7 linux/drivers/acpi/include/aclocal.h - 1.8 linux/drivers/acpi/include/acmacros.h - 1.7 linux/drivers/acpi/include/acnamesp.h - 1.8 linux/drivers/acpi/include/acparser.h - 1.5 linux/drivers/acpi/include/actbl.h - 1.6 linux/drivers/acpi/namespace/nsdump.c - 1.4 linux/drivers/block/cciss.c - 1.18 linux/drivers/md/Makefile - 1.6 linux/drivers/md/lvm-snap.c - 1.7 linux/drivers/md/md.c - 1.30 linux/drivers/scsi/cpqfc.Readme - 1.5 linux/drivers/scsi/cpqfcTScontrol.c - 1.6 linux/drivers/scsi/cpqfcTSinit.c - 1.12 linux/drivers/scsi/cpqfcTSioctl.h - 1.2 linux/drivers/scsi/cpqfcTSstructs.h - 1.5 linux/drivers/scsi/cpqfcTSworker.c - 1.7 linux/include/asm-arm/arch-tbox/keyboard.h - 1.2 linux/drivers/video/sis/sis_main.c - 1.7 linux/arch/arm/def-configs/neponset - 1.3 linux/arch/arm/def-configs/pangolin - 1.3 linux/drivers/scsi/mvme147.c - 1.2 linux/drivers/acpi/tables/tbconvrt.c - 1.6 linux/drivers/acpi/tables/tbxfroot.c - 1.5 linux/drivers/acpi/namespace/nsinit.c - 1.7 linux/drivers/acpi/include/actbl71.h - 1.5 linux/drivers/acpi/include/actbl2.h - 1.5 linux/drivers/acpi/include/actbl1.h - 1.4 linux/mm/shmem.c - 1.20 linux/drivers/acpi/acpi_ksyms.c - 1.5 linux/drivers/acpi/hardware/hwsleep.c - 1.5 linux/drivers/acpi/hardware/hwtimer.c - 1.5 linux/drivers/s390/char/tapeblock.c - 1.4 linux/drivers/s390/block/xpram.c - 1.7 linux/include/asm-arm/arch-sa1100/graphicsclient.h - 1.2 linux/include/asm-arm/arch-integrator/keyboard.h - 1.2 linux/drivers/scsi/aic7xxx/cam.h - 1.3 linux/drivers/scsi/aic7xxx/aicasm/aicasm_symbol.h - 1.2 linux/drivers/scsi/aic7xxx/aicasm/aicasm_symbol.c - 1.4 linux/drivers/scsi/aic7xxx/aicasm/aicasm_scan.l - 1.3 linux/drivers/scsi/aic7xxx/aicasm/aicasm_insformat.h - 1.2 linux/drivers/scsi/aic7xxx/aicasm/aicasm_gram.y - 1.3 linux/drivers/scsi/aic7xxx/aicasm/aicasm.h - 1.3 linux/drivers/scsi/aic7xxx/aicasm/aicasm.c - 1.3 linux/drivers/scsi/aic7xxx/aicasm/Makefile - 1.3 linux/drivers/scsi/aic7xxx/aic7xxx_seq.h - 1.5 linux/drivers/scsi/aic7xxx/aic7xxx_reg.h - 1.5 linux/drivers/scsi/aic7xxx/aic7xxx_proc.c - 1.4 linux/drivers/scsi/aic7xxx/aic7xxx_pci.c - 1.4 linux/drivers/scsi/aic7xxx/aic7xxx_osm.h - 1.6 linux/drivers/scsi/aic7xxx/aic7xxx_linux_pci.c - 1.5 linux/drivers/scsi/aic7xxx/aic7xxx_linux_host.h - 1.3 linux/drivers/scsi/aic7xxx/aic7xxx_linux.c - 1.7 linux/drivers/scsi/aic7xxx/aic7xxx_inline.h - 1.4 linux/drivers/scsi/aic7xxx/aic7xxx_93cx6.h - 1.2 linux/drivers/scsi/aic7xxx/aic7xxx_93cx6.c - 1.3 linux/drivers/scsi/aic7xxx/aic7xxx.h - 1.4 linux/drivers/scsi/aic7xxx/aic7xxx.c - 1.6 linux/drivers/scsi/aic7xxx/aic7770_linux.c - 1.4 linux/drivers/scsi/aic7xxx/aic7770.c - 1.4 linux/arch/arm/mach-sa1100/dma-sa1100.c - 1.4 linux/arch/arm/mach-sa1100/dma-sa1111.c - 1.4 linux/include/asm-arm/hardware/ep7212.h - 1.2 linux/arch/arm/mach-shark/leds.c - 1.2 linux/drivers/net/wireless/hermes.h - 1.7 linux/include/asm-m68k/raw_io.h - 1.2 linux/include/asm-m68k/mc146818rtc.h - 1.2 linux/include/asm-m68k/sun3xflop.h - 1.2 linux/include/asm-m68k/zorro.h - 1.2 linux/drivers/mtd/nftlcore.c - 1.7 linux/drivers/mtd/mtdblock_ro.c - 1.5 linux/drivers/mtd/chips/cfi_cmdset_0002.c - 1.3 linux/drivers/acpi/executer/exstore.c - 1.3 linux/drivers/acpi/ospm/ec/ec_osl.c - 1.4 linux/drivers/acpi/ospm/include/pr.h - 1.3 linux/drivers/acpi/ospm/button/bn_osl.c - 1.4 linux/drivers/acpi/utilities/utxface.c - 1.3 linux/drivers/acpi/utilities/utobject.c - 1.3 linux/drivers/acpi/utilities/utmisc.c - 1.3 linux/drivers/acpi/utilities/utinit.c - 1.3 linux/drivers/acpi/utilities/utglobal.c - 1.3 linux/drivers/acpi/utilities/uteval.c - 1.3 linux/drivers/acpi/utilities/utdelete.c - 1.3 linux/drivers/acpi/utilities/utdebug.c - 1.3 linux/drivers/acpi/utilities/utcopy.c - 1.3 linux/drivers/acpi/utilities/utalloc.c - 1.3 linux/drivers/acpi/ospm/button/bn.c - 1.3 linux/drivers/acpi/ospm/busmgr/bmutils.c - 1.3 linux/drivers/acpi/ospm/thermal/tz.c - 1.3 linux/drivers/acpi/ospm/busmgr/bmpower.c - 1.3 linux/drivers/acpi/ospm/busmgr/bm_osl.c - 1.4 linux/drivers/acpi/ospm/busmgr/bm.c - 1.3 linux/drivers/acpi/ospm/battery/bt_osl.c - 1.4 linux/drivers/acpi/ospm/battery/bt.c - 1.3 linux/drivers/acpi/include/acstruct.h - 1.3 linux/drivers/acpi/ospm/system/sm_osl.c - 1.4 linux/drivers/acpi/ospm/thermal/tz_osl.c - 1.5 linux/drivers/acpi/ospm/thermal/tzpolicy.c - 1.3 linux/drivers/acpi/ospm/system/sm.c - 1.3 linux/drivers/acpi/ospm/include/bt.h - 1.3 linux/drivers/acpi/ospm/include/bn.h - 1.3 linux/drivers/acpi/include/acutils.h - 1.3 linux/drivers/acpi/include/platform/acenv.h - 1.3 linux/drivers/acpi/include/platform/acgcc.h - 1.5 linux/drivers/acpi/include/platform/aclinux.h - 1.2 linux/drivers/acpi/debugger/dbcmds.c - 1.3 linux/drivers/acpi/debugger/dbdisasm.c - 1.3 linux/drivers/acpi/debugger/dbdisply.c - 1.3 linux/drivers/acpi/debugger/dbfileio.c - 1.3 linux/drivers/acpi/debugger/dbinput.c - 1.3 linux/drivers/acpi/debugger/dbstats.c - 1.3 linux/drivers/acpi/debugger/dbutils.c - 1.3 linux/drivers/acpi/debugger/dbxface.c - 1.3 linux/drivers/acpi/ospm/processor/prpower.c - 1.3 linux/drivers/acpi/ospm/processor/prperf.c - 1.3 linux/drivers/acpi/ospm/processor/pr_osl.c - 1.4 linux/drivers/acpi/ospm/ac_adapter/ac_osl.c - 1.4 linux/drivers/acpi/ospm/processor/pr.c - 1.3 linux/drivers/acpi/ospm/ac_adapter/ac.c - 1.3 linux/drivers/acpi/executer/exxface.c - 1.3 linux/drivers/acpi/executer/exutils.c - 1.3 linux/drivers/acpi/ospm/ec/ecmain.c - 1.3 linux/drivers/acpi/ospm/include/tz.h - 1.3 linux/drivers/acpi/ospm/ec/ecspace.c - 1.3 linux/drivers/acpi/executer/exconfig.c - 1.3 linux/drivers/acpi/executer/exconvrt.c - 1.3 linux/drivers/acpi/executer/excreate.c - 1.3 linux/drivers/acpi/executer/exdump.c - 1.3 linux/drivers/acpi/executer/exdyadic.c - 1.3 linux/drivers/acpi/executer/exfldio.c - 1.3 linux/drivers/acpi/executer/exmisc.c - 1.3 linux/drivers/acpi/executer/exmonad.c - 1.3 linux/drivers/acpi/executer/exprep.c - 1.3 linux/drivers/acpi/executer/exregion.c - 1.3 linux/drivers/acpi/executer/exresnte.c - 1.3 linux/drivers/acpi/executer/exresolv.c - 1.3 linux/drivers/acpi/executer/exresop.c - 1.3 linux/drivers/media/video/meye.c - 1.4 linux/drivers/video/aty/mach64_cursor.c - 1.2 linux/drivers/sound/rme96xx.c - 1.3 linux/drivers/video/sa1100fb.h - 1.2 linux/include/asm-arm/arch-sa1100/simpad.h - 1.2 linux/arch/arm/def-configs/bitsy - 1.2 linux/arch/arm/def-configs/h3600 - 1.2 linux/arch/arm/mach-sa1100/simpad.c - 1.2 linux/include/asm-arm/arch-anakin/keyboard.h - 1.2 linux/arch/arm/mach-sa1100/neponset.c - 1.3 linux/arch/arm/mach-sa1100/leds.h - 1.3 linux/arch/arm/mach-sa1100/leds-simpad.c - 1.2 linux/arch/arm/mach-sa1100/leds-cerf.c - 1.2 linux/arch/arm/mach-sa1100/leds-assabet.c - 1.2 linux/arch/arm/mach-sa1100/graphicsclient.c - 1.3 linux/arch/arm/mach-sa1100/assabet.c - 1.3 linux/arch/arm/mach-sa1100/cerf.c - 1.2 linux/arch/arm/mach-sa1100/freebird.c - 1.2 linux/drivers/video/radeonfb.c - 1.4 linux/drivers/video/radeon.h - 1.3 linux/drivers/sound/nec_vrc5477.c - 1.3 linux/drivers/sound/ite8172.c - 1.3 linux/drivers/isdn/hisax/st5481_d.c - 1.3 linux/drivers/isdn/hisax/st5481_usb.c - 1.3 linux/fs/jffs2/background.c - 1.3 linux/drivers/ide/ataraid.c - 1.3 linux/drivers/md/Makefile.in - 1.2 linux/drivers/pcmcia/sa1100_generic.c - 1.2 linux/drivers/pcmcia/sa1100_cerf.c - 1.2 linux/drivers/pcmcia/sa1100_assabet.c - 1.2 linux/drivers/pcmcia/sa1100_neponset.c - 1.2 linux/drivers/pcmcia/sa1100_simpad.c - 1.2 linux/drivers/pcmcia/sa1100_stork.c - 1.2 linux/arch/arm/mach-sa1100/h3600.c - 1.2 linux/arch/arm/mach-sa1100/graphicsmaster.c - 1.2 linux/drivers/message/i2o/i2o_proc.c - 1.3 linux/drivers/message/i2o/i2o_pci.c - 1.4 linux/drivers/message/i2o/i2o_block.c - 1.3 linux/drivers/net/8139cp.c - 1.2 From owner-linux-xfs@oss.sgi.com Sat Oct 27 16:42:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9RNgoo11037 for linux-xfs-outgoing; Sat, 27 Oct 2001 16:42:50 -0700 Received: from femail48.sdc1.sfba.home.com (femail48.sdc1.sfba.home.com [24.254.60.42]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9RNgj011013 for ; Sat, 27 Oct 2001 16:42:45 -0700 Received: from there ([65.4.56.167]) by femail48.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20011027234239.VKNQ5793.femail48.sdc1.sfba.home.com@there> for ; Sat, 27 Oct 2001 16:42:39 -0700 Content-Type: text/plain; charset="iso-8859-15" From: Micah Yoder To: linux-xfs@oss.sgi.com Subject: Upgrading kernel, Compile error in module Date: Sat, 27 Oct 2001 16:42:51 -0400 X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011027234239.VKNQ5793.femail48.sdc1.sfba.home.com@there> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi again. Decided it was finally time to upgrade my 2.4.6pre2-xfs, which has been working great, for security and VM fixes. Just grabbed latest CVS an hour or two ago (2.4.14pre3). Thing that makes me nervous is that there was a minor compile error in gvim ./drivers/block/paride/pcd.c: static struct block_device_operations pcd_bdops = { owner: THIS_MODULE, open: cdrom_open, release: cdrom_release, ioctl: cdrom_ioctl, check_media_change: cdrom_media_changed, } /* line 274 */ static struct cdrom_device_ops pcd_dops = { pcd_open, pcd_release, [...] Note the lack of a semicolon on 274!!! I added it and now it compiles. Dunno if that booboo was inherited from Linus or from one of you, but you might want to fix it. :-) So that's fixed, but the fact that it was there worries me some! What other nasties besides compile errors could be in there? Also I'm a bit amused that the sizes of bzImage and vmlinuz are SMALLER than with my previous kernel. I configured this with make oldconfig and answered N (default) to all new features. Was a bit tempted by XFS_QUOTA but decided to pass on it for now. Think it's "safe" to put this thing on a production server? Again, my "problem" is that it's co-located, 500 miles away, so a mistake could be costly... but if it works for most people I'm willing to try it. Thanks, Micah -- Like to travel? http://TravTalk.org Micah Yoder Internet Development http://yoderdev.com From owner-linux-xfs@oss.sgi.com Sun Oct 28 06:19:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9SEJ7U28357 for linux-xfs-outgoing; Sun, 28 Oct 2001 06:19:07 -0800 Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9SEJ3028334 for ; Sun, 28 Oct 2001 06:19:03 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9SEJ0FC042010; Sun, 28 Oct 2001 15:19:00 +0100 (CET) Message-Id: <4.3.2.7.2.20011028151645.0389dc68@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 28 Oct 2001 15:17:22 +0100 To: Simon Matter , linux-xfs From: Seth Mos Subject: Re: RedHat 7.2 has 2.4.9 Kernel as update In-Reply-To: <3BD40587.BAF4A871@ch.sauter-bc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 13:39 22-10-2001 +0200, Simon Matter wrote: >I just found the RedHat 7.2 updates and they include 2.4.9 like with >RedHat 7.1. Interesting to see a distro where you can download updates >before the product is available. Windows 2000 was released the exact same way. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Sun Oct 28 06:53:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9SErcT28806 for linux-xfs-outgoing; Sun, 28 Oct 2001 06:53:38 -0800 Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9SErZ028783 for ; Sun, 28 Oct 2001 06:53:35 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9SErXkN010633 for ; Sun, 28 Oct 2001 15:53:33 +0100 (CET) Message-Id: <4.3.2.7.2.20011028155036.038993e0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 28 Oct 2001 15:51:54 +0100 To: linux-xfs@oss.sgi.com From: Seth Mos Subject: FAQ update Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Included explanation for redhat installer disks releases. In short: Be patient while SGI and some others are working on this. Cheers ps. I could have seen this coming before going on vacation. -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Sun Oct 28 07:16:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9SFGE329334 for linux-xfs-outgoing; Sun, 28 Oct 2001 07:16:14 -0800 Received: from linux.nameip.net ([211.187.6.46]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9SFGB029312 for ; Sun, 28 Oct 2001 07:16:11 -0800 Received: (qmail 5028 invoked from network); 28 Oct 2001 15:21:34 -0000 Received: from unknown (HELO orgio.net) (211.187.6.46) by 0 with SMTP; 28 Oct 2001 15:21:34 -0000 Message-ID: <3BDC227D.5010509@orgio.net> Date: Mon, 29 Oct 2001 00:21:33 +0900 From: Seung-young Oh User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011013 X-Accept-Language: ko MIME-Version: 1.0 To: linux-xfs Subject: Using xfs_repair for a root filesystem? Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, If my root filesystem is damaged somehow and I'm asked to unmount the root partition & use xfs_repair, how do I go about it? I've read through some docs on the SGI XFS website, and couldn't locate the answer for it. Am I screwed in this case? I'd appreciate any input. Thank you. -- ICQ#: 103231199 From owner-linux-xfs@oss.sgi.com Sun Oct 28 07:17:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9SFHR129383 for linux-xfs-outgoing; Sun, 28 Oct 2001 07:17:27 -0800 Received: from mta1-rme.xtra.co.nz (mta1-rme.xtra.co.nz [210.86.15.129]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9SFHN029358 for ; Sun, 28 Oct 2001 07:17:24 -0800 Received: from mdew ([210.54.114.44]) by mta1-rme.xtra.co.nz with ESMTP id <20011028151717.SDLM2333.mta1-rme.xtra.co.nz@mdew>; Mon, 29 Oct 2001 04:17:17 +1300 Subject: Re: FAQ update From: mdew To: Seth Mos Cc: xfs In-Reply-To: <4.3.2.7.2.20011028155036.038993e0@pop.xs4all.nl> References: <4.3.2.7.2.20011028155036.038993e0@pop.xs4all.nl> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 29 Oct 2001 15:29:51 +1300 Message-Id: <1004322591.839.12.camel@mdew> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2001-10-29 at 03:51, Seth Mos wrote: > Included explanation for redhat installer disks releases. > > In short: Be patient while SGI and some others are working on this. > > Cheers > ps. I could have seen this coming before going on vacation. > -- > Seth > Every program has two purposes one for which > it was written and another for which it wasn't > I use the last kind. > just a small question regarding XFS and daily rpm updates..is it _really_ needed? it would be easier to say maintain rpms for major releases i.e major kernel releases or major XFS changes, rather manage an entire daily rpm tree aswell... ? From owner-linux-xfs@oss.sgi.com Sun Oct 28 07:29:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9SFTxB29713 for linux-xfs-outgoing; Sun, 28 Oct 2001 07:29:59 -0800 Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9SFTt029691 for ; Sun, 28 Oct 2001 07:29:55 -0800 Received: from walt400.localhost (user-uini6vm.dsl.mindspring.com [165.121.27.246]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id KAA11746 for ; Sun, 28 Oct 2001 10:29:54 -0500 (EST) Received: from there (localhost.localdomain [127.0.0.1]) by walt400.localhost (Postfix) with SMTP id 6CFD2816549; Sun, 28 Oct 2001 07:28:22 -0800 (PST) Content-Type: text/plain; charset="euc-kr" From: Walt H To: Seung-young Oh , linux-xfs Subject: Re: Using xfs_repair for a root filesystem? Date: Sun, 28 Oct 2001 07:28:22 -0800 X-Mailer: KMail [version 1.3.1] References: <3BDC227D.5010509@orgio.net> In-Reply-To: <3BDC227D.5010509@orgio.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011028152822.6CFD2816549@walt400.localhost> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Conceivably, you could boot up using some sort of rescue disk with an XFS enabled kernel and run xfs_repair from there. I use Timo's rescue kit which I customize with my own XFS aware kernel and the tools on it. It's based on Debian and has some good stuff on it. http://rescuecd.sourceforge.net If you've got the SGI installer for Redhat you could probably do it that way too. I don't use Redhat, so I'm not sure / unable to help out there. -Walt On Sunday 28 October 2001 07:21 am, Seung-young Oh wrote: > Hello, > If my root filesystem is damaged somehow and I'm asked to unmount the > root partition & use xfs_repair, how do I go about it? > I've read through some docs on the SGI XFS website, and couldn't locate > the answer for it. Am I screwed in this case? > I'd appreciate any input. Thank you. From owner-linux-xfs@oss.sgi.com Sun Oct 28 07:42:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9SFg9D30742 for linux-xfs-outgoing; Sun, 28 Oct 2001 07:42:09 -0800 Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9SFg4030717 for ; Sun, 28 Oct 2001 07:42:04 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9SFg0et025930; Sun, 28 Oct 2001 16:42:01 +0100 (CET) Message-Id: <4.3.2.7.2.20011028163933.035229f0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 28 Oct 2001 16:40:18 +0100 To: Marc Schmitt , Steve Lord From: Seth Mos Subject: Re: Corruption of in-memory data detected. Cc: Eric Sandeen , linux-xfs@oss.sgi.com, florin@sgi.com In-Reply-To: <3BD800FC.6020005@inf.ethz.ch> References: <200110242032.f9OKWPk32359@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 14:09 25-10-2001 +0200, Marc Schmitt wrote: >Steve Lord wrote: > >>Yes, but the detection process may need some work - ext2 will probably >>have radically different behavior on an error. It may throw up on the >>filesystem, or you may have to run fsck afterwards to see what happened >>to the fs. > > >Hmm, using mke2fs 1.25 (with m set to 1), mongo runs a complete benchmark >over the 1.2TB: >Filesystem 1k-blocks Used Available Use% Mounted on >/dev/md0 1135510828 20 1123788584 1% /local > >After unmounting, I ran e2fsck:e2fsck 1.25 (20-Sep-2001) >/dev/md0: clean, 11/293076992 files, 9177898/293055600 blocks you may need to force the the fsck. In this case it is probably only checking if it was cleanly unmounted or not. >Same steps as above with the current version of e2fsprogs on a RedHat 7.1 >system showed no different result (e2fsck 1.23, 15-Aug-2001 for EXT2 FS >0.5b, 95/08/09) > > >Greetz > Marc > > -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Sun Oct 28 08:04:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9SG4Gu31234 for linux-xfs-outgoing; Sun, 28 Oct 2001 08:04:16 -0800 Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9SG4C031212 for ; Sun, 28 Oct 2001 08:04:12 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9SG40L3018482; Sun, 28 Oct 2001 17:04:00 +0100 (CET) Message-Id: <4.3.2.7.2.20011028170126.03458240@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 28 Oct 2001 17:02:17 +0100 To: "Martin K. Petersen" , Jonathan Dill From: Seth Mos Subject: Re: Corruption of in-memory data detected. Cc: Steve Lord , Marc Schmitt , Eric Sandeen , linux-xfs@oss.sgi.com, florin@sgi.com In-Reply-To: References: <3BD87EC3.4A1E938B@umbi.umd.edu> <200110241510.f9OFAR707303@jen.americas.sgi.com> <3BD87EC3.4A1E938B@umbi.umd.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 17:13 25-10-2001 -0400, Martin K. Petersen wrote: > >>>>> "Jonathan" == Jonathan Dill writes: > >Jonathan> FWIW, I discovered that the Filesize limit problem that I >Jonathan> was having is due to a bug in tcsh--From tcsh, even though >Jonathan> the filesize limit is set to "unlimited" I cannot create a >Jonathan> file > 2 GB. I was able to reproduce this problem by >Jonathan> several different methods. From bash, I can create files > >Jonathan> 2 GB with no problems. > >Ayup. We've seen this a few times. tcsh is incorrectly compiled (no >largefile flags). > >Perhaps we should add this to the FAQ? It's in there under largefile support. Mail read up to thursday. 4 more days to go. -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Sun Oct 28 08:35:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9SGZfK31735 for linux-xfs-outgoing; Sun, 28 Oct 2001 08:35:41 -0800 Received: from merlin.giref.ulaval.ca (postfix@merlin.giref.ulaval.ca [132.203.7.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9SGZc031713 for ; Sun, 28 Oct 2001 08:35:38 -0800 Received: from merlin.giref.ulaval.ca (merlin.giref.ulaval.ca [132.203.7.100]) by merlin.giref.ulaval.ca (Postfix) with ESMTP id C50DB23DB8 for ; Sun, 28 Oct 2001 11:35:37 -0500 (EST) Date: Sun, 28 Oct 2001 11:35:37 -0500 (EST) From: Luc Lalonde To: Subject: Postfix MTS and XFS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello Folks, I've been quite happy with XFS on this Suse 7.1 system. I've got 2.4.7-xfs installed with egcs-2.91.66 and it is rock solid (100 days uptime). I'm about to switch my /var and / partitions from ReiserFS to XFS. Before I do so, has anyone else used the combination of Postfix and XFS? I was reading that there might be some locking issues. Cheers. Luc Lalonde, Responsable du reseau GIREF Telephone: (418) 656-2131 poste 6623 Courriel: llalonde@giref.ulaval.ca From owner-linux-xfs@oss.sgi.com Sun Oct 28 08:40:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9SGeUx31877 for linux-xfs-outgoing; Sun, 28 Oct 2001 08:40:30 -0800 Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9SGeQ031855 for ; Sun, 28 Oct 2001 08:40:26 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9SGeO8F032844; Sun, 28 Oct 2001 17:40:24 +0100 (CET) Message-Id: <4.3.2.7.2.20011028173346.0388b758@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 28 Oct 2001 17:38:39 +0100 To: mdew From: Seth Mos Subject: Re: FAQ update Cc: xfs In-Reply-To: <1004322591.839.12.camel@mdew> References: <4.3.2.7.2.20011028155036.038993e0@pop.xs4all.nl> <4.3.2.7.2.20011028155036.038993e0@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 15:29 29-10-2001 +1300, mdew wrote: >On Mon, 2001-10-29 at 03:51, Seth Mos wrote: > > Included explanation for redhat installer disks releases. > > > > In short: Be patient while SGI and some others are working on this. > >just a small question regarding XFS and daily rpm updates..is it >_really_ needed? I missed the part about the daily RPMS bit. This was about the installer disks for redhat. >it would be easier to say maintain rpms for major releases i.e major >kernel releases or major XFS changes, rather manage an entire daily rpm >tree aswell... ? That is what this is about. RPMS are made for security updates, and releases. Note that a RedHat release does not imply a new SGI installer release. It is more done out of the sheer demand for it. The daily RPMS are provided by people other then SGI and are considering making weekly RPMS instead. Even bi-weekly would catch most linus kernel releases. -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Sun Oct 28 08:41:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9SGfhh31927 for linux-xfs-outgoing; Sun, 28 Oct 2001 08:41:43 -0800 Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9SGfd031905 for ; Sun, 28 Oct 2001 08:41:40 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9SGfYEc022780; Sun, 28 Oct 2001 17:41:34 +0100 (CET) Message-Id: <4.3.2.7.2.20011028173852.03884798@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 28 Oct 2001 17:39:49 +0100 To: Seung-young Oh , linux-xfs From: Seth Mos Subject: Re: Using xfs_repair for a root filesystem? In-Reply-To: <3BDC227D.5010509@orgio.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 00:21 29-10-2001 +0900, Seung-young Oh wrote: >Hello, >If my root filesystem is damaged somehow and I'm asked to unmount the >root partition & use xfs_repair, how do I go about it? >I've read through some docs on the SGI XFS website, and couldn't locate >the answer for it. Am I screwed in this case? >I'd appreciate any input. Thank you. Use the SGI XFS installer CD and boot with linux rescue. This will lead to a prompt so you can run xfs_repair on the fs. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Sun Oct 28 08:44:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9SGiV632151 for linux-xfs-outgoing; Sun, 28 Oct 2001 08:44:31 -0800 Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9SGiR032129 for ; Sun, 28 Oct 2001 08:44:28 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9SGiO8F033234; Sun, 28 Oct 2001 17:44:24 +0100 (CET) Message-Id: <4.3.2.7.2.20011028174044.038770e8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 28 Oct 2001 17:42:39 +0100 To: Luc Lalonde , From: Seth Mos Subject: Re: Postfix MTS and XFS In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 11:35 28-10-2001 -0500, Luc Lalonde wrote: >Hello Folks, > >I've been quite happy with XFS on this Suse 7.1 system. I've got >2.4.7-xfs installed with egcs-2.91.66 and it is rock solid (100 days >uptime). > >I'm about to switch my /var and / partitions from ReiserFS to XFS. Before >I do so, has anyone else used the combination of Postfix and XFS? I was >reading that there might be some locking issues. The locking that Postfix uses was asumed to be correct and should work. There is no final verdict on this though. I believe Postfix was patched for ReiserFS a while a go which also affected the XFS behaviour. -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Sun Oct 28 09:39:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9SHd0e00361 for linux-xfs-outgoing; Sun, 28 Oct 2001 09:39:00 -0800 Received: from burgers.bubbanfriends.org (IDENT:postfix@burgers.bubbanfriends.org [216.140.122.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9SHct000338 for ; Sun, 28 Oct 2001 09:38:56 -0800 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 03C01400E07; Sun, 28 Oct 2001 12:39:02 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 023872400216; Sun, 28 Oct 2001 12:39:01 -0500 (EST) Date: Sun, 28 Oct 2001 12:39:01 -0500 (EST) From: Mike Burger To: Luc Lalonde Cc: Subject: Re: Postfix MTS and XFS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm using XFS on my root, /var and /home partitions, and am using Postfix. I've had no problems with this combination, to date. On Sun, 28 Oct 2001, Luc Lalonde wrote: > Hello Folks, > > I've been quite happy with XFS on this Suse 7.1 system. I've got > 2.4.7-xfs installed with egcs-2.91.66 and it is rock solid (100 days > uptime). > > I'm about to switch my /var and / partitions from ReiserFS to XFS. Before > I do so, has anyone else used the combination of Postfix and XFS? I was > reading that there might be some locking issues. > > Cheers. > > Luc Lalonde, Responsable du reseau GIREF > > Telephone: (418) 656-2131 poste 6623 > Courriel: llalonde@giref.ulaval.ca > > > > From owner-linux-xfs@oss.sgi.com Sun Oct 28 11:06:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9SJ6PI02414 for linux-xfs-outgoing; Sun, 28 Oct 2001 11:06:25 -0800 Received: from porsta.cs.Helsinki.FI (root@porsta.cs.Helsinki.FI [128.214.48.124]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9SJ6K002391 for ; Sun, 28 Oct 2001 11:06:20 -0800 Received: from melkki.cs.Helsinki.FI (sslwrap@localhost [127.0.0.1]) by porsta.cs.Helsinki.FI (8.11.6/8.11.6) with ESMTP id f9SJ6Hk15865 for ; Sun, 28 Oct 2001 21:06:17 +0200 Received: (from hhaataja@localhost) by melkki.cs.Helsinki.FI (8.11.6/8.11.2) id f9SJ6Bs26944 for linux-xfs@oss.sgi.com; Sun, 28 Oct 2001 21:06:11 +0200 Date: Sun, 28 Oct 2001 21:06:11 +0200 From: Harri Haataja Cc: xfs Subject: Re: FAQ update Message-ID: <20011028210611.A26342@cs.helsinki.fi> References: <4.3.2.7.2.20011028155036.038993e0@pop.xs4all.nl> <4.3.2.7.2.20011028155036.038993e0@pop.xs4all.nl> <1004322591.839.12.camel@mdew> <4.3.2.7.2.20011028173346.0388b758@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20011028173346.0388b758@pop.xs4all.nl>; from knuffie@xs4all.nl on Sun, Oct 28, 2001 at 05:38:39PM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Oct 28, 2001 at 05:38:39PM +0100, Seth Mos wrote: > At 15:29 29-10-2001 +1300, mdew wrote: > >On Mon, 2001-10-29 at 03:51, Seth Mos wrote: > > >it would be easier to say maintain rpms for major releases i.e major > >kernel releases or major XFS changes, rather manage an entire daily rpm > >tree aswell... ? > > That is what this is about. RPMS are made for security updates, and > releases. Note that a RedHat release does not imply a new SGI installer > release. It is more done out of the sheer demand for it. > > The daily RPMS are provided by people other then SGI and are considering > making weekly RPMS instead. Even bi-weekly would catch most linus kernel > releases. I haven't seen either, but I did recenly get new kernel rpms (2.4.9) from the testing dir in ftp. Now the 3d GL apps (for example gliv still works) all seem to not work. Is that an XF4.1 thing (something I heard, does RH7.2 have DRI?) or is the driver (Ati Rage Fury) broken? Was nice seeing ext3 included, though. I need that somewhere. And to stay remotely on-topic, I don't think daily rpms are quite needed unless you want to roll out CVS as rpms (for XFS part) but they stayed in 2.4.5 for ages (or were well-hidden). -- [Microsoft Vaccine 2000 is configuring your immune system. This may take a few minutes. If your body stops responding for a long time and there is no brain activity please die. Setup will continue after you are reborn.] -- Buzh From owner-linux-xfs@oss.sgi.com Sun Oct 28 11:08:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9SJ8lZ02501 for linux-xfs-outgoing; Sun, 28 Oct 2001 11:08:47 -0800 Received: from porsta.cs.Helsinki.FI (root@porsta.cs.Helsinki.FI [128.214.48.124]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9SJ8h002479 for ; Sun, 28 Oct 2001 11:08:43 -0800 Received: from melkki.cs.Helsinki.FI (sslwrap@localhost [127.0.0.1]) by porsta.cs.Helsinki.FI (8.11.6/8.11.6) with ESMTP id f9SJ8ek16172 for ; Sun, 28 Oct 2001 21:08:41 +0200 Received: (from hhaataja@localhost) by melkki.cs.Helsinki.FI (8.11.6/8.11.2) id f9SJ8YM27191 for linux-xfs@oss.sgi.com; Sun, 28 Oct 2001 21:08:34 +0200 Date: Sun, 28 Oct 2001 21:08:34 +0200 From: Harri Haataja Cc: linux-xfs@oss.sgi.com Subject: Re: Postfix MTS and XFS Message-ID: <20011028210834.B26342@cs.helsinki.fi> 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 mburger@bubbanfriends.org on Sun, Oct 28, 2001 at 12:39:01PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Oct 28, 2001 at 12:39:01PM -0500, Mike Burger wrote: > On Sun, 28 Oct 2001, Luc Lalonde wrote: > > > I've been quite happy with XFS on this Suse 7.1 system. I've got > > 2.4.7-xfs installed with egcs-2.91.66 and it is rock solid (100 days > > uptime). > > > > I'm about to switch my /var and / partitions from ReiserFS to XFS. Before > > I do so, has anyone else used the combination of Postfix and XFS? I was > > reading that there might be some locking issues. > > I'm using XFS on my root, /var and /home partitions, and am using Postfix. > > I've had no problems with this combination, to date. Me three, 2.4.5 (Release 1.0.1) has been very hapy on multitude of installations with postfix. Some of them even have actual mail traffic :-D -- The demon with arms and pincers, its form a true mockery of life, behind you, however, asks if you'd like to sit about upon its lap and look down at the pond whilst enjoying some tea. -- Randy The Random on a.s.r From owner-linux-xfs@oss.sgi.com Sun Oct 28 11:22:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9SJM2q03185 for linux-xfs-outgoing; Sun, 28 Oct 2001 11:22:02 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9SJLw003149 for ; Sun, 28 Oct 2001 11:21:58 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA22987 for ; Sun, 28 Oct 2001 11:21:52 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA3419756; Sun, 28 Oct 2001 13:20:41 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA57248; Sun, 28 Oct 2001 13:20:41 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9SJGKf24472; Sun, 28 Oct 2001 13:16:20 -0600 Message-Id: <200110281916.f9SJGKf24472@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Walt H cc: Seung-young Oh , linux-xfs Subject: Re: Using xfs_repair for a root filesystem? In-Reply-To: Message from Walt H of "Sun, 28 Oct 2001 07:28:22 PST." <20011028152822.6CFD2816549@walt400.localhost> Date: Sun, 28 Oct 2001 13:16:20 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk You can burn the Linuxcare bootable toolbox onto a cdrom - it has xfs support and is not too big to download. http://lbt.linuxcare.com >From this you can mount xfs filesystems, you should be able to run repair from it as well. Steve > Conceivably, you could boot up using some sort of rescue disk with an XFS > enabled kernel and run xfs_repair from there. I use Timo's rescue kit which I > > customize with my own XFS aware kernel and the tools on it. It's based on > Debian and has some good stuff on it. http://rescuecd.sourceforge.net > If you've got the SGI installer for Redhat you could probably do it that way > too. I don't use Redhat, so I'm not sure / unable to help out there. > > -Walt > > > On Sunday 28 October 2001 07:21 am, Seung-young Oh wrote: > > Hello, > > If my root filesystem is damaged somehow and I'm asked to unmount the > > root partition & use xfs_repair, how do I go about it? > > I've read through some docs on the SGI XFS website, and couldn't locate > > the answer for it. Am I screwed in this case? > > I'd appreciate any input. Thank you. From owner-linux-xfs@oss.sgi.com Sun Oct 28 11:22:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9SJMZe03242 for linux-xfs-outgoing; Sun, 28 Oct 2001 11:22:35 -0800 Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9SJMU003208 for ; Sun, 28 Oct 2001 11:22:30 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9SJMQ96074849; Sun, 28 Oct 2001 20:22:27 +0100 (CET) Message-Id: <4.3.2.7.2.20011028201200.02be38f0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 28 Oct 2001 20:20:36 +0100 To: Harri Haataja From: Seth Mos Subject: Re: FAQ update Cc: xfs In-Reply-To: <20011028210611.A26342@cs.helsinki.fi> References: <4.3.2.7.2.20011028173346.0388b758@pop.xs4all.nl> <4.3.2.7.2.20011028155036.038993e0@pop.xs4all.nl> <4.3.2.7.2.20011028155036.038993e0@pop.xs4all.nl> <1004322591.839.12.camel@mdew> <4.3.2.7.2.20011028173346.0388b758@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 21:06 28-10-2001 +0200, Harri Haataja wrote: >I haven't seen either, but I did recenly get new kernel rpms (2.4.9) >from the testing dir in ftp. Now the 3d GL apps (for example gliv still >works) all seem to not work. This probably has to do with the arrival of Xf 4.1 in 2.4.7 >Is that an XF4.1 thing (something I heard, does RH7.2 have DRI?) or is >the driver (Ati Rage Fury) broken? Nope it is selected at compile time for 4.0 or 4.1 Eric can you check if the new RPMS are compiled for 4.0.x since this would break backwards compatibility for people updating their configs. >Was nice seeing ext3 included, though. I need that somewhere. Compatibility reasons I asume. >And to stay remotely on-topic, I don't think daily rpms are quite needed >unless you want to roll out CVS as rpms (for XFS part) but they stayed >in 2.4.5 for ages (or were well-hidden). Because off the security updates that were released for 7.1 they are in the process of building and testing a new kernel which is released as a update for customers. On a side note to the other developers: How is IA64 coming along. SGI anounced their systems quite some time ago. Would it be feasible to combine 7.2 and ia64 and xfs? (smoking pot, I know) Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Sun Oct 28 11:41:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9SJfMr04221 for linux-xfs-outgoing; Sun, 28 Oct 2001 11:41:22 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9SJfH004199 for ; Sun, 28 Oct 2001 11:41:17 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA08628 for ; Sun, 28 Oct 2001 11:40:39 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA3430272; Sun, 28 Oct 2001 13:40:00 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA03300; Sun, 28 Oct 2001 13:40:00 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9SJZd224527; Sun, 28 Oct 2001 13:35:39 -0600 Message-Id: <200110281935.f9SJZd224527@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: drpmartin@home.com cc: linux-xfs@oss.sgi.com Subject: Re: Red Hat v7.2 ext3 Date: Sun, 28 Oct 2001 13:35:39 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > Red Hat is promoting v7.2 with what they call an ext3 journaling file > system. > I want to upgrade from v7.1 (we have the XFS enabled kernel working > now). > However, it is important to us to be able to mount IRIX SGI scsi disks > on > various Linux boxes, which we can now do. Are ext3 and XFS the same? And > > if not, do you know if the v7.2 kernel can create and mount XFS > filesystems > on whole disks and/or disk partitions? > > -- > Dr. Philip D. Martin > 2452 Crooks Rd., #52 > Troy, MI 48084 > Phone: (248)244-9339 > ext3 and xfs are different implementations of journalling filesystems. ext3 is ext2 with journalling added. You cannot just use redhat 7.2 to mount xfs filesystems, you will need one of the kernel rpms we have supplied on the oss ftp site - currently in the testing directory. If you want to look at irix disks then you need to build irix partition support into the kernel, I am not sure redhat does that by default. You will then be able to mount irix disks partitioned with fx. You will not be able to mount xlv or xvm volumes though. Steve p.s. please do not use html email when sending email to this list, it gets picked up by mail filters, which is why your original message was not sent out to the list. From owner-linux-xfs@oss.sgi.com Sun Oct 28 15:59:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9SNxmq13568 for linux-xfs-outgoing; Sun, 28 Oct 2001 15:59:48 -0800 Received: from femail40.sdc1.sfba.home.com (femail40.sdc1.sfba.home.com [24.254.60.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9SNxf013545 for ; Sun, 28 Oct 2001 15:59:46 -0800 Received: from there ([65.4.56.167]) by femail40.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20011028235930.UESD25699.femail40.sdc1.sfba.home.com@there> for ; Sun, 28 Oct 2001 15:59:30 -0800 Content-Type: text/plain; charset="iso-8859-15" From: Micah Yoder To: linux-xfs@oss.sgi.com Subject: RE: Postfix MTS and XFS Date: Sun, 28 Oct 2001 15:59:42 -0500 X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011028235930.UESD25699.femail40.sdc1.sfba.home.com@there> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Same here. Have been using 2.4.6pre2, all partitions XFS, using the Postfix version that came with Red Hat 7.1 powertools. No problems. -- Like to travel? http://TravTalk.org Micah Yoder Internet Development http://yoderdev.com From owner-linux-xfs@oss.sgi.com Sun Oct 28 17:40:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9T1e2c15867 for linux-xfs-outgoing; Sun, 28 Oct 2001 17:40:02 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9T1dx015843 for ; Sun, 28 Oct 2001 17:39:59 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id RAA00631 for ; Sun, 28 Oct 2001 17:39:58 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA39845 for linux-xfs@oss.sgi.com; Mon, 29 Oct 2001 12:38:40 +1100 (EST) Date: Mon, 29 Oct 2001 12:38:40 +1100 (EST) From: Nathan Scott Message-Id: <200110290138.MAA39845@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - acl_set Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Sun Oct 28 17:37:32 PST 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:105589a linux/fs/xfs/xfs_acl.c - 1.8 - we must validate an ACL coming in across the syscall interface - in particular, we cannot just assume the ace count is valid, and then use that as a loop control variable. From owner-linux-xfs@oss.sgi.com Sun Oct 28 17:45:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9T1jKf16489 for linux-xfs-outgoing; Sun, 28 Oct 2001 17:45:20 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9T1j7016465 for ; Sun, 28 Oct 2001 17:45:07 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id CAA966657 for ; Mon, 29 Oct 2001 02:45:05 +0100 (CET) mail_from (nathans@wobbly.melbourne.sgi.com) 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 MAA24223; Mon, 29 Oct 2001 12:43:44 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA18554; Mon, 29 Oct 2001 12:43:43 +1100 (AEDT) Date: Mon, 29 Oct 2001 12:43:43 +1100 From: Nathan Scott To: "Eitzenberger, Holger" Cc: "linux-xfs@oss.sgi.com" Subject: Re: Oops in acl_set(2) Message-ID: <20011029124343.I578786@wobbly.melbourne.sgi.com> References: <0025cb44@cycos.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <0025cb44@cycos.com>; from holger.eitzenberger@cycos.com on Fri, Oct 26, 2001 at 02:48:40PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Fri, Oct 26, 2001 at 02:48:40PM +0200, Eitzenberger, Holger wrote: > > Hi, > > i found a serious bug in acl_set(2) which oopses my machine. The bug is reproducible. Any local account will do. > I have checked in a fix for this - it should show up in the CVS repository on oss.sgi.com shortly. Please try it out, and let me know if it fixes your problem. The test program you sent, modulo a few changes, no longer causes an oops with this new kernel code (but does get the EINVAL which it should). many thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Oct 28 18:19:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9T2JvZ17161 for linux-xfs-outgoing; Sun, 28 Oct 2001 18:19:57 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9T2Jr017136 for ; Sun, 28 Oct 2001 18:19:53 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9T2JmW32241 for ; Sun, 28 Oct 2001 18:19:48 -0800 Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id SAA18923; Sun, 28 Oct 2001 18:19:17 -0800 (PST) Message-ID: <3BDCBBB8.D84B0E48@sgi.com> Date: Sun, 28 Oct 2001 20:15:20 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: Harri Haataja CC: xfs Subject: Re: FAQ update References: <4.3.2.7.2.20011028155036.038993e0@pop.xs4all.nl> <4.3.2.7.2.20011028155036.038993e0@pop.xs4all.nl> <1004322591.839.12.camel@mdew> <4.3.2.7.2.20011028173346.0388b758@pop.xs4all.nl> <20011028210611.A26342@cs.helsinki.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Harri Haataja wrote: > I haven't seen either, but I did recenly get new kernel rpms (2.4.9) > from the testing dir in ftp. Now the 3d GL apps (for example gliv still > works) all seem to not work. > Is that an XF4.1 thing (something I heard, does RH7.2 have DRI?) or is > the driver (Ati Rage Fury) broken? Not sure of the details, but the 2.4.9-6 and 2.4.9-7 RPMs differ only in the DRI config options - 2.4.9-6 is for RH7.1, 2.4.9-7 is for RH7.2. Try grabbing the apropriate one and see if that helps... > Was nice seeing ext3 included, though. I need that somewhere. > > And to stay remotely on-topic, I don't think daily rpms are quite needed > unless you want to roll out CVS as rpms (for XFS part) but they stayed > in 2.4.5 for ages (or were well-hidden). My thoughts on this are that any one who is going to use CVS snapshot code in their kernel should be enough of a "power user" to compile it themselves... I'm a bit wary of making it TOO easy for a novice to blow up their system with untested code. :) If anyone else wants to make the snapshot RPMs, I'm not going to complain, but I'm not going to offer them on oss. :) We do RPMs either for an upcoming release, or maybe for another pressing need such as the recent security update. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Sun Oct 28 18:32:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9T2WTS17455 for linux-xfs-outgoing; Sun, 28 Oct 2001 18:32:29 -0800 Received: from burgers.bubbanfriends.org (IDENT:postfix@burgers.bubbanfriends.org [216.140.122.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9T2WQ017433 for ; Sun, 28 Oct 2001 18:32:26 -0800 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id D1775400E07; Sun, 28 Oct 2001 21:32:35 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id C5F1F2400216; Sun, 28 Oct 2001 21:32:35 -0500 (EST) Date: Sun, 28 Oct 2001 21:32:35 -0500 (EST) From: Mike Burger To: Eric Sandeen Cc: Harri Haataja , xfs Subject: Re: FAQ update In-Reply-To: <3BDCBBB8.D84B0E48@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 28 Oct 2001, Eric Sandeen wrote: > Harri Haataja wrote: > > > I haven't seen either, but I did recenly get new kernel rpms (2.4.9) > > from the testing dir in ftp. Now the 3d GL apps (for example gliv still > > works) all seem to not work. > > Is that an XF4.1 thing (something I heard, does RH7.2 have DRI?) or is > > the driver (Ati Rage Fury) broken? > > Not sure of the details, but the 2.4.9-6 and 2.4.9-7 RPMs differ only in > the DRI config options - 2.4.9-6 is for RH7.1, 2.4.9-7 is for RH7.2. > Try grabbing the apropriate one and see if that helps... Interesting...I'm using 2.4.9-7 on my 7.1 system...no problems, yet. From owner-linux-xfs@oss.sgi.com Mon Oct 29 00:40:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9T8eLs26725 for linux-xfs-outgoing; Mon, 29 Oct 2001 00:40:21 -0800 Received: from hotmail.com (f80.law7.hotmail.com [216.33.237.80]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9T8eI026703 for ; Mon, 29 Oct 2001 00:40:18 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 29 Oct 2001 00:40:12 -0800 Received: from 211.99.247.66 by lw7fd.law7.hotmail.msn.com with HTTP; Mon, 29 Oct 2001 08:40:12 GMT X-Originating-IP: [211.99.247.66] From: "Harrison Xing" To: linux-xfs@oss.sgi.com Subject: A few XFS Mount code bugs in XFS 1.0.1 Date: Mon, 29 Oct 2001 16:40:12 +0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 29 Oct 2001 08:40:12.0966 (UTC) FILETIME=[53552460:01C16055] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk For XFS 1.0.1 release: In file fs/xfs/xfs_mount.c, there seems to be some bugs with error handling. First, around line 851 and 870, the following code should be added rvp->v_flag |= VPURGE; before calling vn_purge(rvp, &vmap); Second, the exit of error2 should add some code to free the log structure. eg. xfs_log_unmount_dealloc(mp) for some error cases after the log structure is allocated. Third, if it exits from line 840, ( "fail to read root inode") , the next mount will Oops. I've looked at the code but didn't find any obvious errors, maybe someone can check it for more details. Probably there are some problems with xfs_iget at error handling. Best Regards, Harrison Xing _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From owner-linux-xfs@oss.sgi.com Mon Oct 29 02:03:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9TA37528895 for linux-xfs-outgoing; Mon, 29 Oct 2001 02:03:07 -0800 Received: from porsta.cs.Helsinki.FI (root@porsta.cs.Helsinki.FI [128.214.48.124]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9TA31028870 for ; Mon, 29 Oct 2001 02:03:01 -0800 Received: from melkki.cs.Helsinki.FI (sslwrap@localhost [127.0.0.1]) by porsta.cs.Helsinki.FI (8.11.6/8.11.6) with ESMTP id f9TA2sk23882; Mon, 29 Oct 2001 12:02:55 +0200 Received: (from hhaataja@localhost) by melkki.cs.Helsinki.FI (8.11.6/8.11.2) id f9TA2oN20784; Mon, 29 Oct 2001 12:02:50 +0200 Date: Mon, 29 Oct 2001 12:02:50 +0200 From: Harri Haataja To: Eric Sandeen Cc: xfs Subject: Re: FAQ update Message-ID: <20011029120250.A20531@cs.helsinki.fi> References: <4.3.2.7.2.20011028155036.038993e0@pop.xs4all.nl> <4.3.2.7.2.20011028155036.038993e0@pop.xs4all.nl> <1004322591.839.12.camel@mdew> <4.3.2.7.2.20011028173346.0388b758@pop.xs4all.nl> <20011028210611.A26342@cs.helsinki.fi> <3BDCBBB8.D84B0E48@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BDCBBB8.D84B0E48@sgi.com>; from sandeen@sgi.com on Sun, Oct 28, 2001 at 08:15:20PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Oct 28, 2001 at 08:15:20PM -0600, Eric Sandeen wrote: > Harri Haataja wrote: > > > I haven't seen either, but I did recenly get new kernel rpms (2.4.9) > > from the testing dir in ftp. Now the 3d GL apps (for example gliv still > > works) all seem to not work. > > Is that an XF4.1 thing (something I heard, does RH7.2 have DRI?) or is > > the driver (Ati Rage Fury) broken? > > Not sure of the details, but the 2.4.9-6 and 2.4.9-7 RPMs differ only in > the DRI config options - 2.4.9-6 is for RH7.1, 2.4.9-7 is for RH7.2. > Try grabbing the apropriate one and see if that helps... I almost guessed that but abandoned the idea. I'll try that soon. For some reason the more recent mkinitrd (using pivotroot) never seems to work on older (let's say pre-7.2?) systems if upgrading from it but with newer kernels such as this it does. Another odd end. I don't know what's with it. It's a bit funny anyway because if your temp is mounted nodev (call me paranoid now) (IIRC), it gives an error "all your loopback devices are in use". I usually changed it to make the temps in /boot/. > > And to stay remotely on-topic, I don't think daily rpms are quite needed > > unless you want to roll out CVS as rpms (for XFS part) but they stayed > > in 2.4.5 for ages (or were well-hidden). > > My thoughts on this are that any one who is going to use CVS snapshot > code in their kernel should be enough of a "power user" to compile it > themselves... I'm a bit wary of making it TOO easy for a novice to blow > up their system with untested code. :) I'm not sure but can you easily check out the whole deal and rebuild it as rpm? There are sides to having your software (incl. kernels, though it's painful) managed. -- I don't suffer from insanity; I enjoy every minute of it. -- Lieven Marchand From owner-linux-xfs@oss.sgi.com Mon Oct 29 06:44:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9TEi7e13703 for linux-xfs-outgoing; Mon, 29 Oct 2001 06:44:07 -0800 Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9TEi1013681 for ; Mon, 29 Oct 2001 06:44:01 -0800 Received: from chemraeker1 (chemraeker1.Chem.LSA.UMich.Edu [141.211.69.17]) by changeofhabit.mr.itd.umich.edu (8.9.3/3.2r) with SMTP id JAA21995 for ; Mon, 29 Oct 2001 09:44:00 -0500 (EST) Content-Type: text/plain; charset="iso-8859-1" From: Todd Raeker To: linux-xfs@oss.sgi.com Subject: encounter a 4 GB file size limit Date: Mon, 29 Oct 2001 09:43:59 -0500 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <01102909435902.11332@chemraeker1> Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi All, I have just installed xfs for linux on my RedHat 7.1 with the 2.4.3-SGI_XFS_1.0.1 kernel. All has gone well except that I encounter a 4 GB (4194624 k reported from df -k) file size limit on an 15 GB xfs filesystem rather than essentially unlimited size. I have played around with a fe tuning options but always get the exact same limit each time. No errors pop up in any logs. My test program just keeps writing as if nothing is wrong but the file stops growing after 4194624 k has been written in the sequential file. Any hints as to what may be wrong and/or how to fix this would be greatly appreciated as 4 GB is not enough? Todd. -- Todd Raeker Department of Chemistry University of Michigan (734) 647-2867 Phone (734) 615-6950 FAX From owner-linux-xfs@oss.sgi.com Mon Oct 29 06:55:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9TEt3014053 for linux-xfs-outgoing; Mon, 29 Oct 2001 06:55:03 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9TEsx014025 for ; Mon, 29 Oct 2001 06:54:59 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id PAA1023613 for ; Mon, 29 Oct 2001 15:54:57 +0100 (CET) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA3433558; Mon, 29 Oct 2001 08:53:40 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA59211; Mon, 29 Oct 2001 08:53:39 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9TEnAa28244; Mon, 29 Oct 2001 08:49:10 -0600 Message-Id: <200110291449.f9TEnAa28244@jen.americas.sgi.com> To: Todd Raeker cc: linux-xfs@oss.sgi.com Subject: Re: encounter a 4 GB file size limit References: <01102909435902.11332@chemraeker1> Comments: In-reply-to Todd Raeker message dated "Mon, 29 Oct 2001 09:43:59 -0500." Date: Mon, 29 Oct 2001 08:49:09 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hi All, > > I have just installed xfs for linux on my RedHat 7.1 with the > 2.4.3-SGI_XFS_1.0.1 kernel. All has gone well except that I encounter a 4 GB > > (4194624 k reported from df -k) file size limit on an 15 GB xfs filesystem > rather than essentially unlimited size. I have played around with a fe > tuning options but always get the exact same limit each time. No errors pop > up in any logs. My test program just keeps writing as if nothing is wrong > but the file stops growing after 4194624 k has been written in the sequential > > file. > > Any hints as to what may be wrong and/or how to fix this would be greatly > appreciated as 4 GB is not enough? Check the output of the limit command in csh or tcsh, or the ulimit -a command in bash. It could also be an application issue if the binary was not built with LFS (large file support) built in. Steve From owner-linux-xfs@oss.sgi.com Mon Oct 29 07:17:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9TFHsI16938 for linux-xfs-outgoing; Mon, 29 Oct 2001 07:17:54 -0800 Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9TFHo016916 for ; Mon, 29 Oct 2001 07:17:50 -0800 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9TFHiNe060485; Mon, 29 Oct 2001 16:17:48 +0100 (CET) Message-Id: <4.3.2.7.2.20011029160254.02c3a3e0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 29 Oct 2001 16:16:01 +0100 To: Todd Raeker , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: encounter a 4 GB file size limit In-Reply-To: <01102909435902.11332@chemraeker1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 09:43 29-10-2001 -0500, Todd Raeker wrote: >Hi All, > >I have just installed xfs for linux on my RedHat 7.1 with the >2.4.3-SGI_XFS_1.0.1 kernel. All has gone well except that I encounter a 4 GB >(4194624 k reported from df -k) file size limit on an 15 GB xfs filesystem >rather than essentially unlimited size. I have played around with a fe >tuning options but always get the exact same limit each time. No errors pop >up in any logs. My test program just keeps writing as if nothing is wrong >but the file stops growing after 4194624 k has been written in the sequential >file. That should not happen. It should work beyond 4GB. I can create a 40GB file without problems. I don't recall seeing this problem with the 1.0.1 release. >Any hints as to what may be wrong and/or how to fix this would be greatly >appreciated as 4 GB is not enough? You could try the newer 2.4.9-6 RPMs that are available on the FTP site under /projects/xfs/testing/ Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Mon Oct 29 07:22:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9TFMIA17106 for linux-xfs-outgoing; Mon, 29 Oct 2001 07:22:18 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9TFME017084 for ; Mon, 29 Oct 2001 07:22:14 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA01381 for ; Mon, 29 Oct 2001 07:22:07 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA3422946; Mon, 29 Oct 2001 09:20:57 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA33623; Mon, 29 Oct 2001 09:20:57 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9TFGR632409; Mon, 29 Oct 2001 09:16:27 -0600 Message-Id: <200110291516.f9TFGR632409@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Harrison Xing" cc: linux-xfs@oss.sgi.com Subject: Re: A few XFS Mount code bugs in XFS 1.0.1 In-Reply-To: Message from "Harrison Xing" of "Mon, 29 Oct 2001 16:40:12 +0800." Date: Mon, 29 Oct 2001 09:16:27 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks for these, I will be putting them into the tree today sometime. Steve > For XFS 1.0.1 release: > In file fs/xfs/xfs_mount.c, there seems to be some bugs with error > handling. > > First, around line 851 and 870, the following code should be added > rvp->v_flag |= VPURGE; > before calling > vn_purge(rvp, &vmap); > > Second, the exit of error2 should add some code to free the log structure. > eg. > xfs_log_unmount_dealloc(mp) > for some error cases after the log structure is allocated. > > Third, if it exits from line 840, ( "fail to read root inode") , the next > mount > will Oops. I've looked at the code but didn't find any obvious errors, > maybe > someone can check it for more details. Probably there are some problems > with xfs_iget at error handling. > > Best Regards, > Harrison Xing > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From owner-linux-xfs@oss.sgi.com Mon Oct 29 07:32:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9TFWYF17938 for linux-xfs-outgoing; Mon, 29 Oct 2001 07:32:34 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9TFWR017913 for ; Mon, 29 Oct 2001 07:32:27 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA05534 for ; Mon, 29 Oct 2001 07:31:50 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA3431494; Mon, 29 Oct 2001 09:31:11 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA56948; Mon, 29 Oct 2001 09:31:10 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9TFQf132535; Mon, 29 Oct 2001 09:26:41 -0600 Message-Id: <200110291526.f9TFQf132535@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Micah Yoder cc: linux-xfs@oss.sgi.com Subject: Re: Upgrading kernel, Compile error in module In-Reply-To: Message from Micah Yoder of "Sat, 27 Oct 2001 16:42:51 EDT." <20011027234239.VKNQ5793.femail48.sdc1.sfba.home.com@there> Date: Mon, 29 Oct 2001 09:26:41 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hi again. Decided it was finally time to upgrade my 2.4.6pre2-xfs, which has > > been working great, for security and VM fixes. Just grabbed latest CVS an > hour or two ago (2.4.14pre3). > > Thing that makes me nervous is that there was a minor compile error in gvim > ./drivers/block/paride/pcd.c: > > static struct block_device_operations pcd_bdops = { > owner: THIS_MODULE, > open: cdrom_open, > release: cdrom_release, > ioctl: cdrom_ioctl, > check_media_change: cdrom_media_changed, > } /* line 274 */ > > static struct cdrom_device_ops pcd_dops = { > pcd_open, > pcd_release, > [...] > > Note the lack of a semicolon on 274!!! I added it and now it compiles. > Dunno if that booboo was inherited from Linus or from one of you, but you > might want to fix it. :-) > It was inherited from Linus, most of the files (99%) in the tree are unmodified by us. In general with this sort of problem if it is not fixed in the latest pre-xxx kernel from Linus, submit a patch to Linux kernel and Linus. Unless a fix affects mainline kernel functionality I try to keep our tree identical to Linus's. > So that's fixed, but the fact that it was there worries me some! What other > nasties besides compile errors could be in there? > There was a change went into the 2.4.13-pre3 which affects how block device modules do reference counting to avoid module unload being performed on running code. Most of this code change was probably a global cut and paste, a few errors can easily creep into a change like this and they usually get sorted out fairly quickly. > > Think it's "safe" to put this thing on a production server? Again, my > "problem" is that it's co-located, 500 miles away, so a mistake could be > costly... but if it works for most people I'm willing to try it. In general I would not put a pre-xxx kernel up in production unless you yourself have done fairly extensive testing. The 2.4.13 kernel itself seems fairly robust, there is a patch for this on the ftp site: ftp://oss.sgi.com/projects/xfs/download/patches Steve > > Thanks, > Micah > > -- > Like to travel? http://TravTalk.org > Micah Yoder Internet Development http://yoderdev.com From owner-linux-xfs@oss.sgi.com Mon Oct 29 07:36:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9TFaC220230 for linux-xfs-outgoing; Mon, 29 Oct 2001 07:36:12 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9TFaA020208 for ; Mon, 29 Oct 2001 07:36:10 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA04479 for ; Mon, 29 Oct 2001 07:35:32 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA3435313 for ; Mon, 29 Oct 2001 09:34:53 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA45190 for ; Mon, 29 Oct 2001 09:34:53 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id f9TFUNd03458; Mon, 29 Oct 2001 09:30:23 -0600 Message-Id: <200110291530.f9TFUNd03458@jen.americas.sgi.com> Date: Mon, 29 Oct 2001 09:30:23 -0600 Subject: TAKE - mount error path cleanups Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Error path cleanups from Harrison Xing. Date: Mon Oct 29 07:34:30 PST 2001 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:105599a linux/fs/xfs/xfs_mount.c - 1.263 From owner-linux-xfs@oss.sgi.com Mon Oct 29 09:13:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9THDRO22791 for linux-xfs-outgoing; Mon, 29 Oct 2001 09:13:27 -0800 Received: from umbi3.umbi.umd.edu (umbi3.umbi.umd.edu [136.160.7.51]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9THDM022766 for ; Mon, 29 Oct 2001 09:13:22 -0800 Received: from umbi.umd.edu (amanda.carb.nist.gov [129.6.113.5]) by umbi3.umbi.umd.edu (Netscape Messaging Server 4.15) with ESMTP id GLZ96B00.7YS; Mon, 29 Oct 2001 12:13:23 -0500 Message-ID: <3BDD8E31.9C817A5@umbi.umd.edu> Date: Mon, 29 Oct 2001 12:13:21 -0500 From: Jonathan Dill Organization: CARB X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-6SGI_XFS_PR3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Todd Raeker CC: linux-xfs@oss.sgi.com Subject: Re: encounter a 4 GB file size limit References: <01102909435902.11332@chemraeker1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Todd, I ran into a filesize limitation with RH 7.1 tcsh that was not compiled with O_LARGEFILE enabled. I recompiled tcsh and that solved the problem. You can use this test that was sent by Nathan Scott to check if it's a limitation of your shell: # Example of tcsh with filesize limitation: # strace /bin/tcsh -c 'echo > /tmp/blop' |& grep 'open("/tmp/blop"' open("/tmp/blop", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3 # Example of tcsh compiled with O_LARGFILE # strace /bin/tcsh -c 'echo > /tmp/blop' |& grep 'open("/tmp/blop"' open("/tmp/blop", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3 A similar test should work for other shells as well. To fix the problem, I installed tcsh-6.10-6.src.rpm with "rpm -ivh" (I used the src.rpm from RH 7.2, but the src.rpm from RH 7.1. should work too). I extracted the tcsh-6.10.tar.gz archive, editted the Makefile.in and editted the CFLAGS line as follows: CFLAGS = @CFLAGS@ -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 Then I tarred up the tcsh back to tcsh-6.10.tar.gz and ran "rpm -bb SPEC/tcsh.spec" to generate a new i386.rpm. I'm sure there is a more elegant way to make this change, eg. a patch applied through the .spec file. -- "Jonathan F. Dill" (dill@umbi.umd.edu) CARB IT Coordinator Experimental Support Site http://concept.umbi.umd.edu From owner-linux-xfs@oss.sgi.com Mon Oct 29 09:29:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9THTHc30487 for linux-xfs-outgoing; Mon, 29 Oct 2001 09:29:17 -0800 Received: from fs1.theiqgroup.com (fs1.theiqgroup.com [216.81.249.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9THT9030465 for ; Mon, 29 Oct 2001 09:29:09 -0800 Received: from theiqgroup.com (funkmotor.theiqgroup.com [216.81.249.21]) by fs1.theiqgroup.com (8.11.0/8.11.0) with ESMTP id f9THT3501960 for ; Mon, 29 Oct 2001 11:29:03 -0600 Message-ID: <3BDD91DF.7000509@theiqgroup.com> Date: Mon, 29 Oct 2001 11:29:03 -0600 From: Kelly Corbin Organization: The IQ Group, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: [Fwd: Re: XFS Support] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Just curious if anyone from XFS has worked with anyone with Intermezzo on getting the two working together. I know they are working with someone from ReiserFS to get that filesystem working with Intermezzo. Intermezzo is enjoying a resurgence of interest right now and if it worked with XFS I'm sure a lot of people would be using the two together. Below is a post on the Intermezzo list. Just my $0.02 Thanks Kelly -------- Original Message -------- Subject: Re: XFS Support Date: Sun, 9 Sep 2001 06:27:29 -0600 From: "Peter J. Braam" To: Ghetto Scientist CC: intermezzo-devel@lists.sourceforge.net, intermezzo-discuss@lists.sourceforge.net References: <000901c138a1$8a1979a0$f62cf818@potlnd1.or.home.com> I wish we had resources to do this: what needs to be done is to organize a "journaled" file write. There is infrastructure present in XFS to help this, but it's not trivial. I believe the nested transactions, which forms the other component, were done in May. - Peter - On Sat, Sep 08, 2001 at 01:04:57PM -0700, Ghetto Scientist wrote: > Has any progress been made on XFS support for Intermezzo? I know there was > work being done at one time but I haven't seen any mention of it lately on > either list. > > --adam > > > _______________________________________________ > intermezzo-discuss mailing list > intermezzo-discuss@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/intermezzo-discuss -- _______________________________________________ intermezzo-discuss mailing list intermezzo-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/intermezzo-discuss -- -------------------------------------------- -- Kelly Corbin -- Systems Administrator -- -- http://www.theiqgroup.com -- The Future of eServices... -- -- The IQ Group, Inc. -- 6740 Antioch Suite 110 -- Merriam, KS 66204 -- (913)-722-6700 x105 -- Fax (913)722-7264 -------------------------------------------- From owner-linux-xfs@oss.sgi.com Mon Oct 29 09:39:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9THdps30748 for linux-xfs-outgoing; Mon, 29 Oct 2001 09:39:51 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9THdj030724 for ; Mon, 29 Oct 2001 09:39:45 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA12350 for ; Mon, 29 Oct 2001 09:39:38 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA3440488; Mon, 29 Oct 2001 11:38:28 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA05560; Mon, 29 Oct 2001 11:38:28 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9THXvk11421; Mon, 29 Oct 2001 11:33:57 -0600 Message-Id: <200110291733.f9THXvk11421@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Kelly Corbin cc: linux-xfs@oss.sgi.com Subject: Re: [Fwd: Re: XFS Support] In-Reply-To: Message from Kelly Corbin of "Mon, 29 Oct 2001 11:29:03 CST." <3BDD91DF.7000509@theiqgroup.com> Date: Mon, 29 Oct 2001 11:33:57 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Just curious if anyone from XFS has worked with anyone with Intermezzo > on getting the two working together. I know they are working with > someone from ReiserFS to get that filesystem working with Intermezzo. Beyond chatting with Peter at the 2.5 kernel summit and various discussions since then no. Right now we are very bandwidth limited and taking on things like this is not something we can do right now. I am looking over the changes Peter has and will probably check them into the tree, but really unless someone external to SGI has the bandwidth and expertise to do this, it is not going to make progress. We will be happy to answer questions should someone undertake the project. Steve > > Intermezzo is enjoying a resurgence of interest right now and if it > worked with XFS I'm sure a lot of people would be using the two together. > > Below is a post on the Intermezzo list. > > Just my $0.02 > > Thanks > > Kelly > > -------- Original Message -------- > Subject: Re: XFS Support > Date: Sun, 9 Sep 2001 06:27:29 -0600 > From: "Peter J. Braam" > To: Ghetto Scientist > CC: intermezzo-devel@lists.sourceforge.net, > intermezzo-discuss@lists.sourceforge.net > References: <000901c138a1$8a1979a0$f62cf818@potlnd1.or.home.com> > > I wish we had resources to do this: what needs to be done is to > organize a "journaled" file write. There is infrastructure present in > XFS to help this, but it's not trivial. > > I believe the nested transactions, which forms the other component, > were done in May. > > - Peter - > > > > -- > -------------------------------------------- > -- Kelly Corbin > -- Systems Administrator > -- > -- http://www.theiqgroup.com > -- The Future of eServices... > -- > -- The IQ Group, Inc. > -- 6740 Antioch Suite 110 > -- Merriam, KS 66204 > -- (913)-722-6700 x105 > -- Fax (913)722-7264 > -------------------------------------------- From owner-linux-xfs@oss.sgi.com Mon Oct 29 10:21:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9TILPt31642 for linux-xfs-outgoing; Mon, 29 Oct 2001 10:21:25 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9TILM031620 for ; Mon, 29 Oct 2001 10:21:22 -0800 Received: from clink-eth.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA15578 for ; Mon, 29 Oct 2001 10:21:15 -0800 (PST) mail_from (roehrich@clink-eth.americas.sgi.com) Received: (from roehrich@localhost) by clink-eth.americas.sgi.com (SGI-8.9.3/8.9.3) id MAA30531 for linux-xfs@oss.sgi.com; Mon, 29 Oct 2001 12:20:04 -0600 (CST) Date: Mon, 29 Oct 2001 12:20:04 -0600 (CST) From: Dean Roehrich Message-Id: <200110291820.MAA30531@clink-eth.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - Port DMAPI function prohibited_mr_events() to linux. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Oct 29 10:19:47 PST 2001 Workarea: clink-eth.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:105615a linux/fs/xfs/xfs_dmapi.c - 1.41 - port prohibited_mr_events() to linux. remove some ifdef __sgi gunk. From owner-linux-xfs@oss.sgi.com Mon Oct 29 10:27:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9TIRmx31883 for linux-xfs-outgoing; Mon, 29 Oct 2001 10:27:48 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9TIRf031861 for ; Mon, 29 Oct 2001 10:27:41 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id TAA952660 for ; Mon, 29 Oct 2001 19:27:40 +0100 (CET) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA3437278 for ; Mon, 29 Oct 2001 12:26:23 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id MAA74640 for ; Mon, 29 Oct 2001 12:26:22 -0600 (CST) Subject: Who / What's using Linux XFS? From: Eric Sandeen To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 29 Oct 2001 12:23:59 -0600 Message-Id: <1004379839.13361.47.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi all - I'd like to put a page up on the web site detailing the various applications, distributions, installations, and embedded products using XFS for Linux. I'd appreciate some submissions; examples below. Applications ------------ Grub GNU parted Ferris Samba, supports XFS acls. Distributions ------------- Mandrake 8.1 Debian "sid" has xfs patches JBLinux J-B linux Installations ------------- Hm, no examples here... what I'm _not_ looking for is "my home fileserver." What I _am_ looking for is something like "The human genome project stores all data on Linux/XFS" :) Basically, something that someone else contemplating a substantial Linux/XFS deployment would be interested in. Products -------- I know of some embedded projects using XFS, but I'm not sure I'm free to mention them. If you're using XFS in your whiz-bang toaster or set-top box, that'd be a good data point as well. If you have something to submit, please include a URL for the project/distro/installation site for more info, and a brief description of features, capabilities, etc of the submission. I'll reserve the right to filter all this for things that I feel are substantial enough to mention. This thread has the potential to get fairly off-topic, so let's not delve too far into discussions of the relative merits of various distros, etc... Thanks! -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Oct 29 10:39:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9TId7G32406 for linux-xfs-outgoing; Mon, 29 Oct 2001 10:39:07 -0800 Received: from itspec.amoa.org (amoa.org [207.207.51.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9TId0032384 for ; Mon, 29 Oct 2001 10:39:00 -0800 Received: from itspec.amoa.org (itspec.amoa.org [127.0.0.1]) by itspec.amoa.org (8.11.6/8.11.6) with ESMTP id f9TIcET25843 for ; Mon, 29 Oct 2001 12:38:14 -0600 Subject: Re: Who / What's using Linux XFS? From: Chris Tooley To: linux-xfs@oss.sgi.com In-Reply-To: <1004379839.13361.47.camel@stout.americas.sgi.com> References: <1004379839.13361.47.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16.99+cvs.2001.10.28.13.59 (Preview Release) Date: 29 Oct 2001 12:38:14 -0600 Message-Id: <1004380695.23409.8.camel@itspec.amoa.org> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The Austin Museum of Art has two file servers (only 40 and 50 gig of software RAID respectively) running on RedHat 7.1 XFS. We have another file server that is using the ext2 acl patches for backwards compatability which is 100 gig. About 50 users use the two XFS boxes pretty much all day long. Had one power failure, boxes were up for 10 minutes before the other box was done fscking. Chris Tooley On Mon, 2001-10-29 at 12:23, owner-linux-xfs@oss.sgi.com wrote: > Hi all - > > I'd like to put a page up on the web site detailing the various > applications, distributions, installations, and embedded products using > XFS for Linux. > > I'd appreciate some submissions; examples below. > > Applications > ------------ > Grub > GNU parted > Ferris > Samba, supports XFS acls. > > Distributions > ------------- > Mandrake 8.1 > Debian "sid" has xfs patches > JBLinux > J-B linux > > Installations > ------------- > Hm, no examples here... what I'm _not_ looking for is "my home > fileserver." What I _am_ looking for is something like "The human > genome project stores all data on Linux/XFS" :) Basically, something > that someone else contemplating a substantial Linux/XFS deployment would > be interested in. > > Products > -------- > I know of some embedded projects using XFS, but I'm not sure I'm free to > mention them. If you're using XFS in your whiz-bang toaster or set-top > box, that'd be a good data point as well. > > > If you have something to submit, please include a URL for the > project/distro/installation site for more info, and a brief description > of features, capabilities, etc of the submission. > > I'll reserve the right to filter all this for things that I feel are > substantial enough to mention. > > This thread has the potential to get fairly off-topic, so let's not > delve too far into discussions of the relative merits of various > distros, etc... > > Thanks! > > -Eric > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. > From owner-linux-xfs@oss.sgi.com Mon Oct 29 12:17:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9TKHYp05045 for linux-xfs-outgoing; Mon, 29 Oct 2001 12:17:34 -0800 Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9TKHT005018 for ; Mon, 29 Oct 2001 12:17:29 -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 f9TKHQBd055725; Mon, 29 Oct 2001 21:17:27 +0100 (CET) Message-Id: <4.3.2.7.2.20011029193944.036e1710@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 29 Oct 2001 21:15:44 +0100 To: Eric Sandeen , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Who / What's using Linux XFS? In-Reply-To: <1004379839.13361.47.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 12:23 29-10-2001 -0600, Eric Sandeen wrote: >Hm, no examples here... what I'm _not_ looking for is "my home >fileserver." What I _am_ looking for is something like "The human >genome project stores all data on Linux/XFS" :) Basically, something >that someone else contemplating a substantial Linux/XFS deployment would >be interested in. Coltex Retail group BV in the Netherlands uses RedHat Linux with XFS for their main database server which collects the data from over 240 clothing retail stores throughout the Netherlands. Coltex depends on the availabilty of the server for over 100 hundred employees in the main office for retrieval of logistical and sales figures. The database size is roughly 10GB large containing both historical and current data. The entire production and logistical system depends on the availability of the system and downtime would mean a significant financial penalty. The speed and reliability of the XFS filesystem which has a proven track record and mature tools to go with it is fundamental to the availability of the system. XFS has saved us a lot of time during testing and implementation. A long filesystems check is no longer needed when bad things happen when they do. The increased speed of our database system which is based on Progress 9.1C is also a nice benefit to this filesystem. Spell check as needed. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Mon Oct 29 12:17:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9TKHTt05019 for linux-xfs-outgoing; Mon, 29 Oct 2001 12:17:29 -0800 Received: from femail32.sdc1.sfba.home.com (femail32.sdc1.sfba.home.com [24.254.60.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9TKHI004994 for ; Mon, 29 Oct 2001 12:17:24 -0800 Received: from there ([65.4.56.167]) by femail32.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20011029201708.RRSE26359.femail32.sdc1.sfba.home.com@there>; Mon, 29 Oct 2001 12:17:08 -0800 Content-Type: text/plain; charset="iso-8859-1" From: Micah Yoder To: Steve Lord Subject: Re: Upgrading kernel, Compile error in module Date: Mon, 29 Oct 2001 12:17:19 -0500 X-Mailer: KMail [version 1.3.1] Cc: linux-xfs@oss.sgi.com References: <200110291526.f9TFQf132535@jen.americas.sgi.com> In-Reply-To: <200110291526.f9TFQf132535@jen.americas.sgi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011029201708.RRSE26359.femail32.sdc1.sfba.home.com@there> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Monday 29 October 2001 10:26 am, Steve Lord wrote: > There was a change went into the 2.4.13-pre3 which affects how block device > modules do reference counting to avoid module unload being performed on you mean 2.4.14pre3? If 13, any issues from that should be fixed... (I didn't see it in the changelog for either 2.4.13 or 2.4.14) > In general I would not put a pre-xxx kernel up in production unless you > yourself have done fairly extensive testing. The 2.4.13 kernel itself > seems fairly robust, there is a patch for this on the ftp site: > > ftp://oss.sgi.com/projects/xfs/download/patches ok I'll compile that sucker instead. Thanks! Micah -- Like to travel? http://TravTalk.org Micah Yoder Internet Development http://yoderdev.com From owner-linux-xfs@oss.sgi.com Mon Oct 29 12:30:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9TKUJ306365 for linux-xfs-outgoing; Mon, 29 Oct 2001 12:30:19 -0800 Received: from tima.ddts.net (IDENT:postfix@adsl-63-205-129-53.dsl.lsan03.pacbell.net [63.205.129.53]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9TKUE006343 for ; Mon, 29 Oct 2001 12:30:15 -0800 Received: by tima.ddts.net (Postfix, from userid 500) id 8618F307106; Mon, 29 Oct 2001 13:30:12 -0800 (PST) Date: Mon, 29 Oct 2001 13:30:12 -0800 From: Artem Veremey To: linux-xfs@oss.sgi.com Subject: XFS corruption Message-ID: <20011029133012.A6980@bud> Reply-To: tima@alumni.psu.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Organization: Home X-Operating-System: Linux/2.4.13-xfs-fast (i686) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi all, I have a case of XFS corruption to report. After poweroff, /dev/hda8 (/home) did not mount - "unknown fs...". xfs_repair produces the following results: xfs_repair /dev/hda8 Phase 1 - find and verify superblock... superblock read failed, offset 370130944, size 2048, ag 4294967295, rval 4 fatal error -- Input/output error Kernel logged a few dozen errors like this during xfs_repair (that happens with DMA disabled): Oct 29 09:56:21 bud kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Err or } Oct 29 09:56:21 bud kernel: hda: dma_intr: error=0x40 { UncorrectableError }, LBAsec t=19197740, sector=722913 Oct 29 09:56:21 bud kernel: end_request: I/O error, dev 03:08 (hda), sector 722913 xfs_check produced many errors too of the following two types: block 7/305 expected type unknown got free2 and block 6/22564 expected type free1 got unknown Disk (IBM 60GXP 40Gb) seems to be OK (only one partition failed and filling new fs on /dev/hda8 with dd doesn't produce errors) Machine runs a kernel build from cvs update on Oct 25. Linux version 2.4.13-xfs-fast (root@bud) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Thu Oct 25 22:23:37 PDT 2001 (-fast is just a configuration for specific hardware on that box) /sbin/xfs_repair -V xfs_repair version 1.3.9 MB chipset - ALi Magic1. The question is who's fault is that? :) From owner-linux-xfs@oss.sgi.com Mon Oct 29 13:02:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9TL2qF15511 for linux-xfs-outgoing; Mon, 29 Oct 2001 13:02:52 -0800 Received: from femail4.sdc1.sfba.home.com (femail4.sdc1.sfba.home.com [24.0.95.84]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9TL2j015488 for ; Mon, 29 Oct 2001 13:02:50 -0800 Received: from there ([65.4.56.167]) by femail4.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20011029210235.DAZA571.femail4.sdc1.sfba.home.com@there> for ; Mon, 29 Oct 2001 13:02:35 -0800 Content-Type: text/plain; charset="iso-8859-15" From: Micah Yoder To: linux-xfs@oss.sgi.com Subject: updating usermode packages Date: Mon, 29 Oct 2001 13:02:46 -0500 X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011029210235.DAZA571.femail4.sdc1.sfba.home.com@there> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk [micah@nova micah]$ rpm -qa | grep xfs xfsprogs-1.2.7-0 xfsprogs-devel-1.2.7-0 xfsdump-1.0.9-0 How important is it to upgrade these when one upgrades a kernel? -- Like to travel? http://TravTalk.org Micah Yoder Internet Development http://yoderdev.com From owner-linux-xfs@oss.sgi.com Mon Oct 29 13:05:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9TL53u15629 for linux-xfs-outgoing; Mon, 29 Oct 2001 13:05:03 -0800 Received: from gk.hm.epigenomics.net (qmailr@gk.hm.epigenomics.net [212.121.137.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9TL4x015607 for ; Mon, 29 Oct 2001 13:05:00 -0800 Received: (qmail 822 invoked from network); 29 Oct 2001 21:05:01 -0000 Received: from raman.epigenomics.epi (qmailr@192.168.2.2) by salam.epigenomics.epi with SMTP; 29 Oct 2001 21:05:01 -0000 Received: (qmail 23783 invoked from network); 29 Oct 2001 21:04:57 -0000 Received: from broglie.epigenomics.epi (qmailr@192.168.1.5) by raman.epigenomics.epi with SMTP; 29 Oct 2001 21:04:57 -0000 Received: (qmail 14869 invoked by uid 9); 29 Oct 2001 21:04:57 -0000 From: Robert Sander Reply-To: Robert Sander X-Newsgroups: epi.ml.linux.xfs Subject: Re: Who / What's using Linux XFS? Date: Mon, 29 Oct 2001 21:04:56 +0000 (UTC) Organization: Epigenomics AG Lines: 19 Message-ID: References: <1004379839.13361.47.camel@stout.americas.sgi.com> X-Complaints-To: usenet@epigenomics.com User-Agent: slrn/0.9.7.2 (Linux) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 29 Oct 2001 18:30:02 +0000 (UTC), Eric Sandeen wrote: > Hm, no examples here... what I'm _not_ looking for is "my home > fileserver." What I _am_ looking for is something like "The human > genome project stores all data on Linux/XFS" :) Basically, something > that someone else contemplating a substantial Linux/XFS deployment would > be interested in. Hey, missed by about 2 centimeters. ;-) We have one 430GB RAID system with XFS in production storing corporate documents and another will go into production soon storing more scientific data. Greetings -- Robert Sander Computer Scientist Epigenomics AG Bioinformatics R&D www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Mon Oct 29 13:12:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9TLCQW15961 for linux-xfs-outgoing; Mon, 29 Oct 2001 13:12:26 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9TLCI015938 for ; Mon, 29 Oct 2001 13:12:18 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA27990 for ; Mon, 29 Oct 2001 13:12:11 -0800 (PST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA3166389; Mon, 29 Oct 2001 15:11:00 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id PAA27482; Mon, 29 Oct 2001 15:11:00 -0600 (CST) Subject: Re: updating usermode packages From: Eric Sandeen To: Micah Yoder Cc: linux-xfs@oss.sgi.com In-Reply-To: <20011029210235.DAZA571.femail4.sdc1.sfba.home.com@there> References: <20011029210235.DAZA571.femail4.sdc1.sfba.home.com@there> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 29 Oct 2001 15:10:50 -0600 Message-Id: <1004389850.1570.21.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Most userspace tools upgrades aren't kernel-version related (although sometimes they are - not recently). However, getting the latest userspace stuff is usually a good idea, as new versions are often due to bugfixes. -Eric On Mon, 2001-10-29 at 12:02, Micah Yoder wrote: > [micah@nova micah]$ rpm -qa | grep xfs > xfsprogs-1.2.7-0 > xfsprogs-devel-1.2.7-0 > xfsdump-1.0.9-0 > > How important is it to upgrade these when one upgrades a kernel? > > -- > Like to travel? http://TravTalk.org > Micah Yoder Internet Development http://yoderdev.com -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Oct 29 13:14:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9TLEKW16265 for linux-xfs-outgoing; Mon, 29 Oct 2001 13:14:20 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9TLEH016242 for ; Mon, 29 Oct 2001 13:14:17 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA28203 for ; Mon, 29 Oct 2001 13:14:09 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA3440079; Mon, 29 Oct 2001 15:12:57 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA64077; Mon, 29 Oct 2001 15:12:57 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id f9TL8PV12857; Mon, 29 Oct 2001 15:08:25 -0600 Subject: Re: updating usermode packages From: Steve Lord To: Micah Yoder Cc: linux-xfs@oss.sgi.com In-Reply-To: <20011029210235.DAZA571.femail4.sdc1.sfba.home.com@there> References: <20011029210235.DAZA571.femail4.sdc1.sfba.home.com@there> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16 (Preview Release) Date: 29 Oct 2001 15:08:25 -0600 Message-Id: <1004389705.12833.5.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2001-10-29 at 12:02, Micah Yoder wrote: > [micah@nova micah]$ rpm -qa | grep xfs > xfsprogs-1.2.7-0 > xfsprogs-devel-1.2.7-0 > xfsdump-1.0.9-0 > > How important is it to upgrade these when one upgrades a kernel? > > -- > Like to travel? http://TravTalk.org > Micah Yoder Internet Development http://yoderdev.com > Basically not very - unless there is an explicit instruction to do so. For the most part user space is getting very few bug fixes, there were some alignment fixes recently which affected ia64 and sparc, and a fix for making filesystems bigger than 1 Tbyte. If we make a kernel interface change then we will definitely tell people about it explicitly. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Oct 29 13:19:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9TLJgP17737 for linux-xfs-outgoing; Mon, 29 Oct 2001 13:19:42 -0800 Received: from ausmail.coremetrics.com ([209.184.141.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9TLJb017715 for ; Mon, 29 Oct 2001 13:19:37 -0800 Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Oct 2001 15:19:06 -0600 Message-ID: <85063BBE668FD411944400D0B744267A88869D@AUSMAIL> From: "Gonyou, Austin" To: "'linux-xfs@oss.sgi.com'" Subject: I/O Issue causes hanging processes Date: Mon, 29 Oct 2001 15:19:03 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This script will cause some issues on Linux running XFS. Currently the kernel is a 2.4.10 vanilla + xfs patch. That's it. There are no other drivers, etc. I'm going to test with other filesystems too, but it seems to be a buffering issue. If anyone could test with this script on a box they can reboot readily, cuz typing 'reboot' at a prompt is sure lilo corruption or library corruption most times. The only way we've been able to ensure the system will come back up with minimal damage is to do a hard reboot. Thanks for listening and I hope someone can help answer this terrible issue. ##!/usr/bin/perl # #open FD, ">>spew.out"; # #while (true) { # print FD #"asdjf;lasdjkflasjdflasjkdfljkasdflkjasd;lfjkas;dlfjka;sldkfja;sldkfjasl;dk fja;sldjkf;lasdkjf;laskjdf;laskdjf;laskjdf;la#skjqpoewiurqpoweiurpoqweiur #poqwieurpoqiweurpoiqwueproiuweopriulznmxc/.v,mzxc/v.,mzxc/.,vm;alksdjf;lask jdf;lkasdjpfqiweuroiwuqpeoriuwqpeoiruopqeiurp#oiasjdfl;kjas;dlfkjasdl;kfja;s ldkjflaskdjf;lknmzX?C>,nvxcz/.vnz/xc.,vnxzcnv/kjsda;lkfja;sdldkjfpalsdkjfpas d\n"; #} # #close FD; -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com From owner-linux-xfs@oss.sgi.com Mon Oct 29 13:35:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9TLZYi20061 for linux-xfs-outgoing; Mon, 29 Oct 2001 13:35:34 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9TLZT020039 for ; Mon, 29 Oct 2001 13:35:30 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA05156 for ; Mon, 29 Oct 2001 13:34:51 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA3417491; Mon, 29 Oct 2001 15:34:10 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA52240; Mon, 29 Oct 2001 15:34:10 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id f9TLTcT12911; Mon, 29 Oct 2001 15:29:38 -0600 Message-Id: <200110292129.f9TLTcT12911@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Gonyou, Austin" cc: "'linux-xfs@oss.sgi.com'" Subject: Re: I/O Issue causes hanging processes In-Reply-To: Message from "Gonyou, Austin" of "Mon, 29 Oct 2001 15:19:03 CST." <85063BBE668FD411944400D0B744267A88869D@AUSMAIL> Date: Mon, 29 Oct 2001 15:29:38 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Well, I unmangled the script - basically an infinite write loop in perl. I then ran it on a test box, and the end result was this: [root@lord /xfs]# ./spew File size limit exceeded (core dumped) This produced 2Gbyte output file, I suspect perl is not compiled with LFS support on my box. No system errors and no other problems - apart from a non-responsive box during the file writing. I would recommend you try a later kernel, 2.4.10 is supposed to be a bit iffy. Try 2.4.13 and see what happens. > This script will cause some issues on Linux running XFS. > Currently the kernel is a 2.4.10 vanilla + xfs patch. That's it. > There are no other drivers, etc. I'm going to test with other filesystems > too, > but it seems to be a buffering issue. If anyone could test with this script > on a box > they can reboot readily, cuz typing 'reboot' at a prompt is sure lilo > corruption > or library corruption most times. The only way we've been able to ensure the > system will come > back up with minimal damage is to do a hard reboot. Thanks for listening and > I hope someone can > help answer this terrible issue. > Steve From owner-linux-xfs@oss.sgi.com Mon Oct 29 14:19:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9TMJpA21249 for linux-xfs-outgoing; Mon, 29 Oct 2001 14:19:51 -0800 Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9TMJh021227 for ; Mon, 29 Oct 2001 14:19:44 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9TMJcqJ061328; Mon, 29 Oct 2001 23:19:39 +0100 (CET) Message-Id: <4.3.2.7.2.20011029231249.036cd228@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 29 Oct 2001 23:17:57 +0100 To: tima@alumni.psu.edu, linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: XFS corruption In-Reply-To: <20011029133012.A6980@bud> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 13:30 29-10-2001 -0800, Artem Veremey wrote: >Hi all, >I have a case of XFS corruption to report. > >After poweroff, /dev/hda8 (/home) did not mount - "unknown fs...". >xfs_repair produces the following results: > >xfs_repair /dev/hda8 >Phase 1 - find and verify superblock... >superblock read failed, offset 370130944, size 2048, ag 4294967295, rval 4 > >fatal error -- Input/output error > >Kernel logged a few dozen errors like this during xfs_repair (that happens >with DMA disabled): >Oct 29 09:56:21 bud kernel: hda: dma_intr: status=0x51 { DriveReady >SeekComplete Err >or } >Oct 29 09:56:21 bud kernel: hda: dma_intr: error=0x40 { UncorrectableError >}, LBAsec >t=19197740, sector=722913 >Oct 29 09:56:21 bud kernel: end_request: I/O error, dev 03:08 (hda), >sector 722913 > >xfs_check produced many errors too of the following two types: >block 7/305 expected type unknown got free2 >and >block 6/22564 expected type free1 got unknown Your disk is b0rken. (Like so many other IBM drives). Better see your retailer since it will probably go _very_ soon. >Disk (IBM 60GXP 40Gb) seems to be OK (only one partition failed and >filling new fs on /dev/hda8 with dd doesn't produce errors) There is a thorough explanation for this in the FAQ. Sometimes drives only start remapping clusters after a reboot or after a too long time. Sometimes you run out of spare clusters and you actually get to see this. Get your disk replaced imediately. It think it will hold out for a day if you are lucky. >Machine runs a kernel build from cvs update on Oct 25. > >Linux version 2.4.13-xfs-fast (root@bud) (gcc version egcs-2.91.66 >19990314/Linux (egcs-1.1.2 release)) #1 Thu Oct 25 22:23:37 PDT 2001 >(-fast is just a configuration for specific hardware on that box) > >/sbin/xfs_repair -V >xfs_repair version 1.3.9 > >MB chipset - ALi Magic1. Your disk is having problems and not the IDE controller. >The question is who's fault is that? :) The disk and mine ofcourse. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Mon Oct 29 14:43:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9TMhxX21767 for linux-xfs-outgoing; Mon, 29 Oct 2001 14:43:59 -0800 Received: from femail47.sdc1.sfba.home.com (imail@femail47.sdc1.sfba.home.com [24.254.60.41]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9TMhv021745 for ; Mon, 29 Oct 2001 14:43:57 -0800 Received: from there ([65.4.56.167]) by femail47.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20011029224355.CQQR13109.femail47.sdc1.sfba.home.com@there>; Mon, 29 Oct 2001 14:43:55 -0800 Content-Type: text/plain; charset="iso-8859-1" From: Micah Yoder To: Steve Lord Subject: Re: Upgrading kernel, Compile error in module Date: Mon, 29 Oct 2001 14:44:07 -0500 X-Mailer: KMail [version 1.3.1] Cc: linux-xfs@oss.sgi.com References: <200110291526.f9TFQf132535@jen.americas.sgi.com> In-Reply-To: <200110291526.f9TFQf132535@jen.americas.sgi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011029224355.CQQR13109.femail47.sdc1.sfba.home.com@there> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Monday 29 October 2001 10:26 am, Steve Lord wrote: > seems fairly robust, there is a patch for this on the ftp site: > > ftp://oss.sgi.com/projects/xfs/download/patches Actually, no there isn't! I see patches for 2.4.6 to 2.4.12, plus some 2.4.14-pre patches. No 2.4.13! -- Like to travel? http://TravTalk.org Micah Yoder Internet Development http://yoderdev.com From owner-linux-xfs@oss.sgi.com Mon Oct 29 14:51:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9TMpC622014 for linux-xfs-outgoing; Mon, 29 Oct 2001 14:51:12 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9TMp8021989 for ; Mon, 29 Oct 2001 14:51:08 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id XAA1083675 for ; Mon, 29 Oct 2001 23:51:07 +0100 (CET) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA3439865; Mon, 29 Oct 2001 16:49:49 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id QAA60527; Mon, 29 Oct 2001 16:49:49 -0600 (CST) Subject: Re: Upgrading kernel, Compile error in module From: Eric Sandeen To: Micah Yoder Cc: Steve Lord , linux-xfs@oss.sgi.com In-Reply-To: <20011029224355.CQQR13109.femail47.sdc1.sfba.home.com@there> References: <200110291526.f9TFQf132535@jen.americas.sgi.com> <20011029224355.CQQR13109.femail47.sdc1.sfba.home.com@there> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 29 Oct 2001 16:49:39 -0600 Message-Id: <1004395779.1570.37.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Whoops, my scripts need to be a little smarter... Give me a little while, I'll put one up. -Eric On Mon, 2001-10-29 at 13:44, Micah Yoder wrote: > On Monday 29 October 2001 10:26 am, Steve Lord wrote: > > > seems fairly robust, there is a patch for this on the ftp site: > > > > ftp://oss.sgi.com/projects/xfs/download/patches > > Actually, no there isn't! I see patches for 2.4.6 to 2.4.12, plus some > 2.4.14-pre patches. No 2.4.13! > > -- > Like to travel? http://TravTalk.org > Micah Yoder Internet Development http://yoderdev.com -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Oct 29 15:14:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9TNEwr23226 for linux-xfs-outgoing; Mon, 29 Oct 2001 15:14:58 -0800 Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9TNEr023203 for ; Mon, 29 Oct 2001 15:14:53 -0800 Received: from brocade.com (amitc-linux [192.168.198.232]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id PAA14728; Mon, 29 Oct 2001 15:14:37 -0800 (PST) Message-ID: <3BDDE44B.1040905@brocade.com> Date: Mon, 29 Oct 2001 15:20:43 -0800 From: Amit D Chaudhary User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010913 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com CC: Robert Sander Subject: Re: process hang with xfs 1.0.1 References: <3BC7950E.8030807@brocade.com> <200110131403.f9DE3QJ01897@jen.americas.sgi.com> <20011013195809.A1617@epigenomics.com> <3BC8CCBE.50903@brocade.com> <20011014153548.A6910@epigenomics.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Just an FYI as it might be useful to those using xfs 1.0.1. The fix to the problem originally reported by me is to have the mmap_sem as rw_semaphore and the new rw_semaphore implementation as in 2.4.7. So though xfs_read showed up in stack trace during the process hang, this was more of a mainline kernel fix. Robert's tip that 2.4.7 fixes it helped. Thanks and Regards Amit Robert Sander wrote: > On Sat, Oct 13, 2001 at 04:22:38PM -0700, Amit D Chaudhary wrote: > >> >>Robert Sander wrote: >> >> >>>OK, using 2.4.12 or later was not an option because the aacraid >>>patch for the Dell RAID controller was not working. >>> >>>But with 2.4.7 this particular problem went away now. >>> >>Did you use xfs 1.0.1 with kernel 2.4.7? >> > > No, I took the patch for 2.4.7 from oss.sgi.com, I think > all these patches are "just" minor changes from 1.0.1 to > match the current kernel and have some bug fixes in them. > > Greetings > From owner-linux-xfs@oss.sgi.com Mon Oct 29 15:44:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9TNixr27027 for linux-xfs-outgoing; Mon, 29 Oct 2001 15:44:59 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9TNiu027002 for ; Mon, 29 Oct 2001 15:44:56 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA07348 for ; Mon, 29 Oct 2001 15:44:55 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA29792 for linux-xfs@oss.sgi.com; Tue, 30 Oct 2001 10:43:34 +1100 (EST) Date: Tue, 30 Oct 2001 10:43:34 +1100 (EST) From: Nathan Scott Message-Id: <200110292343.KAA29792@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - acl_set Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Oct 29 15:43:01 PST 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:105657a linux/fs/xfs/xfs_acl.c - 1.9 - The fix for the acl_set ACL validity problem was a little too strict, and didn't allow the special case of ACL_NOT_PRESENT in the ae_cnt which is used to signify "delete this ACL". This simple fix allows that special case through, and the ACL QA tests all pass again. From owner-linux-xfs@oss.sgi.com Mon Oct 29 15:47:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9TNlcs27237 for linux-xfs-outgoing; Mon, 29 Oct 2001 15:47:38 -0800 Received: from be-research.ucsd.edu (be-research.ucsd.edu [132.239.236.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9TNla027212 for ; Mon, 29 Oct 2001 15:47:36 -0800 Received: from woodson.ucsd.edu (woodson.ucsd.edu [132.239.236.12]) by be-research.ucsd.edu (8.11.1/8.11.1) with ESMTP id f9TNlZ020649 for ; Mon, 29 Oct 2001 15:47:35 -0800 (PST) Received: from localhost (drew@localhost) by woodson.ucsd.edu (8.11.1/8.9.1/SOE-nullclient-1998.12.16) with ESMTP id f9TNlYa1293816 for ; Mon, 29 Oct 2001 15:47:35 -0800 (PST) X-Authentication-Warning: woodson.ucsd.edu: drew owned process doing -bs Date: Mon, 29 Oct 2001 15:47:34 -0800 From: Drew Schaffner To: Subject: 2.4.13 Patch Available? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Is there a patch against the current stable kernel release 2.4.13 available? I looked at ftp://oss.sgi.com/projects/xfs/download/patches/ and it skips 2.4.13, it goes from 2.4.6 through 2.4.14-pre3 but 2.4.13 is missing. I was hoping to use 2.4.13 to get Andreas Dilger's /dev/random fixes among other things. Thanks, Drew Schaffner From owner-linux-xfs@oss.sgi.com Mon Oct 29 17:30:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9U1U4W29464 for linux-xfs-outgoing; Mon, 29 Oct 2001 17:30:04 -0800 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9U1Tx029429 for ; Mon, 29 Oct 2001 17:29:59 -0800 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 514C7C00B61 for ; Tue, 30 Oct 2001 09:29:56 +0800 (PHT) Received: from mrtg.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 58BE9C00B60 for ; Tue, 30 Oct 2001 09:29:54 +0800 (PHT) Date: Tue, 30 Oct 2001 09:29:54 +0800 (PHT) From: Federico Sevilla III To: Linux XFS Mailing List Subject: Re: 2.4.13 Patch Available? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 29 Oct 2001 at 15:47, Drew Schaffner wrote: > Is there a patch against the current stable kernel release 2.4.13 > available? I looked at > ftp://oss.sgi.com/projects/xfs/download/patches/ and it skips 2.4.13, > it goes from 2.4.6 through 2.4.14-pre3 but 2.4.13 is missing. There is one now. I do believe this was a case of Eric's script going bonkers a bit. He fixed it, it seems. :) > I was hoping to use 2.4.13 to get Andreas Dilger's /dev/random fixes > among other things. If they're in the mainline Linux kernel, they're in the XFS tree as well. :) --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Tue Oct 30 00:49:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9U8npW05862 for linux-xfs-outgoing; Tue, 30 Oct 2001 00:49:51 -0800 Received: from sqf1373.britain.agilent.com ([192.25.22.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9U8ng005840 for ; Tue, 30 Oct 2001 00:49:43 -0800 Received: from agilent.com (IDENT:mcowe@localhost [127.0.0.1]) by sqf1373.britain.agilent.com (8.9.3/8.9.3) with ESMTP id IAA16575 for ; Tue, 30 Oct 2001 08:49:36 GMT Message-ID: <3BDE69A0.1130A061@agilent.com> Date: Tue, 30 Oct 2001 08:49:36 +0000 From: Malcolm Cowe Organization: Agilent Technologies UK Ltd. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.18-mosix i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Followup: XFS 1.0.1 Install Problems References: <3BD5919D.9EF74294@agilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk You may remember that I was having problems using XFS on an HP NetServer last week using the XFS installer for RH 7.1. After much rooting around, it appears that the problem may have to do with a conflict between the kernel driver for the NetRAID SCSI interface included with the server (a NetRAID 2M card in this instance), and the firmware distributed by HP. Apparently the firmware isn't particularly good at 64 bit addressing. >From the "megaraid.c" driver source (linux 2.4.9): * * Check added for HP 1M/2M controllers if having firmware H.01.07 or * H.01.08. If found, disable 64 bit support since these firmware have * limitations for 64 bit addressing * This conflict has been resolved in newer kernel revisions, and so I am confident that I will be able to use XFS in future projects on this hardware platform. I cannot say for certain that this was the contributing factor, but it appears to have been the most likely cause, and is not necessarily XFS specific since the recommendation is to upgrade the driver on all RH 7.1 based systems. Regards, -- Malcolm Cowe. IT | Technical Computing, Telephone: +44 131 331 6466 Agilent Technologies Ltd. Telnet: 313-3466 Malcolm Cowe wrote: > > Hi, > > I've spent part of today trying to install an XFS enabled RH 7.1 > distribution based on your ISO cdrom image. However, when the system > reboots after the install completes, I get the following error just > after the kernel uncompresses: > > invalid compressed format > -- System halted > > From searching the Web, there doesn't appear to be any conclusive > discussion about what this error means. The most likely answer is that > the kernel image has been corrupted, but I don't know how that could be > -- I put a separate 32MB /boot partition right at the start of the disk, > and use ext2 for it. > > I'm using a NetServer LH3000 from HP with a NetRAID 2M card configured > for 2x36GB disks in RAID 1. I have tried installing a stock RH system > with the same file system layout, and it succeeds. If I have to create > my own kernel image, are there any fs conversion tools to help me? Also, > which kernel revision would you recommend (we are sticking with 2.4.9 > for the most part since it appears more stable than the newer releases)? > > If you can help, I'd appreciate it. > > -- > Malcolm Cowe. > IT | Technical Computing, Telephone: +44 131 331 6466 > Agilent Technologies Ltd. Telnet: 313-3466 From owner-linux-xfs@oss.sgi.com Tue Oct 30 01:53:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9U9ro114981 for linux-xfs-outgoing; Tue, 30 Oct 2001 01:53:50 -0800 Received: from s1.uklinux.net (ns1.uklinux.net [212.1.130.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9U9rl014956 for ; Tue, 30 Oct 2001 01:53:47 -0800 Received: from pyewacket.nic.uklinux.net (host213-1-188-180.btinternet.com [213.1.188.180]) (authenticated) by s1.uklinux.net (8.11.6/8.11.6) with ESMTP id f9U9rjf21289 for ; Tue, 30 Oct 2001 09:53:45 GMT Envelope-To: Received: from [127.0.0.1] (helo=there) by pyewacket.nic.uklinux.net with smtp (Exim 3.22 #1) id 15yV3h-0000UO-00 for linux-xfs@oss.sgi.com; Tue, 30 Oct 2001 09:19:45 +0000 Content-Type: text/plain; charset="iso-8859-1" From: nic Reply-To: nic@uklinux.net Organization: Quixotic Hackers To: linux-xfs Subject: grub rpms w/xfs Date: Tue, 30 Oct 2001 09:19:44 +0000 X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi all, If anyones interested, I've taken RedHat 7.2's grub 0.90 rpm and put Serguei Tzukanov's xfs+jfs patch on the end. No doubt, the SGI folks have already done this but I thought that some of you might want to play. :-) http://www.nic.uklinux.net/src/rpms/ nic From owner-linux-xfs@oss.sgi.com Tue Oct 30 03:20:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9UBKG016863 for linux-xfs-outgoing; Tue, 30 Oct 2001 03:20:16 -0800 Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9UBKC016841 for ; Tue, 30 Oct 2001 03:20:13 -0800 Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.33 #1) id 15yWvM-0007dX-00; Tue, 30 Oct 2001 12:19:16 +0100 To: Drew Schaffner Cc: Subject: Re: 2.4.13 Patch Available? References: From: Florian Weimer Date: 30 Oct 2001 12:19:16 +0100 In-Reply-To: (Drew Schaffner's message of "Mon, 29 Oct 2001 15:47:34 -0800") Message-ID: Lines: 11 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Drew Schaffner writes: > I was hoping to use 2.4.13 to get Andreas Dilger's /dev/random fixes > among other things. They aren't in 2.4.13 as far as I know. -- Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 From owner-linux-xfs@oss.sgi.com Tue Oct 30 06:33:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9UEXov23582 for linux-xfs-outgoing; Tue, 30 Oct 2001 06:33:50 -0800 Received: from eclectic.kluge.net (IDENT:root@dsl092-071-242.bos1.dsl.speakeasy.net [66.92.71.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9UEXk023558 for ; Tue, 30 Oct 2001 06:33:47 -0800 Received: (from felicity@localhost) by eclectic.kluge.net (8.11.6/8.11.6) id f9UEXjm25055 for linux-xfs@oss.sgi.com; Tue, 30 Oct 2001 09:33:45 -0500 Date: Tue, 30 Oct 2001 09:33:45 -0500 From: Theo Van Dinter To: linux-xfs@oss.sgi.com Subject: Upgrading RH 7.1 to 7.2 w/ XFS Message-ID: <20011030093345.D24814@kluge.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I joined the list a few days ago, mostly to find out what (if any) procedure existed to upgrade a 7.1-XFS box to 7.2-XFS ... The responses have pretty much all been "wait for the installer", which probably is the best course of action for most folks. Just so people know it's possible though, I spent a few hours and went through manually to upgrade one of my XFS-enabled boxes to 7.2. It essentially involved a lot of 'rpm -Fvh [x-z]*rpm' type runs, and it took a while to figure out all of the non-specific dependencies (/sbin/ip is in the iproute RPM BTW.) The only things I have left to do are kernel and X upgrades. I grabbed the 2.4.9 RPMs from the sgi/testing FTP area, and need to recompile the video board FB driver (NVidia) for the new kernel before X will be complete. I should then be able to convert my last ext2 partition to ext3 while leaving the rest of the system as XFS. (One day I'll buy a bigger drive and properly migrate that filesystem ... Couldn't do the backup/mkfs/restore shuffle with my currently available space.) The biggest problem was the Gnome bits which took a little to determine the new pacakges that needed installing. If you have a server-install (ie: no/little X), it should be much simpler. I have one I'm going to look at upgrading tonight or tomorrow in hopefully a much shorter time. -- Randomly Generated Tagline: "Outside of traffic, there is nothing that has held this country back as much as committees." - Will Rodgers From owner-linux-xfs@oss.sgi.com Tue Oct 30 07:16:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9UFGiB27495 for linux-xfs-outgoing; Tue, 30 Oct 2001 07:16:44 -0800 Received: from ns.procomp.net (ns.procomp.net [195.109.47.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9UFGe027469 for ; Tue, 30 Oct 2001 07:16:40 -0800 Received: from port001 (floink.xs4all.nl [213.84.65.168]) by ns.procomp.net (8.10.0/8.10.0) with SMTP id f9UFG9U13871 for ; Tue, 30 Oct 2001 16:16:09 +0100 Reply-To: From: "Joost van der Locht" To: Subject: Patching Kernel 2.4.13 (with LVM patch 1.0.1.rc4) Date: Tue, 30 Oct 2001 16:16:38 +0100 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I try to patch a 2.4.13 Kernel with the LVM 1.0.1.rc4 patch installed. Now I get some errors that some patches already have been applied. It asks for Assume -R? What to do? Joost van der Locht Technisch Directeur E*Cube BV Toernooiveld 214 - 6525 EC Nijmegen T: 024-3500437 - F: 024-3500613 http://www.e-cube.nl e-mail: joost@e-cube.nl ICQ UIN: 494145 From owner-linux-xfs@oss.sgi.com Tue Oct 30 07:33:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9UFXOR28045 for linux-xfs-outgoing; Tue, 30 Oct 2001 07:33:24 -0800 Received: from mailout05.sul.t-online.de (mailout05.sul.t-online.com [194.25.134.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9UFXM028023 for ; Tue, 30 Oct 2001 07:33:22 -0800 Received: from fwd00.sul.t-online.de by mailout05.sul.t-online.de with smtp id 15yatE-0003Gv-02; Tue, 30 Oct 2001 16:33:20 +0100 Received: from home.sky.net (520031304466-0001@[217.80.58.158]) by fmrl00.sul.t-online.com with esmtp id 15yat3-08l5aiC; Tue, 30 Oct 2001 16:33:09 +0100 Received: from fzzgrr by home.sky.net with local (Exim 3.32 #1 (Debian)) id 15yauW-00011F-00; Tue, 30 Oct 2001 16:34:40 +0100 Date: Tue, 30 Oct 2001 16:34:39 +0100 From: Ulrich Wiederhold To: linux-xfs@oss.sgi.com Subject: Patches for ac-Kernels Message-ID: <20011030163439.A3851@sky.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.3.23i Organization: Using Linux Only X-Operating-System: Debian GNU/Linux testing/unstable (Kernel 2.4.13-xfs) X-Sender: 520031304466-0001@t-dialin.net Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f9UFXM028024 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, please CC me, because I am not subscribed. I am looking for a xfs-patch to a current ac-Kernel. I know, that you don´t support the ac-kernel-series, but I would like to test the other VM in there and can´t do it without the xfs patch. Perhaps anybody got a patch working with Alans kernels and could send it to me? Thanks a lot. Uli -- 'The box said, 'Requires Windows 95 or better', so i installed Linux - TKK 5 From owner-linux-xfs@oss.sgi.com Tue Oct 30 07:50:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9UForL28574 for linux-xfs-outgoing; Tue, 30 Oct 2001 07:50:53 -0800 Received: from s1.uklinux.net (ns1.uklinux.net [212.1.130.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9UFon028551 for ; Tue, 30 Oct 2001 07:50:49 -0800 Received: from pyewacket.nic.uklinux.net (host213-122-6-57.btconnect.com [213.122.6.57]) (authenticated) by s1.uklinux.net (8.11.6/8.11.6) with ESMTP id f9UFoj728375; Tue, 30 Oct 2001 15:50:45 GMT Envelope-To: linux-xfs@oss.sgi.com Received: from [127.0.0.1] (helo=there) by pyewacket.nic.uklinux.net with smtp (Exim 3.22 #1) id 15ybAD-0000oB-00; Tue, 30 Oct 2001 15:50:53 +0000 Content-Type: text/plain; charset="iso-8859-1" From: nic Reply-To: nic@uklinux.net Organization: Quixotic Hackers To: Theo Van Dinter , linux-xfs@oss.sgi.com Subject: [OT] Re: Upgrading RH 7.1 to 7.2 w/ XFS Date: Tue, 30 Oct 2001 15:50:52 +0000 X-Mailer: KMail [version 1.3.1] References: <20011030093345.D24814@kluge.net> In-Reply-To: <20011030093345.D24814@kluge.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tuesday 30 October 2001 14:33, Theo Van Dinter wrote: My experience was similar (and moving rapidly off topic) The other important gotcha is for people who build their own kernels is that you have to have netlink compiled in or you can't talk to the network... Playing around with linuxconf (I never usually use this, but I was attempting to get the card up the "Red Hat way") also shows that they assume network cards are compiled as modules if you use this tool. Whatever. I won't be running it again, anyway. For those who want grub (standard for virgin 7.2 installs), see my previous message. Very OT-gripes: have to build xemacs from src rpm, exim isn't in the cheap version at all (and isn't on rhn). Otherwise pretty damn good (with apologies to other distro users and employees). nic From owner-linux-xfs@oss.sgi.com Tue Oct 30 07:55:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9UFtrD28812 for linux-xfs-outgoing; Tue, 30 Oct 2001 07:55:53 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9UFtn028790 for ; Tue, 30 Oct 2001 07:55:49 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA13936 for ; Tue, 30 Oct 2001 07:55:42 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA3441268 for ; Tue, 30 Oct 2001 09:54:32 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA17922 for ; Tue, 30 Oct 2001 09:54:32 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id f9UFnq622052; Tue, 30 Oct 2001 09:49:52 -0600 Message-Id: <200110301549.f9UFnq622052@jen.americas.sgi.com> Date: Tue, 30 Oct 2001 09:49:52 -0600 Subject: TAKE - merge upto 2.4.14-pre5 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk More VM tweaking, plus a couple of fixes which have been requested on the list - paride/pcd.c build fix and random device fix, both from Linus not me. Date: Tue Oct 30 07:53:18 PST 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:105709a linux/mm/vmscan.c - 1.85 linux/mm/swapfile.c - 1.43 linux/mm/swap_state.c - 1.35 linux/mm/swap.c - 1.18 linux/mm/page_io.c - 1.18 linux/mm/page_alloc.c - 1.64 linux/mm/memory.c - 1.66 linux/mm/filemap.c - 1.95 linux/kernel/ksyms.c - 1.115 linux/include/linux/pagemap.h - 1.34 linux/include/linux/mm.h - 1.70 linux/fs/buffer.c - 1.92 linux/drivers/char/random.c - 1.21 linux/drivers/block/paride/pcd.c - 1.13 linux/drivers/block/ll_rw_blk.c - 1.79 linux/Makefile - 1.146 linux/drivers/char/drm/drmP.h - 1.14 linux/arch/i386/kernel/apic.c - 1.21 linux/mm/shmem.c - 1.21 linux/drivers/char/drm/drm_vm.h - 1.6 From owner-linux-xfs@oss.sgi.com Tue Oct 30 08:04:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9UG4tt29253 for linux-xfs-outgoing; Tue, 30 Oct 2001 08:04:55 -0800 Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9UG4q029230 for ; Tue, 30 Oct 2001 08:04:52 -0800 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9UG4j56065770; Tue, 30 Oct 2001 17:04:45 +0100 (CET) Message-Id: <4.3.2.7.2.20011030165317.036dfd20@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 30 Oct 2001 17:03:00 +0100 To: Ulrich Wiederhold , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Patches for ac-Kernels In-Reply-To: <20011030163439.A3851@sky.net> 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 f9UG4q029232 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 16:34 30-10-2001 +0100, Ulrich Wiederhold wrote: >Hello, >please CC me, because I am not subscribed. >I am looking for a xfs-patch to a current ac-Kernel. >I know, that you don´t support the ac-kernel-series, but I would like to >test the other VM in there and can´t do it without the xfs patch. >Perhaps anybody got a patch working with Alans kernels and could send it >to me? >Thanks a lot. Mandrake folks use the -ac kernels for their distribution. You can find their 2.4.13 mdk kernels in the cooker directory. http://ftp.sunet.se/ would be a good start. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Tue Oct 30 09:48:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9UHms532069 for linux-xfs-outgoing; Tue, 30 Oct 2001 09:48:54 -0800 Received: from umbi3.umbi.umd.edu (umbi3.umbi.umd.edu [136.160.7.51]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9UHmp032047 for ; Tue, 30 Oct 2001 09:48:51 -0800 Received: from umbi.umd.edu (amanda.carb.nist.gov [129.6.113.5]) by umbi3.umbi.umd.edu (Netscape Messaging Server 4.15) with ESMTP id GM15HG00.52Y for ; Tue, 30 Oct 2001 12:48:52 -0500 Message-ID: <3BDEE801.C1727CCA@umbi.umd.edu> Date: Tue, 30 Oct 2001 12:48:49 -0500 From: Jonathan Dill Organization: CARB X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Linux XFS Mailing List Subject: 2.4.9 /dev/nst1 "Bad file descriptor" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Since upgrading from 2.4.3 to the 2.4.9 prerelease kernels, long tape writes fail after 1-2 GB on a 20 GB native tape with "Bad file descriptor" on /dev/nst1. I switched back to the 2.4.3 kernel and the tapedrive is working fine. When I get caught up on my backups and have some time to play with it, I'll send some more info. I'm just hoping that someone may have heard of a problem like this and know what causes it. -- "Jonathan F. Dill" (dill@umbi.umd.edu) CARB IT Coordinator Experimental Support Site http://concept.umbi.umd.edu From owner-linux-xfs@oss.sgi.com Tue Oct 30 10:34:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9UIY5o02206 for linux-xfs-outgoing; Tue, 30 Oct 2001 10:34:05 -0800 Received: from fs1.theiqgroup.com (fs1.theiqgroup.com [216.81.249.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9UIY0002184 for ; Tue, 30 Oct 2001 10:34:00 -0800 Received: from theiqgroup.com (funkmotor.theiqgroup.com [216.81.249.21]) by fs1.theiqgroup.com (8.11.0/8.11.0) with ESMTP id f9UIXk501802; Tue, 30 Oct 2001 12:33:46 -0600 Message-ID: <3BDEF28A.5080301@theiqgroup.com> Date: Tue, 30 Oct 2001 12:33:46 -0600 From: Kelly Corbin Organization: The IQ Group, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Eric Sandeen CC: linux-xfs@oss.sgi.com Subject: Re: Who / What's using Linux XFS? References: <1004379839.13361.47.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Here at the IQ Group, Inc. we use XFS for all our production and development servers. Our OS of choice is Slackware Linux 8.0. Our hardware of choice is Dell and VALinux servers. As for applications, we run the standard Unix/Linux apps like Sendmail, Apache, BIND, DHCP, iptables, etc.; as well as Oracle 9i and Arkeia. We've been running XFS across the board for about 3 months now without a hitch (so far). Size-wise, our biggest server is about 40 GB, but that will be increasing substantially in the near future. Our production servers are collocated so a journaled FS was a must. Reboots are quick and no human interaction is required like with a bad fsck on ext2. Additionally, our database servers gain additional integrity and robustness. We originally chose XFS over ReiserFS and ext3 because of it's age (it's been in production on SGI boxes for probably longer than all the other journalling FS's combined) and it's speed appeared comparable as well. Hope this is what you were looking for. Kelly -- -------------------------------------------- -- Kelly Corbin -- Systems Administrator -- -- http://www.theiqgroup.com -- The Future of eServices... -- -- The IQ Group, Inc. -- 6740 Antioch Suite 110 -- Merriam, KS 66204 -- (913)-722-6700 x105 -- Fax (913)722-7264 -------------------------------------------- From owner-linux-xfs@oss.sgi.com Tue Oct 30 11:12:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9UJChL03739 for linux-xfs-outgoing; Tue, 30 Oct 2001 11:12:43 -0800 Received: from rcmls02.va.mediaone.net (rcmls02.va.mediaone.net [24.30.225.41]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9UJCe003714 for ; Tue, 30 Oct 2001 11:12:40 -0800 Received: from Default (va-65-97-0-63.va.mediaone.net [65.97.0.63]) by rcmls02.va.mediaone.net (8.11.1/8.11.1) with SMTP id f9UJB7j26707 for ; Tue, 30 Oct 2001 14:11:07 -0500 (EST) Message-ID: <002601c1618f$41338e80$6501a8c0@va.mediaone.net> From: "Mark Pruett" To: References: <4.3.2.7.2.20011029193944.036e1710@pop.xs4all.nl> Subject: Linux XFS on Alpha's Date: Tue, 30 Oct 2001 14:07:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Is anyone here using XFS on Linux on the Alpha platform? We've been testing both XFS and Reiserfs, and we always get problems requiring xfs_repair during power-off tests (where we intentionally kill power during disk writes.) We invariably lose the directory to which the files were written, and end up with a huge number of files in lost+found. On the Intel platform, we don't see this behavior. regards, Mark Pruett From owner-linux-xfs@oss.sgi.com Tue Oct 30 11:30:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9UJUN704312 for linux-xfs-outgoing; Tue, 30 Oct 2001 11:30:23 -0800 Received: from imapserverb.fnal.gov (imapserverb.fnal.gov [131.225.9.17]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9UJUK004290 for ; Tue, 30 Oct 2001 11:30:20 -0800 Received: from imapserverb.fnal.gov ([131.225.9.17]) by imapserverb.fnal.gov (Netscape Messaging Server 4.15) with SMTP id GM1A6I00.HUN for ; Tue, 30 Oct 2001 13:30:18 -0600 Received: from fnal.gov ([131.225.7.82]) by imapserverb.fnal.gov (NAVIEG 2.1 bld 63) with SMTP id M2001103013301816927 for ; Tue, 30 Oct 2001 13:30:18 -0600 Message-ID: <3BDEFFCB.4E1099A2@fnal.gov> Date: Tue, 30 Oct 2001 13:30:19 -0600 From: yocum@fnal.gov X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: xfs-list Subject: 2.2.12 CVS not complete? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi all, It appears that the 2.2.12 kernel isn't in the CVS rep correctly - almost all of the i2o stuff (and maybe more) is missing and 'make menuconfig/xconfig` fails miserably. Any ideas? Thanks, Dan -- Dan Yocum Sloan Digital Sky Survey, Fermilab 630.840.6509 yocum@fnal.gov, http://www.sdss.org SDSS. Mapping the Universe. From owner-linux-xfs@oss.sgi.com Tue Oct 30 11:39:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9UJdmS04580 for linux-xfs-outgoing; Tue, 30 Oct 2001 11:39:48 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9UJdj004558 for ; Tue, 30 Oct 2001 11:39:45 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA01731 for ; Tue, 30 Oct 2001 11:39:08 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA3282064; Tue, 30 Oct 2001 13:38:28 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA11303; Tue, 30 Oct 2001 13:38:28 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id f9UJXk128852; Tue, 30 Oct 2001 13:33:46 -0600 Subject: Re: 2.2.12 CVS not complete? From: Steve Lord To: yocum@fnal.gov Cc: xfs-list In-Reply-To: <3BDEFFCB.4E1099A2@fnal.gov> References: <3BDEFFCB.4E1099A2@fnal.gov> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16 (Preview Release) Date: 30 Oct 2001 13:33:46 -0600 Message-Id: <1004470426.28754.4.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2001-10-30 at 13:30, yocum@fnal.gov wrote: > Hi all, > > It appears that the 2.2.12 kernel isn't in the CVS rep correctly - almost > all of the i2o stuff (and maybe more) is missing and 'make > menuconfig/xconfig` fails miserably. > > Any ideas? > > Thanks, > Dan I do remember one or two releases where the code was in transit between directories, but I remember these as being pre-xxx kernels. How are you getting a 2.4.12 kernel out of the tree - since we are at 2.4.14-pre5 right now and there are no tags in the tree. Can you try one of the patches from the ftp site? Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Oct 30 11:55:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9UJtUQ05009 for linux-xfs-outgoing; Tue, 30 Oct 2001 11:55:30 -0800 Received: from c011.snv.cp.net (c011-h013.c011.snv.cp.net [209.228.34.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9UJtL004986 for ; Tue, 30 Oct 2001 11:55:22 -0800 Received: (cpmta 23329 invoked from network); 30 Oct 2001 11:55:16 -0800 Date: 30 Oct 2001 11:55:16 -0800 Message-ID: <20011030195516.23328.cpmta@c011.snv.cp.net> X-Sent: 30 Oct 2001 19:55:16 GMT Received: from [209.187.169.169] by mail.metconnect.com with HTTP; 30 Oct 2001 11:55:16 PST Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 To: linux-xfs@oss.sgi.com From: kent robotti X-Mailer: Web Mail 3.9.3.5 X-Sent-From: robotti@metconnect.com Subject: Who / What's using Linux XFS? Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi all - I'd like to put a page up on the web site detailing the various applications, distributions, installations, and embedded products using XFS for Linux. I'd appreciate some submissions; examples below. Thanks! -Eric This is a cd boot/rescue system with XFS support. This is the home page for it. http://www.tux.org/pub/people/kent-robotti/looplinux/rip/index.html Begin3 Title: RIP Version: 42 Entered-date: 15OCT2001 Description: Small ram linux system for the purpose of system booting or repairing, a boot/rescue system. You can put this system on a cd disk and boot it. It's more or less designed for non-networked, stand-alone, home pc hard drive boot/rescue/backup! It has large file support, you can use the programs mke2fs, mkdosfs, mkreiserfs, mkfs.xfs, mkfs.jfs, split, mount, tar, gzip,bzip2, and busybox for files larger than 2GB! You can only have files larger than 2GB on a ext2/3, reiserfs, jfs, or xfs partition. The programs e2fsck, mke2fs, and tune2fs have ext3 filesystem support. It includes the fat16/32, ext2/3, and reiserfs partition resizing programs 'parted, resize_reiserfs'. It also includes the partition image program 'partimage' which saves partitions in the ext2, ext3, reiserfs, jfs, xfs, ntfs, fat16, and fat32 formats to an image file. Only used blocks are copied to save space and increase the speed. The image file can be compressed, in gzip, or bzip2 formats. It also includes the 'mc' file manager! It has support for these filesystems. ext2 iso9660 jfs msdos ntfs reiserfs ufs umsdos vfat xfs The kernel is version 2.4.12, it has support for IDE and SCSI hard drives. You need at least 12mb of RAM and a 486dx CPU to boot it. Keywords: CD Boot/Rescue System! Author: robotti@metconnect.com (Kent Robotti) Maintained-by: Primary-site: ftp://ibiblio.org/pub/Linux/system/recovery rip-42.iso.bin 3616Kb Alternate-site: Platforms: Linux or dos/win system. Copying-policy: GPL End This is a root image with XFS support, it allows you to install the slackware linux distribution on a dos/win9x system, using the loop device or a umsdos filesystem. You can also install slackware on it's own linux partition. loopslak.bin 1404kb This is the home page for it. http://www.tux.org/pub/people/kent-robotti/looplinux ftp://ftp.tux.org/pub/people/kent-robotti/looplinux There's more info at the above site. From owner-linux-xfs@oss.sgi.com Tue Oct 30 12:03:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9UK3sC05464 for linux-xfs-outgoing; Tue, 30 Oct 2001 12:03:54 -0800 Received: from imapserverb.fnal.gov (imapserverb.fnal.gov [131.225.9.17]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9UK3k005440 for ; Tue, 30 Oct 2001 12:03:47 -0800 Received: from imapserverb.fnal.gov ([131.225.9.17]) by imapserverb.fnal.gov (Netscape Messaging Server 4.15) with SMTP id GM1BQ900.EXQ for ; Tue, 30 Oct 2001 14:03:45 -0600 Received: from fnal.gov ([131.225.7.82]) by imapserverb.fnal.gov (NAVIEG 2.1 bld 63) with SMTP id M2001103014034508767 ; Tue, 30 Oct 2001 14:03:45 -0600 Message-ID: <3BDF07A2.4810BBE6@fnal.gov> Date: Tue, 30 Oct 2001 14:03:46 -0600 From: yocum@fnal.gov X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: xfs-list Subject: Re: 2.2.12 CVS not complete? References: <3BDEFFCB.4E1099A2@fnal.gov> <1004470426.28754.4.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve, Steve Lord wrote: > > On Tue, 2001-10-30 at 13:30, yocum@fnal.gov wrote: > > Hi all, > > > > It appears that the 2.2.12 kernel isn't in the CVS rep correctly - almost > > all of the i2o stuff (and maybe more) is missing and 'make > > menuconfig/xconfig` fails miserably. > > > > Any ideas? > > > > Thanks, > > Dan > > I do remember one or two releases where the code was in transit between > directories, but I remember these as being pre-xxx kernels. How are you > getting a 2.4.12 kernel out of the tree - since we are at 2.4.14-pre5 > right now and there are no tags in the tree. Can you try one of the cvs -z3 co -D "October 11, 2001 21:00:00 UTC" linux-2.4-xfs I've done this a lot with other versions with no problems. > patches from the ftp site? Sure... yep. That appears to work. I forgot the patches were available via ftp. It's still odd that the above doesn't work, tho. Cheers, Dan -- Dan Yocum Sloan Digital Sky Survey, Fermilab 630.840.6509 yocum@fnal.gov, http://www.sdss.org SDSS. Mapping the Universe. From owner-linux-xfs@oss.sgi.com Tue Oct 30 12:54:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9UKsEB06793 for linux-xfs-outgoing; Tue, 30 Oct 2001 12:54:14 -0800 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9UKsA006770 for ; Tue, 30 Oct 2001 12:54:10 -0800 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id 894FD67043 for ; Tue, 30 Oct 2001 21:54:03 +0100 (CET) Subject: mongo pl ...... To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Tue, 30 Oct 2001 21:54:02 +0100 X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.0.8 |June 18, 2001) at 30.10.2001 21:54:03 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f9UKsB006771 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I often read about people who are using this program to check the stability of her filesystems ;-)..... So I decided to check it also out, but the only thing i found was the program on the reiserfs homepage, but I found no possibility to check xfs with it. Can you please give me some hints to get this working?? thanx in advance wali ps: we're running xfs on 4 netinstallservers with each 75GB of diskspace under SuSE 7.2 From owner-linux-xfs@oss.sgi.com Tue Oct 30 13:02:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9UL26D07109 for linux-xfs-outgoing; Tue, 30 Oct 2001 13:02:06 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9UL1I007075 for ; Tue, 30 Oct 2001 13:01:18 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id WAA965470 for ; Tue, 30 Oct 2001 22:01:15 +0100 (CET) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA3428999; Tue, 30 Oct 2001 14:59:56 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA26198; Tue, 30 Oct 2001 14:59:56 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id f9UKtEW29027; Tue, 30 Oct 2001 14:55:14 -0600 Subject: Re: mongo pl ...... From: Steve Lord To: Michael Wahlbrink Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: multipart/mixed; boundary="=-DQuksTfs0R34p/bwuRw+" X-Mailer: Evolution/0.16 (Preview Release) Date: 30 Oct 2001 14:55:14 -0600 Message-Id: <1004475314.28754.36.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-DQuksTfs0R34p/bwuRw+ Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2001-10-30 at 14:54, Michael Wahlbrink wrote: > Hi, > I often read about people who are using this program to check the stability of > her filesystems ;-)..... > So I decided to check it also out, but the only thing i found was the program on > the reiserfs homepage, but I found no possibility to check xfs with it. Can you > please give me some hints to get this working?? > > thanx in advance > wali > > ps: we're running xfs on 4 netinstallservers with each 75GB of diskspace under > SuSE 7.2 Modified mongo.pl attached Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com --=-DQuksTfs0R34p/bwuRw+ Content-Type: text/x-perl Content-Disposition: attachment; filename=mongo.pl Content-Transfer-Encoding: 7bit #!/usr/bin/perl # # Copyright 2000 by Hans Reiser, licensing governed by reiserfs/README # # # Mongo.pl is reiserfs benchmark. # # To run please use run_mongo script or : # # # ./mongo.pl reiserfs /dev/xxxx /testfs log1 5 # or # # ./mongo.pl ext2 /dev/xxxx /testfs log2 5 # # 5 - number of processes, you can set any number here # # Test will format partition /dev/xxxx by 'mkreiserfs' or 'mke2fs' # mount it and run given number of processes during each phase : # Create, Copy, Symlinks, Read, Stats, Rename and Delete. # # Also, the program calc fragmentations after Create and Copy phases: # Fragm = number_of_fragments / number_of_files # (Current version use the files more than 16KB to calc Fragm.) # # You can find the same results in files : log, log.tbl, log_table # # log - raw results # log.tbl - results for compare program # log_table - results in table form # $EXTENDED_STATISTICS = 1; use POSIX; use File::stat; sub print_usage { print "\nUsage: mongo.pl "; print " \n"; print " - the name of filesystem [reiserfs|ext2]\n"; print " - the device for benchmark (e.g. /dev/hda9)\n"; print " - mount-point for the filesystem"; print " (e.g. /mnt/testfs)\n"; print " - the name prefix for benchmark results\n"; print " - the number of benchmark processes\n"; print "\nexamples:\n"; print "mongo.pl reiserfs /dev/hda9 /testfs reiserfs_results 1\n"; print "mongo.pl ext2 /dev/hda9 /testfs ext2_results 1\n"; print "\nThe results will be put in ./results directory\n"; } #------- Subroutines declaration -------- sub make_fsys; sub mongo_x_process; sub mongo_launcher; sub set_params; #------- main() ------------------------- if ( $#{ARGV} != 4 ) { print_usage; exit(0); } #-------------------------------------------- # Set working directories #-------------------------------------------- $TOPDIR = "$ENV{PWD}"; $RESDIR = "${TOPDIR}/results"; $HTMLDIR = "${RESDIR}/html"; $FILESYSTEM = $ARGV[0]; $DEVICE = $ARGV[1]; $TESTDIR = $ARGV[2]; $PROCESSES = $ARGV[4]; $LOGFILE = "${RESDIR}/${ARGV[3]}"; $LOGFILE2 = "${LOGFILE}_table"; $LOGFILE3 = "${LOGFILE}.tbl"; $TMPFILE = "${RESDIR}/mongo_tmp"; $nproc = $PROCESSES; $READIT = "${TOPDIR}/mongo_read"; $SLINKS = "${TOPDIR}/mongo_slinks"; #-------- reiser_fract_tree parameters---------------- $x1mb = 1024 * 1024; $x2mb = 2 * $x1mb; $x3mb = 3 * $x1mb; $x5mb = 5 * $x1mb; $x50mb = 50 * $x1mb; $x100mb = 100 * $x1mb; # Total amount of bytes in all files on test partition #----------------------------------------------------- $small_bytes = $x50mb; $medium_bytes = $x100mb; $big_bytes = $x100mb; $large_bytes = $x100mb; # Median size of files in bytes for first tree to create #------------------------------------------------------- $small_size = 100; $medium_size = 1000; $big_size = 10000; $large_size = 100000; # Keep the largest file to one fifth (100 million bytes) # of the total tree size. #------------------------------------------------------- $max_file_size = 100000000; # Yuri Shevchuk says that 0 is the median size # in real life, so I believe him. #---------------------------------------------- $median_dir_nr_files = 0; # This should be larger, change once done testing. #------------------------------------------------- $bytes_to_consume = 10000000; $median_file_size = 100; $max_file_size = 1000000; $median_dir_nr_files = 100; $max_directory_nr_files = 10000; $median_dir_branching = 0; $max_dir_branching = 1; # This should be varying, someday.... #------------------------------------ $write_buffer_size = 4096; @numb_of_bytes = ($small_bytes, $medium_bytes, $big_bytes, $large_bytes); @size_of_files = ($small_size, $medium_size, $big_size, $large_size); #@size_of_files = ($small_size); $reiser_fract_tree_rep_counter = 3; $total_params = $#{numb_of_bytes}; #... Make directories for results #-------------------------------- unless (-e $RESDIR) { print "Creating dir: ${RESDIR} \n"; system("mkdir $RESDIR"); } unless ( -e $HTMLDIR ) { print "Creating dir: ${HTMLDIR} \n"; system("mkdir $HTMLDIR"); } #... Compile *.c files if it is necessary #---------------------------------------- sub compile { my $file = shift @_; my $opt = shift @_ if @_ ; my $cfile = $file . ".c"; die "source file \"${cfile}\" does not exist" unless (-e "$cfile"); if ( -e "$file" && (stat("$file")->mtime >= stat("$cfile")->mtime)) { print "$file is up to date ...\n"; } else { print "Compiling ${cfile} ...\n"; system ("gcc $cfile -o $file $opt"); } } compile("reiser_fract_tree", "-lm"); compile("mongo_slinks"); compile("mongo_read"); compile("map5"); compile("summ"); #... Check the command string parameters #--------------------------------------- unless ( ($FILESYSTEM eq "reiserfs") or ($FILESYSTEM eq "ext2") or ($FILESYSTEM eq "xfs")) { print "mongo.pl: not valid filesystem name: ${FILESYSTEM} \n"; print "Usage: mongo.pl \n"; exit(0); } unless ( -b $DEVICE ) { print "mongo.pl: not valid device: ${DEVICE} \n"; print "Usage: mongo.pl \n"; exit(0); } #------- Subroutines -------------------------------------- #---------------------------------------------------------- sub get_blocks_usage ($) { my ($mp) = @_; my $df = `df -k $mp | tail -n 1`; chomp $df; my @items = split / +/, $df; return $items[2]; } sub make_fsys { system ("umount $TESTDIR") ; if ( $FILESYSTEM eq "reiserfs" ) { system("echo y | mkreiserfs $DEVICE") ; system("mount -t reiserfs $DEVICE $TESTDIR") ; } if ( $FILESYSTEM eq "ext2" ) { system("mke2fs $DEVICE") ; system("mount $DEVICE $TESTDIR") ; } if ( $FILESYSTEM eq "xfs" ) { system("mkfs -t xfs -f -l size=16384b $DEVICE") ; system("mount -o logbufs=8 $DEVICE $TESTDIR") ; } } #------------------------------------------------------------------ # Mongo Launcher #------------------------------------------------------------------ sub mongo_launcher { my ($phase_num, $phase_name, $cmd, $dir1, $dir2, $flag, $processes) = @_ ; print "$phase_num.$phase_name files of median size $median_file_size bytes ($p processes)...\n"; print LOG "********* Phase $phase_num: $phase_name files of median size $median_file_size bytes ($p processes) *********\n"; $i=0; $total=0; # eliminate the rep counter and the while while ( $i < $reiser_fract_tree_rep_counter ) { print "$phase_name : "; print LOG "$phase_name : "; $com = ""; $pp=$processes; $j=0; while ($pp > 0) { $pp--; # the fact that this if statement was necessary indicated you # attempted excessive generalization and abstraction where it was not # natural to the task that makes the code harder to understand. put # every command on one line to execute. I like it when I can read a # one line command and see what that phase of the test does instead of # looking in many places throughout the code. if ($phase_num == 1) { $com .= "$cmd $dir1-$i-$j $flag"; } elsif ($phase_num == 2) { $com .= "$cmd $dir1-$i-$j $dir2-$i-$j"; } elsif ($phase_num == 3) { $com .= "$cmd $dir1-$i-$j "."-type f | while read X; do echo \$X \$X.lnk ; done | $TOPDIR/mongo_slinks "; } elsif ($phase_num == 4) { $com .= "$cmd"; } elsif ($phase_num == 5) { $com .= "$cmd"; } elsif ($phase_num == 6) { $com .= "$cmd $dir1-$i-$j -type f | perl -e 'while (<>) { chomp; rename (\$_, \"\$_.r\"); };'"; #$com .= " & $cmd $dir2-$i-$j "."-type d -exec mv {} {}.r ';'"; } elsif ($phase_num == 7) { if ($processes > 1) { $com .= "$cmd $dir1-$i-$j & $cmd $dir2-$i-$j"; } else { $com .= "$cmd $dir1-$i-$j ; $cmd $dir2-$i-$j"; } } $com .= " & "; $j++; } $com .= " wait"; #print $com, "\n"; @t=`(time -p $com) 2>&1`; @tt = split ' ', $t[0]; $res = $tt[1]; unless ( $res =~ /\s*\d+/) { print @t , "\n"; print LOG @t, "\n"; } else { print LOG "$res sec.\n"; print "$res sec.\n"; } $total += $res; $i++; } print "total $phase_name time: $total sec.\n"; print LOG "total $phase_name time: $total sec.\n"; $ares[$phase_num]=$total; # ser array of results if ($EXTENDED_STATISTICS) { if( $phase_num < 3) { $used = get_blocks_usage($TESTDIR) - $used0; if ($phase_num == 1) { $used1=$used; }elsif($phase_num == 2){ $used2=$used; } print "Used disk space (df) : $used KB\n"; print LOG "Used disk space (df) : $used KB\n"; open (FIND_PIPE, "find $TESTDIR|") || die "cannnot open pipe from \"find\": $!\n"; $dirs = 0; $files = 0; $files16 = 0; while() { chomp; $st = lstat ($_); if (S_ISDIR($st->mode)) { $dirs ++; } elsif (S_ISREG($st->mode)) { $files ++; $files16 ++ if ($st->size > 16384); } } close (FIND_PIPE); print "Total dirs: $dirs\n"; print "Total files: $files\n"; print LOG "Total dirs: $dirs\n"; print LOG "Total files: $files\n"; #$f=$frag; $f16 = $files16; $fr16 =`find $TESTDIR -type f -size +16k | xargs $TOPDIR/map5 | $TOPDIR/summ | tail -n 1 2>&1`; @ff16= split ' ', $f16; @ffr16= split ' ', $fr16; $files16 = $ff16[0]; $frag = $ffr16[0]; $procent = $frag / $files16; print "Total fragments : $frag \n"; print LOG "Total fragments : $frag \n"; printf "Fragments / files :%.3f\n", $procent; printf LOG "Fragments / files :%.3f\n", $procent; $frag_res[$phase_num]=$procent; # ser array of results } } system("sync"); print "\n"; print LOG "\n"; } # and what is an x process? #------------------------------------------------------------------ # MONGO_X_PROCESS ( x is number of processes to run ) #------------------------------------------------------------------ sub mongo_x_process { my ($processes) = @_ ; $p = $processes; make_fsys; # make and mount the file system $used0 = get_blocks_usage($TESTDIR); open LOG, ">>$LOGFILE" or die "Can not open log file $LOGFILE\n"; open LOG2, ">>$LOGFILE2" or die "Can not open log file $LOGFILE2\n"; open LOG3, ">>$LOGFILE3" or die "Can not open log file $LOGFILE2\n"; print LOG "FILESYSTEM=$FILESYSTEM \n"; print "\n"; if($p == 1) { print "mongo_single_process, the_set_of_param.N=$par_set_n of $total_params \n"; print LOG "mongo_single_process, the_set_of_paramN=$par_set_n of $total_params \n"; } elsif ($p > 1) { print "mongo_multi_process ($p processes), the_set_of_param.N=$par_set_n of $total_params \n"; print LOG "mongo_multi_process ($p processes), the_set_of_paramN=$par_set_n of $total_params \n"; } print "Results in file : $LOGFILE \n"; print "\n"; $dir1 = "$TESTDIR/testdir1"; $dir2 = "$TESTDIR/testdir2"; $flag = 0; $cmd_1 = "$TOPDIR/reiser_fract_tree $bytes_to_consume $median_file_size $max_file_size $median_dir_nr_files $max_directory_nr_files $median_dir_branching $max_dir_branching $write_buffer_size"; $cmd_2 = "cp -r"; $cmd_3 = "find"; $cmd_4 = "find $TESTDIR -type f | xargs $TOPDIR/mongo_read"; $cmd_5 = "find $TESTDIR -type f > /dev/null"; # it should be enough for stat all files. -zam $cmd_6 = "find"; #" $TESTDIR -type f -exec mv {} {}.r ';'"; $cmd_7 = "rm -r"; system("sync"); $frag = 0; mongo_launcher ( 1, "Create", $cmd_1, $dir1, $dir2, $flag, $p); # phase 1 mongo_launcher ( 2, "Copy ", $cmd_2, $dir1, $dir2, $flag, $p); # phase 2 mongo_launcher ( 3, "Slinks", $cmd_3, $dir1, $dir2, $flag, $p); # phase 3 mongo_launcher ( 4, "Read ", $cmd_4, $dir1, $dir2, $flag, $p); # phase 4 mongo_launcher ( 5, "Stats ", $cmd_5, $dir1, $dir2, $flag, $p); # phase 5 mongo_launcher ( 6, "Rename", $cmd_6, $dir1, $dir2, $flag, $p); # phase 6 mongo_launcher ( 7, "Delete", $cmd_7, $dir1, $dir2, $flag, $p); # phase 7 print LOG2 "\n"; if ($processes > 1) { print LOG2 "MONGO_MULTI_PROCESS ($processes processes) BENCHMARK RESULTS (time in sec.)\n"; }else { print LOG2 "MONGO_SINGLE_PROCESS BENCHMARK RESULTS (time in sec.)\n"; } print LOG2 " FILESYSTEM=$FILESYSTEM\n"; print LOG2 " parameters: files=$files, base_size=$median_file_size bytes, dirs=$dirs\n"; print LOG2 "--------------------------------------------------------------\n"; print LOG2 "Create\tCopy\tSlink\tRead\tStats\tRename\tDelete\n"; print LOG2 " time \ttime\ttime\ttime\ttime \t time \t time\n"; print LOG2 "--------------------------------------------------------------\n"; print LOG2 "$ares[1]\t$ares[2]\t$ares[3]\t$ares[4]\t$ares[5]\t$ares[6]\t$ares[7]\n"; print LOG2 "--------------------------------------------------------------\n"; print LOG2 "The size of files tree : \n"; print LOG2 " after create = $used1 kb\n"; print LOG2 " after copy = $used2 kb\n"; print LOG2 "\n"; print LOG3 "\n"; if ($processes > 1) { print LOG3 "MONGO_MULTI_PROCESS ($processes) \n"; }else { print LOG3 "MONGO_SINGLE_PROCESS \n"; } print LOG3 "parameters: \n"; print LOG3 "files=$files \n"; print LOG3 "base_size=$median_file_size bytes \n"; print LOG3 "dirs=$dirs \n"; print LOG3 "\n"; print LOG3 "FSYS=$FILESYSTEM \n"; print LOG3 "(time in sec.) \n"; print LOG3 "Create : $ares[1]\n"; print LOG3 "Fragm. : $frag_res[1]\n\n"; print LOG3 "Copy : $ares[2] \n"; print LOG3 "Fragm. : $frag_res[2]\n\n"; print LOG3 "Slinks : $ares[3]\n"; print LOG3 "Read : $ares[4]\n"; print LOG3 "Stats : $ares[5]\n"; print LOG3 "Rename : $ares[6] \n"; print LOG3 "Delete : $ares[7]\n"; print LOG3 "\n"; if($processes > 1) { print LOG "******* The end of mongo_multi_process *******"; }else { print LOG "******* The end of mongo_single_process *******"; } } #--------------------------------------------------- # Set parameters #--------------------------------------------------- sub set_params { my ($n) = @_ ; $bytes_to_consume = $numb_of_bytes[$n]; $median_file_size = $size_of_files[$n]; #$max_file_size = 1000000; #$median_dir_nr_files = 100; #$max_directory_nr_files = 10000; #$median_dir_branching = 0; #$max_dir_branching = 1; } #---------------------------------------------------------- # TEST START #---------------------------------------------------------- $par_set_n = 0; foreach $fsize (@size_of_files) { set_params ($par_set_n); mongo_x_process( $nproc ); # run n processes $par_set_n++; } system("umount $TESTDIR"); exit; --=-DQuksTfs0R34p/bwuRw+-- From owner-linux-xfs@oss.sgi.com Tue Oct 30 13:05:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9UL5t407302 for linux-xfs-outgoing; Tue, 30 Oct 2001 13:05:55 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9UL5p007280 for ; Tue, 30 Oct 2001 13:05:51 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id WAA1217198 for ; Tue, 30 Oct 2001 22:05:50 +0100 (CET) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA3316721; Tue, 30 Oct 2001 15:04:32 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id PAA34669; Tue, 30 Oct 2001 15:04:31 -0600 (CST) Subject: Re: mongo pl ...... From: Eric Sandeen To: Michael Wahlbrink Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16 (Preview Release) Date: 30 Oct 2001 15:04:12 -0600 Message-Id: <1004475853.5087.1.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk You can add something like this to mongo.pl: if ( $FILESYSTEM eq "xfs" ) { system("mkfs.xfs -f -l size=8192b $DEVICE") ; system("mount -t xfs -o logbufs=8 $DEVICE $TESTDIR") ; } -Eric On Tue, 2001-10-30 at 14:54, Michael Wahlbrink wrote: > Hi, > I often read about people who are using this program to check the stability of > her filesystems ;-)..... > So I decided to check it also out, but the only thing i found was the program on > the reiserfs homepage, but I found no possibility to check xfs with it. Can you > please give me some hints to get this working?? > > thanx in advance > wali > > ps: we're running xfs on 4 netinstallservers with each 75GB of diskspace under > SuSE 7.2 -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Oct 30 13:06:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9UL6KU07355 for linux-xfs-outgoing; Tue, 30 Oct 2001 13:06:20 -0800 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9UL6I007333 for ; Tue, 30 Oct 2001 13:06:18 -0800 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id 4EB8867043 for ; Tue, 30 Oct 2001 22:06:11 +0100 (CET) Subject: Re: mongo pl ...... To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Tue, 30 Oct 2001 22:06:11 +0100 X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.0.8 |June 18, 2001) at 30.10.2001 22:06:12 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f9UL6I007334 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 30.10.2001 21:55:14 Steve Lord wrote: [...] > >Modified mongo.pl attached > >Steve Thanks a lot for the fast answer! cu wali From owner-linux-xfs@oss.sgi.com Tue Oct 30 13:09:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9UL9ns07630 for linux-xfs-outgoing; Tue, 30 Oct 2001 13:09:49 -0800 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9UL9e007591 for ; Tue, 30 Oct 2001 13:09:40 -0800 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f9UL8uS06336 for ; Tue, 30 Oct 2001 16:08:56 -0500 (EST) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 30 Oct 2001 16:09:16 -0500 Received: from zmerd004.ca.nortel.com ([47.124.0.133]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VPDB1BAS; Tue, 30 Oct 2001 16:08:38 -0500 Received: from wmery000.ca.nortel.com ([47.131.36.101]) by zmerd004.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 418H796Y; Tue, 30 Oct 2001 16:08:37 -0500 Subject: Kernel OOPS 2.4.5-XFS-1.0.1 w/Feral FC drivers From: "Sean Kormilo" To: Linux XFS Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 30 Oct 2001 16:09:13 -0500 Message-Id: <1004476153.21484.32.camel@wmery000.ca.nortel.com> Mime-Version: 1.0 X-Orig: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I'm using XFS on a Linux PPC based system, with a Systran Fibre channel card (based on the Qlogic ISP2200A chip). I'm using Feral software device drivers (http://www.feral.com). Kernel version : 2.4.5 with the following sets of patches applied- XFS 1.0.1 - release version LVM 1.0.1-rc2 I'm exporting an XFS filesystem over NFS to another linux based client. If files are being written to the filesystem over NFS and I pull the fibre channel link, I get a bunch of warning messages like: SCSI disk error : host 0 channel 0 id 3 lun 0 return code = 10000 I/O error: dev 08:02, sector 22061432 But in the end, I wind up with a kernel panic, the output of which follows: kernel BUG at sched.c:709! Oops: Exception in kernel mode, sig: 4 NIP: C0011A18 XER: 20000000 LR: C0011A18 SP: C1113B70 REGS: c1113ac0 TRAP: 0700MSR: 00089032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 Using defaults from ksymoops -t elf32-powerpc -a powerpc:common TASK = c1112000[8] 'isp_thrd0' Last syscall: -1 last math c165c000 last altivec 00000000 GPR00: C0011A18 C1113B70 C1112000 0000001B 00001032 00000001 C02A0000 C02A0000 GPR08: C02A0000 00000000 00002CE3 C1113AB0 44822022 0184DC4C 00000000 00000000 GPR16: 00000000 00000000 C02C0000 C1113E68 00000000 00000001 00000001 00000000 GPR24: C01A0000 00000001 C1113C08 00000001 00000002 C0250000 00000000 C1113B70 Call backtrace: C0011A18 C002879C C0027B08 C0027CFC C0094328 C00ED1B4 C00D2BD4 C008FDDC C0090078 C01249D8 C0124AE4 C0124E88 C01394FC C011E674 C011E464 C0019BB4 C0019A70 C0019870 C00119A0 C0009C28 C012DB58 C0006664 Kernel panic: Aiee, killing interrupt handler! Warning (Oops_read): Code line not seen, dumping what data is available >>NIP; c0011a18 <===== Trace; c0011a18 Trace; c002879c <___wait_on_page+9c/d0> Trace; c0027b08 Trace; c0027cfc Trace; c0094328 Trace; c00ed1b4 <_xfs_force_shutdown+108/12c> Trace; c00d2bd4 Trace; c008fddc Trace; c0090078 <_end_pagebuf_page_io+120/134> Trace; c01249d8 <__scsi_end_request+dc/1d0> Trace; c0124ae4 Trace; c0124e88 Trace; c01394fc Trace; c011e674 Trace; c011e464 Trace; c0019bb4 Trace; c0019a70 Trace; c0019870 Trace; c00119a0 Trace; c0009c28 <__down+54/b4> Trace; c012db58 Trace; c0006664 5 warnings issued. Results may not be reliable. If I remove the XFS patches from the tree and run the same test using ext2 based filesystems, the panic does not occur. Interestingly, if I run the system with the XFS patches applied, but have no XFS based filesystems mounted, it still panic's (I don't have the ksymoops output for this type of panic, however). I just get the following message on the console: Kernel panic: scsi_free:Bad offset In interrupt handler - not syncing Rebooting in 60 seconds.. Any help or suggestions would be appreciated. Sean. -- Sean C. Kormilo, Software Architect, Nortel Networks email: skormilo@nortelnetworks.com From owner-linux-xfs@oss.sgi.com Tue Oct 30 13:25:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ULPNA08556 for linux-xfs-outgoing; Tue, 30 Oct 2001 13:25:23 -0800 Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ULPJ008534 for ; Tue, 30 Oct 2001 13:25:19 -0800 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9ULPG3u070142; Tue, 30 Oct 2001 22:25:16 +0100 (CET) Message-Id: <4.3.2.7.2.20011030220617.035c9c40@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 30 Oct 2001 22:23:31 +0100 To: "Michael Wahlbrink" , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: mongo pl ...... In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 21:54 30-10-2001 +0100, Michael Wahlbrink wrote: >Hi, >I often read about people who are using this program to check the stability of >her filesystems ;-)..... >So I decided to check it also out, but the only thing i found was the >program on >the reiserfs homepage, but I found no possibility to check xfs with it. >Can you >please give me some hints to get this working?? You only have to search the mongo.pl file for the mke2fs command and copy that if loop and put a mkfs.xfs in there. You als have to search for the unknown fs phrase or something like that and include xfs in to the valid fs evaluation. http://iserv.nl/files/xfs/ Someone should submit this patch to the reiserfs people. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Tue Oct 30 13:28:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ULSXl08690 for linux-xfs-outgoing; Tue, 30 Oct 2001 13:28:33 -0800 Received: from mail.dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ULSU008659 for ; Tue, 30 Oct 2001 13:28:30 -0800 Received: from ranma.dkp.com (ranma.dkp.com [205.150.40.12]) by mail.dkp.com (Postfix) with ESMTP id 313531AB2A for ; Tue, 30 Oct 2001 16:28:29 -0500 (EST) Received: by ranma.dkp.com (Postfix, from userid 168) id E89C95A5DA; Tue, 30 Oct 2001 16:28:28 -0500 (EST) Date: Tue, 30 Oct 2001 16:28:28 -0500 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Re: Who / What's using Linux XFS? Message-ID: <20011030162828.B1690@dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <1004379839.13361.47.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1004379839.13361.47.camel@stout.americas.sgi.com> User-Agent: Mutt/1.3.23i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Oct 29, 2001 at 12:23:59PM -0600, Eric Sandeen wrote: > I'd like to put a page up on the web site detailing the > various applications, distributions, installations, and > embedded products using XFS for Linux. Not sure if this counts... We're a 3D computer graphics/post-production house. We've currently got four fileservers using XFS under Linux online - three 350GB servers and one 800GB server. The servers are under fairly heavy load - network load to and from the dual NICs on the box is basically maxed out 18 hours a day - and we do have occasional lockups and drive failures. Thanks to Linux SW RAID5 and XFS, though, we haven't had any data loss, or significant down time. Andrew Klaassen From owner-linux-xfs@oss.sgi.com Tue Oct 30 13:29:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ULTL208737 for linux-xfs-outgoing; Tue, 30 Oct 2001 13:29:21 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ULT9008713 for ; Tue, 30 Oct 2001 13:29:09 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9ULT4T02206 for ; Tue, 30 Oct 2001 13:29:04 -0800 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA3448864; Tue, 30 Oct 2001 15:27:48 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA87506; Tue, 30 Oct 2001 15:27:47 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id f9ULN5f29063; Tue, 30 Oct 2001 15:23:05 -0600 Subject: Re: Kernel OOPS 2.4.5-XFS-1.0.1 w/Feral FC drivers From: Steve Lord To: Sean Kormilo Cc: Linux XFS In-Reply-To: <1004476153.21484.32.camel@wmery000.ca.nortel.com> References: <1004476153.21484.32.camel@wmery000.ca.nortel.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16 (Preview Release) Date: 30 Oct 2001 15:23:05 -0600 Message-Id: <1004476985.28795.46.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2001-10-30 at 15:09, Sean Kormilo wrote: > Hi, > > I'm using XFS on a Linux PPC based system, with a Systran Fibre channel > card (based on the Qlogic ISP2200A chip). I'm using Feral software > device drivers (http://www.feral.com). > > Kernel version : 2.4.5 with the following sets of patches applied- > XFS 1.0.1 - release version > LVM 1.0.1-rc2 > > I'm exporting an XFS filesystem over NFS to another linux based client. > If files are being written to the filesystem over NFS and I pull the > fibre channel link, I get a bunch of warning messages like: > > SCSI disk error : host 0 channel 0 id 3 lun 0 return code = 10000 > I/O error: dev 08:02, sector 22061432 > > But in the end, I wind up with a kernel panic, the output of which > follows: > > kernel BUG at sched.c:709! > Oops: Exception in kernel mode, sig: 4 > NIP: C0011A18 XER: 20000000 LR: C0011A18 SP: C1113B70 REGS: c1113ac0 TRAP: 0700MSR: 00089032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 > Using defaults from ksymoops -t elf32-powerpc -a powerpc:common > TASK = c1112000[8] 'isp_thrd0' Last syscall: -1 > last math c165c000 last altivec 00000000 > GPR00: C0011A18 C1113B70 C1112000 0000001B 00001032 00000001 C02A0000 C02A0000 > GPR08: C02A0000 00000000 00002CE3 C1113AB0 44822022 0184DC4C 00000000 00000000 > GPR16: 00000000 00000000 C02C0000 C1113E68 00000000 00000001 00000001 00000000 > GPR24: C01A0000 00000001 C1113C08 00000001 00000002 C0250000 00000000 C1113B70 > Call backtrace: > C0011A18 C002879C C0027B08 C0027CFC C0094328 C00ED1B4 C00D2BD4 > C008FDDC C0090078 C01249D8 C0124AE4 C0124E88 C01394FC C011E674 > C011E464 C0019BB4 C0019A70 C0019870 C00119A0 C0009C28 C012DB58 > C0006664 > Kernel panic: Aiee, killing interrupt handler! > Warning (Oops_read): Code line not seen, dumping what data is available > > >>NIP; c0011a18 <===== > Trace; c0011a18 > Trace; c002879c <___wait_on_page+9c/d0> > Trace; c0027b08 > Trace; c0027cfc > Trace; c0094328 > Trace; c00ed1b4 <_xfs_force_shutdown+108/12c> > Trace; c00d2bd4 > Trace; c008fddc > Trace; c0090078 <_end_pagebuf_page_io+120/134> > Trace; c01249d8 <__scsi_end_request+dc/1d0> > Trace; c0124ae4 > Trace; c0124e88 > Trace; c01394fc > Trace; c011e674 > Trace; c011e464 > Trace; c0019bb4 > Trace; c0019a70 > Trace; c0019870 > Trace; c00119a0 > Trace; c0009c28 <__down+54/b4> > Trace; c012db58 > Trace; c0006664 > > > 5 warnings issued. Results may not be reliable. > > > If I remove the XFS patches from the tree and run the same test using > ext2 based filesystems, the panic does not occur. Not surprising, the xfs forced shutdown code is getting executed when you lose the fiberchannel connection. It looks like the forced shutdown code is doing a little too much in interrupt context, it will take some thinking about as to how to fix this. > > Interestingly, if I run the system with the XFS patches applied, but > have no XFS based filesystems mounted, it still panic's (I don't have > the ksymoops output for this type of panic, however). I just get the > following message on the console: > > Kernel panic: scsi_free:Bad offset > In interrupt handler - not syncing > Rebooting in 60 seconds.. > In this case I have no idea - if you are not running on an xfs filesystem then this has nothing to do with xfs, there are no mods in the code base which would get executed in this case. I suspect the forced shutdown code in xfs is going to need some work before this scenario will work for you. You could try editing the _xfs_force_shutdown() function in fs/xfs/xfs_rw.c and removing this chunk of code: while (xfs_incore_relse(&mp->m_ddev_targ, 1, 0)) { if (ntries >= XFS_MAX_DRELSE_RETRIES) break; delay(++ntries * 5); } What it is doing in there looks radically different from the Irix version, and is I suspect broken in this case. Let me know what this does for you. What does happen with ext2 - it should be getting I/O errors back from the fiber channel driver. > Any help or suggestions would be appreciated. > > Sean. > > > -- > > Sean C. Kormilo, Software Architect, Nortel Networks > email: skormilo@nortelnetworks.com > Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Oct 30 14:54:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9UMsfj12874 for linux-xfs-outgoing; Tue, 30 Oct 2001 14:54:41 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9UMsa012852 for ; Tue, 30 Oct 2001 14:54:37 -0800 Received: from clink-eth.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA03360 for ; Tue, 30 Oct 2001 14:54:27 -0800 (PST) mail_from (roehrich@clink-eth.americas.sgi.com) Received: (from roehrich@localhost) by clink-eth.americas.sgi.com (SGI-8.9.3/8.9.3) id QAA29791 for linux-xfs@oss.sgi.com; Tue, 30 Oct 2001 16:53:08 -0600 (CST) Date: Tue, 30 Oct 2001 16:53:08 -0600 (CST) From: Dean Roehrich Message-Id: <200110302253.QAA29791@clink-eth.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - put LGPL on dmapi-relevant headers Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Oct 30 14:52:52 PST 2001 Workarea: clink-eth.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:105763a linux/include/linux/xfs_fs.h - 1.29 linux/include/linux/dmapi.h - 1.7 cmd/attr/include/attributes.h - 1.4 cmd/xfsprogs/include/handle.h - 1.4 cmd/xfsprogs/include/xfs_fs.h - 1.10 cmd/acl/include/acl.h - 1.9 cmd/dmapi/include/dmapi.h - 1.3 - No Message Supplied From owner-linux-xfs@oss.sgi.com Tue Oct 30 14:59:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9UMx6V13063 for linux-xfs-outgoing; Tue, 30 Oct 2001 14:59:06 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9UMx3013041 for ; Tue, 30 Oct 2001 14:59:03 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id OAA03977 for ; Tue, 30 Oct 2001 14:58:24 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) 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 JAA06891; Wed, 31 Oct 2001 09:57:39 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA77056; Wed, 31 Oct 2001 09:57:36 +1100 (AEDT) Date: Wed, 31 Oct 2001 09:57:35 +1100 From: Nathan Scott To: Mark Pruett Cc: linux-xfs@oss.sgi.com Subject: Re: Linux XFS on Alpha's Message-ID: <20011031095735.C540229@wobbly.melbourne.sgi.com> References: <4.3.2.7.2.20011029193944.036e1710@pop.xs4all.nl> <002601c1618f$41338e80$6501a8c0@va.mediaone.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <002601c1618f$41338e80$6501a8c0@va.mediaone.net>; from mpruett@mediaone.net on Tue, Oct 30, 2001 at 02:07:19PM -0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Tue, Oct 30, 2001 at 02:07:19PM -0800, Mark Pruett wrote: > Is anyone here using XFS on Linux on the Alpha platform? > We've been testing both XFS and Reiserfs, and we always > get problems requiring xfs_repair during power-off tests (where > we intentionally kill power during disk writes.) We invariably > lose the directory to which the files were written, and end up > with a huge number of files in lost+found. Are you running xfs_repair before log recovery (ie. mount)? If so, that's bad - you need to mount first so that the journal can be replayed before you run xfs_repair. Try also a current (xfsprogs-1.3.12+) version of xfs_repair - this will warn you if the log is dirty when you try to run xfs_repair, and will not allow it. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Oct 30 16:32:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9V0Wbq15543 for linux-xfs-outgoing; Tue, 30 Oct 2001 16:32:37 -0800 Received: from plato.arts.usyd.edu.au (plato.arts.usyd.edu.au [129.78.16.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9V0WP015520 for ; Tue, 30 Oct 2001 16:32:26 -0800 Received: from arts.usyd.edu.au (IDENT:matthew@whitestar.arts.usyd.edu.au [129.78.16.20]) by plato.arts.usyd.edu.au (8.9.3/8.9.3) with ESMTP id LAA19255 for ; Wed, 31 Oct 2001 11:32:24 +1100 (EST) Message-ID: <3BDF4696.999BEE85@arts.usyd.edu.au> Date: Wed, 31 Oct 2001 11:32:22 +1100 From: Matthew Geier Organization: Arts IT Unit, Sydney University X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.7-pre6-xfs i686) X-Accept-Language: en, pdf MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: Who / What's using Linux XFS? References: <1004379839.13361.47.camel@stout.americas.sgi.com> <20011030162828.B1690@dkp.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms1C65606FCD53C3B461A756BE" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms1C65606FCD53C3B461A756BE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ive got XFS on a 'production' file server. The machine could have upto 500 people logged in, but typically less than 200. Most are Mac users, connected via NetAtalk for 'personal files', although there are shared areas for admin units. Probably about 30-40 windows users. (Samba) Its the file server for an Academic faculty at a University. We have a AlphaServer 800 running Digital Unix for email and web (running ADVFS, Digital/Compaq/HP?'s journaling FS). Also a old mac G3 'server' running ASIP 6.3 bash-2.04$ df -h -T Filesystem Type Size Used Avail Use% Mounted on /dev/sda2 xfs 301M 164M 137M 55% / /dev/sda1 ext2 61M 14M 44M 23% /boot /dev/rd/c0d0p1 xfs 205G 73G 132G 36% /home /dev/sda5 xfs 2.2G 1.3G 1014M 56% /usr /dev/sda7 xfs 2.9G 254M 2.6G 9% /usr/local /dev/sda6 xfs 1.9G 163M 1.7G 9% /var uptime 11:21am up 93 days, 23:09, 139 users, load average: 0.06, 0.07, 0.06 bash-2.04$ (The user count is wrong - Im trying to use Samba's UTMP support, and it often doesn't clean up after itself :-) bash-2.04$ ps -ef | grep afpd | wc 122 1340 9859 bash-2.04$ ps -ef | grep smbd | wc 24 216 1829 bash-2.04$ Might give a better idea of current 'users' - just under 150. uname -a Linux aristotle.arts.usyd.edu.au 2.4.7-pre6-xfs #24 SMP Thu Jul 19 16:47:10 EST 2001 i686 unknown bash-2.04$ Hardware RAID, via Mylex dual channel controller with 4 drives, Intel Tupelo MB, Intel 'SC5000' server chassis with redundant power and hot-swap scsi bays. The system boots of a non RAID single 9gb UW-scsi drive. Have removed both a power supply and a raid disk on the running system to check that the redundancy actually worked (and that scripts watching for faults actually worked...) Only system 'crash' was caused by some one accidently unplugging it, just before we put it into production. In day to day use it has run well. The network between the users is Cisco ethernet switches, at 100Mb, with 1000Mb optical trunks and 7 'virtual' LANs. -- Matthew Geier matthew@arts.usyd.edu.au Arts IT Unit +61 2 9351 4713 Sydney University --------------ms1C65606FCD53C3B461A756BE Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIH0AYJKoZIhvcNAQcCoIIHwTCCB70CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BbswggKKMIIB86ADAgECAgMFMYswDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMTA3MDkxOTEyNThaFw0wMjA3MDkxOTEyNTha MEoxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxJzAlBgkqhkiG9w0BCQEWGG1h dHRoZXdAYXJ0cy51c3lkLmVkdS5hdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA1H+o MQ4xn5lDS/7p9rYboPW7grw13lXOj7Xisip37QttkX7Ga3ITBXnsAKnuFK3Z7GtILACBXil1 BngLBOd0AlW9zqQBXEOP9aODNJzBsTb3+tOHwQo6shcORKQArKEinG00SuwBdzxALU3KWT6E yIUSvoz7q0PN4C8qUF3t00sCAwEAAaM1MDMwIwYDVR0RBBwwGoEYbWF0dGhld0BhcnRzLnVz eWQuZWR1LmF1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAiJu7SNBXsW7I+ZH9 e2+0M47BmR3DxV31VbW9mKcwuamusWSJJEy5MAKZc8b0snRX/XDkCpM+av3VxDJX8T3rxOE0 siyCC6Tclu6wjwjw0goXK4N6Xhsz+qwIfdoclNZkqK5yInEZtc5ijKr0IPRgch79f35WP82C SNHVYApmjzgwggMpMIICkqADAgECAgEMMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJa QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoT EVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERp dmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG 9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMwMDAwMDAwWhcN MDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES MBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmlj YXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNE KYpjNSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu 2HL5ugL217CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQAB o04wTDApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0T AQH/BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0 S1liiu1EvknH6A27j7kNaiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHC CafvS65y3QZn9VBvLli4tgvBUFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+p lrgFPFL83eliA0gxggHdMIIB2QIBATCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNV BAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBS U0EgMjAwMC44LjMwAgMFMYswCQYFKw4DAhoFAKCBmTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wMTEwMzEwMDMyMjNaMCMGCSqGSIb3DQEJBDEWBBTvNbFW wdd4qggolxz5P32bENLgkDA6BgkqhkiG9w0BCQ8xLTArMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDANBgkqhkiG9w0BAQEFAASBgG3tM7OSQTQHjHdvSNJ6 pvXLQ0bGKzd9XioVj+gs9xXCNTqg+sZwcT7Y+/u46NKEUzNZ2UeoHnMm62T4YMx1kmhwad1/ ZS5JGjtTxtlQeRR4r9s4AGtfNRJ7sICnpdR4BpYL0eK1TZzAuaqSJzTswU/wioFVw47yAOd/ WdS3bJzD --------------ms1C65606FCD53C3B461A756BE-- From owner-linux-xfs@oss.sgi.com Tue Oct 30 17:10:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9V1AIB16462 for linux-xfs-outgoing; Tue, 30 Oct 2001 17:10:18 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9V1AE016440 for ; Tue, 30 Oct 2001 17:10:14 -0800 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA09947 for ; Tue, 30 Oct 2001 17:09:36 -0800 (PST) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA64506; Wed, 31 Oct 2001 12:08:46 +1100 (AEDT) Date: Wed, 31 Oct 2001 12:08:46 +1100 From: Timothy Shimmin To: Jonathan Dill Cc: Linux XFS Mailing List Subject: Re: 2.4.9 /dev/nst1 "Bad file descriptor" Message-ID: <20011031120845.C52179@boing.melbourne.sgi.com> References: <3BDEE801.C1727CCA@umbi.umd.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <3BDEE801.C1727CCA@umbi.umd.edu>; from dill@umbi.umd.edu on Tue, Oct 30, 2001 at 12:48:49PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Jonathan, On Tue, Oct 30, 2001 at 12:48:49PM -0500, Jonathan Dill wrote: > Since upgrading from 2.4.3 to the 2.4.9 prerelease kernels, long tape > writes fail after 1-2 GB on a 20 GB native tape with "Bad file > descriptor" on /dev/nst1. I'm not sure I understand what you are saying here (I often read things the wrong way). Are you saying that after you've done a number of tape writes each of a certain buffer size (which would be ?), that when you have in total written out around 1 to 2 Gb that you get this error ? [I initially was thinking you were referring to the problem of large tape block writes of 1-2Mb and you might need to change max_sg_segs for the st module as described in cmd/xfsdump/doc/README.xfsdump] Are there any messages in the system logs from the st driver ? Were you using xfsdump ? > I switched back to the 2.4.3 kernel and the > tapedrive is working fine. When I get caught up on my backups and have > some time to play with it, I'll send some more info. I'm just hoping > that someone may have heard of a problem like this and know what causes > it. > > -- > "Jonathan F. Dill" (dill@umbi.umd.edu) > CARB IT Coordinator > Experimental Support Site http://concept.umbi.umd.edu > --Tim From owner-linux-xfs@oss.sgi.com Tue Oct 30 18:24:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9V2ORG18337 for linux-xfs-outgoing; Tue, 30 Oct 2001 18:24:27 -0800 Received: from vertigo.incyte.com (master.incyte.com [198.31.37.253]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9V2ON018314 for ; Tue, 30 Oct 2001 18:24:23 -0800 Received: from vertigo.incyte.com (wfrancis@localhost) by vertigo.incyte.com (8.11.6/8.11.0) with ESMTP id f9V2Nlf25980; Tue, 30 Oct 2001 18:23:47 -0800 Message-Id: <200110310223.f9V2Nlf25980@vertigo.incyte.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: Who / What's using Linux XFS? In-Reply-To: Your message of "29 Oct 2001 12:23:59 CST." <1004379839.13361.47.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Oct 2001 18:23:47 -0800 From: Will Francis Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm currently in the process of slowly converting 21 clusters totaling 2300+ processors over to XFS. These machines are running a fairly stock RH7.1+XFS. The application is our own custom scheduler for doing genomic research. We have one of the worlds largest sequencing labs which generates a tremendous amount of raw data. Vast amounts of CPU cycles must be applied to it to turn it into useful data we can then sell access to. > What I _am_ looking for is something like "The human >genome project stores all data on Linux/XFS" :) We're not with the HGP, but we do process a huge amount of human genomic data. currently, a minority of these machines are running XFS, but as I can get downtime on the clusters I am upgrading them to 7.1+XFS. When I'm done, it'll be about 10TB of XFS goodness... across 9G disks mostly. If you want any additional info, lemme know. (BTW, when I spoke at LinuxWorld this year about the clusters, I put in a nice plug for you guys :-) /W From owner-linux-xfs@oss.sgi.com Tue Oct 30 21:59:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9V5xbF22564 for linux-xfs-outgoing; Tue, 30 Oct 2001 21:59:37 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9V5x9022376 for ; Tue, 30 Oct 2001 21:59:29 -0800 Received: from maties2.sun.ac.za (maties2.sun.ac.za [146.232.128.10]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id CAA05655 for ; Tue, 23 Oct 2001 02:05:31 -0700 (PDT) mail_from (bgmilne@cae.co.za) Received: from www.cae.sun.ac.za ([146.232.145.5] helo=mail.cae.co.za) by maties2.sun.ac.za with esmtp (Exim 3.33 #3) id 15vxUC-0003S3-00 for linux-xfs@oss.sgi.com; Tue, 23 Oct 2001 11:04:36 +0200 Received: by mail.cae.co.za (Postfix, from userid 239) id 84F4B107FE; Tue, 23 Oct 2001 10:57:19 +0200 (SAST) Received: from cae.co.za (bgmilne.cae.co.za [146.232.174.36]) by mail.cae.sun.ac.za (Postfix) with ESMTP id 45AD7107FE for ; Tue, 23 Oct 2001 10:57:15 +0200 (SAST) Message-ID: <3BD53217.7080302@cae.co.za> Date: Tue, 23 Oct 2001 11:02:15 +0200 From: Buchan Milne User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs Subject: Re: ext3 + xfs + jfs + reiser References: <20011022122106.A12279@bistro.marx> <1003771829.13566.38.camel@stout.americas.sgi.com> <3BD45AAB.2D75ACAC@illusionary.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: scanned for viruses at mail.cae.co.za by AMaViS 0.2.1 (http://amavis.org/) X-Scanner: exiscan *15vxUC-0003S3-00*UEXCtL5mmhM* http://duncanthrax.net/exiscan/ Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Derek Glidden wrote: >Eric Sandeen wrote: > >>Dunno about a single patch, but the latest Mandrake has all of those >>filesystems co-existing. >> > >On a slight tangent, I was at an expo last week and a SuSE guy was also >there. A brief discussion popped up about journaling filesystems and we >determined that XFS was *not* going to be in SuSE 7.3 while Reiser, ext3 >and JFS were. His explanation was that XFS was not stable enough but >had no more technical information. > >Can any SuSE guys around here comment more on that? > No, but this is what Civileme (the highly-respected-in-Mandrake-circles QA manager at Mandrakesoft) posted on the Mandrakeforum: http://mandrakeforum.com/article.php?sid=1212&lang=en It is interesting to see here that: 1)Mandrake considers XFS better for general use than ReiserFS, which they have shipped with since 7.1 2)Mandrake considers JFS (1.0.4) unstable, I am not sure if they actually disabled JFS in the installer or not .... 3)Ext3 is by far the slowest of the 3 Journalling FS's availble, and only has one advantage - easy migration from ext2. That said, I am still sitting with the majority of our data on ReiserFS, until I have enough spare disk space to migrate to XFS (ACLs would be really convenient right now ....) > >(My suspicions are really less that it's unstable and more that it >touches pretty deeply into the rest of the VFS layer that made them >unhappy and not want to use it for whatever reason. Some of the same >stuff I've seen Alan Cox mention here.) > AFAIK XFS and Ext3 are both in -ac kernels now? > >>On Mon, 2001-10-22 at 12:21, pac@fortuitous.com wrote: >> >>> Anyone know of a super-duper-all-in-one patch for >>> xfs+ext3+jfs+ (reiser is already in the kernel) ? >>> This is not for the faint-of-heart ... After taking a look at the kernel in Mandrake's cooker at: http://www.linux-mandrake.com/cgi-bin/cvsweb.cgi/SPECS/kernel you will notice that there are a lot of patches for XFS and JFS against 2.4.12-ac3 ..... Buchan -- |----------------Registered Linux User #182071-----------------| Buchan Milne Mechanical Engineer, Network Manager Cellphone * Work +27 82 472 2231 * +27 21 808 2497 ext 202 Stellenbosch Automotive Engineering http://www.cae.co.za From owner-linux-xfs@oss.sgi.com Tue Oct 30 22:27:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9V6Rds23871 for linux-xfs-outgoing; Tue, 30 Oct 2001 22:27:39 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9V6RZ023849 for ; Tue, 30 Oct 2001 22:27:35 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id WAA00875 for ; Tue, 30 Oct 2001 22:27:34 -0800 (PST) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id RAA11697; Wed, 31 Oct 2001 17:26:28 +1100 Date: Wed, 31 Oct 2001 17:26:28 +1100 From: Keith Owens Message-Id: <200110310626.RAA11697@sherman.melbourne.sgi.com> Subject: TAKE - Correct find next bit on 64 bit architectures Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The "find next bit" code has been changed recently (copied from reiserfs), it fails on architectures where sizeof(int) != sizeof(long). This explains why IA64 XFS recovery was failing, it may explain problems on other 64 bit platforms. Date: Tue Oct 30 22:23:03 PST 2001 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:105780a linux/fs/xfs/xfs_buf_item.c - 1.115 From owner-linux-xfs@oss.sgi.com Tue Oct 30 22:38:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9V6cuT24278 for linux-xfs-outgoing; Tue, 30 Oct 2001 22:38:56 -0800 Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9V6cq024256 for ; Tue, 30 Oct 2001 22:38:53 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9V6coRq041889; Wed, 31 Oct 2001 07:38:51 +0100 (CET) Message-Id: <4.3.2.7.2.20011031073509.037fb990@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 31 Oct 2001 07:37:01 +0100 To: Jonathan Dill , Linux XFS Mailing List From: Seth Mos Subject: Re: 2.4.9 /dev/nst1 "Bad file descriptor" In-Reply-To: <3BDEE801.C1727CCA@umbi.umd.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 12:48 30-10-2001 -0500, Jonathan Dill wrote: >Since upgrading from 2.4.3 to the 2.4.9 prerelease kernels, long tape >writes fail after 1-2 GB on a 20 GB native tape with "Bad file >descriptor" on /dev/nst1. I switched back to the 2.4.3 kernel and the >tapedrive is working fine. When I get caught up on my backups and have >some time to play with it, I'll send some more info. I'm just hoping >that someone may have heard of a problem like this and know what causes >it. I have no problems writing more then 30GB on a Ultrium LTO drive. Something must have broken. Have you tried tar or just filling with zero's ? Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Tue Oct 30 22:55:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9V6tqi24670 for linux-xfs-outgoing; Tue, 30 Oct 2001 22:55:52 -0800 Received: from mail.hs.tecmath.com (www.tecmath.de [213.69.212.80]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9V6tm024648 for ; Tue, 30 Oct 2001 22:55:48 -0800 Received: from tmsgi7.humanmodeling.tecmath.de ([192.168.98.14]) by mail.hs.tecmath.com with esmtp (Exim 3.16 #1) id 15ypHm-00087T-00; Wed, 31 Oct 2001 07:55:38 +0100 Date: Wed, 31 Oct 2001 07:55:41 +0100 From: Martin Apel X-X-Sender: apel@tmsgi7.humanmodeling.tecmath.de To: sandeen@sgi.com cc: linux-xfs@oss.sgi.com Subject: Re: Who / What's using Linux XFS? In-Reply-To: <3BDEF28A.5080301@theiqgroup.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 30 Oct 2001, Kelly Corbin wrote: We use a production server with a 270 GB RAID 5 (hardware) disk array. It is based on a Suse 7.2 distribution, but with a standard 2.4.12 kernel with XFS and LVM patches. The server provides NFS to 8 Unix clients as well as Samba to about 80 PCs. The machine also runs Bind 9, Apache, Exim, DHCP, POP3, MySQL. I have tried out different configurations with ReiserFS, but I didn't manage to find a stable configuration with respect to NFS. Since I converted all disks to XFS some 3 months ago, we never had any filesystem-related problems. Martin ________________________________________________________________________ Martin Apel, Dipl.-Inform. t e c m a t h A G Group Manager Software Development Human Solutions Division phone +49 (0)6301 606-300 Sauerwiesen 2, 67661 Kaiserslautern fax +49 (0)6301 606-309 Germany apel@hs.tecmath.com http://www.tecmath.com ________________________________________________________________________ From owner-linux-xfs@oss.sgi.com Tue Oct 30 23:08:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9V78Tu25032 for linux-xfs-outgoing; Tue, 30 Oct 2001 23:08:29 -0800 Received: from vasquez.zip.com.au (vasquez.zip.com.au [203.12.97.41]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9V78P025010 for ; Tue, 30 Oct 2001 23:08:25 -0800 Received: from zip.com.au (root@zipperii.zip.com.au [61.8.0.87]) by vasquez.zip.com.au (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id SAA06218; Wed, 31 Oct 2001 18:07:56 +1100 X-Authentication-Warning: vasquez.zip.com.au: Host root@zipperii.zip.com.au [61.8.0.87] claimed to be zip.com.au Message-ID: <3BDFA22B.A25FF2FA@zip.com.au> Date: Tue, 30 Oct 2001 23:03:07 -0800 From: Andrew Morton X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.13-ac2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Buchan Milne CC: linux-xfs Subject: Re: ext3 + xfs + jfs + reiser References: <20011022122106.A12279@bistro.marx> <1003771829.13566.38.camel@stout.americas.sgi.com> <3BD45AAB.2D75ACAC@illusionary.com> <3BD53217.7080302@cae.co.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Buchan Milne wrote: > > No, but this is what Civileme (the highly-respected-in-Mandrake-circles > QA manager at Mandrakesoft) posted on the Mandrakeforum: > http://mandrakeforum.com/article.php?sid=1212&lang=en > Those figures are grotesquely wrong. They show ext3 in writeback mode as being slower than in ordered-data mode, which is unlikely to be the case. They show ext3 in ordered data mode to be slower than ext2 at reading, which is not possible - the read code paths are, for all intents and purposes, identical. They show ext3 in writeback mode to be half the read speed of ext3 in ordered-data mode. But the read code paths are identical. And the figures appear to show, with no commentary at all, that ext3 deletes files 200x more slowly than ext2, which is simply daft. All this would tend to cast some doubt over the figures for the other filesystems. I'd suggest you put ths one gently aside and run your own tests. - From owner-linux-xfs@oss.sgi.com Tue Oct 30 23:09:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9V79bd25114 for linux-xfs-outgoing; Tue, 30 Oct 2001 23:09:37 -0800 Received: from mail.hs.tecmath.com (www.tecmath.de [213.69.212.80]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9V79Y025092 for ; Tue, 30 Oct 2001 23:09:35 -0800 Received: from tmsgi7.humanmodeling.tecmath.de ([192.168.98.14]) by mail.hs.tecmath.com with esmtp (Exim 3.16 #1) id 15ypV6-00089C-00; Wed, 31 Oct 2001 08:09:24 +0100 Date: Wed, 31 Oct 2001 08:09:27 +0100 From: Martin Apel X-X-Sender: apel@tmsgi7.humanmodeling.tecmath.de To: sandeen@sgi.com cc: linux-xfs@oss.sgi.com Subject: Re: Who / What's using Linux XFS? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I noticed that did a mistake in the mail I just sent. I took Kelly's mail, when I decided to write something about our production server. I forgot to delete the line saying 'Kelly Corbin wrote'. So the mail has nothing to do with Kelly. Sorry for any confusion I caused. Martin ________________________________________________________________________ Martin Apel, Dipl.-Inform. t e c m a t h A G Group Manager Software Development Human Solutions Division phone +49 (0)6301 606-300 Sauerwiesen 2, 67661 Kaiserslautern fax +49 (0)6301 606-309 Germany apel@hs.tecmath.com http://www.tecmath.com ________________________________________________________________________ From owner-linux-xfs@oss.sgi.com Wed Oct 31 00:03:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9V83fT26253 for linux-xfs-outgoing; Wed, 31 Oct 2001 00:03:41 -0800 Received: from relay.xlink.net (relay.xlink.net [193.141.40.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9V822026179 for ; Wed, 31 Oct 2001 00:02:02 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id JAA12452 for ; Wed, 31 Oct 2001 09:02:00 +0100 (MET) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id JAA06048; Wed, 31 Oct 2001 09:01:06 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 126DC57306; Wed, 31 Oct 2001 09:00:56 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id BD73E25835; Wed, 31 Oct 2001 09:00:55 +0100 (CET) Message-ID: <3BDFAFB7.54F9A1FE@ch.sauter-bc.com> Date: Wed, 31 Oct 2001 09:00:55 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.10 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Buchan Milne Cc: linux-xfs Subject: Re: ext3 + xfs + jfs + reiser References: <20011022122106.A12279@bistro.marx> <1003771829.13566.38.camel@stout.americas.sgi.com> <3BD45AAB.2D75ACAC@illusionary.com> <3BD53217.7080302@cae.co.za> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Buchan Milne schrieb: > > Derek Glidden wrote: > > >Eric Sandeen wrote: > > > >>Dunno about a single patch, but the latest Mandrake has all of those > >>filesystems co-existing. > >> > > > >On a slight tangent, I was at an expo last week and a SuSE guy was also > >there. A brief discussion popped up about journaling filesystems and we > >determined that XFS was *not* going to be in SuSE 7.3 while Reiser, ext3 > >and JFS were. His explanation was that XFS was not stable enough but > >had no more technical information. > > > >Can any SuSE guys around here comment more on that? > > > No, but this is what Civileme (the highly-respected-in-Mandrake-circles > QA manager at Mandrakesoft) posted on the Mandrakeforum: > http://mandrakeforum.com/article.php?sid=1212&lang=en > > It is interesting to see here that: > 1)Mandrake considers XFS better for general use than ReiserFS, which > they have shipped with since 7.1 > 2)Mandrake considers JFS (1.0.4) unstable, I am not sure if they > actually disabled JFS in the installer or not .... JFS is there. But when I made a crash test with ext2,ext3,reiserfs, JFS and XFS, JFS was the only one where I was forced to recover by hand. So it means it is not so well integrated in the Mandrake distro. > 3)Ext3 is by far the slowest of the 3 Journalling FS's availble, and > only has one advantage - easy migration from ext2. Well, I just made my own tests again and its alwas the same: XFS is VERY good with big files while ext3 is good with lots of small files. > > That said, I am still sitting with the majority of our data on ReiserFS, > until I have enough spare disk space to migrate to XFS (ACLs would be > really convenient right now ....) My future systems will most likely have mixed ext3 and XFS. Maybe only /home will be on XFS. This way its easy to upgrade with original RedHat installer and still keeping most data on XFS. > > > > >(My suspicions are really less that it's unstable and more that it > >touches pretty deeply into the rest of the VFS layer that made them > >unhappy and not want to use it for whatever reason. Some of the same > >stuff I've seen Alan Cox mention here.) > > > AFAIK XFS and Ext3 are both in -ac kernels now? > > > > >>On Mon, 2001-10-22 at 12:21, pac@fortuitous.com wrote: > >> > >>> Anyone know of a super-duper-all-in-one patch for > >>> xfs+ext3+jfs+ (reiser is already in the kernel) ? > >>> > This is not for the faint-of-heart ... After taking a look at the > kernel in Mandrake's cooker at: > http://www.linux-mandrake.com/cgi-bin/cvsweb.cgi/SPECS/kernel > you will notice that there are a lot of patches for XFS and JFS against > 2.4.12-ac3 ..... > > Buchan > > -- > |----------------Registered Linux User #182071-----------------| > Buchan Milne Mechanical Engineer, Network Manager > Cellphone * Work +27 82 472 2231 * +27 21 808 2497 ext 202 > Stellenbosch Automotive Engineering http://www.cae.co.za From owner-linux-xfs@oss.sgi.com Wed Oct 31 00:16:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9V8Gwk26539 for linux-xfs-outgoing; Wed, 31 Oct 2001 00:16:58 -0800 Received: from pooh.lsc.hu (IDENT:qmailr@lsc.net23.hu [195.56.172.131]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9V8Gu026513 for ; Wed, 31 Oct 2001 00:16:56 -0800 Received: (qmail 6474 invoked by uid 547); 31 Oct 2001 08:30:34 -0000 Date: Wed, 31 Oct 2001 09:30:34 +0100 From: GCS To: linux-xfs Subject: Re: ext3 + xfs + jfs + reiser Message-ID: <20011031093034.A6447@lsc.hu> References: <20011022122106.A12279@bistro.marx> <1003771829.13566.38.camel@stout.americas.sgi.com> <3BD45AAB.2D75ACAC@illusionary.com> <3BD53217.7080302@cae.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BD53217.7080302@cae.co.za>; from bgmilne@cae.co.za on Tue, Oct 23, 2001 at 11:02:15AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Oct 23, 2001 at 11:02:15AM +0200, Buchan Milne wrote: > This is not for the faint-of-heart ... After taking a look at the > kernel in Mandrake's cooker at: > http://www.linux-mandrake.com/cgi-bin/cvsweb.cgi/SPECS/kernel > you will notice that there are a lot of patches for XFS and JFS against > 2.4.12-ac3 ..... Also, take a look at ftp://c64.rulez.org/pub/users/gcs/patch-2.4.13 It is for kernel 2.4.13 ofcourse, contains LVM 1.0.1rc4, JFS 1.0.7 and ofcourse XFS of date oct. 26. Bye, GCS From owner-linux-xfs@oss.sgi.com Wed Oct 31 01:20:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9V9KLZ04312 for linux-xfs-outgoing; Wed, 31 Oct 2001 01:20:21 -0800 Received: from haddock.cd.chalmers.se (haddock.cd.chalmers.se [129.16.79.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9V9KH004289 for ; Wed, 31 Oct 2001 01:20:17 -0800 Received: from haddock.cd.chalmers.se (localhost [127.0.0.1]) by haddock.cd.chalmers.se (8.9.3+Sun/8.8.7) with ESMTP id KAA14265; Wed, 31 Oct 2001 10:19:59 +0100 (MET) Message-Id: <200110310919.KAA14265@haddock.cd.chalmers.se> X-Face: ^"+mumOlNwo;yI>`\39\txuVze?eiR9uqpo2*mE!9MWXgXI0v(3ArwymNWe'.q:eLl!=guD x{jGFEWN6,#HoN%2qRW;7.CL]9%Ap,067"u1%!NUqS.MhV'+,6$Fj-;W2Z}Y,JUZ'L+f)|B@3k3n;gLl*#i[(J-os#fNnDJ8m["|JWNwpORh|_.MGkR#|a~QS!"4hEQ{O{[Ii14{xD PU/:5wuv7m1=TK=.>G8wdfpY~]{H(Qa\1`%|Hz:!)c3f9UOW|WgE"4d\E7?oDu9. Content-Type: text/plain; charset=iso-8859-1 To: Keith Owens Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - Correct find next bit on 64 bit architectures In-Reply-To: Message from Keith Owens of "Wed, 31 Oct 2001 17:26:28 +1100." <200110310626.RAA11697@sherman.melbourne.sgi.com> References: <200110310626.RAA11697@sherman.melbourne.sgi.com> Date: Wed, 31 Oct 2001 10:19:59 +0100 From: Anders Hammarquist Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > The "find next bit" code has been changed recently (copied from > reiserfs), it fails on architectures where sizeof(int) != sizeof(long). > This explains why IA64 XFS recovery was failing, it may explain > problems on other 64 bit platforms. Excellent! This fixes recovery on sparc64 as well. Now all I have left to do is figure out why it breaks when running on an md device. When will people learn that all the world is NOT a VAX? /Anders -- -- Of course I'm crazy, but that doesn't mean I'm wrong. Anders Hammarquist | iko@cd.chalmers.se Physics student, Chalmers University of Technology, | Hem: +46 31 88 48 50 G|teborg, Sweden. RADIO: SM6XMM and N2JGL | Mob: +46 707 27 86 87 From owner-linux-xfs@oss.sgi.com Wed Oct 31 01:24:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9V9O8q04492 for linux-xfs-outgoing; Wed, 31 Oct 2001 01:24:08 -0800 Received: from pasmtp.tele.dk (pasmtp.tele.dk [193.162.159.95]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9V9O3004470 for ; Wed, 31 Oct 2001 01:24:04 -0800 Received: from mmstreaming.dk (staalanden.arkena.com [80.62.194.202]) by pasmtp.tele.dk (Postfix) with ESMTP id 36994B525 for ; Wed, 31 Oct 2001 10:24:00 +0100 (CET) Received: by mmstreaming.dk (Postfix, from userid 501) id A2992AD9C; Wed, 31 Oct 2001 10:23:59 +0100 (CET) Date: Wed, 31 Oct 2001 10:23:59 +0100 From: Thomas Kirk To: linux-xfs@oss.sgi.com Subject: warning Message-ID: <20011031102359.E20383@mmstreaming.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Im getting this info when im trying to create xfs filesystem on 400GB system : whatever:~# mkfs -t xfs -f /dev/sdb mkfs.xfs: warning - cannot set blocksize on block device /dev/sdb: Invalid argument ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ meta-data=/dev/sdb isize=256 agcount=100, agsize=1048576 blks data = bsize=4096 blocks=104248032, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=12725 realtime =none extsz=65536 blocks=0, rtextents=0 It exits fine and i can mount the disk afterward but somehow im not satisfied? Could somebody tell me if this is okie or not? -- Venlig hilsen/Kind regards Thomas Kirk ARKENA thomas(at)arkena(dot)com Http://www.arkena.com "On a normal ascii line, the only safe condition to detect is a 'BREAK' - everything else having been assigned functions by Gnu EMACS." (By Tarl Neustaedter) From owner-linux-xfs@oss.sgi.com Wed Oct 31 01:39:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9V9drk04897 for linux-xfs-outgoing; Wed, 31 Oct 2001 01:39:53 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9V9dn004874 for ; Wed, 31 Oct 2001 01:39:49 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id BAA26578 for ; Wed, 31 Oct 2001 01:39:42 -0800 (PST) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip.americas.sgi.com [128.162.185.208]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id DAA3453683; Wed, 31 Oct 2001 03:38:33 -0600 (CST) Received: from sgi.com (lord-net.americas.sgi.com [128.162.154.13]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id DAA39350; Wed, 31 Oct 2001 03:38:32 -0600 (CST) Message-ID: <3BDFC7D9.2C9877FF@sgi.com> Date: Wed, 31 Oct 2001 03:43:53 -0600 From: Stephen Lord X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Kirk CC: linux-xfs@oss.sgi.com Subject: Re: warning References: <20011031102359.E20383@mmstreaming.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thomas Kirk wrote: > Im getting this info when im trying to create xfs filesystem on 400GB > system : > > whatever:~# mkfs -t xfs -f /dev/sdb > mkfs.xfs: warning - cannot set blocksize on block device /dev/sdb: Invalid argument > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ You need a newer mkfs - the ioctl to do the set blocksize was removed, since we no longer needed it. The warning is actually harmless though. Steve > > > meta-data=/dev/sdb isize=256 agcount=100, agsize=1048576 blks > data = bsize=4096 blocks=104248032, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=0 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=12725 > realtime =none extsz=65536 blocks=0, rtextents=0 > > It exits fine and i can mount the disk afterward but somehow im not > satisfied? Could somebody tell me if this is okie or not? > > -- > Venlig hilsen/Kind regards > Thomas Kirk > ARKENA > thomas(at)arkena(dot)com > Http://www.arkena.com > > "On a normal ascii line, the only safe condition to detect is a 'BREAK' > - everything else having been assigned functions by Gnu EMACS." > (By Tarl Neustaedter) From owner-linux-xfs@oss.sgi.com Wed Oct 31 01:42:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9V9gg805176 for linux-xfs-outgoing; Wed, 31 Oct 2001 01:42:42 -0800 Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9V9gc005148 for ; Wed, 31 Oct 2001 01:42:38 -0800 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9V9gWB9093324; Wed, 31 Oct 2001 10:42:32 +0100 (CET) Message-Id: <4.3.2.7.2.20011031103945.0373f208@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 31 Oct 2001 10:40:46 +0100 To: Thomas Kirk , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: warning In-Reply-To: <20011031102359.E20383@mmstreaming.dk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 10:23 31-10-2001 +0100, Thomas Kirk wrote: >Im getting this info when im trying to create xfs filesystem on 400GB >system : > >whatever:~# mkfs -t xfs -f /dev/sdb >mkfs.xfs: warning - cannot set blocksize on block device /dev/sdb: Invalid >argument >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >meta-data=/dev/sdb isize=256 agcount=100, agsize=1048576 blks >data = bsize=4096 blocks=104248032, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=0 >naming =version 2 bsize=4096 >log =internal log bsize=4096 blocks=12725 >realtime =none extsz=65536 blocks=0, rtextents=0 > >It exits fine and i can mount the disk afterward but somehow im not >satisfied? Could somebody tell me if this is okie or not? This is fine. This was due to a removed IO ctl somewhere down the line. It does not affect operational behaviour. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Wed Oct 31 05:01:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9VD1I112534 for linux-xfs-outgoing; Wed, 31 Oct 2001 05:01:18 -0800 Received: from relais-int6.globalintranet.net (mailgate.globalintranet.net [194.206.181.247]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9VD1C012512 for ; Wed, 31 Oct 2001 05:01:12 -0800 Received: from ginnbc175.ftgin.net ([10.255.7.31]) by relais-int6.globalintranet.net (Netscape Messaging Server 4.15) with ESMTP id GM2MTO02.NEU for ; Wed, 31 Oct 2001 14:01:00 +0100 To: linux-xfs@oss.sgi.com Subject: Re: warning MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.07a May 14, 2001 From: alexis.janiak@intranode.com Message-ID: Date: Wed, 31 Oct 2001 14:01:22 +0100 X-MIMETrack: Serialize by Router on E-NODE/Srv/INTRANODE(Release 5.0.3 (France)|21 March 2000) at 31/10/2001 14:01:41, Serialize complete at 31/10/2001 14:01:41 Content-Type: text/plain; charset="us-ascii" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk perhaps I'm wrong, but mkfs need a partition device (/dev/sdb1 for example), not the device itself (/dev/sdb), doesn't it ? shouldn't be : whatever:~# mkfs -t xfs -f /dev/sdb1 ^ what happen with a device argument (boot sector, partitions, etc etc) ? > > Im getting this info when im trying to create xfs filesystem on 400GB > system : > > whatever:~# mkfs -t xfs -f /dev/sdb > mkfs.xfs: warning - cannot set blocksize on block device /dev/sdb: Invalid > argument > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > meta-data=/dev/sdb isize=256 agcount=100, agsize=1048576 blks > data = bsize=4096 blocks=104248032, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=0 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=12725 > realtime =none extsz=65536 blocks=0, rtextents=0 > > It exits fine and i can mount the disk afterward but somehow im not > satisfied? Could somebody tell me if this is okie or not? > > -- > Venlig hilsen/Kind regards > Thomas Kirk > ARKENA > thomas(at)arkena(dot)com > Http://www.arkena.com > > > "On a normal ascii line, the only safe condition to detect is a 'BREAK' > - everything else having been assigned functions by Gnu EMACS." > (By Tarl Neustaedter) > From owner-linux-xfs@oss.sgi.com Wed Oct 31 06:13:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9VEDLO24648 for linux-xfs-outgoing; Wed, 31 Oct 2001 06:13:21 -0800 Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9VEDI024276 for ; Wed, 31 Oct 2001 06:13:18 -0800 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id f9VEDEUs099161; Wed, 31 Oct 2001 15:13:14 +0100 (CET) Message-Id: <4.3.2.7.2.20011031151027.03556bc8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 31 Oct 2001 15:11:26 +0100 To: alexis.janiak@intranode.com, linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: warning In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 14:01 31-10-2001 +0100, alexis.janiak@intranode.com wrote: >perhaps I'm wrong, but mkfs need a partition device (/dev/sdb1 for >example), not the device itself (/dev/sdb), doesn't it ? >shouldn't be : >whatever:~# mkfs -t xfs -f /dev/sdb1 It is not neccesary. You can fomat the raw device if you wish to do so. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Wed Oct 31 06:17:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9VEHpe25895 for linux-xfs-outgoing; Wed, 31 Oct 2001 06:17:51 -0800 Received: from rover (rover.mkp.net [209.217.122.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9VEHm025873 for ; Wed, 31 Oct 2001 06:17:48 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=jaguar.mkp.net) by rover with esmtp (Exim 3.33 #1) id 15ywBd-0006Zx-00; Wed, 31 Oct 2001 09:17:45 -0500 Received: (from mkp@localhost) by jaguar.mkp.net (8.11.2/8.9.3) id f9VEHfo01840; Wed, 31 Oct 2001 09:17:41 -0500 X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f To: alexis.janiak@intranode.com Cc: linux-xfs@oss.sgi.com Subject: Re: warning References: From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 31 Oct 2001 09:17:41 -0500 In-Reply-To: Message-ID: Lines: 16 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk alexis> perhaps I'm wrong, but mkfs need a partition device (/dev/sdb1 alexis> for example), not the device itself (/dev/sdb), doesn't it ? Nobody forces you to partition a disk. If you don't have to deal with other operating systems, using the unpartitioned device is just fine. alexis> what happen with a device argument (boot sector, partitions, etc etc) ? Boot sector and partitions get overwritten. -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Wed Oct 31 09:02:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9VH2R607538 for linux-xfs-outgoing; Wed, 31 Oct 2001 09:02:27 -0800 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9VH2K007515 for ; Wed, 31 Oct 2001 09:02:20 -0800 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f9VH1ZS14987 for ; Wed, 31 Oct 2001 12:01:35 -0500 (EST) Received: from zcard00n.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 31 Oct 2001 12:01:55 -0500 Received: from zmerd004.ca.nortel.com ([47.124.0.133]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id V88B5LKD; Wed, 31 Oct 2001 12:01:16 -0500 Received: from wmery000.ca.nortel.com ([47.131.36.101]) by zmerd004.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 418H70YF; Wed, 31 Oct 2001 12:01:16 -0500 Subject: Re: Kernel OOPS 2.4.5-XFS-1.0.1 w/Feral FC drivers From: "Sean Kormilo" To: Steve Lord Cc: Linux XFS In-Reply-To: <1004476985.28795.46.camel@jen.americas.sgi.com> References: <1004476153.21484.32.camel@wmery000.ca.nortel.com> <1004476985.28795.46.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 31 Oct 2001 12:01:53 -0500 Message-Id: <1004547713.21484.64.camel@wmery000.ca.nortel.com> Mime-Version: 1.0 X-Orig: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve, Thanks for the quick response. > In this case I have no idea - if you are not running on an xfs > filesystem then this has nothing to do with xfs, there are no mods in > the code base which would get executed in this case. > > I suspect the forced shutdown code in xfs is going to need some work > before this scenario will work for you. You could try editing the > _xfs_force_shutdown() function in fs/xfs/xfs_rw.c and removing this > chunk of code: > > while (xfs_incore_relse(&mp->m_ddev_targ, 1, 0)) { > if (ntries >= XFS_MAX_DRELSE_RETRIES) > break; > delay(++ntries * 5); > } > > What it is doing in there looks radically different from the Irix > version, and is I suspect broken in this case. Let me know what this > does for you. I made this change, and the panic no longer occurs there (the one with the oops output), but I still get the other "scsi_free:Bad offset" panic. For some reason, that particular panic does not produce the "oops" type output, so there is no traceback to follow. Any idea how I can get it to supply me with the oops output? I realize this is likely no longer an XFS problem, but something in the SCSI layer. In terms of this modification you described, are there any system level impacts to removing this code? Based on the comments there, it doesn't seem like there should be. Incidentally, I immediately unmount and ther remount the filesystem once I'm able to do so (ie: once the FC link is plugged back in). > > What does happen with ext2 - it should be getting I/O errors back from > the fiber channel driver. > I'm still trying to quantify the ext2 behaviour. I have some problems with a few of my scripts that are designed to handle this scenario. Once I get those straightened out, I should be able to supply a better answer. Sean. -- Sean C. Kormilo, Software Architect, Nortel Networks email: skormilo@nortelnetworks.com From owner-linux-xfs@oss.sgi.com Wed Oct 31 10:01:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9VI1DC08854 for linux-xfs-outgoing; Wed, 31 Oct 2001 10:01:13 -0800 Received: from www.fortuitous.com (cs6625128-203.austin.rr.com [66.25.128.203]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9VI18008831 for ; Wed, 31 Oct 2001 10:01:08 -0800 Received: by www.fortuitous.com (Postfix, from userid 500) id EA596C0F; Wed, 31 Oct 2001 12:01:19 -0600 (CST) Date: Wed, 31 Oct 2001 12:01:19 -0600 From: pac@fortuitous.com To: linux-xfs@oss.sgi.com Subject: OT: VMware crashes, corrupts files. Message-ID: <20011031120119.A7699@bistro.marx> Reply-To: pac@fortuitous.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f9VI19008832 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Linux 2.4.4-xfs #2 , CVS kernel. vmware 2.0.4 build 1118 Vmware will occasionally suspend to a strange mode where when I restart vmware, the entire system locks up. Im forced to reboot. The interesting thing is that when I look at the ~/.vmware/preferences files ( a text file ) its filled with control characters etc... Its exactly the same size as the original maybe +_ a single byte. When I look at the vmware data file directories, there is a lock file present. I delete the lock files, restored ~/.vmware/preferences, deleted nvram file and it works again. Otherwise, it continues to lock my computer solid. Im working on an upgrade to 2.4.7-xfs now. -pac -- .--------------------------------------------------------. | Dr. Philip A. Carinhas | pac@fortuitous.com | | Fortuitous Technologies Inc. | http://fortuitous.com | | Linux Consulting & Training | Tel : 1-512-467-2154 | `--------------------------------------------------------' From owner-linux-xfs@oss.sgi.com Wed Oct 31 11:47:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9VJln114225 for linux-xfs-outgoing; Wed, 31 Oct 2001 11:47:49 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9VJlZ014202 for ; Wed, 31 Oct 2001 11:47:35 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id UAA1315549 for ; Wed, 31 Oct 2001 20:47:33 +0100 (CET) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA3460738 for ; Wed, 31 Oct 2001 13:46:16 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA24407 for ; Wed, 31 Oct 2001 13:46:16 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id f9VJgSO08703; Wed, 31 Oct 2001 13:42:28 -0600 Message-Id: <200110311942.f9VJgSO08703@jen.americas.sgi.com> Date: Wed, 31 Oct 2001 13:42:28 -0600 Subject: TAKE - merge upto 2.4.14-pre6 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Here we go again ..... Date: Wed Oct 31 11:44:21 PST 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:105838a linux/include/linux/netfilter_ipv4/ipt_length.h - 1.1 linux/net/ipv6/netfilter/ip6t_owner.c - 1.1 linux/net/ipv6/netfilter/ip6t_LOG.c - 1.1 linux/net/ipv4/netfilter/ipt_ttl.c - 1.1 linux/net/ipv4/netfilter/ipt_length.c - 1.1 linux/net/ipv4/netfilter/ip_nat_snmp_basic.c - 1.1 linux/net/ipv4/netfilter/ip_nat_irc.c - 1.1 linux/net/ipv4/netfilter/ip_conntrack_irc.c - 1.1 linux/net/8021q/vlanproc.h - 1.1 linux/net/8021q/vlanproc.c - 1.1 linux/net/8021q/vlan_dev.c - 1.1 linux/net/8021q/vlan.h - 1.1 linux/net/8021q/vlan.c - 1.1 linux/net/8021q/Makefile - 1.1 linux/include/linux/netfilter_ipv4/ipt_ttl.h - 1.1 linux/include/linux/netfilter_ipv4/ip_conntrack_irc.h - 1.1 linux/include/linux/if_vlan.h - 1.1 linux/net/packet/af_packet.c - 1.26 linux/net/netsyms.c - 1.38 linux/net/irda/Makefile - 1.8 linux/net/ipx/Makefile - 1.4 linux/net/ipv6/tcp_ipv6.c - 1.30 linux/net/ipv4/tcp_output.c - 1.24 linux/net/ipv4/tcp_ipv4.c - 1.38 linux/net/ipv4/tcp_input.c - 1.31 linux/net/ipv4/tcp.c - 1.35 linux/net/ipv4/sysctl_net_ipv4.c - 1.13 linux/net/ipv4/syncookies.c - 1.13 linux/net/ipv4/route.c - 1.29 linux/net/ipv4/ipconfig.c - 1.21 linux/net/ipv4/ip_sockglue.c - 1.17 linux/net/ipv4/ip_gre.c - 1.18 linux/net/ipv4/af_inet.c - 1.29 linux/net/ipv4/Makefile - 1.7 linux/net/ethernet/Makefile - 1.4 linux/net/core/dev.c - 1.47 linux/net/core/Makefile - 1.6 linux/net/Makefile - 1.16 linux/net/Config.in - 1.18 linux/net/802/Makefile - 1.5 linux/mm/vmscan.c - 1.86 linux/mm/page_alloc.c - 1.65 linux/mm/memory.c - 1.67 linux/mm/filemap.c - 1.96 linux/kernel/ksyms.c - 1.116 linux/include/net/tcp.h - 1.26 linux/include/net/sock.h - 1.25 linux/include/net/route.h - 1.14 linux/include/linux/sockios.h - 1.8 linux/include/linux/sched.h - 1.46 linux/include/linux/pci.h - 1.50 linux/include/linux/pagemap.h - 1.35 linux/include/linux/netdevice.h - 1.30 linux/include/linux/mm.h - 1.71 linux/include/linux/if_ether.h - 1.9 linux/include/linux/if_arp.h - 1.12 linux/include/linux/if.h - 1.4 linux/include/asm-sparc64/pgtable.h - 1.26 linux/include/asm-sparc64/floppy.h - 1.15 linux/include/asm-sparc/uaccess.h - 1.8 linux/include/asm-sparc/system.h - 1.10 linux/include/asm-sparc/spinlock.h - 1.8 linux/include/asm-sparc/semaphore.h - 1.8 linux/include/asm-sparc/scatterlist.h - 1.8 linux/include/asm-sparc/checksum.h - 1.5 linux/include/asm-sparc/bitops.h - 1.13 linux/include/asm-sparc/atomic.h - 1.9 linux/fs/super.c - 1.67 linux/fs/dquot.c - 1.43 linux/drivers/scsi/st.c - 1.35 linux/drivers/scsi/qlogicpti.c - 1.16 linux/drivers/sbus/char/zs.c - 1.20 linux/drivers/net/sunlance.c - 1.24 linux/drivers/net/sunbmac.c - 1.20 linux/drivers/char/random.c - 1.22 linux/arch/sparc64/mm/ultra.S - 1.21 linux/arch/sparc64/mm/init.c - 1.35 linux/arch/sparc64/kernel/sys_sparc.c - 1.21 linux/arch/sparc64/kernel/sparc64_ksyms.c - 1.36 linux/arch/sparc64/kernel/smp.c - 1.30 linux/arch/sparc64/kernel/setup.c - 1.24 linux/arch/sparc64/defconfig - 1.53 linux/arch/sparc/prom/console.c - 1.8 linux/arch/sparc/mm/sun4c.c - 1.28 linux/arch/sparc/mm/srmmu.c - 1.27 linux/arch/sparc/mm/fault.c - 1.17 linux/arch/sparc/kernel/windows.c - 1.4 linux/arch/sparc/kernel/time.c - 1.14 linux/arch/sparc/kernel/sparc-stub.c - 1.8 linux/arch/sparc/kernel/ioport.c - 1.19 linux/arch/sparc/kernel/check_asm.sh - 1.5 linux/arch/sparc/defconfig - 1.26 linux/Makefile - 1.147 linux/Documentation/Configure.help - 1.112 linux/drivers/sbus/char/aurora.c - 1.16 linux/drivers/char/drm/drmP.h - 1.15 linux/include/asm-sparc64/pgalloc.h - 1.15 linux/drivers/usb/usb-uhci-debug.h - 1.6 linux/arch/i386/kernel/microcode.c - 1.12 linux/net/ipv4/netfilter/ip_tables.c - 1.12 linux/net/ipv4/netfilter/ip_nat_ftp.c - 1.8 linux/net/ipv4/netfilter/ip_conntrack_ftp.c - 1.8 linux/net/ipv4/netfilter/Makefile - 1.9 linux/net/ipv4/netfilter/Config.in - 1.5 linux/include/linux/netfilter_ipv4/ip_conntrack.h - 1.8 linux/net/ipv6/netfilter/ip6t_limit.c - 1.3 linux/net/ipv6/netfilter/ip6_tables.c - 1.9 linux/net/ipv6/netfilter/Makefile - 1.8 linux/net/ipv6/netfilter/Config.in - 1.3 linux/net/ipv6/netfilter/ip6t_multiport.c - 1.2 linux/net/ipv6/netfilter/ip6t_mac.c - 1.3 linux/include/net/inet_ecn.h - 1.2 linux/include/net/tcp_ecn.h - 1.3 linux/mm/oom_kill.c - 1.9 linux/include/asm-sparc/xor.h - 1.2 linux/mm/shmem.c - 1.22 linux/fs/reiserfs/stree.c - 1.10 linux/fs/reiserfs/super.c - 1.9 linux/fs/reiserfs/tail_conversion.c - 1.8 linux/fs/reiserfs/prints.c - 1.7 linux/fs/reiserfs/objectid.c - 1.6 linux/fs/reiserfs/namei.c - 1.11 linux/fs/reiserfs/lbalance.c - 1.5 linux/fs/reiserfs/journal.c - 1.11 linux/fs/reiserfs/inode.c - 1.17 linux/fs/reiserfs/ibalance.c - 1.5 linux/fs/reiserfs/do_balan.c - 1.6 linux/fs/reiserfs/dir.c - 1.8 linux/fs/reiserfs/buffer2.c - 1.4 linux/include/linux/reiserfs_fs.h - 1.11 linux/drivers/video/aty/atyfb_base.c - 1.6 linux/drivers/char/drm/drm_vm.h - 1.7 From owner-linux-xfs@oss.sgi.com Wed Oct 31 11:52:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9VJqYu14401 for linux-xfs-outgoing; Wed, 31 Oct 2001 11:52:34 -0800 Received: from umbi3.umbi.umd.edu (umbi3.umbi.umd.edu [136.160.7.51]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9VJqN014378 for ; Wed, 31 Oct 2001 11:52:23 -0800 Received: from umbi.umd.edu (mystery.carb.nist.gov [129.6.113.182]) by umbi3.umbi.umd.edu (Netscape Messaging Server 4.15) with ESMTP id GM35V900.4AE; Wed, 31 Oct 2001 14:52:21 -0500 Message-ID: <3BE05612.5BD3FFA4@umbi.umd.edu> Date: Wed, 31 Oct 2001 14:50:42 -0500 From: Jonathan Dill Organization: CARB X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-6SGI_XFS_PR3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Todd Raeker , Linux XFS Mailing List Subject: filesize limit "rolls over" to 0 kbytes at 4 GB References: <01102909435902.11332@chemraeker1> <3BDD8E31.9C817A5@umbi.umd.edu> <01103113542200.01720@chemraeker1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Todd Raeker wrote: > Thanks for the info you provided. I did as your suggest but then ran into > a 4 GB limit. Running limit under tcsh showed the 4 GB limit. However, I > should be able to unlimit the filesize but am ignored. What do you get when > you issue the limit command ? Certainly 4 GB is better than 2 but I should > not be limited as I think I am doing what I need. (Just to refresh for the list, we recompiled tcsh with O_LARGEFILE to get past the 2 GB filesize limit, but now "limit -h" shows a 4 GB limit). Hmm. I see what you mean when I do "limit -h" it says the filesize limit is 4194302 kbytes. However, despite the advertised limit, I was able to create a 4.7 GB file as root: [root@localhost ~]# du -h /trans/mystery/20011025.home.0.gz 4.7G /trans/mystery/20011025.home.0.gz What's very odd is that the value seems to "roll over" to 0 kbytes at precisely 4 GB: [root@localhost ~]# limit -h cputime 0:0-1 filesize 4194303 kbytes datasize 4194303 kbytes stacksize 4194303 kbytes coredumpsize 4194303 kbytes memoryuse 4194303 kbytes descriptors 1024 memorylocked 4194303 kbytes maxproc 1535 openfiles 1024 [root@localhost ~]# limit -h filesize 4194304 [root@localhost ~]# limit -h cputime 0:0-1 filesize 0 kbytes datasize 4194303 kbytes stacksize 4194303 kbytes coredumpsize 4194303 kbytes memoryuse 4194303 kbytes descriptors 1024 memorylocked 4194303 kbytes maxproc 1535 openfiles 1024 If you keep increasing the limit, you get a modulus of 4 GB eg. 5 GB gives you a limit of 1 GB, 37 GB gives you a limit of 1 GB etc. Anybody have any ideas about this? -- "Jonathan F. Dill" (dill@umbi.umd.edu) From owner-linux-xfs@oss.sgi.com Wed Oct 31 12:04:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9VK4Wa14864 for linux-xfs-outgoing; Wed, 31 Oct 2001 12:04:32 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9VK4S014842 for ; Wed, 31 Oct 2001 12:04:28 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9VK4MT01037 for ; Wed, 31 Oct 2001 12:04:22 -0800 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA3463730; Wed, 31 Oct 2001 14:03:06 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA64090; Wed, 31 Oct 2001 14:03:06 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id f9VJxH209320; Wed, 31 Oct 2001 13:59:17 -0600 Subject: Re: filesize limit "rolls over" to 0 kbytes at 4 GB From: Steve Lord To: Jonathan Dill Cc: Todd Raeker , Linux XFS Mailing List In-Reply-To: <3BE05612.5BD3FFA4@umbi.umd.edu> References: <01102909435902.11332@chemraeker1> <3BDD8E31.9C817A5@umbi.umd.edu> <01103113542200.01720@chemraeker1> <3BE05612.5BD3FFA4@umbi.umd.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16.99+cvs.2001.10.31.06.29 (Preview Release) Date: 31 Oct 2001 13:59:17 -0600 Message-Id: <1004558357.8600.23.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2001-10-31 at 13:50, Jonathan Dill wrote: > > If you keep increasing the limit, you get a modulus of 4 GB eg. 5 GB > gives you a limit of 1 GB, 37 GB gives you a limit of 1 GB etc. > > Anybody have any ideas about this? > > -- > "Jonathan F. Dill" (dill@umbi.umd.edu) I do know that if you use the limits interface then there is only 4 bytes of space in the kernel to store limits. Which means you cannot impose a limit of greater than 4G bytes. The rollover you are seeing is probably because of this. Setting a limit to RLIM_INFINITY which is 0xffffffff on i386 effectively disables the limit checking and this is the only way to get into higher order files. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Oct 31 13:39:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9VLd7R19452 for linux-xfs-outgoing; Wed, 31 Oct 2001 13:39:07 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9VLd4019430 for ; Wed, 31 Oct 2001 13:39:04 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA28781 for ; Wed, 31 Oct 2001 13:38:56 -0800 (PST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA3294319 for ; Wed, 31 Oct 2001 15:37:47 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id PAA41571 for ; Wed, 31 Oct 2001 15:37:47 -0600 (CST) Subject: More testing RPMs From: Eric Sandeen To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16 (Preview Release) Date: 31 Oct 2001 15:37:42 -0600 Message-Id: <1004564262.2022.9.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ok gang, this time you get "PR4" ftp://oss.sgi.com/projects/xfs/download/testing/RH2.4.9-6 (for RH7.1) ftp://oss.sgi.com/projects/xfs/download/testing/RH2.4.9-7 (for RH7.2) Changes in PR4: * Disabled (broken) xfs support in intermezzo * Merged in a few recent xfs fixes Have fun, -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Oct 31 13:41:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9VLfY219796 for linux-xfs-outgoing; Wed, 31 Oct 2001 13:41:34 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9VLeI019639 for ; Wed, 31 Oct 2001 13:40:18 -0800 Received: from ausmail.coremetrics.com ([209.184.141.185]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAB04030 for ; Wed, 31 Oct 2001 13:40:08 -0800 (PST) mail_from (austin@coremetrics.com) Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Wed, 31 Oct 2001 15:37:58 -0600 Message-ID: <85063BBE668FD411944400D0B744267A8886BE@AUSMAIL> From: "Gonyou, Austin" To: Linux XFS Mailing List Subject: Linux + XFS + SCSI = Problems? Date: Wed, 31 Oct 2001 15:37:57 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C16254.4E490DF0" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk 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_01C16254.4E490DF0 Content-Type: text/plain; charset="iso-8859-1" I'm trying to uncover the root of an issue. The issue is this: When running a perl script I can get perl to jump up to 99% cpu. When this happens, I can't kill the process. The only thing I can do to recover properly is reset the system. Either power cycle or reset. Is there anyone who could attempt to run the attatched script and let me know if they experience something similar? The targe configuration of the box I'm most concerned with is as follows: 512MB RAM (ecc, parity, registered) 1x 9GB SCSI HDD(seagate) 1x PCI RAID controller(AMI MegaRAID express) wrthru and read-cached. DUAL 550 PIII RH 7.1 SGI XFS 1.0 installed or later. non-updated perl 5.6.0(installed with 7.1) Mount options for the filesystem I'm testing with. /dev/sda5 on /home type xfs (rw,biosize=13,logbufs=8,osyncisdsync) 2.4.13 Vanilla kernel + SGI XFS patch for 2.4.13. Attatched are the perl scripts I use to test with. Also the kernel config I'm using. I'm pretty desparate here. If you can offer help on this, please help! -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com ------_=_NextPart_000_01C16254.4E490DF0 Content-Type: text/plain; name="1550-Kernel-config.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="1550-Kernel-config.txt" #=0A= # Automatically generated by make menuconfig: don't edit=0A= #=0A= CONFIG_X86=3Dy=0A= CONFIG_ISA=3Dy=0A= # CONFIG_SBUS is not set=0A= CONFIG_UID16=3Dy=0A= =0A= #=0A= # Code maturity level options=0A= #=0A= CONFIG_EXPERIMENTAL=3Dy=0A= =0A= #=0A= # Loadable module support=0A= #=0A= CONFIG_MODULES=3Dy=0A= CONFIG_MODVERSIONS=3Dy=0A= CONFIG_KMOD=3Dy=0A= =0A= #=0A= # Processor type and features=0A= #=0A= # CONFIG_M386 is not set=0A= # CONFIG_M486 is not set=0A= # CONFIG_M586 is not set=0A= # CONFIG_M586TSC is not set=0A= # CONFIG_M586MMX is not set=0A= # CONFIG_M686 is not set=0A= CONFIG_MPENTIUMIII=3Dy=0A= # CONFIG_MPENTIUM4 is not set=0A= # CONFIG_MK6 is not set=0A= # CONFIG_MK7 is not set=0A= # CONFIG_MCRUSOE is not set=0A= # CONFIG_MWINCHIPC6 is not set=0A= # CONFIG_MWINCHIP2 is not set=0A= # CONFIG_MWINCHIP3D is not set=0A= # CONFIG_MCYRIXIII is not set=0A= CONFIG_X86_WP_WORKS_OK=3Dy=0A= CONFIG_X86_INVLPG=3Dy=0A= CONFIG_X86_CMPXCHG=3Dy=0A= CONFIG_X86_XADD=3Dy=0A= CONFIG_X86_BSWAP=3Dy=0A= CONFIG_X86_POPAD_OK=3Dy=0A= # CONFIG_RWSEM_GENERIC_SPINLOCK is not set=0A= CONFIG_RWSEM_XCHGADD_ALGORITHM=3Dy=0A= CONFIG_X86_L1_CACHE_SHIFT=3D5=0A= CONFIG_X86_TSC=3Dy=0A= CONFIG_X86_GOOD_APIC=3Dy=0A= CONFIG_X86_PGE=3Dy=0A= CONFIG_X86_USE_PPRO_CHECKSUM=3Dy=0A= # CONFIG_TOSHIBA is not set=0A= # CONFIG_MICROCODE is not set=0A= # CONFIG_X86_MSR is not set=0A= # CONFIG_X86_CPUID is not set=0A= CONFIG_NOHIGHMEM=3Dy=0A= # CONFIG_HIGHMEM4G is not set=0A= # CONFIG_HIGHMEM64G is not set=0A= # CONFIG_MATH_EMULATION is not set=0A= # CONFIG_MTRR is not set=0A= CONFIG_SMP=3Dy=0A= # CONFIG_MULTIQUAD is not set=0A= CONFIG_HAVE_DEC_LOCK=3Dy=0A= =0A= #=0A= # General setup=0A= #=0A= CONFIG_NET=3Dy=0A= CONFIG_X86_IO_APIC=3Dy=0A= CONFIG_X86_LOCAL_APIC=3Dy=0A= CONFIG_PCI=3Dy=0A= # CONFIG_PCI_GOBIOS is not set=0A= # CONFIG_PCI_GODIRECT is not set=0A= CONFIG_PCI_GOANY=3Dy=0A= CONFIG_PCI_BIOS=3Dy=0A= CONFIG_PCI_DIRECT=3Dy=0A= CONFIG_PCI_NAMES=3Dy=0A= # CONFIG_EISA is not set=0A= # CONFIG_MCA is not set=0A= CONFIG_HOTPLUG=3Dy=0A= =0A= #=0A= # PCMCIA/CardBus support=0A= #=0A= CONFIG_PCMCIA=3Dy=0A= CONFIG_CARDBUS=3Dy=0A= # CONFIG_I82365 is not set=0A= # CONFIG_TCIC is not set=0A= CONFIG_SYSVIPC=3Dy=0A= CONFIG_BSD_PROCESS_ACCT=3Dy=0A= CONFIG_SYSCTL=3Dy=0A= CONFIG_KCORE_ELF=3Dy=0A= # CONFIG_KCORE_AOUT is not set=0A= CONFIG_BINFMT_AOUT=3Dy=0A= CONFIG_BINFMT_ELF=3Dy=0A= # CONFIG_BINFMT_MISC is not set=0A= # CONFIG_PM is not set=0A= # CONFIG_ACPI is not set=0A= # CONFIG_APM is not set=0A= =0A= #=0A= # Memory Technology Devices (MTD)=0A= #=0A= # CONFIG_MTD is not set=0A= =0A= #=0A= # Parallel port support=0A= #=0A= # CONFIG_PARPORT is not set=0A= =0A= #=0A= # Plug and Play configuration=0A= #=0A= # CONFIG_PNP is not set=0A= # CONFIG_ISAPNP is not set=0A= # CONFIG_PNPBIOS is not set=0A= =0A= #=0A= # Block devices=0A= #=0A= CONFIG_BLK_DEV_FD=3Dy=0A= # CONFIG_BLK_DEV_XD is not set=0A= # CONFIG_PARIDE is not set=0A= # CONFIG_BLK_CPQ_DA is not set=0A= # CONFIG_BLK_CPQ_CISS_DA is not set=0A= # CONFIG_BLK_DEV_DAC960 is not set=0A= CONFIG_BLK_DEV_LOOP=3Dy=0A= # CONFIG_BLK_DEV_NBD is not set=0A= CONFIG_BLK_DEV_RAM=3Dy=0A= CONFIG_BLK_DEV_RAM_SIZE=3D4096=0A= CONFIG_BLK_DEV_INITRD=3Dy=0A= =0A= #=0A= # Multi-device support (RAID and LVM)=0A= #=0A= CONFIG_MD=3Dy=0A= # CONFIG_BLK_DEV_MD is not set=0A= # CONFIG_MD_LINEAR is not set=0A= # CONFIG_MD_RAID0 is not set=0A= # CONFIG_MD_RAID1 is not set=0A= # CONFIG_MD_RAID5 is not set=0A= # CONFIG_MD_MULTIPATH is not set=0A= CONFIG_BLK_DEV_LVM=3Dy=0A= =0A= #=0A= # Networking options=0A= #=0A= CONFIG_PACKET=3Dy=0A= CONFIG_PACKET_MMAP=3Dy=0A= # CONFIG_NETLINK is not set=0A= # CONFIG_NETFILTER is not set=0A= CONFIG_FILTER=3Dy=0A= CONFIG_UNIX=3Dy=0A= CONFIG_INET=3Dy=0A= CONFIG_IP_MULTICAST=3Dy=0A= # CONFIG_IP_ADVANCED_ROUTER is not set=0A= # CONFIG_IP_PNP is not set=0A= # CONFIG_NET_IPIP is not set=0A= # CONFIG_NET_IPGRE is not set=0A= # CONFIG_IP_MROUTE is not set=0A= # CONFIG_INET_ECN is not set=0A= # CONFIG_SYN_COOKIES is not set=0A= # CONFIG_IPV6 is not set=0A= # CONFIG_KHTTPD is not set=0A= # CONFIG_ATM is not set=0A= # CONFIG_IPX is not set=0A= # CONFIG_ATALK is not set=0A= # CONFIG_DECNET is not set=0A= # CONFIG_BRIDGE is not set=0A= # CONFIG_X25 is not set=0A= # CONFIG_LAPB is not set=0A= # CONFIG_LLC is not set=0A= # CONFIG_NET_DIVERT is not set=0A= # CONFIG_ECONET is not set=0A= # CONFIG_WAN_ROUTER is not set=0A= # CONFIG_NET_FASTROUTE is not set=0A= # CONFIG_NET_HW_FLOWCONTROL is not set=0A= =0A= #=0A= # QoS and/or fair queueing=0A= #=0A= # CONFIG_NET_SCHED is not set=0A= =0A= #=0A= # Telephony Support=0A= #=0A= # CONFIG_PHONE is not set=0A= # CONFIG_PHONE_IXJ is not set=0A= # CONFIG_PHONE_IXJ_PCMCIA is not set=0A= =0A= #=0A= # ATA/IDE/MFM/RLL support=0A= #=0A= CONFIG_IDE=3Dy=0A= =0A= #=0A= # IDE, ATA and ATAPI Block devices=0A= #=0A= CONFIG_BLK_DEV_IDE=3Dy=0A= # CONFIG_BLK_DEV_HD_IDE is not set=0A= # CONFIG_BLK_DEV_HD is not set=0A= # CONFIG_BLK_DEV_IDEDISK is not set=0A= # CONFIG_IDEDISK_MULTI_MODE is not set=0A= # CONFIG_BLK_DEV_IDEDISK_VENDOR is not set=0A= # CONFIG_BLK_DEV_IDEDISK_FUJITSU is not set=0A= # CONFIG_BLK_DEV_IDEDISK_IBM is not set=0A= # CONFIG_BLK_DEV_IDEDISK_MAXTOR is not set=0A= # CONFIG_BLK_DEV_IDEDISK_QUANTUM is not set=0A= # CONFIG_BLK_DEV_IDEDISK_SEAGATE is not set=0A= # CONFIG_BLK_DEV_IDEDISK_WD is not set=0A= # CONFIG_BLK_DEV_COMMERIAL is not set=0A= # CONFIG_BLK_DEV_TIVO is not set=0A= # CONFIG_BLK_DEV_IDECS is not set=0A= CONFIG_BLK_DEV_IDECD=3Dy=0A= # CONFIG_BLK_DEV_IDETAPE is not set=0A= # CONFIG_BLK_DEV_IDEFLOPPY is not set=0A= # CONFIG_BLK_DEV_IDESCSI is not set=0A= # CONFIG_BLK_DEV_CMD640 is not set=0A= # CONFIG_BLK_DEV_CMD640_ENHANCED is not set=0A= # CONFIG_BLK_DEV_ISAPNP is not set=0A= # CONFIG_BLK_DEV_RZ1000 is not set=0A= CONFIG_BLK_DEV_IDEPCI=3Dy=0A= CONFIG_IDEPCI_SHARE_IRQ=3Dy=0A= CONFIG_BLK_DEV_IDEDMA_PCI=3Dy=0A= CONFIG_BLK_DEV_ADMA=3Dy=0A= # CONFIG_BLK_DEV_OFFBOARD is not set=0A= CONFIG_IDEDMA_PCI_AUTO=3Dy=0A= CONFIG_BLK_DEV_IDEDMA=3Dy=0A= # CONFIG_IDEDMA_PCI_WIP is not set=0A= # CONFIG_IDEDMA_NEW_DRIVE_LISTINGS is not set=0A= # CONFIG_BLK_DEV_AEC62XX is not set=0A= # CONFIG_AEC62XX_TUNING is not set=0A= # CONFIG_BLK_DEV_ALI15X3 is not set=0A= # CONFIG_WDC_ALI15X3 is not set=0A= # CONFIG_BLK_DEV_AMD74XX is not set=0A= # CONFIG_AMD74XX_OVERRIDE is not set=0A= # CONFIG_BLK_DEV_CMD64X is not set=0A= # CONFIG_BLK_DEV_CY82C693 is not set=0A= # CONFIG_BLK_DEV_CS5530 is not set=0A= # CONFIG_BLK_DEV_HPT34X is not set=0A= # CONFIG_HPT34X_AUTODMA is not set=0A= # CONFIG_BLK_DEV_HPT366 is not set=0A= CONFIG_BLK_DEV_PIIX=3Dy=0A= CONFIG_PIIX_TUNING=3Dy=0A= # CONFIG_BLK_DEV_NS87415 is not set=0A= # CONFIG_BLK_DEV_OPTI621 is not set=0A= # CONFIG_BLK_DEV_PDC202XX is not set=0A= # CONFIG_PDC202XX_BURST is not set=0A= # CONFIG_PDC202XX_FORCE is not set=0A= # CONFIG_BLK_DEV_SVWKS is not set=0A= # CONFIG_BLK_DEV_SIS5513 is not set=0A= # CONFIG_BLK_DEV_SLC90E66 is not set=0A= # CONFIG_BLK_DEV_TRM290 is not set=0A= # CONFIG_BLK_DEV_VIA82CXXX is not set=0A= # CONFIG_IDE_CHIPSETS is not set=0A= CONFIG_IDEDMA_AUTO=3Dy=0A= # CONFIG_IDEDMA_IVB is not set=0A= # CONFIG_DMA_NONPCI is not set=0A= CONFIG_BLK_DEV_IDE_MODES=3Dy=0A= # CONFIG_BLK_DEV_ATARAID is not set=0A= # CONFIG_BLK_DEV_ATARAID_PDC is not set=0A= # CONFIG_BLK_DEV_ATARAID_HPT is not set=0A= =0A= #=0A= # SCSI support=0A= #=0A= CONFIG_SCSI=3Dy=0A= CONFIG_BLK_DEV_SD=3Dy=0A= CONFIG_SD_EXTRA_DEVS=3D40=0A= # CONFIG_CHR_DEV_ST is not set=0A= # CONFIG_CHR_DEV_OSST is not set=0A= # CONFIG_BLK_DEV_SR is not set=0A= # CONFIG_CHR_DEV_SG is not set=0A= CONFIG_SCSI_DEBUG_QUEUES=3Dy=0A= CONFIG_SCSI_MULTI_LUN=3Dy=0A= # CONFIG_SCSI_CONSTANTS is not set=0A= # CONFIG_SCSI_LOGGING is not set=0A= =0A= #=0A= # SCSI low-level drivers=0A= #=0A= # CONFIG_BLK_DEV_3W_XXXX_RAID is not set=0A= # CONFIG_SCSI_7000FASST is not set=0A= # CONFIG_SCSI_ACARD is not set=0A= # CONFIG_SCSI_AHA152X is not set=0A= # CONFIG_SCSI_AHA1542 is not set=0A= # CONFIG_SCSI_AHA1740 is not set=0A= CONFIG_SCSI_AIC7XXX=3Dy=0A= CONFIG_AIC7XXX_CMDS_PER_DEVICE=3D253=0A= CONFIG_AIC7XXX_RESET_DELAY_MS=3D15000=0A= CONFIG_AIC7XXX_BUILD_FIRMWARE=3Dy=0A= # CONFIG_SCSI_DPT_I2O is not set=0A= # CONFIG_SCSI_ADVANSYS is not set=0A= # CONFIG_SCSI_IN2000 is not set=0A= # CONFIG_SCSI_AM53C974 is not set=0A= # CONFIG_SCSI_MEGARAID is not set=0A= # CONFIG_SCSI_BUSLOGIC is not set=0A= # CONFIG_SCSI_CPQFCTS is not set=0A= # CONFIG_SCSI_DMX3191D is not set=0A= # CONFIG_SCSI_DTC3280 is not set=0A= # CONFIG_SCSI_EATA is not set=0A= # CONFIG_SCSI_EATA_DMA is not set=0A= # CONFIG_SCSI_EATA_PIO is not set=0A= # CONFIG_SCSI_FUTURE_DOMAIN is not set=0A= # CONFIG_SCSI_GDTH is not set=0A= # CONFIG_SCSI_GENERIC_NCR5380 is not set=0A= # CONFIG_SCSI_IPS is not set=0A= # CONFIG_SCSI_INITIO is not set=0A= # CONFIG_SCSI_INIA100 is not set=0A= # CONFIG_SCSI_NCR53C406A is not set=0A= # CONFIG_SCSI_NCR53C7xx is not set=0A= # CONFIG_SCSI_NCR53C8XX is not set=0A= # CONFIG_SCSI_SYM53C8XX is not set=0A= # CONFIG_SCSI_PAS16 is not set=0A= # CONFIG_SCSI_PCI2000 is not set=0A= # CONFIG_SCSI_PCI2220I is not set=0A= # CONFIG_SCSI_PSI240I is not set=0A= # CONFIG_SCSI_QLOGIC_FAS is not set=0A= # CONFIG_SCSI_QLOGIC_ISP is not set=0A= # CONFIG_SCSI_QLOGIC_FC is not set=0A= # CONFIG_SCSI_QLOGIC_1280 is not set=0A= # CONFIG_SCSI_SEAGATE is not set=0A= # CONFIG_SCSI_SIM710 is not set=0A= # CONFIG_SCSI_SYM53C416 is not set=0A= # CONFIG_SCSI_DC390T is not set=0A= # CONFIG_SCSI_T128 is not set=0A= # CONFIG_SCSI_U14_34F is not set=0A= # CONFIG_SCSI_ULTRASTOR is not set=0A= # CONFIG_SCSI_DEBUG is not set=0A= =0A= #=0A= # PCMCIA SCSI adapter support=0A= #=0A= # CONFIG_SCSI_PCMCIA is not set=0A= =0A= #=0A= # Fusion MPT device support=0A= #=0A= # CONFIG_FUSION is not set=0A= # CONFIG_FUSION_BOOT is not set=0A= # CONFIG_FUSION_ISENSE is not set=0A= # CONFIG_FUSION_CTL is not set=0A= # CONFIG_FUSION_LAN is not set=0A= =0A= #=0A= # IEEE 1394 (FireWire) support (EXPERIMENTAL)=0A= #=0A= # CONFIG_IEEE1394 is not set=0A= =0A= #=0A= # I2O device support=0A= #=0A= # CONFIG_I2O is not set=0A= # CONFIG_I2O_PCI is not set=0A= # CONFIG_I2O_BLOCK is not set=0A= # CONFIG_I2O_LAN is not set=0A= # CONFIG_I2O_SCSI is not set=0A= # CONFIG_I2O_PROC is not set=0A= =0A= #=0A= # Network device support=0A= #=0A= CONFIG_NETDEVICES=3Dy=0A= =0A= #=0A= # ARCnet devices=0A= #=0A= # CONFIG_ARCNET is not set=0A= CONFIG_DUMMY=3Dm=0A= # CONFIG_BONDING is not set=0A= # CONFIG_EQUALIZER is not set=0A= # CONFIG_TUN is not set=0A= =0A= #=0A= # Ethernet (10 or 100Mbit)=0A= #=0A= CONFIG_NET_ETHERNET=3Dy=0A= # CONFIG_SUNLANCE is not set=0A= # CONFIG_HAPPYMEAL is not set=0A= # CONFIG_SUNBMAC is not set=0A= # CONFIG_SUNQE is not set=0A= # CONFIG_SUNLANCE is not set=0A= # CONFIG_SUNGEM is not set=0A= # CONFIG_NET_VENDOR_3COM is not set=0A= # CONFIG_LANCE is not set=0A= # CONFIG_NET_VENDOR_SMC is not set=0A= # CONFIG_NET_VENDOR_RACAL is not set=0A= # CONFIG_AT1700 is not set=0A= # CONFIG_DEPCA is not set=0A= # CONFIG_HP100 is not set=0A= # CONFIG_NET_ISA is not set=0A= CONFIG_NET_PCI=3Dy=0A= # CONFIG_PCNET32 is not set=0A= # CONFIG_ADAPTEC_STARFIRE is not set=0A= # CONFIG_AC3200 is not set=0A= # CONFIG_APRICOT is not set=0A= # CONFIG_CS89x0 is not set=0A= # CONFIG_TULIP is not set=0A= # CONFIG_DE4X5 is not set=0A= # CONFIG_DGRS is not set=0A= # CONFIG_DM9102 is not set=0A= CONFIG_EEPRO100=3Dy=0A= # CONFIG_LNE390 is not set=0A= # CONFIG_FEALNX is not set=0A= # CONFIG_NATSEMI is not set=0A= # CONFIG_NE2K_PCI is not set=0A= # CONFIG_NE3210 is not set=0A= # CONFIG_ES3210 is not set=0A= # CONFIG_8139CP is not set=0A= # CONFIG_8139TOO is not set=0A= # CONFIG_8139TOO_PIO is not set=0A= # CONFIG_8139TOO_TUNE_TWISTER is not set=0A= # CONFIG_8139TOO_8129 is not set=0A= # CONFIG_SIS900 is not set=0A= # CONFIG_EPIC100 is not set=0A= # CONFIG_SUNDANCE is not set=0A= # CONFIG_TLAN is not set=0A= # CONFIG_VIA_RHINE is not set=0A= # CONFIG_WINBOND_840 is not set=0A= # CONFIG_NET_POCKET is not set=0A= =0A= #=0A= # Ethernet (1000 Mbit)=0A= #=0A= # CONFIG_ACENIC is not set=0A= # CONFIG_DL2K is not set=0A= # CONFIG_MYRI_SBUS is not set=0A= # CONFIG_NS83820 is not set=0A= # CONFIG_HAMACHI is not set=0A= # CONFIG_YELLOWFIN is not set=0A= # CONFIG_SK98LIN is not set=0A= # CONFIG_FDDI is not set=0A= # CONFIG_HIPPI is not set=0A= # CONFIG_PLIP is not set=0A= # CONFIG_PPP is not set=0A= # CONFIG_SLIP is not set=0A= =0A= #=0A= # Wireless LAN (non-hamradio)=0A= #=0A= # CONFIG_NET_RADIO is not set=0A= =0A= #=0A= # Token Ring devices=0A= #=0A= # CONFIG_TR is not set=0A= # CONFIG_NET_FC is not set=0A= # CONFIG_RCPCI is not set=0A= # CONFIG_SHAPER is not set=0A= =0A= #=0A= # Wan interfaces=0A= #=0A= # CONFIG_WAN is not set=0A= =0A= #=0A= # PCMCIA network device support=0A= #=0A= CONFIG_NET_PCMCIA=3Dy=0A= # CONFIG_PCMCIA_3C589 is not set=0A= # CONFIG_PCMCIA_3C574 is not set=0A= # CONFIG_PCMCIA_FMVJ18X is not set=0A= CONFIG_PCMCIA_PCNET=3Dy=0A= # CONFIG_PCMCIA_NMCLAN is not set=0A= # CONFIG_PCMCIA_SMC91C92 is not set=0A= # CONFIG_PCMCIA_XIRC2PS is not set=0A= # CONFIG_ARCNET_COM20020_CS is not set=0A= # CONFIG_PCMCIA_IBMTR is not set=0A= # CONFIG_PCMCIA_XIRCOM is not set=0A= # CONFIG_PCMCIA_XIRTULIP is not set=0A= CONFIG_NET_PCMCIA_RADIO=3Dy=0A= CONFIG_PCMCIA_RAYCS=3Dy=0A= # CONFIG_PCMCIA_NETWAVE is not set=0A= # CONFIG_PCMCIA_WAVELAN is not set=0A= # CONFIG_AIRONET4500_CS is not set=0A= =0A= #=0A= # Amateur Radio support=0A= #=0A= # CONFIG_HAMRADIO is not set=0A= =0A= #=0A= # IrDA (infrared) support=0A= #=0A= # CONFIG_IRDA is not set=0A= =0A= #=0A= # ISDN subsystem=0A= #=0A= # CONFIG_ISDN is not set=0A= =0A= #=0A= # Old CD-ROM drivers (not SCSI, not IDE)=0A= #=0A= # CONFIG_CD_NO_IDESCSI is not set=0A= =0A= #=0A= # Input core support=0A= #=0A= # CONFIG_INPUT is not set=0A= # CONFIG_INPUT_KEYBDEV is not set=0A= # CONFIG_INPUT_MOUSEDEV is not set=0A= # CONFIG_INPUT_JOYDEV is not set=0A= # CONFIG_INPUT_EVDEV is not set=0A= =0A= #=0A= # Character devices=0A= #=0A= CONFIG_VT=3Dy=0A= CONFIG_VT_CONSOLE=3Dy=0A= CONFIG_SERIAL=3Dy=0A= # CONFIG_SERIAL_CONSOLE is not set=0A= # CONFIG_SERIAL_EXTENDED is not set=0A= # CONFIG_SERIAL_NONSTANDARD is not set=0A= CONFIG_UNIX98_PTYS=3Dy=0A= CONFIG_UNIX98_PTY_COUNT=3D256=0A= =0A= #=0A= # I2C support=0A= #=0A= # CONFIG_I2C is not set=0A= =0A= #=0A= # Mice=0A= #=0A= # CONFIG_BUSMOUSE is not set=0A= # CONFIG_MOUSE is not set=0A= =0A= #=0A= # Joysticks=0A= #=0A= # CONFIG_INPUT_GAMEPORT is not set=0A= # CONFIG_QIC02_TAPE is not set=0A= =0A= #=0A= # Watchdog Cards=0A= #=0A= # CONFIG_WATCHDOG is not set=0A= # CONFIG_INTEL_RNG is not set=0A= # CONFIG_NVRAM is not set=0A= # CONFIG_RTC is not set=0A= # CONFIG_DTLK is not set=0A= # CONFIG_R3964 is not set=0A= # CONFIG_APPLICOM is not set=0A= # CONFIG_SONYPI is not set=0A= =0A= #=0A= # Ftape, the floppy tape device driver=0A= #=0A= # CONFIG_FTAPE is not set=0A= # CONFIG_AGP is not set=0A= # CONFIG_DRM is not set=0A= =0A= #=0A= # PCMCIA character devices=0A= #=0A= # CONFIG_PCMCIA_SERIAL_CS is not set=0A= # CONFIG_MWAVE is not set=0A= =0A= #=0A= # Multimedia devices=0A= #=0A= # CONFIG_VIDEO_DEV is not set=0A= =0A= #=0A= # File systems=0A= #=0A= # CONFIG_QUOTA is not set=0A= CONFIG_FS_POSIX_ACL=3Dy=0A= # CONFIG_AUTOFS_FS is not set=0A= CONFIG_AUTOFS4_FS=3Dy=0A= # CONFIG_REISERFS_FS is not set=0A= # CONFIG_REISERFS_CHECK is not set=0A= # CONFIG_ADFS_FS is not set=0A= # CONFIG_ADFS_FS_RW is not set=0A= # CONFIG_AFFS_FS is not set=0A= # CONFIG_HFS_FS is not set=0A= # CONFIG_BFS_FS is not set=0A= CONFIG_FAT_FS=3Dy=0A= CONFIG_MSDOS_FS=3Dy=0A= # CONFIG_UMSDOS_FS is not set=0A= CONFIG_VFAT_FS=3Dy=0A= # CONFIG_EFS_FS is not set=0A= # CONFIG_JFFS_FS is not set=0A= # CONFIG_JFFS2_FS is not set=0A= # CONFIG_CRAMFS is not set=0A= # CONFIG_TMPFS is not set=0A= # CONFIG_RAMFS is not set=0A= CONFIG_ISO9660_FS=3Dy=0A= # CONFIG_JOLIET is not set=0A= # CONFIG_MINIX_FS is not set=0A= # CONFIG_VXFS_FS is not set=0A= # CONFIG_NTFS_FS is not set=0A= # CONFIG_NTFS_RW is not set=0A= # CONFIG_HPFS_FS is not set=0A= CONFIG_PROC_FS=3Dy=0A= # CONFIG_DEVFS_FS is not set=0A= # CONFIG_DEVFS_MOUNT is not set=0A= # CONFIG_DEVFS_DEBUG is not set=0A= CONFIG_DEVPTS_FS=3Dy=0A= # CONFIG_QNX4FS_FS is not set=0A= # CONFIG_QNX4FS_RW is not set=0A= # CONFIG_ROMFS_FS is not set=0A= CONFIG_EXT2_FS=3Dy=0A= # CONFIG_SYSV_FS is not set=0A= # CONFIG_UDF_FS is not set=0A= # CONFIG_UDF_RW is not set=0A= # CONFIG_UFS_FS is not set=0A= # CONFIG_UFS_FS_WRITE is not set=0A= CONFIG_PAGE_BUF=3Dy=0A= CONFIG_XFS_FS=3Dy=0A= # CONFIG_XFS_RT is not set=0A= CONFIG_HAVE_ATTRCTL=3Dy=0A= CONFIG_XFS_DMAPI=3Dy=0A= # CONFIG_XFS_QUOTA is not set=0A= =0A= #=0A= # Network File Systems=0A= #=0A= # CONFIG_CODA_FS is not set=0A= # CONFIG_NFS_FS is not set=0A= # CONFIG_NFS_V3 is not set=0A= # CONFIG_ROOT_NFS is not set=0A= # CONFIG_NFSD is not set=0A= # CONFIG_NFSD_V3 is not set=0A= # CONFIG_SUNRPC is not set=0A= # CONFIG_LOCKD is not set=0A= # CONFIG_SMB_FS is not set=0A= # CONFIG_NCP_FS is not set=0A= # CONFIG_NCPFS_PACKET_SIGNING is not set=0A= # CONFIG_NCPFS_IOCTL_LOCKING is not set=0A= # CONFIG_NCPFS_STRONG is not set=0A= # CONFIG_NCPFS_NFS_NS is not set=0A= # CONFIG_NCPFS_OS2_NS is not set=0A= # CONFIG_NCPFS_SMALLDOS is not set=0A= # CONFIG_NCPFS_NLS is not set=0A= # CONFIG_NCPFS_EXTRAS is not set=0A= =0A= #=0A= # Partition Types=0A= #=0A= # CONFIG_PARTITION_ADVANCED is not set=0A= CONFIG_MSDOS_PARTITION=3Dy=0A= # CONFIG_SMB_NLS is not set=0A= CONFIG_NLS=3Dy=0A= =0A= #=0A= # Native Language Support=0A= #=0A= CONFIG_NLS_DEFAULT=3D"iso8859-1"=0A= CONFIG_NLS_CODEPAGE_437=3Dy=0A= # CONFIG_NLS_CODEPAGE_737 is not set=0A= # CONFIG_NLS_CODEPAGE_775 is not set=0A= # CONFIG_NLS_CODEPAGE_850 is not set=0A= # CONFIG_NLS_CODEPAGE_852 is not set=0A= # CONFIG_NLS_CODEPAGE_855 is not set=0A= # CONFIG_NLS_CODEPAGE_857 is not set=0A= # CONFIG_NLS_CODEPAGE_860 is not set=0A= # CONFIG_NLS_CODEPAGE_861 is not set=0A= # CONFIG_NLS_CODEPAGE_862 is not set=0A= # CONFIG_NLS_CODEPAGE_863 is not set=0A= # CONFIG_NLS_CODEPAGE_864 is not set=0A= # CONFIG_NLS_CODEPAGE_865 is not set=0A= # CONFIG_NLS_CODEPAGE_866 is not set=0A= # CONFIG_NLS_CODEPAGE_869 is not set=0A= # CONFIG_NLS_CODEPAGE_936 is not set=0A= # CONFIG_NLS_CODEPAGE_950 is not set=0A= # CONFIG_NLS_CODEPAGE_932 is not set=0A= # CONFIG_NLS_CODEPAGE_949 is not set=0A= # CONFIG_NLS_CODEPAGE_874 is not set=0A= # CONFIG_NLS_ISO8859_8 is not set=0A= # CONFIG_NLS_CODEPAGE_1251 is not set=0A= # CONFIG_NLS_ISO8859_1 is not set=0A= # CONFIG_NLS_ISO8859_2 is not set=0A= # CONFIG_NLS_ISO8859_3 is not set=0A= # CONFIG_NLS_ISO8859_4 is not set=0A= # CONFIG_NLS_ISO8859_5 is not set=0A= # CONFIG_NLS_ISO8859_6 is not set=0A= # CONFIG_NLS_ISO8859_7 is not set=0A= # CONFIG_NLS_ISO8859_9 is not set=0A= # CONFIG_NLS_ISO8859_13 is not set=0A= # CONFIG_NLS_ISO8859_14 is not set=0A= # CONFIG_NLS_ISO8859_15 is not set=0A= # CONFIG_NLS_KOI8_R is not set=0A= # CONFIG_NLS_KOI8_U is not set=0A= # CONFIG_NLS_UTF8 is not set=0A= =0A= #=0A= # Console drivers=0A= #=0A= CONFIG_VGA_CONSOLE=3Dy=0A= # CONFIG_VIDEO_SELECT is not set=0A= # CONFIG_MDA_CONSOLE is not set=0A= =0A= #=0A= # Frame-buffer support=0A= #=0A= # CONFIG_FB is not set=0A= =0A= #=0A= # Sound=0A= #=0A= # CONFIG_SOUND is not set=0A= =0A= #=0A= # USB support=0A= #=0A= # CONFIG_USB is not set=0A= # CONFIG_USB_UHCI is not set=0A= # CONFIG_USB_UHCI_ALT is not set=0A= # CONFIG_USB_OHCI is not set=0A= # CONFIG_USB_AUDIO is not set=0A= # CONFIG_USB_BLUETOOTH is not set=0A= # CONFIG_USB_STORAGE is not set=0A= # CONFIG_USB_STORAGE_DEBUG is not set=0A= # CONFIG_USB_STORAGE_DATAFAB is not set=0A= # CONFIG_USB_STORAGE_FREECOM is not set=0A= # CONFIG_USB_STORAGE_ISD200 is not set=0A= # CONFIG_USB_STORAGE_DPCM is not set=0A= # CONFIG_USB_STORAGE_HP8200e is not set=0A= # CONFIG_USB_STORAGE_SDDR09 is not set=0A= # CONFIG_USB_STORAGE_JUMPSHOT is not set=0A= # CONFIG_USB_ACM is not set=0A= # CONFIG_USB_PRINTER is not set=0A= # CONFIG_USB_DC2XX is not set=0A= # CONFIG_USB_MDC800 is not set=0A= # CONFIG_USB_SCANNER is not set=0A= # CONFIG_USB_MICROTEK is not set=0A= # CONFIG_USB_HPUSBSCSI is not set=0A= # CONFIG_USB_PEGASUS is not set=0A= # CONFIG_USB_KAWETH is not set=0A= # CONFIG_USB_CATC is not set=0A= # CONFIG_USB_CDCETHER is not set=0A= # CONFIG_USB_USBNET is not set=0A= # CONFIG_USB_USS720 is not set=0A= =0A= #=0A= # USB Serial Converter support=0A= #=0A= # CONFIG_USB_SERIAL is not set=0A= # CONFIG_USB_SERIAL_GENERIC is not set=0A= # CONFIG_USB_SERIAL_BELKIN is not set=0A= # CONFIG_USB_SERIAL_WHITEHEAT is not set=0A= # CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set=0A= # CONFIG_USB_SERIAL_EMPEG is not set=0A= # CONFIG_USB_SERIAL_FTDI_SIO is not set=0A= # CONFIG_USB_SERIAL_VISOR is not set=0A= # CONFIG_USB_SERIAL_IR is not set=0A= # CONFIG_USB_SERIAL_EDGEPORT is not set=0A= # CONFIG_USB_SERIAL_KEYSPAN_PDA is not set=0A= # CONFIG_USB_SERIAL_KEYSPAN is not set=0A= # CONFIG_USB_SERIAL_KEYSPAN_USA28 is not set=0A= # CONFIG_USB_SERIAL_KEYSPAN_USA28X is not set=0A= # CONFIG_USB_SERIAL_KEYSPAN_USA28XA is not set=0A= # CONFIG_USB_SERIAL_KEYSPAN_USA28XB is not set=0A= # CONFIG_USB_SERIAL_KEYSPAN_USA19 is not set=0A= # CONFIG_USB_SERIAL_KEYSPAN_USA18X is not set=0A= # CONFIG_USB_SERIAL_KEYSPAN_USA19W is not set=0A= # CONFIG_USB_SERIAL_KEYSPAN_USA49W is not set=0A= # CONFIG_USB_SERIAL_MCT_U232 is not set=0A= # CONFIG_USB_SERIAL_PL2303 is not set=0A= # CONFIG_USB_SERIAL_CYBERJACK is not set=0A= # CONFIG_USB_SERIAL_XIRCOM is not set=0A= # CONFIG_USB_SERIAL_OMNINET is not set=0A= # CONFIG_USB_RIO500 is not set=0A= =0A= #=0A= # Bluetooth support=0A= #=0A= # CONFIG_BLUEZ is not set=0A= =0A= #=0A= # Kernel hacking=0A= #=0A= CONFIG_DEBUG_KERNEL=3Dy=0A= # CONFIG_DEBUG_HIGHMEM is not set=0A= # CONFIG_DEBUG_SLAB is not set=0A= # CONFIG_DEBUG_IOVIRT is not set=0A= CONFIG_MAGIC_SYSRQ=3Dy=0A= # CONFIG_DEBUG_SPINLOCK is not set=0A= # CONFIG_DEBUG_BUGVERBOSE is not set=0A= # CONFIG_KDB is not set=0A= # CONFIG_KDB_MODULES is not set=0A= # CONFIG_KALLSYMS is not set=0A= # CONFIG_FRAME_POINTER is not set=0A= ------_=_NextPart_000_01C16254.4E490DF0 Content-Type: application/octet-stream; name="spew-fork.pl" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="spew-fork.pl" #!/usr/bin/perl -w=0A= =0A= $|=3D1;=0A= sub spew {=0A= open(FD, ">>spew.out.$$");=0A= while (true) {=0A= print FD "asdklfasd;kfjsad;kfjs;dlj = a;sdlkfnas,nfp9ibvp98ay085hq325l;mndfg'adfa=0A= 'sd;lmf,m/,sd\fasdfna.,mdnf.m,ansdflkjanfoiuahsel;kjrqwe\as\df]adfh\||PP= Ot'rq[tjwq.,mnt/>M>spew.out");=0A= while (true) {=0A= print FD "asdklfasd;kfjsad;kfjs;dlj = a;sdlkfnas,nfp9ibvp98ay085hq325l;mndfg'adfa=0A= 'sd;lmf,m/,sd\fasdfna.,mdnf.m,ansdflkjanfoiuahsel;kjrqwe\as\df]adfh\||PP= Ot'rq[tjwq.,mnt/>M; Wed, 31 Oct 2001 13:49:49 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA08552 for ; Wed, 31 Oct 2001 13:49:14 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA3461040; Wed, 31 Oct 2001 15:48:32 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA02609; Wed, 31 Oct 2001 15:48:32 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id f9VLihd02054; Wed, 31 Oct 2001 15:44:43 -0600 Subject: Re: Linux + XFS + SCSI = Problems? From: Steve Lord To: "Gonyou, Austin" Cc: Linux XFS Mailing List In-Reply-To: <85063BBE668FD411944400D0B744267A8886BE@AUSMAIL> References: <85063BBE668FD411944400D0B744267A8886BE@AUSMAIL> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16.99+cvs.2001.10.31.06.29 (Preview Release) Date: 31 Oct 2001 15:44:43 -0600 Message-Id: <1004564683.2013.2.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2001-10-31 at 15:37, Gonyou, Austin wrote: > I'm trying to uncover the root of an issue. > The issue is this: > When running a perl script I can get perl to jump up to 99% cpu. When this > happens, I can't kill the process. > The only thing I can do to recover properly is reset the system. Either > power cycle or reset. > Is there anyone who could attempt to run the attatched script and let me > know if they experience something similar? > > The targe configuration of the box I'm most concerned with is as follows: > 512MB RAM (ecc, parity, registered) > 1x 9GB SCSI HDD(seagate) > 1x PCI RAID controller(AMI MegaRAID express) wrthru and read-cached. > DUAL 550 PIII > RH 7.1 SGI XFS 1.0 installed or later. > non-updated perl 5.6.0(installed with 7.1) > Mount options for the filesystem I'm testing with. > /dev/sda5 on /home type xfs (rw,biosize=13,logbufs=8,osyncisdsync) > > 2.4.13 Vanilla kernel + SGI XFS patch for 2.4.13. > Attatched are the perl scripts I use to test with. Also the kernel config > I'm using. I'm pretty desparate here. > If you can offer help on this, please help! > > > -- > Austin Gonyou > Systems Architect, CCNA > Coremetrics, Inc. > Phone: 512-796-9023 > email: austin@coremetrics.com > > ---- > Austin, you did not tell me you were using biosize, have you tried without it? Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Oct 31 14:15:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9VMFLJ20774 for linux-xfs-outgoing; Wed, 31 Oct 2001 14:15:21 -0800 Received: from burgers.bubbanfriends.org (IDENT:postfix@burgers.bubbanfriends.org [216.140.122.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9VMFH020749 for ; Wed, 31 Oct 2001 14:15:17 -0800 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 3FD9D400E0A; Wed, 31 Oct 2001 17:15:19 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 30E772400216; Wed, 31 Oct 2001 17:15:19 -0500 (EST) Date: Wed, 31 Oct 2001 17:15:19 -0500 (EST) From: Mike Burger To: Eric Sandeen Cc: Subject: Re: More testing RPMs In-Reply-To: <1004564262.2022.9.camel@stout.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Question. I'm currently running the 2.4.9-7 on my RH7.1 machine. Is there really that much of a difference, or am I ok in continuing that trend. I ask as I haven't had any problems, yet, with 2.4.9-7PR3...I don't mind continuing to test these out, but I feel I should go the correct path. On 31 Oct 2001, Eric Sandeen wrote: > Ok gang, this time you get "PR4" > > ftp://oss.sgi.com/projects/xfs/download/testing/RH2.4.9-6 (for RH7.1) > ftp://oss.sgi.com/projects/xfs/download/testing/RH2.4.9-7 (for RH7.2) > > Changes in PR4: > > * Disabled (broken) xfs support in intermezzo > > * Merged in a few recent xfs fixes > > Have fun, > > -Eric > > From owner-linux-xfs@oss.sgi.com Wed Oct 31 14:27:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9VMR5x21143 for linux-xfs-outgoing; Wed, 31 Oct 2001 14:27:05 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9VMQx021121 for ; Wed, 31 Oct 2001 14:26:59 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id XAA1392032 for ; Wed, 31 Oct 2001 23:26:58 +0100 (CET) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA3464029; Wed, 31 Oct 2001 16:25:40 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id QAA04356; Wed, 31 Oct 2001 16:25:40 -0600 (CST) Subject: Re: More testing RPMs From: Eric Sandeen To: Mike Burger Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16 (Preview Release) Date: 31 Oct 2001 16:25:35 -0600 Message-Id: <1004567135.2465.14.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Mike - Assuming I've kept all my ducks in a row, the only difference between -6 and -7 is the DRM config: -Eric --- linux-2.4.9-6-RH/configs/kernel-2.4.9-i686.config Fri Oct 19 15:27:09 2001 +++ linux-2.4.9-7-RH/configs/kernel-2.4.9-i686.config Mon Oct 22 11:08:07 2001@@ -1083,13 +1083,13 @@ CONFIG_AGP_ALI=y CONFIG_AGP_SWORKS=y CONFIG_DRM=y -# CONFIG_DRM_NEW is not set -CONFIG_DRM40_TDFX=m -CONFIG_DRM40_GAMMA=m -CONFIG_DRM40_R128=m -CONFIG_DRM40_I810=m -CONFIG_DRM40_MGA=m -CONFIG_DRM40_RADEON=m +CONFIG_DRM_NEW=y +CONFIG_DRM_TDFX=m +CONFIG_DRM_GAMMA=m +CONFIG_DRM_R128=m +CONFIG_DRM_I810=m +CONFIG_DRM_MGA=m +CONFIG_DRM_RADEON=m # CONFIG_DRM41_SIS is not set CONFIG_PCMCIA_SERIAL=m -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Oct 31 14:27:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9VMRYq21249 for linux-xfs-outgoing; Wed, 31 Oct 2001 14:27:34 -0800 Received: from ausmail.coremetrics.com ([209.184.141.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9VMRS021224 for ; Wed, 31 Oct 2001 14:27:28 -0800 Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Wed, 31 Oct 2001 16:26:35 -0600 Message-ID: <85063BBE668FD411944400D0B744267A8886C5@AUSMAIL> From: "Gonyou, Austin" To: linux-xfs@oss.sgi.com Subject: RE: More testing RPMs Date: Wed, 31 Oct 2001 16:26:35 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I just started trying it. Sorry for the conusion. I started using it because I put a sleep(1); just after the print garbage and noticed that the system was writing out in 4096 byte chunks. The mount options there are from a progression of trying different things. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com > -----Original Message----- > From: Mike Burger [mailto:mburger@bubbanfriends.org] > Sent: Wednesday, October 31, 2001 4:15 PM > To: Eric Sandeen > Cc: linux-xfs@oss.sgi.com > Subject: Re: More testing RPMs > > > Question. > > I'm currently running the 2.4.9-7 on my RH7.1 machine. > > Is there really that much of a difference, or am I ok in > continuing that > trend. > > I ask as I haven't had any problems, yet, with 2.4.9-7PR3...I > don't mind > continuing to test these out, but I feel I should go the correct path. > > On 31 Oct 2001, Eric Sandeen wrote: > > > Ok gang, this time you get "PR4" > > > > ftp://oss.sgi.com/projects/xfs/download/testing/RH2.4.9-6 > (for RH7.1) > > ftp://oss.sgi.com/projects/xfs/download/testing/RH2.4.9-7 > (for RH7.2) > > > > Changes in PR4: > > > > * Disabled (broken) xfs support in intermezzo > > > > * Merged in a few recent xfs fixes > > > > Have fun, > > > > -Eric > > > > > From owner-linux-xfs@oss.sgi.com Wed Oct 31 14:30:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9VMUDW21455 for linux-xfs-outgoing; Wed, 31 Oct 2001 14:30:13 -0800 Received: from ausmail.coremetrics.com ([209.184.141.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9VMU5021433 for ; Wed, 31 Oct 2001 14:30:05 -0800 Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Wed, 31 Oct 2001 16:29:14 -0600 Message-ID: <85063BBE668FD411944400D0B744267A8886C7@AUSMAIL> From: "Gonyou, Austin" To: Linux XFS Mailing List Subject: RE: Linux + XFS + SCSI = Problems? Date: Wed, 31 Oct 2001 16:29:12 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I just started trying it. Sorry for the conusion. I started using it because I put a sleep(1); just after the print garbage and noticed that the system was writing out in 4096 byte chunks. The mount options there are from a progression of trying different things. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com > -----Original Message----- > From: Steve Lord [mailto:lord@sgi.com] > Sent: Wednesday, October 31, 2001 3:45 PM > To: Gonyou, Austin > Cc: Linux XFS Mailing List > Subject: Re: Linux + XFS + SCSI = Problems? > > > On Wed, 2001-10-31 at 15:37, Gonyou, Austin wrote: > > I'm trying to uncover the root of an issue. > > The issue is this: > > When running a perl script I can get perl to jump up to > 99% cpu. When this > > happens, I can't kill the process. > > The only thing I can do to recover properly is reset the > system. Either > > power cycle or reset. > > Is there anyone who could attempt to run the attatched > script and let me > > know if they experience something similar? > > > > The targe configuration of the box I'm most concerned with > is as follows: > > 512MB RAM (ecc, parity, registered) > > 1x 9GB SCSI HDD(seagate) > > 1x PCI RAID controller(AMI MegaRAID express) wrthru and read-cached. > > DUAL 550 PIII > > RH 7.1 SGI XFS 1.0 installed or later. > > non-updated perl 5.6.0(installed with 7.1) > > Mount options for the filesystem I'm testing with. > > /dev/sda5 on /home type xfs (rw,biosize=13,logbufs=8,osyncisdsync) > > > > 2.4.13 Vanilla kernel + SGI XFS patch for 2.4.13. > > Attatched are the perl scripts I use to test with. Also the > kernel config > > I'm using. I'm pretty desparate here. > > If you can offer help on this, please help! > > > > > > -- > > Austin Gonyou > > Systems Architect, CCNA > > Coremetrics, Inc. > > Phone: 512-796-9023 > > email: austin@coremetrics.com > > > > ---- > > > > Austin, you did not tell me you were using biosize, have you tried > without it? > > Steve > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com > From owner-linux-xfs@oss.sgi.com Wed Oct 31 18:54:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA12sJU28602 for linux-xfs-outgoing; Wed, 31 Oct 2001 18:54:19 -0800 Received: from mail.dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA12sE028580 for ; Wed, 31 Oct 2001 18:54:14 -0800 Received: from ranma.dkp.com (ranma.dkp.com [205.150.40.12]) by mail.dkp.com (Postfix) with ESMTP id 688F01AB2C for ; Wed, 31 Oct 2001 21:54:11 -0500 (EST) Received: by ranma.dkp.com (Postfix, from userid 168) id A9C8659E31; Wed, 31 Oct 2001 21:54:10 -0500 (EST) Date: Wed, 31 Oct 2001 21:54:10 -0500 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: I/O error in filesystem ("md(9,2)") meta-data dev 0x903 Message-ID: <20011031215410.F3514@dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Okay... Just had an error on a production fileserver. If I'm reading the error correctly, it means that there was an I/O error on the log device, which caused XFS to shut down. The I/O error appears to have been the result of XFS sending multiple requests for the same block to the RAID subsystem (whatever that means). I killed all daemons accessing the device, unmounted the array, ran xfs_repair, and put the array back into service. Did I do the right thing? Is my diagnosis correct? Here's the relevant entry from my /etc/fstab: /dev/md2 /n/bubba1 xfs rw,defaults,logbufs=4,logdev=/dev/md3 0 0 ...and here are the error messages: Oct 31 20:29:15 bubba kernel: raid5: multiple 1 requests for sector 65277048 Oct 31 21:24:00 bubba kernel: I/O error in filesystem ("md(9,2)") meta-data dev 0x903 block 0x17f07 Oct 31 21:24:00 bubba kernel: ("") error -1070893103 buf count 5 Oct 31 21:24:00 bubba kernel: xfs_force_shutdown(md(9,2),0x2) called from line 940 of file xfs_log.c. Return address = 0xc01c329c Oct 31 21:24:00 bubba kernel: Log I/O Error Detected. Shutting down filesystem: md(9,2) Hmmm.... I notice there's a long delay between the "multiple 1 requests..." and the filesystem shutdown. Perhaps they have nothing to do with each other - and yet that's the only "multiple 1 requests..." error in the past week of logs. Andrew Klaassen From owner-linux-xfs@oss.sgi.com Wed Oct 31 19:36:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA13aQA30024 for linux-xfs-outgoing; Wed, 31 Oct 2001 19:36:26 -0800 Received: from umbi3.umbi.umd.edu (umbi3.umbi.umd.edu [136.160.7.51]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA13aL030001 for ; Wed, 31 Oct 2001 19:36:21 -0800 Received: from umbi.umd.edu (mystery.carb.nist.gov [129.6.113.182]) by umbi3.umbi.umd.edu (Netscape Messaging Server 4.15) with ESMTP id GM3RCN00.CCG; Wed, 31 Oct 2001 22:36:23 -0500 Message-ID: <3BE0C2A6.C1D891BE@umbi.umd.edu> Date: Wed, 31 Oct 2001 22:33:58 -0500 From: Jonathan Dill Organization: CARB X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-6SGI_XFS_PR3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: Todd Raeker , Linux XFS Mailing List Subject: Re: shell filesize limit of 4 GB References: <01102909435902.11332@chemraeker1> <3BDD8E31.9C817A5@umbi.umd.edu> <01103113542200.01720@chemraeker1> <3BE05612.5BD3FFA4@umbi.umd.edu> <1004558357.8600.23.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: > I do know that if you use the limits interface then there is only 4 > bytes of space in the kernel to store limits. Which means you cannot > impose a limit of greater than 4G bytes. The rollover you are seeing > is probably because of this. Setting a limit to RLIM_INFINITY which > is 0xffffffff on i386 effectively disables the limit checking and this > is the only way to get into higher order files. How do I set the limit to RLIM_INFINITY? Trying to do it with the limit command seems to have no effect: [root@amanda ~]# limit -h filesize filesize 4194303 kbytes [root@amanda ~]# limit -h filesize 68719476736 [root@amanda ~]# limit -h filesize filesize 0 kbytes It's curious that I was still able to create a 4.7 GB file. With the old tcsh without -D_FILE_OFFSET_BITS=64, this is what I get even though I can't create > 2 GB files: [root@bit ~]# limit -h filesize filesize unlimited If I have problems the next time I'm trying to create large files, I guess I'll have to try bash and see what I can do with that. -- "Jonathan F. Dill" (dill@umbi.umd.edu) From owner-linux-xfs@oss.sgi.com Wed Oct 31 22:12:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA16CPg00887 for linux-xfs-outgoing; Wed, 31 Oct 2001 22:12:25 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA16CE000865 for ; Wed, 31 Oct 2001 22:12:14 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with SMTP id fA16C8K32028 for ; Wed, 31 Oct 2001 22:12:08 -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 RAA16425; Thu, 1 Nov 2001 17:10:48 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA00006; Thu, 1 Nov 2001 17:10:46 +1100 (AEDT) Date: Thu, 1 Nov 2001 17:10:46 +1100 From: Nathan Scott To: Jonathan Dill Cc: Todd Raeker , Linux XFS Mailing List , tcsh-bugs@mx.gw.com Subject: Re: shell filesize limit of 4 GB Message-ID: <20011101171046.E541473@wobbly.melbourne.sgi.com> References: <01102909435902.11332@chemraeker1> <3BDD8E31.9C817A5@umbi.umd.edu> <01103113542200.01720@chemraeker1> <3BE05612.5BD3FFA4@umbi.umd.edu> <1004558357.8600.23.camel@jen.americas.sgi.com> <3BE0C2A6.C1D891BE@umbi.umd.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BE0C2A6.C1D891BE@umbi.umd.edu>; from dill@umbi.umd.edu on Wed, Oct 31, 2001 at 10:33:58PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Jonathan, [For the tcsh-bugs@mx.gw.com folk, this is a Linux+XFS system with glibc 2.2.4, the problem involves setting any high limits with large file support enabled - its a tcsh/glibc header file interaction bug, by the look of things] On Wed, Oct 31, 2001 at 10:33:58PM -0500, Jonathan Dill wrote: > Steve Lord wrote: > > I do know that if you use the limits interface then there is only 4 > > bytes of space in the kernel to store limits. Which means you cannot > > impose a limit of greater than 4G bytes. The rollover you are seeing > > is probably because of this. Setting a limit to RLIM_INFINITY which > > is 0xffffffff on i386 effectively disables the limit checking and this > > is the only way to get into higher order files. > > How do I set the limit to RLIM_INFINITY? Trying to do it with the limit > command seems to have no effect: > > [root@amanda ~]# limit -h filesize > filesize 4194303 kbytes > [root@amanda ~]# limit -h filesize 68719476736 > [root@amanda ~]# limit -h filesize > filesize 0 kbytes > > It's curious that I was still able to create a 4.7 GB file. With the > old tcsh without -D_FILE_OFFSET_BITS=64, this is what I get even though > I can't create > 2 GB files: > > [root@bit ~]# limit -h filesize > filesize unlimited > > If I have problems the next time I'm trying to create large files, I > guess I'll have to try bash and see what I can do with that. > Okay... I've had another quick look at this problem. Firstly, there is a more recent version of tcsh at http://www.tcsh.org/ - so, I'm using that one (which has fixed the O_LARGEFILE issue, btw). The limit problem you describe above remains, however. So, poking around in tcsh-6.11.00/sh.func.c for my first time, the problem would appear to be a type-related bug in sh.func.c in its definition of RLIM_TYPE. Try out this patch (and verify that you get the "debug" output at compile time)... diff -Naur tcsh-6.11.00/sh.func.c tcsh-6.11.00-ns/sh.func.c --- tcsh-6.11.00/sh.func.c Tue Mar 13 23:53:50 2001 +++ tcsh-6.11.00-ns/sh.func.c Thu Nov 1 16:39:02 2001 @@ -1720,7 +1720,8 @@ # if defined(_SX) typedef long long RLIM_TYPE; # else /* _SX */ - typedef unsigned long RLIM_TYPE; +# warning debug - using unsigned long long RLIM_TYPE + typedef unsigned long long RLIM_TYPE; # endif /* _SX */ # endif /* SOLARIS2 || (sgi && SYSVREL > 3) */ # endif /* BSD4_4 && !__386BSD__ */ tcsh-6.11.00-ns# ./tcsh tcsh-6.11.00-ns# limit filesize filesize unlimited tcsh-6.11.00-ns# dd if=/dev/zero of=big bs=1024 seek=687194 count=1 1+0 records in 1+0 records out tcsh-6.11.00-ns# ls -lh big -rw-rw-r-- 1 root root 671M Nov 1 16:56 big tcsh-6.11.00-ns# dd if=/dev/zero of=bigger bs=1024 seek=6871947673 count=1 1+0 records in 1+0 records out tcsh-6.11.00-ns# ls -lh bigger -rw-rw-r-- 1 root root 6.4T Nov 1 16:56 bigger tcsh-6.11.00-ns# dd if=/dev/zero of=sick bs=1024 seek=6871947673699 count=1 1+0 records in 1+0 records out tcsh-6.11.00-ns# ls -lh sick -rw-rw-r-- 1 root root 6.3P Nov 1 16:57 sick tcsh-6.11.00-ns# tcsh-6.11.00-ns# tcsh-6.11.00-ns# limit filesize 68719476736 tcsh-6.11.00-ns# limit filesize filesize unlimited tcsh-6.11.00-ns# tcsh-6.11.00-ns# limit filesize 4194303 tcsh-6.11.00-ns# limit filesize filesize 4194303 kbytes tcsh-6.11.00-ns# limit filesize 4194304 tcsh-6.11.00-ns# limit filesize filesize unlimited tcsh-6.11.00-ns# uname -a Linux troppo 2.4.14-pre6-xfs #65 Thu Nov 1 13:06:14 EST 2001 i686 unknown tcsh-6.11.00-ns# So, that seems to work now - and not an XFS related problem. Definately a tcsh bug though. cheers. -- Nathan